When Open Source Is Only a Prompt: I Found a Ridiculous New Way to Open Source

Recently, while wandering around GitHub, I came across a project that felt both shocking and funny: voice-input-src. It is a voice input tool built for Mac.

When you opened the repository, you will not find any traditional Swift source code. Instead, the repo contains only an extremely detailed prompt written for AI, specifically Claude, with both Chinese and English instructions.

That made me curious: Can this kind of open source actually work? Can users really reproduce a usable app from this? Since I happen to have a MacBook, I decided to try reproducing it on my own machine and see whether this open-source model was feasible.

---

Project Breakdown: Is This Really "Source Code"?

1. An Extremely Minimal Repository

The project has a README.md file containing the required prompt text, and nothing else.

I have to admit, this kind of open-source project is very easy to understand.

2. Prompt as Source Code

Traditional open source is "humans read code, compilers execute code." This project is more like "humans read the prompt, AI executes the prompt."

The author, yetone, even created a separate voice-input-dist repository to store the app source code generated by AI. This cleanly separates the "source" from the "artifact," and it also makes comparison easier for users.

It is a small but interesting design choice.

What Is Hidden Inside the Prompt?

Since the prompt is basically the only thing we can inspect in this repository, I analyzed it before trying to reproduce the project.

This is not a casual requirement document written by someone who knows nothing about programming. It is a document written by someone who clearly understands macOS APIs and implementation details.

From these details, it is clear that the author knew exactly which frameworks to call, which components to use, what conflicts might appear later, and how those conflicts should be handled.

Because the author understands the technical background and implementation difficulties well enough, he could write such a precise project-level prompt. One GitHub issue even commented:

This thing is the real prompt development tutorial.

My Reproduction Attempt on My Mac

To verify whether this kind of open source is actually effective, and also to experience this slightly wild form of prompt engineering, I ran a complete "from prompt to app" experiment on my Mac.

1. Environment

• Mac: My 2021 M1 Pro MacBook, running Tahoe 26.3.1.
• AI tool: Codex, using GPT 5.4 Extra High. I wanted to see whether a model different from the author's Claude setup could still succeed.

Here is my device configuration:

2. Steps

1. Feed the prompt: Send the full prompt from the repository to Codex.
2. Functional acceptance testing: Definitely not because I do not know Swift well enough to read all the generated code.

Checklist:

✅ Can the Fn key reliably start recording without opening the emoji panel? ✅ Does the floating waveform change in real time with volume? ✅ How accurate is Chinese recognition? Does LLM correction work?

3. Actual Implementation

On my machine, the app did not build successfully on the first attempt. The first full build took about 23 minutes and cost $1.3994 USD. After that, two small runtime/build issues appeared, so I asked Codex to fix them twice. Including fixes, the total cost was $1.9734 USD.

Here is Codex's summary of the two fixes:

These two fixes essentially solved one compile-time problem and one runtime crash.

The first fix was in PasteboardInjector.swift line 18. The original code used an expression like pasteboard.pasteboardItems?.map { ... } ?? [], relying on Swift to infer the type of items. In some cases, this optional chain plus empty-array fallback made type inference unstable, eventually causing an error at return PasteboardBackup(items: items). The fix was simple: explicitly write items as [Item]. This did not change any business logic; it only replaced "let the compiler guess" with "tell the compiler the type directly."

The second fix was in FloatingPanelController.swift line 93. The original code set collectionBehavior = [.canJoinAllSpaces, .fullScreenAuxiliary, .moveToActiveSpace, .ignoresCycle]. The issue is that .canJoinAllSpaces and .moveToActiveSpace conflict semantically. One means "join all Spaces," while the other means "move with the currently active Space." AppKit is sensitive to this kind of window behavior combination, and it can trigger an assertion that ends as an abort signal crash. The fix changed it to a more stable combination: keep .moveToActiveSpace, .fullScreenAuxiliary, and .ignoresCycle, add .transient, and remove .canJoinAllSpaces. The floating window can still appear in the current Space and alongside full-screen apps, but it no longer crashes during initialization.

Result

You can probably guess it: this entire article was dictated using the generated app.

The effect is actually pretty good. Characters appear quickly, faster and more immediate than Apple's built-in dictation, and invoking it is more convenient.

Here is what it looked like:

As for shortcomings, you can see that the text was not centered nicely at first, which felt a bit uncomfortable. I later prompted Codex to fix that too. Overall, my version still did not look as polished as the author's Claude-generated demo, but at least it worked.

Is This the Future of Open Source, or Just a Joke?

1. The Positive View: Extreme DRY

• Very low maintenance cost: The author does not need to care about Xcode version changes or Swift syntax evolution. He only provides a requirements document.
• Reproducibility: As long as the AI model is capable enough, anyone can generate a functionally similar app at any time.
• Easy sharing: This way of sharing is direct. Compared with publishing a huge codebase vibe-coded from scratch, a carefully written prompt may actually be cleaner in some cases.

2. The Slightly Negative View

• Uncontrollability: Generated code quality depends heavily on the AI model. It is hard to guarantee identical results every time. My Codex version was usable, but visually not as good as the author's demo.
• Operational friction: To generate the code, users still need an AI environment and enough budget. For small projects this is fine, but larger projects can become expensive. Users also have to wait for generation, which is less convenient than downloading a release from the author.

Overall, I do not think this experiment is a bad thing. On the contrary, the author's creative repo structure gave me a small shock.

Maybe this should be understood less as a concrete project distribution method and more as an excellent AI tutorial. To write a prompt like the author's, you still need solid technical knowledge and a clear understanding of the target platform.

At least for me, I definitely could not write such a perfect prompt in one shot.

If you have some spare time, I recommend trying it yourself.