Fixed price, AI-generated code, and the warranty period
What changes in the arithmetic of a contract when the code is generated: the warranty, the scope, the milestones, and the part of the work that will still be ordered.
Most of this blog is written for any team that ships software and has to answer for it. This piece is for the narrower case that taught me most of it: software built under contract, for a fixed price, with an acceptance date and a warranty period, for a client who knows their own domain better than the people building for them. If that is not your situation, the ten articles in the series are the general case. If it is, here is the arithmetic that the general case leaves out.
The warranty
On a fixed-price contract, every defect that escapes into the warranty period is fixed with your own money. The client paid for a working system; the fix is yours to fund, from the margin you quoted. That was always true. What changed is the rate at which code is produced and the rate at which it is checked. When a model generates most of the code, the volume of change per week goes up, the number of people who have read every line goes down, and the warranty period becomes the place where the difference is collected.
So the verification stack is not an abstract quality cost. It is priced insurance, and the premium can be compared to the claim. A unit test that takes a minute to generate and runs in milliseconds, against a warranty fix that costs a day of a senior engineer plus a deployment plus a conversation with the client. A mutation score that shows the tests are real, against the test suite that passed and the defect that shipped anyway. An exploratory session on the staging environment every two days, against the acceptance meeting where the client finds what the suite could not describe. On a fixed price the cheapest verification is the kind that runs before the code reaches a person, and the most expensive is the kind the client performs after delivery.
One consequence for quoting. Teams used to quote from effort: so many person-days to build. When building is cheap and checking is not, the quote has to be built from the verification plan: which layers, how many cases, what evidence, and how long the person who has to accept it will need. A quote that prices generation and leaves verification as “testing, two weeks” has priced the cheap half.
Scope on a fixed price
The decomposition piece argued that work should be cut into units that merge independently and verify independently, and that the task graph is the dashboard of the project. On a fixed-price contract the same graph does three more jobs.
It is the work breakdown you quote from. Each node has a done condition the machine can check, so the quote is a list of checkable things rather than a list of hopes.
It is the progress report the client can read. A node that is merged and verified is a piece of behaviour the client can see running, which is a better report than “back end seventy percent done”, and harder to argue with. Demonstrate each vertical slice as it lands.
It is scope control. When the client asks for one more thing, it is a node, with a done condition, with a place in the graph, with a visible effect on the critical path. The conversation about whether it is in scope happens over a graph rather than over a feeling.
Contracts still ask for milestones and dates, and the honest way to produce them is to project the living graph onto a timeline: group the nodes into acceptance batches, divide the nodes remaining by the measured throughput, how many nodes clear the gates per week, and put buffer on the nodes in risky zones. Internally the team runs by the graph; externally it reports by milestone. One source of data, two presentations. The failure mode is letting the contract’s presentation drive the internal work, which is the shortest road back to a waterfall with a model at the keyboard.
The documents the contract requires
Some delivery cultures require a basic design document, a detailed design document and a test specification as deliverables, and in the Japanese tradition they have names: 基本設計書, 詳細設計書, テスト仕様書. Other cultures require a security evidence pack, an architecture section in a procurement questionnaire, a traceability matrix for a regulator. They are the same kind of thing: documents that exist because someone outside the team has to accept the work and needs something to accept.
The design-docs piece gave the rule: decisions flow down from people, text flows out of the model, and deliverable documents are rendered from the decision documents and from the code. For contract work two details are worth adding.
The detailed design document existed to coordinate a designer and a coder who were different people, often in different companies. Now the coder is an agent, and the per-task plan reviewed at the plan gate is the detailed design, generated right before each task. If the contract still requires the document, render it from the code after the fact and attach the reviewed plans as the trace. Do not let the obligation to deliver a document pull you back into designing in advance what did not need designing in advance.
The test specification plus evidence is where the machine earns its keep twice. Generate the specification from the acceptance criteria, one criterion, one case, steps in a fixed order, expected result in the words the criterion used. Run the automated suite. Export the results and the screenshots. The same run that gives the pipeline its verdict gives the client the evidence file, and every case in it traces back to a criterion the client agreed to.
The team the client used to see
For many clients a large manual testing team was the visible proof that quality was being taken seriously. It could be counted. It appeared in the staffing plan. Replacing it with evidence that has to be read, this many cases, this mutation score, this export per release, is a problem of trust, not of engineering. Done well it is a sales advantage: here is the evidence, read it. Done badly, the client hears “they cut testing to save money”, and the next contract goes elsewhere.
The rule from the verification piece applies with extra force: never retire the visible thing without naming what replaced it, in the client’s language. Which layer catches what now. How many cases cover the behaviour the client cares about, and which criterion each came from. What ships with each release. Who on your side owns that layer. And exploratory testing stays and grows, because it is the part that needs a person who can be surprised, and the client’s own acceptance round is exploratory testing from their side of the table.
Handing over understanding
A product company keeps its system and its people. A contract ends. The team disbands or moves to the next client, and the knowledge of the system was always hard to keep. Now add that the system was largely generated: the client receives something that neither the client nor the vendor, in the old sense, ever wrote.
Handover of understanding, not only of code and documents, is becoming a deliverable in its own right, and it may be worth pricing as one. The minimum: decision records written while the decisions were live, generated by the agent and checked by a person, so the why survives; a reference architecture used across projects, the same structure, the same conventions, the same fitness functions, so that the client receives a documented standard rather than a bespoke maze and so that what your team learned on one project is company property rather than something that dissolved when the project ended; and a record of who changed what, when, and who approved it, that the client can read without asking you.
The part that will still be ordered
One more thing the general case does not have to think about. The client also has a model now. The part of the work that was easy to specify was always the part that paid for the team, and it is the first part a client can now do in-house, because the easy-to-specify part is also the easy-to-generate part. What remains to be ordered is the part that is hard to specify, hard to verify, and expensive to get wrong: the core domain, the integrations with what the client already runs, the migration of real data, and the accountability when it fails.
Which means the process in this blog is not a way to deliver the old work faster. It is a description of the work that will still be bought: the specification, the verification, the evidence, the handover. Read the commentary on this with the usual caution, since most of it comes from people selling tools or training. But the asymmetry is plain. The client who in-houses the easy half now owns the verification of the easy half too, and may discover what it costs. The vendor who can show, in evidence the client can read, that the hard half was built right has something the model does not replace.
In Rindo the client can be invited into the project as a Viewer, where the audit trail, the revision history and the test runs are readable without asking anyone, and a project can be exported whole as one archive at the end.