Unsurprisingly, there are a lot of strong opinions on AI assisted coding. Some engineers swear by it. Others say it’s dangerous. And of course, as is the way with the internet, nuanced positions get flattened into simplistic camps where everyone’s either on one side or the other.

A lot of the problem is that people aren’t arguing about the same thing. They’re reporting different experiences from different vantage points.

I’ve sketched a chart to illustrate the pattern I’m seeing. It’s not empirical, just observational.

The yellow line shows perceived usefulness of AI coding tools. The blue line shows the distribution of engineering competence. The green dotted line shows what the distribution would look like if we went by how experienced people say they are.

Different vantage points

Look at the first peak on the yellow line. A lot of less experienced and mediocre engineers likely think these tools are brilliant. They’re producing more code, feeling productive. The problem is they don’t see the quality problems they’re creating. Their code probably wasn’t great before AI came along. Most code is crap. Most developers are mediocre, so it’s not surprising this group is enthusiastic about tools that help them produce more (crap) code faster.

Then there’s a genuinely experienced cohort. They’ve lived with the consequences of bad code and learnt what good code looks like. When they look at AI-generated code, they see technical debt being created at scale. Without proper guidance, AI-generated code is pretty terrible. Their scepticism is rational. They understand that typing isn’t the bottleneck, and that speed without quality just creates expensive problems.

Calling these engineers resistant to change is lazy and unfair. They’re not Luddites. They’re experienced enough to recognise what they’re seeing, and what they’re seeing is a problem.

But there’s another group at the far end of the chart. Highly experienced engineers working with modern best practices – comprehensive automated tests, continuous delivery, disciplined small changes. Crucially they’ve also learned how work with AI tools using those practices. They are getting productivity without impacting quality. They’re also highly aware typing is not the bottleneck, so not quite as enthusiastic as our first cohort.

Interestingly, I’ve regularly seen sceptical senior engineers change their view once they’ve been shown how you can blend modern/XP practices with AI assisted coding.

Why the discourse is broken

When someone from that rare disciplined expert group writes enthusiastically about AI tools, it’s easy to assume their experience is typical. It isn’t. Modern best practices are rare. Most teams don’t deploy to production multiple times per day. Most codebases don’t have comprehensive automated tests. Most engineers don’t work in small validated steps with tight feedback loops.

Meanwhile, the large mediocre majority is also writing enthusiastically about these tools, but they’re amplifying dysfunction. They’re creating problems that others will need to clean up later. That’s most of the industry.

And the experienced sceptics – the people who can actually see the problems clearly – are a small group whose warnings get dismissed as resistance to change.

The problem of knowing who to listen to

When you read enthusiastic takes on AI tools, is that coming from someone with comprehensive tests and tight feedback loops, or from someone who doesn’t know what good code looks like? Both sound confident. Both produce content.

When someone expresses caution, are they seeing real problems or just resistant to change?

The perception gap – that green dotted line versus reality – means we’re consistently misjudging who has the experience and practices to make reliable claims. And when you layer on the volume of hype around AI tools, it becomes nearly impossible to filter for signal. The loudest voices aren’t necessarily the most credible ones. The most credible voices – experienced engineers with rigorous practices – are drowned out by sheer volume from both the mediocre majority and the oversimplified narratives that AI tools are either revolutionary or catastrophic.

We’re not just having different conversations. We’re having them in conditions where it’s genuinely hard to know whose experience is worth learning from.

Some argue that even if the current AI boom leads to an overbuild, it might not be a bad thing – just as the dotcom bubble left behind the internet infrastructure that powered later decades of growth.

It’s a tempting comparison, but the parallels only go so far.

The dotcom era’s overbuild created durable, open infrastructure – fibre networks and interconnects built on open standards like TCP/IP and HTTP. Those systems had multi-decade lifespans and could be reused for whatever came next. Much of the fibre laid in the 1990s still carries traffic today, upgraded simply by swapping out the electronics at each end. That overinvestment became the backbone of broadband, cloud computing, and the modern web.

Most of today’s AI investment, by contrast, is flowing into proprietary, vertically integrated systems rather than open, general-purpose infrastructure. Most of the money is being spent on incredibly expensive GPUs that have a 1-3 year lifespan due to becoming obsolete quickly and wearing out under constant, high-intensity use. These chips aren’t general-purpose compute engines; they’re purpose-built for training and running generative AI models, tuned to the specific architectures and software stacks of a few major vendors such as Nvidia, Google, and Amazon.

