301–310 of 325 posts
That sounds like a good idea, but shipping 10x as many features and bugfixes sounds better. I started using AI with the best intentions. Checking everything before committing. Improving output by hand if it didn't quite follow the existing code style guidelines or variables were not named as well as they should be. Or if it did something sloppy or hacky. Now, AI GOES BURRRRRRRRRRRR! If the tests pass it's good to shi…
Write yourself a /review command. That is an empty markdown file at `.claude/commands/review.md`. In it, put a checklist of things the agent should look for. When you’re ready to have your agent review the code, type `/review`. The checklist will be examined and it’ll plan out some findings to ask you if you want them fixed. Mine starts with “Enter plan mode. Examine the differences on this branch vs. main. Consider:…
- You should use skills instead of commands (commands still work, but they've been rolled into skills) https://code.claude.com/docs/en/skills
- Hardcoding git diff against main isn't always ideal (depending on your git workflow). If you branch off of branches, the agent will figure it out, but it often has to go through a few hops to determine what to actually diff. You're better to ask it to diff 'the commits on this branch' or similar.
- You might not necessarily want to enter plan mode for a review. I don't personally as I don't see any benefit to it writing a markdown plan file for a review.
Write yourself a /review command. That is an empty markdown file at `.claude/commands/review.md`. In it, put a checklist of things the agent should look for. When you’re ready to have your agent review the code, type `/review`. The checklist will be examined and it’ll plan out some findings to ask you if you want them fixed. Mine starts with “Enter plan mode. Examine the differences on this branch vs. main. Consider:…
My experience is the more things you add to the list, the worse agents perform (I'm not exactly the first person to notice this) I actually have a pretty simple set of instructions right now and Claude still regularly messes them up. Like, my first instructions are: - Never commit to git without permission. - Never sign commit messages You know what it constantly does? Commits without permissions and signs commit mes…
As some other comments have said, there are various other options like hooks which are run by the harness and can be used to always enforce certain things (running a formatter for example).
But for your examples, settings are the correct solution. Set an ask permission on git commit and it will always prompt you before committing. For commit messages, just set attribution commit to an empty string and it will stop adding its own attribution. https://code.claude.com/docs/en/settings#attribution-setting...
Two tiny changes; problem solved permanently.
Write yourself a /review command. That is an empty markdown file at `.claude/commands/review.md`. In it, put a checklist of things the agent should look for. When you’re ready to have your agent review the code, type `/review`. The checklist will be examined and it’ll plan out some findings to ask you if you want them fixed. Mine starts with “Enter plan mode. Examine the differences on this branch vs. main. Consider:…
A couple of notes for anyone reading this comment and thinking of implementing something similar: - You should use skills instead of commands (commands still work, but they've been rolled into skills) https://code.claude.com/docs/en/skills - Hardcoding git diff against main isn't always ideal (depending on your git workflow). If you branch off of branches, the agent will figure it out, but it often has to go through…
- Skills over commands: agreed - but they are more complex than a single file. I’m suggesting a command because it’s a great way to start and build up that checklist. Over time, migrate it to a skill. But one thing I’d say is keep it in your repo. That way, PRs can include new bullet points with the code that gave rise to them. Opinions will differ on this: it muddies the PR a little in the present. But OTOH future folks can git blame to see where that bullet came from.
- Hardcoding against main: yes, this is a very good catch - a better prompt is to tell the agent to compare to the branch’s merge base. Again a detail left off for simplicity to encourage folks to start somewhere. Your suggestion is a quick win fast follow for correctness.
(side note - 90% of the time Opus 4.8 guesses the intent and decides to use the merge base on its own! Opus 4.6 didn’t do that. These things are smart if you set them up for success!)
- Plan mode for review I would say personal choice. It is crucial in my experience because some of my list makes it overzealous in planning cleanups and the like. YMMV. Yes plan mode is optional and I sometimes have to reread and discuss a review plan after a context switch in my day - but at least it didn’t spray bad cleanups all over a decent PR.
Earlier quoted context omitted.
A couple of notes for anyone reading this comment and thinking of implementing something similar: - You should use skills instead of commands (commands still work, but they've been rolled into skills) https://code.claude.com/docs/en/skills - Hardcoding git diff against main isn't always ideal (depending on your git workflow). If you branch off of branches, the agent will figure it out, but it often has to go through…
Thanks for this, I’d agree and elaborate a little - Skills over commands: agreed - but they are more complex than a single file. I’m suggesting a command because it’s a great way to start and build up that checklist. Over time, migrate it to a skill. But one thing I’d say is keep it in your repo. That way, PRs can include new bullet points with the code that gave rise to them. Opinions will differ on this: it muddies…
Agreed on the plan mode. I think it's personal choice and also situation-dependent. When I've already reviewed everything the agent has written and made changes along the way, I'm pretty confident a review is only going to throw up minor tweaks. When reviewing someone else's code or if you've got a load of changes you haven't reviewed yourself yet, plan mode is probably useful. I always think it's worth highlighting that plan mode isn't just 'don't make changes', it's a fundamentally different mode with a different prompt and objectives.
Write yourself a /review command. That is an empty markdown file at `.claude/commands/review.md`. In it, put a checklist of things the agent should look for. When you’re ready to have your agent review the code, type `/review`. The checklist will be examined and it’ll plan out some findings to ask you if you want them fixed. Mine starts with “Enter plan mode. Examine the differences on this branch vs. main. Consider:…
My experience is the more things you add to the list, the worse agents perform (I'm not exactly the first person to notice this) I actually have a pretty simple set of instructions right now and Claude still regularly messes them up. Like, my first instructions are: - Never commit to git without permission. - Never sign commit messages You know what it constantly does? Commits without permissions and signs commit mes…
Non-deterministic behavior via code.
Earlier quoted context omitted.
Thanks for this, I’d agree and elaborate a little - Skills over commands: agreed - but they are more complex than a single file. I’m suggesting a command because it’s a great way to start and build up that checklist. Over time, migrate it to a skill. But one thing I’d say is keep it in your repo. That way, PRs can include new bullet points with the code that gave rise to them. Opinions will differ on this: it muddies…
A skill is a single file too thought right? Just `.claude/skills/review/SKILL.md` instead of `.claude/commands/review.md`. I think the format is more or less identical as well? I may be missing some subtle difference though. As you say, either will work fine for this, but in general Anthropic's advice is to just use skills now. Agreed on the plan mode. I think it's personal choice and also situation-dependent. When I…
Earlier quoted context omitted.
My experience is the more things you add to the list, the worse agents perform (I'm not exactly the first person to notice this) I actually have a pretty simple set of instructions right now and Claude still regularly messes them up. Like, my first instructions are: - Never commit to git without permission. - Never sign commit messages You know what it constantly does? Commits without permissions and signs commit mes…
You should set things like this in Claude's settings.json rather than just asking the model and hoping it will obey. That way it will be enforced by the harness. As some other comments have said, there are various other options like hooks which are run by the harness and can be used to always enforce certain things (running a formatter for example). But for your examples, settings are the correct solution. Set an ask…
Earlier quoted context omitted.
You should set things like this in Claude's settings.json rather than just asking the model and hoping it will obey. That way it will be enforced by the harness. As some other comments have said, there are various other options like hooks which are run by the harness and can be used to always enforce certain things (running a formatter for example). But for your examples, settings are the correct solution. Set an ask…
Thanks, that's helpful, although I can't help but appreciate I had to get this suggestion from a person rather than the AI..
Crazy how many engineers in here just say they are using another prompt on top. From my experience that makes things worse. It does abstractions, but the wrong ones. It overcomments, confusing future calls of the LLM. To me building on multiple scalable systems this has been the most dangerous part of LLMs. On a good codebase it will work good, but it will maek it worse, so you keep using it, till it doesnt work and…
> To solve this you can regular refactor, but it’s not a nice experienc. Really? I always thought that was the best part of programming. And now that I can direct an LLM to identify a specific pattern and rework it in a certain way, or to extract a function for a specific purpose and then use it where possible (with my review, of course), so much the better. I agree with you about the joy of writing things directly,…
I’ve recently been given the task to work on a fully vibe-coded app. I reduced the code from 140k to 28k lines. This was luckily pre-mvp stage so no users. But if people get stuck at this stage, imagine what’s happening with real workload.
I’ve always been a solo dev, but I’m wondering how in big companies there is even so much to you can actually touch that you need an LLM to do that. Like I can’t delete refactor 120k lines in an established codebase. And one task to fix, takes review time and product time. Like are there now engineers that commit 1k+ lines a day of LLM produced output ?
Bugfixing often is just a bunch of lines, or a replacement of a service often isolated maye 150-200 lines, but I just might be just not experienced enough on these kind of codebases. I can’t grasp the notion of the LLM-multiplex and I don’t know where it’s going.
I have to say I have seen some good solo-dev projects popping up recently (games) that actually got profitable, but usually they were experienced in their discipline before.