It was around midnight on a Friday, three weeks ago, and I was designing persona based personalization for a product I was not building.

What I was supposed to be doing was finding the pattern for wiring a relationship based access control service into one of our existing microservices, so we could stop hardcoding role checks into conditional blocks and stop leaning on PostHog to manage feature flags. That had been the job for weeks, I cared about it, and I had been making real progress on it.

Instead I was sketching recommendation flows for something else entirely, at midnight, on a Friday, with nobody asking me to.

Here is the part that took me the longest to understand. Nothing had gone wrong. No agent had hallucinated, no answer had come back incorrect, no code had been bad. Everything I did that week was defensible and most of it was genuinely good work. I just was not building the thing I had set out to build, and I had not been for days, and not one person had mentioned it.

So I spent the next thirty or forty five minutes tracing my own week backwards, looking for the point where the path bent.

There is a moment in the sixth Harry Potter book where Dumbledore stops collecting memories and starts studying the ones he already has, turning them over in the pensieve until the single binding thread through Tom Riddle's life becomes visible. I have thought about that scene more than I expected to since that Friday, because what I needed at midnight was not more information. I needed to get what I already had out of my head and somewhere I could look at it coldly. Willpower does not scale. Artifacts do.

The most expensive question I asked that week sounded completely harmless. Something about whether we could personalize the experience by persona, and it arrived in the middle of a perfectly sensible conversation about running scans across our repositories to find every place that could be modeled as a relationship triplet. Good idea, that one. The kind of thing you are quietly pleased with yourself for having thought of.

From there it cascaded, for something close to seven days.

Curiosity ate the cat. That is not the saying, I am aware, but it is nearer to what happened, because nothing got killed exactly, I just got quietly eaten over a week by my own engineering curiosity, which as it turns out is a considerably more dangerous animal than it used to be.

What I had to show for it was five architecture decision records and about four planning documents. Nine documents. Two of the ADRs and two of the plans I have not opened since and will not open again.

Nine documents, four of them dead, and a week of forward motion that did not happen. That is the bill, and I will leave it sitting there without dressing it up, because dressing it up is the whole temptation.

All of this, six weeks of it, ran through coding agents, mostly Claude Code, inside spec driven workflows I had adopted because I thought they would keep me honest. GSD for execution, BMAD style planning for thinking. They did not save me on their own, because any framework that lets you open a new thread will let you open a new thread.

Something has changed about the shape of engineering work and I am not sure we have named it correctly yet.

What got cheap is building, and not just the typing, but the whole apparatus of working out how to build something you never have before. What a Zanzibar style relation tuple model is, how a Kubernetes control plane should be organized, how to cross compile cleanly for a different processor architecture. Weeks of reading and a couple of false starts, now a few hours of interrogation.

What did not get cheap is deciding. Judgment never does, and it got harder, because the number of available directions went up while the cost of pursuing any one of them went down. Verifying got more expensive too, since there is simply more output to check. The part of the job that used to be most of the job is now the small part, and the part that was always hard is nearly all of it.

I want to be careful with the leveling claim, because it is mostly earned and slightly oversold. Build cost collapsed and knowledge access collapsed. Distribution did not. Customer trust did not. Capital, regulatory posture, proprietary data, none of that moved. David can build like Goliath now. He still cannot reach like Goliath. The sling levels the fight, it does not aim itself.

The obvious objection is that I have described scope creep, which has existed as long as software has, and given it fresh vocabulary. I believed that for about a day. I do not think it holds.

Scope creep classically arrives from outside you. Somebody wants something, and it arrives with friction attached, because somebody has to be convinced, somebody has to be resourced, something on a plan has to move. Which means there is always a person in the room capable of saying no, even if they say it badly.

What happened to me came from inside me, at zero friction, with nobody in the room at all.

The second difference unsettles me more. Old scope creep left you with a longer backlog, which at least looks like what it is. This leaves you with artifacts. Finished ones. Research writeups, decision records, plans, prototypes for directions you are never going to take. It does not feel like drift while it is happening, it feels like a productive week, and it reads like a productive week on disk, which is why mine ran seven days without tripping anything.

The question underneath all of this turns out to be embarrassingly simple. Who says no?

Think about what used to. The budget said no. Headcount said no. Not knowing how to do the thing said no, and said it for months at a stretch. The cost of exploring a direction said no before you were three days into it. Every one of those was friction, and every one is precisely what we have spent two years celebrating the removal of. We took the brakes off deliberately. That was the point.

Ben Parker got there before the rest of us, as he usually does. With great power comes great responsibility, which were, famously, his last words before he dropped Peter Parker. The part I had never thought carefully about is who that responsibility is owed to, and by whom. It is not owed to the agent, which neither needs it nor can use it. It is owed by the person holding the wand, and it consists almost entirely of knowing when to stop.

Because the agent will not tell you. Mine did not. It answered every question I asked, correctly, quickly, for seven days, and it never once mentioned that I had stopped building the service.

