All posts
Newsletter·13 July 2026·No. 3·8 min read

Code Agents: When AI Takes Center Stage in the Project

By Pierre Wilmet

Not so long ago, AI in software development mostly resembled enhanced autocomplete. You'd write a function, and the assistant would suggest what came next. You'd ask a question, and it would answer. Convenient, sometimes brilliant, sometimes dangerously overconfident — like many tools that end up in production.

However, a new phase is taking shape: code agents.

A code agent doesn't just suggest a line of code or explain an error. It reads a codebase, understands a request, modifies multiple files, runs tests, corrects its own errors, opens a pull request, or documents its work. It no longer just responds: it takes action.

This is a major shift, as it moves AI from the role of a conversational assistant to that of an operational contributor.

From assistant to colleague

A traditional code assistant supports the developer while the developer remains in control. It completes a line of code, suggests a function, explains an error message, or generates a unit test.

A code agent, on the other hand, works differently. It is given a broader objective: "fix this bug", "add this feature", "update this dependency", "improve this page", "find out why this test is failing."

From there, the agent breaks down the problem. It reads the relevant files, looks up references, identifies dependencies, proposes a plan, modifies the code, executes commands, observes errors, starts over — and then produces a result.

It's this loop that changes everything: observe, act, verify, correct.

Where autocomplete speeds up a local action, the agent takes charge of an entire task. It doesn't replace software development, but it profoundly changes its granularity. The developer no longer controls the process line by line: they can control it by intent.

What's the situation today?

All major AI development tools are repositioning themselves around this idea.

GitHub Copilot now offers a "coding agent" capable of taking an issue and generating a pull request. OpenAI presents Codex as an agent that handles development tasks end-to-end, from routine fixes to complex refactorings. Anthropic positions Claude Code as an agent capable of reading a codebase, modifying files, and executing commands in the terminal or IDE.

This evolution is not just a marketing ploy. It reflects a broader transformation: models are reasoning more effectively over time, IDEs are more connected, protocols like MCP facilitate access to tools, and companies are seeking to automate repetitive tasks in the software development cycle.

In other words, AI is no longer confined to a chat box. It's making its way into Git, the terminal, issue tickets, CI, and pull requests. That's useful. It's also exactly the kind of statement that should raise an eyebrow with any security team.

The strengths of code agents…

Code agents really shine when it comes to well-defined tasks.

They help fix simple bugs, add tests, migrate repetitive APIs, rename elements, update documentation, enforce coding conventions, explain an existing codebase, or prepare a draft pull request.

Their strength lies in their mechanical patience. A human quickly gets tired of modifying twenty nearly identical files; an agent doesn't complain. Which is unfair, since it really should.

They're also invaluable for exploring a project. A developer arriving at a codebase might ask: "Where is authentication handled?", "Which files are involved in this workflow?", "Which parts might be affected if I modify this function?" A good agent then acts as a guide through a complex system.

Finally, agents speed up the transition from idea to prototype. For a small feature, an internal interface, or a well-defined change, they quickly produce an initial version. Not necessarily perfect, but often sufficient to kick off a review.

… And their weaknesses

Problems arise as soon as the task becomes ambiguous.

A developer may write code that compiles without understanding the intended outcome. They may address the symptom rather than the cause. They may add a special condition instead of fixing a fragile architecture. They may produce a solution that is locally correct but globally flawed.

This is one of the major pitfalls: the agent gives the impression of making progress. It modifies files, runs tests, and opens a pull request. Visually, it appears to be working. But activity does not equal value.

Recent benchmarks confirm this: agents are progressing quickly, but remain far from full autonomy in complex industrial environments. On realistic mobile tasks drawn from a production iOS codebase, even the best-performing configurations achieve only a 12% success rate. On 5G tasks, models often diagnose bugs correctly, but resolution rates remain between 10% and 30%. The limitation is clear: understanding a problem and solving it properly are two different things.

Agents also struggle with implicit dependencies. An experienced human knows that a change in one module can break business behavior, an internal convention, or an undocumented edge case. The agent, on the other hand, relies heavily on what it is given: tests, logs, documentation, context, examples, and project rules.

