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

Tools: Code Is All You Need

lucumr.pocoo.org

Post reply on HN
Print view View original

171–180 of 234 posts

Re: Tools: Code Is All You Need

#171

Post by forrestthewoods »

nativeit wrote: post #167
forrestthewoods wrote: post #112

Earlier quoted context omitted.

> you'd be hard-pressed to find something more universal than a shell script. 99.9% of my 20-year career has been spent on Windows. So bash scripts are entirely worthless and dead to me.

What do you suppose the proportion is of computers actively running Windows in the world right now, versus those running some kind of *nix/BSD-based OS? This includes everything a person or machine could reasonably interface with, and that's Turing complete (in other words, a traffic light is limited to its own fixed logic, so it doesn't count; but most contemporary wifi routers contain general-purpose memory and pro…

I think if someone were, for example, to release an open source C++ library and it only compiles for Linux or only comes with Bash scripts then I would not consider that library to be crossplatform nor would I consider it to run everywhere.

I don’t think it’s “just semantics”. I think it’s a meaningful distinction.

Game dev is a perhaps a small niche of computer programming. I mean these days the majority of programming is webdev JavaScript, blech. But game dev is also overwhelmingly Windows based. So I dispute any claim that Unix is “everywhere”. And I’m regularly annoyed by people who falsely pretend it is.

Re: Tools: Code Is All You Need

#172

Post by skeeter2020 »

golergka wrote: post #160
foobarbecue wrote: post #29

Earlier quoted context omitted.

Hype cycle for drones and VR was similar -- at the peak, you have people claiming drones will take over package delivery and everyone will spend their day in VR. Reality is that the applicability is more narrow.

People claimed that we would spend most of our day on the internet in the mid-90s, and then the dotcom bubble burst. And then people claimed that by 2015 robo-taxis would be around all the major cities of the planet. You can be right but too early. There was a hype wave for drones and VR (more than one for the latter one), but I wouldn't be so sure that it's peak of their real world usage yet.

>> You can be right but too early.

Unless opportunity cost is zero this is a varation on being wrong.

Re: Tools: Code Is All You Need

#173

Post by SatvikBeri »

I use Julia at work, which benefits from long-running sessions, because it compiles functions the first time they run. So I wrote a very simple MCP that lets Claude Code send code to a persistent Julia kernel using Jupyter.

It had a much bigger impact than I expected – not only does test code run much faster (and not time out), but Claude seems to be much more willing to just run functions from our codebase rather than do a bunch of bespoke bash stuff to try and make something work. It's anecdotal, but CCUsage says my token usage has dropped nearly 50% since I wrote the server.

Of course, it didn't have to be MCP – I could have used some other method to get Claude to run code from my codebase more frequently. The broader point is that it's much easier to just add a useful function to my codebase than it is to write something bespoke for Claude.

Re: Tools: Code Is All You Need

#174

Post by skeeter2020 »

whiplash451 wrote: post #32
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.

Th author is not bearish on LLMs at all; this post is about using LLMs and code vs. LLMs with autonomous tools via MCP. An example from your set would be translation. The author says you'll get better results if you do something like ask an LLM to translate documents, review the proposed approach, ask it to review it's work and maybe ask another LLM to validate the results than if you say "you've got 10K documents in English, and these tools - I speak French"

Re: Tools: Code Is All You Need

#175

Post by hollerith »

nativeit wrote: post #165
hollerith wrote: post #116

Earlier quoted context omitted.

Mind share of the basic design. Unix's design decisions are important parts of MacOS and Linux. Multics would be an example of a more innovative OS than Unix, but its influence on the OSes we use today has been a lot less.

I suppose the deeper question I'd have would be, how would its no-cost distribution prevent better alternatives from being developed/promoted/adopted along the way? I guess I don't follow your line of logic. To be fair, I'm not experienced enough with either OS development nor any notable alternatives to Unix to agree/disagree with your conclusions. My intuition wants to disagree, only because I like Linux, and even…

Most OSes no longer have any users or squeak by with less than 1000 users on their best day ever: Plan 9, OS/2, Beos, AmigaOS, Symbian, PalmOS, the OS for the Apple II, CP/M, VMS, TOPS-10, Multics, Compatible Time-Sharing System, Burroughs Master Control Program, Univac's Exec 8, Dartmouth Time-Sharing System, etc.

Some of the events that help Unix survive longer than most are the decision of DARPA (in 1979 or the early 1980s IIRC) to fund the addition of a TCP/IP networking stack to Unix and the decision in 1983 of Richard Stallman to copy the Unix design for his GNU project. The reason DARPA and Stallman settled on Unix was that they knew about it and were somewhat familiar with it because it was given away for free (mostly to universities and research labs). Success tends to beget success in "spaces" with strong "network externalities" such as the OS space.

>Getting this back to the OG point

