In 1793 Eli Whitney invented a machine that could separate cotton fibers from their sticky seeds. The ‘Cotton Gin’ (short for ‘Cotton Engine’) mechanised what was previously a hugely laborious and inefficient manual process and it transformed the textile industry almost overnight. Suddenly mass-scale cotton production became not only more possible, but vastly more profitable. The Cotton Gin had resolved one of the biggest bottlenecks in cotton production and farmers in the American South could now process huge amounts of the crop in a mechanical way. Cotton rapidly became the primary agricultural export of the region.
One can perhaps forgive contemporary observers for thinking that the new technology would result in a reduced dependence on manpower but instead the opposite happened. The constraint simply moved. With plantation owners now incentivised to grow much more of the crop, and cleaning the cotton no longer proving to be a bottleneck in the production process, the binding constraint shifted to become the supply of labour needed to plant and pick the now wildly profitable crop. The catastrophic result of the mechanisation of cotton cleansing was that, far from reducing the need for enslaved labour as some had hoped, it massively entrenched and expanded slavery across the American South.
The Cotton Gin is a good example of one of the key principles of Eli Goldratt’s Theory of Constraints. Every system has at least one constraint (the weakest link, if you like) that limits and governs its overall output. Improving anything other than the primary constraint won’t improve the total throughput. But the moment we focus on improving one bottleneck the constraint simply moves to another part of the system.
AI is no different. When we apply AI to remove one bottleneck in a process (for example coding capacity), the constraint will shift to another point in the process (for example QA). The surprise here is less that AI is shifting the bottleneck, and more that this isn’t seen as one of the most reliable predictions we can make about any productivity intervention, including AI. So the challenge becomes knowing where your constraint is likely to move next. If you don’t do this you’re likely to have speeded up one stage in the process but generated a new, unmanaged constraint that will now absorb the extra throughput that you’ve just enabled. And it will probably do this in ways that you can’t see or control, so rather than the system running better it’s just straining at a different point.
Amdahl’s Law is a principle used in computer science to show that the overall performance improvement of a system is fundamentally limited by the proportion of the task that cannot be improved. So, taking developers as an example, coding is widely believed to be about 20-30% of the software development lifecycle (all the work involved in producing and maintaining software). So even a massive speed-up in coding capability yields a relatively small overall velocity gain. There was also some interesting research published earlier this year, based on a survey of over a thousand enterprise developers, which showed that whilst 72% of developers who have tried AI use it every day to write code, the bottleneck had shifted from code generation to code verification. Reviewing and debugging the AI-generated code was taking so long that it was off-setting the time-saved by generating it in this way. This is an example of what often happens in AI implementation – you’re making one part of the process more efficient but in doing so you shift the constraint on to a part of the process that can’t be automated and the system outputs don’t improve.
Right now, most of the bottlenecks that AI is removing are production constraints (writing the code, summarising the meeting, drafting the copy, generating the options). But when production is made more efficient the constraint simply shifts to evaluation bottlenecks (is this right? Is it safe? How good is it? Do I trust it? Can we execute this?). You then hit another underlying challenge which is that production improvements can scale but judgement can’t. The gains from AI generation may be exponential in terms of production, but the human capacity for review, evaluation, assessment, and interpretation is finite and linear.
So whilst you may be able to scale some parts of a process through AI and automation, the output of a system can still be limited by the stages that assess whether any of that output is actually any good. Put another way, if the constraints are derived from humans, it’s also those very constraints that make the outputs worth anything at all. As the British Advertising legend David Abbott is once thought to have said ‘Sh*t that arrives at the speed of light, is still sh*t.’ But, as the software engineer Fernando Borretti has recently pointed out these human-derived inputs that resist automation are all internal things – human judgement, tacit knowledge, executive function, mental energy. AI is very good at moving the bottleneck from where machines work to where humans judge, but if judgement is the new constraint what happens when that comes under pressure? The survey of enterprise developers that I mentioned earlier also revealed that even though 96% of developers don’t trust AI code to be correct, only 48% said that they verified it before committing. In other words work flows through unverified and a constraint that looks like it’s been resolved has simply become invisible. It’s accumulating risk without you even realising it.
Another survey, this time of over 10,000 developers by Faros AI, revealed a different, compounding side to this problem. Whilst AI coding assistants generated 98% more pull requests (the unit of work a developer submits for review), those bundles of proposed code changes had typically increased in size by 154%, and code review time had increased by 91% as a result. Since code was much easier to write, it was being written in much larger batches, overwhelming reviewers and creating cognitive overload. Review teams couldn’t keep pace.
A key principle from Lean manufacturing is that value should flow continuously through a system. The instinct in mass production was to make things in large batches to benefit from economies of scale but Taiichi Ohno, the originator of Lean practices, saw that large batches can create a cascade of problems including hiding defects for longer (because a whole batch has to be produced before it can be inspected), inventory piling up between stages, and the system becoming harder to coordinate. Reducing the batch size means that problems surface immediately, work doesn’t accumulate, and the whole system stays much more responsive. Lean principles have long been imported into software development (Lean software, DevOps) as a way to reduce bottlenecks and hidden defects but AI is resurfacing a challenge that seventy years of operations thinking was meant to have solved.
These issues go far beyond coding and apply anywhere that AI is being implemented for productivity gain at specific stages in processes. Optimising for one step in the system whilst ignoring the whole system picture can actively degrade throughput because you’ve overwhelmed the downstream constraint with bigger, less legible batches of work. When that downstream constraint is human, that overwhelm can also take on uniquely human qualities.
By the end of the 1970s, the nuclear power industry had largely automated away the physical, manual bottlenecks involved with running a power station and shifted the human role to monitoring dials and judging when something was wrong. At Three Mile Island in 1979, the partial meltdown didn’t happen because human operators were not working hard enough, it happened because they were drowning in signals (hundreds of competing alarms, flashing warning lights) and had to decide under pressure which signal to pay attention to. In her renowned 1983 paper ‘Ironies of Automation’ (great title), Lisanne Bainbridge noted how automation often hands the human the hardest task (the vigilant judgement over a system that runs well until suddenly it doesn’t) whilst simultaneously eroding the hands-on skills that they need to intervene to put things right. A recent BCG study of 1,488 US workers across large companies found that constant AI use and monitoring resulted in what they called ‘Brain fry’ – mental fatigue, decision overload, an increase in errors and even intent to leave their job. The risk is that AI implementation doesn’t only move the bottleneck to human judgement, it moves it to a kind of judgement that is hard to sustain and results in a degradation of human fulfilment and well-being. The constraint has just moved to the one component in the system that fatigues.
So what to do? Goldratt’s Theory of Constraints outlines a continuous five-step thinking process: identify the constraint which is dictating the pace of the entire system; exploit the constraint by making it as efficient as possible without investing significant new resources; subordinate everything else to the constraint to ensure that it is never left waiting for work; then elevate the constraint by investing time or capital to permanently expand the capacity of the bottleneck; then repeat the process by identifying where the new constraint is and tackle that. These five steps create a good discipline for avoiding the temptation to try and add capacity by just buying another tool. Exploiting the constraint first protects human attention, keeps batch size small, and stops your valuable human judgement being spent on things that a machine could easily screen. Only then do you elevate the constraint and add capacity. This means that you’re treating human evaluation and assessment as a finite resource to protect and invest in rather than assuming it is something that is freely available and limitless.
One final thought. Optimising individual stages of a process can get you so far, but sometimes the real benefit comes from reinventing the system itself. In 1860 the Pony Express transformed transcontinental communication in the US, carrying mail from Missouri to California in ten days when the alternative was weeks by stagecoach. It was a system built with a particular constraint in mind – fresh horses were needed every ten to fifteen miles, and riders swapped at relay stations. When the telegraph finally reached the coast in 1861 the Pony Express became obsolete overnight. It had run for just 18 months. The Pony Express system had optimised brilliantly for a set of constraints that became irrelevant as soon as the telegraph arrived. AI is not only giving us myriad opportunities to optimise within a system, but sometimes the opportunity to rethink the system itself.
A version of this post appeared on my weekly Substack of AI and digital trends, and transformation insights. To join our community of over thirteen thousand subscribers you can sign up to that here.
To get posts like this delivered straight to your inbox, drop your email into the box below.
Leave a Reply