# How to accelerate with AI when your company is starting late

> Starting late is an advantage only if you skip stages: organize data, processes, and communication first, build a culture of working with AI, then adopt only AI that compounds. Late starters who skip the foundation replay the industry's mistakes in order and buy point acceleration that never reaches delivery.

_Insights · 2026-07-11_

**A company that starts AI in 2026 holds an advantage nobody advertises: four years of the industry's mistakes, already made, measured, and published, that it never has to repeat. Capturing that advantage takes a specific sequence: organize your data, processes, and communication first, build a culture that understands how to work with AI, and only then adopt AI tools, choosing the ones that compound over the ones that isolate.** Most late starters run the sequence backwards. They start with subscriptions, and the result is already in the data: in [McKinsey's March 2025 global survey](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai-how-organizations-are-rewiring-to-capture-value), more than 80 percent of respondents said their organizations were seeing no tangible impact on enterprise-level EBIT from their use of gen AI. I spent the last few months watching a company live out the backwards version from the inside.

## How a mid-2026 AI mandate became a rerun of the industry's 2023 mistakes

The most expensive way to start AI late is to start it in the original order. The company I watched had stayed away from AI for reasons that were, at the time, defensible: a validated financial product managing tens of millions for its users, a business model that did not need AI to work, and an engineering team openly skeptical of AI even as a coding tool. Then, in mid-2026, the investor board asked for AI to be involved internally, and the catching up began.

What appeared over the following months was not a strategy. It was a timeline, replayed. An AI subscription for transcribing calls. Another for asking questions about the database in natural language. Automation proofs of concept built in a visual no-code tool. Each initiative was reasonable in isolation, and each one was a faithful reproduction of a stage the rest of the industry had already passed through, learned from, and moved beyond. Far from catching up to the frontier, the company was reenacting the path, stage by stage.

I want to be precise about my seat: I was consulting there on another front, and AI strategy was not my lane, so I had no power to decide any of this. What I had was the view. And the view was a company paying full price, in time and in credibility, for lessons the industry had already published for free.

## Starting AI late is an advantage only if you skip stages

