# What Happens When AI Writes All the Code The client described the changes, Claude Code wrote them for twelve weeks. What had to be automated around the model to make that safe. **Canonical:** https://spoko.space/blog/when-ai-writes-all-the-code/ **Language:** en **Published:** 2026-09-05 **Tags:** AI, code review, automation, GitHub, process, TypeScript **Category:** AI --- For twelve weeks I worked for a client not so much on the code as on the process around it. The client — someone with no programming background — described the changes, and Claude Code wrote them. My job was to automate everything else: planning, review, tests and deployment, so that whatever came out of the model could safely reach production. **Not a single line of code was written by hand in that time**, and every pull request arrived with a description of the change, an automated review and tests along the way. A human stepped in where the process itself marked something as a critical decision. The model writing the code is not the interesting part — anyone can do that today. What is interesting is how much of the work around the code can be taken off a person's hands without anything falling apart at that pace. The project is commercial and under an NDA, so I name neither the client nor the product. ## Who actually wrote this code **There was no hand-written code at all.** In this arrangement the human had three jobs: describe what should change, approve the plan before any code existed, and settle the places where the process itself signalled that a decision was critical. The agent handled the rest. That third job should not fall to the person describing the changes. When the process marks something as critical — permissions, money, another company's data — the call has to be made by somebody who can read a diff and predict what happens after deployment. In practice that means an experienced developer. Automation takes the routine off a person, not the responsibility. ## Conversation first, code second A change starts here with a procedure that interviews you: one question at a time, with a proposed answer and a way out for "no, differently". The model asks about things the brief never mentioned — what should happen in the edge case, whether this applies to old data too, how we will know it is done. Only out of that conversation does a plan come, and only an approved plan goes to implementation. Every such conversation leaves a file behind, so after three months the repository holds a complete set of descriptions: what, why, and how we will know it is finished. This stage looks like the most redundant one in the whole process, and it is the opposite. A model given a one-sentence instruction guesses the rest, and it guesses very convincingly. After twenty questions there is nothing left to guess. I apply the same rule in my own projects — on [ZapiszPrzepis](https://spoko.space/blog/zapiszprzepis-ai-first-app/) a plan before the code cut the search feature from a week to three days. ## What review looks like Code written by a model has to be read, and at several changes a day nobody will do that by hand with the attention it deserves. That part was taken over by [Cezar](https://github.com/open-mercato/cezar) — a tool that wires agents into the task lifecycle on GitHub, with a custom set of procedures plugged into it. ![A queue of pull requests waiting for automated review — seven changes ready to be checked](https://spoko.space/_spoko/cezar-inbox.Cadqkiay.webp) A pull request shows up on GitHub and gets a label, which starts the workflow: **What happens once a pull request is opened** 1. **Reading the change** — The agent reads the diff, the linked task and the change plan, if one exists. 2. **Filling in the record** — If somebody skipped the planning stage, the agent reconstructs the description from what was actually built. 3. **Review across six dimensions** — Match with the plan, scope, security, architecture, consistency with existing patterns, acceptance criteria. 4. **Verdict and comment** — Approved, changes requested or rejected — with a list of findings, each carrying a file and a line number. 5. **Label on the list** — The state of a change is visible by colour on the pull request list, without opening it. The agent is banned from touching code. The only thing it may write is the record of the change, never a fix in the sources. ![A pull request list with state labels applied automatically after review](https://spoko.space/_spoko/cezar-pr-lista.DpNdm1EQ.webp) Day to day, the label next to the title is the entire interface: green means the agent has no objections, orange means there are findings to read. ## What this agent catches A single review opens with a verdict and a table scoring the change across six dimensions: ![A review verdict: a table scoring six dimensions — from match with the plan to acceptance criteria](https://spoko.space/_spoko/cezar-review-werdykt.DFOiFVEd.webp) Below it come numbered findings, each with a severity, a file, a line number and a proposed fix: ![Three findings from one review — each with a severity, a location in the code and a ready fix](https://spoko.space/_spoko/cezar-review-znaleziska.CPN8q011.webp) Close to half of those findings are not about code quality — they are about whether the change does what it said it would, whether the acceptance criteria were met, and whether something arrived that nobody ordered. A linter will not check that, because it does not know the plan, and a human at five in the afternoon is looking at the diff, not at what they set out to do. ### One specific case instead of adjectives On one pull request the agent reported that one write path checked permissions at the organisation level but skipped access to the specific company. The interface did not expose this, because the selection list was already filtered. A user could still send a crafted form and attach a resource belonging to another company. The agent gave the file and line number, pointed at the identical operation in a neighbouring file where the check was done correctly, and wrote which function to add. Types will not catch this, because both paths are type-correct, and nobody had written a test for it. ## More findings is not better This is the trap that automated review makes easy to fall into. On another project I used CodeRabbit and got long lists of findings, most of which turned out to be false. Going through them cost more time than reading the code, and after two weeks I started scrolling past them. Formally the tool was working; in practice it had stopped contributing anything. Here the problem ran the other way: suspiciously few critical findings came out. The code was reviewed by the model that wrote it, and it is hard to catch an assumption you made yourself. Both extremes end the same way — the human stops reading. A review is worth exactly as much as its accuracy, not as many items as its list has. Hence the conclusion I take into the next projects: split writing and reviewing between models from different vendors, and check which one catches the things you actually react to. ## Pace Half the pull requests closed within **an hour**. The changes were small, so review was short; review was automated, so it did not wait for anyone's free evening. Nothing piled up, so nothing swelled. Two rounds of findings were usually enough, though some changes came back a dozen times. ## One address the agent looks at The project started on a public bundle of procedures for Claude Code, but plans went into one directory, specifications into another, progress reports into a third. A person copes with that, because they remember where they put things. An agent remembers nothing between sessions. It gets only what it can find, and the whole mechanism described above rests on that: review compares a change against its plan, so a plan sitting at an unexpected address is, to the agent, the same as a plan that does not exist. ## Where this does not work **Planning was deliberately dropped.** Over time it was judged to take too long, and some changes went straight to implementation. The procedure can reconstruct the description after the fact, so the record has no holes — but a description written after implementation answers the question "what did we do", while the value of this stage lies in the question "what should we do", asked earlier. **The build gate rarely fires.** The agent is supposed to build the branch and check types, but it usually has no environment at hand. CI remains the hard gate, and the agent adds what CI cannot check. How I plug AI into tests themselves is in the [guide to E2E testing with Playwright](https://spoko.space/blog/e2e-tests-ai-playwright-guide/). ## What your project gets out of this - **Every change is described before it exists and checked against that description once it does.** Nothing reaches production without a trace of why it went in. - **Acceptance criteria are not ticked off on trust.** If something quietly fell off the list, review surfaces it before deployment. - **AI has no write access where the risk is real.** Fixes land as a draft to approve, never as an automatic merge. - **The process stays with you.** The procedures are ordinary files in your repository, which you can read and change. - **One person responsible for the whole thing** — from setting the scope, through deployment, to support after launch. ## Summary - **A model can write all of the code**, as long as a conversation and a plan come before implementation and automated review comes after. Generating the code is the easy part here. - **Close to half the review findings are about matching the plan and the acceptance criteria**, not about code quality. No tool that does not know what was agreed will check that. - **Automated review shortens the cycle, because it does not wait for a free evening.** Half the changes closed within an hour. - **The number of findings is a bad metric.** A list too long with false alarms and a list too short on real findings end the same way: the human stops reading. - **Use models from different vendors for writing and for reviewing.** The same model rarely sees its own faulty assumptions. - **Decisions marked critical are approved by an experienced developer.** The process points at the place, but somebody who can read a diff has to judge the consequences. ## Where Cezar came from From [10xDevs](https://10xdevs.pl/) — a course run by Przemek Smyrdek and Marcin Czarkowski of [Przeprogramowani](https://przeprogramowani.pl/). The tool was shown at a [guest session](https://przeprogramowani.substack.com/p/wez-te-3-rzeczy-pod-uwage-zanim-zaczniesz) by Piotr Karwatka, the founder of Divante, now working on Open Mercato. The tool itself has changed a great deal since then. The process described above, however, does not depend on any particular button in an interface: the procedures are files in the repository, and the gate is a label on a pull request. ## Frequently Asked Questions ### Does AI write the code in your projects? Yes, and in the project described here the model wrote all of it. A human approved the plan before implementation and settled the decisions the process flagged as critical. This only works because there is a process around code generation: a conversation and a plan before implementation, automated review after it. ### Does automated review replace a human? No. It replaces the first pass — the one that checks whether a change does what it said it would, whether the acceptance criteria were met, and whether anything came along that nobody ordered. A human decides on deployment — for changes marked critical that should be an experienced developer — and agent fixes arrive as a draft, never as an automatic merge. ### Does a process like this slow the work down? It speeds it up. In this project half the pull requests closed within an hour: changes are small, so review is short, and review is automated, so it does not wait for somebody to have a free evening. ### What does an agent like this actually catch? Close to half the findings are not about code quality at all — they are about matching the plan, meeting the acceptance criteria and staying inside scope. The rest is security, consistency with existing patterns and architecture. A classic linter has no interest in the first group, because it does not know what was agreed. ### Does this process stay in my project? Yes. The procedures sit in the repository as ordinary files, the workflow runs on GitHub, and the record of every change lives in the code. You can carry on with it with me or without me. ### Is the model that wrote the code good enough to review it? It works, but it is the weakest variant: a model rarely catches its own faulty assumptions, so the list of findings comes out shorter than it should be. The opposite failure matters just as much — a tool that produces long lists of false alarms also stops working, because people start scrolling past them. What counts is how often a finding is right, not how many there are. ### What in this process still does not work? The build gate in review fires rarely, because the agent usually has no environment in which to build the branch — the hard check stays with CI. This only surfaced after counting the repository history and is being fixed. ### Does this only work on large projects? The payoff grows with the number of changes, but the threshold is low. It starts to make sense the moment you can no longer remember what you agreed three weeks ago — which happens sooner than most people assume. ## Sources - [Cezar — an agent orchestrator for the task lifecycle](https://github.com/open-mercato/cezar) — A tool that wires agents into issues and pull requests on GitHub - [10xDevs](https://10xdevs.pl/) — The course where I came across Cezar - [10xDevs 3.0 guest session](https://przeprogramowani.substack.com/p/wez-te-3-rzeczy-pod-uwage-zanim-zaczniesz) — A webinar with four guests, Piotr Karwatka among them - [Claude Code — skills documentation](https://docs.claude.com/en/docs/claude-code/skills)