It’s more reasonable to extrapolate based on past evidence than arbitrary conjecture.
Self driving cars are great!
…but fully autonomous (level 4+) driving turns out to be really much harder to do that the initial 6-12 of self driving demos suggested it would be.
Its always easier to get the first prototypes and demos up, and its literally ALWAYS wrong to extrapolate exponential improvement based on that initial set of results.
It should be a surprise to no one that AI coding follows a diminishing returns log curve, and that improvements are merely incremental after the initial burst of improvement.
I am still not sure what their opinion or point is, because they vagueposted instead of telling us.
Last year, the frontier llms could produce working code, but the code looked brittle and overly defensive. Earlier this year, it got better and started to take more of the codebase into account. Since Claude 5.5, the quality improved substantially.
A lot of these things could be improved with prompt engineering and steering, but much less so nowadays.
But I don't think code quality is easy to measure, so the best we have is people's experience.
Certainly in 2024 I did not foresee AI coding ending up as reliably good as I find it in recent months.
I'd like to have some understanding of whether this improvement is likely to continue or we've reached plateau.
Of course, back in the 50's an 60's, they extrapolated that we'd have flying cars today, so you're not wrong to be careful about extrapolating...
llm's are only good for closed systems with robust automated verification loops, which makes me doubt it's general applicability. at least for now, humans seem much better at navigating domains without an easy way to verify systems.
i remember a year ago i'd have to tell the llm to use the bash tool to compile to see failures. these days, for every task it
1. throughly inspects git history
2. runs the full test suite to get a baseline
3a. for each change, runs (a subset if i'm lucky) the testsuite
3b. writes about 3 billion lines of tests, including tests to test tests
4a. uses the harness's screenshot tool to check each visual change
4b. for webapps, spends several minutes poking at it with some kind of browser devtool
5. runs the entire "smoke test" suite, which often takes several minutes and regularly interrupts my keyboard focus
6. runs the full test suite at the end
even small changes take at least 10+ minutes to complete, but with much higher accuracy than a year ago.
to me these things are dumb but persistent, useful but not intelligent.
Then you have a very uncommon definition of the term "intelligent", because that's roughly what I would expect an intelligent, conscientious developer to do. Many, many bugs stem from developers who believe themselves to be too "intelligent" to need an extensive test suite.
same with anything else really. a better chef can nail a dish in one or two attempts, whereas a worse but persistent chef might take 100 attempts to achieve the same quality.
or likewise, i'm not as good as a basketball player if it takes me 100 attempts to nail a three pointer when an nba player does it 35% of the time - despite both of us eventually achieving the goal.
Not quite right - RLHF is about aligning with human preferences (because it trains, as the name implies, on signal from humans). This does not necessarily correlate with behavior. We use RLHF across any number of domains and with any number of goals, not just alignment.
RLVR is a (more recent, better in some cases) way to automate the training loop without the human being involved, because you give the model a way to verify its own results and train on that as a signal.
The harnesses have improved and I suspect there’s a decent amount of logic pushed there.
Models are larger, so the generalization that happens is better.
Lots of effort has been put towards training on coding tasks.
A year to ship is the old paradigm. With 100% agentic vibecoding, everything should be amazing now.
just use nuclear
But for me personally, the software I use on a day to day basis actually has changed drastically. I have lots of little apps and CLIs that speed up my workflows that I never had time to build in the past.
If you use it internally in business, you don't need to wait. There's lots of stuff deployed every day and works really well. If you want to see results in public, you'll have to wait for reasons unrelated to the speed of coding. Does something actually solve a problem, is it interesting enough to be popular for you to find it, is it better than most other attempts happening at the same time, and all the usual questions related to the business side. It's going to take time for PoCs to get refined enough that they gain popularity. The second issue is that lots of projects need data in addition to the software - and that still needs to be produced manually. And finally, creating a proper pubic project takes effort - there are lots more single-user solutions now.
At least in my company, it is. I have vibe coded three apps that are far better than the competition: an Xpra/Wprs alternative that's faster and much more reliable, an alternative to the VSCode Git Graph extension that is much faster and has tons more useful features (e.g. drag and drop to move/copy/rebase commits which is a feature I always wanted), and a Mac app that lets you use cheap MIDI controllers to control your screen brightness, volume, media playback etc.
I use them all every day and they're all extremely reliable, and much better than the existing tools. One was entirely vibe coded and the other two were unfinished projects that I vibe completed (probably 70% vibe code).
I suspect a mountain of people and companies have tools like these but they haven't open sourced them because a) I used company tokens so there's admin to get things open sourced, and b) it almost feels like there's no point... you can just vibe code your own version to your exact liking. Do you really want to use mine?
The amount of posts when somebody introduces their program here on HN, that may have been LLM coded but that does not neglect the often massive amount of time the "dev" put into it. And yet, its all dismissed under this single negative "vibecoded" label.
I noticed that we are seeing more and more closed source programs, because people do not want to open source LLM generated code, out of fear that people start a negative PR loop against their program. And this reflects back to people not even releasing their programs into the wild.
There seem to be a inability of people to tell the difference between somebody spending a few prompts on making something, vs somebody spending months on 10.000's of prompts to make a great working program. It all gets thrown under that "vibe coded" bus. When its ironic because most code by now is LLM coded anyway. The amount of people hand coding is now probably a absolute minority.
Mostly, I think if you are promoting outside of your main area of expertise and couldn't have written it on your own, people don't want to put stuff out there and portray themselves as an expert in a subject matter that they relied heavily on AI assistance for, because it wouldn't be honest to other contributors to said project or other similar projects that were done without AI assistance.
So, I think I'd be fine with taking a look at and contributing to "vibe coded" projects so long as it is disclosed the level of expertise on the underlying subject matter that the repo maintainer has and the extent of the AI assistance.
Then it may be a genuine learning opportunity for them (and for me) and more power to them and it's a shame if it doesn't get published, but I can see why socially there is a pressure not to do it.
how/why that has happened is another story. I don't see the value in giving away my valuable thinking and ideas when it isn't appreciated and this massive-theft-founded AI company culture of our time thinks it is entitled to everything we create.
[Controversial edit: I don't think of myself as a slave, no matter what others may try to convince me to believe.]
Maybe with capable agents productivity is increasing even more now, but building sw still takes time, even if only weeks or months instead of years.
As-is we're not going to get commercial fusion until at least what, 2040? 50?
So people are super impressed because things just work, and they do.. Until they dont.
Just because things compile doesnt mean they're going to hold up, and most of this slop wouldn't, ive seen it first hand and you can also tell by the increased amount of outtages across different platforms.
Now it’s permanent baby sitting.
Repeated forever, a statement always has a chance to be right.
After a point it’s going to be challenged
Every person I’m meeting in the real world who use agents have roughly the same experience. About a year ago they started working reliably and the side projects where we played around with it started seeing actual results.
About 6 months ago I started seeing colleagues and friends all around the same time saying that LLMs solve real problems for them.
For my own case, I’ve replaced years of sloppy spaghetti code in our internal tools and services, from a bunch of engineers many of which has left the company, with code that’s objectively better quality and more coherent (though docstrings and tests tend to accumulate garbage, so cleanups are necessary eventually).
More availability issues with internet services.
We're accelerating our ability to produce mediocre software that solves common-place, mediocre problems, but with more "freedom", more customisation.
His Lordship Mr Blow, has something of an academic sense of what innovation means. He wants to see new problems being solved. A new O/S that is "secure by design" in throwing away old models of shared-CPU schedulers, and the like. I assume, new techniques in 3D game graphics. New ways of mixing compile-time/run-time langauges to accelerate development. And so on. New in the way that an academic research project should be new.
What we have from AI in software isnt anything new. Claude releases an office suite with AI assistance. We havent yet seen AI accelerate anything other than end-user programming, or lift-and-shift projects.
These might be very valuable, but theyre not innovative.
Acceleration due to AI is still described as a "time warp" not an ability to come up with ideas you wouldn't have come up with before, e.g. https://www.planned-obsolescence.org/p/ai-is-dramatically-ac...
The changes always come in monster one-shot PRs ofc - too much for a human to read - so I just feed the branch to my Claude (identical to the one they’re working with) and after some thought it will give me 15 to 30 suggestions of what needs fixing.
I’m still not understanding why this happens?
LLMs are designed to circumvent our ability to tell who knows what they're talking about. Our fundamental intuition about computer programs - garbage in, garbage out - has been broken. Now everyone can sound the same. But those who do know what they're talking about understand it's just a tool, those who don't think they're like Neo and just learnt kung fu.
I recently reviewed a large PR from a decent developer. I wrote some of the requirements after meeting with stake holders and did my own investigation on potential solutions.
The PR was full of bugs, missed half the requirements and the code that was there wasn’t even fully tested.
This person has successfully delivered complex things before. So what the hell? And this is not the first time I’ve thought their usage of agents and conclusions from ai assisted explorations were not right or could be better.
There’s still some weird human element. Though I’m noticing that responses are getting better with less “prompt engineering” so maybe this will all be gone soon.
Was this a developer who has been forced or pressured to use LLMs?
I know that should that time come for me, I'm not going to burn myself out wrestling to make something good.
My experience has been good, if I get the project off on a good path, with clear principles, patterns, and practices that I want to see enforced.
"List every file you need, read them in one pass, make all edits, run tests once." It stopped the read,edit,read,edit loop.
The second was a stopping rule I added : "After two failed attempts at one symptom, stop editing and get a diagnosis first"
Different tasks, different tools, different prompts, or different ability to evaluate the results, likely some combination of all of the above.
- Tools: I can't get the ChatGPT web interface, with any prompts, any models, any amount of retries, with any combination of settings, to respond to a coding task with anything other than <snippet ignoring multiple explicit requirements for what should be a 20 SLOC task> <here's how you make it actually prod-ready (often stating that it just refused to implement something I asked for)> <paternalistic essay about how I shouldn't use my vibe-coded URL parser to send a man to the moon>. The underlying models are a fair bit better. Fully controlling the system prompt helps a lot. Agentic flows paper over a lot of those deficiencies. Anthropic models (and web interfaces) work a lot better for codegen for me out of the box. Agentic flows make that delineation much sharper.
- Tasks: I don't like the concurrent data structures LLMs write. Its opinions about the novel pseudo-probabilistic algorithms I care about are wrong. The level of hand-holding I need to get proper matrix codegen is insane. It works extremely poorly when operating at a meta-type level and trying to design a cohesive API. But, if you're not doing those things, who cares? I vibe-slopped a new programming language yesterday just to try it out with a new harness I previously vibe-slopped. At this stage, it doesn't have to be correct. If I get it kind of working just a little and think the results look promising then I can do better later if I want. A lot of companies are in (or at least think they're in -- IME this mentality bites founders much earlier than they expect much of the time) that stage.
- Prompts: LLMs are much more sensitive than you might expect to minor variations in prompts. The classic example I hope everyone knows by now: There are precious few scenarios where your interaction with an LLM should be a very long session repeatedly telling it the mistakes it's made. Almost anything else is better, up to and including (as a bad solution but still better for codegen output than the baseline) still having a very long session but asking the agent to rewrite the previous messages as if it had succeeded and then having the person manually edit the conversation.
- Evaluation Ability: Really? You thought +3k SLOC was the best way to solve that feature? I have a whole SOTA event loop and multi-processing framework in 3k SLOC, and when interacting with most companies' codebases you really ought to be deleting code with the average feature you implement, not adding code. Like you said, the code smells are everywhere. Like, slop is fine from time to time (easily 30% of the code I write for work is slop, largely because it serves one-off tasks), but some of the people pushing it just can't tell the difference. Just a month ago, somebody (outside of $WORK) was showing off a fancy new UI feature on some geo-rich project. It had a small bug. The implementor said they knew about it. The problem is that "if you know you know," and the only reasonable way the code for that kind of feature should have that kind of bug is if it has major problems which just aren't surfacing much in this particular demo. I suggested a couple alternative test cases to optimize toward, and a week and a couple rewrites later it was in a much better place. There were tens of thousands of tests before I made that suggestion, dozens of times the LLM confirmed the system was working as intended, and on and on and on. None of that matters if you need to build something that works and know that it works. The tests were all shit, as were the false assurances.
If you're looking to make it better, there are some tweaks you can make to your CLAUDE.md or what have you to help a bit. I have a lot that I do to make mine generate passable code without requiring constant human intervention, but something it responds well to is (1) pinning down what you care about re abstractions, and (2) giving it explicit permission/guidance to spawn sub-agents to make that happen. A lot of the problems with LLM-generated code are fixed if you fix the abstraction issue, and many of those fixes are relatively "mechanical" checks you can apply:
1. When reading the name of an abstraction, do you have a good idea of what it does?
2. What about the name and signature?
3. Does the implementation match that intuition?
4. Does any part of the codebase reach past the intended abstraction?
5. Does your code require nonlocal reasoning? (side-note: this is very important for humans, but it's more important for models since their harnesses aggressively try to avoid bloating context windows, so it's quite common that if you need two lines of code far apart in a file to relate to one another then you'll see downstream bugs)
6. Do all of the abstractions pull their weight? Are they all even used?
7. Is it possible to delete 80% of the suggested code and have an equivalently working product?
8. Do existing abstractions/conventions solve the problem you wrote a new abstraction for?
And so on. You obviously can't compress all good engineering judgement into a brief model context window, but you can get a lot more than you might expect. Whatever it is that you see agents doing poorly, try to come up with a general principle you think it should try to respect, and write that down for your future projects.
This slope is hardly any different had they gotten an offshoring team at the lowest bid.
The only jobs that were created were at their locations, at the expense of local teams.
Because it’s an infinite loop in essence. There are always things to improve. There are always things to fix. There are always bugs in software. There are always more cases to check. There’re always better ways to do things.
You can add new code indefinitely with diminishing returns. Each addition introduces new bugs. So after a point it may become negative returns.
As human engineers we make tradeoffs. We prefer simple and clean over more complete but bloated.
Without a stop condition Claude can “improve” the code indefinitely.
So when a LLM writes new software and the LLM sweeps keep finding a ton of issues. Yea, but the LLM wrote that code in a few hours, what may have been weeks of work. The sweeps its running is finding things, that may have taken years to remove as customers report issues.
Combined with LLMs tend to "over find" issue things that we will never bother with as human written code. We may say "too trivial to fix, not a issue", ... bla bla but for a LLM its a issue to fix, so it looks like LLM code has more issues.
And while we may pat ourselves on our back for finding X bug that created data loss or a crash, there is probably a dozen high to medium bugs hidden somewhere to be found by the customers (yikes!). Where as LLMs then to reduce that vector after a sweep to barely a few medium or low items.
This is what i always need to tell people. LLMs are not just doing the work of humans at a 10x faster speed, they are also solving bugs and other issues what may have taken years for humans to iron out, what a LLM does in maybe a 24h bug hunt session.
it’s all very much over-eager junior level.
You have not seen the over smart senior dev that tries to one-liner everything. Or that makes code so complex, that its a "job secure" feature because nobody else can figure out what the ** is going on.
I noticed that there is this perception that medium or senior devs are the panicle of coding, and good practices when most are not. A lot of are simply restrained because companies force specific coding standards and left to their own devices, they will love to run amuck. Remove those handrails and your going to see code that makes most LLMs blush. lol
after some thought it will give me 15 to 30 suggestions of what needs fixing.
That simply means that your collogues never bothered to run a bug hunt sweep after their work. If they did so, just like a human dev writing something and having the work checked by another dev, this will have been reduced a minimum. People seem to have this thinking that LLMs need to write perfect code from the start, when its trained on our human code, with all its issues. Just like if we wrote code manually, and then somebody checks the code before pushing and committing it, do the same for LLM code.
!!! LLM do not mean that good coding and deployment practices are suddenly useless !!!
You have to carefully manage the project scope, and catch the ai getting stuck. There is a stars aligning point where you are matching the model to its scope on a clearly defined goal to iterate towards and its mind-blowing. And then if you go even a bit over that point it's perf falls off a cliff.
And it changes with each model with each new release.
For example, I wasted a bunch of usage today giving Fable 5.2 8 sub-orch opus high agents that each were given bunch of chatgpt subagents. It was fun watching all the churn, and I'm trying to find some way to use up all my openai usage.
But in the end I made much less progress/made a bunch more slop code than if I had just narrowed project scope and gave fable a smaller easier task with less agents under it. And now my weekly usage is gone in 2 days.
When the next GPT or Claude models come out, people will say that AI coding sucked "until they came out."
What will next year bring?