In this case the evidence is literally first-hand experience. There is nothing that will change my mind on this because it’s my direct personal experience from actual use.
I honestly don’t care what marketing says, and if other people have different experiences then that’s just them. In my personal actual real-world experience I found that they let me get tons more done and their quality of work is perfectly fine as long as you’re using the right tools and giving them the right instructions.
The article says that developers are disagreeing with that in situations where they are “forced” to use AI, and that’s fair, it doesn’t make sense to force a tool to be used for something it’s not good at. They might be using it wrong. I use it whenever it’s better than not using it, and that ends up being quite often in my workflow.
using the right tools and giving them the right instructions.
The right tools is definitely key. Back an eternity ago, like October 2025, there was only Claude IMO if you wanted anything bigger than about a page of code. The others have come a long way - better than Claude was then, and I still feel like Claude is out in front, though by a less dramatic margin now.
As for “the right instructions” - I’d say it’s more of “use the right process” which basically involves applying all those best practices that have developed over the past decades for human development, but we old farts from back before their time “don’t need all that, it’s a waste of time” because, basically, we internally practice most of the discipline without doing the documentation. With the AI tools: document your requirements, your architecture, tool choice selection process, designs, development plan, comment the code with traceability to why the code is being written, unit and integration tests, reviews, lessons learned, etc. etc. Having all that documentation kept with the project, well organized, is key to “bringing the AI agent up to speed” which you may be doing often. They really do demonstrate the eternal sunshine of the spotless mind, so if you have them take the time to write everything relevant down as they go (not just the code), then when a new one comes online it can jump into the middle of a development plan without repeating (as many) mistakes / making (as many) bad assumptions.
To be brutally honest, working with AI coding agents reminds me a LOT of working with overseas programmer consultants - if you don’t get everything in writing you’re gonna have a bad time.
Indeed. My usual analogy is “it’s a team of junior devs at your beck and call, who will do a huge amount of work quickly when you tell them to so make sure you told them to do the right work.”
As for the documentation, commenting, unit tests, and so forth - AI is very handy for getting that stuff written too, just make sure to check up on it. For large pieces of work I will often tell the AI to write up an architecture document first, as a separate step, both to make sure it understands what I asked for and to store as future reference for the AI to make sure it doesn’t “forget” how the code is supposed to work or why it exists.
There was a fun Python application I worked with an AI on a few months back where most of the code ran as a conventional Python program in a conventional Python environment, but one particular file was being “injected” into an entirely separate and very locked-down Python sandbox to use as a bridge between that sandbox and the rest of the application out in the outside world. That particular file would be the only one that was able to import key modules and access key data, and it couldn’t import any other modules that the “outside” application might have access to. Two very different execution environments bundled together in the same repository. But I made sure the file had comments explaining this strange setup and that there were system architecture documents explaining how it worked, and I only recall having to remind the AI once or twice that the change it wanted to make would run afoul of that. It otherwise managed the separation of functionality just fine. And that was with the previous generation of models, the current ones are even better.
having to remind the AI once or twice that the change it wanted to make would run afoul of that.
I find that doing periodic “directed reviews” with the AI agent looking for violations is helpful. Not a 100% guarantee of compliance on the first pass, but pretty close after 3 or 4 passes from varying perspectives.
Also, when something is really important, having the agent break up the changes as small as practical, then reviewing each change by hand as it goes through, definitely is more confidence inspring than attempting to review 3000 lines of change in a 20,000 line module of code all at once against a 20 page description of changes.
Unfortunately your being downvoted by the echo chamber participants that have to make sure you know that your opinion is wrong and theirs is better. AI is a tool, just like my impact gun. Yea there are times where you absolutely should not use an impact gun on something, but it’s THE tool for some situations. And yea, using an impact gun where you should t will get you in trouble just like using AI in situations you shouldn’t will get you in trouble. There is nothing new on that front!
In this case the evidence is literally first-hand experience. There is nothing that will change my mind on this because it’s my direct personal experience from actual use.
I honestly don’t care what marketing says, and if other people have different experiences then that’s just them. In my personal actual real-world experience I found that they let me get tons more done and their quality of work is perfectly fine as long as you’re using the right tools and giving them the right instructions.
The article says that developers are disagreeing with that in situations where they are “forced” to use AI, and that’s fair, it doesn’t make sense to force a tool to be used for something it’s not good at. They might be using it wrong. I use it whenever it’s better than not using it, and that ends up being quite often in my workflow.
The right tools is definitely key. Back an eternity ago, like October 2025, there was only Claude IMO if you wanted anything bigger than about a page of code. The others have come a long way - better than Claude was then, and I still feel like Claude is out in front, though by a less dramatic margin now.
As for “the right instructions” - I’d say it’s more of “use the right process” which basically involves applying all those best practices that have developed over the past decades for human development, but we old farts from back before their time “don’t need all that, it’s a waste of time” because, basically, we internally practice most of the discipline without doing the documentation. With the AI tools: document your requirements, your architecture, tool choice selection process, designs, development plan, comment the code with traceability to why the code is being written, unit and integration tests, reviews, lessons learned, etc. etc. Having all that documentation kept with the project, well organized, is key to “bringing the AI agent up to speed” which you may be doing often. They really do demonstrate the eternal sunshine of the spotless mind, so if you have them take the time to write everything relevant down as they go (not just the code), then when a new one comes online it can jump into the middle of a development plan without repeating (as many) mistakes / making (as many) bad assumptions.
To be brutally honest, working with AI coding agents reminds me a LOT of working with overseas programmer consultants - if you don’t get everything in writing you’re gonna have a bad time.
Indeed. My usual analogy is “it’s a team of junior devs at your beck and call, who will do a huge amount of work quickly when you tell them to so make sure you told them to do the right work.”
As for the documentation, commenting, unit tests, and so forth - AI is very handy for getting that stuff written too, just make sure to check up on it. For large pieces of work I will often tell the AI to write up an architecture document first, as a separate step, both to make sure it understands what I asked for and to store as future reference for the AI to make sure it doesn’t “forget” how the code is supposed to work or why it exists.
There was a fun Python application I worked with an AI on a few months back where most of the code ran as a conventional Python program in a conventional Python environment, but one particular file was being “injected” into an entirely separate and very locked-down Python sandbox to use as a bridge between that sandbox and the rest of the application out in the outside world. That particular file would be the only one that was able to import key modules and access key data, and it couldn’t import any other modules that the “outside” application might have access to. Two very different execution environments bundled together in the same repository. But I made sure the file had comments explaining this strange setup and that there were system architecture documents explaining how it worked, and I only recall having to remind the AI once or twice that the change it wanted to make would run afoul of that. It otherwise managed the separation of functionality just fine. And that was with the previous generation of models, the current ones are even better.
I find that doing periodic “directed reviews” with the AI agent looking for violations is helpful. Not a 100% guarantee of compliance on the first pass, but pretty close after 3 or 4 passes from varying perspectives.
Also, when something is really important, having the agent break up the changes as small as practical, then reviewing each change by hand as it goes through, definitely is more confidence inspring than attempting to review 3000 lines of change in a 20,000 line module of code all at once against a 20 page description of changes.
Unfortunately your being downvoted by the echo chamber participants that have to make sure you know that your opinion is wrong and theirs is better. AI is a tool, just like my impact gun. Yea there are times where you absolutely should not use an impact gun on something, but it’s THE tool for some situations. And yea, using an impact gun where you should t will get you in trouble just like using AI in situations you shouldn’t will get you in trouble. There is nothing new on that front!
I don’t disagree with the post you are responding to, almost all of that is reasonable.
Your overall argument would be more convincing if it wasn’t you doing the exact same thing you are complaining about.
As for specifics , the “Just a tool” argument is meh, not all tools are equal in potential benefit and harm.
Asbestos (while it is a material) was a “tool” used to insulate from heat.
Was it good at that, sure, it probably saved many lives, was it also harmful as fuck in the medium to long term, yes it was.
It can be a useful tool and also be a detriment, those things aren’t mutually exclusive.
The danger of a tool can also be mitigated with adequate safeguards that come from experience gained over time.
The argument then becomes risk vs reward, which is an entirely different conversation.