Everything Breaks

What Moving from Prototype to Implementation Actually Requires

Let me tell you what implementation feels like.

Everything breaks. Everything you thought you had right goes wrong. If it could go wrong, it will go wrong. Wrong, wrong-wrong, and more wrong.

The prototype worked. You tested it. You showed it to people. It did the thing, and you felt the particular satisfaction of having built something that functions, the moment the gap closes between what you imagined and what exists. Then you tried to make it real, for real users, under conditions you did not design for, and the thing handed you back every assumption you made while building it.

I have had this happen with a script I was proud of. It ran for months on my machine, doing exactly what I built it to do. The first time someone else ran it, it failed in under ten seconds, on a detail so small I had never once thought about it.

For those of us who are building objects for people but weren’t trained formally to do that building (i.e. you’re the person on your team who got excited about AI, de facto became the person everyone asks for help, and now suddenly are “in charge” of AI development without any background on paper that would give you the “expertise” to be leading such an initiative), it is really hard not to get discouraged byt he movement from “Brilliant!” to “Everything is wrong all the time!” It feels like failure. So let me state this baldly: this is not a failure. It is implementation. It is what happens when a system designed under controlled conditions meets the uncontrolled world. Every prototype is a hypothesis. Implementation is the test. Saying that doesn’t necessarily hlep with the feelings of inadequacy and failure that well up in us nonetheless.

I recently wrote The Builder’s Progression as a way of thinking about getting a better perspective on the terrain. Understanding where we stand in our capacities and techniques in relationship to what generative AI might do for us. This essay is about a boundary running sideways across every one of those stages. Call it the Works-For-Me Line.

Most people are not prepared for how different the test feels from the hypothesis, and the unpreparedness is structural rather than personal.

That structure is worth naming, because I have spent the past two years inside it. Turning something that works into something other people can depend on used to be a profession. It came with training, a title, a career path, and colleagues down the hall who had already solved the problem you were stuck on. That work has been redistributed without anyone announcing it. It now lands on whoever in the office was curious enough to try the thing first, which in most higher education and nonprofit settings means one person, with no budget line and nobody to ask.

I include myself in that. I was trained to read theology. Nothing in that preparation has anything to say about deployment, or error handling, or what to do when a tool I built fails in someone else’s hands on a Tuesday morning while I am sitting in a meeting. I have been working the terms out as I go, mostly by getting things wrong first and paying attention afterward. So this is written as much for me as for anyone reading it. The reason to publish rather than keep it is that nearly everyone I talk to is having some version of the same experience, and almost nobody has been handed the words for it.

---

The Firstborn Question

Before the documentation, the UX testing, the error handling, the deployment, there is one question that determines whether you get through implementation.

Are you willing to give your firstborn child for this project?

I used to tell students who were thinking about applying to doctoral programs in theology something similar. Are you ready to have to try and compete with all your friends for a very few number of tenure-track jobs that will require you to sacrifice your sense of ego and importance so that you can be underpaid for the level of expertise that you have? Couldn’t you ve happier doing anything else? Every time someone asks me about how they can take their great and useful prompt, bot, webapp, small piece of software, whatever... and turn it into something their friends and neighbors will benefit from, I get flashbacks to these moments with students. What will you be willing to sacrifice to do this.

So we will casll this the “Firstborn Question” (thanks Abraham). And we need to recognized that, yes, it is hyperbolic.; and, it is also not quite hyperbolic enough. Implementation requires a category of commitment that prototyping does not. The prototype can be abandoned; you can learn from it, set it aside, start something else. Once real users depend on it, once a client has paid for it, once you have told people it exists and works, it has to keep working. Every failure becomes someone else’s problem. Every gap in your design becomes a gap in someone’s day.

Fred Brooks put a number on that weight in 1975. He opened The Mythical Man-Month by refusing to call a working program a product, and laid out a ladder instead. At the bottom sits a program that runs for its author. Above it sits a programming product: the same idea generalized, tested, documented, and maintainable by strangers. Above that sits a programming system, integrated with other components across defined interfaces. At the top sits a programming systems product, which is both at once.

Each rung, Brooks estimated, costs roughly three times the one beneath it. A programming systems product therefore runs about nine times the cost of the program already working on your machine. The thing you have when the prototype runs is one unit. The thing you are proposing to build is nine by Brooks anecdotal estimation. That’s a lot of emotional difference.

The Firstborn Question stops being melodrama at that point and becomes arithmetic. It asks whether you have nine units of anything (time, money, attention, plain stubbornness) standing behind something that already looks finished at one. Most people answer with the enthusiasm they felt at one unit, which is the wrong measurement taken at the wrong moment.

