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 "in parallel", so it must be better, I guess.
- Install the /code-review plugin. This just installs the skills and subagents above.
- Simply ask Claude to review the code. Probably works almost as well as the above in most situations.
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.
Some of the advice here is also off. For example:
"Install a language server plugin. Type errors and unused imports caught after every edit. Highest-impact plugin you can install."
I work mostly with Rust, Python, and Dart, and followed similar advice, installing LSPs for all three in both Claude Code and Codex. Two months later, after heavy development in all three languages and hundreds of sessions - and frequently running out of RAM due to all the Rust analyzer, Dart analysis server, and Ty LSP servers the harnesses were spinning up - I checked the session logs to see how often the agents were actually invoking the LSP tools. The answer was they had invoked them literally once the entire time. I uninstalled all my LSPs and haven't looked back. The agents do just fine using ripgrep and calling cargo clippy, dart analyze, ty check, etc. themselves.
I have thought for a while now that skills were a bad abstraction. There's a lack of definition around what to use them for that I think contributed to why they rose to the top, but that's also why I think they aren't a good long term option.
The fact that I can have a skill that is just general guidance on front end design best practices that an agent can call upon whenever they feel, and another that is essentially a run book of steps that need to be followed exactly only when explicitly triggered, and a third that is basically just instructions on how to use a specific tool and all of those are acceptable just feels wrong to me. I get why it caught on and why the flexibility is attractive when the entire world is collectively learning a new tool, but skills have come to feel like the junk drawer in the kitchen where you just throw random shit when you don't want to think about a better place to put it.
I would love to see the world standardize on something like:
- Agents: Essentially personalities for a model to take on. This becomes the new place for skills like "front end expert" where you're not telling an agent to do a specific thing, just to think in a certain way about a task.
- Prompts: Repeatable instructions for specific tasks that an agent should follow when prompted. This could be something like a checklist style run book on how to resolve a certain error that an agent needs to follow exactly or it could be something like here's an idea I have for a new feature please poke holes in it.
- Tools: Tools (like CLIs, MCPs, or scripts) and instructions on how and when to use them. I'm purposefully not calling this skills because I think the term is overloaded, but that's kind of what this is.
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 slash commands and such.
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 language gotchas" and also "Look at test changes"...etc. Yes these are all somewhat implicitly already part of what "code review" means, but the models perform best with explicitness.
If you want my 2c as a power user: just don't think about it and use /code-review xhigh --fix. This will cover like 98% of what you want out of code review. It's a good skill.
I don't even bother looking at the code until I've run a code review pass on it. Why waste my time with trivial bug fixes? I find the best way to spend time right now is like:
- Defining the issue/ticket, what "success" looks like (if I have a good idea of this), high level approach guidance 50%
- Dispatch agent to work on it 5%
- Occasionally return and nudge agent + send /simplify or /code-review 5%
- Look at the code/session summary, divergences from the plan, ask followup questions 40%
Occasionally yes there is some solution the AI chose that is suboptimal and I would prefer fixed in a different way. Mostly though it's straightforward.
Are you thinking of the /effort level in Claude Code? I would just go with xhigh as a reasonable default. Most important thing in prompting is specifying what "done" and "success" looks like to you. Ask Claude to help you come up with a well formed request and spend most of your time on that, then paste that into a brand new session.
And why would someone use the various levels? Is a low code review even worth running? And how do I know what level to use in the first place?
This stuff all seems so nebulous to me and I’ve yet to see anything that says use x in y situation. So I default to higher effort levels than I likely need.
Hey Boris, thanks for the great product and for listening!
I find the mix between slash commands that are programmatic harness configuration and control commands (/config, /model, /feedback, /fork, /usage, etc.) and ones that are little more than prompt template insertion (/code-review, /<skill>, etc.) to be a little confusing and unnecessary. A slash command should be one thing, and one thing only: a command for the harness, not the agent.
When I invoke a slash command like /code-review, I should be invoking some additional harness functionality, something above and beyond the agent's sphere of influence - not just pasting some hidden text into the next turn. Otherwise, why wouldn't I just say "Claude, review this code"?
Yet most of these "added value" commands bloating the slash command list, are just shortcuts for copy and paste. I don't want to go to have to learn the syntax of a special /code-review command (which options are positional args, which are --flags, etc.), and I'm much less likely to use or even be aware of a command like this, when I can just ask "Do a balanced code review and fix the issues", or use the GUI to set the effort level to xhigh before asking "Review my code." That way I can also be more specific about exactly what I need, rather than relying on what's in the canned prompt - a prompt which I'll probably never read and vet myself anyway. The value added by the slash command needs to be really high compared to just typing a prompt, for it to justify the friction of discovery and learning the syntax.
So I suppose I'm advocating for a different system. Keep slash commands for meta-level harness control and configuration, and add a new mechanism for canned prompt insertion, one which is tailor made for that purpose rather than overloading the slash command system. Let the user see what's in the canned prompts, and even make adjustments or edits as needed before sending them, one-time or persisted. Provide a GUI in the app with the user's favorite prompts, where the user can add, delete, and edit them, making it easy to invoke and insert them as needed. Or let the agent automatically discover and use them as needed, rather than requiring the user to remember and recall their magic shortcuts and their arguments. That's just one idea.
Skills, plugins, commands, and so on, need to be consolidated not just for code review of course but across the full architecture of how prompt templates are managed.
> # do an expensive and extremely thorough review (reliably catches >99% of bugs, costs $3-20 per review depending on complexity):
/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
Hey Boris, some feedback. I like the new /code-review skill but was disappointed you guys removed /simplify because I quite liked the focus on finding code reuse/efficiency opportunities.
I see now in 2.1.152 you added those focus areas back to /code-review, but still bundled with the correctness finding. It would be great to have more fine grained control over the /code-review angles beyond just effort level. Or maybe you would recommend that I just specify that as freeform input after effort level?
Yep, you can add free-form input. Will update /simplify to only check for code quality and not bugs (the way it used to work), that's a good suggestion.
> 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 subagent approach is structurally different from the others because it runs with clean context. That has three major effects:
1. All other things being equal, it will result in a lower cost-to-solution because of the quadratic cost scaling of an LLM session (input token or cached-input cost being paid with each new round).
2. The review model will not be able to 'cheat' by retaining assumptions from the main session, such as "x must be done like y." For people, this is why having a separate person perform code review (or, if not possible, reviewing code after a mind-clearing break) is handy; the applicability of this analogy to LLMs is vague but reasonable.
3. The main model will only see the results of the review, not the detailed reasoning that leads up to it. On one hand this avoids more context pollution, but on the other hand it might lead to duplicative logic to re-discover the mechanics behind bugs found.
> I checked the session logs to see how often the agents were actually invoking the LSP tools. The answer was they had invoked them literally once the entire time.
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.
> The subagent approach is structurally different from the others because it runs with clean context.
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.
Why does it need plugins/skills for a code review? Claude will just "review it" if you ask it to, and if you have particular preferences, they can go in CLAUDE.md
Skills are effectively the same thing as asking it, just with more depth. So the skill is just a framework for a very precisely asked question. It often includes how you want Claude to respond, etc.
I’m not aware of anything fundamentally unique about skills or commands, they’re just more tokens to shape the llm
> 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.
Yes, yes, thank you, sometimes I feel like I'm taking crazy pills.
The industry and overall developer ecosystem has become absolutely mesmerized by the act of creating and popularizing little bits of protocol and machinery to dress up the act of inserting text into the machine. Yes, they're useful and provide some consistency, but I'm convinced that the main reason people like them so much is because they put a thin "I'm still a programmer wielding complicated tools that laypeople don't understand" coating over the fact that we're all just asking the AI nicely to do a thing.
I imagine that the companies that earn money from input and output tokens really, really like excessive skills because of the sheer amount of potentially pointless constraints and instructions being sent back and forth ("don't store passwords as plaintext", "always check for syntax errors" and other obvious guidelines).
You're absolutely right to call this out — and honestly? I want to sit with that for a moment. Here's the thing: this isn't really about AI writing. It's not even about coding agents. It's about something much deeper. What's genuinely worth knowing: while I generally agree, many people may not. I think there's a really interesting conversation to be had here. Thanks for naming this. It needed to be named.
(/s - Blargh, writing like that that by hand is exhausting)
Hah thanks. I also feel this way rage-spotting AI-generated text everywhere these days. I have been looking into the speech patterns of LLMs lately ("unslopping" my own AI outputs) so had a bunch of the most horrible cliches memorized. Unfortunately this is a useless talent as a "reverse mechanical turk" at approx $25,000 for 1M output tokens (at 0.3 tok/sec) is not competitive in today's market.
I was at a restaurant the other day and my kid noticed how the waiter started every sentence with "Absolutely!" That reminded me of the Anthropic Super Bowl ad, and got me thinking if the waiter's speech patterns had been influenced by AI.
I hear you on vendor lock-in. Everyone's freaked out about other companies getting the upper-hand with AI in the loop, so there's this charge to use the hell out of it at all costs. Meanwhile, we're quietly picking winners and losers on the service side of all this, and we'll have to live with that outcome for a long time.
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.
Right now, self-hosting is too expensive if you’re starting from scratch. We have an old EliteDesk that can run the most basic of models, but it doesn’t feel like it’s worth it. Electricity is also quite expensive in many places, it adds up.
If hardware prices ever come back to sane levels, eh… the Framework desktop with Ryzen AI might be interesting to play with.
Self-hosting right now is in a weird spot. I'd say that the main benefit of the open models is not self-hosting, but having dozens of different independent providers that can host them for you. You aren't stuck with a single one.
Basically any other that is not stuck to being managed just by one company. Claude Code does things like using CLAUDE.md and other stuff specific to just their platform, so you are basically locking your project, and everyone else who works on it, to Claude Code only, if you don't also port everything you do to other harnesses. If Anthropic is giving cheaper tokens in exchange for locking you in into their ecosystem, then maybe it's time to test other models and not just use Claude for everything.
If you don't like CLAUDE.md, you can just add a memory/modify the plan agent to make an AGENTS.md. These aren't rigid systems. And, you don't have to tell it to look for an AGENTS.md, it'll just pick it up. First thing it does with /init is just look at what's already in the project folder. You should give CC a try!
works the other way as well, i have my opencode.jsonc which declares what model an agent should use, and it points at .claude/agents/ those agents each have their anthropic based model instead, almost feel like this broke in the past week though for just cc, hard to tell as cc keeps changing and i dont wanna update and learn more claude based nonsense again, if i wasn't locked into a year of pro or whatever, I would 100% be done using them entirely.
The comment wasn't about CC specifically. If you rely (like, can't ship without it) on any model that you don't control, it's not really your product. If Dario decides to increase pricing 500% because it's Tuesday, and you can't work without CC, you really have no choice but to open your wallet.
codex is also good, has better usage limits compared to CC.
Issue is that CC forced corps over 150 people into a API pricing, which is, well, suboptimal compared what we get. I think it will push those towards hiring more juniors (finally).
I find it interesting how they are almost all specifically for Claude and/or Claude code.
When open source glm-5.1 is just as good - if not better and stuff like opencode exists.
Not hard; just initially expensive (hardware mostly).
While I'm also a huge fan of local LLMs and believe they will be key in the future; I think the claim of "just as good" is hyperbole. They're productively useful tools though, and something worth exploration.
Well GLM-5.1 is 744billion params, no way I can run that locally. I use the opencode Go or Zen subscription. They have a zero day retention policy for all the model providers which is nice.
And then I can still use little local models like qwen and stuff by just swapping over to them.
But GLM is SOTA level for code, so it's obviously going to beat all local small models by a lot.
And you don't even have to use the OpenCode CLI, their subscription works with Pi, Charm and other harnesses. This is the way. If they screw up everything, I can drop their sub and go somewhere else.
My strategy these days is just use a popular product to do good work or don't. Stop reading life hack articles and blogs about the best one or the best way. Don't even click it.
I mean, to be fair there is nothing but shallow content available considering it's all stochastic responses that are incredibly difficult to actually measure and make real scientific inferences about. Until that changes I think it's going to be constant slop about optimization.
Do you have any resources for someone just getting started that you'd recommend? I've --successfully-- ignored AI for the last two years as I was taking care of our kiddo. I'm attempting to catch up in the next few weeks.
You took the time to write out this comment. To the benefit of those who read it, please expand upon where the article is shallow and what content you miss.
The critique seems perfectly clear to me: The post has no value. There's nothing to salvage, no improvements to be made. It would be best if it simply did not exist.
The poster probably hopes (as many of us do) that people will absorb the sentiment and post less of this junk in the future.
I am, too, and it got me thinking... why? And I realized that I've tried to be polite in all my interactions my whole life and I'm not going to practice being terse and commanding for a few pennies worth of tokens.
I've been using Claude to work on a medium-sized (100+kLoc) codebase, and it's a great productivity multiplier. Putting hours into creating a good AGENTS file is more improved results a lot. I find that over time it picks up the codebase quite well. Tedious tasks that would take a day are now a matter of a few prompts.
Still... I'm not ready to give it more autonomy. Even as it gets high-level things quite well, I still look at the code, give feedback, and have 3-4 rounds of tweaks until I'm happy with it, and also happy that I stil feel I have a good handle on the codebase.
Try to quantify those 3-4 rounds of tweaks into a set of rules to put into your AGENTS. Instead of iterating, have it start over from AGENTS file and see if it's correct now.
Ngl, that’s gold right here. I’ve been trying to automate my sessions, and what I’ve found cool is that you can ask Claude about how to improve on how to ask Claude things, and from there ask Claude to iterate on your session cycles
The percentage of times I prompt claude "what about checking if there are any child processes running?" or "Would using a lock here greatly simplify the design?" only to have myself be correct is approaching 100%. That is it isn't just claude sycophantically agreeing with me. The code itself becomes smaller, simpler, and more reliable with fewer bugs.
The agents tend to produce working code but the larger the scope the bigger the mess they tend to make. They will happily evolve toward a local maxima but leave world-destroying bugs lurking in the implementation.
The other issue is that claude regularly ignores explicit instructions in CLAUDE.md or in prompts. It will "helpfully" decide to just start doing whatever it wants or reinterpret instructions completely differently than it did the last 100 times.
It has nothing to do with losing control or trust. LLMs are not conscious. They have no executive function. They aren't even thinking. They're just models predicting the next word in the script. They are very useful tools but that's all they are: tools.
No. Because they still hallucinate at times. Confuse things. Forget things. Or none of the above, as it is anthropomorphizing, but the result is the same. They can make incredible working one shots, you start to trust them, then you trust too much and .. feel the result.
Yes. I am fighting with the disobeyance of LLM on working through my pipeline commands. I believe these violations are caused by its hallucinations. So I am still developing a mechanical system to monitor agents’ behaviors automatically. I believe these routines and monitors will play as a set of scaffold to keep leading the LLM on the right way all the time.
This was very difficult to read.
We really need to snap out of letting LLMs write posts. Even if there is some added value in this post, the feeling of chewing sand is just distracting and unnecessary.
The number one power move I have is Nix integration. The availability of tooling, secrets, environment and the ability for the agent to modify its own environment is... well, I don't know how people live without it. I guess you guys still install things using commands and hope everything you need is present on the next machine? Developer machine, CI environment, deployment environment: They're all derived from a single source, and compiling and running always works on every machine.
In Claude I use /branch and /rename a lot (context checkpoints, fork, go back)
I use sandboxing almost exclusively: https://github.com/nix-tools/bubblebox -- it's a generalisation of Numtide's claudebox with a few fixes and some feature additions (more coming). This is best compared to always running your Claude in Docker containers, except there's no Docker runtime. Works fine in WSL and nix-darwin, too.
I do the same. Codex manages a per project flake.nix and uses `nix develop` for all testing. nix-direnv for my own convenience. I generally have it generate dockerfiles or other deployment assets at some point.
I also prefer giving it a VPS over a Docker container.
On my own machine I just give it a Linux User Namespace, i.e. soft virtualisation via "bubblewrap."
What Docker Compose and Linux User Namespaces provide that a VPS doesn't: You can easily mount extra directories from your developer host machine in read or read+write mode. With the VPS you (most likely) need it to clone all of your resources separately, which requires SSH keys, and now you're slowly building towards an independent agentic environment, which is definitely very nice, but time-consuming, compared to piggybacking on your developer environment. Definitely the direction I'm going.
nix develop ensures your dev env is the same as your build/test/prod env. At least with Python everything is a flurry of requirements.txt, Python versions, poetry, pyproject.toml, perhaps automated with direnvs, a hefty Dockerfile/docker-compose, and perhaps conda (ugh) along the way; lots of moving parts.
I have a project that's mostly Rust sprinkled with C++ libs and Python helpers and it's easier to manage than the average virtualenv. Everything builds with nix build, everything runs with nix run, profiler/debugger works, IDE detects everything on any of my computers, builds and links with CUDA on x86, aarch64, NixOS, MacOS, Ubuntu or Amazon Linux. nix build can even build a Docker image for the odd need of Docker, and I haven't tried but I'm convinced that if I import the flake on my nix-config it will be built into the SD card for my Raspberry Pi just fine.
It's even replaced Ansible for me, colmena all the way.
Pythonistas have mostly moved to uv, which solves much of the "flurry" you describe. Tools like Mise add more of the benefits ascribed to nix. And smolmachines' smolvms can provide better isolation than Docker. Just saying, TIMTOWTDI. Not hating on nix, just pointing out it's not the only game in town.
+100. I also dig fnox (encrypted-secrets-in-git) and hk (pre-hooks manager that is actually fast and stays out of the way) by the same author, pretty much default for any project I start nowadays.
What happens when you have a codebase made with claude using this setup and claude is down for let's say 8 hours? Are you able to efficiently, smoothly and productively take over the codebase?
You could say the same thing about any always online software suite and it would be equally fair as we move into more agentic development workflows.
EX. Sure, you could go back to the old ways of using a drafting table for your engineering work if CAD went down but it would be exponentially slower…
Personally with my workflow I spend 30-60 minutes per Claude feature spec doc when I’m pair planning. If Claude goes down I would just prepare spec docs on my own until it came back online and then rapidly review them before calling the coding workflow.
> You could say the same thing about any always online software suite
But this is the reason "serious shops" do not use always online software and tools in critical parts of the SDLC. There is a difference between influencers/people on socials promoting things vs. reality where the expectation is that things don't just stop working because there is an internet outage or some 3rd party disruption
I would argue that it's really only toy projects that can continue in an Internet outage. "Serious shops" will be using cloud based version control, cloud based testing workflows, and most likely cloud based distribution of the software. isn't it only the little side projects you can get away with not needing the Internet for? Software long ago stopped being something one person on a computer did, today the professional SDLC includes many tools that are hosted.
Do farmers still plough fields with a Horse just in case their tractor runs out of diesel? Of course not, as technology moves on we all have to accept the inherent risks in exchange for the huge benefits, otherwise the work you do will be too slow and your job taken by someone willing to leverage the tools available today.
Which nobody is doing, especially not people who vibe code products. Saying "just prepare for it" as an answer to "what do you do if", is not really enough when that "prepare for it" is very expensive (time, tokens, effort etc.).
For someone to do this, they would have to think for themselves, which I've also not seen much of in the vibe-coding space.
Wait, what is "claude the model"? Anthropic's models are named versions of Opus, Sonnet, and Haiku. Claude, Claude Cowork, and Claude Code are their products which leverage those models. Right?
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.
So work stops until Claude is back? What if Claude comes back and costs 10x the amount? The answer is obviously that you'll "bend over" and pay, because the AI vendor who convinced you that Claude is so great owns you, your codebase, and by extension your company now.
Or you point your Claude code at a different LLM provider. It's not complicated and there are lots of vendors (and in the open-weights space multiple vendors serving the same models competing on price). Sure DeepSeek 4 isn't quite Opus at the moment. But it's plenty good to do the work. We've got different competing front-end tools and different competing back-end providers. No one 'owns' your company. Maybe that will change as the market evolves and one of the frontier tools become so much better than one vendor will own the market. But that's not where we are now.
What happens when your engineer realizes they can make 10x more at another company? They leave and work stops. You then hire someone else or raise your pay to get better, more reliable engineers. The analogies keep going because AI is a tool, not a replacement. If it's a tool used by a non-technical person, so be it, but it's still just a tool.
I have seen many many times in microcontroller forums posts from first timers in the liking of "hello sirs i have problem please show how to do this", followed by their own reply a few hours later asking again because they were holding up, where "this" was usually something really trivial, you just needed to read the docs and the rightful answer was "did you really not try anything in 6 hours?"
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.
The OP was asking what happens to productivity when your LLM is offline, I'd assume it isn't available yo onboard anyone at that time either.
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.
AI should enhance your skills. If it's down and your first though is to buy another sub from a different vendor this might be a skill issue. (I'm afraid every day that this will happen to me btw.)
Yes, but that's also a specific luxury I can choose for myself. Definitely a fun and interesting question. At some level of reliance, people would answer "no", but there's the large middle ground (assuming similarly-frontier models are down): having a weaker(?) AI model help you get up to speed ASAP by summarizing code pedagogically, and linearizing the code read order. Basically like an AI-assisted (but manual) code review to reorient yourself.
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.
Pretty much every single detailed prompt made after trial, error, and refinement is tailored to a specific LLM. They will all perform worse used with other LLMs than a similar prompt tailored for the second LLM would perform, and at times quite poorly.
Just use a fallback, like Codex CLI. Takes a little effort upfront to ensure your configuration is wired correctly for both harnesses, but it is pretty easy to get them 90% identical (there will almost always be some experimental / edge case features that differ across harnesses, but in my experience those are negligible in practice).
I more meant feature-level differences. For instance, Claude Code has agent teams, and Codex CLI does not. Or for a while, Codex had "/goal" and Claude Code did not (though now Claude Code has it too). To your point, it is usually possible to polyfill these gaps either with custom code/skills/hooks or with third party plugins.
if there is 8 hours of downtime (even before AI) I take that opportunity to do other codebase maintenance, debugging, file organization, renaming all the things I said I'd rename or take a break.
pre AI if my IDE was down for whatever reason I wouldn't switch IDE's, I would do something else.
Some agent-written tools and modules are easily the best codebases I've worked with. Documented correctly to the T with various charts and explanations for everything, "start here" guides, concepts defined clearly, and very good Git commit messages.
Naturally you can also have a LLM one-shot a 14000 line PHP monstrosity - it's up to you still, LLM or not.
The main problem is that it'll probably be a waste of time to code anything yourself if Claude is back online in 8 hrs. It's like walking to the next bus stop when you missed your bus - it won't make you get home any sooner.
8 hrs will probably be better spent reading specs or checking things with stakeholders so the next features you let Claude implement are the ones the business actually wants.
We have 3 big competitors in the space: Anthropic, Google and Microsoft. I think they can all use the same base configuration. So it's not that we are out of options here.
In my experience the answer is "no". If I am reviewing some slop and I ask Claude's human babysitter why this class has these constructors, they don't have any idea. Without Claude they don't understand the output at any level.
What happens when you have a codebase made with gcc for let's say 8 hours? Are you able to efficiently, smoothly and productively take over the assembly code?
You can use a local model, which will go down exactly as often as gcc will. We may still have hopeful notions of being able to understand the codebase, but the reality seems to be that the codebases we don't understand will be the ones that will win out in the market, because they'll be cheaper while still only having about as many bugs as they had when people wrote them.
Because you're better able to take over the codebase a local model wrote than one Claude wrote? The original question was about taking over an LLM-written codebase, it doesn't sound to me like the argument was about a codebase that Claude, specifically, wrote.
What does it matter what the codebase is made with? If Claude is down, use Codex, or Gemini, or Deepseek. That version of the argument is just way too easy to counter.
The reliance on context to drive correct actions just doesn't work well. I am constantly wrestling with AI agents that do not do what you tell them. Every AI agent out there seems to suck in this regard, leaving it up to the user to build in their own guardrails. I have a bad feeling that nobody is working on an improved solution.
I’ve seen no reason to believe it’s even possible to solve this.
The worst thing about LLMs is they can pass the Turing test, leading people to believe they have an Asimov style robot instead of a very cool statistical model. It feels like they should be able to follow instructions or keep instructions from content separate, but that’s not what’s happening.
When the you send a prompt and the AI wants to run a tool, it should be outputting a structured output which the AI agent can scan, find a tool call, and run that tool call. But how does the AI know the "right" way to call the tool, right args, etc? You're supposed to tell it once at the beginning of the context... but it can forget that.
So really, your tool-specific rules should be passed to the AI either with your follow-up prompt, or in response to the request to issue a tool call, so the AI can validate what it will compose the tool call as, right as it's making the call. This means the agent should keep track of tool-specific rules, and reinforce them to the AI. Yes this will spend a few more tokens per call, but it will probably improve the outcomes somewhat.
In addition to this, we should probably be abstracting the tool calls more. Rather than let the AI run a Bash one-liner which includes writing files to `/tmp/foo.txt`, we should have the AI output even more structured tool calls, liike `make_temp_file AS BAR`, and have it then call another tool referencing $BAR (`some_other_tool -tmpfile $BAR`). This way there is less to go wrong because it's not getting in the weeds doing shell scripting while it's trying to do something more important (diagnosing an issue).
I think this will require additional training by the AI companies. Which is why we need to define these kind of standards now, so 6-12 months from now, we will have AI that actually support these higher level abstractions. You then customize your abstraction, and the AI doesn't have to know anything about how it works on your box. It would greatly reduce the complexity required for AIs to do agentic work.
bun run test -- -t "test name" # Single suite
bun run test:file -- "glob" # Specific files
# 4. Lint before committing
bun run lint:file -- "file1.ts"
bun run lint
# 5. Before creating PR
bun run lint:claude && bun run test
```
I have these things in pre-commit, this way the targets are always ran and the agent is forced to fix them (I ask claude to commit changes). The agents are erratic and very often skip these steps. Anything that can be deterministic I keep as scripts.
Regarding commits; both codex and claude are terrible at writing them. I have in my user CLAUDE.md:
```
Pattern: `type(scope): message` where type is `fix`, `feat`, `chore`,
`docs`, `refactor`, or `style`; scope marks what is affected; message is a
short lowercased description.
Keep subject and body lines under 72 characters. Always write a body
explaining what, how, and why in continuous human-readable text. For fixes
include the error message being fixed. No first-person speech. Re-read the
actual git diff before writing — the message must describe what changed,
not what was planned.
Use following command to create commit:
```bash
git commit -F - <<'EOF'
type(scope): subject line
Body paragraph explaining what, how, and why.
EOF
```
```
Without it would write the body as a single long sentence; when asked to fix lines it would just insert \n (newlines), which were not respected and were instead just rendered as characters.
Another thing I find helpful is VOCABULARY.md. Very often the agent would assume (connect?) a different thing than what I had in mind, with VOCABULARY I make sure when I say "thing" claude and I have both the same "understading" (connection?) what "thing" is.
There is so many concepts that I just sometimes forget, that's the purpose of the file, so I don't have to guess and can explain clearly what I mean (I am not a native speaker).
To understand a solution you must first understand the problem. If your whole company calls its customers "clients" but claude finds that confusing, I think it's probably easier to tell claude that then get everyone in the company to change how they talk.
I mean at this point, you should just write a few deterministic orchestration scripts to automate away the boring parts and write the code yourself. Why are we wasting our time on making the wonder shit-machine work?
I don't know, after working for 13 (?) years as a software (and backend) engineer I kind of think writing the actual code is the boring part of our job. 90% of it (random number) is mostly a template code (depending on the language you use).
VS Code - how much of this can you NOT do with VS COde. For instance, even /rename doesn't work in VS Code. I guess I can try all the recommended commands, but I'm skeptical. Or, conversely, is best practice just to use Claude on the command line, even if I have VS Code as my editor? I think the VS Code integration with Claude is pretty great, but just the /rename issue shows that it is limited.
In the recent weeks, I think the harness/model came to a point that you can just ask it to do stuff and it just does. You can use plan mode, you can also use superpowers, or whatever other skill, but given that you'll review something anyway, why not work directly with code instead of silly amounts of md files?
I like having a spec file that is used to generate the code. It's more dense and easier to understand what the application is supposed do. Prior to AI Agents, I had a more complex relationships with requirements because not all devs updated them. I was confused if the spec or code was the correct behavior for any aspect of the application.
In the recent weeks I trust Claude less and less. Yes, you can ask it to do stuff and it does stuff. But if you do look what it did you will often find corners cut, work based on assumptions and not verification, a lot of stuff missed.
Even tests - it is common for it to write tests which in reality test nothing.
Because it might not have done what I wanted it to do. Also, just as with normal code review, I’m not just looking at the code but the final product. Maybe I realize after that I asked it to do something that was wrong?
I really appreciate the documentation. But, it appears to me that this is how I also use Claude daily and I thought I am just using it as a coding agent. The intro however sounds like a recipe to use Claude for everything else beyond a coding agent.
Also, this stuff feels like alchemy to me . I bet some of you have the same feeling.
Sometimes I feel like the only sane person in the room for not wanting to have to usher the LLM through phase by phase. Every time I need to choose the next skill or cat the next error is just a waste of my time that could be spent doing things that actually need my attention like making business tradeoffs.
I only use opus 4.7 and am on the 100$/mo plan. I usually make sure the context does not grow beyond 30-40% of the 1m tokens. On heavy coding days where I do something pretty similar to this, I would occasionally run into the five hour limit, but that happens like once per week and then it wouldn't take too long to reset. Note that I use caveman, but I'm not sure to what extent that really helps.
To me, this kind of talk exhibits the very cultish and con side of the whole genAI train. In a way, it does a poor job especially when the intent is positive about the technology, it sheds a bad look on it.
Generally, and more so with paid products, one should expect to get something that is ready to be used, tuned by who's selling it at the best of their efforts. Instead, this is basically saying that the product is actually not much more than an empty box, and that it is your responsibility to augment it with third-party plugins and markdown texts that make it finally useful. And you better be carefully selecting the skills you install, you don't want to end up with second tier material made by GithubInfluencerA, you definitely need the work of GithubInfluencerB.
In the end, it's what is giving companies fuel to keep the hype running, because it allows to counter every possible argument or doubt about the technology, especially the ones made in good faith. No matter the problem you're facing, the blame is definitely on you, the user, for not setting up the tool in the right way.
I'm struggling in a lot of ways in accepting LLMs, but if I'll ever come completely sold on them and take this technology seriously, it won't be before this mood has gone away.
I see this kind of first-gen coding agents a bit like the AI-era microsoft excel: you need to be a poweruser to use it correctly, otherwise you'll end up failing catastrophically. Hence the amount of different ways to use it.
Having an "unfinished" product is also a great marketing tool for companies like anthropic: each skill/plugin/guide that you see on the internet is boosting their SEO + social validation metrics.
I understand and sympathize with this point of view.
I would just say this: there is a difference between advice for using a product, and for _optimizing_ your use of a product. Between a user and a power user.
I think devs probably disproportionately like to see themselves as power users of any given tool, and thus with coding agents, there are 1000 "systems" being thrown out on GitHub on any given day. Generally speaking, it is safe to avoid these, especially if you're new to the tool.
But saying the fact that people are into optimizing their setups indicates some fundamental deficiency of the tool misses the point, I think.
Claude Code and Codex CLI (and OpenCode, and I'm sure many others) are _remarkably_ effective right out of the box. The teams behind these tools must make them _generically_ useful so that they are accessible to as many people, and as many use cases, as possible. That is part of why, when you become familiar with the tool, there is typically going to be a level of customization you can apply to it to optimize it for _your_ use cases, beyond the generic out of the box configuration.
Similarly, I don't think it would be fair to critique VS Code simply because most power users augment it with a suite of extensions. In fact, it's customizability/extensibility is part of what makes it great.
I absolutely understand the power user perspective. The point is not that, and maybe I wasn't clear enough in pointing it out.
Here, something different is going on instead of the usual "base tool is ok for 90% of use cases, remaining 10% is covered by plugins and extensions". A lot of developers are finding it difficult to commit to agentic coding workflows, feeling a stretch on a lot of different aspects.
Companies, with the help of a very prominent and vocal part of the web and social media community, are addressing every issue by simply blaming the users, saying it's their fault if they're not keeping up with all the alleged advancements in prompt strategies. See the whole "maybe you haven't tried it in the last two months, everything's changed now". While it's true that things have been moving very fast, the fundamental idea behind the technology is the same, and some concerns about it simply cannot be wiped away by scaling some factors.
To me, this kind of talk exhibits the very cultish and con side of the whole genAI train ... Generally, and more so with paid products, one should expect to get something that is ready to be used
Right like I bought an AWS EC2 m6a.metal instance expecting to get something that is ready to be used. Now being told to recite arcane "commands" from the cloud computing holy book. They claim their supposedly groundbreaking hypertext protocol isn't even accessible to mere mortals using a $6000/month EC2, the blame is definitely on you, the user, for not setting up the tool in the right way.
This sysadmin cloud cult is basically saying that the EC2 product is actually not much more than an empty box, and that it is your responsibility to augment it with third-party servers and interpreters and application source texts that make it finally useful. And you better be carefully selecting the tools you install.
an EC2 instance gives exactly what you're told you'll be getting. You pay for a VM in some public cloud, you get it.
It's not that Claude code isn't a finite product per-se, I certainly can find some value in it. What I'm saying is that people selling it, through the convenient talks of prominent voices on the Internet and gullible C-suites, are trying to make it look like it's the only software engineer the world will need from now on. What makes me mad is not the deceptive advertising, that's already everywhere, it's the fact that the industry is happily believing all of this. If you raise any doubt, it must be that you haven't tried with the right skill.
I’m getting into the agentic coding (I know, late to the party, and that’s been a good spot for my experience and use case), so I’m reading with interest. The first tip: “give Claude a way to verify its own work”.
So what’s the recommendation for Claude to have a feedback loop?
Because it’s not what follows in the article: _“Explore, then plan, then code.”, “Use plan mode…”, “Reference, do not describe.”_
In my experience, the biggest benefit comes from having good quality integration and unit tests that are easy for the agent to run on its own to verify its work against.
I'm stuck on the usage "mulle times a week" which shows up twice in the context of the Claude team editing or contributing to a CLAUDE.md file. Is this an AI-generated artifact?
How much time do you lose when doing things like "verify plan with a second clean agent" instead of just reading and fixing it yourself in 5 min? How much understanding do you lose? How do you manage to treat it "as an engineer" where it's clearly not there yet? How much time do you lose when it makes almost the same mistake, invents stuff or tries to gaslight you over and over? What about blood pressure?
The post goes to the point. Somehow this must be buried in Anthropic's documentation but I miss this kind of back-to-basic posts. Even if they are LLM-penned.
The author’s claim that Claude is a multiplier for skill is probably true for now but it also feels like cope inspired by usability issues with Claude. The advice is all good, but none of it is especially clever or impressive or hard to grasp. The multiplier just comes from the fact that anthropic hadn’t taken this essay and several similar ones and incorporated their feedback into the product. This is a pretty shallow most of expertise that anthropic ought to automate in a week.
My complaint with anthropic is actually the opposite. They seem too focused on building this suite of products (because they want lock-in), but they can’t even get the availability and speed on their models in an acceptable state. It really does seem like they’re falling behind google and OpenAI at the moment.
I don't know how you guys still use anthropic models and Claude Code. It's so unbearably slow. Yesterday I was on screenshare with a coworker that still uses claude and I was shocked how much time was spent just waiting for tokens to generate.
Do yourself a favor and try Codex. Then do yourself an even bigger favor and try composer 2.5 from Cursor. It's night and day difference. You don't even have time to get distracted, you stay in the zone.
Beyond the issue of AI serfdom, I just don’t want so much of my workflow to depend on “some other company.”
This whole setup is basically setting you up to have all your projects in a Claude SaaS lock-in.
I also think if AI was actually smart it wouldn’t need so much handholding. I don’t want to spend my time developing skills and writing markdown files to try to get this dumb thing to write code for me. Why isn’t the AI reading the codebase and understanding what to do?
Best Claude Code daily-driver guide I’ve read. Though I’ve only read two. The “let Claude write rules for itself” CLAUDE.md pattern is the highest-ROI habit in there. Buth here’s the thing. The assumption underneath: this works when Claude mostly follows CLAUDE.md. Anthropic’s own engineering post from May 25 (https://www.anthropic.com/engineering/how-we-contain-claude) reports their telemetry shows ~93% of permission prompts get clicked through and ~17% of dangerous actions slip past the auto-mode filter.
Their conclusion: environment-layer containment first, then model-layer steering.
CLAUDE.md is the right configuration layer but it is not a containment layer. Worth thinking about whether your worst case is a lost afternoon or a lost database and all backups deleted, too: https://safebots.ai/compromise.html
But the more important point are the costs. People are starting to realize just how costly it can be to run agents without precomputing and caching: https://safebots.ai/costs.html and self-orchestrating agents can go up to 1000x: https://safebots.ai/kimi.html
I agree, I find that just telling claude to use the CLIs I would have used anyway in the prompt works just fine. Use gh to do X, use az to do Y, build using Z. The harness handles the rest. All these MCPs, Skills, plugins, etc are just noise
> Delegate, do not pair-program. Cat Wu (Claude Code team): “The model performs best if you treat it like an engineer you’re delegating to, not a pair programmer you’re guiding line by line.” Write a crisp brief upfront, then let it run.
This is also how you get a slop codebase that you won’t easily understand.
It becomes a labyrinth that only the Agent knows.
It’s not a catastrophe when your making prototypes or projects like you see on X.
But if you are expanding your codebase or trying to build something more professional and maintainable. I find it important to explicitly spec things bit by bit so I can understand and some what keep my writing style in this codebase.
But this is only productive when you have a fast model otherwise it kills your chain of thought while you wait for the output.
If the model is slow, delegation is probably the only way.
Oh great! Another AI slop article about "working" with AI (= working for AI). Do you notice how much bloody work you put in the boring parts, only to leave out the most creative aspect of software engineering to a slot-machine?
I agree. In fact, computers in general are for lazy cretins who can't use a pen and paper. We got man into space calculating with a pen and paper, if it was good enough then, it is good enough now. I like your concept, it should go further, cars are for people too lazy to walk. Planes are for people too lazy to flap their arms. Video cameras are for people too lazy to draw each frame by hand in real time then play them in a hand cranked projector.