He freely admits that the LLM did his job way faster than he could, but then claims that he doesnt believe it could make him 10x more productive. He decides that he will not use his new "superpower" because the second prompt he sent revealed that the code had security issues, which the LLM presumably also fixed after finding them. The fact that the LLM didnt consider those issues when writing his code puts his mind at rest about the possibility of being replaced by the LLM. Did he consider that the LLM wouldve done it the right way after the first message if prompted correctly? Considering his "personal stance on ai" I think he was going into this experience expecting exactly the result he got to reinforce his beliefs. Unironically enough thats exactly the type of person who would get replaced, because as a developer if youre not using these tools youre staying behind
> Did he consider that the LLM would've done it the right way after the first message if prompted correctly?
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."
It's reasonable to expect people to know how to use their tools well.
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.
Eeeh, the LLM wouldn't have done it correctly, though. I use LLMs exclusively for programming these days, and you really need to tell them the architecture and how to implement the features, and then review the output, otherwise it'll be wrong.
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.
I use (and like) AI, but “you failed the AI by not prompting correctly” strikes me as silly every time I hear it. It reminds me of the meme about programming drones where the conditional statement “if (aboutToCrash)” is followed by the block “dont()”.
What I have come to understand is that it will do exactly what you tell it to do and it usually works well if you give it the right context and proper constraints, but never forget that it is essentially just a very smart autocomplete.
> Did he consider that the LLM wouldve done it the right way after the first message if prompted correctly?
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.
> which the LLM presumably also fixed after finding them
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.
Exactly. I have all sorts of personal feelings about "AI" (I don't call it that, whatever) but spending a few days with Claude Code made it clear to me that we're in a new era.
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.
You are the last barrier between the generated code and production. It would be silly to trust the LLM output blindly and not deeply think about how it could be wrong.
The METR study that you're likely talking about had a lot of nuances that don't get talked about, not to mention outright concerns e.g. this one participant revealed he had a pretty damning selection bias:
There's a dissonance I feel. The study for example looked at experienced developer working on existing open source projects.
Lots of people we're now conversing with could be junior or mid-level, might have tried it for little prototypes/experiments, or for more trivial software like commissioned websites, and so on. They could all be benefiting from agentic coding workflows in ways that we don't. With the caveat that the study you talked about also showed even the experience devs felt more productive, so clearly the use of AI biases your perception of delivery speed.
The large array of context I suspect is responsible for some of that dissonance on online discourse.
Here's my blog with a work in progress article [0], written in a DSL I wrote called Web Pipe [1] that I started four days ago [2] with probably about 12 hours worth of work:
You don’t need to bathe in a stupid practice 24/7 to determine it is a stupid practice. He could see where it was going.
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.
It’s a shame that AI companies don’t share examples of their training data. I would assume one could best prompt an LLM by mimicking how the training data asks questions.
> Did he consider that the LLM wouldve done it the right way after the first message if prompted correctly?
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?
I'll admit I'm probably not as good at programming as the creator of curl. I write SaaS CRUD apps as a solo dev in a small business for a living. LLMs took away the toil of writing react and I appreciate that.
I have been using LLMs for coding for the past few months.
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.
My experience using LLMs is similar to my experience working with a team of junior developers. And LLMs are valuable in a similar way.
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.
A problem I'm seeing more and more in my code reviews is velocity being favored over correctness.
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.
It's a large enough team and there are members that rubber stamp everything.
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)
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'll wait for more studies about productivity, one data point is not solid foundation, there are a lot of people who want this to be true, and the models and agent systems are still getting better
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
Your comments are citing this blog post and arxiv preprint.
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.
> So, if the study showed experienced developers had a decline in productivity,
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.
What were you using? Did you use it for a real project? I ask because you're going to have a vastly different experience with Cursor than with Claude Code, for example.
My work has offered us various tools. Copilot, Claude, Cursor, ChatGPT. All of them had the same behavior for me. They would produce some code that looks like it would work but hallucinate a lot of things like what parameters a function takes or what libraries to import for functionality.
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.
A lot of people is using the tool in a wrong way. It’s massively powerful, there’s a lot of promisses but it’s not magic. The tool works on words and statistics. Better be really thoughtful and precise beforehand.
No one notices that Cursor or Claude code is not asking questions to clarify. It’s just diving right in. We humans ask ourselves a lot of questions before diving in so when we do it’s really precise.
When we use CC with a really great level of precision on a well defined context the probability of answering right goes up. That’s the new job we have with this tool.
I think one of the reasons "coding with AI" conversations can feel so unproductive, or at least vague, to me, is that people aren't talking about the same thing. For some, it means "vibe coding" ... tossing quick prompts into something like Cursor, banging out snippets, and hoping it runs. For others, it's using AI like a rubber duck: explaining problems, asking clarifying questions, maybe pasting in a few snippets. And then there's the more involved mode, where you're having a sustained back-and-forth with multiple iterations and refinements. Without recognizing those distinctions, the debate tends to talk past itself.
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 yesterday I gave gemini code a git worktree of the system I'm building at work. (Corp approved yadda yadda).
Can't remember the prompt was "evaluate the codebase and suggest any improvements. specifically on the <nameofsystem> system"
Then I tabbed out and did other stuff
Came back a bit later, checked out its ramblings. It misunderstood the whole system completely and tried to add a recursive system that wasn't even close to what it was supposed to be.
BUT it had detected an error message that just provided an index where parsing failed on some user input like "error at index (10)", which is completely useless for humans. But that's what the parser library gives us, so it's been there for a while.
It suggested a function that grabs the input, modifies it with a marker at the index given by the error message and shows clearly which bit in the input was wrong.
Could I have done this myself? Yes.
Would I have bothered, no I have actual features to add at this point.
Was it useful? Definitely. There was maybe 5 minutes of active work on my part and I got a nice improvement out of it.
And this wasn't the only instance.
Even the misunderstanding could've been avoided by me providing the agent better documentation on what everything does and where they are located.
I really think people are approaching LLMs wrong when it comes to code. Just directing an agent to make you something you’re unfamiliar with is always going to end up with this. It’s much better to have a few hours chat with the LLM and learn some about the topic, multiple times over many days, and then start.
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.
The problem is not in making something you're unfamiliar with. The problem is doing something that your familiar with, trying out an LLM to see if it can assist you, then you are kind of impressed for the first few prompts so you let it off the leash and suddently you find yourself in a convoluted codebase you would never write that way with so many weird often nonsensical things different to how you normally approach them (or any sane person would) so that you can basically throw it all in the trash. The only way this can be avoided is by diligently checking every single diff the LLM makes. but let's be honest, its just so damn inviting to let it off the leash for a moment.
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.
I recently had the following experience. I vibe-coded something in a language I'm not super familiar with, it seemed correct, it type-checked. Tests passed. Then reviewer pointed many stylistic issues and was rightfully pissed at me. When I addressed the comments, I realized I would not have made those mistakes had i written the code myself. It was a waste of time for me and the reviewer.
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.
Readit News
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.
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.
This is a nice way of putting it. And when the guard is tested or breached it’s time to add that item to the context files.
In that way, you are coding how you want coding to code.
Meaning you no longer write any code directly, or that you no longer use LLMs other than for coding tasks?
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!
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.
Well that's certainly a belief. Why are you not applying your lofty analysis to your own bias?
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.
Maybe. Or maybe a third prompt would have found more. And more on the fourth. And none on the fifth, despite some existing.
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.
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4945566
https://arxiv.org/abs/2302.06590
The METR study that you're likely talking about had a lot of nuances that don't get talked about, not to mention outright concerns e.g. this one participant revealed he had a pretty damning selection bias:
https://xcancel.com/ruben_bloom/status/1943536052037390531
Lots of people we're now conversing with could be junior or mid-level, might have tried it for little prototypes/experiments, or for more trivial software like commissioned websites, and so on. They could all be benefiting from agentic coding workflows in ways that we don't. With the caveat that the study you talked about also showed even the experience devs felt more productive, so clearly the use of AI biases your perception of delivery speed.
The large array of context I suspect is responsible for some of that dissonance on online discourse.
https://scholar.google.com/scholar?hl=en&q=llm%20developer%2...
> The only study I’ve seen so far on LLMs and productivity
Why are you guys all citing the same study in this thread? There are several studies including a survey paper.
[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...
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.
Replaced with a technology that rambles
Its advocates thought
This stuff is so hot
But in the end their brains were all scrambled
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?
Dead Comment
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.
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)
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
https://github.com/blebbit/at-mirror/commits/main/
- 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
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.
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.
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.
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.
Can't remember the prompt was "evaluate the codebase and suggest any improvements. specifically on the <nameofsystem> system"
Then I tabbed out and did other stuff
Came back a bit later, checked out its ramblings. It misunderstood the whole system completely and tried to add a recursive system that wasn't even close to what it was supposed to be.
BUT it had detected an error message that just provided an index where parsing failed on some user input like "error at index (10)", which is completely useless for humans. But that's what the parser library gives us, so it's been there for a while.
It suggested a function that grabs the input, modifies it with a marker at the index given by the error message and shows clearly which bit in the input was wrong.
Could I have done this myself? Yes.
Would I have bothered, no I have actual features to add at this point.
Was it useful? Definitely. There was maybe 5 minutes of active work on my part and I got a nice improvement out of it.
And this wasn't the only instance.
Even the misunderstanding could've been avoided by me providing the agent better documentation on what everything does and where they are located.
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.
Deleted Comment
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.