{"slug": "local-gains-dont-move-a-system", "title": "Local gains don’t move a system", "summary": "A developer argues that AI-driven productivity gains at individual steps rarely improve overall delivery because local optimizations miss the system's real constraint. Citing Goldratt's Theory of Constraints, Amdahl's Law, and Brooks' No Silver Bullet, the engineer contends that teams should map how work flows, measure waiting time, and eliminate unnecessary processes before automating them. \"Local gains do not move a system,\" the developer writes, warning that AI can make bad processes faster rather than better.", "body_md": "AI is amazing. You can answer questions. You can build new things. You have the power of a thousand PhDs at your fingertips.\n\nBut nothing is getting better…\n\nCycle time looks the same. Roadmaps slip the same. Everyone says they are feeling faster, but yet nothing arrives sooner.\n\n**Local gains do not move a system.**\n\nThe two best ways to miss gains are spending time at a place that isn’t the constraint or automating a process that shouldn’t exist in the first place.\n\nNone of this is new and these problems existed way before AI (or cloud, or computers!).\n\n## You saved time in the wrong place\n\n[The Goal](https://en.wikipedia.org/wiki/Theory_of_constraints) (Goldratt, 1984). “An hour saved at a non-bottleneck is a mirage”. There’s no point speeding up writing code if the release process takes a quarter.\n\n[Amdahl’s Law](https://en.wikipedia.org/wiki/Amdahl's_law) (1967). A variant of the Goal from parallel computing “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”.\n\n[Parkinson’s Law of Triviality](https://en.wikipedia.org/wiki/Law_of_triviality) (1957) - Committees focus on what they understand rather than what matters (boilerplate, commit messages, meeting notes, argh!). AI makes optimising these things much easier to imagine than before, whether or not it’s actually a genuine constraint.\n\n## You automated stupidity\n\n[Don’t Automate, Obliterate](https://hbr.org/1990/07/reengineering-work-dont-automate-obliterate) (Hammer[1](#footnote-1), HBR July-August 1990) - “Stop paving cow paths”. Applying technology to a bad process just builds a fast bad process. Reimagine it instead!\n\n[No Silver Bullet](https://en.wikipedia.org/wiki/No_Silver_Bullet) (Brooks, 1986). Accidental complexity versus essential complexity. AI is good at the accidental stuff, but the hard stuff is the essential complexity which is where your time goes!\n\n[Ironies of Automation](https://en.wikipedia.org/wiki/Ironies_of_Automation) (Bainbridge, 1983). Automation “can make the difficult parts of the human operator’s task more difficult”. AI writes code, humans find it harder to review code. And since they are no longer writing code they find it harder. Repeat.\n\n[MABA-MABA or Abracadabra](https://www.researchgate.net/publication/226605532_MABA-MABA_or_abracadabra_Progress_on_human-automation_co-ordination/link/02bfe5101b450a6ec5000000/download?_tp=eyJjb250ZXh0Ijp7ImZpcnN0UGFnZSI6InB1YmxpY2F0aW9uIiwicGFnZSI6InB1YmxpY2F0aW9uIn19) (Woods and Dekker, 2002). The assumption you can automate part of a human’s work without changing the system is wrong. It changes who has to coordinate with whom and what they can see. Ten engineers plus agents, is not ten engineers of output plus agents. It’s a new system.\n\n## What to do instead?\n\nAI doesn’t change the underlying problem. You’re still dealing with a system.\n\nAll of the references above have similar solutions to the problem.\n\n1. Take a bit of work and understand how it flows through the system. Make sure to mark every point in the system where it got stuck and what it was waiting for.\n2. Add up the waiting time. Everything that isn’t moving is waiting. If a change with three hours of work took nine days to ship, then that’s about 96% of a working days’ time sitting still. Double the speed of the three hours work and you’ve saved ninety minutes. Fix the release process and you’ve saved much more.\n3. Focus on the most expensive queue; not the most irritating one.\n4. Before you automate it, ask whether it should even exist. Automating the wrong thing just makes it permanent and much harder to argue with.\n5. Whatever survives, automate it!\n\nAnd then do it again because as soon as you do, the constraint will move somewhere else.\n\nAI agents *are* a new thing; applying systems thinking to speeding things up isn’t.\n\nFocus on the systematic approach and layer on some AI (where needed) and you might just see those improvements.\n\n[1](#footnote-anchor-1)\n\nAuthor is called Hammer, he’s written a paper called Don’t Automate, Obliterate. There’s a really good pun in there somewhere, but I haven’t found it yet!", "url": "https://wpnews.pro/news/local-gains-dont-move-a-system", "canonical_source": "https://fffej.substack.com/p/local-gains-dont-move-a-system", "published_at": "2026-09-07 05:30:30+00:00", "updated_at": "2026-09-21 23:22:43.841345+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools"], "entities": ["Goldratt", "Amdahl's Law", "Brooks", "Bainbridge", "Woods", "Dekker", "Harvard Business Review"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/local-gains-dont-move-a-system", "markdown": "https://wpnews.pro/news/local-gains-dont-move-a-system.md", "text": "https://wpnews.pro/news/local-gains-dont-move-a-system.txt", "jsonld": "https://wpnews.pro/news/local-gains-dont-move-a-system.jsonld"}}