Hot Takes: What the AI Hype Gets Wrong About Software Engineering Excellence | Harness Blog

‍

Matthew Skelton is the CEO & CTO of Conflux and a featured speaker at this year’s DevOps Modernization Summit. Ahead of our annual summit, Matthew has shared his hot takes on AI, DORA, and the key to successful automation. We’ve summarized his thoughts below – or watch for yourself.

Hot Take #1: You're Using AI Backwards

The AI gold rush is in full swing. Every engineering leader is under pressure to adopt it, measure it, and show ROI on it. But here's the uncomfortable truth most people aren't saying out loud: AI is having a massive impact on software engineering — and it's still not delivering real value. Most engineering teams start with the tool, then hunt for a use case. That's exactly wrong.

"It's really important for us to come back to the idea of starting with the outcomes first, then working back towards understanding how we'd use AI to empower teams to be effective stewards of value, to reduce cognitive load, to shorten time to do things that are not value add," Matthew shares.

Until you flip that equation — outcomes first, tools second — AI is just expensive noise. Know what problem you're solving before you touch the tooling.

Hot Take #2: AI-Generated Code Is Creating More Work, Not Less

Here's one nobody wants to admit at the all-hands: spinning up AI to generate mountains of code isn't always a productivity win. Sometimes it's just a liability transfer.

"We're not going to use AI to generate mountains of code that then has to be retested and where we find all the security bugs. But we can use it to aid teams to focus on their mission more effectively," according to Matthew.

More code means more review, more vulnerabilities, more cognitive load on already-stretched developers, creating a velocity paradox. The teams winning with AI aren't using it to ship more — they're using it to do less of what doesn't matter.

Hot Take #3: Chasing DORA Metrics Is a Trap

DORA metrics are everywhere. Deployment frequency. Lead time. MTTR. Change failure rate. And they're being misused by almost everyone who tracks them.

"DORA metrics are output metrics. We shouldn't be trying to drive them directly. We need to be looking at the fundamental capabilities — improving our capabilities and expect to see the DORA metrics change,” he says.

Optimizing for the metric instead of the capability is how you get teams gaming numbers while software quality quietly deteriorates. DORA metrics are a thermometer — not a treatment plan.

And there's another inconvenient truth: "The context for using DORA metrics is quite specific — it's teams that have end-to-end responsibility for value flow. And lots of organizations are not in that place."

If your teams don't own the full value stream, DORA might just be the wrong measuring stick entirely.

Hot Take #4: Most Engineering Metrics Aren't Safe to Optimize

The metrics you push on need to be "safe to optimize." Choosing the wrong metrics doesn't just give you bad data — it actively drives behavior you don't want.

"The specific metrics you want to choose very much depend on the context that you're talking about. We need people with a high degree of awareness of the operating context to select the right metrics to empower leaders to be able to push those levers," he states.

Cookie-cutter metric frameworks applied without context are how you end up with fast deployments of broken software. Context is everything.

Hot Take #5: Manual Compliance Is Already Dead — You Just Haven't Admitted It Yet

The pace of change in technology, regulation, and market conditions has blown past what any team can manage through manual inspection.

"The rate of change of technology, of regulatory requirements, of market and economic trading relationships — the rate of change of all these things is too fast for us to have manual inspection of things like security compliance and regulatory compliance," Matthew says.

If your compliance and security processes still depend on humans checking boxes at the end of a release cycle, you're not managing risk — you're manufacturing it. Compliance has to be baked into the platform. Full stop.

Hot Take #6: Automating Compliance Without Building Trust Will Backfire

Here's the nuance that gets lost when teams rush to automate compliance into their delivery platforms: the technology is the easy part.

According to Matthew: "This has to be baked in. But it has to be baked in in a way which builds trust with the people who are, in some cases, on the hook for things like security compliance and regulatory compliance — particularly in financial services."

"In addition to baking compliance into a platform, we need to have a social dynamic inside the organization that builds that trust so that people feel confident that what the platform is doing and controlling is what's needed."

You can automate every security gate in your CI/CD pipeline, but if the compliance team doesn't trust the platform, they'll route around it. Governance is a people problem as much as a technology problem. Build the trust, or the automation won't stick.

The Bottom Line

Engineering excellence in 2026 doesn't go to the team with the most AI tools or the prettiest DORA dashboard. It goes to the teams who are ruthlessly honest about where they're generating real value — and brave enough to act on what the data is actually telling them.

Start with outcomes. Pick metrics that are safe to optimize. Automate compliance with trust baked in alongside it. And stop using AI to generate problems you'll have to fix later.

Want more hot takes? Join this year’s DevOps Modernization Summit and hear straight from industry leaders.