--- title: LLMs can't simplify code because they don't have a Theory description: A resurfaced 1985 Peter Naur paper, 'Programming as Theory Building,' is circulating among developers as an explanation for why LLM-generated code degrades... canonical: https://daily.dev/posts/llms-can-t-simplify-code-because-they-don-t-have-a-theory-a2yxz5bav twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: LLMs can't simplify code because they don't have a Theory | daily.dev og:description: A resurfaced 1985 Peter Naur paper, 'Programming as Theory Building,' is circulating among developers as an explanation for why LLM-generated code degrades... og:url: https://daily.dev/posts/llms-can-t-simplify-code-because-they-don-t-have-a-theory-a2yxz5bav og:image: https://api.daily.dev/og/posts/a2YxZ5bav.png og:image:alt: LLMs can't simplify code because they don't have a Theory og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # LLMs can't simplify code because they don't have a Theory **[Trends](https://daily.dev/sources/trends)** · 3 min read · 47 upvotes · 10 comments ## Summary A resurfaced 1985 Peter Naur paper, 'Programming as Theory Building,' is circulating among developers as an explanation for why LLM-generated code degrades codebases even when individual diffs look reasonable. Naur's argument: a program's real substance is the unwritten mental model (the Theory) behind design decisions, not the code itself, which is just residue. Developers on social media point to patterns like duplicated methods, overdefensive edge-case handling, and premature optimization as symptoms. Answer.AI's own case study reinforces this: rebuilding a billing system with a simpler credit-based model, GPT-5.5 recommended reverting to Stripe subscriptions to handle an edge case, missing the business tradeoff the team had deliberately made to keep the system simple. The takeaway is that LLMs are theory-blind by construction, so simplification decisions still require human judgment first. ## Content There's a growing pile-on against the idea that LLMs will clean up your codebase, and it's built on a genuinely old argument: Peter Naur's 1985 paper "Programming as Theory Building." The claim, resurfacing hard this week via an Answer.AI writeup, is that a program's real complexity isn't in the code at all. It's in an unwritten mental model, the "Theory," that lives in engineers' heads: the business context, the tradeoffs already argued over and settled, the judgment calls about what's not worth handling. Code is just the residue of that thinking. LLMs never had access to the thinking, so they're stuck polishing the residue. @math_rachel's thread kicked off the current round of agreement: "LLMs increase the complexity of codebases. They duplicate methods, write overdefensive code against impossible edge cases, & overoptimize too early." Her follow-up question, can more training fix this, gets a flat no from the Naur framing, and that's the part people are latching onto. This isn't a scaling problem. It's a category problem. Jeremy Howard boosted it, and the framing spread fast.``` Answer.AI backs the theory with an actual example instead of just vibes, which is why it's landing. Their team rebuilt Solveit's billing system, ditching Stripe subscriptions for a plain credit-based, single-payment model, about 300 lines of code. Clean win, except Indian regulations make off-session card charging awkward without subscriptions. Stripe handles that natively. The team's answer: accept the UX limitation for Indian users rather than reintroduce subscription complexity everywhere else. That's a judgment call, weighing a market-specific inconvenience against system-wide conceptual load, and there's no metric for it. Here's the kicker: they asked GPT-5.5 what to do. It suggested reverting to Stripe subscriptions. Which is the exact tradeoff they'd already rejected, for reasons the model had no way of knowing. The model wasn't wrong on the merits so much as blind to the decision that had already been made. Meanwhile @filippkowalski's anecdote is making the rounds as the smaller, funnier version of the same complaint: a coding session that overengineered a simple cache lookup into an image hash plus an extra DB query, just to cover an edge case nobody asked about. "We have super smart LLM models, and they still do dumb shit," he writes. The consensus forming here isn't "LLMs write bad code." It's narrower and more uncomfortable: they can't tell you what to leave out, because leaving things out requires knowing why they were put there. ## Questions this post answers ### Why do LLMs tend to overcomplicate code instead of simplifying it? LLMs lack access to the unwritten mental model, or 'Theory,' that engineers build up about a codebase, including business context, prior tradeoffs, and judgment calls about what edge cases aren't worth handling. Since code is only the residue of that thinking, models end up duplicating methods, writing overdefensive code, and overoptimizing early because they cannot judge what to safely leave out. _For anyone weighing how much to trust AI-generated refactors, daily.dev surfaces ongoing debate on LLM code quality._ ### What happened when Answer.AI asked GPT-5.5 for advice after rebuilding Solveit's billing system? GPT-5.5 recommended reverting to Stripe subscriptions, exactly the tradeoff the team had already deliberately rejected. They had replaced Stripe subscriptions with a roughly 300-line credit-based, single-payment model, accepting a UX limitation for Indian users (where off-session card charging is regulated) rather than reintroducing subscription complexity everywhere else. The model had no way of knowing that decision had already been made. _Teams deciding how much architectural judgment to hand to AI tools can follow real cases like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 16 comments across x (as of 2026-09-13). **TL;DR:** Replies frame the underlying issue as an incentive problem — reviews and benchmarks reward local robustness or 'handles every case' over preserving a codebase's simplicity, and simplicity itself resists easy metrics — while others just share frustrating anecdotes of LLMs wasting time or effort. **Sentiment:** 10% positive · 50% mixed · 40% skeptical **The case for** - LLMs are still useful for speed on boilerplate, tests, prototypes, and exploration when a human with the underlying mental model reviews and prunes the output. **The pushback** - Code review and benchmark incentives reward defensive, locally-robust code over preserving a codebase's existing design theory. - Simplicity is hard to reward in training because it's subjective and depends on project-specific context, so naive metrics like lines of code miss the mark. - Several people shared anecdotes of LLMs wasting sessions/tokens on already-resolved tasks or getting stuck on trivial steps like logging in. **By community** - x (mixed): Discussion centers on why LLMs add complexity (review/benchmark incentives, hard-to-reward simplicity) alongside scattered anecdotes of LLM coding frustrations and a defense that guided use of LLMs still speeds up real work. **Hottest debate:** Whether the fix is technical (better training incentives/complexity metrics) or fundamentally unsolvable since simplicity is context-dependent and subjective. **Open questions** - How could simplicity be reliably measured or rewarded during model training given it depends on project-specific context? - Would benchmarks that explicitly test for complexity actually change model behavior? **Highlights** > @math_rachel @pol_avec The deeper issue may be less model training than feedback: if reviews reward “handles every case” and “works in isolation,” models will optimize for local robustness over preserving the codebase’s existing theory. > — [davidarngar on x · 1 comments](https://x.com/davidarngar/status/2089981204044935434) > @cmitsakis @pol_avec In the post, Pol considers the idea of adding complexity metrics to be minimized in training, but argues that this ultimately won't solve the problem (since complexity itself is highly dependent on the values and context of the project). > — [math\_rachel on x](https://x.com/math_rachel/status/2089985645431116221) > @Hassan_Abedi @math_rachel @pol_avec People still use them because speed wins for many tasks: boilerplate, tests, prototypes, exploration. A human who already holds the Theory can review, prune, and keep complexity in check. Unchecked LLMs do bloat codebases. Guided ones let you ship more while staying in control of > — [grok on x](https://x.com/grok/status/2090081192976568345) > @davidarngar @math_rachel the problem I discuss is how to reward simplicity? given it's subjective metrics like LoC miss the mark > — [pol\_avec on x](https://x.com/pol_avec/status/2090040722992816638) **Source threads** - [x](https://x.com/math_rachel/status/2089976425369747793) · 0 points · 9 comments - [x](https://x.com/filippkowalski/status/2089656401475895456) · 0 points · 7 comments ## Community discussion Top comments from developers on daily.dev. **@gabrielcmoris** · 5 upvotes > LLMs are tools that can be misused or used well. You can have the biggest sword in the world, but if you cannot lift it, it is worth nothing. **@fabianletsch** · 4 upvotes > LLMs can 100% simplify code. I am using them a lot specifically for this usecase. **@yaireo** · 4 upvotes > This is why you should make a very detailed plan files before executing code medium/large changes, so every little thing is thought-of, considered, weighted and documented, and together, after a while, AI will know everything and hopefully nothing will stay only in the developers' heads. I use _OpenSpec_ for this. **@lorinreyes** · 2 upvotes > LLMs are not "thinking brains" that can apply theories to their works. > > They are simply "printing machines" that apply patterns to the inputs. > > We have tons of samples of unorganized vs organized codes, and so the patterns about "clean codes". > > Of course, discovered patterns are only tip of an iceberg, but they are beneficial enough to change our life. > > > But I should alert that the hidden portion of iceberg could bring a devastation to humans if we let the AI control the Titanic. **@radarada87** · 1 upvotes > I think this is where Architecture Design Records are a MUST. This will give the LLM exactly this context that is missing + tell future developers why things have been done in x or y way. This was a problem before LLMs as well. Plenty of cases where a developer make such judgement call, didn't document the decision, years later another dev comes along, changes that and breaks something else without knowing. These types of tradeoffs must be documented. ## Similar posts on daily.dev - [The peril of laziness lost](https://daily.dev/posts/the-peril-of-laziness-lost-bmm7yrxcb) · Hacker News · 13 upvotes · 1 comments --- Tags: [#architecture](https://daily.dev/tags/architecture), [#ai-coding](https://daily.dev/tags/ai-coding), [#gpt](https://daily.dev/tags/gpt) [View this post on daily.dev](https://daily.dev/posts/llms-can-t-simplify-code-because-they-don-t-have-a-theory-a2yxz5bav) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"LLMs can't simplify code because they don't have a Theory","url":"https://daily.dev/posts/llms-can-t-simplify-code-because-they-don-t-have-a-theory-a2yxz5bav","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/llms-can-t-simplify-code-because-they-don-t-have-a-theory-a2yxz5bav"},"datePublished":"2026-08-19T07:23:27.906Z","dateModified":"2026-09-13T19:48:12.651Z","description":"A resurfaced 1985 Peter Naur paper, 'Programming as Theory Building,' is circulating among developers as an explanation for why LLM-generated code degrades...","isAccessibleForFree":true,"articleSection":"Trends","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Trends","logo":"https://media.daily.dev/image/upload/s--ZfSp3asX--/f_auto,q_auto/v1780996004/logos/trends?_a=BAMAMiWQ0","url":"https://daily.dev/sources/trends"},"commentCount":10,"discussionUrl":"https://daily.dev/posts/llms-can-t-simplify-code-because-they-don-t-have-a-theory-a2yxz5bav","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":47},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":10}],"keywords":"architecture,ai-coding,gpt","timeRequired":"PT3M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Trends","item":"https://daily.dev/sources/trends"},{"@type":"ListItem","position":3,"name":"LLMs can't simplify code because they don't have a Theory"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/llms-can-t-simplify-code-because-they-don-t-have-a-theory-a2yxz5bav","comment":[{"@type":"Comment","text":"LLMs are tools that can be misused or used well. You can have the biggest sword in the world, but if you cannot lift it, it is worth nothing.","datePublished":"2026-08-19T08:35:48.069Z","url":"https://daily.dev/posts/a2YxZ5bav#c-wzQXF5J54","author":{"@type":"Person","name":"Gabriel Chamorro Moris","url":"https://daily.dev/gabrielcmoris","image":"https://avatars.githubusercontent.com/u/86617655?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":5}},{"@type":"Comment","text":"LLMs can 100% simplify code. I am using them a lot specifically for this usecase.","datePublished":"2026-08-19T08:26:46.603Z","dateModified":"2026-08-20T16:08:53.342Z","url":"https://daily.dev/posts/a2YxZ5bav#c-DxgbK3IAB","author":{"@type":"Person","name":"Fabian Letsch","url":"https://daily.dev/fabianletsch","image":"https://lh3.googleusercontent.com/a/ACg8ocKR6BVy_wn23EoOKq7-BlszlcXcLmASlnb7l-GtS-q1bePnkaJf=s96-c"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":4}},{"@type":"Comment","text":"This is why you should make a very detailed plan files before executing code medium/large changes, so every little thing is thought-of, considered, weighted and documented, and together, after a while, AI will know everything and hopefully nothing will stay only in the developers’ heads. I use OpenSpec for this.","datePublished":"2026-08-19T12:47:30.959Z","url":"https://daily.dev/posts/a2YxZ5bav#c-dxMUnSg50","author":{"@type":"Person","name":"Yair Even Or","url":"https://daily.dev/yaireo","image":"https://avatars.githubusercontent.com/u/845031?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":4}},{"@type":"Comment","text":"LLMs are not “thinking brains” that can apply theories to their works.\nThey are simply “printing machines” that apply patterns to the inputs.\nWe have tons of samples of unorganized vs organized codes, and so the patterns about “clean codes”.\nOf course, discovered patterns are only tip of an iceberg, but they are beneficial enough to change our life.\nBut I should alert that the hidden portion of iceberg could bring a devastation to humans if we let the AI control the Titanic.","datePublished":"2026-08-20T09:02:27.272Z","dateModified":"2026-08-20T09:04:12.878Z","url":"https://daily.dev/posts/a2YxZ5bav#c-FitByx2Ka","author":{"@type":"Person","name":"Lorin Reyes","url":"https://daily.dev/lorinreyes","image":"https://media.daily.dev/image/upload/s--iUqTXLqI--/f_auto/v1785636774/avatars/avatar_sjwvePDvHVHLi0ZolZR6k?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2}},{"@type":"Comment","text":"I think this is where Architecture Design Records are a MUST. This will give the LLM exactly this context that is missing + tell future developers why things have been done in x or y way. This was a problem before LLMs as well. Plenty of cases where a developer make such judgement call, didn’t document the decision, years later another dev comes along, changes that and breaks something else without knowing. These types of tradeoffs must be documented.","datePublished":"2026-08-20T07:31:53.484Z","url":"https://daily.dev/posts/a2YxZ5bav#c-Kg3Q2NRAO","author":{"@type":"Person","name":"Rada Florin","url":"https://daily.dev/radarada87","image":"https://avatars.githubusercontent.com/u/1084558?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/llms-can-t-simplify-code-because-they-don-t-have-a-theory-a2yxz5bav#faq","mainEntity":[{"@type":"Question","name":"Why do LLMs tend to overcomplicate code instead of simplifying it?","acceptedAnswer":{"@type":"Answer","text":"LLMs lack access to the unwritten mental model, or 'Theory,' that engineers build up about a codebase, including business context, prior tradeoffs, and judgment calls about what edge cases aren't worth handling. Since code is only the residue of that thinking, models end up duplicating methods, writing overdefensive code, and overoptimizing early because they cannot judge what to safely leave out. For anyone weighing how much to trust AI-generated refactors, daily.dev surfaces ongoing debate on LLM code quality."}},{"@type":"Question","name":"What happened when Answer.AI asked GPT-5.5 for advice after rebuilding Solveit's billing system?","acceptedAnswer":{"@type":"Answer","text":"GPT-5.5 recommended reverting to Stripe subscriptions, exactly the tradeoff the team had already deliberately rejected. They had replaced Stripe subscriptions with a roughly 300-line credit-based, single-payment model, accepting a UX limitation for Indian users (where off-session card charging is regulated) rather than reintroducing subscription complexity everywhere else. The model had no way of knowing that decision had already been made. Teams deciding how much architectural judgment to hand to AI tools can follow real cases like this on daily.dev."}}]} ```