13 ms·

How I'm Productive with Claude Code

281 points by neilkakkar 6mo ago

jmathai 6mo ago
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 managing just two agents and keeping them isolated. But again, I'm the bottleneck. I think I could use 5 agents if my brain were smarter........or if the tools were better. I am also a PM by day and I'm in Claude Code for PM work almost 90% of my day.
- orwin 6mo ago
  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.
  - jmathai 6mo ago
    Is it that the tickets are too verbose?
    - orwin 6mo ago
      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.
      - jmathai 6mo ago
        Yup. Makes a lot of sense.
CrzyLngPwd 6mo ago
`And like any good manager, you get to claim credit for all the work your “team” does.` Is that how it works? Do managers claim credit for the work of those below them, despite not doing the work? I hope they also get penalised when a lowly worker does a bad thing, even if the worker is an LLM silently misinterpreting a vague instruction.
- idiotsecant 6mo ago
  Yes. That is how management works. Although a good manager will focus some of that praise onto team members who deserve it.
- jmathai 6mo ago
  Yup, the manager gets implicit credit for the work their team does. In most cases, deservedly so. I don't see why it should be any different for engineers using LLMs as "direct reports". Not all engineers will be the same level of "good" with LLM tools so the better you are (as with any other skill as well) the more credit you would receive.
- dakiol 6mo ago
  Are you kidding? What else would managers get credit from? They don't produce anything the company is interested in. They steer, they manage, and so if the ones being managed produce the thing the company is interested in, then sure all the credit goes to the team (including the manager!). As it usually happens, getting credit means nothing if not accompanied by a salary bump or something like that. And as it usually happens, not the whole team can get a salary bump. So the ones who get the bump are usually one or two seniors on the team, plus the manager of course... because the manager is the gatekeeper between upper management (the ones who approve salary bumps) and the ICs... and no sane manager would sacrifice a salary bump for themselves just to give it away to an IC. And that's not being a bad manager, that's simply being human. Also if you think about it, if the team succeeded in delivering "the thing", then the manager would think it's partially because of their managing, and so he/she would believe a salary bump is deserved When things go south, no penalization is made. A simple "post-mortem" is written in confluence and people write "action items". So, yeah, no need for the manager to get the blame. It's all very shitty, but it's always been like that.
markbao 6mo ago
> What’s become more fun is building the infrastructure that makes the agents effective. Solving new problems is a thing engineers get to do constantly, whereas building an agent infrastructure is mostly a one-ish time thing. Yes, it evolves, but I worry that once the fun of building an agentic engineering system is done, we’re stuck doing arguably the most tedious job in the SDLC, reviewing code. It’s like if you were a principal researcher who stopped doing research and instead only peer reviewed other people’s papers. The silver lining is if the feeling of faster progress through these AI tools gives enough satisfaction to replace the missing satisfaction of problem-solving. Different people will derive different levels of contentment from this. For me, it has not been an obvious upgrade in satisfaction. I’m definitely spending less time in flow.
serf 6mo ago
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.
- matheusmoreira 6mo ago
  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.
  - munk-a 6mo ago
    This right here is the big value I see in LLMs as well. I specifically suffer from analysis paralysis when starting something big and just getting skeletonized cheap code out quick as a template then refining it is much more to my strengths. I am ADHD and task breakdown is a known difficulty for that disorder so it has been hugely helpful. That said, by the time I'm happy with it all the AI stuff outside very boilerplate ops/config stuff has been rewritten and refined. I just find it quite helpful to get over that initial hump of "I have nothing but a dream" to the stage of "I have a thing that compiles but is terrible". Once I can compile it then I can refine which where my strengths lie.
  - vova_hn2 6mo ago
    > 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...
    - 6mo ago
MeetingsBrowser 6mo ago
> I’m not “using a tool that writes code.” I’m in a tight loop: kick off a task, the agent writes code, I check the preview, read the diff, give feedback or merge, kick off the next task the assumption to this workflow is that claude code can complete tasks with little or no oversight. If the flow looks like review->accept, review->accept, it is manageable. In my personal experience, claude needs heavy guidance and multiple rounds of feedback before arriving at a mergeable solution (if it does at all). Interleaving many long running tasks with multiple rounds of feedback does not scale well unfortunately. I can only remember so much, and at some point I spend more time trying to understand what has been done so far to give accurate feedback than actually giving feedback for the next iteration.
felipevb 6mo ago
> 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.
- dgunay 6mo ago
  I do parallel agents in worktrees and I don't always constantly keep an eye on them like a fry cook flipping 20 burgers at once. Sometimes it's just nice to know that I can spin one up, come back tomorrow, and some progress has been made without breaking my current flow.
- saadn92 6mo ago
  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.
- torben-friis 6mo ago
  I would like some research regarding multi agent flows and impact on speed and correctness, because I have a feeling that it's like a texting and driving situation, where self perception of skill loss and measured skill loss diverge. I have nothing to back up the idea though.
  - saadn92 6mo ago
    you do lose context, but if you generate a plan beforehand and save it, then it makes it easier to gain that context when you come back. I've been able to get out things a lot more quickly this way, because instead of "working" that day, I'll just review the work that's been queued up and focus on it one at a time, so I'm still the bottle neck but it has allowed me to move more quickly at times
  - jannyfer 6mo ago
    Ooooh very interesting idea. I also have nothing to back it up, but it fits my mental models. When juggling multiple things as humans, it eats up your context window (working memory). After a long day, your coherence degrades and your context window needs flushing (sleeping) and you need to start a new session (new day, or post-nap afternoon).
