A popular post on X in August said the big AI vendors will sell you a $200 monthly plan for their coding agents and never tell you about the fix that brings it down to $20.
I think it is sensationalized.
The post argues about which plan to buy. The bigger saving comes from letting agents evolve the work into deterministic code wherever it can go: an ordinary script that does the same thing every time. An agent is billed in tokens, the units of text it reads and writes, every time it thinks. A script that runs costs next to nothing to run again.
That code also teaches. Working code, especially comprehensive code that works, is one of the most useful references an AI can have: the agents pattern each new piece off it, and the more of it there is, the better they do. That is what a software factory is for: agents producing code, and every finished piece becoming the reference for the next.
Here is what that looked like on a real project.
Each finished script
becomes the next reference.
On a recent Azure migration, the job was to move an organization's cloud estate into a new tenant, their own separate Azure environment. That meant exporting everything that existed, surveying the exported settings, and producing Bicep templates, the files that rebuild it, filled with accurate values. The agents ran that workflow, improved their own craft until the same work could be done by a script, then improved the export code and the templates until the whole thing ran as a deterministic pipeline.
After twenty rounds of that loop, every resource was copied over to the new tenant exactly.
What remained was a script we can re-run for no tokens.
Production, which on that project meant testing and a few environment deployments, ran at almost zero tokens. The script does the work and the agent merely runs the tool.
That script is now the reference. The time the project saved went into generalizing its code into a reusable tool, which we are extending across the Microsoft 365 workloads, so the next project starts from code that already works.
Getting started is difficult. Once the reference code builds up, the agents largely carry it forward. Even the start can be codified: my larger build has commands that stand up a new engagement by a standard protocol and spawn its second brain, the wiki of facts its agents work from, out of a template.
The client owns that code when the project ends, the same as with traditional software: reusable deterministic tools, and the dashboards and reports people actually read. There are fewer screens to fill in, because the tools are run by asking the AI in chat.
Some use cases evolve all the way to 100% deterministic code. Others stay flexible. The specialist skills that ran a migration can also stand up new infrastructure, deploy a common landing zone or build a demo quickly, and anything temporary or unique still needs the model, working with the tools you have given it.
The agents are flexible middleware. The tools we give them expand what they can do.
Every repeated mistake
is written into a skill.
The code only got there because the agents stopped repeating themselves. Early on, the migration loop ran for a day with no noticeable progress, because there was nowhere to store what the agents learned and the same mistakes kept coming back.
The fix was specialized agents, one per competency, each improving its craft until a mistake stopped recurring. Some resources had been missing 20% of their exported metadata and recovering only 5% per iteration. With better craft the agents captured close to 100% on the first pass, and the scripts now capture all of it. Each iteration became drastically cheaper.
When an agent stalls, takes too long over something basic, or fails several times in a row, ask it to take a step back, persist the learning, then apply it and try again.
Most of the time it works.
The standing instruction was the same throughout: code your procedures for repeatability, and use every learning three ways. Improve the code, update the agentic behaviour, and document the facts in the second brain.
Facts go in the wiki. Behaviour goes in the agentic layer: the agents, skills and commands that tell them how to work. Wherever a loop fails, the skill gets improved before the next run.
I rarely import third party skills. They are built for their creator's workflow, and I believe the labs fold the most popular ones into training anyway. I use them as inspiration and have the model build a better skill for the repo, around the organization's own procedures, dialled in to the sliver that matters so it does not bloat the context.
Eventually
skills become code.
A skill that is improved at every failure gets better until its outputs are perfect, run after run. Once a skill produces perfect outputs, it becomes a candidate for deterministic code, and at that point the conversion can be made: the agents write the script that does the same work the same way every time.
After the conversion, the agent no longer does that work. It runs the tool. That is how the migration's production runs got to almost zero tokens.
Operators steer
until the guardrails take over.
The craft does not run itself. People stayed in the loop for judgment and decisions. The migration ran across close to 100 sessions, and people did the manual verification at target, confirming resources were mounted and data was copied.
The steering call I made most often early on was specific: update the wiki now, or update the skill now. Until a repo knows when to do that itself, someone has to say so.
The other was to simplify and stay focused. Early agents spew output and fixate on things you do not want. A north star file, one page stating the repo's purpose, handles that: work that does not serve it gets ignored.
Those calls build up into repo guardrails, and the guardrails then do the steering for you.
Scope is a human call as well. In the first week of that migration we pulled in three subscriptions instead of one, cut scope hard, and rebuilt the second brain from scratch, distilling what was useful from the first.
People discuss and decide, and only then does a decision go into the brain. A single wrong fact gets corrected in place. When assumptions have spread, rebuild from the facts in the original, because with several agents writing at once they are too hard to pull back out.
That is why skilled subject matter experts have to be the operators and guardians of the truth. The models are very smart and cannot see the big picture; operators supply the finesse. This is human judgment, not mechanical operations.
My estimates put builds
at a third of the time.
With that judgment in place, the time saving is real. Estimating software builds is much of my work. With agents, a build takes roughly a third of the time a human-only team would need, and most of that time goes on testing and tuning. In my experience the code that comes out is significantly better than what a mixed team of seniors, intermediates and juniors produces.
The migration came in on the same ratio, finishing in a third of its original estimate, which justified its own cost against a traditional all-human project.
I expect the same ratio on the next project, with fewer people involved. Every project I do will use this method from here on.
Give your agents
these standing instructions.
To do the same on your own build, paste this into the instruction file your agents read at the start of every session (AGENTS.md, or CLAUDE.md for Claude Code) and hold them to it.
## Standing instructions
- Code every procedure for repeatability. Prefer a script over doing the same work again by hand.
- Use every learning three ways: improve the code, update the skill that failed, and record the fact in the wiki.
- If you stall, take too long over something basic, or fail several times in a row: stop, write what you learned into the skill or the wiki, then apply it and try again.
- When a skill has produced perfect output run after run, propose converting it to a deterministic script. After the conversion, run the script instead of redoing the work.