If you’re anything like me, you love music.
You constantly listen to it while working or relaxing, you whistle some while riding your bike, you hum it to yourself while showering.
Unfortunately, you don’t play it on an instrument because life hasn’t found it necessary to burden you with the ability to do so. You did at some point buy a second-hand guitar, went through some lessons, but that didn’t last because your progress was much slower than you’d hoped for. You’ve since forgotten all the chords, and it’s sitting in a closet somewhere next to the umbrellas.
That’s a shame because you keep having various tunes stuck in your head and have no real way to get them out. If you want to make a tune, you need to go to BandLab and click on random keyboard keys until it sounds right because you don’t read/write notes or know what “in key” means.
No more!
What’s Diapason?
Diapason is a small in-browser tool which allows you to whistle or hum a tune into your mic, then have it intuit what you were going for as best it can, giving you a solid MIDI file.
The name comes from diapason, which is a tuning fork in Italian and French.
Features include:
- totally private, everything is on your device unless you explicitly share it
- recording a mic feed with live view with a wizard-like UI, optimized for whistling and humming
- sophisticated audio processing allowing for automatically detecting the audio key, pitch and timing correction
- various presets allow to easily apply various corrections or change the mood in bulk
- detailed sliders and dropdowns to continue fine-tuning what the presets start with, adjustable instrument, octave, or key
- integration with actual MIDI instruments using Web MIDI API
- embeddable, styleable, usable on desktops, tables, phones, touch, mouse, keyboard
Try it yourself
This is a fully functional demo:
How was Diapason built?
Diapason was built in a fully agentic way (AKA vibe coded) to test out various state-of-the-art approaches and skills available for
this type of development. The agents I used were Anthropic’s Claude Code using opus-5.5 and OpenAI’s Codex using sol-6.1.
The primary skills used were superpowers and impeccable.
The artifacts the skills created can be seen in the repo itself.
Rules are executable
The rule I’ve used on this and other projects with great success is realizing coding agent’s AGENTS.md is just a pinky promise:
it’s just a text file stating a goal. The agent doesn’t need to follow that goal, it might choose not to or forget about it
as the context gets filled.
This is why my AGENTS.md always includes:
This rule applies to every suggestion, refactor, or new pattern you introduce — always.
Executable tool > Agent skill > Written guideline > Nothing
When proposing or implementing any rule, convention, or best practice, assign it to the highest tier you can reach.Agents must figure out a way to make the work happen without themselves doing it. If there’s a tool which can find an issue
(e.g. oxlint with a custom AST rule), the agent must prefer that over just updating a skill file or doing it manually.
This makes the rules executable by the developer, CI and subsequent agentic sessions, highly improving the output.
Issues while building
A large gap in understanding the domains means my prompts are very verbose and hand-wavy due to me needing to explain a musical concept with paragraphs of text, upon which the agent says
You probably meant anacrusis.
to which I got to be honest - I’m not exactly sure that I did. Maybe?
If this was software engineering, it would be a word like monotonic, invariant or debounce: it’s a single word which covers two paragraphs of semantics, saying the word is not only very efficient, it’s super precise. This is because all those words in those two implicit paragraphs are transferred atomically (another such word).
You rely on the agent being able to recognize your intent by your vague (and probably partially incorrect) descriptions of things you don’t know the names of.
Conclusion
In the future, not knowing the domain you’re working in well enough to communicate within it efficiently, but also not having the incentive to learn it deeply enough to be able to will be the key to most of the problems we’ll encounter.
Strict, executable guardrails are what keep agents on track. With them in place, we actually can build in domains we’re not experts in, and the result will be just like my whistling: close enough to work.