The deal room is open, but the buyer’s technical team cannot tell which account controls production or how the deployed build relates to the repository. That is a handoff problem, whether the software was written by people, generated with AI or both. Code origin is not the verdict. Verifiable ownership is.
The answer in 60 seconds
Look for six signals:
- a current map of the system and its dependencies;
- a repeatable build, release and rollback path;
- controlled identities, data access and secrets;
- critical journeys tested beyond the happy path;
- observable operations, recovery and a workable support model;
- named human owners, recorded decisions and known debt.
Those signals support three decisions: accept and operate, accept with bounded hardening, or pause and rescue.
In this article
- The real test is not “who wrote the code?”
- Three business moments that expose a weak handoff
- The six evidence packs a receiving team needs
- The ten-question takeover test
- Decide: take over, harden or pause
- What a professional assessment should produce
- Conclusion: ownership has to be demonstrated
The real test is not “who wrote the code?”
AI-assisted development ranges from suggested lines to agent-led implementation. Research reports mixed, context-dependent results; it does not justify treating AI-built software as inherently better or worse (NCSC, Geruslu, Aliyeva and Tüzün).
The useful question is narrower: can an accountable team explain important flows, create a release, investigate failure and make a responsible change? Review depth should rise with the consequences and sensitivity of failure. A named owner does not prove correctness, but production decisions should not be ownerless.
This distinction helps avoid two poor decisions: rejecting a workable product because AI touched it, or accepting an impressive demo without evidence of production readiness.
Three business moments that expose a weak handoff
An enterprise customer starts technical review
The buyer may ask who can access customer data, what validates a release and what follows a failed deployment. Written policy is useful; current artefacts and demonstrated procedures are stronger evidence. AI-agent permissions and access control can be examined separately without replacing the handoff question.
An investor or acquirer begins technical due diligence
A functioning product does not reveal whether critical dependencies, release or the support model will transfer. The decision needs boundaries: what is understood, what requires hardening, and what remains too uncertain to accept.
The builder leaves
A repository export is not operational ownership. Cloud accounts, deployment knowledge and incident history may still sit with a founder, freelancer or outgoing agency. The gap becomes visible when the new team cannot ship or respond to a fault independently.
The six evidence packs a receiving team needs
An evidence pack combines current artefacts with actions the receiving team can perform. Documentation shows the intended path; execution tests whether it still works.
1. System and dependency map
Buyer question: What must we understand and control to run the critical journey? Concrete evidence: A current architecture view, request and data flows, services, suppliers, versions, owners, maintenance status and exit constraints for critical dependencies. Failure exposed when missing: An unknown single point of failure, abandoned component or supplier dependency with no owner. Google’s launch guidance puts architecture, dependencies and failure modes within readiness review, while warning that checklists must fit context (Google SRE).
2. Reproducible build and release path
Buyer question: Can the receiving team release the product from its source? Concrete evidence: Declared environment, build command, pipeline, source revision, linked artefact, deployment procedure and exercised rollback. Failure exposed when missing: A release dependent on the outgoing builder’s laptop, memory or credentials. Build provenance can link an artefact to source and build steps; it does not prove quality, security or maintainability (SLSA).
3. Security, identity, data and secrets
Buyer question: Who actually controls sensitive access and assets after the handoff? Concrete evidence: An identity and account inventory, effective permissions, organisational ownership, demonstrated revocation or rotation, secret locations without exposed values, dependency status and inspected CI/CD changes. Failure exposed when missing: An irreplaceable personal account, shared secret, excessive permission or pipeline that nobody owns. OWASP treats these as a connected control surface and calls for human accountability and independent review (OWASP).
4. Critical-journey tests and failure evidence
Buyer question: Does important behaviour hold under invalid, edge and plausible abuse conditions as well as the happy path? Concrete evidence: Requirements linked to normal, boundary, negative and adversarial cases; recorded results; known defects; and competent review of security-critical behaviour and test changes. Failure exposed when missing: A green test suite that checks only assumptions made by the same agent that changed the code. Passing tests remain useful evidence, but not independent security assurance.
5. Operations, recovery and support
Buyer question: Can the team detect, decide, communicate and restore when customers experience failure? Concrete evidence: Logs, metrics or traces tied to critical journeys, owned alerts, operating procedures, incident records, an observed rollback or restoration exercise and clear support responsibilities. Failure exposed when missing: A backup never restored, an alert with no responder or a support promise with no operating owner. Recovery guidance emphasises scoped, monitored exercises and documented results, not a backup checkbox (Google Cloud).
6. Human ownership, decisions, documentation and known debt
Buyer question: Who will make decisions after transfer, and what knowledge will those decisions rely on? Concrete evidence: Named owners for product, code, data, operations and support; decision records; prioritised debt; walkthroughs; and hands-on exercises performed by the receiving team. Failure exposed when missing: Orphaned documentation, implicit responsibility or recurring dependence on the outgoing builder. Debt should be connected to business consequences; it is not an automatic argument for a rewrite. See IZZY’s separate technical-debt decision framework.
The ten-question takeover test
This is a decision aid, not a score. Each answer should point to a current artefact, a demonstrated action or a named owner.
- Which map connects the critical customer journey to the services, data stores and suppliers behind it?
- Which inventory records the version, owner, maintenance state and exit constraint of each critical dependency?
- Which source revision produced the deployed artefact, through which verifiable build steps?
- Can someone on the receiving team run the build, deployment and intended rollback now?
- Which record connects accounts, identities, roles, secrets and revocation rights to organisational owners?
- Which results cover the critical journey under normal, boundary, invalid and abuse conditions?
- Which usable signal lets a named responder diagnose a customer-visible failure?
- Which rollback or restoration of the critical scope has been exercised, observed and recorded?
- Who detects, decides, responds, communicates and restores service during an incident?
- Which known debt, decision records and practical transfer exercises has the receiving team examined?
Decide: take over, harden or pause
The result depends on the product, transaction and consequences - not a universal threshold.
| Observed situation | Decision | Next move |
|---|---|---|
| Critical journeys are understood; build, release, observation and recovery have been demonstrated; responsibilities are assigned. | Accept and operate | Transfer access progressively and watch the first changes under the new owners. |
| The core is operable, but bounded gaps remain in security, testing, dependency exit or operations. | Accept with bounded hardening | Define risks, owners, exit criteria and the order of remediation. |
| The team cannot build, deploy or restore the critical scope, or material unknowns prevent accountable ownership. | Pause and rescue | Stabilise access and service, reconstruct missing evidence, then reassess the handoff. |
What a professional assessment should produce
A useful assessment does more than list defects. It should map architecture, dependencies and ownership; record which builds, releases, controls, signals and recovery exercises were actually observed; and separate verified facts from unresolved questions. The NIST Secure Software Development Framework can provide shared language for buyer-supplier discussions, but it is not a takeover certification.
Findings should be prioritised by business consequence: an unavailable journey, exposed data, blocked release, fragile recovery or dependency on one person. The output should define owners, sequencing and exit criteria for an executable remediation path. It should also identify where specialist work - such as penetration testing, legal review or intellectual-property analysis - is outside scope.
Automated scanners can surface candidates for investigation. Material findings still need architectural context, exploitability review and human validation before they become decision evidence. A clean scan cannot establish safety or production readiness.
Conclusion: ownership has to be demonstrated
Possessing the files is not the same as owning the product operationally. A credible handoff exists when another team can understand, change, release, observe and restore the service under explicit human responsibility. Where the evidence is already present, the decision may be accept and operate. Other products need a bounded hardening plan. A rewrite is not the default verdict.
Prepare the handoff before it becomes an emergency
For a 30-minute scoping conversation, bring repository read access or an export; any architecture and deployment notes available, even if incomplete; one critical customer journey; known incidents or support pain; and the date and context of the handoff, enterprise review or deal.
The conversation establishes an initial decision path: accept and operate, define bounded hardening, or prepare a rescue. This is not a free audit, certification or promise of buyer acceptance.
Frequently asked questions
No. The available findings vary by task, method and context (Molison et al.). Assess the product’s critical behaviour, security, operability and accountable ownership rather than its origin label.
No. They can identify items for investigation, but relevant findings need validation and context. Scanners do not show by themselves whether the team can release, recover or support the service.
When the architecture persistently blocks the target journey, critical dependencies can no longer be maintained, or restoring an operable core is less viable than rebuilding the useful scope. Compare explicit scenarios and consequences; “AI-built” is not a sufficient reason.
Their availability can help with walkthroughs and bounded support, but it should not become a permanent dependency. An important evidence point is that the receiving team performs critical procedures itself. Google SRE describes training and progressive transfer as parts of accepting production responsibility, without establishing a universal process (Google SRE).
No. It can identify escalation needs, but the scope must be explicit. Penetration testing, regulatory analysis, contract review and intellectual-property checks require their own evidence and expertise. For transactions, see IZZY’s separate technical due diligence service.
Sources and method
This framework synthesises official guidance, technical specifications and bounded open research checked on 22 July 2026. The sources inform what evidence to request; they do not establish a universal handoff standard or measure every AI-built product. Research findings remain limited to their stated methods and samples.
- NCSC - The “vibe coding spectrum” approach to AI-assisted software development
- OWASP - Secure Coding with AI Cheat Sheet
- NIST - Secure Software Development Framework, SP 800-218
- Google SRE - The Evolving SRE Engagement Model
- Google SRE - Reliable Product Launches at Scale
- Google Cloud - Perform testing for recovery from failures
- SLSA - Provenance, specification v1.2
- NIST - Incident Response Recommendations, SP 800-61 Rev. 3
- OpenTelemetry - Observability primer
- Molison et al. - Is LLM-Generated Code More Maintainable & Reliable than Human-Written Code?
- Geruslu, Aliyeva and Tüzün - Factors Influencing the Quality of AI-Generated Code