These chips live inside purpose-built AI data centres – engineered for extreme power density, advanced cooling, and specialised networking. Unlike the general-purpose facilities of the early cloud era, these sites are tightly coupled to the hardware and software of whoever built them. Together, they form a closed ecosystem optimised for scale but hard to repurpose.

That’s why, if the AI bubble bursts, we could just be left with a pile of short-lived, highly specialised silicon and silent cathedrals of compute – monuments from a bygone era.

The possible upside

Still, there’s a more positive scenario.

If investment outruns demand, surplus capacity could push prices down, just as the post-dotcom bandwidth glut did in the early 2000s. Cheap access to this kind of compute might open the door for new experimentation – not just in generative AI, but in other high-compute domains such as simulation, scientific research, and data-intensive analytics. Even if the hardware is optimised for GenAI, falling prices could still make large-scale computation more accessible overall. A second-hand market in AI hardware could emerge, spreading access to powerful compute much more widely.

The supporting infrastructure – power grid upgrades, networking, and edge facilities – will hopefully remain useful regardless. And even if some systems are stranded, the talent, tooling, and operational experience built during the boom will persist, as it did after the dotcom crash.

Without openness, the benefits stay locked up

The internet’s long-term value came not just from cheap capacity, but from open standards and universal access. Protocols like TCP/IP and HTTP meant anyone could build on the same foundations, without permission or platform lock-in. That openness turned surplus infrastructure into a shared public platform, unlocking decades of innovation far beyond what the original investors imagined.

The AI ecosystem is the opposite: powerful but closed. Its compute, models, and APIs are owned and controlled by a handful of vendors, each defining their own stack and terms of access. Even if hardware becomes cheap, it won’t automatically become open. Without shared standards or interoperability, any overbuild risks remaining a private surplus rather than a public good.

So the AI boom may not leave behind another decades-long backbone like the internet’s fibre networks. But it could still seed innovation if the industry finds ways to open up what it’s building – turning today’s private infrastructure into tomorrow’s shared platform.

Update: This post has received quite a lot of attention on HackerNews. Link to comments if you enjoy that sort of thing. Also, hi everyone 👋, I’ve written a fair bit of other stuff on AI, among other things, if your interested.

This is one of the most important pieces of writing I’ve read on AI – and that’s not the kind of thing I say lightly. If you’re leading in a business right now and looking at AI adoption, it’s worth your full attention.

Duncan Brown’s Team dynamics after AI isn’t about model performance or the usual surface-level debates. It’s about the potential for AI to quietly reshape the structure and dynamics of teams – how work actually gets done.

He shows how the promise of AI enabling smaller teams (“small giants”) and individuals taking on hybrid roles can lead organisations to blur boundaries, remove friction and assume they can do more with less. But when that happens, you lose the feedback loops, diversity of perspective – and start to erode the structural foundations that quietly hold alignment together and make teams effective.

He also points to something I’ve been saying for a while – that AI doesn’t necessarily make us more productive, it can just make us busier. More output, more artefacts, more noise – but not always more value.

Here lies the organisational risk. The system starts to drift. Decisions narrow. Learning slows. More artefacts get produced, but they create more coordination and interpretation work, not less. The subtle structures that keep context and coherence together begin to thin out. Everything looks efficient – right up until it isn’t.

A bit like what happened with Nike: they optimised for the short-term and de-emphasised the harder, slower work that built long-term brand strength. It seemed to work at first, but the damage wasn’t visible until it was too late and it’ll now take them years to build back.

It’s also written by someone who’s been deep in the trenches – leading engineering at the UK Gov’s AI incubator, so not your usual ill-informed AI commentator.

And as a massive Ian MacKaye/Fugazi fan and a lapsed skateboarder, it honestly feels like another me wrote it.

Essential reading. It’s a long read – get a brew and a quiet 15 minutes.

The idea of LLMs as a new abstraction layer for software development keeps coming up. On the surface it sounds appealing. Just as compilers turn source into binaries, AI could turn prompts into systems. You store the prompts, they become the source of truth, AI generates the code and the code just becomes an artefact.

