The last four articles leaned on people who did their thinking between 1972 and 2023. The choice is deliberate, because the classics sort the permanent from the temporary better than anything written last month can. But it leaves an obvious question open, and this article answers it: what are the practitioners closest to the work actually saying right now, and does any of it agree with the theory?
It does, which was not guaranteed. Five people, working from a personal weblog, a consultancy, a newsletter and an incident practice, have converged on the same finding without much coordination. The input mode changed. The discipline did not. And the part that got harder is the part nobody is selling you a tool for.
1. The naming argument is not about naming
In February 2025 Andrej Karpathy coined “vibe coding” for a way of working in which you give in to the vibes, let the model do whatever it does, and accept the result without reading it. The phrase escaped immediately, as good phrases do, and within months it was being used for everything from a weekend hack to a disciplined production workflow.
Simon Willison drew the line on 7 October 2025. Vibe coding, he wrote, is building software through dice rolls without caring what code is produced. What experienced engineers do when they use agents responsibly is a different activity, and he proposed calling it vibe engineering. Karpathy has since suggested “agentic engineering” instead. Addy Osmani backs that on practical grounds: the word “vibe” does not survive contact with an executive. Tell a CTO you are vibe engineering their payment system and watch the face.
The terminology will settle wherever it settles. What the argument is really about is where responsibility sits, and both proposed terms answer it the same way. In one mode nobody is answerable for the code, because nobody read it. In the other somebody is, and that somebody is a person.
2. Willison’s list is a job description, and the job is management
Willison names what vibe engineering requires, and the list is unglamorous: automated testing, planning, documentation, good version control, code review, a deep understanding of what is being built, and what he calls a very weird form of management.
Read that list again with the last three articles in mind. Nothing on it is new. Every item was standard practice in 2015, and most of it was standard in 1995. What has changed is that each item has stopped being a mark of professionalism and started being the mechanism by which work gets verified at all.
The management phrase is the one to sit with. Willison reports running several agents in parallel, finding it surprisingly effective and mentally exhausting, and that combination will be familiar to anyone who has ever run a team of four. You are not typing. You are specifying, delegating, waiting, checking, and deciding what to accept. Holding four contexts you did not personally build is tiring in a specific way. Management has always felt like that, which is why so many strong engineers find their first management job harder than expected.
3. Boeckeler builds the thing Fowler asked for
The last article ended on deterministic enforcement rather than probabilistic prompting. Birgitta Boeckeler has the concrete version, and it is the most useful idea in this article.
She is Thoughtworks’ global lead for AI-assisted software delivery, a role the firm created in July 2023, and she still writes production code, which shows in the specificity of what she says. Her framing is harness engineering. A harness has two halves. Guides tell the agent what to do, and in practice they are markdown files sitting in the repository. Sensors observe what the agent actually did, and in practice they are the tools you already own: static analysis, security scanners, tests, the pipeline. Guides are advice and can be ignored. Sensors are not, and that asymmetry is the whole design.
Her warning is that a harness is not a one-off build. It needs continuous maintenance, because the models underneath it keep changing and a guide tuned to last year’s model can quietly stop steering anything.
Then there is the observation that should worry any executive reading this. Only a small number of organisations, she says, treat AI-assisted delivery as anything more than the introduction of a tool that requires no change management. She is describing a transformation failure rather than an engineering one, which is the diagnosis this whole series has been making from the other direction.
4. Orosz reports the gap
Gergely Orosz is not proposing a theory, and that is his value. He runs the interviews and publishes the numbers, and the numbers keep saying the same uncomfortable thing: individual developers feel considerably faster while organisational delivery moves very little.
I keep returning to what that gap implies. Both halves are true. The engineer is not lying about the experience, and the measurement is not wrong about the outcome. Something between the keystroke and production is absorbing the gain. Everything here has been an attempt to name it: the queue, the coupling, the loops, the unreviewed change nobody can revert in halves.
5. Hochstein knows where it will show up
Lorin Hochstein writes about incidents from inside the resilience engineering tradition, and he has made two observations in the past six months that belong in every board pack on this subject.
The first, in February, is that the industry has produced a great deal of AI tooling for site reliability and almost nothing for incident management. The tools aim at resolving the incident faster. Almost none of them aim at the learning the incident makes available, which is the more valuable of the two and always was.
The second, in June, is sharper. He wrote that he dreads a future of incident reports written by models, and he was careful about why. Using a model to assemble the ingredients of a report saves real toil and he has no objection to it. Using one to write the report removes the act in which the organisation actually learns anything, because the understanding was never in the document. It was in the writing of it.
That is Ohno’s andon cord argument arriving from a different direction, and it generalises well beyond incidents. Any artefact whose value lies in the thinking it forces will lose that value the moment it can be produced without the thinking. The document survives. The learning does not.
6. What the convergence is worth
Five independent observers, no shared employer, no common method, and they agree. The tools changed what a keystroke costs. They did not change what a system costs, who is answerable for it, or what has to be true before you ship. The constraint moved from producing to verifying, and verification still ends with a person deciding to accept the result.
The practical version is short. Somebody must be answerable for every merged change. The guides go in the repository and the sensors go in the pipeline. And the artefacts whose worth is the thinking they force stay written by people, however tempting the alternative becomes.
The next article moves to the Interaction lever, and to why a team’s energy is not a resource an agent can supply.
Where this falls: Building, the third of the series' four phases, after Learning and Deciding and before Transforming. The Identity lever asks who or what is building and what it can actually promise, and directing an agent is that question in its most practical form. What an organisation gets out of that work is a working system and people who can still supervise it. The Build Is the Test opens this stretch of the argument.
(An Organisational Prompt is something you can do now....)
Organisational Prompt
Find out which of your controls are guides and which are sensors.
List every rule your organisation has issued about AI-assisted development in the last year. Coding standards, prompt guidance, the acceptable-use policy, whatever went out in the all-hands deck. You will probably find between five and fifteen.
Now sort each one into two piles. A guide is advice: it tells somebody what to do and depends on them choosing to do it. A sensor observes what actually happened and can stop the work: a failing check, a blocked merge, a scan that refuses. Be strict. If it can be ignored by a busy person on a Thursday, it is a guide.
Most organisations will find every item lands in the first pile. That is not a governance programme; it is a set of hopes, distributed at scale. Pick the two rules you would least like violated and ask what it would take to convert each into something the pipeline enforces.
Then ask who maintains them. A harness tuned to one generation of models stops steering when the models move, and they move faster than your policy review cycle.
Further Reading
Simon Willison: Vibe engineering (October 2025). Short, and the comment thread underneath it is a fair sample of how divided serious engineers still are. His weblog is the single best running record of what is actually working.
Birgitta Boeckeler keeps an index of her own talks and memos, which is the honest way to follow someone whose subject changes every quarter. The Exploring Generative AI memo series on Fowler’s site is where the field observation is written down.
Lorin Hochstein: Surfing Complexity. Start with the piece on LLM-written incident reports and then read backwards. He is the clearest current writer on what automation does to the shape of failure.
I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.