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.
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.