Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Claude Code as a Daily Driver: Claude.md, Skills, Subagents, Plugins, and MCPs

arps18.github.io

Post reply on HN
Print view View original

261–270 of 297 posts

Re: Claude Code as a Daily Driver: Claude.md, Skills, Subagents, Plugins, and MCPs

#261

Post by sgc »

tvmalsv wrote: post #251
sgc wrote: post #216

Earlier quoted context omitted.

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.

How well would it work to ask the working LLM to rewrite the prompt to get the best results? Do the models understand enough about themselves to do that?

Claude has a /product-self-knowledge skill, and I am sure the others have something similar. So yes, it is possible if you work with care, as necessary with all things LLM related. There are hundreds if not thousands of skills on github that were created just this way.

Re: Claude Code as a Daily Driver: Claude.md, Skills, Subagents, Plugins, and MCPs

#262

Post by sgc »

CamperBob2 wrote: post #259
sgc wrote: post #216

Earlier quoted context omitted.

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.

That's kind of pointless, then, because what happens when Anthropic releases their next-gen model?

It's not like you aim to do it, you are just in a feedback loop improving results for the tool you are using. It is inherent in any prompt developed through iteration.

Re: Claude Code as a Daily Driver: Claude.md, Skills, Subagents, Plugins, and MCPs

#267

Post by _heimdall »

ordersofmag wrote: post #74
lionkor wrote: post #72

Earlier quoted context omitted.

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 wil…

I didn't realize you could swap out the underlying model used by Claude Code. Aren't all of the Claude tools tied directly to Anthropics models, their authentication and billing, etc?

Re: Claude Code as a Daily Driver: Claude.md, Skills, Subagents, Plugins, and MCPs

#268

Post by sshine »

chrisweekly wrote: post #134
fer wrote: post #116

Earlier quoted context omitted.

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 th…

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.

Nix is like Borg of Star Trek: It assimilates everything.

I'm not a Python developer, but I follow the news, and I agree that uv is the future of Python package management.

So if you're a Nix user and you want Nix to be opt-in, and you love uv, you use uv2nix, declare the uv lock file the source of truth and build your Nix derivations on that. When the hashpins live in the uv lock file, uv works just fine, but uv2nix produces derivations that are cached and can be embedded in CI or deployment strategies.

So... running CI on your uv-based project means your Nix tooling can cache both tooling and dependencies.

And... deploying your uv-based project you can build an OCI image with the same source of truth as the dev/CI environments.

This matters more for toolchains that YOLO more wrt. dependency pinning: Does that CLI call in your Dockerfile really pull the same thing down just because it's still v6.6.6? Some package managers provide a lot of sane choices, and I'd bet uv is one of them. But your Dockerfile is always a second-grade citizen unless you re-use the same base as a devcontainer.

Re: Claude Code as a Daily Driver: Claude.md, Skills, Subagents, Plugins, and MCPs

#269

Post by tomhow »

thunky wrote: post #132
moron4hire wrote: post #120

Earlier quoted context omitted.

Yes, I actually have done that.

[flagged]

Please resist in future :) The guidelines ask us to avoid internet tropes, precisely because they're repetitive, and more apt to make us groan than smile.

https://news.ycombinator.com/newsguidelines.html

Re: Claude Code as a Daily Driver: Claude.md, Skills, Subagents, Plugins, and MCPs

#270

Post by alexwwang »

xenadu02 wrote: post #228
alexwwang wrote: post #86

Earlier quoted context omitted.

Understandable. You don’t want to lose control to your codebase and don’t trust LLM is competent in handling that fully.

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 t…

Yes. They are tools. So my approach, at least try to approach is to keep on polishing the skills and check the output of LLM in loops with mcp to alert the abnormality asap so the LLM won’t go to next step to make things worse.
Post reply on HN