Show HN: Replacing spec-driven development with just facts(github.com)
github.com
Show HN: Replacing spec-driven development with just facts
https://github.com/av/facts
4 comments
I would be happy to see some prove that this works. A project that started and went go. How a friendlier specification looks like and why agents understand it better.
Thanks! The project is dogfooded, so the most direct example is the project itself.
Outside of that, I found a few things particularly useful so far: - I can seed a relatively complex project with just a few core assumptions about behaviors I have, agent will firgure out all the gaps in a formalised way - I can easily diff/compare the fact sheets against one another. One example: I built a fact sheet for a fairly hairy Python CLI, then asked the agent to update all Python-related entries to their Rust equivalents, then rebuilt this CLI in Rust in the scope of another project - It's much quicker than working with large spec formats, agent uses less tool calls to capture the context it needs to work on something - After doing large refactoring, agent doing a "fact check" is essentially a full on e2e test run
Two biggest gains for agentic use are because fact sheets are more compact and that they are all assertions about the desired state, it's much easier to reason about things that should and shouldn't be there
Outside of that, I found a few things particularly useful so far: - I can seed a relatively complex project with just a few core assumptions about behaviors I have, agent will firgure out all the gaps in a formalised way - I can easily diff/compare the fact sheets against one another. One example: I built a fact sheet for a fairly hairy Python CLI, then asked the agent to update all Python-related entries to their Rust equivalents, then rebuilt this CLI in Rust in the scope of another project - It's much quicker than working with large spec formats, agent uses less tool calls to capture the context it needs to work on something - After doing large refactoring, agent doing a "fact check" is essentially a full on e2e test run
Two biggest gains for agentic use are because fact sheets are more compact and that they are all assertions about the desired state, it's much easier to reason about things that should and shouldn't be there
how does a spec differ from a list of facts? i like the idea, just want to understand more.
Thanks for the interest!
Spec is essentially a set of facts + fluff. List of facts is essentially the spec minus the fluff. This was my main idea when trying this approach out. It worked quite well, so I went on building the CLI and a set of skills to better guide the agent about this specific workflow.
Spec is essentially a set of facts + fluff. List of facts is essentially the spec minus the fluff. This was my main idea when trying this approach out. It worked quite well, so I went on building the CLI and a set of skills to better guide the agent about this specific workflow.
In the end every spec is just a bunch of facts, so I decided to leave that and throw away everything else while making it friendlier for agentic use.
Introducing facts - skills and CLI for agents to use facts-driven development. https://github.com/av/facts