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

81–90 of 192 posts

Re: How I'm Productive with Claude Code

#81

Post by cocoa19 »

scorpioxy wrote: post #62
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.

I’m glad I’m not the only one that noticed this is madness.

I find it crazy to build a complex system to juggle 10 different threads in your brain, including the complexity of the tool itself.

Re: How I'm Productive with Claude Code

#82

Post by anukin »

groby_b wrote: post #69
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 do…

Can you define what “all else” means here?

PRs or closed jira tickets can be a metric of productivity only if they add or improve the existing feature set of the product.

If a PR introduces a feature with 10 bugs in other features and I have my agent swarm fix those in 10-20 PRs in a week, my productivity and delivery have both taken a hit. If any of these features went to prod, I have lost revenue as well.

Shipping is not same as shipping correctly with minimal introduction of bugs.

Re: How I'm Productive with Claude Code

#84

Post by skydhash »

101011 wrote: post #52
skydhash wrote: post #49

Earlier quoted context omitted.

What about number of working features or system completeness? Current state vs desired state is fairly visible.

how do you define system completeness? what if you ship one really big feature vs three really small ones? I would posit that you need extra context to obtain meaning from those metrics, which inherently makes them less visible

System completeness can be defined from the product definition. The latter is where requirements and definitions of done come from. Working features are the most important thing and most principles and techniques were about reducing the cost to get there.

Re: How I'm Productive with Claude Code

#85

Post by skydhash »

> /git-pr removed the friction of formatting - turning code changes into a presentable PR.

What I want from a PR is what's not in the patch, especially the end goal of the PR, or the reasoning for the solution represented by the changes.

> SWC removed the friction of waiting - the dead time between making a change and seeing it.

Not sure how that relates to Claude Code.

> The preview removed the friction of verifying changes - I could quickly see what’s happening.

How Claude is "verifying" UI changes is left very vague in the article.

> The worktree system removed the friction of context-switching - juggling multiple streams of work without them colliding.

Ultimately, there's only one (or two) main branches. All those changes needs to be merged back together again and they needs to be reviewed. Not sure how collisions and conflicts is miraculously solved.

Re: How I'm Productive with Claude Code

#86

Post by Leynos »

dominotw wrote: post #64
Leynos wrote: post #53

Earlier quoted context omitted.

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…

Again, here's what works for me.

When I get an idea for something I want to build, I will usually spend time talking to ChatGPT about it. I'll request deep research on existing implementations, relevant technologies and algorithms, and a survey of literature. I find NotebookLM helps a lot at this point, as does Elevenreader (I tend to listen to these reports while walking or doing the dishes or what have you). I feed all of those into ChatGPT Deep Research along with my own thoughts about the direction the system, and ask it to produce a design document.

That gets me something like this:

https://github.com/leynos/spycatcher-harness/blob/main/docs/...

If I need further revisions, I'll ask Codex or Claude Code to do those.

Finally, I break that down into a roadmap of phases, steps and achievable tasks using a prompt that defines what I want from each of those.

That gets me this:

https://github.com/leynos/spycatcher-harness/blob/main/docs/...

Then I use an adapted version of OpenAI's execplans recipe to plan out each task (https://github.com/leynos/agent-helper-scripts/blob/main/ski...).

The task plans end up looking like this:

https://github.com/leynos/spycatcher-harness/blob/main/docs/...

At the moment, I use Opus or GPT-5.4 on high to generate those plans, and Sonnet or GPT-5.4 medium to implement.

The roadmap and the design are definitely not set in stone. Each step is a learning opportunity, and I'll often change the direction of the project based on what I learn during the planning and implementation. And of course, this is just what works for me. The fun of the last few months has been everyone finding out what works for them.

Re: How I'm Productive with Claude Code

#87

Post by the_arun »

browningstreet wrote: post #47
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…

Maybe author knows that too, but wants to talk about it nonetheless. First line of article: “Commits are a terrible metric for output, but they're the most visible signal I have.”

Using AI we can make 1000s of commits per day. This metric becomes even more pointless in the days of AI. If we increase sales, New subscription count, reduced bug count, reduced incidents etc., those can be real metrics. I'm sure I am preaching to the choir.

Re: How I'm Productive with Claude Code

#88

Post by Rover222 »

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…

Of course lines of code is a meaningful metric. It's not like the author said it's the ONLY meaningful metric.

Re: How I'm Productive with Claude Code

#89

Post by chadcmulligan »

Maybe 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 things in flutter after a week without reading a book or manual. It's like a talking encyclopaedia, or having an expert on tap, do many people use it like this? or am I just out of the loop, I always think of Star Trek when I'm doing it. I architected / designed a new system by asking Claude for alternatives and it gave me an option I'd never considered to a problem, it's amazing for this, after all it's read all the books and manuals in the world, it's just a matter of asking the right questions.

Re: How I'm Productive with Claude Code

#90

Post by tecleandor »

the_arun wrote: post #87
browningstreet wrote: post #47

Earlier quoted context omitted.

Maybe author knows that too, but wants to talk about it nonetheless. First line of article: “Commits are a terrible metric for output, but they're the most visible signal I have.”

Using AI we can make 1000s of commits per day. This metric becomes even more pointless in the days of AI. If we increase sales, New subscription count, reduced bug count, reduced incidents etc., those can be real metrics. I'm sure I am preaching to the choir.

I have coworkers commiting tens or hundreds of thousands of "lines of code" a week, because they'll push whatever the AI gives them, including dependencies and virtualenvs, without any review.

Of course, at the same time we're getting dozens of alerts a week about services deployed open to the Internet without authentication and full of outdated vulnerable libraries (LLMs will happily add two or three years old dependencies to your lockfiles).

Post reply on HN