A manifesto for software engineering with AI

Tagged: ai, ai engineering, software engineering, accessibility

This text was written by a machine.

So was almost everything I have published since June 2025, when the first code I did not type landed in a repository belonging to a company I worked for, about two months after I had started studying how to make that happen properly. I decide what is said, what stays and what goes live. The machine produces the sentences. That division of labour is the subject of this page, and the page is its own first exhibit.

It is written for me first, because a commitment that is not written down is a mood. Then for anyone who reads my code or my text: anything I produce with a machine will carry a line pointing here, so that the terms it was made under are one link away. Then for anyone who works with me, who is entitled to know in advance how I will behave when the tool changes under us again, as it will.

  1. What is live is mine, whatever wrote it
  2. The rest of the process has to move at the speed of code, or the speed was wasted
  3. The work happens before the code, and the prototype is the agreement
  4. Refactoring is cheap now, so governance and QA grow rather than shrink
  5. I will not refuse a tool to protect a skill I am proud of
  6. My opinion of whether the technology should exist is not my job. Applying engineering to it is
  7. A first failure is a research assignment, not a verdict
  8. I will not claim what I have not measured, for or against
  9. I will automate everything that is safe to automate
  10. I will adapt the codebase to its best producer, whatever that takes
  11. I will stay able to judge what the machine produces
  12. Code is a means, and I judge it by whether it works, not by whether it is mine
  13. The machine does not lower the bar on who can use the result

1. What is live is mine, whatever wrote it

The machine wrote it. I answer for it. On my site, in my code, in my work as an individual contributor, there is no “the agent did it” available to me, and I do not want one. If it is live, I put it there, and I have read it. Responsibility for text I have not read is a slogan, so reading what goes live is not a preference. It is the mechanism.1

In a supervising role the shape changes and the size does not. I no longer answer for every line, but I answer for whether the people who do have the means and the awareness to answer for theirs. Responsibility does not shrink when the role changes. It only changes what I am responsible for.2

2. The rest of the process has to move at the speed of code, or the speed was wasted

For decades every other part of building software was arranged around one fact: writing code was slow. Planning, specification, review, sign-off, release, all of it accommodated that speed and hid behind it. The fact has changed, and a process that keeps its old shape produces a new thing: long windows in which nothing happens, on either side of a step that now takes an afternoon. The whole cycle stays as long as it ever was. Either the rest of the process is rethought as well, or the speed was wasted.3

3. The work happens before the code, and the prototype is the agreement

With a machine as the bridge between what we need and what gets built, the expensive mistake is no longer a bug. It is four thousand lines of correct code for the wrong thing. So I will train, monitor and adjust the people around the work, product owners, project managers, QA, so that we prototype, experiment and agree before the code exists rather than after it. A working prototype now costs about what a drawing did. The prototype is the agreement.4

4. Refactoring is cheap now, so governance and QA grow rather than shrink

Even so, we will get it wrong sometimes, and when we do we will refactor, because refactoring is now cheap and doable in a way it never was. But cheap refactoring is only safe when something can prove that the result still does what the last version did. That is what governance and QA are: not a brake on change but the guarantee that makes fast change survivable. They have to grow in proportion to what the machine lets us change. Where code got faster, they got more important, not less.3

5. I will not refuse a tool to protect a skill I am proud of

Something I did by hand yesterday does not have to be done by me today, and the fact that I was good at it is not an argument. Refusing to try a tool because it competes with a skill I am proud of puts the company I work for, and the people I work with, at risk on behalf of my past. I will not do that. When a thing I used to do no longer needs me, I let it go and go looking for the thing that does.5

6. My opinion of whether the technology should exist is not my job. Applying engineering to it is

Every previous shift had professionals whose whole answer was that it should not exist. Scribes against the press. Painters against the camera. The silent film against sound. Assembly programmers against the compiler. Their opinion did not survive the shift, but it did cost them the years they spent holding it.6

I refuse that seat. I am not hired to hold a position on whether a tool should exist. I am hired to apply engineering to it: to analyse it, tune it, and use whatever in it separates the work I do from where things stand. That is what software has always been for, if you think about it. When a more efficient thing exists, my role stops being to compete with it and starts being to make it work properly, because the people who do that are otherwise the people I will be competing with.

7. A first failure is a research assignment, not a verdict

I will not try a promising technology once, fail, and present my own failure as evidence that it obviously does not work. A first failure says almost nothing about the tool and something about how I used it. What it earns is more research: reading, another attempt, a different setup, a measurement. “I tried it and it did not work” is a status report, not a conclusion.7

8. I will not claim what I have not measured, for or against

The enthusiast’s claim and the sceptic’s are the same kind of thing: an opinion standing where a number should be. Every claim I make about what the machine does for me comes with what I counted, where, and how, or it does not get made.1 The sixth commitment refuses the naysayer’s opinion. This one refuses mine.2

9. I will automate everything that is safe to automate

Programming a computer is exactly this: taking a task a person was doing and arranging for a machine to do it instead. I promised to do that when I chose the trade, and I will not stop because writing the code is now one of the tasks.

Safe means I am prepared to answer for it under the first commitment, with the jobs filled that make an answer possible. It is not a matter of size. What it excludes is short: operations that cannot be reversed, secrets, production access, and other people’s data. None of those the machine touches without a person in the loop who has read what it is about to do.4

