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

51–60 of 192 posts

Re: How I'm Productive with Claude Code

#51

Post by layer8 »

bluelightning2k wrote: post #32
dakiol wrote: post #22

I don't understand the "being more productive" part. Like, sure, LLMs make us iterate faster but our managers know we're using them! They don't naively think we suddenly became 10x engineers. Companies pay for these tools and every engineer has access to them. So if everyone is equally productive, the baseline just shifted up... same as always, no? Mentioning LLM usage as a distinction is like bragging about using a…

Sometimes outcomes and achievements and work product are useful beyond just... stack ranking yourself against your peers. Seems so odd to me that this is your mentality unless you're earlier in your career.

Usually hedonic adaptation ends up catching up, and then it’s just the new baseline.

Re: How I'm Productive with Claude Code

#52

Post by 101011 »

skydhash wrote: post #49
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.”

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

Re: How I'm Productive with Claude Code

#53

Post by Leynos »

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 (Sourcery, CodeRabbit, and Codescene). They catch the small things (violations of contract, antipatterns, etc.) and the large (ux concerns, architectural flaws, etc.).

Go all in on linting. Make the rules as strict as possible, and tell the review bots to call out rule subversions. Write your own lints for the things the review bots are complaining about regularly that aren't caught by lints.

Use BDD alongside unit tests, read the .feature files before the build and give feedback. Use property testing as part of your normal testing strategy. Snapshot testing, e2e testing with mitm proxies, etc. For functions of any non-trivial complexity, consider bounded or unbounded proofs, model checking or undefined behaviour testing.

I'm looking into mutation testing and fuzzing too, but I am still learning.

Pause for frequent code audits. Ask an agent to audit for code duplication, redundancy, poor assumptions, architectural or domain violations, TOCTOU violations. Give yourself maintenance sprints where you pay down debt before resuming new features.

The beauty of agentic coding is, suddenly you have time for all of this.

Re: How I'm Productive with Claude Code

#54

Post by prmoustache »

So many pretend they are more productive but so few are able to articulate what they actually produced.

Some says features. Well. Are they used. Are they beneficial in any way for our society or humanity? Or are we junk producing for the sake of producing?

Re: How I'm Productive with Claude Code

#56

Post by [deleted] »

skydhash wrote: post #49
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.”

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

[deleted]

Re: How I'm Productive with Claude Code

#57

Post by jwpapi »

I have a little ai-commit.sh as "send" in package.json which describes my changes and commits. Formatting has been solved by linters already. Neither my approach nor OP approach are ground-breaking, but i think mine is faster, you also !p send (p alias pnpm) inside from claude no need for it to make a skill and create overhead..

Like thinking about it a pr skill is pretty much an antipattern even telling ai to just create a pr is faster.

I think some vibe coders should let AI teach them some cli tooling

Re: How I'm Productive with Claude Code

#58

Post by Sabu87 »

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…

I'm also trying everything to learn how to use Claude, everything is so new. And keep upgrading.

Re: How I'm Productive with Claude Code

#59

Post by imiric »

> 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 well, can we also offload that to "AI"? In which case, why even bother with PRs at all? Why are you still participating in a ceremony that was useful for humans to share knowledge and improve the codebase, when machines don't need any of it?

> My role has changed. I used to derive joy from figuring out a complicated problem, spending hours crafting the perfect UI. [...] What’s become more fun is building the infrastructure that makes the agents effective. Being a manager of a team of ten versus being a solo dev.

Yeah, it's great that you enjoy being a "manager" now. Personally, that is not what I enjoy doing, nor why I joined this industry.

Quick question: do you think your manager role is safe from being automated away? If machines can write code and prose now better than you, couldn't they also manage other machines into producing useful output better than you? So which role is left for you, and would you enjoy doing it if "manager" is not available?

Purely rhetorical, of course, since I don't think the base premise is true, besides the fact that it's ignoring important factors in software development such as quality, reliability, maintainability, etc. This idea that the role of an IC has now shifted into management is amusing. It sounds like a coping mechanism for people to prove that they can still provide value while facing redundancy.

Re: How I'm Productive with Claude Code

#60

Post by orwin »

jmathai wrote: post #2

This is basically the same workflow I've come to adopt. I don't use any "pre-built" skills, mine are actually still .md files in the .claude/command/ folder because that's when I started. The workflow is so good, I'm the bottleneck. I've started to use git worktrees to parallelize my work. I spend so much time waiting...why not wait less on 2 things? This is not a solved problem in my setup. I have a hard time managi…

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 that it doesn't take us one hour to refine it collectively.
Post reply on HN