Posted by dimonomid 16 hours ago
This book gives a conceptual groundwork for what I believe to be both the promise, and crisis of AI. AI excels at, and either will soon or already has surpassed humans at a kind of reasoning that Horkheimer calls "instrumental reason." This is reason as a tool for achieving ends. AI will, I think, surpass humans at writing maintainable code, as this falls within that domain. The writer is thoughtful, but the obstacles listed in the article are technical, and they will likely fall.
A second kind of reasoning, which he calls "objective reason," is reasoning about which ends are worth pursuing. Our contemporary pragmatic, positivist culture in the West has a hard time reasoning about ends. We tend to just see different perspectives, competing power networks, etc. We are skeptical of capital-J Justice, for example. We tend to see it as historically and culturally contingent, or else as a mask for powerful interests. Horkheimer believed this learned relativism was responsible for new forms of domination and control that emerged in the 20th century in both totalitarian and putatively free societies.
I think the author's thesis would be correct if it had focused on AI's inability to discern ends. But that then raises the question: can we discern ends? Horkheimer never settled on a way to rehabilitate objective reason. He focused on critique, and his critics suggest he ended up with a tangle of negations that couldn't hold up any objective ends. I think rehabilitating objective reason is the task that faces us whether we like it or not, given our moment in history with the advent of AI. It's something practitioners need to think about. Either we recover the philosophical tools of objective reason in light of the critique which caused them to be discarded in the first place, or ends will be imposed arbitrarily by any and everyone with the means to do so.
We could take the Hofstadter idea and say that there is an isomorphism between these two artifacts. Software is a manifestation of the team's knowledge the way an organism is a manifestation of a genome.
With AI, the second artifact is no longer necessarily produced. We don't need to have a team that, as the project progresses, slowly becomes a group of domain experts. Experts that can drive the project direction. Experts that, with time, can see the flaws in their first project and start new breakthrough projects to fix these flaws.
Imagine breeding a new tomato plant. One is robust and tasty, the other is neither, but the genetic code is easier to understand. Picking the legible plant, because legibility is important to you, and may make future tinkering easier, is a dead end. Being able to create a billion different tomato plants and applying selection pressure is more effective, if you have the resources.
The idea that we are applying all this effort to make creating nauseating ads and heinous travel booking sites easier disgusts me, but hey, whatcha gonna do?!? :-)
Source?
False. AI is evolving by leaps and bounds and the outputs are better and better by the day
Personally, repeating what the article says, I haven't coded since may 2026, not a single line, and AI has been delivering exceptional results, improving by the day
Any AI related article necessarily needs to consider future improvements as they will come not by surprise but by steady refinements, and posts like this will look just like the same early AI slop they complain about
Coding IS solved
The world will always have people whose coding skills are beaten by a chatbot.
> Coding IS solved
You coding is solved.
> Fact is, vibe-coded projects devolve over time into an unmaintainable mess. The reason is simple, yet hard to fix: code maintainability and good architecture don’t have good measurements that we can apply, because it takes months, years even, to notice the effects of bad architecture or of unmaintainable code.
>
> For one, AI is not trained on what it means for code to be maintainable. For instance, any reinforcement learning done needs a reward signal that can be measured immediately, not in months or years.
I think at the end of the day, it is not impossible to have AI write "good" or "high quality" code. If anything, once the patterns are established, AI will be more likely to adhere to the patterns and rules than any human team. It requires the most experienced engineers on the team to split their time writing the core patterns and documenting them in references/skills.
But it takes a lot of "taste" and a willingness to slow down a bit with AI (to create necessary artifacts), something teams find hard to do when you can ship so fast now.
My experience has been that there is a camp of very senior engineers that are unwilling to adapt to reality and focus on documentation and writing (effectively producing skills and agent guidance which multiplies their effectiveness); they will cling to their knowledge thinking coding a sacred art.
I don't think so. It's true that human also write shitty code but the key difference is we actually remember what is the intention behind those crappy implementations so someone can fix it later. aka it is the matter of long term memory that currently LLM architecture is not capable of.
You can argue that claude can read the whole linux codebase and report bugs, but they can only report local bugs, not systematic one. 1M context windows seems like huge, but the effective range is actually pretty limited, and it still does not equal to human insight.
> aka it is the matter of long term memory that currently LLM architecture is not capable of
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.
Well, and "intention" is a mine field of its own.
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.
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".
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.
> "the scaffolding produced by the team" also includes the scaffolding produced by past AIs.
> "the scaffolding produced by the team" also includes the scaffolding produced by past engineers.
Better yet, extract docs from code comments. Even better when the docs are spatially co-located and line of sight as the agent crawls through code.
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.
> because you have time to reflect
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.
What you say here is not always the case.
They can't think that a software can be written, designed and maintained in English or higher constructs.
It is binary of either vibe coded app, or worshipping the code that they worship (and I spent 20+ years on)..the industry is moving on faster than most can wrap their heads on, but for those who understand software engineering was always beyond and above code, they will adapt, meanwhile, those who built their entire identity and skillset around managing code will struggle. There will be a place for those people, but it will be niche and specific, and we won't need as many.
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.