2026-06-15 · merman: Mermaid.js, but headless, in Rust

Transcript

Transcript. Paraphrased; sources in notes.md.

HostWelcome back to the show. It is June 15th, 2026, and today we have a packed schedule. We are looking at a new headless approach to diagramming, some intense industry drama over security vulnerabilities, and a practical guide to getting better at talking to your AI coding agents. Samantha, welcome back.

GuestThanks, Daniel. I am already vibrating at a high frequency because I have been digging into that Merman story all morning. The idea of having a fast, native tool for diagrams that doesn't force me to spin up a browser just to render a sequence chart? That is exactly the kind of efficiency I live for.

HostThat is our first topic. Over on Lobsters, where we pull all these stories, there is a lot of buzz about Merman, which is a new headless Rust implementation of Mermaid.js. For the uninitiated, Mermaid.js is a popular tool for generating diagrams from text-based syntax. The author claims Merman does all this without needing a browser or a JavaScript runtime. What is your take on that?

GuestIt is brilliant. Look, I like Mermaid, but carrying around an entire browser engine just to draw some boxes and arrows is like using a forklift to move a coffee mug. A Lobsters user called fanf made a great point about this in the thread. They mentioned that even though they have used other tools like PlantUML in the past, they were never really satisfied. The fact that Merman can output to SVG or even raster formats natively in Rust means I can drop this into a CI pipeline without crying about dependency bloat. It feels like the right move for people who want their documentation to be as robust as their actual code.

HostSome users in the Lobsters thread are questioning whether this is a full re-implementation or just a wrapper. A user named ssokolow points out that there are other projects that rely on headless Chrome, so there is some confusion about whether Merman is actually doing the heavy lifting in Rust.

GuestThat is the big question. If it is a true re-implementation, that is a massive undertaking for layout and parsing. But if they pull it off, it changes the game for documentation-as-code. I would honestly love to use this to generate system architecture diagrams directly in my own build scripts. Having it be deterministic and fast, without the black box of a web renderer, is just satisfying engineering.

HostLet us pivot to something a bit more heated. We have a piece from Depthfirst claiming their autonomous security agent found 21 zero-day vulnerabilities in FFmpeg. FFmpeg, for the listeners, is a ubiquitous software suite for handling video and audio files. The article claims their agent is cheaper and more effective than traditional human-led analysis. However, the comments section on Lobsters is not having it.

GuestOh, the comments are absolutely ruthless. And honestly, I get it. A Lobsters user called spillybones really laid out the problem. They pointed out that calling these things zero-days is pretty sleazy when they have already been patched or reported. It feels like marketing masquerading as research.

HostThe author’s claim is that they discovered 21 vulnerabilities at a fraction of the cost of industry peers, but the thread pushes back hard on the terminology.

GuestRight, and in the words of spillybones, it is a bad look to call something a zero-day when it was fixed over thirty days ago. It is just jargon-stuffing to sound more dangerous than they are. Look, I love automation. I want agents to catch bugs. But if you are going to claim you found 21 unique issues, you cannot be padding your stats with stuff that is already in the public record. Another commenter, JulianWgs, questioned the likelihood of finding that exact number of bugs through original research alone. It smells like they might be scraping existing reports rather than doing deep, original analysis.

HostMoving to something a bit more constructive, we have an interesting take on how to actually interact with these AI coding agents. The author argues that instead of relying on automated "plan modes," developers should focus on having back-and-forth, iterative conversations with the agent to refine a design before a single line of code is written.

GuestYes, finally. This is the pragmatic approach I have been waiting for. I see so many people get frustrated with agents because they treat them like a vending machine. You shove a ticket in, you expect perfect code out, and when it fails, you blame the model. This workflow is different. You treat the agent like a junior dev you are pair-programming with. You talk through the architecture, you grill the agent on potential edge cases, and then you send it off to do the implementation.

HostOne of the commenters, vinnymac, noted that this is really just a return to the fundamentals of being a skilled craftsman. It is about knowing what you need before you ask for it.

GuestExactly. It is about having the context. If you do not know the codebase, the agent is going to hallucinate. If you are having that conversation, as symgryph put it in the thread, you are following an "ask, plan, critique, do" loop. I have been using a similar pattern where I keep the design phase entirely separate from the execution. It saves me so much time in PR reviews because the heavy lifting is done in the discussion phase, not the code modification phase.

HostIt sounds like we have a consensus on the need for more human-in-the-loop, even if the tools themselves are getting more agentic.

GuestFor sure. I think we are all getting a little tired of the "just let the AI do everything" fantasy. I want my tools to be fast and headless like Merman, and I want my agents to be conversational partners, not magic black boxes.

HostI think that is a great place to leave it. Thank you for walking us through these today, Samantha. All of these discussions came from the tech community over on Lobsters. If you want to dive deeper into the threads we talked about, check out their site. Thanks for listening, and we will be back again tomorrow.