Changing Roles
How the engineer's job changes when agents do the typing. The role shifts from writing code to directing, reviewing, and owning outcomes -- which reshapes the skills that matter, how people are hired, how performance is judged, and what it even means to be a software engineer.
The first two themes describe what agents do and what they run on. This one is about the people. When the typing is largely automated, the scarce work moves to the ends -- deciding what to build and proving it works -- and the engineer's day reorganizes around direction, review, and judgment rather than authorship.
That shift ripples outward. It changes which skills are worth building, how newcomers should learn the craft, what hiring should screen for, and how individual performance is fairly measured once "lines of code" means nothing. The patterns here trace those consequences -- honestly, including where the change is real and where it is still being figured out.
Three roles get collapsed into one "AI" buzzword: traditional ML/AI (training models), AI engineering (building AI into products -- mostly integration), and agentic coding (doing software development with agents). The further you move from ML toward agentic coding, the less day-to-day ML depth the work needs -- embeddings, RAG, and prompt engineering become useful background, not the main focus.
PeopleAs agents do the typing, the engineer's job shifts from authoring code to directing it -- scoping work, choosing approaches, reviewing output, and steering several agents at once. The unit of work moves up a level: from writing functions to specifying intent and judging results.
PeopleWhere orchestration is the role shift, collaboration is the per-task question: how closely do you work with the agent? Clarity and risk set the dial -- unclear or high-stakes work keeps you in the loop (pairing, planning and triaging together), while clear, low-risk work is handed off to run. The skill is routing each task to the right mode.
PeopleThe gap between code that exists in your codebase and code anyone actually understands. As agents generate faster than humans can read, understanding -- not typing -- becomes the bottleneck, and the debt compounds: each unreviewed change raises the cost of the next one.
PeopleAs writing code gets cheap, the scarce skill moves to deciding what to build. The AI product engineer owns the outcome, not just the implementation -- pairing engineering with product judgment, taste, and direct contact with the user problem.
PeopleHow do you learn to engineer when the agent writes the first draft? The craft doesn't disappear -- it inverts: fundamentals like systems thinking, debugging, and judgment matter more, even as syntax matters less. The risk is skill atrophy, especially for juniors; the upside is an always-on tutor that can make the craft more accessible. Which wins depends on how deliberately you teach.
PeopleWhen anyone can produce plausible code with an agent, the coding screen stops predicting much. Hiring shifts toward what agents don't supply -- judgment, systems thinking, taste -- and toward integrators, not ML researchers. Teams redesign the screen (AI-allowed rounds, workflow observation) and read proxies like open-source work and tool maturity, since no one yet has years of agentic-coding experience.
PeopleOnce an agent can emit thousands of lines on command, output metrics measure the wrong thing -- and pull-request and code volume only inflate with AI. Performance has to be re-anchored on outcomes and leverage: problems solved, quality shipped, and how much a person improves the shared system (context, harness, evals) and lifts the team -- not the volume of code produced.