My impression is people build very fragile Rube Goldberg devices on top of the models and those things break. That's not to say anything is wrong about the Rube Goldberg machines! They're very interesting and do new things (and they help me understand how things work). I'm just saying that there's probably a significant misattribution about where the fragility exists.
I sort of agree with this about cognitive load. I'm somewhat new (started dipping my toes around July) but use Claude code heavily now. I did spend a lot of time playing with configuring it at first and creating agents etc. But I have a weird setup where I have three computers that I work on and at one point I realized vanilla Claude Code had adopted the things I was doing as defaults (and improved on them). So I have sort of declared a configuration bankruptcy and just use the recommended things. The only things I still do are things that help both Claude and I keep track of things (md files describing decisions and context of files).
[I still haven't figured out MCP or how/why to use them or why to bother. You run servers. I guess. It's too complex for my smol brain to understand]
> I still haven't figured out MCP or how/why to use them or why to bother. You run servers. I guess. It's too complex for my smol brain to understand
I know this is self-deprecating humor, but you do NOT have a smol brain: MCP servers are not as needed anymore now that Claude Code supports "Skills". They are also very token hungry as their spec is not lazy-loaded like the skills.
It was / and still is very useful if you collaborate with other engineers or want to perform operations in a non-stochastic fashion.
MCP servers are a way to expose a set of APIs (openAPI spec) to an LLM to perform the listed operations in a deterministic fashion (including adding some auditing, logging, etc). LLMs are fine-tuned for tool calling, so they do it really well and consistently.
Examples:
- Documentation / Glossary: MCP server that runs somewhere that reads a specific MD file or database that is periodically updated: think "what are my team members working on" / "let me look up what this means in our internal wiki".
- Gating operations behind authentication: a MCP server that is connected to your back office and allows you to upgrade a customer's plan, list existing customers, surface current. Super useful if you're a solo-founder for example.
It's more like you want Claude to interact with X, and you go to see if there's an MCP server for it.
Claude could use the API directly but most MCP now comes with OAuth so you can let it act as you, in case API keys are hard to come by or chargeable. Sometimes with a good skill or a preconfigured CLI tool skills can be just as good if not far more powerful than an MCP server.
But the trigger you'd look for to decide to use an MCP is 'i wish Claude could access X'. My top examples:
- pulling designs from figma to implement them
- fetching ticket context for a job from JIRA
- getting a stack trace to investigate from Sentry
If you haven't grokked MCP yet don't bother now; it's on the way out. Instead do learn to write an AGENT.md file (create a CLAUDE.md file to point to it) then list all the tools you have at its disposal. It will probably know how to use them; it just needs to be told what's available.
I definitely relate with your sentiment and I like your term "configuration bankruptcy"
on MCP, the mental model that clicked for me is "giving claude access to tools it can call" so that instead of copy pasting from your database or API, claude can just... query it
I've not explicitly used skills or MCP, but have had zero issues with Claude calling apis via curl as an example. I'm not sure what the MCP server or skill is actually enabling at this point. If I wanted CC to talk to SQL Server, I'd have it open a nix-env with the tools needed to talk to the database. One of my primary initial claude.md entries has to do with us running on NixOS and that temporarily installing tools is trivial and it should do things in the NixOS way whenever possible. Since then it has just worked with practically everything I've thrown at it. Very rarely do I see it trying to use a tool that isn't installed anymore. CC even uses my local vaultwarden where I have a collection of credentials shared with it. All driven through claude.md.
I, too, made this assumption. Then I learned it was an actual product my ex-employer had selected and kept using.
It still didn't make sense why an enhancement request and a fix request couldn't be moved between queues. Or why I received three (at least) emails when an issue was closed.
For example sometimes you're faced with choosing between high-quality libraries to adopt and it's not particularly clear whether you picked the wrong one until after you've tried integrating them. I've found it can be pretty helpful to let the LLM try them all and see where the issues ultimately are.
> sometimes you're faced with choosing between high-quality libraries to adopt and it's not particularly clear whether you picked the wrong one until after you've tried integrating them.
Maybe I'm lucky, but I've never encountered this situation. It has been mostly about what tradeoffs I'm willing to make. Libraries are more line of codes added to the project, thus they are liabilities. Including one is always a bad decision, so I only do so because the alternative is worse. Having to choose between two is more like between Scylla and Charybdis (known tradeoffs) than deciding to go left or right in a maze (mystery outcome).
It probably depends on what you're working on. For the most part relying on a high-quality library/module that already implements a solution is less code to maintain. Any problems with the shared code can be fixed upstream with more eyeballs and more coverage than anything I build locally. I prefer to keep my eyeballs on things most related to my domain and not maintain stuff that's both ultimately not terribly important and replaceable (if push comes to shove).
Generally, you are correct that having multiple libraries to choose among is concerning, but it really depends. Mostly it's stylistic choices and it can be hard to tell how it integrates before trying.
How do you get junior devs if your concept of the LLM is that it's "a principal engineer" that "do[es] not ask [you] any questions"?
Also, I'm pretty sure junior devs can use directing a LLM to learn from mistakes faster. Let them play. Soon enough they're going to be better than all of us anyway. The same way widespread access to strong chess computers raised the bar at chess clubs.
I don't think the chess analogy grabs here. In chess, you play _against_ the chess computer. Take the same approach and let the chess computer play FOR the player and see how far he gets.
Maybe. I don't think adversarial vs not is as important as gaining experience. Ultimately both are problem solving tasks and learning instincts about which approaches work best in certain situations.
I'm probably a pretty shitty developer by HN standards but I generally have to build a prototype to fully understand and explore problem and iterate designs and LLMs have been pretty good for me as trainers for learning things I'm not familiar with. I do have a certain skill set, but the non-domain stuff can be really slow and tedious work. I can recognize "good enough" and "clean" and I think the next generation can use that model very well to be become native with how to succeed with these tools.
Let me put it this way: people don't have to be hired by the best companies to gain experience using best practices anymore.
Yeah, it was confusing. I my circles the US one is known as "BP" and Canadian is "CBP". It makes more sense that they were talking about the Mexican border in retrospect given some other cues.
You must be misremembering, or maybe the your social circle mixed up the two by accident, which then became established. The Canadian border agency is never called CBP, because the actual name of the agency is CBSA. CBP always refers to the US agency.
reply