Corey Ercanbrack is CTO at Vasion, leading the AI-native transformation of a cloud-native platform under FedRAMP High.
In Q1 2025, 21% of my company’s qualified code was AI-assisted. Twelve months later, it was 62%. Qualified means the roughly 80% of what we ship that our tooling can measure. During that same period, our engineering organization grew by 19%.
That growth was planned before any of this started, and AI would have given me a defensible reason to cancel it. I kept the plan because of my conviction, which the year’s data later backed up: We had produced more code, and our customers reported fewer defects, but delivery speed also slowed.
Every CTO is being asked whether AI means fewer engineers, usually by someone holding a budget. But, based on my experience, this question optimizes for expense over opportunity. Here’s a better question: What can the engineers you already have now take on?
Adoption will look different than expected.
We gave engineers access to new models and tools early. I expected resistance to break along seniority lines. Instead, every manager on my team folded AI into their work almost immediately, but engineers took a year.
Some of that gap was due to concerns about risk, but risk doesn’t explain all of it.
Delegation is a skill leaders have already built: set context, judge output and verify before you trust. Individual contributors, however, have spent years getting excellent at doing the work themselves. Asking them to direct an agent is asking for a change in what they’re paid to be good at.
To facilitate adoption, leaders should nurture the skills that make managers early adopters across the team. Many engineers will perceive this shift as “I write code” to “AI writes code,” so it’s crucial that leadership frames it as an opportunity where engineers don’t think “I have to use AI,” but “I get to use AI.”
Don’t wait for adoption to happen on its own. Name champions, hire a head of AI and run internal boot camps. After 22 boot camps, our AI contributors went from 42% to 72%, faster than we could have hired for it.
Address every metric that matters.
Over the 12-month period, pull requests per developer rose 44%, and completed work items per developer rose 49%. Both counts are per developer and include only substantive changes, so neither the added headcount nor easier work-splitting inflates them.
Quality didn’t pay for that speed. Customer-reported defects per work item fell 29%. In May, we shipped the largest release in company history, more than 50 new features in six months. Without AI, we estimate it would have been closer to 30.
Then there’s the number I care about most: The time from a finished change to that change merging into the product rose by 38%.
Growing your capacity to produce code faster than your capacity to judge it constrains delivery. The lesson here is that by measuring output alone, you might call the year a win and miss the metrics that need your attention.
Writing code and engineering software are not the same job.
AI makes code cheaper to produce, but not cheaper to judge. Every change still has to be understood by someone who knows the system, and we were generating changes faster than we could evaluate them.
Our system is multi-tenant and immutable, cloud-native across six regions, running under FedRAMP High authorization. An agent can fix the symptom a customer reported and leave the cause of the problem in place. It can write a correct query and forget the tenant boundary. It can produce code that is right at test volume and wrong in production. It can finish work without emitting the audit event that makes it provable.
Even if each update passes review as correct code, each can be a different kind of wrong.
That’s where the budget question from earlier comes into play. In my experience, humans are still the only ones who know what a change touches beyond the change itself.
More code doesn’t reduce the need for experienced engineers. Often, it manufactures more of the work only experienced engineers can do.
That is why we only slightly altered our hiring plan to use the open roles to bring on senior engineers. You cannot solve this problem by adding reviewers.
Planning agents can help make the plan good enough to trust before anything gets built, and then the system can flag only where the result diverges. But it’s still too early to know if that closes the gap. Solve it, and the constraint moves upstream to keeping architecture in a state agents can work in. That is engineering work, too.
One caveat. We run under FedRAMP High and build for some of the largest enterprises in the world, so review landing as our constraint is no surprise. A team without that exposure may reach a different answer about headcount.
Regardless, AI moves work toward judgment, and that is the part you cannot buy in bulk.
One of my principal architects held out the longest, and his skepticism was earned. He had consistently watched AI-generated SQL pass review and behave differently at scale. The engineer running the tool did not understand the problem well enough to see the answer was wrong.
The principal architect is now one of our heaviest AI users. He doesn’t see AI as a code generator. For him it’s a grilling partner that he can argue an architecture decision with and that can ask questions he had not considered.
His turnaround taught me the biggest lesson: The better the intelligence gets, the more it matters that the human directing it understands the problem.
The mistake is treating AI as a cheaper way to do yesterday’s work. Ask what becomes scarce when code gets easy, then hire and measure for that. AI did not make our hiring plan unnecessary, but it told us to spend it on judgment.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?