Jet Engine on a Tractor: AI’s Big Productivity Trap | Uptime Labs

AboutContact<br>Log In

Book a demo<br>Try it now

Back to articles

Jet Engine on a Tractor: AI’s Big Productivity Trap

Hamed Silatani

June 19, 2026

Tags:<br>Incident Management

AI & Automation

link copied to clipboard

https://uptimelabs.io/articles/jet-engine-on-a-tractor-ais-big-productivity-trap

IN THIS ARTICLE

Incident Timeline

Ready to make incident response your competitive advantage?

See how Uptime Labs builds provable, scalable incident response capability across your organisation.

Book a demo<br>Explore the platform

Organisations are complex socio-technical systems. Two words in that phrase carry fundamental implications for AI adoption strategy: socio-technical and system.<br>The former means people are part of the system. The latter means a functioning whole: a set of parts that only produces its result together, not individually. You can have the best individual components and still end up with a dysfunctional system.<br>I'm an early adopter by nature. As an engineer, I love using new ideas to do more good, faster. But this time around, something feels off. I'm getting a lot more done, yet I can't see proportional productivity in terms of economic value. I'm more stressed, I work longer hours, I pay more (AI tokens) and yet the output doesn't reflect any of it.<br>Then, in what felt like a coincidence, two separate talks gave me an explanation.<br>The first was by Adam Bender, who applies a systems thinking lens to AI adoption in software engineering. The second was by Daron Acemoglu, an economist who uses Weak Link Theory to explain the economic impact of technological revolutions. After watching both, I realised they were saying the same thing: your productivity is limited by the weakest link in the system.<br>Building and operating software is a function of a socio-technical system, which is itself a subsystem of a bigger whole called an organisation. If you map out how software is actually created and operated in your organisation, my bet is you'll end up with a complex, interconnected system that no single person fully understands. And yet, somehow, it works. Here's my own list at Uptime Labs:<br>Mission of Uptime Labs: Why we do what we do<br>Engineering principles: influencing product, architectural, and technical choices<br>Understanding of all the technical decisions made so far<br>Product requirements and user research<br>Repository structure<br>Quality gates<br>Workflows<br>Development environment and testing strategy<br>Continuous deployment, post-deployment tests and rollback mechanisms<br>Writing code and code reviews<br>Communicating changes to customers<br>Observability<br>Incident response process and tooling<br>That list is already intimidating, and we're a startup. I can't even list everything, let alone map all the relationships between the parts.<br>Unless we can claim that AI eliminates the need for human input in every single one of those components, we will always end up with a socio-technical system that involves humans. Now assume AI can automate and scale all the non-human parts. Humans immediately become the weak link. At least three things are likely to happen:‍<br>1.People will feel unprecedented pressure<br>The system accelerates around them to the point of breaking i.e. a jet engine bolted onto a tractor. You can ignite it, but the tractor wasn't built for that.<br>2. The value of the weak link rises dramatically<br>Engineers who address the bottleneck unlock value across the whole system. Contrary to much of the public discourse, those skills become more valuable, not less.<br>3. A lot of money gets wasted<br>We pay to generate 10x more code because we can. But if the system's output doesn't increase and may actually decrease due to pressure on the weak link. Ie. we've invested heavily in one part while starving the rest.<br>A few examples related to other parts of the system:<br>Take the principle of releasing small pieces of code, noticing a problem and rolling back quickly. What happens when you're releasing far more code, far faster, without time to observe the impact in production? Some problems take hours to surface.<br>Or consider code reviews; the cognitive load scales with the volume of code.<br>Or shared system understanding, which is critical to effective incident response. If nobody fully understands what was just deployed, how does the team reason their way through an outage?<br>This is where the left-over principle becomes important. These are the skills that remain uniquely human once AI handles everything else: sense-making, coordination, communication under pressure. When an incident hits, what determines whether it takes 20 minutes or 4 hours to resolve isn't usually the tooling. It's whether the people involved can orient quickly, communicate clearly, and make decisions in uncertainty. Those skills aren't a nice-to-have. As AI raises the ceiling on everything else, they become the rate-limiting factor.<br>My point isn't to slow down AI adoption. It's to think about the...