Let’s assume, for the sake of the argument, things like non-determinism and hallucination are solved. There is still a big problem.

Complexity.

Software is never static. Requirements change, and each change adds complexity. Even the best engineers in the world struggle with this – whole disciplines around refactoring, code composition and architecture exist to contain it, and still complexity piles up.

Unless we reach some form of AI superintelligence, well beyond anything today, AI will run into the same problems, probably faster. Entropy builds up, not down.

The only way I can think of around that would be to regenerate the entire codebase (or at least large parts of it) from prompts each time, like a compiler rebuilding from source.

However, that just hits another wall.

But by my rough calculations, a mid-size 500k LOC codebase, with today’s LLMs and compute, would take days to build and cost thousands.

Software development depends on feedback loops measured in seconds or minutes, not hours or days.

And this points to a natural physical law – processing information always carries an energy cost – you can’t avoid it, only shift it.

in this case, from human cognitive effort to machine compute cycles. And today, the machine version would be far less efficient.

tl;dr You can’t beat the 2nd law of thermodynamics.

The recent DORA 2025 State of AI-Assisted Software Development report suggests that, today, only a small minority of the industry are likely to benefit from AI-assisted coding – and more importantly, avoid doing themselves harm.

The report groups teams into seven clusters to show how AI-assisted coding is shaping delivery. Only two – 6 (“Pragmatic performers”) and 7 (“Harmonious high-achievers”) – are currently benefitting.

They’re increasing throughput without harming stability – without an increase in change failure rate (CFR) i.e. they’re not seeing significantly more production bugs, which would otherwise hurt customers and create additional (re)work.

For the other clusters, AI mostly amplifies existing problems. Cluster 5 (Stable and methodical) will only benefit if they change how they work. Clusters 1–4 (the majority of the industry) are likely to see more harm than good – any gains in delivery speed are largely cancelled out by a rise in the change failure rate (CFR), as the report explains.

The report shows 40% of survey respondents fall into clusters 6 and 7. Big caveat though: DORA’s data comes from teams already familiar with DORA and modern practices (even if not applying them fully). Across the wider industry, the real proportion is likely *half that or less*.

That means around three-quarters of the industry are not yet in a position to realistically benefit from AI-assisted coding.

For leaders, it’s less about whether to adopt AI-assisted coding, and more about whether your ways of working are good enough to turn it into an asset, rather than a liability.

I don’t think people fully appreciate yet how agentic AI use cases are restricted by what Simon Willison coined the “lethal trifecta”. His article is a bit technical so I’ll try and break it down in more layman’s terms.

An AI agent becomes very high risk when these three things come together:

• Private data access – the agent can see sensitive information, like customer records, invoices, HR files or source code.
• Untrusted inputs – it also reads things you don’t control, like emails from customers, supplier documents, 3rd party/open source code or content on the web.
• The ability to communicate externally – it has a channel to send data out, like email, APIs or other external systems.

Each of those has risks on its own, but when you put all three together it creates a structural vulnerability we don’t yet know how to contain. That’s what makes the trifecta “lethal”. If someone wants to steal your data, you have no effective way to stop them. Malicious instructions hidden in untrusted inputs can trick the agent into exfiltrating (sending out) whatever private data it can see.

If you broaden that last point from “communicate externally” to “take external actions” (like sending payments, updating records in systems, or deploying code) the risk extends even further – not just leaking data, but also doing harmful things like hijacking payments, corrupting information, or changing how systems behave.

It’s all a bit like leaving your car running with the keys in the ignition and hoping no one crashes it.

Where this matters most is in the types of “replace a worker” examples people get excited about. Think of:

• an AI finance assistant that reads invoices, checks supplier sites, and then pays them
• a customer support agent that reads emails, looks up answers on an online system and then issues refunds
• a DevOps helper that scans logs, searches the web for known vulnerabilities or issues, and then pushes config changes

All of those tick all three boxes – private data, untrusted input, and external actions – and that makes them unsafe right now.

There are safer uses, but they all involve breaking the loop – for example:

• our finance bot only drafts payments for human approval
• our support agent can suggest, but doesn’t issue refunds
• our DevOps helper only runs in a sandbox (a highly isolated environment)

Unless I have got this wrong, until we know how to contain the trifecta, the glossy vision of fully autonomous agents doesn’t look like something we can safely build.

