Fast or cheap? For most of my career in engineering, speed and quality sat on opposite ends of a seesaw. The "OR" in "fast or cheap" was non-negotiable.

It was expected that pushing for faster releases meant that something in quality would give way. Tightening quality controls meant the schedule slipped. Every engineering leader I know has lived some version of that tradeoff. I expect the same to be true in a lot of industries.

What I'm seeing now, in our own teams and in the wider data, is that the seesaw is starting to level out. Recent research from Ivanti across IT functions found that 63% of IT workers spend less time on repetitive tasks because of AI, and 64% say their teams now catch or fix problems before end users notice. Faster and steadier, at the same time. That result has less to do with tooling budgets than with leadership. When a leader makes daily AI use a plain expectation instead of leaving it to whoever feels like experimenting, the practice spreads and the work changes. Left optional, it tends to stay a novelty.

Where the Recovered Time Goes

The first thing good automation gives an engineering team back is time. IT professionals in the research reported saving more than 312 hours a year — 7.8 full work weeks and counting. The number is headline-worthy, but the hours themselves matter less than what a team chooses to do with them.

Half of IT pros say AI lets them focus on more complex or strategic work, and 45% say it gives them better visibility for decisions. In my experience, redirection doesn't happen on its own. Recovered hours leak away into more of the same unless a leader is deliberate about pointing them somewhere. The capacity AI frees up is only as valuable as the judgment you apply to spending it. (Do you want that free time spent on 17 reviews of the same doc by three different people, or is there a better use? You already know the answer.)

The harder question for engineering leaders isn't whether AI creates capacity, it's how to measure whether that capacity is actually translating into better outcomes. Traditional productivity metrics don't fully capture this shift. Emerging frameworks point toward a more nuanced approach: balancing speed, quality, developer experience, and business impact. In other words, it's not just about doing more work, but enabling teams to deliver the right work, more effectively.

Why Adoption Is a Leadership Job

There's a comfortable assumption that adoption takes care of itself once the tools are good enough. The data says otherwise. The same research shows a wide difference between teams experimenting with AI and teams running it at scale: 89% of IT pros at the most advanced organizations say AI frequently helps them detect issues before users are affected, against 43% at the earliest-stage ones. Advanced individual users save about six hours a week; the least mature save three.

Good tools matter — you can't get those results without capable platforms underneath them, and the gap between a mature platform and a thin one is real. But tools sitting unused change nothing. What moves a team from the low end of that range to the high end is a leader treating daily AI use as the expectation, asking how each part of the work could be done with AI in the loop, and following up on whether it actually is. Code review, test generation and coverage, planning and estimation, incident summaries, surfacing risk early — there's very little in a modern engineering workflow that AI can't take part in. The progress shows up where a team builds that participation into its daily routine and holds itself to it.

Security Has to Get Faster, Not Slower

I can see why so many people worry that moving this fast is an invitation to quality and security problems. It's a fair worry. But slowing down is the wrong response — the better move is to push security earlier and let AI carry more of the load there too. Detecting vulnerabilities before code is submitted, flagging insecure patterns as they're written, prioritizing what to fix by real risk, summarizing incidents so mitigation starts sooner — these are exactly the repetitive, high-volume tasks where AI earns its place. Done well, shifting security left with AI support removes late surprises instead of adding them. Speed and safety stop competing.

That said, faster doesn't mean unsupervised. The research is a useful reality check: 68% of IT pros have personally seen AI produce a hallucination with potential operational impact. Most caught it before it caused harm; some didn't. The teams handling this well decide in advance which calls AI can make on its own — restarting a failed service, applying a routine patch — and which ones still need a human, like a system-wide change or an emergency response. Trust in these systems is something you define on purpose, not something you assume.

Bring the Whole Team Along

You might recognize at least one of the patterns in the data from seeing it yourself. I know I've witnessed it: if you're already an advanced AI user, you're also the most eager to keep learning. Intent to upskill runs at 86% among the most advanced users, against 37% among basic users. Enthusiasm and capability feed each other.

That's an opening for leaders. The engineers who are already fluent are your best teachers. Pairing them with people earlier in the curve and giving them room to pass on what they've figured out, spreads capability faster than any formal program — and it builds the kind of team where AI fluency is normal rather than exceptional. The goal is a whole team that treats these tools as part of the job, with fluency spread widely instead of concentrated in a few specialists.

I'm not talking about some sort of moonshot here. More than half of IT organizations are already running AI on a broad or business-critical scale, and they expect AI to handle nearly half of operations within 18 months. My advice to any engineering leader is to build the habits, the guardrails and the skills now, while the work is still manageable, rather than waiting for permission or for the technology to settle. Set speed and solidity to coexist, and you stop having to choose between them.