An agent will build whatever you point it at. That stopped being the interesting part a while ago. What decides whether it builds the right thing is what you constrain it with, and most of the work I've done this year has quietly turned into constraint design.
Eyal Blum at Figma wrote up a case study that names this better than anything else I've read. Five packages, 200+ tests, IRS wash sale rules, 48 hours across dozens of AI sessions. The sessions that mattered most produced no code at all. They produced documents.
His framing is that the bottleneck moved. It used to be "can the AI write code." Now it's "can the AI stay coherent across a project that doesn't fit in a single session." His answer is to externalize context into a PRD, a design doc, and an implementation plan, and let each session read the current state and update it.
All these documents do one thing. They limit what the AI should be doing. The PRD limits scope. The design doc commits the data model and the seven algorithm phases before anyone writes code. The implementation plan cuts each phase down to something one session can finish. By the time a sub-agent starts writing, there's about one thing left that it could reasonably build.
He says this outright:
"This is where you put safeguards against slop. By investing time in precise requirements and acceptance criteria, you're defining what 'correct' means before any code is written."
Defining correct before any code exists. That's the job.
The part where he gets specific
The best section is about acceptance criteria. It goes from philosophical ideas about how agents act to how you begin steering their behavior.
A criterion like "verify basic wash sale detection" constrains nothing. An agent can satisfy that with almost anything. So he writes them like this instead:
Buy 100 shares at $50 on Jan 10. Sell 100 shares at $45 on Feb 15 (loss = $500). Buy 100 shares at $48 on Mar 1. Expected: loss of $500 is disallowed, replacement basis adjusted to $53 ($48 + $5), holding period starts Jan 10.
His tip for writing them: concrete numbers, explicit expected outputs, simple to complex. And then the reason, which is the whole thesis in one line: "The acceptance criteria become test specifications." When a criterion has concrete inputs and expected outputs, an agent can translate it directly into a test with an assertion. No ambiguity, no hallucinated numbers.
He's describing the moment a constraint stops being prose and becomes something a machine can check. That's the transition I care about most, and he found it from the other direction, working forward from how to write good requirements.
What his validation pass found
After every phase completes, his orchestrator launches a validation agent that cross-references the implementation against the acceptance criteria. It caught this:
"In my case, this caught real drift — AC-2, AC-4, and AC-5 had input differences between the PRD's examples and the golden test fixtures."
Three acceptance criteria drifted, on a careful project, with the documents being read into every session.
I've seen this read as a hole in his argument. I think it's the opposite. He built the validation pass because he already understood the principle: a constraint you can check mechanically is worth more than one you can only read. He didn't trust the documents to hold on their own, so he added something that fails when they don't. Then he published what it caught instead of quietly fixing it, which is the most useful paragraph in the article.
The drift is the frame working. Constraints vary in how hard they bind, and his pipeline has both kinds in it. The documents carried the intent across six context boundaries, which is real work that nothing else was doing. The validation pass is what made a violation impossible to miss.
So I want to take his idea further rather than argue with it. Why ask an agent to manage any expectation that can be expressed in code? Anything you hand it in prose becomes one more thing it weighs against everything else in the window. Anything you write as a check gets decided before the agent ever sees it.
How far up you can push a constraint
Sort them by how hard they bind and it's clearer where each one belongs.
A sentence in a PRD binds by persuasion. The agent reads it, weighs it against the code in front of it and everything else in context, and usually complies. A concrete acceptance criterion binds harder, because it says exactly what the output must be. A test binds hardest. It doesn't argue with the agent. It fails.
All three are useful and they're doing different jobs. Plenty of things can only be prose, because judgment doesn't compile. The mistake I keep making is leaving something at the persuasion level after it's become precise enough to move up. AC-1 in his article is already a test. It has inputs, an expected output, and no ambiguity. It just hasn't been compiled yet, and asking an agent to honor it by reading is asking it to do work a test runner does for free.
That's where I spend my time now, and it's what we build at Taskless: taking the corrections that would otherwise live in a markdown file and turning them into checks that run. Same intent, higher rung. Eyal's pipeline is the strongest argument I've seen for why that rung exists, because he arrives at the need for it from his own work and then reports what it found.
His own criteria for when the full process pays off includes the phrase "acceptance criteria that can be mechanically verified." We want the same thing. I'd just push the mechanical part further down the pipeline, so more of the design doc's decisions turn into things that fail rather than things that are read.
Two things I do now
I match models to task tiers. Drafting a PRD wants a strong model. Turning a design doc into phases is a translation job that a mid-tier model handles. Coding a well-scoped phase against clear tests runs fine on something fast and cheap. I'd been doing this by feel. His point is that the documents are what make it possible, since they're the interface between models, and it doesn't matter which model wrote the PRD as long as the PRD is good.
I keep the orchestrator out of implementation code. It reads the plan, the sub-agent summaries, and the test results. If it reads Phase 3's implementation, that context crowds out the room it needs to reason about Phase 8. I'd been letting my orchestrating sessions read too much and paying for it late in the run without connecting the two.
The same thinking pushed me to get explicit in my harness about when to use a sub-agent and when to use a worktree. Concurrent dev flows are solvable, concurrent runtimes are not. Two agents can edit in separate worktrees all day. They still can't both bind port 3000 or own the same test database. So the answer depends on what the phase is actually doing, and the agent picks wrong if you leave it open: a test phase fans out fine, and anything that needs the app running is one at a time in one place. That rule lives in my harness as prose, because deciding which case you're in is judgment.
Go read the whole thing. It's the most concrete writeup of multi-session AI development I've found, and it's the rare one that measures its own process and prints the number.