Hacker News new | ask | show | jobs
by SwellJoe 69 days ago
Inventing a new thing "for agents" always feels counter-productive. Your new thing isn't in the training data, so you have to teach it how to use your thing. Why not use tech that's already in the training data? Agents know Python and Django. Or, better (because the performance, maintainability, and deployment story are much nicer with no extra work, since agents write the code), agents know Go.

The very nature of LLMs means you can't invent a thing for current agents to use that they'll be better at using than the things they already know how to use from their immense training data. You can give them skills, sure, and that's useful, but it's still not their native tongue.

To make a thing that's really for agents, you need to have made a popular thing for humans ten years ago, so there's a shitload of code and documentation for them to train on.

3 comments

this was true a year ago, but if you give an agent a new spec to follow (e.g. a .md file), it will follow it.

we have a custom .yaml spec for data pipelines in our product and the agent follows it as well as anything in the training data.

while I agree you don't need to build a new thing "for agents", you can get them to understand new things, that are not in the training data, very easily.

Just because they can doesn't mean inventing a new framework "for agents" is going to be superior to letting agents use what's in their training data. I suspect it'll be worse, but the time/resources needed to prove that is beyond what I'd be willing to invest.

What makes something like this "for agents", anyway? It's opinionated...a human's opinions, I assume, since agents don't want anything and thus can't have opinions. But, many existing tools are opinionated. Types are good for agents, because it keeps them honest, but many existing things in this space have types. Python is good for agents, because there's a shitload of Python code and documentation in their training data, but many existing things are built with Python (and TypeScript, Go, and Rust are also typed languages and well-represented in the training data).

I dunno. I think a lot of folks are sitting around with an agent thinking, what can I build? And, a lot of things "for agents" are being built, as a result. I think most of them don't need to be built and don't improve software development with agents. They often just chew up context and cache with extra arbitrary rules the agent needs to follow without delivering improvements.

> we have a custom .yaml spec for data pipelines in our product and the agent follows it as well as anything in the training data.

Doesn't this end up being way more expensive, because you don't pay for model parameter activations but for the tokens in/out, meaning that anything not in the training data (and therefore, the model) will cost you. I could make Opus use a new language I came up with if I wanted to and it'd do an okay job with enough information... but it'd be more expensive and wasteful than just telling it to write the same algorithms in Python, and possibly a bit more error prone. Same with frameworks and libraries.

This makes sense, but it also causes concern. With AI whether it is content or programming, losing the new novel approaches which may wind up being better in the long run, get shut down for expediency in the short run. This is nothing new and not AI specific behavior, large comoanies have been doing this forever, but it leads to a death of innovation and a spiral inward of self reinforcing loops. You are absolutely right that llms won’t know it and will need to learn something like this all over, but they are good at that and if we stop to find better patterns (which is what humans are great at doing) we keep creativity alive and find meaning while making our work more productive in the long term.
That's a different conversation than the one I'm having. I haven't made any argument against making new things.

I'm saying "Django, but different" isn't for agents. It makes agents work harder, in general.

Make anything you want. Just don't lie to yourself and others about who it's for.

Yeah this is just wrong.

The whole point of AI is that it can generalise to stuff outside its training set, and anyone who uses Claude on a daily basis completes tasks that have not already been completed elsewhere.

These models excel at tool use. They’re using CRMs, word processors and dozens of other systems that weren’t programmable before - lots of tools have opened MCP/API/CLI interfaces for the first time specifically to support AI, and it works.

I don’t know where this meme comes from, but we haven’t “invented the last language” and we’re not going to be frozen in 2023 for tooling, any more than the Industrial Revolution led to automation of artisan workshops rather than the invention of the modern factory system.

That's not what I'm saying. I'm saying that if you make "Django, but different" it isn't for agents.

Django, but different is not a "tool use" situation. It is a framework with a ton of conventions and libs, etc. Agents will be better able to write Django than "Django, but different". Will they work with your new libraries? Of course. They're very good at all sorts of coding tasks, and they can read docs, search the web, experiment, and correct themselves in an agentic context even absent any relevant training data. But, what may have been a one-shot with Django code, might require several tries with your new thing.

That is not an argument against making new things. I'm not make any argument against making new things, anywhere in this thread. My argument is that if you make "Django, but different", it isn't "for agents", because agents already know Django and they know your new thing considerably less. Your new thing is more work for the agent.

My comment is about being honest with yourself and others about what you're building and for whom.

Read the about page (https://plainframework.com/about/).

This Show HN post doesn't seem to be by the author and it's not presenting the project in a good way in my opinion. I also don't like the agent framing of the project home page, but after reading the about, I'm willing to tone down my criticism.

The framework seems like an interesting project to keep an eye on.