AI coding agents are tools that read a codebase, make changes across several files, run commands and report back on what they did. For a small product team, they change where the hours go. They don't change who is responsible for the result.
This article covers where agents genuinely save time, where they still need a person watching closely, how we use them on client work, and what all of this means if you're about to hire a team to build something for you.
Where agents save real time
The best jobs for an agent have three things: a clear goal, a pattern to follow, and a way to check the result.
Scaffolding. Adding a new screen, a new API route or a new form usually follows patterns the codebase already has. An agent can copy the pattern, wire up the obvious parts and leave a working starting point. A developer then spends their time on the part that's actually new.
Tests. Writing tests for code that already exists is slow, and it's the first thing to slip when a deadline is close. An agent can read a function, list the cases it should handle and write the tests. A person still decides which cases matter, but the typing is done.
Refactors. Renaming a concept across a codebase, splitting a large file, or moving from one pattern to another touches many files in the same way. Agents are good at repetitive, consistent changes, and a good test suite tells you straight away whether anything broke.
Migrations. Upgrading a framework or a library usually means reading a migration guide and applying the same kinds of edits in many places. An agent can work through the list, run the build, and fix what fails, while a developer checks the edge cases the guide warns about.
Documentation. Agents can write a first draft of setup notes, API descriptions and handover documents from the code itself. The draft needs checking, but it's much easier to correct a draft than to start from a blank page, and handover notes are something every client should get.
What these jobs have in common: the agent isn't deciding what to build. It's doing work whose shape is already known.
Where they still need a person
Product decisions. An agent will build what you ask for. It won't tell you that the feature your first customers need is a different one, or that the second screen can wait until the next release. Deciding what to build, and what to cut, still comes from talking to the people who will use it.
Architecture. How data is stored, how parts of the system talk to each other and where the boundaries sit are decisions that are expensive to change later. An agent can suggest options, but it doesn't carry the context of where the product is going, what the team can maintain, or what has already been agreed with the client.
Security. Agents can write code that works and is still unsafe: a missing permission check, a secret in the wrong place, input that isn't validated. Security needs someone who asks "what could go wrong here?" on purpose, every time, and who knows which parts of the system hold data that matters.
Reviewing every change. This is the rule that makes the rest possible. Every change an agent makes is read by a person before it ships, exactly as if a colleague had written it. If nobody on the team can explain a change, it doesn't go in.
What this means if you're hiring a studio
Faster iterations. When the repetitive work takes less time, more of the budget goes to the parts you care about: the screens your users touch, the workflow that's specific to your business, and the feedback rounds that make it right. You should expect to see working software sooner and more often. On our projects, that means a working link every week from the third step of the process.
The same review standards. Code written with an agent's help should meet the same bar as any other code: it's reviewed, it's tested, and someone on the team can explain it. Speed is only useful if the result is something you can maintain after launch.
Who owns the code. Ask how ownership of the code and designs is handled in your contract, and whether the use of AI tools changes anything about it. You should get a clear answer in writing before work starts.
Questions to ask any team that uses AI agents
- Which parts of the work do you use agents for, and which parts do you never hand to them?
- Who reviews each change before it ships?
- How do you test what an agent writes?
- Does any of our code or data leave your systems when you use these tools, and where does it go?
- How is ownership of the code and designs handled in our contract?
- If an agent introduces a bug, how would you find it, and how quickly?
A good team will answer these plainly and without hesitation. If the answers are vague, that tells you something too.
If you're planning a web app and want to see how we run a project from the first call to launch, our web app development page walks through it.
