Live data from Hacker News

How I'm Productive with Claude Code

neilkakkar.com

11–20 of 192 posts

Re: How I'm Productive with Claude Code

#11
This 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 developers used to push back on when management proposed it.

Turns out we weren't opposed to bad metrics! We were just opposed to being measured! Given the chance to pick our own, we jumped straight to the same nonsense.

Re: How I'm Productive with Claude Code

#13
post #5

I like llms too, and I think they make me more productive.. but a chart of commits/contribs is such a lousy metric for productivity. It's about on par with the ridiculousness of LOC implying code quality.

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 and cleaner. It's just that the tasks seemed so monumental I felt paralyzed and had difficulty even starting. Claude broke things down into manageable steps that were easy to do. Having a code review partner was also invaluable for a solo hobbyist like me.

Re: How I'm Productive with Claude Code

#14
post #5

I like llms too, and I think they make me more productive.. but a chart of commits/contribs is such a lousy metric for productivity. It's about on par with the ridiculousness of LOC implying code quality.

> It's about on par with the ridiculousness of LOC implying code quality.

Most effective engineers on the brownfield projects I've worked on, usually deleted more LOC than they've added, because they were always looking to simplify the code and replace it with useful (and often shorter) abstractions.

Re: How I'm Productive with Claude Code

#15
I've been doing a lot of parallel work and it can be draining. It feels exciting to have 6 agents spinning on things, but unless you have very well scoped plans, you need to still check in frequently.

If you have the tokens for it, having a team of agents checking and improving on the work does help a lot and reduces the slop.

Re: How I'm Productive with Claude Code

#16
post #9

> 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.

the way I handle this is that I just create pull requests (tell the agent to do it at the end), and then I'll come back at a later time to review, so I always have stuff queued up to review.

Re: How I'm Productive with Claude Code

#19
> 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.

Re: How I'm Productive with Claude Code

#20

This 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…

> Turns out we weren't opposed to bad metrics! We were just opposed to being measured! Given the chance to pick our own, we jumped straight to the same nonsense.

This seems like a distinction without a difference, unless there actually are any good metrics (which also requires them to be objectively and reliably quantifiable). I think most developers don't really want to measure themselves, it's just that pro-AI people think measurement is necessary to put forward a convincing argument that they've improved anything.

Post reply on HN