>If agentic development actually worked the way any of them say it does
I think its fascinating just how much of a gap there is between what's being claimed, and the verifiable observable data of the open source world. Major open source projects are by and large starting to ban LLMs now, because the contributions made by LLM users have been universally terrible and unhelpful. There doesn't appear to be a single major project that's found generating code to lead to major productivity speedups, and the consensus appears to be that its just lead to a lot of crappy contributions that are harder to spot immediately as being obvious crap
I regularly see people claim that they are now 10x more productive with LLM code generation, and I just wonder where all the code is. Is it somehow true that these gains are only being realised in proprietary projects, and not a single one of them has put even a small fraction of their new found engineering powers into eg Godot? Why do only the poor quality LLM code generation users make PRs to open source projects, and never the engineers that know how to really use it correctly?
If you look in the open source major project space, you can find almost no evidence that AI code generation exists at all. Go browse your favourite critical tool and look for AI generated PRs that have landed in the codebase, its probably a tiny handful of them in comparison to the human written PRs prior to an LLM ban. It turns out that once you have a verifiable, open quality review bar, for some reason almost no LLM commits really meet the level of quality necessary
I strongly suspect that what we're seeing is that much of the tech code-writing economy had already become completely performative prior to AI turning up. It no longer matters in the current age if your code is good, or works, because your job is to give the illusion of product development while the stock market price gets pumped, until you all cash out your share value, get bought, or hop jobs in 2 years. For many companies it literally does not matter if you produce anything that generates value (or works), because the illusion of progress is all that matters. AI is absolutely incredible at creating the illusion of progress, because it looks a whole lot like real code, it just appears to have failed the bar of making actual projects that work. If that was never the goal in the first place, it probably really is a 10x productivity boost
@antirez is a very prominent open source contributor that gets lot of shit done with LLMs. Mitchel Hashimoto is also open about using LLMs to speed up his work. There are some caveats attached: neither of them is doing crazy loops or graphs producing thousands of lines of code, they are both amazing software engineers and they know what they are doing.
> Why do only the poor quality LLM code generation users make PRs to open source projects, and never the engineers that know how to really use it correctly?
It could be that the engineers who are extremely productive with LLMs are landing PRs that look indistinguishable from good, hand-written PRs.
If so, where are all the new features in the open-source projects I use? Why hasn't GIMP replicated Photoshop? Why hasn't CUDA been fully reverse-engineered as an open source toolchain? These are unreasonable expectations, but only in response to unreasonable claims of productivity. What before took ten years should now only take one, right?
It seems likely that the gains from generating tons of code are being offset by the debt incurred to understanding what you're doing. We see lots of greenfield projects one-shotted with GPT or GLM or whatnot, but very little on the side of projects with long-term maintenance goals. This is telling, to me, that the _effective_ gains are much lower than perceived (it's lots of fun to see the thing crank out code at breakneck pace, probably contributing to this). Still quite nice, and very useful, but not a totally new paradigm.
They don't though, very few people were anti AI in the early days. Open source projects were largely initially very interested in LLM usage, and generally had a pro AI contribution policy. This changed when it did not help their lives
Eg if you check out Godot, initially they were cool with LLM code, and then had to clamp down on it because it was not leading to anything good
Scaling AI use in highly-collaborative environments, which open source projects are, is very challenging. I totally understand the apprehensiveness around it.
How is it challenging for open source projects? You just write a PR, and try to get it to meet the maintainer's quality bar. That's exactly how all code is written in any environment - you do code review and refine a PR until its good enough to be merged
With AI and how a lot of people use it, the quantity of written PRs goes up, but the quality goes down, and the maintainers of the project, who are often volunteers, now have to deal with this in addition to the standard work they've been doing before.
Why are Amazon and Walmarts mobile apps still janky crap that costs them money? Why does Meta still have four redundant, broken sign-up flows before you can give them money to advertise?
Wherever these “10000x” engineering gains are… I’m wondering why they’re only for shit nobody sees or touches.
Those websites are janky despite having all the (non AI) solutions available already. They suck for reasons independent of the quality of LLMs. I have not worked inside a megacorp but my understanding is they suck because of what are essentially political roadblocks within the organisation.
If that were true, we'd expect to see massively accelerated velocity of open source projects by these engineers. They should be creating new open source projects at a truly astounding rate, with new tooling springing up every day that dwarfs the existing open source space as their productivity completely eclipses traditional development
Instead, software is plodding along exactly the same as it did prior to LLM code generation, and there's no evidence of superprogrammers making superprojects in 1/10th of the time. With a 10x productivity gain, what used to take a year should take a month
I think what you're missing is that there are new open source projects being created at a very fast rate.
But that doesn’t mean they stick.
And the core issue isn’t AI, it’s that… a successful, highly adopted project requires time for people to know it exists, adopt it, and also time by the maintainer growing community and ensuring reliability. The people factor is more important. I see tons of new projects, but I’m not going to pick a brand new project that has high odds of being abandoned. I’m going to pick the one that consistently maintains it and has some adoption already.
I have seen engineers create very successful internal projects fairly quickly. And yes, a project that would have taken a year taking a month. And offering a lot of extra bells and whistles that you just wouldn’t have time for.
But these are greenfield internal projects, and the bar is much, much lower for those.
I have seen multiple internal incidents root-caused by an agent faster than the humans responding. Just because it can go up and down rabbit holes a lot faster.
The problem is that AI solves one bottleneck, but not others. One team member produces a huge amount of new PRs. (Like 12 solid enhancements and big fixes in a couple hours.) Now I have less time because I’m reviewing that. And we’re all context switching a lot more.
On top of that, I find AI workflows continue to be deeply immature, even though certain models are very effective and very good at troubleshooting.
The story around testing is not really improving for example. AI can write tests, but are they good? I don’t think we have much actually ensuring product quality and reliability automatically. Unit tests are not enough.
Collaboration is very poor too. Coworkers agent creates PR, and now I’m reviewing it, and now he sends my comments back to his agents… really clunky workflow especially since I’m ACTUALLY just prompting his agent.
Plus, certain models (Opus) are getting much worse at writing. I will not use Opus any more because the writing style is so horrible.
The constant change means approaches that worked well a couple months ago don’t work well today. And there are no real experts, because no one’s been doing this for long. And half the posts and learning out there are outdated, or straight up blogspam.
This makes it hard for people to learn and get better, despite the fact that models like Sol 5.6 are effective troubleshooters, and write decent code.
Github's Octoverse report kind of gives you that evidence, no? Pull requests landed in 2025 were up 30% over 2024. This year it's going to be much higher.
I'm coming to the conclusion that the right way to use LLMs for code generation is asking it to solve specific problems, giving it existing code and asking it how it would propose changing something or other, or if it has an alternative to an existing logic flow that's problematic and asking it what it thinks the problem is and how it would suggest it be written.
I'm coming from the perspective of infra management so that's my bias, and a very complex code base may make my perspective off mark.
But nowhere does it seem it to be a good idea for the whole thing to be LLM generated. It seems to view a big holistic problem in steps in isolation, causing it to add complexity on top of complexity as it's going through it's later stages. For example it'll create infrastructure designs that add layers of unnecessary and redundant tooling and business logic, when a human would have re evaluated step 1's path when it realized step 3 was doing the same thing again in a more complex way.
> I strongly suspect that what we're seeing is that much of the tech code-writing economy had already become completely performative prior to AI turning up. It no longer matters in the current age if your code is good, or works, because your job is to give the illusion of product development while the stock market price gets pumped, until you all cash out your share value, get bought, or hop jobs in 2 years.
I think this is probably the answer. Working as a professional software engineer actually has very little to do with writing good code and maybe never has. The job is to “ship products”, and as long as you keep up a sufficiently convincing illusion of progress toward that end the bills get paid and nobody really cares about the impact on end users.
Major open source projects are by and large starting to ban LLMs now, because the contributions made by LLM users have been universally terrible and unhelpful.
There are two incentives for contributing to open source. The first is to make the app better (add a feature, improve the code, fix a bug, etc.) It's possible that LLMs don't meet the bar but if a human has put the effort in it's not always obvious that it's AI. More likely LLM code is accepted when it's good and rejected when it's bad. The system works.
However, the second incentive is that open source contributions are seen as a 'ahortcut' to making a name for yourself. Being a contributor on a big project goes on resumes and GitHub profiles. Often people who use AI for that don't review the code or even check it does what they say it does. That slop needs to be banned. The downside is losing the good contributions, but it's still a net win.
We have a greenfield project at our company, yes proprietary, now taking us months where previously it'd have taken weeks for even a single feature. We definitely see the (whatever)x performance boost with our own eyes.
Its always been possible to trade long term productivity for short term gains with technical debt. This is why the bar I'm interested in is long term projects, which have proven to have long term success, instead of a small disposable project where the code quality doesn't matter
Then why isn't it showing up in open source at all? The people who file PRs are just regular average devs, but the quality of LLM PRs seems to be universally crap in comparison
Or maybe open-source development is just poorly compatible with AI workflow? Today, projects may need a community, an issue tracker, but pull requests are becoming less important.
I suspect the ban of AI in established projects to be a very complex decision. Even if core developers would like to use AI, they don't want to review all of the AI-generated code from the larger community. So the only consistent way to preserve sanity is to declare that nobody would use it. Good luck enforcing it though!
> Nothing's stopping core developers from adopting LLM generated code for themselves, while banning it for external contributors
And if they're doing that, why would they tell you, or anyone?
And if they're doing that responsibly - collaborating with AI, and reviewing the code - they don't even have an ethical reason to tell about AI involvement, any more than telling about the StackOverflow answers or blog posts they read before coming up with some implementation.
If they were sneaking LLM generated code into these projects, we'd expect to see their feature development 10x even if they covertly aren't telling anyone. Which open source codebases have seen a truly massive 10x increase in delivered feature velocity since AI turned up? Where are all the new contributors who contribute features at 10x the rate of the existing meatcoding developers?
Then all it'd take is one of these engineers blowing the lid on their whole secret LLM contribution strategy to absolutely break the industry wide open to the benefits of these massive productivity increases, and finally prove all the doubters wrong. They sure are good at keeping secrets that would directly benefit them to expose
Sure, it just seems a little odd that no LLMgineer ever contributes their incredible more performant scheduler back though right? After all if you can do it with claude, anyone can, all it'd take is to ask claude to rewrite it. Linux accepts LLM generated PRs, all the code has to do is meet the review bar and one of the most critical pieces of software engineering on the planet gets better for everyone
Why does it seem odd when people who do attempt to contribute back are attacked?
AI lowers the bar to making submissions which permits flawed subissions to be thoughtlessly submitted by people who don't really understand what they are doing, technically or culturally.
It does, however, enable people who put in the effort to work on something significant. Those people are fewer in number, but exist. They do get to see the animosity that unwitting novices receive.
I don't think it would be surprising for those people to opt out of engaging with a toxic environment.
You'd think one 10x engineer or one core developer already part of the project would have completely eclipsed all the other engineers, and worked around the difficulties there
Or, failing that, you'd think any of these engineers - given the truly vast amount of programming power now available at their fingertips with their 10x productivity - would have simply replaced these projects. It'd only take a few 10xers who wanted to show that everyone else was wrong. That's how open source often works, someone just gets a been in their bonnet and then we get linux
Instead: I can't find any of it. There's no evidence of this productivity boost in the wild. There aren't new high quality 10x open source projects springing up that are replacing everything. There aren't high quality LLM contributions, feature development isn't going faster. There's almost no evidence of high quality AI code generation at all in the open source space, existing projects or otherwise
Where's all the code? I want the receipts if people are claiming a 10x productivity. Because at the moment, the much more likely explanation seems to be that its simply not true
I can't point you at any because I don't want to send a mob their way.
For any instances where people have made things and revealed them to the world have been declared to have been grossly flawed by being held to a standard of scrutiny that no person usually gets.
People are attacked for low quality. There are counter examples but it is definitely striking how infrequently you see a PR which doesn’t stand out for being turgid or flawed, and whose author clearly expects a cookie for their “contribution” of a couple minutes of prompting.
Non-falsifiable statements aren't going to work here anymore.
What's the point of writing great software if nobody else is going to use it, and how do we even confirm there are these alleged secret geniuses hiding away somewhere? Surely their work would leak out by some nth-order effect.
- numpy/numpy: https://github.com/numpy/numpy/pull/31573 - ~21x speedup of Python datetime → datetime64 conversion, with Claude Code used for profiling and implementing the performance improvements
- apache/datafusion: https://github.com/apache/datafusion/pull/21182 - up to 49x speedup of LIMIT queries by eliminating unnecessary sorts and pushing limits into file scans, generated with Claude Code
- apache/datafusion: https://github.com/apache/datafusion/pull/21651 - ~4.39x speedup of ClickBench Q6 by resolving MIN/MAX directly from Parquet metadata instead of scanning columns, generated with Claude Code
- numpy/numpy: https://github.com/numpy/numpy/pull/31274 - up to ~1.44x speedup of common small NumPy reductions, with the fast path written by Claude Code and manually refined
That's a fair use case for them though. LLMs are superhuman at short term performance engineering/debugging/testing. But even that comes with the caveat that these commits come from talented coders using LLMs as a grad student. I think that OP is against the claim that "agent in a loop beats a talented human at long term coding tasks".
Because if it was true then open source projects such as GIMP could basically be as feature heavy as Photoshop overnight.
I, too, will reject the idea that "agent in a loop beats a talented human at long term coding tasks".
LLMs amplify existing expertise. Give them to experts and you can get fantastic results. Give them to amateurs and you might get the occasional impressive demo, but you're not going to get anything that a responsible software team would commit to maintaining in the long term.
> I regularly see people claim that they are now 10x more productive with LLM code generation, and I just wonder where all the code is.
Perhaps the biggest issue hasn't been the speed of development all along but people working on wrong things, hence why progress isn't as evident. LLM helping to build something that isn't needed faster isn't going to productivity more visible.
I use my powers to finish my own projects (until the next creative barrier) while my professional workload has been reduced to 20% effort with 0 stress.
I wrote a game I left in a folder from 11 years ago in 2 months, front and back plus all the tooling, plus features I never would have attempted before. I recreated open-sourced projects from github, written in a language I wasn't familiar with, so I could better work with the application and include it in my backend codebase.
I rewrote my mail server in less than 2 days, which took me over 2 weeks to configure and setup the last time.
My life is easier, because the demands are the same but I have more free time. I research more, I learn more, and I try more things. Just like any software project, some are abandoned (even with LLMs) when running into unforeseen issues or mismatches with theoretical plans. Most importantly, I can make things that I think are exciting, with very little effort. The first 35 years of development, I struggled to be good enough to tackle sourcing various projects without becoming frustrated and mostly knowing myself well enough to avoid trying at all.
Now I can see myself writing passion projects until I'm dead.
I find it game changing for experimental work and prototyping. As a research scientist this is a major bottleneck and clean code is often not the right optimization target.
> I think its fascinating just how much of a gap there is between what's being claimed, and the verifiable observable data of the open source world.
According to this list of top Github repos by stars[1], of the top 10, nine of them are informational and one is OpenClaw, which certainly has plenty of AI generated code.
The next 10 include react which has a CLAUDE.md and a .claude, and lots of landed PRs that look like AI. And linux, which, we all read Linus' stance. He sees the value. And superpowers, ECC, and hermes-agent. All of which are AI stuff.
I think it would be reasonable to ask which major open source projects aren't using AI assistance?
> Major open source projects are by and large starting to ban LLMs now, because the contributions made by LLM users have been universally terrible and unhelpful.
That is not why. Or at least not the majority of it. The biggest part is that maintainers just can't keep up. They don't have time to do in depth reviews for the number of PRs coming in to find out if it: works, does what it says it does, meets a need, has docs, is well written, meets criteria, etc. That does not mean all those PRs are trash. Some might be trash, some might be gold. Just like human generated ones.
What it comes down to is vibes. Anti-AI folk don't like AI for reasons (that are valid) and they don't want to find any value in it. So they don't. But lots of people are. Lots of really cool, interesting, clever, new software is being written and getting used and building communities but people see CLAUDE.md and go "slop, no thanks" and won't even give it a try.
>I think it would be reasonable to ask which major open source projects aren't using AI assistance?
Where are all the vast quantity of LLM commits for these open source projects, if these engineers are truly 10xing their productivity with LLM code generation? Because I regularly browse the source of many of these, and can find almost no evidence that LLM code generation is anywhere near the level of productivity being claimed for:
1. ImGui
2. SFML
3. SDL
4. GLFW
5. OpenSSL
6. Linux
7. GCC
8. Clang/LLVM
9. Libc++/libstdc++/msstl
10. Rust
11. Godot
12. Nlohmann
13. Boost
14. Python
15. GNU tools
Etc etc. There are even more major projects, but these are just the critical ones I can think of off the top of my head. If you go for a browse though eg Godot, you might think that LLMs don't exist. In fact if you go for a browse through any of these, you might think that LLMs are borderline never used for code generation in the open source world. This is a diverse collection of random projects, and yet for some reason none of these have experienced a 10x increase in productivity in any form from any contributors from LLM code generation
>That is not why. Or at least not the majority of it
Its not the quantity, if maintainers were receiving incredibly high quality PRs that could just be merged, they'd be very happy. Godot is an example of a project that was initially pro LLM, and then had to about face because the PRs were just absolutely crap
>Some might be trash, some might be gold
Is there any evidence that any of these PRs have ever been gold?
You have to consider that there is a chilling effect in the open source space because llm use has now become an ideological battle, and people have lost their collective minds over it.
Bun did a nearly 100% hands off keyboard rewrite. And people largely ridiculed the effort with mud slinging and goal post moving.
There are plenty of measurable examples of the productivity boost when there is a well defined oracle, such as rewrites and (kind of)formally verified specifications.
I've got an agent harness that I built that decompiles games. Don't want to dox myself on this account, so this is all I'll say about it.
I may have been able to decompile 1 game a year into readable source. Now I can offload nearly all of that process to an Nvidia 5090 and the extremely cheap deepseek v4 flash.
With dedicated focus and a lot of personal time, or employer time, I may have been able to reconstruct a good amount of react linting rules to biome. But instead, by focusing on a harness that can prove parity, I can get all of the rules ported while I sleep or solve other institutional problems.
Once you can prove the outcome, however hard or soft you need based on the domain, the output gains are literally undeniable.
Imo the vaporware is all of these "one-shot" projects that people love to show off. Once the market corrects and the hypecycle dies down theres going to be a lot of interesting engineering in this space. Right now there's a bit of a Cambrian explosion of ideas, and for better or worst that space fills up with the over the enthusiastic and chareltons.
Fragmented thoughts I'm typing while walking, the point is murky
> Why do only the poor quality LLM code generation users make PRs to open source projects, and never the engineers that know how to really use it correctly?
Selection bias? OSS has a thing proprietary projects don't - an endless cohort of opportunists trying to wedge in a "contribution" for personal gain, be it a Hacktober t-shirt or resume boost or an occasional vulnerability (with the resume boosting being by far most likely). The good LLM-based contributions, you probably won't recognize as AI-assisted unless the author explicitly decided to label them, and if they're really good and use LLMs responsibly, they probably don't even have any ethical obligation to label LLM involvement, much less any benefit.
OSS involvement in general stopped being an indicator of skill once Github activity became a factor for job applications.
Edit:
There's also a second factor: many people (myself included) use LLMs to code one-off personal tools with no intent of them having more than one user, ever. Get an itch, have an LLM scratch it for you, carry on with your life. You'll see little trace of it, because it's hard to distinguish a single-user program that's good enough for specific purpose from a pile of autogenerated slop that probably doesn't work, and neither of these will show up as PRs to big OSS repos anyway.
The the idea that engineers are covertly sneaking huge quantities of LLM generated code into these projects doesn't pass the smell test, as there's lots of evidence that this isn't true. It'd be incredibly obvious if new contributors were turning up en masse and contributing absolutely incredible amounts of high quality code, because everyone would be crowing about it
Instead, if you check out something like ImGui, we can see that its largely just Omar as usual with a bunch of PRs. Nothing much seems to have changed, feature development carries on at the same pace as it did previously. This is replicated across nearly every single major long term open source project I can find
The only reason developers now feel the need to hide their LLM usage is because the LLM contributions have all been shockingly bad, so you're reversing cause and effect. If LLM contributions had been incredible, they wouldn't be frowned upon socially now. Surely someone would blow the lid on this huge covert conspiracy about how incredible their contributions to.. SFML have been?
This effect also wouldn't prevent LLMgineers from creating their own open source projects that should be absolutely outstripping the existing open source space. After all how old is ImGui? With a 10x productivity gain, it should take a year of development to easily match its features if those gains are truly real now
>if they're really good and use LLMs responsibly, they probably don't even have any ethical obligation to label LLM involvement
The copyright issues means that non disclosure is inherently unethical
> The only reason developers now feel the need to hide their LLM usage is because the LLM contributions have all been shockingly bad, so you're reversing cause and effect. If LLM contributions had been incredible, they wouldn't be frowned upon socially now
You're dismissing scale of things. OSS communities were having high-profile discussions about gatekeeping and discrimination way before LLMs were a thing, because already at that point the amount of human generated slop was becoming untenable. And yet, no one argued that this must be evidence that all human contributions are bad and humanity is a bubble waiting to pop.
> ImGui
Weird choice of an example. ImGui is common infrastructure. Who in their right mind would want to mess with that? Especially when building something to solve some end-user problem (whether N=1 or N=1 billion), ImGui is a component you include, not one you rewrite.
There's hardly any reason anyone has to contribute to that project, with or without LLMs.
LLMs work well for boring stuff that other people have already done a hundred times. Where the LLMs fail is solving difficult problems that aren't explored as well. The people seeing the 10x speed up are likely just doing CRUD apps or other software that have already been well documented by Stack Overflow or cloned a million times on Github. In my own use, it completely breaks down when for solving actually difficult things.
I don't know how you can claim it's all vapour ware.
Two years ago, I couldn't just roughly describe my backlog and then have the code fixed. I had to type it out myself, run it, look at logs, fix toolchain issues, and so on. It was tedious. Or I could get a junior to do it.
Now can get these things done quite fast, without concentrating nearly as hard.
Clearly, it isn't vapour.
It delivers something. That something we have yet to figure out the best way to use, but there's definitely something there that works.
I get the feeling a lot of people are frustrated because the little gains are lost in organisational chaos, rather than the tools not working.
On your last point, I think it has a lot to do with how it's introduced in organizations. If everyone just goes hog wild with it, enamored with their newfound productivity, not only will the little gains be lost, I'd argue all the generated noise will be a net negative. And people will hate that.
That's the result of AI adoption in a company being people just getting a subscription and doing their own thing, instead of systematically introducing and finding a common ground; a trivial example of that would be open source projects increasingly adopting LLM policies to get everyone on the same page.
It's August 9, 2026 and if you're a software engineer who hasn't had multiple "holy shit, I can't believe it just did that" moments, it's time to consider a new trade.
I find this to be an incredibly myopic viewpoint. Software engineering is not defined by a single tool or technology, but rather how we design, implement, and maintain processes of value we want to automate or scale.
LLMs will certainly be an aide, but assuming adoption of them is required across a whole _field_ ignores whole classes of problems, domains, and constraints the production of software covers.
Rather, we should be wary of allowing our skills and hard-earned knowledge to atrophy by over reliance on new technology that is far from perfect, reliable, or even universally available. These tools more than any before suffer from the junk-in-junk-out problem and I’d much rather work with someone who knows their fundamentals than someone who knows their way around a the LLM of the month.
On the contrary, taken at face value I find the GP comment to be spot on.
They aren't saying LLM adoption is required across 100% of the field. They are pointing out that LLMs have reached an impressively capable state, and someone insufficiently inclined to test new tooling that they still dismiss LLMs as "just fancy autocomplete" is exactly who gets left behind when technology advances.
Two things can be true at the same time, 1) that LLMs are not required across a whole field, and 2) that software engineers unwilling to acknowledge their utility have as much a place in the future as the software engineers of 50 years ago who refused to use a compiler.
Can you elaborate on how someone would get "left behind"? Isn't the whole point of LLMs that they use natural language and require less effort?
If they're so easy to use, wouldn't the opposite be true? i.e. people who over rely on LLMs become weaker at the core competency? Nobody gives a rat's ass if you did something in an hour or took all night. The deadline is still next week because of all the meetings. What's the point? Anyone at any point in human history can tell you that doing too much too early has extremely high odds of failure. You're much better off thinking about the business concerns at hand instead of getting lost in the weeds playing with the code.
There's also zero chance of the cadence speeding up because software engineers were never the bottleneck, and LLMs don't work so well for everyone else's job.
If you can't pull rabbits out of hats when the time is right without an LLM, you're already at a disadvantage compared to everyone else who can (anyone who isn't a junior dev today).
> people who over rely on LLMs become weaker at the core competency
What if what people become weaker at, is no longer the core competency? Then people who maintain their skills at what used to be the core competency, at the expense of what is actually the core competency, will be left behind.
The rest of your comment, re: nothing taking less than a week because of meetings and software never being the bottleneck, is not something generally true across the industry. I'm sorry that that has been your experience; it does not sound pleasant.
I'd like to see evidence of this reality you're conveniently imagining to sow doubts among the uninitiated.
You're correct that the focus is no longer just writing code after a few years of experience, but it doesn't change the fact that being held accountable for the code means it is one of your core competencies.
You cannot seriously believe anyone is going to throw the baby out with the bathwater by giving away their power to "AI". Why else do you think a dev is in all those meetings? Why do they get paid to "hurry up and wait"? That's not inefficiency. That's the real work.
Those who find this reality unpleasant have always been the ones to switch careers (and then realize all careers are the same). I'm not sure what you're trying to say other than you'd like to muddy waters because you really like AI and are allergic to code and accountability. Do not be so naive.
> Why else do you think a dev is in all those meetings
Piss-poor management by scleratic and top-heavy organizations, mainly.
You're trying to start a fight by casually accusing me of stances I didn't take, mixed in with insults. There are healthier ways to deal with your insecurities.
Nothing I said is incompatible with devs being responsible for what they produce. Though you seem to be saying that someone should be fired because their code managed to hit a nondeterministic compiler bug? Why didn't they double check the assembly? They should take accountability.
Okay. Please generate using an AI model code for a safety-critical system which is able to be incorporated into an aircraft and that passes the coding standards and requirements in that domain and come back and tell us all about it. Surely, if AI was so good across the entire domain of software engineering, this would be trivial to do.
Edit: although you might be subject to an NDA... But this is pretty much my test for "AIs will take all the jobs": can it write truly safety-critical software yet?
Most programmers are not experienced enough to write such code themselves off-hand, but more importantly, the safety-critical systems are made safe by following a strict process, not by skills of individuals, which makes it orthogonal to involvement of LLMs.
Also, weird choice of example. 99.9% of coding is not safety-critical, so whatever reservations this would imply (even if it actually doesn't imply any), don't apply anyway.
Why? This has already done via existing processes. My point was to illustrate that if the future is LLMs then surely these processes wouldn't be needed anymore? After all, the LLM would just... Do it itself.
> ... the safety-critical systems are made safe by following a strict process, not by skills of individuals, which makes it orthogonal to involvement of LLMs.
And an LLM that is going to take all the jobs wouldn't be able to execute that process independently and with little oversight?
If my example is, to you, not a good one, what would you rather I use? Most of the common ones can be overly trivialized/minimized (particularly by someone who is uninterested in admitting that LLMs can't do something). That is not to imply that the gp is this kind of individual, but far too many people who I ask to do this (or something similar) are exactly that kind of person: believing that LLMs are insanely great and can't admit (or see) the cons.
Long bet: the NTSB will require all transportation software to be submitted for independent review, and that review process will be heavily automated by AI, within 5 years. Take it?
If we assume the current administration (and the following one) continues to be bullish on AI, then this is a suckers bet. Assuming the next administration isn't too busy cleaning up the messes of the current one.
I recently asked it a series of technical physics questions about a field I used to be involved in to evaluate whether it'd be useful for doing research, and literally every single answer it gave was critically wrong - even for basic questions. Its certainly true that I went "holy shit", but not in a good way
I did but it was followed by "holy shit now I gotta review this +3000 -500 LOC PR full of subtly wrong abstractions, needless diversions and incorrect assumptions".
People keep repeating your sentiment here but I simply can't follow, are we even on the same planet? Or did everyone switch to just not caring about maintainability and code quality anymore? Or are your work tasks simply so mindnumbingly, stupidly simple that even an AI can oneshot them properly?
I mean this honestly btw, not dismissively like some sister comments. The gap between the productivity increases people report on HN and what I experience myself is insane. In fact, if I factor in the procrastination I find myself doing on dotting the i's on a supposedly "one-shotted" AI implementation of a nontrivial feature, I think the AI actively slows me down.
The only way I've found that I can actually use AI productively and sustainably is in very small tight loops and, well, at that point it's not that much faster than just typing in the code (with the occasional "Cursor Tab" complete).
You have to have a team of agents with different roles reviewing that for you. An Advocate, a Skeptic, an Architect, a Security Engineer, a Disgruntled User, a Single Mom, a Clueless CTO, etc. each provides their unique prospective on the change. Then you have a Remediator and a Consolidator to address the feedback. Finally a Liquidator in case of a catastrophic failure.
I prefer to have a Clippy agent that identifies code that should be copied and pasted into random locations for no good reason. You may think it's not necessary given how LLMs operate, but I have found it's critical for 10x gains.
I think to effectively use LLMs in a controlled way, they can help with three things:
- Help you pump out boilerplate, or otherwise "obvious" code, that you can review at a glance
- Help you gain understanding, either through rapid plan writing/revision or code quality/architectural/security analysis. The gotcha is that it can only help along one axis at a time, or at least can only communicate information sensibly to humans this way
- Cross-cutting or fuzzy matching across a codebase. This is the hugest win, like "replace this pattern with the new approach everywhere". This used to be the scariest sort of task, and now it is one of the more stable things LLMs get right.
Where things go off the rail is when you want it to plan AND implement features. The blind spots of LLMs are not where they are for humans and way more work to anticipate. You have to stay on top of the bucking bronco, but you CAN move much faster if you can architect your system so more tasks fall in the "obvious" bucket - that is where the art of engineering still lives. Human understanding remains the goal.
I've had a similar experience on huge codebases written entirely by an aI. It works for very very specific cases (e.g., Opus 5 has helped me with SIMD optimizations) but I wouldn't trust it to do a 10000 LoC project even with agents just because of the complexity problem and the shear amount of code I have to review. Or I'll have to change a bunch of things because the LLM made assumpts I didn't specify and it didn't ask about (e.g.: I have had to repeatedly tell these models to use std::atomic_flag and not std::atomic<bool> for a project I maintain because for some reason I cannot fathom, they love, love using the generic std::atomic<T> template, and they love using std::atomic<bool> where an std::atomic_flag would be better). Just little things add up, and before you know it I'm spending more time fixing it's issues than I am making progress.
Very, very senior dev here who has never taken a shortcut in his life. Don't mean to sound like a prick but you're doing it wrong. You have to find your own path through this stuff. It works, promise. I was in your shoes six weeks ago.
Wait, only six weeks ago? That's not long enough to be reporting success, genuinely. Come back in a few months, bare minimum. I'm far from a skeptic, but I've also personally had a number of moments over the past 12 months where I've declared "this is the future!" about some new app I vibe-coded, or some new workflow I started following, only to abandon it a few weeks later. And it's not just me. Check back in on many of the vibe-coded projects or AI tools you see shared and you'll see the same. It's happened at my work too — people taking over entire meetings to discuss their new revolutionary AI workflow and then, a week later, nothing...
A big problem is that these codebases rot. Agents move incredibly fast at first, but then as you pay less attention (or perhaps no attention at all) to the architecture, they slowly fall to bits. So then you decide, I'll use AI to rewrite it! And it gets better for a while until, well, you get it.
That's not to say there isn't value here, there absolutely is, just — chill. A little.
Ah, the classic HN "I keep Wikipedia's list of logical fallacies on my bookmark bar" retort.
“No true Scotsman” would require me to redefine “senior developer” to exclude people who disagree with me. I didn’t.
And “you’re holding it wrong” is a strange objection to a tool that, like Git, rewards learning how to use it. The question is whether that learning pays off.
I respect the people who still haven't tried. They held a firm line when the rest of us were drawn to the shiny new thing. They're not becoming dependent on yet another centralized service (let's be real, the big centralized models are still way better than the open-weights models that most of us can run, particularly for coding). They can still develop software with nothing but their own computer, and that computer doesn't even have to be particularly new.
Nah, for what was broadly avaiable, last year it was still in the area of better custom stackoverflow answers. A good search engine for code. Helpful, but I don't remember mindblown moments.
This year we have agents work with complex codebases. That was and still is mindblown to me.
I had DeepSeek 4 Pro do a very good job yesterday of loop-unrolling and SIMD-ifying (both SSE/AVX and ARM Neon versions) some very old scalar Col3f image processing and resampling/resizing C++ code I hadn't touched in 12 years or so.
It also wrote some unit tests that validated the kernel sampling weights, and wrote some Jupyter notebooks to go along with the kernel algorithms as comparisons.
It's not just web dev... It helps (a lot in some cases) if you ask very specific things rather than just "make this vague thing", but I'm more and more coming round to the conclusion it is now a useful dev tool (until two months ago I was a sceptic).
> image processing and resampling/resizing C++ code I hadn't touched in 12 years or so.
So an unimportant, personal project. People seem to extrapolate being able to do something cool into being able to do useful work, which is what this whole discussion is about.
It's an example of useful work. 11 years ago, I would have been able to use that code in production for the company I worked at at the time, and the conversion would have been very useful.
I'm also using Github Copilot at work, but I can't as easily talk about what I'm doing there.
The tests and notebooks maybe: not the unrolling and re-architecting to use masking SIMD-ification. I used to do SIMD stuff a lot over the last 17 years, and it would have taken me probably a day to do that (convert 7 algorithms, all with support for various wrapping/mirroring/clamping extent-handling, so around 800 raw source file lines of templated C++) to use SIMD - and well.
Then it probably would have taken me at least half a day to think about what tests to write and to make them.
It did it in around 5 minutes. I had to check it, and it wasn't perfect, but it compiled, ran, and was very close.
You could convert ~800 lines of scalar float processing templated C++ code that used mixins for wrapping logic and float/double to well-optimised SIMD code for two different ISAs (without using wrapper class helpers, it wrote the full intrinsics) in under 5 minutes and write tests for them at the same time?
This is a sifferent point than what the thread started with (speed vs. correct output for hard problems). Yours stands, but it changed the direction of the discussion as I understand it. Hence the pushback.
I agree but how many developers did you know making heavy use of it? It always seemed like it was a poorly thought out experiment that gained a lot of traction and hype from the non-technical crowd. I don't say that to be elitist, I just think that non-technical users need a much more consistent and constrained product because they can't really fix and upstream things themselves (even with the use of agents). For all the hype it got, not a single person from my circle installed it to even check it out.
I do agree that the current pace of abandonware creation is wild. I think a lot of projects are generated top down from an idea, and not bottom up through usage. If you have a new experimental project, and you don't have recent commits, I assume you are not using it and thus it has no value.
I think agentic use is mostly only valuable as author extension (help you search, rubber duck, generate code but needs very heavy review). Over time with enough usage of a process I do think some of them can turn into author automation but not from simply writing down an idea. It takes lots and lots of executions, iterations, generalizations, specifications, basically lots of work to get any decently hands-off intelligent automation through agents.
Did not get bought by OpenAI. Creator was hired by OpenAI and they sponsor the project with tokens. OpenClaw is a non-profit now.
The problem is really that the promise was so big but the management and implementation was so painful, coupled with non-stop updates, coupled with far too big of an implementation surface.
A classic "lets solve 15 problems at once" situation, but none of them really well.
I was fairly skeptical of agentic coding before I used it for a real product. Although I still have to be heavily involved in planning the code that LLMs write for me, they can write code much faster than I can, and they know more about edge cases than I do, so they can handle edge cases/subtle bugs that I would have missed. I have been paid to write code at every level of the stack from assembly to frontend javascript, but I'm not equally good at all those areas. In some areas I can still outperform LLMs, but for areas I'm weak they do a much better job than I would have.
I still think of what I'm doing as software engineering, and I'm glad that I had many years of professional and hobby development before using agents since I think that's given me the ability to make good architectural decisions (and helps me resteer the LLMs when they want to do something suboptimal), but my involvement in actually writing code is quickly going to zero. That said, they aren't perfect and they still introduce bugs, but I believe the quality of my current product is higher than what I would have created pre-agentic coding.
Things I've found helpful in keeping quality high:
- Visual regression tests (detect UI bugs before you commit them)
- Fuzz testing of interfaces and app behavior
- Automatically add regression tests for any bug that I/the LLM fixes
- Logging/alerting that tracks an errors/invariant violations triggered in the app
- Performance metrics that are surfaced in a dashboard.
All of these are very easy to add since the LLM can create this infrastructure for you. The fuzz testing in particular is something very few products I've previously worked on have since most people don't know how to implement it. I ran the fuzzers for a few minutes and they quickly caught multiple subtle bugs that I was not aware of.
This is a real product that helps a real, non-VC funded service business, and although I could have made something similar myself it would have taken me a lot longer, be harder to use, and probably be less reliable.
Edit: while it's true that you can quickly blow through the $20/month plan, the $200/month plan allows you to get a lot done and is basically sufficient for my needs. It's also very cheap when you consider what it would cost to pay someone to do similar work.
Adding too many tests was a real issue before LLMs. You end up in situations where you when you add a feature there's 200 (out of e.g. 10k) tests that fail and you have to figure out which of them should fail and you need to fix them and which are actual bugs.
I haven't run into this yet. My test failures have either been real or have been triggered by an (intentional) breaking change. The later does require updating the tests, but I think catching the real bugs is worth that tradeoff. I haven't found spurious failures to be a big problem (I've had a few but rewriting the tests that have this problem has eliminated it for me). My codebase is a pretty modular rails app, which I think helps with this.
I have worked on other projects where flaky tests are a problem (and generally cause developers to ignore and submit anyways), but so far I've avoided that. My experience with flaky tests is that they're typically due to poor modularity or to subsystems that other teams can modify. This project exists in a monorepo and I'm the sole developer so that's not a problem here.
I disagree, I say the more tests the merrier, if you can afford the time cost. It's fairly rare to see faulty tests in my experience. Yes you can have hundreds failing tests and the code still works 100% - because those tests are testing API usage in a way the actual application never uses. But that's still a bug, it's just a future bug waiting to happen that you caught early. I wouldn't delete those tests.
> I was optimistic, but once I had it wired up to one of my projects, instead of making magical hands-off progress on my todo list it spent nearly my entire $20 worth of “ona compute units”, whatever those are, thrashing and trying to get a hold of the todos from linear just so it could pick one to start.
This is one of the reasons that I've simply not bothered with a lot of these types of AI products. It feels like gambling. Maybe I'll spend $20 on tokens and end up with something awesome. Or maybe I'll spend $20 on tokens and end up with nothing useful and then I'll be glad it was only $20 I lost.
There are definitely guys in some companies just pointing an agent swarm at 50 Github tickets and saying "go get 'em boys" and hence need a lot of orchestration tools but for the rest of us do we really need the AI to do all the build steps and the testing steps... or do we just need the new feature that runs when the button is clicked and then we can check it out in the browser ourselves. The code gen is what I need the AI for, not the 'smoke tests' and the tsc finagling. I'm willing to spend some mental calories myself in figuring this feature out step by step
Actually this makes me wonder if some people are just not very into building step by step like "okay first let's check the JSON shape the endpoint returns", "okay now let's make a simple form", etc
> some people are just not very into building step by step like "okay first let's check the JSON shape the endpoint returns", "okay now let's make a simple form", etc
That's accurate. There are a lot of people (some of them quite senior and/or skilled) who operate in the way you described.
The build and test steps allow the agent to self correct. Why would I want to waste my time trying out a half-finished or outright broken feature if the AI didn't even run a type checker on it to see if it even compiled?
> just pointing an agent swarm at 50 Github tickets and saying "go get 'em boys"
I still don‘t know if this is real. If it works like that, where are the companies that only kept every tenth, 10x‘d AI enhanced dev? They should have significantly higher margins. The companies that keep all devs and 10x‘d them, finally bringing that backlog to 0 should have exploding revenue and profit.
Exactly. If you can free engineering capacity from tedious busywork (fixing bugs), you have them available for implementing/delegating to implement experimental features into new revenue streams.
Why fire anyone in this scenario? Growth is only going to keep coming.
I don't think devs are that expensive relative to a big company.
Airbnbs revenue last year was 12b. If they have 1000 engineers,maybe average 200k/yr that's only 200m. If they got rid of their engineers still only a fraction of of the revenue
The product is being launched before the value is clear.
We've seen similar waves with new technologies before: overexposing the pros, dismissing the cons, hyper-optimism, and people using a lot of jargon without saying much of substance. The difference this time is the scale of the impact and the volume around it.
Its reasonable to dislike a bad product experience, but its strange to draw a conclusion of AI altogether based on a tool with limited usage (I've never heard of it).
That's like saying smart watches are useless based on trying out the smart watch made by will.i.am's tech company rather than Apple's.
I find it hard to buy this generalization about _all_ "AI"/agent software when the author has only provided _one_ example. A couple alternatives could've been explored, like Cursor Cloud Agents or even just running Claude Code with remote control on another machine. I'd also personally never spend a dime on any product unless I've read _some_ positive sentiment from online commentary, like Hacker News. To my point, Ona appears to have a pretty low amount of feedback that makes it difficult to justify any $20 bills: https://hn.algolia.com/?q=ona.com
AI is good at building "disposable" software. I think this category will grow specially for regular joes.
There's no such thing as a free lunch, and anyone trying to build software without significant guardrails and insights into the process will have to give up control of their codebase.
Ray Myers does a good job of exploring this topic in a recent Software Should Work talk, trying to answer: "Is code for people or AI?" [0]
YMMV but I think with the SOTA models building a token efficient engineering loop is absolutely doable with (imho) solid development and testing practices. I see no reason to buy a 3rd party system for this either. I'm not in enterprise so don't come at me here - I'm a small shop and I'm not trying to corral 100 devs or whatever.
We've got linear boards getting cards pushed and pulled, debated over by multiple models, coded, debated, tested, accepted, etc etc.
True software factories now exist and they don't screw up the login.
Small companies doing consulting certainly could. My use of the term "software factory" really implies a lot of automation in turning out useful tools for internal and external customers.
You see a version of this in every tech boom cycle, but this one is way more reflexive.
Mature technical software projects are slow moving because they have real users building other real software and businesses with them. Their engineering involves navigating the ecosystem and dep and compatibility constraints.
Any project moving super fast pumping out PRs either isn’t burdened/blessed with real usage OR doesn’t care about (reap real value from) the users it has.
Related theory is that the LLM “labs” are actually not particularly incentivized to prioritize stable API surfaces. They want machine interfaces to constantly rapidly change so that we must depend on model based natural language surfaces to navigate the complexity.
> But so far most of what they do is make more annoying work for me. More integrations to debug, more auth tokens to refresh, more bills to keep track of, more meandering and drawn out descriptions of non-bugs with bogus fix suggestions and misinformed “root cause” analyses. It’s tiresome.
God this times 1000. I'm so sick of having AI chase a bug and having to lead it by the hand like a toddler to try and help me solve bugs. The difference is, a toddler learns when you explain. An LLM holds your responses in context and uses them to generate more authentic sounding garbage, but next session, foomf, the lesson is unlearned again.
I had a tiny problem with prerendering not working on a react site last night, I must have spent close to an hour running commands it asked me to run like a moron, verifying dumb things I had already checked like "did the file actually upload to ftp" or had I restarted Apache or was there some magic htaccess file somewhere. Eventually I just gave up on Claude and tried some different paths in Apache virtual host settings and it worked.
Of course if I went back to Claude and reported that, as would be my instinct with a human, it would confidently explain why that was the bug, why it couldn't spot the issue, and how smart I am for finding it. And then it would forget everything tomorrow
> I'm so sick of having AI chase a bug and having to lead it by the hand like a toddler to try and help me solve bugs.
This hasn't been my experience at all. I can give it a vague description of the problem and have it find it pretty easily without any more input from me.
I do think there's a pretty big variation in tools and setups and what output people are getting. I'm now just using OpenAI Codex in VS Code and it churns through problems like they're nothing.
Sometimes I have to get it to not over-engineer a solution; not because it's necessarily wrong but because I don't need that much correctness.
Kira is probably too young (good for her! I am not cynical here) to remember how the software development worked when PHP just came out. We are at that point of time now, again.
Next stop will be Perl: write only language.
And then we will hit the "Java EE" wall.
Again.
And our LinkedIn will get red hot from recruiters looking for "experienced crisis devlopers".
Writing meaningful and correct code was always difficult. That we know how to generate pointless CRUD or half-baked apps using agents doesn't mean we can do them well. It's probably sufficient for selling them as a business but far from being great.
It seems nobody is user testing/pentesting their projects anymore. The notion of an MVP being good enough has been pushed a lot recently but it seems that the user experience of these MVPs has not been taken into consideration.
The discontent is real. The deficiencies these people mention are real. And it's not actually getting better. Sure, web devs and CRUD app devs may be screwed over a bit harder now, but when it gets into really deep complex stuff, the usability of the output goes way, way down. This cliff is real. I assure you. And it's not getting better.
Why is that strange? To me, it’s evidence of growing dissatisfaction with the direction of the field and frustration with being made to deal with the consequences of others bad work
agentic coding is real. If AI labs can take over the coding tool market, that's a billion+ market. LLMs work in coding, and AI labs can slowly expand into other white collar work. Vaporware? Hardly.
The tech is real, the use cases are increasingly forced and fabricated to justify a ludicrous valuation that will never come to pass. For research and military applications ML is great, but it isn’t going to print trillions for anyone.
I agree, the fact that with an open model I can be modifying go and react code that I'd never consider touching as a human who values their eyesight and come up with real patches, fixes and extensions of almost any project on github is truely fascinating and, addictive.
I can absolutely see where this technology works; but like EVERYTHING THAT THESE VC FUNDED FASCISTS IGNORE, just because it works in the lab does not mean it works in real life. I can see exactly where this technology fails: it lets you spool out so much thread into the abyss that you're just going to keep refactoring everything, all the time and when it blows a hole in your project, whelllp! you wanted to refactor that too. Imagine having 100 side projects grossly built and still, you just want to move on.
Fiishing projects are still going to need work and the explosion of "this is _my_ engineering harness" is everyone twiddling their thumbs cause real projects of significant value are still about scope and "total addressable market" and not "I made an AI to diddle children, so you dont have to" crowd.
I'm honestly not sure if the people writing those articles are in a different field or something. I have been coding for 20 years and there goes no day that doesn't leave me impressed.
It's nothing short of magic. And in terms of productivity, features that took months are now being done in days. I'm not even sure what the author is talking about frankly.
Was ready for some interesting music theory or analysis on genres of music that somehow map to the sound of vaporwave... but of course it's just about LLMs.
"The hard part of software engineering was never writing the code."
Again, are we still on this ridiculous concept. I stopped reading at that sentence.
Is that going to be the revisionist future that the industry tells itself - ""one day, LLMs came along and suddenly computers could program themselves, and it was an absolute revolution, but it made no difference at all to anything because "The hard part of software engineering was never writing the code." so people stopped using LLMs because of that. And that's how LLM's came to an end after being a short trend.""
I think it's true. Writing code is the most fun part of my job, but it's also the least time consuming. For any given feature, everything around the code takes 10x as much time. Getting the requirements, writing the spec, refining the spec, doing the QA work, delivery. The actual "coding" part in the middle is quick, fun, and creative. Since it's quick I get to sit and think about abstractions and performance, which is great.
But, it could be even quicker if I just give up and willingly write shitty code that works. I don't do that, but I could, and I doubt anyone outside of close developers on my team would ever notice.
The hard part was the rote memorization of leetcode challenges and then learning to pattern match to the particular problem in a 5 minute technical interview.
The second part was that the test was being administered by a gatekeeper who was hired before those practices were put in place.
The 3rd was what? Amazon or Netflix burning your ass out because they are anti-human companies?
I don't think you really deserved downvotes. Some people are more geared toward evangelizing technology (or evangelizing anything really), and some are not. I'm pretty much in the 'not' camp.
I'll share my experiences and how I do things, but I'm not about to engage in arguments about it. If you don't want to use it, then don't. What I do I care?
Exactly. So I find the sort of blog posts as TFA here quite strange, like who are they arguing against? I just follow ones that talk about how they use the tools rather than meta debates on their usage.
>If agentic development actually worked the way any of them say it does
I think its fascinating just how much of a gap there is between what's being claimed, and the verifiable observable data of the open source world. Major open source projects are by and large starting to ban LLMs now, because the contributions made by LLM users have been universally terrible and unhelpful. There doesn't appear to be a single major project that's found generating code to lead to major productivity speedups, and the consensus appears to be that its just lead to a lot of crappy contributions that are harder to spot immediately as being obvious crap
I regularly see people claim that they are now 10x more productive with LLM code generation, and I just wonder where all the code is. Is it somehow true that these gains are only being realised in proprietary projects, and not a single one of them has put even a small fraction of their new found engineering powers into eg Godot? Why do only the poor quality LLM code generation users make PRs to open source projects, and never the engineers that know how to really use it correctly?
If you look in the open source major project space, you can find almost no evidence that AI code generation exists at all. Go browse your favourite critical tool and look for AI generated PRs that have landed in the codebase, its probably a tiny handful of them in comparison to the human written PRs prior to an LLM ban. It turns out that once you have a verifiable, open quality review bar, for some reason almost no LLM commits really meet the level of quality necessary
I strongly suspect that what we're seeing is that much of the tech code-writing economy had already become completely performative prior to AI turning up. It no longer matters in the current age if your code is good, or works, because your job is to give the illusion of product development while the stock market price gets pumped, until you all cash out your share value, get bought, or hop jobs in 2 years. For many companies it literally does not matter if you produce anything that generates value (or works), because the illusion of progress is all that matters. AI is absolutely incredible at creating the illusion of progress, because it looks a whole lot like real code, it just appears to have failed the bar of making actual projects that work. If that was never the goal in the first place, it probably really is a 10x productivity boost
@antirez is a very prominent open source contributor that gets lot of shit done with LLMs. Mitchel Hashimoto is also open about using LLMs to speed up his work. There are some caveats attached: neither of them is doing crazy loops or graphs producing thousands of lines of code, they are both amazing software engineers and they know what they are doing.
Yes. Feels like the better you are at your craft the better the tools work.
AI is a power tool/factory with no safety features. Expertise is required to get anything useful from them.
Yep, much like having access to a circular saw won't make me a carpenter, having access to an LLM won't make the average person a software engineer.
> Why do only the poor quality LLM code generation users make PRs to open source projects, and never the engineers that know how to really use it correctly?
It could be that the engineers who are extremely productive with LLMs are landing PRs that look indistinguishable from good, hand-written PRs.
If so, where are all the new features in the open-source projects I use? Why hasn't GIMP replicated Photoshop? Why hasn't CUDA been fully reverse-engineered as an open source toolchain? These are unreasonable expectations, but only in response to unreasonable claims of productivity. What before took ten years should now only take one, right?
It seems likely that the gains from generating tons of code are being offset by the debt incurred to understanding what you're doing. We see lots of greenfield projects one-shotted with GPT or GLM or whatnot, but very little on the side of projects with long-term maintenance goals. This is telling, to me, that the _effective_ gains are much lower than perceived (it's lots of fun to see the thing crank out code at breakneck pace, probably contributing to this). Still quite nice, and very useful, but not a totally new paradigm.
> Why hasn't GIMP replicated Photoshop?
My guess is that open source folks overindex on being anti-AI.
They don't though, very few people were anti AI in the early days. Open source projects were largely initially very interested in LLM usage, and generally had a pro AI contribution policy. This changed when it did not help their lives
Eg if you check out Godot, initially they were cool with LLM code, and then had to clamp down on it because it was not leading to anything good
Scaling AI use in highly-collaborative environments, which open source projects are, is very challenging. I totally understand the apprehensiveness around it.
How is it challenging for open source projects? You just write a PR, and try to get it to meet the maintainer's quality bar. That's exactly how all code is written in any environment - you do code review and refine a PR until its good enough to be merged
With AI and how a lot of people use it, the quantity of written PRs goes up, but the quality goes down, and the maintainers of the project, who are often volunteers, now have to deal with this in addition to the standard work they've been doing before.
This doesn't seem to match the claims of 10x productivity that are being levied though. In fact it seems like the overall productivity is lower
Yeah, why hasn't AMD added every single CUDA feature lol
Why are Amazon and Walmarts mobile apps still janky crap that costs them money? Why does Meta still have four redundant, broken sign-up flows before you can give them money to advertise?
Wherever these “10000x” engineering gains are… I’m wondering why they’re only for shit nobody sees or touches.
Those websites are janky despite having all the (non AI) solutions available already. They suck for reasons independent of the quality of LLMs. I have not worked inside a megacorp but my understanding is they suck because of what are essentially political roadblocks within the organisation.
If that were true, we'd expect to see massively accelerated velocity of open source projects by these engineers. They should be creating new open source projects at a truly astounding rate, with new tooling springing up every day that dwarfs the existing open source space as their productivity completely eclipses traditional development
Instead, software is plodding along exactly the same as it did prior to LLM code generation, and there's no evidence of superprogrammers making superprojects in 1/10th of the time. With a 10x productivity gain, what used to take a year should take a month
I think what you're missing is that there are new open source projects being created at a very fast rate.
But that doesn’t mean they stick.
And the core issue isn’t AI, it’s that… a successful, highly adopted project requires time for people to know it exists, adopt it, and also time by the maintainer growing community and ensuring reliability. The people factor is more important. I see tons of new projects, but I’m not going to pick a brand new project that has high odds of being abandoned. I’m going to pick the one that consistently maintains it and has some adoption already.
I have seen engineers create very successful internal projects fairly quickly. And yes, a project that would have taken a year taking a month. And offering a lot of extra bells and whistles that you just wouldn’t have time for.
But these are greenfield internal projects, and the bar is much, much lower for those.
I have seen multiple internal incidents root-caused by an agent faster than the humans responding. Just because it can go up and down rabbit holes a lot faster.
The problem is that AI solves one bottleneck, but not others. One team member produces a huge amount of new PRs. (Like 12 solid enhancements and big fixes in a couple hours.) Now I have less time because I’m reviewing that. And we’re all context switching a lot more.
On top of that, I find AI workflows continue to be deeply immature, even though certain models are very effective and very good at troubleshooting.
The story around testing is not really improving for example. AI can write tests, but are they good? I don’t think we have much actually ensuring product quality and reliability automatically. Unit tests are not enough.
Collaboration is very poor too. Coworkers agent creates PR, and now I’m reviewing it, and now he sends my comments back to his agents… really clunky workflow especially since I’m ACTUALLY just prompting his agent.
Plus, certain models (Opus) are getting much worse at writing. I will not use Opus any more because the writing style is so horrible.
The constant change means approaches that worked well a couple months ago don’t work well today. And there are no real experts, because no one’s been doing this for long. And half the posts and learning out there are outdated, or straight up blogspam.
This makes it hard for people to learn and get better, despite the fact that models like Sol 5.6 are effective troubleshooters, and write decent code.
Github's Octoverse report kind of gives you that evidence, no? Pull requests landed in 2025 were up 30% over 2024. This year it's going to be much higher.
That's the point. Huge increases in pull requests. Virtually no increase in features or reliability.
[dead]
LLM code is obvious to spot. If an LLM designed a screwdriver set it would make a screwdriver for each head instead of making a replaceable head.
LLMs are superhuman at short term coding such as debugging and writing tests though and you're missing out by not using them there.
> LLM code is obvious to spot. If an LLM designed a screwdriver set it would make a screwdriver for each head instead of making a replaceable head.
Commercial and industrial electricians are LLMs now?
So... basically an autocomplete to help you type faster and spot check if you did something unusual in the parts you wrote by hand?
I'm coming to the conclusion that the right way to use LLMs for code generation is asking it to solve specific problems, giving it existing code and asking it how it would propose changing something or other, or if it has an alternative to an existing logic flow that's problematic and asking it what it thinks the problem is and how it would suggest it be written.
I'm coming from the perspective of infra management so that's my bias, and a very complex code base may make my perspective off mark.
But nowhere does it seem it to be a good idea for the whole thing to be LLM generated. It seems to view a big holistic problem in steps in isolation, causing it to add complexity on top of complexity as it's going through it's later stages. For example it'll create infrastructure designs that add layers of unnecessary and redundant tooling and business logic, when a human would have re evaluated step 1's path when it realized step 3 was doing the same thing again in a more complex way.
> I strongly suspect that what we're seeing is that much of the tech code-writing economy had already become completely performative prior to AI turning up. It no longer matters in the current age if your code is good, or works, because your job is to give the illusion of product development while the stock market price gets pumped, until you all cash out your share value, get bought, or hop jobs in 2 years.
I think this is probably the answer. Working as a professional software engineer actually has very little to do with writing good code and maybe never has. The job is to “ship products”, and as long as you keep up a sufficiently convincing illusion of progress toward that end the bills get paid and nobody really cares about the impact on end users.
Major open source projects are by and large starting to ban LLMs now, because the contributions made by LLM users have been universally terrible and unhelpful.
There are two incentives for contributing to open source. The first is to make the app better (add a feature, improve the code, fix a bug, etc.) It's possible that LLMs don't meet the bar but if a human has put the effort in it's not always obvious that it's AI. More likely LLM code is accepted when it's good and rejected when it's bad. The system works.
However, the second incentive is that open source contributions are seen as a 'ahortcut' to making a name for yourself. Being a contributor on a big project goes on resumes and GitHub profiles. Often people who use AI for that don't review the code or even check it does what they say it does. That slop needs to be banned. The downside is losing the good contributions, but it's still a net win.
We have a greenfield project at our company, yes proprietary, now taking us months where previously it'd have taken weeks for even a single feature. We definitely see the (whatever)x performance boost with our own eyes.
Its always been possible to trade long term productivity for short term gains with technical debt. This is why the bar I'm interested in is long term projects, which have proven to have long term success, instead of a small disposable project where the code quality doesn't matter
Difference is whether it's a false dichotomy now, because models like Fable can write better code than most devs I know.
Then why isn't it showing up in open source at all? The people who file PRs are just regular average devs, but the quality of LLM PRs seems to be universally crap in comparison
> now taking us months where it'd have taken weeks...
So 0<whatever<1
Nah, the GP's claim is weeks for each feature, versus a few months in total. On a greenfield project.
Weeks for each feature in a greenfield project... Yeah, LLMs make unworking code way faster than that.
Feature vs full project timeline
Or maybe open-source development is just poorly compatible with AI workflow? Today, projects may need a community, an issue tracker, but pull requests are becoming less important.
I suspect the ban of AI in established projects to be a very complex decision. Even if core developers would like to use AI, they don't want to review all of the AI-generated code from the larger community. So the only consistent way to preserve sanity is to declare that nobody would use it. Good luck enforcing it though!
Why would the PR format be bad for LLMs? Its just code review + merging in branches, which is what every company should be doing anyway
Nothing's stopping core developers from adopting LLM generated code for themselves, while banning it for external contributors
> Nothing's stopping core developers from adopting LLM generated code for themselves, while banning it for external contributors
And if they're doing that, why would they tell you, or anyone?
And if they're doing that responsibly - collaborating with AI, and reviewing the code - they don't even have an ethical reason to tell about AI involvement, any more than telling about the StackOverflow answers or blog posts they read before coming up with some implementation.
If they were sneaking LLM generated code into these projects, we'd expect to see their feature development 10x even if they covertly aren't telling anyone. Which open source codebases have seen a truly massive 10x increase in delivered feature velocity since AI turned up? Where are all the new contributors who contribute features at 10x the rate of the existing meatcoding developers?
Then all it'd take is one of these engineers blowing the lid on their whole secret LLM contribution strategy to absolutely break the industry wide open to the benefits of these massive productivity increases, and finally prove all the doubters wrong. They sure are good at keeping secrets that would directly benefit them to expose
Nah this take is wrong. I used Claude code with my custom skill and I wrote a more performant scheduler than the default Linux one in Rust.
It's not just productivity, it's life changing.
Sure, it just seems a little odd that no LLMgineer ever contributes their incredible more performant scheduler back though right? After all if you can do it with claude, anyone can, all it'd take is to ask claude to rewrite it. Linux accepts LLM generated PRs, all the code has to do is meet the review bar and one of the most critical pieces of software engineering on the planet gets better for everyone
Why does it seem odd when people who do attempt to contribute back are attacked?
AI lowers the bar to making submissions which permits flawed subissions to be thoughtlessly submitted by people who don't really understand what they are doing, technically or culturally.
It does, however, enable people who put in the effort to work on something significant. Those people are fewer in number, but exist. They do get to see the animosity that unwitting novices receive.
I don't think it would be surprising for those people to opt out of engaging with a toxic environment.
You'd think one 10x engineer or one core developer already part of the project would have completely eclipsed all the other engineers, and worked around the difficulties there
Or, failing that, you'd think any of these engineers - given the truly vast amount of programming power now available at their fingertips with their 10x productivity - would have simply replaced these projects. It'd only take a few 10xers who wanted to show that everyone else was wrong. That's how open source often works, someone just gets a been in their bonnet and then we get linux
Instead: I can't find any of it. There's no evidence of this productivity boost in the wild. There aren't new high quality 10x open source projects springing up that are replacing everything. There aren't high quality LLM contributions, feature development isn't going faster. There's almost no evidence of high quality AI code generation at all in the open source space, existing projects or otherwise
Where's all the code? I want the receipts if people are claiming a 10x productivity. Because at the moment, the much more likely explanation seems to be that its simply not true
I can't point you at any because I don't want to send a mob their way.
For any instances where people have made things and revealed them to the world have been declared to have been grossly flawed by being held to a standard of scrutiny that no person usually gets.
It seems everyone is Cardinal Richelieu now.
People are attacked for low quality. There are counter examples but it is definitely striking how infrequently you see a PR which doesn’t stand out for being turgid or flawed, and whose author clearly expects a cookie for their “contribution” of a couple minutes of prompting.
Are you alleging that there are far more things that takes no effort than things that takes quite a lot of effort,
You might have something there.
It probably holds true for a lot of things. Either that or most gutairs sold are defective.
Non-falsifiable statements aren't going to work here anymore.
What's the point of writing great software if nobody else is going to use it, and how do we even confirm there are these alleged secret geniuses hiding away somewhere? Surely their work would leak out by some nth-order effect.
What statement did I make that was unfalsifiable?
I made a claim that absence of evidence is not evidence of absence.
That is not a claim of existence.
If you want to see contributions to Linus that used AI you can search for commits with tags that look like this in their commit message:
This search on GitHub seems to find about 2,000 of those: https://github.com/search?q=repo%3Atorvalds%2Flinux+assisted...... but if you clone the git repo you can get an exact count of 824 commits (not sure why the search over-counted).
Here's a good candidate for a material performance improvement:
https://github.com/torvalds/linux/commit/e1bf79628453e6afac8...
I would submit it but the pr was too long to fit on GitHub
… doesn’t Linux work through email, not GitHub?
It's a reference to Fermat's note.
Here are a few examples you might find credible:
- pola-rs/polars: https://github.com/pola-rs/polars/pull/26823 - ~2.68x median speedup of primitive-to-boolean casting credited to Claude Opus 4.6
- pydantic/monty: https://github.com/pydantic/monty/pull/643 - ~53x speedup (488ms down to 9.2ms) of bytes substring search generated with Claude Code
- numpy/numpy: https://github.com/numpy/numpy/pull/31573 - ~21x speedup of Python datetime → datetime64 conversion, with Claude Code used for profiling and implementing the performance improvements
- apache/datafusion: https://github.com/apache/datafusion/pull/21182 - up to 49x speedup of LIMIT queries by eliminating unnecessary sorts and pushing limits into file scans, generated with Claude Code
- apache/datafusion: https://github.com/apache/datafusion/pull/21651 - ~4.39x speedup of ClickBench Q6 by resolving MIN/MAX directly from Parquet metadata instead of scanning columns, generated with Claude Code
- pola-rs/polars: https://github.com/pola-rs/polars/pull/27958 - ~3.2x speedup of Int8 Series sum, developed with assistance from Claude Fable and Claude Opus 4.8
- numpy/numpy: https://github.com/numpy/numpy/pull/31274 - up to ~1.44x speedup of common small NumPy reductions, with the fast path written by Claude Code and manually refined
That's a fair use case for them though. LLMs are superhuman at short term performance engineering/debugging/testing. But even that comes with the caveat that these commits come from talented coders using LLMs as a grad student. I think that OP is against the claim that "agent in a loop beats a talented human at long term coding tasks".
Because if it was true then open source projects such as GIMP could basically be as feature heavy as Photoshop overnight.
I, too, will reject the idea that "agent in a loop beats a talented human at long term coding tasks".
LLMs amplify existing expertise. Give them to experts and you can get fantastic results. Give them to amateurs and you might get the occasional impressive demo, but you're not going to get anything that a responsible software team would commit to maintaining in the long term.
I'm choosing to interpret this as very dry sarcasm.
With the "It's not X, it's Y" at the end I sure hope that it's the case.
You can tell that a human wrote it because X is a noun and Y is an adjective
[dead]
> I regularly see people claim that they are now 10x more productive with LLM code generation, and I just wonder where all the code is.
Perhaps the biggest issue hasn't been the speed of development all along but people working on wrong things, hence why progress isn't as evident. LLM helping to build something that isn't needed faster isn't going to productivity more visible.
There's no reason that some people wouldn't be using their new found 10x superpowers on open source projects though
I use my powers to finish my own projects (until the next creative barrier) while my professional workload has been reduced to 20% effort with 0 stress.
I wrote a game I left in a folder from 11 years ago in 2 months, front and back plus all the tooling, plus features I never would have attempted before. I recreated open-sourced projects from github, written in a language I wasn't familiar with, so I could better work with the application and include it in my backend codebase.
I rewrote my mail server in less than 2 days, which took me over 2 weeks to configure and setup the last time.
My life is easier, because the demands are the same but I have more free time. I research more, I learn more, and I try more things. Just like any software project, some are abandoned (even with LLMs) when running into unforeseen issues or mismatches with theoretical plans. Most importantly, I can make things that I think are exciting, with very little effort. The first 35 years of development, I struggled to be good enough to tackle sourcing various projects without becoming frustrated and mostly knowing myself well enough to avoid trying at all.
Now I can see myself writing passion projects until I'm dead.
I find it game changing for experimental work and prototyping. As a research scientist this is a major bottleneck and clean code is often not the right optimization target.
> I think its fascinating just how much of a gap there is between what's being claimed, and the verifiable observable data of the open source world.
According to this list of top Github repos by stars[1], of the top 10, nine of them are informational and one is OpenClaw, which certainly has plenty of AI generated code.
The next 10 include react which has a CLAUDE.md and a .claude, and lots of landed PRs that look like AI. And linux, which, we all read Linus' stance. He sees the value. And superpowers, ECC, and hermes-agent. All of which are AI stuff.
I think it would be reasonable to ask which major open source projects aren't using AI assistance?
> Major open source projects are by and large starting to ban LLMs now, because the contributions made by LLM users have been universally terrible and unhelpful.
That is not why. Or at least not the majority of it. The biggest part is that maintainers just can't keep up. They don't have time to do in depth reviews for the number of PRs coming in to find out if it: works, does what it says it does, meets a need, has docs, is well written, meets criteria, etc. That does not mean all those PRs are trash. Some might be trash, some might be gold. Just like human generated ones.
What it comes down to is vibes. Anti-AI folk don't like AI for reasons (that are valid) and they don't want to find any value in it. So they don't. But lots of people are. Lots of really cool, interesting, clever, new software is being written and getting used and building communities but people see CLAUDE.md and go "slop, no thanks" and won't even give it a try.
[1]: https://github.com/EvanLi/Github-Ranking/blob/master/Top100/...
>I think it would be reasonable to ask which major open source projects aren't using AI assistance?
Where are all the vast quantity of LLM commits for these open source projects, if these engineers are truly 10xing their productivity with LLM code generation? Because I regularly browse the source of many of these, and can find almost no evidence that LLM code generation is anywhere near the level of productivity being claimed for:
1. ImGui
2. SFML
3. SDL
4. GLFW
5. OpenSSL
6. Linux
7. GCC
8. Clang/LLVM
9. Libc++/libstdc++/msstl
10. Rust
11. Godot
12. Nlohmann
13. Boost
14. Python
15. GNU tools
Etc etc. There are even more major projects, but these are just the critical ones I can think of off the top of my head. If you go for a browse though eg Godot, you might think that LLMs don't exist. In fact if you go for a browse through any of these, you might think that LLMs are borderline never used for code generation in the open source world. This is a diverse collection of random projects, and yet for some reason none of these have experienced a 10x increase in productivity in any form from any contributors from LLM code generation
>That is not why. Or at least not the majority of it
Its not the quantity, if maintainers were receiving incredibly high quality PRs that could just be merged, they'd be very happy. Godot is an example of a project that was initially pro LLM, and then had to about face because the PRs were just absolutely crap
>Some might be trash, some might be gold
Is there any evidence that any of these PRs have ever been gold?
You have to consider that there is a chilling effect in the open source space because llm use has now become an ideological battle, and people have lost their collective minds over it.
Bun did a nearly 100% hands off keyboard rewrite. And people largely ridiculed the effort with mud slinging and goal post moving.
There are plenty of measurable examples of the productivity boost when there is a well defined oracle, such as rewrites and (kind of)formally verified specifications.
I've got an agent harness that I built that decompiles games. Don't want to dox myself on this account, so this is all I'll say about it.
I may have been able to decompile 1 game a year into readable source. Now I can offload nearly all of that process to an Nvidia 5090 and the extremely cheap deepseek v4 flash.
With dedicated focus and a lot of personal time, or employer time, I may have been able to reconstruct a good amount of react linting rules to biome. But instead, by focusing on a harness that can prove parity, I can get all of the rules ported while I sleep or solve other institutional problems.
Once you can prove the outcome, however hard or soft you need based on the domain, the output gains are literally undeniable.
Imo the vaporware is all of these "one-shot" projects that people love to show off. Once the market corrects and the hypecycle dies down theres going to be a lot of interesting engineering in this space. Right now there's a bit of a Cambrian explosion of ideas, and for better or worst that space fills up with the over the enthusiastic and chareltons.
Fragmented thoughts I'm typing while walking, the point is murky
> Why do only the poor quality LLM code generation users make PRs to open source projects, and never the engineers that know how to really use it correctly?
Selection bias? OSS has a thing proprietary projects don't - an endless cohort of opportunists trying to wedge in a "contribution" for personal gain, be it a Hacktober t-shirt or resume boost or an occasional vulnerability (with the resume boosting being by far most likely). The good LLM-based contributions, you probably won't recognize as AI-assisted unless the author explicitly decided to label them, and if they're really good and use LLMs responsibly, they probably don't even have any ethical obligation to label LLM involvement, much less any benefit.
OSS involvement in general stopped being an indicator of skill once Github activity became a factor for job applications.
Edit:
There's also a second factor: many people (myself included) use LLMs to code one-off personal tools with no intent of them having more than one user, ever. Get an itch, have an LLM scratch it for you, carry on with your life. You'll see little trace of it, because it's hard to distinguish a single-user program that's good enough for specific purpose from a pile of autogenerated slop that probably doesn't work, and neither of these will show up as PRs to big OSS repos anyway.
The the idea that engineers are covertly sneaking huge quantities of LLM generated code into these projects doesn't pass the smell test, as there's lots of evidence that this isn't true. It'd be incredibly obvious if new contributors were turning up en masse and contributing absolutely incredible amounts of high quality code, because everyone would be crowing about it
Instead, if you check out something like ImGui, we can see that its largely just Omar as usual with a bunch of PRs. Nothing much seems to have changed, feature development carries on at the same pace as it did previously. This is replicated across nearly every single major long term open source project I can find
The only reason developers now feel the need to hide their LLM usage is because the LLM contributions have all been shockingly bad, so you're reversing cause and effect. If LLM contributions had been incredible, they wouldn't be frowned upon socially now. Surely someone would blow the lid on this huge covert conspiracy about how incredible their contributions to.. SFML have been?
This effect also wouldn't prevent LLMgineers from creating their own open source projects that should be absolutely outstripping the existing open source space. After all how old is ImGui? With a 10x productivity gain, it should take a year of development to easily match its features if those gains are truly real now
>if they're really good and use LLMs responsibly, they probably don't even have any ethical obligation to label LLM involvement
The copyright issues means that non disclosure is inherently unethical
> The only reason developers now feel the need to hide their LLM usage is because the LLM contributions have all been shockingly bad, so you're reversing cause and effect. If LLM contributions had been incredible, they wouldn't be frowned upon socially now
You're dismissing scale of things. OSS communities were having high-profile discussions about gatekeeping and discrimination way before LLMs were a thing, because already at that point the amount of human generated slop was becoming untenable. And yet, no one argued that this must be evidence that all human contributions are bad and humanity is a bubble waiting to pop.
> ImGui
Weird choice of an example. ImGui is common infrastructure. Who in their right mind would want to mess with that? Especially when building something to solve some end-user problem (whether N=1 or N=1 billion), ImGui is a component you include, not one you rewrite.
There's hardly any reason anyone has to contribute to that project, with or without LLMs.
LLMs work well for boring stuff that other people have already done a hundred times. Where the LLMs fail is solving difficult problems that aren't explored as well. The people seeing the 10x speed up are likely just doing CRUD apps or other software that have already been well documented by Stack Overflow or cloned a million times on Github. In my own use, it completely breaks down when for solving actually difficult things.
I don't know how you can claim it's all vapour ware.
Two years ago, I couldn't just roughly describe my backlog and then have the code fixed. I had to type it out myself, run it, look at logs, fix toolchain issues, and so on. It was tedious. Or I could get a junior to do it.
Now can get these things done quite fast, without concentrating nearly as hard.
Clearly, it isn't vapour.
It delivers something. That something we have yet to figure out the best way to use, but there's definitely something there that works.
I get the feeling a lot of people are frustrated because the little gains are lost in organisational chaos, rather than the tools not working.
On your last point, I think it has a lot to do with how it's introduced in organizations. If everyone just goes hog wild with it, enamored with their newfound productivity, not only will the little gains be lost, I'd argue all the generated noise will be a net negative. And people will hate that.
That's the result of AI adoption in a company being people just getting a subscription and doing their own thing, instead of systematically introducing and finding a common ground; a trivial example of that would be open source projects increasingly adopting LLM policies to get everyone on the same page.
It's August 9, 2026 and if you're a software engineer who hasn't had multiple "holy shit, I can't believe it just did that" moments, it's time to consider a new trade.
I find this to be an incredibly myopic viewpoint. Software engineering is not defined by a single tool or technology, but rather how we design, implement, and maintain processes of value we want to automate or scale.
LLMs will certainly be an aide, but assuming adoption of them is required across a whole _field_ ignores whole classes of problems, domains, and constraints the production of software covers.
Rather, we should be wary of allowing our skills and hard-earned knowledge to atrophy by over reliance on new technology that is far from perfect, reliable, or even universally available. These tools more than any before suffer from the junk-in-junk-out problem and I’d much rather work with someone who knows their fundamentals than someone who knows their way around a the LLM of the month.
On the contrary, taken at face value I find the GP comment to be spot on.
They aren't saying LLM adoption is required across 100% of the field. They are pointing out that LLMs have reached an impressively capable state, and someone insufficiently inclined to test new tooling that they still dismiss LLMs as "just fancy autocomplete" is exactly who gets left behind when technology advances.
Two things can be true at the same time, 1) that LLMs are not required across a whole field, and 2) that software engineers unwilling to acknowledge their utility have as much a place in the future as the software engineers of 50 years ago who refused to use a compiler.
Can you elaborate on how someone would get "left behind"? Isn't the whole point of LLMs that they use natural language and require less effort?
If they're so easy to use, wouldn't the opposite be true? i.e. people who over rely on LLMs become weaker at the core competency? Nobody gives a rat's ass if you did something in an hour or took all night. The deadline is still next week because of all the meetings. What's the point? Anyone at any point in human history can tell you that doing too much too early has extremely high odds of failure. You're much better off thinking about the business concerns at hand instead of getting lost in the weeds playing with the code.
There's also zero chance of the cadence speeding up because software engineers were never the bottleneck, and LLMs don't work so well for everyone else's job.
If you can't pull rabbits out of hats when the time is right without an LLM, you're already at a disadvantage compared to everyone else who can (anyone who isn't a junior dev today).
> people who over rely on LLMs become weaker at the core competency
What if what people become weaker at, is no longer the core competency? Then people who maintain their skills at what used to be the core competency, at the expense of what is actually the core competency, will be left behind.
The rest of your comment, re: nothing taking less than a week because of meetings and software never being the bottleneck, is not something generally true across the industry. I'm sorry that that has been your experience; it does not sound pleasant.
I'd like to see evidence of this reality you're conveniently imagining to sow doubts among the uninitiated.
You're correct that the focus is no longer just writing code after a few years of experience, but it doesn't change the fact that being held accountable for the code means it is one of your core competencies.
You cannot seriously believe anyone is going to throw the baby out with the bathwater by giving away their power to "AI". Why else do you think a dev is in all those meetings? Why do they get paid to "hurry up and wait"? That's not inefficiency. That's the real work.
Those who find this reality unpleasant have always been the ones to switch careers (and then realize all careers are the same). I'm not sure what you're trying to say other than you'd like to muddy waters because you really like AI and are allergic to code and accountability. Do not be so naive.
> Why else do you think a dev is in all those meetings
Piss-poor management by scleratic and top-heavy organizations, mainly.
You're trying to start a fight by casually accusing me of stances I didn't take, mixed in with insults. There are healthier ways to deal with your insecurities.
Nothing I said is incompatible with devs being responsible for what they produce. Though you seem to be saying that someone should be fired because their code managed to hit a nondeterministic compiler bug? Why didn't they double check the assembly? They should take accountability.
Okay. Please generate using an AI model code for a safety-critical system which is able to be incorporated into an aircraft and that passes the coding standards and requirements in that domain and come back and tell us all about it. Surely, if AI was so good across the entire domain of software engineering, this would be trivial to do.
Edit: although you might be subject to an NDA... But this is pretty much my test for "AIs will take all the jobs": can it write truly safety-critical software yet?
Okay. Please write such a system yourself.
Most programmers are not experienced enough to write such code themselves off-hand, but more importantly, the safety-critical systems are made safe by following a strict process, not by skills of individuals, which makes it orthogonal to involvement of LLMs.
Also, weird choice of example. 99.9% of coding is not safety-critical, so whatever reservations this would imply (even if it actually doesn't imply any), don't apply anyway.
> Okay. Please write such a system yourself.
Why? This has already done via existing processes. My point was to illustrate that if the future is LLMs then surely these processes wouldn't be needed anymore? After all, the LLM would just... Do it itself.
> ... the safety-critical systems are made safe by following a strict process, not by skills of individuals, which makes it orthogonal to involvement of LLMs.
And an LLM that is going to take all the jobs wouldn't be able to execute that process independently and with little oversight?
If my example is, to you, not a good one, what would you rather I use? Most of the common ones can be overly trivialized/minimized (particularly by someone who is uninterested in admitting that LLMs can't do something). That is not to imply that the gp is this kind of individual, but far too many people who I ask to do this (or something similar) are exactly that kind of person: believing that LLMs are insanely great and can't admit (or see) the cons.
If he’s such a good pediatrician, would you allow him to do brain surgery on you?
Long bet: the NTSB will require all transportation software to be submitted for independent review, and that review process will be heavily automated by AI, within 5 years. Take it?
If we assume the current administration (and the following one) continues to be bullish on AI, then this is a suckers bet. Assuming the next administration isn't too busy cleaning up the messes of the current one.
I recently asked it a series of technical physics questions about a field I used to be involved in to evaluate whether it'd be useful for doing research, and literally every single answer it gave was critically wrong - even for basic questions. Its certainly true that I went "holy shit", but not in a good way
Can you give an example? I've actually been pretty happy with how the latest ChatGPT answers senior-undergrad level physics questions.
I did but it was followed by "holy shit now I gotta review this +3000 -500 LOC PR full of subtly wrong abstractions, needless diversions and incorrect assumptions".
People keep repeating your sentiment here but I simply can't follow, are we even on the same planet? Or did everyone switch to just not caring about maintainability and code quality anymore? Or are your work tasks simply so mindnumbingly, stupidly simple that even an AI can oneshot them properly?
I mean this honestly btw, not dismissively like some sister comments. The gap between the productivity increases people report on HN and what I experience myself is insane. In fact, if I factor in the procrastination I find myself doing on dotting the i's on a supposedly "one-shotted" AI implementation of a nontrivial feature, I think the AI actively slows me down.
The only way I've found that I can actually use AI productively and sustainably is in very small tight loops and, well, at that point it's not that much faster than just typing in the code (with the occasional "Cursor Tab" complete).
Am I doing something wrong?
You have to have a team of agents with different roles reviewing that for you. An Advocate, a Skeptic, an Architect, a Security Engineer, a Disgruntled User, a Single Mom, a Clueless CTO, etc. each provides their unique prospective on the change. Then you have a Remediator and a Consolidator to address the feedback. Finally a Liquidator in case of a catastrophic failure.
You forgot Boot the Dog who simply wakes up periodically to check if the crypto rugpull is ready
Ah, Poe’s law… my favorite
I prefer to have a Clippy agent that identifies code that should be copied and pasted into random locations for no good reason. You may think it's not necessary given how LLMs operate, but I have found it's critical for 10x gains.
I can see how that agent can be useful in certain scenarios. We just introduced a Cheering agent to help with moral.
I think to effectively use LLMs in a controlled way, they can help with three things: - Help you pump out boilerplate, or otherwise "obvious" code, that you can review at a glance - Help you gain understanding, either through rapid plan writing/revision or code quality/architectural/security analysis. The gotcha is that it can only help along one axis at a time, or at least can only communicate information sensibly to humans this way - Cross-cutting or fuzzy matching across a codebase. This is the hugest win, like "replace this pattern with the new approach everywhere". This used to be the scariest sort of task, and now it is one of the more stable things LLMs get right.
Where things go off the rail is when you want it to plan AND implement features. The blind spots of LLMs are not where they are for humans and way more work to anticipate. You have to stay on top of the bucking bronco, but you CAN move much faster if you can architect your system so more tasks fall in the "obvious" bucket - that is where the art of engineering still lives. Human understanding remains the goal.
Thanks, this is helpful
I've had a similar experience on huge codebases written entirely by an aI. It works for very very specific cases (e.g., Opus 5 has helped me with SIMD optimizations) but I wouldn't trust it to do a 10000 LoC project even with agents just because of the complexity problem and the shear amount of code I have to review. Or I'll have to change a bunch of things because the LLM made assumpts I didn't specify and it didn't ask about (e.g.: I have had to repeatedly tell these models to use std::atomic_flag and not std::atomic<bool> for a project I maintain because for some reason I cannot fathom, they love, love using the generic std::atomic<T> template, and they love using std::atomic<bool> where an std::atomic_flag would be better). Just little things add up, and before you know it I'm spending more time fixing it's issues than I am making progress.
Very, very senior dev here who has never taken a shortcut in his life. Don't mean to sound like a prick but you're doing it wrong. You have to find your own path through this stuff. It works, promise. I was in your shoes six weeks ago.
Wait, only six weeks ago? That's not long enough to be reporting success, genuinely. Come back in a few months, bare minimum. I'm far from a skeptic, but I've also personally had a number of moments over the past 12 months where I've declared "this is the future!" about some new app I vibe-coded, or some new workflow I started following, only to abandon it a few weeks later. And it's not just me. Check back in on many of the vibe-coded projects or AI tools you see shared and you'll see the same. It's happened at my work too — people taking over entire meetings to discuss their new revolutionary AI workflow and then, a week later, nothing...
A big problem is that these codebases rot. Agents move incredibly fast at first, but then as you pay less attention (or perhaps no attention at all) to the architecture, they slowly fall to bits. So then you decide, I'll use AI to rewrite it! And it gets better for a while until, well, you get it.
That's not to say there isn't value here, there absolutely is, just — chill. A little.
To be fair, a "very very senior dev" wouldn't tell me that I'm doing it wrong without telling me what I'm doing wrong.
I've tried. It's like trying to teach squirrels how to Google. Really, you just have to figure out what works for you. You will be rewarded.
This combination of "no true scotsman" and "you're holding it wrong" is quite amazing to behold.
If AI is as good as it being marketed as, you shouldn't even be able to hold it wrong!
Ah, the classic HN "I keep Wikipedia's list of logical fallacies on my bookmark bar" retort.
“No true Scotsman” would require me to redefine “senior developer” to exclude people who disagree with me. I didn’t.
And “you’re holding it wrong” is a strange objection to a tool that, like Git, rewards learning how to use it. The question is whether that learning pays off.
A very very senior dev can use LLMs with confidence and definitely doesn't get surprised by them.
People review PRs? LGTM.
Mr lucky over here with an agent that removes code!
Fair, that was unrealistic. One day, maybe!
Oh, I have those moments daily. Like, "holy shit, I can't believe it just fucked up a rote task this badly".
I have been doing this stupid shit for long enough that, frankly, I am only happy when it does exactly what I intended.
[flagged]
I respect the people who still haven't tried. They held a firm line when the rest of us were drawn to the shiny new thing. They're not becoming dependent on yet another centralized service (let's be real, the big centralized models are still way better than the open-weights models that most of us can run, particularly for coding). They can still develop software with nothing but their own computer, and that computer doesn't even have to be particularly new.
[flagged]
Nah, for what was broadly avaiable, last year it was still in the area of better custom stackoverflow answers. A good search engine for code. Helpful, but I don't remember mindblown moments.
This year we have agents work with complex codebases. That was and still is mindblown to me.
Don't make new accounts just to add snarky responses. If you're gonna do it, use your real account so we know who to flag.
I'll worry when that stops happening. Probably means I'm getting in my own way or not thinking big enough.
[flagged]
Learning is lifelong, in most trades. What are you on about? Especially in something vast as programming/SW/ops.
That's exactly my point — by now you should have learned enough not to be surprised.
Not everyone is a web developer bub
I had DeepSeek 4 Pro do a very good job yesterday of loop-unrolling and SIMD-ifying (both SSE/AVX and ARM Neon versions) some very old scalar Col3f image processing and resampling/resizing C++ code I hadn't touched in 12 years or so.
It also wrote some unit tests that validated the kernel sampling weights, and wrote some Jupyter notebooks to go along with the kernel algorithms as comparisons.
It's not just web dev... It helps (a lot in some cases) if you ask very specific things rather than just "make this vague thing", but I'm more and more coming round to the conclusion it is now a useful dev tool (until two months ago I was a sceptic).
> image processing and resampling/resizing C++ code I hadn't touched in 12 years or so.
So an unimportant, personal project. People seem to extrapolate being able to do something cool into being able to do useful work, which is what this whole discussion is about.
It's an example of useful work. 11 years ago, I would have been able to use that code in production for the company I worked at at the time, and the conversion would have been very useful.
I'm also using Github Copilot at work, but I can't as easily talk about what I'm doing there.
What do you consider useful work?
This is still rather basic stuff to be absolutely honest with you.
The tests and notebooks maybe: not the unrolling and re-architecting to use masking SIMD-ification. I used to do SIMD stuff a lot over the last 17 years, and it would have taken me probably a day to do that (convert 7 algorithms, all with support for various wrapping/mirroring/clamping extent-handling, so around 800 raw source file lines of templated C++) to use SIMD - and well.
Then it probably would have taken me at least half a day to think about what tests to write and to make them.
It did it in around 5 minutes. I had to check it, and it wasn't perfect, but it compiled, ran, and was very close.
Sorry, but this is just not a complex or hard task in image processing. Image resizing is a staple algorithm as common as bread and butter.
You could convert ~800 lines of scalar float processing templated C++ code that used mixins for wrapping logic and float/double to well-optimised SIMD code for two different ISAs (without using wrapper class helpers, it wrote the full intrinsics) in under 5 minutes and write tests for them at the same time?
It's the time compression I'm impressed with.
This is a sifferent point than what the thread started with (speed vs. correct output for hard problems). Yours stands, but it changed the direction of the discussion as I understand it. Hence the pushback.
Yeah I expect it to be helpful in some basic image processing stuff, but it will quickly fail once you try to implement research papers on the topic.
I can specifically and directly state that is false.
Feel free to share specifics.
https://news.ycombinator.com/item?id=49226923
Might I recommend HVAC or plumbing, it's honorable work and pays well. Trim trees if you've got the body for it.
I don't recommend web work, the last ten years or the next ten. Wouldn't touch the stuff. I skipped the phone app era, too.
Why is there honor in HVAC? Family honor?
You're definitely doing something with a net good impact on people instead of making the next ad tracking software or camera image recognition loop.
The churn in this space puts javascript to shame. As an example, its only been a few months and AFAICT no one is even talking about openclaw anymore.
I agree but how many developers did you know making heavy use of it? It always seemed like it was a poorly thought out experiment that gained a lot of traction and hype from the non-technical crowd. I don't say that to be elitist, I just think that non-technical users need a much more consistent and constrained product because they can't really fix and upstream things themselves (even with the use of agents). For all the hype it got, not a single person from my circle installed it to even check it out.
I do agree that the current pace of abandonware creation is wild. I think a lot of projects are generated top down from an idea, and not bottom up through usage. If you have a new experimental project, and you don't have recent commits, I assume you are not using it and thus it has no value.
I think agentic use is mostly only valuable as author extension (help you search, rubber duck, generate code but needs very heavy review). Over time with enough usage of a process I do think some of them can turn into author automation but not from simply writing down an idea. It takes lots and lots of executions, iterations, generalizations, specifications, basically lots of work to get any decently hands-off intelligent automation through agents.
Did that get bought by openai? Lost its rogue cool factor.
Did not get bought by OpenAI. Creator was hired by OpenAI and they sponsor the project with tokens. OpenClaw is a non-profit now.
The problem is really that the promise was so big but the management and implementation was so painful, coupled with non-stop updates, coupled with far too big of an implementation surface.
A classic "lets solve 15 problems at once" situation, but none of them really well.
Maybe OpenClaw solved the problem it was designed to solve.
remember moltbook?
I was fairly skeptical of agentic coding before I used it for a real product. Although I still have to be heavily involved in planning the code that LLMs write for me, they can write code much faster than I can, and they know more about edge cases than I do, so they can handle edge cases/subtle bugs that I would have missed. I have been paid to write code at every level of the stack from assembly to frontend javascript, but I'm not equally good at all those areas. In some areas I can still outperform LLMs, but for areas I'm weak they do a much better job than I would have.
I still think of what I'm doing as software engineering, and I'm glad that I had many years of professional and hobby development before using agents since I think that's given me the ability to make good architectural decisions (and helps me resteer the LLMs when they want to do something suboptimal), but my involvement in actually writing code is quickly going to zero. That said, they aren't perfect and they still introduce bugs, but I believe the quality of my current product is higher than what I would have created pre-agentic coding.
Things I've found helpful in keeping quality high:
- Visual regression tests (detect UI bugs before you commit them)
- Fuzz testing of interfaces and app behavior
- Automatically add regression tests for any bug that I/the LLM fixes
- Logging/alerting that tracks an errors/invariant violations triggered in the app
- Performance metrics that are surfaced in a dashboard.
All of these are very easy to add since the LLM can create this infrastructure for you. The fuzz testing in particular is something very few products I've previously worked on have since most people don't know how to implement it. I ran the fuzzers for a few minutes and they quickly caught multiple subtle bugs that I was not aware of.
This is a real product that helps a real, non-VC funded service business, and although I could have made something similar myself it would have taken me a lot longer, be harder to use, and probably be less reliable.
Edit: while it's true that you can quickly blow through the $20/month plan, the $200/month plan allows you to get a lot done and is basically sufficient for my needs. It's also very cheap when you consider what it would cost to pay someone to do similar work.
Adding too many tests was a real issue before LLMs. You end up in situations where you when you add a feature there's 200 (out of e.g. 10k) tests that fail and you have to figure out which of them should fail and you need to fix them and which are actual bugs.
I haven't run into this yet. My test failures have either been real or have been triggered by an (intentional) breaking change. The later does require updating the tests, but I think catching the real bugs is worth that tradeoff. I haven't found spurious failures to be a big problem (I've had a few but rewriting the tests that have this problem has eliminated it for me). My codebase is a pretty modular rails app, which I think helps with this.
I have worked on other projects where flaky tests are a problem (and generally cause developers to ignore and submit anyways), but so far I've avoided that. My experience with flaky tests is that they're typically due to poor modularity or to subsystems that other teams can modify. This project exists in a monorepo and I'm the sole developer so that's not a problem here.
I disagree, I say the more tests the merrier, if you can afford the time cost. It's fairly rare to see faulty tests in my experience. Yes you can have hundreds failing tests and the code still works 100% - because those tests are testing API usage in a way the actual application never uses. But that's still a bug, it's just a future bug waiting to happen that you caught early. I wouldn't delete those tests.
> I was optimistic, but once I had it wired up to one of my projects, instead of making magical hands-off progress on my todo list it spent nearly my entire $20 worth of “ona compute units”, whatever those are, thrashing and trying to get a hold of the todos from linear just so it could pick one to start.
This is one of the reasons that I've simply not bothered with a lot of these types of AI products. It feels like gambling. Maybe I'll spend $20 on tokens and end up with something awesome. Or maybe I'll spend $20 on tokens and end up with nothing useful and then I'll be glad it was only $20 I lost.
When this article talks about ONA it means https://ona.com/ - a cloud agent service that was acquired by OpenAI a couple of months ago.
(I wouldn't suggest basing my evaluation of the entire field of coding agents around that particular product.)
[flagged]
What the heck? What product was I advertising here?
The one you link to?
You mean in the comment where I suggested that I didn't think it was a very good product?
I posted this comment because I didn't know what the author meant by ONA and had to look it up myself.
I wonder if there is cargo culting afoot
There are definitely guys in some companies just pointing an agent swarm at 50 Github tickets and saying "go get 'em boys" and hence need a lot of orchestration tools but for the rest of us do we really need the AI to do all the build steps and the testing steps... or do we just need the new feature that runs when the button is clicked and then we can check it out in the browser ourselves. The code gen is what I need the AI for, not the 'smoke tests' and the tsc finagling. I'm willing to spend some mental calories myself in figuring this feature out step by step
Actually this makes me wonder if some people are just not very into building step by step like "okay first let's check the JSON shape the endpoint returns", "okay now let's make a simple form", etc
> some people are just not very into building step by step like "okay first let's check the JSON shape the endpoint returns", "okay now let's make a simple form", etc
That's accurate. There are a lot of people (some of them quite senior and/or skilled) who operate in the way you described.
The build and test steps allow the agent to self correct. Why would I want to waste my time trying out a half-finished or outright broken feature if the AI didn't even run a type checker on it to see if it even compiled?
> just pointing an agent swarm at 50 Github tickets and saying "go get 'em boys"
I still don‘t know if this is real. If it works like that, where are the companies that only kept every tenth, 10x‘d AI enhanced dev? They should have significantly higher margins. The companies that keep all devs and 10x‘d them, finally bringing that backlog to 0 should have exploding revenue and profit.
Where does AI create value? I can‘t see it.
I use it every day, but nothing got faster.
The creation of downstream issues has gotten faster, in my experience. The rate at which shit is thrown against walls has also gotten faster.
Exactly. If you can free engineering capacity from tedious busywork (fixing bugs), you have them available for implementing/delegating to implement experimental features into new revenue streams.
Why fire anyone in this scenario? Growth is only going to keep coming.
> They should have significantly higher margins.
I don't think devs are that expensive relative to a big company.
Airbnbs revenue last year was 12b. If they have 1000 engineers,maybe average 200k/yr that's only 200m. If they got rid of their engineers still only a fraction of of the revenue
The product is being launched before the value is clear.
We've seen similar waves with new technologies before: overexposing the pros, dismissing the cons, hyper-optimism, and people using a lot of jargon without saying much of substance. The difference this time is the scale of the impact and the volume around it.
> The product is being launched before the value is clear.
May I fix that for you?
The product is being launched before the value is there.
Its reasonable to dislike a bad product experience, but its strange to draw a conclusion of AI altogether based on a tool with limited usage (I've never heard of it).
That's like saying smart watches are useless based on trying out the smart watch made by will.i.am's tech company rather than Apple's.
I find it hard to buy this generalization about _all_ "AI"/agent software when the author has only provided _one_ example. A couple alternatives could've been explored, like Cursor Cloud Agents or even just running Claude Code with remote control on another machine. I'd also personally never spend a dime on any product unless I've read _some_ positive sentiment from online commentary, like Hacker News. To my point, Ona appears to have a pretty low amount of feedback that makes it difficult to justify any $20 bills: https://hn.algolia.com/?q=ona.com
AI is good at building "disposable" software. I think this category will grow specially for regular joes.
There's no such thing as a free lunch, and anyone trying to build software without significant guardrails and insights into the process will have to give up control of their codebase.
Ray Myers does a good job of exploring this topic in a recent Software Should Work talk, trying to answer: "Is code for people or AI?" [0]
[0] https://www.youtube.com/watch?v=mZgglPK8Rg0
YMMV but I think with the SOTA models building a token efficient engineering loop is absolutely doable with (imho) solid development and testing practices. I see no reason to buy a 3rd party system for this either. I'm not in enterprise so don't come at me here - I'm a small shop and I'm not trying to corral 100 devs or whatever. We've got linear boards getting cards pushed and pulled, debated over by multiple models, coded, debated, tested, accepted, etc etc. True software factories now exist and they don't screw up the login.
> True software factories now exist
That statement somehow amazes me. Obviously, LLMs need plenty of steering, but I don't get how a company can be built on that.
Small companies doing consulting certainly could. My use of the term "software factory" really implies a lot of automation in turning out useful tools for internal and external customers.
No, but a lot is.
You see a version of this in every tech boom cycle, but this one is way more reflexive.
Mature technical software projects are slow moving because they have real users building other real software and businesses with them. Their engineering involves navigating the ecosystem and dep and compatibility constraints.
Any project moving super fast pumping out PRs either isn’t burdened/blessed with real usage OR doesn’t care about (reap real value from) the users it has.
Related theory is that the LLM “labs” are actually not particularly incentivized to prioritize stable API surfaces. They want machine interfaces to constantly rapidly change so that we must depend on model based natural language surfaces to navigate the complexity.
> But so far most of what they do is make more annoying work for me. More integrations to debug, more auth tokens to refresh, more bills to keep track of, more meandering and drawn out descriptions of non-bugs with bogus fix suggestions and misinformed “root cause” analyses. It’s tiresome.
God this times 1000. I'm so sick of having AI chase a bug and having to lead it by the hand like a toddler to try and help me solve bugs. The difference is, a toddler learns when you explain. An LLM holds your responses in context and uses them to generate more authentic sounding garbage, but next session, foomf, the lesson is unlearned again.
I had a tiny problem with prerendering not working on a react site last night, I must have spent close to an hour running commands it asked me to run like a moron, verifying dumb things I had already checked like "did the file actually upload to ftp" or had I restarted Apache or was there some magic htaccess file somewhere. Eventually I just gave up on Claude and tried some different paths in Apache virtual host settings and it worked.
Of course if I went back to Claude and reported that, as would be my instinct with a human, it would confidently explain why that was the bug, why it couldn't spot the issue, and how smart I am for finding it. And then it would forget everything tomorrow
I suspect the issue there was Claude, especially Opus 5, which just hates the idea that it could ever be wrong about anything.
> I'm so sick of having AI chase a bug and having to lead it by the hand like a toddler to try and help me solve bugs.
This hasn't been my experience at all. I can give it a vague description of the problem and have it find it pretty easily without any more input from me.
I do think there's a pretty big variation in tools and setups and what output people are getting. I'm now just using OpenAI Codex in VS Code and it churns through problems like they're nothing.
Sometimes I have to get it to not over-engineer a solution; not because it's necessarily wrong but because I don't need that much correctness.
Kira is probably too young (good for her! I am not cynical here) to remember how the software development worked when PHP just came out. We are at that point of time now, again.
Next stop will be Perl: write only language.
And then we will hit the "Java EE" wall. Again.
And our LinkedIn will get red hot from recruiters looking for "experienced crisis devlopers".
The trouble is that the loudest voices will dominate, so the little measurable wins adding up in most organizations don't get attention.
I stopped at "The hard part of software engineering was never writing the code."
Better read https://blog.senko.net/code-was-never-the-hard-part-is-an-in...
Writing meaningful and correct code was always difficult. That we know how to generate pointless CRUD or half-baked apps using agents doesn't mean we can do them well. It's probably sufficient for selling them as a business but far from being great.
It seems nobody is user testing/pentesting their projects anymore. The notion of an MVP being good enough has been pushed a lot recently but it seems that the user experience of these MVPs has not been taken into consideration.
It's strange to me that the voices naysaying agentic coding capabilities seem to be getting louder in recent weeks.
I almost wonder if there's a campaign to start suppressing public awareness of where SOTA capabilities really are.
The discontent is real. The deficiencies these people mention are real. And it's not actually getting better. Sure, web devs and CRUD app devs may be screwed over a bit harder now, but when it gets into really deep complex stuff, the usability of the output goes way, way down. This cliff is real. I assure you. And it's not getting better.
Why is that strange? To me, it’s evidence of growing dissatisfaction with the direction of the field and frustration with being made to deal with the consequences of others bad work
It's really just evidence of what group of people are doing submissions at any given time.
agentic coding is real. If AI labs can take over the coding tool market, that's a billion+ market. LLMs work in coding, and AI labs can slowly expand into other white collar work. Vaporware? Hardly.
It’s starting to resemble a pyramid scheme with Nvidia at the top, OpenAI & Anthropic beneath.
That Nvidia finances a lot of this should give anyone with a clue on finance pause, that it doesn’t tells you you’re in the middle of a bubble.
The tech is real, the use cases are increasingly forced and fabricated to justify a ludicrous valuation that will never come to pass. For research and military applications ML is great, but it isn’t going to print trillions for anyone.
I agree, the fact that with an open model I can be modifying go and react code that I'd never consider touching as a human who values their eyesight and come up with real patches, fixes and extensions of almost any project on github is truely fascinating and, addictive.
I can absolutely see where this technology works; but like EVERYTHING THAT THESE VC FUNDED FASCISTS IGNORE, just because it works in the lab does not mean it works in real life. I can see exactly where this technology fails: it lets you spool out so much thread into the abyss that you're just going to keep refactoring everything, all the time and when it blows a hole in your project, whelllp! you wanted to refactor that too. Imagine having 100 side projects grossly built and still, you just want to move on.
Fiishing projects are still going to need work and the explosion of "this is _my_ engineering harness" is everyone twiddling their thumbs cause real projects of significant value are still about scope and "total addressable market" and not "I made an AI to diddle children, so you dont have to" crowd.
I'm honestly not sure if the people writing those articles are in a different field or something. I have been coding for 20 years and there goes no day that doesn't leave me impressed.
It's nothing short of magic. And in terms of productivity, features that took months are now being done in days. I'm not even sure what the author is talking about frankly.
Am I missing something?
Was ready for some interesting music theory or analysis on genres of music that somehow map to the sound of vaporwave... but of course it's just about LLMs.
"The hard part of software engineering was never writing the code."
Again, are we still on this ridiculous concept. I stopped reading at that sentence.
Is that going to be the revisionist future that the industry tells itself - ""one day, LLMs came along and suddenly computers could program themselves, and it was an absolute revolution, but it made no difference at all to anything because "The hard part of software engineering was never writing the code." so people stopped using LLMs because of that. And that's how LLM's came to an end after being a short trend.""
I think it's true. Writing code is the most fun part of my job, but it's also the least time consuming. For any given feature, everything around the code takes 10x as much time. Getting the requirements, writing the spec, refining the spec, doing the QA work, delivery. The actual "coding" part in the middle is quick, fun, and creative. Since it's quick I get to sit and think about abstractions and performance, which is great.
But, it could be even quicker if I just give up and willingly write shitty code that works. I don't do that, but I could, and I doubt anyone outside of close developers on my team would ever notice.
A great article yesterday about this very concept: https://news.ycombinator.com/item?id=49222189
The hard part was the rote memorization of leetcode challenges and then learning to pattern match to the particular problem in a 5 minute technical interview.
The second part was that the test was being administered by a gatekeeper who was hired before those practices were put in place.
The 3rd was what? Amazon or Netflix burning your ass out because they are anti-human companies?
> Is it all just vapourware?
No. Anyone making this claim is being disingenuous.
[flagged]
I don't think you really deserved downvotes. Some people are more geared toward evangelizing technology (or evangelizing anything really), and some are not. I'm pretty much in the 'not' camp.
I'll share my experiences and how I do things, but I'm not about to engage in arguments about it. If you don't want to use it, then don't. What I do I care?
Exactly. So I find the sort of blog posts as TFA here quite strange, like who are they arguing against? I just follow ones that talk about how they use the tools rather than meta debates on their usage.