What a genuine handover looks like when the client uses AI coding tools.

A client commissions a custom application and plans to maintain it with its own engineers using AI coding agents. The supplier transfers a repository and declares the work complete. The next engineer discovers undocumented environment variables, external services, model assumptions and fragile deployment steps.

The decision behind the technology

The modern handover cannot stop at access. Generative tooling increases the ease of making changes, which makes architectural context, tests and operational documentation more important. A coding agent needs reliable constraints rather than a repository of unknown conventions.

A better way to frame the work

Provide architecture decision records, system/data flow, dependency and license register, environment setup, deployment runbook, tests, evaluation cases, permissions matrix, known risks and acceptance history. Validate the handover with a second person actually building and releasing a bounded change.

Put the idea under realistic pressure

Ask a new engineer to recreate an environment, run tests, change a nontrivial rule and prove behavior still holds. Record every undocumented step. That exercise is a better measure of independence than merely transferring the GitHub organization.

When the recommendation changes

A client may legitimately retain a managed engineering partner. Ownership does not require every company to staff its own technical operations. It does require the option to change provider without unnecessary lock-in, subject to the contract.

What to decide before moving forward

Define what custom IP transfers, what remains licensed, what documentation is included and how access is managed after acceptance. Treat handover as a testable milestone.

References and context

Stack Overflow Developer Survey 2026; NIST AI RMF.