It is eleven on a Tuesday morning at Road 12A in Dhanmondi, and I am on the fourth slab of a seven storey residential build with my clipboard taped at the top so the wind off the lake does not turn the pages on me. The architect's drawing pinned to the board says the slab will carry a twelve inch beam at the column line. The rebar schedule says 48 pieces of 16 millimetre at the bottom mat. The foreman, an unhurried Comilla man called Bashar bhai, is telling me his crew tied 36.
Twelve pieces of rebar do not care what the drawing says.
By the time we have walked the slab once with the plumb line, we will know which one the building intends to honour, and it will not be the drawing. It will be whatever the crew actually tied, which is the closest thing this site has to a brief.
I have spent the last decade writing PRDs from a desk near Mohakhali and watching them collide with the build out at Tongi, and the collision is the same one I am watching on the slab here. The PRD describes a system the team would be proud to have built, all clean state machines and tidy edge cases and the handling of unicode and emoji everybody nods at in the kickoff. The compiled artefact, by contrast, describes the system that actually exists, in a form so honest it refuses to start when the spec is wrong about it. A missing comma in an import statement does not care which Slack thread settled the auth question, and the TypeScript narrowing on the response payload does not care that the design team called it a "drawer" in Figma and "modal" in the PRD. The build only ships what is actually true, and on the morning a feature lands in production, the build is the only document anyone is reading.
The point is older than I am. Kent Beck has been arguing since his original test driven development book, and a thousand interviews after, that the test is the only piece of writing in a codebase that the compiler is forced to take seriously. Hillel Wayne, who writes a careful blog about formal methods, keeps returning to the same gap from the other end. Most production outages trace back to a model nobody on the team ever bothered to write down, not to a model that turned out wrong once real traffic hit it. The code went to staging carrying assumptions the PRD never articulated, and the build shipped exactly those.
load-calculation memo
ref LC-2026-04 · 11 May 2026
P R D
what the team wishes were true
C O M P I L E D B U I L D
what is actually true
initialled · site supervisor
S.E.There is a particular kind of PM I have learned to recognise, who treats the staging deploy as a finishing step instead of the first real read on the brief. She files the PRD in Confluence on Monday, watches engineering build through the week, and reads the deploy notes on Friday the way you read the weather, as ambient news that the day is done. The compile errors that flickered past in CI on Wednesday were live user research on her spec, as were the type errors the agent quietly fixed on Thursday morning without flagging. By Friday an engineer had deleted three tests because they had drifted from the new shape of the API, and she got none of that either. The product she shipped is whatever survived a week of small private negotiations between the codebase and itself. She wrote a brief, and never went back to read the one the build had been writing her all week in return.
The reflex on every engineering team I have worked with is to treat these as nuisance traffic, errors to be cleared so the actual work can resume, when the compile error is the actual work and the reflex has it exactly backwards. The build has read the brief carefully and found a sentence it cannot honour. It is asking the team to rewrite either the sentence or the code, the way Bashar bhai is asking me, with a polite cough at the rebar count, to either accept the slab he built or send his boys back to tie another twelve pieces by lunch. Bashar bhai is being literal about it, which is the only stance a foreman can afford when the pour is two hours away. The drawing said 48; he has tied 36; the building will be the one we agree on after the second walk.
load-calculation memo · ref LC-2026
The fastest way to ship the right thing is to let the build read the spec back to you continually, on every commit and every push, in a register the spec is no longer allowed to ignore.
initialled · site supervisor · 11 May 2026
What I have started doing, on every feature where the deadline is mine to defend, is bring the compiler and the runner into the loop of writing the brief earlier than is socially comfortable. The first artefact for a new feature is no longer a Figma frame and a PRD. It is a stub of the API the new code will live behind, checked into a branch, returning responses mocked by hand, with a type checker watching it and three tests that run end to end pointed at it before any of the screens exist. The PRD comes a day later and is shorter, because the build has already answered four of the questions I would have written paragraphs about, starting with whether the response is a list or a paginated cursor and whether the empty state is null or an empty array. The auth header question, whether it gets renamed on a 401 retry, is usually the one the TypeScript narrowing has already settled before I open the doc.
Dan Luu has written several times about how engineering orgs decay slowly and the same way every time. They accumulate thousands of small unresolved ambiguities that the team treats as someone else's problem, until production catches fire on a Saturday and the engineer on call has to invent a policy in the dark. Most of those ambiguities had a more honest home. They had a compile error or a failing test that flagged them on the Wednesday they were first written, and the team chose to dismiss the flag because the brief, on paper, looked tidy.
The work I now ask of any agent or junior on a feature is not to implement the spec but to compile it. In practice that means reading the PRD and writing the type signatures it implies, then writing the smallest set of tests that would distinguish the intended behaviour from each obvious nearby behaviour. What comes back to me is the list of places where the PRD could not answer. That list of unanswered places, in my experience, is the real brief. The PRD was only the first draft of it, and the compiled types and failing tests are the editor's marks against that draft. The third pass is the brief the team will build against, which I assemble after sitting with the agent and deciding what each ambiguity actually meant. It lives in the code, not the wiki, because the only document that updates itself when the code changes is the code.
load-calculation memo
ref LC-2026-04b · 11 May 2026
P R D d r a f t 1
paragraphs and bullets
P R D a f t e r c o m p i l e
types, tests, three flagged ambiguities
initialled · site supervisor
S.E.There is a paragraph in The Pragmatic Programmer on what Hunt and Thomas call tracer bullets that has stayed with me since the first read. You wire the whole system end to end with the cheapest possible implementation of every part, light it up, and see where the bullet actually lands. The PRD is the aim and the build is the tracer round. The gap between where you aimed and where it hit is the only feedback worth optimising against, and the team that takes that feedback every commit instead of every quarter is the team whose features land where they were pointed.
The slab finished at half past three, after Bashar bhai's crew tied the missing twelve pieces and the architect's drawing took a correction in red pencil at the column line that we both initialled.
I keep telling this story as though the correction were obviously worth it, and mostly I believe that, though I am less sure than I let on in meetings that the twelve extra pieces of rebar were free. Bashar bhai's crew stayed on past when they would otherwise have knocked off, and nobody on my side of the ledger ever prices that in when we talk about the value of catching an error early. I do not have a clean answer for what that costs him against what it saves the building, and I have mostly stopped asking, which is its own kind of dishonesty. Bashar bhai would not call any of this authoring a document, and if I put it to him in those words he would assume I was trying to bill someone. The pour went on the corrected version, not the drawn one, and that is the only part of the morning I am fully certain of.