A company that starts AI in 2026 inherits four years of published mistakes to skip. The rerun is a late starter replaying the industry's AI adoption mistakes in their original order instead of entering at the current frontier, and it begins the moment a company declines that inheritance. Development economists have a name for accepting it: leapfrogging, studied since Luc Soete's 1985 paper in World Development, and defined by [UNCTAD (2018)](https://unctad.org/system/files/official-document/presspb2018d8_en.pdf) as bypassing "the intermediate stages of technology" in a development process. The canonical example is telephony: [ITU's 2024 figures](https://www.itu.int/itu-d/reports/statistics/2024/11/10/ff24-subscriptions/) show Africa with 98 mobile subscriptions per 100 inhabitants against a single fixed line per 100. The countries that connected last never built the copper. They entered at the frontier.

Late AI adopters hold the same position, and most of them squander it. While the company in my story deliberated, the world moved: in McKinsey's Global Survey published in November 2025, [88 percent of respondents reported regular AI use](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai) in at least one business function at their organizations, up from 78 percent a year earlier. The frontier kept advancing, the published record of what worked and what failed kept growing, and none of that record transfers automatically. UNCTAD titled its leapfrogging brief "Look before you leap" for a reason I will return to: skipping stages has a prerequisite, and it is not a purchase order.

## Isolated AI subscriptions create point acceleration, not faster delivery

Point AI is any tool adopted to accelerate a single task in isolation, disconnected from the shared context the rest of the organization works from. Point AI buys local relief, and its gains do not compose. A transcription bot saves the note-taker an hour. A chat-with-your-database tool saves an analyst a query. Each is real, each is local, and each leaves behind one more island of context that nothing else can read. This is the pattern I watched, and it is the pattern the industry has already measured to exhaustion.

[McKinsey's June 2025 report on agentic AI](https://www.mckinsey.com/capabilities/quantumblack/our-insights/seizing-the-agentic-ai-advantage) describes the resulting paradox: nearly eight in ten companies report using gen AI, and just as many report no significant bottom-line impact. The report's explanation matches what point AI predicts: horizontal copilots and chatbots scaled quickly but deliver diffuse, hard-to-measure gains, while the transformative, function-specific use cases, "about 90 percent of which remain stuck in pilot mode", never add up at the business level. Software companies specifically fare no better: [Bain's Technology Report 2025](https://www.bain.com/insights/from-pilots-to-payoff-generative-ai-in-software-development-technology-report-2025/) found that "two out of three software firms have rolled out generative AI tools, and among those, developer adoption is low". A rolled-out tool that developers avoid moves no delivery metric.

The opposite of point AI is AI that compounds: every new tool reads from and writes back to the same governed context, so the second tool makes the first one more valuable instead of more contradictory. Compounding is a property of the connections between tools, which is exactly why it cannot be bought one subscription at a time.

## The industry's own data shows the pattern: locally faster, globally flat

You can see AI everywhere in an engineering organization except in the delivery statistics. The economist Robert Solow wrote the original version in the [New York Times Book Review in 1987](http://www.standupeconomist.com/pdf/misc/solow-computer-productivity.pdf): "You can see the computer age everywhere but in the productivity statistics." Nearly four decades later, AI adoption is reproducing his paradox at fast forward, and reconciling the numbers everyone quotes shows how.

[Bain (2025)](https://www.bain.com/insights/from-pilots-to-payoff-generative-ai-in-software-development-technology-report-2025/) reports that "teams using AI assistants see 10% to 15% productivity boosts, but often the time saved isn't redirected toward higher-value work", while some companies report 25 to 30 percent gains by pairing generative AI with end-to-end process transformation. Same models, same vendors, double the outcome: the difference is the organization, not the tool. [METR's 2025 randomized trial](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) found that 16 experienced open-source developers completing 246 real tasks were 19 percent slower with AI allowed, while believing they had been about 20 percent faster, so self-reported acceleration is not a measurement. And [Atlassian's 2025 developer experience survey](https://www.atlassian.com/blog/developer/developer-experience-report-2025) of 3,500 developers and managers found 68 percent of developers saving more than ten hours a week with AI while half report losing ten or more hours a week to organizational friction, with finding information at the top of the list. The dividend is real, and it leaks out through the gaps between tools and between teams.

I call this shape locally faster, globally flat: every task accelerates, and delivery does not. It is the adoption-stage sibling of the failure I documented inside the delivery pipeline, [locally right, globally wrong](/en/blog/insights/why-ai-makes-software-delivery-slower). Solow's paradox eventually resolved. [Oliner and Sichel (2000)](https://www.aeaweb.org/articles?id=10.1257%2Fjep.14.4.3) concluded that information technology "largely is the story" behind the late 1990s productivity surge, and Paul David's 1990 comparison of the computer to the electric dynamo explained the lag: electricity transformed factory productivity decades after the motors arrived, once factories were rebuilt around them. The gains follow the reorganization, not the invention. A rerun postpones exactly that part.

## The 2026 frontier is an operating model: spec-driven work over governed context

The frontier a late starter should enter at is an operating model, not a tool. By mid-2026, using AI weekly is simply what software teams do: [Pragmatic Engineer's survey of 906 readers](https://newsletter.pragmaticengineer.com/p/ai-tooling-2026) (self-selected, mostly engineers and engineering leaders, fielded in early 2026) found 95 percent using AI tools at least weekly and 55 percent regularly working with AI agents, with Claude Code used by 71 percent of those agent users. [Faros AI's 2026 telemetry](https://pages.faros.ai/hubfs/AI_Engineering_Report_2026_The_Acceleration_Whiplash_Faros.pdf) across 22,000 developers in its customer base tells the same story from the pipes: 60 percent of developers use an AI tool weekly, and AI agents went from reviewing zero percent of pull requests in Faros's 2025 dataset to 25 percent in the 2026 one. The same report is honest about the cost of all that speed without governance: bugs per developer up 54 percent, and 31 percent more pull requests merging with no review at all.

What changed at the frontier is where the work starts. [GitHub shipped Spec Kit in September 2025](https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/) around the idea that the spec "becomes the source of truth your tools and AI agents use to generate, test, and validate code". Thoughtworks' Technology Radar placed spec-driven development in its Assess ring in November 2025, an emerging practice worth exploring rather than a settled one, and its April 2026 edition still holds the spec-driven tools it lists, GitHub Spec Kit and OpenSpec, at Assess, while moving [Claude Code from Trial to Adopt](https://www.thoughtworks.com/content/dam/thoughtworks/documents/radar/2026/04/tr_technology_radar_vol_34_en.pdf) in five months because teams "use it day-to-day in production software delivery". In the teams I work with, the same shift swallowed internal automation: what would have been a visual no-code workflow in 2023 is now a small tool written by a coding agent from a spec, versioned next to the code it serves. I know of no published dataset tracking that migration, so take it as one consultant's sample, but the tooling record above points the same way.

[DORA's 2025 research](https://services.google.com/fh/files/misc/2025_dora_ai_capabilities_model.pdf), built on survey responses from nearly 5,000 technology professionals, gives the frontier its one-line law: "AI's primary role in software development is to amplify. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones." Of the seven capabilities DORA found to amplify AI's positive impact, two are about nothing but context: healthy data ecosystems and AI-accessible internal data. The conditions for acceleration are organizational, and they are exactly the stages a rerun skips.

## The first 90 days for a late starter: foundation, culture, then only AI that compounds

Leapfrogging has a prerequisite the vendor decks omit: absorptive capacity. Nobody skips stages from the ground. The development economics is blunt about this. [Steinmueller (2001)](https://library.fes.de/libalt/journals/swetsfulltext/17160724.pdf) wrote that "efforts to build absorptive capacity are a specific strategy for economic development and a prerequisite for technological leapfrogging", and [Keun Lee (2019)](https://downloads.unido.org/ot/16/41/16414872/WP_17_FINAL.pdf) warned that laggards "should not attempt pre-mature leapfrogging but should first build some absorptive capacity", comparing the leap to flying a balloon after the ladder is gone: without the capability, you fall. Applied to a software company, absorptive capacity is not a data lake. It is whether your organization can absorb a tool that acts on its knowledge.

I had no decision power in the company I watched. If I could rewind to the month of the mandate holding it, this is the 90 days I would run.

**Weeks 1 to 4, foundation before tools.** Organize the data, the processes, and the communication that any AI will depend on. Inventory where truth lives: which decisions are in specs, which in tickets, which only in the codebase, which only in someone's head. Reconcile the names, close the process gaps humans currently paper over, and make that context machine-readable. Nothing in this phase requires buying anything, and everything after it depends on it.

**Weeks 5 to 8, culture before rollout.** Build a shared understanding of how AI works, where it fails, and how to work with it, and do it with the skeptics rather than around them. [Bain (2025)](https://www.bain.com/insights/from-pilots-to-payoff-generative-ai-in-software-development-technology-report-2025/) found that "three of four companies say that the hardest part is getting people to change how they work". Treat an engineering team's aversion as calibration data from the people who will catch what the AI gets almost right, not as an obstacle to manage. Reduce it with working examples on the team's real tasks, not with mandates and usage quotas.

**Weeks 9 to 12, only AI that compounds.** Now adopt tools, under one admission rule: every AI tool must read from and write back to the same governed context, or it does not come in. A tool that creates its own island subtracts from the system even when it wins its local task. This is where the foundation pays: the shared context you organized becomes a [context layer](/en/blog/guides/context-layer-for-ai-agents), the single place every agent checks what is currently true before acting. Rules files and MCP servers are the right plumbing and the wrong governance; [an interface to context is not a decision about truth](/en/blog/insights/is-mcp-enough-for-shared-context). For the profile of company that starts late, regulated, careful, allergic to shipping its internals to a cloud vendor, this is also the step that must run on its own servers. That constraint is why [LoomSignal](/en#pricing), our context layer for the delivery lifecycle, is self-hosted and bought once.

A late starter that runs this sequence enters at the frontier in one quarter, with the one asset the early adopters had to earn through four years of published failure: knowing which stages were the mistakes.

The company in my story is not there. Months after the mandate, delivery has not moved, the pressure from the board has only grown, and the budget conversation has turned, against the direction of the entire market it waited on, back toward hiring more people. That is the real cost of the rerun: not the wasted subscriptions, but the conclusion the organization draws at the end of it, that AI does not work, when what never worked was the order. Being late to AI is a scheduling problem. Repeating the industry's path in order is a strategy problem. Only one of them can still be fixed today.

---
Source: https://loomsignal.io/en/blog/insights/how-to-accelerate-with-ai-starting-late