The honest answer tells you whether you are ready. A paying client who needs the thing will keep you in the room when everything is broken and the debugging is tedious and the elegant prototype feels like it happened to someone else. An obsession that will not leave you alone does the same work by a different route. Without one of the two, you do not have nine units, and no amount of starting excitement will manufacture them.

Let me say this plainly, because the alternative usually gets treated as defeat. If the prototype is interesting but not urgent, if you could live without finishing it, stay at the prototype. It has value. The question was never whether you can implement. It is whether you have the driver that carries you through the part where everything breaks.

Brooks’s bottom rung is a place to live, not a waiting room, and that matters most for the people least likely to believe it. Most of the people building things with generative AI right now in higher education and the nonprofit sector are not developers and never planned to be. You are a director of annual giving who got tired of writing the same acknowledgment letter four hundred times a year. You are an assistant registrar with a script that reconciles two exports nobody ever built an integration for. You are a program officer with a prompt that turns messy site-visit notes into a usable first draft. The thing you built gives you back six hours a week. It has an audience of one, and one was the right number.

The pressure to widen that audience arrives fast, and it usually arrives from a generous place. Someone sees your screen, says this is amazing, asks whether everyone can have it, and the question sounds like recognition. What it proposes is that you take on nine units of work for a tool currently returning one, inside an institution that will not give you release time, will not fund a support line, and will still want the annual report on the same date. Your tool does not have to become your department’s tool. It does not need a login page, a training doc, or a name. The six hours a week stay real either way, and building something excellent that only you will ever run is a complete outcome with nothing missing from it.

---

What Actually Breaks

It helps to know what is coming, and to be relieved in advance of the assumption that breakage is a verdict on you.

Richard Cook studied failure in systems where failure kills people, and in 1998 he compiled eighteen propositions about how complex systems behave. Complex systems, he observed, run in degraded mode continuously: the working system always carries faults, and it keeps working because the faults have not yet lined up. Catastrophe requires several failures at once, which is why single-cause explanations offered afterward are almost always wrong. Read that against your prototype and the diagnosis changes. It was not sturdy on Tuesday and fragile on Wednesday; it carried the same faults both days, and what changed was the exercise. Charles Perrow had named the class of system where this becomes inevitable in Normal Accidents (1984): interactive complexity plus tight coupling makes the accident a property of the design rather than a lapse in judgment.

Underneath that picture, three specific things go wrong.

Edge cases. Your prototype handled the inputs you gave it. Real users will hand it inputs you never imagined: empty fields, unexpected formats, content in languages you did not test for, combinations of choices that should not coexist and do. The reason you missed them has a structure worth naming. Your test inputs came from the same mind that wrote the system’s assumptions, which means they were selected, unconsciously, to be inputs those assumptions could handle. You cannot falsify your own blind spots with materials you produced from inside them.

Load. The prototype worked for you, run a few times, one request at a time. Real usage means many people at once and infrastructure you never had to think about because you never had to. Michael Nygard drew the line in Release It!, published in 2007: there is a difference between software that is feature-complete and software that is production-ready, and most software is designed to pass QA rather than to survive production. The failures that matter arrive at integration points, the seams where your thing meets something you do not control. A script that reads one local folder correctly meets a shared drive, an API rate limit, and forty simultaneous users, and the logic you wrote is not what gives way.

Distance. The third never announces itself as a breakage, which is why it goes unnoticed longest and costs the most.

---

The Works-For-Me Line

Every prototype works for someone: its builder. Crossing the Works-For-Me Line means the system now has to work for a person who does not know what you know, cannot ask you, and will not be watching over your shoulder while you demonstrate the correct way to use it.

Don Norman mapped this distance in 1988, in The Design of Everyday Things. He described three things that are easy to collapse into one. There is the designer’s conceptual model, how the builder understands the system. There is the user’s conceptual model, how the person in front of it understands the system. And there is the system image: the thing actually built, including its interface, its behavior, its error messages, and whatever documentation ships alongside it.

The finding matters for anyone crossing the line. A designer never transmits their model to a user; the channel does not exist. What gets transmitted is the system image, and the user constructs their own model out of that alone. When the two models diverge, two gulfs open. The gulf of execution is the distance between what the user wants to do and what the system will let them express. The gulf of evaluation is the distance between what the system reports back and what the user can conclude from it. Both are properties of the artifact rather than deficiencies in the person operating it.

Run the standard complaints through that frame and they stop being complaints. They will use it wrong. They will expect it to do things it does not do. They will be confused by outputs that seem obvious to you. They will give up at exactly the moment you would have known to try something else. Every item is a design fact with an address in the system image, which means every item is something you can go and fix.

