The coding agent and the new assembly point of development

In May 2025, Microsoft announced Copilot's transition into agent mode: the tool can now receive tasks, write code, run tests, and open pull requests autonomously. This is not just an extension of autocomplete - it is a different level of development automation.

I deliberately avoid the word "revolution." This step followed predictably from what has been happening with agent frameworks over the past few months. But predictability does not reduce practical importance. For companies that commission or run software development, the decision point has shifted.

What exactly changed

Previously, Copilot helped a developer write code faster - offering completions, generating functions from descriptions, explaining unfamiliar code. The developer stayed in control: they formulated the task, accepted or rejected suggestions, ran tests, made commits.

A coding agent changes that distribution. The agent receives a task formulated in natural language - for example, "add validation for this field" or "fix this error from the test report" - and independently goes through the entire cycle: writes the changes, runs tests, verifies the tests pass, opens a pull request for review.

The developer shifts from writing code to formulating tasks and reviewing results.

What this means for companies

This change is important to understand correctly because it has consequences in several directions.

Speed of iteration. Tasks that used to require several hours of a developer's time can be done faster. This does not mean the team can be reduced - it means the same team can handle a larger volume of tasks or focus on harder problems.

Codebase quality. The agent works only as well as the codebase and test coverage are good. If tests are weak or the code is tangled, the agent will make changes that formally pass tests but introduce problems. Investment in tests now pays off not only as protection against regressions but as a precondition for the agent to work well.

Task management. If an agent can pick up tasks from the backlog and execute them independently, the quality of task formulation becomes critical. A vague task produces a vague result that takes longer to review and fix than it would have taken to do it properly in the first place.

Security. An agent that writes code and makes commits works with access to the repository. This requires rethinking what permissions it has and how the review process is organised before merging. Automated code without review is a new risk vector.

What has not changed

The fundamental questions of software development are not solved by automating execution.

Architectural decisions - what to build and how - remain with people. The agent executes specific, bounded tasks well. It does not answer the question "how should this system be structured."

Defining what is needed - product thinking, user understanding, prioritisation - remains outside the scope of agent automation.

Questions for a manager

If you manage a development team or commission development:

1. How well are tasks formulated in the backlog - specifically enough for an agent to act on them?
2. What is the test coverage, and are there critical areas with no tests?
3. How is the review process organised - is there a risk that automated code could reach production without inspection?
4. How will we measure whether the agent is working in our favour, rather than simply adding complexity?

These questions do not require immediate changes. They require honest answers before decisions about tooling are made.