There is also this recent introduction to Claude Code by Boris Cherny who wrote it.

https://www.youtube.com/watch?v=6eBSHbLKuN0

Interesting that about 80% of developers at Anthropic are now using it.

There's a question at the end of the presentation about why is Claude Code a command line tool, not an IDE... basic answer was because command line is ubiquitous so it fits into everyone's workflow regardless of tool choice, but second part was more interesting ... That internal to Anthropic they are seeing how fast Claude itself is improving, and are projecting that using IDEs to develop software may shortly no longer make sense!

The hype for Claude Code has been huge!

I still feel that for large project, and large changes within those projects - I should write the code myself.

The code outputted often runs, especially after a few attempts of fixes etc. However when I read the code later, I can see often it could have been done in a much simpler way.

If so, why not prompt it to make a second pass with your observations and see how the results change?

Yeah sure that is possible - but you cannot achieve the same results as actually writing the code.

If you are going to write the code, you need to understand the full problem space, at which point you can see the simple solution.

If I need to figure this out, writing the code is not a problem and Claude becomes mostly an annoyance.

In a recent talk by the author (I just posted a link), he says a best practice for large requests (e.g. implement an entire project/solution) is to ask Claude Code to think about it and present you with alternative approaches/designs (which you can then review). You could provide feedback and iterate if you wanted to.

Ah. I find that I don't have enough focus on my projects where I use Claude and so it helps keep me focused, plus I can outline a task, hit send, and deal with the next crisis, then come back to what got generated and evaluate it.