And it may be that we never can. The problem isn’t LLM immaturity or missing features – it’s structural. LLMs can’t reliably tell malicious instructions from benign ones. To them, instructions are just text – there’s no mechanism to separate a genuine request from an attack hidden in the context. And because attackers can always invent new phrasings, the exploit surface is endless.

And if so, I wonder how long it will take before the penny drops on this.

Edit: I originally described the third element of Simon’s trifecta as “external actions”. I’ve updated this to align with Simon Willison’s original article, and instead expanded on the external actions point (partly after checking with Simon).

Tech gets the headlines, org change gets the results

What if most of the benefit from successful technology adoption doesn’t come from the technology at all? What if it comes from the organisational and process changes that ride along with it? The technology acted as a catalyst – a reason to look hard at how work gets done, to invest in skills, and to rethink decision-making.

In fact, those changes could have been made without the technology – the shiny new tech just happened to provide the justification. Which raises the uncomfortable question: if we know what works, why aren’t we doing it anyway?

This is a bit of a thought piece, a provocation. It would be absurd to say new technologies have no benefit whatsoever (especially as a technologist). However it’s worth bearing in mind, that despite decades of massive investment, and wave after wave of new technologies since the 1950s (each time touted as putting us on the cusp of “the next industrial revolution”), I.T. has delivered only modest direct productivity gains (hence the Solow Productivity Paradox).

What the evidence does show, overwhelmingly, is that technology adoption only succeeds when it comes hand-in-hand with organisational change.

So perhaps it wasn’t really the technology all along – perhaps it was the organisational change?

The diet plan fallacy

People often swear by a specific diet – keto, intermittent fasting, Weight Watchers. But decades of research in nutrition shows that the core mechanism is always the same: consistent calorie balance, exercise, and sustainable habits. ¹ The diet brand is the hook. The results come from the same behaviour changes.

Successful digital transformations, cloud adoptions, ERP rollouts, or CRM programmes, the tech often get the credit when performance improves. But beneath the surface, perhaps the real gains come from strengthening organisational foundations – many of which could have been done anyway. Processes are simplified, decision-making shifts closer to the front line, teams gain clearer responsibilities, and skills are developed.

It just happens that the diet book – or the new platform – created the focus to do it.

What the research tells us

Technology only works when it comes with organisational change

Economists have long argued that IT delivers value only when combined with complementary organisational change. Bresnahan, Brynjolfsson and Hitt found that firms saw productivity gains when IT adoption came alongside workplace reorganisation and new product lines – but not from IT on its own.²

Brynjolfsson, Hitt and Yang went further, showing that the organisational complements to technology – such as new processes, incentives and skills – often cost more than the technology itself. Though largely intangible, these investments are essential to capturing productivity gains, and help explain why the benefits of IT often take years to appear. ³

Tech without organisational change delivers little benefit

Healthcare provides a good example. Hospitals that simply digitise patient records, without redesigning their workflows, see little improvement. But when technology is paired with process simplification and Lean methods, the results are very different – smoother patient flow, higher quality of care, and greater staff satisfaction. Once again, it’s the organisational change that unlocks the value, not the tool alone. ⁴

Anecdotally, I have seen it time and time again in my career. Most digital transformation attempts fail. Countless ERP rollouts, that not only overran, but ended up with orgs in a worse situation that they started – sub optimal processes now calcified in systems that are expensive and hard to change.

Better management works without new tech

Bloom et al introduced modern management practices into Indian textile firms – standard procedures, quality control, performance tracking. Within a year, productivity rose 11–17 percent. Crucially, these gains came not from new machinery or IT investment, but from better ways of working. In fact, computer use increased as a consequence of adopting better management practices, not as the driver. ⁵

Large-scale surveys across thousands of firms show the same pattern: management quality is consistently linked to higher productivity, profitability and survival. The practices that matter are not about technology, but about how organisations are run – setting clear, outcome-focused targets, monitoring performance with regular feedback, driving continuous improvement, and rewarding talent on merit. These disciplines also enable more decentralised decision-making, empowering teams to solve problems closer to the work. US multinationals outperform their peers abroad not because they have better technology, but because they are better managed. ⁶

AI: today’s diet plan – and why top-down continues to fail

