Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • One concern about accuracy of the diagrams. In the example, there is a transition back to the session service labelled "wait for release" after the "no" decision. I'm not seeing that in the shown diff.

    Looking at the code the "no" seems to relate to the context expiring, so you wouldn't want to wait more if the context already expired, you'd want to stop. Is there a reason that label exists?

    I'm pretty wary of LLM development tools hallucinating and wasting my time, is that whats happening in the lease broker example?

  • Thanks! The project looks great and I am definitely interested in this approach. I hope it will help me with my usual issue - I review a lot of code these days and it's really hard to understand what changes about and why they even needed usually, without deep analysis and AI sessions. It's always good to have such a visual method to check briefly what's there on architecture and design level - these mistakes are hardest to find in other people's code, as it is for me.

    I especially like your way to connect agents - I'm basically using what I wish to use, without limitations or pay walls. At my work, all AI tools should be reviewed and approved before usage but here I just use my coding agent and this is "plugin" for visualisation, so I guess it will be approved in no time. Thanks to not keeping a forced data collection, it will really help to promote your tool in corporate environments.

    No reasons to not try it for me! I am looking closely at what will come next and will try to share my feedback, if there will be some.

    For now, I just feel that it will be good to have a way to trigger review creation from the app itself, not to create a new agent session for this. Kinda a bit counterintuitive but I understand why it works this way and it's not a real issue.

  • "Known limitations You cannot currently edit files in Whiteboard. If this is something that you find yourself wanting to do, please file an issue!"

    Seems like a big limitation for an "IDE"

  • This is really cool! I'm pumped for anything that makes it easier to review generated code. I, like many people these days, am searching for ways to stay close to the code whilst not being overwhelmed... and as a visual personal i like your idea to semantically link code to diagrams

    I've been working on a (semi-)similar thing, a TUI for narrative code reviews - https://github.com/mtford90/revue - the idea being to generate "guided tours" of a change as opposed to a big wall of files.

  • This is definitely getting at least some things right about how we work with agents today, specifically that we often work at the architecture level, and we need a better alternative to the current Plan Mode offered by coding agents to efficiently architect software at a high level, which is more visual and offers better back-and-forth incrementation with the agent than simply "reject final plan with X message".

    From the website demos i definitely think this is a clean interface, although I don't know how much better this is compared to some simple custom Mermaid format, which the agent can write as artifact files and present to users. Zooming out, this app seems like 1 feature (a MCP with a GUI attached to it) rather than an entire product.

    Also, I don't know if asking the agent to write specific code changes into the plan is a good idea. I think maybe that a "plan -> approve -> write code" would let the agent write higher quality code than "plan which contains code -> approve". But maybe you can make it work when combined with some specific prompting marking the code as clearly work-in-progress and subject to change, and that the agent should surface any parts implemented differently relative to the plan to the user, etc.

  •   You cannot currently edit files in Whiteboard. If this is something that you find yourself wanting to do, please file an issue!
    
    Do you still consider this an IDE? Curious
    by icar
  • How do you compare to https://likec4.dev/ and https://erode.dev/ , which are currently fully open-source and community driven?

    C4 gives the text-based representation needed for LLMs to generate and maintain large architecture diagrams - why not build off that heritage?

  • Oh WOW, cool to see a technique that'll be everywhere in 12 months (the fake pen drawing animations + streaming diagrams as they're produced) first be announced. Do we still do "First!" comments, y'all?

    ~~[EDIT: you need to put "only for macOS" in way more prominent places, all over -- that offends my soul greatly and may Linus frown upon you all]~~ [EDIT2: I was mistaken!]

    This all looks really solid. That said, two remarks:

    1. The integration with OS LSPs is quite fun and commendable. Is it possible that the diagrams might get their own LSP, someday? Or is better just staying as direct TS callsites?

    2. The choice of the word "IDE" seems like it might get you in trouble, given the small "cannot edit files" detail. Any comments on the decision there, as opposed to, say... "brainstorming tool"? Or hell, "[architectonic] harness"?

    3. The psuedocode "semantic diff" thing is an incredible idea, wow. Props there.

    4. This language kinda concerns me: "how the requirements that you set were implemented". In my highly-arbitrary development flow, it ideally goes `idea -> spec/reqs -> plan -> test -> impl -> eval -> land -> review`, and this kind of tool seems explicitly targeted towards just the second and third with some partial coverage of their neighbors on either side. More concretely: by adding implementation, don't you lose a powerful specificity selling point and now have to compete with all full harnesses?

    5. Suggesting "GPT-6 Luna and Claude Opus 5.5" is presumably a typo? Cause the equivelant of Opus 5.5 is Astra, and even then not really.

    by bbor

Explore Birbla archives