Why To Keep Hiring Engineers Even When Your Code Is AI-Assisted

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.”​