Web Directions Year round learning for product, design and engineering professionals

Why AI Coding Tools Might Not Make the Slightest Difference

The excitement around AI coding tools is genuine and widespread. GitHub Copilot, Claude, ChatGPT for code—they're undeniably impressive. They can generate working code in seconds. They reduce boilerplate. They help people code in languages they barely know. So naturally, organizations are investing heavily. The pitch is simple: faster coding means faster shipping means competitive advantage.

But what if the assumption is wrong? What if the bottleneck in software delivery was never actually the speed of writing code?

This is Jason Cornwall's central challenge to the conventional thinking. After years at SEEK focused on what actually makes engineering teams effective, he's observed something that most productivity discussions miss: the constraints on shipping software run far deeper than keystroke speed.

Consider where time actually goes in a typical software project. Writing code itself is maybe 20% of the work. The rest is figuring out what to build, talking to stakeholders, understanding requirements, designing systems that work at scale, reviewing code, debugging in production, maintaining and updating legacy systems. Code writing is almost not the bottleneck.

The real constraints are elsewhere. Unclear requirements that lead to rework. Poor system design that creates cascading problems later. Inadequate testing that ships bugs to production. Knowledge silos where only one person understands a critical system. Deployment pipelines so fragile they take hours to run. Teams that don't talk to each other effectively. Technical debt that slows everything down.

An AI coding tool that makes you 5x faster at writing code doesn't help any of these problems. If you're shipping the wrong thing faster, that's worse, not better. If your system architecture is fundamentally broken, faster code generation just means you reach the breaking point faster.

This isn't an argument against AI coding tools. It's an argument for looking honestly at where the actual constraints are. Some teams might genuinely benefit from faster code writing. Others won't see any difference—and some might even get worse outcomes if faster tools mean less careful thinking about what they're building.

The uncomfortable truth is that improving engineering effectiveness is boring work. It's about better communication between engineers and product. It's about investing in developer experience infrastructure so people aren't fighting tools. It's about writing tests, documenting decisions, paying down technical debt. It's about organizational structure and how information flows. None of this is glamorous, and none of it gets disrupted by better coding AI.

The organizations that see real gains from AI coding tools will be the ones that already have reasonable answers to these other problems. They've got clear requirements, sound architecture, good testing practices, and strong communication. For them, AI tools are a genuine acceleration. But if those foundations are weak, faster code writing just accelerates in the wrong direction.

There's an implicit assumption in most productivity discussion that moving faster is always good. But speed in the wrong direction is waste. And the things that actually slow down software delivery—unclear thinking, poor design, organizational siloes, technical debt—can't be solved with a faster keyboard.

Jason Cornwall is bringing this grounded, unsentimental perspective to AI Engineer Melbourne 2026 on June 3-4, asking the questions that organizations need to answer before betting on AI coding tools to transform their engineering effectiveness.