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

You should write an agent

fly.io

Post reply on HN
Print view View original

391–400 of 409 posts

Re: You should write an agent

#391

Post by nativeit »

keyle wrote: post #215
dave1010uk wrote: post #80

Two years ago I wrote an agent in 25 lines of PHP [0]. It was surprisingly effective, even back then before tool calling was a thing and you had to coax the LLM into returning structured output. I think it even worked with GPT-3.5 for trivial things. In my mind LLMs are just UNIX strong manipulation tools like `sed` or `awk`: you give them an input and command and they give you an output. This is especially true if y…

> a small Autobot that you can't trust That gave me a hearty chuckle!

I let it watch my kids. Was that a mistake?

/s

Re: You should write an agent

#392

Post by nativeit »

recursive wrote: post #359
criddell wrote: post #354

Earlier quoted context omitted.

> Personally I’d absolutely buy an LLM in a box In a box? I want one in a unit with arms and legs and cameras and microphones so I can have it do useful things for me around my home.

You're an optimist I see. I wouldn't allow that in my house until I have some kind of strong and comprehensible evidence that it won't murder me in my sleep.

Well, first we let it get a hamster, and we see how that goes. Then we can talk about letting the Agentic AI get a puppy.

Re: You should write an agent

#393

Post by mattmanser »

simplesagar wrote: post #61
vidarh wrote: post #37

Earlier quoted context omitted.

I'd second the article on this, but also add to it that the biggest reason MCP servers don't really matter much any more is that the models are so capable of working with APIs , that most of the time you can just point them at an API and give them a spec instead. And the times that doesn't work, just give them a CLI tool with a good --help option . Now you have a CLI tool you can use yourself, and the agent has a too…

I feel the CLI vs MCP debate is an apples to oranges framing. When you're using claude you can watch it using CLI's, running brew, mise, lots of jq but what about when you've built an agent that needs to work through a complicated API? You don't want to make 5 CRUD calls to get the right answer. A curated MCP tool ensures it can determinism where it matters most.. when interacting with customer data

Sounds more like a problem with your APIs trying to follow some REST 'purity' rather than be usable.

Re: You should write an agent

#394

Post by AceJohnny2 »

tptacek wrote: post #382
AceJohnny2 wrote: post #149

Earlier quoted context omitted.

Worth highlighting that both OP article and the one Simon linked are by @tptacek, who is also one of the top commenters here on HN. His fly.io posts are very much in his style. I figure they let him post there, without corp-washing, because any publicity is good publicity.

This is the corp-washed version of this post.

can I have access to the corp-unwashed version

Re: You should write an agent

#395

Post by theshrike79 »

hoppp wrote: post #122
johnfn wrote: post #116

Earlier quoted context omitted.

The post is just about playing around with the tech for fun. Why does monetization come into it? It feels like saying you don't want to use Python because Astral, the company that makes uv, is operating at a loss. What?

Agents use Apis that I will need to pay for and generally software dev is a job for me that needs to generate income. If the Apis I call are not profitable for the provider then they won't be for me either. This post is a fly.io advertisement

I have an "agent" that posts our family schedule + weather + other relevant stuff to our shared channel.

It costs like 0.000025€ per day to run. Hardly something I need to get "profitable".

I could run it on a local model, but GPT-5 is stupidly good at it so the cost is well worth it.

Re: You should write an agent

#396

Post by nitwit005 »

> You only think you understand how a bicycle works, until you learn to ride one.

I realize this is just for motivation in a subtitle, but people generally don't grasp how bicycles work, even after having ridden one.

Veritasium has a quite good video on the subject: https://www.youtube.com/watch?v=9cNmUNHSBac

Re: You should write an agent

#397

Post by vinhnx »

simonw wrote: post #372
losvedir wrote: post #363

I appreciate the goal of demystifying agents by writing one yourself, but for me the key part is still a little obscured by using OpenAI APIs in the examples. A lot of the magic has to do with tool calls, which the API helpfully wraps for you, with a format for defining tools and parsed responses helpfully telling you the tools it wants to call. I kind of am missing the bridge between that, and the fundamental knowle…

Yeah, that's basically it. Many models these days are specifically trained for tool calling though so the system prompt doesn't need to spend much effort reminding them how to do it. You can see the prompts that make this work for gpt-oss in the chat template in their Hugging Face repo: https://huggingface.co/openai/gpt-oss-120b/blob/main/chat_te... - including this bit: {%- macro render_tool_namespace(namespace_name…

Thank you Simon! This information is invaluable to know about the underlying tools coherent of language model, gladly we have gpt-oss for clear example for how the model understand and perform tool.

Re: You should write an agent

#398

Post by tinodb »

riskable wrote: post #11

It's interesting how much this makes you want to write Unix-style tools that do one thing and only one thing really well. Not just because it makes coding an agent simpler, but because it's much more secure!

Indeed. I have a tiny wrapper around the llm cli that gives it 3 tools: read these docs for program X, read its config and search-replace in said config. I use it for adopting Ghostty for example. I can now ask it: “how do I switch between window panes?” Then: “change that shortcut to …”

Re: You should write an agent

#399

Post by anonym29 »

DeathArrow wrote: post #258
anonym29 wrote: post #64

Earlier quoted context omitted.

Cerebras now has glm 4.6. Still obscenely fast, and now obscenely smart, too.

Aren't there cheaper providers of GLM 4.6 on Openrouter? What are the advantages of using Cerebras? Is it much faster?

Cerebras offers a $50/mo and $200/mo "Cerebras Code" subscription for token limits way above what you could get for the same price in PAYG API credits. https://www.cerebras.ai/code

Up until recently, this plan only offered Qwen3-Coder-480B, which was decent for the price and speed you got tokens at, but doesn't hold a candle to GLM 4.6.

So while they're not the cheapest PAYG GLM 4.6 provider, they are the fastest, and if you make heavy use their monthly subscription plan, then they're also the cheapest per token.

Note: I am neither affiliated with nor sponsored by Cerebras, I'm just a huge nerd who loves their commercial offerings so much that I can't help but gush about them.

Re: You should write an agent

#400

Post by saghm »

dave1010uk wrote: post #80

Two years ago I wrote an agent in 25 lines of PHP [0]. It was surprisingly effective, even back then before tool calling was a thing and you had to coax the LLM into returning structured output. I think it even worked with GPT-3.5 for trivial things. In my mind LLMs are just UNIX strong manipulation tools like `sed` or `awk`: you give them an input and command and they give you an output. This is especially true if y…

The obvious difference between UNIX tools and LLMs is the non-determinism. You can't necessarily reason about what the output will be, and then continue to pipe into another LLM, etc., and eventually `eval` the result. From a technical perspective you can deal do this, but the hard part seems like it would be how to make sure it doesn't do something you really don't want it to do. I'd imagine that any potential deviations from your expectations in a given stage would be compounded as you continue to pipe along into additional stages that might have similar deviations.

I'm not saying it's not worth doing, considering how the software development process we've already been using as an industry ends up with a lot of bugs in our code. (When talking about this with people who aren't technical, I sometimes like to say that the reason software has bugs in it is that we don't really have a good process for writing software without bugs at any significant scale, and it turns out that software is useful for enough stuff that we still write it knowing this). I do think I'd be pretty concerned with how I could model constraints in this type of workflow though. Right now, my fairly naive sense is that we've already moved the needle so far on how much easier it is to create new code than review it and notice bugs (despite starting from a place where it already was tilted in favor of creation over review) that I'm not convinced being able to create it even more efficiently and powerfully is something I'd find useful.

Post reply on HN