10. I will adapt the codebase to its best producer, whatever that takes

The machine is now the most productive writer of code I have access to, and it works better under some conditions than others. So I will change whatever has to change for it to produce more, cheaper and more reliably: architecture, documentation, the environment it runs in, the tooling around it, the shape of a task. That is not a concession. It is what an engineer does for whichever part of the system produces the most.8

I am not doing this for my own comfort. A company that does not adapt to its most productive producer will be beaten by one that did, and I am working so that the companies I work for are the ones still standing.

11. I will stay able to judge what the machine produces

Handing over the doing is the point. Handing over the understanding along with it is how the first commitment turns into a signature on something I cannot read. So I keep the knowledge that lets me review: enough of the language, the system and the domain to know when the output is wrong, and to know it before it is live. The reviewer’s job is the one I keep for myself, and staying able to do it is part of the job.2

12. Code is a means, and I judge it by whether it works, not by whether it is mine

A variable named well but not what I would have called it. A function split where I would not have split it. A structure I would have arranged another way. None of that makes code bad, and I will not mark it as bad on those grounds. Code is judged by whether it does the job, whether it is safe to change, and whether the next person can read it. It is not judged by whether it matches my taste. Code works for me, not the other way round.

This was true when I reviewed code written by people, and it stays true reviewing code written by a machine. The review I keep for myself under the previous commitment asks whether the code is right. It does not ask whether it is mine.29

13. The machine does not lower the bar on who can use the result

I am blind. Part of what looks at a screen on my behalf is now a machine, and the tooling I have adapted for it is the reason I can do this work at all.10 The other side of that is a rule: speed of production buys no exemption. An interface a machine generated is audited like one a person wrote, and the environment I build around the machine has to remain usable by me, or it has failed at its first job. Being dynamic, which everything above says we now can be, includes not leaving people behind at the new speed.

What this is not

It is not a claim that the technology is finished. It fails, in ways I have written about at length, and the record of where it failed is in the footnotes.

It is not a claim that it needs less of an engineer. The series this page draws on argues the opposite: an agent removes the one job that was never the hard job, and leaves one person holding every job that was. These commitments are what the more consists of.

And it is not advice. It is a description of how I work, written down so that it can be checked against what I actually do.

Versions

  • 10 September 2026. First published.

Footnotes

  1. You are now the whole team is the long form of this page. Every claim in it is measured against two repositories built this way, and the conversations with the agent are quoted from both sides, because my prompts on their own would prove nothing. An hour a day is where the numbers are: where the hours went, how much had to be done twice, and what a machine that had never seen any of it could build in nine minutes.

  2. Six things that got through is the record of what every mechanism in the series missed anyway, kept because the proof that a job is being done is the artifact, not the absence of failure. One of the six is a rule I was proudest of, whose hole an agent found and was entirely right about. Being right mattered more than it being mine.

  3. Nothing I can publish yet. What I have measured about process and governance so far is inside a team whose code is not mine to show. This is the footnote most likely to grow.

  4. The night that produced no code: five hundred and forty lines of documentation, six files, and not one line of code before the first commit. Conditions, not instructions: what I actually typed on that first night, and why almost none of it was an instruction.

  5. At long last, only an engineer is the argument that something else laying the bricks does not make you less of an engineer. It makes you only an engineer, which is what you were meant to be.

  6. From sources that can be checked, because the famous prediction quotes mostly cannot be. Plato, Phaedrus: Socrates argues that writing will produce forgetfulness in those who learn it, and the appearance of wisdom rather than the thing itself. Johannes Trithemius, De laude scriptorum, written in 1492: a monk should keep copying by hand, because the printed book is the lesser object; he had it printed in Mainz in 1494, so that it would reach more readers. Charlie Chaplin, 1929: talkies “are ruining the great beauty of silence”; City Lights, released silent in 1931, was made to prove it, is a masterpiece, and changed nothing about what happened to silent film. And FORTRAN, 1957: John Backus’s own account of the project records the widespread belief among programmers that a compiler could not produce code efficient enough to use, and that his team spent most of its effort on the optimiser to prove otherwise. That one is our own profession, reacting to our own tool, with the same argument about quality.

  7. The gap between what you said and what you meant: extrapolation is the whole reason to use an agent and the whole risk of using one, because they are the same mechanism. So the question is never how to stop it, and a first attempt that went wrong is usually a place where it was wide when it should have been narrow.

  8. I stopped building the product to build the tool: twenty-six days spent on the environment instead of the product, and the four questions that separate that from procrastination.

  9. Salvatore Sanfilippo, the author of Redis, in Control the ideas, not the code, July 2026, on reviewing code an agent wrote for Redis: he finds things he does not like how they are coded, but other Redis files written by other contributors have “far worse, and not since they are not good coders, but because it is a matter of taste.” He goes further than I do: he thinks reading the code at all is now mostly pointless, and that the review time should go to design and QA. I keep the reading, under the first commitment. I agree with him about the taste.

  10. The terminal I could not build and The server is everywhere, a bridge is somewhere: what it sounds like when a terminal is navigable by heading, and the architecture that lets one server serve any screen reader.

Comments