Amdahl's Law and AI Productivity

How AI productivity is limited


Amdahl’s law, from 1967, perfectly describes everything about AI productivity. It explains why some people think productivity is way up and some see negligible impact. What is Amdahl’s law? Amdahl’s law is most often used around parallelizing code. It says that the gain from optimizing code depends on the portion that you can’t optimize, or more general:

“the overall performance improvement gained by optimizing a single part of a system is limited by the fraction of time that the improved part is actually used”

Amdahl’s law applies to many things beside optimizing code.

Amdahl’s law is the reason why the German railroad no longer aims for speeds above 300km/h and more or less settled on 250-300km/h. Because the German railroad system is limited by the many stops. The fastest train in Germany from Berlin to Frankfurt (Sprinter) is not so fast because it goes so fast, but because it does not stop. And if you can’t remove the stops, there is no need to go faster. The gain gets less and less but the costs rise and rise.

Amdahl’s law is core to the understanding of AI productivity. Your productivity gain is determined by the time you spend with AI and the parts of your work that you can’t (yet) use AI for. When I’ve started coding with Cursor, my idea->code part doubled or tripled in speed. I want something, I tell the AI, then <tab><tab><tab> - done.

All Todos AI

But now I’m limited by the time between AI usage. What do I want? What needs to be done? Me thinking and deciding is limiting my productivity gain. The time I don’t use AI is limiting my productivity gain by AI (Amdahl’s law!).

That implies I need to be more focused on making decisions and creating and maintaining TODO lists, so I can get faster back to using an AI - instead of spending time away from it. This, of course will shrink until it is gone, with AI being able to do more and more things for me.

The takeaway, all discussions about AI and productivity need to take Amdahl’s law into account, the tasks where you can’t and don’t use AI limit the overall productivity gains.

Join CTO Newsletter

Join more than 3500 CTOs and Engineering Managers

More Stuff from Stephan

Other interesting articles for CTOs

Best books for CTOThe CTO BookExperienced CTO CoachEngineering Manager CoachingConsulting and Workshops to Save you TimeCTO MentorCTO MentoringCTO NewsletterHow many developers do you need?Postgres for Everything Technology and RoadmapsHow to become a CTO in a company - a career path

Other Articles

Scrum is no longer fit with remote work

How I Wrote My CTO Book With My Own Tool

How To Succeed With A Rewrite - And Why They Fail

The 5 Reasons Not to Use Scrum

Comparing SQL, SQL JSON, ORM and GraphQL performance in Golang