AI adoption is largely failing. Who could have imagined? Despite the enormous hype, most pilots stall and broader rollouts struggle to deliver. McKinsey’s global AI survey finds that while uptake is widespread, only a small minority of companies are seeing meaningful productivity or financial gains.⁷

And those that are? Unsurprisingly, they’re the ones rewiring how their companies are run.⁸ BCG reports the same pattern: the organisations capturing the greatest returns are the ones that focus on organisational change – empowered teams, redesigned workflows, new ways of working – not those treating AI as a technology rollout. As they put it, “To get an AI transformation right, 70% of the focus should be on people and processes.” ⁹ (you may well expect them to say that of course).

Yet many firms are rushing headlong into the same old mistakes, only this time at greater speed and scale. “AI-first” mandates are pushed from the top down, with staff measured on how much AI they use instead of whether it creates any real value.

Lessons from software development

The DevOps Research and Assessment (DORA) programme ¹⁰ has spent the past decade studying what makes software teams successful. Its work draws on thousands of organisations worldwide and consistently shows that the biggest performance differences come not from technology choices, but from practices and processes: culture, trust, fast feedback loops, empowered teams, and continuous improvement ¹¹.

Cloud computing was the catalyst for the DevOps movement, but you could have been doing all of these things anyway without any whizzy cloud infrastructure.

Now GenAI code generation is exposing similar. All the evidence to date is suggesting productivity and quality gains only appear when teams already have strong engineering foundations: highly automated build, test and deployment and frequently releasing small incremental changes. Without these guardrails, AI just produces poor-quality code at higher speed ¹² and exacerbates downstream bottlenecks ¹³.

And none of this is really new. Agile and Extreme Programming largely canonised all the practices advocated for by the DevOps movement more than 20 years ago – themselves rooted in the management thinking of Toyota and W. Edwards Deming in post-war Japan. They’ve always been valuable – with or without cloud, with or without AI.

Maybe (hopefully) GenAI will be the catalyst for broader adoption of these practices, but it begs the question: if teams have to adopt them in order to get value from AI, where is most of the benefit really coming from – the AI tools themselves, or the overdue adoption of ways of working that have proven to work for decades? Just as with diet plans, the results come from habits that were always known to work.

Tech gets the credit, but does it deserve it?

The headlines almost always go to the technology. It’s more exciting – and easier to draw clicks – to talk about shiny new tools than the slow, unglamorous work of redesigning processes, clarifying roles, and building management discipline. Much of what passes for “transformation success” in the press is little more than PR puff, often sponsored by the vendors who sold the system or the consultants who implemented it (don’t even get me started on the IT awards industry).

Its the same inside organisations too. It’s far more palatable to credit the expensive system you just bought than to admit the real benefit came from the hard graft of changing how people work – the organisational equivalent of eating better and exercising consistently.

The fundamentals that always matter

Looking back across the evidence, there’s a clear pattern, The same fundamentals show up time and again:

• Clarity of purpose and outcomes – setting clear, measurable goals and objectives that link to business results, not tool rollout metrics.
• Empowered teams and decentralised decisions – letting people closest to the work solve problems and take ownership.
• Tight feedback loops – between users and builders, management and operations, experiment and learning.
• Continuous improvement culture – fixing problems iteratively as they emerge.
• Investment in people and process – developing skills, aligning incentives, and embedding routines and management systems that build lasting and adaptable capability.

None of these depend on technology. They’re just good, well proven, organisational practices.

So maybe it wasn’t the technology that delivered the transformation at all? Maybe the real gains came from the organisational changes – the better management, the clearer goals, the empowered teams – changes that could have been made without the technology in the first place? The shiny new tool just gave us the excuse.

The obvious question then is: why wait for the latest wave of tech innovation to do all this?

1. Effect of Low-Fat vs Low-Carbohydrate Diet on 12-Month Weight Loss in Overweight Adults. Gardner et al 2018 ↩︎
2. Information Technology, Workplace Organization and the Demand for Skilled Labor: Firm-Level Evidence ↩︎
3. Intangible Assets: Computers and Organizational Capital ↩︎
4. Electronic patient records: why the NHS urgently needs a strategy to reap the benefits. April 2025 ↩︎
5. Does management matter? Evidence from India, Bloom et al 2012 ↩︎
6. Measuring and explaining management practices across firms and countries. Bloom et al 2007 ↩︎
7. McKinsey: The state of AI: How organizations are rewiring to capture value ↩︎
8. McKinsey: Seizing the agentic AI advantage ↩︎
9. BCG: Wheres the value in AI Adoption ↩︎
10. DORA ↩︎
11. DORA Capability Catalog ↩︎
12. GitClear AI Copilot Code Quality Report 2025 ↩︎
13. Faros AI: AI Engineering Report July 2025 ↩︎

