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

81–90 of 120 posts

Re: Components of a Coding Agent

#81

Post by whattheheckheck »

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…

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

Re: Components of a Coding Agent

#84

Post by visarga »

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…

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 outcomes, and become a workbook after execution. The same task.md is seen twice by judge agents which run without extra context, the plan judge and the implementation judge.

I ran tests to see which component of my harness contributes the most and it came out that it is the judges. Apparently claude code can solve a task with or without a task file just as well, but the existence of this task file makes plans and work more auditable, and not just for bugs, but for intent follow.

Coming back to user intent, I have a post user message hook that writes user messages to a project scoped chat_log.md file, which means all user messages are preserved (user text Once every 10-20 tasks I run a retrospective task that inspects all task.md files since last retro and judges how the harness performs and project goes. This can detect things not apparent in task level work, for example when using multiple tasks to implement a more complex feature, or when a subsystem is touched by multiple tasks. I think reflection is the one place where the harness itself and how we use it can be refined.

    claude plugin marketplace add horiacristescu/claude-playbook-plugin

    source at https://github.com/horiacristescu/claude-playbook-plugin/tree/main

Re: Components of a Coding Agent

#85

Post by miki123211 »

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…

See also: https://juxt.github.io/allium/ (not affiliated in any way, just an interesting project)

I'm using something similar-ish that I build for myself (much smaller, less interesting, not yet published and with prettier syntax). Something like:

    a->b # b must always be true if a is true
    ab # works both ways
    a=>b # when a happens, b must happen
    a->fail, a=> fail # a can never be true / can never happen
    a # a is always true
So you can write:

    Product.alcoholic? Product in Order.lineItems -> Order.customer.can_buy_alcohol?
    u1 = User(), u2=User(), u1 in u2.friends -> u2 in u1.friends
    new Source() => new Subscription(user=Source.owner, source=Source)
    Source.subscriptions.count>0 # delete otherwise
This is a much more compact way to write desired system properties than writing them out in English (or Allium), but helps you reason better about what you actually want.

Re: Components of a Coding Agent

#86

Post by oortcrate_1 »

Totally agree. Chat history feels like a side effect, not a source of truth. Having an explicit markdown file for goals and constraints has been a game changer for my workflow. It turns out you don't need a complex setup; you just need the agent to be explicit about what it’s doing and why.
Post reply on HN