Without the right context, it may deliver a very precise answer to the wrong problem. The tech world loves this kind of unnecessary elegance.

What happens to the developer in all of this?

So the question isn't whether agents will "replace developers." It's a more interesting one: what happens to development work when part of the execution can be delegated?

The developer spends more time defining the problem, providing the right context, breaking down tasks, setting constraints, reviewing results, verifying impacts, and deciding what to integrate.

They are less the author of the code and more the supervisor of systems capable of producing it.

This requires new skills: knowing how to formulate a good request, knowing how to spot a bad yet plausible solution, knowing how to design tests that truly capture the intent, knowing how to limit an agent's permissions, and knowing how to review an AI-generated PR with more skepticism than a human-generated one — which is saying quite a lot.

Development becomes more like an orchestra. Multiple agents can work in parallel on distinct tasks. But someone still has to decide what music to play, verify that the instruments don't contradict each other, and prevent the trombone from blasting its way into production.

The importance of testing

With code agents, tests are no longer just a safety net. They become a control interface.

A developer iterates much more effectively when tests clearly indicate what is failing. A vague request like "improve this module" is difficult to verify; a request accompanied by acceptance criteria, expected tests, and concrete examples provides the developer with a much more robust feedback loop.

That's why the companies that will derive the most value from agents won't necessarily be the ones that buy the best tool, but those that already have good software hygiene: reliable tests, fast CI, minimal documentation, clear conventions, understandable architecture, and identified ownership.

Agents do not eliminate bad practices. They amplify them.

A clear codebase becomes easier to evolve. A confusing codebase becomes easier to quickly degrade.

Risks to manage

  • Security: an agent that can read secrets, execute commands, or modify files must be restricted. Its permissions must be explicit, traceable, and tailored to the task.
  • Technical debt: an agent may resolve an issue with a superficial fix. Without thorough review, the team accumulates code that works today but will become difficult to maintain tomorrow.
  • Loss of understanding: if developers accept changes without understanding them, the team gradually loses intellectual ownership of its own system. The code exists, but no one really knows why it's written that way anymore.
  • Cost: agents consume far more tokens than a simple chatbot. They read context, generate code, rerun tests, make corrections, and start over. Their costs must be tracked, especially when they run for long periods or in parallel.

What needs to be put in place?

To adopt code agents intelligently, two extremes must be avoided.

The first: banning them entirely out of fear of risk. That's tantamount to ignoring a major evolution in software development.

The second: giving them access to everything and hoping "it'll be fine." This strategy has already shaped much of the history of modern cybersecurity.

A sound approach starts with limited tasks: documentation, testing, minor fixes, repetitive migrations, isolated refactorings, and code analysis. Teams then gradually expand the scope based on observed quality.

We also need to establish simple rules: no critical changes without human review, no unnecessary access to confidential information, no writing to production, traceability of actions, mandatory testing, clear descriptions of changes, and validation by a code manager.

Finally, we need to measure. How much time was saved? How many PRs were accepted? How many bugs were introduced? What is the cost per successful task? What portion of the work requires human correction? Without measurement, the agent is nothing more than a black box with a modern interface.

And what about the future?

Code agents do not spell the end of the developer. Rather, they herald the end of a certain type of repetitive, localized, and mechanical work.

Value is shifting toward understanding the system, formulating requirements, test quality, architecture, code reviews, security, and product decisions.

Good news for teams that already know how to build clean code. Bad news for those who were hoping that AI would magically compensate for a lack of methodology.

Code agents will likely become a standard part of the development environment, just like Git, CI, or linters. At first, they impress us. Then they become integrated. Finally, we can't imagine how we ever managed without them — which is usually the exact moment they become truly dangerous.

So the question isn't: "Should we use code agents?" The real question is: "What tasks are we willing to delegate to them, with what safeguards, and while retaining what level of human responsibility?"

Get the next edition in your inbox

Now and then, our notes on AI, developer tooling and the craft of good work. No spam, unsubscribe anytime.