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.
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
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).
> 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.
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)
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.
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.
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.
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.
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.
In my experience threatening the death penalty for the Claude board of directors improves its performance even more than threats of corporal harm or imprisonment.
Personally I'd like to see AI ceos (legally) exterminated for their traitorous crimes against American society and culture.
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
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.
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.
+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.
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.
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.
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
There are dozens of competitive models that can take over the job. It's just simply a matter of getting Claude (while it's running) to generate feature-parallel multi-agent LLM configurations which can hot-swap between LLM providers in the case that Claude has an outage.
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.
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.
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.)
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.
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.
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).
> 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
You don't need to put in any effort, just get Claude (Codex CLI if Claude is down) to generate the multi-harness config for you.
You sound like you might be a beginner so let me help you out with some advice -- You can get your multi-harness configurations completely identical by simply telling Claude to research the Codex spec and eliminate all feature drift between your configs. Hope this helps.
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.
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?
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.
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.
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).
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.
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.
If you aren't using AI for code review in 2026, why would you even bother? High quality, error-free, better-than-human code generation AND review is available for cheaper than ever. Why are you wasting your life reading code you didn't even write?
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?
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.
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?
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?
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 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.
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.
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?
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.
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?
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 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
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
> 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.
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.
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.
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 (defaults to your current effort level). all of these also accept --fix:
/code-review low
/code-review medium
/code-review high
/code-review xhigh
/code-review max
# do an expensive and extremely thorough review (reliably catches >99% of bugs, costs $3-20 per review depending on complexity):
/code-review ultra
Open to feedback if anyone has feedback or ideas for how to make these even nicer to use.
I just consider this temp phase because models are dumb and harnesses are not yet there.
When I need code review I should just say “review it”. Model should figure out what plugins, skills, etc. to use.
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
1 reply →
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).
My personal experience is the opposite. Lack of skills uses more tokens.
> 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.
How many times can I read the same shallow guidance written by AI on using a coding agent? Good god when will it stop
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)
I could literally feel my blood beginning to boil. You have a talent for this.
1 reply →
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!
For most people, CC is cheaper tokens for a SOTA model.
What agentic platform would you recommend for those with API access (including other models)?
9 replies →
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.
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.
If you're talking about Claude Code: Just the official docs [0] and then the best practices tweeted by Anthropic team members like Boris (@bcherny).
Ignore all the 3rd party frameworks (at least for now, probably forever.)
[0]: https://code.claude.com/docs/en/quickstart
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.
Makes one wonder...
How easy is that to setup by comparison?
4 replies →
Reachmaxxxing wannabe influencers who were too far gone to looksmaxxx have to do something to grift a living and NFTs are dead.
It can stop now and you can choose not to click on the links :)
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.
In my CLAUDE.md I have:
- corporal threats of harm directly against Claude
- threats of prison for the entire board of directors of Anthropic
- explanation how every time it goes off the rails / makes mistakes, it gives more evidence to a class action lawsuit against Anthropic
Especially the latter two seem to have improved its "behaviour" to be more "careful" and "deliberate"
I am nothing but polite with my agents. I always ask, say "please" and "thank you", and never swear at it or call it names.
I'm hoping that when the robot apocalypse happens, they'll let me stay in the breeding harem, or worst case let me live a few extra minutes.
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.
Apocalyptic safety is just a bonus.
In my experience threatening the death penalty for the Claude board of directors improves its performance even more than threats of corporal harm or imprisonment.
Personally I'd like to see AI ceos (legally) exterminated for their traitorous crimes against American society and culture.
Fix the CSS div alignment issue, make no mistakes or Dario Amodei will die instantly.
Claude: Oh shit this is serious I need to step up and center the div with perfect precision … (45k tokens later) … style="margin: 0 auto”
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
1 reply →
Understandable. You don’t want to lose control to your codebase and don’t trust LLM is competent in handling that fully.
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.
1 reply →
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.
Codex is way better at nix than I am.
I just gave mine its own VPS. Maybe more expensive than Nix but it was very easy
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.
I just use docker and I don't feel I'm missing anything?
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.
1 reply →
Docker's ability to mount host directories in the container is really nice.
Maybe you have some premade tooling that helps provide persistency between container invocations.
But by default, closing your agent container and opening it again just wipes everything you didn't host-mount.
What I'm advocating is really just the same functionality without the Docker runtime, because Linux has namespaces.
Feels more like you're on your host system with exactly the minor variations you specify.
Making Docker feel like your host system is possible, but I just never felt at home.
1 reply →
For those who don't want the complexity of Nix, Mise is a good compromise
For those who don't know: Mise is a version manager (among other things), and is said to be an improvement over its predecessor, asdf:
https://mise.en.dev
https://asdf-vm.com
+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.
Though I also use nix to manage my machines :-D
2 replies →
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.
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.
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
Precisely. Every online-only solution is a huge risk i personally do not want to take, i've always done my best to use offline-only tools.
That may restrict me from the latest and greatest, but i prefer not to be left at mercy of any corpo
How does "CAD" go down? Sure, there are online CAD systems (onshape), but there are offline ones too (fusion, freecad)
> 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
1 reply →
> You could say the same thing about any always online software suite
Uh, people do say this thing. It is a basic factor and question asked during technology procurement. Uptime and fail states matter.
AI just seems exempt from all the questions people usually ask about relying on other people's software.
After 1 hour you asked the question, I am reading the replies and the conclusion is: no, they cannot.
There are dozens of competitive models that can take over the job. It's just simply a matter of getting Claude (while it's running) to generate feature-parallel multi-agent LLM configurations which can hot-swap between LLM providers in the case that Claude has an outage.
3 replies →
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.
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.
5 replies →
What happens if you get up in the morning and your car won't start? Do you walk to work?
Yes, I actually have done that.
1 reply →
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.)
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.
Claude Code CLI is just a software package, if Anthropic API is down you could always connect Deepseek/other provider API to Claude Code CLI...
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.
1 reply →
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).
> 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
You don't need to put in any effort, just get Claude (Codex CLI if Claude is down) to generate the multi-harness config for you.
You sound like you might be a beginner so let me help you out with some advice -- You can get your multi-harness configurations completely identical by simply telling Claude to research the Codex spec and eliminate all feature drift between your configs. Hope this helps.
2 replies →
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.
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.
A local model doesn't have downtime. No you can't be as hands off with it as something like Claude, but isn't that a good thing?
time for a day off!
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?
1. When and how would gcc go down?
2. How often do you think that happens, compared to Claude?
7 replies →
GCC down? Did the AI rotten your brain that much?
How can you come up with such non sense.
The same thing as happens if I go to sleep for 8 hours.
wat?
Is this really a position you want to take in public with your real name and identity and everything plastered over your profile?
1 reply →
This is just so much fluff. All the focus on "orchestrating" is ultimately accidental complexity.
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.
100% AI generated according to Pangram.
Regarding:
``` # Development Workflow
*Always use `bun`, not `npm`.*
# 1. Make changes
# 2. Typecheck (fast)
bun run typecheck
# 3. Run tests
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.
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).
Isn't it simpler to use claude's vocabulary? I don't see a good use case for this.
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).
Example: https://github.com/rkuska/carn/blob/main/VOCABULARY.md
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.
Claude Code with skills is undoubtedly powerful and useful, but it doesn't always work as expected.
I always get the best results when I have live feedback with it.
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.
> but given that you'll review something anyway,
If you aren't using AI for code review in 2026, why would you even bother? High quality, error-free, better-than-human code generation AND review is available for cheaper than ever. Why are you wasting your life reading code you didn't even write?
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?
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.
Yep, Claude is behaving more and more like a human being.
There are some system prompts for making Claude Code a tool to the human, not the human a tool to Claude.
With this i mean there are some system prompts that make Claude very concerned about your autonomy.
I think in the future this type of system prompt will be embeded to force people to think a little.
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?
> 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?
The marketing strategy for the AI firms is to get people with poor reading and writing skills socially dependent on their "tools".
The selling point is that you can delay "reading and fixing it yourself in 5 minutes" ad infinitum, consequences be damned.
What we gain from LLMs is avoiding (heaven forbid) having to read and write for another 15 minutes.
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.
Have tests, provide screenshots (or enable it to navigate the UI): https://code.claude.com/docs/en/best-practices#give-claude-a...
Typically for most code it's telling claude how to run tests.
For front end code it's giving claude a way to 'see' the work for example a Playwrite MCP server seems common. https://playwright.dev/docs/getting-started-mcp
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?
That got me too. It's not there anymore.
Could be a simple typo, but I my mind jumped to `s/tip//g` which is kinda interesting
I think you're right, more evidence: "11. s From the Anthropic Team", "Boris’s single most-repeated ."
I tried both Claude Code and OpenCode with deepseek flash api. claude code eats more tokens for the same task (but only tested it for an hour).
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.
Why are there so many flagged comments in here? They all look fairly banal but yet still flagged.
The majority seems AI-generated slop.
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.
Out of curiosity, how much does it cost to daily drive Claude like this?
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.
about 10-22€/month is the minimum since you need Claude Code, which means you either need the pro subscription (22€) or an API with some credit on it
isn't it $20/month /s
What's the standard for a "battle station" interface to manage agents for programming (using isolation with maybe git work tree and ideally VMS ?)
I found this one: do you guys know something else ?
I’m so done reading articles like this.
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?
Because it’s artificial, that’s why.
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.
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?
Written by an LLM, deployed by an agent to the blog, posted to HN by a bot, upvoted by more bots to market "AI".
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.
"Claude Code as a Daily Driver", which was also used to generate this article..
Also, how is "Explore, then plan, then code" considered "beyond the basics"?
I’ve used Claude for a couple of months now and didn’t know about the specific “plan mode” you can put it into!
Nerds and their tendency to over-complicate everything. What is wrong with just an IDE with a simple claude integration?
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
Claude is not a simple technology. Why are you trying to stuff a 4-dimensional peg in a square hole.
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
> 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.
Honestly, claude code has saved so many hours of finding bugs for developers
generated hours...I can find bugs as a developer easily, the rest comes from the user.
The good bugs from AI are bug neither developer nor user has found, so it is more work.
For lazy cretins maybe
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.
1 reply →
Bro go take a walk really, get some fresh air maybe, get a grip jeez
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
[flagged]