Thread

1. mafro · 1789642301 · focus · HN ↗

   I've used OpenSpec extensively on two large pieces of software which were worked solo over 6-9 months.

   Recently, I've completely ditched the specification part. I found they just weren't useful over the longer term. I used an LLM to assess in both directions whether the code matched the specs and whether the specs matched the code. On both software projects this came out with huge divergence from spec to code.

   Basically the old theory is true - the code IS the specification.

   What I did find very useful and have retained is the process flow. Create a proposal, review the proposal, implement, review the code. Also useful was building and maintaining ADRs and invariant logs for where a unit test cannot be made to verify behaviour. The process and the ADRs, unit test, invariant log all help the software stay coherent as the LLM churns on it over many unconnected contexts.

   1. sieve · 1789647657 · focus · HN ↗

      > Basically the old theory is true - the code IS the specification.

      The spec is whatever I write by hand. The code is what the LLM writes for me. The spec could be anything depending on how much detail you want.

      The problem with the "code IS the spec" in the age of LLMs is that they will change stuff without telling you while hitting their immediate goal. Six months ago, I used to review every single change. Now I get the LLM to audit the code to compare against the spec. Any divergence means one of two things:

      - either I have to update the spec, or

      - the LLM has to update the code.

      1. mafro · 1789661033 · focus · HN ↗

         I can appreciate your approach, but I'm not hand writing 100s to 1000s of specs by hand - at that point I'll just write the code myself

Unofficial Hacker News client; not affiliated with Y Combinator.