Most leaders I talk to have already run the adoption push. They're tracking token usage, and the metrics keep sorting the team into the same three groups: a few power users, a lot of ad hoc users, and the ones who are resistant or barely touch it. These are the numbers boards and C-levels ask for. The metrics are interesting, but they're not what matters, because getting individuals to use AI doesn't lead to effective use. What matters is the system.
Here's my hypothesis: a team where everyone burns tokens like your best engineer is still weaker than one where the agents do the work and people decide what gets built, watch it happen, and accept or reject the result.
I led engineering in enterprise and regulated healthcare for years. These days I run a pipeline of AI agents on client work. Running them every day has changed what I think an engineering team should look like.
When I ask CTOs and VPs of Engineering how they work with agents, the conversation goes to adoption: how they're measuring tokens, where they're seeing usage. What I almost never hear is a description of a system.
The problem you actually have is that there's no system of agents for your team to work with. The question is where human judgment still belongs, not how many engineers you need.
Most orgs design their AI process around the team they already have. That's a reasonable instinct, but it keeps every existing checkpoint alive whether or not it's still useful.
Start from scratch and it comes out differently: people at the front deciding what to build and why, people at the end deciding whether to accept what came out, and somebody watching the process itself instead of standing inside it. I call it bookends. The humans at the bookends aren't working alone either. I collaborate with agents to come up with the design, and I collaborate with agents on the reviews at the other end. What I keep is the decision.
Mine runs this way today. Work goes in as a spec'd issue, agents build in isolated worktrees, an automated review is the only gate in the middle, and I come back at UAT to accept or reject. The middle stays empty, but only for work where I've already decided the risk is acceptable. I still make plenty of calls myself: approach, security, third-party config, what ships to production, to name a few. The system hasn't earned that authority yet.
In a large org this is harder, and the answer isn't copying my pipeline. Those bookends belong to different people: service owners, security, product, whoever answers for the thing in production. The hard part is splitting them up without making accountability fuzzy.
And it breaks. One of my builds stored a client's vendor logins so the system could sign into vendor sites on its own. We worked the approach up front and I signed off on an encrypted store with the key held on the server. It got built, tests passed, it worked. Then came the security review, another collaboration with an agent, and the answers didn't convince me the design was good enough for my customers. The key sat next to the data it protected, a decrypt left no trace, and rotating the key meant re-encrypting every row by hand. That's operational work I'd own forever. I changed my mind. I moved the key to a managed key service and didn't add a human reviewer to the pipeline. The review stayed in the pipeline, and the question it answers hasn't changed: can I honestly tell a client their data is protected.
That's my default now. When something gets through that shouldn't, I change the pipeline first instead of adding another reviewer. A human review goes in when the damage would be hard to undo, or when I can't show the pipeline would catch the same problem next time.
If you want to try this, be specific about where you're headed. Not "we're using AI." Something closer to: agents do the work by default inside limits you've set, and a limit only moves after the process has proven it can hold.
Start with one bug report and run it end to end. Then routine bugs, then small features. Every time you reject a result, the reason tells you what the pipeline needs next.
The decision in front of you isn't which AI tools to buy. It's whether you're improving individual tool use or changing how the work gets done.
If you're further along than this, I want the specifics: where did you remove a human checkpoint and have it hold, and where did you decide one has to stay?