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

51–60 of 73 posts

Re: The Code-Only Agent

#51

Post by CuriouslyC »

dfajgljsldkjag wrote: post #3

Agents can complete an impressive amount of tasks with just this, but they quickly hit a bottleneck in loading context. A major reason for the success of agentic coding tools such as Claude and Cursor is how they push context of the problem and codebase into the agent proactively, rather than have the agent waste time and tokens figuring out how to list the directory etc.

Cursor does RAG based on the active state of the editor (focused window, cursor location, recently touched files, etc). This works really well for copilot style small modifications, but it's unhelpful for larger changes, and can actually cause some context rot.

Claude only loads specific files (e.g. CLAUDE.md) and any files those reference with @syntax on load. Everything else is discovered using grep/find mostly.

Re: The Code-Only Agent

#52

Post by fudged71 »

Garlef wrote: post #34
fudged71 wrote: post #26

Earlier quoted context omitted.

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.

Interesting. Could you provide a bit more detail on how the DAG emerges?

2026 paper titled Evolving Programmatic Skill Networks, operationalized in Claude Code

Re: The Code-Only Agent

#53

Post by iepathos »

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 trusting both the tool AND the generated wrapper

The theoretical framing about "proofs as programs" and "semantic guarantees" sounds impressive, but the generated wrapper doesn't provide stronger semantics than rg alone, it actually provides strictly weaker ones. This is true for pretty much any CLI tool you're having the AI wrap python code around to do instead of calling battle tested tools directly.

For actual development work, the artifact that matters is the code you're building, which we're already tracking in source control. Nobody needs a "witness" of how the agent found the right file to edit and if they do agents have parseable logs. Direct tool calls are faster, more reliable, and the intermediate exploration steps are ephemeral scaffolding anyway.

Re: The Code-Only Agent

#54

Post by bob1029 »

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…

> but the generated wrapper doesn't provide stronger semantics than rg alone, it actually provides strictly weaker ones

I don't know if I agree with this.

I had been doing some experiments using Powershell as the only available tool, and I found that switching to an ExecuteFunction (C#) tool provided a much less buggy experience, even when Process.Start is involved.

Which one is functionally a superset of the other is actually kind of a chicken-egg problem because they can both bootstrap into the other. However, in practice the code tool seems to provide far more "paths" and intermediate tokens to absorb the complexity of the original ask. Powershell seemed much more constraining at the edges. I had a lot of trouble getting the shell to accept verbatim strings as file contents. csc.exe has zero issues with this by comparison.

Re: The Code-Only Agent

#55

Post by mkw5053 »

This got me thinking about the Unix philosophy of composing small, specialized tools that each do one thing well. While at first glance a "single powerful tool" approach might seem aligned with that ethos, I think it actually runs counter to it. Forcing agents to reimplement ls, grep, and find throws away decades of battle-tested code. The real Unix-style approach would be giving agents more specialized tools, not fewer, and letting them learn to compose those tools effectively.

Re: The Code-Only Agent

#56

Post by NitpickLawyer »

rcarmo wrote: post #49
NitpickLawyer wrote: post #32

Earlier quoted context omitted.

> That only really works well inside the same session That was already "fixed" by people adding snippets to agents.md and it worked. Now it's even more streamlined with skills. You can even have cc create a skill after a session (i.e. prompt it like "extract the learnings from this session and put them into a skill for working with this specific implementation of sqlite"). And it works, today.

I beg to differ: https://taoofmac.com/space/notes/2026/01/14/0830

> I prefer the more deterministic behavior of MCP for complex multi-step tasks, and the fact that I can do it effectively using smaller, cheaper models is just icing on the cake.

Yeah, that makes sense. That's not what the person that I replied was talking about, tho. Skills work fine for "loading context pertinent to one type of task", such as working on a feature without "forgetting" what was done in the previous session.

The article deals with specific, somewhat predefined workflows.

Re: The Code-Only Agent

#57

Post by hamdingers »

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!

This was my first thought as well, I found the examples of `ls` and `grep` amusing in this context.

I think the author's point is: instead of exposing `grep`/`head`/`awk` as their own distinct tools, expose a single tool for writing the language. They chose Python but one could just as easily choose bash.

Re: The Code-Only Agent

#58

Post by jebarker »

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?

Re: The Code-Only Agent

#59

Post by jrm4 »

bandrami wrote: post #41
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…

Every individual programmer having locally-implemented idiosyncratic versions of sed and awk with imperfect reconstruction between sessions sounds like a regression to me

But -- I think, only because of the friction of having to read and parse what they did, which, to me could greatly be alleviated by AI itself.

Put differently -- for those who'd like to share, yes, give me your locally implemented idosyncraticness with a little AI to help explain to me what's going on, and I feel like that's a sweet spot between "AI do the thing" and "give me raw code"

Re: The Code-Only Agent

#60

Post by jrm4 »

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…

I don't think "efficency" is at all the point? At all?

It's safety, reliability, and human understanding -- and like OOP, for example, are often directly at odds with "efficiency."

Post reply on HN