Hacker News Reader

Comment by Bishonen88 | Hacker News Reader

Looking at the Screenshots, this would've taken days/weeks e.g. 5 years ago. Now this seems to be vibe coded in 2 sessions. Crazy world we live in.

View on HN

Ha! I appreciate the compliment (I think?). To be transparent: yes, AI tools were used during development — they're fantastic for boilerplate, documentation, and exploring unfamiliar APIs.

But this wasn't "2 sessions" — Ferrite has been in development for months with ~30,000 lines of Rust across 50+ modules. The Mermaid renderer alone is ~6000 lines of layout algorithms (Sugiyama-style graph layout, sequence diagram activation tracking, nested state machines, etc.).

AI helped ALOT, but there's no "generate full app" prompt that produces working text editors with native diagram rendering, rope-based text buffers, and custom window chrome. Still takes understanding the domain.

That said, you're right that the development velocity is higher than 5 years ago. Exciting times!

Yep, it always seems easy from the outside until you start doing it. Then unless you are doing a crud web app you quickly run into issues where unless you know what you are doing- Claude Code won’t help you.

Exactly. The AI is great at "write me a function that does X" or "convert this to async." It struggles with: - Graph layout algorithms (crossing minimization, layer assignment) - State machine interactions (how does undo interact with sync scroll when switching view modes?) - Performance debugging (why is syntax highlighting slow on scroll?)

The domain knowledge still matters. AI just compresses the boilerplate time.

I want to see the work done by human beings, not just the AI output. "Open source" to me is sharing the input required, idealistically as much as possible. Without including at least prompts and separating AI output from manual revisions this GitHub repo feels more like publishing "open weights" does, definitely useful but for the most part only for its intended purpose instead of also teaching how to do something similar myself. (See also recent discussion about Android publishing source less often: https://news.ycombinator.com/item?id=46524379)

None of this should be considered critical of this project specifically, very few share "how the sausage is made". You're breaking new ground with a comment about being AI generated prominent in the README, I hope that catches on.

> "Open source" to me is sharing the input required [...]

I don't disagree with your sentiment, I am also more interested in human-written projects, but I'm curious about how this works. Would a new sorting network not be open source if found by a closed source searching program, like AlphaDev? Would code written with a closed source LSP (ie. Pylance) not be open source even if openly licenced? Would a program written in a closed source language like Mojo then be closed source, no matter what the author licences it under? The line between input and tool seems arbitrary at best, and I don't see what freedoms are being restricted by only releasing the generated code.

the line is blurry for shure. Code generated by a closed-source compiler (or LSP) is still 'your' code. Maybe the difference is whether humans can reproduce and learn from the process? With traditional code, you can read commit history and understand the author's thinking. With AI-generated code, that context is lost unless explicitly shared. Food for thought.

Great point about sharing the 'how' not just the 'what'. I'll consider adding prompt history or a development log showing the AI interactions, just have to figure out how to present all the data i guess. The commit messages could definitely include more context about what was requested vs generated. Thanks for the thoughtful framing,'open weights vs open source' is a useful distinction

Done! I just published the full workflow documentation today:

AI Development Workflow: Complete explanation of the process, handover system, how I manage context between sessions

Historical PRDs: The actual Product Requirements Documents used to generate tasks (v0.1.x through v0.3.0)

Task JSON files: How requirements were broken down into implementable tasks via Task Master

Handover templates: The reusable prompts I use to maintain context between AI sessions

Thanks for pushing on transparency, your comment about "open weights vs open source" is a useful framing. The goal is to share enough that someone could reproduce and learn from the approach.

It can be vibe-coded quickly but can also be done rather quickly without ai - the heavy lifting is UI lib from Zed. That is the real unlock in apps like this.

Small correction: Ferrite uses egui (by Emil Ernerfeldt), not anything from Zed. Different ecosystem entirely.

- Zed uses their own gpui framework - Ferrite uses egui — an immediate-mode GUI library

egui is great for rapid development but has limitations. The v0.3.0 custom editor widget is specifically because egui's built-in TextEdit blocks features like proper multi-cursor and code folding. We're not getting much "for free" there — the Mermaid renderer, syntax highlighting integration, and view synchronization are all custom.

That said, egui definitely accelerated the initial UI work. Credit where due!

You are right, my bad.

Reply on news.ycombinator.com