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

161–170 of 192 posts

Re: How I'm Productive with Claude Code

#161

Post by neilkakkar »

imiric wrote: post #59

> The PR descriptions are more thorough than what I’d write, because it reads the full diff and summarises the changes properly. I’d gotten so used to the drudgery that I’d stopped noticing it was drudgery. Who are you creating PR descriptions for, exactly? If you consider it "drudgery", how do you think your coworkers will feel having to read pages of generic "AI" text? If reviewing can be considered "drudgery" as w…

I think you'd like this post I wrote: https://neilkakkar.com/agentic-debt.html , parts of why I think we wouldn't get automated away just yet. It might be true eventually - and when it does happen, I'm sure I'll find something else to do, most probably up the stack. Managing for now seems like a terrible task for agents. I need to guide them to the right solution.

_Parts_ of what I write are drudgery, which gets automated away. The "why" we talk about in sync, so it's much less of an issue in general.

When I say management, I mean more like a staff engineer or a tech lead, rather than a traditional manager.

Re: How I'm Productive with Claude Code

#162

Post by skydhash »

dominotw wrote: post #148
bmurphy1976 wrote: post #103

Earlier quoted context omitted.

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.

Building a fancy looking process doesnt mean output isnt slop. Vibecoders on reddit have even more insane "engineering" process. parent comment has all these Architecture & Design Principles • Single Responsibility Principle (SRP) • CQRS (Command Query Responsibility Segregation) • Domain Segregation • Domain-Driven Naming Conventions • Clear function/variable naming standards • Architectural constraint definition •…

And here I am, just drawing diagrams on a whiteboard and designing UI in Balsamiq.

Re: How I'm Productive with Claude Code

#163

Post by dominotw »

skydhash wrote: post #162
dominotw wrote: post #148

Earlier quoted context omitted.

Building a fancy looking process doesnt mean output isnt slop. Vibecoders on reddit have even more insane "engineering" process. parent comment has all these Architecture & Design Principles • Single Responsibility Principle (SRP) • CQRS (Command Query Responsibility Segregation) • Domain Segregation • Domain-Driven Naming Conventions • Clear function/variable naming standards • Architectural constraint definition •…

And here I am, just drawing diagrams on a whiteboard and designing UI in Balsamiq.

you are prbly shipping so that puts you ahead of most ppl still setting up their perfect process.

Re: How I'm Productive with Claude Code

#164

Post by orwin »

jmathai wrote: post #74
orwin wrote: post #60

Earlier quoted context omitted.

I like Claude, at least when the user reviews the code before asking for a PR. But gods I hate tickets/feature requests written by Opus/Sonnet (or worse: Codex or Gemini). If you know/understand your product enough it's probably less of a problem for your team than it is for mine, but each time I see a feature request automagically written in the backlog I know I will have to spend at least 30 minutes rewriting in so…

Is it that the tickets are too verbose?

A bit, but mostly it propose extremely well-rounded solutions that are almost never complete, and sometimes miss a major point. I would rather have my juniors work themselves to understand what is needed, or/and ask me questions rather than follow the ticket that is basically a Claude plan. Right now I am modifying and object that was incomplete and I will have to do a migration because I didn't catch the missing attribute during the PR. It isn't big, and we could have coded workaround instead of redesigning the object, but: workarounds complexify the code, the data is less intuitive, and that also means the person who wrote the original object do not really understand the goals.

With a less 'expensive' ticket, with less explanation about how things should be done, but why they are needed, we would have had discussions, in dailies or 1on1, and that could have been ironed out then.

Yeah, basically Claude generate tickets that are heavy on the 'how' and light on the 'why', and I think that should be the other way around, for multiple reasons, but I'm already long-winded.

Re: How I'm Productive with Claude Code

#167

Post by r_lee »

renegade-otter wrote: post #120
scuff3d wrote: post #65

Earlier quoted context omitted.

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…

Yes. Your brain, your clear thinking and your focus are the ultimate scarce resource. Writing code is easy, but I review one large PR from a coworker, and I need a nap. Claiming that you have "ten agents writing code at night" is not the flex you think it is. That's just a recipe for burnout and bad design decisions. Stop running your agents and go touch grass.

> I review one large PR from a coworker, and I need a nap.

feels like nowadays this is illegal and instead you should be running 50 agent swarms and be putting out 20 features an hour while reviewing the code via agents and .....

ugh.

Re: How I'm Productive with Claude Code

#168

Post by groby_b »

anukin wrote: post #82
groby_b wrote: post #69

Earlier quoted context omitted.

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…

"All else equal" means that PR volume is a signal that needs to be read in context a number of other metrics, as well as qualitative feedback.

You're absolutely right that PRs fixing things that a previous PR broke is a negative. Same for PRs implementing work not needed, or driving up tech debt.

"You're productive because you have lots of PRs" is a mistake without that context. But so is "You produce very little PRs, but that's fine, we shouldn't look at volume".

It's not a performance metric. It is an indicator worth following up. And there's a lot of reflexive "bad metric" arguments blanket dismissing that indicator.

Does that help explain?

Re: How I'm Productive with Claude Code

#169

Post by groby_b »

SpicyLemonZest wrote: post #105
groby_b wrote: post #69

Earlier quoted context omitted.

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

> But once you buy a car, the metric completely decouples, and no longer points towards your original fitness goals even a tiny bit.

True, but if what you care about is "how quickly and safely can I reach a given goal", distance traveled over time is a great initial indicator, and accident rate will help illuminate.

The question "does AI help me move faster towards a goal, at the same quality standard", is relatively easy to judge in a solo project. As long as you verify equivalent standards, and don't play in an area you don't know at least - folks have a pretty clear understanding of their own productivity if it's a familiar thing.

Re: How I'm Productive with Claude Code

#170

Post by jmalicki »

skydhash wrote: post #84
101011 wrote: post #52

Earlier quoted context omitted.

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.

If you only accept PRs that implement working features, i.e. you're not gaming it, then it's the same thing.

If you try to come up with an objective definition of working feature you're back to gamability criticism.

Post reply on HN