

I’m a professional developer and have tested AI tools extensively over the last few years as they develop. The economic implications of the advancements made over the last few months are simply impossible to ignore. The tools aren’t perfect, and you certainly need to structure their use around their strengths and weaknesses, but assigned to the right tasks they can be 10% or less of the cost with better results. I’ve yet to have a project where I’ve used them and they didn’t need an experienced engineer to jump in and research an obscure or complex bug, have a dumb architectural choice rejected, or verify if stuff actually works (they like reporting success when they shouldn’t), but again the economics; the dev can be doing other stuff 90% of the time.
Don’t get me wrong, on the current trajectory this tech would probably lead to deeply terrible socioeconomic outcomes, probably techno neofeudalism, but for an individual developer putting food on the table I don’t see it as much of a choice. It’s like the industrial revolution again, but for cognitive work.
I’ve used it most extensively doing Ruby on Rails greenfield apps, and also some JS front ends, some Python mid sized apps, and some Rust and Nix utilities. You’re absolutely right about it struggling with code base scale, I had to rework the design process around this. Essentially, design documentation telling the story, workflow documentation describing in detail every possible functionality, and an iteration schedule. So the why, what, and how formalized and in detail, in that order. It can generate the bulk of those documents given high level explanations, but require humans to edit them before making them the ‘golden’ references. Test driven development is beyond critical, telling it everywhere to use it extensively with writing failing tests first seems to work best.
So to actually have it do a thing I load those documents into context, give it a set unit of work from the iteration schedule, and work on something else.
It does go down some seriously wrong paths sometimes, like writing hacky work arounds if it incorrectly diagnosing some obscure problem. I’ve had a few near misses where it tried to sneak in stuff that would bury future work in technical debt. Most problematic is it’s just subtle enough that a junior dev might miss it; they’d probably get sent down a rabbit hole with several layers of spaghetti obscuring the problem.