How expert witnesses assess AI-assisted development in a software dispute: the standard of care, the limits of proving code provenance, automated verification and where it fails, and forming an opinion under CPR Part 35.
I write software with AI assistance most working weeks. Agentic tools sit inside my own development practice, and they sit inside the practice of most competent suppliers building commercial software today. That is the starting point for any honest assessment of an AI-related dispute: the use of these tools is no longer novel, exceptional, or in itself a sign that something went wrong.
The dispute reaches litigation by a familiar route wearing new clothes. A supplier delivers a system built substantially with AI assistance. Defects emerge, or the code proves unmaintainable, or a security failure surfaces, and the client learns how much of the work was generated rather than written by hand. The complaint that forms in response is usually some version of “they let an AI build it.”
Framed that way, the complaint goes nowhere. A dispute that turns on whether AI should have been used at all turns on a question the market has already settled, and a supplier defending the claim will say so.
The question a dispute actually turns on is narrower, and it is not really about the AI. It is whether the engineering discipline the supplier applied around the tool, the review, the testing, and the accountability for what shipped, fell below what a reasonably competent supplier would have applied under comparable constraints. I am instructed as a software expert, not as an authority on artificial intelligence, and that distinction matters. The evidence I assess is the same engineering evidence I would assess in any software dispute, read in light of how the work was actually produced. This guide documents how I approach that assessment.
What AI-Assisted Development Is, in Litigation Terms
AI assistance in software development runs along a spectrum. At one end are the autocomplete suggestions that finish a line as a developer types. In the middle sits chat-driven generation, where a developer describes what they want and the model returns a function or a module. At the far end are agentic systems that plan and write changes across a whole codebase with limited human intervention. A modern supplier may use all three on the same project, often without recording which produced what.
For a court, the important point holds across the entire spectrum. The human supplier remains the author of record and the party accountable for the result. The sophistication of the tool changes how code is produced; it does not change who owes the client a duty of competence. A supplier does not discharge its obligations by delegating them to a model, any more than it would by delegating them to an unsupervised junior.
This matters because “the AI generated it” is frequently offered, in correspondence and sometimes in evidence, as though it explained the defect away. It does not. The contract was with the supplier. The standard expected is the supplier’s standard. A statement that part of the work was machine-generated is a description of method, not a transfer of responsibility for the outcome.
The tool changes how the code was written. It does not change who is answerable for it.
What the Development Record Shows
The evidence in an AI-related dispute is, for the most part, the evidence I would gather in any software dispute. The codebase as delivered. The version control history, read as a forensic timeline. The pull-request and code-review records. The continuous-integration logs and test results. Where they survive, the contractual documents and the project correspondence that show what the client was promised and what concerns were raised along the way.
Where AI-specific traces exist, they add to that picture. Some tools retain session logs or prompt histories; configuration files record which assistant was in use and how it was set up; commit metadata occasionally points to a generation step. These can show the pace and volume of generated change, and sometimes the absence of any human checkpoint between generation and deployment.
One reading of that history is worth singling out, because it answers a question the rest of the record only circles: was the intent fixed before the code, or reconstructed after it? A disciplined supplier working at agentic speed commits the specification and the test plan to the branch before implementation begins, so the history carries an audit trail of what “done” meant before a line was written. Where that record exists, I can hold the delivered code against an intent the supplier itself fixed in advance. Where the only trace of intent is a chat session that has since been compacted or lost, there is nothing of the kind to measure the code against, and the claim that the system does what was asked rests on the supplier’s word rather than its record. The order in which things were committed is mundane metadata, and it is one of the cleaner signals of whether the work was governed or merely generated.
I am candid, in reports and at the outset of an instruction, about a limit that solicitors should understand early. Provenance is rarely recorded cleanly. Most codebases do not mark which lines came from a model, so I generally cannot prove, and do not attempt to prove, that a particular function was AI-generated. That limit matters less than it first appears, because the question that decides the dispute does not depend on it. What the record shows reliably is the discipline applied around the code, whatever its origin: whether changes were reviewed before they merged, whether tests accompanied them, whether anyone other than the original author understood what was committed.
I can seldom prove a line of code came from a model. I can almost always show whether anyone checked it.
The Standard of Care in AI-Assisted Development
The question the supplier wants the dispute to be about is whether using AI was acceptable. It is a comfortable question for the defence, because the answer is plainly yes, and a dispute that rests there resolves in the supplier’s favour before the real issue is reached.
The stronger question is not whether the supplier used AI, but how it behaved towards what the AI produced. A reasonably competent supplier discharges four duties as it works with these tools. It understands the tool’s limits, that generated code can be fluent and wrong at once, can carry security flaws, and can invent interfaces that do not exist. It verifies generated code rather than trusting it on sight, through whatever combination of human review and automated checking the risk demands, treating the model’s output as it would treat a capable but unsupervised junior’s: useful, often right, and not to be shipped unchecked. It tests the deliverable to the same standard regardless of how the code was produced, because the bar the client is owed does not fall because a machine wrote part of the work. And it retains accountability for maintainability, so that the team can explain, support, and extend what it shipped rather than depending on the tool to understand its own output.
The expectation scales with the domain and its risks. Generated code in a throwaway internal utility is one thing. Generated code handling money, personal data, or safety-critical behaviour is another, and the review and testing a court would expect around it is correspondingly heavier. A supplier that applied the same light touch to both has a harder position to defend, and the contrast is usually visible in the record.
Using AI is not a breach. Shipping its output unchecked is.
Patterns of AI-Related Development Failure in Disputes
Most AI-assisted development never reaches a dispute, and most that does is defensible. The patterns worth an expert’s attention are the ones where the use of the tool produced a result the client was entitled not to bear. A few recur.
The first is unverified generation shipped wholesale. The volume of change outran the team’s capacity to check it, and code reached production that no one had read with care and no test meaningfully exercised. The signature in the record is generation-scale velocity with no answering growth in review or test activity: a great deal of code arriving very quickly, and nothing to show it was checked on the way.
The second is plausible-but-wrong code accepted on trust. The model produced something that looked right, compiled, and passed a cursory glance, but rested on a misunderstanding: an interface used incorrectly, an edge case left unhandled, a security assumption that did not hold. I have seen this take the form of a generated enumeration whose default value silently resolved to the first member declared, so that any caller reading an unset field received the wrong setting altogether. It was fluent, it compiled, and it was wrong. Errors of that shape hide just as readily behind a name collision the model failed to notice, or an equality check that compares references where it should compare values. What cuts through is showing that the error was the kind a competent review would have caught, which moves the failing from the tool to the supplier who did not review.
The third is the comprehension gap. The supplier delivered a working system its own team could not fully explain, because the code was generated faster than anyone built an understanding of it. This is the AI-era form of a familiar maintainability failure: the client was promised an asset it could operate and extend, and received one that no one could safely change.
The fourth concerns security and provenance. Generated code can reproduce insecure patterns absorbed during training, and it can reproduce licensed code whose origin the supplier never checked. The first is a quality failure; the second can become an intellectual property question, which I examine in the context of source code and IP disputes rather than here. What these patterns share is that the harm is demonstrable without asking the court to rule on artificial intelligence at all. In each, the failure is an ordinary engineering failure that the use of AI accelerated rather than excused.
The Harness, and Where It Fails
A supplier defending its work will often make a fair point: at the speed a capable agent now generates code, no one reads every line, and a standard that demands it describes a practice nobody follows. That is true, and it is why the question that matters is not how much a human read, but what verified the code once a human could not.
This is the work that has come to be called the harness: the system of automated checks that surrounds generation. The test suite the agent runs against its own output, the type checker and the linter, the integration gate that blocks a broken change, the security and dependency scanning, and increasingly an evaluation step in which one agent’s work is checked by another before a person sees it. Where generation outpaces reading, the harness, not the human eye, becomes the primary line of quality control. Relying on it is a legitimate engineering response, not a corner cut, and a supplier that built a strong one has a sound answer to the velocity problem. The discipline has a name now, harness engineering, and the firms that build these models, Anthropic and OpenAI among them, publish detailed engineering accounts of how they do it. I keep a harness of this kind in my own day-to-day development and have published a reproducible account of how one is built and run. The techniques are neither proprietary nor secret, and a supplier cannot credibly claim there was no established way to work responsibly at this speed.
The standard of care therefore asks whether the verification around the generation was adequate to the risk the software carried, not whether a person read each line. A supplier that ran high-volume agentic generation into production with no test suite, no integration gate, and no automated checks has a weak position whatever it says about review. A supplier that can show a thorough harness has a strong one, even where line-by-line reading was light. I set out what a quality harness incorporates in detail separately.
The harness has its own failure modes, and they are where these disputes increasingly turn. It can exist and test the wrong things, exercising the easy paths and leaving the risky ones untouched. It can be trusted past what it proves, treating a passing suite as correctness when the same process generated both the code and the tests, so that the blind spots in one are the blind spots in the other. And it can be absent altogether behind a confident claim that the system works. Each of these is observable after the fact, because the harness leaves a record: the test code, the pipeline configuration, and the build logs all show what was actually checked, and what was not.
A passing test suite written by the same system that wrote the code proves less than it appears to.
Writing Findings That Survive Cross-Examination
The temptation in an AI-related report is to make the AI the story. It should be resisted. A report that leads with “the supplier used AI” invites the obvious reply that everyone does, and the opinion deflates on the first question. The methodology and the engineering evidence come first; the role of AI emerges as part of how the work was produced, not as the accusation itself.
The same honesty about provenance that I bring to the instruction belongs in the report. I do not claim to prove that specific code was machine-generated where the record will not support it, and I say as much plainly. The analysis rests on the discipline applied around the code, which is observable, and not on the attribution of authorship, which usually is not. An expert who overclaims provenance hands the cross-examiner an easy opening; an expert who is candid about the limit is far harder to dislodge on the parts of the opinion that decide the case.
Acknowledge that AI use is reasonable and widespread before explaining why this use, in this matter, fell short, and let the court weigh that context rather than appearing to have ignored it. Distinguish what the measurements show, the review coverage and the test results, from what you infer from them. I keep a detailed working log of method throughout; it never forms part of the report, but it is the best preparation there is for a difficult cross-examination.
The position that holds under pressure is never that the supplier used AI. It is that the deliverable fell below the standard the client was owed, and that the way the supplier worked with AI is how it got there.