On the topic of LLM-generated software there is one thing I've only grown more concerned and confident about - the need for systems design and architecture thinking.
From what I've experienced, both anecdotally and first-hand, is that LLM-generated software systems eventually devolve, and when they do it happens quickly.
One deviation in a pattern (assuming they even existed to begin with) will very quickly spiral out of control. One extra API-endpoint will be considered authoritative and justification for another, slight variation of the first.
If a system continues to receive new components, new material it will eventually find itself in a desperate state of repair, possibly even to the extent that it will require such a massive refactor it may actually be cheaper to rebuild entirely.
These "cracks" will not exist in smaller pieces of software, they are simply too small to exhibit these patterns. But with sufficient enough code base, with reasonable complexity it will start showing up at the seams.
If someone were to tell me they have not seen this, I would genuinely render me incredulous as to how they have managed to instruct a system to never bend a written, or more probably unwritten, rule of system design and architecture.
So, back to the original point. Software generation may be "solved" but systems design and architecture sure as hell is not "solved" and no amount of prompting will easily solve this IMHO.
It requires contextual queues coming from business domain language, societal rules and guidelines, and just sometimes... very simple human intuitive reasoning about a feature.
#LLM #Programming #SystemDesign #SoftwareArchitecture
Christoffer S.
npub1nf…8yzp9
2026-09-15 10:21:34 UTC
Author Public Key
npub1nfcxlme0vu874ttzet99lr9z67qz2my0ks37y23fm5c3re7flynqp8yzp9Seen on
wss://relay.momostr.pinkPublished at
2026-09-15 10:21:34 UTCEvent JSON
{
"id": "6f8d71bf90ca186c091f7f92cdedfc5d5f5e70a0afbc9afdd80ea8bfee4fe0d0",
"pubkey": "9a706fef2f670feaad62caca5f8ca2d780256c8fb423e22a29dd3111e7c9f926",
"created_at": 1789467694,
"kind": 1,
"tags": [
[
"t",
"systemdesign"
],
[
"t",
"programming"
],
[
"t",
"softwarearchitecture"
],
[
"t",
"llm"
],
[
"proxy",
"https://swecyb.com/@nopatience/117274554853787487",
"web"
],
[
"proxy",
"https://swecyb.com/users/nopatience/statuses/117274554853787487",
"activitypub"
],
[
"L",
"pink.momostr"
],
[
"l",
"pink.momostr.activitypub:https://swecyb.com/users/nopatience/statuses/117274554853787487",
"pink.momostr"
],
[
"-"
]
],
"content": "On the topic of LLM-generated software there is one thing I've only grown more concerned and confident about - the need for systems design and architecture thinking.\n\nFrom what I've experienced, both anecdotally and first-hand, is that LLM-generated software systems eventually devolve, and when they do it happens quickly.\n\nOne deviation in a pattern (assuming they even existed to begin with) will very quickly spiral out of control. One extra API-endpoint will be considered authoritative and justification for another, slight variation of the first.\n\nIf a system continues to receive new components, new material it will eventually find itself in a desperate state of repair, possibly even to the extent that it will require such a massive refactor it may actually be cheaper to rebuild entirely.\n\nThese \"cracks\" will not exist in smaller pieces of software, they are simply too small to exhibit these patterns. But with sufficient enough code base, with reasonable complexity it will start showing up at the seams.\n\nIf someone were to tell me they have not seen this, I would genuinely render me incredulous as to how they have managed to instruct a system to never bend a written, or more probably unwritten, rule of system design and architecture.\n\nSo, back to the original point. Software generation may be \"solved\" but systems design and architecture sure as hell is not \"solved\" and no amount of prompting will easily solve this IMHO. \n\nIt requires contextual queues coming from business domain language, societal rules and guidelines, and just sometimes... very simple human intuitive reasoning about a feature.\n\n#LLM #Programming #SystemDesign #SoftwareArchitecture",
"sig": "1ffaccdede6e81d3cc6b06352db29999d190f1a5ad8893005ea1acb60d83d7a18a92a5f8d15ebe078de347ea9fb87bbf7cec0492317e8304f9a1563a17bdb48f"
}