The $1 House Still Needs a Site Survey

Matt Pocock got Uncle Bob on a livestream, and the bit I keep coming back to is the house.

Bob asks you to imagine that every change to a house costs a dollar. The foundation, the roof, moving the kitchen, moving the stairs. All of it, a dollar.

Would you pay an architect thousands to get the plan perfect before the contractor starts? Or would you tell them to put the foundation there, walk through it, decide the traffic pattern is wrong, and move the stairs?

He is right about the plan. He leaves out the other half of what an architect does.

What Bob gave up, and what he kept

Bob is blunt about heavy up front specification. He tried it, he was trying it again the week of the interview, and he calls the outcome the same every time: you write the plan, the agents run off half cocked on some nonsense the plan never anticipated, and you stop, rewrite, and start them over.

The agents themselves make this worse, because they love writing plans. The plans come back gorgeous and full of things nobody can build. So he went back to the agile loop. Do a story or two, look at what came out, reorganise, do a bit more.

What he did not give up is constraint.

Later in the same conversation he describes a file that pins which module is allowed to depend on which, and how the dependencies should flow. A checker runs at the end of the loop.

If the agents violated the rules they have to fix it, usually by inverting a dependency or splitting a module in half. He runs crap scores over the code and mutation testing over the tests, and the agents sit in that loop until the tools go green.

Ask him about specifications and he says they are ephemeral and he throws them away. The dependency rules and the thresholds are the things he keeps.

The distinction worth pulling out is prescription versus context.

Matt raises this in the conversation and lets it go. He asks how much planning happens before the gauntlet starts, because putting the wrong work through it is wasteful, and he says out loud that building the wrong thing is still possible. Bob answers with the history of waterfall and the agile correction, which is a good answer to how much planning and not an answer to how you know it is the right work. The gauntlet is a delivery machine. Crap scores, mutation testing and a dependency checker will tell you the thing was built well. None of them can tell you whether it was worth building.

The architect's other job

An architect does not exist because moving a wall is expensive. Before anyone decides where the walls go, someone has to know whether the plot floods, which way the prevailing wind comes from, where the sun rises, what the planning authority will allow, where the utilities run, whether anyone living there uses a wheelchair, and whether the family will still fit in the house in twenty years.

None of those answers get cheaper because the contractor works for a dollar a change. You can iterate at enormous speed and end up with a beautifully built house facing the wrong way on a floodplain. You are placing a bet either way. The survey is what tells you the odds.

The interview nobody passes by typing

There is a version of this you have probably sat through. You walk into a principal engineer system design interview and the panel says: design a system for X. If your first answer is "let's start coding and discover the architecture as we go", you have not shown them any system design yet.

What you do instead is ask. How many users? What is the read to write ratio? What consistency guarantees do we need? What happens when a region fails? What data are we storing and where is it allowed to live? What is the growth curve? Which parts of this cannot go down?

They are the forces acting on the architecture, and they decide which implementations are even in the running.

They get to this themselves. Matt reaches for John Ousterhout's split between tactical and strategic programming, and both of them stop to pull the book off the shelf. Bob takes it as given: agents are strong at the tactical work and weak at the strategic. That list of questions is the strategic work. The agents did not make any of it cheaper.

Context that compiles

Bob's reason for preferring tools over prompts has a name: lost in the middle. Anything you write at the top of a long context loses its grip as the window fills. A checker that fails the build does not, which is why I keep putting standards in linters instead of prompt files. Sort your context into two piles.

The first pile compiles. Module dependency rules in a file with a checker behind them, the way Bob does it. Complexity and coverage thresholds, picked so a green gate means something. A performance budget expressed as a test that fails at 200ms. Data residency as a lint rule that rejects an import of the wrong region's client. A public contract pinned by contract tests. Agents obey these because they run into them, not because they read them.

The second pile does not compile. What are we optimising for. Which constraints are fixed and which are negotiable. What this system has to become when the thing the company announced last quarter actually ships. Who this is for and what happens to them when it breaks. No checker exists for any of that, and you cannot leave it in a prompt and expect it to survive. It also decides whether the foundations hold: what you know is coming changes how you build now.

Bob's answer about juniors sits in that second pile. Asked how someone starting out learns the strategic half, he suggested they spend a few months being treated like an agent, given agent sized tasks and put through the same deterministic gauntlet, "horribly unproductive but learning a hell of a lot".

His own judgement came from somewhere else. He can spot an agent thrashing because he has watched systems thrash for fifty years. A principal engineer asks about regional failure because they were on call the night a region went down, and about data residency because they have watched a regulatory constraint arrive long after the architecture was set. The tactical work was the apprenticeship that produced the context.

There is a second question underneath the one about juniors learning to code. Where does the next generation get its context from, if the ten years of implementation that used to supply it are the part we are handing to the agents? I do not have a good answer yet.

Direction is not a plan

The vision does not need to be two hundred pages. It can be a paragraph.

This system will serve millions of users across several regions, hold regulated financial data, and keep taking payments while a region is down.

That paragraph says nothing about the implementation. It rules out a large class of the implementations an agent would otherwise produce. You can still throw code away six times an hour inside it, which is the part Bob and Matt are right about. I still would not put customers in that house, for the same reason I would not put them in a vibe-coded prototype.

That paragraph is a fence. It says what the system must never do. It does not say what anyone is trying to achieve, and an agent held inside a fence will build something nobody wanted, and build it well, at speed.

When a customer's card fails, they keep their service and understand what happened, without having to call us.

Back to the house

The contractor moves any wall for a dollar, so use that. Do not spend six months deciding whether the kitchen island sits 20cm to the left. Build it, walk around it, move it.

Before the first dollar, though, somebody has to say: we are on a floodplain, the wind comes off the west, one of the people living here uses a wheelchair, and we would like the house standing in thirty years.

This is the site survey. It covers the ground, and it covers who is going to live on it: a family who cook together every night and have never once eaten in the dining room.

One half tells you what the plot will allow, the other what the house is for.

Neither half is a floor plan. A contractor who moves any wall for a dollar can satisfy both while you are still arguing about the island.

As the cost of producing code falls towards nothing, working out the forces and where the system is heading is a larger share of what engineers are paid for.