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.
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 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.
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.
> 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 can do it better. That it's not yet solved by models suggests that it's not easy, maybe even not practically achievable with current tools. But that's not the same thing as not solvable.
The author admits to a measurement: maintainability. There are quantitative and qualitative ways to measure this, the biggest signal being outright abandonment
> 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.
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?
> 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 with 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.
> 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.
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 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.
> ... 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.
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.
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 has hobbies either productive or unproductive. I can't find the 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.
One way to get one's employees to care about the quality of the product they are being paid to build (for someone else's profit) is 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.
> 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.
> 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.
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.
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.
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.
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.
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.
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.
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.
> 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 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.
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
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.
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.
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.
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"
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.
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.
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.
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.”
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
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 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.
> 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"
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.
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.
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.
> 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.
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.
> 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.
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.
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.
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".
> 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.
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.
> 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.
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 ...
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 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.
>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
> 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.
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.
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.
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
Do not share videos with si parameters. It links together the accounts of the sender and receiver.
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.
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.
"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.
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.
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.
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.
Trends over time with 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.
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.
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.
This is exactly what I said in my top comment. This is a huge problem.
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.
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.
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
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 has hobbies either productive or unproductive. I can't find the question.
Sounds like there is a compensation problem then.
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.
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.
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 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.
You might write good, maintainable code, but they will prefer the slop generator who delivers quicker.
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.
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.
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.
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 post to combat the AI influx of 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.
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
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.
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.
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.
But reading code? What does that accomplish, other than to slow your dev process down enormously? Serious question.
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.
Source?
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.
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.
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.”
LLMs commit crap, and read the "pattern" back, and consider it as gospel and repeat it all across the code base...
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.
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.
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.
Just because it's bad for a human doesn't necessarily mean everything will fall apart - unless a human has to maintain it unaided.
Build the systems around the code and let the agents do their work.
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"
> 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.
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.
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 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.
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.
Yea, probably with a more expensive model.
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.
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 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.
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.
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.
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.
Well, and "intention" is a mine field of its own.
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
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 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.
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.
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.
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...
What you say here is not always the case.
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.
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 wouldn't know a single engineer who'd want to work at a place like that
- 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 ...
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.
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.
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.
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.
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.
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.
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
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.
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.
Counter prediction: using AI attractive even for employees. Do you really think you’d wanna join such a company? No way.