>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
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.
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
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 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 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.
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
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.
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
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.
> 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.
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
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.
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 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
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 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.
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 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.
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.
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.
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
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.
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]
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.
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
> 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.
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.
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.
Last time this topic came up, I said it's not worth arguing with engineers who don't try or use AI, their experience is so far removed from those who do that there is no common ground to be had and it's just a waste of time for me to even attempt to. Seems I'm proven right again.
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?
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.
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.
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.
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
"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.""
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?
> 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.
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.
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.
>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.
> 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
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.
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
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.
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.
So... basically an autocomplete to help you type faster and spot check if you did something unusual in the parts you wrote by hand?
> 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?
> 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 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
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
> 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.
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.
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
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.
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.
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.
> 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.
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
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.
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 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
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.
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 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.
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.
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.
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'm convinced a lot of people just haven't tried and are digging their heels in and refusing to do so.
Claude Opus 5 is insane. Still not able to do big complex projects well start to finish but it can, with guidance, implement large parts of them.
There are now open weights models approaching it in performance too.
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.
Not everyone is a web developer bub
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.
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.
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.
https://news.ycombinator.com/item?id=49226923
I have been doing this stupid shit for long enough that, frankly, I am only happy when it does exactly what I intended.
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 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
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.
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
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.)
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.
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
> 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.
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.
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.
Last time this topic came up, I said it's not worth arguing with engineers who don't try or use AI, their experience is so far removed from those who do that there is no common ground to be had and it's just a waste of time for me to even attempt to. Seems I'm proven right again.
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?
The trouble is that the loudest voices will dominate, so the little measurable wins adding up in most organizations don't get attention.
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.
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.
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?
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.
"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.""
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?
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...
> 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.
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.
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.
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.
> Is it all just vapourware?
No. Anyone making this claim is being disingenuous.