Thread

1. vladzoff · 1790317015 · focus · HN ↗

   I can see the value of having the agent and the human looking at the same design. The thing I'd worry about is the diagram becoming another thing that slowly diverges from the code. Would be interesting to see how you handle that once the implementation starts moving.

   1. sidharthkmenon · 1790318603 · focus · HN ↗

      yeah, i think this is a real concern. the diagrams are all attached to code by design so we can tell if something has drifted (e.g. can model a diagram node in a sense as a code forge "comment"; building upon some great work from e.g. gitlab here!).

      there's a separate problem here re: multiple sources of truth (e.g. Linear for a spec) that you're also getting at. in my own experience, whiteboard is still quite helpful when it's important to understand the change going in (which isn't every single one!).

      in the future, we plan to deliver (1) affordances to capture the spec planning process in the whiteboard so you can iterate more flexibly / in more ways, and (2) will also ship a hosted product so this can be multiplayer - which will help resolve that source-of-truth issue, we hope.

   2. ketan_around · 1790318825 · focus · HN ↗

      yeah, for sure. i think the diagrams/artifacts are definitely more ephemeral, since they fall out of date. in my experience, the more lasting artifacts from the whiteboarding session have been 1) making the code that ships higher quality because i understand it, and 2) getting my own mental model aligned with the current state of the codebase.

      we're dreaming up some features in a hosted version of the product which could maintain an up-to-date 'software map' of your codebase, and that is the backbone which would power all diagrams/visualizations

Unofficial Hacker News client; not affiliated with Y Combinator.