2026-08-16
Craft Must Become Machinery
Careful people can get excellent work from coding agents. That is useful, but it is not the finish line. If the quality lives in one person's habits, the factory loses it when that person leaves the keyboard.
The craft is real
Good agent-assisted coding does not look like making a wish and accepting whatever appears. It takes judgment. Someone chooses the shape of the problem, gives the agent the right context, notices when the plan is weak, and refuses output that merely looks finished. The work can move quickly, but the quality still comes from decisions made before, during, and after generation.
That is why the vibe-coding story is so misleading. It sells the visible moment when language becomes software and hides the experienced operator holding the whole process together. The operator knows which files matter, which convention cannot bend, which test is meaningful, and which plausible answer is dangerous. Remove that judgment and the same tool produces a different class of result.
Calling this a craft is fair. Treating craft as the operating model is not. A business cannot scale a production system that depends on a gifted person remembering how to steer every run.
Personal skill is a hidden dependency
Watch a strong operator work and you will see dozens of controls that the system does not own. They narrow the task before asking for code. They pull in a relevant example. They reject an overbroad change. They run a check the agent forgot. They recognize a familiar failure from three projects ago. Most of those decisions never become part of the machinery. They vanish into the next prompt or stay in the operator's head.
That creates a fragile kind of leverage. The agent is fast, but the line still waits for the person who knows how to load it. Another operator gets different results. A new hire repeats old mistakes. A correction helps one conversation and teaches nothing to the next run. The organization owns the subscription and the repository, but it does not own the process that made the output good.
This is the same failure software teams have tolerated for years: important operating knowledge stored in human availability. Agents make the dependency easier to see because generation accelerates until it reaches the judgment queue. Then the supposedly autonomous system stops and asks its craftsperson what to do.
Encode every move that repeats
The answer is not to remove experts. It is to make their repeatable moves executable. If an operator always supplies the same architectural rule, put it in maintained context that the factory retrieves for that class of task. If they always reject the same risky pattern, turn the rejection into a gate. If they always ask the same clarifying question, make that decision a required part of the specification.
A useful correction should change the next run. The factory should record what failed, route the defect to the stage that caused it, and strengthen the relevant context, boundary, or proof requirement. That is how judgment compounds. The lesson stops being advice one person may remember and becomes machinery every agent must pass.
Not every decision can be encoded, and it should not be. People still choose what deserves to exist, which tradeoffs the business will accept, and what consequences require a stop. But once a choice becomes stable and repeatable, continuing to perform it by hand is not craftsmanship. It is a manual build step the organization has declined to automate.
Proof is part of the craft
The most dangerous personal habit is private confidence. An experienced operator can read a change, run a few checks, and feel that the result is sound. They may be right. The factory still needs evidence that survives outside their judgment and outside the agent's chosen conditions.
Acceptance has to be defined before the builder optimizes for an easy demonstration. Tests must attack the real boundaries. Permissions must hold through routes nobody showed in the happy path. State changes must be read back independently. A release must leave enough evidence to explain what happened and send production failures to the part of the line that owns them.
That standard is stricter than careful prompting because it does not ask whether a skilled person can produce one good result. It asks whether the system can repeatedly earn authority to ship. The distinction matters as agents take on more work and fewer people remain in the loop. Trust cannot shrink to the confidence of the last human who looked.
Move the craft into the factory
Coding craft will not disappear when agents write most of the code. It will move. Less of it will live in the physical act of implementation. More of it will live in specifications, context systems, authority boundaries, evaluation, routing, and the feedback loops that make later work better than earlier work.
That move will eliminate jobs. Companies will not keep the same number of people manually applying rules that a governed factory can retain and enforce on every run. The people who remain will own the harder judgment: setting the destination, defining the standard, and deciding what the evidence means when reality disagrees with the plan.
Our position is that the best agent operators are building the knowledge that will replace the need for an operator at every step. Their value is not how artfully they can conduct one coding session. It is how much of that judgment they can leave behind as a system. Craft proves what good looks like. Machinery makes good repeatable.
In response to AI Coding Without the Vibes by Peterbloem.