A few years ago, the senior engineers on my team wrote code for most of the week. Today they write it for maybe 15% of the week. The other 85% is something that looks a lot like engineering management.
The job title on the posting has not changed. The work completely has.
The Shift Nobody Is Naming Yet
Software engineering is in the middle of a role transformation that nobody seems to be naming clearly. The engineer who ships the most value used to be the one who could write the most quality code in a week. That person still exists, but they are no longer the top performer on the teams I lead.
The top performer now is the engineer who can orchestrate four or five autonomous agents through a week of coordinated work. They review agent PRs at speed without rubber-stamping. They design the skills and context the agents load. They set budgets, catch systemic issues, and intervene when an agent goes off track.
This person writes less code. They ship more work.
What Actually Changed
Let me be specific about what has changed and what has not.
What changed:
- Where leverage comes from. Before, leverage came from writing better code faster. Now it comes from running more agents on more problems simultaneously.
- What fills the day. Implementation time dropped. Review, orchestration, skill design, and monitoring filled the gap.
- What senior means. Senior used to mean "writes the best code and mentors juniors." It still means that, but it also means "orchestrates a small agent org well."
- The feedback loop. Instead of writing code and catching your own mistakes, you watch several agents work in parallel and intervene when things drift.
What did not change:
- Technical judgment matters more, not less. You are reviewing five PRs a day instead of one. You cannot rubber-stamp.
- Architecture and system design matter more. Agents can implement features. They are mediocre at architectural decisions.
- Debugging skills matter more. When something breaks in a multi-agent system, you need to trace through multiple traces, contexts, and decisions.
- Your taste matters more. Agents will happily produce mediocre work that compiles and passes tests. You are the quality bar.
The New Skills
A year ago I would have put AI engineering skills in a separate bucket. Now they are core. The skills I find the strongest engineers on my team using every day:
1. Context engineering
Setting up the context an agent loads for a task. Not prompt engineering in the narrow sense. Understanding what information the agent needs, in what structure, and excluding everything else so it stays focused.
2. Skill framework design
Designing reusable behavioral guardrails for agents. "When fixing a bug, first reproduce it. Then write a failing test. Then fix it." These are skills you write once and every agent loads them.
3. Budget discipline
Per-agent cost caps. Token economics. Rate limit awareness. Knowing when an agent is going in circles and burning money versus making progress.
4. Agent observability
Reading traces, interpreting cost metrics, detecting hallucinations, identifying when an agent's work quality drops. This is new ops work and almost no tooling exists for it yet.
5. High-speed code review
Reviewing PRs from five agents a day means you cannot read every line the way you used to. You develop pattern recognition for what to deep-read and what to skim. Get this wrong and you ship bugs at scale. Get it right and you ship features at scale.
6. Intervention judgment
Knowing when to let an agent keep going versus when to stop and redirect. Agents can get stuck in loops. You develop a sense for when to trust the process and when to course-correct.
The Parts Nobody Talks About
Two things I did not expect when this shift started rolling out across my team.
The first: it is exhausting in a different way. Writing code for eight hours is mentally taxing in a known pattern. Reviewing PRs from multiple agents an hour, switching contexts, making intervention decisions under time pressure, that is a different kind of mental load. The fatigue looks more like running a small team than being an individual contributor.
The second: the work is more creative, not less. Removing the mechanical task of typing out code you already designed in your head frees up cognitive space for the interesting problems. The best engineers now spend more time thinking about architecture, trade-offs, and system design than they did when they were the ones banging out the code.
What This Means For Your Career
If you are a senior IC, this is already your job. The industry has not agreed on this yet, but the best senior engineers I work with are already operating this way. If you resist it, you get left behind. If you embrace it, your output multiplies.
If you are earlier in your career, the skills above are the skills to develop. The ability to write a clean function still matters. The ability to orchestrate agents writing clean functions matters more.
If you are a hiring manager, this changes what you look for. The engineer who can orchestrate agents through a complex feature in three days is worth more than the engineer who can ship the same feature themselves in two weeks.
The job title will catch up eventually. For now, the title is still Senior Engineer. The work is something new.