"To come back to the point of why agents can’t (really) deal with the slop themselves, we need to look at the evaluation of SlopCodeBench. In contrast to other coding benchmarks, which give the agent a complete list of instructions at the start and then have a set of hidden tests the program needs to pass, they do the opposite. They create multiple rounds of instruction and test iterations, where in between checkpoints the context of the models is erased. Thereby mimicking much more closely an iterative process, like how coding agents are actually used by humans. The result of that is that bad coding decisions accumulate over time and for the strict solve rate, where all tests have to be passed at all checkpoints, even state of the art models achieve 0% pass rate"
I like how this captures with a metric (lines of code and cyclomatic complexity, some other basically tractable measures) in an automated way, something we all by now intuitively know.
I love this train of thought. Code quality is critical, but I don’t think we’re correctly evaling it at the moment. If we could get solid benchmarks measuring the quality of generated code, we might see the models climb those benches fast.
I believe that the era of “ai writes tons of slop code” will be a stepping stone in the longer story, and is simply a current gap in the reward functions.
Per the author - if we can get strong measurements of what good code is, we can train against it and close the gap fast. Excited to see more thinking in this area
Sooooo much of what is considered "code quality" today is irrelevant when robots are writing the code. We've been largely optimizing for things like composability/unit testability in the past 15 or so years, and that's primarily a human concern that's unrelated to the final output.
Totally agreed that we're not looking at the correct metric right now. Increasingly, code quality will be determined by outcomes.
I code to make money, and the kind of stuff I work on doesn't kill people or lose massive amounts of money if it has bugs, so to me velocity to a solution is much more important than velocity to understanding.
There is some sense of rose-tinted glasses of pre-LLM coding. A lot of human written code, particularly at the enterprise level, was of low quality well before AI automated it.
1. People didn’t wear that as a badge of honour though.
2. A lot of it wasn’t. Low quality code/speed serves a purpose for point solutions and scripts etc. That’s not the same thing as writing a core system and if the user doesn’t put any credentials in for an S3 bucket then it falls back to giving information about your own S3 bucket (as I’ve seen just this week).
3. Plenty of companies you can discern the difference between mission critical systems versus “business” systems where if it falls over it’s annoying but not the end of the world.
I've been doing development, in one way or another, since the 90s. I've worked with dozens of teams from enterprises to startups. Hundreds of developers. The quality of work has been all over the place, but the majority was not great.
I'm arguing that what people today call "AI slop" is already higher quality than what most developers created historically, and the fact that tests and documentation pretty much come for free now means that the floor has been raised.
The quality of AI generated code is not great. Yes, it will get better. It's already better than 65%+ of what regular devs can do AND it is faster to produce, iterate, and release.
This is off-topic, but I strongly dislike AI written documentation.
When I see AI house style my eyes glaze over. Just this morning I reviewed an RFC from a colleague that he said was a spec for a web service. The document had no introduction, no context, it described endpoints for 2 distinctly different services instead of 1, and made no effort to reconcile why there are 2. It was scattershot with details, some of them important, some completely irrelevant. It was replete with typical LLM-ism.
Basically, it was a dump of a conversation he had with an LLM. As a document to build shared knowledge, it was nearly useless. The only feedback I could provide was a polite "I do not understand what you are trying to build".
But, supposedly, another engineer is already working on implementing this spec. I assume the other engineer just cycled this "spec" into his LLM, and off the two of them went. \o/
They are trying to pull me into their project right now, I stood up some containerization infra for them. But, oh boy, do I not want to join. I looked over their codebase, by LOC the codebase is 35% comments, and a lot of the comments are contradictory, there are dependencies that are not used, there is no tooling of any kind (no type checking, no linting, no PR process), there is no auth (this code is already running in production lol -- they have public endpoints exposed that can be used to scrape/mutate internal company data). Another 30-40% of the codebase is unit tests that test trivial stuff like whether their framework's serializers and ORM work, ex: x=DB.create_x(arg=1), assert(x.arg == 1).
At the intuitive level, I do not understand people who say coding is solved... To me it seems like LLMs are a multiplier (LLMs are amazing, sci-fi level shit), but if you multiply a negative number or 0, you get something that is <=0. Making agentic coding work requires a lot of discipline & expertise.
Oh man, the "unit tests" that test whether the framework/browser/language is doing what it's supposed to drive me insane. Those have their own tests already! Test the unit under test, that's why it's called that!
AI documentation is practically worthless ime. I forbid it in my projects. It's almost always more useful to not have any documentation and read the code than to rely on AI docs.
Writing code at enterprise level is insanely difficult. You are constrained by budget, staff, legacy databases/environments, business rules hiding all over the place, and people.
You can't just rewrite everything. So over many years people are touching small parts of the pie.
Yeah, enterprise code has that trope of being enterprise-y, verbose and bad. In my experience, that has always been the opposite. At the big corps/FAANGs I worked at, a single line of change can adversely impact millions of paying customers, so a lot of the verbosity and harnesses exists to dampen the failure modes.
Most of the terribly written stuff has always been at startups, where devs fling nearly anything across the finish line, if it barely works the happy path.
So much "bad" enterprise code evolved into that state over years or even decades of small changes. Meanwhile, last year I got to watch an LLM-authored codebase speedrun itself into a similar state in only a couple months. And I would say that the enterprise code was actually better. It at least did its job fairly reliably. The LLM codebase was riddled with defects, so much so that it ate up all our time and our feature delivery rate ground to a halt.
There are two observations that really eat at me:
1. Studies seem to indicate that agentic coding uses 2-10x as many lines of code to accomplish the same task.
2. One of the only really well-established empirical results in software engineering is the strong association between LOC and defect rate.
Are you saying that pure vibe coding by a non-technical person produces better code than pre-LLM developers, or that experienced dev + AI produces better code?
Both of those things are very different, and AI shouldn't be the one taking the credit if it's the second case.
I would argue the average code quality of LLM's today is much higher than pre-AI code quality. It's better documented, more readable, and has fewer bugs. There was a brief period where frontier models were still worse than the average developer, but that period among frontier models is well past us.
Are they really though? And if so, how much of that is due to the hyper growth in this specific space?
Meanwhile, the SWE job market across all companies seems pretty rough right now. Talk to someone looking for a job. Most companies seem to be in a holding pattern - little to no new SWE positions available.
The job market sucks for absolutely everyone right now, it's not a SWE thing. Fwiw I've had five recruiters reach out to me in the last four months and I'm not even applying places.
It's a far cry from 2021-2022 but I'm not convinced it's worse for SWEs today than it is for everyone else
I wonder how much of this is due to the AI tooling being taught on sloppy code that humans have written. Over the last 4 decades I've looked at a lot of code on the Internet and there's a lot of slop out there.
It will be solved when there is no more code left to write.
Code is an abstract concept that is not bound to the physical world and I imagine that future will have some much more of it that it is difficult to comprehend. Everything will be code and more code will be written than ever before.
Code will never going to be solved. The question is how much humans will be involved and I think the evidence is that perhaps just a bit. However, because we are talking about vast libraries of code even if we are involved in under 1% of all code and decision making that is needed around the code, there are still not enough developers out there to take on the task.
Code and software and applications are an intermediate stage. The final stage is an AI/LLM that just does the thing that is needed without any code being written, there are no applications or programs, just an AI that does everything.
Coding is not solved, correctness is not a feature, it is the bare minimum. If your code does not do what it is supposed to do, you could as well have no code at all. Efficiency, security, maintainability, reliability, readability, understandability, extensibility, maintainability, observability, portability, ... this is what high quality coding is about, not that it works, that is a given. And in my experience current models are pretty bad at this.
second sentence of the article: "Just because the code is formally correct doesn’t mean that it is not introducing unnecessary abstractions, creating duplicates, or just making bad decisions overall. This is not a groundbreaking observation, most people who have vibe-coded a project, have realized that each additional feature can sometimes lead to an explosion of lines of code (LOC)."
"Coding" is just a poor term for this, as there's so much room to weasel different meanings out of it. At every company I've worked in past 20+ years the "coders" were engineering a product from wrong or unclear requirements and specs from non-technical people. The act of coding was secondary (but an important throttling function to make us stop and think about what is even possible or makes sense.) Never did FAANGs, so YMMV.
Really doubt we are near that being solved with non-technical folks + LLMs. I'm seeing people gleefully rebuilding products with the exact same blind spots in their understanding/logic using LLMs. Claude, etc are not seemingly able to "AGI" around goofy asks. The CSS looks a little nicer than their legacy products though, lol.
I doubt many people here are brave enough to claim their code does what is supposed to do in every conceivable case. Maybe you have high confidence in the correctness of parts of the code. Correctness of an application is murky though. Things we build are never fully correct, merely correct enough. Like maybe you're responsible for the UI in a web app and you're using your expertise to ensure it gracefully handles display across browsers and a gamut of screen sizes/form factors. But are you also verifying how it works when localized with an RtL script? Are you checking every change you make against CJK?
I just setup a large refactor with Astra and was feeling super lazy and let it mostly do it without my usual extreme micro managing.
The refactor ended up adding 22,000 loc.
I went in there and quickly read through it, laughed my ass off. Reverted the work tree. Micromanaged a new refactor. Net lines of code for something really elegant and easy to reason about was -3k loc in the project.
In case you are wondering why vibe coders are doing 30k loc a day, this is why.
My experience is a little different. For higher abstraction languages the output is largely acceptable in my work. I always consider that LLMs don't know what I don't tell them and they have limited context to work from. Coding issues I often identify:
* Efficiency. Marginal by default. Coding efficiency problems often appear because LLMs dont usually consider the entire codebase or future plans (although they do guess at some futures). Sometimes they write/name things in ways that are lazy/wasted cycles. Most of the time, they don't.
* Security. Marginal by default. I say they do pretty good. Considering all the failure modes, not so much.
* Maintainability. Marginal by default. Mostly due to the careful consideration of modularity, upgrade paths, etc. while often taking wildly different approaches to solutions without having specific broad instructions. Even then, there can be big gaps in quality.
* Observability. Not acceptable by default. There's usually some consideration and can often one-shot.
* Portability. Not acceptable by default. Good, if you specify what those targets are. Regardless, testing validates this above the coding and models are very good at hitting functional test targets. This is less of an issue in something like Java ofc.
This sounds roughly right to me, except for "maintainability". In my experience, agents really don't like deleting code unless you explicitly ask for it. If you're not careful, you end up with new better implementations of things but with the old implementation still around in perpetuity. Humans do this too of course.
Humans had to get it drilled into them that "+12 -440" is a damn good line stat, and that keeping around dead code is bad, especially in the age of version control.
Not too surprised that LLMs also don't "get it" by default?
The shadow of Chesterton's Fence is relevant. The LLM doesn't know why code exists, if it doesnt start traversing up the scope of a project. Even then, it can't be sure that the code isn't a dependency of something else outside the project (especially if there's a side effect). I'm not sure it's ever going to be easy to address this concern in a straightforward and portable way.
I do sometimes see duplicate functions, which is troubling.
They're being trained by a lot of repetitions of one-shot bugfixes and feature implementations. If they don't have to maintain code over the long term they have no incentive to not take the easy win with lower immediate risk and higher longer-term maintenance burden.
Right. It feels like we're living in a parallel world or something. Can agents code? Sure. Can you let them code on their own for a serious production project? Not a chance.
me too; and my coding agents are slowed down (from developing features) because I require them to refactor the code to be more readable; my code metrics tests force AIs to leverage functional programming and design patterns).
Yes agents can produce code that compiles and runs, but I had to add tools to keep them on track, document their work, follow a process, check their outputs. I also use other AIs to generate developer documentation and review code.
It is like managing a bunch of idiot savant eager-to-please interns.
Consider that the people who have never have never had to be on-call for a product that results in losses for the company in the event of an outage, and/or have never had to attend an RCA meeting have just as much of a voice in this discussion. Some segments of the software industry don't even have to worry about those sorts of things, and it's easy to get myopic after a while...I doubt that a long time dev at hobbyist-centric wearable manufacturers or audio plugin shops has the same sorts of concerns as someone who has specialized in ad delivery for social media sites.
You come across as someone who has never worked on a real software project. Humans create tons of bugs on a regular basis. AI is already better than most programmers.
I'm definitely not experienced enough to know but I read people are having it write somewhat elaborate documentation beforehand. Have it figure out which parts of the code may be touched, what other things will be affected and which uncertainties it has. Basically a full report before giving permission for any code to be written/modified. Again, I haven't seen it, don't know how common this is nor how effective. Though it sounded interesting.
I have worked my entire life as a professional software developer and I agree, even among senior developers I would guess [way] less then 10 % consistently produce high quality code. But if I have to decided whether I want to use an AI to help me write code, I does not matter if it can write better code then an unexperienced junior, it has to write better code than I would on my own.
I've found I can produce 10x more code than I could otherwise, of lower quality than I would otherwise, but the speedup is worth it. Extensive testing is what makes it work, with every bug becoming a red first test with a fix. High level compartmentalization keeps everything on track, you don't let it do the big picture architecture, but you let it do each component as decided on and work through the bugs later. I've seen much worse from teams of humans and I've accepted the drawbacks that are slowly going away with each new model.
> I've found I can produce 10x more code than I could otherwise, of lower quality than I would otherwise, but the speedup is worth it.
The speedup of slop production being “worth it” is what we, as a society, are having trouble evaluating at this point in time. In all likelihood it’s worth it only in the short term.
And there is another problem: LLMs generating too much code, code that is doing more than was asked. And that cannot be fixed by tests. Usually, we create tests for wanted behavior and expected exceptions. But we don't create tests for undesired behavior.
Documentation is important. I would say Opus' propensity to write documentation that documents non-features is part of the problem being discussed.
And the problem isn't just that it says what the software doesn't do, most of the things it claims are in fact meaningless, it's not even clearly describing something the software shouldn't do.
Code cost is almost down to zero. If you move the point of “just leave it to the machine” from the compiler (where humans used to do the coding) to the high level logic (now with LLMs) then in most cases more code does not really matter. Like, why build and maintain an abstraction where the LLM could implement this many times over each time with different subtleties? Why use a library with its own constraints when you could have exactly what you want? Why use cross platform frameworks when you can just one shot the thing to N different platforms?
It’s not even slower. You can have code that’s larger yet more performant (stripping away abstractions can do that).
From time to time I try to do a pass of coalescing flows and cases and removing dead code to reduce the context and prevent the LLM from tripping over itself. But if it’s exclusively LLM maintained code I don’t care too much if there’s more of it.
Just last two weeks I had to slap Fable, three times, to stop writing 1000-2000 lines of defensive code... because of DB columns I just forgot should be NOT NULL. That was it. Nothing else. I told it that, boom, -4800 coding lines: gone.
LLMs defend the status quo and they regularly lose sight of everything bigger than the current PR they are working on.
I too am gradually making peace with the fact that LLM-maintained code does not have to be 100% readable for humans.
But this is not about readability. It's about the data model. So one concession I am willing to make is: don't care too much about the code _BUT_ manually curate the data model. So far: small wins on iteration turns and code volume producing. Too early to tell but for now I am happy with the results.
It's not solved, I agree. But if we pretend it is we can prepare for when it actually becomes solved, if ever, and measuring sloppiness is a worthy pursuit even if we never "solve code".
I think this is a two things can be true situation, where our colloquial meaning of coding is not quite adequate to indicate the full range of criteria that really matter, but also, that criteria as a totality (maintainability, reliability etc) is something that can also be targeted and optimized for.
This reminds me a bit of a PhD Comics webcomic that confidently claimed we would "never" cure cancer, on the grounds that cancer is not one thing. And I don't know that we will ever actually cure cancer, but that wouldn't be the reason. Correctly noting the problem space is bigger than a layperson would initially appreciate is a lot of things, most of them helpful, but the one thing it's not is a formal a demonstration of optimizing against the problem space as a whole.
Yeah, the author leads with a blatantly false claim that models are almost perfect at generating code. They are not. They write pretty bad code, worse than any capable human would.
This has been a problem in the software industry for a loooong time, though. Too many developers see "It works" as the end state, a signal that you're done. "It works" is just step 1.
Number of iterations solved correctly, on a very large set of iterations, seems like a very good metric. Better than anything else because it measures what we actually care about, not some proxy.
The only caveat is that it's the same model doing an iteration and then using that iteration as a starting point for the next step. So the model is allowed to write absolutely insane solutions, as long as it can read them back, even if no one else can.
One thing that could be done is to use a separately developed baseline coding model B to evaluate the outcome of each iteration. For model under test X to pass an iteration, not only should it be able to solve starting from the previous solution, but so should B, starting from X's previous solution.
>In my research and tests simply taking the change in the number of LOCs has been a surprisingly effective metric for sloppiness, with the ironic caveat that if we started optimizing for it, it would cease to be a meaningful measure.
This matches my experience. Before working on an issue, I ask the LLM to estimate net LOCs at the final PR based on the scope. It works well, and review steps do flag inconsistencies. But as the OP mentioned, if you turn this into a hard metric vs "design smell", you can see LLMs code-golfing for oneliners.
I've had some success with tokens as a measure of complexity instead of number of lines, but should be combined with additional rules, e.g. disallowing lambdas, exec, eval, compile, __import__ and complex list comprehensions for Python. Fortunately, Python's "ast" module makes this quite easy.
Ya, now that I have some solid AI coding experience under my belt, there does seem to be some gaps between practice and reality. I have a fairly complex codebase which I pretty much hand code everything. When I add a new feature, I spend a lot of time designing and refactoring that feature into the codebase. Either the feature dovetails into the existing design or the feature creates new designs which will then facilitate even better future features. When AI approaches the feature, it just plows the feature in, and with bugs since it has trouble fully understanding the total design. So over time, you have a spaghetti design where you just have a whole bunch of features tied together with no unified design. I guess thats ok if AI is supporting it, but you now have a large cost and bug surface area and an insane human learning curve. So nothing has really changed here, we have been dealing with low quality codebases way before AI came along. I think AI has mastered the one shot single feature, tool, or simple app, but it struggles with the design complexity of a rich multi feature application or system.
I liken it to contractors or overseas engineers. They don't really care about the long-term effects of their code.
I does the thing, adds some code, adds test that cover that code, and responds with "Done."
At a fully agentic "No looking at code" company, we now don't have a great understanding of that code, we don't know whether it's a good implementation or not, whether it fits our current patterns, is maintainable, or composable.
We're entirely in the dark, at the behest of an agent at this point - if we want to maintain velocity. (And I would love to know whether that velocity is real or just perceived). It feels like the code part is faster? But also feels like I have to spend a lot more time up front working through a problem to understand it. In the past, I gained that understanding WHILE I was working through the code. Who knows.
What has this author written before LLMs? Why should we listen to him and his adjudication of "perfect code"?
Cyclomatic complexity is the oldest paper generating grift for college students. There are hundreds of thousands of useless papers about cyclomatic complexity.
90% of problems are easy once you know what you actually want well enough for you to be able to ask it from an LLM.
90% of code before LLMs was badly copied from StackOverflow anyway.
That 10% that's remaining, I've see 0, ZERO, nil progress. Windows is still awful. Spotify still doesn't work correctly offline. Youtube search is trash. Jira takes 20 seconds sometimes to load a task. LLMs haven't created a new database or a new game engine or a new renderer or anything like that.
The maths breakthroughs are really more of a testament to the efforts of the last 150 years for maths to be an organised verifiable principle. If LLMs had to practice math they way Euler did, they wouldn't be able to find shit.
(sorry if I sound incoherent, just some thoughts while I'm commuting)
Having reached the same conclusions as the author led me to create my first agent to do architecture review, and that's how I learned about the metrics behind good practices that I'd been following for years. LCOM, cyclomatic complexity, that kind of stuff...
It's so easy to ship a lot of code, more effort should be put into ensuring the code is correct, with self-improving feedback loops that involve developers, and dedicated tooling...
But again, a while ago, everything was about prompt engineering, and now you can express you idea vaguely and get a somewhat working result, so this likely will evolve fast as well...
Coding just a stage in the software development. Design and specifications which can help in coding is not solved at all and may never - the end result is software reliability is not a solved problem.
Sounds right to me. As AI has picked up, I have found myself drawn to resources that (I hope) help improve my taste and judgment not only of code but also of overall software design. The lessons in _Code Complete_, for example, have been helpful to me in thinking about managing the complexity of a codebase. It was useful before, too, but perhaps even more so now.
Coding is not just the program running in memory, its also the process of distributing the mental model of understanding among the team.
If humans increasingly are kept out of coding, then who holds the mental model?
If AI holds the mental model, by definition human prompts will be over lossy channel. This is true without AI too. Software quality is directly dependent on good devs that translate from business/PM speak to technical decisions.
So is coding solved now? it was already solved decades ago.
Imho a better way of thinking about it is in terms of views - you can have an unimaginably complex codebase that nobody reads in full, but either agents or humans receive views/perspectives on that codebase.
Before LLMs we couldn’t have built tools that would deliver such views, now we can.
I mean... Nobody NEEDs to hold a mental model, but we've been increasingly trying to build that mental model into an agentic codebase... maybe we're doing it wrong but it is NOT going well.
The agents jot down absolutely everything (and more, which is the issue), thousands and thousands files of perceived business logic, decisions, workflows, architecture, data modeling, etc... It gets stale extremely quickly - we change one thing in the system and 570 "shards" need to be updated. I stumble on more and more things every day that are untrue about the agents "mental model" and it appears to just keep doing it. One small addition not properly reviewed by a human introduces a cascade of misconceptions system wide.
We've tried these "views" you mention, we call them subsections, but it runs into the same problems. One falsification ends up poisoning entire projects.
Remember when we use to refactor functions in a codebase in order to slim down complexity? Yeah - we ended up doing that but with documentation... IMO code is deterministic and we have trained professionals who know how to read it quickly and modify it. (We don't even need to write it anymore, but reading it is the simplest way to ensure no-loss understanding of a piece of functionality.)
Oh, I just dropped all the comments. Memory and session histories are for storing these things, comments just add confusion.
Subsections - how do they run into the same problem? What falsification? The views I mean are dynamic ad hoc. Every single small task gets its own temporary view.
But perhaps I’m misunderstanding something that you’re saying?
The only difference with the past that you need less time to dig through the codebase or documentation, the agent can do it for you and provide only meaningful info, but without a "Mental model"(or knowing what's going under the hood) your own prompts will be the main reason of the sloppiness and high token usage.
We'll invent other tools to help with the mental models, ones that are more intuitive.
Imagine being able to walk into a house and see immediately the leaks dripping from the ceiling, the clunky layout and smell the stinky garbage that hasn't been collected.
We're already in a sort of IDE when you think about it, we're operating a much larger mental model than any code-base, and we rarely remember that we're operating with such a model.
> Imagine being able to walk into a house and see immediately the leaks dripping from the ceiling, the clunky layout and smell the stinky garbage that hasn't been collected.
No need to imagine. Just open the README.md of many projects.
Mental models existed before coding. The pyramids were not built by just a couple of guys hauling some rocks together. It was a highly structured organization.
Or the East India Company or many other great organizations that achieved big things before computers.
Does anybody actually know whether there's a limit to the complexity LLMs are capable of dealing with in a codebase? It's very obvious that they don't write code that is suitable for people to understand it (and it's gonna get worse and worse the more RL is used to train these models), but if there isn't a point at which LLMs also struggle due to the complexity they introduce, then I'm not sure it really matters anymore for a large part of non safety-critical software. I really hope there is, because steering them is, I feel, one of the last competencies through which I can still add value, but is there actually evidence that these models struggle more with poorly maintained code?
Yeah, exactly my experience. Especially ever since Fable came out, I felt paralysed, many times, about how many decisions I have to hand it. Which is 10x harder when you handed it the reins to build the PR and you practically only knew the compressed initial problem statement. Then it stands up a draft PR and says: "Decisions you owe me: [insert bulleted list with 8 items each a paragraph long]" and you are like: "...oh shit".
It becomes a very heavy and difficult exercise of it walking you through the implementation and the judgment calls it had to make along the way. VERY exhausting.
There's a silver lining though: you do get to gradually clarify a proto project spec and various requirements, but boy does it take time and energy to re-contextualise when the bot tells you that you should make decisions.
> I really hope there is, because steering them is, I feel, one of the last competencies through which I can still add value
Something as simple as output length is a hard linear floor for productivity, even putting aside the obvious context problems that you're intuiting, and it's far from being the biggest cost that arises from steering skill. Learning to make a smaller, faster model do the same work with less tokens is a technical domain that a lot of people don't seem capable of learning. I'm not just talking about "context engineering", but learning how to fine tune, post-train, create better harnesses, design inference setups, etc. If we're both using AI, but I'm beating you to market every single time and with a better product, what is your AI usage actually buying you? Yes, competency and skill is this meaningful right now, and it's highly technical.
Right now most of the labor who understand the technology enough to do those things lives at the companies selling you these services, but you can absolutely learn to do these things yourself right now. It's actually really fun! A hell of a lot more fun than fucking prompting that's for sure.
Right now where we're at, I would equate it to the early mainframe era where the programmers came with the computer. I'm placing calls that we follow a similar track, that we're going to see a decoupling, and we're going to see it in our lifetime. Especially with the political climate? In 50 years, OpenAI will have a ring to it like IBM does today.
I started Valknut (https://github.com/sibyllinesoft/valknut) when I saw the writing on the wall regarding Agent code structure/abstractions/etc being a limiting factor in the ability to autonomously build projects. My experience was that good linters helped, but it wasn't enough, you needed to be able to enforce information-theoretic related organizing principles in addition to file/function LOC and local complexity metrics to guide agents on how to structure code.
Originally I tried to walk the line between improved agent performance and human readability, but current models are so good I don't think human readability matters much, though at a high level, being able to grok the overall folder structure still matters. I've got my hands full polishing a demo for my game, but I intend to revisit Valknut by crafting an eval set that lets me calculate the difference in agent token consumption and task failure rate between ~isomorphic codebase structures. This will let me loop agents to discover organizing policies that improve them.
Truthfully though, with today's models I don't think this sort of codebase optimization is likely to have much impact below 250k-300k LoC projects, and it probably won't be a decisive win till you're near 1M. Also, the shelf life of a product like this isn't infinite as each generation of models pushes those numbers up while also having new policy preferences that require re-evaluating existing policies.
163 comments
[ 0.20 ms ] story [ 6.3 ms ] threadI like how this captures with a metric (lines of code and cyclomatic complexity, some other basically tractable measures) in an automated way, something we all by now intuitively know.
I believe that the era of “ai writes tons of slop code” will be a stepping stone in the longer story, and is simply a current gap in the reward functions.
Per the author - if we can get strong measurements of what good code is, we can train against it and close the gap fast. Excited to see more thinking in this area
Totally agreed that we're not looking at the correct metric right now. Increasingly, code quality will be determined by outcomes.
Which is more important to you: Velocity to a solution? Or velocity to understanding?
Velocity to solution is default for almost everyone else, especially one-off or low impact / low consequence of failure projects.
Alan Kay called programming "Pop Culture" some 20 years ago[0]
[0] https://queue.acm.org/doi/10.1145/1039511.1039523
2. A lot of it wasn’t. Low quality code/speed serves a purpose for point solutions and scripts etc. That’s not the same thing as writing a core system and if the user doesn’t put any credentials in for an S3 bucket then it falls back to giving information about your own S3 bucket (as I’ve seen just this week).
3. Plenty of companies you can discern the difference between mission critical systems versus “business” systems where if it falls over it’s annoying but not the end of the world.
I've been doing development, in one way or another, since the 90s. I've worked with dozens of teams from enterprises to startups. Hundreds of developers. The quality of work has been all over the place, but the majority was not great.
I'm arguing that what people today call "AI slop" is already higher quality than what most developers created historically, and the fact that tests and documentation pretty much come for free now means that the floor has been raised.
The quality of AI generated code is not great. Yes, it will get better. It's already better than 65%+ of what regular devs can do AND it is faster to produce, iterate, and release.
When I see AI house style my eyes glaze over. Just this morning I reviewed an RFC from a colleague that he said was a spec for a web service. The document had no introduction, no context, it described endpoints for 2 distinctly different services instead of 1, and made no effort to reconcile why there are 2. It was scattershot with details, some of them important, some completely irrelevant. It was replete with typical LLM-ism.
Basically, it was a dump of a conversation he had with an LLM. As a document to build shared knowledge, it was nearly useless. The only feedback I could provide was a polite "I do not understand what you are trying to build".
But, supposedly, another engineer is already working on implementing this spec. I assume the other engineer just cycled this "spec" into his LLM, and off the two of them went. \o/
They are trying to pull me into their project right now, I stood up some containerization infra for them. But, oh boy, do I not want to join. I looked over their codebase, by LOC the codebase is 35% comments, and a lot of the comments are contradictory, there are dependencies that are not used, there is no tooling of any kind (no type checking, no linting, no PR process), there is no auth (this code is already running in production lol -- they have public endpoints exposed that can be used to scrape/mutate internal company data). Another 30-40% of the codebase is unit tests that test trivial stuff like whether their framework's serializers and ORM work, ex: x=DB.create_x(arg=1), assert(x.arg == 1).
At the intuitive level, I do not understand people who say coding is solved... To me it seems like LLMs are a multiplier (LLMs are amazing, sci-fi level shit), but if you multiply a negative number or 0, you get something that is <=0. Making agentic coding work requires a lot of discipline & expertise.
Testing though I'll mostly give you
You can't just rewrite everything. So over many years people are touching small parts of the pie.
If it works it isn't low quality.
then the same applies to AI written code?
So much "bad" enterprise code evolved into that state over years or even decades of small changes. Meanwhile, last year I got to watch an LLM-authored codebase speedrun itself into a similar state in only a couple months. And I would say that the enterprise code was actually better. It at least did its job fairly reliably. The LLM codebase was riddled with defects, so much so that it ate up all our time and our feature delivery rate ground to a halt.
There are two observations that really eat at me:
1. Studies seem to indicate that agentic coding uses 2-10x as many lines of code to accomplish the same task.
2. One of the only really well-established empirical results in software engineering is the strong association between LOC and defect rate.
Both of those things are very different, and AI shouldn't be the one taking the credit if it's the second case.
its just now the same humans weaponized by AI ship 20x more of low quality code.
Meanwhile, the SWE job market across all companies seems pretty rough right now. Talk to someone looking for a job. Most companies seem to be in a holding pattern - little to no new SWE positions available.
It's a far cry from 2021-2022 but I'm not convinced it's worse for SWEs today than it is for everyone else
Code is an abstract concept that is not bound to the physical world and I imagine that future will have some much more of it that it is difficult to comprehend. Everything will be code and more code will be written than ever before.
Code will never going to be solved. The question is how much humans will be involved and I think the evidence is that perhaps just a bit. However, because we are talking about vast libraries of code even if we are involved in under 1% of all code and decision making that is needed around the code, there are still not enough developers out there to take on the task.
I might be wrong :)
The market is already collapsing in China and India.
Really doubt we are near that being solved with non-technical folks + LLMs. I'm seeing people gleefully rebuilding products with the exact same blind spots in their understanding/logic using LLMs. Claude, etc are not seemingly able to "AGI" around goofy asks. The CSS looks a little nicer than their legacy products though, lol.
I doubt many people here are brave enough to claim their code does what is supposed to do in every conceivable case. Maybe you have high confidence in the correctness of parts of the code. Correctness of an application is murky though. Things we build are never fully correct, merely correct enough. Like maybe you're responsible for the UI in a web app and you're using your expertise to ensure it gracefully handles display across browsers and a gamut of screen sizes/form factors. But are you also verifying how it works when localized with an RtL script? Are you checking every change you make against CJK?
The refactor ended up adding 22,000 loc.
I went in there and quickly read through it, laughed my ass off. Reverted the work tree. Micromanaged a new refactor. Net lines of code for something really elegant and easy to reason about was -3k loc in the project.
In case you are wondering why vibe coders are doing 30k loc a day, this is why.
My experience is a little different. For higher abstraction languages the output is largely acceptable in my work. I always consider that LLMs don't know what I don't tell them and they have limited context to work from. Coding issues I often identify:
* Efficiency. Marginal by default. Coding efficiency problems often appear because LLMs dont usually consider the entire codebase or future plans (although they do guess at some futures). Sometimes they write/name things in ways that are lazy/wasted cycles. Most of the time, they don't.
* Security. Marginal by default. I say they do pretty good. Considering all the failure modes, not so much.
* Maintainability. Marginal by default. Mostly due to the careful consideration of modularity, upgrade paths, etc. while often taking wildly different approaches to solutions without having specific broad instructions. Even then, there can be big gaps in quality.
* Observability. Not acceptable by default. There's usually some consideration and can often one-shot.
* Portability. Not acceptable by default. Good, if you specify what those targets are. Regardless, testing validates this above the coding and models are very good at hitting functional test targets. This is less of an issue in something like Java ofc.
Not too surprised that LLMs also don't "get it" by default?
I do sometimes see duplicate functions, which is troubling.
Yes agents can produce code that compiles and runs, but I had to add tools to keep them on track, document their work, follow a process, check their outputs. I also use other AIs to generate developer documentation and review code.
It is like managing a bunch of idiot savant eager-to-please interns.
It's just that many (I guess that includes me? :D) assumed that they are better than the actually were.
Better at writing code within a huge system, definitely not. Maybe in the future, but as of Astra, Fable 5.1, the answer is still no.
If anything, it works more reliably today with the smarter models.
The speedup of slop production being “worth it” is what we, as a society, are having trouble evaluating at this point in time. In all likelihood it’s worth it only in the short term.
That is never worth it. You're ruining the software you work on when you do this.
Its documentation about what the code does not do could fill whole books.
UI copy being full of slop explaining what the software does not do is another problem.
I am not convinced that a lack of negative test cases is an issue.
I do agree it generates too much code most of the time.
And the problem isn't just that it says what the software doesn't do, most of the things it claims are in fact meaningless, it's not even clearly describing something the software shouldn't do.
From time to time I try to do a pass of coalescing flows and cases and removing dead code to reduce the context and prevent the LLM from tripping over itself. But if it’s exclusively LLM maintained code I don’t care too much if there’s more of it.
Just last two weeks I had to slap Fable, three times, to stop writing 1000-2000 lines of defensive code... because of DB columns I just forgot should be NOT NULL. That was it. Nothing else. I told it that, boom, -4800 coding lines: gone.
LLMs defend the status quo and they regularly lose sight of everything bigger than the current PR they are working on.
I too am gradually making peace with the fact that LLM-maintained code does not have to be 100% readable for humans.
But this is not about readability. It's about the data model. So one concession I am willing to make is: don't care too much about the code _BUT_ manually curate the data model. So far: small wins on iteration turns and code volume producing. Too early to tell but for now I am happy with the results.
This reminds me a bit of a PhD Comics webcomic that confidently claimed we would "never" cure cancer, on the grounds that cancer is not one thing. And I don't know that we will ever actually cure cancer, but that wouldn't be the reason. Correctly noting the problem space is bigger than a layperson would initially appreciate is a lot of things, most of them helpful, but the one thing it's not is a formal a demonstration of optimizing against the problem space as a whole.
The only caveat is that it's the same model doing an iteration and then using that iteration as a starting point for the next step. So the model is allowed to write absolutely insane solutions, as long as it can read them back, even if no one else can.
One thing that could be done is to use a separately developed baseline coding model B to evaluate the outcome of each iteration. For model under test X to pass an iteration, not only should it be able to solve starting from the previous solution, but so should B, starting from X's previous solution.
This matches my experience. Before working on an issue, I ask the LLM to estimate net LOCs at the final PR based on the scope. It works well, and review steps do flag inconsistencies. But as the OP mentioned, if you turn this into a hard metric vs "design smell", you can see LLMs code-golfing for oneliners.
I does the thing, adds some code, adds test that cover that code, and responds with "Done."
At a fully agentic "No looking at code" company, we now don't have a great understanding of that code, we don't know whether it's a good implementation or not, whether it fits our current patterns, is maintainable, or composable.
We're entirely in the dark, at the behest of an agent at this point - if we want to maintain velocity. (And I would love to know whether that velocity is real or just perceived). It feels like the code part is faster? But also feels like I have to spend a lot more time up front working through a problem to understand it. In the past, I gained that understanding WHILE I was working through the code. Who knows.
Reality: earandil.com uses 170% CPU in Firefox.
What has this author written before LLMs? Why should we listen to him and his adjudication of "perfect code"?
Cyclomatic complexity is the oldest paper generating grift for college students. There are hundreds of thousands of useless papers about cyclomatic complexity.
90% of problems are easy once you know what you actually want well enough for you to be able to ask it from an LLM.
90% of code before LLMs was badly copied from StackOverflow anyway.
That 10% that's remaining, I've see 0, ZERO, nil progress. Windows is still awful. Spotify still doesn't work correctly offline. Youtube search is trash. Jira takes 20 seconds sometimes to load a task. LLMs haven't created a new database or a new game engine or a new renderer or anything like that.
The maths breakthroughs are really more of a testament to the efforts of the last 150 years for maths to be an organised verifiable principle. If LLMs had to practice math they way Euler did, they wouldn't be able to find shit.
(sorry if I sound incoherent, just some thoughts while I'm commuting)
I don't think this is true. They very well might have, but a specific one, not a generic reusable version you find on GitHub or whatever.
Of course, sloppiness to date can be measured by different shared and interpreted preferences and definitions.
It's so easy to ship a lot of code, more effort should be put into ensuring the code is correct, with self-improving feedback loops that involve developers, and dedicated tooling...
But again, a while ago, everything was about prompt engineering, and now you can express you idea vaguely and get a somewhat working result, so this likely will evolve fast as well...
If humans increasingly are kept out of coding, then who holds the mental model?
If AI holds the mental model, by definition human prompts will be over lossy channel. This is true without AI too. Software quality is directly dependent on good devs that translate from business/PM speak to technical decisions.
So is coding solved now? it was already solved decades ago.
Imho a better way of thinking about it is in terms of views - you can have an unimaginably complex codebase that nobody reads in full, but either agents or humans receive views/perspectives on that codebase.
Before LLMs we couldn’t have built tools that would deliver such views, now we can.
The agents jot down absolutely everything (and more, which is the issue), thousands and thousands files of perceived business logic, decisions, workflows, architecture, data modeling, etc... It gets stale extremely quickly - we change one thing in the system and 570 "shards" need to be updated. I stumble on more and more things every day that are untrue about the agents "mental model" and it appears to just keep doing it. One small addition not properly reviewed by a human introduces a cascade of misconceptions system wide.
We've tried these "views" you mention, we call them subsections, but it runs into the same problems. One falsification ends up poisoning entire projects.
Remember when we use to refactor functions in a codebase in order to slim down complexity? Yeah - we ended up doing that but with documentation... IMO code is deterministic and we have trained professionals who know how to read it quickly and modify it. (We don't even need to write it anymore, but reading it is the simplest way to ensure no-loss understanding of a piece of functionality.)
Subsections - how do they run into the same problem? What falsification? The views I mean are dynamic ad hoc. Every single small task gets its own temporary view.
But perhaps I’m misunderstanding something that you’re saying?
Imagine being able to walk into a house and see immediately the leaks dripping from the ceiling, the clunky layout and smell the stinky garbage that hasn't been collected.
We're already in a sort of IDE when you think about it, we're operating a much larger mental model than any code-base, and we rarely remember that we're operating with such a model.
No need to imagine. Just open the README.md of many projects.
Or the East India Company or many other great organizations that achieved big things before computers.
AI: "You asked to add feature X. Here are 25 questions that impact feature Z, B, and C in your gigantic codebase"
Developer: I can answer 8 of these questions... Guess I need to go figure out the rest of them.
Writing the code + building the functionality has always been the easy part.
It becomes a very heavy and difficult exercise of it walking you through the implementation and the judgment calls it had to make along the way. VERY exhausting.
There's a silver lining though: you do get to gradually clarify a proto project spec and various requirements, but boy does it take time and energy to re-contextualise when the bot tells you that you should make decisions.
Something as simple as output length is a hard linear floor for productivity, even putting aside the obvious context problems that you're intuiting, and it's far from being the biggest cost that arises from steering skill. Learning to make a smaller, faster model do the same work with less tokens is a technical domain that a lot of people don't seem capable of learning. I'm not just talking about "context engineering", but learning how to fine tune, post-train, create better harnesses, design inference setups, etc. If we're both using AI, but I'm beating you to market every single time and with a better product, what is your AI usage actually buying you? Yes, competency and skill is this meaningful right now, and it's highly technical.
Right now most of the labor who understand the technology enough to do those things lives at the companies selling you these services, but you can absolutely learn to do these things yourself right now. It's actually really fun! A hell of a lot more fun than fucking prompting that's for sure.
Right now where we're at, I would equate it to the early mainframe era where the programmers came with the computer. I'm placing calls that we follow a similar track, that we're going to see a decoupling, and we're going to see it in our lifetime. Especially with the political climate? In 50 years, OpenAI will have a ring to it like IBM does today.
Originally I tried to walk the line between improved agent performance and human readability, but current models are so good I don't think human readability matters much, though at a high level, being able to grok the overall folder structure still matters. I've got my hands full polishing a demo for my game, but I intend to revisit Valknut by crafting an eval set that lets me calculate the difference in agent token consumption and task failure rate between ~isomorphic codebase structures. This will let me loop agents to discover organizing policies that improve them.
Truthfully though, with today's models I don't think this sort of codebase optimization is likely to have much impact below 250k-300k LoC projects, and it probably won't be a decisive win till you're near 1M. Also, the shelf life of a product like this isn't infinite as each generation of models pushes those numbers up while also having new policy preferences that require re-evaluating existing policies.