aguimaraes1986 6mo ago
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.
- zahlman 6mo ago
  > 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.
  - sodapopcan 6mo ago
    The only time metrics have been useful to me in the past is when they are kept private to each team, which is to say that I do think they are useful for measuring yourself, but not for others to measure you. Taken over time, they can eventual give you a really good idea of what you can deliver. Sandbag a bit (ie, undershoot that number), communicate that to ye olde stakeholders, and everybody's happy that you can actually do what you say you'll do without being stressed out (obviously this doesn't work in startups).
- browningstreet 6mo ago
  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.”
deleted 6mo ago
[deleted]
tomasz-tomczyk 6mo ago
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.
mpalmer 6mo ago
[dead]
deleted 6mo ago
[deleted]
paganel 6mo ago
> 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.
- paulhebert 6mo ago
  Yeah I agree. We have “Cursor Bot” enabled at work. It reviews our PRs (in addition to a human review) One thing it does is add a PR summary to the PR description. It’s kind of helpful since it outlines a clear list of what changed in code. But it would be very lacking if it was the full PR description. It doesn’t include anything about _why_ the changes were made, what else was tried, what is coming next, etc.
- ytoawwhra92 6mo ago
  Same reason they outsource writing their blog posts. This weird notion that the purpose of the thing is the thing itself, not what people get out of the thing. Tracks completely that a person who thinks their number of commits and think that shows how productive they are (while acknowledging that it's a poor metric and just shrugging).
- godd2 6mo ago
  > Why do they outsource something that is meant to have been written by a human Says who? The point of the summary is so that I don't have to go look at the diff and figure out what happened.
  - piva00 6mo ago
    The point of the summary is also to explain "why" something was done, most Claude-generated PR descriptions I've been seeing go through the "what" and "how" but if the human-in-the-loop didn't care to precisely describe the "why" it is just an English version of the changes made in the code... I can just read the code for that, give me the reasons behind the diff and I'm a happy camper.
dakiol 6mo ago
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 modern compiler instead of writing assembly. Yeah it's faster, but so is everyone else code... Besides, I wouldn't brag about being more productive with LLMS because it's a double edge sword: it's very easy to use them, and nobody is reviewing all the lines of code you are pushing to prod (really, when was the last time you reviewed a PR generated by AI that changed 20+ files and added/removed thousands of lines of code?), so you don't know what's the long game of your changes; they seem to work now but who knows how it will turn out later?
- bluelightning2k 6mo ago
  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.
  - dakiol 6mo ago
    Fair enough. I've been in software more than I would like to admit. And the more I'm in, the less I care about achievements in a work environment. All I care about is that the company pays me every month, because companies don't care about me (they care about my outome per hour/week/month). So it's essential to rank yourself high against your peers (being ethically and the like, ofc), otherwise you are out in the next layoff. I know not every company is like this, but the vast majority of tech companies are. Outside of work, yeah, everything is fine and there's nothing but the pure pursue of knowledge and joy.
    - exogenousdata 6mo ago
      All companies are like this. Some just have better HR/PR.
ayhanfuat 6mo ago
I don't know if I am just in an unlucky A/B assignment or anything but I really don't understand people juggling multiple agent sessions. For me Opus 4.6 High performance went from unbelievable to mediocre. And this keeps happening making the whole agentic coding very unreliable and frustrating. I do use it but I have to babysit and I get overwhelmed even with a single session.
keybored 6mo ago
As an outsider it seems like agentic coders get buried in the weeds of running agents in parallel and churning out commits. (Even after a sheepish “commits are a bad metric but”) And every week there is a new orchestration, something, who even cares. Is that the end game? Well why can’t the agents orchestrate the agents? Agents all the way down? The whole agent coding scene seems like people selling their soul for very shiny inflatable balloons. Now you have twelve bespoke apps tailored for you that you don’t even care about.
jikojkb 6mo ago
[dead]
deleted 6mo ago
[deleted]
leontloveless 6mo ago
[dead]
aplomb1026 6mo ago
[dead]
dakiol 6mo ago
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, take an enormous amount of time compare to the time it took the agents to produce it? (you know, it's more difficult to read other people's/machine code than to write it yourself)... meaning all the productivity gained is thrown out the door. Unless you don't review every generated line manually, and instead rely on, let's say, UI e2e testing, or perhaps unit testing (that the agents also wrote). I don't know, perhaps we are past the phase of "double check what agents write" and are now in the phase of "ship it. if it breaks, let agents fix it, no manual debugging needed!" ?
- Salgat 6mo ago
  This is the biggest bottleneck for me. What's worse is that LLMs have a bad habit of being very verbose and rewriting things that don't need to be touched, so the surface area for change is much larger.
  - cyanydeez 6mo ago
    It's kind weird; I jumped on the vibe coding opencode bandwagon but using local 395+ w/128; qwen coder. Now, it takes a bit to get the first tokens flowing, and and the cache works well enough to get it going, but it's not fast enough to just set it and forget it and it's clear when it goes in an absurd direction and either deviates from my intention or simply loads some context whereitshould have followed a pattern, whatever. I'm sure these larger models are both faster and more cogent, but its also clear what matter is managing it's side tracks and cutting them short. Then I started seeing the deeper problematic pattern. Agents arn't there to increase the multifactor of production; their real purpose is to shorten context to manageable levels. In effect, they're basically try to reduce the odds of longer context poisoning. So, if we boil down the probabilty of any given token triggering the wrong subcontext, it's clear that the greater the context, the greater the odds of a poison substitution. Then that's really the problematic issue every model is going to contend with because there's zero reality in which a single model is good enough. So now you're onto agents, breaking a problem into more manageable subcontext and trying to put that back into the larger context gracefully, etc. Then that fails, because there's zero consistent determinism, so you end up at the harness, trying to herd the cats. This is all before you realize that these businesses can't just keep throwing GPUs at everything, because the problem isn't computing bound, it's contextual/DAG the same way a brain is limited. We all got intelligence and use several orders of magnitude less energy, doing mostly the same thing.
deleted 6mo ago
[deleted]
prmoustache 6mo ago
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?
deleted 6mo ago
[deleted]
jwpapi 6mo ago
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
- neilkakkar 6mo ago
  OP here, I disagree, it's great to have a skill for cases where you have extra steps and want the agent to run some verification steps before making a PR. It's called making a PR, but it's not _just_ running the gh cli to make a PR. It's checking if I'm in a worktree, renames branches accordingly, adds a linear ticket if provided, generates a proper PR summary. I'm not optimising for how fast the PR is created, I want it to do the menial steps I used to do .
  - jwpapi 6mo ago
    I have cli script for that as well. I have a cli script(wtq) that takes whatever is in my clipboard, creates a new worktree, cds into that worktree, installs dependencies, and then starts a claude session with the query in my clipboard. Once im done i can rune `wtf` and it it does the finish up work you described. It’s not about the workflow. A skill doesn’t make sense when you have a deterministic describable workflow, it’s just slower, because you have an interpretation and consuming step in there. You can just tell claude to turn the skill into a bash script and then alias it to whatever you like. A skill is useful if you have a variety of use cases that need to be interepretated and need a lot of the same utility.
    - neilkakkar 6mo ago
      I see what you mean - I have a setup-worktree script that does this, but I use the skill for knowing when to do bits and pieces. I would agree, if it were 100% deterministic script is much better.
imiric 6mo ago
> 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.
- neilkakkar 6mo ago
  I think you'd like this post I wrote: https://neilkakkar.com/agentic-debt.html 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.
SeriousM 6mo ago
> Fast rebuilds and automated previews made another friction visible: I could only comfortably work on one thing at a time. Oh really? I enjoy doing one thing at the time, with focus. AI, as you're using it OP, isn't make you faster, it is making you work more for the same amount of money. You burn yourself for no reason.
jee599 6mo ago
[dead]
m000 6mo ago
I'm very sceptical on how well AI can "read the full diff and summarise the changes properly". A colleague has been using Claude for this exact purpose for the past 2-3 months. Left alone, Claude just kept spewing spammy, formulaic, uninteresting summaries. E.g. phrases like "updated migrations" or "updated admin" were frequent occurrences for changes in our Django project. On the other hand, important implementation choices were left undocumented. Basically, my conclusion was that, for the time being, Claude's summaries aren't worthy for inclusion in our git log. They missed most things that would make the log message useful, and included mostly stuff that Claude could generate on demand at any time. I.e. spam.
- piva00 6mo ago
  Same experience here, I see many people in the company (5-10k employees) pushing commits with Claude-generated comments that are absolutely useless. I got praised for my commit messages by another team, they asked me how I was making Claude generate them, and I had to tell them I'm just not using Claude for that. I like writing my own commit messages because it helps me as well, I have to understand what was done and be able to summarise it, if I don't understand quickly enough to write a summary in the commit message it means something can be simplified or is complex enough to need comments in the code.
maxbeech 6mo ago
[dead]
skydhash 6mo ago
> /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.
chadcmulligan 6mo ago
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.
- AtlasBarfed 6mo ago
  Ive done a couple exploratory learning with AIs and wow could it help with learning. Imo we may be messing up the economy with AIs. They should be engineering better workers, not being employed to make one person do the work of three poorly. The power of AIs to smooth learning and raise expertise, rather than replace it, should be the adaptation goal. Obviously AIs as work assistants are powerful, but all the AI bullshitting CEOs overselling AIs is really damaging on the whole economic level Particularly because the current marketing leads to the next generation abandoning roles that AI bullshitters claim are perfectly replaced. It's like the urbanization demographic bomb on steroids.
  - chadcmulligan 6mo ago
    I find myself worrying the AI bubble will pop and we'll lose this aspect of AI's without it ever being properly explored. Instead of doomscrolling now I find myself firing up claude and saying 'explain ... to me' and it proceeds to tell me all about it. I can ask it questions and it seems fairly right - at least right enough for me to proceed, it's way better at this than building code, in my experience anyway.
    - 6mo ago
thegrim33 6mo ago
Ah, another pro-AI coding post written by someone whose livelihood depends on promoting/selling AI-assisted coding products. Color me shocked. And they used AI to write the post itself.
AuthAuth 6mo ago
Oh look someone over glazing AI and its usefulness. I hope this is a real person authentically sharing their opinion and not some AI startup guerrilla marketing.
whatthe12899 6mo ago
if you can't be bothered to write your own PR descriptions because it's drudgery, how can you expect others to read your (now-lengthier-because-AI) PR descriptions? This is an honest as someone who is also now doing this.
- Klaster_1 6mo ago
  I recently switched to agent writing my PR and commit messages with skills that mimic me doing the same. Most of the time, it writes exactly what I'd write and if something is off, editing takes less time than writing from scratch.
throw_m239339 6mo ago
I don't even need to read that article, I just can ask Claude how could I be more productive with Claude.
- breakingcups 6mo ago
  You'd be getting practically the same result. If someone is too lazy to write their own commit messages they're definitely too lazy to write this blog post manually.
overgard 6mo ago
Is Anthropic raising funds again? I'm so sick of these thinly veiled advertisements.
- Razengan 6mo ago
  This. I couldn't have been the only one noticing this uncanny frequency in fluff specifically praising Claude instead of AI coding in general. Now it's just becoming blatant
  - bdangubic 6mo ago
    There is a big difference between Claude and "AI coding in general"
BANRONFANTHE 6mo ago
[dead]
shevy-java 6mo ago
Guys - we lost another one to Skynet.
thunfischtoast 6mo ago
Call me incompetent, but I don't get it. > I switched the build to SWC, and server restarts dropped to under a second. What is SWC? The blog assumes I know it. Is it https://swc.rs/ https://swc.rs/ ? or this https://docs.nestjs.com/recipes/swc https://docs.nestjs.com/recipes/swc ?
- just-tom 6mo ago
  In the links you provided, swc is the same entity.
- TheRoque 6mo ago
  Both links are the same, SWC in this context is probably Speedy Web Compiler. It transpiles really fast but doesn't do any type checks.
  - maleldil 6mo ago
    > It transpiles really fast but doesn't do any type checks What's the point of using it during development, then?
    - OscarDC 6mo ago
      Transpilation is here a necessary step to test the application because e.g. his browser won't be able to parse raw TypeScript code. Typechecking is not: the browser doesn't care about it, it's mainly to help the developer verify its code. So to speed-up the build during development (to have faster iterations) the idea is often to make the building process only about the build by removing "unnecessary" steps like type-checking from it, while having a separate linting / typechecking etc. process, which could even run in parallel - but not be necessary to be able to test the application. This is often done by using tools like a bundler (e.g. esbuild) or a transpiler (babel, swc) to erase the types without checking them in your bundling process.
- michaelsalim 6mo ago
  Pretty sure they're the same thing. The second link is on how to use swc with nestjs.
Havoc 6mo ago
> And like any good manager, you get to claim credit for all the work your “team” does. Meanwhile in the real world the expectations shift to normalise the 10x and your boss wants to know why your output isn’t 12x like that of Max
yason 6mo ago
The other article references in the bottom was much more interesting: https://neilkakkar.com/agentic-debt.html https://neilkakkar.com/agentic-debt.html
winsonaibuilder 6mo ago
[dead]
vincentabolarin 6mo ago
I have been using Claude AI - not Claude Code - and it has greatly improved my productivity, too. However, I agree with you that commits are a terrible (or an unreliable) metric; more commits do not necessarily equal higher productivity.
ulrikrasmussen 6mo ago
I think more people should focus on using LLMs to relieve cognitive load rather than parallelize and overload their brains. We need to learn to live with the fact that humans are not good at multi-tasking, and LLMs are not going to make us better at it. I have started using Claude to develop an implementation plan, but instead of making Claude implement it and then have me spend time figuring out what it did, I simply tell it to walk me through implementing it by hand. This means that I actually understand every step of the development process and get to intervene and make different choices at the point of time where it matters. As opposed to the default mode which spits out hundreds of lines of code changes which overloads my brain, this mode of working actually feels like offloading the cognitive burden of keeping track of the implementation plan and letting me focus on both the details and the big picture without losing track of either one. For truly mechanical sub-tasks I can still save time by asking Claude to do them for me.
- wouldbecouldbe 6mo ago
  Some of us love it, bit intense sometimes, but fun. So I guess we get to decide it ourselves what we prefer. I know many will then say, BUT QUALITY, but if you learn to deal with your own and claude quirks, you also learn how to validate & verify more efficiently. And experience helps here.
- nzach 6mo ago
  I've been using a POC-driven workflow for my agentic coding. What I do is to use the LLM to ask a lot of questions to help me better understand to problem. After I have a good understanding I jump into the code and code by hand the core of the solution. With this core work finished(keep in mind that at this point the code doesn't even need to compile) I fire up my LLM and say something like "I need to do X, uncommited in this repo we have a POC for how we want to do it. Create and implement a plan on what we need to do to finish this feature." I think this is a good model because I'm using the LLM for the thing it is good at: "reading through code and explaining what it does" and "doing the grunt work". While I do the hard part of actually selecting the right way of solving a problem.
- kajkojednojajko 6mo ago
neilkakkar 6mo ago
Hello! OP here, a lot of comments have this common theme of wondering if this is overloading / context switching / the brain thrashing. Helped me surface an important distinction on why it doesn't really happen for me. I think there's three parts to it: 1. I work on only one thing at a time, and try to keep chunks meaty 2. I make sure my agents can run a lot longer so every meaty chunk gets the time it deserves, and I'm not babysitting every change in parallel, that would be horrible! (how I do this is what this post focuses on) 3. New small items that keep coming up / bug fixes get their own thread in the middle of the flow when they do come up, so I can fire and forget, come back to it when I have time. This works better for me because I'm not also thinking about these X other bugs that are pending, and I can focus on what I'm currently doing. What I had to figure out was how to adapt this workflow to my strengths (I love reviewing code and working on one thing at a time, but also get distracted easily). For my trade-offs, it was ideal to offload context to agents whenever a new thing pops up, so I continue focusing on my main task. The # of PRs might look huge (and they are to me), but I'm focusing on one big chonky thing a day, the others are smaller things, which together mean progress on my product is much faster than it otherwise would be.
pugchat 6mo ago
[dead]
peytongreen_dev 6mo ago
[flagged]
kevinbaiv 6mo ago
[flagged]
wenldev 6mo ago
[dead]
Nevermark 6mo ago
The amount of code changes I find acceptable, to simplify and shrink my code base, is now almost unbounded. Overstating things of course. But paying off technical debt never felt so good. And the expected decrease in forward friction has never been so achievable so quickly.
mulr00ney 6mo ago
>The time saved matters, but the real unlock was the mental overhead removed. Every PR used to be a small context switch: stop thinking about the code, start thinking about how to describe the code. Now I type /git-pr and move on to the next thing. This one's interesting to me. For a lot of my career, the act of writing the PR is the last sanity check that surfaces any weirdness or my own misgivings about my choices. Sometimes there would be code that felt natural when I was writing it and getting the feature working, and maybe that code survived my own personal round of code review... but having to write about it in plain english for the benefit of someone doing review with less context was a useful spot to do some self-reflection.
Yash16 6mo ago
[dead]
null_author 6mo ago
[dead]
theAurenVale 6mo ago
tbh the real productivity gain for me is iteration count. before id try maybe 2-3 approaches before shipping something. now i can test 10 diffrent implementations in the same window. code quality doesnt always go up but i understand the problem space alot better by the time im done
theAurenVale 6mo ago
the real bottleneck isnt writing code its knowing what to write. every productivity article about AI tools measures output volume but nobody seems to be asking whether the things being built faster are actualy the right things. ive been building a side project and honestly the hardest part is still deciding what matters, the AI just helps me iterate on that decision faster
wazionapps 6mo ago
[flagged]
marvec 6mo ago
How about "time to the first paying user" metric? Parallelism could slow that down. Or even "lines of code per paying user"? Or just a user... It is not an art to agent-code a ton of code. It is an art to land just the few ones that are a must for a good MVP.
tazsat0512 6mo ago
[dead]

281 points by neilkakkar 6mo ago

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 managing just two agents and keeping them isolated. But again, I'm the bottleneck. I think I could use 5 agents if my brain were smarter........or if the tools were better. I am also a PM by day and I'm in Claude Code for PM work almost 90% of my day.

orwin 6mo ago
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.
- jmathai 6mo ago
  Is it that the tickets are too verbose?
  - orwin 6mo ago
    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.
    - jmathai 6mo ago
      Yup. Makes a lot of sense.

CrzyLngPwd 6mo ago

`And like any good manager, you get to claim credit for all the work your “team” does.` Is that how it works? Do managers claim credit for the work of those below them, despite not doing the work? I hope they also get penalised when a lowly worker does a bad thing, even if the worker is an LLM silently misinterpreting a vague instruction.

idiotsecant 6mo ago
Yes. That is how management works. Although a good manager will focus some of that praise onto team members who deserve it.
jmathai 6mo ago
Yup, the manager gets implicit credit for the work their team does. In most cases, deservedly so. I don't see why it should be any different for engineers using LLMs as "direct reports". Not all engineers will be the same level of "good" with LLM tools so the better you are (as with any other skill as well) the more credit you would receive.
dakiol 6mo ago
Are you kidding? What else would managers get credit from? They don't produce anything the company is interested in. They steer, they manage, and so if the ones being managed produce the thing the company is interested in, then sure all the credit goes to the team (including the manager!). As it usually happens, getting credit means nothing if not accompanied by a salary bump or something like that. And as it usually happens, not the whole team can get a salary bump. So the ones who get the bump are usually one or two seniors on the team, plus the manager of course... because the manager is the gatekeeper between upper management (the ones who approve salary bumps) and the ICs... and no sane manager would sacrifice a salary bump for themselves just to give it away to an IC. And that's not being a bad manager, that's simply being human. Also if you think about it, if the team succeeded in delivering "the thing", then the manager would think it's partially because of their managing, and so he/she would believe a salary bump is deserved When things go south, no penalization is made. A simple "post-mortem" is written in confluence and people write "action items". So, yeah, no need for the manager to get the blame. It's all very shitty, but it's always been like that.

markbao 6mo ago

> What’s become more fun is building the infrastructure that makes the agents effective. Solving new problems is a thing engineers get to do constantly, whereas building an agent infrastructure is mostly a one-ish time thing. Yes, it evolves, but I worry that once the fun of building an agentic engineering system is done, we’re stuck doing arguably the most tedious job in the SDLC, reviewing code. It’s like if you were a principal researcher who stopped doing research and instead only peer reviewed other people’s papers. The silver lining is if the feeling of faster progress through these AI tools gives enough satisfaction to replace the missing satisfaction of problem-solving. Different people will derive different levels of contentment from this. For me, it has not been an obvious upgrade in satisfaction. I’m definitely spending less time in flow.

serf 6mo ago

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.

matheusmoreira 6mo ago
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.
- munk-a 6mo ago
  This right here is the big value I see in LLMs as well. I specifically suffer from analysis paralysis when starting something big and just getting skeletonized cheap code out quick as a template then refining it is much more to my strengths. I am ADHD and task breakdown is a known difficulty for that disorder so it has been hugely helpful. That said, by the time I'm happy with it all the AI stuff outside very boilerplate ops/config stuff has been rewritten and refined. I just find it quite helpful to get over that initial hump of "I have nothing but a dream" to the stage of "I have a thing that compiles but is terrible". Once I can compile it then I can refine which where my strengths lie.
- vova_hn2 6mo ago
  > 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...
  - 6mo ago

MeetingsBrowser 6mo ago

> I’m not “using a tool that writes code.” I’m in a tight loop: kick off a task, the agent writes code, I check the preview, read the diff, give feedback or merge, kick off the next task the assumption to this workflow is that claude code can complete tasks with little or no oversight. If the flow looks like review->accept, review->accept, it is manageable. In my personal experience, claude needs heavy guidance and multiple rounds of feedback before arriving at a mergeable solution (if it does at all). Interleaving many long running tasks with multiple rounds of feedback does not scale well unfortunately. I can only remember so much, and at some point I spend more time trying to understand what has been done so far to give accurate feedback than actually giving feedback for the next iteration.

felipevb 6mo ago

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

dgunay 6mo ago
I do parallel agents in worktrees and I don't always constantly keep an eye on them like a fry cook flipping 20 burgers at once. Sometimes it's just nice to know that I can spin one up, come back tomorrow, and some progress has been made without breaking my current flow.
saadn92 6mo ago
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.
torben-friis 6mo ago
I would like some research regarding multi agent flows and impact on speed and correctness, because I have a feeling that it's like a texting and driving situation, where self perception of skill loss and measured skill loss diverge. I have nothing to back up the idea though.
- saadn92 6mo ago
  you do lose context, but if you generate a plan beforehand and save it, then it makes it easier to gain that context when you come back. I've been able to get out things a lot more quickly this way, because instead of "working" that day, I'll just review the work that's been queued up and focus on it one at a time, so I'm still the bottle neck but it has allowed me to move more quickly at times
- jannyfer 6mo ago
  Ooooh very interesting idea. I also have nothing to back it up, but it fits my mental models. When juggling multiple things as humans, it eats up your context window (working memory). After a long day, your coherence degrades and your context window needs flushing (sleeping) and you need to start a new session (new day, or post-nap afternoon).

aguimaraes1986 6mo ago

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.

zahlman 6mo ago
> 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.
- sodapopcan 6mo ago
  The only time metrics have been useful to me in the past is when they are kept private to each team, which is to say that I do think they are useful for measuring yourself, but not for others to measure you. Taken over time, they can eventual give you a really good idea of what you can deliver. Sandbag a bit (ie, undershoot that number), communicate that to ye olde stakeholders, and everybody's happy that you can actually do what you say you'll do without being stressed out (obviously this doesn't work in startups).
browningstreet 6mo ago
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.”

deleted 6mo ago

[deleted]

tomasz-tomczyk 6mo ago

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.

mpalmer 6mo ago

[dead]

deleted 6mo ago

[deleted]

paganel 6mo ago

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

paulhebert 6mo ago
Yeah I agree. We have “Cursor Bot” enabled at work. It reviews our PRs (in addition to a human review) One thing it does is add a PR summary to the PR description. It’s kind of helpful since it outlines a clear list of what changed in code. But it would be very lacking if it was the full PR description. It doesn’t include anything about _why_ the changes were made, what else was tried, what is coming next, etc.
ytoawwhra92 6mo ago
Same reason they outsource writing their blog posts. This weird notion that the purpose of the thing is the thing itself, not what people get out of the thing. Tracks completely that a person who thinks their number of commits and think that shows how productive they are (while acknowledging that it's a poor metric and just shrugging).
godd2 6mo ago
> Why do they outsource something that is meant to have been written by a human Says who? The point of the summary is so that I don't have to go look at the diff and figure out what happened.
- piva00 6mo ago
  The point of the summary is also to explain "why" something was done, most Claude-generated PR descriptions I've been seeing go through the "what" and "how" but if the human-in-the-loop didn't care to precisely describe the "why" it is just an English version of the changes made in the code... I can just read the code for that, give me the reasons behind the diff and I'm a happy camper.

dakiol 6mo ago

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 modern compiler instead of writing assembly. Yeah it's faster, but so is everyone else code... Besides, I wouldn't brag about being more productive with LLMS because it's a double edge sword: it's very easy to use them, and nobody is reviewing all the lines of code you are pushing to prod (really, when was the last time you reviewed a PR generated by AI that changed 20+ files and added/removed thousands of lines of code?), so you don't know what's the long game of your changes; they seem to work now but who knows how it will turn out later?

bluelightning2k 6mo ago
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.
- dakiol 6mo ago
  Fair enough. I've been in software more than I would like to admit. And the more I'm in, the less I care about achievements in a work environment. All I care about is that the company pays me every month, because companies don't care about me (they care about my outome per hour/week/month). So it's essential to rank yourself high against your peers (being ethically and the like, ofc), otherwise you are out in the next layoff. I know not every company is like this, but the vast majority of tech companies are. Outside of work, yeah, everything is fine and there's nothing but the pure pursue of knowledge and joy.
  - exogenousdata 6mo ago
    All companies are like this. Some just have better HR/PR.

ayhanfuat 6mo ago

I don't know if I am just in an unlucky A/B assignment or anything but I really don't understand people juggling multiple agent sessions. For me Opus 4.6 High performance went from unbelievable to mediocre. And this keeps happening making the whole agentic coding very unreliable and frustrating. I do use it but I have to babysit and I get overwhelmed even with a single session.

keybored 6mo ago

As an outsider it seems like agentic coders get buried in the weeds of running agents in parallel and churning out commits. (Even after a sheepish “commits are a bad metric but”) And every week there is a new orchestration, something, who even cares. Is that the end game? Well why can’t the agents orchestrate the agents? Agents all the way down? The whole agent coding scene seems like people selling their soul for very shiny inflatable balloons. Now you have twelve bespoke apps tailored for you that you don’t even care about.

jikojkb 6mo ago

[dead]

deleted 6mo ago

[deleted]

leontloveless 6mo ago

[dead]

aplomb1026 6mo ago

[dead]

dakiol 6mo ago

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, take an enormous amount of time compare to the time it took the agents to produce it? (you know, it's more difficult to read other people's/machine code than to write it yourself)... meaning all the productivity gained is thrown out the door. Unless you don't review every generated line manually, and instead rely on, let's say, UI e2e testing, or perhaps unit testing (that the agents also wrote). I don't know, perhaps we are past the phase of "double check what agents write" and are now in the phase of "ship it. if it breaks, let agents fix it, no manual debugging needed!" ?

Salgat 6mo ago
This is the biggest bottleneck for me. What's worse is that LLMs have a bad habit of being very verbose and rewriting things that don't need to be touched, so the surface area for change is much larger.
- cyanydeez 6mo ago
  It's kind weird; I jumped on the vibe coding opencode bandwagon but using local 395+ w/128; qwen coder. Now, it takes a bit to get the first tokens flowing, and and the cache works well enough to get it going, but it's not fast enough to just set it and forget it and it's clear when it goes in an absurd direction and either deviates from my intention or simply loads some context whereitshould have followed a pattern, whatever. I'm sure these larger models are both faster and more cogent, but its also clear what matter is managing it's side tracks and cutting them short. Then I started seeing the deeper problematic pattern. Agents arn't there to increase the multifactor of production; their real purpose is to shorten context to manageable levels. In effect, they're basically try to reduce the odds of longer context poisoning. So, if we boil down the probabilty of any given token triggering the wrong subcontext, it's clear that the greater the context, the greater the odds of a poison substitution. Then that's really the problematic issue every model is going to contend with because there's zero reality in which a single model is good enough. So now you're onto agents, breaking a problem into more manageable subcontext and trying to put that back into the larger context gracefully, etc. Then that fails, because there's zero consistent determinism, so you end up at the harness, trying to herd the cats. This is all before you realize that these businesses can't just keep throwing GPUs at everything, because the problem isn't computing bound, it's contextual/DAG the same way a brain is limited. We all got intelligence and use several orders of magnitude less energy, doing mostly the same thing.

deleted 6mo ago

[deleted]

prmoustache 6mo ago

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?

deleted 6mo ago

[deleted]

jwpapi 6mo ago

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

neilkakkar 6mo ago
OP here, I disagree, it's great to have a skill for cases where you have extra steps and want the agent to run some verification steps before making a PR. It's called making a PR, but it's not _just_ running the gh cli to make a PR. It's checking if I'm in a worktree, renames branches accordingly, adds a linear ticket if provided, generates a proper PR summary. I'm not optimising for how fast the PR is created, I want it to do the menial steps I used to do .
- jwpapi 6mo ago
  I have cli script for that as well. I have a cli script(wtq) that takes whatever is in my clipboard, creates a new worktree, cds into that worktree, installs dependencies, and then starts a claude session with the query in my clipboard. Once im done i can rune `wtf` and it it does the finish up work you described. It’s not about the workflow. A skill doesn’t make sense when you have a deterministic describable workflow, it’s just slower, because you have an interpretation and consuming step in there. You can just tell claude to turn the skill into a bash script and then alias it to whatever you like. A skill is useful if you have a variety of use cases that need to be interepretated and need a lot of the same utility.
  - neilkakkar 6mo ago
    I see what you mean - I have a setup-worktree script that does this, but I use the skill for knowing when to do bits and pieces. I would agree, if it were 100% deterministic script is much better.

imiric 6mo ago

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

neilkakkar 6mo ago
I think you'd like this post I wrote: https://neilkakkar.com/agentic-debt.html 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.

SeriousM 6mo ago

> Fast rebuilds and automated previews made another friction visible: I could only comfortably work on one thing at a time. Oh really? I enjoy doing one thing at the time, with focus. AI, as you're using it OP, isn't make you faster, it is making you work more for the same amount of money. You burn yourself for no reason.

jee599 6mo ago

[dead]

m000 6mo ago

I'm very sceptical on how well AI can "read the full diff and summarise the changes properly". A colleague has been using Claude for this exact purpose for the past 2-3 months. Left alone, Claude just kept spewing spammy, formulaic, uninteresting summaries. E.g. phrases like "updated migrations" or "updated admin" were frequent occurrences for changes in our Django project. On the other hand, important implementation choices were left undocumented. Basically, my conclusion was that, for the time being, Claude's summaries aren't worthy for inclusion in our git log. They missed most things that would make the log message useful, and included mostly stuff that Claude could generate on demand at any time. I.e. spam.

piva00 6mo ago
Same experience here, I see many people in the company (5-10k employees) pushing commits with Claude-generated comments that are absolutely useless. I got praised for my commit messages by another team, they asked me how I was making Claude generate them, and I had to tell them I'm just not using Claude for that. I like writing my own commit messages because it helps me as well, I have to understand what was done and be able to summarise it, if I don't understand quickly enough to write a summary in the commit message it means something can be simplified or is complex enough to need comments in the code.

maxbeech 6mo ago

[dead]

skydhash 6mo ago

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

chadcmulligan 6mo ago

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.

AtlasBarfed 6mo ago
Ive done a couple exploratory learning with AIs and wow could it help with learning. Imo we may be messing up the economy with AIs. They should be engineering better workers, not being employed to make one person do the work of three poorly. The power of AIs to smooth learning and raise expertise, rather than replace it, should be the adaptation goal. Obviously AIs as work assistants are powerful, but all the AI bullshitting CEOs overselling AIs is really damaging on the whole economic level Particularly because the current marketing leads to the next generation abandoning roles that AI bullshitters claim are perfectly replaced. It's like the urbanization demographic bomb on steroids.
- chadcmulligan 6mo ago
  I find myself worrying the AI bubble will pop and we'll lose this aspect of AI's without it ever being properly explored. Instead of doomscrolling now I find myself firing up claude and saying 'explain ... to me' and it proceeds to tell me all about it. I can ask it questions and it seems fairly right - at least right enough for me to proceed, it's way better at this than building code, in my experience anyway.
  - 6mo ago

thegrim33 6mo ago

Ah, another pro-AI coding post written by someone whose livelihood depends on promoting/selling AI-assisted coding products. Color me shocked. And they used AI to write the post itself.

AuthAuth 6mo ago

Oh look someone over glazing AI and its usefulness. I hope this is a real person authentically sharing their opinion and not some AI startup guerrilla marketing.

whatthe12899 6mo ago

if you can't be bothered to write your own PR descriptions because it's drudgery, how can you expect others to read your (now-lengthier-because-AI) PR descriptions? This is an honest as someone who is also now doing this.

Klaster_1 6mo ago
I recently switched to agent writing my PR and commit messages with skills that mimic me doing the same. Most of the time, it writes exactly what I'd write and if something is off, editing takes less time than writing from scratch.

throw_m239339 6mo ago

I don't even need to read that article, I just can ask Claude how could I be more productive with Claude.

breakingcups 6mo ago
You'd be getting practically the same result. If someone is too lazy to write their own commit messages they're definitely too lazy to write this blog post manually.

overgard 6mo ago

Is Anthropic raising funds again? I'm so sick of these thinly veiled advertisements.

Razengan 6mo ago
This. I couldn't have been the only one noticing this uncanny frequency in fluff specifically praising Claude instead of AI coding in general. Now it's just becoming blatant
- bdangubic 6mo ago
  There is a big difference between Claude and "AI coding in general"

BANRONFANTHE 6mo ago

[dead]

shevy-java 6mo ago

Guys - we lost another one to Skynet.

thunfischtoast 6mo ago

Call me incompetent, but I don't get it. > I switched the build to SWC, and server restarts dropped to under a second. What is SWC? The blog assumes I know it. Is it https://swc.rs/ https://swc.rs/ ? or this https://docs.nestjs.com/recipes/swc https://docs.nestjs.com/recipes/swc ?

just-tom 6mo ago
In the links you provided, swc is the same entity.
TheRoque 6mo ago
Both links are the same, SWC in this context is probably Speedy Web Compiler. It transpiles really fast but doesn't do any type checks.
- maleldil 6mo ago
  > It transpiles really fast but doesn't do any type checks What's the point of using it during development, then?
  - OscarDC 6mo ago
    Transpilation is here a necessary step to test the application because e.g. his browser won't be able to parse raw TypeScript code. Typechecking is not: the browser doesn't care about it, it's mainly to help the developer verify its code. So to speed-up the build during development (to have faster iterations) the idea is often to make the building process only about the build by removing "unnecessary" steps like type-checking from it, while having a separate linting / typechecking etc. process, which could even run in parallel - but not be necessary to be able to test the application. This is often done by using tools like a bundler (e.g. esbuild) or a transpiler (babel, swc) to erase the types without checking them in your bundling process.
michaelsalim 6mo ago
Pretty sure they're the same thing. The second link is on how to use swc with nestjs.

Havoc 6mo ago

> And like any good manager, you get to claim credit for all the work your “team” does. Meanwhile in the real world the expectations shift to normalise the 10x and your boss wants to know why your output isn’t 12x like that of Max

yason 6mo ago

The other article references in the bottom was much more interesting: https://neilkakkar.com/agentic-debt.html https://neilkakkar.com/agentic-debt.html

winsonaibuilder 6mo ago

[dead]

vincentabolarin 6mo ago

I have been using Claude AI - not Claude Code - and it has greatly improved my productivity, too. However, I agree with you that commits are a terrible (or an unreliable) metric; more commits do not necessarily equal higher productivity.

ulrikrasmussen 6mo ago

I think more people should focus on using LLMs to relieve cognitive load rather than parallelize and overload their brains. We need to learn to live with the fact that humans are not good at multi-tasking, and LLMs are not going to make us better at it. I have started using Claude to develop an implementation plan, but instead of making Claude implement it and then have me spend time figuring out what it did, I simply tell it to walk me through implementing it by hand. This means that I actually understand every step of the development process and get to intervene and make different choices at the point of time where it matters. As opposed to the default mode which spits out hundreds of lines of code changes which overloads my brain, this mode of working actually feels like offloading the cognitive burden of keeping track of the implementation plan and letting me focus on both the details and the big picture without losing track of either one. For truly mechanical sub-tasks I can still save time by asking Claude to do them for me.

wouldbecouldbe 6mo ago
Some of us love it, bit intense sometimes, but fun. So I guess we get to decide it ourselves what we prefer. I know many will then say, BUT QUALITY, but if you learn to deal with your own and claude quirks, you also learn how to validate & verify more efficiently. And experience helps here.
nzach 6mo ago
I've been using a POC-driven workflow for my agentic coding. What I do is to use the LLM to ask a lot of questions to help me better understand to problem. After I have a good understanding I jump into the code and code by hand the core of the solution. With this core work finished(keep in mind that at this point the code doesn't even need to compile) I fire up my LLM and say something like "I need to do X, uncommited in this repo we have a POC for how we want to do it. Create and implement a plan on what we need to do to finish this feature." I think this is a good model because I'm using the LLM for the thing it is good at: "reading through code and explaining what it does" and "doing the grunt work". While I do the hard part of actually selecting the right way of solving a problem.
kajkojednojajko 6mo ago

neilkakkar 6mo ago

Hello! OP here, a lot of comments have this common theme of wondering if this is overloading / context switching / the brain thrashing. Helped me surface an important distinction on why it doesn't really happen for me. I think there's three parts to it: 1. I work on only one thing at a time, and try to keep chunks meaty 2. I make sure my agents can run a lot longer so every meaty chunk gets the time it deserves, and I'm not babysitting every change in parallel, that would be horrible! (how I do this is what this post focuses on) 3. New small items that keep coming up / bug fixes get their own thread in the middle of the flow when they do come up, so I can fire and forget, come back to it when I have time. This works better for me because I'm not also thinking about these X other bugs that are pending, and I can focus on what I'm currently doing. What I had to figure out was how to adapt this workflow to my strengths (I love reviewing code and working on one thing at a time, but also get distracted easily). For my trade-offs, it was ideal to offload context to agents whenever a new thing pops up, so I continue focusing on my main task. The # of PRs might look huge (and they are to me), but I'm focusing on one big chonky thing a day, the others are smaller things, which together mean progress on my product is much faster than it otherwise would be.

pugchat 6mo ago

[dead]

peytongreen_dev 6mo ago

[flagged]

kevinbaiv 6mo ago

[flagged]

wenldev 6mo ago

[dead]

Nevermark 6mo ago

The amount of code changes I find acceptable, to simplify and shrink my code base, is now almost unbounded. Overstating things of course. But paying off technical debt never felt so good. And the expected decrease in forward friction has never been so achievable so quickly.

mulr00ney 6mo ago

>The time saved matters, but the real unlock was the mental overhead removed. Every PR used to be a small context switch: stop thinking about the code, start thinking about how to describe the code. Now I type /git-pr and move on to the next thing. This one's interesting to me. For a lot of my career, the act of writing the PR is the last sanity check that surfaces any weirdness or my own misgivings about my choices. Sometimes there would be code that felt natural when I was writing it and getting the feature working, and maybe that code survived my own personal round of code review... but having to write about it in plain english for the benefit of someone doing review with less context was a useful spot to do some self-reflection.

Yash16 6mo ago

[dead]

null_author 6mo ago

[dead]

theAurenVale 6mo ago

tbh the real productivity gain for me is iteration count. before id try maybe 2-3 approaches before shipping something. now i can test 10 diffrent implementations in the same window. code quality doesnt always go up but i understand the problem space alot better by the time im done

theAurenVale 6mo ago

the real bottleneck isnt writing code its knowing what to write. every productivity article about AI tools measures output volume but nobody seems to be asking whether the things being built faster are actualy the right things. ive been building a side project and honestly the hardest part is still deciding what matters, the AI just helps me iterate on that decision faster

wazionapps 6mo ago

[flagged]

marvec 6mo ago

How about "time to the first paying user" metric? Parallelism could slow that down. Or even "lines of code per paying user"? Or just a user... It is not an art to agent-code a ton of code. It is an art to land just the few ones that are a must for a good MVP.

tazsat0512 6mo ago

[dead]