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

91–100 of 120 posts

Re: Components of a Coding Agent

#91

Post by comboy »

whattheheckheck wrote: post #81
comboy wrote: post #39

Earlier quoted context omitted.

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 contrad…

And what is a spec other than a program in a programming language? How do you prove the code artifact matches the spec or state machine

Program defines the exact computer instructions. Most of the time you don't care about that level of detail. You just have some intent and some constraints.

Say "I want HN client for mobile", "must notify me about comments", you see it and you add "should support dark mode". Can you see how that is much less than anything in any programming language?

Re: Components of a Coding Agent

#93

Post by addandsubtract »

zbyforgotpass wrote: post #37

Isn't there a better word than harness? I understand the metaphor of leading and constraining a raw power - but I don't like it.

It's kinda ironic that everything has become an "app" over the past 10 years. Facebook is an "app", Reddit is an "app", your bank is an "app". However, the one time we actually introduce an app to execute our LLM calls, we don't call it an "app"? Wat.

Re: Components of a Coding Agent

#94

Post by dkersten »

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…

I’m building something similar. It’s not public yet because it’s still early and I’m still working on exactly what it is supposed to be.

But the idea is similar in that I start with a spec and feed the LLM context that is a projection of the code and spec, rather than a conversation. The context is specific to the specific workflow stage (eg planning needs different context to implementing) and it doesn’t accumulate and grow (at least, the growth is limited and based on the tool call loop, not on the entire process).

My main goals are more focused context, no drift due to accumulated context, and code-driven workflows (the LLM doesn’t control the RPI workflow, my code does).

It’s built as a workflow engine so that it’s easy for me to experiment with and iterate on ideas.

I like your idea of using TOML as the artifact that flow between workflow stages, I will see if that’s something that might be useful for me too!

Re: Components of a Coding Agent

#95

Post by beshrkayali »

AnimalMuppet wrote: post #48
dboreham wrote: post #33

Earlier quoted context omitted.

Waterfall!

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 have some ideas.

I agree that, this is what makes it not waterfall. You're iterating on the spec and not backtracking from broken code. The spec is the "source code", replanning and rebuilding is just "recompiling".

Re: Components of a Coding Agent

#96

Post by beshrkayali »

visarga wrote: post #84
beshrkayali wrote: post #36

Earlier quoted context omitted.

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…

My own approach also has intent sitting at the top: intent justifies plan justifies code justifies tests. And the other way around, tests satisfy code, satisfy plan, satisfy intent. These threads bottom up and top down are validated by judge agents. I also make individual tasks md files (task.md) which makes them capable of carrying intent, plan, but not just checkbox driven "- [ ]" gates, they get annotated with out…

The hierarchy you describe (intent -> plan -> code -> tests) maps well to how Ossature works. The difference is that your approach builds scaffolding around Claude Code to recover structure that chat naturally loses, whereas Ossature takes chat out of the generation pipeline entirely. Specs are the source of truth before anything is generated, so there's no drift to compensate for, the audit and build plan handle that upfront.

The judge finding is interesting though. Right now verification during build for each task in Ossature is command-based, compile, tests, that kind of thing. A judge checking spec-to-code fidelity rather than (or maybe in addition to?) runtime correctness is worth thinking about.

Re: Components of a Coding Agent

#97

Post by beshrkayali »

dkersten wrote: post #94
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…

I’m building something similar. It’s not public yet because it’s still early and I’m still working on exactly what it is supposed to be. But the idea is similar in that I start with a spec and feed the LLM context that is a projection of the code and spec, rather than a conversation. The context is specific to the specific workflow stage (eg planning needs different context to implementing) and it doesn’t accumulate…

Very much the same thinking. Ossature already structures work that way at the plan level during audit, so curious to see where you take it. Happy to share more about the TOML approach if useful. Feel free to reach out (me at my domain)

Re: Components of a Coding Agent

#100

Post by Asuka-wx »

The useful framing here is that coding agents get better less from raw model gains and more from better scaffolding around the model. Once you give them tools, repo context, and a simple state machine, the bottleneck shifts to context qual
Post reply on HN