AI Has No Wisdom and Neither Will You
alexn.org
alexn.org
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.
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 guess we were all lacking wisdom.
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.
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.
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.
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.
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.
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.
I believe this is what Socrates said (verbatim) about the invention of writing.
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.
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.
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.
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.
At the very latest, when "AGI robots" will be commonplace and taking on the most crucial labour on our behalf.
I wish more people would at least consider this idea.
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 just seems to me that fundamentally this is a knowledge organization problem.
“Any idiot can run a business, but it takes an MBA to run a business that barely functions.”
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.
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.
It's also very automated so the jobs went away, but the US continues to manufactures a lot of things.
You don't develop "institutional knowledge" from a few prompts. It takes years to develop them.
They took jobs that Americans would have wanted higher pay to do, higher benefits, higher safety standards...
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.
Maybe it will be no big deal, and nobody will read code anymore, but it is understandable why somebody might be concerned about it.
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.
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.
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.
"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.
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...
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
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.
> 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.
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).
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.
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.
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"
> 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.
Induction fallacy at its best
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.
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.
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.
Sounds like there is a compensation problem then.
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.
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.
SonarQube
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.
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.
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.
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.
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.
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.
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...
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.
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.
~41k SLOC, ~11k lines of comments
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)
This is the opposite of really striving to understand what your AI is producing.
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.
But why though?
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
lol
and 9/10 times project open source, project bad slop
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.
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.
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.
Economics depend on that a lot.
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?
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.
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.
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.
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.
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.
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.
Anyone could say the same about any post they don't agree with, doesn't seem very helpful.
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 my own prediction: this isn't going to happen
Just look at the growing gap in traffic accident rates between human and AI driven cars. Humans are losing.
"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.
See: https://www.smithsonianmag.com/history/what-the-luddites-rea...
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.”"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"
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.
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.
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.
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
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
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.
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.
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.
But reading code? What does that accomplish, other than to slow your dev process down enormously? Serious question.
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.)
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.
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.
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.
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.
"A Project must have proper tests and specs, and only incidentally for a working program that executes"
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.
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.
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'.
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?
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.
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.
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.
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.
It is perfectly possible to vibe-code a badly designed app that still passes those 12, 15 or whatever points you define.
This takes time away from implementing new features, but that’s true of all code health maintenance.
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.
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.
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.
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?
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.
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.
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.
"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?
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.
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.
>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.
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.
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.
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.
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…
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 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.
We're a few years into a new technology that is still improving. This is a point-in-time critique.
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.
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 was mostly 256k, then it went to 1M and now it has stalled there.
For starters, LLM’s need to stop being our friends. But that won’t happen because the dopamine loop is baked in on purpose.
Mostly stalled now...
If the models are as capable in a years time as they are today you could say they have stalled.
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.
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?
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.
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.
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.
Capital always prefers machines.
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.
This will probably maintain the problem in a different form.
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.
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.
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.
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.
How do you guide the LLM away from making a horrible choice if you don't understand the internals?
- 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 ...
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".
>>"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.
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.
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.
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.
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.
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.
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?!? :-)
Source?
> 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.
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.
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.
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
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.
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.
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)
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.
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
The world will always have people whose coding skills are beaten by a chatbot.
> Coding IS solved
You coding is solved.
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.
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.
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.
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.
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.
Counter prediction: using AI attractive even for employees. Do you really think you’d wanna join such a company? No way.
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.
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.
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.
has the author not started to develop instincts with regard to ai usage and pitfalls?
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.
i wouldn't know a single engineer who'd want to work at a place like that
Just because it's bad for a human doesn't necessarily mean everything will fall apart - unless a human has to maintain it unaided.
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)
Build the systems around the code and let the agents do their work.