Your AI Coding Assistant Stopped Suggesting and Started Shipping. Now What?

A few months ago, I saw something that made me rethink what coding assistants are actually capable of. A teammate was dealing with a frustrating race condition hidden deep inside a legacy service. It wasn't an obvious bug, and it had already taken quite a bit of time to investigate.

Instead of digging through the code manually again, he described the problem to a coding agent, started it, and stepped away for a coffee.

A few minutes later, the tests were passing, and there was a pull request ready for review.

That was the moment it clicked for me. This wasn't just smarter autocomplete or a chatbot generating snippets. The agent had explored the codebase, identified the relevant files, tested different approaches, verified the fix, and completed the task with very little guidance.

If you're still thinking about coding assistants the way we did a year or two ago, it's probably time to look at them differently. They're no longer just helping us write code. They're starting to take ownership of well-defined engineering tasks, and that's changing how many of us work.

Autocomplete Was Never the Interesting Part

For a long time, coding assistants were basically smarter autocomplete tools. They could suggest the next few lines of code, generate boilerplate, or explain an error message when you paste it into a chat window. Tools like GitHub Copilot made writing code faster, and there was no doubt that they improved day-to-day productivity.

But you were still driving the entire process. You decided where to start, which files to open, what needed to change, and whether the generated code actually solved the problem. The assistant helped you write code, but it wasn't responsible for the task itself.

That's what has changed over the last year. Today's coding agents are built to work toward an objective rather than simply respond to prompts. Give them a goal, access to your project, a terminal, and permission to run tests, and they'll start working through the problem on their own.

They inspect the codebase, identify the relevant files, make changes, run the tests, learn from the results, and keep iterating until they either solve the problem or genuinely need your input.

They're no longer trying to predict your next line of code. They're trying to complete the task. A typical workflow looks something like this:

$ agent run "checkout_test.py is flaky, find out why and fix it"

▸ Reading checkout_test.py, checkout_service.py, order_state.py
▸ Running test suite 5x to reproduce flakiness... 2/5 failures
▸ Hypothesis: race condition between inventory lock release and
  payment webhook handler
▸ Reading inventory_lock.py, webhook_handler.py
▸ Adding targeted logging, re-running...
▸ Confirmed: webhook can fire before lock release commits
▸ Editing inventory_lock.py — moving lock release after commit ack
▸ Running full test suite 10x... 10/10 pass
▸ Opening PR #4127: "Fix race condition in checkout lock release"

Done in 6m 42s. 1 file changed, 9 insertions, 3 deletions.

$ agent run "checkout_test.py is flaky, find out why and fix it"

▸ Reading checkout_test.py, checkout_service.py, order_state.py
▸ Running test suite 5x to reproduce flakiness... 2/5 failures
▸ Hypothesis: race condition between inventory lock release and
  payment webhook handler
▸ Reading inventory_lock.py, webhook_handler.py
▸ Adding targeted logging, re-running...
▸ Confirmed: webhook can fire before lock release commits
▸ Editing inventory_lock.py — moving lock release after commit ack
▸ Running full test suite 10x... 10/10 pass
▸ Opening PR #4127: "Fix race condition in checkout lock release"

Done in 6m 42s. 1 file changed, 9 insertions, 3 deletions.

Nobody told me which file the bug was in. That's the part that used to be the job.

