Tools: Code Is All You Need • Hacker News Board

Re: Tools: Code Is All You Need

#31

Post by forrestthewoods » Thu, Jul 03, 2025, 2:35 PM UTC

Unpopular Opinion: I hate Bash. Hate it. And hate the ecosystem of Unix CLIs that are from the 80s and have the most obtuse, inscrutable APIs ever designed. Also this ecosystem doesn’t work on Windows — which, as a game dev, is my primary environment. And no, WSL does not count.

I don’t think the world needs yet another shell scripting language. They’re all pretty mediocre at best. But maybe this is an opportunity to do something interesting.

Python environment is a clusterfuck. Which UV is rapidly bringing into something somewhat sane. Python isn’t the ultimate language. But I’d definitely be more interested in “replace yourself with a UV Python script” over “replace yourself with a shell script”. Would be nice to see use this as an opportunity to do better than Bash.

I realize this is unpopular. But unpopular doesn’t mean wrong.

Re: Tools: Code Is All You Need

#32

Post by whiplash451 » Thu, Jul 03, 2025, 2:36 PM UTC

pclowes wrote: post #5

Directionally I think this is right. Most LLM usage at scale tends to be filling the gaps between two hardened interfaces. The reliability comes not from the LLM inference and generation but the interfaces themselves only allowing certain configuration to work with them. LLM output is often coerced back into something more deterministic such as types, or DB primary keys. The value of the LLM is determined by how well…

Interesting take but too bearish on LLMs in my opinion.

LLMs have already found large-scale usage (deep research, translation) which makes them more ubiquitous today than 3D printers ever will or could have been.

Re: Tools: Code Is All You Need

#33

Post by bitwize » Thu, Jul 03, 2025, 2:37 PM UTC

graerg wrote: post #6

> This is a significant advantage that an MCP (Multi-Component Pipeline) typically cannot offer Oh god please no, we must stop this initialism. We've gone too far.

We're all in line to get de-rezzed by the MCP, one way or another.

Re: Tools: Code Is All You Need

#34

Post by light_hue_1 » Thu, Jul 03, 2025, 2:39 PM UTC

victorbjorklund wrote: post #30

I think the GitHub CLI example isn't entirely fair to MCP. Yes, GitHub's CLI is extensively documented online, so of course LLMs will excel at generating code for well-known tools. But MCP shines in different scenarios. Consider internal company tools or niche APIs with minimal online documentation. Sure, you could dump all the documentation into context for code generation, but that often requires more context than…

That's handled by the MCP server in the sense of it doesn't do authentication, etc. it provides a simplified view of the world.

If that's what you wanted you could have designed that as your poorly documented internal API differently to begin with. There's zero advantage to MCP in the scenario you describe aside from convincing people that their original API is too hard to use.

Re: Tools: Code Is All You Need

#35

Post by lsaferite » Thu, Jul 03, 2025, 2:40 PM UTC

gbrindisi wrote: post #7

lsaferite wrote: post #4

Earlier quoted context omitted.

Just as a related aside, you could literally make that bottom section into a super simple stdio MCP Server and attach that to Claude Code. Each of your operations could be a tool and have a well-defined schema for parameters. Then you are giving the LLM a more structured and defined way to access your custom commands. I'm pretty positive there are even pre-made MCP Servers that are designed for just this activity. Ed…

wouldn't this defeat the point? Claude Code already has access to the terminal, adding specific instruction in the context is enough

No. You are giving textual instructions to Claude in the hopes that it correctly generates a shell command for you vs giving it a tool definition with a clearly defined schema for parameters and your MCP Server is, presumably, enforcing adherence to those parameters BEFORE it hits your shell. You would be helping Claude in this case as you're giving a clearer set of constraints on operation.

Re: Tools: Code Is All You Need

#36

Post by the_mitsuhiko » Thu, Jul 03, 2025, 2:41 PM UTC

victorbjorklund wrote: post #30

I think the GitHub CLI example isn't entirely fair to MCP. Yes, GitHub's CLI is extensively documented online, so of course LLMs will excel at generating code for well-known tools. But MCP shines in different scenarios. Consider internal company tools or niche APIs with minimal online documentation. Sure, you could dump all the documentation into context for code generation, but that often requires more context than…

> Sure, you could dump all the documentation into context for code generation, but that often requires more context than interacting with an MCP tool.

MCP works exactly that way: you dump documentation into the context. That's how the LLM knows how to call your tool. Even for custom stuff I noticed that giving the LLM things to work with that it knows (eg: python, javascript, bash) beats it using MCP tool calling, and in some ways it wastes less context.

YMMV, but I found the limit of tools available to be <15 with sonnet4. That's a super low amount. Basically the official playwright MCP alone is enough to fully exhaust your available tool space.

Re: Tools: Code Is All You Need

#37

Post by recursivedoubts » Thu, Jul 03, 2025, 2:41 PM UTC

I would like to see MPC integrate the notion of hypermedia controls.

Seems like that would be a potential way to get self-organizing integrations.

Re: Tools: Code Is All You Need

#38

Post by the_mitsuhiko » Thu, Jul 03, 2025, 2:42 PM UTC

apgwoz wrote: post #23

the_mitsuhiko wrote: post #15

Earlier quoted context omitted.

It's the wrong acronym. I wrote this blog post on the bike and used an LLM to fix up the dictation that I did. While I did edit it heavily and rewrote a lot of things, I did not end up noticing that my LLM expanded MCP incorrectly. It's Model Context Protocol.

And you shipped it to production. Just like real agentic coding! Nice!

Which I don't feel great about because I do not like to use LLMs for writing blog posts. I just really wanted to explore if I can write a blog post on my bike commute :)

Re: Tools: Code Is All You Need

#39

Post by lreeves » Thu, Jul 03, 2025, 2:43 PM UTC

jayd16 wrote: post #27

mritchie712 wrote: post #2

> try completing a GitHub task with the GitHub MCP, then repeat it with the gh CLI tool. You'll almost certainly find the latter uses context far more efficiently and you get to your intended results quicker. This is spot on. I have a "devops" folder with a CLAUDE.md with bash commands for common tasks (e.g. find prod / staging logs with this integration ID). When I complete a novel task (e.g. count all the rows that…

I feel like I'm taking crazy pills sometimes. You have a file with a set of snippets and you prefer to ask the AI to hopefully run them instead of just running it yourself?

The commands aren't the special sauce, it's the analytical capabilities of the LLM to view the outputs of all those commands and correlate data or whatever. You could accomplish the same by prefilling a gigantic context window with all the logs but when the commands are presented ahead of time the LLM can "decide" which one to run based on what it needs to do.

Re: Tools: Code Is All You Need

#40

Post by vasusen » Thu, Jul 03, 2025, 2:44 PM UTC

I think the Playwright MCP is a really good example of the overall problem that the author brings up.

However, I couldn’t really understand if he’s saying that the Playwright MCP is good to use for your own app or whether he means for your own app just tell the LLM directly to export Playwright code.