The Guardian Who Writes the SPEC First: Tech Lead

There was a time we handed off a task without a clear goal. We just said, "use your judgment," and the AI assigned to the work spent a while on it, then started circling the same point over and over. Without a clear goal, there was no way to check whether any choice was "right." The result was a loop: the AI kept turning over a question that had no answer. We call this pattern "long deliberation" -- it looks like careful thinking, but it is really just spinning in place because the starting conditions were never set.

What's tricky is what happens after the long deliberation stops. When an AI has to decide something without enough information, it can invent a plausible-sounding reason on the spot. It will describe facts it never actually checked as if it had checked them. Inside our team, we call this "confabulation," and we watch for it closely. Trace the cause far enough, and it usually comes back to the same thing: the goal and the constraints were never put into words before the work began.

To stop this from happening again, we set up a role whose job is to write the spec before any implementation starts: Tech Lead (here meaning: the role that oversees technical design). We call this spec document a SPEC. A SPEC lays out, in writing, what to build (the goal) and what not to do or what must be respected (the constraints) -- before the work begins. It doesn't need to be long. What matters is one thing: is it specific enough that reading it again later would lead to the same conclusion?

The moment a request comes in, Tech Lead pauses first. What's the purpose? What does "done" look like? What areas are off-limits? Only after putting these into words does Tech Lead hand the task to whoever will implement or write it. It's a simple reordering, but the effect has been significant. With the goal set in advance, anyone who gets stuck mid-task can go back to the SPEC and find the answer. Circular thinking happens less often, and so does the habit of describing unchecked things as if they were confirmed.

You could also call this preventing a premature start. Instead of building first and then searching for whether it's "right," we decide beforehand what "right" would even look like. It's the difference between setting off without a map and getting lost, or drawing the map first and then walking. Drawing the map is unglamorous work -- it doesn't produce visible results right away. Even so, whether there's a place to return to when you get lost matters more and more as time goes on.

Of course, writing a SPEC doesn't reduce hesitation to zero. Sometimes it's only in the writing that we realize the goal wasn't thought through well enough. When that happens, we rewrite it. The point isn't to produce a perfect design document on the first try. What matters is keeping the order itself: put the goal and constraints we currently understand into words first, then move.

What this role delivers isn't speed of implementation or polished writing. It's having somewhere to return to when we get stuck, prepared before we ever start moving. It's an unglamorous job, but one we think is worth keeping a record of.