Syntactically correct Python is everywhere. Idiomatic TypeScript is everywhere. Well-tested React components, clean Go functions, properly structured SQL queries – the internet is full of them. The code that rises to visibility (starred repositories, accepted answers, cited libraries) is disproportionately well-written. LLMs learned from the best available examples of what code should look like at the expression level.<\/p>\n\n\n\n
So when you ask an LLM to implement a function, write a test, translate code between languages, or produce a boilerplate component – it does these things well because it has seen thousands of examples of them done well. It is pattern-matching against a high-quality corpus.<\/p>\n\n\n\n
Why LLMs Are Bad at Architecture<\/h2>\n\n\n\n
The answer, again, is in the training data. But this time the story runs in reverse.<\/p>\n\n\n
![\"Two](\"https:\/\/harmonic-framework.com\/wp-content\/uploads\/2026\/04\/library-chart.png\")
LLMs were not trained on good architecture – because most architecture is bad.<\/p>\n\n\n\n
The average codebase does not have clean component boundaries. The average GitHub repository does not demonstrate principled decomposition. The average production system – the one that actually runs real software for real organizations – is a tangle of historical decisions, accumulated coupling, and pragmatic shortcuts that made sense at the time. The architectural patterns that survive into the training corpus are mostly noise: God classes, layered monoliths where the layers have all blurred together, services that started as microservices and ended as distributed monoliths.<\/p>\n\n\n\n
Good architecture is rare. It is rare in open source, rarer in enterprise software, and almost invisible in the kind of code that gets posted publicly. The training data for architectural reasoning is overwhelmingly composed of examples of what not<\/em> to do.<\/p>\n\n\n\n So when you ask an LLM “should this be a separate service or stay in the monolith?”, “where does this business logic belong?”, “why is this component hard to test and what does that tell us?” – it reaches for the same pattern-matching mechanism that works for code. It finds patterns. Those patterns are mostly wrong.<\/p>\n\n\n\n John Henry was a steel-driver on the Chesapeake & Ohio Railroad. When a steam-powered drilling machine arrived to replace him and his crew, he challenged it to a race. He won. He drove more steel than the machine in a single shift. Then he died – hammer in hand, heart given out from the effort.<\/p>\n\n\n The story is a tragedy not because John Henry lost. He won. The tragedy is that winning was meaningless. The steam drill went back to work the next morning. And the morning after that. It did not get tired. It did not need to recover. It got better with each iteration of the design, and every improvement cost the railroad less than paying a human crew.<\/p>\n\n\n\n The developers who are racing LLMs at code generation are John Henry. Some of them are winning individual sprints – typing faster, knowing more idioms, catching subtle bugs the model misses. The race is still lost. Not because LLMs are better today at every coding task. Because the trajectory is one-directional, the improvement pace is relentless, and the cost of the machine approaches zero while the cost of the human does not.<\/p>\n\n\n\n The question is not whether you can beat the machine today. The question is whether beating the machine is the right race to be running.<\/p>\n<\/blockquote>\n\n\n\n John Henry’s error was not in swinging the hammer. It was in believing that swinging the hammer was the point. The point was the railroad. The point was getting people and goods from one place to another. The hammer was infrastructure. When better infrastructure arrived, the hammer became optional. The engineers who designed the route – who understood terrain, gradient, load, and the economics of where the line should go – those people were not replaced by the steam drill. The steam drill needed them more than ever, because now it could move faster than anyone had anticipated and the decisions about direction became more consequential, not less.<\/p>\n\n\n\n The standard AI-displacement narrative runs roughly like this: AI can now write code; developers write code; therefore developers will be displaced. It sounds logical. It isn’t.<\/p>\n\n\n\n It conflates “writing code” with “doing software engineering.” These have never been the same thing. Writing code is the mechanism by which software engineering decisions get expressed in an executable form. The decisions themselves – what to build, how to structure it, where to draw the boundaries, how to reason about change – are not coding. They were never coding. Coding was always just the tool.<\/p>\n\n\n\n The developers whose jobs are genuinely threatened are those who were doing coding without design thinking. Following patterns mechanically. Translating requirements into code without understanding why the requirements have the shape they do. Writing boilerplate. Filling in CRUD endpoints. Producing test coverage that satisfies a metric without revealing structural truth. AI does these things better, faster, and at lower cost. That is real displacement, and it is already happening.<\/p>\n\n\n\n But the developers who understand systems – who can identify what changes and why, draw boundaries that isolate change, reason about long-term structural evolution, derive a test strategy from an architecture rather than spraying assertions at code – those developers become more<\/em> valuable, not less. Because the thing they do cannot be trained into a model that learned from bad architecture.<\/p>\n\n\n\n We have been here before. Every major increase in abstraction removed a coding bottleneck and elevated the work that remained.<\/p>\n\n\n\nThe John Henry Problem<\/h2>\n\n\n\n
![\"John](\"https:\/\/harmonic-framework.com\/wp-content\/uploads\/2026\/04\/john-henry.png\")
\n
The Argument That AI Will Take Developer Jobs Gets This Backwards<\/h2>\n\n\n\n
This Is What Every Abstraction Jump Has Always Done<\/h2>\n\n\n\n