Awesome Read!!
Components of a Coding Agent
101–110 of 120 posts
Re: Components of a Coding Agent
#102[dead]
Re: Components of a Coding Agent
#103I 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
[dead]
Re: Components of a Coding Agent
#104[dead]
Re: Components of a Coding Agent
#105Earlier 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…
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 is…
All three of these are real. The audit pass in Ossature is meant to catch the first two before generation starts, it reads across all specs and flags underspecified behavior, missing details, and contradictions. You resolve those, update the specs, and re-audit until the plan is clean. It's not perfect but it shifts a lot of the discovery earlier in the process.
The third point is harder. You still need to know your tooling well enough to write a spec that works with it. That part hasn't gone away.
Re: Components of a Coding Agent
#106Earlier quoted context omitted.
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 tha…
Yes, judges should not just look for bugs, they should also validate intent follow, but that can only happen when intent was preserved. I chose to save the user messages as a compromise, they are probably 10 or 100x smaller than full session. I think tasks themselves are one step lower than pure user intent. Anyway, if you didn't log user messages you can still recover them from session files if they have not been removed.
One interesting data point - I counted word count in my chat messages vs final code and they came out about 1:1, but in reality a programmer would type 10x the final code during development. From a different perspective I found I created 10x more projects since I relied on Claude and my harness than before. So it looks user intent is 10x more effective than manual coding now.
Re: Components of a Coding Agent
#107Earlier 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…
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 a b # 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 alw…
Allium looks interesting, making behavioral intent explicit in a structured format rather than prose is very close to what I'm trying to do with Ossature actually.
Ossature uses two markdown formats, SMD[1] for describing behavior and AMD for structure (components, file paths, data models). AMDs[2] link back to their parent SMD so behavior and structure stay connected. Both are meant to be written, reviewed, and/or owned by humans, the LLM only reads the relevant parts during generation. One thing I am thinking about for the future is making the template structure for this customizable per project, because "spec" means different things to different teams/projects. Right now the format is fixed, but I am thinking about a schema-based way to declare which sections are required, their order, and basic content constraints, so teams can adapt the spec structure to how they think about software without having to learn a grammar language to do it (though maybe peg-based underneath anyway, not sure).
The formal approach you describe is probably more precise for expressing system properties. Would be interesting to see how practical it is to maintain it as a project grows.
Re: Components of a Coding Agent
#108Re: Components of a Coding Agent
#109> This is speculative, but I suspect that if we dropped one of the latest, most capable open-weight LLMs, such as GLM-5, into a similar harness, it could likely perform on par with GPT-5.4 in Codex or Claude Opus 4.6 in Claude Code. Unless I'm misunderstanding what's being described here, running Claude Code with different backend models is pretty common. https://docs.z.ai/scenario-example/develop-tools/claude It doe…
I've found that on some projects maybe 70-80% of what can be done with Sonnet 4.6 in OpenCode can be done with a cheaper model like MiMo V2 Pro or similar. On others Sonnet completely outperforms. I'm not sure why. I only find Opus to be worth the extra cost maybe 5% of the time. I also find OpenCode to be drastically better than Claude Code, to the extent that I'm buying OpenRouter API credits rather than Claude Max…
[flagged]
Re: Components of a Coding Agent
#110> 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 c…
Exactly this. The audit pass in Ossature is specifically for that "unclear spec" case, you resolve ambiguities in the spec before generation starts rather than discovering them mid-conversation and losing them the next session. Once the plan is clean, the LLM never needs to ask a clarifying question. Memories and agent files are patching over the fact that intent was never properly captured to begin with.