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. polycaster · 1789645821 · focus · HN ↗

      The code is only part of the specification. It does rarely document the actual requirements to a degree you can rely on for decision making. Sure, the code should speak for itself, but it mostly speaks about the WHYs of the implementation, not the reasoning behind the actual requirement. I found that OpenSpec actually helps a lot in this regard.

      1. mafro · 1789661340 · focus · HN ↗

         I challenge you to use a frontier LLM to analyse your code and specs and verify if they are meaningfully aligned.

         Code almost never speaks to the WHY; ADRs will help there.

         Code never captures requirements, but it does reflect actual system behaviour, which is a specification.

Unofficial Hacker News client; not affiliated with Y Combinator.