I found my own version watching a colleague run a script I had built for my content pipeline. It expected a particular nested folder structure to already exist. I had built that structure so long ago it had stopped being a decision and become furniture. She ran the script into an empty directory, it failed instantly, and the error message described the symptom in terms only I could interpret. Two of Norman’s gulfs in about eight seconds, from a tool I would have called finished.

Capability and audience are different measurements, and this is why. The assistant registrar whose script reconciles two exports is finished, and owes nobody an apology for it, however plain the script looks to someone who writes software for a living. A builder with far more technical range, whose prototype has real architecture and error handling and a test suite underneath it, can still sit entirely on the near side of the line. Nobody crosses the Works-For-Me Line by getting better at building. You cross it by changing who the system is for, which makes the decision in front of you a question about people. Who else, specifically, and what will you owe them once they depend on it?

---

The Intimacy Gap

Something genuinely new is happening between builders and their code, and it deserves to be named honestly rather than defensively.

The traditional developer knew every stone. They wrote every line. They understood the architecture from the inside: not only what the system did but why it did it that way, what the alternatives had been, what would break if you changed a given piece. That knowledge made them good at anticipating where users would struggle, because they could trace the paths to friction without leaving their chair.

The agentic builder works differently. Generating substantial portions of a codebase rather than typing it produces a different relationship to the result. You know what you asked for. You may not know precisely what you got. You can read it, more or less, and reading is not the operation that produces a feel for a system. Peter Naur made the underlying point in 1985: the theory of a program lives in the person who built it rather than in the text they produced. That theory is what the agentic builder never acquired, and the hole it leaves sits exactly where UX intuition used to live. Call it the Intimacy Gap.

There is now evidence that this kind of self-knowledge fails in measurable ways. In July 2025, METR ran a randomized controlled trial on experienced open-source developers. Sixteen developers took on 246 real tasks in mature repositories they already knew well, each task randomly assigned to an AI-allowed or AI-disallowed condition. The setup matters: real work by people on their own familiar ground rather than benchmark puzzles handed to strangers.

The developers were 19% slower when they used the AI. Before starting, they had forecast a 24% speedup. Afterward, having just been slowed down, they estimated they had been about 20% faster.

The slowdown is the headline and the least interesting of the three numbers. The one that should concern anyone building this way is the last: experienced builders were wrong about their own building, confidently, in the flattering direction, on ground they knew intimately. Speed is among the easiest things to be right about, since anyone with a clock can check it. If self-assessment fails there, the intuition telling you where a user will get stuck is not a faculty you should treat as evidence. Which means agentic builders need more deliberate documentation and testing than traditional developers did, precisely because the tooling made the building faster. The intimacy has to be replaced by structure that lives outside your head.

This is also one of the legitimate sources of discomfort experienced developers feel about agentic building, and it deserves something better than dismissal. The objection usually gets heard as nostalgia, or as defense of a threatened skill set. Underneath it sits a more precise observation: a particular kind of knowing is being bypassed, that knowing had uses well beyond producing the code, and those uses are hardest to see from the position of someone who never had it. Those developers are describing something real, and the useful response is to build the replacement rather than to argue them out of the objection.

---

Documentation Written at the Moment of Decision

Two structures do most of the work of standing in for that intimacy. The first is documentation, and the word misleads enough to need qualifying immediately.

Not retrospective documentation. Documentation written in the moment, as each decision gets made, as each piece takes shape. What does this step do? What does it need? What does it produce? What happens when it fails? Four questions, answered while the answers are still obvious, which is the only window in which they are obvious. This is harder than it sounds, because the momentum of building pulls against it. Stopping to write feels like stepping off the treadmill at the exact moment it finally got up to speed.

David Parnas and Paul Clements addressed the difficulty in 1986, in a paper whose title gives away its argument: “A Rational Design Process: How and Why to Fake It.” They began by conceding what every working engineer knew and no document admitted: real design does not proceed by orderly derivation from requirements, but by false starts, half-understood problems, decisions made on incomplete information, and mistakes discovered late and repaired sideways. The tidy documents produced afterward describe a process that never happened.

Their response was the interesting part. Rather than abandoning the rational record as a fiction, they argued for producing it deliberately: write the documentation the ideal process would have produced, and write it continuously, as the work happens. The reasoning behind that instruction carries the weight. The artifact is permanently self-evident, since the code will still be sitting there next year saying exactly what it does. The reasoning is not. It exists only in the head of the person holding it, decays on a schedule nobody controls, and cannot be reconstructed from the artifact afterward at any price.

That is what makes retrospective documentation nearly worthless. It describes what a system does, which the code already told you. Documentation written at the moment of decision records why the system does that instead of the three other things you were weighing at four o’clock on a Thursday, which is the only question you will actually have at eleven at night three months later. Michael Nygard turned this into a format in 2011 with the architecture decision record: context, decision, consequences, one short file per decision, written when the decision is made. The format stays small because the realistic alternative to a small format is nothing at all.