I agree that it is easy to avoid writing shell scripts. The problem is that other people write them, e.g., as the recommended way to install some package I want. The recommended way to install a Rust toolchain for example is to run a shell script (rustup). I trust the Rust maintainers not to intentionally put an attack in the script, but I don't trust them not to have inadvertently included a vulnerability in the script that some third party might be able to exploit (particularly since it is quite difficult to write an attack-resistant shell script).

Re: Tools: Code Is All You Need

#176

Post by skeeter2020 »

simonw wrote: post #25

Something I've realized about LLM tool use is that it means that if you can reduce a problem to something that can be solved by an LLM in a sandbox using tools in a loop, you can brute force that problem. The job then becomes identifying those problems and figuring out how to configure a sandbox for them, what tools to provide and how to define the success criteria for the model. That still takes significant skill an…

One of my biggest, ongoing challenges has been to get the LLM to use the tool(s) that are appropriate for the job. It feels like teach your kids to say, do laundry and you want to just tell them to step aside and let you do it.

Re: Tools: Code Is All You Need

#177

Post by nartho »

shepherdjerred wrote: post #170
vunderba wrote: post #115

Earlier quoted context omitted.

> The job then becomes identifying those problems and figuring out how to configure a sandbox for them, what tools to provide, and how to define the success criteria for the model. Your test case seems like a quintessential example where you're missing that last step. Since it is unlikely that you understand the math behind fractals or x86 assembly (apologies if I'm wrong on this), your only means for verifying the a…

Are fractals or x86 assembly representative of most dev work?

I think it's irrelevant. The point they are trying to make is anytime you ask a LLM for something that's outside of your area of expertise you have very little to no way to insure it is correct.

Re: Tools: Code Is All You Need

#178

Post by hollerith »

nativeit wrote: post #165
hollerith wrote: post #116

Earlier quoted context omitted.

Mind share of the basic design. Unix's design decisions are important parts of MacOS and Linux. Multics would be an example of a more innovative OS than Unix, but its influence on the OSes we use today has been a lot less.

I suppose the deeper question I'd have would be, how would its no-cost distribution prevent better alternatives from being developed/promoted/adopted along the way? I guess I don't follow your line of logic. To be fair, I'm not experienced enough with either OS development nor any notable alternatives to Unix to agree/disagree with your conclusions. My intuition wants to disagree, only because I like Linux, and even…

OK, consider the browser market: are there any browsers that cost money? If so, I've not heard of it. From the beginning, Netscape Corporation, Microsoft, Opera and Apple gave away their browsers for free. That is because by the early 1990s it was well understood (at least by Silicon Valley execs) that what is important is grabbing mind share, and charging any amount of money would severely curtain the ability to do that.

In the 1970s when Unix started being distributed outside of Bell Labs, tech company execs did not yet understand that. The owners of Unix adopted a superior strategy to ensure survival of Unix by accident (namely, by being sued -- IIRC in the 1950s -- by the US Justice Department on anti-trust grounds).

Re: Tools: Code Is All You Need

#179

Post by dingnuts »

basch wrote: post #68
dingnuts wrote: post #59

Earlier quoted context omitted.

Outside of tech circles it looks like NFTs: people following hype using tech they don't understand which will be popular until the downsides we're aware of that they are ignorant to have consequences, and then the market will reflect the shift in opinion.

No way. Everybody under a certain age is using ChatGPT, where they were once using search and friendship/expertises. It’s the number 1 app in the App Store. Copilot use in the enterprise is so seamless, you just talk to PowerPoint or outlook and it formulated what you were supposed to make or write. It’s not a fad, it is a paradigm change. People don’t need to understand how it works for it to work.

I know it's popular; that doesn't mean it's not a fad. Consequences take time. It's easy to use but once you get burned in a serious way by the bot that's still wrong 20% of the time, you'll become more reluctant to put your coin in the slot machine.

Maybe if the AI companies start offering refunds for wrong answers, then the price per token might not be such a scam.

Re: Tools: Code Is All You Need

#180

Post by zahlman »

arkmm wrote: post #150
pamelafox wrote: post #110

Regarding the Playwright example: I had the same experience this week attempting to build an agent first by using the Playwright MCP server, realizing it was slow, token-inefficient, and flaky, and rewriting with direct Playwright calls. MCP servers might be fun to get an idea for what's possible, and good for one-off mashups, but API calls are generally more efficient and stable, when you know what you want. Here's…

This is cool! Also have found the Playwright MCP implementation to be overkill and think of it more as a reference to an opinionated subset of the Playwright API. LinkedIn has this reputation of being notorious about making it hard to build automations on top of, did you run into any roadblocks when building your personal LinkedIn agent?

... Ah, reading these as well as more carefully reading TFA, I understand now that there is an MCP based on Playwright, and that Playwright itself is not considered an example of something that accidentally is an MCP despite having been released all the way back in January 2020.

... But now I still feel far away from understanding what MCP really is. As in:

* What specifically do I have to implement in order to create one?

* Now that the concept exists, what are the implications as the author of, say, a traditional REST API?

* Now that the concept exists, what new problems exist to solve?

Post reply on HN