alt Hacker NewsClaude Code has genuinely changed my workflow. Not in a "write the whole thing for me" way - more like having a really fast pair who knows the codebase.
The pattern that works best for me: I describe what I want at a high level, let it scaffold, then I read through and course-correct. The reading step is crucial. Blindly accepting generates technical debt faster than you can imagine.
Where it really shines is the tedious stuff - writing tests for edge cases, refactoring patterns across multiple files, generating boilerplate that follows existing conventions. Things that would take me 45 minutes of context-switching I can knock out in 5.
The automation piece I've landed on: I let it handle file operations and running commands, but I stay in the loop on architecture decisions. The moment you start rubber-stamping those, you end up with a codebase you don't understand.
Replies
Pretty similar here. Another thing I keep thinking is a phrase pilots use when flying airplanes using FMSes and autopilot: "never fly your airplane to a place you haven't already been to in your mind" - that is, don't ever just sit back and let the automation work, stay a step ahead of the automation and drop down to less automation when you aren't certain that it is doing the right thing.
When you send Claude Code something and already have an idea for what an acceptable solution looks like, you're a massive step ahead when it's time to read the diff and decide what you think of it. This does mean that every so often my productivity drops to basically zero as I try to understand what is actually happening before I just put the AI on the job, but so far it seems to be a good rule to keep in mind that allows me to use AI effectively while generating a code base that I still understand.
Which Claude Code model do you usually use? Any noticeable differences?
Having AI generate tests is technical debt unless what you're doing is extremely trivial and well-trodden in which case you can basically gen all of the code and not care at all.
Tests are where the moat still exists because prior to creating tests the outcomes are unverifiable.
> The moment you start rubber-stamping those, you end up with a codebase you don't understand.
Yeah, treat it like an intern or junior engineer who needs constant feedback and reviews.
I have similar observations. The time saved is things like going to some library I wrote to find the exact order of parameters, or looking up some API on the internet and adjusting my code to it. Inevitably if I did that the old way, I would screw up something trivial and get annoyed.
I rarely let it run for over 10 minutes unattended, but the benefits are not just pure time.
Being able to change the code without getting bogged down allows you to try more things. If I have to wait half an hour between iterations, I'm going to run into bedtime quite fast.
On top of this, I'm finding that the thing that takes the deepest attention is often, amazingly, trivial things. Fiddling with a regex takes attention, but it doesn't often decide the success of the project.
By contrast, the actual work, which is making technical decisions, is something I can do without concentrating in the same way. It's strange that the higher value thing feels less stressful.
Put these together and I'm more productive. I can string together a bunch of little things, and not have to be at my sharpest. Work can be scheduled for whenever, which means days are more flexible. More gets done, with less attention.