Hao Sun is an AI Engineer and former Founding member of MultiOn and Please Platforms.
A year of agentic coding inside my AI org included chatbots that answered crash questions, sandboxed, phone-controlled agents running next to the training cluster and everything that broke along the way.
Everyone is still arguing about which model tops which benchmark. Spend a year putting coding agents in front of hundreds of engineers, and that argument starts to feel like the least interesting one. The models got good faster than our roadmap assumed. What decided whether an agent moved real work was everything wrapped around it: who was allowed to turn it on, where it ran, what it could destroy and whether the vendor kept a copy of your source. If you are rolling agents out this year, that is the work to plan for. The model will mostly take care of itself.
Covering The Unit Of Work, Not The Announcement
A new model card tells you the parameters went up. It does not tell you what changed in your job. Over the year, our unit of work changed four times, and only the first change was about the model itself:
1. The model got good enough to open a pull request a human would merge. That was necessary, and the easy part.
2. Access went self-serve. This did more for output than any single model upgrade.
3. The agent moved next to the code and the cluster. Placement changed which tasks were even possible.
4. We had to bound what an unattended agent could delete, and which vendors could see the code. Policy and blast radius set the real ceiling on autonomy.
Three of those four are not model problems. They are access, placement and safety problems. That ratio is the whole story.
The Mechanism: What Actually Broke
Here are three field notes drawn from my experience, because none of these lessons became real until we earned the scars.
Self-Serve
For a long time, getting an agent meant a manual approval queue. The moment the tool was genuinely good, that queue became the most expensive thing we owned. Moving to request-plus-manager-approval, behind one internal gateway, took the tool from a pilot clique to hundreds of engineers in about a week. The lesson is unglamorous: The bottleneck was org design, not model capability.
Blast Radius
The write-up that reframed the year for a lot of us was not about a model at all. It was one engineer working out how to stop an unattended agent from wiping a shared research file system so large it cannot realistically be restored.
The realization: There are two blast radii, not one. The agent process on the login node is the first. The batch jobs it launches, which run somewhere else with full access to shared storage, are the second.
Sandbox the first and ignore the second, and you have built a fence with no back wall. Shell-command filtering will not save you; there are infinite ways to delete a file. The answer lives lower down, at read-only mounts, scratch overlays you review before they land and containerized jobs.
Policy
More than once, the newest, best model showed up and the answer was no, because it failed a zero-data-retention bar: The vendor would keep prompts or code. Engineers felt that as pure FOMO, a better tool sitting just across a line they could not cross. It was still correct. Capability comes back next quarter. Source code that leaks into someone else’s training set does not. Because everything sat behind one gateway, “no” got enforced once instead of re-argued per tool.
‘But The Model Gains Are What Mattered’
The strongest objection is that the model jumps are the real story and the rest is plumbing. That’s half right. The model gains were necessary. They were not sufficient, and more of them did not relieve the actual constraint. This is the Jevons paradox in miniature: When generation gets cheap, the bottleneck moves to the expensive step next door.
Cheap, fast agents did not remove work; they moved the scarce resource from “writing the code” to “deciding what to keep and making sure it cannot hurt you.” A smarter model with the same broken access flow, the same shared-filesystem exposure and the same retention risk would not have shipped more. It would have shipped the same amount faster, with a larger downside.
What To Actually Do This Week
The next step is not to “become AI-native.” It’s one move.
Take one real workflow and place it exactly one rung higher. If you prompt ad hoc, save your best repeated one as a reviewed skill. If you already have skills, put one behind a supervised workflow with an approval gate. If you already schedule work, do not raise autonomy until you can answer one question honestly: What is the worst thing this agent can delete, and can it actually reach it?
Separately, put one gateway in front of your models so policy and cost are enforced in a single place rather than per tool. Then stop touching model choice for a month and watch whether output actually changed.
What Stays Human
The model can take most of the execution. It does not get to hold the stop. A human still decides which 20% is worth staying, still approves the merge and still owns the taste for what “good” looks like in your codebase. The agents that compounded were the ones that encoded your conventions and left the judgment with you. The ones that dazzled in a demo and made the call themselves are the ones you meet again in the incident review.
So here is the question we kept having to answer, and the one to leave you with: If the agent takes 80% of the execution, what is your 20%, and have you made the other 80% safe enough to let go of?
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
