--- author: "[[Bob Marshall]]" tags: - blogpost publish: 2026-04-29 sources: - https://flowchainsensei.wordpress.com/2026/04/29/zero-none-not-one-why-no-organisation-is-truly-ready-to-adopt-ai-in-software-development/ --- ## Zero. None. Not One: Why No Organisation Is Truly Ready to Adopt AI in Software Development _The hype is deafening. The readiness is not. or Is your organisation yet another rusty old car?_ Every week, another analyst firm publishes a report declaring that some percentage of organisations — 34%, 61%, 78%, take your pick — are ‘AI-ready’. Chief information officers announce transformation programmes. Vendors promise 10x developer productivity. Engineering leaders book their spots at the nearest AI summit, clutching a GitHub Copilot licence like a golden ticket. And yet, if we are being honest — properly, uncomfortably honest — the answer to the question ‘how many organisations are ready to successfully adopt AI in their software development function?’ is the same number that shows up when you ask how many software projects come in on time, on budget, and on scope. Zero. --- ### The Readiness Illusion Let us start with what ‘ready’ actually means. Not ‘has purchased a tool’. Not ‘has run a pilot with three enthusiastic engineers who were going to be productive regardless’. Not ‘has a slide in the board deck with the word _AI_ on it’. Ready means: the organisation has the technical foundations, the cultural posture, the process maturity, and the measurement frameworks to absorb AI tooling and translate it into durable, compound business value — rather than a short-lived productivity spike followed by a new class of technical and organisational debt. By that definition? Nobody is there. --- ### The Six Gaps Nobody Wants to Talk About #### 1. The Data and Codebase Gap AI coding tools are only as good as what they are working with. The models that power these tools were trained on clean, public, well-structured code. Your codebase was built over fifteen years by forty different teams, three of whom no longer exist, using frameworks that were deprecated twice, with documentation that was ‘temporarily’ skipped and never revisited. AI does not magically understand your domain. It autocompletes confidently into your most dangerous corners. It will suggest a refactor that looks plausible and is subtly, catastrophically wrong — and your developers, moving faster because ‘AI is helping’, will merge it anyway. Organisations with legacy codebases are not getting a productivity boost from AI. They are getting a faster way to make existing problems worse. #### 2. The Process Maturity Gap AI amplifies what already exists. If your development processes are solid — clear requirements, rigorous code review, strong test coverage, meaningful CI/CD pipelines — AI has something real to accelerate. If your processes are a loose collection of habits and heroics stitched together by a few key people, AI accelerates the chaos. Most organisations fall squarely in the second camp. Test coverage remains depressingly low across the industry. Code review is inconsistent. Requirements are vague. Technical debt backlogs are treated as a holding pen for problems that will never actually get fixed. AI does not fix process debt. It inherits it — and then runs with it at speed. #### 3. The Skills and Judgement Gap Here is the uncomfortable paradox at the heart of AI-assisted development: the developers who benefit most from AI are the ones who need it least. Senior engineers with deep domain knowledge, strong mental models, and sharp instincts for when code ‘smells wrong’ — they can use AI as a genuine force multiplier. They know when to trust the suggestion and when to override it. They can spot the confident-but-wrong output because they already understand the problem space. Junior developers, whom organisations are increasingly tempted to equip with AI tools as a substitute for mentorship, are in a different position entirely. They do not yet have the judgement to validate what the model produces. They accept plausible-looking answers. They build on shaky foundations quickly, which is worse than building on shaky foundations slowly. The industry is not investing in the human expertise required to critically supervise AI output. It is investing in AI output, and hoping the supervision takes care of itself. It will not. #### 4. The Culture Gap This one is the most overlooked, and probably the most decisive. AI adoption in software development does not just change what developers do — it changes what it means to be a developer. It challenges deeply held professional identities, disrupts established team dynamics, and surfaces anxieties that most engineering cultures have no language for and no appetite to address. In organisations where engineers are evaluated on individual output, AI creates perverse incentives: pass off generated code as your own work, inflate velocity metrics, and avoid asking the questions that would reveal you do not fully understand what the AI produced. In organisations where blame culture is the norm, nobody wants to be the person who accepted an AI suggestion that caused an incident. The tool gets quietly abandoned, and leadership wonders why adoption stalled. Then there is the trust problem. Experienced engineers often resist AI tools not out of Luddism but out of legitimate professional scepticism — they have seen enough ‘revolutionary’ tools come and go to be wary, and they know that the most dangerous code is the code that looks right but is not. That scepticism is healthy. But in cultures that frame AI adoption as a directive rather than a conversation, that scepticism gets labelled as resistance, the people who raised valid concerns get sidelined, and the organisation loses the very voices most capable of supervising the technology wisely. AI adoption also changes team dynamics in ways nobody plans for. When some developers are using AI heavily and others are not, you get asymmetric velocity, inconsistent code quality, and a slow fracturing of shared norms around what ‘good’ looks like. Pair that with the fact that most organisations have not updated their code review standards, their definition of done, or their expectations of engineers to account for AI-assisted work — and you have a culture running a new operating model on old assumptions. Culture is the connective tissue that determines whether new tools take root or quietly wither. And almost no software organisation has done the cultural groundwork — the honest conversations about identity, incentives, trust, and standards — that AI adoption actually demands. #### 5. The Collective Assumptions and Beliefs Gap Underneath culture — beneath the incentive structures, the team dynamics, the review processes — sits something harder to see and harder still to shift: the shared, largely unspoken assumptions that govern how an organisation thinks about software development in the first place. Every engineering organisation runs on a set of collective beliefs. Beliefs about what quality means. About who is responsible for outcomes. About whether speed or correctness is the real priority when they conflict. About whether ‘done’ means shipped or validated. About whether the purpose of a developer is to produce code or to solve problems. Most of these beliefs have never been made explicit — they have accumulated over years through decisions, incidents, leadership behaviour, and the stories an organisation tells about its own successes and failures. AI does not arrive into a neutral space. It lands directly into this belief system — and it will be interpreted through it. In an organisation that collectively believes developers are primarily measured by output volume, AI becomes a tool for generating more output faster. The underlying belief — that volume is the point — does not get questioned. It gets turbocharged. In an organisation that believes quality is ‘someone else’s job’ (QA’s job, the tech lead’s job, the review process’s job), AI-generated code will receive the same cursory scrutiny as human-generated code always did. The belief that scrutiny is someone else’s responsibility does not change just because the code came from a model. More insidiously: most organisations hold a collective belief that technology adoption is fundamentally a technical problem. Buy the right tools. Configure them correctly. Train people to use them. Done. This belief is precisely why AI adoption keeps failing — because the hardest parts are not technical at all. They are about what the organisation thinks it is doing when it builds software, and what it believes good looks like. Until those assumptions are surfaced, examined, and in many cases deliberately replaced, AI will be grafted onto a belief system that was shaped by a completely different era of software development. The tool changes. The mental model does not. And the mental model always wins. #### 6. The Measurement Gap How do you know if AI adoption in your software function is working? If your answer is ‘developer satisfaction scores’ or ‘lines of code produced’, you are measuring the wrong things entirely. The relevant questions are harder: is the _quality_ of software output improving? Are defect rates falling? Is time to production incident going up or down? Is technical debt accelerating or decelerating? Is the codebase becoming more or less maintainable over time? Almost no organisation has the instrumentation to answer these questions before it adopts AI, which means it has no baseline against which to measure the impact of adoption. Organisations will declare victory based on vibes and vendor case studies, and will not notice the slow-motion degradation until it surfaces as a crisis. ### The Bind Nobody Is Naming So here is where we arrive, and it is not a comfortable place. Adopt AI now — into unprepared codebases, immature processes, blame cultures, unexamined belief systems, and with no measurement baseline — and you risk destroying the very thing you are trying to improve. You accelerate entropy. You accumulate a new layer of AI-generated technical debt on top of the debt you already had. You deskill the junior engineers who were supposed to grow into your future senior engineers. You create a codebase that moves faster and degrades faster, and you will not know which is happening until it is too late to cheaply reverse. Delay adoption — take the time to do the groundwork properly, fix the processes, surface the assumptions, build the measurement infrastructure — and your competitors, who are not asking these questions, will be moving faster in the short term. They will ship more. They will look more productive. They will attract the investors and the talent who have been told that AI adoption is the signal of a serious engineering organisation. You will look slow. You may lose ground that is genuinely hard to recover. This is the bind. It is real, and it is not going away. The technology industry has a long history of creating exactly this kind of false urgency — where the cost of moving carefully looks indistinguishable from the cost of standing still, and where the people who are doing the hard foundational work are penalised by a market that cannot yet see the difference between adoption and readiness. We saw it with cloud migration. Organisations that lifted and shifted their on-premise mess into the cloud did not become cloud-native organisations — they became organisations with an expensive, poorly architected cloud mess instead. The ones that slowed down to re-architect properly got there later and got there right. Most of them no longer regret the patience. We saw it with agile. Organisations that bolted a scrum ceremonies onto a waterfall mindset did not become agile — they became organisations with two-week sprints and the same old dysfunction. The ones that did the cultural and structural work underneath the practices built something that actually compounded over time. AI in software development is the same story, compressed into a shorter timeline and with higher stakes, because the tools are more powerful and the gap between what they promise and what unprepared organisations can actually absorb is correspondingly larger. The bind does not have a clean resolution. But it does have a less bad path through it: be honest about which parts of your organisation are genuinely ready to absorb AI benefit, and start there — not everywhere. Run real adoption in the pockets of the codebase and the teams where the foundations are solid enough to get the upside without the downside. Use the rest of the organisation’s time to build the foundations that do not yet exist. That is not a transformation narrative. It will not look good on a board deck. But it is the only path that does not trade your medium-term future for a short-term productivity story. ### Why Vendors and Analysts Will Not Tell You This The AI tooling market is worth billions. The analyst firms are paid by the vendors. The case studies are curated. The pilots are run by the most enthusiastic engineers in the most favourable conditions, and then presented as representative. Nobody in this ecosystem is financially incentivised to say: _slow down, get your house in order first._ The incentives all point towards adoption, and towards adoption now, before your competitors get there. The result is a wave of organisations deploying AI into development functions that are not ready for it — and calling the resulting chaos ‘transformation’. ### This Is Not an Argument Against AI To be clear: AI is genuinely powerful. The trajectory of these tools is real. The productivity ceiling is higher than almost anything that came before it in software development tooling. But power deployed into an unprepared context does not produce good outcomes. It produces fast bad ones. The organisations that will actually succeed with AI in software development are the ones that resist the pressure to announce and instead do the unglamorous work first: modernising codebases, strengthening engineering processes, investing in human judgement and code review culture, building measurement infrastructure, and thinking carefully about where AI assistance adds signal versus where it adds noise. Those organisations exist. But they are not ready _today_ — they are getting ready, and that is a meaningfully different thing. ### The Honest Prescription If you want to actually be ready — not performatively ready, but genuinely ready — here is what it takes. Audit your codebase honestly. Know where it is structurally sound enough to benefit from AI acceleration, and where it will absorb AI output into existing rot. Fix your processes before you automate them. Test coverage, code review culture, CI/CD discipline — get these to a level you are not embarrassed by before you add AI to the mix. Surface your collective assumptions. Before you deploy a tool, ask the harder question: what does this organisation actually believe about software quality, developer accountability, and what ‘done’ means? AI will amplify whatever the answer is. Make sure you can live with the amplified version. Invest in senior judgement. AI oversight is a skill. Develop it deliberately, and resist the temptation to treat AI as a substitute for experienced engineers rather than a tool for them. Instrument before you adopt. Build the measurement frameworks now, so you can tell the difference between AI making things better and AI making things faster in ways that will hurt you later. Be honest about what a pilot proves. Enthusiasm in a three-month pilot with volunteers proves enthusiasm in a three-month pilot with volunteers. That is it. --- The organisations that say they are ready are, almost certainly, not. The honest ones — the ones quietly asking hard questions about their codebase, their processes, their beliefs, and their measurement gaps — are the ones who might actually get there. Zero are ready today. Some could be, if they do the work. The question is whether the hype gives them permission to do that work patiently, or whether it pressures them into a sprint they have not trained for. _The answer is not ‘do not adopt AI’. It is ‘do not mistake a tool for a strategy’._ ### Further Reading DORA. (2024). _Accelerate state of DevOps report 2024_. Google Cloud. [https://dora.dev/research/2024/dora-report/](https://dora.dev/research/2024/dora-report/) Forsgren, N., Humble, J., & Kim, G. (2018). _Accelerate: The science of lean software and DevOps: Building and scaling high performing technology organisations_. IT Revolution Press. McKinsey & Company. (2024, May 30). _The state of AI in early 2024: Gen AI adoption spikes and starts to generate value_. [https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai-2024](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai-2024) McKinsey & Company. (2025a). _The state of AI in 2025: Agents, innovation, and transformation_. [https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai) McKinsey & Company. (2025b, November). _Unlocking the value of AI in software development_. [https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/unlocking-the-value-of-ai-in-software-development](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/unlocking-the-value-of-ai-in-software-development) Westrum, R. (2004). A typology of organisational cultures. _BMJ Quality & Safety_, _13_(Suppl 2), ii22–ii27. [https://doi.org/10.1136/qhc.13.suppl_2.ii22](https://doi.org/10.1136/qhc.13.suppl_2.ii22)