AI-written code and the standard of a competent developer

A large and growing share of the code shipped today was not typed by a developer. It was suggested by an assistant in the editor, written by an agent working through a ticket, or generated wholesale from a prompt and lightly edited. That is not, in itself, a problem. Developers have always reused code they did not write, from libraries, frameworks, Stack Overflow answers and their own previous projects.

What has changed is the speed and the volume, and with it the gap between code that works and code that is fit to run in production. When a software dispute reaches an expert, the question is rarely “was AI used?”. It is the familiar one: did the supplier deliver software to the standard of a reasonably competent developer? AI changes the evidence available to answer that question, and it changes how easy it is to fall short.

MVP standard is not production standard

The most common pattern I see is not bad code. It is code written to one standard and sold, deployed or relied on at another.

A minimum viable product exists to prove that something can work and that someone wants it. It is allowed to cut corners deliberately: hard-coded configuration, a single region, no retry logic, happy-path validation, manual deployment, logs that go nowhere, secrets in an environment file, no load testing, and a test suite that covers the demo rather than the edge cases. Those are reasonable decisions for an MVP, provided everyone understands they have been made.

Production software carries a different set of obligations:

• Correctness under real input. Validation of every external input, defined behaviour for malformed data, idempotent handling of retries and duplicate events.
• Security. Authentication and authorisation enforced on the server, dependencies scanned and pinned, secrets held in a vault rather than the repository, least-privilege service accounts.
• Operability. Structured logging, metrics and alerting, health checks, documented runbooks, and the ability to roll back a release.
• Resilience and scale. Timeouts, back-off, rate limiting, connection pooling, and evidence from load testing that the system meets its non-functional requirements.
• Data protection. Retention rules implemented in code, personal data minimised and encrypted, and access to it logged.
• Maintainability. Code another competent developer can read, change and test without the original author in the room.

AI tools are extremely good at producing MVP-standard code. They will scaffold a working application in an afternoon, and it will demo well. They are much less reliable at the second list, because most of it is not visible in the output. A model asked to “add a payments endpoint” will usually produce one that works. It will not necessarily add idempotency keys, handle a webhook arriving twice, log without leaking card data, or fail safely when the provider times out, unless someone who knows those things matter asks for them and checks they are there.

So when I assess whether software met the required standard, one of the first things I establish is which standard was agreed. Contracts, statements of work and acceptance criteria often describe production obligations while the delivered system shows every sign of a prototype that was never hardened. The speed of AI-assisted development makes that gap easier to open and harder to notice, because the prototype looks finished.

What provenance evidence exists

A recurring question is whether it can be shown that code was AI-generated. Usually not from the code alone. Stylistic “detectors” for AI-written code are unreliable: generated code is trained on human code, developers edit what they accept, and short functions have very few distinguishing features. I would not rely on a detector score in a report, and I would expect to challenge one put forward by the other side.

The more useful evidence is in the process around the code:

• Commit metadata. Some tools add trailers to commit messages, such as a Co-Authored-By line naming the assistant, or commit under a dedicated bot identity. These are conventions rather than guarantees, since they can be switched off or edited, but where they exist they are contemporaneous.
• Agent and assistant logs. Agentic tools typically keep session transcripts: the prompt, the files read, the commands run and the changes proposed. Organisations using enterprise licences may also have usage and audit logs held by the vendor.
• Pull request history. The size and timing of changes, who reviewed them, how long review took, and what comments were made. A 4,000-line change approved eleven minutes after it was opened tells its own story, whoever wrote it.
• Ticket and CI records. Whether each change was linked to a requirement, and whether automated tests and scans ran and passed before it was merged.

None of this is new forensically. It is the same version control and pipeline evidence used in any software dispute. The point is that it needs to be preserved early, because agent logs and vendor-side records are often retained for weeks rather than years.

Licensing and third-party code

Models occasionally reproduce recognisable fragments of their training data, including code under copyleft licences. Most organisations now handle this with a combination of vendor settings that filter verbatim matches, indemnities from the tool provider, and software composition analysis in the pipeline. Whether those measures were in place is a factual question I can usually answer from the configuration and the pipeline history. Whether they were adequate is a matter for the circumstances of the case.

What a reasonably competent team does now

The standard is not “do not use AI”. It never could be: the tools are now ordinary professional equipment. In my view, a competent team using AI-generated code does the same things it always should have done, with more discipline because the volume is higher:

1. Agrees, in writing, whether a deliverable is a prototype or a production system, and what the non-functional requirements are.
2. Treats generated code as untrusted contributions that must pass the same review, testing and scanning as any other change.
3. Keeps changes small enough to review properly, rather than accepting large generated diffs in a single approval.
4. Runs security, dependency and licence scanning automatically on every change.
5. Records which tools are used, under what configuration, and keeps their logs for the life of the project.
6. Hardens before go-live: load testing, failure testing, a security review, and operational readiness checks.

Where a project has gone wrong, the evidence usually shows that one or more of these steps was skipped because the software appeared to be working. That is the gap a court is likely to care about, and it is the same gap it has always cared about. AI has just made it much faster to walk into.