I have very rarely needed the site: modifier, and even knowing this exists sets people apart, and reinforces there is skill to it
In the end, every tool I tried felt like I was spending a significant amount of time saying “no that won’t work” just to get a piece of code that would build, let alone fit for the task. There was never an instance where it took less time or produced a better solution than just building it myself, with the added bonus that building it myself meant I understood it better.
In addition to that I got into this line of work because I like solving problems. So even if it was as fast and as reliable as me I’ve changed my job from problem solver to manager, which is not a trade I would make.
My personal experience indicates this, AI enhances me but cannot replace me
Been doing something closer to pair programming to see what "vibe" coding is all about (they are not up to being left unattended)
See recent commits to this repo
- Claude Code is a Slot Machine https://news.ycombinator.com/item?id=44702046
- GPTs and Feeling Left Behind: https://news.ycombinator.com/item?id=44851214
- I also used the Emperor/clothes metaphor: https://news.ycombinator.com/item?id=44854649
And just so we are clear, in the only current actual study measuring productivity of experienced developers so far, it actually led to 19% decline in productivity. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o...
So, if the study showed experienced developers had a decline in productivity, and some developers claim gains in theirs, there is high chance that the people reporting the gains are...less experienced developers.
See, some claim that we are not using LLMs right (skills issue on our part) and that's why we are not getting the gains they do, but maybe it's the other way around: they are getting gains from LLMs because they are not experienced developers (skills issue on their part).
I'm an experience (20y) developer and these tools have saved me many hours on a regular basis, easily covering the monthly costs many times over
It's also not the only data, here's one with results in the other direction
https://medium.com/@sahin.samia/can-ai-really-boost-develope...
It’s interesting they showed the biggest gains for junior developers. The other study showing productivity losses for experienced developers. That suggests these tools are a lot more helpful for junior developers compared to senior developers at the moment.
Theore you use it, the more you get a feel for when and when not to use it
You forgot to add: first time users, and within their comfort zone. Because it would be completely different result if they were experienced with AI or outside of their usual domain.
You are also misrepresenting the literature. There are many papers about LLMs and productivity. You can find them on Google Scholar and elsewhere.
The evidence is clear that LLMs make people more productive. Your one cherry picked preprint will get included in future review papers if it gets published.
They are like an overeager junior, they know how to write the code but they don't know how to architect the systems or to avoid bugs. Just today I suspected something, asked the LLM to critique its own code, paying attention to X Y Z things, and it found a bunch of unused code and other brittleness. It fixed it, with my guidance, but yeah, you can't let your guard down.
Of course, as you say, these are the tools of the trade now, and we'll have to adapt, but they aren't a silver bullet.
Meaning you no longer write any code directly, or that you no longer use LLMs other than for coding tasks?
Maybe. Or maybe a third prompt would have found more. And more on the fourth. And none on the fifth, despite some existing.
In my experience: not always, and my juniors aren't experienced enough to catch it, and the LLM at this point doesn't "learn" from our usage properly (and we've not managed to engineer a prompt good enough to solve it yet), so its a recurring problem.
> if prompted correctly
At some point this becomes "draw the rest of the owl" for me, this is a non-trivial task at scale and with the quality bar required, at least with the latest tools. Perhaps it will change.
We're still using them, they still have value.
I think the article is implicitly saying that an LLM that's skilled enough to write good code should have done it "the right way" without extra prompting. If LLMs can't write good code without human architects guiding it, then I doubt we'll ever reach the "10x productivity" claims of LLM proponents.
I've also fell into the same trap of the author in assuming that because an LLM works well when guided to do some specific task, that it will also do well writing a whole system from scratch or doing some large reorganization of a codebase. It never goes well, and I end up wasting hours arguing with an LLM instead of actually thinking about a good solution and then implementing it.
Don’t do this! Start another prompt!
This is an argument used constantly by AI advocates, and it's really not as strong as they seem to think.*
Yes, there exists some prompt that produces the desired output. Reductio ad absurdum, you can just prompt the desired code and tell it to change nothing.
Maybe there is some boilerplate prompt that will tell the LLM to look for security, usability, accessibility, legal, style, etc. issues and fix them. But you still have to review the code to be sure that it followed everything and made the correct tradeoff, and that means that you, the human, has to understand the code and have the discernment to identify flaws and adjust the prompt or rework the code in steps.
It's precisely that discernment that the author lacks for certain areas and which no "better" prompting will obviate. Unless you can be sure that LLMs always produce the best output for a given prompt, and the given prompt is the best it can be, you will still need a discerning human reviewer.
* Followed closely by: "Oh, that prompt produced bad results 2 weeks ago? AI moves fast, I'm sure it's already much better now, try again! The newest models are much more capable."
If you know how to set up and sharpen a hand plane and you use them day in and day out, then I will listen to your opinion on a particular model of plane.
If you've never used one before and you write a blog post about running into the same issues every beginner runs into with planes then I'm going to discount your opinion that they aren't useful.
And because it always comes up, no, not even if temperature is set to 0. It still hinges on insignificant phrasing quirks, and the tiniest change can produce drastically different output. Temperature 0 gives you reproducibility but not the necessary predictability for a good tool.
MCMC is also not deterministic, and yet people learn how to use it well. Being non-deterministic is kind of the whole point of anything based on statistics. It's deterministic conditioned on the seed.
This shows the core of the flaw in the argument.
"The tool is great. If the result is not perfect, it is the user to blame."
It's unfalsifiable. The LLM can provide terrible results for reasonable prompts, but the response is never that LLMs are limited or have flaws, but that the user needs to prompt better or try again with a better LLM next week.
And more importantly, this is for the good case where the user has the discernment and motivation to know that the result is bad.
There are going to be lots of bad outputs slipping past human screeners, and many in the AI crowd will say "the prompt was bad", or "that model is obsolete, new models are better" ad infinitum.
This isn't to say that we won't get LLMs that produce great output with imperfect prompts eventually. It just won't be achieved by blaming the user rather than openly discussing the limitations and working through them.
The only study I’ve seen so far on LLMs and productivity, showed that developers using an LLM were LESS productive than those who didn’t use them.
[0] https://williamcotton.com/articles/introducing-web-pipe
[1] https://github.com/williamcotton/williamcotton.com/blob/mast...
[2] https://github.com/williamcotton/webpipe-rs/commits/main/?af...
And how do you know if it did it the right way?
Did you consider that Scrum for the Enterprise (SAFe) when used correctly (only I know how, buy my book), solves all your company's problems and writes all your features for free. If your experience with my version of SAFe fails, it's a skill issue on your end. That's how you sound.
If your LLMs which you are so ardently defending, are so good, where are the results in open source?
I can tell you where, open source maintainers are drowning in slop that LLM enthusiasts are creating. Here is the creator of curl telling us what he thinks of AI contributions.https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-s... Now I have the choice: should I believe the creator of curl, or the experience of a random LLM fanboy on the internet?
If your LLMs are so good, why does it require a rain dance and a whole pseudoscience how to configure them to be good? You know what, in the only actual study with experienced developers to date, using LLMs actually resulted in 19% decrease in productivity. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o... Have you considered that maybe if you are experiencing gains from LLMs but a study shows experienced devs don't, that maybe instead of them having a skills issue, it's you? Cause the study showed experienced devs don't benefit from LLMs. What does it make you?
It's not going to replace me, it's going to allow me to get projects done that I've backburnered for years. Under my direction. With my strict guidance and strict review. And that direction and review requires skill -- higher level skills.
Yes, if you let the machine loose without guidance... you'll get garbage-in, garbage-out.
For years I preferred to do ... immanent design... rather than up front design in the form of docs. Now I write up design docs, and then get the LLM to aid in the implementation.
It's made me a very prolific writer.
Replaced with a technology that rambles
Its advocates thought
This stuff is so hot
But in the end their brains were all scrambled
Well that's certainly a belief. Why are you not applying your lofty analysis to your own bias?
Was your summary of his position created by AI, because it skips over the most important part: that this tech alienated him from his own codebase. It’s doing the same thing to you. The difference is you don’t give a shit.
AI an amazing productivity boost only assuming you don’t give a shit.
But maybe AI is just better than I ever was at front end and react
Maybe I should do something else
And ask questions and read all the code and modify it yourself; and read the compile errors and try to fix then yourself; etc. Come back to the LLM when you’re stuck.
Having the machine just build you something from a two sentence prompt is lazy and you’ll feel lazy and bad.
Learn with it and improve with it. You’ll end up with more knowledge and a code base for a project that you do (at least somewhat) understand, and you’ll have a project that you wouldn’t have attempted otherwise.
I think the LLM accounting benchmark is a good analogy. The first few prompts are like the first month in accounting. the books are correct before so the LLM has a good start. in the accounting benchmark then the miscalculations compound as do the terrible practices in the codebase.
How many more times is someone going to write this same article?
Those that get lazy and produce low quality output will be pruned like they are today
On an old sitcom a teenager decides to cheat on an exam by writing all the answers on the soles of his shoes. But he accidentally learns the material through the act of writing it out.
Similarly, the human will maintain a grasp of all the code and catch issues early, by the mechanical act of typing it all out.
For me, anything that feels like anything remotely resembling a "superpower" with AI starts with doing a lot of heavy lifting upfront. I spend significant time preparing the right context, feeding it to the model with care, and asking very targeted questions. I'll bounce ideas back and forth until we've landed on a clear approach. Then I'll tell the model exactly how I want the code structured, and use it to extend that pattern into new functionality. In that mode, I'm still the one initializing the design and owning the understanding...AI just accelerates the repetitive work.
In the end, I think the most productive mindset is to treat your prompt as the main artifact of value, the same way source code is the real asset and a compiled binary is just a byproduct. A prompt that works reliably requires a high degree of rigor and precision -- the kind of thinking we should be doing anyway, even without AI. Measure twice, cut once.
If you start lazy, yes...AI will only make you lazier. If you start with discipline and clarity, it can amplify you. Which I think are traits that you want to have when you're doing software development even if you're not using AI.
Just my experience and my 2c.
I recently had a team member submit code done primarily by an LLM that was clearly wrong. Rather than verifying that the change was correct, they rapid fired a cr and left it up to the team to spot problems.
They've since pushed multiple changes to fix the initial garbage of the LLM because they've adopted "move fast and break things". The appearance of progress without the substance.
This is highly rewarded in many (most?) corporate environments, so that’s not surprising.
When’s the last time you heard “when will it be done?”
When’s the last time you heard “can you demonstrate that it’s right|robust|reliable|fast enough|etc?”
Takes just a lunch break for the review to go up and get approved by someone that just made sure there's code there. (Who is also primarily using LLMs without verifying)
Unfortunately for the writer, he will probably get fired because of AI. But not because AI will replace him - because seniors will.
Bold statement! In the real world, senior developers were actually 19% less effective by using LLMs in the only study up to date.
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o...
Very brave to have an edgy opinion based on vibes that is counter to the only actual study though. Claiming that things are XYZ just because it feels like it is all the rage nowadays, good for being with the times.
> Unfortunately for the writer, he will probably get fired because of AI. But not because AI will replace him - because seniors will
Here is another prediction for you. In the current real world LLMs create mountains of barely working slop on a clean project, and slowly pollute it with trash feature after feature. The LGTM senior developers will just keep merging and merging until the project becomes such a tangled mess that the LLM takes billion tokens to fix it or it outright can't, and these so called senior developers had their skills deteriorate to such an extent that they'd need to call the author of the article to save them from the mess they created with their fancy autocomplete.
For fucks sake it probably got you to the same first draft you would have gotten to yourself in 10x less time. In fact there plenty of times where it probably writes a better first draft than you would have. Then you can iterate from there, review and scrutinize it just as much as you should be doing with your own code.
Last I checked the majority of us don't one shot the code we write either. We write it once, then iterate on things we might have missed. As you get better you prompt instinctively to include those same edge cases you would have missed when you were less experienced.
Everybody has this delusion that your productivity comes from the AI writing perfect code from step 1. No, do the same software process you normally should be doing, but get to the in between steps many times faster.
The benefit of writing your own first draft is the same reason why you take notes during classes or rephrase things in your head. You're building up a mental model of the codebase as you write it, so even if the first draft isn't great you know where the pieces are, what they should be doing and why they should be doing it. The cognitive benefits of writing notes is well known.
If you're using an AI to produce code you're not building up any model at all. You have to treat it as an adversarial process and heavily scrutinize/review the code it outputs, but more importantly it's code you didn't write and map. You might've wrote an extensive prompt detailing what you want to happen, but you don't know if it did happen or not.
You should start asking yourself how well you know the codebase and where the pieces are and what they do.
After initial hesitation and fighting the the LLMs, I slowly changed my mode from adversarial to "it's a useful tool". And now I find that I spend less time thinking about the low-level stuff (shared pointers, move semantics, etc. etc.) and more time thinking about the higher-level details. It's been a bit liberating, to be honest.
I like it now. It is a tool, use it like a tool. Don't think of "super intelligence", blah blah. Just use it as a tool.
Do you expect LLMs to get those ones right?
There are many problems where the solution would take me a few hours to derive from scratch myself, but looking at a solution and deciding “this is correct” or “this is incorrect” takes a few minutes or seconds.
So I don’t expect the junior or the LLM to produce a correct result every time, but it’s quick to verify the solution and provide feedback, thus I have saved time to think about more challenging problems where my experience and domain knowledge is more valuable.
Software and technology takes mastery; imagine the string manipulation syntax for different programming languages. There are many ways to achieve a business objective. Choosing the right language/coding style for the specific use case and expected outcome takes iterations and planning.
AI still in infancy yet it has replaced and disrupted whole niche markets and it's just the beginning. The best any dev can do in this context is sharpen their use of it and that becomes a superpower; well defined context and one's own good grasp of the tech stack being worked on.
Context: I still lookup rust docs and even prompt for summaries and bullet point facts about rust idioms/concepts that I am yet to internalize. JS is what I primarily write code in but, currently learning rust as I work on a passion project.
└── Dey well
Like any tool, there's a right and wrong time to use an LLM. The best approach is to use it to go faster at things you already understand and use it as an aid to learn things you don't but don't blindly trust it. You still need to review the code carefully because you're ultimately responsible for it, your name is forever on it. You can't blame an LLM when your code took down production, you shipped it.
It’s a double-edged sword: you can get things done faster, but it's easy to become over-reliant, lazy, and overestimate your skills. That's how you get left behind.
The old advice has never been more relevant: "stay hungry."
I also think it's a matter of how one uses them. I do not use any of the LLMs via their direct APIs. I do not want LLMs in any of my editors. So, when I go to ask questions in with web app, it takes a bit more friction. I'm honestly an average at best programmer, and I do not really need LLMs for much. I mainly use LLMs to just ask trivial questions that I could have googled. However, LLMs are not rife with SEO ads and click-bait articles (yet).
I'm sure it's writing lazy stupid JavaScript, but the alternative is that my users got a CLI. Given that alternative, I think they don't mind the stupid JavaScript.
As unfashionable as it sounds on hacker news, a hybrid workflow and some adaptation are necessary. In my case, the LLM boom actually pushed me to start a CS master’s (I’m a self‑taught dev with 10+ years of experience after a sociology BA) and dive into lower‑level topics, QMK flashing, homelab, discrete math. LLMs made it easier to digest new material and kept me curious. I was a bit burned out before; now I enjoy programming again and I’m filling gaps I didn’t know I had.
I often get down-voted on Hacker News for my take on AI, but maybe I am just one of the few exceptions who get a lot out of LLMs
Another thing that happens quite often. I give the task to the LLM. It's not quite what I want. I fix the prompt. Still not there. Every iteration takes time, in which I lose my focus because it can take minutes. Sometimes it's very frustrating, I feel I'm not using my brain, not learning the project. Again, loss of time.
At the current stage, if I want to be productive, I need to restrict the use of the LLMs to the tasks for which there's a high change that it'll get it right in the first try. Out of laziness, I still have the tendency to give it some more complex tasks and ultimately lose time.
j45•2h ago
Maintaining your own list of issues to look for and how to resolve them, or prevent them outright is almost mandatory, and also doubles as a handy field reference guide for what gaps exist in applying LLM's to your particular use when someone higher up asks.
mockingloris•2h ago
It takes mastery, just like with actual programming syntax. There are many ways to achieve a business objective. Choosing the right one for the specific use case and expected outcome takes iterations.
AI HAS replaced whole niche markets and it's just the beginning. The best any dev can do in this context is sharpen their use of it. That becomes a superpower; well defined context and one's own good grasp of the tech stack being worked on.
Context: I still lookup rust docs and even prompt for summaries and bullet point facts about rust idioms for better understanding of the code. I identify as a JS dev first but, currently learning rust as I work on a passion project.
└── Dey well