The Work Moved
The tool changed. The problem did not.
An engineer asks an agent to add a bulk export to the billing page.
Ten minutes later, the agent opens a candidate change. The button works against a fixture, and the tests pass. The code arrived before the coffee cooled.
The trusted outcome has not arrived. Someone still needs to check permissions, large accounts, malformed exports, and production behavior. But the part of the work that once produced the clearest evidence of engineering skill now takes minutes.
This should feel like leverage. It can feel uncomfortably close to replacement.
If the agent writes the code, what am I for?
The purpose stayed
Before digital editing, an editor cut film with a blade and joined it with tape. A clean cut demanded precision. Digital tools removed the blade. They did not remove the editor.
The blade mattered, but it was not the purpose. The editor decided where a scene should end, which glance the audience should see, and how long a silence should last. When the instrument changed, more attention moved to those decisions.
The analogy stops there. A coding agent does more than replace a blade. It can propose the cut, explain its choice, and challenge the scene. The analogy cannot promise what happens to software jobs. It shows only that an instrument and a purpose are different things.
The same distinction matters in software. A customer who asks for a billing rule wants correct invoices, not a diff. The company needs someone to understand the rule, protect adjacent behavior, and own the result. Code carries those decisions into the system.
Writing code consumed enough time that the instrument and the job blurred together. Agents now separate them. In bounded, legible, well-tested work, they can make code production dramatically cheaper. Tangled systems, unclear requirements, migrations, and regulated surfaces still resist the shortcut. Delivery did not become cheap merely because a plausible implementation appeared.
The purpose stayed. The center of scarce attention moved.
Pride is not the problem
Attachment to code is understandable. Code is tangible. You can point to a diff and say, “I made that.” Years of practice appear in a clean interface, a careful abstraction, or a bug found three levels below the symptom. Pride in that skill is earned.
Code is also a way of thinking. Writing an unfamiliar path can expose a missing requirement, teach the mechanics of a system, or provide control where an agent adds risk. Sometimes the task is smaller than the explanation needed to delegate it. These are engineering reasons to work directly, not symptoms of fear.
The useful comparison is total time to a trusted outcome. Delegate when the agent shortens that path. Work directly when investigation, learning, control, or verification makes the direct path better.
Pride becomes a constraint only when it decides the method before the evidence does. If every problem must pass through your hands to feel legitimate, you protect a familiar motion at the expense of the result.
Many programmers say they entered the field because they enjoy solving problems. New tools force that claim to become precise. Loving code is fine. Requiring every business problem to preserve the activity you love is different. The craft serves the outcome.
Adaptability moves the boundary
Adaptability does not mean rebuilding your workflow whenever a model launches. It means changing your behavior when the evidence changes.
Adaptable engineers test new tools on real work. They learn which tasks an agent handles reliably, where it loses the thread, and what evidence makes its output trustworthy. They delegate more when the loop is strong and step closer when the requirement is vague, the blast radius is wide, or the result is hard to reverse.
A task that required a careful synchronous session three months ago may now run safely in the background. A model that once failed across a large repository may now navigate it well. A workflow that felt reckless may become ordinary after better tests, clearer component boundaries, and stronger verification.
The boundary will keep moving. Agents already participate in planning, design, review, and diagnosis. Moving upstream from code offers no permanent refuge. Adaptability means revising your role as the tools improve without surrendering the independent judgment needed to challenge them.
Nobody can promise what this does to engineering headcount. Cheaper implementation may reduce some demand, unlock more software, or do both. Task shrinkage alone does not settle the question. What we can say is narrower: engineers who turn changing capabilities into reliable product work give a team more options. System knowledge, failure diagnosis, risk judgment, and customer context help close the gap between a candidate and an outcome.
Two ways to stand still
The transition creates two independent failure modes.
One engineer understands the system but refuses to delegate work an agent can complete safely. Another delegates freely but cannot explain why the result works, where it can fail, or what evidence deserves trust.
Experience can pull people toward the first failure; inexperience can pull them toward the second. Neither belongs to a career level. Tool openness and system understanding are separate qualities.
Good agentic engineering requires both. Increase delegation without losing the model that lets you direct the work, challenge the result, and debug failure. Judge the method by whether it builds and tests that understanding.
Sometimes writing the code is the fastest way to learn. Sometimes reading, tracing, testing, and breaking generated code teaches more. Manual work needs no moral quota. Understanding needs proof.
Follow the work
Implementation remains part of engineering. It can discover the problem, not merely express an answer. But it no longer deserves a fixed place at the center of every engineer’s identity.
On a bounded task, the agent may handle most production; human attention moves to the requirement, evidence, integration, and operation. On an unfamiliar task, writing code may remain the fastest way to think. The boundary changes with the work.
Do not attach your identity to a fixed territory. Attach it to the ability to make something useful and trustworthy. Code remains one powerful way to do that. It is no longer the only way.
The tools will keep changing. Stay with the problem, and follow the work.