Use them with care and remember to second-guess and inspect everything that comes out of them and you'll not only get good results, you'll hopefully learn and improve your own skills at the same time.

Full blog post: buff.ly/fjUnYRd

As a result of this, I spent most of my coding time yesterday refactoring and cleaning up code that I had previously created with the help of Claude Code. There were also a few bugs and design issues that needed to be fixed.

Absolutely, glad you liked it!

You can find the slides here
raniz85.github.io/talks_pipeli...

There's a PDF download button in the menu at the lower left of the window (only shows on hover).

I guess this is what the various instruction/guidelines files are for, but in my experience putting something in there is hit-or-miss since it seems to be ignored quite often.

They will remember this and not do the same mistake again (hopefully at least). A coding agent might find this instruction somewhere in the context for the rest of the session. But once I exit the session or it compacts the history it'll be gone and I'll have to provide the same instruction again.

If I'm teaching TDD to someone unfamiliar with it I can instruct them and give them reasons. If, for example, they throw an exception instead of returning a default response in a new method I can tell them that this doesn't make the assertion fail and as such doesn't count as a test failure.