>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?
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.
> 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.
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.
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
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
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.
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!
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.
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?
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?
I recently asked it a series of technical physics questions about a field I used to be involved in to evaluate whether it'd be useful for doing research, and literally every single answer it gave was critically wrong - even for basic questions. Its certainly true that I went "holy shit", but not in a good way
I did but it was followed by "holy shit now I gotta review this +3000 -500 LOC PR full of subtly wrong abstractions, needless diversions and incorrect assumptions".
People keep repeating your sentiment here but I simply can't follow, are we even on the same planet? Or did everyone switch to just not caring about maintainability and code quality anymore? Or are your work tasks simply so mindnumbingly, stupidly simple that even an AI can oneshot them properly?
I mean this honestly btw, not dismissively like some sister comments. The gap between the productivity increases people report on HN and what I experience myself is insane. In fact, if I factor in the procrastination I find myself doing on dotting the i's on a supposedly "one-shotted" AI implementation of a nontrivial feature, I think the AI actively slows me down.
The only way I've found that I can actually use AI productively and sustainably is in very small tight loops and, well, at that point it's not that much faster than just typing in the code (with the occasional "Cursor Tab" complete).
You have to have a team of agents with different roles reviewing that for you. An Advocate, a Skeptic, an Architect, a Security Engineer, a Disgruntled User, a Single Mom, a Clueless CTO, etc. each provides their unique prospective on the change. Then you have a Remediator and a Consolidator to address the feedback. Finally a Liquidator in case of a catastrophic failure.
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 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.
Nah, for what was broadly avaiable, last year it was still in the area of better custom stackoverflow answers. A good search engine for code. Helpful, but I don't remember mindblown moments.
This year we have agents work with complex codebases. That was and still is mindblown to me.
I 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 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.
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
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]
Its reasonable to dislike a bad product experience, but its strange to draw a conclusion of AI altogether based on a tool with limited usage (I've never heard of it).
That's like saying smart watches are useless based on trying out the smart watch made by will.i.am's tech company rather than Apple's.
I find it hard to buy this generalization about _all_ "AI"/agent software when the author has only provided _one_ example. A couple alternatives could've been explored, like Cursor Cloud Agents or even just running Claude Code with remote control on another machine. I'd also personally never spend a dime on any product unless I've read _some_ positive sentiment from online commentary, like Hacker News. To my point, Ona appears to have a pretty low amount of feedback that makes it difficult to justify any $20 bills: https://hn.algolia.com/?q=ona.com
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.
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.
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 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.
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.
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.
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.
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 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.
> 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 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?
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.
> 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.
> 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.
Yeah, why hasn't AMD added every single CUDA feature lol
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.
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.
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.
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
I would submit it but the pr was too long to fit on GitHub
… doesn’t Linux work through email, not GitHub?
I'm choosing to interpret this as very dry sarcasm.
[dead]
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.
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
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.
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?
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?
I recently asked it a series of technical physics questions about a field I used to be involved in to evaluate whether it'd be useful for doing research, and literally every single answer it gave was critically wrong - even for basic questions. Its certainly true that I went "holy shit", but not in a good way
I did but it was followed by "holy shit now I gotta review this +3000 -500 LOC PR full of subtly wrong abstractions, needless diversions and incorrect assumptions".
People keep repeating your sentiment here but I simply can't follow, are we even on the same planet? Or did everyone switch to just not caring about maintainability and code quality anymore? Or are your work tasks simply so mindnumbingly, stupidly simple that even an AI can oneshot them properly?
I mean this honestly btw, not dismissively like some sister comments. The gap between the productivity increases people report on HN and what I experience myself is insane. In fact, if I factor in the procrastination I find myself doing on dotting the i's on a supposedly "one-shotted" AI implementation of a nontrivial feature, I think the AI actively slows me down.
The only way I've found that I can actually use AI productively and sustainably is in very small tight loops and, well, at that point it's not that much faster than just typing in the code (with the occasional "Cursor Tab" complete).
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
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!
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?
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.
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.
Oh, I have those moments daily. Like, "holy shit, I can't believe it just fucked up a rote task this badly".
[flagged]
Nah, for what was broadly avaiable, last year it was still in the area of better custom stackoverflow answers. A good search engine for code. Helpful, but I don't remember mindblown moments.
This year we have agents work with complex codebases. That was and still is mindblown to me.
Don't make new accounts just to add snarky responses. If you're gonna do it, use your real account so we know who to flag.
I'll worry when that stops happening. Probably means I'm getting in my own way or not thinking big enough.
[flagged]
Learning is lifelong, in most trades. What are you on about? Especially in something vast as programming/SW/ops.
That's exactly my point — by now you should have learned enough not to be surprised.
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.
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.
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
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.)
[flagged]
What the heck? What product was I advertising here?
The one you link to?
You mean in the comment where I suggested that I didn't think it was a very good product?
I posted this comment because I didn't know what the author meant by ONA and had to look it up myself.
Its reasonable to dislike a bad product experience, but its strange to draw a conclusion of AI altogether based on a tool with limited usage (I've never heard of it).
That's like saying smart watches are useless based on trying out the smart watch made by will.i.am's tech company rather than Apple's.
I find it hard to buy this generalization about _all_ "AI"/agent software when the author has only provided _one_ example. A couple alternatives could've been explored, like Cursor Cloud Agents or even just running Claude Code with remote control on another machine. I'd also personally never spend a dime on any product unless I've read _some_ positive sentiment from online commentary, like Hacker News. To my point, Ona appears to have a pretty low amount of feedback that makes it difficult to justify any $20 bills: https://hn.algolia.com/?q=ona.com
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.
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.
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 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.
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.
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.
[delayed]
Writing meaningful and correct code was always difficult. That we know how to generate pointless CRUD or half-baked apps using agents doesn't mean we can do them well. It's probably sufficient for selling them as a business but far from being great.
It'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.
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 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.
The trouble is that the loudest voices will dominate, so the little measurable wins adding up in most organizations don't get attention.
> 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.
agentic coding is real. If AI labs can take over the coding tool market, that's a billion+ market. LLMs work in coding, and AI labs can slowly expand into other white collar work. Vaporware? Hardly.
It’s starting to resemble a pyramid scheme with Nvidia at the top, OpenAI & Anthropic beneath.
That Nvidia finances a lot of this should give anyone with a clue on finance pause, that it doesn’t tells you you’re in the middle of a bubble.
"The 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?
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.