Comment by frereubu
4 months ago
> treat the AI like a super-speedy but junior developer on your team
That sounds like it's going to take a lot more time that just writing the code for an experienced developer. The issue with AI for me is that it produces plausible-looking code which requires a lot of attention to read through, because things that look superficially "right", including any justification in code comments, can actually have really problematic flaws.
I remember when I'd rushed a piece of work when studying, I had a lecturer who told us something like:
There are a few kinds of developers: good, bad, slow and fast. Everyone wants to be a good developer but a fast and bad developer is worse than a slow and bad developer because they end up doing so much damage.
He could have been copying General Kurt Hammerstein. Paraphrasing here:
There are four kinds of military officers: smart and lazy, smart and hard working, dumb and hardworking, dumb and lazy.
Keep the dumb and hardworking away from any high level position. They actively make things worse. Dumb and lazy are useful for simple tasks with oversight. Smart and hardworking are excellent for high level staff and analyst positions.
The Smart and Lazy should be saved for high level command. They expend only the energy necessary to get the job done and then focus on the next important task.
[dead]
Except you ask it to not to. Sure it's far from perfect but honestly that is not an issue. If you ask Claude to study and document the codebase and then write unit tests I am sure there are only very few broken ones, less hallucination more like real small bugs.
I've found utility + speed go up the more conservative (in number of lines) the model generates. If it only completed a line it's much more likely to be exactly what I was about to type