Congratulations on the ten-minute launch. I would like to meet the person who owns month seven.
Not the person in the demo. The person who gets the message saying a customer has changed their name, the old report still shows the old name, and nobody knows which version of the record the export used. The person who discovers that a seemingly harmless shortcut has become a promise other parts of the system depend on.
That person rarely appears in the victory screenshot.
On October 8, Brais Moure criticized two bad extremes in AI development: mechanical copying and uncontrolled production at greater speed. I would add a third, which is treating the speed of the first version as the entire cost of ownership.
The invoice arrives in ordinary language
Imagine a fictional little scheduling tool. An assistant builds it quickly. The screens look plausible, the happy path works and the team is understandably delighted. Then somebody asks to correct an appointment after a notification has been sent. A second person asks what happens if two people edit the same booking. A third wants to know which information remains after deletion.
Those are not exotic edge cases invented by a gloomy maintainer. They are ordinary questions a useful service eventually attracts. The first version may handle them beautifully. It may not. The launch video cannot tell us unless somebody actually asked.
Here is my maintenance question: can the owner explain the important behavior without asking the assistant to invent an explanation after the fact?
That does not require a person to memorize every line. It requires them to know where to look, what the system is supposed to preserve and how to tell whether a change has broken a promise. A project can become too complex for one person's complete memory. It should not become too mysterious for the team responsible for it.
Daniel Stenberg's account of human control in curl is useful precisely because it avoids the simplistic argument that AI assistance must be rejected. He describes humans owning changes while tools, including AI, help identify problems. Responsibility survives the tool.
I like that formulation. It leaves room for the useful part of automation without outsourcing the consequences to a machine that does not attend the support meeting.
A smaller patch can be a faster product
The throughput scoreboard encourages a peculiar kind of theater. A large change looks like more progress than a small one. A new abstraction looks like more engineering than removing an unnecessary step. A thousand generated lines look industrious even if the actual requirement could have been met with a much smaller decision.
Fuck that scoreboard when it starts charging the next maintainer for your presentation.
I want a change whose owner can describe the trigger, the resulting behavior and the reason for the shape of the solution. I want the checking effort to match the consequence. I want the important unanswered question to remain visible instead of being buried under a cheerful claim that the tests are green.
This is not a demand to turn every tiny personal experiment into an enterprise process. A disposable prototype can be disposable. The trouble begins when a prototype quietly acquires users, data and obligations while everyone continues describing it as the thing we made in ten minutes.
Useful speed includes the time saved by not making a future colleague reverse-engineer your intention. It includes leaving a clear note, choosing a smaller change and admitting that the demo did not test the hard part.
Launch quickly if the situation supports it. Enjoy the first working version. Then name the owner of the next ten months. If the answer is still the agent, I think you have named a tool and misplaced a responsibility.
A thought worth keeping?
