There’s a conversation happening in every engineering org right now, whether it’s out loud or just quietly in people’s heads: what exactly is my job now?
For a long time, the path was well understood. Junior developers write code, senior developers write better code and review it, tech leads set patterns and mentor, and engineering managers coordinate people and delivery. Everyone had a lane. AI has blown that model up, not by replacing people, but by fundamentally changing where the value is.
The engineers and leaders who are thriving right now aren’t the ones who are best at writing code. They’re the ones who are best at directing, reviewing, and shaping the work that AI agents are producing.
From Producer to Director
Here’s the mental shift that took me a while to internalise: your job is no longer to be the best implementer. It’s to be the best decision-maker about what gets implemented and why.
Think of it like the difference between being a craftsman and being an architect. A craftsman’s value is in their ability to produce the work with their hands. An architect’s value is in their ability to understand the brief, envision the outcome, and communicate that clearly enough for others (or now, agents) to execute it faithfully.
The coding work itself hasn’t disappeared. There’s more of it than ever. But the constraint has shifted from how fast can humans write code to how well can humans define, review, and guide what agents produce. That changes everything about what a strong engineering leader looks like.
Architecture, Strategy, Vision: Now the Whole Job
When an agent can scaffold a feature in minutes, the bottleneck becomes the quality of what you gave it to work from. Vague requirements produce vague code. Poorly considered architecture decisions, when handed to an agent that will faithfully implement them at scale, produce large amounts of faithfully bad code.
This is where Engineering Managers and tech leads are finding renewed purpose. Spending time deeply on:
- System design and architecture: The decisions that are hard to reverse, that constrain everything downstream, that require experience and judgment.
- Product strategy: What should we actually be building? What’s the simplest version of this that delivers value?
- Technical vision: Where is the codebase going in 6 months? What patterns should agents be following? What should they never do?
- Context documents: More on this below, but writing the documentation that puts agents in the right headspace is now a core leadership skill.
The engineers who are leaning into this are finding that their impact is multiplied. One person with a clear vision and a well-configured agent workflow can ship what used to take a team.
Controlling Agents Through Context
One of the more interesting things about working with AI coding agents (tools like GitHub Copilot, Cursor, and others) is that they’re heavily influenced by the context you give them. This has spawned a new type of document that’s becoming a standard part of engineering workflows: the AGENTS.md file, custom instruction files, and project-scoped prompt documents.
These documents are essentially your communication layer with your agents. A well-written AGENTS.md might define:
- The coding style and conventions for the project
- Which patterns to use and which to avoid
- How to structure components, name things, and organise files
- Testing expectations
- Scope boundaries: what the agent should and shouldn’t touch
Tech leads who are writing these documents well are discovering something important: it forces you to articulate things that usually live only in your head. The conventions that you’d catch in a code review but never wrote down anywhere. The architectural decisions that are obvious to you but invisible to a new team member, or an agent.
There’s also a feedback loop here. When an agent produces something that misses the mark, the right response isn’t just to fix the output. It’s to update your context documents so the agent gets it right next time. This is a fundamentally different kind of engineering leadership work, and it’s a skill that takes practice.
Linear and the Agent-Friendly Backlog
Project management tooling is catching up fast. Linear has become the tool of choice for a lot of engineering teams, and it’s easy to see why when you start working in an AI-native way.
Where a traditional Jira ticket might be a title and two sentences, Linear has nudged teams toward writing richer, more structured issue descriptions. And now with AI agents that can be pointed at a Linear ticket to execute on, the quality of that ticket has a direct impact on the quality of what gets built.
The mental model is shifting from assign this to a developer to can an agent execute on this ticket as written? If the answer is no (too vague, missing acceptance criteria, or lacking technical context), that’s a signal the issue needs more work before it goes anywhere.
For engineering managers and leads, this creates a new responsibility around backlog hygiene. Grooming a ticket used to be about making sure a human developer had enough information to get started. Now it’s about making sure that information is structured clearly enough that an agent can run with it autonomously, with a human reviewing the output rather than doing the work line by line.
Some teams are even going further, using agents to draft tickets from higher-level briefs, then having leads review and refine those before they’re executed. The human judgment is still in the loop, just at a different stage.
The Review Layer Is the New Craft
If you’re an engineering leader and you’re worried that AI is devaluing your expertise, I’d push back on that. What’s changing is where you apply it.
The code review is becoming more important, not less. When agents are generating code, the review is where human expertise catches the subtle misalignments: the technically correct implementation that misses the intent, the approach that works for this feature but creates problems for the next one, the security concern that the agent didn’t have enough context to see coming.
This requires:
- Deep familiarity with the codebase and its constraints
- Clear communication about why something isn’t right, not just that it isn’t
- The ability to update context documents so the same mistake doesn’t happen again
- Trust in your own judgment about when to approve and when to push back
These are the skills that separate a great engineering leader from a mediocre one, and they haven’t changed. They’ve just been relocated to a new part of the workflow.
The Leaders Who Are Struggling
It’s also worth being honest about where the friction is. Not everyone is finding this transition easy.
The engineers who built their identity around being great implementers — who took pride in hammering out clean code quickly — are having to find a new source of professional satisfaction. That’s genuinely hard. The craft is real and it matters, and being asked to step back from it to direct others (or agents) doing it can feel like a demotion even when it isn’t.
There’s also a learning curve to working effectively with agents that a lot of people underestimate. It’s not as simple as asking a question and accepting whatever comes back. It requires developing intuition for when to trust the output, when to scrutinise it, and how to give feedback that actually improves future results.
The leaders who are investing time in building this intuition are pulling ahead. The ones who are treating AI tools as a productivity shortcut but not changing how they think about their role are finding the benefits much more limited.
Getting Started
If you’re an Engineering Manager or tech lead who’s still finding your footing with this shift, a few practical starting points:
- Write an
AGENTS.mdfor one of your projects. Even if it’s imperfect, the act of writing down your conventions is valuable regardless of agents. - Try completing a full feature with an agent, staying in the director seat. Define the work clearly, review what it produces, iterate through feedback. Notice where you struggle to articulate what you want.
- Audit your Linear (or equivalent) backlog. Would an agent have enough context to work from these tickets? Where are the gaps?
- Share the experience with your team. The best teams right now are learning together, sharing prompt patterns that work, updating shared context docs based on what agents get wrong.
The shift is real and it’s happening fast. The good news is that the skills that make a great engineering leader (clear thinking, good judgment, strong communication, technical depth) are exactly what this new way of working demands. They just need to be applied in new places.
The Engineering Agent Manager is already here. The question is whether you’re ready to step into that role.