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

The Code-Only Agent

rijnard.com

Post reply on HN
Print view View original

61–70 of 73 posts

Re: The Code-Only Agent

#61

Post by frumplestlatz »

iepathos wrote: post #53

The "code witness" concept falls apart under scrutiny. In practice, the agent isn't replacing ripgrep with pure Python, it's generating a Python wrapper that calls ripgrep via subprocess. So you get: - Extra tokens to generate the wrapper - New failure modes (encoding issues, exit code handling, stderr bugs) - The same underlying tool call anyway - No stronger guarantees - actually weaker ones, since you're now trust…

> In practice, the agent isn't replacing ripgrep with pure Python, it's generating a Python wrapper that calls ripgrep via subprocess.

Yep. I have very strong guardrails on what commands agents can execute, but I also have a "vterm" MCP server that the agent uses to test the TUI I'm developing in a real terminal emulator; it can send events, take screenshots, etc.

More than once it's worked around bash tool limitations by using the vterm MCP server to exit the TUI app under development and start issuing unrestricted bash commands. I'm probably going to add command filtering on what can be run under vterm (so it can't exit back to an initial shell), which will help unless/until I add a "!" style command to my TUI, in which case I'm sure it'll find and exploit that instead.

Re: The Code-Only Agent

#62

Post by znnajdla »

jebarker wrote: post #58

I don't really buy into the setup here. Bash is Turing complete. How is calling os.walk in Python more "code-only" than calling find in bash? Would it be more authentically "code only" if you only let the LLM use C?

Because the process is reproducible. A series of bash commands are run as tools and forgotten, it’s hard to replicate that for future testing and verification. If the LLM generates a single bash script then that would be code-only.

Re: The Code-Only Agent

#63

Post by znnajdla »

killerstorm wrote: post #50

I don't believe this would be more efficient. Use of common tools like `ls` and file patching is already baked into model's weights, it can do that with minimal amount of effort, leaving more room for actually thinking about app's code. If you force it to wrap these actions into non-standard tools you're basically distracting the model: it has to think about app-code and tool-code in the same context. In some cases i…

It doesn’t matter if it’s less efficient, what matters is that it has more chances to verify and get it right. It’s hard to rollback a series of tool calls. It’s easier to revert state and rerun a complete piece of code until you get the desired result.

Re: The Code-Only Agent

#64

Post by znnajdla »

ray_v wrote: post #15

Uh, correct me if I'm wrong, but aren't bash and GNU tools ALSO code? They're ROCK SOLID, battle tested, well understood APIs for performimg actions, including running other CLIs, and any OTHER code it's written. It makes the the MOST sense for the agent to live at that level!

I think the point is being able revert to the initial state, and to have a single step between the initial state and final state. It’s hard to rollback a series of tool calls, and your search for a solution continues at every step. With a “code only” agent, the goal is to get to the final state in a single step, and you can keep reverting state and modifying the code until you get there. You can’t do that with a series of tool calls.

Re: The Code-Only Agent

#66

Post by trackspike »

binalpatel wrote: post #2

I went down (continue to do down) this rabbit hole and agree with the author. I tried a few different ideas and the most stable/useful so far has been giving the agent a single run_bash tool, explicitly prompting it to create and improve composable CLIs, and injecting knowledge about these CLIs back into it's system prompt (similar to have agent skills work). This leads to really cool pattens like: 1. User asks for s…

Hey that sounds a lot like the project I’m working on, with the twist that it’s containerized. It’s still in dev https://github.com/brycewcole/capsule-agents

Re: The Code-Only Agent

#67

Post by craigds »

ashrodan wrote: post #23

Nice I have a skill I should publish that uses uv scripts Very powerful strategy. I have also tinkered with a multi language sandbox but that's a but involved

uv script skill sounds useful, please do publish that

Re: The Code-Only Agent

#68

Post by actionfromafar »

fudged71 wrote: post #26
binalpatel wrote: post #2

I went down (continue to do down) this rabbit hole and agree with the author. I tried a few different ideas and the most stable/useful so far has been giving the agent a single run_bash tool, explicitly prompting it to create and improve composable CLIs, and injecting knowledge about these CLIs back into it's system prompt (similar to have agent skills work). This leads to really cool pattens like: 1. User asks for s…

I've been on a similar path. Will have 1000 skills by the end of this week arranged in an evolving DAG. I'm loving the bottoms-up emergence of composable use cases. It's really getting me to rethink computing in general.

how are they stored?

Re: The Code-Only Agent

#69

Post by lighthouse1212 »

I've been experimenting with persistent agent systems and found the code-only vs specialized-tools debate might miss a middle path around session continuity.

The key challenge isn't execution (both work) but cross-session persistence. What's worked for me: file-based handoffs rather than context injection.

Instead of maintaining context across agent invocations, have the agent write structured state to files (markdown logs, JSON state) and read them at session start. Each new session reads previous sessions' artifacts and "recognizes" the ongoing work rather than trying to "remember" it.

This sidesteps the context-loading bottleneck - you're not injecting historical conversation; the agent reconstructs understanding from durable artifacts. More like picking up a colleague's notes than continuing your own thought.

Has anyone experimented with this pattern at scale?

Re: The Code-Only Agent

#70

Post by theshrike79 »

lighthouse1212 wrote: post #69

I've been experimenting with persistent agent systems and found the code-only vs specialized-tools debate might miss a middle path around session continuity. The key challenge isn't execution (both work) but cross-session persistence. What's worked for me: file-based handoffs rather than context injection. Instead of maintaining context across agent invocations, have the agent write structured state to files (markdow…

Steve Yegge's Beads tries to be this.

It has grown to a massive 400kLOC monstrosity, but in essence it's a CLI tool designed to fit the LLM averages (all switches are what LLMs expect etc), all it does is keep a task list in JSONL files.

You can do the same with github issues, most models can use the `gh` tool to manage issues

Post reply on HN