Coding Agents Changed How We Build. Here Is What That Looks Like

A couple of years ago, writing software at a small studio meant a lot of typing. Not the interesting kind, where you are deciding what a system should do. The other kind: wiring up the fifth CRUD form of the week, renaming a field across forty files, writing the test you already know how to write. That work has not disappeared, but a good chunk of it no longer lands on a person.

We build websites, web apps, and AI systems, and we use coding agents heavily in our own work. This is not a pitch and it is not a warning. It is an honest account of what actually changed, day to day, once agents became part of how we build.

I will start with the part everyone wants to hear about, then get to the part that matters more.

What got dramatically faster

The first thing to go was scaffolding. A new page, a form with validation, an API route, the boring glue between them. An agent produces a working first version in the time it used to take me to open the right files. That sounds small until you notice how much of a week is spent on exactly that kind of setup.

Tests came next. Not because agents write brilliant tests, but because they write the obvious ones fast, and the obvious ones are the ones we used to skip when a deadline was close. Now there is no excuse. You describe the behavior, the agent drafts the cases, you fix the two it got wrong. Coverage stopped being a chore we felt guilty about.

Migrations and refactors changed the most, honestly. Renaming a concept across a codebase, moving a database column, pulling a tangled function apart. These used to be all-day jobs that nobody volunteered for, because they were tedious and easy to get subtly wrong. An agent will grind through every reference without getting bored on file thirty. We still check the result, but the dread is gone.

And then there is exploring options. This one surprised me. When you are not sure whether an approach will work, it used to cost too much to try three of them, so you picked one and hoped. Now you can ask an agent to sketch two or three real versions of a feature, run them, and see which one actually feels right before committing. We throw more of these away than we keep, and that is the point. Cheap exploration means fewer expensive mistakes locked in early. If you want the longer version of how these tools actually produce code, we wrote about that in AI agents that write code.

What changed about how we work

Here is the shift that took longer to admit. When writing code gets cheap, reading code gets expensive.

We spend more time on review now, not less. An agent can hand you two hundred lines that look completely reasonable and contain one quiet assumption that will bite you in production. The confident, tidy output is exactly what makes it dangerous. So the job moved. Less time producing the first draft, much more time interrogating it: does this handle the empty case, does it match how the rest of the system works, is it solving the problem we actually have.

Our testing habits changed to match. We lean harder on running the thing than on trusting that it reads correctly. Agent code often looks right and behaves wrong, so we exercise the real flow, click the real buttons, watch the real logs. A green typecheck is not evidence anymore. Behavior is.

The new failure modes are specific, and worth naming plainly:

• Confident nonsense. The code is well formatted and completely wrong, which is harder to catch than obviously broken code.
• Plausible drift. An agent quietly invents a slightly different pattern than the one your codebase already uses, and now you have two ways of doing the same thing.
• Silent scope creep. You asked for a small fix and got a helpful rewrite of three things you did not want touched.

None of these are reasons to stop. They are reasons to review like an adult. We adapted by writing tighter instructions, working in smaller steps, and treating every agent as a fast junior who is brilliant at typing and cannot be trusted with a decision. That framing keeps a human in the loop where it counts, which is a habit we take seriously and wrote more about in keeping a human in the loop.

What stayed firmly human

Now the part that matters more than any of the speed.

Deciding what to build did not move an inch. An agent has no idea whether a feature is worth building, whether the client actually needs it, or whether the simplest answer is to not build it at all. That judgement is the whole job, and it is still ours. The best engineering decision is often to delete the ticket, and no agent will ever suggest that.

Architecture stayed human too. Agents are great inside a well-shaped structure and hopeless at choosing the structure. How the pieces fit, what talks to what, which constraints you accept now so you are not trapped in a year. Get that wrong and no amount of fast code saves you. Get it right and the agent becomes genuinely useful, because it is filling in a plan a person made.

Taste stayed human, which is harder to put into words but easy to feel. The difference between software that works and software that is a pleasure to use lives in a thousand small choices an agent will average its way straight through. Someone has to care about the thing being good, not just correct.

And accountability never moved at all. When something ships broken, "the agent wrote it" is not an answer we would ever give a client, and we would not accept it from ourselves. We put our name on the work. That is the actual line, and it is a comforting one: the responsibility stays with people, so the decisions do too. If you are wondering where all this leaves the developer, the short version is that the role got more human, not less, and we argued that case in will AI replace developers.

So the honest summary is this. Coding agents made the mechanical parts of our work faster and the human parts more important. We build more, we throw away more of our first attempts, and we think harder about the things that were always the real job. The tools got better. The responsibility for what gets made did not go anywhere.

If you have a project where that mix of speed and judgement matters, that is exactly the kind of work we like. Work with us and we will tell you honestly what is worth building and what is not.