The problem imo is the slow deterioration of institutional knowledge that offloading the mental task of wisdom gathering to AI is causing.
One interesting comparison is to the history of manufacturing. West/America decided one day that manufacturing would be cheaper to outsource and better (short term) profit was to be made by outsourcing it all to China. The institutional expertise started to deteriorate, to the point that America simply didn't even have the capacity, or expertise anymore to produce stuff (such as grill brush [1])
I feel like you could take all the handwavy comment that are made today to dismiss this caution, and find equal dismissal back then when companies were actively outsourcing the manufacturing.
"I'm coding 10x faster"
"look at the output velocity per employee"
"we are producing much more (in China)"
"look at profit / number of (manufacturing) employers"
Seems ok if you're American / Chinese but I'm struggling to understand how the rest can be OK with allowing institutional knowledge to deteriorate while having an active dependency to the former two. We already see this with the tech dependency towards USA and manufacturing competition from China.
> I feel like you could take all the handwavy comment that are made today to dismiss this caution, and find equal dismissal back then when companies were actively outsourcing the manufacturing.
Absolutely people were extremely dismissive to anyone saying that we're losing the ability to make things in this country!
There were all these theories like Comparative Advantage that people would trot out to point out that, if you don't like outsourcing, not only are you ignorant and backwards you're also probably racist.
I specifically remember seeing the ricardian tables, featuring 8th grade math proving how competitive advantage means everyone wins. This was very persuasive to me as a college sophomore, all my professors were on board and I was young.
I remember being a young guy, blue collar background, but in the left-wing anti-globalization movement (think Seattle WTO protester types).
When I was in college or going to parties with New Yorker Reader types I'd try to argue against globalization and they would start smugly dropping their theories on me. I was too young and naive to refute them in any kind of convincing way, but my life experience told me that it was wrong.
But it was pervasive in the zeitgeist. Basically anyone trying to argue against it was backwards and stupid, or shrill if they were lefty.
> But it was pervasive in the zeitgeist. Basically anyone trying to argue against it was backwards and stupid, or shrill if they were lefty.
It was so very weird. Even in Ireland (which was the target of the first wave of US outsourcing), people seemed to believe that everyone could be "knowledge workers" and that industry was unimportant.
I still don't really get why everyone believed this, but they did. Something something Upton Sinclair I guess.
I wonder if the exact date of anti-globalization switching from being a "left populism" to "right populism" thing could be determined.
However I'm not sure it could really be stopped or whether it was inevitable from containerization. Can you really prevent people from getting cheaper products forever?
Again containerization happened in the 1970s and 1980s. The China Shock was 2000-2010.
What technology was invented in 2000 that allowed everything to go to China? No technology. That was the year the US adopted Permanent Normalized Trade Relations with China. It was a government policy change!
By the way the US already had trade relations with China. All PNTR did was promise not to change the policy in the future. That was the starting gun that signaled to all American companies that they should start investing in production in China.
So would globalization happen on some scale just because of the march of technology? Sure. But the way it happened, the speed at which it happened and the extent to which it happened, were the result of policy choices.
I'm pretty sure that China demonstrating that they are a stable country, that they want foreign investment, that they won't gank your investment two weeks after you make it, and that they aren't going to do another Great Leap Forward may have had something to do with why foreign investment in it skyrocketed.
This sort of thing takes time, and by the 00s, enough time (and a recent Hong Kong transfer that did not result in mass liquidation) passed, and foreign investors were gaining confidence.
The world, and especially China has agency of its own, it isn't sorely driven by whatever American policy is it's flavour of the week.
Completely agree Jiang Zemin spent the 1990s courting global capital.
The point is that it wasn't technology it was policy, on the Chinese and American side, that drove the China Shock.
This was also what a lot of anti-globalization people were say at the time. The pro-globalization people were saying not only is it good but it's inevitable. There Is No Alternative.
The anti globalization people were saying if it's inevitable why does it need all these policy changes, trade agreements, and bigwig conferences?
Those would be part of the mechanisms of inevitability (under that hypothesis). Globalization is a phenomenon at the human societal level, they would be predicting human behaviors, it's not like rocks and rivers were going to precipitate it. It's not like those singular events "changed everything" either, it's an accumulation of decades of social sentiments, purchasing decisions, etc.
This whole subthread is from like an alternate timeline where the world actually found out or agreed that globalization was bad and stopped or slowed it somehow? Did the US meaningfully take back manufacturing or something?
If globalization is not inevitable, what's the alternative?
> The world, and especially China has agency of its own, it isn't sorely driven by whatever American policy is it's flavour of the week
Amen. A two-pole model is simple and attractive but the rest of the world is also, you know, doing stuff and buying things. America can, for example, preserve its car industry by refusing to allow Chinese EVs, but will gradually discover it has become uncompetitive overseas.
>Can you really prevent people from getting cheaper products forever?
Do you even want cheap products? We're all trapped in low-quality-product hell together, and some of us have realized we'd be less frustrated and less poor with something at least not-quite-so-low-quality.
If people could have realized that sooner, and if there had been some vision or political will at the top, stopping this would've been a matter of very boring policy decisions. It wasn't inevitable. Containerization might have made it easier, but it didn't make it irresistible.
anti-Globalization on the right has nothing in common with anti-Globalization on the left. The only thing they share is the name. And is probably the reason we don‘t call it anti-globalization any more, but rather simply anti-capitalism or more accurately anti-global capitalism, or anti-imperialism. Anti Neo-colonialism used to be popular but is already (and rightly so) falling out of fashion.
Even back then people on the left had a problem with the term globalization. On the left it was wildly recognized that the term came from the right to decorate global capitalism and (what was then called) Neo-colonialism in a more palatable light for liberals. In Iceland we used to make fun of it and said it should instead be called Americanization.
Right-wing anti-globalization is basically just hating foreigners (except white Americans), and supporting border fascism. Interestingly the right wing types in Europe love American culture, and have no problem with America spreading their capitalism and Neo-liberalism world wide (they only hate it when the EU does it).
Yes, economists famously do, and they also lack intelligence and knowledge given that their theories keep being proven wrong by reality but they never update them.
Economists have effectively become a priestly class, dressing up the ruling ideology in "science-y" robes so as to communicate authority. All social sciences are at risk of doing so, but they fall right into this hole the instant that they don't perceive the world as it exists.
A trained economist either sells out to the Overlords or he gets a job as a barkeep. Or he ends up as some crank in a half-forgotten nonprofit somewhere. There's no middle ground.
Human intelligence is a remarkable adaptation, but "tendency towards delusion" might be the decidedly maladaptive trait that comes with it.
And they were right. American manufacturing is $3 trillion/year, second only to China, and 1/5th of the entire world. American built airliners and American built engines fly all over the world. Millions of American cars come out of factories every year. American rockets put more into orbit than everyone else combined.
The idea that the US lost its manufacturing is not based in reality. One reason people think that is because people think cheap plastic crap and consumer electronics when they think “manufacturing.” Another reason is that US manufacturing has become highly efficient and automated, so a fairly small portion of the population works in it.
Yeah, your iPhone wasn’t built in the US. But the plane that got it here probably was.
Whatever analysis you make, let's use the correct numbers, from which you were off by about 1/5th. Should you think that is a negligible margin, you'd have to consider the US participation in global manufacturing output as similarly significant.
I'm sure fresh numbers are available, they're just unpublished.
We could do some educated guessing here - in the last 5 years China's economy grew at the rates of 8.6%, 3%, 5.4%, 5%, 5%, the US grew at 6.5%, 2.5%, 2.9%, 2.8%, 2.2%. We can extrapolate the manufacturing numbers based on that, which would give some advantage to the US because the US manufacturing lags the average, while the Chinese leads it.
Ok thank you for finding more up-to-date data for US manufacturing GDP. Let's re-do the analysis with 2025 data, because I draw the line at using annualized data for a year that has not yet ended.
So you were very much closer to the 3 trillion figure (again, 2026 annualized data is not current, it's forecast). Still quite off from the 1/5th of total. About the same as the EU - 3.03 trillions for 2025 (https://www.macrotrends.net/global-metrics/countries/euu/eur...)
In terms of participation in world total the US has come down from 22.44% in 1997 to 16.82% in 2025 losing 5.38 percentage points or a loss of over 1/5th in less than 30 years.
I'd say there is some justification to claim a decline in US manufacturing.
Again thank you for engaging productively and providing up to date data. I feel like I should offer praise as I chastised you for cursing at me for using data 4 years out of date.
There’s a decline in the relative share, but that’s down to the rest of the world growing. Adjusted for inflation, 1997 was slightly below the current figure. That’s nothing to brag about, but it’s a far cry from the “we don’t make anything anymore” narrative I see so much.
Where it has declined substantially is employment. That peaked at almost 20 million at the end of the 70s and is now under 13 million.
> The idea that the US lost its manufacturing is not based in reality.
But I disagree with your claim that people are right in being extremely dismissive of losses in US manufacturing.
>> Absolutely people were extremely dismissive to anyone saying that we're losing the ability to make things in this country!
Interpreting that as a complete loss of manufacture capacity I agree with you, with the qualification that concerns of relative decline were justified since there was a definite decline in aggregate.
I have to say that overall I don't think economies and citizens of these economies should prefer certain economic activities over others. In principle I think specialization is a good thing. On the other hand, I do think that the US has committed some strategy mistakes in terms of how much manufacturing activity was moved out of the country and how dependent it has come to be on foreign supplies of, for instance, rare earths and advanced IC.
But that analysis is predicated on US strategic goals and geopolitical intent. The coming impasse over Taiwan with China is almost completely self imposed due to the prioritization of short term corporate profit over strategic goals.
But that is a different conversation altogether. I think data from the past 30 years show that alarmism over de-industrialization was overblown as you said AND that there has been nonetheless a significant decline in the previously absolutely dominant position of the US economy in global manufacturing. If that is good or bad, to whom or to what ends, is way outside the scope of internet forum messages.
And do you know where the tools and dies to make those things come from? Where the robots that work at those lines come from? Where the chips in those robots at those lines come from?
Hint: not here. Even basic machining is cooked here. Go on Xometry and compare the pricing of any simple design made in USA vs. China and you’ll see, we can’t competitively do the basics anymore (you conflate basic with crap).
If you go back to WWII America was the China of the world: mass produced products if midrange quality.
Europe owned high end quality, especially Germany.
Most Radar technology was invented in the UK and then sent to the USA where American engineers would redesign it for mass production. You'd have a magnetron that the British machined at great expense and the Americans would redesign it so it could be stamped out by the thousands.
Germans would look at the wrecks of bombers they shot down. Early on they'd look at a B17 and say "this thing is crude" but by 1944 they'd look at a late model bomber and say "we don't even know how they made some of this stuff".
People have it entirely backwards. They think if you can do high end manufacturing the low end is easy. In fact if you can do mass production of low end parts with consistent quality then high end stuff is easy.
We can't manufacture most of those low-end things at competitive prices with developing nations - and we never will be able to (or else we have bigger problems).
So who's going to buy the low-end stuff at high-end prices?
You can try tariffs and the like (as we're foolishly doing right now) - that usually ends up having the opposite intended effect. You make everything more expensive domestically, including manufacturing (b/c your inputs got more expensive), and hurt our ability to export, even the things we did well.
Meanwhile, the rest of the world unencumbered with protectionism reaps the benefits of free trade and out competes us.
All this eventually leads to a loss of manufacturing jobs and output and manufacturers that can only sell to the domestic market (instead of the whole world). The whole sector starts to shrink. So that's no good.
America has lots of natural resources (even more when we're friendly with Canada) cheap electricity, good transportation infrastructure (historically).
China has to import much of their raw materials. Wood from SEA and Russia, oil from the middle east and Russia, even coal, ore and beef cattle from Australia! They don't have the water supply, forests, mines or oil that exist in North America.
There is no good reason for them to be the manufacturing center of the globe and there were rational reasons why the US was the center of manufacturing in the globe in the 20th century.
The reason they became the global center of manufacturing was policy choices in China and the US at the turn of this century, and the reason why they remain the center of manufacturing is they developed a massive amount of capital and know-how in an era where the USA was actively destroying its own.
China has plenty of coal. They import metal refining coal, which they don’t have. And they import thermal coal because it’s easier to boat the stuff in from Indonesia than move it east by rail from western China.
Australia was never very interested in being a manufacturing power house, they simply don’t have the people for it anyways, and it’s easier to ship raw material than finished goods vast distances. Russia has the same problem in population so China is convenient for them. China would have happened even if the USA didn’t help it along in 80s-90s.
Australia in the mid 70s was party to the Lima Declaration [1]
Presently there's a lot of yap how it didn't or wasn't the reason Australia lost its way to retain its manufacturing sector. Indirectly though it was bouncing around the walls of Govt and industry's board rooms and pushed decisions to reduce or discontinue ongoing training in regard to upskilling, or simply improving skill sets that might be needed in the unemployed working class.
However much of the shift way from general manufacturing was the inevitable result of the declaration, the inability for a small manufacturer in places like Australia to compete with cheap imports - I recall a relative back in 1979 - 80 having a long rant about a manufacturing company near him - the whole problem was the small dry cells the company purchased at quantity to install into an electronic device - the exact same branded dry cells were available to their oversea competition for next to nothing and could / did sell their version cheaper than the purchase price the company was paying for the batteries per unit.
The other part of the issue was those industries that opted to hang on - the bogey man here again was the thinking that it would be better / overall cheaper for manufacturing sector to be elsewhere overseas. Thus with this mindset setting fruit in the higher branches of the wealth market, there was not much help from Industry heads or Govt at the time to encourage or provide affordable means for whichever industry still hanging on, to modernise - textile being one that comes to mind. I actually had a strong belief (I knew no better from the propaganda being dribbled out,) 80s / early 90s that the reason the textile and clothing industry was falling off was overseas workers were paid a pittance, which made it hard for textile companies here to stay competitive - that was until someone who'd had travelled and had business interests though Asia and the US dispelled the usual propaganda I'd been suckling on, she corrected me on that it's not all sweat shops, and much of the textile base over in Asia had modernised quickly and been computerised for years.
One other metric the parent didn't mention: The US is #1 in the world in productivity per worker in manufacturing.
We're not the largest in absolute output, but we are literally the best manufacturer in the world, and we are the 2nd largest.
We manufacture lots of stuff, often the most state of the art and difficult things to manufacture. We're very good at it.
And we've sat around close to full employment for so long, the only way to convert more of the economy to manufacturing is to either import workers, cannibalize other sectors of the economy, or automate even more.
Yes, a larger share of the economy is services, but is there some objective optimal ratio of services to manufacturing we should be shooting for? If so, what is it? No one ever says.
Yeah but something something testosterone manliness degeneracy decadence.
Sending emails from an ergonomic chair for eight* hours a day and having to be civil to female coworkers and polite to your boss inherently degrades the male spirit in a way that permanently damaging and poisoning your body with 12-hour factory shifts with a foreman yelling at you doesn't. This is so self-evident and obvious that nobody even bothers to state it, it's just an assumed undercurrent in discussions of "bullshit jobs" etc.
Among others, yes. Nearly $100 billion in revenue last year. From your snark I guess we’re not supposed to count a manufacturer with revenue equaling the GDP of a small country because they’ve had some quality issues?
Boeing is not a healthy company it's a deeply sick company with a horrible internal culture. I know because I've spoken with people who work there.
The fact that leadership is focused on extracting profits out of the enterprise is also not a show of strength. It's a demonstration that they're trying to drain whatever value is left in it.
This is pretty much true of any of the American "greats:" Boeing, Intel, GE, GM, Corning. They're producing (or have recently been producing) great profits because they're eating their own seed corn. Nobody expects them to still be the businesses they currently are in another few decades.
The ecosystem to build cheap physical products is incredibly important for creating new wealth. If you're building something new, in manufacturing cities in China you can walk across the street and get everything you need. In the U.S. you have to fly to China and build relationships with Chinese suppliers. Which means creation of new products, which is where most future wealth will come from, is extremely difficult. This is like Germany lacking a meaningful tech ecosystem because creating tech startups is so difficult.
We can make planes and engines because we kept the expertise, and we can make rockets because of herculean efforts of a few people. This simply isn't good enough, we need to make creating new physical things as easy as possible.
This also applies to the UK: major manufacturer of turbines, i.e. Rolls Royce in Derbyshire. More electronics than you'd expect, but all short-run highly specialized things like satellites and scientific instruments and Martin-Baker ejection seats.
Massive numbers of people on production lines is not coming back. The rest of the economy is too well paid for that and automation too advanced. VW will retain car manufacturing in Europe by automating away its workforce, at the cost of high redundancies.
That's manufacturing based in dollars which is quite misleading. Rolling with your example of planes, this [1] is how a 737 looks in terms of manufacturing. Boeing does a lot of assembling, but the majority of the manufacturing is outsourced.
When people think of manufacturing they generally think of going from basic materials to something useful, rather than 'just' assembling quite advanced parts. Like if I go buy some parts and 'build' a PC that'd technically be manufacturing, and quite high value manufacturing if I was able to sell it at a good markup.
If you can’t see the direction and velocity of China you’re beyond hope
Americans cars are falling behind, they rely heavily on American cultural exports which relies on the world not thinking Americas are twats because the voted for Trump. Germany alone is over twice the size of America in terms of car exports. Including domestic destinations then china is three times the size of America.
America planes fall out of the sky far too often as Boeing pivoted from engineering to politics
Musk does good rockets. Not America. China is catching up and lost to overtake unless starship proves itself; and if it does China will copy that too.
Chinese planes are increasing very year, comac now about 15% of traffic, and heading towards about 20% in a decades time. and Boeing is about the same size as airbus at 40% each which will shrink as china catches up, won’t surprise me in 2050 is the largest provider of passenger planes is Chinese.
Why are you championing a system that benefits a smaller minority of people every year? Americans don't prosper when Apple sells iphones. Americans don't prosper when they sell more F150s. The sure as heck don't prosper when Boeing sells 747s either.
You literally are praising a system that condemned tens of millions of Americans to abject poverty because the rich wanted slightly better returns.
Those three companies employ hundreds of thousands of Americans. Millions more are employed by suppliers, contractors, dealers, etc. Selling iPhones, F-150s, and 7x7s is how those people make their living. In what sense are they not prospering from that?
Americans are better off than they've ever been. The improvement has disproportionately gone to the wealthy, but even the poorest have seen gains, not losses.
I don't understand this kind of comment. It's like some sort of disaster fantasy. Like you need it to be a crapsack world full of slums, so you come up with absurd takes like American companies employing huge number of Americans not contributing to American prosperity, and just make up troubles.
How is that the case? Apple, Ford, and Boeing are American companies that hire mostly Americans, with some number of H1-Bs. Those Americans pay taxes in California, Michigan, Washington, and elsewhere, and also to the federal government. Those taxes get redistributed to all of America, as determined by the budget as set by Congress and the President. We can complain about billionaires at the top not paying their fair share, and that the budget isn't set how you would, but largely, that is the deal. The workers on iPhone, the F150, the 7*7 pay their taxes in America. Those three are American success stories.
Boeing builds their planes in America, F150s are largely built in Michigan, iPhones are manufactured in China, but California is much richer because of the taxes that Apple employees pay. Millions of Americans are in poverty according to the latest census, but I don't know how you establish cause for that poverty being "that rich people wanted higher returns".
I think one other point is that demand for American goods has never been higher. I've had Europeans come to me with tears in their eyes saying 'sir, sir, we want more Fords'. There has never been a better car brand than an American one, that's for sure.
>“we don’t make anything anymore” narrative I see so much."
This conflating US financializing manufacturing vs actual industrial capacity, i.e. the entire manufacturing by value / MVA "cope". US objectively doesn't make much relative to past and a lot of shit US makes, US doesn't actually make, others does the actual making while US financializes and capture via spreadsheet maxxing, hedonic adjustments etc, and do insert "I made this meme" on things US fundamentally did not "make"
Like US does make some legitimate frontier stuff in house - the reality is is in aggregate industrial base terms, US MAKES / FABRICATES very little vs pre industrial chain hollow out, US does import a lot of subcomponents that others make, integrates, or outsource actual MAKING abroad while capturing intangibles like IP/patent fees that get bundled up into value add stats, but when people talk about making they're talking about extraction to factory gate pipeline. Not US can sell a bunch of foreign made goods with some CONUS final assembly or IP accounting because muh smile curve that attributes disproportionate "value" to US "makers". Consider a US widget co imports $10 of components assembles and sells for $40, the statistically manufacturing value add is $30 even though US did very little making. Now add tariffs, regulatory capture etc and widget sells for $50 and that's $40 of MVA for basically doing minimal M. Said US widget factory makes 10 widgets and adds $400 to MVA. Meanwhile a PRC widget company makes 100 identical widgets at $2 each... but their MVA is only $200, but they did literally all the making. These two industrial bases are not the same. Then a few years later, US BLS/BEA applies a statistical adjustment because widget X is slightly more performant... (prevalent in tech), so that widget is now listed as $100 equivalent utility, so hey manufacturing expanded (it didn't).
SpaceX... doesn't make that much... they make a few thing that are reusable and due to techstack can lift a lot, i.e. operational improvement (not discounting how game changing resuable is). But compare to PRC, who made like 2x-3x more first stages, i.e. their output is significantly higher, which is to say SpaceX is "making" at about American scale. For reference Boeing like ~30% domestic content, US auto ~50%. Reality is the ONLY thing US is REALLY good at making is refined fossil, agri, wood products etc. Almost everything else US very good at making money, but not the stuff.
TLDR US got much better at MAKING money from other people MAKING things. The other caveat is regulatory capture = US grossly overpay for mediocre shit, a lot of stuff that makes in US are just... not good, i.e. vehicles, but people trapped paying domestic premium which inflates value add but not actual relevant when people discuss US making things. US broadly makes a lot of mediocre overpriced things while population stuck shopping in company store for large items, that looks good on value add / productivity stats... but it's not reflection of industrial capacity which is what people think about in terms of real manufacturing.
What many people don't realize is why is America suddenly caring about manufacturing everything inhouse when Elites decided earlier Globalization was good, because China wants to command respect more than America. That is also the reason why Gold is pushing higher. If China was nobody, no nation would care for gold. So all these unnecessary downstream reasons distort what is actually going on.
If there was no China, Globalization would spread very strongly with Bangladesh manufacturing clothes and Milan doing the fashion show. All those calculations are coming undone. So please keep this main reason front and center when we discuss this matters.
Toyota would have gone bankrupt in post-War Japan if it wasn't from massive US demand in the Korean War.
The Vespa popularized by Hollywood's Roman Holiday propped up a post-War Italy.
Ping-Pong Diplomacy of the 70s gifted China its electronics manufacturing (think: PONG) turning it from a 3rd world backwater to what it is today. The exchange was in removing the 'Gang of Four' and the drugs associated with it.
---
The US was put into a privileged position as reserve currency of the WORLD in Bretton Woods. This is with the understanding/responsibility that the US would act as World Police and prop up foreign economies.
That’s a good point. I’m also going to bring race into this and say it’s also because the Chinese are not white. The same type of rhetoric was said about Japan in the 80s, but barely about Germany.
Even with how long Russia has been an antagonist, they are still seen as a “wayward brother.”
This analogy really only works assuming that maintaining [insert company]'s institutional expertise requires N engineers to maintain individual lines of code manually.
This is already showing not to be true with AI. Institutional knowledge is not the same as knowing how to implement low-level software details. Even today, every company does not need engineers to remember git cli syntax by memory, how to write parsers for JSON, or write the large amount of boilerplate from scratch that is at every software company. Most company's already hire engineers who have zero experience in the existing code base, yet they are productive despite this lack of institutional knowledge. For a company to maintain institutional knowledge they may only need N/K engineers.
We were already there at places with a lot of contractors, capped at 1 or 2 year stays. You saw teams of 10, 20, with 2 people with serious institutional knowledge. Now the contractors are just Claude
What really doesn't make sense to me is setting uniform token targets for all engineers. I'd be more interested in setting token ranges with hard limits for certain roles that see diminishing returns from the overuse of coding agents and where maintaining institutional knowledge, architectural awareness... is more valuable than moving as fast as possible. Like everything else, these limits should be adjusted over time as tooling for those roles improves but it really feels like there are human limits that organizations should avoid exceeding.
This breaks down at a sectorial level. If one company offloads that knowledge to the wider economy/world, fine. But if <<all> the companies in a domain/sector do it at the same time, at some point the destruction is extremely hard to undo.
Most of us can't hunt either. Somethings go away in time because they're no longer needed (by the masses). That is essentially what society does -- it allows us to multiply a few for the benefit of many so the many can focus on other things.
The resilience is more in ensuring archival process to ensure it's never lost forever, and a continuity plan to ensure enough (but few) people still know.
No, it wasn't. This often made claim is based on a passage of Phaedrus where Socrates is quoting an Egyptian legend, and the negative judgement of the invention of writing is done by a pharaoh inside that legend being told inside the dialogue.
Besides, the dialogue is not about writing itself, but about writing down political speeches and the consequences and impact of political speeches being read rather than heard.
Also, the dialogue dates from about three thousand years after writing was invented.
Some direct quotes from the dialogue:
SOCRATES: So, it is obvious to everyone that speech writing is not shameful, not in itself anyway (258d)
SOCRATES: We are left with the question of the appropriateness and inappropriateness of writing, and how it may be executed in a worthy or an inappropriate manner. Do you agree? (274b)
And this, a very relevant insight for an age when some are convinced that text analysis should suffice for intelligent work:
SOCRATES: Then a person who thinks he has left a skill in writing behind him, and anyone who, for his part, inherits this on the assumption that something clear and certain will emerge from writing, would be full of enormous silliness, and indeed ignorant of the prophetic words of Ammon in believing that written words are anything more than a reminder to a person who already knows whatever it is that the written words may refer to.
Ironically, the sharpest criticism Socrates made of writing in the often misread Phaedrus was of misreading texts.
We have significantly degraded in our ability to memorize e.g. epic poems or preserve oral traditions since the advent of writing.
I know that sounds trite in retrospect, given the benefits, and that's half the point. But there are real tradeoffs too! For example, culture has a LOT more generation-to-generation turnover as a result of literacy being common, making it unstable.
I think (?) my point was that Socrates equated Memory with Wisdom, and the invention of writing would impact Memory and thus Wisdom. I believe he was just plain wrong. Equating (manual) coding/code-review with Wisdom makes the same category error.
Writing had been invented three thousand years before Socrates
The passage criticizing the "invention of writing" is a quote from a legend where a Pharaoh passes negative judgement to a god, by the way, who had invented writing in the story.
Ironically, the dialogue in question, Phaedrus, is about the dangers of misreading text. It discusses writing political speeches not writing per se.
Was Socrates even wrong, though? There have certainly been millions of words written that were lacking in wisdom and have convinced people of falsehoods to their detriment! When’s the last time you saw a debate be reasonable? devoid of cheap jokes or hot takes? actually change someone’s mind? or the whole audience’s mind?
In the world where we didn’t outsource Western manufacturing to China, our homes would not be overflowing with disposable junk; in the world where the Luddites won, our wardrobes would not be stuffed full of disposable clothes; perhaps in the world where Socrates won our minds would not be jammed full of nonsense.
It's not really a case of 'winning' though is it? There is no agreed criteria by which to judge which is going to pass muster for a majority of people (both in Socrates time and ours).
I mean, you can s/“won”/“had their ideas reach a supermajority in the population such that their future (and our present) resembled the future they wanted instead of the future they worried the target of their ire would (and did) bring about”, or equivalent, at your leisure - I think my point stands either way.
One affects memorization and is a trade-off for writing, a process that arguably allows someone to work through their own knowledge of a subject and find or realize gaps in understanding.
Having something else do all of that for you is completely different and essentially tossing any gain outside of the creation of some gray slurry of an output in the trash.
>The institutional expertise started to deteriorate, to the point that America simply didn't even have the capacity, or expertise anymore to produce stuff
Right. And the spin I would put on your point: while the U.S. could never compete with outsourced labor, institutional manufacturing expertise could (you would think) still be valuable to startups finding some kind of niche in the manufacturing space.
With all this new 3D printing infrastructure, and constantly improving robotics, maybe some manufacturing efficiencies in some spaces could emerge that compete on cost and outcompete the cost of shipping stuff across an ocean. The availability of institutional expertise could be one of the necessary ingredients for mixing and matching the way to a new efficiency.
Yeah it's bleak in terms of automating away labor, but I'd like to think robotics is the next automated frontier after LLMs and we want to get there first.
Well I have seen many mediocre folks who confidently operate in India as they have licenses and things just work their way (CAs, lawyers, even a lot of diagnostic Doctors serving the very bottom and whose modus operandi is simply giving an antibiotic for everything). I am hoping that good AI will lift a lot of the mediocre ones at least 1 SD above.
Peace through global interdependence wasn't a bad side effect at all. The analogy only holds so much, but I'd wholly agree that any profound deterioration of skills across the board would create dependencies on AI infra that are on a whole new level.
At the very latest, when "AGI robots" will be commonplace and taking on the most crucial labour on our behalf.
I think this is a good point but we should see AI at the person level.
For your example, not all companies/people manufacture, but everyone has access to AI.
Soon a lot of people will lose skills to AI and at some point we would need them back and there won't be many skilled workers with it
I've been taking a "help me help myself" approach to interactions with LLMs. I might run my plan on how I'm going to build something past an AI asking it to critique it. I then incorporate that info into my original plan, or not. However, I am responsible for the design, I write the code. I started doing this because for decades I've been building my own programs since I learned to code just for the sheer fun of it (like many here) and I don't want to give that up to LLMs. I might as well let them play my video games for me.
I wish more people would at least consider this idea.
> The problem imo is the slow deterioration of institutional knowledge that offloading the mental task of wisdom gathering to AI is causing.
That's the whole point of Global managerial class even without AI. The idea is just by creating metrics one can measure how teams, groups, organization and whole industries are performing.
Before the current AI complex the previous one Agile Industry Complex One can see we starting producing 10x more code, 50x more JIRAs resolved, 100x more network bandwidth used. All these metrics tremendous gain in productivity.
Also it may not have been seen in US but in many places a change in political regime does want to burn down previously collected institutional knowledge because new dispensation have their own idea about what is knowledge, who will preserve it and how it will be preserved.
How come we cannot keep/define "specs" of how to manufacture such "mundane" objects such as a grill brush, everything from what raw materials are required, how should the assembly line(s) look like, which industrial robots or their human professional alternatives are required, etc. etc.
It just seems to me that fundamentally this is a knowledge organization problem.
I'm agreeing with you, in that yes it would be best and simple to solve "How come we cannot..." with some basic steps - but companies and industries often cut corners to the point of barely being viable long term.
Grill brush found out that the problem is chinese products are so much cheaper (without ascribing cause of that) that north american producers can only compete on native advertising (B2C) or purchasers that require a north american supply chain (B2B).
I think you missed their conclusions. The problem wasn't that China was a lot cheaper. The problem was that substantial subcomponent or process vendors only exist in china. Like, they could find American sheet metal stamping companies but they were all using custom tooling made in China because American tooling doesn't exist anymore.
Tooling is a high-skill trade. America used to be amazing at tooling. What's more, tooling isn't super cost sensitive because one tool can make thousands of parts.
When outsourcing to China began the tools would be made in the USA and shipped to China for the low-skill work. But over time those Chinese manufacturers figured out the tooling. What's more they realized that controlling the tooling would let them control the whole process.
They started doing things like, for instance, including the tooling in the price of the product so you don't even see it, if you use their tools. Just send them the cad file and they'll do the rest. So American tool making went away. But this was a conscious decision on the part of the Chinese manufacturer and an unconscious decision on the part of American importers who didn't really value their in-house expertise.
> The problem was that substantial subcomponent or process vendors only exist in china.
He found vendors in USA. They didn't call him back.
USA has manufacturing. But Americans want to drive cars and own their own home. In order to achieve that American manufacturers need high volume or high margin - better BBQ scrubber isn't either of those.
> What's more, tooling isn't super cost sensitive because one tool can make thousands of parts.
Tool making is highly sensitive to labor cost. Every article is a one-off. It can't be automated, often not even duplicated. There are tool and die makers in the USA but if you want to make consumer products you can't afford American tool and die because American tool and die makers want to drive cars and own their own homes. Chinese tool and die makers don't have the same expectations.
It is not unsurprising to find dev lacking knowledge in domain stuff that would be actually required if they were doing the development themselves, rather than outsource it to an LLM.
So the client who writes the ticket understand the domain, the LLM that implement it understand it too.
There is more to development than domain knowledge. There are decades of wisdom about development best practices on how to keep a large codebase maintainable, performant, testable, etc. that LLMs frequently don't follow. And now humans aren't practicing those skills either or passing down lessons learned to the next generation of programmers.
Maybe it will be no big deal, and nobody will read code anymore, but it is understandable why somebody might be concerned about it.
This hit close to home and I giggled over it for about 5 minutes. Both Europe and the US have so much potential but they're both mismanaged albeit in slightly different ways. There should be some way out of this mess.
The outsourcing of manufacturing was largely influenced by the externality of environmental pollution. People wanted to live in clean habitats. We had rivers on fire for weeks, extinction of species, and horrible pollution causing cancer and birth defects. Giving "the commies" the dirty, dangerous jobs, and moving everyone up into middle management and white collar knowledge work was seen as an evolution of the economy.
The political move to put all of that death and destruction onto China, where environmental regulation is willfully ignored in the interest of economics, was a smart move on their end.
We lost so much intellectual knowledge and other "tribal" technology in these processes to this outsourcing, which is unfortunate. We're almost having to rebuild our manufacturing from first principles, which may not be a bad thing.
Clean Air Act was passed in 1963. the Clean Water Act was passed in 1972. The China Shock began in 2000 after PNTR.
Avoiding environmental regulation was one reason to move factories to China, avoiding unions and high wages was another.
But the local communities weren't demanding that their factories be moved overseas so they could have a clean if impoverished towns. Your entire causality is completely backwards.
It isn't 100% causality, but it was definitely one of the ways it was sold to people through PR/propaganda.
Free trade / globalism was the larger "true" move, and yes getting away from unions and high wages to maximize profits was a big part.
Corporations made a change from valuing stakeholder value (employees, communities, customers, suppliers, the nation) to pure shareholder value (profits over everything else, despite the long term result that profits by any and all means hurts all stakeholders and eventually can cannibalize the company unless you have monopolistic moats).
I promise you the people in the towns where the factories were closing were 100% against it. And the corporations never tried to claim that "at least your town will be cleaner" probably because they were mostly leaving behind superfund sites they were trying to avoid cleaning up.
Was the New Yorker crowd clinking glasses together talking about how good it was to get the dirty steel mills out of the country? Sure maybe but this argument never resonated with anyone on the ground.
Were companies actively moving factories offshore so they could be dirtier because they didn't have to comply with American environmental laws? Absolutely.
it wasn't completely abolished. but the economics forced out the low-value-added work, only high-value manufacturing (and politically important manufacturing) remained.
> West/America decided one day that manufacturing would be cheaper to outsource and better (short term) profit was to be made by outsourcing it all to China. The institutional expertise started to deteriorate, to the point that America simply didn't even have the capacity, or expertise anymore to produce stuff
Americans produce the highest technology equipment in the world. Our machining base is structurally sound, but its all making weapons, so you don't hear about it.
It's true that China benefitted immensely from outsourcing, but they took the jobs Americans didn't want. It's the same with immigration today - folks cross the Rio Grande to do chores that Americans won't, or others fly in and work for nothing in academia while they wait for their PhD.
> The problem imo is the slow deterioration of institutional knowledge that offloading the mental task of wisdom gathering to AI is causing.
Have you considered the institutional knowledge could actually be actively preserved and distributed with AI? The kind of tacit knowledge that is situated and not readily preserved in a book might be absorbed by thinking machines and proliferated to the next person who needs it. The caveats would be trade secrets, skill differentiators, that people might not be willing to discuss, and manufacturing secrets of national importance. Maybe you can think of others.
>Have you considered the institutional knowledge could actually be actively preserved and distributed with AI?
Well that's what this whole debate comes down to. And, to my mind at least, it's a rare case of an actually interesting question about AI, because like the article says, it can plausibly deteriorate exactly that kind of knowledge. But as you note, it can also maintain it.
I think there's a sense in which it might do both at the same time. AI's version of on call tacit knowledge might be something like lazy-loading just-in-time tacit knowledge, but at the cost of who knows what cognitive paths we might have by keeping that knowledge resting in-house. We would gain real efficiency but we wouldn't know we wouldn't know.
>The kind of tacit knowledge that is situated and not readily preserved in a book might be absorbed by thinking machines and proliferated to the next person who needs it. The caveats would be trade secrets, skill differentiators, that people might not be willing to discuss, and manufacturing secrets of national importance. Maybe you can think of others.
It's funny that you credit AI with this (and I don't disagree), because tacit knowledge was exactly the thing Hubert Dreyfus spent a career insisting computers would never have, and his wisdom was taught to generations of undergraduates across the country and world who treated it as received wisdom and still is regarded as such in certain academic corners.
I edited that sentence to try and clarify a bit, but Dreyfus was a continental philosopher out of Berkley active basically from the 1950s to the 2010s. He engaged in decades of friendly debates with other philosophers about the limits of computers.
When he described those limits, he always frustrated computer scientists and analytic philosophers because he spoke in a kind of informal philosophical vocabulary and didn't really formalize his ideas. So he would say computers didn't have things like "tacit knowledge" or "insight" and he railed against "symbol manipulation". Famously he declared chess would never surpass human expert play. He wrote a book called "What Computers Can't Do" and another called "What Computer's Still Can't Do".
I personally think his argument was laughably wrong if well intentioned. But some people think it was respectable. I think in the present day, he's often rehabilitated with a kind of apologetic reinterpretation, such that things like transformers, weights, vectors, etc were what he really meant all along.
I think he was not wrong that some higher layer of sophistication would prove to be necessary, but he was wrong, I think definitively, to think that "symbol manipulation" of computers was a kind of category error. Even today's best models are still running on logic gates over 1's and 0's, and it was his failure of imagination to doubt that those could be the conceptual bedrock for AI, tacit knowledge and all.
He passed away in 2017, which is too bad because I would have loved to have seen his interpretation of things like GPT-6 Astra.
> think that "symbol manipulation" of computers was a kind of category error
This is where we do drift off into the semantic bog. If there is tacit knowledge in an LLM, then where is it? It must be in the weights, and it must have somehow come from the training data. Therefore the weights represent "compressed" knowledge. Is that then not "tacit" since it's explicitly encoded?
You'll get no disagreement from me here. But be ready because some people live to debate this, and Dreyfus is the poster child for a whole philosophical tradition.
I think what it comes down to, is trying to turn the specialness of human intelligence into undefinable magic, essentially playing god of the gaps with the concept of human insight. So by design, it has to be something that can't be amenable to any formal representation like weights.
> Famously he declared chess would never surpass human expert play. He wrote a book called "What Computers Can't Do" and another called "What Computer's Still Can't Do".
He never made such a claim. In the introduction to the 1972 print of this book he discusses the forecasts from Turing to his time of computers' abilities to play chess and the then state of the art. He criticizes the early optimism in 1950s mentioning that in 1957 H. Simon though in 10 years computers would excel in chess.
Dreyfus goes on to discuss the history of forecasts and progress in computer chess in a nuanced and highly informative analysis.
Whatever your opinion of his work I don't think it's fair to say his arguments are "laughably wrong" at any turn. I haven't read his books in detail but from what I know he made great contributions to the dialogue about technology and I don't know any instance of his making crass predictions or anything that he wrote that could be labelled "laughable".
Dreyfus certainly claims he was mischaracterized, but what he "really" said always turns out to be a conveniently moving target.
He thought that the complexity of chess rendered it solvable in principle but "uncomputable" in practice. You're right that he was speaking to the times he was familiar with, and what he meant by "impossible in practice" was something like letting a 1Mhz computer explore all the possible chess moves from now until the heat death of the universe. Relying on that to insist that computers defeating humans in his lifetime was consistent with what he envisioned stretches past charitability and into sophistry.
And I don't think you can extend him that charity without doing the same in the other direction, which would also collapse his basic thesis. Dreyfus was disproportionately preoccupied with retelling the failures of the 1950s over and over again using them to represent the whole of computing while the world moved on, and extending the same charitable repairs in favor of AI research make it something less easily caricatured, and still based on the same logic gates and 0s and 1s he was criticizing.
If that's not enough, Dreyfus explicitly said that what was lacking in chess programs was (1) any practical ability to do the brute forcing needed, (2) any kind of nim-style logical shortcuts around brute forcing or (3) any kind of expert level heuristics because he categorically believed those simply weren't programmable. And he believed that those exhausted the options. [1]
There's no version of this that can be correct because even if you think he's right that chess engines got better by progressing to some different conceptual paradigm, that paradigm is still embodied in same logic gates and 1's and 0's that he thought only pertained to prior paradigms he was criticizing. He was wrong to assume such things as "heuristics" were outside of that scope.
> I think there's a sense in which it might do both at the same time.
This is probably true.
Many artisan fabric techniques were lost when industrial looms displaced those jobs. But heavy industry enabled cloth to be manufactured at a rate that people were free to spend their time and money on other priorities - and now (centuries later) the society is in a sufficiently advanced stage of development that the old techniques are being rediscovered.
Perhaps the example underscores the importance of thoughtful preservation of insitutional knowledge.
> Americans produce the highest technology equipment in the world. Our machining base is structurally sound, but its all making weapons, so you don't hear about it.
It's also very automated so the jobs went away, but the US continues to manufactures a lot of things.
>Have you considered the institutional knowledge could actually be actively preserved and distributed with AI? The kind of tacit knowledge that is situated and not readily preserved in a book might be absorbed by thinking machines and proliferated to the next person who needs it. The caveats would be trade secrets, skill differentiators, that people might not be willing to discuss, and manufacturing secrets of national importance. Maybe you can think of others.
You don't develop "institutional knowledge" from a few prompts. It takes years to develop them.
> West/America decided one day that manufacturing would be cheaper to outsource and better (short term) profit was to be made by outsourcing it all to China.
Bogus nonsense.
1. Manufacturing output in West/America is higher than it ever was in history.
2. What has reduced over time is the number of people employed in manufacturing, not manufacturing output. And that's an effect of automation, same as it happened over centuries in agriculture.
3. West/America did not decide anything, the realities of capitalism did.
You're either a capitalist and embrace efficiency of producing where it makes sense (for many different reasons) or you're fine with inefficient third-tier industries.
The tax payer may help a handful of sectors that would otherwise die survive if they are truly critical for national security, but just a handful, not all of them.
There's a continuum between "vibe coded by someone with no technical knowledge or inclination" and "hand written domain driven design development". You can absolutely use coding agents AND have maintainable code. But yes, the coding agents will not magically make everything maintainable if you don't tell them to.
"Code maintainability and good architecture don’t have good measurements that we can apply"
Who has no wisdom? There are dozens of ways to measure code maintainability. Cyclomatic complexity is just one.
Nothing stops you from wiring up something like SonarQube metrics to your agentic coding workflow.
Plenty of measurements exist, but the trick, as the article said, is finding good measurements.
Cyclomatic complexity has been pretty solidly discredited within the maintainability research community for decades.
Sonar's cognitive complexity metric is a bit better, but here's a study that found that it still only has about a 0.5 correlation with how much difficulty programmers actually had reading code as measured by multiple methods.
They found that the most accurate way to measure code complexity that didn't involve something like an eye tracker or EEG is still basically just vibes - asking programmers if they thought it was hard to understand.
Halstead Effort came in second, and scored pretty well, but here's another one where it doesn't do so well, either. And it scores the SonarQube metrics even worse, with only a 0.35 correlation: https://www.sciencedirect.com/science/article/abs/pii/S01641...
Yeah, we have this rule in our SQ and I absolutely hate it because of the number of times I'm forced to break something up. Complexity that matters is usually at a higher, more architectural level.
Yeah. Looking at the code samples in that first page was pretty interesting. They're cherry-picked, of course, but still it's a little galling to see which ones SQ gave a lower score.
I definitely wouldn't want AI to be autonomously using that as a guide without doing some fairly serious internal A/B testing first. Kind of like for cyclomatic complexity, it's just too easy to find ways to maliciously comply. And if that's what you ask AI to do then that's likely what you're going to get.
I agree with the larger point, but here I'll disagree:
> There are dozens of ways to measure code maintainability.
There are no good ways. I'm averse to making absolute statements, but here I'll take that chance. I worked in dev producitivy for years with people who spent decades in that domain across multiple companies with very high volumes of code production. Everybody agreed: All metrics are flawed and even a combination of metrics is insufficient.
Just to give one fundamental reason (in addition to a lot of the sibling comments): for any given metric there are an infinite set of counter-examples that don't trigger any thresholds but are clearly bad code. So these metrics typically only help in trivial cases, don't catch a majority of the cases, and so often become more of an annoyance due to low SNR. A lot of dev productivity work ends up being wiring these metrics in and then providing escape hatches when they inevitably get too noisy!
And most relevant to this discussion: these tools do not say anything about higher-level concerns like architecture, over-engineering and design, which IME is where agents tend to mess up most. I've almost never had a complaint about the code itself; the logic, naming, functions, data structures, even a lot of the testing, are all on point. It's always been the higher-level structure and design: over-engineering, duplicate classes, suboptimal abstractions, redundant operations across layers that could be solved by adding a single variable in a class, etc. etc.
I think the problem, like with code written by humans, is lack of sufficient context while doing a task leading to tunnel-vision. This is why we need to oversee and ensure things are good holistically. I suspect models are now good enough to play the role of an architect as well, though, and I've read some indications of that online... I just haven't tried giving them that much control yet.
> There's a continuum between "vibe coded by someone with no technical knowledge or inclination" and "hand written domain driven design development". You can absolutely use coding agents AND have maintainable code. But yes, the coding agents will not magically make everything maintainable if you don't tell them to.
Yes. But I think the idea is without "hand written domain driven design development" the result trends to "vibe coded by someone with no technical knowledge or inclination," as developers de-skill.
- lot of (most?) people can do basic multiplication (I’m too lazy to fetch any stats but I hope you’ll have some observations in your bubble dear reader)
So are you agreeing with me or not? Because it's not black and white. Having a few non-deskilled developers around who do the equivalent of "compete in mental calculations" is the same as having none at all.
It's sort of like the retort "AI won't take all the jobs from humans, some will be left [at the very top and very bottom]." Even if true, fat lot of good it does most people who would be unemployed in that scenario.
Also, if you get widespread deskilling, but massive increases in code production due to AI, you're probably still going to get "organizations falling into the trap" like the OP describes and the remaining skilled people getting burned out trying to hold it all together. Modern American business culture (in aggregate) is incapable of learning to not burn people out until everyone is already burned out, only then will it pay attention to the problem (and then probably forget what they learned and start repeat it in 10 years).
> So are you agreeing with me or not?
I’m disagreeing with black or white view.
You make it
A bit black or white.
Llm will not take jobs, at worst it will shift jobs.
If we will allow current llm to develop code without inspecting it, we will still want to provide direction and expect certain quality level. So in “worst” case you will need at least design/QA people.
If code will be free, and it will increase 1000x, you probably will need 100x design/QA people. (Unit tests written by same llm, if not reviewed are worthless as assurance). I’m absolutely certain that humans will have plenty of software related jobs.
As to programmer deskilling, another parallel: lot of programmers have very little knowledge of how to deal with databases correctly/efficiently, because they are somewhat lazy and good tooling/orms allow to get away with it, but there are also plenty of devs who do know how db works and how to design a db schema for their app access as it improves overall system performance and correctness. Same with LLM case, having knowledge of what happens in code, gives an edge, and competitive/curious/overly-responsible people will continue reading things in depth (llms also make learning somewhat easier). And its definitely not 1%.
Furthermore, llm prices are subsidised a lot now, so it’s yet to be seen if llms are economically viable as vibe coding agents on a large scale.
Our class sizes at the university that I teach at have plummeted with the crash. What I'm hoping is that this means I'm just going to be teaching people who are actually interested in producing quality code.
//There's a continuum between "vibe coded by someone with no technical knowledge or inclination" and "hand written domain driven design development".
Somewhere in the middle of that continuum sits - "domain driven specifications, described using high level english concepts(that are well defined) from the domain , combined with a selection of a few standard architectures"
I agree that "maintainability" is the wrong place to stake one's flag. It's a technical problem and will probably be overcome.
The "lack of wisdom" in AI coded projects which does not strike me as a soluble technical problem concerns questions like: which software is worth writing and which isn't? How are tradeoffs evaluated?
I don't think AIs are structurally capable of answering these questions in the same way humans are. But they make those decisions anyway!
Those metrics don't amount to wisdom. Wisdom is something like realizing that you don't have to special-case some code over <here>, you just need to create a new reusable primitive over <there> that fixes two bugs with one stone, and you'd probably wind up needing it anyway. Both bits of code could sail through all the measurements of code maintainability you could come up with, and an agent suggest to me the brittle solution, but I came up with the more maintainable one.
> yes, the coding agents will not magically make everything maintainable if you don't tell them to.
There's the rub. It requires knowing about and caring about maintainability. And a lot of the people who "haven't written a line of code since 2025" don't care
Humans aren't magical, so if people can figure out what maintainable code is and how to write it, so can a non-human. Furthermore, humans are rather unlikely to be the optimal form of intelligence for software architecture and engineering, so it's almost certainly the case that if humans can figure it out, some non-human could do it better. That it's not yet solved by models suggests that it's not easy and maybe even not practically achievable with current tools. But that's not the same thing as not solvable.
> Furthermore, humans are rather unlikely to be the optimal form of intelligence for software architecture and engineering
I like this framing. Humans invented software (and engineering in general) as a means to solve problems with methods that work best for us. There may be entirely different, and parallel, problem-solving methodologies outside of human best-practices.
I have not found it difficult to get these systems to write maintainable code. You're probably correct that most people don't care about this so they don't bother to do so. But IMO, this doesn't seem like a problem that is crying out for a solution.
> But yes, the coding agents will not magically make everything maintainable if you don't tell them to.
You say that like adding "Make it maintainable." to your prompts solves the problem. But the reality is we only have weak metrics for measuring maintainability. For example, you can trivially optimize for Cyclomatic complexity by blowing away abstractions and duplicating code everywhere. That doesn't make the code better. Cyclomatic complexity is a tool that has to be applied judiciously.
That doesn't mean you can't or shouldn't use AI to generate code. But it does mean if you want your project to scale, you're still going to need a lot of developer involvement at the code level to ensure the code remains maintainable so that future developers can build on top of it. AI is not like compilers, which allow developers to build complex solutions without being proficient at the next level down (assembly).
The author admits to a measurement: maintainability. There are quantitative and qualitative ways to measure this, the biggest signal being outright abandonment
That's terrible as a signal. It's too late for anything, and there's many reasons things get abandoned.
> code maintainability and good architecture don’t have good measurements that we can apply, because it takes months, years even, to notice the effects of bad architecture or of unmaintainable code.
One way of understanding "good" here is "actionable", imho.
> But yes, the coding agents will not magically make everything maintainable if you don't tell them to.
But that's not actually a change. Humans wouldn't magically make everything maintainable if you don't tell them to (and maybe not even if you do). You have to monitor them and train them, carefully, basically forever.
Maybe not forever. Humans you have to do it basically forever, because humans don't improve very fast. AI... you have to do it forever with the current level of tech. If the tech improves enough, who knows?
> You can absolutely use coding agents AND have maintainable code. But yes, the coding agents will not magically make everything maintainable if you don't tell them to.
The trillion dollar question is how you do this, if your employees do not care (they are optimising for salary & time spent not code quality) and you have no way of telling apart AI slop vs. good maintainable code. (If you could you would just train the AI.)
Before AI there was at least some way to tell apart good programmers from bad, because there was some human effort involved in coding. Now with AI and slop generation there is almost now way to do this.
> if your employees do not care (they are optimising for salary & time spent not code quality)...
From what I see is it's mainly managers and higher brass who doesn't care about code quality and sustainability, and aims to drive time to market metrics down aggressively with AI.
Any employee who cares about code quality will become a poor performer with a red luddite label because they dare to change what the AI has emitted for them.
I'd love to be wrong, very wrong about this, actually.
They don't care about maintainability because they're not going to be debugging it at 1am on Friday night but mainly because if something is wrong they have lots of people below them to blame for it.
Developers, however, are still responsible for the code! We must review the AI....all 80k lines of code it generated yesterday. If we don't then we are at fault. And we must go full throttle of course. So ....not be picky and retrograde about accepting what is generated.....
IOW we know who is going to get screwed and it isn't them.
Yeah but I mean, what is their compensation based on? I'm genuinely pretty curious about the point you're making here. I don't know anything about underwriting or how that profession works or how it is analogous to what you see as the future for software developers. But it seems interesting and possibly insightful.
I often have to ask myself if I’m asking for something different because of preference or need. I don’t really know what others are doing but I see this comment a lot about needing to always correct agents. I can’t figure out if it’s an exaggeration or not because once I’ve planned how I want something done I pretty much have zero need to intervene.
Impossible to know without doing a detailed comparison. Are you using the same LLMs? Are your criteria for correcting the output the same? Are you working on similar code? Are your plans and prompts the same?
It's fine to have preferences. The biggest problem with bikeshedding is the time spent (wasted) debating. But you don't have to debate the AI, you just tell it your preferences, and ideally encode them so that they are repeatable.
Of course it's fine to have preferences. I think you missed the nuance. Bikeshedding implies the time is wasted because the topic wasn't important in the first place. The color of the bike shed, as it were, has nothing to do with the storing of the bikes.
I am equating the nerve that develops in people that get lost bikeshedding (wasting time on inconsequential parts of the problem) with fighting an llm on inconsequential implementation details.
We most certainly agree: what matters should always be the actual requirements (functional, security, performance, etc.) You can't bikeshed an important topic. Everything else is implementers decision. In my experience an experienced engineer understands the difference and trusts implementers to make the decisions that they do own.
No I understand the nuance. But it's only bad to have preferences about things that barely matter if you waste time on them. You don't have to fight the llm, you just tell it what you prefer and it does that, that's what's great about them. (If it is not listening to your directives, then you have other problems.)
You use the intentionally vague word "implementers" to abstract whether you're delegating to a human or to an AI. But the key point is that these are not the same thing. If I'm delegating to a person, that person is the "implementer". If I'm using an AI to generate an implementation, I am still the "implementer", it is merely a computer program working on my behalf.
Directing an AI's work is not "fighting it". You keep characterizing it that way, but it's the wrong characterization. "Implementer" is not blurry at all. Humans are responsible for the things they implement, whether or not they use AI tooling to do that implementation.
Is that my characterization? This subthread is about how it’s so time consuming fixing every little thing the AI does to be just like you would have done. My challenge to that sentiment is “give it some freedom, don’t micromanage it.” That’s all.
I understand the boundaries of ownership and responsibility. That’s why I can tell you if you are spending inordinate amounts of time correcting AI code then you’re doing something wrong. Either write the code yourself or reassess your ownership boundaries. You’re acting as a manager of a team of agents in an agentic coding paradigm. Managers don’t tell me how to write code.
Without going and re reading the whole thread, I'm pretty sure that both of your comments that I replied to included this "fighting the AI" characterization. It's certainly fair that you didn't start the thread about it but were just taking the premise of the sub thread. But I just disagree with that whole premise. I think what's nice about these tools is that I can just write a document that says things like "prefer immutability" and then I neither need to micromanage nor accept code I don't like, and there is no long slack thread about whether I'm right about any of the things I've written into those rules, the AIs are happy to do as I've asked.
I think this entire analogy about being a manager of a team of agents that is in vogue is completely misguided. Have I always been the manager of a team of bash scripts? No. These tools are way more capable, but they are still just tools that I'm using to do my own work, they are not people that I'm delegating responsibility to.
> I think what's nice about these tools is that I can just write a document that says things like "prefer immutability" and then I neither need to micromanage nor accept code I don't like
Why are we even arguing then? You and I agree. Did I ever say "don't share a single preference with the AI"? You set the guardrails and preferences and the AI follows them. This is how it's always worked so it's reasonable for me to assume that people "fighting the AI" have already done this and are being overly pedantic about the output. Otherwise it wouldn't be eating up inordinate amounts of time...
> Have I always been the manager of a team of bash scripts? No.
No. You're not even remotely close here. Let's revisit this once you've figure out how to have a team of bash scripts implement 100k lines of code and build entire systems in 2 weeks based on high level instructions and requirements shared in context and prompts. You have responsibility at a different level and scale in an AI native workflow.
I don't know why we're arguing about the first thing :)
But I think we have a real disagreement about the second thing. You don't "have responsibility at a different level and scale in an AI native workflow", you're still using tools. I understand that what you're saying is that it's such a difference in scale that it is a difference in kind. But I don't agree. I'm fundamentally at odds with this entire framing of ai agents as a team that is being managed. I don't like any of the anthropomorphizing of ai tools. It's fine if it's just an analogy, but people take it way too seriously as a real thing IMO. I fully recognize that I'm out of step with the prevailing discourse on this, but it's a genuine disagreement, I'm not confused about what other people think.
"Hey look I got this brand new tool it can do everything my old tools did and more but I'm scared to use it to do more--might shoot myself in the foot."
I think most people have felt that way before. Only way forward is to practice with the new tool (=
> From what I see is it's mainly managers and higher brass who doesn't care about code quality and sustainability, and aims to drive time to market metrics down aggressively with AI.
Trends over time will drive more observable changes. If a whole generation of programmers picks up bad habits that their managers don't care about (think very junior), that will take some time to play out. It's like children's literacy. You don't notice overnight, but a decade of neglect and you have a reading problem in kids.
Yes, this is why it's good that we're having these debates. We should keep having them. Personally, I am not yet convinced that this is a real problem. But I also haven't yet worked on a team with people who have entered the field in the last few years.
> Any employee who cares about code quality will become a poor performer with a red luddite label because they dare to change what the AI has emitted for them.
I think that's true but it's a special case. AI is here to stay and with AI coding IS faster and quality is better than ever before. Ideally you want your luddite fired along with the slop generators and keep the ones who are using AI and taking their time to deliver a maintainable code.
"Luddites" can just be the ones pointing out the Emperor's new clothes have a big hole in them. Removing them is just ensuring that whatever mistakes you're making get reinforced.
> ... with AI coding IS faster and quality is better than ever before.
Is this claim based on something?
I'm not against or "for" AI (whatever that means), I try to use it as effectively I can, but for me it's not at all obvious that quality is better than ever before.
Speed I can buy, especially in new projects and utilities, but quality? At least I haven't seen this in practice, if anything I'm just seeing more code, issues, PR's and pressure ==> more slop, more bugs, less quality.
You can always say "skill issue" and "process issue", but that's partly my point here, AI doesn't magically solve this.
Presumably it is based on that person's personal experiences, like your own comment and all the other comments here?
Speaking for myself, based on my own personal experiences, quality is by far the bigger advantage of these tools. It has never ever been easier to write automated tests and to automate tedious manual validation. I'm running my code through like 10x more paces than I ever did before, because I can just say "hey try running this in these twenty different ways" (including with browser automation, if that's relevant), without needing to either do the tedious steps to run all that or to take the time to write a script to do it, and to compile and attach the findings to the PR. This saves me hours to days of work on validation, but the reality is that I just wouldn't have spent that time in the past, I just stopped at a lower bar for quality, because I couldn't justify the ROI for spending all that time on it. But now the ROI is huge, so it's a no brainer.
If people are not taking advantage of this, then yes, that is literally a skill issue.
For some reason this reminds me A LOT of past discussions about microservices, most wonderful on paper and forever debated, but I've never seen it work out perfectly in practice, for me it's mostly been a cluster F in most companies that adopted them.
Currently I see AI similarly, in theory perfect, in practice I don't see the claimed effects. So yes, skill issue, but skills are relevant and your company probably can't hire a rockstar team (if that matters in the future).
But your comment on personal experiences was very good! Spot on, we are all biased, easy to forget. Thank you for that.
> If people are not taking advantage of this, then yes, that is literally a skill issue.
...or domain. You said "including with browser automation", so you do web or web-adjacent development.
Not all of us are doing that. What I work on doesn't have any UI or output besides a log file most of the time, but it connects to many places and does many things like an octopus, but nobody sees that, but feels that it's there because their environment keeps on working.
I said "if that's relevant" and you jumped to "this guy just makes websites". I do many things.
The octopus you just described sounds to me like an excellent example of what having the ability to more easily do tedious validation is most useful for. If you know that the "environment keeps on working", there must be some way for you to observe that fact. And if it is an octopus, it is likely difficult and/or to change the conditions and observe the correctness with respect to those changes. I find it so much easier to do this exact kind of thing now. Or, "easier" really isn't the right word. It's that the activation energy is low enough now that I'm able to do a lot of things up front that I used to rely on runtime monitoring to validate.
I guess YMMV, and it's not magic, but for me it totally changes the calculation on when it makes sense to automate something (like that chart from the old xkcd about how many times you'll do the thing and how long it takes to automate) in a way that means I'm doing a bunch of things that are useful for quality that just would never have passed the bar in the past.
> I said "if that's relevant" and you jumped to "this guy just makes websites". I do many things.
I didn't. I made a guess. I might be wrong, that's OK. I love to be wrong, because I learn things by being wrong. Also no offense was intended, and I don't consider webdev inferior anything. What I tried to mean is, if AI has more training data for a domain, it does better. If you fire the same model on a niche domain, it falls flat.
> If you know that the "environment keeps on working", there must be some way for you to observe that fact.
Yes.
> And if it is an octopus, it is likely difficult and/or to change the conditions and observe the correctness with respect to those changes.
Nope. On the contrary, because there's so much innate knowledge that is required to know what to do, simulating in mind, deploying and testing on real world is much easier and faster than letting loose an ML model on it. You need real data, real data comes in slow, but you can catch problems early and easily.
Considering it's a niche area, AI also doesn't have much training on that domain, so it's doubly inapplicable for what we do.
> but for me it totally changes the calculation on when it makes sense to automate something ... (snipped for brevity)
It's great that if it works for you, but YMMV part is way more correct than people want to accept and want to learn. AI is a pneumatic hammer, but not everything is a nail which can be driven in with that.
When it works, it works. When it doesn't, well people still pretend it does or insists it shall. We must accept the limitations.
> deploying and testing on real world is much easier and faster than letting loose an ML model on it.
No this is what you're not getting. It is "doing the things I would do to deploy and test in the real world, but faster and in the background while I do other things", it is not "letting loose an ML model on it". This is the new capability. If you have any process like "do {action}, wait until {something}, check {something}, determine if it matches expectation", it is now possible to run that loop way more times in way more variants without either spending the time on it synchronously oneself or writing a script to do it. (If you do that specific action loop often enough, it's probably worth writing the script anyway, but that's also much quicker to do now.)
The AI doesn't need training on the domain, it just needs to be told "these are the things I would do, please do them for me and report back".
I'm sympathetic to not everything being nail-like, but I really think you're leaving a lot of chips on the table if you can't imagine any of this kind of action-check-evaluate loop you have that you could offload.
I'm saying you could do more things. Instead of waiting until a new thing is merged so that it can be deployed and waiting for monitoring to catch issues, you could be deploying pre-merge to testbeds, using different variants of the code or different configurations of the whole system or different inputs to exercise edge and corner cases. Maybe it's too complex of a system to set up that kind of testbed or simulation? Well, it's easier to do that now too! I can spin up and down environments, either with containers on my workstation, or in cloud deployments, that I would have not attempted in the past, because it would have taken me too long to set them up. But now it doesn't take that long, and I find it super valuable to be able to try more things out. (Cost is still a real constraint, I'm not saying that constraints magically no longer exist.)
Obviously I have no idea what your work looks like! But what I'm saying is that time savings are not just time savings. There can be a point at which the time savings bring you under an "activation energy" such that it unlocks a new capability, not just a speedup. And some of those unlocked capabilities can be directed toward improving the quality of software. And I think that's awesome and useful, is my prevailing point here. I won't claim that it will usher in an industry wide improvement in quality or anything, but for me personally, I'm making better software more quickly now, and I'm very pleased that I can do that.
I fully agree with this point about quality. I am doing so much more testing than I used to, because I have so much more time to do it, and it's so much easier to automate the more tedious kinds of validation.
Maybe it's true that lots of people aren't taking advantage of this and are shipping trash, but that's their own problem, and there have always been people who do the job poorly.
That's true, but it doesn't have to stay in this form.
> with AI coding IS faster and quality is better than ever before.
Citation needed, because the last study I read about was painting a completely different picture about code quality. Also, just because the AI pulling and remixing code from a known repository with high quality doesn't mean your code will be at the same quality automatically. Passing tests is not enough.
> Ideally you want your luddite fired along with the slop generators.
The thing is it's not possible to see who generates slop and who generates code, and if you fire the only people who knows about the codebase intimately, you'll be on a very exciting, possibly fatal ride. I don't recommend this. AI doesn't know your history and trade-offs. These guys do, and can guide you to clear.
AI can't.
Believing that AI will create bug-free code from start is believing that Rust is the silver bullet.
The reason that we can (not that everyone, or even most people will) create higher quality software now is that it is now much easier to try out a bunch of edge and corner cases, which would have previously often required a prohibitive amount of time to set up and run. It's a dream! I can certainly believe that people aren't taking advantage of this, but they should be!
But I totally agree with you about the measurement problem. I think it's a very difficult time to be a hiring and firing manager.
> The thing is it's not possible to see who generates slop and who generates code, and if you fire the only people who knows about the codebase intimately, you'll be on a very exciting, possibly fatal ride. I don't recommend this.
This is exactly what I said in my top comment. This is a huge problem.
"Just do everything to hold things together, and let me abuse you without complaint" is exactly the kind of patronizing sentiment that infests the tech adjacent scene these days.
The answer to that is "Fuck you, no. I have worth, and you will respect it". Gilded Age paternalisms are not something that needs to be brought back into vogue unchallenged, especially when the intent is to keep the rabble quiet, and the checks rolling in and up.
No, the luddite is the person in one bad location on the continuum, opposite the AI psychotic on the other bad end of the spectrum. The person holding everything together is the one applying wisdom to the use of tools for the things they are good at while avoiding the things they are bad at, rather than blindly following one ideology or its opposite.
Sorry, but you're distorting my framing of the term in my original comment.
I labeled the person who uses AI to generate code and uses their brain and wisdom about the system to refine that code as the luddite since they will work slower when compared to other "higher performers" who don't care about the code quality.
In my framing I'm aware that the person is not a luddite per-se, but will look like it since they will be slower while trying to create better code, albeit using AI in the process as well.
Citing myself:
> Any employee who cares about code quality will become a poor performer with a red luddite label because they dare to change what the AI has emitted for them.
Chances are high the luddite is the one with the deepest understanding about the product and the code base - the one who is actually passionate about the project and actually cares.
Maybe? This does not seem to be in evidence to me. In my experience thus far, this seems to be way more of a personality and ideology split than a depth of understanding split. On my teams thus far, I've seen the deepest experts land on opposite sides of this question.
That could be the case. But if other companies figure out a way to deliver good code with AI, then the company with the luddites is going bankrupt. Luddites are better than slop generators, but both are worse against a developer with AI who actually cares and has a deep understanding of the code base and programming.
Well, and that's how you get enshittification everywhere. Everyone just cares about time to market, consumers are left to drown among a sea of slop, and honest businesses go down because they cannot stand a chance against slop peddlers flush with VC money.
Enshittification happens after the company was quick to deliver a working solution. They successfully captured the market, killed off the competition and now they are ready to start milking the customers who have no other choice.
AI slop can actually help with this, because it reduces the cost of replacing their enshittificated software.
The reason its hard to dethrone Facebook, Instagram, YouTube, Twitch, etc. Is not because it's hard to recreate the software (it may or may not be) it's because of network effects, budgets, etc.
And unless you have ownership level stake in the company, you *shouldnt* care about what happens downstream of selling labor to the company. Yes, I highly recommend 8 and skate.
Ive seen soooo many people burnt out, or "ive given years to the company and i got hit with layoffs", or "$200 software would have saved $1000000 when I brought it up to them". And companies will throw you away the MOMENT your usefulness is gone, even if just perceived. So, use them just as much as they use you.
And that idea of slacker is ALSO a way to generate more money for you, by slyly withholding or slowing work. I didnt get my paltry 3% last year. Inflation up 15% or whatever stupid number. But I can control how much work I do, so my effective wage/hour stays with inflation.
Save your caring for your personal projects, nonprofits you help at, your and family/friends labor you help with.
With some. You insisted, so let's get into the details.
1. Caring about the company when you are a worker and not owner?
Yes and no. I don't care about the company. I do care about what I do. It's a self-respect matter. I do good work not because I'm a slave to company, but because of self respect. My deal is simple: "I'll do my best to produce the best artifact and push the company further as long as it doesn't conflict with my personal principles, you'll buy that time for that amount of money".
I have a simple, foundational rule: I'll sleep sound at night, and this rule is rooted in my ethics. So, I don't shortchange anyone, incl. my employer. If terms change between us, we will discuss, but this probability is not a reason to do shitty work (or optimize for money, or which sugarcoated absurdity others name this).
2. Companies will throw away/layoff people with no notice?
Yes, this is bad. This is life. It's not nice, fair or acceptable, but without unionization, you can't act against this. So, you either try to change this or you just accept it. Realities of work life is not a predicament to shortchange your employer again.
This is as absurd as saying "I'll die anyway, why do all these things? I can just die on-demand".
Meaningless...
3. Work slowage (work-to-rule) as a counter to low/no pay raises in accordance to general inflation
We can accept that, but you all shall really unionize. It's not scary. Try organizing. It's a force multiplier.
4. Invest emotional and physical labor in ventures you gain completely out of
Everybody should have hobbies either productive or unproductive. I can't find the question.
There are companies where you can spend years doing as you describe. More and more, though, you’re competing with people who care even though they don’t own, put in the same effort YoY, and invest in their job. Companies love these employees.
So I guess it really depends on your values and what you want out of life. If you enjoy hobbies and time outside of work, sure find a job where you can coast. Don’t get frustrated when you get laid off just find another place to work. Etc.
Plenty of people want to grow within the industry and build a career, though. And many have what we call basic self-respect and care about how they are perceived.
> and aims to drive time to market metrics down aggressively with AI.
Go fast and break things has been a mantra for how long?
I think a lot of the laments about "good" code are really about "ownership" - and as someone who spent most of my working career in OTHER peoples code bases I have seen some things. There are a lot of you who think that your code bases are "great" when they are NOT. Personal understanding is not a good measure of quality.
The increased cadence from AI is just speed running to the legacy code base.
The answer: express the concern, and reiterate it after every issue that arises because of increased complexity. Start building a plan on how to "unravel" the mess, how to migrate things in place, how to start drawing boundaries in your systems. The system is designed to reward heroes who fix problems - you want to be super man who stops the bridge from falling apart, not the engineer who pushes the costly fixes it before it does.
> Go fast and break things has been a mantra for how long?
Practically since eternity, but just as we learnt to manage current rate of "fast" and "breakage", somebody attached a solid booster behind us. So we're trying to understand what happened and what's happening and what will happen.
> I think a lot of the laments about "good" code are really about "ownership"
People owning what they did, have responsibility and initiative about doing better is always a good thing, yes.
> and as someone who spent most of my working career in OTHER peoples code bases I have seen some things.
I can understand that, I'm sorry you had to go through this.
> There are a lot of you who think that your code bases are "great" when they are NOT. Personal understanding is not a good measure of quality.
My codebases are as great as my knowledge. I love when someone reads my code and points where I f'ed up. I also love to show what I did has achieved something I was aiming for and discuss how to achieve it betterer.
> The system is designed to reward heroes who fix problems...
And this is the problem. Because I work silently and diligently build something looking unimpressive while working like an atomic clock without any problems.
One way to get workers to care about the quality of the product they are being paid to build (for someone else's profit) is for the management to show some loyalty and build trust over the course of a decades-long career by treating them fairly and avoiding layoffs.
Sounds like a culture problem. I’ve never had a team I lead not give a shit. Even if the project is dumb (some projects are dumb), there’s enough pride in competence and desire not to dump garbage on the people around you to ensure they at least want to try.
Disagree, throwing more money at devs hoping it will improve quality while continuing to take away their authority will only perpetuate the slop machine.
It's not that hard: treat people with dignity and take their contributions seriously, not as a disposable meat mass. In fact, not only will this improve code quality, it's likely to improve employee retention too.
You pay someone and give them the explicit responsibility for code quality in your system, empowering them to gate check-in with any static analysis and adversarial agent review they feel like.
It’s not a silver bullet but you absolutely can do better than just giving up.
Anything involving an AI won't work. If it did AI companies would already train their AI with it. Review solutions during training, generate synthetic data etc., or as a budget solution just route the requests through more models before giving you an answer.
This isn't true, there's a limit to how much feed-forward processes can correct themselves and well-poisoning of context is far too common.
Try using an LLM to rewrite an LLM output without the slop (vs asking for no slop to begin with) or sandboxed subagents that critique a parent's draft.
There is absolutely a step-function improvement in quality but:
1) not everyone wants to explode their cost by adding extra calls
2) this can't just be "trained in" to a system as obviously they have attempted this but the technique still provides an uplift.
If you can do adversarial agent review, or use an LLM to fix the slop and it works, then technically you already have an LLM trained which knows what to do. You can just use them to improve the other model. The issue is that we don't have these at the moment.
> Before AI there was at least some way to tell apart good programmers from bad
There were only bad ways, and the best way was to just find people who were both good programmers and cared about quality to keep an eye on the rest. Nothing much has changed in that respect.
I don't think it's that hard of a question to answer. I've noticed on my team, our thinking has shifted from how do you directly solve a problem, to how you get an agent to effectively solve the problem and not produce slop in the process.
One thing that we have done that's probably made the biggest impact is alot more upfront architecture with the knowledge that pretty soon agents will be running wild all over the code. Having worked with these agents for a while now, you get a very good sense of how they will go about solving a problem and the various footguns they will encounter along the way. Editing an AGENTS.md file or building a skill is not nearly as fun as coding by hand but it will pay dividends over and over if you do it right.
Another big thing is doing refactoring passes. Early on in our projects our agents generated ALOT of slop and we had to go back and fix alot of it. But every time we did one of these passes, a major aspect was improving agent instructions / skills / etc so it doesn't happen again. It can be a painful process at first but I found that over time, the amount of slop the agent produces goes down by orders of magnitude.
I feel like we're still very much programming, but we're now doing it at a "higher level" where we are not writing the code ourselves but instructing the agent to. And IMHO, properly instructing an agent on a production codebase is not a trivial task.
> and you have no way of telling apart AI slop vs. good maintainable code. (If you could you would just train the AI.)
I know how to distinguish good maintainable code from garbage. I have known for quite a few years. But knowing how to train someone, or an AI? I'm a good coder, not necessarily a good teacher. And there are things about code that I _feel_, not that I can rationally explain.
I completely agree with you on this. I was talking about the employer perspective. They have no way to tell apart the two and thus have no way to set the incentives.
You might write good, maintainable code, but they will prefer the slop generator who delivers quicker.
> Before AI there was at least some way to tell apart good programmers from bad
That's why companies were interviewing people on tasks that had nothing to do with writing maintainable software. /s
I understand the concern and it should be addressed and researched. But, simply saying "humans were writing code themselves" doesn't provide any evidence for better quality.
The comment you replied to did not say anything about unit tests. And "software quality" is much broader than "data structure and code complexity".
I do think this gets to the heart of the matter. I think many programmers have missed the forest for the trees on why things like data structure and code complexity matter. They do matter, but they don't matter in and of themselves. They matter because they are the best techniques we have for making software that is of high quality (the software, that is, not the code) and which remains so over time, while continuing to be developed and adapted.
I strongly believe that it is now much easier to create software that is of high quality and adaptability, orthogonally to the data structure and code complexity concerns. Those concerns remain relevant, but it's a mistake to think of them as the primary thing rather than things that support the primary thing
In the beginning of August 2026, I started a hobby project: building a MongoDB-like database. I have 20 years of industry experience and a master's degree in computer science, so I followed a disciplined, spec-driven development model using Claude, Kiro, Qwen Coder, and Cursor.
The first version was built in about two weeks of part time work. Then I started exploring. I learned relational algebra, researched almost every kind of database, reworked the internals, built a small relational algebra layer, a query planner, and an executor, covering everything from the backend storage to the query language. I learned more in those two months than in the previous 20 years.
Did I care what code the agents wrote? No. I read zero lines of generated code. What I cared about was correctness, verified through tests, and the high-level product features. For the first time in my career, I acted as a senior product manager, steering the project along the right roadmap. Without AI, I wouldn't have been able to do that.
When you have superpowers in your hands, you don't need to worry about the laundry. For the first time in my career, I can produce code in C, C++, Java, .NET, or any other language. Sometimes it takes me longer than a senior developer in that language, but does that really matter? Absolutely not.
Writing documentation and code by hand in 2026 is like driving a horse and buggy. It doesn't matter how skilled you are with the reins; you'll never compete with a car.
My hobby db project isnt opened source yet.
"My project isn't open sourced yet" underlines the problem. There has been a massive explosion of software that works, but badly. The average user experience suffers as a result.
Call me cynical, but I dont remember interacting with well engineered software, outside of pure, mainstream opensource repos.
Most of proprietary software is just crap, and always has been. The agents are not producing worse code than typical, demotivated, i-dont-care-what-i-am-building-i-wont-try-using-it corporate development teams have over the years. I'd even bet that because now making changes and fixes is so much easier, the user perceived quality will trend upwards for popular stuff.
I have seen a decent amount of clearly AI generated software that's useful, would likely not have been made without AI, and is better for for being AI generated. With AI, people make improvements that they would have never have bothered spending time to do manually. If anything, having uncharacteristically good "production value" in a clearly hobby project is how I typically spot AI use in projects that aren't obvious vibe coded slop.
The code itself may or may not be spaghetti. Not that I care as a user. User experience and code quality had never a particularly strong correlation even before AI.
Databases, programming languages, compilers, operating system internals, networks these things are pretty complicated in itself. With your day jobs you can't master any of this without spending years in your part time.
But now at least you can start something of your interest and learn on the way. Learning a new concepts, implements it, test it and reproduce cycle is so fast that it is only possible because of AI. You need to find the process which works for you. AI already knows every programming language, its best practices, entire computer science knowledge is already mastered by current state of AI. There isn't any single database internals which Ai doesnt know. If you dont believe just start implementing JavaScript or C compiler yourself without even having knowledge of compilers and in a few weeks you will where you stand. You will not only having a functional compiler but you will know the internals of compiler constructions, all the concepts.
Okay, you're going to need to go into a lot more detail about exactly how you learned more in 2 months than you did in 20 years having read zero generated code.
Code examples are literally bread and butter when it comes to learning.
How can you learn without looking at code? That's like saying that you can learn to be an architect without looking at drawings...
I didnt know what is relational algebra is? why query plannering execution done in certain ways. What are backend storage system available in open source or commercial products. What are the traitts of each backend storage and how does that effects the replication and failover scenarios. I know all of this, I implemented a small subset of sql's relational algebra in my project and its correct and concise. I expored different backend storage systems, first tried one, then move to next and then 3rd in line, all that in span of less than a month without ever looking what code the coding agents generates.
To make this concrete, it takes someone about 4 months to go through a university course.
They might take six courses at a time.
So you are saying that you learned more than 400 times as much content as a university course?
I'm sorry but this just sounds hilarious And unlikely to most people, and it comes off a bit crazy sounding... For example, do you actually think you could even pass a single university course exam on introductory relational algebra without AI I assistance at all?
I think what is more likely is that you feel confident trying to solve problems with AI's help.
That is not learning.
To learn something, it has to be in your brain, not the AI.
You need to learn the concepts not implementation detail. If you know what is relational algebra and AI teaches you this in hours then you dont need to know the implementation details any longer. If you can borrow intelligence to solve a problem, you should do that. We, the most IT industry is already working in high level languages which is not how the computer works but abstractions over abstractions that very very few people know the entire cycle of a program how it runs. So AI is not a future abstracton, it is already here and its "intelligent" as opposed to other abstractions. Writing code or documentation by hand is gone, its past. All programming languages, framworks are implementation details and AI has already mastered them, we need to now move on to high goals than learning how to write a loop.
I don't even disagree with you here. It's something I've said in the past about things like algorithms. Sometimes knowing a surface level thing allows you to utilise it without necessarily needing to know the implementation level details.
But you did not LEARN Relational Algebra. You learned OF relational algebra. And there's a pretty stark difference there.
>I didnt know what is relational algebra is? why query plannering execution done in certain ways. What are backend storage system available in open source or commercial products. What are the traitts of each backend storage and how does that effects the replication and failover scenarios. I know all of this, I implemented a small subset of sql's relational algebra in my project and its correct and concise. I expored different backend storage systems, first tried one, then move to next and then 3rd in line, all that in span of less than a month without ever looking what code the coding agents generates.
To be as frank as possible--you "understand" these topics in the same way someone who watches pop-science videos about astronomy "understands" astronomy. That is to say, you have a surface level understanding at best.
This is the sort of behavior people have been talking about over the last few years. People confuse what the AI "understands" with what they understand, and it makes them say delusional stuff like "I learned more in the last 2 months than in 20 years."
It is fault tolerant, distributed broker which gurantees durable queues, pub/sub and RPC all into one easy to use programming model. The application is in production and passing millions of messages every day with sub-millisecond performance, you can crash a server and replica set invokes within seconds without losing any messages.
The entire project is created in less than a month with part time working, just because of AI. Its in production and already proven.
Not that Github vanity metrics are the end-all be-all, but let's be real: this project has 0 forks and 1 star. You don't know if it properly functions because nobody is using it. Calling it "proven" production software is a joke.
Yes, you're running it in production, but to put it in perspective: PHP 5 was also proven production software at one point, running way more production instances than you.
I also don't care the exact cpu instructions my compiler emits. In fact I have no idea what the "stuff" it emits means (beyond the most elementary)... That doesnt stop me from creating very useful software that maybe even billions of people rely on (once you include the users of products that use our software)
Those with 20 years of experience are crushing it.
My worry is not about us. The worry is about the kids. I'm tech lead. I don't think the juniors at my company are learning anything from me. I'm not certain they're learning anything about _software_. Idk, I could be wrong. We barely talk because everyone has become so siloed.
I am trying. The main issue is it would be extremely annoying for the juniors, who have work to get done, and prefer to throw problems at Claude rather than ask me questions.
In general, I believe learning usually needs to be driven by the learner.
> For the first time in my career, I acted as a senior product manager, steering the project along the right roadmap. Without AI, I wouldn't have been able to do that.
This may be Dunning–Kruger effect in action. (this is not an insult, but showing cognitive biases)
Maybe I've just given up, or maybe I'm a realist? But I fully believe AI will just...catch up with everything?
There's so much money in it right now. There's such a momentum. There are zero incentives to slow down for those that are in charge.
I've accepted that in 5-10 years, the vast majority of human devs. and engineers will not touch a single line of code. It'll be small increments, with a couple of big ones here and there.
And there will not be any triumph for those that hold steadfast to the principle of human coding. They'll be tiny boutique shops that do custom stuff, in the same way cobblers are to the mega shoe factories.
We've been able to make watches with machines for 50 years. Handmade Watchmakers, and their producuts are more valuable and in demand than any guy running a conveyer belt. They still make 20x more if not 50x. People look up to them.
You can make a choice not to become a button pusher and still do things by hand. You dont have to fry your brain. You're falling for a massive trap to strip you of your value.
the difference is that code is not something the average person will marvel at over the intricate hand built details. You might get a few nerds interested if it's something super novel (like rewriting a major modern web app without any 3rd party libraries that is 30x more performant), but most people dont care. Extra true for businesses, I can't think of a business other than maybe a mom&pop shop or a place where showing wealth is important where they wouldnt happily issue casio watches far before they would consider a rolex.
Regular businesses are not going to build their own slop software because of AI, this is delusional. People will be hired because they love to build. Only a small percentage of the world loves to build things.
The most passionate people with the best reputation will suceed, they will continue to be in the most demand and will be the most valuable, like a swiss watchmaker.
Sorry LLMs arent replacing anyone who's got strong skills and cultivates them. You're so wrong here. These more passionate builders will however replace the lazy people who offload all their skill and brain capability to llms, and they'll use AI to help them.
Being lazy and letting llms do everything for you is not a good strategy.
Handmade watches are a tiny, niche market; they survive only because they've positioned themselves as a status symbol. Quartz watches are both cheaper and more accurate.
There is not room in the world for more handmade watchmakers, and there's not going to be room for much "artisan software" either.
Yeah, I have a really hard time buying the "AI code isn't maintainable long term" because if you look at the quality increase from January of this year to now, it's insane. We've gone from Opus 4.6 and GPT 5.4 to Fable 5.1 and GPT 6 in less than a year, where we went from 0 mathematics problems being solved by AI to a Millennium prize problem being solved in a few days of compute. Obviously not the same as coding skills, but it shows the growth in raw reasoning and abstraction.
I understand why people are resistant to this from an emotional perspective, but I really don't see a plateau in sight. RLVR is clearly still cooking and narrow RSI seems to be on the horizon.
But I'm also a realist. If the technology exists, it will be used to the maximum economical extent.
You can get a decent idea running some of this stuff locally. Depending on how efficient you want your agent to be, you can get an awful lot done on beefy local hardware and ~300W power consumption. Just inference of course ...
That would be like saying the first vehicle off the assembly line had to be profitable; there is an ocean of optimization that will drive the economics.
feels like pure copium to believe that won't change rapidly.
> if you look at the quality increase from January of this year to now, it's insane.
It's non-existent. LLMs still suck at writing code just as much as they did at the beginning of 2026, or 2025 for that matter. LLM proponents are always trying to hype everyone up on the supposed improvements, but they have never yet been real. That means they are unlikely to be real in the future either.
That's just ... not true? Have you tried qwen3.8 (compared to qwen3) or deepseek 4? they've improved tremendously, maybe not at every class of problems, but if you take a disciplined approach and don't ask them to one-shot everything (e.g. update agents.md as you go, actually use the thing you build, give feedback etc), it's positively absurd what you can get done now with a single agent.
I agree that not every class of software or problem or this or that is going to be decimated/revolutionized whatever, but to not see any improvement since 2025 just sounds like you're not looking.
> I've accepted that in 5-10 years, the vast majority of human devs. and engineers will not touch a single line of code.
Why would companies employ human engineers then? What is the value addition to justify high human salaries. If AI is going to get so good (and I am not saying it won’t happen, that’s a separate debate), why can’t AI figure out the prompts itself?
That is where a lot of people in tech believe things are headed, executives in particular. Fully autonomous AI-driven codebases. “Dark factories.” One agent generating a plan, one writing the code, one responsible for testing and validating, and one to orchestrate the rest.
The idea is software development will follow in the footsteps of physical manufacturing and eventually become fully automated. I think one huge flaw with this belief/comparison is that the automated assembly line is deterministic. LLMs and AI agents are not. Every Tacoma made on the Toyota assembly line is made from the same blueprint. There are no robots deciding on-the-fly whether to use a laser weld or an adhesive, what material to use for a specific component, etc. Now think about how LLMs build software. No matter how strict a harness or detailed spec you give it, it will always make decisions. That is what makes it “agentic” after all.
I've fully automated the software development part in my company. With production apps, no code has been written by hands, no requirement written by hand. Everything is fully automated except the testing part. And testing means the human testable parts are still performed by hands. The resule, with less people we produce more, actually way more. Our cost has gone down, quality has improved litrally. The code is being produced with AI is of higher quality, we employ multiple agents during planning phase and then different agents during execution phase. Sometimes some tasks has to be redone because some agents are better than others. Our release cycle is reduced from 2 weeks to 2 days.
We'll probably get there, once frontier labs RL the fuck out of AI agents sitting in meetings and interpreting incoherent ramblings of business majors into actionable requirements. That's the biggest value human devs currently provide.
Yes, AI for now has significant code quality issues, but that's mostly because it lacks agency to take care of code quality unless you explicitly tell it to. It is good at refactoring its own messes when you even vaguely ask for it. So while something like Astra still needs supervision to produce decent code, I expect that in a year or two it will be unnecessary.
I'm in the same boat. When I started thinking about LLM development as multi-year iterative training adjustments, it felt like the majority of shortcomings can be addressed.
Man.. just code, let people build, design, adjust. Who cares? Who are these people writing these posts? Why should we give anything they have to say warrant? These posts are getting old, very quick.
I work in an industry where software bugs can cause real harm to real people. I care that my coworkers are producing more bugs than ever because they don't take the time to think about the code anymore.
Then where are your industrial controls to catch bugs before they are introduced to the product? Where is the feedback loop to the developers running the AI to control the situation?
LLMs should not touch these technologies. Keep your slop factories in webdev. We have missles, planes and pacemakers to make still. If you ever feel like using your brain again, theres plenty of work to be done that llms cannot touch.
Surely those industries are not relying on humans writing "good code" to make sure faults are not introduced, right? There are static analysis and automated testing and rigorous QA processes, surely?
I think that we should realistically expect that even a very rigorous testing and validation process is not fool proof, just as we anticipated that the code isn't.
I don't think my comment implied that any testing and validation process will be fool proof. There are two claims in the comment I replied two, first that people are creating "more bugs than ever". I take that to mean more bugs per line of code or more bugs per unit of functionality or something like that. If that's the case, then I think it implies that testing and validation has gotten worse per that same unit, which I think suggests that it could be improved, without expecting it to become fool proof. Then there is a causal claim, that these bugs are because people are not thinking about the code. Maybe so, but to me, it seems more likely to be caused by inadequate validation.
> I don't think my comment implied that any testing and validation process will be fool proof.
It does by, attributing a change in quality to a "testing and validation problem".
If there is a change in programming methodology, as far as we know no change in testing and validation methodology and at the same time an increase in the production of bugs, it's not reasonable to attribute that increased error rate to testing and validation getting worse.
It's like adding spinning saw blades to the fronts of cars and then attributing the increased fatality rates to pedestrians not wearing safety reflectors.
If it happened as you describe, with no change in the testing and validation processes, then it exposed an existing weakness in those processes, which should be improved.
In your analogy, what I would say is that the saw blades on the front of cars situation exposed a weakness in the regulatory regime for what can be put on the front of cars, which should be improved.
> If it happened as you describe, with no change in the testing and validation processes, then it exposed an existing weakness in those processes, which should be improved.
I remind you that the belief you are defending is that an increase in the number of bugs produced per some unit of implementation "implies that testing and validation has gotten worse", not the general idea that you can or should improve software quality by improving testing and validation.
If we adopt the realistic perspective that the testing and validation process can only catch some fraction of bugs, then an increase in the number of bugs produced in the implementation stage is bad irrespective of what that fraction is. You can improve the testing and validation process so as to minimize the fraction of bugs that get past QA, but when you multiply that by the number of bugs produced in implementation you will be worse off if you produce 7 bugs per month during implementation than if you produce 5 bugs, regardless of whether you can also improve the testing and validation process. You will on average, over time, have fewer bugs in production if you produce fewer bugs during implementation given any testing and validation process that isn't completely fool proof.
No, what I'm defending is my initial comment in this thread:
> Isn't this a testing and validation problem?
One way for it to be that kind of problem is by exposing weakness in the existing approach. Another way would be if the approach was worsened. But both things fit my original contention.
I don't disagree with your concluding paragraph at all. But what I think is that there is no reason that implementing with llm based tooling implies an increased defect rate. Rather, I think it implies that there are existing or new holes in the quality process. That doesn't imply that I think a defect rate of zero is possible. But I think holding the defect rate steady is possible.
You could also just remove the product from the market. That will guarantee a reduction of bugs in production to 0. That exposes a weakness in the existing approach to marketing and overall product design, meaning the problem is in marketing and product design.
It's a product of the times. You have some folks who are really passionate about the craft of software, some folks to whom it's just a job, and an entire culture that promotes and incentivizes engagement through raw emotional connection (outrage, passion, pick an emotion).
What you don't see from most perspectives are the silent masses who simply don't engage, don't care about the discussion, and/or are too busy doing what they enjoy.
I think too many people (very much including me) who are "passionate about the craft of software" allowed themselves to become too focused on the code itself as if that were the first order concern of the craft. But the craft has always been about the quality of the software, including how its quality changes as a function of time and adaptation. Code quality is only in support of that concern, it is not itself the primary concern.
It has been a fairly painful experience for me to shift my thinking on this, but it's a much better mindset. I still care about many of the same code quality concerns I always have, but I'm thinking a lot more about why I care than I once did.
I don't know, we spent the last few years with tons of posts telling us "coding is dead" and the biggest companies in the world telling us our jobs are going to go extinct.
That mindset has also deteriorated my working environment due to some coworkers buying into it.
So it's kind of nice to see some sanity checks that align with my beliefs too. I can share articles like this with my teammates. I can see that I'm not alone in thinking most LLM code is slop.
I think too junior devs NEED to see this. My team had a couple of promising juniors who are now completely brain rotted by AI and can't even write "Hello World" without consulting Claude anymore.
To analogize coding to sculpting - you're in the "toddler with playdough" phase. At some point you might want to make something other people will find pleasing and maybe even worth putting on display, the rules of composition, the details of materials, and the techniques for not wasting expensive materials suddenly become important.
If you're just writing code to fuck around or automate a small part of your life, whatever. But if you're making a big system or wanting other people to use your product, these things about how to make good software become more relevant.
> I’m going to make a prediction of my own… In the future we will see more and more companies proudly boasting their “NO-AI” policy as a competitive advantage. And they will be right
I'm going to make my own prediction: this isn't going to happen
I'll go one further: We'll see companies proudly boasting "no humans" as a competitive advantage and arguing letting humans do certain types of work is unsafe.
Not a lot of shops these days are bragging about hand-writing machine code and a complete lack of automated testing. We had already automated so much before LLMs came into the picture.
Why would you brag abput this. Most places make perf products do not use llms to write all their code. This isnt rare. You people dont know much outside of webdev. There isnt a single defense outfit doing it lol.
I think we'll probably get both kinds of companies, but that they will both be fringe approaches, and the predominant choice will be to have humans working with AI tools.
"We're not going to use tractors to plow the fields"
"We're not going to use trucks to deliver our produce"
"We're not going to use planes to meet with our global partners"
"We're not going to use computers to run our business"
"We're not going to open a web shop, brick and mortar forever"
"We're not going to use AI to make decisions for us"
Pet peeve - luddites had never been against technology. They had been against using low paid inexperienced grunt workers to displace well paid experts.
As the Industrial Revolution began, workers naturally worried about being displaced by increasingly efficient machines. But the Luddites themselves “were totally fine with machines,” says Kevin Binfield, editor of the 2004 collection Writings of the Luddites. They confined their attacks to manufacturers who used machines in what they called “a fraudulent and deceitful manner” to get around standard labor practices. “They just wanted machines that made high-quality goods,” says Binfield, “and they wanted these machines to be run by workers who had gone through an apprenticeship and got paid decent wages. Those were their only concerns.”
The definition you're using is not the definition that people nowadays understand the word for.
You don't go to a magazine website for the current common meaning or understanding of a word, you go to the dictionary And in a dictionary you'll read that a luddite is someone who is opposed to new technology, automation, or industrial change.
There are countless examples where people resist new technology for various reasons other than "using low paid inexperienced grunt workers to displace well paid experts". And this is what we call luddites, not the historical original definition of the word.
It's the same vibe as "They called <insert genius> crazy for his ideas!"
Yes, the also called lots of actual crazy people crazy. In fact the probability of actually being crazy, given people are calling you crazy, is very high.
And why are the people calling people Luddite some of the least intelligent people I meet, and seem to be complete sheep fighting some psychological war on behalf of their billionaire lords who own the machinery.
Not wanting to hand off all your labor to a machine does not make you a luddite, nor should it be acceptable to call people that because you dont know how to have a real conversation.
It seems like "luddite" is a reasonable description for a strict "NO-AI" policy. You softened it to "not wanting to hand off all your labor" in this comment, but the word "any" would be a more apt way to describe the quote in the comment you replied to.
I already know how to code proficiently in more than 20 languages, that's the result of 40 years working in the field and being a 100X programmer. The summarizer is just a tool for myself, I build tools every day to simplify my life, not for sale, not for monetization, like tracking gym schedules or pickleball rallies with my friends, like kanban boards for my wife, they solve problems I have, not you, so that's enough for me and rewarding in itself
And AI does it all for me while I sip coffee and play mahjong (built by AI of course)
I mean this sincerely; the arrogance of calling yourself a 100X programmer is astounding. I don't know how you managed a 40 year career with that kind of attitude.
I havent met a single honest person who doesn't admit that their use or LLMs degrades their ability to do the same things without them. You're being dishonest.
What was edgy about asking someone to read a Thomas Pynchon essay on the word Luddite? Id argue their weird comment about people who don't like AI being luddites is more annoying and discriminatory.
AI maxxers know they're doing harm to themselves by overusing llms. The way they react so defensively when you point it out to them lets you know its real. Everyone wants to pretending like they have superpowers and are evolving into "100x" engineers, but in reality they're devolving.
I remember seeing some companies boast about "no outsourcing". I think 99% of their customers won't care for such things, as long as the customer gets what they want.
You’re both sorta right imo. Some companies are going to try and virtue-signal artisanal AI-free code, and some will just deliver sorta what you asked for, and neither will be perfect.
Most software is not good, using these rules. And that is written by human developers. The problem is that most software developers have less than 5 years experience. The community doubles every 5 years. Experience is scarce. So AI, learning from all the stuff online, does not learn great code, it learns from available code.
You can make it produce better code, if you do the hard work of defining better in terms the AI understands.
I've been trying to find a way forward with AI generated code, using my own definition of 'good architecture', and results with chatgpt 6 are promising. Not perfect, but good enough.
I used a book I was writing as input, you can read an unfinished version of it here: https://programming-for-wizards.dev.muze.nl/
(Still working out the kinks of the underlying software)
The other approach is to explicitly keep the whole decision tree as a causal chain in a repository: https://github.com/muze-labs/spiral-developer
Still testing that one out.
> Fact is, vibe-coded projects devolve over time into an unmaintainable mess. The reason is simple, yet hard to fix: code maintainability and good architecture don’t have good measurements that we can apply, because it takes months, years even, to notice the effects of bad architecture or of unmaintainable code.
Oh boy do I have some news for you about legacy codebases.
I’m not even sure that his axiom is true. A project started with a 2024/5 model can subsequently be worked on by more capable models (who don’t, unlike some humans, have a deep aversion to paying down technical debt). I’ve seldom seen a human written legacy application spontaneously acquire a better engineering team every six months.
I believe many of us here knows that the idea of a simple prompt to make something more than a sketch or a prototype don’t really work.
Unless you steer and understand what an LLM will produce, you will end up with something that possible ”works” that has no future plans baked in. Suno generated music has a very unpleasant feeling of sounding like competent music with nothing to say.
I’d say that vibecoded software is similar. My speculation is that current breed of LLMs do not have an I, and I really don’t exactly knows what goes on in those vast arrays of numbers. There’s something there perhaps, but no person.
Still even in the short term someone wants to run a company that expects responsibility of its organisation, how are you going to exact that responsibility if no one actually understands how the thing the organisation makes works.
Maybe a simple crud system can be made fast and loose. But a bank settlement? A pacemaker? Deletion of sensitive data?
I know some companies are betting on that the agent can fix what the agent breaks. It may be true, but up until now everytime I try to relax on strict steering of an agent it tends to go badly rather fast.
Again I don’t know, but I think as long as we don’t invent synthetic persons with their own ideas on what they want to do, which btw opens a massive can of worms, the current situation will persist. However clever the current breeds of systems are.
I do want to state that a find the current trajectory fascinating. I use LLMs daily, it expands the number solutions I can explore. But in order to make something I feel is mine. There’s a choice and the buck stops with me.
Imagine AI making your favorite book or film. Could it be prompted into making Lord of the Rings or whatever it is that you enjoy? I think those who only watched the film might say yes :-) Those who love the book might say no.
There’s a few things on this. I’ve read the trilogy many many times during my life. Every reread I found something new, something I hadn’t considered before. Still it was eerie to see Peter Jackson’s rendition because it was very close to how I picture the book in my mind.
So, I think if you know just a little bit of film making and writing and LLMs you know you could not prompt any of them into existence with just saying ”write lord of the rings”
But if you have an idea for a creative project, using an LLM to explore ideas can definitely be a fruitful endeavour.
The gods don’t give gifts by ghost goblins cannot be dismissed as slop. I’ve personally used LLM to explore large sets of photographs to use as a backdrop for a DJ set, essentially to have the set tell a story.
So, as most things, it’s complicated. But at the same time I’m curious what will happen next
And in 10 years we are going to do double blind studies and realize that nobody can tell the difference. A fact that will be ignored for the next half a century.
I've read a lot of posts similar to this recently and keep asking myself if the past 20 years of my professional experience was that atypical.
I’m sure there are companies who are writing “perfectly maintainable and highly scalable code”. However, for half of my career I’ve been brought into startups to clean up the mess created by engineering teams.
While AI may create an unmaintainable mess (I’m not totally convinced), from my perspective many (not all) engineering teams have been doing that all along. #v2 #refactor
Ah yeah, light bulb moment here. I do think the disconnect I sense in reading these comments and discussing this might be in my level of expectations for how good "code quality" has ever been or even really can be in non-trivial applications.
To me, AIs seem to write code with a normal (low) level of quality, but I now have so many more tools to make sure the software works nonetheless, to refactor quickly, and to encode better practices that (mostly) stick in the future.
So to me, this is all a huge net win. But I guess if I'd ever worked on a pristine perfectly engineered system, I might see this all differently.
To me, it's always been a mess, and I'm just ecstatic that I have more ways to manage the mess now.
We (collectively) were unprepared for a machine that presents itself in human forms. We were the frogs that boiled ourselves. We built a world of images and words on a screen. And then we built a machine that can (increasingly) mirror that world; it does so in a way which most of us are incapable of disambiguating.
It feels like there is indeed a ghost in the machine.
And there is, but that ghost is us. And that ghost is fading surprisingly quickly.
As much as I'd love to believe it, it is now a conservative take. Sure, having a solid architecture in mind still matters right now, but manually writing code is completely unnecessary and, before long, even designing the architecture is going to be completely automated.
Here I am starting to think a central part of knowledge work is the knowledge gained.
Maybe you are right, maybe not, let's see. Unfortunately I kinda agree, because humans are really good at being lazy and going in the path of least resistance (including me). It's genuinely difficult to not use AI even if it makes my work worse, as long as it's easier and faster.
Does writing table schemas count as writing code? Is that architecting? Both?
I personally don’t trust coding agents to have enough context to write domain-specific table schemas, and I don’t have the patience to transcribe all of the context into a natural language prompt. If I ask it to, it’ll write something for sure, and maybe that can be a jumping point for me, but at some point I have to physically write what the columns will be.
You should definitely try it if you haven't already. Most of the models are deeply familiar with domain specific areas in ways that most of us aren't. In fact, I would say the problem is generally the opposite. If model size and effort is is high, it will over architect what an app needs. I find myself reigning in a giant email notification system with subscriptions and "channels" and other such nonsense when sometimes you just want a simple one off.
Yes, the LLM knows the definitions of the words in my domain, that’s clear and obvious.
No, the LLM doesn’t know our product strategy and why certain things matter and certain things don’t. That’s very much what I get paid to do. There’s not even agreement within our team about what path we should take through the domain-product space, there’s no chance in hell that the LLM will choose a profitable random walk through that domain-product space.
If it were able to do that, then AGI would have already been achieved and we’re only compute power away from OpenAI or Anthropic making the marginal utility of any piece of code $0.
Yeah, it's not just over-engineering, it is just that generic systems that look like everything else usually don't solve a business problem, but I think I would be less dismissive of its world model in general.
LLMs are not a "random walk", they take in information and they explore the space according to the way they've been instructed.
I’m taking this view now as well. If you’re reading code, you’re probably doing it wrong. You should absolutely be setting criteria that can be objectively measured and rejecting code that doesn’t meet those criteria or perform as specified. We are all senior software engineering managers now, with a fleet of cheap and ambitious young engineers doing all the authoring.
But reading code? What does that accomplish, other than to slow your dev process down enormously? Serious question.
Man, I think that code is still the artifact that we produce as developers. Code is the truth. I don't find it difficult or super time consuming to just... read the code, either. I've highlighted quite a few issues with LLM/Agent output from just glancing at the code.
I'll let you know how it goes... My new VP of engineering is a 'no looking at code' type of guy and is ripping 10K LOC PRs / Docs / plans against our 25 year old codebase and I would not say that they're 'good' PRs.
Maybe I'm completely wrong, but I think reading the code is more valuable than ever when working in a full-stack / small company role. I can tell you exactly what the business logic or functionality is for a certain piece of our system, in truth, without having to step through and make sense of ambiguous docs (that were also AI generated).
(I have a sneaking suspicion that in two years or less, my small team is going to significantly compromise the integrity of this codebase. Maybe by then we can refactor with GPT 12.)
> You should absolutely be setting criteria that can be objectively measured and rejecting code that doesn’t meet those criteria or perform as specified
This is the classic "make no mistakes".
On a serious note, I might set as criteria "avoid code duplication". Does that mean that the model/agent will actually follow it?
> What does that accomplish, other than to slow your dev process down enormously?
I am an OSS developer and I often see PRs (i.e. from the general public) that look correct, pass all CI checks, are heavily documented and they are still wrong.
Most of the times either they duplicate code that already exists somewhere else, or they implement a "feature" by opening a can of worms for subsequent "features" in the same area.
> even designing the architecture is going to be completely automated
I mean, people have been dreaming about this for decades. The whole reason UML was so overdesigned in the first place was in hopes that people could code by drawing boxes and lines. The full COBRA spec had software autonomously buying components in digital marketplaces and installing without human supervision.
It is funny to see engineers insisting that there's no way a machine could do this better. If anything, the surprise is that it took good old human language -- that second L in LLM -- to get the computer to sling code. The assumption was that a computer would just "speak code" like some kind of native tongue, but instead it just understands human language and associates that with code, and relies upon things like compilers and tests to see if it's right. Just like humans.
Predictably, now that it's actually happening, engineers are worried. As they should be, but I think it's a short-term worry. The job is changing, productivity is leaping, but its still a world where computers don't need to do stuff, humans do, so humans will be making it happen one way or another.
Tbf, at this point, this has been said ad-nauseam.
At least I did not find a new thought in that (granted, relatable) rant.
"This is bad and you are bad" requires people to not defend their reality through rationalization, but the point we're at with AI right now is driven by exactly that. So this is at best highly ineffective at reaching the people it claims to want to reach.
That said, the underlying emotion of "you all suck and I hope you lose your jobs you frauds" is relatable and worth screaming from the rooftops of Linkedin dot com for the catharsis alone.
If you have ever looked at a kite and said to yourself, "that is as good as a hang-glider. maybe better.", you might be subject to the perils of one-shot AISDLC
> Fact is, vibe-coded projects devolve over time into an unmaintainable mess.
We've had strong coding agents for less than a year. Anyone making such a definitive statement about how vibe-coded projects progress over time is basing it on guesswork, not evidence.
In my experience, the most difficult part of a software project is getting the specifications correct. To abuse Harold Abelson famously quote: "Programs must be written for people to read, and only incidentally for machines to execute."
"A Project must have proper tests and specs, and only incidentally for a working program that executes"
So there's evidence that it can be done badly enough that the problems show up in less than a year. That doesn't prove that more evidence will show up after a couple years, or five, but it does make one suspect that it will.
1) A lot of the time i spent deciding on interfaces (methods, classes, etc.) for humans. E.g. should this be two methods or one, should this method be in this class or moved to utility. Those problems went away.
2) What about performant code? This can be prompted away and when the measurements in your performance tests do not go down, then you can step in.
3) Sad to say but the AI has always been better than me at code-reviews. Maybe this is just me and if so I own that, but to the articles point, it might be harder to fix now.
4) "vibe-coded projects devolve over time into an unmaintainable mess". Preventing and managing this mess is the new skill sets we need to develop as software engineers.
5) Another skill-set we will need to master is how to maintain and grow our coding skills. Some ideas are: a) every once in a while implement a feature yourself. b) no AI Tuesdays! c) Have the AI quiz you on the code base. d) Have the AI develop HTML docs about how the code works.
I've found it helpful to make an explicit delineation in the codebase for which interfaces I'm going to agonize over and refine and which I'm going to ignore.
One set goes into haxe files and I use reflaxe macros to write tiny compilers that generate docs, clients, servers, cli's, test cases, serializers and deserializers, etc in whatever language is appropriate. That leaves gaps, which the AI can then fill in.
So I iterate on the haxe stuff. If the AI is struggling to "draw the rest of the owl," I change the source of truth until it has enough guidance re: type related errors, failing tests, and documentation. As requirements change, these things change.
As for the rest of the owl, it's disposable. Every few months I'll delete it and have an AI rewrite it from scratch (now with a smarter model and better docs and API specs and tests to guide it). This keeps the cruft from accumulating while preserving human contact with the code.
> Preventing and managing this mess is the new skill sets we need to develop as software engineers.
How can we prevent and manage the mess if we're not actively working in the codebase though? (Sometimes, I'll get a 'feel' for when something needs changed or will become unmaintainable, but that required consistently interacting with the thing)
Currently, we look at code once during the PR and then we never touch it again until it comes up in the PR.
I'm still handling a few tickets a week without AI, because sometimes it's faster to make a 2 line fix than to write + review a prompt, but increasingly it's just to make sure I still 'got it'.
1) Those problems did not go away. They only "went away" if you assume no one will ever need to read code again. And if you believe that, you clearly aren't reading the code already. Which I guess is why you think naming and architecture problems went away. AI is the absolute worst at architecture decisions.
2) not even sure what you mean by this
3) probably shouldn't admit that. It implies the reviewer has a less than average understanding of the code they're reviewing.
4) preventing and managing vibe code devolving into a pile of slop requires programmers not use AI. 80% accuracy repeated in more and more layers === more and more failures. In other words, the skill required is exactly the skill of being a good programmer without AI.
5) e) no AI all the time or only use AI as search. You're almost there with a and b. With c, it just doesn't understand well enough to "quiz you". With d, how are you going to know if the docs are correct if you aren't reading the slop?
Every large code base goes to shit unless you have a very strict bdfl at the top.
AI is nothing special or new in this regard. It just gives a single guy the velocity to ruin a codebase at the rate of a full enterprise team at double the speed.
A shitty code base still makes money, and that's all that will ever count for the majority of the employed developers, those who don't blog.
To me, the problem is not about what AI is good or bad at, but about institutional knowledge. If AI is doing the coding, writing, designing, or whatever else, you slowly lose the ability to a) learn from others in the org because nobody knows what you need to learn anymore and b) actually improve stuff because there's no more "what good looks like"
My companies current national marketing campaign strategy, structure and creative work has been created by an MBA from outside our industry who did a "deep dive" using AI. The project manager they brought in to run the tickets is also adding AI made decisions on brand and ad copy.
The short version of the result is that we're completely copying the leaders in our market that have 100x our marketing budget because they're the only ones with documented strategies for AI to cheatsheet from, with no sense or irony or concern that perhaps their scale is a core part of their strategy.
It's not just institutional knowledge. We're suffering the death of the specialist. Now every generalist is pulling triggers with no sense of limitations.
it will not. Dead Internet Theory - eventually everything will be slop. And even if you care to avoid the slop, there is no place left for anyone to differentiate from the market slop offering because the 10-20% that actually care about not being fed slop are not enough to sustain a market.
I think (hope?) our industry will reach some equilibrium between fully agentic development and reviewing/hand tuning the code.
Personally for my job I struggle to justify writing code by hand. Agents are much better at typing the code, reading the code, finding patterns and discovering bugs. They don't have my knowledge and my background so the current models still miss things or overcomplicate the code. I don't know if that's going to be true of the next generation of models (or the one after that).
With current models, I cannot fully give in to the vibes. I _have_ to look at code (maybe not 100% of it but at least a majority of the lines). I _have_ to grill the agent to make sure it writes the best code that I deem possible for the problem at hand. This isn't the fastest way to do agentic development, but AI agents have already made us significantly faster than we were in the pre-AI era. I don't want to squeeze every ounce of 'development speed' if that comes at a cost to code quality, maintainability or debuggability.
For my side projects, things are different: either I only care about the outcome (and I give in to the 'vibes') or I care about the journey just as much as the destination in which case the agents are extremely advanced search engines, code reviewers and mentors but they don't get to write any of the code.
Yeah, I guess I personally fall on the whole spectrum: for side projects I'm at the extremes but for my professional work I fall somewhere in the middle.
Mind you I may be dating myself as I was first introduced to this paradigm in 2015 working as a Java SpringBoot engineer on an enterprise project that I then migrated (57 microservices) all to Scala, after onboarding two weeks to Scala fresh from no prior Java experience.
I feel like there is so much "wisdom" encoded in books and writings from some of the most prolific engineers and architects over the last several decades.
Look at Matt Pocock's skills with simple primitives like grilling the human, researching through wayfinder maps (a Godsend to my workflow prior to Cursor Projects and orchestrator patterns), and having a solid Domain Driven Design through defining a shared glossary and breaking up work around proper seams.
Could you share some higher bars that may make up a better "rubric" for this issue? I am actively trying to do so. Shy of just condensing core Manning publications that cover domains of interest, I am struggling to find a good bar to have my clankers validate against outside of minimizing cyclomatic complexity.
Cyclomatic (and cognitive complexity) are a good start.
Some other ideas
1) Enforce architecture decisions (see archunit). But somebody needs to write them down first.
2) Check that tests actually break if the code that accompanies them is removed (several LLMs/agents today create tests that don't actually test the code they "guard against)
3) Automated performance testing. An LLM/agent might create a change that is "correct" but increases latency for 3x (best case) and 20x (worst case)
The hardest part that I see no solution for today is to understand when a change breaks backwards compatibility. LLMs/agents are trigger-happy and will happily refactor/remove stuff without any care about who is using that.I don't have a proposal for that, but the problem is there and is not covered by 12-factor config.
Excellent set of criteria, thank you. Something like am archlint, or performance lint, and sanity check on tests "Actually testing a seam or function" of the actual code base sound like good research avenues.
You can still read the code, ask the AI questions about it, and ask it to fix things. Coding agents are a power tool for cleaning up codebases, but you have to ask for the right cleanups, which means figuring out what it is based on your understanding. (You can also ask the AI to suggest ideas.)
This takes time away from implementing new features, but that’s true of all code health maintenance.
> You can still read the code, ask the AI questions about it, and ask it to fix things
This only works in small projects. For large projects, it is close to impossible. Everybody talks about how new models appear all the time and nobody comments on the fact that context size has almost stalled.
Sure. But in order to do central refactoring and actually improve stuff you need to keep in context all the small pieces.
You can split a small program into piece A, B, C All of them look correct on their own. But they duplicate something in 3 different ways and person/agent who can "see" all of them can see the duplication and refactor.
Current model context is simply not enough for large projects.
Same problem for letting AI review code. A PR might look correct on its own and be small enough to fit into context. But somebody who has access to the whole code of the project again sees the duplication.
I am an OSS developer and when reviewing PRs I actually look at how the same problem was solved in other popular OSS projects. No AI can check this today because there is simply not enough context.
Basically if we had unlimited context what you said might be true. But context size is limited today.
I suppose it's not enough to break everything down into smaller pieces, your architecture also needs to be composable. That would address the issue of duplication. Think a plugin system.
Duplication was just an example. Code architecture is the general topic.
Yes a plugin system is great, but it only works if that plugin API/interface it designed correctly and gives plugins what they need while still enforcing good practices.
But somebody needs to design a plugin system that does this first. And designing a plugin system (for large projects) brings us back to square 1 :-) (that you need a large enough context to see what the code does in order to anticipate plugin needs).
Was expecting to read something along the lines of:
"Knowing what you don't know is the beginning of wisdom", and a new take on AI reasoning, but didn't actually use the word wisdom in the text.
Anyway, I think we're increasingly finding the old adage "garbage-in, garbage-out" still applies.
The question I would ask is: Does anyone first ask the AI for a non-coding solution rather than jumping straight to code? Is Systems Analysis dead? Does no one read Hawryszkiewycz anymore?
> The difference now is that AI can make low effort work look high effort at a surface level.
True, but we'll also get higher standards I think. It's become easier to do things, so skilled people can do more complicated things. We compare to what humans can achieve.
> because we’ve always done automation at scale, everything we do is automation
I'm weirdly attached to this line. Physical automation a.k.a. factories are not portable. The manufacturing techniques are, but to "spin up" a new factory requires expertise, effort and capital. In contrast to software, replication can be done quite effortlessly, with containers and such tools, it's easily a one-man job.
Writing, coding and art are not meant to be repetitive, scalable tasks. I think that's what's driving the core of the backlash. If these forms of human expressions can be automated, then why would we need to apply our mental capacity at all?
I do think AI might get better and better at coding, as long as there are still humans creating software for AI to learn from—which may actually be a bad thing.
What worries me more is my own tendency to rely on AI more and more. It is becoming increasingly difficult to choose the harder path of coding by myself instead of taking the easier road, even though I know that road may gradually make me lose some of my skills.
Fortunately, I am closer to the end of my career than the beginning, but I worry a great deal about the new generation of developers.
AI lacks wisdom because it processes patterns, not reality. It excels at statistical synthesis but cannot understand the meaning, stakes, or consequences of its outputs.The real danger is cognitive atrophy. If we outsource our critical thinking to automated averages, we stop doing the messy, high-latency work of building our own internal world models—effectively redefining "wisdom" as whatever the model outputs.Would you like to turn this short summary into a social media post, a quick debate rebuttal, or a thesis statement?
Very interesting post. Feels like my comment from two days ago [1], elaborated. I must thank the author for verbalizing all the concerns.
So now we have a fork: red-pillers who want to regenerate software all the time (esp those with unlimited token budgets) and blue-pillers who want to maintain more code mass per developer-head. Plus, we have software artisans.
I'm all in favor for well crafted software and thoughtful designed stuff. The "No-AI" branding will probably become somewhat popular as you expect it, but how can we trust this?
We've already seen so many examples of people (wether normal people or very important people) using AI and disguising it as their own thought. How can we ever trust a company just slapping a "No-AI used" logo on their landing page?
Wisdom is very rare. I constantly have to tell people "we did it like that in 2012 because it seemed like a good idea and there were no better options - but this is 2026 and there are now better options and we shouldn't do things the old way instead.
Too often people get an idea and don't stop to ask if there is an even better idea. (I'm guilty of this myself). Often it takes a while to figure out what the good ideas are, but people want an answer now.
>People are actually terrible at making predictions. I believe the future will surprise all of us. But, I’m going to make a prediction of my own…
>In the future we will see more and more companies proudly boasting their “NO-AI” policy as a competitive advantage. And they will be right.
I will very happily take the other side of this bet. Maybe if LLMs stayed as September 2026 LLMs for the next 20 years, I'd grant it's possible. But that's not what's going to happen.
Are LLMs getting much better at coding? The new models are arguably better at understanding context and coming up with a solution that works but they still write just as much hilariously bad or hacky code as the models did 2 years ago. I e.g. ask Fable 5.1 to make changes to my software and if it's something that's not a standard CRUD architecture on top of a well-specified library it will come up with pretty wild stuff, i.e. producing shell scripts with a "cat" command that contains a 1,000 line Golang program that it compiles on the fly to load some data, or a whole Javascript tool it crams into a string in a server-side web app to make some UI element work instead of figuring out how to do it "right". Another model wrote its own (buggy) YAML parser for reading translations and I had to figure out why it broke my whole pipeline (can't even say why it chose to write that instead of just reusing a standard library, maybe I told it before to be careful when adding untrusted dependencies so it interpreted it as writing everything itself). Seems these systems are always trained to produce the desired output but I think it's very difficult to get training data that teach the systems how to keep the code maintainable when making hundreds or thousands of such individual edits. Honestly not sure if that will get better fast, so far it seems not!
I guess there's no reason to believe these models can't be as smart as a great software architect / engineer or team of such people that build an elegant and maintainable software solution over many years together based on customer feedback, then again the models are appallingly bad at some forms of reasoning, I mean they will "understand" something once you make them aware of it like e.g. a flaw in the software architecture, but when asking them to audit the code and check for issues they will often have a blind spot to finding such problems. It's interesting, like they have very high ability but very little awareness or self-directed thinking outside of the prompts they receive.
They're getting a bit better at coding. My prediction is that by 2029, they will be noticeably considerably better at coding than they are today. That will include them becoming less myopic.
I experience all the same issues you mention. I am just predicting where the ball is moving. In the scheme of things, LLMs have been useful for coding for, what, like... 1.5 years??? What other technology has ever existed where people expect it to go from "just came out" to "changes everything for everyone" in 2 years?
In the arc of history I see us at the very, very early stages of AI-driven software development.
Forgetting about AI for the moment I do like this paragraph very much:
> The proficient developers, the experts, rely on their intuition built with sweat and tears, working long hours trying to debug and fix production issues, swearing to never again be so foolish as to repeat past mistakes. It’s the kind of intuition that can’t really be made into a list of rigid rules, because everything is context-dependent. Experts are incompatible with the same rules and recipes that make beginners more productive. Experts don’t
follow the rules, they make the rules.
.... because I have found the same thing - that there's nobody more zealous about some paradigm than those who are recently converted to it and who haven't come to find that everything has its trade-offs. Design is always about evaluating the trade-offs and seeing which ones most suit the given situation.
For this to work long-term there has to be continuous improvement.
My belief is that paying off tech debt requires a better model than creating it. At the same time there are people who will create tech debt no matter the tool.
Should the models stop improving, the debt will pile up.
I predict there's always going to be a Wirth's law or Peter principle of slopcoding — it will always be easier to tack on a new feature than to understand a whole system and clean it up.
Alternatively stated: codebases will expand to the limit of an organization's ability to manage them, so the equilibrium will remain at the point of near, but not total, incomprehensibility.
It's definitely true. I didn't use AI at all until this January because the code it wrote was too bad. Now I'm comfortably using AI for less important programming tasks and it's okay as long as you steer it carefully. I see no reason why it wouldn't get better up to a point that AI written code is better than what any human programmer could produce. It's also constantly getting better at refactoring.
Also AI is fine at creating maintainable software, you just have to nag it to and not accept its first attempt at it, and subject it to peer review. This is plenty similar to human developers.
Yeah and they’re typically fired for incompetence, or their startup fails, or their product flounders but that’s okay because the company doesn’t need the product to actually be successful.
Meanwhile, the people who work on actual products that matter have a valid criticism that can’t be dismissed with “some humans don’t even manage to do that.”
Yes, including myself in the past. I’m grateful to be out of that situation.
Probably a vast majority of software written never actually gets interacted with by a user. A vast majority of VC-funded software probably never gets interacted with by a user.
Feels pretty great to work on a product that actually has a user, and that user isn’t actually the product (and that user isn’t being manipulated or exploited). Tiny, tiny minority of the software industry I work in.
That does not sound right, I would guess the most code is in enterprise and business applications and people have to use it no matter how bad it is. I would guess only a tiny fraction of code - besides hobby projects - ends up in the trash without ever having users.
I’m coming from the angle that the majority of software written is internal or B2B rather than B2C, and that most critical B2B software features are hammered out in the first couple of years of development while the remaining development cycles are for niche requests to maintain specific clients who don’t actually know what they want and then don’t end up resubscribing / even using the feature.
If you don’t think about it as a per-software criteria, but per-feature criteria, the vast majority of software features developed are probably completely ignored or even untouched compared to the “critical few”.
Very, very long tail distribution. The most executed 100 lines of code (maybe some Java class init snippet, or some Linux kernel snippet) is probably executed more per day than the per-day bottom 80% of all code combined. Maybe the bottom 99.9% of all code combined.
But that is generally true, most things in the real world have a few common cases and a lot of rare exceptions, so every software dealing with the thing will have a hot path and many additional paths that are rarely or maybe never executed. Or look at large applications like Excel, Photoshop or Blender, they have a million features but most user will probably never use even a single percent of them.
If you would fire all incompetent [1] software developers, there would be almost nobody left.
[1] There is probably a more fitting word, I am just reusing incompetence here, but that is not a really fitting description, I think. I would maybe say carelessness or something like that, but a single word is not going to capture the issue accurately.
Same with pretty much any other profession. Hunting for reliable and reasonably-priced HVAC, plumbing, handymen, etc. is a part-time job.
But the point OP was trying to make is that because LLM harnesses output code that is at least better than the worst, say, 20% of developers then we should be fine with it. Meanwhile, I’ve worked in shops where you have to be way above the worst 20% in order to keep your job or even be hired in the first place. And it isn’t some crazy lose-sleep-over-it, stressful requirement. It’s just that literally if you’re not good enough your work will be identified as a liability and you’ll be let go. It’s only happened to 3 people fwiw.
I think crappy code that looks like crap, is better than good looking code that is actually crap if someone cares to look..at least it can be fixed early.
LLMs commit crap, and read the "pattern" back, and consider it as gospel and repeat it all across the code base...
That's like asking why senior/staff engineers tend to review more code than write themselves. In certain environments there's a scaling constraint, and you can generally have wider impact through oversite than typing at a keyboard yourself. That's not to say one is more worthy of your time or not, just that it's not unique to AI.
Generally though, you are also investing your time into leveling up junior engineers to take over responsibilities from you. I just never really see that happening with AI. Even as it gets "better" technically, there's no real growth pattern to its work and it doesn't understand ownership or responsibility.
But if scaling isn't a problem, then sure just write it yourself.
Same reason you’d hire engineers rather than expecting the CTO to do all the programming?
It doesn’t take much effort to setup cross-agent reviews and automatic reviews for slop and accretion, while directing design decision questions back to the human to consider. I have had a considerable increase in throughput of code that I designed and made the important decisions about, and that I’m pleased with the quality of, although as always in these discussions, someone will be a long shortly to tell me that that implies I must be a terrible engineer.
But people don't use AI the way they use human beings because it's a technology and it's being consistently overhyped by its own makers as superhuman intelligence
Improvement can still be happening, and it can be happening slower than it was a year ago. Both can be true.
And the observation that it's happening slower than it was means, not that it's stalled, but at least that it's not exponential anymore. The exponential phase is already over. That has implications for where we think the plateau is likely to be.
> Fact is, vibe-coded projects devolve over time into an unmaintainable mess.
Is it a fact though? Maybe my projects aren't ambitious enough, but about 6 months ago I stopped hitting the point where AI can't maintain what it has written. It's probably unmaintainable by humans, but that might be an increasingly irrelevant quality.
the thing is.. the author says all vibe coded projects devolve into an unmaintainable mess, well so does all software, I have never seen any large scale software project that was absolutely beautiful over time, at least not in gaming and enterprise
it just doesn't happend, too much time pressure, and low-hanging fruits must be had, money must be made, and so it goes... that begs the question, if most enterprise software and/or game projects are an unmaintainable mess, yet they still make money and "work" somehow, whats the value in "beautiful" projects/architectures/code over time, if it provably works either way?
> and let’s be honest, most code in the wild is pretty bad
Most code in general is bad by some metric, and likely many metrics. Let’s not pretend that closed-source, in-house code is better.
> There is no fitness function you can define for maintainable code, at least not one that we can discern, otherwise it would’ve been baked into our linters.
This is emotionally appealing because it tells me that my judgement is irreplaceable. But it’s also essentially an appeal to magic. A metric than cannot be defined is either not real or is a matter of taste. And maintainability cannot be a question of taste because it makes concrete claims about the software, not just human perception of it.
All this is to say that we have yet to establish that “vibe-coded projects devolve over time into an unmaintainable mess” is a fact, or that it’s more true of vibe coded projects than hand coded projects. We are still learning how to build the right guard rails on vibe coded software because previously we relied a lot on humans reasoning over the code and saying “this looks about right” which frankly is not a strong engineering practice to start with.
Hard disagree. Usually I am wiser than the AIs but there have been times where the AI has pushed back and made me see the light on some poor design I was about to pursue
Sometimes, a rubber duck is good enough. But sometimes, you can benefit a lot from a rubber duck that can say "actually, your entire line of reasoning is wrong". Even if the latter is more frustrating.
I think the issue here is the nebulous definition of vibecoding.
You, as an experienced engineer, are doing a lot of hand holding and review of LLM-generated output, maybe even(?) using it as purely a check on your own work. There are others, though, that are essentially outsourcing the entire process to a basic, underspecified chat prompt.
It's a mix. There are some projects where I let the LLM mostly run free and I focus on architecture. Even through some scary parts. Recently I picked a parallelization scheme for this and let the LLM cook. I have no idea how it implemented it, except that it (supposedly) "does it the way I asked:
Honestly, I'm not clear where the line is as far as what is reasonable, and it seems to me that no one is really addressing that question. It's easy to wave your hands and say "vibecoding is bad", without really defining what vibecoding is.
I suppose it'll be a few years before we see the true volume of technical debt catch up with the worst offenders, but even then, without the original LLM conversations associated with it, it'll be difficult to assess that in a structured way. Mind you, that doesn't even address the ever-improving models.
I'm not quite a doomer. I use AI every single day. I also take a fairly negative view of AI generated code, but I think it's unavoidable while remaining employed these days. A fact I find pretty depressing.
I absolutely agree with the author that humans need to be in the loop reviewing and understand the code they're merging, and generally take a "Hey, build X like Y utilizing Z" approach when using AI to build instead of the "Hey, solve this problem" approach. Our PE overlords actually mandate the latter, but I'm not doing it.
However, a point the author misses is that with AI, major refactors become relatively quick. Hours instead of months/years.
Yes, AI can and probably will land you with major foundational and architectural problems, but your architecture isn't set in stone anymore. Your entire codebase bends like a leaf in the wind.
Yes but if you don't care enough to think about, analyze, and decide how to improve your architecture, it doesn't matter. And I'm seeing that a lot with full vibe code code bases
Yes, and I'm arguing you can absolutely vibe code your way out of a corner you vibe coded your way into. Especially with enough vibe coded functionality tests. Your codebase is entirely mutable soup.
Caring about the architecture only matters if you intend to build on top of it, where it become hard to mutate for needs. Big refactors are quick and (relatively) cheap if you don't care about the code.
Don't get me wrong, I am not in any way a fan of vibe coding but the "you're going to vibe code yourself into a corner you can't get out of" argument doesn't hold water.
> I'm no luddite, I’ve integrated AI in my everyday work, while actually teaching my colleagues what I’ve learned
It's appalling that we still hold on to such things that are no longer necessary. Code maintainability is not a problem when you don't have to open a file and inspect how something works anymore. You use english to add to it. You sit on chairs everyday where you don't give a shit how they were created. They fulfill their purpose. hopefully the same can be said for your software.
> Code maintainability is not a problem when you don't have to open a file and inspect how something works anymore. You use english to add to it.
Hilarious and unhinged junior dev and/or outsourced dev and/or expert beginner take here.
Not everything is baby's first React app for an internal business or B2B SaaS startup with 3 users. Sometimes your software is actually used by people, and bugs happen, and you need to figure out why bugs happen, and quickly. You do this by reading the code. Yes, AI is very helpful with this--sometimes. But even SOTA agents cannot solve every bug, particularly when the person directing them has no clue what they're doing, as in your case, so they aren't given good constraints or starting points.
>It's appalling that we still hold on to such things that are no longer necessary. Code maintainability is not a problem when you don't have to open a file and inspect how something works anymore.
Even if you never read/write code anymore you still need to care. LLMs also suffer from a bad code. LLMs very quickly lose track of their own shit and start producing more bugs.
you don't need to read or write code directly to prevent it from becoming an unmaintainable mess. they way you prompt, the loops and skills you build for your harness and the way you set structure around it can get you most of the benefits of reading & writing code manually
Here's the one simple trick that fixes everything:
- Use the code that your agents write in anger.
There you go. Do I know when my agents fuck up? Yes, I absolutely do -- because I'm a user of the code I have my agents write, and I ask things like "why is it taking 50 ms to start this program ..." and then I go in and find stupidity, and excise it. I do this over and over again.
Is it faster than writing it out by hand? Maybe! It's definitely a different perspective.
Start behaving like a baby "why, why, why" and then do a bit of reading, and you'll be fine.
A lot of these blog posts seem like they're aimed at software written by B2B companies who don't even use their own software ...
And, so what? Software as an engineering discipline has long lacked standardization and regulation to be on par with other engineering disciplines, and the fact that code and all its surrounding ecosystems are not "visibile" or "malleable" makes this extremely hard.
You can use terraform and yaml to define infrastructure that literally spins up machines _somewhere_ in the internet. With all its issues, bugs and associated consequences mostly being ignored.
I just don't understand the difficulty in KNOWING what needs to be done: NO LLM usage in university/grad/high schools, NO LLM usage in the first 3 years of your professional career.
Once the basics are solidly grasped, then they can use it at will.
The problem has never been about wisdom, knowledge or LLMs writing good, bad, maintainable or terrible code. It has always been about the skill level of people using it AND on the fact that people start off-loading basic things to these models that they wouldn't before.
If you have the knowledge and "suffered" through experience to learn the fundamentals, than not using LLMs becomes more deterimental than beneficial.
You just CAN NOT skip the trial by fire of learning and absorbing knowledge on your own. That's all.
This is one of those predictions that sound very wise and do well on Hacker News, but will turn out to be completely wrong. For the simple reason that we’re basing all our assumptions on decades of learned behavior predicated on coding being expensive. Writing code has historically been expensive and, by extension, so is maintaining it.
But when you can literally generate a whole codebase in a few hours, a lot of these assumptions don’t hold up. That doesn’t mean you don’t need sound logic and maintainability. But a lot of the small things you think would go wrong because of a bloated codebase stop being meaningful objections when you can keep generating, testing, and reworking it until those issues are resolved.
A lot of what we consider good engineering judgment is shaped by the constraints we’ve always worked under. I don’t think people appreciate how much of that changes when those constraints go away. The "slop" problem is ultimately a verification and testability problem.
A book that has shaped my thinking on AI, and much else besides, has been Horkheimer's Eclipse of Reason.
This book gives a conceptual groundwork for what I believe to be both the promise, and crisis of AI. AI excels at, and either will soon or already has surpassed humans at a kind of reasoning that Horkheimer calls "instrumental reason." This is reason as a tool for achieving ends. AI will, I think, surpass humans at writing maintainable code, as this falls within that domain. The writer is thoughtful, but the obstacles listed in the article are technical, and they will likely fall.
A second kind of reasoning, which he calls "objective reason," is reasoning about which ends are worth pursuing. Our contemporary pragmatic, positivist culture in the West has a hard time reasoning about ends. We tend to just see different perspectives, competing power networks, etc. We are skeptical of capital-J Justice, for example. We tend to see it as historically and culturally contingent, or else as a mask for powerful interests. Horkheimer believed this learned relativism was responsible for new forms of domination and control that emerged in the 20th century in both totalitarian and putatively free societies.
I think the author's thesis would be correct if it had focused on AI's inability to discern ends. But that then raises the question: can we discern ends? Horkheimer never settled on a way to rehabilitate objective reason. He focused on critique, and his critics suggest he ended up with a tangle of negations that couldn't hold up any objective ends. I think rehabilitating objective reason is the task that faces us whether we like it or not, given our moment in history with the advent of AI. It's something practitioners need to think about. Either we recover the philosophical tools of objective reason in light of the critique which caused them to be discarded in the first place, or ends will be imposed arbitrarily by any and everyone with the means to do so.
In traditional software development process two artifacts are created. The obvious one is software. The second, is knowledge of the problem domain in the development team heads.
We could take the Hofstadter idea and say that there is an isomorphism between these two artifacts. Software is a manifestation of the team's knowledge the way an organism is a manifestation of a genome.
With AI, the second artifact is no longer necessarily produced. We don't need to have a team that, as the project progresses, slowly becomes a group of domain experts. Experts that can drive the project direction. Experts that, with time, can see the flaws in their first project and start new breakthrough projects to fix these flaws.
We should start building our Dyson Sphere now because the only solution to bad computation is more computation. Evolution through competition is the only way forward I see. It won't necessarily improve human legibility without feedback, though. And in the end, we can't care TOO much about legibility.
Imagine breeding a new tomato plant. One is robust and tasty, the other is neither, but the genetic code is easier to understand. Picking the legible plant, because legibility is important to you, and may make future tinkering easier, is a dead end. Being able to create a billion different tomato plants and applying selection pressure is more effective, if you have the resources.
The idea that we are applying all this effort to make creating nauseating ads and heinous travel booking sites easier disgusts me, but hey, whatcha gonna do?!? :-)
> Fact is, vibe-coded projects devolve over time into an unmaintainable mess. The reason is simple, yet hard to fix: code maintainability and good architecture don’t have good measurements that we can apply, because it takes months, years even, to notice the effects of bad architecture or of unmaintainable code.
>
> For one, AI is not trained on what it means for code to be maintainable. For instance, any reinforcement learning done needs a reward signal that can be measured immediately, not in months or years.
Sad to say, but this is no different from human written code. Human written code just takes even longer to realize the mistakes because the pace is slower.
I think at the end of the day, it is not impossible to have AI write "good" or "high quality" code. If anything, once the patterns are established, AI will be more likely to adhere to the patterns and rules than any human team. It requires the most experienced engineers on the team to split their time writing the core patterns and documenting them in references/skills.
But it takes a lot of "taste" and a willingness to slow down a bit with AI (to create necessary artifacts), something teams find hard to do when you can ship so fast now.
My experience has been that there is a camp of very senior engineers that are unwilling to adapt to reality and focus on documentation and writing (effectively producing skills and agent guidance which multiplies their effectiveness); they will cling to their knowledge thinking coding a sacred art.
> Sad to say, but this is no different from human written code.
I don't think so. It's true that human also write shitty code but the key difference is we actually remember what is the intention behind those crappy implementations so someone can fix it later. aka it is the matter of long term memory that currently LLM architecture is not capable of.
You can argue that claude can read the whole linux codebase and report bugs, but they can only report local bugs, not systematic one. 1M context windows seems like huge, but the effective range is actually pretty limited, and it still does not equal to human insight.
> aka it is the matter of long term memory that currently LLM architecture is not capable of
Long term memory is easier than you think when you consider what an agent has to do when it is reading and editing code: instruct the agent to leave comments on its rationale and reasoning directly in the code. This is infrastructure free memory that every agent that then sees the code will read. Your code review agent will see the reasoning and decision making your coding agent formulated. When an agent comes and refactors this code in 6 months, the comments will be there (and it will update it!). When an agent is trying to troubleshoot an issue, it will read the comment. No infrastructure needed! Don't overthink it; use comments.
Code comments are line-of-sight for agents and one of the cheapest, highest leverage ways to get better coding performance from AI because unlike skills that may or may not activate, comments end up in context as long as they are well placed and carry the right instructions.
Best places to have it leave comments: 1) start of the file because it frequently uses `sed -n 1,200p` to read files and 2) inside the body of the method because it may find by keyword and read a few lines past. If your harness is set up with an LSP, language standard comments are also useful because then it can read comments on the member.
Tips for comments: point it to other, related members or artifacts; point it to external canonical docs; point is to a specific issue number or PR; have examples directly in the comment using your language's example markers; point it to example, reference usages in code. Use AGENTS.md to tell your agents how you want it to leave comments and to specifically read, follow, and maintain comments.
You don't need infrastructure or special architecture; Every coding agent is text-in, text-out. You need comments that get carried with text-in and a bit of guidance to the agent on how to use comments effectively.
No, developers definitely do not remember what they did two months ago. If you are busy, even two weeks is a problem. That is why we discuss documentation so much, self-documenting code, tickets and tests.
I've seen LLMs "connect the dots" across complex systems many times before. When it works, it's shocking how quickly it can pin down a bug that spans across the software stack.
1M context window is plenty. Once it's skimmed the code and come up with a theory for the problem, it can spin up a subagent that has a whole fresh context window and it can dedicate the whole thing to that one hunch.
To me the difference is humans (ideally) will learn when they build something in a non-optimal way, and so will improve over time to become a competent engineer / architect. We cannot be perfect but to me a huge part of life is learning from failure and improving yourself, something that LLMs short-circuit and cannot replace.
LLMs cannot truly learn and so are destined to produce whatever the "average" software looked like at their training cutoff, or worse to produce code based on _other_ LLM generated code.
LLMs learn, and in two main ways: in-context and in training stages, release to release. The former is quick and sample efficient - perfect for adjusting AI behavior on the fly, and for enabling AI's own problem-solving capabilities. The latter modifies the "behavior defaults" and gives you performance gains that stick.
Why do you think that "write maintainable code" is somehow impossible to learn for an AI? We already have AI storming the frontiers of research math - way beyond the "average" of the field. If you can RL for "better at math", I see no reason why "better at maintaining code" would be somehow impossible.
You can construct an RL env where a codebase is presented as a "tree", and the AI is given one change to make at a time - and the per-change reward is not just whether the change itself has been evaluated as "made successfully", but also whether it made future changes down the line more or less likely to be successful, and harder or easier to make.
This is a formulation already used by some "maintainable code" benchmarks, so I expect something like it to make is way into frontier lab RL pipelines some time between "next week" and "a couple months ago".
Yes, "code rot" is not in any way an AI-unique problem. Codebases like Flash Player or Bethesda Engine have been deep in decay long before AI was capable of contributing to them.
Historically, this was caused by hiring the cheapest developers one can find, having high turnover, outsourcing, pushing to ship at any cost and more. AI just lets you get there faster, and without having to hire bargain bin Indians.
The thing is, today's AI is already far better at "code rot per feature shipped" than the worst of developers - and I struggle to believe that we're at the limit there.
I've already seen benchmarks that test for AI's ability to make incremental changes and tweaks to code continuously - thus, tracking whether earlier changes make the latter changes harder. This makes for a clear target to RL for.
AI is not better nor worse at producing code rot; just faster at it.
AI produced code is a function of the team driving and instructing the agents along with the scaffolding produced by the team (skills, examples, docs, comments); same with human teams.
A team that cannot guide a human team to produce better code will not be able to guide an AI team to produce better code because it's the same skillset: being able to write good docs, create constraints structurally in code, produce core architecture that enforces good behavior.
Not entirely wrong, but there's a very big hole: "the scaffolding produced by the team" also includes the scaffolding produced by past AIs.
An AI that knows how to keep the documentation accurate and up to date, and does it by default, would, all other things equal, rot your codebase less. An AI that changes the code without checking whether it obsoleted a bunch of examples in the docs would rot your codebase more.
While I think that you can reduce "AI-induced code rot" with good prompting and steering, you could also make headway against it at model level, by making the AI "well-behaved" by default.
> "the scaffolding produced by the team" also includes the scaffolding produced by past AIs.
This statement is also true of humans. Everything you've stated here is also true for human engineers.
> "the scaffolding produced by the team" also includes the scaffolding produced by past engineers.
But the agent can be instructed reliably to keep documentation accurate and up to date and will then do so dutifully. Put it in AGENTS.md that it must always update the /docs directory by creating a new doc or updating an existing doc and it will do it. (Yes, adherence may be 95% of the time, but that is likely several points higher than with most non-NASA human teams)
Better yet, extract docs from code comments. Even better when the docs are spatially co-located and line of sight as the agent crawls through code.
> Human written code just takes even longer to realize the mistakes because the pace is slower.
Yes but the ceiling is still higher, and that's the author's point. If you vibe code, without code review, code becomes a mess quickly. If humans write code by hand, then this is often the case too, but crucially, this is not unavoidable. Sure, most codebases are a terrible mess, but some are not. AIs unfortunately got trained on all of them (+ reinforcement-learned stuff) and therefore their quality standard is about as low as that of the average codebase, ie pretty damn bad.
But there are plenty examples of acceptably decent yet long-lived codebases, both in OSS and inside companies. You simply couldn't get that quality by vibe coding. (unless you review every line of code and every design decision, at which point you're about as fast as you would be writing it all by hand, assuming some seniority)
>Sad to say, but this is no different from human written code. Human written code just takes even longer to realize the mistakes because the pace is slower.
I really don't think so, poor written human code IME is rarely overly complex, where as the AI code is almost always vastly over complex. Naturally complexity can be an issue because it leads to more surface area for failures and challenges to diagnose, but where I am REALLY seeing an issue is the complexity hiding an issue. Something that should normally fail or produce an error is covered up by something multiple layers deep in the code that returns an incorrect value instead of an error when something goes off the rails.
AI written code is a function of the human created constraints around it.
That is why I believe the most senior engineers on the team with the most scars and most experience need to shift into writing those constraints instead of writing code.
In writing those constraints, they can multiply their effect across a tireless fleet of agents that generally want to copy existing patterns and can be guided to use skills.
> Sad to say, but this is no different from human written code. Human written code just takes even longer to realize the mistakes because the pace is slower.
When the pace is slower you can notice mistakes earlier because you have time to reflect. It also allows you to detect when it’s becoming hard to maintain and you can correct course, rather than after it has become an unworkable mess.
It doesn't mean that people do. This is a false narrative we tell ourselves. Yes, there are craft-oriented devs and teams, but these are the exception rather than the rule because in the end, it is the GTM and business teams that define what, when, how and rarely the engineering teams.
There is no team without tech debt because there is no "golden" project where every decision has been made right because of reflection on decisions made wrong.
After a certain point, people would be forced to refactor, because they find themselves unable to handle the complexity.
With LLMs, there is no such friction. So the complexity get piled upon complexity in the form of a million best practices that is indiscriminately followed...
> After a certain point, people would be forced to refactor, because they find themselves unable to handle the complexity.
This is a fallacy; this is why legacy code exists that teams just work around. They lack the tests to verify it, the person that wrote it is long gone, it's handling some mission critical dataflow so no one touches the code and just builds around it.
>They lack the tests to verify it, the person that wrote it is long gone, it's handling some mission critical dataflow so no one touches the code and just builds around it.
> Fact is, vibe-coded projects devolve over time into an unmaintainable mess. The reason is simple, yet hard to fix: code maintainability and good architecture don’t have good measurements that we can apply, because it takes months, years even, to notice the effects of bad architecture or of unmaintainable code.
False. AI is evolving by leaps and bounds and the outputs are better and better by the day
Personally, repeating what the article says, I haven't coded since may 2026, not a single line, and AI has been delivering exceptional results, improving by the day
Any AI related article necessarily needs to consider future improvements as they will come not by surprise but by steady refinements, and posts like this will look just like the same early AI slop they complain about
They can't think that a software can be written, designed and maintained in English or higher constructs.
It is binary of either vibe coded app, or worshipping the code that they worship (and I spent 20+ years on)..the industry is moving on faster than most can wrap their heads on, but for those who understand software engineering was always beyond and above code, they will adapt, meanwhile, those who built their entire identity and skillset around managing code will struggle. There will be a place for those people, but it will be niche and specific, and we won't need as many.
> it takes months, years even, to notice the effects of bad architecture or of unmaintainable code.
I think this is a bad take... if you are going that long without noticing, you are (hopefully) delivering end user value all that time. That is the main driver of code. You can normally dig/hack/rearchitect your way out of an ugly code situation. If you've been building value for the last year based on the hacky code, that's a win.
I think this is a form of path dependency. We talk about unmaintainable messes, but honestly, if you look at Kairosoft or famous game codebases, you'll find 30,000 lines in a single file or just completely chaotic code. I am actually in a position where I see bad code all the time.
The truth is, "good code" is relative. It is determined by the specific domain and the composition of the team. Is incomprehensible FP (Functional Programming) code good? No, it isn't. A programmer must assess the team's capabilities and adapt accordingly. Good code is ultimately something that morphs based on the shape of the organization. Once defined this way, good code might share certain commonalities (like readability or a shared mental model), but its actual form varies wildly.
So, what is good code? That definition is missing. To be blunt, the Hacker News posts insisting that we must write "good code" are essentially a form of self-hypnosis.
Just look at paradigms. The mechanics of OOP have changed significantly, FP approaches have evolved, and DOD or DDD are fundamentally different from their early days. Whenever paradigms are discussed, someone claims, "That problem was solved in the past, and nowadays we do X," only for someone else to reply, "I don't think that's actually solved," leading to a fragmented breakdown in consensus. Ultimately, which knowledge remains as tacit knowledge is entirely dependent on the organization's capability.
You could argue that AI is terrible at simplifying code. However, I am skeptical that AI coding needs to be identical to human coding. When you actually code with AI, it often produces structures humans would call anti-patterns, including God Objects. Yet some of those structures can be faster or simpler for machines to navigate. There is no reason to assume that the optimal modularity for AI maintainers must be identical to the optimal modularity for human maintainers.
Of course, I am not denying that the rewards of good architecture are delayed, or that there comes a point where maintenance becomes impossible. But as the AI era ushers in an age of overproduction, software could become disposable, strictly personal, highly tailored to small niches, or ultimately, heavily polarized.
Realistically, programming domains fall into two major categories: "ship it and forget it" (one-offs) and continuous services. I agree with the OP's point that AI struggles to understand boundary delineations. But honestly, you can enforce those boundaries by injecting them into the spec. How those boundaries are drawn in the first place, however, is purely a matter of personal experience.
Personally, I define "good code" as code that allows the entity responsible for the software to achieve its purpose with a sufficiently low cost and error rate, factoring in the software's expected lifespan and future changes.
If you ask an AI to generate work based on this standard of what level of code is "adequate," you might get entirely different results. The biggest problem with discussions around AI is not just that ideological identities prevent proper evaluation (as seen in that article), but that the AI itself scales proportionally to its input. It is an incredibly difficult issue to judge because you don't know an individual's workflow or exactly how they are utilizing the tool.
I do think the value of reading code is important. However, much of what we are discussing in the AI era is actually rooted in the path dependency of how to become a good human senior developer.
Instead, the core focus of AI-driven development might shift toward defining broader abstractions: data semantics, invariant external contracts, and migration strategies.
Ultimately, I believe the paradigm shift of our era should lead us to ask: "How do we write code most economically in a system where AI is the primary maintainer?" The OP might think differently, but at least, that is where I stand.
I have more than 15 years in the industry. I have worked in some of the most horrendous codebase someone has ever conceived. Honestly? Humans can do worst than AI.
Let's stop overvaluing human work. Sure, I don't want AI to write the entire codebase without I know what the fuck it did.
But AI is on an equal footing with an average dev.
> because it takes months, years even, to notice the effects of bad architecture or of unmaintainable code.
Well said. The cost of bad architecture imposes a heavy penalty on the project down the line.
> The proficient developers, the experts, rely on their intuition built with sweat and tears, working long hours trying to debug and fix production issues
Long hours of grinding with the problem, the solution, the code and the machine all makes for an intuitive understanding of what a good architecture is in the first place.
LLMs are a tool. A useful tool unlike any we have seen so far. But still a tool. Treating it as such and leveraging it should be prioritized.
The entire field of software engineering has plenty of depth without requiring you to be the person actually writing and reading the code. The author falsely conflates reading and writing the code to be the same as understanding the structure and design and architecture of the system. These two things aren't the same and never were.
Everything is reactionary. The focus is always on short term profits. No one cares about long term effects --- until they start impacting short term profits.
This is an inherent vulnerability that is easily exploited by someone willing to engage in some simple, long term planning --- like China has already done with manufacturing.
For decades, the USA gladly shifted manufacturing to China without a second thought. Now, we lack the expertise to make our own and have no choice but to use China.
Replace "manufacturing" with "software" and "China" with "AI" and it's deja vu all over again.
>vibe-coded projects devolve over time into an unmaintainable mess
The author seems to be confusing "I didn't write any code" with "I don't care about software design and maintainability". There exist maintainable and thoughtfully designed software systems for which the designer did not write any code and didn't read most of it. It's not the median, but the median software project has always been unmaintainable before agents.
Sure but many many developers who are willing to outsource every modicum of thought and effort to AI don't care about design and maintainability. And the supposed "super intelligence" of AI gives them a cop out for that
Those people will never reach mastery, because they no longer make choices, they no longer take responsibility for mistakes in coding and no longer learn from those mistakes. It’s the AI that’s making mistakes now, the AI doesn’t learn from those mistakes, and neither are the people relying on AI for coding.
Just to give a hot take, it's funny to look at his builtwith.com. As a developer you have a static site that depends on Cloudflare, Mailchimp, Postmark, Isso ...
Twenty years ago any self-respecting dev would have run the equivalent of all that themselves on their own metal. In 2026 elite neckbeard practice is write the "never reach mastery, because they no longer make choices, they no longer take responsibility" post, hit "publish" and it's magically deployed around the global internet for you. Like a child.
In the future we will see more and more companies proudly boasting their “NO-AI” policy as a competitive advantage. And they will be right.
Yes, a "NO-CLOUD" policy was already so popular, surely this will happen too.
The argument I'd make in support of the title would be that wisdom is embodied knowledge - knowledge earned from direct experience. Known first-hand. An AI can already have linguistic/technical ability that exceeds a human (at various levels of skill, even) - in coding, copy-editing, what have you. But wisdom? That is the scar tissue we carry from wrong choices. Until an agent has persistent sense of self and a "body" (or pseudo-body) whose existence it is predicated on (thus creating incentivization/outcome alignment), it will not be able to approach "wisdom" in the sense that humans do.
That may seem to have no bearing on the specific subset of tasks related to coding and so on - but it actually does. Humans have a hard limit of attention span, hours in a day, years in a life. An AI does not. So if it fucks things up royally by half-assing an architectural decision, it won't care. And if it doesn't have a persistent memory, it won't even know that it made that mistake before. So it has neither the prerequisite abilities nor the incentives to gain what would be hard-earned wisdom from its mistakes.
In fact, as long as the business model of its creators depends on more usage = more profit, they are actively discouraged from implementing any kind of wisdom-like ability.
For them to be able to offer that without undercutting their profit, they'd need to be able to execute "outcome based billing".
A bit offtopic, but this seems to be an AI pattern everywhere:
>>"The AI learns rules from rulebooks meant for beginners. The AI notices patterns from code in the wild and let’s be honest, most code in the wild is pretty bad."
Similarly, for self-driving, the AI for driving learns from rulebooks meant for beginners and observes patterns of driving from ordinary drivers in the wild and let’s be honest, most ordinary drivers in the wild are pretty bad. The best the AI self drivers trained in this way can hope to get is the average slop driver minus the catastrophic errors.
Similarly, in legal specialties, there are a few highly expert and wise practitioners, and hordes of average practitioners, and quite a few near-malpractice practitioners, and it is the latter group who write the most stuff on the web because that is how they do marketing, trying to make their ignorance look better — and mostly louder — than what the average lay-person knows. The AIs can NOT tell the difference and 'learns', and dispenses both the good and the actively harmful advice. Acdg to relative who is a top expert in their specialty, AIs can both find key relationships between laws in complicated situations but also readily dispense the actively harmful advice, and you MUST already be a top expert to recognize which is which.
They are great averaging machines, but when average is not good enough, you must be on top of your game.
> Experts don’t follow the rules, they make the rules.
No. Most rules are there before and will stay after the expert enter the field within its career path, unless the field is bright new territory no one fooled before, which is rare.
Not only experts have to know the rules, otherwise they wouldn’t be expert, but good experts also ideally know why the rules were set, and at least have a fairly well aligned representation of what it would likely lead to to follow or not each rule in this or that situation, which rules are in conflicts and what the tradeoffs are when favoring one on the other.
Everything is context dependant, yes. And LLMs can help to leverage on far wider contexts that a single individual would be able to do on its own. It’s require interest to reach some goal in some social context, and not everyone will use LLMs with the same creativity.
This week-end I was discussing with a friend about our respective use of LLMs. At some point they told me they no longer read the MR, as LLMs can also do great job on that matter now, which is in sharp contrast with what I do. Not that I don’t auto-review with LLMs, but I use that as a first step, be it mine or some other colleague. And then I ask an LLM to prepare me a reading plan to check the MR, taking into account the activity scope and the implementation architecture. To me it was an obvious way to go, but for them it was something they never considered. That’s random sample, of course they would certainly be cases we would switch the "I wouldn’t have thought about it" role.
So yes, LLMs can be used to produce faster giant piles of unmaintainable codebases. Or they can be used to strengthen processes that lead to code quality. The nail won’t prevent us to knock our thumb, to use a nail in reverse side, or to smash our coworker.
I get the paperclip plant issue, but that’s some extreme scenario (which is of course the point of the allegory), and most bad uses will be far more mundane in how they look and what the consequences are. And most good uses will look more and more transparent to users to the point they won’t even wonder about it at each use. Like, most people open the tap, see water fall and they don’t get a sense of wonder, not giving a thought to this masterpiece of engineering and gratitude for all people that works daily in the shadow for this miracle to happen. They don’t leave the toilets thinking "how freaking amazing such a complex system of wastewater is something I can benefit from everyday, unlike so many other of the 100G humans that walked this earth."
Next time you go to WC or tap some water, think about it.
Not all rules survive by this fact alone, which obviously is as true as the fact that there are people that don’t care about any rule and people that will deliberately break rule for the mere sake of the thrill. Rules can also stop being used, they can keep going on charming sufficient fan base willing to fight for their application in an environment which changed upside down and were every other new rules are directly conflicting with this old one.
I still can't believe that anyone who has used AI and understands development thinks that "No AI" policies are going to exist anywhere but the smallest of niches. Maybe they've been blessed to only ever work with the top 1% of the industry?
At this point AI is a better developer than most mid-level SMEs I've worked with. I hate this fact, but I don't have a shred of evidence to dispute it anymore. I work on a 20 year old codebase that thousands of developers use and it finds bugs in pre-AI code daily.
IMO reviews are more useful for communicating some change to the rest of your team so they can maintain it later than as bug finders. AI is better as a bug finder.
As much as I agree with this article, I feel that there's a logical flaw here. The author admits that it's difficult to measure bad code - but continues with the assertion that it exists. If the only negative to "bad code" is that it's difficult to maintain once the author has left or difficult to refactor, then the question really is whether or not LLMs will continue to be able to maintain their spaghetti code.
Just because it's bad for a human doesn't necessarily mean everything will fall apart - unless a human has to maintain it unaided.
I think the key distinction is that it's difficult to determine whether a single commit or pull request is bad code at a glance, but it's easy to determine when the codebase as a whole has gone bad due to many low quality commits.
The latter often doesn't even require looking at the code, you can usually feel it just by using the software. From my experience, all software primarily written by AI is full of little bugs and inconsistencies that reflect bad code architecture (such as two very similar pieces of functionality in two different places behaving in wildly different ways, due to the AI being unaware of the first when asked to implement the second and writing the code twice)
I totally agree, and I agree with the article in general. I just don't think it follows that code that's bad because humans had to maintain it is necessarily bad by definition.
I've vibecoded loads of AI apps for myself and almost none of them are still in use. Not because I didn't really want them or they didn't work, but because the more I used them the dirtier I felt, as though I could feel the bad decisions and the bugs underneath just by interacting with it.
I think this kind of blog post reflects a fear of infantilization by AI. By asserting that only humans know what good code looks like, the author is attempting to mend his own ego.
Build the systems around the code and let the agents do their work.
The problem imo is the slow deterioration of institutional knowledge that offloading the mental task of wisdom gathering to AI is causing.
One interesting comparison is to the history of manufacturing. West/America decided one day that manufacturing would be cheaper to outsource and better (short term) profit was to be made by outsourcing it all to China. The institutional expertise started to deteriorate, to the point that America simply didn't even have the capacity, or expertise anymore to produce stuff (such as grill brush [1])
I feel like you could take all the handwavy comment that are made today to dismiss this caution, and find equal dismissal back then when companies were actively outsourcing the manufacturing.
"I'm coding 10x faster" "look at the output velocity per employee"
"we are producing much more (in China)" "look at profit / number of (manufacturing) employers"
Seems ok if you're American / Chinese but I'm struggling to understand how the rest can be OK with allowing institutional knowledge to deteriorate while having an active dependency to the former two. We already see this with the tech dependency towards USA and manufacturing competition from China.
[1] https://youtu.be/3ZTGwcHQfLY
> I feel like you could take all the handwavy comment that are made today to dismiss this caution, and find equal dismissal back then when companies were actively outsourcing the manufacturing.
Absolutely people were extremely dismissive to anyone saying that we're losing the ability to make things in this country!
There were all these theories like Comparative Advantage that people would trot out to point out that, if you don't like outsourcing, not only are you ignorant and backwards you're also probably racist.
I specifically remember seeing the ricardian tables, featuring 8th grade math proving how competitive advantage means everyone wins. This was very persuasive to me as a college sophomore, all my professors were on board and I was young.
I guess we were all lacking wisdom.
I remember being a young guy, blue collar background, but in the left-wing anti-globalization movement (think Seattle WTO protester types).
When I was in college or going to parties with New Yorker Reader types I'd try to argue against globalization and they would start smugly dropping their theories on me. I was too young and naive to refute them in any kind of convincing way, but my life experience told me that it was wrong.
But it was pervasive in the zeitgeist. Basically anyone trying to argue against it was backwards and stupid, or shrill if they were lefty.
> But it was pervasive in the zeitgeist. Basically anyone trying to argue against it was backwards and stupid, or shrill if they were lefty.
It was so very weird. Even in Ireland (which was the target of the first wave of US outsourcing), people seemed to believe that everyone could be "knowledge workers" and that industry was unimportant.
I still don't really get why everyone believed this, but they did. Something something Upton Sinclair I guess.
I wonder if the exact date of anti-globalization switching from being a "left populism" to "right populism" thing could be determined.
However I'm not sure it could really be stopped or whether it was inevitable from containerization. Can you really prevent people from getting cheaper products forever?
Again containerization happened in the 1970s and 1980s. The China Shock was 2000-2010.
What technology was invented in 2000 that allowed everything to go to China? No technology. That was the year the US adopted Permanent Normalized Trade Relations with China. It was a government policy change!
By the way the US already had trade relations with China. All PNTR did was promise not to change the policy in the future. That was the starting gun that signaled to all American companies that they should start investing in production in China.
So would globalization happen on some scale just because of the march of technology? Sure. But the way it happened, the speed at which it happened and the extent to which it happened, were the result of policy choices.
Offshoring to Asia began long before it moved into China. What you are describing is the acceleration point of the trend.
I'm pretty sure that China demonstrating that they are a stable country, that they want foreign investment, that they won't gank your investment two weeks after you make it, and that they aren't going to do another Great Leap Forward may have had something to do with why foreign investment in it skyrocketed.
This sort of thing takes time, and by the 00s, enough time (and a recent Hong Kong transfer that did not result in mass liquidation) passed, and foreign investors were gaining confidence.
The world, and especially China has agency of its own, it isn't sorely driven by whatever American policy is it's flavour of the week.
Completely agree Jiang Zemin spent the 1990s courting global capital.
The point is that it wasn't technology it was policy, on the Chinese and American side, that drove the China Shock.
This was also what a lot of anti-globalization people were say at the time. The pro-globalization people were saying not only is it good but it's inevitable. There Is No Alternative.
The anti globalization people were saying if it's inevitable why does it need all these policy changes, trade agreements, and bigwig conferences?
Those would be part of the mechanisms of inevitability (under that hypothesis). Globalization is a phenomenon at the human societal level, they would be predicting human behaviors, it's not like rocks and rivers were going to precipitate it. It's not like those singular events "changed everything" either, it's an accumulation of decades of social sentiments, purchasing decisions, etc.
This whole subthread is from like an alternate timeline where the world actually found out or agreed that globalization was bad and stopped or slowed it somehow? Did the US meaningfully take back manufacturing or something?
If globalization is not inevitable, what's the alternative?
> a recent Hong Kong transfer that did not result in mass liquidation
No, but there definitely was a much slower gradual repression over a longer period, with a final round of protest repression: https://en.wikipedia.org/wiki/2019%E2%80%932020_Hong_Kong_pr...
> The world, and especially China has agency of its own, it isn't sorely driven by whatever American policy is it's flavour of the week
Amen. A two-pole model is simple and attractive but the rest of the world is also, you know, doing stuff and buying things. America can, for example, preserve its car industry by refusing to allow Chinese EVs, but will gradually discover it has become uncompetitive overseas.
>Can you really prevent people from getting cheaper products forever?
Do you even want cheap products? We're all trapped in low-quality-product hell together, and some of us have realized we'd be less frustrated and less poor with something at least not-quite-so-low-quality.
If people could have realized that sooner, and if there had been some vision or political will at the top, stopping this would've been a matter of very boring policy decisions. It wasn't inevitable. Containerization might have made it easier, but it didn't make it irresistible.
anti-Globalization on the right has nothing in common with anti-Globalization on the left. The only thing they share is the name. And is probably the reason we don‘t call it anti-globalization any more, but rather simply anti-capitalism or more accurately anti-global capitalism, or anti-imperialism. Anti Neo-colonialism used to be popular but is already (and rightly so) falling out of fashion.
Even back then people on the left had a problem with the term globalization. On the left it was wildly recognized that the term came from the right to decorate global capitalism and (what was then called) Neo-colonialism in a more palatable light for liberals. In Iceland we used to make fun of it and said it should instead be called Americanization.
Right-wing anti-globalization is basically just hating foreigners (except white Americans), and supporting border fascism. Interestingly the right wing types in Europe love American culture, and have no problem with America spreading their capitalism and Neo-liberalism world wide (they only hate it when the EU does it).
Irrational exuberance
> I guess we were all lacking wisdom.
Yes, economists famously do, and they also lack intelligence and knowledge given that their theories keep being proven wrong by reality but they never update them.
Economists have effectively become a priestly class, dressing up the ruling ideology in "science-y" robes so as to communicate authority. All social sciences are at risk of doing so, but they fall right into this hole the instant that they don't perceive the world as it exists.
A trained economist either sells out to the Overlords or he gets a job as a barkeep. Or he ends up as some crank in a half-forgotten nonprofit somewhere. There's no middle ground.
Human intelligence is a remarkable adaptation, but "tendency towards delusion" might be the decidedly maladaptive trait that comes with it.
> All social sciences are at risk of doing so,
It's like saying that the Titanic was at risk of sinking after it hit the iceberg.
> A trained economist either sells out to the Overlords or he gets a job as a barkeep.
That's what training is for.
> Human intelligence is a remarkable adaptation, but "tendency towards delusion" might be the decidedly maladaptive trait that comes with it.
I'd say the reason is more external than internal - personal interest is a mind bender.
They're the mandrins of our modern age. Their role is to make what our rulers want to do sound smart and reasonable
okay lets do wide spread price controls and wealth taxes it'll be great
If there are not history books out there that try to discern the etiology of those decisions, there really should be.
And they were right. American manufacturing is $3 trillion/year, second only to China, and 1/5th of the entire world. American built airliners and American built engines fly all over the world. Millions of American cars come out of factories every year. American rockets put more into orbit than everyone else combined.
The idea that the US lost its manufacturing is not based in reality. One reason people think that is because people think cheap plastic crap and consumer electronics when they think “manufacturing.” Another reason is that US manufacturing has become highly efficient and automated, so a fairly small portion of the population works in it.
Yeah, your iPhone wasn’t built in the US. But the plane that got it here probably was.
> And they were right. American manufacturing is $3 trillion/year, second only to China, and 1/5th of the entire world.
Values are 2021 because that's the most recent available for US at the same source, to keep consistent.
World Manufacturing output: 16.16 trillion https://data.worldbank.org/indicator/NV.IND.MANF.CD
US Manufacturing output: 2.5 trillion (15.47% of world) https://data.worldbank.org/indicator/NV.IND.MANF.CD?location...
China Manufacturing output: 4.85 trillion (30.01% of world) https://data.worldbank.org/indicator/NV.IND.MANF.CD?location...
Whatever analysis you make, let's use the correct numbers, from which you were off by about 1/5th. Should you think that is a negligible margin, you'd have to consider the US participation in global manufacturing output as similarly significant.
You’re using numbers from five years ago and you’re going to hassle me about not having accurate figures? What the fuck.
> You’re using numbers from five years ago.
I'm sure fresh numbers are available, they're just unpublished.
We could do some educated guessing here - in the last 5 years China's economy grew at the rates of 8.6%, 3%, 5.4%, 5%, 5%, the US grew at 6.5%, 2.5%, 2.9%, 2.8%, 2.2%. We can extrapolate the manufacturing numbers based on that, which would give some advantage to the US because the US manufacturing lags the average, while the Chinese leads it.
The math gives us the current values for
World: $19.4 T, (%6.5,%3.4,3x%2.9)
China: $6.3 T - 32.5%,
US: $2.9 T - 15%.
> You’re using numbers from five years ago
Four. 2021 vs 2025. Unless you have numbers from 2026 from the future.
> and you’re going to hassle me about not having accurate figures?
Merely pointing out. The subjective interpretation of the experience is entirely on you.
> What the fuck.
Get more recent numbers that show I'm wrong and your 3 trillion & 1/5th of world total is right then.
$3.000 trillion annualized in Q1 2026: https://nam.org/mfgdata/facts-about-manufacturing-expanded/
Ok thank you for finding more up-to-date data for US manufacturing GDP. Let's re-do the analysis with 2025 data, because I draw the line at using annualized data for a year that has not yet ended.
World total: 17.6 trillion (https://data.worldbank.org/indicator/NV.IND.MANF.CD?location...) US: 2.961 trillion, 16.82% of world China: 4.82 trillion, 27.38% of world total
So you were very much closer to the 3 trillion figure (again, 2026 annualized data is not current, it's forecast). Still quite off from the 1/5th of total. About the same as the EU - 3.03 trillions for 2025 (https://www.macrotrends.net/global-metrics/countries/euu/eur...)
In terms of participation in world total the US has come down from 22.44% in 1997 to 16.82% in 2025 losing 5.38 percentage points or a loss of over 1/5th in less than 30 years.
I'd say there is some justification to claim a decline in US manufacturing.
Again thank you for engaging productively and providing up to date data. I feel like I should offer praise as I chastised you for cursing at me for using data 4 years out of date.
The 1/5th is definitely very approximate.
There’s a decline in the relative share, but that’s down to the rest of the world growing. Adjusted for inflation, 1997 was slightly below the current figure. That’s nothing to brag about, but it’s a far cry from the “we don’t make anything anymore” narrative I see so much.
Where it has declined substantially is employment. That peaked at almost 20 million at the end of the 70s and is now under 13 million.
Yes. I do agree with you on
> The idea that the US lost its manufacturing is not based in reality.
But I disagree with your claim that people are right in being extremely dismissive of losses in US manufacturing.
>> Absolutely people were extremely dismissive to anyone saying that we're losing the ability to make things in this country!
Interpreting that as a complete loss of manufacture capacity I agree with you, with the qualification that concerns of relative decline were justified since there was a definite decline in aggregate.
I have to say that overall I don't think economies and citizens of these economies should prefer certain economic activities over others. In principle I think specialization is a good thing. On the other hand, I do think that the US has committed some strategy mistakes in terms of how much manufacturing activity was moved out of the country and how dependent it has come to be on foreign supplies of, for instance, rare earths and advanced IC.
But that analysis is predicated on US strategic goals and geopolitical intent. The coming impasse over Taiwan with China is almost completely self imposed due to the prioritization of short term corporate profit over strategic goals.
But that is a different conversation altogether. I think data from the past 30 years show that alarmism over de-industrialization was overblown as you said AND that there has been nonetheless a significant decline in the previously absolutely dominant position of the US economy in global manufacturing. If that is good or bad, to whom or to what ends, is way outside the scope of internet forum messages.
And do you know where the tools and dies to make those things come from? Where the robots that work at those lines come from? Where the chips in those robots at those lines come from?
Hint: not here. Even basic machining is cooked here. Go on Xometry and compare the pricing of any simple design made in USA vs. China and you’ll see, we can’t competitively do the basics anymore (you conflate basic with crap).
If you go back to WWII America was the China of the world: mass produced products if midrange quality.
Europe owned high end quality, especially Germany.
Most Radar technology was invented in the UK and then sent to the USA where American engineers would redesign it for mass production. You'd have a magnetron that the British machined at great expense and the Americans would redesign it so it could be stamped out by the thousands.
Germans would look at the wrecks of bombers they shot down. Early on they'd look at a B17 and say "this thing is crude" but by 1944 they'd look at a late model bomber and say "we don't even know how they made some of this stuff".
People have it entirely backwards. They think if you can do high end manufacturing the low end is easy. In fact if you can do mass production of low end parts with consistent quality then high end stuff is easy.
We can't manufacture most of those low-end things at competitive prices with developing nations - and we never will be able to (or else we have bigger problems).
So who's going to buy the low-end stuff at high-end prices?
You can try tariffs and the like (as we're foolishly doing right now) - that usually ends up having the opposite intended effect. You make everything more expensive domestically, including manufacturing (b/c your inputs got more expensive), and hurt our ability to export, even the things we did well.
Meanwhile, the rest of the world unencumbered with protectionism reaps the benefits of free trade and out competes us.
All this eventually leads to a loss of manufacturing jobs and output and manufacturers that can only sell to the domestic market (instead of the whole world). The whole sector starts to shrink. So that's no good.
America has lots of natural resources (even more when we're friendly with Canada) cheap electricity, good transportation infrastructure (historically).
China has to import much of their raw materials. Wood from SEA and Russia, oil from the middle east and Russia, even coal, ore and beef cattle from Australia! They don't have the water supply, forests, mines or oil that exist in North America.
There is no good reason for them to be the manufacturing center of the globe and there were rational reasons why the US was the center of manufacturing in the globe in the 20th century.
The reason they became the global center of manufacturing was policy choices in China and the US at the turn of this century, and the reason why they remain the center of manufacturing is they developed a massive amount of capital and know-how in an era where the USA was actively destroying its own.
China has plenty of coal. They import metal refining coal, which they don’t have. And they import thermal coal because it’s easier to boat the stuff in from Indonesia than move it east by rail from western China.
Australia was never very interested in being a manufacturing power house, they simply don’t have the people for it anyways, and it’s easier to ship raw material than finished goods vast distances. Russia has the same problem in population so China is convenient for them. China would have happened even if the USA didn’t help it along in 80s-90s.
Australia in the mid 70s was party to the Lima Declaration [1]
Presently there's a lot of yap how it didn't or wasn't the reason Australia lost its way to retain its manufacturing sector. Indirectly though it was bouncing around the walls of Govt and industry's board rooms and pushed decisions to reduce or discontinue ongoing training in regard to upskilling, or simply improving skill sets that might be needed in the unemployed working class.
However much of the shift way from general manufacturing was the inevitable result of the declaration, the inability for a small manufacturer in places like Australia to compete with cheap imports - I recall a relative back in 1979 - 80 having a long rant about a manufacturing company near him - the whole problem was the small dry cells the company purchased at quantity to install into an electronic device - the exact same branded dry cells were available to their oversea competition for next to nothing and could / did sell their version cheaper than the purchase price the company was paying for the batteries per unit.
The other part of the issue was those industries that opted to hang on - the bogey man here again was the thinking that it would be better / overall cheaper for manufacturing sector to be elsewhere overseas. Thus with this mindset setting fruit in the higher branches of the wealth market, there was not much help from Industry heads or Govt at the time to encourage or provide affordable means for whichever industry still hanging on, to modernise - textile being one that comes to mind. I actually had a strong belief (I knew no better from the propaganda being dribbled out,) 80s / early 90s that the reason the textile and clothing industry was falling off was overseas workers were paid a pittance, which made it hard for textile companies here to stay competitive - that was until someone who'd had travelled and had business interests though Asia and the US dispelled the usual propaganda I'd been suckling on, she corrected me on that it's not all sweat shops, and much of the textile base over in Asia had modernised quickly and been computerised for years.
[1] https://www.unido.org/sites/default/files/2012-10/Lima%20Dec... [pdf]
And how much of what China makes is dependent on imports? Breaking news: the global economy in 2026 is highly interconnected.
You're arguing that American manufacturing is healthy because of Boeing?
One other metric the parent didn't mention: The US is #1 in the world in productivity per worker in manufacturing.
We're not the largest in absolute output, but we are literally the best manufacturer in the world, and we are the 2nd largest.
We manufacture lots of stuff, often the most state of the art and difficult things to manufacture. We're very good at it.
And we've sat around close to full employment for so long, the only way to convert more of the economy to manufacturing is to either import workers, cannibalize other sectors of the economy, or automate even more.
Yes, a larger share of the economy is services, but is there some objective optimal ratio of services to manufacturing we should be shooting for? If so, what is it? No one ever says.
Yeah but something something testosterone manliness degeneracy decadence.
Sending emails from an ergonomic chair for eight* hours a day and having to be civil to female coworkers and polite to your boss inherently degrades the male spirit in a way that permanently damaging and poisoning your body with 12-hour factory shifts with a foreman yelling at you doesn't. This is so self-evident and obvious that nobody even bothers to state it, it's just an assumed undercurrent in discussions of "bullshit jobs" etc.
Among others, yes. Nearly $100 billion in revenue last year. From your snark I guess we’re not supposed to count a manufacturer with revenue equaling the GDP of a small country because they’ve had some quality issues?
Boeing is not a healthy company it's a deeply sick company with a horrible internal culture. I know because I've spoken with people who work there.
The fact that leadership is focused on extracting profits out of the enterprise is also not a show of strength. It's a demonstration that they're trying to drain whatever value is left in it.
This is pretty much true of any of the American "greats:" Boeing, Intel, GE, GM, Corning. They're producing (or have recently been producing) great profits because they're eating their own seed corn. Nobody expects them to still be the businesses they currently are in another few decades.
The ecosystem to build cheap physical products is incredibly important for creating new wealth. If you're building something new, in manufacturing cities in China you can walk across the street and get everything you need. In the U.S. you have to fly to China and build relationships with Chinese suppliers. Which means creation of new products, which is where most future wealth will come from, is extremely difficult. This is like Germany lacking a meaningful tech ecosystem because creating tech startups is so difficult.
We can make planes and engines because we kept the expertise, and we can make rockets because of herculean efforts of a few people. This simply isn't good enough, we need to make creating new physical things as easy as possible.
This also applies to the UK: major manufacturer of turbines, i.e. Rolls Royce in Derbyshire. More electronics than you'd expect, but all short-run highly specialized things like satellites and scientific instruments and Martin-Baker ejection seats.
Massive numbers of people on production lines is not coming back. The rest of the economy is too well paid for that and automation too advanced. VW will retain car manufacturing in Europe by automating away its workforce, at the cost of high redundancies.
That's manufacturing based in dollars which is quite misleading. Rolling with your example of planes, this [1] is how a 737 looks in terms of manufacturing. Boeing does a lot of assembling, but the majority of the manufacturing is outsourced.
When people think of manufacturing they generally think of going from basic materials to something useful, rather than 'just' assembling quite advanced parts. Like if I go buy some parts and 'build' a PC that'd technically be manufacturing, and quite high value manufacturing if I was able to sell it at a good markup.
[1] - https://www.visualcapitalist.com/cp/boeing-737-global-supply...
You can find the same kind of diagram for an iPhone. Any product of any complexity is going to have components from all over the place.
All over the place and one place in particular. This is why people generally say the US manufacturing has disappeared relative to China.
If you can’t see the direction and velocity of China you’re beyond hope
Americans cars are falling behind, they rely heavily on American cultural exports which relies on the world not thinking Americas are twats because the voted for Trump. Germany alone is over twice the size of America in terms of car exports. Including domestic destinations then china is three times the size of America.
America planes fall out of the sky far too often as Boeing pivoted from engineering to politics
Musk does good rockets. Not America. China is catching up and lost to overtake unless starship proves itself; and if it does China will copy that too.
Chinese planes are increasing very year, comac now about 15% of traffic, and heading towards about 20% in a decades time. and Boeing is about the same size as airbus at 40% each which will shrink as china catches up, won’t surprise me in 2050 is the largest provider of passenger planes is Chinese.
Why are you championing a system that benefits a smaller minority of people every year? Americans don't prosper when Apple sells iphones. Americans don't prosper when they sell more F150s. The sure as heck don't prosper when Boeing sells 747s either.
You literally are praising a system that condemned tens of millions of Americans to abject poverty because the rich wanted slightly better returns.
Those three companies employ hundreds of thousands of Americans. Millions more are employed by suppliers, contractors, dealers, etc. Selling iPhones, F-150s, and 7x7s is how those people make their living. In what sense are they not prospering from that?
Americans are better off than they've ever been. The improvement has disproportionately gone to the wealthy, but even the poorest have seen gains, not losses.
I don't understand this kind of comment. It's like some sort of disaster fantasy. Like you need it to be a crapsack world full of slums, so you come up with absurd takes like American companies employing huge number of Americans not contributing to American prosperity, and just make up troubles.
How is that the case? Apple, Ford, and Boeing are American companies that hire mostly Americans, with some number of H1-Bs. Those Americans pay taxes in California, Michigan, Washington, and elsewhere, and also to the federal government. Those taxes get redistributed to all of America, as determined by the budget as set by Congress and the President. We can complain about billionaires at the top not paying their fair share, and that the budget isn't set how you would, but largely, that is the deal. The workers on iPhone, the F150, the 7*7 pay their taxes in America. Those three are American success stories.
Boeing builds their planes in America, F150s are largely built in Michigan, iPhones are manufactured in China, but California is much richer because of the taxes that Apple employees pay. Millions of Americans are in poverty according to the latest census, but I don't know how you establish cause for that poverty being "that rich people wanted higher returns".
I think one other point is that demand for American goods has never been higher. I've had Europeans come to me with tears in their eyes saying 'sir, sir, we want more Fords'. There has never been a better car brand than an American one, that's for sure.
>“we don’t make anything anymore” narrative I see so much."
This conflating US financializing manufacturing vs actual industrial capacity, i.e. the entire manufacturing by value / MVA "cope". US objectively doesn't make much relative to past and a lot of shit US makes, US doesn't actually make, others does the actual making while US financializes and capture via spreadsheet maxxing, hedonic adjustments etc, and do insert "I made this meme" on things US fundamentally did not "make"
Like US does make some legitimate frontier stuff in house - the reality is is in aggregate industrial base terms, US MAKES / FABRICATES very little vs pre industrial chain hollow out, US does import a lot of subcomponents that others make, integrates, or outsource actual MAKING abroad while capturing intangibles like IP/patent fees that get bundled up into value add stats, but when people talk about making they're talking about extraction to factory gate pipeline. Not US can sell a bunch of foreign made goods with some CONUS final assembly or IP accounting because muh smile curve that attributes disproportionate "value" to US "makers". Consider a US widget co imports $10 of components assembles and sells for $40, the statistically manufacturing value add is $30 even though US did very little making. Now add tariffs, regulatory capture etc and widget sells for $50 and that's $40 of MVA for basically doing minimal M. Said US widget factory makes 10 widgets and adds $400 to MVA. Meanwhile a PRC widget company makes 100 identical widgets at $2 each... but their MVA is only $200, but they did literally all the making. These two industrial bases are not the same. Then a few years later, US BLS/BEA applies a statistical adjustment because widget X is slightly more performant... (prevalent in tech), so that widget is now listed as $100 equivalent utility, so hey manufacturing expanded (it didn't).
SpaceX... doesn't make that much... they make a few thing that are reusable and due to techstack can lift a lot, i.e. operational improvement (not discounting how game changing resuable is). But compare to PRC, who made like 2x-3x more first stages, i.e. their output is significantly higher, which is to say SpaceX is "making" at about American scale. For reference Boeing like ~30% domestic content, US auto ~50%. Reality is the ONLY thing US is REALLY good at making is refined fossil, agri, wood products etc. Almost everything else US very good at making money, but not the stuff.
TLDR US got much better at MAKING money from other people MAKING things. The other caveat is regulatory capture = US grossly overpay for mediocre shit, a lot of stuff that makes in US are just... not good, i.e. vehicles, but people trapped paying domestic premium which inflates value add but not actual relevant when people discuss US making things. US broadly makes a lot of mediocre overpriced things while population stuck shopping in company store for large items, that looks good on value add / productivity stats... but it's not reflection of industrial capacity which is what people think about in terms of real manufacturing.
What many people don't realize is why is America suddenly caring about manufacturing everything inhouse when Elites decided earlier Globalization was good, because China wants to command respect more than America. That is also the reason why Gold is pushing higher. If China was nobody, no nation would care for gold. So all these unnecessary downstream reasons distort what is actually going on.
If there was no China, Globalization would spread very strongly with Bangladesh manufacturing clothes and Milan doing the fashion show. All those calculations are coming undone. So please keep this main reason front and center when we discuss this matters.
Toyota would have gone bankrupt in post-War Japan if it wasn't from massive US demand in the Korean War.
The Vespa popularized by Hollywood's Roman Holiday propped up a post-War Italy.
Ping-Pong Diplomacy of the 70s gifted China its electronics manufacturing (think: PONG) turning it from a 3rd world backwater to what it is today. The exchange was in removing the 'Gang of Four' and the drugs associated with it.
---
The US was put into a privileged position as reserve currency of the WORLD in Bretton Woods. This is with the understanding/responsibility that the US would act as World Police and prop up foreign economies.
That is the system that is ending.
Keynes didn't want USD to be reserve currency but he was overruled.
That’s a good point. I’m also going to bring race into this and say it’s also because the Chinese are not white. The same type of rhetoric was said about Japan in the 80s, but barely about Germany.
Even with how long Russia has been an antagonist, they are still seen as a “wayward brother.”
This analogy really only works assuming that maintaining [insert company]'s institutional expertise requires N engineers to maintain individual lines of code manually.
This is already showing not to be true with AI. Institutional knowledge is not the same as knowing how to implement low-level software details. Even today, every company does not need engineers to remember git cli syntax by memory, how to write parsers for JSON, or write the large amount of boilerplate from scratch that is at every software company. Most company's already hire engineers who have zero experience in the existing code base, yet they are productive despite this lack of institutional knowledge. For a company to maintain institutional knowledge they may only need N/K engineers.
We were already there at places with a lot of contractors, capped at 1 or 2 year stays. You saw teams of 10, 20, with 2 people with serious institutional knowledge. Now the contractors are just Claude
What really doesn't make sense to me is setting uniform token targets for all engineers. I'd be more interested in setting token ranges with hard limits for certain roles that see diminishing returns from the overuse of coding agents and where maintaining institutional knowledge, architectural awareness... is more valuable than moving as fast as possible. Like everything else, these limits should be adjusted over time as tooling for those roles improves but it really feels like there are human limits that organizations should avoid exceeding.
This breaks down at a sectorial level. If one company offloads that knowledge to the wider economy/world, fine. But if <<all> the companies in a domain/sector do it at the same time, at some point the destruction is extremely hard to undo.
De-tracked video link: https://youtu.be/3ZTGwcHQfLY
Do not share videos with si parameters. It links together the accounts of the sender and receiver.
> Do not share videos with si parameters. It links together the accounts of the sender and receiver.
@mitxela: Thank to for taking a moment of your time to educate those who didn't know.
Thanks. Edited
I recommend https://sharecleaner.com/ for cleaning links of trackers when sharing from mobile. No affiliation, just a user on iOS.
> decided one day that manufacturing would be cheaper to outsource and better (short term) profit was to be made by outsourcing it all to China.
To build a $100M software company, you need 6 engineers and 6 laptops.
To build a $100M hardware company, you need 60 engineers and $100M.
Everyone decided on the most logical choice. It gets even worse if you jump into profit margins, as software is the unambiguous winner there too.
Until software becomes commodity and generated on the fly by large language models.
That until was like 50 years though -- an entire career span for those who started at the start.
Most of us can't hunt either. Somethings go away in time because they're no longer needed (by the masses). That is essentially what society does -- it allows us to multiply a few for the benefit of many so the many can focus on other things.
The resilience is more in ensuring archival process to ensure it's never lost forever, and a continuity plan to ensure enough (but few) people still know.
> The problem imo is the slow deterioration of institutional knowledge that offloading the mental task of wisdom gathering to AI is causing.
I believe this is what Socrates said (verbatim) about the invention of writing.
No, it wasn't. This often made claim is based on a passage of Phaedrus where Socrates is quoting an Egyptian legend, and the negative judgement of the invention of writing is done by a pharaoh inside that legend being told inside the dialogue.
Besides, the dialogue is not about writing itself, but about writing down political speeches and the consequences and impact of political speeches being read rather than heard.
Also, the dialogue dates from about three thousand years after writing was invented.
Some direct quotes from the dialogue:
SOCRATES: So, it is obvious to everyone that speech writing is not shameful, not in itself anyway (258d)
SOCRATES: We are left with the question of the appropriateness and inappropriateness of writing, and how it may be executed in a worthy or an inappropriate manner. Do you agree? (274b)
And this, a very relevant insight for an age when some are convinced that text analysis should suffice for intelligent work:
SOCRATES: Then a person who thinks he has left a skill in writing behind him, and anyone who, for his part, inherits this on the assumption that something clear and certain will emerge from writing, would be full of enormous silliness, and indeed ignorant of the prophetic words of Ammon in believing that written words are anything more than a reminder to a person who already knows whatever it is that the written words may refer to.
Ironically, the sharpest criticism Socrates made of writing in the often misread Phaedrus was of misreading texts.
Be fair to Socrates though.
We have significantly degraded in our ability to memorize e.g. epic poems or preserve oral traditions since the advent of writing.
I know that sounds trite in retrospect, given the benefits, and that's half the point. But there are real tradeoffs too! For example, culture has a LOT more generation-to-generation turnover as a result of literacy being common, making it unstable.
I think (?) my point was that Socrates equated Memory with Wisdom, and the invention of writing would impact Memory and thus Wisdom. I believe he was just plain wrong. Equating (manual) coding/code-review with Wisdom makes the same category error.
Writing had been invented three thousand years before Socrates
The passage criticizing the "invention of writing" is a quote from a legend where a Pharaoh passes negative judgement to a god, by the way, who had invented writing in the story.
Ironically, the dialogue in question, Phaedrus, is about the dangers of misreading text. It discusses writing political speeches not writing per se.
Was Socrates even wrong, though? There have certainly been millions of words written that were lacking in wisdom and have convinced people of falsehoods to their detriment! When’s the last time you saw a debate be reasonable? devoid of cheap jokes or hot takes? actually change someone’s mind? or the whole audience’s mind?
In the world where we didn’t outsource Western manufacturing to China, our homes would not be overflowing with disposable junk; in the world where the Luddites won, our wardrobes would not be stuffed full of disposable clothes; perhaps in the world where Socrates won our minds would not be jammed full of nonsense.
It's not really a case of 'winning' though is it? There is no agreed criteria by which to judge which is going to pass muster for a majority of people (both in Socrates time and ours).
I mean, you can s/“won”/“had their ideas reach a supermajority in the population such that their future (and our present) resembled the future they wanted instead of the future they worried the target of their ire would (and did) bring about”, or equivalent, at your leisure - I think my point stands either way.
One affects memorization and is a trade-off for writing, a process that arguably allows someone to work through their own knowledge of a subject and find or realize gaps in understanding.
Having something else do all of that for you is completely different and essentially tossing any gain outside of the creation of some gray slurry of an output in the trash.
>The institutional expertise started to deteriorate, to the point that America simply didn't even have the capacity, or expertise anymore to produce stuff
Right. And the spin I would put on your point: while the U.S. could never compete with outsourced labor, institutional manufacturing expertise could (you would think) still be valuable to startups finding some kind of niche in the manufacturing space.
With all this new 3D printing infrastructure, and constantly improving robotics, maybe some manufacturing efficiencies in some spaces could emerge that compete on cost and outcompete the cost of shipping stuff across an ocean. The availability of institutional expertise could be one of the necessary ingredients for mixing and matching the way to a new efficiency.
Yeah it's bleak in terms of automating away labor, but I'd like to think robotics is the next automated frontier after LLMs and we want to get there first.
Well I have seen many mediocre folks who confidently operate in India as they have licenses and things just work their way (CAs, lawyers, even a lot of diagnostic Doctors serving the very bottom and whose modus operandi is simply giving an antibiotic for everything). I am hoping that good AI will lift a lot of the mediocre ones at least 1 SD above.
Peace through global interdependence wasn't a bad side effect at all. The analogy only holds so much, but I'd wholly agree that any profound deterioration of skills across the board would create dependencies on AI infra that are on a whole new level.
At the very latest, when "AGI robots" will be commonplace and taking on the most crucial labour on our behalf.
I think this is a good point but we should see AI at the person level. For your example, not all companies/people manufacture, but everyone has access to AI. Soon a lot of people will lose skills to AI and at some point we would need them back and there won't be many skilled workers with it
I've been taking a "help me help myself" approach to interactions with LLMs. I might run my plan on how I'm going to build something past an AI asking it to critique it. I then incorporate that info into my original plan, or not. However, I am responsible for the design, I write the code. I started doing this because for decades I've been building my own programs since I learned to code just for the sheer fun of it (like many here) and I don't want to give that up to LLMs. I might as well let them play my video games for me.
I wish more people would at least consider this idea.
> The problem imo is the slow deterioration of institutional knowledge that offloading the mental task of wisdom gathering to AI is causing.
That's the whole point of Global managerial class even without AI. The idea is just by creating metrics one can measure how teams, groups, organization and whole industries are performing.
Before the current AI complex the previous one Agile Industry Complex One can see we starting producing 10x more code, 50x more JIRAs resolved, 100x more network bandwidth used. All these metrics tremendous gain in productivity.
Also it may not have been seen in US but in many places a change in political regime does want to burn down previously collected institutional knowledge because new dispensation have their own idea about what is knowledge, who will preserve it and how it will be preserved.
It is definitely seen in US.
How come we cannot keep/define "specs" of how to manufacture such "mundane" objects such as a grill brush, everything from what raw materials are required, how should the assembly line(s) look like, which industrial robots or their human professional alternatives are required, etc. etc.
It just seems to me that fundamentally this is a knowledge organization problem.
To abuse an old phrase about engineers and bridges:
“Any idiot can run a business, but it takes an MBA to run a business that barely functions.”
I don't see how that is relevant here. And no, not "any idiot" can run a business.
I'm agreeing with you, in that yes it would be best and simple to solve "How come we cannot..." with some basic steps - but companies and industries often cut corners to the point of barely being viable long term.
Grill brush found out that the problem is chinese products are so much cheaper (without ascribing cause of that) that north american producers can only compete on native advertising (B2C) or purchasers that require a north american supply chain (B2B).
I think you missed their conclusions. The problem wasn't that China was a lot cheaper. The problem was that substantial subcomponent or process vendors only exist in china. Like, they could find American sheet metal stamping companies but they were all using custom tooling made in China because American tooling doesn't exist anymore.
Tooling is a high-skill trade. America used to be amazing at tooling. What's more, tooling isn't super cost sensitive because one tool can make thousands of parts.
When outsourcing to China began the tools would be made in the USA and shipped to China for the low-skill work. But over time those Chinese manufacturers figured out the tooling. What's more they realized that controlling the tooling would let them control the whole process.
They started doing things like, for instance, including the tooling in the price of the product so you don't even see it, if you use their tools. Just send them the cad file and they'll do the rest. So American tool making went away. But this was a conscious decision on the part of the Chinese manufacturer and an unconscious decision on the part of American importers who didn't really value their in-house expertise.
> I think you missed their conclusions.
I didn't miss it.
> The problem was that substantial subcomponent or process vendors only exist in china.
He found vendors in USA. They didn't call him back.
USA has manufacturing. But Americans want to drive cars and own their own home. In order to achieve that American manufacturers need high volume or high margin - better BBQ scrubber isn't either of those.
> What's more, tooling isn't super cost sensitive because one tool can make thousands of parts.
Tool making is highly sensitive to labor cost. Every article is a one-off. It can't be automated, often not even duplicated. There are tool and die makers in the USA but if you want to make consumer products you can't afford American tool and die because American tool and die makers want to drive cars and own their own homes. Chinese tool and die makers don't have the same expectations.
> So American tool making went away.
It didn't go away. You just don't know about it.
It is not unsurprising to find dev lacking knowledge in domain stuff that would be actually required if they were doing the development themselves, rather than outsource it to an LLM.
So the client who writes the ticket understand the domain, the LLM that implement it understand it too.
The dev is the only one that is clueless.
There is more to development than domain knowledge. There are decades of wisdom about development best practices on how to keep a large codebase maintainable, performant, testable, etc. that LLMs frequently don't follow. And now humans aren't practicing those skills either or passing down lessons learned to the next generation of programmers.
Maybe it will be no big deal, and nobody will read code anymore, but it is understandable why somebody might be concerned about it.
>There is more to development than domain knowledge.
Without domain knowledge, the dev will miss critical simplifications. That is one way the code base accrue complexity.
The LLM that implements the ticket understands the domain? I'm rather skeptical of that claim...
I think It infers it from existing code..
In Europe we lead the regulation :)
This hit close to home and I giggled over it for about 5 minutes. Both Europe and the US have so much potential but they're both mismanaged albeit in slightly different ways. There should be some way out of this mess.
The outsourcing of manufacturing was largely influenced by the externality of environmental pollution. People wanted to live in clean habitats. We had rivers on fire for weeks, extinction of species, and horrible pollution causing cancer and birth defects. Giving "the commies" the dirty, dangerous jobs, and moving everyone up into middle management and white collar knowledge work was seen as an evolution of the economy.
The political move to put all of that death and destruction onto China, where environmental regulation is willfully ignored in the interest of economics, was a smart move on their end.
We lost so much intellectual knowledge and other "tribal" technology in these processes to this outsourcing, which is unfortunate. We're almost having to rebuild our manufacturing from first principles, which may not be a bad thing.
Clean Air Act was passed in 1963. the Clean Water Act was passed in 1972. The China Shock began in 2000 after PNTR.
Avoiding environmental regulation was one reason to move factories to China, avoiding unions and high wages was another.
But the local communities weren't demanding that their factories be moved overseas so they could have a clean if impoverished towns. Your entire causality is completely backwards.
It isn't 100% causality, but it was definitely one of the ways it was sold to people through PR/propaganda.
Free trade / globalism was the larger "true" move, and yes getting away from unions and high wages to maximize profits was a big part.
Corporations made a change from valuing stakeholder value (employees, communities, customers, suppliers, the nation) to pure shareholder value (profits over everything else, despite the long term result that profits by any and all means hurts all stakeholders and eventually can cannibalize the company unless you have monopolistic moats).
I promise you the people in the towns where the factories were closing were 100% against it. And the corporations never tried to claim that "at least your town will be cleaner" probably because they were mostly leaving behind superfund sites they were trying to avoid cleaning up.
Was the New Yorker crowd clinking glasses together talking about how good it was to get the dirty steel mills out of the country? Sure maybe but this argument never resonated with anyone on the ground.
Were companies actively moving factories offshore so they could be dirtier because they didn't have to comply with American environmental laws? Absolutely.
You don't have to completely abolish manufacturing to clean up pollution better.
No, you don't, and I am not saying I feel that was reasonable, just that it was an emotional appeal used to sell it to the layfolk.
it wasn't completely abolished. but the economics forced out the low-value-added work, only high-value manufacturing (and politically important manufacturing) remained.
> West/America decided one day that manufacturing would be cheaper to outsource and better (short term) profit was to be made by outsourcing it all to China. The institutional expertise started to deteriorate, to the point that America simply didn't even have the capacity, or expertise anymore to produce stuff
Americans produce the highest technology equipment in the world. Our machining base is structurally sound, but its all making weapons, so you don't hear about it.
It's true that China benefitted immensely from outsourcing, but they took the jobs Americans didn't want. It's the same with immigration today - folks cross the Rio Grande to do chores that Americans won't, or others fly in and work for nothing in academia while they wait for their PhD.
> The problem imo is the slow deterioration of institutional knowledge that offloading the mental task of wisdom gathering to AI is causing.
Have you considered the institutional knowledge could actually be actively preserved and distributed with AI? The kind of tacit knowledge that is situated and not readily preserved in a book might be absorbed by thinking machines and proliferated to the next person who needs it. The caveats would be trade secrets, skill differentiators, that people might not be willing to discuss, and manufacturing secrets of national importance. Maybe you can think of others.
>Have you considered the institutional knowledge could actually be actively preserved and distributed with AI?
Well that's what this whole debate comes down to. And, to my mind at least, it's a rare case of an actually interesting question about AI, because like the article says, it can plausibly deteriorate exactly that kind of knowledge. But as you note, it can also maintain it.
I think there's a sense in which it might do both at the same time. AI's version of on call tacit knowledge might be something like lazy-loading just-in-time tacit knowledge, but at the cost of who knows what cognitive paths we might have by keeping that knowledge resting in-house. We would gain real efficiency but we wouldn't know we wouldn't know.
>The kind of tacit knowledge that is situated and not readily preserved in a book might be absorbed by thinking machines and proliferated to the next person who needs it. The caveats would be trade secrets, skill differentiators, that people might not be willing to discuss, and manufacturing secrets of national importance. Maybe you can think of others.
It's funny that you credit AI with this (and I don't disagree), because tacit knowledge was exactly the thing Hubert Dreyfus spent a career insisting computers would never have, and his wisdom was taught to generations of undergraduates across the country and world who treated it as received wisdom and still is regarded as such in certain academic corners.
> tacit knowledge was exactly the thing Hubert Dreyfus spent a career insisting would never happen
Could you elaborate on this? It sounds like something any anthropologist would laugh at; there's always an oral culture.
I edited that sentence to try and clarify a bit, but Dreyfus was a continental philosopher out of Berkley active basically from the 1950s to the 2010s. He engaged in decades of friendly debates with other philosophers about the limits of computers.
When he described those limits, he always frustrated computer scientists and analytic philosophers because he spoke in a kind of informal philosophical vocabulary and didn't really formalize his ideas. So he would say computers didn't have things like "tacit knowledge" or "insight" and he railed against "symbol manipulation". Famously he declared chess would never surpass human expert play. He wrote a book called "What Computers Can't Do" and another called "What Computer's Still Can't Do".
I personally think his argument was laughably wrong if well intentioned. But some people think it was respectable. I think in the present day, he's often rehabilitated with a kind of apologetic reinterpretation, such that things like transformers, weights, vectors, etc were what he really meant all along.
I think he was not wrong that some higher layer of sophistication would prove to be necessary, but he was wrong, I think definitively, to think that "symbol manipulation" of computers was a kind of category error. Even today's best models are still running on logic gates over 1's and 0's, and it was his failure of imagination to doubt that those could be the conceptual bedrock for AI, tacit knowledge and all.
He passed away in 2017, which is too bad because I would have loved to have seen his interpretation of things like GPT-6 Astra.
Ah I see! The change helps.
> think that "symbol manipulation" of computers was a kind of category error
This is where we do drift off into the semantic bog. If there is tacit knowledge in an LLM, then where is it? It must be in the weights, and it must have somehow come from the training data. Therefore the weights represent "compressed" knowledge. Is that then not "tacit" since it's explicitly encoded?
You'll get no disagreement from me here. But be ready because some people live to debate this, and Dreyfus is the poster child for a whole philosophical tradition.
I think what it comes down to, is trying to turn the specialness of human intelligence into undefinable magic, essentially playing god of the gaps with the concept of human insight. So by design, it has to be something that can't be amenable to any formal representation like weights.
> Famously he declared chess would never surpass human expert play. He wrote a book called "What Computers Can't Do" and another called "What Computer's Still Can't Do".
He never made such a claim. In the introduction to the 1972 print of this book he discusses the forecasts from Turing to his time of computers' abilities to play chess and the then state of the art. He criticizes the early optimism in 1950s mentioning that in 1957 H. Simon though in 10 years computers would excel in chess.
Dreyfus goes on to discuss the history of forecasts and progress in computer chess in a nuanced and highly informative analysis.
Whatever your opinion of his work I don't think it's fair to say his arguments are "laughably wrong" at any turn. I haven't read his books in detail but from what I know he made great contributions to the dialogue about technology and I don't know any instance of his making crass predictions or anything that he wrote that could be labelled "laughable".
Dreyfus certainly claims he was mischaracterized, but what he "really" said always turns out to be a conveniently moving target.
He thought that the complexity of chess rendered it solvable in principle but "uncomputable" in practice. You're right that he was speaking to the times he was familiar with, and what he meant by "impossible in practice" was something like letting a 1Mhz computer explore all the possible chess moves from now until the heat death of the universe. Relying on that to insist that computers defeating humans in his lifetime was consistent with what he envisioned stretches past charitability and into sophistry.
And I don't think you can extend him that charity without doing the same in the other direction, which would also collapse his basic thesis. Dreyfus was disproportionately preoccupied with retelling the failures of the 1950s over and over again using them to represent the whole of computing while the world moved on, and extending the same charitable repairs in favor of AI research make it something less easily caricatured, and still based on the same logic gates and 0s and 1s he was criticizing.
If that's not enough, Dreyfus explicitly said that what was lacking in chess programs was (1) any practical ability to do the brute forcing needed, (2) any kind of nim-style logical shortcuts around brute forcing or (3) any kind of expert level heuristics because he categorically believed those simply weren't programmable. And he believed that those exhausted the options. [1]
There's no version of this that can be correct because even if you think he's right that chess engines got better by progressing to some different conceptual paradigm, that paradigm is still embodied in same logic gates and 1's and 0's that he thought only pertained to prior paradigms he was criticizing. He was wrong to assume such things as "heuristics" were outside of that scope.
1. https://repository.essex.ac.uk/42372/1/Martin%20and%20Willia...
I might have expressed myself poorly. I do not mean to claim Dreyfus is worth reading because correct, but that he is worth reading despite wrong.
I do object to calling his writing "laughable".
Thank you for the article, it seems quite interesting on skimming and I will save it for later.
> I think there's a sense in which it might do both at the same time.
This is probably true.
Many artisan fabric techniques were lost when industrial looms displaced those jobs. But heavy industry enabled cloth to be manufactured at a rate that people were free to spend their time and money on other priorities - and now (centuries later) the society is in a sufficiently advanced stage of development that the old techniques are being rediscovered.
Perhaps the example underscores the importance of thoughtful preservation of insitutional knowledge.
> Americans produce the highest technology equipment in the world. Our machining base is structurally sound, but its all making weapons, so you don't hear about it.
It's also very automated so the jobs went away, but the US continues to manufactures a lot of things.
>Have you considered the institutional knowledge could actually be actively preserved and distributed with AI? The kind of tacit knowledge that is situated and not readily preserved in a book might be absorbed by thinking machines and proliferated to the next person who needs it. The caveats would be trade secrets, skill differentiators, that people might not be willing to discuss, and manufacturing secrets of national importance. Maybe you can think of others.
You don't develop "institutional knowledge" from a few prompts. It takes years to develop them.
> It takes years to develop them.
Is AI going somewhere?
> It's true that China benefitted immensely from outsourcing, but they took the jobs Americans didn't want
They took jobs that Americans would have wanted higher pay to do, higher benefits, higher safety standards...
So you want the job or not?
> West/America decided one day that manufacturing would be cheaper to outsource and better (short term) profit was to be made by outsourcing it all to China.
Bogus nonsense.
1. Manufacturing output in West/America is higher than it ever was in history.
2. What has reduced over time is the number of people employed in manufacturing, not manufacturing output. And that's an effect of automation, same as it happened over centuries in agriculture.
3. West/America did not decide anything, the realities of capitalism did.
You're either a capitalist and embrace efficiency of producing where it makes sense (for many different reasons) or you're fine with inefficient third-tier industries.
The tax payer may help a handful of sectors that would otherwise die survive if they are truly critical for national security, but just a handful, not all of them.
There's a continuum between "vibe coded by someone with no technical knowledge or inclination" and "hand written domain driven design development". You can absolutely use coding agents AND have maintainable code. But yes, the coding agents will not magically make everything maintainable if you don't tell them to.
"Code maintainability and good architecture don’t have good measurements that we can apply"
Who has no wisdom? There are dozens of ways to measure code maintainability. Cyclomatic complexity is just one.
Nothing stops you from wiring up something like SonarQube metrics to your agentic coding workflow.
Plenty of measurements exist, but the trick, as the article said, is finding good measurements.
Cyclomatic complexity has been pretty solidly discredited within the maintainability research community for decades.
Sonar's cognitive complexity metric is a bit better, but here's a study that found that it still only has about a 0.5 correlation with how much difficulty programmers actually had reading code as measured by multiple methods.
They found that the most accurate way to measure code complexity that didn't involve something like an eye tracker or EEG is still basically just vibes - asking programmers if they thought it was hard to understand.
https://www.frontiersin.org/journals/neuroscience/articles/1...
Halstead Effort came in second, and scored pretty well, but here's another one where it doesn't do so well, either. And it scores the SonarQube metrics even worse, with only a 0.35 correlation: https://www.sciencedirect.com/science/article/abs/pii/S01641...
Yeah, we have this rule in our SQ and I absolutely hate it because of the number of times I'm forced to break something up. Complexity that matters is usually at a higher, more architectural level.
Yeah. Looking at the code samples in that first page was pretty interesting. They're cherry-picked, of course, but still it's a little galling to see which ones SQ gave a lower score.
I definitely wouldn't want AI to be autonomously using that as a guide without doing some fairly serious internal A/B testing first. Kind of like for cyclomatic complexity, it's just too easy to find ways to maliciously comply. And if that's what you ask AI to do then that's likely what you're going to get.
I agree with the larger point, but here I'll disagree:
> There are dozens of ways to measure code maintainability.
There are no good ways. I'm averse to making absolute statements, but here I'll take that chance. I worked in dev producitivy for years with people who spent decades in that domain across multiple companies with very high volumes of code production. Everybody agreed: All metrics are flawed and even a combination of metrics is insufficient.
Just to give one fundamental reason (in addition to a lot of the sibling comments): for any given metric there are an infinite set of counter-examples that don't trigger any thresholds but are clearly bad code. So these metrics typically only help in trivial cases, don't catch a majority of the cases, and so often become more of an annoyance due to low SNR. A lot of dev productivity work ends up being wiring these metrics in and then providing escape hatches when they inevitably get too noisy!
And most relevant to this discussion: these tools do not say anything about higher-level concerns like architecture, over-engineering and design, which IME is where agents tend to mess up most. I've almost never had a complaint about the code itself; the logic, naming, functions, data structures, even a lot of the testing, are all on point. It's always been the higher-level structure and design: over-engineering, duplicate classes, suboptimal abstractions, redundant operations across layers that could be solved by adding a single variable in a class, etc. etc.
I think the problem, like with code written by humans, is lack of sufficient context while doing a task leading to tunnel-vision. This is why we need to oversee and ensure things are good holistically. I suspect models are now good enough to play the role of an architect as well, though, and I've read some indications of that online... I just haven't tried giving them that much control yet.
> There's a continuum between "vibe coded by someone with no technical knowledge or inclination" and "hand written domain driven design development". You can absolutely use coding agents AND have maintainable code. But yes, the coding agents will not magically make everything maintainable if you don't tell them to.
Yes. But I think the idea is without "hand written domain driven design development" the result trends to "vibe coded by someone with no technical knowledge or inclination," as developers de-skill.
Some de-skill, but not all.
Somewhat relevant parallel..
Calculators exist, but not all is lost:
- lot of (most?) people can do basic multiplication (I’m too lazy to fetch any stats but I hope you’ll have some observations in your bubble dear reader)
- some people actually compete in mental calculations https://worldmentalcalculation.com/mental-calculations-world...
Same will be with software devs, enthusiasts will continue to exist.
> Some de-skill, but not all.
So are you agreeing with me or not? Because it's not black and white. Having a few non-deskilled developers around who do the equivalent of "compete in mental calculations" is the same as having none at all.
It's sort of like the retort "AI won't take all the jobs from humans, some will be left [at the very top and very bottom]." Even if true, fat lot of good it does most people who would be unemployed in that scenario.
Also, if you get widespread deskilling, but massive increases in code production due to AI, you're probably still going to get "organizations falling into the trap" like the OP describes and the remaining skilled people getting burned out trying to hold it all together. Modern American business culture (in aggregate) is incapable of learning to not burn people out until everyone is already burned out, only then will it pay attention to the problem (and then probably forget what they learned and start repeat it in 10 years).
> So are you agreeing with me or not? I’m disagreeing with black or white view.
You make it A bit black or white.
Llm will not take jobs, at worst it will shift jobs.
If we will allow current llm to develop code without inspecting it, we will still want to provide direction and expect certain quality level. So in “worst” case you will need at least design/QA people.
If code will be free, and it will increase 1000x, you probably will need 100x design/QA people. (Unit tests written by same llm, if not reviewed are worthless as assurance). I’m absolutely certain that humans will have plenty of software related jobs.
As to programmer deskilling, another parallel: lot of programmers have very little knowledge of how to deal with databases correctly/efficiently, because they are somewhat lazy and good tooling/orms allow to get away with it, but there are also plenty of devs who do know how db works and how to design a db schema for their app access as it improves overall system performance and correctness. Same with LLM case, having knowledge of what happens in code, gives an edge, and competitive/curious/overly-responsible people will continue reading things in depth (llms also make learning somewhat easier). And its definitely not 1%.
Furthermore, llm prices are subsidised a lot now, so it’s yet to be seen if llms are economically viable as vibe coding agents on a large scale.
All will be ok, don’t worry too much.
Our class sizes at the university that I teach at have plummeted with the crash. What I'm hoping is that this means I'm just going to be teaching people who are actually interested in producing quality code.
//There's a continuum between "vibe coded by someone with no technical knowledge or inclination" and "hand written domain driven design development".
Somewhere in the middle of that continuum sits - "domain driven specifications, described using high level english concepts(that are well defined) from the domain , combined with a selection of a few standard architectures"
I agree that "maintainability" is the wrong place to stake one's flag. It's a technical problem and will probably be overcome. The "lack of wisdom" in AI coded projects which does not strike me as a soluble technical problem concerns questions like: which software is worth writing and which isn't? How are tradeoffs evaluated? I don't think AIs are structurally capable of answering these questions in the same way humans are. But they make those decisions anyway!
Those metrics don't amount to wisdom. Wisdom is something like realizing that you don't have to special-case some code over <here>, you just need to create a new reusable primitive over <there> that fixes two bugs with one stone, and you'd probably wind up needing it anyway. Both bits of code could sail through all the measurements of code maintainability you could come up with, and an agent suggest to me the brittle solution, but I came up with the more maintainable one.
I find it funny how you can pick examples on one side of the spectrum and then generalize to the entire spectrum.
Induction fallacy at its best
> yes, the coding agents will not magically make everything maintainable if you don't tell them to.
There's the rub. It requires knowing about and caring about maintainability. And a lot of the people who "haven't written a line of code since 2025" don't care
“Claude, make this code maintainable.”
I’m beginning to believe that if this was a “solvable” problem then the billions of dollars poured into coding agents would have solved it by now.
Humans aren't magical, so if people can figure out what maintainable code is and how to write it, so can a non-human. Furthermore, humans are rather unlikely to be the optimal form of intelligence for software architecture and engineering, so it's almost certainly the case that if humans can figure it out, some non-human could do it better. That it's not yet solved by models suggests that it's not easy and maybe even not practically achievable with current tools. But that's not the same thing as not solvable.
> Furthermore, humans are rather unlikely to be the optimal form of intelligence for software architecture and engineering
I like this framing. Humans invented software (and engineering in general) as a means to solve problems with methods that work best for us. There may be entirely different, and parallel, problem-solving methodologies outside of human best-practices.
I have not found it difficult to get these systems to write maintainable code. You're probably correct that most people don't care about this so they don't bother to do so. But IMO, this doesn't seem like a problem that is crying out for a solution.
> But yes, the coding agents will not magically make everything maintainable if you don't tell them to.
You say that like adding "Make it maintainable." to your prompts solves the problem. But the reality is we only have weak metrics for measuring maintainability. For example, you can trivially optimize for Cyclomatic complexity by blowing away abstractions and duplicating code everywhere. That doesn't make the code better. Cyclomatic complexity is a tool that has to be applied judiciously.
That doesn't mean you can't or shouldn't use AI to generate code. But it does mean if you want your project to scale, you're still going to need a lot of developer involvement at the code level to ensure the code remains maintainable so that future developers can build on top of it. AI is not like compilers, which allow developers to build complex solutions without being proficient at the next level down (assembly).
The author admits to a measurement: maintainability. There are quantitative and qualitative ways to measure this, the biggest signal being outright abandonment
That's terrible as a signal. It's too late for anything, and there's many reasons things get abandoned.
> code maintainability and good architecture don’t have good measurements that we can apply, because it takes months, years even, to notice the effects of bad architecture or of unmaintainable code.
One way of understanding "good" here is "actionable", imho.
I agree. In general a high quality and high value signal are two separate things.
> But yes, the coding agents will not magically make everything maintainable if you don't tell them to.
But that's not actually a change. Humans wouldn't magically make everything maintainable if you don't tell them to (and maybe not even if you do). You have to monitor them and train them, carefully, basically forever.
I guess, if I'm reading this correctly, you're saying that we'll need to monitor and train the agents, carefully, basically forever?
Maybe not forever. Humans you have to do it basically forever, because humans don't improve very fast. AI... you have to do it forever with the current level of tech. If the tech improves enough, who knows?
> You can absolutely use coding agents AND have maintainable code. But yes, the coding agents will not magically make everything maintainable if you don't tell them to.
The trillion dollar question is how you do this, if your employees do not care (they are optimising for salary & time spent not code quality) and you have no way of telling apart AI slop vs. good maintainable code. (If you could you would just train the AI.)
Before AI there was at least some way to tell apart good programmers from bad, because there was some human effort involved in coding. Now with AI and slop generation there is almost now way to do this.
> if your employees do not care (they are optimising for salary & time spent not code quality)...
From what I see is it's mainly managers and higher brass who doesn't care about code quality and sustainability, and aims to drive time to market metrics down aggressively with AI.
Any employee who cares about code quality will become a poor performer with a red luddite label because they dare to change what the AI has emitted for them.
I'd love to be wrong, very wrong about this, actually.
They don't care about maintainability because they're not going to be debugging it at 1am on Friday night but mainly because if something is wrong they have lots of people below them to blame for it.
Developers, however, are still responsible for the code! We must review the AI....all 80k lines of code it generated yesterday. If we don't then we are at fault. And we must go full throttle of course. So ....not be picky and retrograde about accepting what is generated.....
IOW we know who is going to get screwed and it isn't them.
We have all become underwriters and should get paid accordingly for that fact.
How are underwriters paid?
Badly.
Yeah but I mean, what is their compensation based on? I'm genuinely pretty curious about the point you're making here. I don't know anything about underwriting or how that profession works or how it is analogous to what you see as the future for software developers. But it seems interesting and possibly insightful.
I often have to ask myself if I’m asking for something different because of preference or need. I don’t really know what others are doing but I see this comment a lot about needing to always correct agents. I can’t figure out if it’s an exaggeration or not because once I’ve planned how I want something done I pretty much have zero need to intervene.
Impossible to know without doing a detailed comparison. Are you using the same LLMs? Are your criteria for correcting the output the same? Are you working on similar code? Are your plans and prompts the same?
Without any comparison I’m pretty sure the ones trying to correct LLM code are the same ones that incessantly bike shed human code decisions too.
It's fine to have preferences. The biggest problem with bikeshedding is the time spent (wasted) debating. But you don't have to debate the AI, you just tell it your preferences, and ideally encode them so that they are repeatable.
Of course it's fine to have preferences. I think you missed the nuance. Bikeshedding implies the time is wasted because the topic wasn't important in the first place. The color of the bike shed, as it were, has nothing to do with the storing of the bikes.
I am equating the nerve that develops in people that get lost bikeshedding (wasting time on inconsequential parts of the problem) with fighting an llm on inconsequential implementation details.
We most certainly agree: what matters should always be the actual requirements (functional, security, performance, etc.) You can't bikeshed an important topic. Everything else is implementers decision. In my experience an experienced engineer understands the difference and trusts implementers to make the decisions that they do own.
No I understand the nuance. But it's only bad to have preferences about things that barely matter if you waste time on them. You don't have to fight the llm, you just tell it what you prefer and it does that, that's what's great about them. (If it is not listening to your directives, then you have other problems.)
You use the intentionally vague word "implementers" to abstract whether you're delegating to a human or to an AI. But the key point is that these are not the same thing. If I'm delegating to a person, that person is the "implementer". If I'm using an AI to generate an implementation, I am still the "implementer", it is merely a computer program working on my behalf.
If it works why fight it? Because it's not what you would have done? Implementer is getting blurry to me, at least.
Directing an AI's work is not "fighting it". You keep characterizing it that way, but it's the wrong characterization. "Implementer" is not blurry at all. Humans are responsible for the things they implement, whether or not they use AI tooling to do that implementation.
Is that my characterization? This subthread is about how it’s so time consuming fixing every little thing the AI does to be just like you would have done. My challenge to that sentiment is “give it some freedom, don’t micromanage it.” That’s all.
I understand the boundaries of ownership and responsibility. That’s why I can tell you if you are spending inordinate amounts of time correcting AI code then you’re doing something wrong. Either write the code yourself or reassess your ownership boundaries. You’re acting as a manager of a team of agents in an agentic coding paradigm. Managers don’t tell me how to write code.
Without going and re reading the whole thread, I'm pretty sure that both of your comments that I replied to included this "fighting the AI" characterization. It's certainly fair that you didn't start the thread about it but were just taking the premise of the sub thread. But I just disagree with that whole premise. I think what's nice about these tools is that I can just write a document that says things like "prefer immutability" and then I neither need to micromanage nor accept code I don't like, and there is no long slack thread about whether I'm right about any of the things I've written into those rules, the AIs are happy to do as I've asked.
I think this entire analogy about being a manager of a team of agents that is in vogue is completely misguided. Have I always been the manager of a team of bash scripts? No. These tools are way more capable, but they are still just tools that I'm using to do my own work, they are not people that I'm delegating responsibility to.
> I think what's nice about these tools is that I can just write a document that says things like "prefer immutability" and then I neither need to micromanage nor accept code I don't like
Why are we even arguing then? You and I agree. Did I ever say "don't share a single preference with the AI"? You set the guardrails and preferences and the AI follows them. This is how it's always worked so it's reasonable for me to assume that people "fighting the AI" have already done this and are being overly pedantic about the output. Otherwise it wouldn't be eating up inordinate amounts of time...
> Have I always been the manager of a team of bash scripts? No.
No. You're not even remotely close here. Let's revisit this once you've figure out how to have a team of bash scripts implement 100k lines of code and build entire systems in 2 weeks based on high level instructions and requirements shared in context and prompts. You have responsibility at a different level and scale in an AI native workflow.
I don't know why we're arguing about the first thing :)
But I think we have a real disagreement about the second thing. You don't "have responsibility at a different level and scale in an AI native workflow", you're still using tools. I understand that what you're saying is that it's such a difference in scale that it is a difference in kind. But I don't agree. I'm fundamentally at odds with this entire framing of ai agents as a team that is being managed. I don't like any of the anthropomorphizing of ai tools. It's fine if it's just an analogy, but people take it way too seriously as a real thing IMO. I fully recognize that I'm out of step with the prevailing discourse on this, but it's a genuine disagreement, I'm not confused about what other people think.
"Hey look I got this brand new tool it can do everything my old tools did and more but I'm scared to use it to do more--might shoot myself in the foot."
I think most people have felt that way before. Only way forward is to practice with the new tool (=
> From what I see is it's mainly managers and higher brass who doesn't care about code quality and sustainability, and aims to drive time to market metrics down aggressively with AI.
Trends over time will drive more observable changes. If a whole generation of programmers picks up bad habits that their managers don't care about (think very junior), that will take some time to play out. It's like children's literacy. You don't notice overnight, but a decade of neglect and you have a reading problem in kids.
Yes, this is why it's good that we're having these debates. We should keep having them. Personally, I am not yet convinced that this is a real problem. But I also haven't yet worked on a team with people who have entered the field in the last few years.
The real problem is all the managers pushing so hard for velocity instead of letting the employees pick up the tools at their convenience.
> Any employee who cares about code quality will become a poor performer with a red luddite label because they dare to change what the AI has emitted for them.
I think that's true but it's a special case. AI is here to stay and with AI coding IS faster and quality is better than ever before. Ideally you want your luddite fired along with the slop generators and keep the ones who are using AI and taking their time to deliver a maintainable code.
"Luddites" can just be the ones pointing out the Emperor's new clothes have a big hole in them. Removing them is just ensuring that whatever mistakes you're making get reinforced.
> ... with AI coding IS faster and quality is better than ever before.
Is this claim based on something?
I'm not against or "for" AI (whatever that means), I try to use it as effectively I can, but for me it's not at all obvious that quality is better than ever before.
Speed I can buy, especially in new projects and utilities, but quality? At least I haven't seen this in practice, if anything I'm just seeing more code, issues, PR's and pressure ==> more slop, more bugs, less quality.
You can always say "skill issue" and "process issue", but that's partly my point here, AI doesn't magically solve this.
Presumably it is based on that person's personal experiences, like your own comment and all the other comments here?
Speaking for myself, based on my own personal experiences, quality is by far the bigger advantage of these tools. It has never ever been easier to write automated tests and to automate tedious manual validation. I'm running my code through like 10x more paces than I ever did before, because I can just say "hey try running this in these twenty different ways" (including with browser automation, if that's relevant), without needing to either do the tedious steps to run all that or to take the time to write a script to do it, and to compile and attach the findings to the PR. This saves me hours to days of work on validation, but the reality is that I just wouldn't have spent that time in the past, I just stopped at a lower bar for quality, because I couldn't justify the ROI for spending all that time on it. But now the ROI is huge, so it's a no brainer.
If people are not taking advantage of this, then yes, that is literally a skill issue.
Good use case.
For some reason this reminds me A LOT of past discussions about microservices, most wonderful on paper and forever debated, but I've never seen it work out perfectly in practice, for me it's mostly been a cluster F in most companies that adopted them.
Currently I see AI similarly, in theory perfect, in practice I don't see the claimed effects. So yes, skill issue, but skills are relevant and your company probably can't hire a rockstar team (if that matters in the future).
But your comment on personal experiences was very good! Spot on, we are all biased, easy to forget. Thank you for that.
I agree with your analogy as well, and I'm very open to the idea that this will mostly end up being good in theory but bad in practice.
> If people are not taking advantage of this, then yes, that is literally a skill issue.
...or domain. You said "including with browser automation", so you do web or web-adjacent development.
Not all of us are doing that. What I work on doesn't have any UI or output besides a log file most of the time, but it connects to many places and does many things like an octopus, but nobody sees that, but feels that it's there because their environment keeps on working.
I said "if that's relevant" and you jumped to "this guy just makes websites". I do many things.
The octopus you just described sounds to me like an excellent example of what having the ability to more easily do tedious validation is most useful for. If you know that the "environment keeps on working", there must be some way for you to observe that fact. And if it is an octopus, it is likely difficult and/or to change the conditions and observe the correctness with respect to those changes. I find it so much easier to do this exact kind of thing now. Or, "easier" really isn't the right word. It's that the activation energy is low enough now that I'm able to do a lot of things up front that I used to rely on runtime monitoring to validate.
I guess YMMV, and it's not magic, but for me it totally changes the calculation on when it makes sense to automate something (like that chart from the old xkcd about how many times you'll do the thing and how long it takes to automate) in a way that means I'm doing a bunch of things that are useful for quality that just would never have passed the bar in the past.
> I said "if that's relevant" and you jumped to "this guy just makes websites". I do many things.
I didn't. I made a guess. I might be wrong, that's OK. I love to be wrong, because I learn things by being wrong. Also no offense was intended, and I don't consider webdev inferior anything. What I tried to mean is, if AI has more training data for a domain, it does better. If you fire the same model on a niche domain, it falls flat.
> If you know that the "environment keeps on working", there must be some way for you to observe that fact.
Yes.
> And if it is an octopus, it is likely difficult and/or to change the conditions and observe the correctness with respect to those changes.
Nope. On the contrary, because there's so much innate knowledge that is required to know what to do, simulating in mind, deploying and testing on real world is much easier and faster than letting loose an ML model on it. You need real data, real data comes in slow, but you can catch problems early and easily.
Considering it's a niche area, AI also doesn't have much training on that domain, so it's doubly inapplicable for what we do.
> but for me it totally changes the calculation on when it makes sense to automate something ... (snipped for brevity)
It's great that if it works for you, but YMMV part is way more correct than people want to accept and want to learn. AI is a pneumatic hammer, but not everything is a nail which can be driven in with that.
When it works, it works. When it doesn't, well people still pretend it does or insists it shall. We must accept the limitations.
> deploying and testing on real world is much easier and faster than letting loose an ML model on it.
No this is what you're not getting. It is "doing the things I would do to deploy and test in the real world, but faster and in the background while I do other things", it is not "letting loose an ML model on it". This is the new capability. If you have any process like "do {action}, wait until {something}, check {something}, determine if it matches expectation", it is now possible to run that loop way more times in way more variants without either spending the time on it synchronously oneself or writing a script to do it. (If you do that specific action loop often enough, it's probably worth writing the script anyway, but that's also much quicker to do now.)
The AI doesn't need training on the domain, it just needs to be told "these are the things I would do, please do them for me and report back".
I'm sympathetic to not everything being nail-like, but I really think you're leaving a lot of chips on the table if you can't imagine any of this kind of action-check-evaluate loop you have that you could offload.
The thing is, I already don’t get blocked by this process. I deploy automatically and continue working. If something goes wrong, monitoring warns me.
Everything is already at the background. That thing doesn’t need a CI, not the classical or AI enabled kind.
Maybe I was not clear about that part of what I do. Three minutes of something not working correctly doesn’t burn our world down.
I'm saying you could do more things. Instead of waiting until a new thing is merged so that it can be deployed and waiting for monitoring to catch issues, you could be deploying pre-merge to testbeds, using different variants of the code or different configurations of the whole system or different inputs to exercise edge and corner cases. Maybe it's too complex of a system to set up that kind of testbed or simulation? Well, it's easier to do that now too! I can spin up and down environments, either with containers on my workstation, or in cloud deployments, that I would have not attempted in the past, because it would have taken me too long to set them up. But now it doesn't take that long, and I find it super valuable to be able to try more things out. (Cost is still a real constraint, I'm not saying that constraints magically no longer exist.)
Obviously I have no idea what your work looks like! But what I'm saying is that time savings are not just time savings. There can be a point at which the time savings bring you under an "activation energy" such that it unlocks a new capability, not just a speedup. And some of those unlocked capabilities can be directed toward improving the quality of software. And I think that's awesome and useful, is my prevailing point here. I won't claim that it will usher in an industry wide improvement in quality or anything, but for me personally, I'm making better software more quickly now, and I'm very pleased that I can do that.
I fully agree with this point about quality. I am doing so much more testing than I used to, because I have so much more time to do it, and it's so much easier to automate the more tedious kinds of validation.
Maybe it's true that lots of people aren't taking advantage of this and are shipping trash, but that's their own problem, and there have always been people who do the job poorly.
> AI is here to stay and with AI coding IS faster and quality is better than ever before.
Localised quality is great; whole-program (even small ones) are not usually readable by me.
> AI is here to stay
That's true, but it doesn't have to stay in this form.
> with AI coding IS faster and quality is better than ever before.
Citation needed, because the last study I read about was painting a completely different picture about code quality. Also, just because the AI pulling and remixing code from a known repository with high quality doesn't mean your code will be at the same quality automatically. Passing tests is not enough.
> Ideally you want your luddite fired along with the slop generators.
The thing is it's not possible to see who generates slop and who generates code, and if you fire the only people who knows about the codebase intimately, you'll be on a very exciting, possibly fatal ride. I don't recommend this. AI doesn't know your history and trade-offs. These guys do, and can guide you to clear.
AI can't.
Believing that AI will create bug-free code from start is believing that Rust is the silver bullet.
There are no silver bullets.
The reason that we can (not that everyone, or even most people will) create higher quality software now is that it is now much easier to try out a bunch of edge and corner cases, which would have previously often required a prohibitive amount of time to set up and run. It's a dream! I can certainly believe that people aren't taking advantage of this, but they should be!
But I totally agree with you about the measurement problem. I think it's a very difficult time to be a hiring and firing manager.
> The thing is it's not possible to see who generates slop and who generates code, and if you fire the only people who knows about the codebase intimately, you'll be on a very exciting, possibly fatal ride. I don't recommend this.
This is exactly what I said in my top comment. This is a huge problem.
...and then you said:
> Ideally you want your luddite fired...
The luddite is the person holding everything together.
Like the office maid who looks like doing nothing but keeping morale high and everybody's sanity intact.
You can hold everything together and not be a luddite.
"Just do everything to hold things together, and let me abuse you without complaint" is exactly the kind of patronizing sentiment that infests the tech adjacent scene these days.
The answer to that is "Fuck you, no. I have worth, and you will respect it". Gilded Age paternalisms are not something that needs to be brought back into vogue unchallenged, especially when the intent is to keep the rabble quiet, and the checks rolling in and up.
I hear you. So how do I earn a salary and say "Fuck you, no. I have worth, and you will respect it" to my employer? I would love to do it.
No, the luddite is the person in one bad location on the continuum, opposite the AI psychotic on the other bad end of the spectrum. The person holding everything together is the one applying wisdom to the use of tools for the things they are good at while avoiding the things they are bad at, rather than blindly following one ideology or its opposite.
Sorry, but you're distorting my framing of the term in my original comment.
I labeled the person who uses AI to generate code and uses their brain and wisdom about the system to refine that code as the luddite since they will work slower when compared to other "higher performers" who don't care about the code quality.
In my framing I'm aware that the person is not a luddite per-se, but will look like it since they will be slower while trying to create better code, albeit using AI in the process as well.
Citing myself:
> Any employee who cares about code quality will become a poor performer with a red luddite label because they dare to change what the AI has emitted for them.
Yeah I think we agree about this. We agree that this person being labeled a luddite does not actually deserve that label.
Chances are high the luddite is the one with the deepest understanding about the product and the code base - the one who is actually passionate about the project and actually cares.
Maybe? This does not seem to be in evidence to me. In my experience thus far, this seems to be way more of a personality and ideology split than a depth of understanding split. On my teams thus far, I've seen the deepest experts land on opposite sides of this question.
That could be the case. But if other companies figure out a way to deliver good code with AI, then the company with the luddites is going bankrupt. Luddites are better than slop generators, but both are worse against a developer with AI who actually cares and has a deep understanding of the code base and programming.
I don't think that's true.
I don't think companies are living and dying, by how much code they can produce. Even tech companies.
They absolutely live and die by how quickly they can produce working solutions.
Well, and that's how you get enshittification everywhere. Everyone just cares about time to market, consumers are left to drown among a sea of slop, and honest businesses go down because they cannot stand a chance against slop peddlers flush with VC money.
"working solutions" is the key portion of the comment.
Pareto principle. 20% of the effort will get you the 80% happy enough with a half finished vibecoded slop.
Enshittification happens after the company was quick to deliver a working solution. They successfully captured the market, killed off the competition and now they are ready to start milking the customers who have no other choice.
AI slop can actually help with this, because it reduces the cost of replacing their enshittificated software.
The reason its hard to dethrone Facebook, Instagram, YouTube, Twitch, etc. Is not because it's hard to recreate the software (it may or may not be) it's because of network effects, budgets, etc.
And unless you have ownership level stake in the company, you *shouldnt* care about what happens downstream of selling labor to the company. Yes, I highly recommend 8 and skate.
Ive seen soooo many people burnt out, or "ive given years to the company and i got hit with layoffs", or "$200 software would have saved $1000000 when I brought it up to them". And companies will throw you away the MOMENT your usefulness is gone, even if just perceived. So, use them just as much as they use you.
And that idea of slacker is ALSO a way to generate more money for you, by slyly withholding or slowing work. I didnt get my paltry 3% last year. Inflation up 15% or whatever stupid number. But I can control how much work I do, so my effective wage/hour stays with inflation.
Save your caring for your personal projects, nonprofits you help at, your and family/friends labor you help with.
I'll disagree with you, but probably what we do and our life philosophies are pretty different, so that's OK.
Well, what part do you disagree with?
1. Caring about the company when you are a worker and not owner?
2. Companies will throw away/layoff people with no notice?
3. Work slowage (work-to-rule) as a counter to low/no pay raises in accordance to general inflation
4. Invest emotional and physical labor in ventures you gain completely out of
With some. You insisted, so let's get into the details.
1. Caring about the company when you are a worker and not owner?
Yes and no. I don't care about the company. I do care about what I do. It's a self-respect matter. I do good work not because I'm a slave to company, but because of self respect. My deal is simple: "I'll do my best to produce the best artifact and push the company further as long as it doesn't conflict with my personal principles, you'll buy that time for that amount of money".
I have a simple, foundational rule: I'll sleep sound at night, and this rule is rooted in my ethics. So, I don't shortchange anyone, incl. my employer. If terms change between us, we will discuss, but this probability is not a reason to do shitty work (or optimize for money, or which sugarcoated absurdity others name this).
2. Companies will throw away/layoff people with no notice?
Yes, this is bad. This is life. It's not nice, fair or acceptable, but without unionization, you can't act against this. So, you either try to change this or you just accept it. Realities of work life is not a predicament to shortchange your employer again.
This is as absurd as saying "I'll die anyway, why do all these things? I can just die on-demand".
Meaningless...
3. Work slowage (work-to-rule) as a counter to low/no pay raises in accordance to general inflation
We can accept that, but you all shall really unionize. It's not scary. Try organizing. It's a force multiplier.
4. Invest emotional and physical labor in ventures you gain completely out of
Everybody should have hobbies either productive or unproductive. I can't find the question.
It’s not black and white.
There are companies where you can spend years doing as you describe. More and more, though, you’re competing with people who care even though they don’t own, put in the same effort YoY, and invest in their job. Companies love these employees.
So I guess it really depends on your values and what you want out of life. If you enjoy hobbies and time outside of work, sure find a job where you can coast. Don’t get frustrated when you get laid off just find another place to work. Etc.
Plenty of people want to grow within the industry and build a career, though. And many have what we call basic self-respect and care about how they are perceived.
> and aims to drive time to market metrics down aggressively with AI.
Go fast and break things has been a mantra for how long?
I think a lot of the laments about "good" code are really about "ownership" - and as someone who spent most of my working career in OTHER peoples code bases I have seen some things. There are a lot of you who think that your code bases are "great" when they are NOT. Personal understanding is not a good measure of quality.
The increased cadence from AI is just speed running to the legacy code base.
The answer: express the concern, and reiterate it after every issue that arises because of increased complexity. Start building a plan on how to "unravel" the mess, how to migrate things in place, how to start drawing boundaries in your systems. The system is designed to reward heroes who fix problems - you want to be super man who stops the bridge from falling apart, not the engineer who pushes the costly fixes it before it does.
> Go fast and break things has been a mantra for how long?
Practically since eternity, but just as we learnt to manage current rate of "fast" and "breakage", somebody attached a solid booster behind us. So we're trying to understand what happened and what's happening and what will happen.
> I think a lot of the laments about "good" code are really about "ownership"
People owning what they did, have responsibility and initiative about doing better is always a good thing, yes.
> and as someone who spent most of my working career in OTHER peoples code bases I have seen some things.
I can understand that, I'm sorry you had to go through this.
> There are a lot of you who think that your code bases are "great" when they are NOT. Personal understanding is not a good measure of quality.
My codebases are as great as my knowledge. I love when someone reads my code and points where I f'ed up. I also love to show what I did has achieved something I was aiming for and discuss how to achieve it betterer.
> The system is designed to reward heroes who fix problems...
And this is the problem. Because I work silently and diligently build something looking unimpressive while working like an atomic clock without any problems.
One way to get workers to care about the quality of the product they are being paid to build (for someone else's profit) is for the management to show some loyalty and build trust over the course of a decades-long career by treating them fairly and avoiding layoffs.
>The trillion dollar question is how you do this, if your employees do not care (they are optimising for salary & time spent not code quality)
Sounds like there is a compensation problem then.
Sounds like a culture problem. I’ve never had a team I lead not give a shit. Even if the project is dumb (some projects are dumb), there’s enough pride in competence and desire not to dump garbage on the people around you to ensure they at least want to try.
Disagree, throwing more money at devs hoping it will improve quality while continuing to take away their authority will only perpetuate the slop machine.
It's not that hard: treat people with dignity and take their contributions seriously, not as a disposable meat mass. In fact, not only will this improve code quality, it's likely to improve employee retention too.
You pay someone and give them the explicit responsibility for code quality in your system, empowering them to gate check-in with any static analysis and adversarial agent review they feel like. It’s not a silver bullet but you absolutely can do better than just giving up.
Anything involving an AI won't work. If it did AI companies would already train their AI with it. Review solutions during training, generate synthetic data etc., or as a budget solution just route the requests through more models before giving you an answer.
This isn't true, there's a limit to how much feed-forward processes can correct themselves and well-poisoning of context is far too common.
Try using an LLM to rewrite an LLM output without the slop (vs asking for no slop to begin with) or sandboxed subagents that critique a parent's draft.
There is absolutely a step-function improvement in quality but: 1) not everyone wants to explode their cost by adding extra calls 2) this can't just be "trained in" to a system as obviously they have attempted this but the technique still provides an uplift.
If you can do adversarial agent review, or use an LLM to fix the slop and it works, then technically you already have an LLM trained which knows what to do. You can just use them to improve the other model. The issue is that we don't have these at the moment.
> Before AI there was at least some way to tell apart good programmers from bad
There were only bad ways, and the best way was to just find people who were both good programmers and cared about quality to keep an eye on the rest. Nothing much has changed in that respect.
There is still lots of human effort involved. If there isn't, you've found the bad programmer
> The trillion dollar question is how you do this
I don't think it's that hard of a question to answer. I've noticed on my team, our thinking has shifted from how do you directly solve a problem, to how you get an agent to effectively solve the problem and not produce slop in the process.
One thing that we have done that's probably made the biggest impact is alot more upfront architecture with the knowledge that pretty soon agents will be running wild all over the code. Having worked with these agents for a while now, you get a very good sense of how they will go about solving a problem and the various footguns they will encounter along the way. Editing an AGENTS.md file or building a skill is not nearly as fun as coding by hand but it will pay dividends over and over if you do it right.
Another big thing is doing refactoring passes. Early on in our projects our agents generated ALOT of slop and we had to go back and fix alot of it. But every time we did one of these passes, a major aspect was improving agent instructions / skills / etc so it doesn't happen again. It can be a painful process at first but I found that over time, the amount of slop the agent produces goes down by orders of magnitude.
I feel like we're still very much programming, but we're now doing it at a "higher level" where we are not writing the code ourselves but instructing the agent to. And IMHO, properly instructing an agent on a production codebase is not a trivial task.
> and you have no way of telling apart AI slop vs. good maintainable code. (If you could you would just train the AI.)
I know how to distinguish good maintainable code from garbage. I have known for quite a few years. But knowing how to train someone, or an AI? I'm a good coder, not necessarily a good teacher. And there are things about code that I _feel_, not that I can rationally explain.
I completely agree with you on this. I was talking about the employer perspective. They have no way to tell apart the two and thus have no way to set the incentives.
You might write good, maintainable code, but they will prefer the slop generator who delivers quicker.
> you have no way of telling apart AI slop vs. good maintainable code
SonarQube
Lol no. Just get your company quality gates and put it in the Claude.md.
I guarantee you will pass the gate, and the code will still be dumb, except now you'll spend 10x the tokens.
> Before AI there was at least some way to tell apart good programmers from bad
That's why companies were interviewing people on tasks that had nothing to do with writing maintainable software. /s
I understand the concern and it should be addressed and researched. But, simply saying "humans were writing code themselves" doesn't provide any evidence for better quality.
You can, but nobody does. Of course, there's a lot of non-AI slop too. (Hello systemd)
> You can, but nobody does.
I for one, have far more rigorous quality checks in my hobby projects (where AI coded), than I ever could justify when I hand-coded them.
I'm not claiming to be everybody, but surely a good portion of the population are using these technologies similarly.
We're not talking about unit tests here. We're talking about data structure and code complexity.
The comment you replied to did not say anything about unit tests. And "software quality" is much broader than "data structure and code complexity".
I do think this gets to the heart of the matter. I think many programmers have missed the forest for the trees on why things like data structure and code complexity matter. They do matter, but they don't matter in and of themselves. They matter because they are the best techniques we have for making software that is of high quality (the software, that is, not the code) and which remains so over time, while continuing to be developed and adapted.
I strongly believe that it is now much easier to create software that is of high quality and adaptability, orthogonally to the data structure and code complexity concerns. Those concerns remain relevant, but it's a mistake to think of them as the primary thing rather than things that support the primary thing
> But yes, the coding agents will not magically make everything maintainable if you don't tell them to.
Yet.
I'm sure in few years, as new criteria enter benchmarks, AI will be creating the clearest and smartest code people every seen, by default.
In the beginning of August 2026, I started a hobby project: building a MongoDB-like database. I have 20 years of industry experience and a master's degree in computer science, so I followed a disciplined, spec-driven development model using Claude, Kiro, Qwen Coder, and Cursor.
The first version was built in about two weeks of part time work. Then I started exploring. I learned relational algebra, researched almost every kind of database, reworked the internals, built a small relational algebra layer, a query planner, and an executor, covering everything from the backend storage to the query language. I learned more in those two months than in the previous 20 years.
Did I care what code the agents wrote? No. I read zero lines of generated code. What I cared about was correctness, verified through tests, and the high-level product features. For the first time in my career, I acted as a senior product manager, steering the project along the right roadmap. Without AI, I wouldn't have been able to do that.
When you have superpowers in your hands, you don't need to worry about the laundry. For the first time in my career, I can produce code in C, C++, Java, .NET, or any other language. Sometimes it takes me longer than a senior developer in that language, but does that really matter? Absolutely not. Writing documentation and code by hand in 2026 is like driving a horse and buggy. It doesn't matter how skilled you are with the reins; you'll never compete with a car. My hobby db project isnt opened source yet.
"My project isn't open sourced yet" underlines the problem. There has been a massive explosion of software that works, but badly. The average user experience suffers as a result.
Call me cynical, but I dont remember interacting with well engineered software, outside of pure, mainstream opensource repos.
Most of proprietary software is just crap, and always has been. The agents are not producing worse code than typical, demotivated, i-dont-care-what-i-am-building-i-wont-try-using-it corporate development teams have over the years. I'd even bet that because now making changes and fixes is so much easier, the user perceived quality will trend upwards for popular stuff.
I would bet every single dollar I have that if the source was shared, there would be 15 "big brains" showing up to point out how it's actually "bad".
I have seen a decent amount of clearly AI generated software that's useful, would likely not have been made without AI, and is better for for being AI generated. With AI, people make improvements that they would have never have bothered spending time to do manually. If anything, having uncharacteristically good "production value" in a clearly hobby project is how I typically spot AI use in projects that aren't obvious vibe coded slop.
The code itself may or may not be spaghetti. Not that I care as a user. User experience and code quality had never a particularly strong correlation even before AI.
I'm sorry, I just don't buy the hyperbole. Something with your previous approach was deeply wrong if you condensed 20 years of learning into 2 months.
Databases, programming languages, compilers, operating system internals, networks these things are pretty complicated in itself. With your day jobs you can't master any of this without spending years in your part time. But now at least you can start something of your interest and learn on the way. Learning a new concepts, implements it, test it and reproduce cycle is so fast that it is only possible because of AI. You need to find the process which works for you. AI already knows every programming language, its best practices, entire computer science knowledge is already mastered by current state of AI. There isn't any single database internals which Ai doesnt know. If you dont believe just start implementing JavaScript or C compiler yourself without even having knowledge of compilers and in a few weeks you will where you stand. You will not only having a functional compiler but you will know the internals of compiler constructions, all the concepts.
Okay, you're going to need to go into a lot more detail about exactly how you learned more in 2 months than you did in 20 years having read zero generated code.
Code examples are literally bread and butter when it comes to learning.
How can you learn without looking at code? That's like saying that you can learn to be an architect without looking at drawings...
I didnt know what is relational algebra is? why query plannering execution done in certain ways. What are backend storage system available in open source or commercial products. What are the traitts of each backend storage and how does that effects the replication and failover scenarios. I know all of this, I implemented a small subset of sql's relational algebra in my project and its correct and concise. I expored different backend storage systems, first tried one, then move to next and then 3rd in line, all that in span of less than a month without ever looking what code the coding agents generates.
To make this concrete, it takes someone about 4 months to go through a university course.
They might take six courses at a time.
So you are saying that you learned more than 400 times as much content as a university course?
I'm sorry but this just sounds hilarious And unlikely to most people, and it comes off a bit crazy sounding... For example, do you actually think you could even pass a single university course exam on introductory relational algebra without AI I assistance at all?
I think what is more likely is that you feel confident trying to solve problems with AI's help.
That is not learning.
To learn something, it has to be in your brain, not the AI.
Learning is not the same as becoming capable.
There's an ocean of difference between those two
You need to learn the concepts not implementation detail. If you know what is relational algebra and AI teaches you this in hours then you dont need to know the implementation details any longer. If you can borrow intelligence to solve a problem, you should do that. We, the most IT industry is already working in high level languages which is not how the computer works but abstractions over abstractions that very very few people know the entire cycle of a program how it runs. So AI is not a future abstracton, it is already here and its "intelligent" as opposed to other abstractions. Writing code or documentation by hand is gone, its past. All programming languages, framworks are implementation details and AI has already mastered them, we need to now move on to high goals than learning how to write a loop.
Seems like my point might not be getting through.
I apologize for being blunt, and I don't mean to sound argumentative here, I'm just trying to give you an outsider's perspective:
You should not tell people you learned more in 2 months than in 20 years.
That's all I meant.
It makes you sound crazy, and its also wrong.
Maybe you built more or you feel more capable than you have felt for 20 years, but you surely did not learn more.
I don't need to hear anything from you about how the capability of the average developer has changed. I'm well aware of that already.
I don't even disagree with you here. It's something I've said in the past about things like algorithms. Sometimes knowing a surface level thing allows you to utilise it without necessarily needing to know the implementation level details.
But you did not LEARN Relational Algebra. You learned OF relational algebra. And there's a pretty stark difference there.
Did your MSCS not include a course on database theory?
It's fairly standard for undergrad CS programs and most textbooks include at least a section on relational algebra.
>I didnt know what is relational algebra is? why query plannering execution done in certain ways. What are backend storage system available in open source or commercial products. What are the traitts of each backend storage and how does that effects the replication and failover scenarios. I know all of this, I implemented a small subset of sql's relational algebra in my project and its correct and concise. I expored different backend storage systems, first tried one, then move to next and then 3rd in line, all that in span of less than a month without ever looking what code the coding agents generates.
To be as frank as possible--you "understand" these topics in the same way someone who watches pop-science videos about astronomy "understands" astronomy. That is to say, you have a surface level understanding at best.
This is the sort of behavior people have been talking about over the last few years. People confuse what the AI "understands" with what they understand, and it makes them say delusional stuff like "I learned more in the last 2 months than in 20 years."
or how to be a doctor without knowing how to cut open a person and look at the internals. looking forward to the future doctors
Yet millions of people code react slop without ever touching a line of assembley
Here is one my project is opened source. Highway https://github.com/System-D-AB/highway
It is fault tolerant, distributed broker which gurantees durable queues, pub/sub and RPC all into one easy to use programming model. The application is in production and passing millions of messages every day with sub-millisecond performance, you can crash a server and replica set invokes within seconds without losing any messages. The entire project is created in less than a month with part time working, just because of AI. Its in production and already proven.
Not that Github vanity metrics are the end-all be-all, but let's be real: this project has 0 forks and 1 star. You don't know if it properly functions because nobody is using it. Calling it "proven" production software is a joke.
Yes, you're running it in production, but to put it in perspective: PHP 5 was also proven production software at one point, running way more production instances than you.
Probably in the same ballpark with "correctness, verified through tests" written by an LLM.
git ls-files | xargs cloc
~41k SLOC, ~11k lines of comments
> Did I care what code the agents wrote? No.
I also don't care the exact cpu instructions my compiler emits. In fact I have no idea what the "stuff" it emits means (beyond the most elementary)... That doesnt stop me from creating very useful software that maybe even billions of people rely on (once you include the users of products that use our software)
Exactly. If you try to understand, really strive to understand what the AI is producing, then a lot of these arguments fall flat.
> I read zero lines of generated code
This is the opposite of really striving to understand what your AI is producing.
No one wants your hobby db
We're in the era of centaur chess.
Those with 20 years of experience are crushing it.
My worry is not about us. The worry is about the kids. I'm tech lead. I don't think the juniors at my company are learning anything from me. I'm not certain they're learning anything about _software_. Idk, I could be wrong. We barely talk because everyone has become so siloed.
Not trying to come at you, but what is stopping you from educating the juniors at your company?
I am trying. The main issue is it would be extremely annoying for the juniors, who have work to get done, and prefer to throw problems at Claude rather than ask me questions.
In general, I believe learning usually needs to be driven by the learner.
Unsolicited suggestion:
- ignore that it is annoying to some. (To certain degree, it is unavoidable and it is ok)
- reserve 1 hour meeting every month(week?) to demo/review/present.
- get buy-in and support words from manager
> hobby project: building a MongoDB-like database
But why though?
"When you have superpowers in your hands, you don't need to worry about the laundry" - love this
> For the first time in my career, I acted as a senior product manager, steering the project along the right roadmap. Without AI, I wouldn't have been able to do that.
This may be Dunning–Kruger effect in action. (this is not an insult, but showing cognitive biases)
1: https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
> correctness, verified through tests
lol
vibecoder 9/10 times, claim 10x improvement, project not open source
and 9/10 times project open source, project bad slop
Maybe I've just given up, or maybe I'm a realist? But I fully believe AI will just...catch up with everything?
There's so much money in it right now. There's such a momentum. There are zero incentives to slow down for those that are in charge.
I've accepted that in 5-10 years, the vast majority of human devs. and engineers will not touch a single line of code. It'll be small increments, with a couple of big ones here and there.
And there will not be any triumph for those that hold steadfast to the principle of human coding. They'll be tiny boutique shops that do custom stuff, in the same way cobblers are to the mega shoe factories.
We've been able to make watches with machines for 50 years. Handmade Watchmakers, and their producuts are more valuable and in demand than any guy running a conveyer belt. They still make 20x more if not 50x. People look up to them.
You can make a choice not to become a button pusher and still do things by hand. You dont have to fry your brain. You're falling for a massive trap to strip you of your value.
the difference is that code is not something the average person will marvel at over the intricate hand built details. You might get a few nerds interested if it's something super novel (like rewriting a major modern web app without any 3rd party libraries that is 30x more performant), but most people dont care. Extra true for businesses, I can't think of a business other than maybe a mom&pop shop or a place where showing wealth is important where they wouldnt happily issue casio watches far before they would consider a rolex.
Regular businesses are not going to build their own slop software because of AI, this is delusional. People will be hired because they love to build. Only a small percentage of the world loves to build things.
The most passionate people with the best reputation will suceed, they will continue to be in the most demand and will be the most valuable, like a swiss watchmaker.
Sorry LLMs arent replacing anyone who's got strong skills and cultivates them. You're so wrong here. These more passionate builders will however replace the lazy people who offload all their skill and brain capability to llms, and they'll use AI to help them.
Being lazy and letting llms do everything for you is not a good strategy.
I think this is a bad example.
Handmade watches are a tiny, niche market; they survive only because they've positioned themselves as a status symbol. Quartz watches are both cheaper and more accurate.
There is not room in the world for more handmade watchmakers, and there's not going to be room for much "artisan software" either.
Yeah, I have a really hard time buying the "AI code isn't maintainable long term" because if you look at the quality increase from January of this year to now, it's insane. We've gone from Opus 4.6 and GPT 5.4 to Fable 5.1 and GPT 6 in less than a year, where we went from 0 mathematics problems being solved by AI to a Millennium prize problem being solved in a few days of compute. Obviously not the same as coding skills, but it shows the growth in raw reasoning and abstraction.
I understand why people are resistant to this from an emotional perspective, but I really don't see a plateau in sight. RLVR is clearly still cooking and narrow RSI seems to be on the horizon.
But I'm also a realist. If the technology exists, it will be used to the maximum economical extent.
We still have to wait for actual cost of generated tokens to be revealed.
Economics depend on that a lot.
You can get a decent idea running some of this stuff locally. Depending on how efficient you want your agent to be, you can get an awful lot done on beefy local hardware and ~300W power consumption. Just inference of course ...
That would be like saying the first vehicle off the assembly line had to be profitable; there is an ocean of optimization that will drive the economics.
feels like pure copium to believe that won't change rapidly.
Belief without evidence is faith. I’m “agnostic” here.
I have no data for neither, so I’ll wait for numbers.
Will LLMs stay being useful? Definitely. Will in 10 years touching/changing code be somewhat niche, like ASM development is now? Not clear yet.
And optimisations are not a given, a lot of low hanging fruit are already taken, because it actually saves lots of money already now.
> if you look at the quality increase from January of this year to now, it's insane.
It's non-existent. LLMs still suck at writing code just as much as they did at the beginning of 2026, or 2025 for that matter. LLM proponents are always trying to hype everyone up on the supposed improvements, but they have never yet been real. That means they are unlikely to be real in the future either.
That's just ... not true? Have you tried qwen3.8 (compared to qwen3) or deepseek 4? they've improved tremendously, maybe not at every class of problems, but if you take a disciplined approach and don't ask them to one-shot everything (e.g. update agents.md as you go, actually use the thing you build, give feedback etc), it's positively absurd what you can get done now with a single agent.
I agree that not every class of software or problem or this or that is going to be decimated/revolutionized whatever, but to not see any improvement since 2025 just sounds like you're not looking.
> I've accepted that in 5-10 years, the vast majority of human devs. and engineers will not touch a single line of code.
Why would companies employ human engineers then? What is the value addition to justify high human salaries. If AI is going to get so good (and I am not saying it won’t happen, that’s a separate debate), why can’t AI figure out the prompts itself?
That is where a lot of people in tech believe things are headed, executives in particular. Fully autonomous AI-driven codebases. “Dark factories.” One agent generating a plan, one writing the code, one responsible for testing and validating, and one to orchestrate the rest. The idea is software development will follow in the footsteps of physical manufacturing and eventually become fully automated. I think one huge flaw with this belief/comparison is that the automated assembly line is deterministic. LLMs and AI agents are not. Every Tacoma made on the Toyota assembly line is made from the same blueprint. There are no robots deciding on-the-fly whether to use a laser weld or an adhesive, what material to use for a specific component, etc. Now think about how LLMs build software. No matter how strict a harness or detailed spec you give it, it will always make decisions. That is what makes it “agentic” after all.
I've fully automated the software development part in my company. With production apps, no code has been written by hands, no requirement written by hand. Everything is fully automated except the testing part. And testing means the human testable parts are still performed by hands. The resule, with less people we produce more, actually way more. Our cost has gone down, quality has improved litrally. The code is being produced with AI is of higher quality, we employ multiple agents during planning phase and then different agents during execution phase. Sometimes some tasks has to be redone because some agents are better than others. Our release cycle is reduced from 2 weeks to 2 days.
Who dictates what changes are made to the software at your company?
We'll probably get there, once frontier labs RL the fuck out of AI agents sitting in meetings and interpreting incoherent ramblings of business majors into actionable requirements. That's the biggest value human devs currently provide.
Yes, AI for now has significant code quality issues, but that's mostly because it lacks agency to take care of code quality unless you explicitly tell it to. It is good at refactoring its own messes when you even vaguely ask for it. So while something like Astra still needs supervision to produce decent code, I expect that in a year or two it will be unnecessary.
I'm in the same boat. When I started thinking about LLM development as multi-year iterative training adjustments, it felt like the majority of shortcomings can be addressed.
Man.. just code, let people build, design, adjust. Who cares? Who are these people writing these posts? Why should we give anything they have to say warrant? These posts are getting old, very quick.
I work in an industry where software bugs can cause real harm to real people. I care that my coworkers are producing more bugs than ever because they don't take the time to think about the code anymore.
Then where are your industrial controls to catch bugs before they are introduced to the product? Where is the feedback loop to the developers running the AI to control the situation?
LLMs should not touch these technologies. Keep your slop factories in webdev. We have missles, planes and pacemakers to make still. If you ever feel like using your brain again, theres plenty of work to be done that llms cannot touch.
Surely those industries are not relying on humans writing "good code" to make sure faults are not introduced, right? There are static analysis and automated testing and rigorous QA processes, surely?
Isn't this a testing and validation problem?
I think that we should realistically expect that even a very rigorous testing and validation process is not fool proof, just as we anticipated that the code isn't.
With that in mind, writing bad code is bad.
I don't think my comment implied that any testing and validation process will be fool proof. There are two claims in the comment I replied two, first that people are creating "more bugs than ever". I take that to mean more bugs per line of code or more bugs per unit of functionality or something like that. If that's the case, then I think it implies that testing and validation has gotten worse per that same unit, which I think suggests that it could be improved, without expecting it to become fool proof. Then there is a causal claim, that these bugs are because people are not thinking about the code. Maybe so, but to me, it seems more likely to be caused by inadequate validation.
> I don't think my comment implied that any testing and validation process will be fool proof.
It does by, attributing a change in quality to a "testing and validation problem".
If there is a change in programming methodology, as far as we know no change in testing and validation methodology and at the same time an increase in the production of bugs, it's not reasonable to attribute that increased error rate to testing and validation getting worse.
It's like adding spinning saw blades to the fronts of cars and then attributing the increased fatality rates to pedestrians not wearing safety reflectors.
If it happened as you describe, with no change in the testing and validation processes, then it exposed an existing weakness in those processes, which should be improved.
In your analogy, what I would say is that the saw blades on the front of cars situation exposed a weakness in the regulatory regime for what can be put on the front of cars, which should be improved.
> If it happened as you describe, with no change in the testing and validation processes, then it exposed an existing weakness in those processes, which should be improved.
I remind you that the belief you are defending is that an increase in the number of bugs produced per some unit of implementation "implies that testing and validation has gotten worse", not the general idea that you can or should improve software quality by improving testing and validation.
If we adopt the realistic perspective that the testing and validation process can only catch some fraction of bugs, then an increase in the number of bugs produced in the implementation stage is bad irrespective of what that fraction is. You can improve the testing and validation process so as to minimize the fraction of bugs that get past QA, but when you multiply that by the number of bugs produced in implementation you will be worse off if you produce 7 bugs per month during implementation than if you produce 5 bugs, regardless of whether you can also improve the testing and validation process. You will on average, over time, have fewer bugs in production if you produce fewer bugs during implementation given any testing and validation process that isn't completely fool proof.
No, what I'm defending is my initial comment in this thread:
> Isn't this a testing and validation problem?
One way for it to be that kind of problem is by exposing weakness in the existing approach. Another way would be if the approach was worsened. But both things fit my original contention.
I don't disagree with your concluding paragraph at all. But what I think is that there is no reason that implementing with llm based tooling implies an increased defect rate. Rather, I think it implies that there are existing or new holes in the quality process. That doesn't imply that I think a defect rate of zero is possible. But I think holding the defect rate steady is possible.
You could also just remove the product from the market. That will guarantee a reduction of bugs in production to 0. That exposes a weakness in the existing approach to marketing and overall product design, meaning the problem is in marketing and product design.
It is a warning to developers who don't understand the trade-offs involved.
Also a confirmation to people who have the same inner thoughts and are ashamed to admit in public that they think the exact same thing.
I think we need such kind of posts to combat the influx of AI news.
It's a product of the times. You have some folks who are really passionate about the craft of software, some folks to whom it's just a job, and an entire culture that promotes and incentivizes engagement through raw emotional connection (outrage, passion, pick an emotion).
What you don't see from most perspectives are the silent masses who simply don't engage, don't care about the discussion, and/or are too busy doing what they enjoy.
I think too many people (very much including me) who are "passionate about the craft of software" allowed themselves to become too focused on the code itself as if that were the first order concern of the craft. But the craft has always been about the quality of the software, including how its quality changes as a function of time and adaptation. Code quality is only in support of that concern, it is not itself the primary concern.
It has been a fairly painful experience for me to shift my thinking on this, but it's a much better mindset. I still care about many of the same code quality concerns I always have, but I'm thinking a lot more about why I care than I once did.
I don't know, we spent the last few years with tons of posts telling us "coding is dead" and the biggest companies in the world telling us our jobs are going to go extinct.
That mindset has also deteriorated my working environment due to some coworkers buying into it.
So it's kind of nice to see some sanity checks that align with my beliefs too. I can share articles like this with my teammates. I can see that I'm not alone in thinking most LLM code is slop.
I think too junior devs NEED to see this. My team had a couple of promising juniors who are now completely brain rotted by AI and can't even write "Hello World" without consulting Claude anymore.
Yeah I agree. We're still swinging this pendulum. We haven't found the stable equilibrium yet. It's useful for people to keep having this debate.
I agree, but the problem is when we outsource understanding.
> Who cares? Who are these people writing these posts? Why should we give anything they have to say warrant? These posts are getting old, very quick.
Anyone could say the same about any post they don't agree with, doesn't seem very helpful.
To analogize coding to sculpting - you're in the "toddler with playdough" phase. At some point you might want to make something other people will find pleasing and maybe even worth putting on display, the rules of composition, the details of materials, and the techniques for not wasting expensive materials suddenly become important.
If you're just writing code to fuck around or automate a small part of your life, whatever. But if you're making a big system or wanting other people to use your product, these things about how to make good software become more relevant.
> I’m going to make a prediction of my own… In the future we will see more and more companies proudly boasting their “NO-AI” policy as a competitive advantage. And they will be right
I'm going to make my own prediction: this isn't going to happen
I'll go one further: We'll see companies proudly boasting "no humans" as a competitive advantage and arguing letting humans do certain types of work is unsafe.
Not a lot of shops these days are bragging about hand-writing machine code and a complete lack of automated testing. We had already automated so much before LLMs came into the picture.
Why would you brag abput this. Most places make perf products do not use llms to write all their code. This isnt rare. You people dont know much outside of webdev. There isnt a single defense outfit doing it lol.
Neither of those mentioned is an equivalent in any way.
Seems like a pretty large claim. Why does a binary exist here and not a continuum?
I think we'll probably get both kinds of companies, but that they will both be fringe approaches, and the predominant choice will be to have humans working with AI tools.
Yep.
Just look at the growing gap in traffic accident rates between human and AI driven cars. Humans are losing.
We should just throw in the towel now then, I guess.
I don't disagree with you, but now what? Seriously - if we accept humans are just generally losing to AI now, what's the right thing for us to do now?
I dunno. Lobotomy? Heroic amounts of debauchery?
Any suggestions?
Luddites have existed since the dawn of times:
>Luddites have existed since the dawn of times:
Pet peeve - luddites had never been against technology. They had been against using low paid inexperienced grunt workers to displace well paid experts.
See: https://www.smithsonianmag.com/history/what-the-luddites-rea...
The definition you're using is not the definition that people nowadays understand the word for.
You don't go to a magazine website for the current common meaning or understanding of a word, you go to the dictionary And in a dictionary you'll read that a luddite is someone who is opposed to new technology, automation, or industrial change.
There are countless examples where people resist new technology for various reasons other than "using low paid inexperienced grunt workers to displace well paid experts". And this is what we call luddites, not the historical original definition of the word.
I know. I'm still upset about being unable to be "happy and gay".
Hardly a pet peeve when it's the most mainstream thing to point out nowadays.
But it's nice to point out to youngins who may not realize how "embrace and extend" worked historically.
this has some pretty extreme selection bias though. You could just as easily say
"We're not going to wear Google Glass"
"We're not going to use Blockchain for every single transaction"
"We're not going to connect every single object and device we have to IoT"
It's the same vibe as "They called <insert genius> crazy for his ideas!"
Yes, the also called lots of actual crazy people crazy. In fact the probability of actually being crazy, given people are calling you crazy, is very high.
Were those actual complaints? Maybe the first, maybe the brick and mortar? Who was saying we will never use planes??
Im assigning you some reading homework today (or have you totally offloaded your ability to read to LLMs too)?
https://archive.nytimes.com/www.nytimes.com/books/97/05/18/r...
And why are the people calling people Luddite some of the least intelligent people I meet, and seem to be complete sheep fighting some psychological war on behalf of their billionaire lords who own the machinery.
Not wanting to hand off all your labor to a machine does not make you a luddite, nor should it be acceptable to call people that because you dont know how to have a real conversation.
It seems like "luddite" is a reasonable description for a strict "NO-AI" policy. You softened it to "not wanting to hand off all your labor" in this comment, but the word "any" would be a more apt way to describe the quote in the comment you replied to.
I created a summarizer for that
https://briff.site
Okay. I prefer to read Thomas Pynchon's writing. Y
Thats a really bad website too btw, design and functionality. Maybe use your brain before you lose it.
For a 100x engineer with 40 yrs exp that you claim to have, you make some real basic high schooler projects lol.
I already know how to code proficiently in more than 20 languages, that's the result of 40 years working in the field and being a 100X programmer. The summarizer is just a tool for myself, I build tools every day to simplify my life, not for sale, not for monetization, like tracking gym schedules or pickleball rallies with my friends, like kanban boards for my wife, they solve problems I have, not you, so that's enough for me and rewarding in itself
And AI does it all for me while I sip coffee and play mahjong (built by AI of course)
Saying you do those things when it’s AI doing them for you is akin to saying I cooked a meal while picking up fast food in a drive through line.
I mean this sincerely; the arrogance of calling yourself a 100X programmer is astounding. I don't know how you managed a 40 year career with that kind of attitude.
I was a 10X programmer and now AI has multiplied that by 10X you do the math if you can, or ask your LLM of choice
AI can be a multiplier of both your intelligence and your stupidity, arrogance is a byproduct
The amount of ego and hubris you're displaying is sure something.
I havent met a single honest person who doesn't admit that their use or LLMs degrades their ability to do the same things without them. You're being dishonest.
Hubris.
Another green name posting edgy comments. It's just embarrassing and you're wasting your time.
What was edgy about asking someone to read a Thomas Pynchon essay on the word Luddite? Id argue their weird comment about people who don't like AI being luddites is more annoying and discriminatory.
AI maxxers know they're doing harm to themselves by overusing llms. The way they react so defensively when you point it out to them lets you know its real. Everyone wants to pretending like they have superpowers and are evolving into "100x" engineers, but in reality they're devolving.
I remember seeing some companies boast about "no outsourcing". I think 99% of their customers won't care for such things, as long as the customer gets what they want.
You’re both sorta right imo. Some companies are going to try and virtue-signal artisanal AI-free code, and some will just deliver sorta what you asked for, and neither will be perfect.
Most software is not good, using these rules. And that is written by human developers. The problem is that most software developers have less than 5 years experience. The community doubles every 5 years. Experience is scarce. So AI, learning from all the stuff online, does not learn great code, it learns from available code. You can make it produce better code, if you do the hard work of defining better in terms the AI understands. I've been trying to find a way forward with AI generated code, using my own definition of 'good architecture', and results with chatgpt 6 are promising. Not perfect, but good enough. I used a book I was writing as input, you can read an unfinished version of it here: https://programming-for-wizards.dev.muze.nl/ (Still working out the kinks of the underlying software) The other approach is to explicitly keep the whole decision tree as a causal chain in a repository: https://github.com/muze-labs/spiral-developer Still testing that one out.
> Fact is, vibe-coded projects devolve over time into an unmaintainable mess. The reason is simple, yet hard to fix: code maintainability and good architecture don’t have good measurements that we can apply, because it takes months, years even, to notice the effects of bad architecture or of unmaintainable code.
Oh boy do I have some news for you about legacy codebases.
I’m not even sure that his axiom is true. A project started with a 2024/5 model can subsequently be worked on by more capable models (who don’t, unlike some humans, have a deep aversion to paying down technical debt). I’ve seldom seen a human written legacy application spontaneously acquire a better engineering team every six months.
I believe many of us here knows that the idea of a simple prompt to make something more than a sketch or a prototype don’t really work.
Unless you steer and understand what an LLM will produce, you will end up with something that possible ”works” that has no future plans baked in. Suno generated music has a very unpleasant feeling of sounding like competent music with nothing to say.
I’d say that vibecoded software is similar. My speculation is that current breed of LLMs do not have an I, and I really don’t exactly knows what goes on in those vast arrays of numbers. There’s something there perhaps, but no person.
Still even in the short term someone wants to run a company that expects responsibility of its organisation, how are you going to exact that responsibility if no one actually understands how the thing the organisation makes works.
Maybe a simple crud system can be made fast and loose. But a bank settlement? A pacemaker? Deletion of sensitive data?
I know some companies are betting on that the agent can fix what the agent breaks. It may be true, but up until now everytime I try to relax on strict steering of an agent it tends to go badly rather fast.
Again I don’t know, but I think as long as we don’t invent synthetic persons with their own ideas on what they want to do, which btw opens a massive can of worms, the current situation will persist. However clever the current breeds of systems are.
I do want to state that a find the current trajectory fascinating. I use LLMs daily, it expands the number solutions I can explore. But in order to make something I feel is mine. There’s a choice and the buck stops with me.
Imagine AI making your favorite book or film. Could it be prompted into making Lord of the Rings or whatever it is that you enjoy? I think those who only watched the film might say yes :-) Those who love the book might say no.
There’s a few things on this. I’ve read the trilogy many many times during my life. Every reread I found something new, something I hadn’t considered before. Still it was eerie to see Peter Jackson’s rendition because it was very close to how I picture the book in my mind.
So, I think if you know just a little bit of film making and writing and LLMs you know you could not prompt any of them into existence with just saying ”write lord of the rings”
But if you have an idea for a creative project, using an LLM to explore ideas can definitely be a fruitful endeavour.
The gods don’t give gifts by ghost goblins cannot be dismissed as slop. I’ve personally used LLM to explore large sets of photographs to use as a backdrop for a DJ set, essentially to have the set tell a story.
So, as most things, it’s complicated. But at the same time I’m curious what will happen next
And in 10 years we are going to do double blind studies and realize that nobody can tell the difference. A fact that will be ignored for the next half a century.
I've read a lot of posts similar to this recently and keep asking myself if the past 20 years of my professional experience was that atypical.
I’m sure there are companies who are writing “perfectly maintainable and highly scalable code”. However, for half of my career I’ve been brought into startups to clean up the mess created by engineering teams.
While AI may create an unmaintainable mess (I’m not totally convinced), from my perspective many (not all) engineering teams have been doing that all along. #v2 #refactor
Ah yeah, light bulb moment here. I do think the disconnect I sense in reading these comments and discussing this might be in my level of expectations for how good "code quality" has ever been or even really can be in non-trivial applications.
To me, AIs seem to write code with a normal (low) level of quality, but I now have so many more tools to make sure the software works nonetheless, to refactor quickly, and to encode better practices that (mostly) stick in the future.
So to me, this is all a huge net win. But I guess if I'd ever worked on a pristine perfectly engineered system, I might see this all differently.
To me, it's always been a mess, and I'm just ecstatic that I have more ways to manage the mess now.
Agents (controlled by same population of devs) can generate unmaintainable code on a different scale.
There are already consequences.
We (collectively) were unprepared for a machine that presents itself in human forms. We were the frogs that boiled ourselves. We built a world of images and words on a screen. And then we built a machine that can (increasingly) mirror that world; it does so in a way which most of us are incapable of disambiguating.
It feels like there is indeed a ghost in the machine.
And there is, but that ghost is us. And that ghost is fading surprisingly quickly.
As much as I'd love to believe it, it is now a conservative take. Sure, having a solid architecture in mind still matters right now, but manually writing code is completely unnecessary and, before long, even designing the architecture is going to be completely automated.
Here I am starting to think a central part of knowledge work is the knowledge gained.
Maybe you are right, maybe not, let's see. Unfortunately I kinda agree, because humans are really good at being lazy and going in the path of least resistance (including me). It's genuinely difficult to not use AI even if it makes my work worse, as long as it's easier and faster.
Does writing table schemas count as writing code? Is that architecting? Both?
I personally don’t trust coding agents to have enough context to write domain-specific table schemas, and I don’t have the patience to transcribe all of the context into a natural language prompt. If I ask it to, it’ll write something for sure, and maybe that can be a jumping point for me, but at some point I have to physically write what the columns will be.
You should definitely try it if you haven't already. Most of the models are deeply familiar with domain specific areas in ways that most of us aren't. In fact, I would say the problem is generally the opposite. If model size and effort is is high, it will over architect what an app needs. I find myself reigning in a giant email notification system with subscriptions and "channels" and other such nonsense when sometimes you just want a simple one off.
Yes, the LLM knows the definitions of the words in my domain, that’s clear and obvious.
No, the LLM doesn’t know our product strategy and why certain things matter and certain things don’t. That’s very much what I get paid to do. There’s not even agreement within our team about what path we should take through the domain-product space, there’s no chance in hell that the LLM will choose a profitable random walk through that domain-product space.
If it were able to do that, then AGI would have already been achieved and we’re only compute power away from OpenAI or Anthropic making the marginal utility of any piece of code $0.
Yeah, it's not just over-engineering, it is just that generic systems that look like everything else usually don't solve a business problem, but I think I would be less dismissive of its world model in general.
LLMs are not a "random walk", they take in information and they explore the space according to the way they've been instructed.
I repeat, I hope you are right as I enjoy coding a lot. I just wish that people who keep not using LLMs too much won't have troubles because of that.
I’m taking this view now as well. If you’re reading code, you’re probably doing it wrong. You should absolutely be setting criteria that can be objectively measured and rejecting code that doesn’t meet those criteria or perform as specified. We are all senior software engineering managers now, with a fleet of cheap and ambitious young engineers doing all the authoring.
But reading code? What does that accomplish, other than to slow your dev process down enormously? Serious question.
Man, I think that code is still the artifact that we produce as developers. Code is the truth. I don't find it difficult or super time consuming to just... read the code, either. I've highlighted quite a few issues with LLM/Agent output from just glancing at the code.
I'll let you know how it goes... My new VP of engineering is a 'no looking at code' type of guy and is ripping 10K LOC PRs / Docs / plans against our 25 year old codebase and I would not say that they're 'good' PRs.
Maybe I'm completely wrong, but I think reading the code is more valuable than ever when working in a full-stack / small company role. I can tell you exactly what the business logic or functionality is for a certain piece of our system, in truth, without having to step through and make sense of ambiguous docs (that were also AI generated).
(I have a sneaking suspicion that in two years or less, my small team is going to significantly compromise the integrity of this codebase. Maybe by then we can refactor with GPT 12.)
> You should absolutely be setting criteria that can be objectively measured and rejecting code that doesn’t meet those criteria or perform as specified
This is the classic "make no mistakes".
On a serious note, I might set as criteria "avoid code duplication". Does that mean that the model/agent will actually follow it?
> What does that accomplish, other than to slow your dev process down enormously?
I am an OSS developer and I often see PRs (i.e. from the general public) that look correct, pass all CI checks, are heavily documented and they are still wrong.
Most of the times either they duplicate code that already exists somewhere else, or they implement a "feature" by opening a can of worms for subsequent "features" in the same area.
How do you measure absence of concurrency bugs for instance?
> even designing the architecture is going to be completely automated
I mean, people have been dreaming about this for decades. The whole reason UML was so overdesigned in the first place was in hopes that people could code by drawing boxes and lines. The full COBRA spec had software autonomously buying components in digital marketplaces and installing without human supervision.
It is funny to see engineers insisting that there's no way a machine could do this better. If anything, the surprise is that it took good old human language -- that second L in LLM -- to get the computer to sling code. The assumption was that a computer would just "speak code" like some kind of native tongue, but instead it just understands human language and associates that with code, and relies upon things like compilers and tests to see if it's right. Just like humans.
Predictably, now that it's actually happening, engineers are worried. As they should be, but I think it's a short-term worry. The job is changing, productivity is leaping, but its still a world where computers don't need to do stuff, humans do, so humans will be making it happen one way or another.
But then what will I do for work? :(
Our only hope is that work will cease to exist.
[Looks at people running AI companies]
Hmm, I have deep concerns about what and who is going to cease to exist.
Well technically my take is still valid
And we will all live happily ever after? What a load of naive nonsense.
Tbf, at this point, this has been said ad-nauseam.
At least I did not find a new thought in that (granted, relatable) rant.
"This is bad and you are bad" requires people to not defend their reality through rationalization, but the point we're at with AI right now is driven by exactly that. So this is at best highly ineffective at reaching the people it claims to want to reach.
That said, the underlying emotion of "you all suck and I hope you lose your jobs you frauds" is relatable and worth screaming from the rooftops of Linkedin dot com for the catharsis alone.
If you have ever looked at a kite and said to yourself, "that is as good as a hang-glider. maybe better.", you might be subject to the perils of one-shot AISDLC
> Fact is, vibe-coded projects devolve over time into an unmaintainable mess.
We've had strong coding agents for less than a year. Anyone making such a definitive statement about how vibe-coded projects progress over time is basing it on guesswork, not evidence.
In my experience, the most difficult part of a software project is getting the specifications correct. To abuse Harold Abelson famously quote: "Programs must be written for people to read, and only incidentally for machines to execute."
"A Project must have proper tests and specs, and only incidentally for a working program that executes"
Somewhat, but I've for sure seen new projects become grindy messes in a few weeks.
Or, evidence from a sample of poorly designed projects.
So there's evidence that it can be done badly enough that the problems show up in less than a year. That doesn't prove that more evidence will show up after a couple years, or five, but it does make one suspect that it will.
Stewardship requires a sustained commitment to quality and in some cases people just care less over time
Solid points. I will add a few points.
1) A lot of the time i spent deciding on interfaces (methods, classes, etc.) for humans. E.g. should this be two methods or one, should this method be in this class or moved to utility. Those problems went away. 2) What about performant code? This can be prompted away and when the measurements in your performance tests do not go down, then you can step in. 3) Sad to say but the AI has always been better than me at code-reviews. Maybe this is just me and if so I own that, but to the articles point, it might be harder to fix now. 4) "vibe-coded projects devolve over time into an unmaintainable mess". Preventing and managing this mess is the new skill sets we need to develop as software engineers. 5) Another skill-set we will need to master is how to maintain and grow our coding skills. Some ideas are: a) every once in a while implement a feature yourself. b) no AI Tuesdays! c) Have the AI quiz you on the code base. d) Have the AI develop HTML docs about how the code works.
I've found it helpful to make an explicit delineation in the codebase for which interfaces I'm going to agonize over and refine and which I'm going to ignore.
One set goes into haxe files and I use reflaxe macros to write tiny compilers that generate docs, clients, servers, cli's, test cases, serializers and deserializers, etc in whatever language is appropriate. That leaves gaps, which the AI can then fill in.
So I iterate on the haxe stuff. If the AI is struggling to "draw the rest of the owl," I change the source of truth until it has enough guidance re: type related errors, failing tests, and documentation. As requirements change, these things change.
As for the rest of the owl, it's disposable. Every few months I'll delete it and have an AI rewrite it from scratch (now with a smarter model and better docs and API specs and tests to guide it). This keeps the cruft from accumulating while preserving human contact with the code.
> Preventing and managing this mess is the new skill sets we need to develop as software engineers.
How can we prevent and manage the mess if we're not actively working in the codebase though? (Sometimes, I'll get a 'feel' for when something needs changed or will become unmaintainable, but that required consistently interacting with the thing)
Currently, we look at code once during the PR and then we never touch it again until it comes up in the PR.
I'm still handling a few tickets a week without AI, because sometimes it's faster to make a 2 line fix than to write + review a prompt, but increasingly it's just to make sure I still 'got it'.
1) Those problems did not go away. They only "went away" if you assume no one will ever need to read code again. And if you believe that, you clearly aren't reading the code already. Which I guess is why you think naming and architecture problems went away. AI is the absolute worst at architecture decisions.
2) not even sure what you mean by this
3) probably shouldn't admit that. It implies the reviewer has a less than average understanding of the code they're reviewing.
4) preventing and managing vibe code devolving into a pile of slop requires programmers not use AI. 80% accuracy repeated in more and more layers === more and more failures. In other words, the skill required is exactly the skill of being a good programmer without AI.
5) e) no AI all the time or only use AI as search. You're almost there with a and b. With c, it just doesn't understand well enough to "quiz you". With d, how are you going to know if the docs are correct if you aren't reading the slop?
Every large code base goes to shit unless you have a very strict bdfl at the top.
AI is nothing special or new in this regard. It just gives a single guy the velocity to ruin a codebase at the rate of a full enterprise team at double the speed.
A shitty code base still makes money, and that's all that will ever count for the majority of the employed developers, those who don't blog.
To me, the problem is not about what AI is good or bad at, but about institutional knowledge. If AI is doing the coding, writing, designing, or whatever else, you slowly lose the ability to a) learn from others in the org because nobody knows what you need to learn anymore and b) actually improve stuff because there's no more "what good looks like"
My companies current national marketing campaign strategy, structure and creative work has been created by an MBA from outside our industry who did a "deep dive" using AI. The project manager they brought in to run the tickets is also adding AI made decisions on brand and ad copy.
The short version of the result is that we're completely copying the leaders in our market that have 100x our marketing budget because they're the only ones with documented strategies for AI to cheatsheet from, with no sense or irony or concern that perhaps their scale is a core part of their strategy.
It's not just institutional knowledge. We're suffering the death of the specialist. Now every generalist is pulling triggers with no sense of limitations.
which begs the question - will institutional knowledge not matter before long?
it will not. Dead Internet Theory - eventually everything will be slop. And even if you care to avoid the slop, there is no place left for anyone to differentiate from the market slop offering because the 10-20% that actually care about not being fed slop are not enough to sustain a market.
Really it seems more like late stage capitalism and things that were already occurring before gen AI in all markets, not just internet based things.
I think (hope?) our industry will reach some equilibrium between fully agentic development and reviewing/hand tuning the code.
Personally for my job I struggle to justify writing code by hand. Agents are much better at typing the code, reading the code, finding patterns and discovering bugs. They don't have my knowledge and my background so the current models still miss things or overcomplicate the code. I don't know if that's going to be true of the next generation of models (or the one after that).
With current models, I cannot fully give in to the vibes. I _have_ to look at code (maybe not 100% of it but at least a majority of the lines). I _have_ to grill the agent to make sure it writes the best code that I deem possible for the problem at hand. This isn't the fastest way to do agentic development, but AI agents have already made us significantly faster than we were in the pre-AI era. I don't want to squeeze every ounce of 'development speed' if that comes at a cost to code quality, maintainability or debuggability.
For my side projects, things are different: either I only care about the outcome (and I give in to the 'vibes') or I care about the journey just as much as the destination in which case the agents are extremely advanced search engines, code reviewers and mentors but they don't get to write any of the code.
Yeah, I guess I personally fall on the whole spectrum: for side projects I'm at the extremes but for my professional work I fall somewhere in the middle.
As far as maintainability is concerned, have we all forgotten the 12 Factor App in the age of AI?
https://12factor.net/ https://en.wikipedia.org/wiki/Twelve-Factor_App_methodology
Kevin Hoffman expanded on that with the 15-factor app: https://developer.ibm.com/articles/15-factor-applications/
Mind you I may be dating myself as I was first introduced to this paradigm in 2015 working as a Java SpringBoot engineer on an enterprise project that I then migrated (57 microservices) all to Scala, after onboarding two weeks to Scala fresh from no prior Java experience.
I feel like there is so much "wisdom" encoded in books and writings from some of the most prolific engineers and architects over the last several decades.
Look at Matt Pocock's skills with simple primitives like grilling the human, researching through wayfinder maps (a Godsend to my workflow prior to Cursor Projects and orchestrator patterns), and having a solid Domain Driven Design through defining a shared glossary and breaking up work around proper seams.
12 factor is good but it is a very low bar.
It is perfectly possible to vibe-code a badly designed app that still passes those 12, 15 or whatever points you define.
Could you share some higher bars that may make up a better "rubric" for this issue? I am actively trying to do so. Shy of just condensing core Manning publications that cover domains of interest, I am struggling to find a good bar to have my clankers validate against outside of minimizing cyclomatic complexity.
Cyclomatic (and cognitive complexity) are a good start.
Some other ideas
1) Enforce architecture decisions (see archunit). But somebody needs to write them down first.
2) Check that tests actually break if the code that accompanies them is removed (several LLMs/agents today create tests that don't actually test the code they "guard against)
3) Automated performance testing. An LLM/agent might create a change that is "correct" but increases latency for 3x (best case) and 20x (worst case)
The hardest part that I see no solution for today is to understand when a change breaks backwards compatibility. LLMs/agents are trigger-happy and will happily refactor/remove stuff without any care about who is using that.I don't have a proposal for that, but the problem is there and is not covered by 12-factor config.
Excellent set of criteria, thank you. Something like am archlint, or performance lint, and sanity check on tests "Actually testing a seam or function" of the actual code base sound like good research avenues.
You can still read the code, ask the AI questions about it, and ask it to fix things. Coding agents are a power tool for cleaning up codebases, but you have to ask for the right cleanups, which means figuring out what it is based on your understanding. (You can also ask the AI to suggest ideas.)
This takes time away from implementing new features, but that’s true of all code health maintenance.
> You can still read the code, ask the AI questions about it, and ask it to fix things
This only works in small projects. For large projects, it is close to impossible. Everybody talks about how new models appear all the time and nobody comments on the fact that context size has almost stalled.
Yes, it's certainly possible to generate code faster than you can clean it up. That's a choice. (Often called technical debt.)
Can't everything be broken down into smaller pieces? And isn't that actually a good principle in general?
Sure. But in order to do central refactoring and actually improve stuff you need to keep in context all the small pieces.
You can split a small program into piece A, B, C All of them look correct on their own. But they duplicate something in 3 different ways and person/agent who can "see" all of them can see the duplication and refactor.
Current model context is simply not enough for large projects.
Same problem for letting AI review code. A PR might look correct on its own and be small enough to fit into context. But somebody who has access to the whole code of the project again sees the duplication.
I am an OSS developer and when reviewing PRs I actually look at how the same problem was solved in other popular OSS projects. No AI can check this today because there is simply not enough context.
Basically if we had unlimited context what you said might be true. But context size is limited today.
I suppose it's not enough to break everything down into smaller pieces, your architecture also needs to be composable. That would address the issue of duplication. Think a plugin system.
Duplication was just an example. Code architecture is the general topic.
Yes a plugin system is great, but it only works if that plugin API/interface it designed correctly and gives plugins what they need while still enforcing good practices.
But somebody needs to design a plugin system that does this first. And designing a plugin system (for large projects) brings us back to square 1 :-) (that you need a large enough context to see what the code does in order to anticipate plugin needs).
Was expecting to read something along the lines of:
"Knowing what you don't know is the beginning of wisdom", and a new take on AI reasoning, but didn't actually use the word wisdom in the text.
Anyway, I think we're increasingly finding the old adage "garbage-in, garbage-out" still applies.
The question I would ask is: Does anyone first ask the AI for a non-coding solution rather than jumping straight to code? Is Systems Analysis dead? Does no one read Hawryszkiewycz anymore?
Effort is all. It was before AI, it is the same with AI.
Putting in massive effort with AI leads to quality exactly like before hand coding.
Vast majority of work was junk before AI because vast majority of people put the minimal possible effort.
The difference now is that AI can make low effort work look high effort at a surface level.
> The difference now is that AI can make low effort work look high effort at a surface level.
True, but we'll also get higher standards I think. It's become easier to do things, so skilled people can do more complicated things. We compare to what humans can achieve.
> because we’ve always done automation at scale, everything we do is automation
I'm weirdly attached to this line. Physical automation a.k.a. factories are not portable. The manufacturing techniques are, but to "spin up" a new factory requires expertise, effort and capital. In contrast to software, replication can be done quite effortlessly, with containers and such tools, it's easily a one-man job.
Writing, coding and art are not meant to be repetitive, scalable tasks. I think that's what's driving the core of the backlash. If these forms of human expressions can be automated, then why would we need to apply our mental capacity at all?
I do think AI might get better and better at coding, as long as there are still humans creating software for AI to learn from—which may actually be a bad thing.
What worries me more is my own tendency to rely on AI more and more. It is becoming increasingly difficult to choose the harder path of coding by myself instead of taking the easier road, even though I know that road may gradually make me lose some of my skills.
Fortunately, I am closer to the end of my career than the beginning, but I worry a great deal about the new generation of developers.
AI lacks wisdom because it processes patterns, not reality. It excels at statistical synthesis but cannot understand the meaning, stakes, or consequences of its outputs.The real danger is cognitive atrophy. If we outsource our critical thinking to automated averages, we stop doing the messy, high-latency work of building our own internal world models—effectively redefining "wisdom" as whatever the model outputs.Would you like to turn this short summary into a social media post, a quick debate rebuttal, or a thesis statement?
Very interesting post. Feels like my comment from two days ago [1], elaborated. I must thank the author for verbalizing all the concerns.
So now we have a fork: red-pillers who want to regenerate software all the time (esp those with unlimited token budgets) and blue-pillers who want to maintain more code mass per developer-head. Plus, we have software artisans.
That will be an interesting horse race.
[1]: https://news.ycombinator.com/item?id=49774239
I'm all in favor for well crafted software and thoughtful designed stuff. The "No-AI" branding will probably become somewhat popular as you expect it, but how can we trust this? We've already seen so many examples of people (wether normal people or very important people) using AI and disguising it as their own thought. How can we ever trust a company just slapping a "No-AI used" logo on their landing page?
Wisdom is very rare. I constantly have to tell people "we did it like that in 2012 because it seemed like a good idea and there were no better options - but this is 2026 and there are now better options and we shouldn't do things the old way instead.
Too often people get an idea and don't stop to ask if there is an even better idea. (I'm guilty of this myself). Often it takes a while to figure out what the good ideas are, but people want an answer now.
>People are actually terrible at making predictions. I believe the future will surprise all of us. But, I’m going to make a prediction of my own…
>In the future we will see more and more companies proudly boasting their “NO-AI” policy as a competitive advantage. And they will be right.
I will very happily take the other side of this bet. Maybe if LLMs stayed as September 2026 LLMs for the next 20 years, I'd grant it's possible. But that's not what's going to happen.
Are LLMs getting much better at coding? The new models are arguably better at understanding context and coming up with a solution that works but they still write just as much hilariously bad or hacky code as the models did 2 years ago. I e.g. ask Fable 5.1 to make changes to my software and if it's something that's not a standard CRUD architecture on top of a well-specified library it will come up with pretty wild stuff, i.e. producing shell scripts with a "cat" command that contains a 1,000 line Golang program that it compiles on the fly to load some data, or a whole Javascript tool it crams into a string in a server-side web app to make some UI element work instead of figuring out how to do it "right". Another model wrote its own (buggy) YAML parser for reading translations and I had to figure out why it broke my whole pipeline (can't even say why it chose to write that instead of just reusing a standard library, maybe I told it before to be careful when adding untrusted dependencies so it interpreted it as writing everything itself). Seems these systems are always trained to produce the desired output but I think it's very difficult to get training data that teach the systems how to keep the code maintainable when making hundreds or thousands of such individual edits. Honestly not sure if that will get better fast, so far it seems not!
I guess there's no reason to believe these models can't be as smart as a great software architect / engineer or team of such people that build an elegant and maintainable software solution over many years together based on customer feedback, then again the models are appallingly bad at some forms of reasoning, I mean they will "understand" something once you make them aware of it like e.g. a flaw in the software architecture, but when asking them to audit the code and check for issues they will often have a blind spot to finding such problems. It's interesting, like they have very high ability but very little awareness or self-directed thinking outside of the prompts they receive.
They're getting a bit better at coding. My prediction is that by 2029, they will be noticeably considerably better at coding than they are today. That will include them becoming less myopic.
I experience all the same issues you mention. I am just predicting where the ball is moving. In the scheme of things, LLMs have been useful for coding for, what, like... 1.5 years??? What other technology has ever existed where people expect it to go from "just came out" to "changes everything for everyone" in 2 years?
In the arc of history I see us at the very, very early stages of AI-driven software development.
Forgetting about AI for the moment I do like this paragraph very much:
> The proficient developers, the experts, rely on their intuition built with sweat and tears, working long hours trying to debug and fix production issues, swearing to never again be so foolish as to repeat past mistakes. It’s the kind of intuition that can’t really be made into a list of rigid rules, because everything is context-dependent. Experts are incompatible with the same rules and recipes that make beginners more productive. Experts don’t follow the rules, they make the rules.
.... because I have found the same thing - that there's nobody more zealous about some paradigm than those who are recently converted to it and who haven't come to find that everything has its trade-offs. Design is always about evaluating the trade-offs and seeing which ones most suit the given situation.
> AI isn't good at software maintainability
We're a few years into a new technology that is still improving. This is a point-in-time critique.
For this to work long-term there has to be continuous improvement.
My belief is that paying off tech debt requires a better model than creating it. At the same time there are people who will create tech debt no matter the tool.
Should the models stop improving, the debt will pile up.
I did hear an argument a couple times saying "this is messy now but a newer model will come and clean this up in the future", hope it's true.
I predict there's always going to be a Wirth's law or Peter principle of slopcoding — it will always be easier to tack on a new feature than to understand a whole system and clean it up.
Alternatively stated: codebases will expand to the limit of an organization's ability to manage them, so the equilibrium will remain at the point of near, but not total, incomprehensibility.
It's not true, a newer model can do better to clean things up but you can't brute force engineer your way out of a shit design.
It's definitely true. I didn't use AI at all until this January because the code it wrote was too bad. Now I'm comfortably using AI for less important programming tasks and it's okay as long as you steer it carefully. I see no reason why it wouldn't get better up to a point that AI written code is better than what any human programmer could produce. It's also constantly getting better at refactoring.
I don't see context size improving.
It was mostly 256k, then it went to 1M and now it has stalled there.
2 years away:tm:
Also AI is fine at creating maintainable software, you just have to nag it to and not accept its first attempt at it, and subject it to peer review. This is plenty similar to human developers.
It creates maintainable looking code that will not stand the test of time.
Some humans don't even manage to do that.
Yeah and they’re typically fired for incompetence, or their startup fails, or their product flounders but that’s okay because the company doesn’t need the product to actually be successful.
Meanwhile, the people who work on actual products that matter have a valid criticism that can’t be dismissed with “some humans don’t even manage to do that.”
The dirty secret is there's a lot of people employed to do things that are not "products that matter" according to your definition.
Yes, including myself in the past. I’m grateful to be out of that situation.
Probably a vast majority of software written never actually gets interacted with by a user. A vast majority of VC-funded software probably never gets interacted with by a user.
Feels pretty great to work on a product that actually has a user, and that user isn’t actually the product (and that user isn’t being manipulated or exploited). Tiny, tiny minority of the software industry I work in.
That does not sound right, I would guess the most code is in enterprise and business applications and people have to use it no matter how bad it is. I would guess only a tiny fraction of code - besides hobby projects - ends up in the trash without ever having users.
I’m coming from the angle that the majority of software written is internal or B2B rather than B2C, and that most critical B2B software features are hammered out in the first couple of years of development while the remaining development cycles are for niche requests to maintain specific clients who don’t actually know what they want and then don’t end up resubscribing / even using the feature.
If you don’t think about it as a per-software criteria, but per-feature criteria, the vast majority of software features developed are probably completely ignored or even untouched compared to the “critical few”.
Very, very long tail distribution. The most executed 100 lines of code (maybe some Java class init snippet, or some Linux kernel snippet) is probably executed more per day than the per-day bottom 80% of all code combined. Maybe the bottom 99.9% of all code combined.
But that is generally true, most things in the real world have a few common cases and a lot of rare exceptions, so every software dealing with the thing will have a hot path and many additional paths that are rarely or maybe never executed. Or look at large applications like Excel, Photoshop or Blender, they have a million features but most user will probably never use even a single percent of them.
If you would fire all incompetent [1] software developers, there would be almost nobody left.
[1] There is probably a more fitting word, I am just reusing incompetence here, but that is not a really fitting description, I think. I would maybe say carelessness or something like that, but a single word is not going to capture the issue accurately.
Same with pretty much any other profession. Hunting for reliable and reasonably-priced HVAC, plumbing, handymen, etc. is a part-time job.
But the point OP was trying to make is that because LLM harnesses output code that is at least better than the worst, say, 20% of developers then we should be fine with it. Meanwhile, I’ve worked in shops where you have to be way above the worst 20% in order to keep your job or even be hired in the first place. And it isn’t some crazy lose-sleep-over-it, stressful requirement. It’s just that literally if you’re not good enough your work will be identified as a liability and you’ll be let go. It’s only happened to 3 people fwiw.
I think crappy code that looks like crap, is better than good looking code that is actually crap if someone cares to look..at least it can be fixed early.
LLMs commit crap, and read the "pattern" back, and consider it as gospel and repeat it all across the code base...
Why would I want to nag it and do all that when I could just do it correctly myself in the first place?
That's like asking why senior/staff engineers tend to review more code than write themselves. In certain environments there's a scaling constraint, and you can generally have wider impact through oversite than typing at a keyboard yourself. That's not to say one is more worthy of your time or not, just that it's not unique to AI.
Generally though, you are also investing your time into leveling up junior engineers to take over responsibilities from you. I just never really see that happening with AI. Even as it gets "better" technically, there's no real growth pattern to its work and it doesn't understand ownership or responsibility.
But if scaling isn't a problem, then sure just write it yourself.
Same reason you’d hire engineers rather than expecting the CTO to do all the programming?
It doesn’t take much effort to setup cross-agent reviews and automatic reviews for slop and accretion, while directing design decision questions back to the human to consider. I have had a considerable increase in throughput of code that I designed and made the important decisions about, and that I’m pleased with the quality of, although as always in these discussions, someone will be a long shortly to tell me that that implies I must be a terrible engineer.
But people don't use AI the way they use human beings because it's a technology and it's being consistently overhyped by its own makers as superhuman intelligence
Nobody does this though, that’s the problem. If most people don’t use a tool the “correct way” at what point do we blame the tool?
For starters, LLM’s need to stop being our friends. But that won’t happen because the dopamine loop is baked in on purpose.
>still improving
Mostly stalled now...
Expecting big progress to be made every month is a bit silly.
If the models are as capable in a years time as they are today you could say they have stalled.
Improvement can still be happening, and it can be happening slower than it was a year ago. Both can be true.
And the observation that it's happening slower than it was means, not that it's stalled, but at least that it's not exponential anymore. The exponential phase is already over. That has implications for where we think the plateau is likely to be.
> Fact is, vibe-coded projects devolve over time into an unmaintainable mess.
Is it a fact though? Maybe my projects aren't ambitious enough, but about 6 months ago I stopped hitting the point where AI can't maintain what it has written. It's probably unmaintainable by humans, but that might be an increasingly irrelevant quality.
the thing is.. the author says all vibe coded projects devolve into an unmaintainable mess, well so does all software, I have never seen any large scale software project that was absolutely beautiful over time, at least not in gaming and enterprise
it just doesn't happend, too much time pressure, and low-hanging fruits must be had, money must be made, and so it goes... that begs the question, if most enterprise software and/or game projects are an unmaintainable mess, yet they still make money and "work" somehow, whats the value in "beautiful" projects/architectures/code over time, if it provably works either way?
One thing I think it’s still easy for a human to beat AI at is a good PR summary.
They are often too verbose, or miss capturing an important concept or purpose, or add bullets for parts of the changes that no one cares about.
I love when I can reason about and follow the LLMs' output, when I learn from it. I hate when it makes me dumber and less efficient.
> and let’s be honest, most code in the wild is pretty bad
Most code in general is bad by some metric, and likely many metrics. Let’s not pretend that closed-source, in-house code is better.
> There is no fitness function you can define for maintainable code, at least not one that we can discern, otherwise it would’ve been baked into our linters.
This is emotionally appealing because it tells me that my judgement is irreplaceable. But it’s also essentially an appeal to magic. A metric than cannot be defined is either not real or is a matter of taste. And maintainability cannot be a question of taste because it makes concrete claims about the software, not just human perception of it.
All this is to say that we have yet to establish that “vibe-coded projects devolve over time into an unmaintainable mess” is a fact, or that it’s more true of vibe coded projects than hand coded projects. We are still learning how to build the right guard rails on vibe coded software because previously we relied a lot on humans reasoning over the code and saying “this looks about right” which frankly is not a strong engineering practice to start with.
Hard disagree. Usually I am wiser than the AIs but there have been times where the AI has pushed back and made me see the light on some poor design I was about to pursue
Sometimes, a rubber duck is good enough. But sometimes, you can benefit a lot from a rubber duck that can say "actually, your entire line of reasoning is wrong". Even if the latter is more frustrating.
Its not a rubber duck anymore when it talks back to you.
I think the issue here is the nebulous definition of vibecoding.
You, as an experienced engineer, are doing a lot of hand holding and review of LLM-generated output, maybe even(?) using it as purely a check on your own work. There are others, though, that are essentially outsourcing the entire process to a basic, underspecified chat prompt.
It's a mix. There are some projects where I let the LLM mostly run free and I focus on architecture. Even through some scary parts. Recently I picked a parallelization scheme for this and let the LLM cook. I have no idea how it implemented it, except that it (supposedly) "does it the way I asked:
https://github.com/ityonemo/bpa
For my projects that I use day to day in prod there is considerably more hand-holding and code review.
Honestly, I'm not clear where the line is as far as what is reasonable, and it seems to me that no one is really addressing that question. It's easy to wave your hands and say "vibecoding is bad", without really defining what vibecoding is.
I suppose it'll be a few years before we see the true volume of technical debt catch up with the worst offenders, but even then, without the original LLM conversations associated with it, it'll be difficult to assess that in a structured way. Mind you, that doesn't even address the ever-improving models.
We are teaching machines to do the work.
Capital always prefers machines.
I'm not quite a doomer. I use AI every single day. I also take a fairly negative view of AI generated code, but I think it's unavoidable while remaining employed these days. A fact I find pretty depressing.
I absolutely agree with the author that humans need to be in the loop reviewing and understand the code they're merging, and generally take a "Hey, build X like Y utilizing Z" approach when using AI to build instead of the "Hey, solve this problem" approach. Our PE overlords actually mandate the latter, but I'm not doing it.
However, a point the author misses is that with AI, major refactors become relatively quick. Hours instead of months/years.
Yes, AI can and probably will land you with major foundational and architectural problems, but your architecture isn't set in stone anymore. Your entire codebase bends like a leaf in the wind.
>major refactors become relatively quick. Hours instead of months/years..
This will probably maintain the problem in a different form.
Yep great point, it works both ways. It can dig you a hole faster, but also help you get out of it with less effort.
Yes but if you don't care enough to think about, analyze, and decide how to improve your architecture, it doesn't matter. And I'm seeing that a lot with full vibe code code bases
Yes, and I'm arguing you can absolutely vibe code your way out of a corner you vibe coded your way into. Especially with enough vibe coded functionality tests. Your codebase is entirely mutable soup.
Caring about the architecture only matters if you intend to build on top of it, where it become hard to mutate for needs. Big refactors are quick and (relatively) cheap if you don't care about the code.
Don't get me wrong, I am not in any way a fan of vibe coding but the "you're going to vibe code yourself into a corner you can't get out of" argument doesn't hold water.
> you can absolutely vibe code your way out of a corner you vibe coded your way into..
Yea, probably with a more expensive model.
> I'm no luddite, I’ve integrated AI in my everyday work, while actually teaching my colleagues what I’ve learned
It's appalling that we still hold on to such things that are no longer necessary. Code maintainability is not a problem when you don't have to open a file and inspect how something works anymore. You use english to add to it. You sit on chairs everyday where you don't give a shit how they were created. They fulfill their purpose. hopefully the same can be said for your software.
> You sit on chairs everyday where you don't give a shit how they were created.
I am dumb on chair making, as the average chair user. I wouldn't trust myself building a commercial-grade chair.
If you are as dumb with software as I am with chair making, you should refrain from building software for others. This is regardless of LLM.
> Code maintainability is not a problem when you don't have to open a file and inspect how something works anymore. You use english to add to it.
Hilarious and unhinged junior dev and/or outsourced dev and/or expert beginner take here.
Not everything is baby's first React app for an internal business or B2B SaaS startup with 3 users. Sometimes your software is actually used by people, and bugs happen, and you need to figure out why bugs happen, and quickly. You do this by reading the code. Yes, AI is very helpful with this--sometimes. But even SOTA agents cannot solve every bug, particularly when the person directing them has no clue what they're doing, as in your case, so they aren't given good constraints or starting points.
>It's appalling that we still hold on to such things that are no longer necessary. Code maintainability is not a problem when you don't have to open a file and inspect how something works anymore.
Even if you never read/write code anymore you still need to care. LLMs also suffer from a bad code. LLMs very quickly lose track of their own shit and start producing more bugs.
What exactly is appalling? Are you referring to something in the sentence you quoted?
So have you never had a problem the LLM couldn't solve? What do you do in that scenario?
How do you guide the LLM away from making a horrible choice if you don't understand the internals?
I do not think, the intention in using AI, will ever be gaining wisdom. It is rather moving computations to a larger computing system.
you don't need to read or write code directly to prevent it from becoming an unmaintainable mess. they way you prompt, the loops and skills you build for your harness and the way you set structure around it can get you most of the benefits of reading & writing code manually
Here's the one simple trick that fixes everything:
- Use the code that your agents write in anger.
There you go. Do I know when my agents fuck up? Yes, I absolutely do -- because I'm a user of the code I have my agents write, and I ask things like "why is it taking 50 ms to start this program ..." and then I go in and find stupidity, and excise it. I do this over and over again.
Is it faster than writing it out by hand? Maybe! It's definitely a different perspective.
Start behaving like a baby "why, why, why" and then do a bit of reading, and you'll be fine.
A lot of these blog posts seem like they're aimed at software written by B2B companies who don't even use their own software ...
AI labs should produce AI that can take support calls. But let it stay away from the fun jobs like coding.
I personally loathe interacting with AI support
"New technology: cool but the supply chain is vulnerable". A tale as old as time.
"There will be consequences"
And, so what? Software as an engineering discipline has long lacked standardization and regulation to be on par with other engineering disciplines, and the fact that code and all its surrounding ecosystems are not "visibile" or "malleable" makes this extremely hard.
You can use terraform and yaml to define infrastructure that literally spins up machines _somewhere_ in the internet. With all its issues, bugs and associated consequences mostly being ignored.
I just don't understand the difficulty in KNOWING what needs to be done: NO LLM usage in university/grad/high schools, NO LLM usage in the first 3 years of your professional career.
Once the basics are solidly grasped, then they can use it at will.
The problem has never been about wisdom, knowledge or LLMs writing good, bad, maintainable or terrible code. It has always been about the skill level of people using it AND on the fact that people start off-loading basic things to these models that they wouldn't before.
If you have the knowledge and "suffered" through experience to learn the fundamentals, than not using LLMs becomes more deterimental than beneficial.
You just CAN NOT skip the trial by fire of learning and absorbing knowledge on your own. That's all.
> No LLM in schools
The only plausible thing to enforce in practice is "no LLM usage in tests", ie using pen and paper or a fully managed digital device.
This is one of those predictions that sound very wise and do well on Hacker News, but will turn out to be completely wrong. For the simple reason that we’re basing all our assumptions on decades of learned behavior predicated on coding being expensive. Writing code has historically been expensive and, by extension, so is maintaining it.
But when you can literally generate a whole codebase in a few hours, a lot of these assumptions don’t hold up. That doesn’t mean you don’t need sound logic and maintainability. But a lot of the small things you think would go wrong because of a bloated codebase stop being meaningful objections when you can keep generating, testing, and reworking it until those issues are resolved.
A lot of what we consider good engineering judgment is shaped by the constraints we’ve always worked under. I don’t think people appreciate how much of that changes when those constraints go away. The "slop" problem is ultimately a verification and testability problem.
Nothing new to read here..
HN is on a comical doomer binge the last couple of years.
A book that has shaped my thinking on AI, and much else besides, has been Horkheimer's Eclipse of Reason.
This book gives a conceptual groundwork for what I believe to be both the promise, and crisis of AI. AI excels at, and either will soon or already has surpassed humans at a kind of reasoning that Horkheimer calls "instrumental reason." This is reason as a tool for achieving ends. AI will, I think, surpass humans at writing maintainable code, as this falls within that domain. The writer is thoughtful, but the obstacles listed in the article are technical, and they will likely fall.
A second kind of reasoning, which he calls "objective reason," is reasoning about which ends are worth pursuing. Our contemporary pragmatic, positivist culture in the West has a hard time reasoning about ends. We tend to just see different perspectives, competing power networks, etc. We are skeptical of capital-J Justice, for example. We tend to see it as historically and culturally contingent, or else as a mask for powerful interests. Horkheimer believed this learned relativism was responsible for new forms of domination and control that emerged in the 20th century in both totalitarian and putatively free societies.
I think the author's thesis would be correct if it had focused on AI's inability to discern ends. But that then raises the question: can we discern ends? Horkheimer never settled on a way to rehabilitate objective reason. He focused on critique, and his critics suggest he ended up with a tangle of negations that couldn't hold up any objective ends. I think rehabilitating objective reason is the task that faces us whether we like it or not, given our moment in history with the advent of AI. It's something practitioners need to think about. Either we recover the philosophical tools of objective reason in light of the critique which caused them to be discarded in the first place, or ends will be imposed arbitrarily by any and everyone with the means to do so.
In traditional software development process two artifacts are created. The obvious one is software. The second, is knowledge of the problem domain in the development team heads.
We could take the Hofstadter idea and say that there is an isomorphism between these two artifacts. Software is a manifestation of the team's knowledge the way an organism is a manifestation of a genome.
With AI, the second artifact is no longer necessarily produced. We don't need to have a team that, as the project progresses, slowly becomes a group of domain experts. Experts that can drive the project direction. Experts that, with time, can see the flaws in their first project and start new breakthrough projects to fix these flaws.
We should start building our Dyson Sphere now because the only solution to bad computation is more computation. Evolution through competition is the only way forward I see. It won't necessarily improve human legibility without feedback, though. And in the end, we can't care TOO much about legibility.
Imagine breeding a new tomato plant. One is robust and tasty, the other is neither, but the genetic code is easier to understand. Picking the legible plant, because legibility is important to you, and may make future tinkering easier, is a dead end. Being able to create a billion different tomato plants and applying selection pressure is more effective, if you have the resources.
The idea that we are applying all this effort to make creating nauseating ads and heinous travel booking sites easier disgusts me, but hey, whatcha gonna do?!? :-)
> The AI learns rules from rulebooks meant for beginners.
Source?
I think at the end of the day, it is not impossible to have AI write "good" or "high quality" code. If anything, once the patterns are established, AI will be more likely to adhere to the patterns and rules than any human team. It requires the most experienced engineers on the team to split their time writing the core patterns and documenting them in references/skills.
But it takes a lot of "taste" and a willingness to slow down a bit with AI (to create necessary artifacts), something teams find hard to do when you can ship so fast now.
My experience has been that there is a camp of very senior engineers that are unwilling to adapt to reality and focus on documentation and writing (effectively producing skills and agent guidance which multiplies their effectiveness); they will cling to their knowledge thinking coding a sacred art.
> Sad to say, but this is no different from human written code.
I don't think so. It's true that human also write shitty code but the key difference is we actually remember what is the intention behind those crappy implementations so someone can fix it later. aka it is the matter of long term memory that currently LLM architecture is not capable of.
You can argue that claude can read the whole linux codebase and report bugs, but they can only report local bugs, not systematic one. 1M context windows seems like huge, but the effective range is actually pretty limited, and it still does not equal to human insight.
Code comments are line-of-sight for agents and one of the cheapest, highest leverage ways to get better coding performance from AI because unlike skills that may or may not activate, comments end up in context as long as they are well placed and carry the right instructions.
Best places to have it leave comments: 1) start of the file because it frequently uses `sed -n 1,200p` to read files and 2) inside the body of the method because it may find by keyword and read a few lines past. If your harness is set up with an LSP, language standard comments are also useful because then it can read comments on the member.
Tips for comments: point it to other, related members or artifacts; point it to external canonical docs; point is to a specific issue number or PR; have examples directly in the comment using your language's example markers; point it to example, reference usages in code. Use AGENTS.md to tell your agents how you want it to leave comments and to specifically read, follow, and maintain comments.
You don't need infrastructure or special architecture; Every coding agent is text-in, text-out. You need comments that get carried with text-in and a bit of guidance to the agent on how to use comments effectively.
No, developers definitely do not remember what they did two months ago. If you are busy, even two weeks is a problem. That is why we discuss documentation so much, self-documenting code, tickets and tests.
Well, and "intention" is a mine field of its own.
I've seen LLMs "connect the dots" across complex systems many times before. When it works, it's shocking how quickly it can pin down a bug that spans across the software stack.
1M context window is plenty. Once it's skimmed the code and come up with a theory for the problem, it can spin up a subagent that has a whole fresh context window and it can dedicate the whole thing to that one hunch.
To me the difference is humans (ideally) will learn when they build something in a non-optimal way, and so will improve over time to become a competent engineer / architect. We cannot be perfect but to me a huge part of life is learning from failure and improving yourself, something that LLMs short-circuit and cannot replace.
LLMs cannot truly learn and so are destined to produce whatever the "average" software looked like at their training cutoff, or worse to produce code based on _other_ LLM generated code.
Ouroboros eat your heart out
LLMs learn, and in two main ways: in-context and in training stages, release to release. The former is quick and sample efficient - perfect for adjusting AI behavior on the fly, and for enabling AI's own problem-solving capabilities. The latter modifies the "behavior defaults" and gives you performance gains that stick.
Why do you think that "write maintainable code" is somehow impossible to learn for an AI? We already have AI storming the frontiers of research math - way beyond the "average" of the field. If you can RL for "better at math", I see no reason why "better at maintaining code" would be somehow impossible.
You can construct an RL env where a codebase is presented as a "tree", and the AI is given one change to make at a time - and the per-change reward is not just whether the change itself has been evaluated as "made successfully", but also whether it made future changes down the line more or less likely to be successful, and harder or easier to make.
This is a formulation already used by some "maintainable code" benchmarks, so I expect something like it to make is way into frontier lab RL pipelines some time between "next week" and "a couple months ago".
While I mostly agree, I think this is something we need to assume the Pareto principle applies to: likely 20% of humans will improve but 80% will not.
Yes, "code rot" is not in any way an AI-unique problem. Codebases like Flash Player or Bethesda Engine have been deep in decay long before AI was capable of contributing to them.
Historically, this was caused by hiring the cheapest developers one can find, having high turnover, outsourcing, pushing to ship at any cost and more. AI just lets you get there faster, and without having to hire bargain bin Indians.
The thing is, today's AI is already far better at "code rot per feature shipped" than the worst of developers - and I struggle to believe that we're at the limit there.
I've already seen benchmarks that test for AI's ability to make incremental changes and tweaks to code continuously - thus, tracking whether earlier changes make the latter changes harder. This makes for a clear target to RL for.
AI is not better nor worse at producing code rot; just faster at it.
AI produced code is a function of the team driving and instructing the agents along with the scaffolding produced by the team (skills, examples, docs, comments); same with human teams.
A team that cannot guide a human team to produce better code will not be able to guide an AI team to produce better code because it's the same skillset: being able to write good docs, create constraints structurally in code, produce core architecture that enforces good behavior.
Not entirely wrong, but there's a very big hole: "the scaffolding produced by the team" also includes the scaffolding produced by past AIs.
An AI that knows how to keep the documentation accurate and up to date, and does it by default, would, all other things equal, rot your codebase less. An AI that changes the code without checking whether it obsoleted a bunch of examples in the docs would rot your codebase more.
While I think that you can reduce "AI-induced code rot" with good prompting and steering, you could also make headway against it at model level, by making the AI "well-behaved" by default.
Better yet, extract docs from code comments. Even better when the docs are spatially co-located and line of sight as the agent crawls through code.
> Human written code just takes even longer to realize the mistakes because the pace is slower.
Yes but the ceiling is still higher, and that's the author's point. If you vibe code, without code review, code becomes a mess quickly. If humans write code by hand, then this is often the case too, but crucially, this is not unavoidable. Sure, most codebases are a terrible mess, but some are not. AIs unfortunately got trained on all of them (+ reinforcement-learned stuff) and therefore their quality standard is about as low as that of the average codebase, ie pretty damn bad.
But there are plenty examples of acceptably decent yet long-lived codebases, both in OSS and inside companies. You simply couldn't get that quality by vibe coding. (unless you review every line of code and every design decision, at which point you're about as fast as you would be writing it all by hand, assuming some seniority)
>Sad to say, but this is no different from human written code. Human written code just takes even longer to realize the mistakes because the pace is slower.
I really don't think so, poor written human code IME is rarely overly complex, where as the AI code is almost always vastly over complex. Naturally complexity can be an issue because it leads to more surface area for failures and challenges to diagnose, but where I am REALLY seeing an issue is the complexity hiding an issue. Something that should normally fail or produce an error is covered up by something multiple layers deep in the code that returns an incorrect value instead of an error when something goes off the rails.
AI written code is a function of the human created constraints around it.
That is why I believe the most senior engineers on the team with the most scars and most experience need to shift into writing those constraints instead of writing code.
In writing those constraints, they can multiply their effect across a tireless fleet of agents that generally want to copy existing patterns and can be guided to use skills.
Taste and smell still apply. You have to know the art and have comparative priors in order to judge the output.
> Sad to say, but this is no different from human written code. Human written code just takes even longer to realize the mistakes because the pace is slower.
When the pace is slower you can notice mistakes earlier because you have time to reflect. It also allows you to detect when it’s becoming hard to maintain and you can correct course, rather than after it has become an unworkable mess.
There is no team without tech debt because there is no "golden" project where every decision has been made right because of reflection on decisions made wrong.
>It doesn't mean that people do.
After a certain point, people would be forced to refactor, because they find themselves unable to handle the complexity.
With LLMs, there is no such friction. So the complexity get piled upon complexity in the form of a million best practices that is indiscriminately followed...
>They lack the tests to verify it, the person that wrote it is long gone, it's handling some mission critical dataflow so no one touches the code and just builds around it.
What you say here is not always the case.
I formulate this idea as "Clean code never survives first contact with users"
> Fact is, vibe-coded projects devolve over time into an unmaintainable mess. The reason is simple, yet hard to fix: code maintainability and good architecture don’t have good measurements that we can apply, because it takes months, years even, to notice the effects of bad architecture or of unmaintainable code.
False. AI is evolving by leaps and bounds and the outputs are better and better by the day
Personally, repeating what the article says, I haven't coded since may 2026, not a single line, and AI has been delivering exceptional results, improving by the day
Any AI related article necessarily needs to consider future improvements as they will come not by surprise but by steady refinements, and posts like this will look just like the same early AI slop they complain about
Coding IS solved
> I haven't coded since may 2026, not a single line, and AI has been delivering exceptional results
The world will always have people whose coding skills are beaten by a chatbot.
> Coding IS solved
You coding is solved.
Will be downvoted for sure, but here we go:
They can't think that a software can be written, designed and maintained in English or higher constructs.
It is binary of either vibe coded app, or worshipping the code that they worship (and I spent 20+ years on)..the industry is moving on faster than most can wrap their heads on, but for those who understand software engineering was always beyond and above code, they will adapt, meanwhile, those who built their entire identity and skillset around managing code will struggle. There will be a place for those people, but it will be niche and specific, and we won't need as many.
> it takes months, years even, to notice the effects of bad architecture or of unmaintainable code.
I think this is a bad take... if you are going that long without noticing, you are (hopefully) delivering end user value all that time. That is the main driver of code. You can normally dig/hack/rearchitect your way out of an ugly code situation. If you've been building value for the last year based on the hacky code, that's a win.
I think this is a form of path dependency. We talk about unmaintainable messes, but honestly, if you look at Kairosoft or famous game codebases, you'll find 30,000 lines in a single file or just completely chaotic code. I am actually in a position where I see bad code all the time.
The truth is, "good code" is relative. It is determined by the specific domain and the composition of the team. Is incomprehensible FP (Functional Programming) code good? No, it isn't. A programmer must assess the team's capabilities and adapt accordingly. Good code is ultimately something that morphs based on the shape of the organization. Once defined this way, good code might share certain commonalities (like readability or a shared mental model), but its actual form varies wildly.
So, what is good code? That definition is missing. To be blunt, the Hacker News posts insisting that we must write "good code" are essentially a form of self-hypnosis.
Just look at paradigms. The mechanics of OOP have changed significantly, FP approaches have evolved, and DOD or DDD are fundamentally different from their early days. Whenever paradigms are discussed, someone claims, "That problem was solved in the past, and nowadays we do X," only for someone else to reply, "I don't think that's actually solved," leading to a fragmented breakdown in consensus. Ultimately, which knowledge remains as tacit knowledge is entirely dependent on the organization's capability.
You could argue that AI is terrible at simplifying code. However, I am skeptical that AI coding needs to be identical to human coding. When you actually code with AI, it often produces structures humans would call anti-patterns, including God Objects. Yet some of those structures can be faster or simpler for machines to navigate. There is no reason to assume that the optimal modularity for AI maintainers must be identical to the optimal modularity for human maintainers.
Of course, I am not denying that the rewards of good architecture are delayed, or that there comes a point where maintenance becomes impossible. But as the AI era ushers in an age of overproduction, software could become disposable, strictly personal, highly tailored to small niches, or ultimately, heavily polarized.
Realistically, programming domains fall into two major categories: "ship it and forget it" (one-offs) and continuous services. I agree with the OP's point that AI struggles to understand boundary delineations. But honestly, you can enforce those boundaries by injecting them into the spec. How those boundaries are drawn in the first place, however, is purely a matter of personal experience.
Personally, I define "good code" as code that allows the entity responsible for the software to achieve its purpose with a sufficiently low cost and error rate, factoring in the software's expected lifespan and future changes.
If you ask an AI to generate work based on this standard of what level of code is "adequate," you might get entirely different results. The biggest problem with discussions around AI is not just that ideological identities prevent proper evaluation (as seen in that article), but that the AI itself scales proportionally to its input. It is an incredibly difficult issue to judge because you don't know an individual's workflow or exactly how they are utilizing the tool.
I do think the value of reading code is important. However, much of what we are discussing in the AI era is actually rooted in the path dependency of how to become a good human senior developer.
Instead, the core focus of AI-driven development might shift toward defining broader abstractions: data semantics, invariant external contracts, and migration strategies.
Ultimately, I believe the paradigm shift of our era should lead us to ask: "How do we write code most economically in a system where AI is the primary maintainer?" The OP might think differently, but at least, that is where I stand.
I have more than 15 years in the industry. I have worked in some of the most horrendous codebase someone has ever conceived. Honestly? Humans can do worst than AI.
Let's stop overvaluing human work. Sure, I don't want AI to write the entire codebase without I know what the fuck it did.
But AI is on an equal footing with an average dev.
I promise you no one in this industry is overvaluing human work.
> "except that the software industry is special"
This is the labor theory of value; consumers don't care if the code is hand-made, they want the cheap goods (software) that are the output.
We already have a no-LLM policy where I work, and we're moving faster and delivering bigger features than ever.
Little boxes, little boxes, little boxes made out of ticky tacky. Little boxes made out of ticky tacky and they all look just the same.
The agents are trained by contained data. All agents. Similar data sets. Human knowledge packaged into little boxes that all look just the same.
When the boxes are doing all the work for us, the differences between them will come down to color.
There’s yellow ones, and blue ones…. And, they’re all made out of ticky tacky and they all cost just the same…
> because it takes months, years even, to notice the effects of bad architecture or of unmaintainable code.
Well said. The cost of bad architecture imposes a heavy penalty on the project down the line.
> The proficient developers, the experts, rely on their intuition built with sweat and tears, working long hours trying to debug and fix production issues
Long hours of grinding with the problem, the solution, the code and the machine all makes for an intuitive understanding of what a good architecture is in the first place.
LLMs are a tool. A useful tool unlike any we have seen so far. But still a tool. Treating it as such and leveraging it should be prioritized.
The entire field of software engineering has plenty of depth without requiring you to be the person actually writing and reading the code. The author falsely conflates reading and writing the code to be the same as understanding the structure and design and architecture of the system. These two things aren't the same and never were.
There is a cluster of users posting nonsensical AI-hate articles such as these.
The deeper issue is American business culture.
Everything is reactionary. The focus is always on short term profits. No one cares about long term effects --- until they start impacting short term profits.
This is an inherent vulnerability that is easily exploited by someone willing to engage in some simple, long term planning --- like China has already done with manufacturing.
For decades, the USA gladly shifted manufacturing to China without a second thought. Now, we lack the expertise to make our own and have no choice but to use China.
Replace "manufacturing" with "software" and "China" with "AI" and it's deja vu all over again.
>vibe-coded projects devolve over time into an unmaintainable mess
The author seems to be confusing "I didn't write any code" with "I don't care about software design and maintainability". There exist maintainable and thoughtfully designed software systems for which the designer did not write any code and didn't read most of it. It's not the median, but the median software project has always been unmaintainable before agents.
Sure but many many developers who are willing to outsource every modicum of thought and effort to AI don't care about design and maintainability. And the supposed "super intelligence" of AI gives them a cop out for that
Absolutely! How did we get horrible code in the past anyhow?
AI's wisdom has been shown empirically by solving Navier-Stokes. Pay more attention here, please. Things are moving very quickly.
Those people will never reach mastery, because they no longer make choices, they no longer take responsibility for mistakes in coding and no longer learn from those mistakes. It’s the AI that’s making mistakes now, the AI doesn’t learn from those mistakes, and neither are the people relying on AI for coding.
Just to give a hot take, it's funny to look at his builtwith.com. As a developer you have a static site that depends on Cloudflare, Mailchimp, Postmark, Isso ...
Twenty years ago any self-respecting dev would have run the equivalent of all that themselves on their own metal. In 2026 elite neckbeard practice is write the "never reach mastery, because they no longer make choices, they no longer take responsibility" post, hit "publish" and it's magically deployed around the global internet for you. Like a child.
In the future we will see more and more companies proudly boasting their “NO-AI” policy as a competitive advantage. And they will be right.
Yes, a "NO-CLOUD" policy was already so popular, surely this will happen too.
https://builtwith.com/alexn.org
I agree with this title, but not the argument.
The argument I'd make in support of the title would be that wisdom is embodied knowledge - knowledge earned from direct experience. Known first-hand. An AI can already have linguistic/technical ability that exceeds a human (at various levels of skill, even) - in coding, copy-editing, what have you. But wisdom? That is the scar tissue we carry from wrong choices. Until an agent has persistent sense of self and a "body" (or pseudo-body) whose existence it is predicated on (thus creating incentivization/outcome alignment), it will not be able to approach "wisdom" in the sense that humans do.
That may seem to have no bearing on the specific subset of tasks related to coding and so on - but it actually does. Humans have a hard limit of attention span, hours in a day, years in a life. An AI does not. So if it fucks things up royally by half-assing an architectural decision, it won't care. And if it doesn't have a persistent memory, it won't even know that it made that mistake before. So it has neither the prerequisite abilities nor the incentives to gain what would be hard-earned wisdom from its mistakes.
In fact, as long as the business model of its creators depends on more usage = more profit, they are actively discouraged from implementing any kind of wisdom-like ability.
For them to be able to offer that without undercutting their profit, they'd need to be able to execute "outcome based billing".
A bit offtopic, but this seems to be an AI pattern everywhere:
>>"The AI learns rules from rulebooks meant for beginners. The AI notices patterns from code in the wild and let’s be honest, most code in the wild is pretty bad."
Similarly, for self-driving, the AI for driving learns from rulebooks meant for beginners and observes patterns of driving from ordinary drivers in the wild and let’s be honest, most ordinary drivers in the wild are pretty bad. The best the AI self drivers trained in this way can hope to get is the average slop driver minus the catastrophic errors.
Similarly, in legal specialties, there are a few highly expert and wise practitioners, and hordes of average practitioners, and quite a few near-malpractice practitioners, and it is the latter group who write the most stuff on the web because that is how they do marketing, trying to make their ignorance look better — and mostly louder — than what the average lay-person knows. The AIs can NOT tell the difference and 'learns', and dispenses both the good and the actively harmful advice. Acdg to relative who is a top expert in their specialty, AIs can both find key relationships between laws in complicated situations but also readily dispense the actively harmful advice, and you MUST already be a top expert to recognize which is which.
They are great averaging machines, but when average is not good enough, you must be on top of your game.
> Experts don’t follow the rules, they make the rules.
No. Most rules are there before and will stay after the expert enter the field within its career path, unless the field is bright new territory no one fooled before, which is rare.
Not only experts have to know the rules, otherwise they wouldn’t be expert, but good experts also ideally know why the rules were set, and at least have a fairly well aligned representation of what it would likely lead to to follow or not each rule in this or that situation, which rules are in conflicts and what the tradeoffs are when favoring one on the other.
Everything is context dependant, yes. And LLMs can help to leverage on far wider contexts that a single individual would be able to do on its own. It’s require interest to reach some goal in some social context, and not everyone will use LLMs with the same creativity.
This week-end I was discussing with a friend about our respective use of LLMs. At some point they told me they no longer read the MR, as LLMs can also do great job on that matter now, which is in sharp contrast with what I do. Not that I don’t auto-review with LLMs, but I use that as a first step, be it mine or some other colleague. And then I ask an LLM to prepare me a reading plan to check the MR, taking into account the activity scope and the implementation architecture. To me it was an obvious way to go, but for them it was something they never considered. That’s random sample, of course they would certainly be cases we would switch the "I wouldn’t have thought about it" role.
So yes, LLMs can be used to produce faster giant piles of unmaintainable codebases. Or they can be used to strengthen processes that lead to code quality. The nail won’t prevent us to knock our thumb, to use a nail in reverse side, or to smash our coworker.
I get the paperclip plant issue, but that’s some extreme scenario (which is of course the point of the allegory), and most bad uses will be far more mundane in how they look and what the consequences are. And most good uses will look more and more transparent to users to the point they won’t even wonder about it at each use. Like, most people open the tap, see water fall and they don’t get a sense of wonder, not giving a thought to this masterpiece of engineering and gratitude for all people that works daily in the shadow for this miracle to happen. They don’t leave the toilets thinking "how freaking amazing such a complex system of wastewater is something I can benefit from everyday, unlike so many other of the 100G humans that walked this earth."
Next time you go to WC or tap some water, think about it.
There are always new people to believe in the rules without question so rules survive.
Not all rules survive by this fact alone, which obviously is as true as the fact that there are people that don’t care about any rule and people that will deliberately break rule for the mere sake of the thrill. Rules can also stop being used, they can keep going on charming sufficient fan base willing to fight for their application in an environment which changed upside down and were every other new rules are directly conflicting with this old one.
I still can't believe that anyone who has used AI and understands development thinks that "No AI" policies are going to exist anywhere but the smallest of niches. Maybe they've been blessed to only ever work with the top 1% of the industry?
At this point AI is a better developer than most mid-level SMEs I've worked with. I hate this fact, but I don't have a shred of evidence to dispute it anymore. I work on a 20 year old codebase that thousands of developers use and it finds bugs in pre-AI code daily.
The LLMs are great for reviews. The No AI" policies would be probably restricted to coding..
Indeed - it's great at finding mistakes.
IMO reviews are more useful for communicating some change to the rest of your team so they can maintain it later than as bug finders. AI is better as a bug finder.
> In the future we will see more and more companies proudly boasting their “NO-AI” policy as a competitive advantage. And they will be right.
Counter prediction: using AI attractive even for employees. Do you really think you’d wanna join such a company? No way.
I would. I'm already seeing people label their docs etc. as not made with AI so someone will actually read them
too doom and gloom.
has the author not started to develop instincts with regard to ai usage and pitfalls?
apparently it needs spelled out.
you won’t lose your expertise if you continue to develop it, and blaming ai is like blaming macros or installers or…
the game hasn’t changed, really, but many are fretting that it has fallen apart.
Then you have to write code. Understanding without doing is not successful IMO.
Is that why you stated the first as a fact?
Writing code is like many things. One means of producing the output.
I might review a paper on Quantum Physics but if I don't understand it then what's the value?
Would you learn nothing from trying?
(In the future we will see more and more companies proudly boasting their “NO-AI” policy as a competitive advantage. And they will be right.)
dumbest take ever. AI is here and not going away, any company that does so will not survive or will be a niche thing for hippies.
It is not going away, just like OOP has not gone away..
> In the future we will see more and more companies proudly boasting their “NO-AI” policy as a competitive advantage. And they will be right.
i wouldn't know a single engineer who'd want to work at a place like that
I would.
As much as I agree with this article, I feel that there's a logical flaw here. The author admits that it's difficult to measure bad code - but continues with the assertion that it exists. If the only negative to "bad code" is that it's difficult to maintain once the author has left or difficult to refactor, then the question really is whether or not LLMs will continue to be able to maintain their spaghetti code.
Just because it's bad for a human doesn't necessarily mean everything will fall apart - unless a human has to maintain it unaided.
I think the key distinction is that it's difficult to determine whether a single commit or pull request is bad code at a glance, but it's easy to determine when the codebase as a whole has gone bad due to many low quality commits.
The latter often doesn't even require looking at the code, you can usually feel it just by using the software. From my experience, all software primarily written by AI is full of little bugs and inconsistencies that reflect bad code architecture (such as two very similar pieces of functionality in two different places behaving in wildly different ways, due to the AI being unaware of the first when asked to implement the second and writing the code twice)
I totally agree, and I agree with the article in general. I just don't think it follows that code that's bad because humans had to maintain it is necessarily bad by definition.
I've vibecoded loads of AI apps for myself and almost none of them are still in use. Not because I didn't really want them or they didn't work, but because the more I used them the dirtier I felt, as though I could feel the bad decisions and the bugs underneath just by interacting with it.
I think this kind of blog post reflects a fear of infantilization by AI. By asserting that only humans know what good code looks like, the author is attempting to mend his own ego.
Build the systems around the code and let the agents do their work.