What saved me was not insight, and certainly not discipline in the moment, at midnight, which is when discipline is least available to anybody. It was an obligation I had set up weeks earlier and half forgotten. Every week I send a progress note to the organization on the access control integration and the modernization work. I had to write that note, and writing it meant answering, in public, in text, what had moved.

Nothing had moved. That is what stopped me. Not virtue. A promise made to other people, with a deadline on it, back when I had no particular reason to want to break it.

Then I did something more uncomfortable than tracing backwards, which was reading the week's output honestly and finding that a lot of it was good. Buried in those nine documents were genuinely illuminating findings about our infrastructure choices, about single threaded processing on Graviton arm64 compute, and about the cost savings that would follow. Not speculation. The good stuff.

I will not smooth over that, because it is what makes the trap a trap. If branching only produced garbage nobody would branch. It produced something valuable, and it still was not a process, because value you find by accident is not a capability you own, it is weather. A week that yields something good by luck is still an undisciplined week.

So the service was code complete, and I parked it there on purpose, and turned the useful part of the mess into the next body of work: a cohesive approach to our infrastructure, a real lean toward cost efficiency, a better HA and resiliency posture, and a more scalable platform underneath it. I did not experience that as a consolation prize, and it has become the more consequential work.

A few days later I was talking with an engineer on my team, someone genuinely excellent at research, and she described her own week to me. She had kept branching, and branching, and branching, and when she finally assembled all of it into a mind map, what she had was a network of threads too tangled to reconcile or even fully understand, with no way to move the needle forward or realize any value from the effort.

I recognized it instantly and told her so, because I had just crawled out of the same hole. We spent the rest of that conversation working the same problem from two directions, which is the only reason I am comfortable telling this part at all. Two capable people, independently, in the same fortnight, undone by the same absence. That is what convinced me it is structural rather than personal.

What we landed on is not exotic, and I am mildly embarrassed by how ordinary it sounds. Write the spec first.

Not a prompt. A spec. Scope, constraints, guardrails, acceptance criteria, validation checks. What this work is, what it is explicitly not, what would prove it done, what would prove it wrong. Then a rule with teeth: when the work diverges, and it will, the divergence goes through a spec review before it becomes work.

Every mechanic we adopted turns out to be the same mechanic in different clothing. Each one is a no I committed to in advance, while calm, so that a version of me at midnight on a Friday does not get a vote.

A spec is a no written down before the temptation exists. A stop condition is a no with a trigger attached. One thread open at a time is a no by construction. An RFC review on anything that defines scope is a no with other people's names on it. And an LLM judge sitting in pull request review, questioning intent and flagging divergence, is a no I outsourced to something that does not get curious at midnight. We lean on Cursor bot heavily for that.

That last one matters most if you run a team, because it is the only part of this that scales. When one person generates more than they can review, that is a bad week. When fifteen do it at once, review capacity becomes the binding constraint on the whole organization, and unreviewed agent output stops being an asset and becomes a liability sitting in your repository. Slop is what happens when generation outruns review, and no model upgrade fixes that.

Two caveats, because this looks different depending on where you sit.

Building alone, there is no RFC review and no team holding a line, so the spec does all the work. Which means writing it down and rereading it before each session, not because it is inspiring but because you are the only gate in the system, and a gate has to be checkable from outside your own head. That is why the pensieve is the right image. The memories have to leave the skull before anyone can examine them.
And if you do not own your scope, your branching is invisible to your manager and surfaces only as slowness, which makes it a reporting problem as much as a discipline one. The permission you might be waiting for is this: closing a thread is not the same as skipping diligence. I closed several directions that afternoon and every one of them was interesting. The fear of looking incurious keeps a lot of branches open.

The test of all of it came immediately, on the arm64 work.

Before anything got built this time, I spent several hours writing the contract. What the modernization was for, why it mattered, and above all how it would simplify maintenance and give us operational excellence rather than just a smaller bill. Those became the constraints the coding agents designed against, and out of that contract came the control plane design, the infrastructure layer, the interface contracts, and golden templates for rolling the upgrade across a fleet of services.

The first services are through, on a structure that holds. The difference between the two attempts had nothing to do with being smarter the second time. It was the ordering. The first time I explored and then built. The second time I wrote the contract, and then explored inside it.

The tools are there, better than last year and better again next year. Discipline is what is wanting, and discipline is a rare commodity.

The mind wants to gallop; that is what minds do, and I do not think that part is fixable.

What I have given up on is the idea that the tooling will fix it for me. It will not, and it is not its job. An agent has no idea you set out for anywhere in particular. Only you know that, which makes knowing your work, and stopping your work, and the writing down of what you actually came here to build your work.

Agentic coding is an extension of your creativity. It is not a replacement for it. Hand it the thinking and it will take the job, cheerfully, all week, and never once mention that you have stopped building the thing you came to build.