For agentic builders the stakes rise. Documentation is the bridge across the Intimacy Gap: how you assemble a working model of a system you did not assemble line by line, and how you keep that model current as the system changes underneath you. Without it you depend on the AI to re-explain your own system to you every time something goes wrong, which works, slowly, and not always, and rarely at the hour you need it most.

---

The Not-You Test

The second structure costs far less than anyone expects. The Not-You Test needs one person who has no idea how the system works, one task for them to complete, and your silence. Run it as early as possible, and more often than feels reasonable.

The economics were settled in 1993, when Jakob Nielsen and Thomas Landauer published a mathematical model of how usability problems accumulate across testers, built from observed detection rates in real studies rather than from intuition. The curve they produced bends early and hard. A single tester surfaces roughly a third of a system’s usability problems; five surface about 85%. Past that, additions get expensive relative to what they return, because the sixth tester spends most of the session rediscovering what testers two and four already found. Nielsen built his 2000 essay on this finding, telling designers to stop at five.

The implication for a solo builder is the part usually missed. People skip usability testing because it sounds like a budget line: a lab, a recruiter, a two-way mirror, a report nobody reads. Five people and an afternoon is not a budget line. And because the curve flattens, three rounds of five beats one round of fifteen, since you fix the problems between rounds and each later round tests a different system.

Steve Krug supplied the discipline for the room itself, in Don’t Make Me Think and the do-it-yourself protocol in Rocket Surgery Made Easy. Give the task. Then stop talking. Watch them use it without helping them. The instinct to say “oh, you should have clicked” will be the strongest instinct you have in that room, and every time you obey it you rescue one user and destroy the finding you brought them in to produce.

This is uncomfortable. It is supposed to be uncomfortable. The discomfort is information, and it is worth being precise about what the information says: you are watching your own model of the system fail in someone else’s hands. That event is the thing you invited five people over to produce. Sitting through it without intervening is the entire skill.

---

What Implementation Actually Is

There is a version of the Builder’s Progression that treats implementation as the destination, the proof that the prototype was real. I want to offer a different frame.

Implementation is where a different kind of work begins. The prototype was about building something that functions. Implementation is about building something that sustains: something that handles what you did not design for, serves people who do not know what you know, and keeps working while you are not watching.

Hannah Arendt drew the distinction that fits this best, in The Human Condition, published in 1958, though she was not writing about software. Arendt separated work from labor. Work is fabrication: it has a definite beginning and end, and it produces a durable object that outlasts the making of it, the table or the house you can point at afterward and call finished. Labor is cyclical and never finished. It sustains what already exists, it has to be done again tomorrow, and the evidence that it was done well is that nothing fell apart.

The prototype is work in Arendt’s sense. It concludes, the conclusion is the reward, and the reward arrives as a moment you can locate in time. Implementation sits closer to labor. It does not conclude. Its satisfaction is that something continues to exist, a real satisfaction with a fundamentally different shape. Nobody throws a party because the system stayed up.

That asymmetry gets mistaken for a personal failing more often than it gets recognized as an inheritance. In 2016, Andrew Russell and Lee Vinsel published an essay in Aeon called “Hail the Maintainers,” arguing that a culture fixated on innovation has almost nothing to say about maintenance, though maintenance is where the overwhelming majority of the work and the value actually sit. The people keeping existing systems running vastly outnumber the people inventing new ones and receive a fraction of the attention. If implementation feels less glamorous to you than prototyping did, you inherited that feeling, along with the vocabulary that made prototyping sound like the interesting part.

Both satisfactions are real, and they require different things from you. The prototype requires vision, fluency, and permission to break things inside the safety of your own testing environment. Implementation requires the willingness to give your firstborn child, or something close enough: the driver that keeps you in the room when everything is broken, the discipline of writing things down while they are still obvious, the humility to watch someone struggle with what you built and treat the struggle as data rather than as an attack on the design.

Not everyone needs to make that crossing, and the exit ramp deserves a sign rather than a footnote. The development director whose acknowledgment letters now draft themselves has already won. Nothing about that win is provisional, nothing further is owed, and six hours a week returned to one person every week is a result most institutional software projects never manage.

But if you are going to cross, if the driver is there and the commitment is real, go in knowing what is coming.

Everything breaks. You fix it. You write down what you fixed and why. You put it in front of someone who is not you. You fix what they find. You keep going.

That is implementation. It is harder than the prototype and more durable than the prototype and, eventually, more satisfying than the prototype.

Just not at first.