211–220 of 297 posts
Also, this stuff feels like alchemy to me . I bet some of you have the same feeling.
Earlier quoted context omitted.
I assume it will be similar to when a person is out sick or on vacation. Another person on the team likely could take over the work for a day, but realistically it just sits until they're is back.
Not really, realistically speaking it's now possible to use an agent to read code and make sensible summaries of a codebase faster than ever before, and it's exactly the thing you'd use to onboard yourself or someone else on the team.
More importantly I think, if devs become dependent enough on LLMs that they just put it aside when the model isn't available, they wouldn't be able to onboard quickly or at all.
It takes experience and a pretty deep understanding of programming in your language of choice to pick up a new code base and quickly understand how it works, the architecture(s) and pattern(s) being used, etc. Those skills would likely have been lost long before a dev simply can't work without the LLM.
How many times can I read the same shallow guidance written by AI on using a coding agent? Good god when will it stop
Can't wait to learn more about how to vendor-lock-in myself really hard into not being able to code without the help of a specific corporation!
At this point, I'm seriously considering what it would take to build a reasonable budget-AI box that's self-hosted. It wouldn't need to blow the doors off of Claude, just get me most of the way there. Maybe even build it out of used and/or last-gen GPUs and a beefy motherboard.
Earlier quoted context omitted.
Hi Boris, what is the advantage of using /code-review vs just asking Opus to “code review”? As a casual user working on hobby projects, I struggle to keep up with the pace of changes and knowing what to use when. My default now is to use Opus for all coding (sonnet is fine but seems dumber) and to prompt it for everything I need. I’ve had great success with this but clearly I’m missing power user functions with the s…
The advantage is that /code-review supplies a structured idea of how to review and what that process should look like and then launches independent subagents to approach the issue from multiple angles. It's analogous to how in the early days you could see benefits by telling the models to "think step by step". /code-review is something like "review angle by angle". "Consider removed behavior" and also "Look at langua…
Outsourcing comprehension to a machine is probably gonna cost you more time in the long run.
We really need some consolidation around commands, skills, subagents, and plugins. For example, if you want to, say, review code, you have five options now: - Write a .claude/commands/review.md. Simple but deprecated. - Use a /code-review skill, either one you install or one you just write yourself (it's just Markdown, after all). - Use the /pr-review subagent. Also just Markdown, but it runs "in the background" and…
Hey, Boris from the CC team here. I agree, we're working on consolidating these. Going forward it will just be the built-in /code-review skill. Here's how to use the skill on the latest version: /code-review # do a balanced code review. checks for bugs and inconsistencies, poor code quality, duplication, band aids, etc. /code-review --fix # same as above, but also fix the issues # choose an explicit effort level (def…
In what scope?
Earlier quoted context omitted.
The point is that, with a sufficiently complex setup (with skills, MCPs, prompts, etc.) the difference in AI models will impact the quality of work. You might not care now, but you might care when you have 2 million lines of code and zero idea whats going on. The point is vendor lock-in. The vibe coding community has reinvented vendor lock-in and is bound to repeat every mistake associated with it.
Can you give an example of a skill or prompt that would work in Claude and not in the others?
We really need some consolidation around commands, skills, subagents, and plugins. For example, if you want to, say, review code, you have five options now: - Write a .claude/commands/review.md. Simple but deprecated. - Use a /code-review skill, either one you install or one you just write yourself (it's just Markdown, after all). - Use the /pr-review subagent. Also just Markdown, but it runs "in the background" and…
Hey, Boris from the CC team here. I agree, we're working on consolidating these. Going forward it will just be the built-in /code-review skill. Here's how to use the skill on the latest version: /code-review # do a balanced code review. checks for bugs and inconsistencies, poor code quality, duplication, band aids, etc. /code-review --fix # same as above, but also fix the issues # choose an explicit effort level (def…
/code-review ultra
main suggestion would be to sound a lot less optimistic about that it finds 99% of bugs or that its at all thorough, and instead list that it is time capped, and will only find bugs that you explicitly tell it to look for.
i used my three runs of ultrareview.
the first run with no other prompting found a couple typos in markdown only
the second one i prompted it with several themes of known open bugs in the code, and it found 6 items
and then the third one i ran after doing an actual long audit through gemini to make a much more detailed prompt about issues in the code
and for that one, instead of doing an exhaustive run, it just never started, so no idea if it worked
but the experience had no relation at all with the reliability or thoroughness claims
We really need some consolidation around commands, skills, subagents, and plugins. For example, if you want to, say, review code, you have five options now: - Write a .claude/commands/review.md. Simple but deprecated. - Use a /code-review skill, either one you install or one you just write yourself (it's just Markdown, after all). - Use the /pr-review subagent. Also just Markdown, but it runs "in the background" and…
> They are all just variations of "insert a canned prompt", varying only along the dimensions of (a) how and where the prompt is installed and from where it is sourced, and (b) which context or contexts the prompt runs in. There's not much advice here about which option is best, and no clear best practices seem to have emerged yet either. Personally, I find just asking Claude to review the code works well enough. The…
Yes, and this is what I mean by "which context the prompt runs in". The subagent approach is different and has pros and cons, and it may in some situations be better (but perhaps not in others). On the other hand, I can also just create a new conversation and paste my own review prompt into it; then take the last turn's summary output and feed it back into my main conversation thread in the unusual event I would need to do so. Spawning a subagent is a convenient shortcut for this, but ultimately, it's the same thing.
> I think the intent behind 'install a language server plugin' is that these tools should lint automatically after every edit, without waiting for an explicit call from the LLM.
This is a great point and I had only checked my session logs for explicit tool calls. I went back and looked for diagnostics injected automatically by the harness after every edit, and whether the agent made use of them.
Claude: neither the Rust or Dart LSPs ever inserted any diagnostic events, but Ty did. Across 627 sessions, ty-lsp injected diagnostics blocks in 186 sessions, with a total of 33 findings. Out of those 33, 32 were dismissed as unrelated (13) or pre-existing (19). Only 1 finding was acted upon. The model is in the habit of running the batch analysis tools (ruff, ty, cargo clippy etc.) and prek anyway, so it would have caught that diagnostic regardless.
Codex: no diagnostic events were inserted by any of the LSPs.
So I won't be reinstalling those LSPs.