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

61–70 of 120 posts

Re: Components of a Coding Agent

#61

Post by ithkuil »

comboy wrote: post #39
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…

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…

The spec can be wrong for many reasons:

1. You can write a spec that builds something that is not what you actually wanted

2. You can write spec that is incoherent with itself or with the external world

3. You can write a spec that doesn't have sufficient mechanical sympathy with the tooling you have and so it requires you to all spec out more and more of the surrounding tech than you practically can.

All of those issues can be addressed by iterating on the spec with the help of agents. It's just an engineering practice, one that we have to become better at understanding

Re: Components of a Coding Agent

#62

Post by hansonkd »

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've been thinking a lot about this lately. It seems like what is missing with most coding agents is a central source of truth. Before the truth of what the company was building and alignment was distributed, people had context about what they did and what others did and are doing.

Now the coding agent starts fresh each time and its up to you to understand what you asked it and provide the feedback loop.

Instead of chat -> code, I think chat -> spec and then spec -> code is much more the future.

the spec -> code phase should be independent from any human. If the spec is unclear, ask the human to clarify the spec, then use the spec to generate the code.

What happens today is that something is unclear and there is a loop where the agent starts to uncover some broader understanding, but then it is lost the next chat. And then the Human also doesn't learn why their request was unclear. "Memories" and Agents files are all ducktape to this problem.

Re: Components of a Coding Agent

#63

Post by hsaliak »

Tool output truncation helps a lot and is one of the best ways to reduce context bloat. In my coding agent the context is assembled from SQLite. I suffix the message ID to rehydrate the truncated tool call if it’s needed and it works great. My exploration on context management is mostly documented here https://github.com/hsaliak/std_slop/blob/main/docs/CONTEXT_M...

Re: Components of a Coding Agent

#65

Post by straydusk »

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…

This is basically what Augment Intent is

Re: Components of a Coding Agent

#66

Post by 4b11b4 »

beshrkayali wrote: post #29
peterm4 wrote: post #20

Earlier quoted context omitted.

This looks great, and I’ve bookmarked to give it a go. Any reason you’ve opted for custom markdown formats with the @ syntax rather than using something like frontmatter? Very conscious that this would prevent any markdown rendering in github etc.

I've answered this exact question in a previous hn comment thread a few weeks ago, maybe I should reconsider front-matter? My previous answer: > Yeah, I did briefly consider front-matter, but ended up with inline @ tags because I thought it kept the entire document feeling like one coherent spec instead of header-data + body, front matter felt like config to me, but this is 0.0.1 so things might change :)

need both

Re: Components of a Coding Agent

#67

Post by [deleted] »

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…

[deleted]

Re: Components of a Coding Agent

#68

Post by 4b11b4 »

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…

yep but spec isn't the root

Re: Components of a Coding Agent

#69

Post by 4b11b4 »

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…

close

Re: Components of a Coding Agent

#70

Post by 4b11b4 »

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…

nice but can't be only text based
Post reply on HN