HI version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
76% Positive
Analyzed from 2403 words in the discussion.
Trending Topics
#llm#code#script#agent#scripts#tools#more#example#claude#tool

Discussion (63 Comments)Read Original on HackerNews
Ie instead of
"hey agent, use the api to get X, then do unpredictable mutation Y to it, and email it to me",
it should be;
"Scheduled task runs code to get X then place it in workspace. Task then starts agent in workspace and is prompted to do mutation Y to it. Post-flight code then sends final product."
The difference here being that the pre/post flight stuff is called deterministically, rather than called by an llm.
It ~can~ be done using standard bash utils but there just isn't a kind of standard pattern for 'move this text block via CLI tools' so the LLM and human both overlook it
Dedicated Infrastructure > automation > ad hoc scripts > non deterministic llms from a dependability perspective alone. Using an LLM to do something that prettier could have done is analogous to using a 3d printer to nail up a fence.
The tooling can remain generic and token spending focused.
The basics of computer engineering is now novel approaches. We are discovering why programming languages exist, starting with a worst version of Cobal running on a very expensive and probabilistic VM.
We will shoehorn every square, rectangular, and all forms of peg through the AI hole.
Drew McDermott, 1976, "Artificial Intelligence Meets Natural Stupidity": https://dl.acm.org/doi/10.1145/1045339.1045340
Note that 1976 had some cool AI, including theorem-provers and story-tellers (Knuth wrote a story-telling program, I think it's an exercise in TAoCP). Yet the underlying theory of intelligence was "intelligence is logical processing of symbolic information"; this is obviously inadequate, but the ideology of analytic philosophy is a helluva drug for a scientist. Likewise with the 21st century "intelligence is about correctly predicting things based on past information,"; this is obviously inadequate, but the ideology of big data technocracy is a helluva drug for a scientist.There's clearly a paradox that happens when people have to face things they treat as essentially magic because the magic has wiped away the pain and suffering that borne them. So too will be another age when people have to relearn everything the LLMs do for us.
> The one-line takeaway
> This already ships by default in every claude/codex/opencode session's system prompt
Use a LLM to summarize it.
GIGO?
It’s very useful and I use it all the time, and in the end you can distill it into a reusable toolbox, somewhat similar to a collection of markdown files with project knowledge.
We have a visual designer and for LLMs to interact with it we originally built a tool per manipulation operation type (e.g. add, edit, delete item - for various item types).
We actually already had a JavaScript API with corresponding .d.ts file for scripting inside our product and one of our clients asked that we also expose this as an MCP tool. I figured sure, should be quite quick and easy, and with Claude Code's help I managed to do it in a single afternoon.
We then found that the LLMs way preferred reaching for this tool, managing with it to get their tasks done with fewer mistakes along the way and in much smaller time frames.
After seeing this and doing some more validation (I've also read that Cloudflare article), we ditched the other tools completely and made a cheat sheet for the LLMs on how to use our API.
Because our API returns decent error messages including stack traces, even if the script fails the LLMs have no trouble making another script to fix their mistake and carrying on from where the error occurred.
In hindsight it really was hardly surprising as LLMs are already aiming to be as good as possible at coding and with JS being so popular I imagine it's particularly good at it.
we did some iterations specially on the typing and error messages, as you mentioned, that help a lot in the reliability
For example in my Liveclip MCP server I'm working on (not released yet) I have table manipulation type tools
So for example a couple days ago Claude made a combined ranking score for my Youtube Shorts analytics -- it did all these tool calls in the same turn
First it normalized the % values into numbers
{ "destination_col": "G", "key": "cinemasleepstories_temp_2026071702", "pattern": "%", "replacement": "", "source": { "col": "E", "row_start": 1, "row_end": 6 } }
Then it made the composite score
{ "dest_col_start": "H", "dest_row_end": 6, "dest_row_start": 1, "expr": "round((likes+1)(followers+1)stayed, 1)", "source_key": "cinemasleepstories_temp_2026071702", "sources": [ { "col": "C", "name": "likes", "row_offset": 0 }, { "col": "D", "name": "followers", "row_offset": 0 }, { "col": "G", "name": "stayed", "row_offset": 0 } ] }
And then it set the new headers
{ "headers": { "G": "Stayed (numeric)", "H": "Composite Score" }, "key": "cinemasleepstories_temp_2026071702" }
If Claude just said "let me write some pandas against this CSV" the workflow would be a lot more iffy and generally uncomfortable/ephemeral
That's obviously a part of the broader picture Claude always runs inside bwrap sandbox, any work involving python/nodejs must happen in the dedicated devcontainer, standard operations are reused via Makefile, Ai can use dedicated account in the developed $thing for testing in live, hooks governing tool calling are brutal, but it works.
For me at least.
I think OP’s example is bad. As that (if I understand the example correctly as I don’t really know what liveclip is) sounds like something worth generating a script for once and reusing it. However, if you’re looking to book a flight, you would prefer an airline cli or mcp server or a nodejs script using puppeteer to automate the browser or even some airline sdk to buy a ticket?
What doesn’t make sense is generating a script to achieve a task without clear feedback loop for verifying the script correctness. In OPs example, there is no way for the LLM to very the correct final result since it’s unknown. It can “code review” the code looking for bugs, but bugs in scripts happen.
Also not exec happens in a sandboxed env, which means it might not have access to the fs by default (it has to agent-fs, which is a layer we built on top of s3 for agents)
But I believe it's not that common as it seems, only one actually trying to push this is executor.sh for example
it's really hard to measure some times. for example, once of the things we have seen is that the specific `workflow-triage` schedule we have have been running much faster and cheaper since we moved some parts of it to use scripts. From our analytics we saw times from ~5min before to ~1 or 2 min now. And in terms of costs we saw +50% reduction.
Why not 90%? because even if it uses the script, that's the "repeatable" part. we still have a reasoning around the output of it, and then deciding how to escalate, which removes the 40% reduction. Still 50% is nice for something we run daily.
so if i were to tell an agent to move the contents of a confluence doc into a file, it would do so without even reading the confluence page - in theory.
Now our idea is to offer this to be harness agnostic (we support codex, claude code, pi, opencode, even devin). And you (as the one deploying AI systems) should be in control of the AI, the execution and the data. That's our goal
We've been building https://github.com/desplega-ai/agent-swarm in the open for a while, and one of the things we wanted to do since the start is find how powerful it can be to push for a code mode like env for the swarm.
We tried it and we managed to reduce up +90% of token costs by using swarm scripts (the code mode variant we implemented) for some of our schedules.
This is game changer, as we are able to
1. Run those schedules faster 2. Cheaper 3. More reliably
Been thinking a lot now on how we should prompt and change the default templates to force the agents to build on top of this. If it can be re-used or it's a recurring thing -> scripts.
Thoughts? Have you seen this type of improvements in your setups?
Cheers,
Any recommendations on how I could make it better next time, so you do not feel like wasting your time (which I get and feel, dont get me wrong!)
I wish there was a way to tag this type of the posts, but at least my HN client allows to tag the authors.
But the LLM that wrote your blog post says your system was already doing this and you just hadn't measured it...? How is it that you managed a reduction in token costs by changing nothing?
And can you provide a human-written explanation of the experimental methodology that gets you this miraculous, literally unbelievable 99.2% reduction in tokens?
Indeed we had the concept of workflows from the start (like n8n), but the point of the scripts is type safe executions that the agents can write, with access to APIs, MCPs, etc.
E.g. this PR from ~10 days ago https://github.com/desplega-ai/agent-swarm/pull/934 was going in this direction, offering a way to defined type safe connections to able to use more the scripts instead of adding MCPs or tools.
e.g. offering a way to do `ctx.api.gmail.searchEmail` coming from an OpenAPI spec.
The whole point of this blog is the "dumb" realisation of the following:
If you have an agent (say Claude Tag, or some other fancy Slack bot) that you keep asking the same things (e.g. check DataDog error and correlate PRs on a timeframe) and the agent does that process agentically, you are wasting tokens.
Now, if you give a way for the agents to write these scripts (code mode) the next time a task like that happens then essentially you just run that and you get easily 90% cost reduction in THAT process. Not globally, obviously.
in fact we are thinking a lot about this, not on a toll based, but rather on a role based.
giving access to specific tools to specific agents, how that works and evolves, and how that links w the humans using it
The tech here is cool; good reminder to push for more scripts in general from the agentic tools.