The coding agent has left the autocomplete box. It now opens the issue, inspects the repository, changes the files, runs the tests and presents the result for review. That sounds like a faster way to type. It is actually a new way to organise responsibility.
The unit of work is no longer a line of code
GitHub now describes its Copilot coding agent as something that can take an issue, work in a temporary development environment and return a pull request. OpenAI built the Codex app around several agents working in parallel, each carrying its own task and context. The important shift is not that either system produces code. We have had code generation for years. It is that the systems can hold a piece of work long enough to cross several boundaries without waiting for a person at each one.
That changes the useful unit of engineering. A prompt is too small. A pull request may already be too late. The real unit is a bounded delegation: a goal, the evidence available to pursue it, the permissions it may exercise and the checks that decide whether its work can move. Teams that treat an agent as a quicker keyboard will get quicker code. Teams that redesign the delegation will change throughput, review and the shape of the job itself.
SourcesGitHub: Improve a project with Copilot coding agent · OpenAI: Introducing the Codex app
Cheap production makes judgment expensive
When code becomes abundant, the scarce thing moves upstream. It becomes the ability to specify a useful change, expose the right constraints and recognise a plausible mistake before it becomes a durable one. Review cannot remain a ceremonial look at a green diff. The reviewer needs to understand what the agent was asked, what it inspected, what it assumed and which tests could have failed to notice the problem.
This is where the cheerful story about removing toil meets its invoice. An agent can multiply small misunderstandings with perfect patience. It can also make a mature engineering system visible: repositories with executable conventions, narrow permissions, observable tool calls and tests that describe actual risk become easier for both people and machines to navigate. The codebase starts revealing whether the organisation knew what it meant in the first place.
The IDE is becoming a control surface
The familiar editor was built around one person manipulating one file at a time. Agentic work puts pressure on that arrangement. The useful screen is less likely to be a wall of generated text and more likely to be a place for routing tasks, comparing evidence, inspecting changes and intervening at the moment judgment matters. The centre of gravity moves from composition to supervision.
That does not make engineers optional. It makes some versions of engineering less defensible. Knowing the syntax while ignoring the system was always a fragile bargain; agents simply expose it. Architecture, product sense, debugging, security and the ability to turn a vague complaint into a testable change become more valuable because they are the parts that determine whether the machine is moving in the right direction.
Ownership survives automation
The cleanest fiction in software has always been that authorship and accountability are the same thing. Large systems disproved that long before agents arrived. Agentic engineering makes the separation impossible to ignore. A machine may author the patch; a person or team still owns the decision to merge, deploy and live with it.
The next engineering culture will not be defined by how much code an agent can emit. It will be defined by how confidently a team can explain what the agent was allowed to do, why the result deserves trust and who is still holding the wheel when the dashboard goes quiet.
The hard question is no longer whether agents can write production code. They can. The hard question is whether our engineering systems can absorb that new supply without turning speed into fog.
