A builder plans what to build and writes it as a spec, builds it in dialogue with AI, runs it, and integrates the whole. 1-03 said that the work of both the coder and the software engineer comes to be done by AI. Beyond that lies a broader role: planning for yourself, then building and running systems in dialogue with AI. This series calls that role the builder. This chapter fixes the definition, and fixes where the builder differs from the software engineer.
A builder's work is a loop of four steps
A builder's work is made of four steps.
- Plan — from the customer, the field, and the builder's own context, draft what to build. Write it as a spec the AI can read, down to how to split it, what to use and what not to, where it goes, and how much to hold yourself. Making the draft and writing the spec are both the builder's work.
- Build with AI — hand AI the intent, the constraints, and the context. AI writes the code and proposes the design. One instruction is not the end of it. The exchange goes back and forth.
- Check — see whether what comes back runs. See whether it fits the design. See whether it breaks in the context it was meant for.
- Integrate and run — fold the part into the whole, keep it consistent, and run it. Running means putting it into the business and getting results. What a company builds has to raise revenue or cut cost, or there was no point building it. What comes out of running it is the material for the next plan. Then return to "plan" and revise the spec.
These four are not a one-way line. They are a loop. One turn takes minutes to hours, depending on scope. A builder runs the loop tens of times a day. Time spent writing code is the smallest part of it, because AI does the writing.
What you write in the first step, "plan," is the first spec you hand to an AI from 1-02. The other three steps are the procedure for turning that spec, and every turn comes back to the spec and revises it. That is what it means for the unit of maintenance to move to the spec (1-02). So the quality of the loop is set in the first step.
field context"] subgraph Builder["Builder's work (the loop of building with AI)"] direction TB D["Plan
(what, how to split it,
written as a spec)"] Hand["Build with AI
(pass intent, constraints, context)"] Eval["Check
(does it run? does it fit?)"] Int["Integrate and run
(into the business, for results)"] D --> Hand --> Eval --> Int --> D end AI(("AI
code, design")) Out["Software running
and producing results"] Ctx -->|this is where the material for the plan comes from| D Hand <-->|intent goes out, code and design proposals come back| AI Int -->|released only with the whole kept consistent| Out Out -.->|revenue and cost results feed the next plan| Ctx classDef good fill:#e8f5e9,stroke:#7a9a6d,color:#3a4d34 classDef bad fill:#fef3e7,stroke:#c89559,color:#5a3f1a class Builder good class AI bad
The builder holds the whole loop. The builder also carries the direction and the responsibility. AI writes the code and proposes the design. But what to build, what to reconcile with reality, and how to run it stay on the builder's side. So does the result of running it — whether revenue went up, or cost went down.
The closest existing job to this role is the film director. A director does not operate the camera. A director does not touch the editing software. A director does not sew costumes. Even so, the director decides what to make, how to show it, where to cut, and in what order to assemble. The director also keeps the whole consistent. The crew gives it form in dialogue with the director. The relationship between the builder and AI maps onto this. Direction and the whole stay with the builder. The code and the design get built through dialogue with AI. What comes out is born of the collaboration. 3-09 returns to this pairing under the heading "app-making comes to resemble film-making."
The software engineer and the builder handle different problems
A software engineer (SE) and a builder look alike. But they are structurally different roles. The dividing line is a single one. The SE solves a narrowly closed problem; the builder handles an open problem.
- A narrowly closed problem — what to build is already defined, and the conditions for a correct answer are clear. "Implement this spec under these constraints" is such a problem. Design and implementation both finish inside the problem. The clearer the rules and the more checkable the answer, the stronger AI is (1-01). So the SE's work comes to be done by AI.
- An open problem — what should be built is not settled in the first place. Reality contradicts itself. The stakeholders' interests split. The constraints move. The right answer sits outside the problem, on the side of reality. Reconciling that with reality and translating it into narrowly closed problems is the builder's work.
What decides the outcome is not the difficulty of the problem. It is whether the problem is closed or open. A narrowly closed problem, however advanced, AI solves. The world's hardest coding problems (1-01) were such a case. Difficulty is not an obstacle. But an open problem changes the terms, because the right answer does not sit inside the problem, and it carries the question of right for whom. AI learns from accumulated precedent. A reality without precedent gives it no material to learn from, and neither does a situation no one has solved yet. So the open problem stays with humans.
Why can a human do it? For two reasons.
- A human has a stake — a human lives inside that reality and takes the trouble and the relief in their own body. So they can decide what to put first.
- A human can carry responsibility — a human is a subject who bears the result of a decision. Under present institutions, only a human can be the address of responsibility.
Those two are why a human can judge what matters. The right answer to an open problem rises out of that judgment: the answer to what should be built, and to what matters for the reality at hand.
Accumulation counts here too. History as a living thing, history as humanity, and a whole life since birth — carved into the body, the culture, and the memory, it gives judgment something to stand on. But what decides it is not the age of that footing. It is standing, right now, in a reality where you carry the stake and bear the result.
Judgment stays with the human
What AI has is only the weights it obtained from training. They are parameters that statistically compress a vast amount of past data. They are nothing more and nothing less. There is no lived history in them. There is no stake in living either. What is worth living for is not in the weights.
So judgment cannot be left to AI. Narrowly closed problems can be left to it. There, AI is faster and more accurate. But what to build, what matters, and what to take responsibility for are judgments about an open problem. These stay with the human. That is the core of the builder's role.
The weights obtained from training can be changed easily, by the developer. What a model is taught, and how it is made to behave, sit within the discretion of whoever trained it. So a model must not be trusted unconditionally. Choosing whose model to use is itself a builder's judgment. Use a model from a developer you can trust.
The typical software engineer is a big-tech employee. Such an engineer owns one specific slice of a giant system, deeply. One feature of search, one service of payments, one layer of an API. The problem is narrow and well defined. That is exactly where AI is strongest. That work is the first to be done by AI.
And at the frontier it is already happening. Anthropic has stated that more than 80 percent of the code it merged into production in May 2026 was written by Claude (VentureBeat). Claude builds Claude. The question to ask here is not whether people are still needed, but what people do. Design and code move to AI; people move to planning and running. What happened at the frontier company is not that the people went away, but that the code people write nearly did.
Output is set by the quality of judgment and the number of loop turns
| Axis | Software engineer | Builder |
|---|---|---|
| Problem handled | Narrowly closed (defined) | Open (reality, context) |
| Center of the work | Designing and writing code | Planning, and writing the spec |
| Context | Given as a spec | Carved out of reality by oneself |
| Center of the skill | Design, implementation, technical fluency | Decomposition, evaluation, integration |
| Headcount per project | A team | One person plus AI |
| Throughput | Proportional to design-and-build speed | Decision quality × loop turns |
The last two rows are the heart of this chapter. An SE's output is set by "headcount × design-and-build speed." Adding people makes it faster. There were limits, but adding people did work. A builder's output is set by "decision quality × loop turns." Adding people does not make it faster, because a chain of judgments cannot be split across heads. Once AI takes on the narrowly closed problem, which is the design and the code, the second equation dominates. That does not mean people are not needed. What sets the headcount is the number of plans being turned. Only the era of counting people by the volume of code is over.
The SE solves a narrowly closed problem. There, AI is strong. The builder handles an open problem. The builder reconciles with reality, plans what to build, and writes the spec. So this is the human's work.
The content of the skills differs as well. What a builder sharpens is the following.
- Reading context — grasping, from the customer, the field, and reality, what matters
- Articulation — turning tacit intent into explicit words that can be handed to AI
- Evaluation — seeing whether what comes back fits reality and meets the purpose
- Integration judgment — seeing whether a part breaks the consistency or the aim of the whole
- Selection and responsibility — picking "this one" out of what comes back, and owning that judgment
None of this comes from language grammar or framework fluency. You do not have to be able to read code. Anyone who can read reality and judge what matters can become a builder. As 1-03 showed, that includes people working in the field.
A builder's foundation is liberal arts, not software engineering
At the center of a builder's work sit reading context, articulation, evaluation, integration judgment, selection, and responsibility. Experience writing code can serve as footing, but it is not the center. What sits at the center is what has been called the liberal arts.
Two senses of that phrase are worth separating. The medieval seven liberal arts are the trivium (grammar, rhetoric, logic) and the quadrivium (arithmetic, geometry, music, astronomy). The modern liberal arts name a broader education spanning the humanities, the social sciences, and the natural sciences. A builder's abilities straddle both.
| What a builder needs | The seven arts (medieval) | The modern liberal arts |
|---|---|---|
| Articulation (tacit intent into explicit words) | Grammar, rhetoric | Linguistics, composition |
| Decomposing the problem (into a handleable form) | Logic (dialectic) | Logic, analysis |
| Integration judgment (seeing the whole stay consistent) | Geometry, music (ratio and construction) | Systems thinking |
| Reading context (from customer, field, reality) | — | History, social science, political philosophy |
| Evaluation (whether it fits reality and the purpose) | — | Aesthetics, ethics |
| Selection (picking "this one" from the options) | — | Ethics, theory of judgment |
| Value and responsibility (what matters; judgment is not handed over) | — | Ethics |
The first three sit squarely in the seven arts. The last four sit outside them and grew up on the modern side. The three inside the seven are how to handle words and structure; the four outside are the judgment of what to aim them at. A builder needs both.
What AI took over is the core of software engineering. Algorithms, language specifications, frameworks, design patterns, how to write tests. The work that remains looks like nothing but liberal-arts ability, and that is a structural necessity.
The history lines up as well. The seven liberal arts were defined as the arts a free person should learn. A free person meant one who was not enslaved. Set against them were the artes mechanicae, the arts of those who work with their hands. The builder is the person who does not hand judgment over to AI. That is, the builder is the contemporary form of the free person's arts.
A builder's foundation is not software engineering. It is the free person's arts of the AI era, the liberal arts.
Summary
A builder runs four steps: plan, build with AI, check, integrate. The narrowly closed problems the SE used to solve are taken over by AI. What the builder handles is the open problem of raising what to build out of reality and turning it into a spec. The foundation for that is liberal arts, not software engineering.
Paired with AI, a builder can carry a large scope alone. This is not only an internal-staff story. By the same logic, the customer can be the builder directly.
The next chapter takes up the era in which customers themselves pair with AI and develop. If AI does the SIer's work, the customer does not need to go through an SIer, and can pair with AI and build directly. The customer who used to commission the work moves to the building side. We trace that shift.