3 ms·

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

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

packetlost 2y ago
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
captainbland 2y ago
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.
- selfselfgo 2y ago
  [dead]
- master_crab 2y ago
  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.
herbst 2y ago
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.

packetlost 2y ago

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

captainbland 2y ago

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.

selfselfgo 2y ago
[dead]
master_crab 2y ago
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.

herbst 2y ago

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.