I still read compiler output.
When I write high-performance GPU code and the numbers don't make sense, I look at the PTX. Sometimes I go lower and read the SASS. I look for register spills, unexpected memory traffic, instructions the compiler failed to fuse, synchronization I didn't ask for, or some perfectly legal decision that happens to be ruinous for the machine in front of me.
Sometimes I change the source until the compiler produces the instruction sequence I wanted. Sometimes I use intrinsics. Occasionally I write the low-level implementation myself because the compiler either can't express what the hardware needs or can't be persuaded to stop doing something stupid.
This isn't an archaeological hobby. It's part of the job. NVIDIA ships tools specifically for extracting PTX, disassembling GPU binaries, inspecting control flow, and examining register use because eventually the abstraction leaks and somebody has to look at what the hardware will actually execute. (NVIDIA Docs)
Compilers didn't make assembly knowledge worthless. They changed its frequency and its economics. Most of the time, reading the emitted instructions doesn't pay: the compiler is good enough, the code is ordinary enough, and the surrounding toolchain provides enough confidence that the lower layer can remain somebody else's problem. Then a kernel is thirty percent slower than it should be, a compiler optimization does something surprising, or the hardware counters tell a story the source can't explain. At that point, the ability to descend through the abstraction becomes disproportionately valuable.
AI-generated code is headed toward the same economic position, with one enormous caveat: AI is a much worse compiler.
I don't think programmers will stop reading or writing code. I think reading every line emitted by a fleet of agents will become economically impossible, while retaining the ability to understand any particular line will remain essential.
We will not read every line. We must remain capable of reading any line.
For programmers of a certain temperament (and I count myself firmly among them) that distinction is both reassuring and deeply uncomfortable. I've spent most of my career believing that code should be more than correct: the thought should be visible inside it, the names honest, the abstractions snug, the complexity worked and reworked until the implementation feels less invented than discovered.
I have spent unreasonable amounts of time replacing functioning code with code I considered beautiful. I do not regret any of it.
Parts 1 and 2 described the codebase and development environment required to make machine-scale implementation viable. This part is about what those systems do to the people who built their identity around the implementation itself.
This is not the artisan's eulogy. It is the artisan's new job description.
When beauty was load-bearing
The artisan tradition is as old as programming, but it didn't begin as an aesthetic preference. It began because the machines were unforgiving. When memory cost a dollar a byte, compression wasn't optional.
The canonical text is Ed Nather's The Story of Mel, about Mel Kaye programming drum-memory computers at Royal McBee. A drum didn't provide uniform access to memory: data rotated physically beneath a read head, so the location of an instruction on the drum affected how long the machine waited before it could execute the next one. Mel arranged his program around the rotation of the hardware, timing software against the movement of metal. His code was hostile to future readers, full of tricks no modern team would accept in review, and magnificent in the very particular way that code can be magnificent when there is nowhere for inefficiency to hide. (Jargon File)
Mel's program wasn't beautiful because it was readable. It was beautiful because it fit the machine with terrifying precision.
And the sensibility Mel represents ran through the whole early industry. Woz fit the Apple II's floppy controller into a handful of chips by replacing an entire board's worth of hardware with cleverness. The demoscene put worlds into four kilobytes. Knuth titled his life's work The Art of Computer Programming and meant the noun literally. Memory, cycles, storage, and instruction bandwidth were expensive and visible, so elegance wasn't polish applied after the program worked. Elegance was often the reason the program could work at all.
Beauty was load-bearing.
Then the bottleneck moved. Hardware became cheaper and more forgiving (Moore's law functioned as a subsidy for sloppiness, renewed every eighteen months), programs grew beyond the comprehension of any one person, and teams became too large for private cleverness to survive contact with an organization. The scarce resource stopped being memory or instruction cycles and became human understanding.
Modern software craftsmanship grew out of that constraint. Meaningful names, small interfaces, locality, modularity, tests, refactoring, explicit control flow: all the practices built around the observation that code is read more often than it is written allowed one engineer to inherit a system another engineer had built. Mel optimized for a drum rotating beneath a read head. We optimized for the person opening the file eighteen months later while an incident channel filled with increasingly nervous executives.
Both traditions called their result beautiful, but they meant different things. Mel's beauty was mechanical economy. Ours was human inheritance.
AI moves the bottleneck again.
Implementation becomes abundant. A model can generate a module, rewrite it, translate it into a language the operator barely knows, produce six alternatives, and throw all of them away before lunch. What remains scarce is judgment: knowing what the system should mean, which constraints matter, whether the parts compose, and when a plausible implementation is lying to you.
Software aesthetics have always followed the bottleneck. The question is where beauty goes when implementation is no longer the scarce part.
The old schism
Long before AI, programmers had divided themselves into two tribes that have never had particularly good names. Call them the artisans and the factory workers (pejoratives intended).
The disagreement was never simply between careful engineers and careless ones. It was a disagreement about where software quality lives.
The artisan believes quality exists partly inside the implementation. Simplicity, locality, honest names, coherent structure, and elegance are not decorations placed on top of correct behavior. They preserve intent, reduce the number of states a system can enter, and prevent the software from becoming impossible to govern. The system behaves well because somebody cared deeply about how it was made.
The factory worker locates quality primarily in the behavior of the finished system. Does it solve the customer's problem? Is it secure enough, reliable enough, and fast enough? Did it ship before the company ran out of money? Customers don't pay extra because an internal interface brought tears to a staff engineer's eyes.
Both positions contain obvious truth, which has never prevented either side from treating the other as an existential threat.
The artisans saw companies drowning in expedient code, adding people to compensate for complexity they had created themselves, and discovering every hidden assumption during an incident. The factory workers saw engineers spend a week polishing a helper function that would be deleted after the next product meeting.
Richard Gabriel gave the economically dominant tendency a name with "worse is better." His argument wasn't simply that bad software wins. It was that a minimal system with a simple implementation can spread before a more complete system is finished, then improve after distribution has already made it the default. The MIT approach lost to the New Jersey approach, over and over, in every market that mattered. Gabriel himself spent years arguing both sides of his own idea, but its survival logic is difficult to deny. (Dreamsongs)
The factory workers won the volume war decades ago. The world needed payroll systems, dashboards, integrations, mobile apps, websites, and seventeen million slightly different ways to approve an expense report. Most of that software was never going to be handcrafted like a database kernel.
The artisans retained the code review, the style guide, and the moral high ground. Also, apparently, the obligation to produce endless books, conference talks, blog posts, and YouTube shorts explaining why the webshits had ruined everything (it is worth noticing that a movement only writes that many manifestos when it is losing).
Then AI strapped a rocket to the factory.
A person who once needed a team can now ask a model to build an application. They may not understand the data model, the authorization system, the concurrency semantics, or why the generated deployment manifest grants the application permission to communicate with half the internet. They judge the result from the outside: it launches, the button works, the demo is convincing, and every individual file looks plausible if you don't stare at it for too long.
This is how you get an N1 with a web frontend.
Thirty individually impressive engines, each apparently functioning, integrated into a machine whose parts do not share one coherent idea of what the machine is. The database migration assumes one model of identity. The API assumes another. The frontend invents a third. The authorization layer politely accommodates all of them. Every subsystem passes its local tests, and the vehicle discovers the interactions during ascent.
The artisans are right to recoil from this. Internal coherence matters. Taste matters. Architecture matters. A system can be assembled from locally competent code and still be globally stupid.
But the artisans are wrong if they believe this will restore the old economics of hand-authored implementation. Organizations are not going to return voluntarily to typing every part once one experienced engineer can direct the output of a team. The productivity difference is too large, and the factory workers were always correct about one thing: for most businesses, code is a means rather than the product.
The future is not the artisan losing while the factory worker wins unchanged. Both are forced to move. The artisan gives up custody of every implementation. The factory worker accepts that throughput without architecture, contracts, integration discipline, and experienced judgment produces failure faster than it produces software.
AI wins the argument about authorship. It does not win the argument about engineering.
The patron saint of code review shrugs
Linus Torvalds recently made the compiler comparison more provocatively than most people would dare.
At the 2026 Open Source Summit North America, he objected to people boasting that almost all their code had been written by AI. Under the same accounting, he argued, compilers already write all the code the machine executes. The fact that a tool performs more of the transformation does not make the tool the responsible engineer. (The New Stack, keynote video)
That's a useful argument precisely because it comes from Linus, a man who has spent decades treating code review as a full-contact sport. And behind the provocation is a stance he has held for years, which amounts to: I don't much care who or what wrote the code, so long as it does its job, isn't stupid about its environment, and doesn't break anything around it.
Read those criteria again, because they're more interesting than the shrug they come wrapped in. Does its job: a correctness claim, and testable. Isn't stupid or naive: a design floor, and reviewable. Doesn't break anything around it: a containment property, and enforceable with boundaries. The indifference is not the absence of standards. It is the reduction of standards to the ones that can be checked, which happens to be exactly the world Parts 1 and 2 describe. Keep the properties that oracles and contracts can verify, and let go of everything that required a human connoisseur reading the code with a loupe.
His position is not that implementation no longer matters or that developers may remain ignorant of what they ship. The Linux kernel's formal policy draws the opposite boundary: AI-assisted contributions are allowed, but an AI agent cannot legally sign the Developer Certificate of Origin. A human must review the generated work, certify its provenance and licensing, and take full responsibility for the contribution. (Linux Kernel Documentation)
Authorship becomes less interesting. Accountability does not.
Whether a line was typed by a person, emitted by a schema generator, translated by a compiler, or proposed by a model matters for provenance and licensing. It matters less as an aesthetic test of legitimacy. The questions that survive are harder: Does the system do what it's supposed to do? Is the implementation naive about the environment in which it runs? Has it widened authority or weakened a boundary? Can somebody diagnose it when it fails? Does an engineer understand it well enough to own the consequences?
That last question is the one the factory workers are most tempted to skip, and the one the artisans cannot be permitted to turn into a demand that every line be lovingly inspected by hand.
Responsibility does not require universal authorship. It requires sufficient understanding to know when the evidence is weak, when the abstraction is leaking, and when somebody has to descend into the machinery.
The worst compiler ever built
At this point the artisan has a perfectly reasonable objection.
A compiler is deterministic translation software built around a formal language, defined semantics, conformance tests, reproducible toolchains, decades of research, and an entire professional class devoted to making it better. An LLM hallucinates, forgets constraints, changes its answer, flatters the operator, and occasionally tries to persuade you that the bug it just introduced is an undocumented feature. No gcc release has ever invented a function that doesn't exist and called it with confidence. If LLVM behaved the way a model does, we wouldn't call it a compiler. We would call it a supply-chain attack with excellent prose.
Correct.
Calm down. It is a metaphor.
A conventional compiler accepts a formal program and emits a lower-level representation while attempting to preserve semantics the programmer has already specified. An AI coding system accepts an incomplete, ambiguous, and frequently contradictory expression of intent, then proposes both the semantics and the implementation at once. Those are not equivalent operations.
But they are beginning to occupy a similar economic position. The human increasingly works at a higher level of intent. A machine emits a lower-level implementation. Most of that output passes through the surrounding toolchain without requiring a person to inspect every line. Specialists descend when the behavior, performance, or evidence no longer makes sense.
The compiler metaphor describes a position in the stack, not an equivalence of behavior.
Conventional compilers aren't infallible either. They miscompile programs. They generate code that is correct but surprisingly poor for a particular architecture. Optimizer transformations that look obvious can become incorrect under obscure combinations of overflow, poison values, aliasing, floating-point flags, or memory behavior.
The response was not to inspect every emitted instruction forever; that would have destroyed the economic value of compilation. Instead, the industry built a formidable apparatus around compilers: language specifications, regression suites, reproducible toolchains, profilers, disassemblers, fuzzers, translation validators, formal proofs for sensitive transformations, and specialists who know when and how to inspect the lower layer. LLVM's own contribution guidance requires regression coverage for miscompilations and Alive2 proofs for proposed optimizer transformations because even mature compiler infrastructure cannot substitute confidence for evidence. (LLVM)
We still employ compiler engineers. We still improve compilers every day. We still write intrinsics and assembly when the abstraction fails. NVIDIA still ships cuobjdump and nvdisasm because somebody occasionally needs to see the actual instruction stream, control-flow graph, register use, and relationship between source and emitted machine code. (NVIDIA Docs)
The mature relationship with compilers was never blind trust. It was selective distrust supported by excellent tooling.
FORTRAN succeeded because John Backus's team understood that a high-level language would be rejected unless the generated code could compete with code written close to the machine. IBM's history records that the first optimizing FORTRAN compiler produced numerical code that ran nearly as fast as carefully handcrafted implementations, overcoming the conviction that automatic translation could never match an expert programmer. (IBM) For years afterward, serious programmers read the emitted assembly to check the compiler's work, the way we now read AI diffs. Then, gradually, they stopped. Not because the output became beautiful, but because the discipline around the compiler made reading unnecessary outside unusual circumstances. Today, suggesting that a colleague inspect the assembler output of their code would be understood as a performance emergency, an edge case, or a hazing ritual.
AI-written software needs its own version of that maturation. Not because an LLM will become identical to a compiler, but because reading every implementation it emits is no longer a viable way to establish confidence.
Part 1 builds fragments of the semantics this terrible compiler lacks: types, schemas, contracts, state machines, capabilities, and database constraints. Part 2 builds the environment in which it can miscompile safely: containment, recoverable mutation, candidate history, comparison, integration pressure, and selective human intervention.
The model alone is not the compiler. The entire development system is. The model generates code. The repository supplies context. The contracts narrow legal meaning. The tests and production evidence provide partial judgment. The workspace contains failure. The candidate history records what was tried. The human remains responsible for deciding whether the original intent was coherent and whether the result deserves to become real.
A real compiler does not flatter you while miscompiling your loop. Ours does. We should build accordingly.
Source code stops being the whole source
People increasingly describe English (or whichever natural language they think in) as the new programming language. I'm sure Karpathy said it more eloquently years ago.
There's something directionally true in the phrase. A person describes a system at a higher level, and a machine emits an implementation. The person no longer needs to remember every library function or type every statement by hand.
Taken literally, however, it is dangerous nonsense.
Natural language is the least precise input in the entire system. "Let users share this project with their team" sounds complete until someone has to define user, team, guest, removal, inheritance, expiration, billing, past-data visibility, and administrative override.
The prompt supplies direction. It does not supply semantics.
The actual source is compound. It includes the issue, the conversation, the existing repository, the type system, the database schema, the RPC definitions, the state machines, the examples, the tests, the security policies, the production traces, the failed candidates, and every durable decision the project has accumulated. The prose says what we want. The rest constrains what those words are allowed to mean.
This is why Part 1's hard contracts are not merely defensive programming. They form part of the grammar and partial semantics of this emerging higher-level language. They turn an ambiguous request into a smaller space of legal implementations. And Part 2's engine shop is not merely agent orchestration. It is the execution environment for this bizarre compiler: where candidate translations are produced, isolated, compared, repaired, combined, pressure-tested, and rejected.
Better prompting is useful, but it can't carry this burden alone. Trying to make generated software reliable through increasingly eloquent prompts is like trying to improve a programming language by teaching everybody to write more persuasive comments.
The prompt is not the program. The whole system is the program.
Follow the metaphor one step further and the generated implementation becomes the object file: a build artifact, regenerated whenever the source above it changes. And nobody, in the entire history of computing, has ever mourned the beauty of an object file (nobody sane, at least).
That is not fully true today, and the reason is worth being precise about. Most codebases don't preserve enough intent above the implementation. Critical decisions live only in the code, in a developer's head, in an abandoned Slack conversation, or in the shape of tests whose purpose nobody remembers. An artifact is disposable only when it can be replaced without losing knowledge. If deleting the implementation deletes the design, then the implementation is not disposable yet.
Once intent, constraints, evidence, and history survive elsewhere, the generated source becomes a lowered representation of a larger program. It remains inspectable. It remains debuggable. It may need to be patched or rewritten by hand. Performance-critical, security-critical, and foundational code may remain carefully authored for a very long time. But implementation is no longer the only durable expression of the design.
Source code stops being the whole source. Most of the time, we work above it. Sometimes we descend. PTX is compiler output, and I still read it.
The mirror and the amplifier
AI can let me work in a language I don't know particularly well. It can find the right API, produce idiomatic glue, translate an algorithm into another ecosystem, or fill in the mechanical details I would otherwise have to learn by reading documentation for three days.
That is extremely useful. It is not the same as safely building a system I do not understand.
I may not know every Rust library call, but I still need to understand ownership, state, concurrency, failure, security boundaries, and the architecture I'm asking the model to implement. I can use AI to close a syntax gap. I can't safely use it to close a conceptual gap whose existence I don't recognize.
If I understand what a scheduler must guarantee, an agent can help me implement one in an unfamiliar language. If I don't understand scheduling, the agent can give my confusion excellent type names.
AI is a mirror and an amplifier. It reflects the operator's model of the problem and then produces that model at a scale the operator could never achieve alone.
Give it coherent intent, strong taste, and experienced judgment, and it multiplies those things. It explores more possibilities, performs more mechanical work, and converts one engineer's understanding into far more implementation capacity. Give it naive assumptions, weak standards, and no grasp of the system, and it multiplies those too.
If you are dumb as a box of rocks, AI does not turn you into a principal engineer. It gives your misunderstanding a fleet, a CI pipeline, and a polished README.
You still get a shit system. You just get it at scale.
This is why taste and experience become more valuable, not less. The scarce skill is increasingly recognizing the missing premise, the naive abstraction, the trust boundary nobody modeled, the performance number that cannot possibly be right, the locally sensible change that will poison the system, and the test suite that proves much less than everybody thinks it proves.
A model can generate an answer to almost any question. Experience tells you whether it was the right question.
In this world, my experience as a principal engineer and technical lead is becoming more useful than my experience as a developer who can personally type every implementation. I can direct more work than I can produce, but only because I have enough scar tissue to know where the work is likely to fail.
The uncs are going to be fine. Possibly better than fine.
The architect still goes underground
"Architect" is dangerous language in software because it can mean somebody who draws boxes, publishes standards, and has not opened the repository since the Obama administration.
That is not the role I mean.
The AI-native artisan is an architect in the older sense: the person responsible for the integrity of the whole machine who also understands how the machine is made. A principal engineer, compiler engineer, technical lead, and chief test engineer compressed into one increasingly caffeinated person.
Most of the time, that person works above the implementation. They define the concepts, contracts, state model, trust boundaries, performance envelope, failure semantics, integration plan, and quality bar. They decide which parts of the system may know about one another, which forms of authority may cross a boundary, and which candidate combinations deserve a full static fire.
Then a number looks wrong.
A latency distribution develops a tail nobody can explain. A generated GPU kernel spills registers. An authorization path passes every test but feels naive. A database query produces a plan no sane person would have predicted. A race appears only after a retry, timeout, and cancellation occur in one particular order. Three agents converge on the same abstraction because they inherited the same false premise from the repository. The architect goes back into the mine.
They read the implementation and the trace, open the query plan, look at the PTX and then the SASS, reproduce the interleaving. They write the low-level code the compiler would not produce, remove the abstraction every agent kept preserving, or discover that the contract itself made the correct implementation impossible.
This is not a failure of the new development model. It is how abstraction has always worked. The higher layer handles the ordinary cases and makes expertise at the lower layer disproportionately valuable when the abstraction leaks.
The difference is that implementation work becomes selective. An experienced engineer shouldn't spend the day polishing every generated adapter. They should descend when risk, economics, contradictory evidence, or anomalous behavior demands it.
Then the insight has to move back upward. A hand-written performance fix becomes a benchmark or compiler improvement. A security flaw becomes a stronger capability boundary. A race becomes a state-machine constraint or deterministic test. A confusing subsystem becomes a better contract so the next thousand implementations do not repeat the same mistake.
The artisan still writes code. They write it where writing code changes the system's understanding of itself.
Which standards survive
There is a lazy version of this argument in which generated code doesn't need to be good because nobody will read it.
That version is wrong.
Code quality still matters. Simplicity, locality, explicit control flow, bounded authority, stable names, reproducibility, and comprehensible failure behavior matter when a human has to debug an incident or audit a security path, and they also matter to agents. Models work better when the relevant context is local, concepts have stable names, interfaces are narrow, and behavior isn't hidden behind a magician's cabinet of reflection, macros, implicit conversion, and framework convention. The machine likes it boring. The style guide has a new audience, and the new audience is often confused by our cleverness.
AI does not make clean code irrelevant. It changes which parts of cleanliness deserve scarce human judgment.
There is a difference between a standard that encodes risk and one that encodes preference. A rule against ambient authority encodes risk. Explicit transaction boundaries encode risk. Limits on hidden state, dependency direction, unbounded resource behavior, and cleverness in security-critical paths encode risk. Whether a loop or a chain feels more expressive when both are equally clear and behave identically is preference. The exact ordering of helper functions is preference. Tabs versus spaces was always preference dressed in tribal paint.
Standards that encode risk remain sacred. Standards that encode preference become automation. Set the formatter and the linter, choose the house style once, and let the agent emit the boring adapter without spending human review cycles deciding whether its local variable names possess sufficient literary merit.
The artisan remains the arbiter of quality, standards, and taste. That role matters more now, because AI amplifies whatever the system tolerates. A repository with vague boundaries and inconsistent abstractions becomes a corpus for generating more of the same. A coherent repository gives the model patterns worth multiplying.
Some of what programmers call beautiful is authorial beauty: elegant compression, a clever mechanism, a solution whose wit another expert can appreciate. Some is structural beauty: a system with few legal states, narrow authority, explicit contracts, local reasoning, and parts that can be replaced without destabilizing their neighbors.
AI lowers the economic value of authorial beauty in ordinary application code. It raises the value of structural beauty everywhere.
The AI-native codebase may be less elegant line by line and more elegant in the shape of what it permits. It may be verbose where a human would be concise, repetitive where a human would introduce a clever abstraction, and ceremonial where a human would prefer flow. That is acceptable when the repetition is generated, the contract is clear, and the behavior is easier to judge.
It is not permission to ship slop. Slop is code whose cost has merely been transferred to whoever must understand, operate, or repair it later. The surrounding system has to ensure that generated volume does not become accumulated entropy. The code should be boring in the small and coherent in the large.
The judgment that used to go into a beautiful function now goes into a beautiful contract: the schema that makes invalid states unrepresentable, the state machine with no illegal transitions, the permission model exactly as wide as it needs to be, the interface that two independent agents cannot misinterpret in incompatible ways. Those artifacts are read by humans, carefully, indefinitely, because they are the durable layer where the meaning of the system lives. If there is a new bottleneck in this architecture, it is here: human review of contract changes is the scarce act everything else routes around. And that is the right bottleneck to have. Contracts change orders of magnitude less often than implementations, and judging them is the work that deserved a connoisseur all along.
Reference surfaces
Early machine-tool builders faced a problem that sounds impossible: how do you make a genuinely flat reference surface if you don't already own a flatter and more precise machine with which to make it? Comparing two plates is not enough; they can fit one another perfectly while one becomes concave and the other convex. The solution was the three-plate method. Three imperfect surfaces are compared in alternating pairs, a machinist marks their points of contact and scrapes away the high spots, and no single plate is accepted as the original truth. Precision emerges from repeated disagreement among all three surfaces. (Eric Weinhoffer)
That is almost suspiciously appropriate for software, because software has no single physics oracle waiting to tell us what is true.
The types disagree with the tests. The tests disagree with production traces. The implementation disagrees with the profiler. Two candidate stacks disagree about the contract. The model's explanation disagrees with the hardware counters.
Every surface is imperfect. Their disagreement tells us where to look. The artisan reads the marks. Sometimes the implementation has the high spot and needs to be scraped; sometimes the contract is wrong; sometimes the test encodes the same mistaken assumption as the code; and sometimes every generated candidate is wrong and the experienced engineer has to write the critical section by hand before they can teach the surrounding system what it should have done.
The reference surfaces of software are the durable bodies of intent and evidence from which implementations inherit their precision: contracts, schemas, tests, policies, examples, traces, and failure history. Someone still has to scrape them.
And there's a detail in the machine-shop tradition worth sitting with. The flattest surfaces in the world are still made by hand, because you cannot use a machine to make a surface more accurate than the machine itself. Every precision machine on earth is descended, through generations of tooling, from a reference surface somebody scraped manually. Mechanization did not eliminate that craft. It concentrated it, at the top of the accuracy chain, in the few places whose precision everything else inherits.
That is where the artisans end up. Not gone. Concentrated.
The problem of the name
I keep reaching for the phrase AI software factory, and every time I say it I wince.
It's trite consultant language. It sounds like something printed beneath an isometric illustration of a conveyor belt carrying glowing pull requests into a cloud.
Worse, it's wrong.
A factory is organized around repeatability. It suppresses variance and stamps known parts from a settled design. The system described across these essays deliberately creates variance: many hypotheses, many candidate implementations, liberal experimentation, severe selection, salvage, recombination, integrated pressure, and a scrap bin that does most of the quality control. It is not an assembly line.
The right image has been in front of us since Part 1.
It is the engine shop.
The agents produce engines. The shop fires them. Part 1 supplies the pressure vessel. Part 2 supplies the blast walls, black boxes, test cells, and machinery for preserving and recombining useful wreckage. Part 3 supplies the people who decide what holding pressure actually means. The artisans don't work the line in that shop, because there is no line. They design the test stands, define what "holds pressure" means, and keep custody of the reference surfaces every generated part is measured against.
The analogy remains imperfect because software never speaks for itself as honestly as metal under load. Contracts and tests reveal only what we have taught them to notice. A component can survive every test and still embody the wrong intent.
That is why the artisan remains. Not as the person hand-polishing every generated part, and not as a detached architect issuing commandments from a slide deck. The artisan becomes the custodian of meaning, quality, coherence, and the reference surfaces from which the rest of the system inherits its standards.
I labored for decades over code that was beautiful and functional at once, and I'm not going to pretend the loss is nothing. Some of the work we enjoy will disappear from ordinary commercial software development. There will be fewer economic reasons to spend an afternoon perfecting an implementation that an agent can generate, test, and replace in minutes. People who never learned to program in the traditional sense will build useful systems while understanding very little of the code inside them. Something real ends when the last generation that read programs for pleasure stops reading them.
That loss is real. Writing code is not clerical labor for those of us who love it. It is a way of thinking. Turning an idea into a precise mechanism changes the idea. The implementation pushes back and reveals the parts of the design we never understood.
But the constraints that made Mel's code beautiful are gone, the constraints that made clean code valuable are going, and the new constraints (ambiguity is expensive, judgment is scarce, meaning must be machine-checkable) reward a different beauty in a different place. The craft doesn't disappear. It concentrates.
We stop insisting that every implementation bear the visible hand of its author. We retain the ability to descend into any implementation when the evidence demands it. We move our attention toward the architecture, contracts, standards, test stands, and reference surfaces whose quality every generated system inherits.
In the old workshop, the artisan shaped the implementation. In the engine shop, the artisan shapes the space of possible implementations, and still knows how to climb down into the machinery when the assembled vehicle starts shaking in a way the models insist is perfectly normal.
The engine shop needs artisans. It just can't afford to have one polishing every bolt.
Keep the disassembler close.
Bring your scraper.