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

111–120 of 120 posts

Re: Components of a Coding Agent

#111

Post by efromvt »

emp17344 wrote: post #52
efromvt wrote: post #50

Earlier quoted context omitted.

It's pretty easy to get determinism with a simple harness for a well-defined set of tasks with the recent models that are post-trained for tool use. CC probably gets some bloat because it tries to do a LOT more; and some bloat because it's grown organically.

>It's pretty easy to get determinism with a simple harness for a well-defined set of tasks with the recent models that are post-trained for tool use. Do you have a source? Claude Code is the only genetic system that seems to really work well enough to be useful, and it’s equipped with an absolutely absurd amount of testing and redundancy to make it useful.

Should I read that as 'generic system'? Most hard data is with company internal evals, but for the well defined tasks externally it's been pretty easy to spin up a basic tool loop and validate. Did you have something in mind? [I don't necessarily count 'coding' as well-defined in the generic sense, so I suspect we're coming at this from different scopes re: the definition of 'LLMs somewhat deterministic and useful as tools']

Re: Components of a Coding Agent

#112

Post by genxy »

alfiedotwtf wrote: post #78
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…

How does this differ from Superpowers?

How about you link to it so people can judge.

Re: Components of a Coding Agent

#113

Post by genxy »

beshrkayali wrote: post #95
AnimalMuppet wrote: post #48

Earlier quoted context omitted.

There are two problems with waterfall. First, if it takes too long to implement, the world moved on and your spec didn't move. Second, there are often gaps in the spec, and you don't discover them until you try to implement it and discover that the spec doesn't specify enough. Well, for the first problem, if an AI can generate the code in a day or a week, the world hasn't moved very much in that time. (In the future,…

You framed it better than I would. The part I'm still working through is making re-planning feel cheap when specs change. Right now if you change something early, downstream tasks get invalidated and the cascade isn't always obvious. Ideally when the project gets built, and then specs change, nothing of the generated code should change if an irrelevant part of the spec changed, this is a bit harder to do properly but…

I don't know what format your spec is in, but it should be graph for this very reason.

Re: Components of a Coding Agent

#114

Post by beshrkayali »

genxy wrote: post #113
beshrkayali wrote: post #95

Earlier quoted context omitted.

You framed it better than I would. The part I'm still working through is making re-planning feel cheap when specs change. Right now if you change something early, downstream tasks get invalidated and the cascade isn't always obvious. Ideally when the project gets built, and then specs change, nothing of the generated code should change if an irrelevant part of the spec changed, this is a bit harder to do properly but…

I don't know what format your spec is in, but it should be graph for this very reason.

Exactly, and it is a DAG (specs and tasks in the toml plan). Check the QOIzig example and its task graph if you’re curious!

Re: Components of a Coding Agent

#117

Post by volume_tech »

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…

[dead]
Post reply on HN