Live data from Hacker News

Show HN: Axe – A 12MB binary that replaces your AI framework

github.com

111–120 of 145 posts

Re: Show HN: Axe – A 12MB binary that replaces your AI framework

#111

I've had good success with something along these lines but perhaps a bit more raw: - claude takes a -p option - i have a bunch of tiny scripts, each script is an agent but it only does one tiny task - scripts can be composed in a unix pipeline For example: $ git diff --staged | ai-commit-msg | git commit -F - Where ai-commit-msg is a tiny agent: #!/usr/bin/env bash # ai-commit-msg: stdin=git diff, stdout=conventional…

Do you have examples of these commit messages? I have yet to see an AI write a good commit message. At least when compared to good commit messages -- if it just does better than "wip" or "fix stuff" that's not a high bar.

Re: Show HN: Axe – A 12MB binary that replaces your AI framework

#112
A problem i have is that the agent's mental model of the system im building diverges from reality over time. After discussing that many times and asking it to remember, it becomes frustrating. In the README you say the agents memory persists across runs, would that solve said problem?

Also, I had to do several refactorings of my agent's constructs and found out that one of them was reinventing stuff producing a plethora of function duplications: e.g. DB connection pools(i had at least four of them simultaneously).

Would AXE require shared state between chained agents? Could it do it if required?

Re: Show HN: Axe – A 12MB binary that replaces your AI framework

#113
I'm not sure if HN is being flooded with bots or if the majority of people here nowadays lack a sense of simplicity.

Anybody looking to do interesting things should instantly ignore any project that mention "persistent memory". It speaks of scope creep or complexity obfuscation.

If a tool wants to include "persistent memory" it needs to write the 3 sentence explanation of how their scratch/notes files are piped around and what it achieves.

Not just claim "persistent memory".

I might even go so far that any project using the terminology "memory" is itself doomed to spend too much time & tokens building scaffolding for abstractions that dont work.

Re: Show HN: Axe – A 12MB binary that replaces your AI framework

#114
This is exactly what I have wanted for a while, so thank you very much!

Disclaimer: I haven't dug into axe enough yet, just going on first impressions.

>No daemon, no GUI.

I love the world we developers live in right now. ;)

>What would you automate first?

In a sense, I have wanted to be able to just add AI to a repo, and treat it like the junior developer it is. Its okay if the junior developer will do literally any stupid thing I tell it to do, because I won't tell it to do stupid things.

So, exactly: refactor this code, implement a shim, produce docs for , construct a build harness, write unit tests, produce a build, diff these codebases, implement this API, do all this on your own branch, and build and test things so that I can review the PR over coffee.

Essentially, three word commands which will encourage the AI to produce better software. Through my repo, so I can just review through the repo.

Okay, that's how I hope things work, now off to actually dig in to axe and give it a try on a few things, thanks very much again ..

Re: Show HN: Axe – A 12MB binary that replaces your AI framework

#115

I'm not sure if HN is being flooded with bots or if the majority of people here nowadays lack a sense of simplicity. Anybody looking to do interesting things should instantly ignore any project that mention "persistent memory". It speaks of scope creep or complexity obfuscation. If a tool wants to include "persistent memory" it needs to write the 3 sentence explanation of how their scratch/notes files are piped aroun…

>scaffolding

The purpose of scaffolding is to create persistent memories.

>claim "persistent memory"

Just look at it as a build product.

>abstractions that don't work

Look at this as a testing problem.

Re: Show HN: Axe – A 12MB binary that replaces your AI framework

#117
I like the idea of LLM-calling as an automation-friendly CLI tool! However, putting all my agents in ~/.config feels antithetical to this. My Bash scripts do not live there either, but rather in a separate script collection, or preferably, at their place of use (e.g. in a repo).

For example, let's say I want to add commit message generation (which I don't think is a great use of LLMs, but it is a practical example) to a repo. I would add the appropriate hook to /.git, but I would also want the agent with its instructions to live inside the repo (perhaps in an `axe` or `agents` directory).

Can Axe load agents from the current folder? Or can that be added?

Re: Show HN: Axe – A 12MB binary that replaces your AI framework

#118
Nice approach treating LLM agents like Unix programs. The TOML config per agent is clean. I've been working on something in a similar vein for invoice processing — small focused agents that do one thing well. Curious how you handle retries when an upstream LLM provider has intermittent failures mid-pipeline?

Re: Show HN: Axe – A 12MB binary that replaces your AI framework

#120
post #106

> - Path-sandboxed file ops. Keeps agents locked to a working directory How is it supposed to work, if agent can simply run "cat" command instead of using skill for file read/write/etc?

chroot

you cant be serious

chroot is not a security tool and never has been

Post reply on HN