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

151–160 of 234 posts

Re: Tools: Code Is All You Need

#151

Post by threatofrain »

sarchertech wrote: post #148
threatofrain wrote: post #102

Earlier quoted context omitted.

Good drones are very Chinese atm, as is casual consumer drone delivery. Americans might be more than a decade away even with concerted bipartisan war-like effort to boost domestic drone competency. The reality is Chinese.

Aren’t people building DIY drones that are close to and in some cases superior to off the shelf Chinese drones?

Off the shelf Chinese drones is somewhat vague, we can just say DJI. Their full drone and dock system for the previous generation goes for around $20k. DJI iterates on this space on a yearly cadence and have just come out with the Dock 3.

54 minute flight time (47 min hover) for fully unmanned operations.

If you're talking about fpv racing where tiny drones fly around 140+ mph, then yeah DJI isn't in that space.

Re: Tools: Code Is All You Need

#152

Post by the_mitsuhiko »

JyB wrote: post #117
the_mitsuhiko wrote: post #36

Earlier quoted context omitted.

> 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, an…

Ive never used that many. The LLM performances collapse/degrade significantly because of too much initial context? It seems like MCP implems updates could easily solve that. Like only injecting relevant servers for the given task based on initial user prompt.

> Ive never used that many.

The playwright MCP alone introduces 25 tools into the context :(

Re: Tools: Code Is All You Need

#153

Post by qazxcvbnmlp »

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?

You dont ask the ai to run the commands. you say "build and test this feature" and then the AI correctly iterates back and forth between the build and test commands until the thing works.

Re: Tools: Code Is All You Need

#154

Post by simonw »

vunderba wrote: post #115
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…

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

That's exactly why I like using Mandelbrot as a demo: it's perfect for "superficial visual inspection".

With a bunch more work I could likely have got a vision LLM to do that visual inspection for me in the assembly example, but having a human in the loop for that was much more productive.

Re: Tools: Code Is All You Need

#155

Post by 65 »

soulofmischief wrote: post #82
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.

That's the claim for AR, not VR, and you're just noticing how research and development cycles play out, you can draw comparisons to literally any technology cycle.

That is in fact the claim for VR. Remember the Metaverse? Oculus headsets are VR headsets. The Apple Vision Pro is a VR headset.

Re: Tools: Code Is All You Need

#156

Post by sarchertech »

threatofrain wrote: post #151
sarchertech wrote: post #148

Earlier quoted context omitted.

Aren’t people building DIY drones that are close to and in some cases superior to off the shelf Chinese drones?

Off the shelf Chinese drones is somewhat vague, we can just say DJI. Their full drone and dock system for the previous generation goes for around $20k. DJI iterates on this space on a yearly cadence and have just come out with the Dock 3. 54 minute flight time (47 min hover) for fully unmanned operations. If you're talking about fpv racing where tiny drones fly around 140+ mph, then yeah DJI isn't in that space.

That hardly seems like it would take the US 10 years to replicate on a war footing aside from the price.

I mean if we’re talking dollar to dollar comparison, the US will likely never be able to produce something as cheaply as China (unless China drastically increases their average standard of living).

Re: Tools: Code Is All You Need

#157

Post by forrestthewoods »

osigurdson wrote: post #146
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.

If you use git on Windows, bash is normally available. Agree, that this isn't widely used though.

Yeah I’ve never see anyone rely on users to use GitBash to run shell scripts.

Amusingly although I certainly use GitHub for hobby projects I’ve never actually used it for work. And have never come across a Windows project that mandated its use. Well, maybe one or two over the years.

Re: Tools: Code Is All You Need

#158

Post by e12e »

simonw wrote: post #74
nico wrote: post #73

Earlier quoted context omitted.

> LLM in a sandbox using tools in a loop, you can brute force that problem Does this require using big models through their APIs and spending a lot of tokens? Or can this be done either with local models (probably very slow), or with subscriptions like Claude Code with Pro (without hitting the rate/usage limits)? I saw the Mandelbrot experiment, it was very cool, but still a rather small project, not really comparabl…

The local models aren't quite good enough for this yet in my experience - the big hosted models (o3, Gemini 2.5, Claude 4) only just crossed the capability threshold for this to start working well. I think it's possible we'll see a local model that can do this well within the next few months though - it needs good tool calling, not an encyclopedic knowledge of the world. Might be possible to fit that in a model that…

I wonder if common lisp with repl and debugger could provide a better tool than your example with nasm wrapped via apt in Docker...

Essentially just giving LLMs more state of the art systems made for incremental development?

Ed: looks like that sort of exists: https://github.com/bhauman/clojure-mcp

(Would also be interesting if one could have a few LLMs working together on red/green TDD approach - have an orchestrator that parse requirements, and dispatch a red goblin to write a failing test; a green goblin that writes code until the test pass; and then some kind of hobgoblin to refactor code, keeping test(s) green - working with the orchestrator to "accept" a given feature as done and move on to the next...

With any luck the resulting code might be a bit more transparent (stricter form) than other LLM code)?

Re: Tools: Code Is All You Need

#160

Post by golergka »

foobarbecue wrote: post #29
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…

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.

Post reply on HN