How an AI-native consulting team is structured when agents write the code

There’s a fair bit written now about what happens to the consulting pyramid when agents do the work. The pieces I’ve read predict a new shape, an obelisk or an hourglass, and they get there from a framework rather than from anything they’ve watched happen. My view comes from inside client teams and from my own practice, where agents have been merging to production on my property portal since January. The shape is worth talking about, because it’s already showing up in the teams I work with.

The ticket writer became the most valuable person in the room

On one engagement there was a person whose job was splitting up the work for the developers. They wrote the cards with everything in them: the sample requests and responses, the event contracts, all of it. I’d been watching the tickets they were producing, and at some point I had to have an uncomfortable conversation with them. By the time they’d done what they were doing, Codex could pick it up. They were doing 90% of the work required to deliver the ticket.

It’s the same role they’d always been doing, splitting the work up for developers, but the developers are just AI agents now. Once the spec is done, it’s nigh on instantaneous to get pull requests out, ten or twenty minutes. The bottlenecks become the review and checking and the specifications.

The first thing I suggested was getting them access to the code and a coding agent, so I could show them how much of the work they were actually doing. Their skill set had just become the most valuable skill set out there, and not only on that team. That’s the bit I think a services firm should sit with. The person who can take a messy client conversation and turn it into a fully described ticket is now doing most of the delivery.

Move engineers with product sense into semi-product roles

The obvious consequence is that you almost need more product managers. But it can’t fall to product to write every PRD either, because then product just becomes the bottleneck. One product person writing every ticket and every PRD for a whole team of developers, that’s just not a ratio that works anymore.

What I’ve been telling teams is that anyone in engineering with product savvy should be quietly retraining into semi-product. You still have to drive it heavily. You have to know the subject, the customers and the architecture, and that’s why it has to come from engineering and not just from hiring more PMs. Pretty much everyone that’s a developer needs to take on some level of product ownership to smooth the bottleneck out again.

The catch is that a large number of developers don’t have any experience in the discovery process. I’m vastly generalising, but the vast majority of software engineers are ticket takers and deliverers, and if anything isn’t defined within the ticket, they break. They don’t think about the way the customers are going to experience it. And the fully described ticket is exactly the part the AI can deliver. I’ve written more about the spec becoming the work in what changes for an engineering team when agents write the code.

Give everyone around the team the tools

The other thing I’m seeing is roles blending. A lot of what I hear from the people I talk to is a hybridisation of roles, where product and design can do tasks that traditionally needed a software engineer.

Pretty much everybody around a team, even if they’re not a developer, should have a Cursor subscription. Design should be using Lovable, v0 or Bolt at a very minimum. There’s no reason to send copy changes off to an engineer. The engineering manager or the QA, anyone who finds it, can prompt Cursor and it’ll create a pull request. It doesn’t need command line knowledge, it’s just a text editor with some stuff inside. Every person around the team should have GitHub access at some level, and that makes a huge difference.

For a consultancy that changes who you staff and how you think about them. The delivery lead, the QA and the designer aren’t just sitting around the engineers anymore, they’re opening pull requests too. What keeps that safe is the build, not the job title, which is how I run it on my own portal (how I let coding agents merge to production).

Who struggles: skeptics, weak architects, and juniors

One company I was talking to said that when they’re hiring now, it’s a big topic in the interview process: how willing people are to use AI and where they are in the journey. It’s not a hard no if they’re not far along, but if they’re completely skeptical and unwilling to engage with it, that’s probably a problem. I agree with that. People can be skeptical in a mature way, maybe it’s not there yet, and that’s fine. They can’t be completely against it. AI is here to stay, right?

There have definitely been devs really worried about their skills atrophying and about getting their next job. I disagree with them, because I think the next job is going to require it. Firms already say they’re short of skills. In Kantata’s 2026 State of the Professional Services Industry report, a vendor survey of 200 professional services leaders run by Censuswide, 68% cite skills shortages as a major barrier, up from 45% the year before. The skills that count are moving as well.

The second group is less obvious. I’ve had at least one developer who was absolutely not doing a good job with AI coding, and I tend to see that as a deficiency in the developer. He wasn’t making it follow the codebase’s conventions, and what he let it build wasn’t at all the way the rest of the codebase was architected. In some ways AI coding lets you identify the developers who aren’t all that strong architecturally. The AI is amazing at refactoring, but somebody has to know what shape it should end up in.

Then there are juniors, and I’ll be blunt. I would not want to be a junior at the moment, because they’re unhireable. It’s an existential problem for software development, really. The pyramid has always leaned on juniors learning by doing the work, and that’s the work the agents are doing now. I don’t have a fix for that.

Judgment and taste are what’s left

It’s really important to recognise that software engineering is not going to be the same. When it’s watched, it writes code as well as good coders do, and the code it spits out is probably what you’d have written anyway. There’s no way a human typing on a keyboard can compete with that. The job moves up and becomes orchestration and taste.

Taste is more than architecture. A lot of it is keeping it architecturally on track, but it’s also the overall ethos of how the project looks and how it runs over a long period. I firmly believe engineers are still required, not least for the judgment and the taste and the verification. But a lot of those skills have been lost over the years, and that’s what I’d be hiring and training for if I were shaping a team around agents. An engineer can be as unhappy about it as they want, but it won’t change their reality.

The consultant’s side of this is the part I know best. I’ve come and gone from the same client several times now. I’m not an employee, I’m a consultant, and when I’m not needed any more the core team can take it from here. Part of my role is making sure the people around me are upskilled. That part of the job hasn’t changed, it’s just what they need to learn that’s different now.

If you want to work through this with your own team, that’s what team enablement is for.