How We Actually Use AI Coding Agents in Production

Recently, while one of my agents was building the Firmware Flashing Service for an IoT project of ours, I was having lunch. By the time I came back to my desk, the service was working exactly as I had envisioned it. A fair share of the code we ship at ARITS now begins its life this way, and I thought it would be worth writing down how we have been running coding agents on production work.

Why we do not vibe code

The first thing to say is that we do not vibe code. Vibe coding, the way I define it, is just asking the AI to build you something ("build me a restaurant management system") and hoping for the best. What we do instead is define the system architecture first: how the services will be distributed, how the solution will be deployed, which framework and which of our own boilerplates will be used. Then we let the AI agents work inside those guardrails. Defining these things makes an agent work in a specific pattern, and that pattern is what generates the outcomes.

The bug that made us write things down

It was not always like this. Early on, a client wrote to us that a form post was not working on staging. When our QA team dug in, they found a family of similar issues the client had not yet seen. The UI our agent had generated looked fantastic, and the API worked as intended. But the frontend and the backend never agreed on the shape of the response, so every other form and listing filter quietly did nothing. I had shipped broken code, and I found out from a client.

So we wrote it down. A skill, for us, is a short instruction file that lives in the repository and teaches the agent how we do one particular thing on a project. The first skill we ever wrote was called validate-api-contract. It forces every agent to check the handshake signature between frontend and backend, in both directions, before it is allowed to call a task finished. Since then, that entire class of bug has faded to a rarity.

That file was the first of many. Open our skills folder today and every rule in it exists because a specific bug shipped, a specific afternoon was lost, a specific correction got repeated one time too many. None of it was written from theory. The folder is the team's scar tissue, written down so that every new agent inherits the scars without repeating the wounds.

Teaching an agent a tool once

Not everything in the folder is a scar, though. Our authentication server is a microservice we reuse as a lego piece across many of the tools and web applications we build. I trained my agent once on how to speak to it over its REST API: creating new users, managing permissions, disabling accounts. Now, integrating that service into a new project is a breeze. I do not have to educate my agent any more; it knows the tool in great detail.

The part that made me nervous

I will be honest about how this felt at the start. The first time agent-written code headed into Bullwip, a property management platform we built for a startup in the UK, it looked all right when I skimmed through it. But I was nervous, and not sure this would scale. Code that is not fully human-validated is a new process flow, and the architecture on paper did not make the feeling go away. Working with the agents did. The more the pattern held, the more confident I became.

I was not the only one who had to be convinced. At ARITS, the senior developers were the skeptics at first, right up until they started enjoying the agentic way of working themselves.

What we tell clients

Do our clients know that agents write a share of their code? Yes, we tell them. This is the current era, and it is the evolving way software development teams work. To meet the expectation of faster delivery in a fast-moving and disruptive industry, we all have to adapt. What we owe our clients is not a promise that humans typed every line; it is that the quality of what we build for them stays consistently high.

What I would tell another CTO

If another CTO asked me over tea whether they should let agents write production code, my answer would be: of course you can, but you have to know what the agent is doing and how it is reaching the desired outcome, and validate every step of the process. That is the whole method, really. Architecture first, guardrails in the repository, and lunch only once you have earned it.

If your team is working through the same questions, do let me know how you are approaching it. I hope this has been of some aid to you. Thanks!