The tools are already good at the work in front of them. Give an agent a clear task and enough context and it will write something reasonable. The harder questions show up on large projects with large teams, where the code is one part of a much bigger system of decisions, and two pieces are still missing.
The first is memory. Most of the effort right now goes into steering the agent and making sure it has the right context. There is no agreed upon approach for what a developer should carry between sessions, or for what a team should share across them. Without that, context goes missing and the agent fills the gap with its own assumptions. In the worst case it makes a decision that is quietly wrong and nobody catches it until later. In the better case you spend your day reminding it of requirements it should have known from the start.
The second is end to end testing the agent can run on its own. This is a security and capability problem for the tooling around the agent. To verify its own work it needs the same kind of access an employee has, enough to deploy, to test, and to reach a production-like environment, with room to escalate when a task calls for it. That runs straight into the principle of least privilege, and at a large company with heterogeneous access systems and a dozen deployment workflows, granting that access safely is hard.
Solve both and the job changes shape. The agent remembers what the team has decided and can prove its changes work in something close to production. At that point the only artifact the engineer writes is the specification, and everything downstream of it becomes the machine’s problem.