Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If you’re getting started, in say Claude, some pointers that helped me

Stay in plan mode most of the time. It will produce a step by step set of instructions - more context - for the LLM to execute the change. It’s the best place to exert detailed control over what will happen. Claude lets you edit it in a vim window.

Think about testing strategy carefully. Connecting the feedback back into the LLM is what makes a lot of the magic happen. But it requires thought or the LLM might cheat or you get a suboptimal result.

Then with these two you spend your time thinking in terms of product correctness - good tests - and implementation plan - deciding if the LLM has a sane grasp of the problem and will create a sane result.

You’re at a higher level of abstraction, still caring about details, but rarely finicky up to your elbows in line by line code.

If you can get good at these you’re well on your way.



Good points. Also:

Force it to have clear metrics / observability on what it is doing. For instance the other day I wanted Claude to modify a Commodore 64 emulator, and I started saying it to implement an observability framework where as the emulator run, it can connect to a socket and ask for registers, read/write memory areas, check the custom chips status, set breakpoints, ... As you can guess, after this the work is of a different kind.


Thank you -

I have coded since 4th grade, and your post made me less depressed about my career. Maybe even a tad hopeful.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: