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

Components of a Coding Agent

magazine.sebastianraschka.com

Post reply on HN
Print view View original

31–40 of 120 posts

Re: Components of a Coding Agent

#31

Post by HarHarVeryFunny »

senko wrote: post #25
HarHarVeryFunny wrote: post #17

Earlier quoted context omitted.

If all you want is a program that calls the model in a loop and offers a bash tool, then ask Claude Code to build that. You won't like it though! For a preview of what it'd be like, just tell your AI chat app that you'll run bash commands for it, and please change the app in your "current directory" to "sort the output before printing it", or some such request.

Claude Code with Opus 4.6 regularly uses sed for multi-line edits, in my experience. On top of it, Pi is famously only exposing 4 tools, which is not just Bash, but far more constrained than CCs 57 or so tools. So, yes, it can work.

I think the problem/limitation would be as much due to context management as tools. Obviously bash plus a few utilities is sufficient to explore/edit the code base, but I can't imagine this working reliably without the models being specifically trained to use specific tools, and recognize/adapt to different versions of them etc.

Context management, both within and across sessions, seems the bigger issue. Without the agent supporting this, you are at the mercy of the model compacting/purging the context as needed, in some generic fashion, as well as being smart enough to decide to create notes for itself tracking what it is doing, etc.

Apparently CC is 512K LOC, which seems massively bloated, but I do think that things like tools, skills, context management and subagents are all needed to effectively manage context and avoid the issues that might be anticipated by just telling the model it's got a bash tool, and go figure.

Re: Components of a Coding Agent

#32

Post by HarHarVeryFunny »

senko wrote: post #25
HarHarVeryFunny wrote: post #17

Earlier quoted context omitted.

If all you want is a program that calls the model in a loop and offers a bash tool, then ask Claude Code to build that. You won't like it though! For a preview of what it'd be like, just tell your AI chat app that you'll run bash commands for it, and please change the app in your "current directory" to "sort the output before printing it", or some such request.

Claude Code with Opus 4.6 regularly uses sed for multi-line edits, in my experience. On top of it, Pi is famously only exposing 4 tools, which is not just Bash, but far more constrained than CCs 57 or so tools. So, yes, it can work.

I thought CC only supports it's find/replace edit tool (implemented by CC itself, using Node.js for file access), and is platform agnostic. Are you saying that on linux CC offers "sed" as a tool too? I can't imagine it offers "bash" since that's way too dangerous.

Re: Components of a Coding Agent

#33

Post by dboreham »

beshrkayali wrote: post #14

> long contexts are still expensive and can also introduce additional noise (if there is a lot of irrelevant info) I think spec-driven generation is the antithesis of chat-style coding for this reason. With tools like Claude Code, you are the one tracking what was already built, what interfaces exist, and why something was generated a certain way. I built Ossature[1] around the opposite model. You write specs describ…

Waterfall!

Re: Components of a Coding Agent

#34

Post by HarHarVeryFunny »

slopinthebag wrote: post #28
HarHarVeryFunny wrote: post #17

Earlier quoted context omitted.

If all you want is a program that calls the model in a loop and offers a bash tool, then ask Claude Code to build that. You won't like it though! For a preview of what it'd be like, just tell your AI chat app that you'll run bash commands for it, and please change the app in your "current directory" to "sort the output before printing it", or some such request.

Claude Code gets smoked on benchmarks by an agent that has a single tool: tmux. So I think they might actually like that quite a bit.

What benchmarks are you referring to?

Re: Components of a Coding Agent

#35

Post by emp17344 »

armcat wrote: post #3

I still find it incredible at the power that was unleashed by surrounding an LLM with a simple state machine, and giving it access to bash

If you saw the Claude Code leak, you’d know the harness is anything but simple. It’s a sprawling, labyrinthine mess, but it’s required to make LLMs somewhat deterministic and useful as tools.

Re: Components of a Coding Agent

#36

Post by beshrkayali »

comboy wrote: post #27
beshrkayali wrote: post #14

> long contexts are still expensive and can also introduce additional noise (if there is a lot of irrelevant info) I think spec-driven generation is the antithesis of chat-style coding for this reason. With tools like Claude Code, you are the one tracking what was already built, what interfaces exist, and why something was generated a certain way. I built Ossature[1] around the opposite model. You write specs describ…

Hey, you seem to have similar view on this. I know ideas are cheap but hear me out: You talk with agent A it only modifies this spec, you still chat and can say "make it prettier" but that agent only modifies the spec, the spec could also separate "explicit" from "inferred". And of course agent B which builds only sees the spec. User actually can care about diffs generated by agent A again, because nobody wants to ve…

Right, the spec/build separation is exactly the idea and Ossature is already built that way on the build side.

I agree a dedicated layer for intent capture makes a lot of sense. I thought about that as well, I am just not fully convinced it has to be conversational (or free-form conversational). Writing a prompt to get the right spec change is still a skill in itself, and it feels like it'd just be shifting the problem upstream rather than actually solving it. A structured editing experience over specs feels like it'd be more tractable to me. But the explicit vs inferred distinction you mention is interesting and worth thinking through more.

Re: Components of a Coding Agent

#38

Post by xstas1 »

emp17344 wrote: post #35
armcat wrote: post #3

I still find it incredible at the power that was unleashed by surrounding an LLM with a simple state machine, and giving it access to bash

If you saw the Claude Code leak, you’d know the harness is anything but simple. It’s a sprawling, labyrinthine mess, but it’s required to make LLMs somewhat deterministic and useful as tools.

Hypothesis: it's a sprawling, labyrinthine mess because it was grown at high speed using Claude Code.

Re: Components of a Coding Agent

#39

Post by comboy »

beshrkayali wrote: post #36
comboy wrote: post #27

Earlier quoted context omitted.

Hey, you seem to have similar view on this. I know ideas are cheap but hear me out: You talk with agent A it only modifies this spec, you still chat and can say "make it prettier" but that agent only modifies the spec, the spec could also separate "explicit" from "inferred". And of course agent B which builds only sees the spec. User actually can care about diffs generated by agent A again, because nobody wants to ve…

Right, the spec/build separation is exactly the idea and Ossature is already built that way on the build side. I agree a dedicated layer for intent capture makes a lot of sense. I thought about that as well, I am just not fully convinced it has to be conversational (or free-form conversational). Writing a prompt to get the right spec change is still a skill in itself, and it feels like it'd just be shifting the probl…

The spec manually crafted the user is ideal.

It's just that we're lazy. After being able to chat, I don't see people going back. You can't just paste some error into the specs, you can't paste it image and say it make it look more like this. Plus however well designed the spec, something like "actually make it always wait for the user feedback" can trigger changes in many places (even for the sake of removing contradictions).

Re: Components of a Coding Agent

#40

Post by senko »

HarHarVeryFunny wrote: post #32
senko wrote: post #25

Earlier quoted context omitted.

Claude Code with Opus 4.6 regularly uses sed for multi-line edits, in my experience. On top of it, Pi is famously only exposing 4 tools, which is not just Bash, but far more constrained than CCs 57 or so tools. So, yes, it can work.

I thought CC only supports it's find/replace edit tool (implemented by CC itself, using Node.js for file access), and is platform agnostic. Are you saying that on linux CC offers "sed" as a tool too? I can't imagine it offers "bash" since that's way too dangerous.

Yes, Claude Code has a Bash tool, and Claude in some cases uses the CLI sed utility (via the Bash tool) for file changes (although it has built-in file update), at least on my Linux machine.
Post reply on HN