zlacker

I feel like I must be missing something, but I just cannot understand the hype around Claude Code. Don't get me wrong, I'm fully bought in on using AI for development and am super happy to use Copilot or Cursor, but as an experienced developer just chatting with the terminal feels so wrong. I've tried it so many times to switch and I can't get into it.

Can anyone else share what their workflow with CC looks like? Even if I never end up switching I'd like to at least feel like I gave it a good shot and made a choice based on that, but right now I just feel like I'm doing something wrong.

>>superf+(OP)
I'll take a crack at it. I liked using Cursor and it was my first introduction but my main editor is Emacs and I like Emacs, it has a bunch of configuration that has built up like barnacles on the bottom of a ship so it was kind of hard using VS Code. I use a project package (projectile) that allows me to quickly move between different projects (git repos, TRAMP sessions, anything really) and I can open a CC terminal there that I can have pop in and out as I need it. Really it's pretty similar to how I used Cursor.

>>superf+(OP)
Workflow is this: - I have emacs open for code editing/reviews/git. - Separate terminal emulator with 1-3 claudes - I work on a story by splitting it into small steps ("Let's move this email logic to the email.service.ts", "here's the fields I'd need to add to the request, create a schema validation in a separate file, and update the router and controller") - I mostly watch claude, and occasionally walk through the code in emacs whenever I feel like I want to review code. - I handle external tools like git or db migrations myself not letting LLMs near them.

In essence, this is pretty much how you'd run a group of juniors - you'd sit on slack and jira diving up work and doing code reviews.

>>superf+(OP)
I use it like having a bunch of L3/L4 engineers. I give them a description of the changes I want to be made, sometimes chat a bit with it to help them design the features and then tell them to have a go at it. Then I create PRs and review them and have them clean up/improve the code and merge it. I try to balance giving it enough stuff to build so I can switch to another agent, and not giving them too much so that they make a weird assumption and run really far with it.

I got really good at reviewing code efficiently from my time at Google and others, which helps a lot. I'm sure my personal career experience influences a lot how I'm using it.

FWIW, I use Codex CLI, but I assume my flow would be the same with Claude Code.

>>thefly+42
> I work on a story by splitting it into small steps

It's funny because that's basically the approach I take in GH Copilot. I first work with it to create a plan broken up into small steps and save that to an md file and then I have it go one step at a time reviewing the changes as it goes or just when it's done.

I understand that you're using emacs to keep an eye on the code as it goes, so maybe what I wasn't groking was that people were using terminal based code editors to see the changes it was making. I assumed most people were just letting it do it s thing and then trying to review everything at the end, but felt like an anti-pattern given how much we (dev community) push for small PRs over gigantic 5k line PRs.

>>thefly+42
have you tried the emacs package agent-shell?

>>superf+(OP)
One thing I really like it for is if you have a lot of something similar - let's say plugins. I can then just go to the plugins directory, and tell claude something as simple as "this is the plugins directory where plugins live. I want to add one called 'sample' that samples records". Note that I don't even have to tell it what that means usually.

It will read the existing plugins, understand the code style/structure/how they integrate, then create a plugin called "sample" AND code that is usually what you wanted without telling it specifically, and write 10 tests for it.

In those cases it's magic. In large codebases, asking it to add something into existing code or modify a behavior I've found it to be...less useful at.

>>thefly+42
yes, similar.

>>thefly+42
As an aside: have you thought about using agent-shell?

https://github.com/xenodium/agent-shell

>>superf+(OP)
iterm and talk to Claude, command+tab to vscode fix/adjust things, command+tab back to iterm and talk more to Claude. Not the most technically advanced setup but it works pretty well for me. I don't like the turbo auto-complete in vscode, it's very distracting. If i want an agent's help I tab over and ask claude.

Also, use the Superpowers plugin for Claude. That really helps for larger tasks but it can over do it hah. It's amusing to watch the code reviewer, implementor, and tester fight and go back and forth over something that doesn't even really matter.

>>thefly+42
At that point though isn't it just as fast/easy to cut/paste the code yourself? That was my conclusion after spending a week breaking things down - I was able to get good code out of the AI, but only after spending as much time writing the prompt as if I just did it myself. (note that this was my first attempt at using an agent, maybe I'll learn to do it better)

>>bluGil+XM
With some experience you start getting the hand of how big a task you can hand off, and then you give the agent a way to test the changes, like using a browser and checking for a component, or adding unit tests for the backend.

Having a tight feedback loop for agents is critical for getting good output.