In 1987, economist Robert Solow observed: “You can see the computer age everywhere but in the productivity statistics.” This became known as the Solow Productivity Paradox.

Despite huge investment in IT during the 1970s and 80s, productivity growth remained weak. The technology largely did what it promised – payroll, inventory, accounting, spreadsheets – but the gains didn’t show up clearly in the data. Economists debated why: some pointed to measurement problems, others to time lags, or the need for organisations to adapt their processes. It wasn’t until the 1990s that productivity growth really picked up, which economists put down to wider IT diffusion combined with organisational change.

We’re seeing something very similar with GenAI today:

• Massive investment
• As yet, very little evidence of any meaningful productivity impact
• Organisations trying to bolt GenAI onto existing processes rather than rethinking them

But there’s also an additional wrinkle this time – a capability misalignment gap.

In the 70s–80s, IT, whilst crude compared to what we have today, was generally capable for the jobs it was applied to. The “paradox” came from underutilisation and lack of organisational change – not because the tech itself failed at its core promises.

With GenAI, the technology itself isn’t yet reliable enough for many of the tasks people want from it – especially those needing precision, accuracy or low fault tolerance. For business-critical processes, it simply isn’t ready for prime time.

That means two things:

1. If it follows the same path as earlier IT, we could be a decade or more away from seeing any meaningful productivity impact.
2. More importantly, technology alone rarely moves the productivity needle. Impact comes when organisations adapt their processes and apply technology where it is genuinely fit-for-purpose.

Yet another study showing that AI-assisted coding isn’t resulting in any meaningful productivity benefits.

Faros AI just analysed data from 10,000+ developers across 1,255 teams. Their July 2025 report: The AI Productivity Paradox confirms what DX, DORA and others have already shown: GenAI coding assistants may make individual developers faster, but organisations are not seeing meaningful productivity gains.

Some of the findings:

• Developers using AI complete 21% more tasks and merge 98% more PRs
• But review times are up 91%, PRs are 154% bigger, and bugs per dev up 9%
• Delivery metrics (lead time, change failure rate) are flat
• At the company level: no measurable impact

Why? Because coding isn’t the bottleneck.

The report itself says it: “Downstream bottlenecks cancel out gains”. Review, testing, and deployment can’t keep pace, so the system jams.

Exactly the point I made in my recent post – only a small amount of overall time is spent writing the code, the majority is queues and inspection. Speeding up coding just piles more into those already bloated stages.

It isn’t really a paradox. It’s exactly what queuing theory and systems thinking predict: speeding up one part of the system without fixing the real constraint just makes the bottleneck worse.

“Typing is not the bottleneck” – illustrated. If you’ve followed me for a while, you’ll know how often I say this – especially since the rise of AI-assisted coding. Here’s an example.

This is a cumulative flow diagram from Jira for a real development team. It shows work only spends around 30% of its time in the value-creation stage (Development). The other 70% is taken up by non-value-adding activities – labour and time-intensive manual inspection steps such as code reviews, feature and regression testing, and work sitting in idle queues waiting to be reviewed, tested and released.

This pattern is the norm. This example isn’t even a bad case (they at least look to be shipping to prod once or twice a week).

If you increase the amount of work in Development – whether through adding more devs, or because of GenAI coding – it increases the amount of work going into all the downstream stages as well. More waiting in idle queues, more to test, bigger and more risky releases, most likely resulting in slower overall delivery.

It’s a bit like trying to drive faster on a congested motorway.

The solution is Continuous Delivery – being able to reliably and safely ship to production in tiny chunks, daily or even multiple times a day – one feature, one bug fix at a time. Not having to batch work up because testing and deployment have such a large overhead.

If your chart looks anything like this, you’ll need to eliminate most, if not all, non-development bottlenecks – turn the ratio on its head – otherwise you’ll probably not see any producivity benefits from GenAI coding.