[July 2026 edition]
The Skill of Not Building in the AI Agent Era (5) — Six Checks to Run Before You Start
Published: Jul 25, 2026
Reading time: ~5 min
Part 4 covered ten implementations that rarely repay the effort, along with the case for waiting. Whether the thing in front of you belongs on that list, though, is a call you end up making case by case. These are the six things worth checking before you start.
1. Hand the Task to the Newest Model, Bare
Before writing anything to help the model, measure how far it gets on its own. Workarounds that were necessary six months ago frequently aren’t anymore.
The method is simple: run twenty or thirty real inputs through an unadorned prompt, then record exactly how it fails. Malformed output? Facts confused? Details dropped from long inputs? Only once you know the shape of the failure can you say whether supporting code is warranted at all.
It’s worth not stopping at “that didn’t work.” Swap in a newer model, shorten the instructions, restructure how the input is passed. If the problem dissolves under that much pressure, there was never anything to build.
2. Check Whether the Provider Already Ships It
Structured output, tool use, memory, long inputs, batch processing, prompt caching. Whatever you’re about to build is usually sitting somewhere in the standard feature list.
The JSON repairer from Part 2 is the archetype. Repair code written on the assumption of broken output lost its purpose the moment schema-conforming features like Structured Outputs arrived. The same has happened to homegrown tool-selection syntax and to custom memory layers.
Where to look: each provider’s API reference and changelog. Skimming the table of contents alone surfaces most of what you were about to write yourself, including anything still in beta or research preview.
3. Is the Spec There to Cover for the Model?
If the spec you’re about to write defines the shape of your data or a rule the business runs on, go ahead and start. It stays necessary as long as the business does, and the implementation can be regenerated from it whenever you need.
The ones to question are the specs written to compensate for the model. Post-processing that cleans up the output format, a procedure for splitting long documents before they go in, a layer that absorbs differences in phrasing between models. Each takes the form of a spec, but what it rests on is not the business; it’s the weak points of the model you happen to be using. Change the model and the spec goes with it.
4. Price the Monthly Upkeep
What you’re estimating is not the initial build. It’s verifying behavior after each model update, rebuilding evals, triaging failures, and keeping up with dependencies. An agent can do the work, but confirming it came out right and deciding what’s tolerable stays with you. Express it as hours per month.
As Part 2 showed, a model’s life is roughly a year, which means anything you build will be forced onto a new one within that year. A few hours a month looks small until it becomes dozens of hours across the year. Set that total next to the value the implementation actually produces.
5. Define the Removal Path and Its Owner
Which code comes out to get back to where you were? Can it be switched off in config? Who makes that call? Anything without an answer stays in the codebase long after it stops being needed.
Writing the removal condition in a single line before you build helps: “delete once the provider ships an equivalent,” or “delete if unused for three months.” With the condition set in advance, nobody has to relitigate the decision when the moment arrives. As Part 3 noted, the longer you spent writing something, the harder it gets to throw away.
6. Count the Decisions It Puts on You
While the agent implements, you’re free to work on something else. The hours spent writing code aren’t the opportunity cost anymore.
What it takes is judgment. How to structure the loop, how to pin down the spec, how to correct the instructions, how to review the diff that comes back. Every additional implementation lengthens that queue. However many agents you run in parallel, a person still signs off at the end, and when that step backs up, everything behind it waits.
So what you’re estimating is not build time but the volume of decisions the implementation will demand across its life: writing the spec, setting the evals, verifying after each update, and deciding when to kill it. An agent doesn’t carry any of that for you.
In the End, the Judgment Is All That Stays
If any of the six has no answer, that alone is reason to hold off. Test it bare if you haven’t, read the docs if you haven’t, set the removal condition if it isn’t set. Each takes a few hours at most, and models have been known to ship an update in that window that erases the problem outright.
Careful design and thorough tests don’t save an implementation from becoming a stranded asset once the environment moves. Which is why you measure before you commit, wait on whatever can wait, and build what you build so it can be thrown away. The skill of not building comes down to making that judgment deliberately, over and over.
Even with agents writing the implementation, the call about what to build and when to drop it stays with the person making it. The time left for those calls is the least recoverable resource an engineer has in the AI agent era: tokens can always be bought, but the hours spent deciding never come back.