How Scale-ups Can Get the Most Out of AI
Engineering leaders are eager for their engineers to fully leverage AI to accelerate roadmap delivery.
They’re also keenly aware of the competitive threat posed by AI – whether from customers choosing to self-build or from competing startups enjoying compressed development timelines.
But often the way they apply AI doesn’t match the needs of a scale-up and leaves most of the potential development throughput gains on the table.
Rather than relying on simpler AI development approaches that may suit startups, scale-ups need a broader application of AI that matches their stage and maximizes throughput without increasing delivery unpredictability.
In this article I cover what that broader application entails and why it substantially increases the value a scale-up can get from AI.
The throughput problem in scaling software companies
The central question is: why do larger and older software companies develop software more slowly per headcount than smaller and younger ones?
The answer is: complexity accumulates exponentially over time, driving growth in the effort required for each new feature or bug fix, which in turn causes decay in delivery throughput.
This accumulating complexity also drives increasing emergent behavior – more frequent bug reports, production incidents, and cross-team conflicts.
These effects cannot be countered by increasing headcount, as it yields sub-linear and delayed throughput growth while further increasing complexity.
Therefore, if a scale-up wishes to deliver on its roadmap predictably and efficiently, it must make a sustained investment in managing and reducing accumulated complexity – and as I’ll show, these investments can pay for themselves quickly through the use of AI.
Where complexity accumulation comes from and why it slows development
Much of the excitement from LLM code generation has come from how quickly it can write accurate code – especially for fresh builds.
But writing code is not how developers have ever spent most of their time. If you were to observe a room of developers, you’d see that they spend most of their time reading and thinking – not typing.
This is particularly true in scale-ups, where developers are seldom working on new builds and instead spend most of their time getting their bearings in large, aging codebases, and making complex incremental changes that must avoid breaking existing functionality.
Another thing you’d notice if you joined their standups is how often they mention obstacles, and how varied those obstacles are – from unreliable tests, to debugging local development environments, to working out why an error occurs in production but not locally.
Put simply, any conceptualization of a developer as a converter of requirement specifications into code is a fiction. In practice, the developer is a solver of problems across both software and the systems and organizations that surround it, and accumulated complexity determines the average time it takes to solve a problem.
This accumulation of complexity arises from the economics of startups: a startup has one goal – to find product-market fit before its money runs out. Investing seed capital into complexity reduction is not a great survival strategy.
Hence, decisions are made based on expediency and urgency. “Simple, reliable, maintainable, and efficient” plays second fiddle to “do whatever we need to do right now to ship the next feature quickly”. Shortcuts, hacks, and “we’ll worry about that later” win the day.
Therefore, by the time a company reaches the scale-up stage, it is carrying a significant burden of deferred “do it the right way” – i.e. accumulated complexity.
This includes manual processes, out-of-date documentation, fragile services, cross-team coordination difficulties, convoluted development setups, and a long list of other issues that create friction for developers.
So rather than using AI purely to accelerate feature development directly – important as that remains – you also need to use it to reverse the causes of that friction, shifting gear out of startup mode and into scale-up mode.
The effectiveness of this approach is further compounded by what LLM-based AI agents are strong at versus weak at. They’re strong at anything involving repetition, volume, transformation or translation, and pattern application at scale, while being weak at tasks requiring deep context, long-range consistency, or precise judgment.
Hence, the more a scale-up uses AI where it’s strong to reduce accumulated complexity, the more it can keep developer time focused on new features – in large, existing codebases where LLMs are weaker.
This accelerates feature delivery, improving sales opportunities. It also reduces bugs and production incidents, and speeds up bug fixes, thereby reducing churn. Together, these effects increase growth.
Focusing only on improving developer skill and frequency of AI usage for developing new features misses the larger opportunity. In 2026, with AI already widely used by developers, this means optimizing for marginal gains while leaving a much larger, structural source of gains on the table.
AI changes the economics of complexity reduction
Before AI, every scale-up had a long list of initiatives that senior engineers knew needed to be done and would significantly reduce friction, but that would never get the green light against the ever-more-urgent priority of features that must be built right now – even long after PMF and sustainable growth have been achieved. This is a situation I call “maximizing the number of features shipped this week and minimizing the number shipped this year”.
After AI, the economics of many of these initiatives have been reversed. The following are examples of initiatives that AI can now accelerate, allowing the company to move back down the accumulated complexity curve and in turn increase development pace.
Replacing legacy systems. Dev teams usually know of at least one legacy service that should have been replaced years ago, which costs 10x the usual effort to add features to and breaks regularly with difficult-to-fix bugs.
Before AI, the idea of rebuilding it from scratch for no immediate feature gain was intolerable, and the idea of incrementally refactoring it got almost as much discussion as it did inaction.
After AI, such replacements can be made rapidly and pay for themselves in saved development capacity in well under a year.
Code updates. It’s common in scale-ups for multiple frameworks to coexist in the codebase, as engineers have introduced various flavor-of-the-month frameworks and languages over time.
No one objects to new features being built in a new framework – especially when it claims to speed up development compared to older ones (with the true motivation often being developers wanting to try new tech and add it to their resumes).
But the same is not true for migrating existing features to the new framework, creating an interwoven mishmash of old and new.
This mishmash slows developers, especially new joiners.
This is an excellent target for AI – which is strong at translating between languages and frameworks – allowing large parts of the codebase to be rapidly updated to the same framework. This was uneconomical before AI.
Test writing. Few developers enjoy writing or updating tests, no matter how much TDD has been advocated, and fewer still of their managers meaningfully object to that lack of interest. Outside of true “encode the requirements as tests” scenarios, it’s a time-consuming chore.
With AI, copious test coverage can be added rapidly at low cost.
This is especially important for refactoring and replacement work, where tests are relied on to ensure the new code fulfils the same functionality as the old.
Automating routine tasks. This is a bottomless barrel. In scale-ups, a huge amount of manual activity accumulates that can be automated. Before AI, the idea of automating things would be raised in meetings but get little follow up – or worse, get started but never delivered.
After AI, that automation can actually get done – and the ROI can be incredible.
As one example I completed recently, a recurring maintenance task was consuming a total of over one dev-year of effort each time it was carried out. Automating it with scripts written using Opus 4.5 took less than a week.
Improving development environments. Unreliable or incomplete local development environments silently waste enormous amounts of developer time, yet receive frustratingly little attention.
AI can set up, fix, and augment local development setups so quickly that it makes no economic sense not to do it – the gains are multiplied across every developer.
Fixing poor documentation. Convoluted and out-of-date documentation causes a lot of lost time for anyone who uses it.
But since those losses happen silently, little effort is spent maintaining documentation, and the losses continue.
Developers are not professional writers, and writing clear, concise documentation is not usually one of their core strengths. Selecting the most read pages from your corporate wiki and running them through AI can greatly improve their usability.
Root cause analysis. Many scale-ups have a bad habit: when an incident happens, they fix it and move on to the next priority before applying preventative measures.
This is driven by the same urgency-based prioritization culture that exacerbates the decay of delivery throughput. During the incident there is urgency, so it gets the necessary resources. After the incident is over, the urgency disappears, so preventing recurrence drops to the bottom of the to-do list.
While ultimately an accountability issue (failing to complete a root cause analysis and its action items should be treated as equivalent to enabling the incident), the work involved is significantly reduced by AI.
It isn’t an appealing task to go through hundreds of messages spread across different threads and channels and piece together what happened and why, so the temptation to prioritize something else is high.
But AI can process all that information and suggest root causes rapidly, with little more than a brief prompt and some copy-pasting. It can also assist with completing the resulting action items, such as revising processes, building safeguards, and implementing fixes.
AI can therefore make it economical to diligently fix the root causes of even minor internal incidents, which is a reliable path to improving delivery predictability.
Systemically simplifying your way to speed and predictability
There are countless ways AI can be used to improve delivery performance beyond direct feature development, and the gains from these improvements compound.
As long as the company shifts gear from startup mode to scale-up mode by dedicating resources to reducing development friction, AI can be used to quickly and permanently remove ongoing time losses and sources of emergent behavior – increasing development throughput and predictability.