The best Hacker News stories from Show from the past week
Latest posts:
Show HN: Strange Attractors
I went down the rabbit hole on a side project and ended up building this: Strange Attractors(<a href="https://blog.shashanktomar.com/posts/strange-attractors" rel="nofollow">https://blog.shashanktomar.com/posts/strange-attractors</a>). It’s built with three.js.<p>Working on it reminded me of the little "maths for fun" exercises I used to do while learning programming in early days. Just trying things out, getting fascinated and geeky, and being surprised by the results. I spent way too much time on this, but it was extreme fun.<p>My favorite part: someone pointed me to the Simone Attractor on Threads. It is a 2D attractor and I asked GPT to extrapolate it to 3D, not sure if it’s mathematically correct, but it’s the coolest by far. I have left all the params configurable, so give it a try. I called it Simone (Maybe).<p>If you like math-art experiments, check it out. Would love feedback, especially from folks who know more about the math side.
Show HN: Pipelex – Declarative language for repeatable AI workflows
We’re Robin, Louis, and Thomas. Pipelex is a DSL and a Python runtime for repeatable AI workflows. Think Dockerfile/SQL for multi-step LLM pipelines: you declare steps and interfaces; any model/provider can fill them.<p>Why this instead of yet another workflow builder?<p>- Declarative, not glue code: you state what to do; the runtime figures out how.
- Agent-first: each step carries natural-language context (purpose, inputs/outputs with meaning) so LLMs can follow, audit, and optimize. Our MCP server enables agents to run pipelines but also to build new pipelines on demand.
- Open standard under MIT: language spec, runtime, API server, editor extensions, MCP server, n8n node.
- Composable: pipes can call other pipes, created by you or shared in the community.<p>Why a domain-specific language?<p>- We need context, meaning and nuances preserved in a structured syntax that both humans and LLMs can understand
- We need determinism, control, and reproducibility that pure prompts can't deliver
- Bonus: editors, diffs, semantic coloring, easy sharing, search & replace, version control, linters…<p>How we got there:<p>Initially, we just wanted to solve every use-case with LLMs but kept rebuilding the same agentic patterns across different projects. So we challenged ourselves to keep the code generic and separate from use-case specifics, which meant modeling workflows from the relevant knowledge and know-how.<p>Unlike existing code/no-code frameworks for AI workflows, our abstraction layer doesn't wrap APIs, it transcribes business logic into a structured, unambiguous script executable by software and AI. Hence the "declarative" aspect: the script says what should be done, not how to do it. It's like a Dockerfile or SQL for AI workflows.<p>Additionally, we wanted the language to be LLM-friendly. Classic programming languages hide logic and context in variable names, functions, and comments: all invisible to the interpreter. In Pipelex, these elements are explicitly stated in natural language, giving AI full visibility: it's all logic and context, with minimal syntax.<p>Then, we didn't want to write Pipelex scripts ourselves so we dogfooded: we built a Pipelex workflow that writes Pipelex workflows. It's in the MCP and CLI: "pipelex build pipe '…'" runs a multi-step, structured generation flow that produces a validated workflow ready to execute with "pipelex run". Then you can iterate on it yourself or with any coding agent.<p>What’s included: Python library, FastAPI and Docker, MCP server, n8n node, VS Code extension.<p>What we’d like from you<p>1. Build a workflow: did the language work for you or against you?
2. Agent/MCP workflows and n8n node usability.
3. Suggest new kinds of pipes and other AI models we could integrate
4. Looking for OSS contributors to the core library but also to share pipes with the community<p>Known limitations<p>- Connectors: Pipelex doesn’t integrate with “your apps”, we focus on the cognitive steps, and you can integrate through code/API or using MCP or n8n
- Visualization: we need to generate flow-charts
- The pipe builder is still buggy
- Run it yourself: we don’t yet provide a hosted Pipelex API, it’s in the works
- Cost-tracking: we only track LLM costs, not image generation or OCR costs yet
- Caching and reasoning options: not supported yet<p>Links<p>- GitHub: <a href="https://github.com/Pipelex/pipelex" rel="nofollow">https://github.com/Pipelex/pipelex</a>
- Cookbook: <a href="https://github.com/Pipelex/pipelex-cookbook" rel="nofollow">https://github.com/Pipelex/pipelex-cookbook</a>
- Starter: <a href="https://github.com/Pipelex/pipelex-starter" rel="nofollow">https://github.com/Pipelex/pipelex-starter</a>
- VS Code extension: <a href="https://github.com/Pipelex/vscode-pipelex" rel="nofollow">https://github.com/Pipelex/vscode-pipelex</a>
- Docs: [<a href="https://docs.pipelex.com" rel="nofollow">https://docs.pipelex.com</a>](<a href="https://docs.pipelex.com/" rel="nofollow">https://docs.pipelex.com/</a>)
- Demo video (2 min): <a href="https://youtu.be/dBigQa8M8pQ" rel="nofollow">https://youtu.be/dBigQa8M8pQ</a>
- Discord for support and sharing: <a href="https://go.pipelex.com/discord" rel="nofollow">https://go.pipelex.com/discord</a><p>Thanks for reading. If you try Pipelex, tell us exactly where it hurts, that’s the most valuable feedback we can get.
Show HN: I made a heatmap diff viewer for code reviews
0github.com is a pull request viewer that color-codes every diff line/token by how much human attention it probably needs. Unlike PR-review bots, we try to flag not just by "is it a bug?" but by "is it worth a second look?" (examples: hard-coded secret, weird crypto mode, gnarly logic, ugly code).<p>To try it, replace github.com with 0github.com in any pull-request URL. Under the hood, we split the PR into individual files, and for each file, we ask an LLM to annotate each line with a data structure that we parse into a colored heatmap.<p>Examples:<p><a href="https://0github.com/manaflow-ai/cmux/pull/666" rel="nofollow">https://0github.com/manaflow-ai/cmux/pull/666</a><p><a href="https://0github.com/stack-auth/stack-auth/pull/988" rel="nofollow">https://0github.com/stack-auth/stack-auth/pull/988</a><p><a href="https://0github.com/tinygrad/tinygrad/pull/12995" rel="nofollow">https://0github.com/tinygrad/tinygrad/pull/12995</a><p><a href="https://0github.com/simonw/datasette/pull/2548" rel="nofollow">https://0github.com/simonw/datasette/pull/2548</a><p>Notice how all the example links have a 0 prepended before github.com. This navigates you to our custom diff viewer where we handle the same URL path parameters as github.com. Darker yellows indicate that an area might require more investigation. Hover on the highlights to see the LLM's explanation. There's also a slider on the top left to adjust the "should review" threshold.<p>Repo (MIT license): <a href="https://github.com/manaflow-ai/cmux" rel="nofollow">https://github.com/manaflow-ai/cmux</a>
Show HN: I made a heatmap diff viewer for code reviews
0github.com is a pull request viewer that color-codes every diff line/token by how much human attention it probably needs. Unlike PR-review bots, we try to flag not just by "is it a bug?" but by "is it worth a second look?" (examples: hard-coded secret, weird crypto mode, gnarly logic, ugly code).<p>To try it, replace github.com with 0github.com in any pull-request URL. Under the hood, we split the PR into individual files, and for each file, we ask an LLM to annotate each line with a data structure that we parse into a colored heatmap.<p>Examples:<p><a href="https://0github.com/manaflow-ai/cmux/pull/666" rel="nofollow">https://0github.com/manaflow-ai/cmux/pull/666</a><p><a href="https://0github.com/stack-auth/stack-auth/pull/988" rel="nofollow">https://0github.com/stack-auth/stack-auth/pull/988</a><p><a href="https://0github.com/tinygrad/tinygrad/pull/12995" rel="nofollow">https://0github.com/tinygrad/tinygrad/pull/12995</a><p><a href="https://0github.com/simonw/datasette/pull/2548" rel="nofollow">https://0github.com/simonw/datasette/pull/2548</a><p>Notice how all the example links have a 0 prepended before github.com. This navigates you to our custom diff viewer where we handle the same URL path parameters as github.com. Darker yellows indicate that an area might require more investigation. Hover on the highlights to see the LLM's explanation. There's also a slider on the top left to adjust the "should review" threshold.<p>Repo (MIT license): <a href="https://github.com/manaflow-ai/cmux" rel="nofollow">https://github.com/manaflow-ai/cmux</a>
Show HN: In a single HTML file, an app to encourage my children to invest
Show HN: In a single HTML file, an app to encourage my children to invest
Show HN: In a single HTML file, an app to encourage my children to invest
Show HN: Learn German with Games
I just started learning German, and it has been a frustrating experience, to say the least. There are so many seemingly arbitrary rules that make pattern recognition very difficult. Therefore, I have been looking for ways to make memorization a bit easier and fun. So, I came up with a bunch of games to make learning German a bit more engaging. Hope you find it useful as well!
Show HN: Learn German with Games
I just started learning German, and it has been a frustrating experience, to say the least. There are so many seemingly arbitrary rules that make pattern recognition very difficult. Therefore, I have been looking for ways to make memorization a bit easier and fun. So, I came up with a bunch of games to make learning German a bit more engaging. Hope you find it useful as well!
Show HN: Bash Screensavers
A github project to collect a bunch of bash-based screensavers/visualizations.
Show HN: Bash Screensavers
A github project to collect a bunch of bash-based screensavers/visualizations.
Show HN: Write Go code in JavaScript files
I built a Vite plugin that lets you write Go code directly in .js files using a "use
golang" directive. It compiles to WebAssembly automatically.
Show HN: Write Go code in JavaScript files
I built a Vite plugin that lets you write Go code directly in .js files using a "use
golang" directive. It compiles to WebAssembly automatically.
Show HN: JSON Query
I'm working on a tool that will probably involve querying JSON documents and I'm asking myself how to expose that functionality to my users.<p>I like the power of `jq` and the fact that LLMs are proficient at it, but I find it right out impossible to come up with the right `jq` incantations myself. Has anyone here been in a similar situation? Which tool / language did you end up exposing to your users?
Show HN: JSON Query
I'm working on a tool that will probably involve querying JSON documents and I'm asking myself how to expose that functionality to my users.<p>I like the power of `jq` and the fact that LLMs are proficient at it, but I find it right out impossible to come up with the right `jq` incantations myself. Has anyone here been in a similar situation? Which tool / language did you end up exposing to your users?
Show HN: MyraOS – My 32-bit operating system in C and ASM (Hack Club project)
Hi HN, I’m Dvir, a young developer. Last year, I got rejected after a job interview because I lacked some CPU knowledge. After that, I decided to deepen my understanding in the low level world and learn how things work under the hood. I decided to try and create an OS in C and ASM as a way to broaden my knowledge in this area.<p>This took me on the most interesting ride, where I’ve learned about OS theory and low level programming on a whole new level. I’ve spent hours upon hours, blood and tears, reading different OS theory blogs, learning low level concepts, debugging, testing and working on this project.<p>I started by reading University books and online blogs, while also watching videos.
Some sources that helped me out were OSDev Wiki (<a href="https://wiki.osdev.org/Expanded_Main_Page" rel="nofollow">https://wiki.osdev.org/Expanded_Main_Page</a>), OSTEP (<a href="https://pages.cs.wisc.edu/~remzi/OSTEP" rel="nofollow">https://pages.cs.wisc.edu/~remzi/OSTEP</a>), open-source repositories like MellOS and LemonOS (more advanced), DoomGeneric, and some friends that have built an OS before.<p>This part was the longest, but also the easiest. I felt like I understood the theory, but still could not connect it into actual code. Sitting down and starting to code was difficult, but I knew that was the next step I needed to take!
I began by working on the bootloader, which is optional since you can use a pre-made one (I switched to GRUB later), but implementing it was mainly for learning purposes and to warm up on ASM. These were my steps after that:<p><pre><code> 1) I started implementing the VGA driver, which gave me the ability to display text.
2) Interrupts - IDT, ISR, IRQ, which signal to the CPU that a certain event occurred and needs handling (such as faults, hardware connected device actions, etc).
3) Keyboard driver, which enables me to display the same text I type on my keyboard.
4) PMM (Physical memory management)
5) Paging and virtual memory management
6) RTC driver - clock addition (which was, in my opinion, optional)
7) PIT driver - Ticks every certain amount of time, and also
8) FS (File System) and physical HDD drivers - for the HDD I chose PATA (HDD communication protocol) for simplicity (SATA is a newer but harder option as well).
For the FS I chose EXT2 (The Second Extended FileSystem), which is a foundational linux FS structure introduced in 1993. This FS structure is not the simplest,
but is very popular in hobby-OS, it is very supported, easy to set up and upgrade to newer EXT versions, it has a lot of materials online, compared to other
options. This was probably the longest and largest feature I had worked on.
9) Syscall support.
10) Libc implementation.
11) Processing and scheduling for multiprocessing.
12) Here I also made a shell to test it all.
</code></pre>
At this point, I had a working shell, but later decided to go further and add a GUI! I was working on the FS (stage 8), when I heard about Hack Club’s Summer of Making (SoM). This was my first time practicing in HackClub, and I want to express my gratitude and share my enjoyment of participating in it.<p>At first I just wanted to declare the OS as finished after completing the FS, and a bit of other drivers, but because of SoM my perspective was changed completely. Because of the competition, I started to think that I needed to ship a complete OS, with processing, GUI and the bare minimum ability to run Doom. I wanted to show the community in SoM how everything works.<p>Then I worked on it for another 2 months, after finishing the shell, just because of SoM!, totalling my project to almost 7 months of work. At this time I added full GUI support, with dirty rectangles and double buffering, I made a GUI mouse driver, and even made a full Doom port! things I would've never even thought about without participating in SoM.<p>This is my SoM project: <a href="https://summer.hackclub.com/projects/5191" rel="nofollow">https://summer.hackclub.com/projects/5191</a>.<p>Every project has challenges, especially in such a low level project. I had to do a lot of debugging while working on this, and it is no easy task. I highly recommend using GDB which helped me debug so many of my problems, especially memory ones.<p>The first major challenge I encountered was during the coding of processes - I realized that a lot of my paging code was completely wrong, poorly tested, and had to be reworked. During this time I was already in the competition and it was difficult keeping up with devlogs and new features while fixing old problems in a code I wrote a few months ago.<p>Some more major problems occurred when trying to run Doom, and unlike the last problem, this was a disaster. I had random PFs and memory problems, one run could work while the next one wouldn’t, and the worst part is that it was only on the Doom, and not on processes I created myself. These issues took a lot of time to figure out. I began to question the Doom code itself, and even thought about giving up on the whole project.<p>After a lot of time spent debugging, I fixed the issues. It was a combination of scheduling issues, Libc issues and the Qemu not having enough (wrongfully assuming 128MB for the whole OS was enough).<p>Finally, I worked throughout all the difficulties, and shipped the project! In the end, the experience working on this project was amazing. I learned a lot, grew and improved as a developer, and I thank SoM for helping to increase my motivation and make the project memorable and unique like I never imagined it would be.<p>The repo is at <a href="https://github.com/dvir-biton/MyraOS" rel="nofollow">https://github.com/dvir-biton/MyraOS</a>. I’d love to discuss any aspect of this with you all in the comments!
Show HN: MyraOS – My 32-bit operating system in C and ASM (Hack Club project)
Hi HN, I’m Dvir, a young developer. Last year, I got rejected after a job interview because I lacked some CPU knowledge. After that, I decided to deepen my understanding in the low level world and learn how things work under the hood. I decided to try and create an OS in C and ASM as a way to broaden my knowledge in this area.<p>This took me on the most interesting ride, where I’ve learned about OS theory and low level programming on a whole new level. I’ve spent hours upon hours, blood and tears, reading different OS theory blogs, learning low level concepts, debugging, testing and working on this project.<p>I started by reading University books and online blogs, while also watching videos.
Some sources that helped me out were OSDev Wiki (<a href="https://wiki.osdev.org/Expanded_Main_Page" rel="nofollow">https://wiki.osdev.org/Expanded_Main_Page</a>), OSTEP (<a href="https://pages.cs.wisc.edu/~remzi/OSTEP" rel="nofollow">https://pages.cs.wisc.edu/~remzi/OSTEP</a>), open-source repositories like MellOS and LemonOS (more advanced), DoomGeneric, and some friends that have built an OS before.<p>This part was the longest, but also the easiest. I felt like I understood the theory, but still could not connect it into actual code. Sitting down and starting to code was difficult, but I knew that was the next step I needed to take!
I began by working on the bootloader, which is optional since you can use a pre-made one (I switched to GRUB later), but implementing it was mainly for learning purposes and to warm up on ASM. These were my steps after that:<p><pre><code> 1) I started implementing the VGA driver, which gave me the ability to display text.
2) Interrupts - IDT, ISR, IRQ, which signal to the CPU that a certain event occurred and needs handling (such as faults, hardware connected device actions, etc).
3) Keyboard driver, which enables me to display the same text I type on my keyboard.
4) PMM (Physical memory management)
5) Paging and virtual memory management
6) RTC driver - clock addition (which was, in my opinion, optional)
7) PIT driver - Ticks every certain amount of time, and also
8) FS (File System) and physical HDD drivers - for the HDD I chose PATA (HDD communication protocol) for simplicity (SATA is a newer but harder option as well).
For the FS I chose EXT2 (The Second Extended FileSystem), which is a foundational linux FS structure introduced in 1993. This FS structure is not the simplest,
but is very popular in hobby-OS, it is very supported, easy to set up and upgrade to newer EXT versions, it has a lot of materials online, compared to other
options. This was probably the longest and largest feature I had worked on.
9) Syscall support.
10) Libc implementation.
11) Processing and scheduling for multiprocessing.
12) Here I also made a shell to test it all.
</code></pre>
At this point, I had a working shell, but later decided to go further and add a GUI! I was working on the FS (stage 8), when I heard about Hack Club’s Summer of Making (SoM). This was my first time practicing in HackClub, and I want to express my gratitude and share my enjoyment of participating in it.<p>At first I just wanted to declare the OS as finished after completing the FS, and a bit of other drivers, but because of SoM my perspective was changed completely. Because of the competition, I started to think that I needed to ship a complete OS, with processing, GUI and the bare minimum ability to run Doom. I wanted to show the community in SoM how everything works.<p>Then I worked on it for another 2 months, after finishing the shell, just because of SoM!, totalling my project to almost 7 months of work. At this time I added full GUI support, with dirty rectangles and double buffering, I made a GUI mouse driver, and even made a full Doom port! things I would've never even thought about without participating in SoM.<p>This is my SoM project: <a href="https://summer.hackclub.com/projects/5191" rel="nofollow">https://summer.hackclub.com/projects/5191</a>.<p>Every project has challenges, especially in such a low level project. I had to do a lot of debugging while working on this, and it is no easy task. I highly recommend using GDB which helped me debug so many of my problems, especially memory ones.<p>The first major challenge I encountered was during the coding of processes - I realized that a lot of my paging code was completely wrong, poorly tested, and had to be reworked. During this time I was already in the competition and it was difficult keeping up with devlogs and new features while fixing old problems in a code I wrote a few months ago.<p>Some more major problems occurred when trying to run Doom, and unlike the last problem, this was a disaster. I had random PFs and memory problems, one run could work while the next one wouldn’t, and the worst part is that it was only on the Doom, and not on processes I created myself. These issues took a lot of time to figure out. I began to question the Doom code itself, and even thought about giving up on the whole project.<p>After a lot of time spent debugging, I fixed the issues. It was a combination of scheduling issues, Libc issues and the Qemu not having enough (wrongfully assuming 128MB for the whole OS was enough).<p>Finally, I worked throughout all the difficulties, and shipped the project! In the end, the experience working on this project was amazing. I learned a lot, grew and improved as a developer, and I thank SoM for helping to increase my motivation and make the project memorable and unique like I never imagined it would be.<p>The repo is at <a href="https://github.com/dvir-biton/MyraOS" rel="nofollow">https://github.com/dvir-biton/MyraOS</a>. I’d love to discuss any aspect of this with you all in the comments!
Show HN: MyraOS – My 32-bit operating system in C and ASM (Hack Club project)
Hi HN, I’m Dvir, a young developer. Last year, I got rejected after a job interview because I lacked some CPU knowledge. After that, I decided to deepen my understanding in the low level world and learn how things work under the hood. I decided to try and create an OS in C and ASM as a way to broaden my knowledge in this area.<p>This took me on the most interesting ride, where I’ve learned about OS theory and low level programming on a whole new level. I’ve spent hours upon hours, blood and tears, reading different OS theory blogs, learning low level concepts, debugging, testing and working on this project.<p>I started by reading University books and online blogs, while also watching videos.
Some sources that helped me out were OSDev Wiki (<a href="https://wiki.osdev.org/Expanded_Main_Page" rel="nofollow">https://wiki.osdev.org/Expanded_Main_Page</a>), OSTEP (<a href="https://pages.cs.wisc.edu/~remzi/OSTEP" rel="nofollow">https://pages.cs.wisc.edu/~remzi/OSTEP</a>), open-source repositories like MellOS and LemonOS (more advanced), DoomGeneric, and some friends that have built an OS before.<p>This part was the longest, but also the easiest. I felt like I understood the theory, but still could not connect it into actual code. Sitting down and starting to code was difficult, but I knew that was the next step I needed to take!
I began by working on the bootloader, which is optional since you can use a pre-made one (I switched to GRUB later), but implementing it was mainly for learning purposes and to warm up on ASM. These were my steps after that:<p><pre><code> 1) I started implementing the VGA driver, which gave me the ability to display text.
2) Interrupts - IDT, ISR, IRQ, which signal to the CPU that a certain event occurred and needs handling (such as faults, hardware connected device actions, etc).
3) Keyboard driver, which enables me to display the same text I type on my keyboard.
4) PMM (Physical memory management)
5) Paging and virtual memory management
6) RTC driver - clock addition (which was, in my opinion, optional)
7) PIT driver - Ticks every certain amount of time, and also
8) FS (File System) and physical HDD drivers - for the HDD I chose PATA (HDD communication protocol) for simplicity (SATA is a newer but harder option as well).
For the FS I chose EXT2 (The Second Extended FileSystem), which is a foundational linux FS structure introduced in 1993. This FS structure is not the simplest,
but is very popular in hobby-OS, it is very supported, easy to set up and upgrade to newer EXT versions, it has a lot of materials online, compared to other
options. This was probably the longest and largest feature I had worked on.
9) Syscall support.
10) Libc implementation.
11) Processing and scheduling for multiprocessing.
12) Here I also made a shell to test it all.
</code></pre>
At this point, I had a working shell, but later decided to go further and add a GUI! I was working on the FS (stage 8), when I heard about Hack Club’s Summer of Making (SoM). This was my first time practicing in HackClub, and I want to express my gratitude and share my enjoyment of participating in it.<p>At first I just wanted to declare the OS as finished after completing the FS, and a bit of other drivers, but because of SoM my perspective was changed completely. Because of the competition, I started to think that I needed to ship a complete OS, with processing, GUI and the bare minimum ability to run Doom. I wanted to show the community in SoM how everything works.<p>Then I worked on it for another 2 months, after finishing the shell, just because of SoM!, totalling my project to almost 7 months of work. At this time I added full GUI support, with dirty rectangles and double buffering, I made a GUI mouse driver, and even made a full Doom port! things I would've never even thought about without participating in SoM.<p>This is my SoM project: <a href="https://summer.hackclub.com/projects/5191" rel="nofollow">https://summer.hackclub.com/projects/5191</a>.<p>Every project has challenges, especially in such a low level project. I had to do a lot of debugging while working on this, and it is no easy task. I highly recommend using GDB which helped me debug so many of my problems, especially memory ones.<p>The first major challenge I encountered was during the coding of processes - I realized that a lot of my paging code was completely wrong, poorly tested, and had to be reworked. During this time I was already in the competition and it was difficult keeping up with devlogs and new features while fixing old problems in a code I wrote a few months ago.<p>Some more major problems occurred when trying to run Doom, and unlike the last problem, this was a disaster. I had random PFs and memory problems, one run could work while the next one wouldn’t, and the worst part is that it was only on the Doom, and not on processes I created myself. These issues took a lot of time to figure out. I began to question the Doom code itself, and even thought about giving up on the whole project.<p>After a lot of time spent debugging, I fixed the issues. It was a combination of scheduling issues, Libc issues and the Qemu not having enough (wrongfully assuming 128MB for the whole OS was enough).<p>Finally, I worked throughout all the difficulties, and shipped the project! In the end, the experience working on this project was amazing. I learned a lot, grew and improved as a developer, and I thank SoM for helping to increase my motivation and make the project memorable and unique like I never imagined it would be.<p>The repo is at <a href="https://github.com/dvir-biton/MyraOS" rel="nofollow">https://github.com/dvir-biton/MyraOS</a>. I’d love to discuss any aspect of this with you all in the comments!
Show HN: Diagram as code tool with draggable customizations
In the past I've used declarative diagram generation tools like Mermaid.js a lot for quickly drawing up things but for presentations or deliverables I find that I have to then move the generated diagrams over to a tool like Lucidchart which allows full control of the organization and customization.<p>Therefore I am now working on this to combine the benefits of both into just one tool which can do both functions.<p>The project is certainly in the early stages but if you find yourself making architecture diagrams I'd love to hear your thoughts on the idea or even a Github issue for a feature request!<p>One of the workflows I'm targeting is when an AI generates the first draft of the diagram (all the LLMs know .mmd syntax) and then the user can then customize it to their liking which I think can drastically speed up making complex diagrams!
Show HN: Diagram as code tool with draggable customizations
In the past I've used declarative diagram generation tools like Mermaid.js a lot for quickly drawing up things but for presentations or deliverables I find that I have to then move the generated diagrams over to a tool like Lucidchart which allows full control of the organization and customization.<p>Therefore I am now working on this to combine the benefits of both into just one tool which can do both functions.<p>The project is certainly in the early stages but if you find yourself making architecture diagrams I'd love to hear your thoughts on the idea or even a Github issue for a feature request!<p>One of the workflows I'm targeting is when an AI generates the first draft of the diagram (all the LLMs know .mmd syntax) and then the user can then customize it to their liking which I think can drastically speed up making complex diagrams!