From Management to Orchestration: Leading Engineering Teams in the Age of AI Agents

The shift that's already underway

Most technology leaders are framing the AI coding revolution as a productivity story. GitHub Copilot suggestions accepted, lines of code written, sprint velocity improved. These are real gains and they're measurable. But they're also the least interesting part of what's happening.

The more significant change is structural. We're moving from a model where software is built by a team of humans writing code, to a model where software is built by humans and agents working together, humans setting direction, providing context, reviewing outputs, and making judgment calls; agents doing an increasing proportion of the implementation work.

This is already true at the task level with tools like Copilot and Claude. It's becoming true at the feature level with tools like Devin, Cursor, and GitHub Copilot Workspace. It will become true at the project level. The question isn't whether this is happening (it is) it's what kind of leadership it requires.

Management versus orchestration: what's actually different

Traditional engineering management is built around a set of assumptions: that the people doing the work need clarity on what to build, context about why it matters, feedback on how they're doing, and space to solve problems. A good engineering manager excels at these things across a team of humans.

Orchestration is different in important ways. When your team includes both people and AI agents, the coordination problem changes:

Context is more explicit

A human engineer can ask a clarifying question when a requirement is unclear. They pick up context from the standup conversation, the product review, the offhand comment in Slack. AI agents can't do this. They operate on what they're given. Writing a good prompt or a well-scoped task description isn't just nice to have, it becomes a core engineering skill. Teams that invest in it outperform those that don't.

This changes what the CTO needs to model. The best engineering leaders will be the ones who can write precise, well-bounded problem statements, not vague requirements, but clear descriptions of the problem, the constraints, the success criteria, and the context the agent needs to operate effectively. This is a skill that takes deliberate practice to develop.

Review and judgment move up the value chain

When agents can produce a working implementation in minutes, the bottleneck shifts from "can we write this code?" to "is this the right code?" The review process becomes more important, not less. Engineers who thrive in this environment are those with strong architectural intuition, who can look at an AI-generated implementation and quickly assess whether it's solving the right problem in the right way.

The implication for team building is significant. The ratio of "can implement quickly" to "can review and judge effectively" is changing. Teams that optimise only for implementation speed will generate a lot of code that passes review but isn't architecturally sound. The leaders who understand this will build teams with a different balance of skills.

The failure modes are different

Human engineers fail by misunderstanding requirements, making mistakes, taking shortcuts under pressure. AI agents fail by hallucinating plausible-sounding but incorrect solutions, optimising for the metric they're given rather than the outcome you want, and confidently doing the wrong thing with no signal that anything is wrong. The bugs that slip through an AI-assisted workflow are often harder to spot than traditional bugs, they look correct.

This doesn't mean AI agents are unreliable. It means the engineering process around them needs to account for their specific failure modes. Testing practices, code review norms, and deployment gates all need to evolve to provide appropriate verification of AI-generated code.

What this means for engineering leaders right now

I'm not interested in the version of this argument that says "AI will replace engineers." That's the wrong frame and it leads to the wrong decisions. The more useful frame is: what does excellent engineering leadership look like in 18 months, and what do you need to do now to build towards it?

Develop real AI literacy, fast

Not "knows that AI tools exist" literacy. Not "has tried ChatGPT a few times" literacy. Genuine, hands-on understanding of how these tools work, what they're good at, where they fall down, and how to design workflows around them. This means spending time with the tools, not just reading about them. A CTO who can't personally evaluate the quality of AI-assisted code, or who doesn't understand how an agentic workflow operates, is making significant decisions with significant blind spots.

The most valuable perspective here isn't the product manager's ("this saves us time") or the marketing team's, "AI-native startup." It's the engineering leader's: what does this actually mean for how we build software, and are we building the right practices around it?

Rethink your hiring framework

If a significant portion of implementation work is AI-assisted, the skills you're hiring for change. I'm not suggesting that implementation skill doesn't matter, it does, deeply. Understanding what good code looks like is inseparable from the ability to write it. But the profile of your senior engineers should increasingly include: strong judgment about system design, ability to review AI outputs with discernment, capacity to write clear problem statements, and comfort operating in a high-ambiguity environment where the tools are changing under your feet.

The engineers who will be most valuable in this environment are the ones with deep foundations (people who understand systems at multiple levels of abstraction) combined with the curiosity to engage seriously with how AI tools are changing the craft. That's a specific profile, and it's worth hiring for deliberately.

Invest in your prompting and workflow culture

Most teams treat prompting as an individual skill, everyone figures it out for themselves. This is inefficient and produces wildly inconsistent results. The teams that are getting real leverage from AI agents are treating prompt engineering as a team practice: sharing effective patterns, building internal libraries of well-designed prompts for common tasks, reviewing AI-assisted PRs in a way that captures learnings about what worked and what didn't.

This is the engineering culture analogue of code review practices, pair programming norms, and architectural decision records. It takes deliberate leadership to build, but the teams that build it will consistently outperform those that don't.

Know when not to use agents

Counterintuitively, one of the most important AI leadership skills is knowing when not to use AI. There are categories of work where human judgment, craft, and contextual intuition are still the highest-quality approach, complex system design decisions, security-sensitive implementations, novel algorithm development, and any work where the problem statement itself isn't yet clear. An over-reliance on AI for these tasks produces output that looks plausible but lacks the depth that comes from genuine human engagement with a hard problem.

The engineering leader who can make these distinctions clearly (and build a culture where the team has the judgment to make them too) will consistently make better decisions than the one who applies AI indiscriminately.

Most companies are worrying about AI for the wrong reasons

The conversations I have with founders and boards about AI in engineering tend to cluster around two concerns: "are we falling behind?" and "are we spending too much on AI tools?" Both are worth thinking about. Neither is the most important question.

The more important questions are: Is our engineering process designed to take genuine advantage of AI-assisted development, or are we just bolting tools onto a workflow that was designed for pre-AI engineering? Are we building the judgment in our engineering team to review and evaluate AI outputs effectively? And are we honest about what AI is actually good at, versus where it creates the illusion of productivity without the substance?

The companies that will look back on 2025–2027 as a period of genuine competitive advantage from AI will be the ones that engaged with these questions seriously. The ones that treated it as a checklist ("we adopted Copilot, we added AI to our pitch deck") will have generated a lot of code that works until it doesn't.

What this means for the CTO role specifically

I spend a lot of time in fractional and interim CTO engagements helping companies navigate exactly this transition. The CTO-level questions that come up repeatedly aren't primarily about which AI tools to adopt. They're about:

• How do we build the right engineering culture for an AI-augmented team?
• How do we evaluate the actual quality of AI-assisted code, beyond whether it passes tests?
• How do we maintain architectural coherence when a significant portion of code is generated?
• How do we build a hiring and development culture that prepares engineers for this environment?
• And how do we tell a credible story to the board about our AI strategy, not just "we use it," but "here's how it's changing our engineering capability in a specific, measurable way"?

These are leadership questions, not tool questions. The technology is moving faster than the leadership thinking about it, and in my experience, the gap between companies that get this right and those that don't isn't about the tools they've chosen. It's about the quality of the leadership thinking about how to use them.

The shift from management to orchestration is real, and it's accelerating. The engineering leaders who adapt to it, who develop genuine AI literacy, rethink their hiring and team-building frameworks, and build the right cultural practices around AI-assisted development, will have a meaningful advantage in the next three years. Those who treat it as a tooling question will be left optimising the wrong things.