It is slightly weird that people accepted this new trend just like that, probably because they think this is being transparent and wanting to give attribution, but it'd be more useful like what the Linux kernel "AI Coding Assistants" page describes, something like `AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]`, at least we get to know which model was used and/if any additional tooling on top. And `Assisted-by:` is more appropriate for that purpose than `Co-authored-by`.

Comments URL: https://news.ycombinator.com/item?id=48166832

Points: 4

# Comments: 0

Not related to the main point of the article, but I find reading long form contnet in a mono font much easier.

The models are already good enough for code generation. What we need is the harness around them actually deterministically enforcing a specific path and “leashing” the models output to be aligned with the intention of the user as much as possible. You can’t make the output of the model deterministic, but you can make everything around it to be so.

Trying to make enforcements work with prompts is like a government agency investigating/auditing itself, there’s no incentive to find problems, so you’ll always inevitably get the “All Good, Boss!”

“Specsmaxxing” is basically the right response to this. When you can't rely on authorial memory, you have to put the intent somewhere durable. Specs become the source of truth by default if we continue down the road of AI generated code.

1: https://ossature.dev/blog/ai-generated-code-has-no-author/

There are two parts worth quoting:

> Although cortical reductions sometimes reflect a process of neurodegeneration, they can also be a sign of refinement and specialization of neural circuits. Adolescence, for instance, is a life period characterized by the continued elimination of redundant synapses (i.e. synaptic pruning) which parallels cognitive and emotional development (Selemon 2013). In the context of the transition to parent-hood, several examples across human and non-human mammals show functional improvements after reductions in brain markers (Pawluski et al. 2022).

And:

> Although we found converging evidence of cortical reductions across the two samples, a number of divergent findings also emerged. First, when disentangling the cortical volume reduction, Californian fathers displayed significant reductions in area and Spanish fathers in thickness. Changes in the area may reflect changes in the number of cells located between radial columns of the brain, while changes in thickness may reflect changes in the number of cells within ontogenic columns (Petanjek et al. 2011). Secondly, the volume of the dorsal attentional network, which supports goal-directed attention, was significantly reduced in Spanish fathers, while it did not show significant changes in Californian fathers. Combined with the default mode network, this network may control sustained attention (Spreng et al. 2010, 2013), a behavior that is often required during childrearing. It is possible that these inconsistent results at the statistical level may be due to the different scan timing windows or to cultural or behavioral differences. For example, due to more generous paternity leave policies in Spain

1: https://academic.oup.com/cercor/article/33/7/4156/6691667

Comments URL: https://news.ycombinator.com/item?id=47967649

Points: 2

# Comments: 0

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.

1: https://docs.ossature.dev/specs/smd.html

2: https://docs.ossature.dev/specs/amd.html

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.

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.

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".

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 problem upstream rather than actually solving it. A structured editing experience over specs feels like it'd be more tractable to me. But the explicit vs inferred distinction you mention is interesting and worth thinking through more.

> 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 :)

> How does the human intervention work out? Do you use a mix of spec and audit editing to get into the ready to generate state?

Yes, the flow is: you write specs then you validate them with `ossature validate` which parses them and checks they are structurally sound (no LLM involved), then you run `ossature audit` which flags gaps or contradictions in the content as INFO, WARNING, or ERROR level findings. The audit has its own fixer loop that auto-resolves ERROR level findings, but you can also run it interactively, manually fix things yourself, address the INFO and WARNING findings as you see fit, and rerun until you are happy. From that it produces a toml build plan that you can read and edit directly before anything is generated. You can reorder tasks, add notes for the LLM, adjust verification commands, or skip steps entirely. So when you run `ossature build` to generate, the structure is already something you have signed off on. There's a bit more details under the hood, I wrote more in an intro post[1] about Ossature, might be useful.

> The spec driven approach is potentially better for writing things from scratch, do you have any plans for existing code?

Right now it is best for greenfield, as you said. I have been thinking about a workflow where you generate specs from existing code and then let Ossature work from those, but I am honestly not sure that is the right model either. The harder case is when engineers want to touch both the code and the specs, and keeping those in sync through that back and forth is something I want to support but have not figured out a clean answer for yet. It's on the list, if you have any thoughts please feel free to open an issue! I want to get through some of the issues I am seeing with just spec editing workflow (and re-audit/re-planning) first, specifically around how changes cascade through dependent tasks.

Regarding success rate, each task requires a verification command to run and pass after generation and if it fails, a separate fixer agent tries to repair it using the error output. The number of retry attempts is configurable. I did notice that the more concise and clear the spec is the more likely it is for capable models to generate code that works (obviously) but that's what auditing is supposed to help with. One interesting case about the chip-8 emulator I mentioned above is that even mentioning the correct name of the solution to a specific problem was not enough, I had to spell out the concrete algorithm in the spec (wrote more details here[2]). But the full prompt and response for every task is saved to disk, so when something does go wrong one can read the exact prompt/response and fix-attempts prompt/response for each task.

1: https://ossature.dev/blog/introducing-ossature/

2: https://log.beshr.com/chip8-emulator-from-spec/

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 describing behavior, it audits them for gaps and contradictions before any code is written, then produces a build plan toml where each task declares exactly which spec sections and upstream files it needs. The LLM never sees more than that, and there is no accumulated conversation history to drift from. Every prompt and response is saved to disk, so traceability is built in rather than something you reconstruct by scrolling back through a chat. I used it over the last couple of days to build a CHIP-8 emulator entirely from specs[2]. I have some more example projects on GitHub[3]

1: https://github.com/ossature/ossature

2: https://github.com/beshrkayali/chomp8

3: https://github.com/ossature/ossature-examples