Coding agents are now good enough that the interesting question is no longer whether they work, but where the time actually goes. On a small team the constraint is rarely typing speed. It is review capacity, context held in one or two people's heads, and the cost of a defect reaching a client. An agent shifts work across those three, and it is worth being precise about which direction.
Where the gain is real
The wins cluster around work that is well specified, verifiable and tedious. Migrating a component set to a new prop signature, writing tests for code that already exists, converting a design into a first pass of markup, drafting the boring half of a CRUD screen, or explaining an unfamiliar codebase before you touch it. In each case the correct output is easy to recognise, which is the property that actually matters. If you cannot tell within a minute whether the result is right, the task is a poor fit.
- Mechanical refactors with a clear before and after.
- Test coverage for existing behaviour, reviewed against the behaviour rather than the code.
- First drafts of routine screens and forms, then edited by hand.
- Reading unfamiliar code and producing a map of it before a change.
- One-off scripts: a data migration, a bulk rename, a log parse. Throwaway code with a visible result.
Where it quietly costs
The losses show up in work where correctness is contextual. Anything touching money, permissions, migrations or a third-party integration's edge cases produces code that reads fluently and is subtly wrong, and reviewing it takes longer than writing it would have. The failure mode is not gibberish; it is plausible code that ignores a rule only your team knows. That rule is not in the repository, which is exactly why the agent cannot honour it.
There is a second cost that is harder to see. An agent will happily add a dependency, invent an abstraction, or duplicate an existing helper it did not find, because none of those look wrong in isolation. Over a few months that produces a codebase that is larger and less coherent than the same work done by hand, and the bill arrives as slower changes rather than as a bug.
Generated code that nobody fully understands is not saved time. It is debt with a shorter fuse than usual.
Set the repository up so the agent can succeed
Most of the difference between a useful agent and an annoying one is the environment it works in, and all of it is work that helps humans too. A fast test suite is the single largest factor, because it is the only feedback loop that runs without you. Type checking and a linter catch a category of confident nonsense before a human sees it. A one-command local setup means the agent can actually run what it wrote instead of guessing.
- A test suite that runs in under a couple of minutes and fails for real reasons.
- Static types and a linter configured to fail the build, not to emit warnings nobody reads.
- One command to install, seed and run the project locally.
- A short conventions file in the repository: how we name things, which patterns are banned, what never gets touched without review.
- Small, focused modules. An agent reasons about a 200-line file far better than a 2,000-line one, and so does a new hire.
The guardrails worth having
Treat agent output exactly like a new contractor's first pull request: read every line, run it, and refuse anything you cannot explain. Keep the diffs small enough to review honestly, because a thousand-line change gets skimmed and both of you know it. Write the project's real constraints into a file the agent reads, so the conventions stop living only in senior heads. And never let generated code touch credentials, payment flows or database migrations without a second person looking.
- Small diffs. A change too big to review is a change nobody reviewed.
- Tests that fail for the right reason before the fix is accepted.
- A hard stop on secrets, payments and migrations without human review.
- No unattended commits to a shared branch, and no agent with production credentials.
The client confidentiality question, answered properly
Before any client code goes near a tool, know three things: whether the vendor trains on your input, where the data is processed, and what your client's contract says about subprocessors. Business tiers of these tools generally offer a no-training commitment; consumer tiers often do not, and the difference is a contractual one, not a technical one. Check the current terms rather than assuming, because they change.
Then handle the obvious hygiene. Keep secrets out of the working tree so nothing can be pasted into a prompt by accident. Redact customer data from test fixtures. If a client's agreement lists approved subprocessors, add the tool or do not use it on that project. Overseas clients increasingly ask this in procurement, and having a written answer is the difference between a quick conversation and a lost contract, which is the same pattern described in AI regulation and what changes in client work.
What to tell clients
Say that you use these tools, that a person reviews and owns every line shipped, and that your rate reflects the outcome rather than the keystrokes. Clients are not paying for typing. They are paying for a system that works on the day their customers use it, and for someone who can fix it at nine on a Friday evening. That has not changed, and any agency claiming a discount purely because a model wrote the first draft is bidding against its own review time.
Measure the thing that actually moved
Lines produced is a vanity number and, at this point, close to a warning sign. The honest measures are how long a change takes from request to production, how much time goes into review, and how many defects reach the client after release. If cycle time improved while review time and escaped defects held steady, the tool is working. If review time is climbing, you have moved the work rather than removed it, and the next step is smaller tasks rather than a better prompt.
The skill that matters more now
As drafting gets cheaper, the scarce skill becomes judgement: deciding what to build, noticing when an approach is wrong, and reviewing well. Junior engineers who lean on agents without reading the output stop developing that judgement, which is a real risk for a small team that needs its people to grow. Pair the tool with the expectation that every engineer can defend what they shipped, line by line, in a review. That expectation is also the most useful thing to set when you are hiring your first developer into a team that already works this way.
None of this changes what we sell. Clients buy working software on our software development and AI work, reviewed and owned by a named person, and the tooling behind it is our problem rather than theirs.
Abishek Bimali
Founder & Engineer
Abishek founded SiteCraft Innovation and leads its engineering. He writes about building web and mobile products that hold up in production, for teams in Nepal and abroad.
