A few days ago we closed a delivery with 47 commits in 24 hours, split between backend and frontend. They were made by a single person working with a coding agentCoding agentAn AI agent that writes, modifies and tests code on its own within a project. It is a striking figure, and that is why it is worth saying straight away that it is not the important one.
The important thing is why it was possible, and what would have happened if the same tool had been in other hands.
Writing code is no longer the bottleneck
A coding agent writes fast, does not get tired, and chains together dozens of changes in a day. That does not eliminate the problem: it shifts it. Before, the slow part was producing the code. Now the slow part is knowing what code is needed and checking that what has been written does what it should.
In other words: the agent provides the speed. The person provides the direction.
What gets multiplied
An agent amplifies whoever directs it, in both directions.
If you know the system well, know the order in which things need to be done, and recognise an error when you see it, the agent converts that knowledge into finished work at a pace that did not exist before.
If you do not know it, the agent converts your gaps into code just as quickly. And it makes it look good, which is exactly what makes it dangerous.
An example, made up but highly recognisable. An online shop decides to stop storing prices with decimals and move to whole cents, to put an end to rounding discrepancies. The agent receives the order, locates the twenty-odd affected files, and changes them all in an afternoon. The tests pass. The code reads well. Two weeks later, percentage discounts start to result in one cent less in some shopping carts. In just one of those files, the agent rounded before multiplying instead of after. Nobody saw it because the test data consisted of round numbers and because the change looked exactly the same as the other twenty.
Anyone who knew that calculation would have asked for a test with €19.99 and 15% before accepting anything. Anyone who did not, accepted a correct change in twenty places and a wrong one in one, with the same confidence in all twenty-one.
That is why the phrase works both ways: the agent multiplies what you already know, and also what you do not know.
Three things anyone directing an agent must master
1. What to ask for. You have to know the system well enough to divide the work into defined steps, take them in the correct order, and know when the result is not what was asked for. An agent answers the question you ask, not the one you should have asked.
2. What it can touch. An agent's permissions must be minimal and explicit: which repositories, which branches, which credentials, and whether or not it has access to production. Giving full access "to go faster" is the shortest way to turn a small mistake into a big one.
3. How far it goes. Not all actions carry the same weight. A change in a branch can be reverted; a data deletion or a bad deployment, not always. Irreversible actions are reviewed by a person before they happen, without exceptions.
How we do it
It is not theory. Our day-to-day with agents has four non-negotiable rules:
- The agent works freely locally and in working branches. Production it does not touch without a person saying yes, step by step.
- Before deploying, a backup of what is to be replaced and a rollback procedure already written. If something fails, it is restored in a minute, not improvised.
- Tests are run before touching anything and are run again on the server afterwards. If one fails, the deployment does not go out, no matter how much of a hurry there is.
- When the agent says "done", someone checks that it is true. The statement is not the evidence.
They are boring rules. That is precisely why they work.
This is not just about code
All of the above applies equally, or even more, to the agents starting to enter companies without writing a single line of code: the one answering customers on WhatsApp, the one recording expenses, the one moving an appointment, the one sending an email on someone's behalf. These are actions on real data and real people, and some cannot be undone.
The same question applies to all of them: what can it do on its own, what needs approval, and who gives it. In NAiOS an agent can propose a charge, a shipment, or a change to a record, but the action is confirmed by a person. It is what we call a HITL company, with the human in the loop. Not because the agent is clumsy, but because responsibility cannot be delegated.
With multiple agents, even more so
When one person coordinates several agents at the same time, the above stops being a best practice and becomes a prerequisite. A mistake no longer occurs in just one place or at a single moment. The permissions and limits of each agent are what separate a team moving forward in parallel from a problem propagating in parallel.
The conclusion
Agents do not replace judgement; they make it more valuable. The person who knows exactly what they are doing achieves in a day what used to take weeks. The one who does not achieves the same, but with their mistakes.
The question for any company adopting agents is not how much faster it can go. It is who is going to direct them, with what permissions, and with what limits. It is, in fact, what the EU AI ActAI Act (EU AI Act)Regulation (EU) 2024/1689: the first comprehensive law on artificial intelligence, with obligations based on risk level calls human oversight, and what it asks companies to ensure their teams know how to do from Article 4. We start there.
