Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I'm Productive with Claude Code

neilkakkar.com

Post reply on HN
Print view View original

61–70 of 192 posts

Re: How I'm Productive with Claude Code

#61

Post by matheusmoreira »

vova_hn2 wrote: post #27
matheusmoreira wrote: post #13

Earlier 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 have quite a lot of skepticism about that as well. I didn't mean to imply I believed it. I was just trying to say that I wasn't lazily copy pasting the LLM output into my repository.

I'm taking the time to understand what it is proposing. I'm pushing back and asking for clarifications. When I implement things, I do it myself in my own way. I experienced a huge increase in my ability to make the cool stuff I've always wanted to make even in spite of this.

I can't even fathom how productive the people who have Claude Code cranking out features on multiple git worktrees in parallel must be. I wouldn't do that in my personal projects but I can totally understand doing that in a job setting.

Re: How I'm Productive with Claude Code

#62

Post by scorpioxy »

aguimaraes1986 wrote: post #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 de…

And the author has a blog post about burnout and anxiety. Maybe all of those things are related.

Working to the point of making yourself sick should not be seen as a mark of pride, it is a sign that something is broken. Not necessarily the individual, maybe the system the individual is in.

Re: How I'm Productive with Claude Code

#63

Post by jonahx »

williamcotton wrote: post #50
aguimaraes1986 wrote: post #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 de…

Lines of code are meaningful when taken in aggregate and useless as a metric for an individual’s contributions. COCOMO, which considers lines of code, is generally accepted as being accurate (enough) at estimating the value of a software system, at least as far as how courts (in the US) are concerned. https://en.wikipedia.org/wiki/COCOMO

> Lines of code are meaningful when taken in aggregate

The linked article does not demonstrate this. It establishes no causal link. One can obviously bloat LOC to an arbitrary degree while maintaining feature parity. Very generously, assuming good faith participants, it might reflect a kind average human efficiency within the fixed environment of the time.

Carrying the conclusions of this study from the 80s into the LLM age is not justified scientifically.

Re: How I'm Productive with Claude Code

#64

Post by dominotw »

Leynos wrote: post #53
dakiol wrote: post #41

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

> Serious planning. The plans should include constraints, scope, escalation criteria, completion criteria, test and documentation plan.

I feel like i am a bit stupid to be not able to do this. my process is more iterative. i start working on a feature then i disocover some other function thats silightly related. go refactor into commmon code then proceed with original task. sometimes i stop midway and see if this can be done with a libarary somewhere and go look at example. i take many detours like these. I am never working on a single task like a robot. i dont want claude to work like that either .That seems so opposite of how my brain works.

what i am missing.

Re: How I'm Productive with Claude Code

#65

Post by scuff3d »

aguimaraes1986 wrote: post #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 de…

Multiple agents in parallel "working on different features" is where people lose me. I don't care how much friction you've eliminated from the loop, eventually that code has to be looked at. Trying to switch between 5 different feature branches and properly review the code, even with AI help, if done properly is going to eat up most of not all the productivity improvements. The only way around it is to start pencils whipping reviews.

Re: How I'm Productive with Claude Code

#66

Post by MattGaiser »

dakiol wrote: post #41

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

Yep. In many cases I am just reviewing test cases it generated now.

> if it breaks, let agents fix it, no manual debugging needed!" ?

Pretty trivial to have every Sentry issue have an immediate first pass by AI now to attempt to solve the bug.

Re: How I'm Productive with Claude Code

#67

Post by sarchertech »

williamcotton wrote: post #50
aguimaraes1986 wrote: post #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 de…

Lines of code are meaningful when taken in aggregate and useless as a metric for an individual’s contributions. COCOMO, which considers lines of code, is generally accepted as being accurate (enough) at estimating the value of a software system, at least as far as how courts (in the US) are concerned. https://en.wikipedia.org/wiki/COCOMO

No one has any idea how to estimate software value, so the idea that some courts in the US have used a wildly inaccurate system that considers LOC is so far away from evidence that LOC is useful for anything that I can’t believe you bothered including that.

LOC is essentially only useful to give a ballpark estimate it complexity and even then only if you compare orders of magnitude and only between similar program languages and ecosystems.

It’s certainly not useful for AI generated projects. Just look at OpenClaw. Last I heard it was something close to half a million lines of code.

When I was in college we had a professor senior year who was obsessed with COCOMO. He required our final group project to be 50k LOC (He also required that we print out every line and turn it in). We made it, but only because we build a generator for the UI and made sure the generator was as verbose as possible.

Re: How I'm Productive with Claude Code

#68

Post by keeda »

williamcotton wrote: post #50
aguimaraes1986 wrote: post #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 de…

Lines of code are meaningful when taken in aggregate and useless as a metric for an individual’s contributions. COCOMO, which considers lines of code, is generally accepted as being accurate (enough) at estimating the value of a software system, at least as far as how courts (in the US) are concerned. https://en.wikipedia.org/wiki/COCOMO

> Lines of code are meaningful when taken in aggregate and useless as a metric for an individual’s contributions.

Yes, and in fact a lot of the studies that show the impact of AI on coding productivity get dismissed because they use LoC or PRs as a metric and "everyone knows LoC/PR counts is a BS metric." But the better designed of these studies specifically call this out and explicitly design their experiments to use these as aggregate metrics.

Re: How I'm Productive with Claude Code

#69

Post by groby_b »

aguimaraes1986 wrote: post #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 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 doesn't disqualify the metric, it just points out it's not a one-dimensional problem.

And for a solo project, it's fairly easy to hold most of these variables relatively constant. Which means "volume went up" is a pretty meaningful signal in that context.

Re: How I'm Productive with Claude Code

#70

Post by BoorishBears »

williamcotton wrote: post #50
aguimaraes1986 wrote: post #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 de…

Lines of code are meaningful when taken in aggregate and useless as a metric for an individual’s contributions. COCOMO, which considers lines of code, is generally accepted as being accurate (enough) at estimating the value of a software system, at least as far as how courts (in the US) are concerned. https://en.wikipedia.org/wiki/COCOMO

> at least as far as how courts (in the US) are concerned.

That's an anti-signal if we're being honest.

Post reply on HN