Where This Actually Helps (And Where It Doesn't)

Let's be realistic. These tools aren't writing every line of code for us, and they probably shouldn't. What I've noticed is that developers are becoming much more selective about what they hand over. Tasks that are repetitive and easy to verify are usually fair game. Things like fixing flaky tests, updating dependencies, generating CRUD code, analyzing logs, or tracking down why an endpoint is suddenly running slower than expected.

On the other hand, work that involves architecture decisions, business logic, security, or long-term design still benefits from human judgment. Those are the areas where context matters, and where a conversation often leads to a better outcome than simply asking an agent to take over.

In practice, the most productive teams aren't trying to replace developers. They're using these tools to take care of the repetitive work, leaving engineers with more time to focus on solving the problems that actually require experience and critical thinking.

One thing I've learned is that the size of a task doesn't really determine whether it's a good candidate for delegation. What matters more is how easy it is to verify the result. For example, a large refactor across a codebase you know well can be a good fit because you can review the changes, run the tests, and quickly spot anything that looks wrong.

On the other hand, a tiny change in something like a payment reconciliation flow might deserve far more attention. Even if it's only a few lines of code, the impact of getting it wrong can be significant, and it's not always easy to validate the outcome with a quick review.

In other words, I don't decide based on how much code is involved. I decide based on how confident I can be that the result is correct. Another change that doesn't get talked about as much is how these agents are being guided.

In the beginning, everything depended on prompts. Every new session meant explaining your project's structure, coding standards, and the little rules your team follows.

That's becoming less common. Most modern coding agents now look for project-level configuration files before they start making changes. These files capture things like coding conventions, architectural guidelines, testing requirements, and simple rules such as "don't modify the migrations folder without approval."

The benefit is obvious. Instead of repeating the same instructions every time, you define them once and let the agent follow them consistently across sessions. It's a small change on the surface, but it makes these tools feel much more like a teammate who's familiar with your project instead of someone who needs the same onboarding every single day.

# Project conventions for AI agents

- Run `pnpm test` before opening any PR, not `npm test`
- Never modify files under /migrations directly — generate
  a new migration instead
- API responses must match the schema in /schemas, run
  `pnpm validate:schema` after changes
- Prefer editing existing utility functions in /lib/utils
  over creating new ones
- Ask before adding a new npm dependency

That configuration file does much more than provide instructions to the agent. It captures the small details that every team relies on but rarely documents well. Things like coding conventions, preferred workflows, and project-specific rules that usually exist only in the minds of experienced engineers or are buried somewhere in an old wiki that hardly anyone opens.

By putting that knowledge into a single place, every coding agent starts with the same understanding of the project instead of having to learn those rules from scratch every time.

The Multi-Agent Thing Is Real, Not Just Marketing

Another trend that's becoming hard to ignore is multi-agent orchestration. Instead of relying on a single agent to handle everything, one agent acts as a coordinator and breaks the work into smaller, focused tasks. For example, one might handle the backend changes, another updates the frontend, while a third reviews the code for potential security issues. Once each task is complete, the coordinator brings everything together into a single result.

I'll admit, I was skeptical when I first heard about this approach. It sounded like another buzzword that would look impressive in demos but struggle in real projects. But after seeing it work on practical tasks, like adding OAuth support without breaking an existing authentication flow, it started to make more sense. The work was naturally divided into backend changes, frontend updates, and a security review, with each part progressing at the same time instead of waiting for the previous step to finish.

It's not the right solution for every problem, but for tasks that can be split into independent pieces, it can save a surprising amount of time.

$ agent run "add OAuth login with Google, keep existing
  email/password flow working"

▸ Planning: 3 subtasks identified
  ├─ [backend] OAuth token exchange + session handling
  ├─ [frontend] Login button + redirect flow
  └─ [security] Review token storage, CSRF handling

▸ Dispatching subtasks (parallel)...
  [backend]  editing auth_service.py, session_store.py
  [frontend] editing LoginPage.tsx, auth_client.ts
  [security] reviewing diffs as they land

▸ [security] flagged: refresh token stored in localStorage,
  recommend httpOnly cookie instead
▸ [backend] applying fix — switching to httpOnly cookie storage
▸ All subtasks complete, running integration tests... 47/47 pass

Like any new approach, it isn't perfect. Coordinating multiple agents adds its own complexity, and there are plenty of situations where a single, well-configured agent is still the better choice. For tasks that require careful reasoning or involve lots of dependencies, keeping everything in one place is often simpler and more reliable.

Where multi-agent workflows really shine is when the work can be divided into independent pieces. Backend, frontend, testing, and security reviews can all move forward at the same time instead of waiting on one another.

It's not a silver bullet, and it won't replace every workflow. But when the problem fits the approach, the productivity gains can be surprisingly real.

The Bill Comes Due Somewhere

Of course, there are trade-offs. As these agents become more capable, they're also becoming more expensive to run. Longer sessions, larger context windows, and frequent tool calls can increase costs much faster than many teams expect.

I've noticed that the conversation is slowly shifting. Instead of asking, "Is this the fastest agent?" teams are starting to ask, "Is it worth the cost?" That means looking beyond impressive demos and measuring things that actually matter, like the cost of resolving an issue, completing a feature, or reviewing a pull request.

Performance is still important, but it's no longer the only metric. Finding the right balance between capability, speed, and cost is becoming just as important. Security is another area that deserves more attention. The same capabilities that allow an agent to review code, identify vulnerabilities, or strengthen an authentication flow can also be misused if the wrong person has access to those tools.

That doesn't mean these agents are unsafe, and it certainly isn't a reason to avoid them. It simply means they should be treated like any other powerful engineering tool.

If an agent has access to your terminal, repository, or production environment, those permissions need to be managed carefully. Giving an agent unrestricted shell access without proper controls isn't very different from giving a new team member broad access on their first day.

As these tools become part of everyday development, security, access control, and auditing need to be considered from the beginning, not added later as an afterthought.

So What Actually Changes for You

If you're thinking about adding one of these tools to your development workflow, or your team has already started using them, but you're still trying to understand where they fit, here are a few lessons I've picked up along the way.

Here are a few things that have stood out to me while working with these tools.

• Look beyond the model. Two coding agents can use the same underlying model and still deliver very different results. What often makes the biggest difference is how they manage context, permissions, available tools, and how they recover when something goes wrong. Don't choose a tool based only on the model it advertises.
• Start with low-risk tasks. Let the agent handle work that's easy to review and validate, like fixing flaky tests, updating dependencies, writing migration scripts, or investigating logs. As your confidence grows, you can gradually trust it with more complex work.
• Document your project's conventions. A simple configuration file that explains coding standards, testing requirements, and project-specific rules can save a lot of time. It helps the agent understand your project from the beginning instead of learning the same lessons in every session.
• Keep an eye on cost. Longer sessions, repeated tool calls, and large context windows can add up quickly. It's worth monitoring how much each task costs so you can balance productivity with efficiency instead of being surprised by your monthly bill.

I don't believe developers are being replaced. What I do think is changing is how we spend our time. Writing code is becoming faster, but reviewing changes, making architectural decisions, understanding business requirements, and ensuring quality are becoming even more important.

In many ways, developers are moving from writing every line of code to guiding the overall process. We define the problem, review the solution, make the final decisions, and step in whenever judgment or experience is needed.

That's a different way of working, and we're still figuring out what it looks like in practice. Whether it's ultimately a better way to build software is something only time will answer. But one thing feels clear already: the role of a software engineer is evolving, and learning how to work effectively with these tools is becoming an important part of the job.