I don't even need to read that article, I just can ask Claude how could I be more productive with Claude.
How I'm Productive with Claude Code
101–110 of 192 posts
Re: How I'm Productive with Claude Code
#102Earlier quoted context omitted.
Ive done a couple exploratory learning with AIs and wow could it help with learning. Imo we may be messing up the economy with AIs. They should be engineering better workers, not being employed to make one person do the work of three poorly. The power of AIs to smooth learning and raise expertise, rather than replace it, should be the adaptation goal. Obviously AIs as work assistants are powerful, but all the AI bull…
I find myself worrying the AI bubble will pop and we'll lose this aspect of AI's without it ever being properly explored. Instead of doomscrolling now I find myself firing up claude and saying 'explain ... to me' and it proceeds to tell me all about it. I can ask it questions and it seems fairly right - at least right enough for me to proceed, it's way better at this than building code, in my experience anyway.
When people say the "bubble will pop" it's meant in analogy to the dotcom era - businesses and investers lost money, but the internet (and its opportunities) didn't vanish.
Even open-weight local models are becoming good enough for teaching yourself quite a range of stuff, especially the beginner aspects. LLMs are not going to simply disappear because of a financial reallignment. The worst thing might be not being able to access a super-duper frontier model for free?
Re: How I'm Productive with Claude Code
#103Honest question: if you're using multiple agents, it's usually to produce not a dozen lines of code. It's to produce a big enough feature spanning multiple files, modules and entry points, with tests and all. So far so good. But once that feature is written by the agents... wouldn't you review it? Like reading line by line what's going on and detecting if something is off? And wouldn't that part, the manual reviewing…
Here's what I suggest: Serious planning. The plans should include constraints, scope, escalation criteria, completion criteria, test and documentation plan. Enforce single responsibility, cqrs, domain segregation, etc. Make the code as easy for you to reason about as possible. Enforce domain naming and function / variable naming conventions to make the code as easy to talk about as possible. Use code review bots (Sou…
Can't upvote you enough. This is the way. You aren't vibe coding slop you have built an engineering process that works even if the tools aren't always reliable. This is the same way you build out a functioning and highly effective team of humans.
The only obvious bit you didn't cover was extensive documentation including historical records of various investigations, debug sessions and technical decisions.
Re: How I'm Productive with Claude Code
#104This is the "lines of code per week" metric from the 90s, repackaged. "I'm doing more PRs" is not evidence that AI is working, it's evidence that you are merging more. Whether thats good depends entirely on what you are merging. I use AI every day too. But treating throughput of code going to production as a success metric, without any mention of quality, bugs, or maintenance burden is exactly the kind of thinking de…
Here's the thing every discussion around this tries to weasel around: All else being equal, yes, more PRs is a signal of productivity. It's not the only metric. But I'm more and more convinced that the people protesting any discussion of it are the ones who... don't ship a lot. Of course it matters in what code base. What size PR. How many bugs. Maintenance burden. Complexity. All of that doesn't go away. But that do…
Number of integration tests might be a good metric (until you announce that it is the metric then like every other metric, inc. profit, it becomes useless!)
For profit failing as a metric, see: Enron.
Re: How I'm Productive with Claude Code
#105This is the "lines of code per week" metric from the 90s, repackaged. "I'm doing more PRs" is not evidence that AI is working, it's evidence that you are merging more. Whether thats good depends entirely on what you are merging. I use AI every day too. But treating throughput of code going to production as a success metric, without any mention of quality, bugs, or maintenance burden is exactly the kind of thinking de…
Here's the thing every discussion around this tries to weasel around: All else being equal, yes, more PRs is a signal of productivity. It's not the only metric. But I'm more and more convinced that the people protesting any discussion of it are the ones who... don't ship a lot. Of course it matters in what code base. What size PR. How many bugs. Maintenance burden. Complexity. All of that doesn't go away. But that do…
The problem is that these caveats, while tolerable in some contexts, make the metric impossible to interpret for something like Claude Code which is (I agree!) a huge change in how most software is developed.
If you mostly get around on your feet, distance traveled in a day is a reasonable metric for how much exercise you got. It's true that it also matters how you walk and where you walk, but it would be pretty tedious to tell someone that a "3 mile run" is meaningless and they must track cardiovascular health directly. It's fine, it works OK for most purposes, not every metric has to be perfect.
But once you buy a car, the metric completely decouples, and no longer points towards your original fitness goals even a tiny bit. It's not that cars are useless, or that driving has a magic slowdown factor that just so happens to compensate for your increased distance travelled. The distance just doesn't have anything to do with the exercise except by a contingent link that's been broken.
Re: How I'm Productive with Claude Code
#106Earlier quoted context omitted.
I don't know. Claude helped me implement a ton of features I had been procrastinating for months in a matter of days. I'm implementing features in my project faster than I can blog about them. It definitely manifested as a huge commit spike. And it's not like I'm blindly commiting LLM output. I often write everything myself because I want to understand what I'm doing. Claude often comments that my version is better a…
> Claude often comments that my version is better and cleaner. Every comment I make is a "really perceptive observation" according to Claude and every question I ask is either "brilliant" or at least "good", so...
I do think this is a learnable skill. I haven't quite gotten Claude to push back as much as I would prefer, but there's a specific tone to strike where the average person in your position would expect and welcome being told they're wrong.
Re: How I'm Productive with Claude Code
#107> The PR descriptions are more thorough than what I’d write Why do people do this? Why do they outsource something that is meant to have been written by a human, so that another human can actually understand what that first human wanted to do, so why do people outsource that to AI? It just doesn't make sense.
> Why do they outsource something that is meant to have been written by a human
Says who? The point of the summary is so that I don't have to go look at the diff and figure out what happened.
Re: How I'm Productive with Claude Code
#108> The worktree system removed the friction of context-switching - juggling multiple streams of work without them colliding. I'm so conflicted about this. On the one hand I love the buzz of feeling so productive and working on many different threads. On the other hand my brain gets so fried, and I think this is a big contributor.
I would like some research regarding multi agent flows and impact on speed and correctness, because I have a feeling that it's like a texting and driving situation, where self perception of skill loss and measured skill loss diverge. I have nothing to back up the idea though.
I am just running multiple agents to work on different projects. Once in a while I have a feature that splits nicely into multiple threads that can be developed concurrently, and I use several concurrent agents to do it. But that is rare.
Re: How I'm Productive with Claude Code
#109Maybe OT - I find Claude Code hit or miss, I spend a lot of time removing dumb code or asking Claude to remove it eg "why do you have a separate..." Claude: "Good catch — there's no real reason...." and so on. Where I find it incredible - learning new things, I recently started flutter/dart dev - I just ask Claude to tell me about the bits, or explaining things to me, it's truly revolutionary imho, I'm building thing…
Many people use it like this - this is playing to its strengths, rather than trying to work around its weaknesses. "What's the idiomatic X language way to do Y?" gets you a solid, useful answer in seconds.
But it's just a damn good tool, not the apocalypse/the thing that lets you finally fire everyone. So it kind of gets lost in the hype.
Re: How I'm Productive with Claude Code
#110> The worktree system removed the friction of context-switching - juggling multiple streams of work without them colliding. I'm so conflicted about this. On the one hand I love the buzz of feeling so productive and working on many different threads. On the other hand my brain gets so fried, and I think this is a big contributor.
Is constant juggling of multiple agents productive? I haven't seen the allure (except maybe with 2 agents sometimes). I guess it depends on what kind of tasks one is doing and I can imagine it working if doing large, long-running tasks, but then reviewing those large changes and refactoring becomes more difficult. And if you're juggling multiple agents, there's the mental context switching and tooling overhead for ma…
I have two modes. Mostly what you describe (phase 1), but followed by "project management" (phase 2), where I iterate through the impementing the plan done in phase 1.