alt Hacker NewsIf I know what I want to code and it's a purely mechanical exercise to code it, I'll just tell Claude what to do and it does it. Pretty neat.
When I don't know what I want to do, I read existing code, think about it, and figure it out. Sometimes I'll sketch out ideas by writing code, then when I have something I like I'll get Claude to take my sketch as an example and having it go forward.
The big mistake I see people make is not knowing when to quit. Even with Opus 4.5 it still does weird things, and I've seen people end up arguing with Claude or trying to prompt engineer their way out of things when it would have been maybe 30 seconds of work to fix things manually. It's like people at shopping malls who spend 15 minutes driving in the parking lot to find a spot close to the door when they could have parked in the first spot they saw and walked to the door in less than a minute.
And as always, every line of code was written by me even if it wasn't written by me. I'm responsible for it, so I review all of it. If I wouldn't have written it on my own without AI assistance I don't commit it.
Replies
If you see a good parking lot, look for a better one. - Mikhail Tal
Yep, I've always tried to live by the two classic XKCDs about automating things: https://xkcd.com/1319/ and https://xkcd.com/1205/.
I think these calculations are very different now that we have these very good LLMs, but they aren't irrelevant.
> The big mistake I see people make is not knowing when to quit.
This is sage advice. I spent the better part of a day trying to steer Gemini into correcting an inconsistency when I likely could have solved it in under an hour. I think persevering with Gemini was due to a number of factors, including novelty, stubbornness, and (unfortunately) not knowing in detail what Gemini had written up to that point.
I eventually studied the resulting code, which ended up having a number of nested 'hacks' and required refactoring - more time wasted, but still much faster overall.