AI made execution cheap. Judgement did not get cheaper.
Building an autonomous agent took days instead of months. Deciding which tasks deserved automation took far longer, and that gap is not closing.
I have been building an autonomous agent for the last few months. It is not finished. The parts I expected to be hard turned out to be fast, and the parts I treated as preliminaries consumed most of the calendar.
Wiring the agent together took days. Tool definitions, the orchestration loop, error handling, retries against a flaky upstream API. Work that would have taken a quarter three years ago closed in a week. The model wrote most of it and explained the parts I pushed back on.
Then I spent three weeks deciding what the agent should do.
That ratio is the whole story of building with AI right now, and most teams have it backwards. They budget for engineering and treat scoping as a meeting. The cost has moved.
What actually got cheap
Execution collapsed in price across every layer I touched:
- Boilerplate and glue code, effectively free
- Integration against documented APIs, hours instead of days
- Test scaffolding, generated faster than I can review it
- Refactors that used to sit in the backlog for a quarter
None of this required a frontier model doing anything clever. It required a competent model doing ordinary work without getting bored.
What did not
Judgement did not move. Specifically:
Knowing which tasks survive contact with production. An agent that reconciles two systems demos beautifully. In production it hits the case where both systems are wrong in different directions, and now you need a human policy for which one wins. That policy is not a prompt. Someone has to decide it and own it.
Knowing which tasks are worth automating at all. Automating a task that runs twice a quarter buys you a maintenance burden. I killed two features on this basis after building them, which is the expensive way to learn it.
Knowing when the demo is lying. A task looks automatable when you have seen the happy path five times. The distribution of real inputs is wider than the distribution you tested against, and models fail differently from the deterministic systems your intuition was trained on.
Owning the failure. When the agent gets it wrong at 2am, a person answers for it. No amount of model capability transfers that.
The practical consequence
If execution costs a tenth of what it did and judgement costs the same, then judgement is now the constraint on everything you ship. That changes how I plan work.
I now spend the first block of any agent project writing down what the system must never do, before writing what it should do. The negative specification is shorter, more stable, and catches the failure modes that the positive specification assumes away.
I also stopped treating "we could automate this" as a reason to automate it. The question I ask instead: if this runs unattended for six months and gets 4% of cases wrong, who notices, and what does it cost to find out? Most candidate tasks fail that question. The ones that pass are worth real engineering.
The teams shipping agents that survive are not the ones with better prompts. They are the ones who spent longer deciding what to point the agent at.
Related reading
- AI engineeringNot every agent in your pipeline should be an LLM callMost agent pipelines route validation, formatting, retries and the final write through the model. Those are the steps that should never vary, and handing them to a model is what makes an agent flaky and expensive.
- AI engineeringI plan agents in two models before I write any codeA method for building AI agents that starts with architecture and adversarial review instead of a system prompt, and why it costs less than rearchitecting later.
- GovernanceAn AI agent with memory is a database nobody governsAgents that remember across your apps and read your files are data systems. They need an owner, a retention policy, and a deletion path, and most teams piloting them have none.