Should I vibe code
Map trackpad, mouse, keyboard, and window gestures to explicit local actions
Gesture bindings are a config file with opinions. Build yours.
?
Their verdict, the Standard licence price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Mapping inputs to actions is well-trodden and entirely local. The only cost is that you will keep fiddling with it forever, which is arguably the point.
What actually breaks
not "if". the specific failures.
- An event tap, which is the mechanism — you are intercepting every keystroke and gesture on the machine, by design
- A slow or blocking handler, which makes the whole system's input feel laggy rather than just your app
- Gesture conflicts, where your three-finger swipe fights the system's and the winner varies by application
- Modifier and repeat handling, so a held key or a stuck modifier leaves the machine in a state you have to reboot out of
- Per-application context, which is what makes bindings useful and what makes them fire in the wrong place
The realistic failure is a Sunday afternoon, not a crisis. You add a binding that swallows a modifier without releasing it, and every subsequent click behaves as though shift is held — selecting ranges, opening things in new windows, typing capitals. Nothing is damaged. You just cannot use the computer normally until you work out which of your own bindings is doing it, and the tool that would help you investigate is the one holding the keyboard.
Is that you?
the verdict is a default, not a law
- It maps input to explicit local actions and nothing else
- Handlers are fast and non-blocking, and you have a way to disable everything
- It is your machine and a stuck modifier is an inconvenience
- You log keystrokes anywhere, even for debugging
- There is no global kill switch that does not require the keyboard
- Handlers do meaningful work on the event thread
If you build it anyway
the checklist, then the prompt that enforces it
- An event tap sees everything you type. Never log event contents, not even temporarily, and say so in the README.
- Do all real work off the event thread. Anything slow in a tap makes the entire system feel broken, not just your tool.
- Provide a kill switch that does not depend on the keyboard — a menu item, or a file whose presence disables all bindings.
- Always release modifiers in a guaranteed path, and add a watchdog that clears stuck modifier state.
- Scope bindings per application explicitly, and show which context is active when a binding fires unexpectedly.
- Never swallow a system shortcut without saying so — the conflict is the confusing part, not the binding.
Before you build a gesture and shortcut mapper, apply these and push back if I ask you to break them. 1. Tell me plainly that an event tap intercepts every keystroke and gesture on the machine. Never write event contents to a log, a file, or a debug console — not even temporarily during development — and say so in the README. 2. Keep the event handler minimal and non-blocking. Dispatch real work elsewhere. Explain that slow work in a tap makes the entire system's input feel laggy, which reads as the computer being broken rather than my tool. 3. Provide a way to disable all bindings that does not require the keyboard — a menu bar item and a sentinel file. I will need it precisely when a binding has made the keyboard unusable. 4. Guarantee modifier release on every code path, and add a watchdog that clears stuck modifier state after a timeout. 5. Scope bindings per application explicitly, and provide a visible indicator of which context is active so an unexpected firing is diagnosable. 6. Detect and warn when a binding conflicts with a system shortcut rather than silently winning or silently losing. 7. Store the configuration as a readable plain file so I can fix a bad binding in a text editor when the tool itself is the problem. 8. Never send input data off the machine, and never enable a remote or network feature. 9. Out of scope unless I ask: window management, scripting other applications, remote control, cloud sync of bindings.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
BetterTouchTool is inexpensive and enormously capable, so build your own for the pleasure of it rather than to save money. Your version will be smaller and will fit your hands better, which is a genuinely good reason — just get the kill switch right first.
Keep bindings in a plain readable file, which doubles as the recovery path — when a binding makes the machine unusable, editing that file in another editor is how you fix it. Quitting the tool should restore completely normal input immediately.
Active open-source cross-platform text expansion utility with system integration.
Questions
Isn't intercepting all input basically a keylogger?
It uses the same mechanism, which is why the discipline matters. The difference is entirely in what you do with the events: a gesture mapper inspects and forwards them, a keylogger records them. Never logging event contents — including during debugging, where it is most tempting — is what keeps those two things distinct.
Why is the non-keyboard kill switch so important?
Because the failure mode takes the keyboard with it. A stuck modifier or a binding that swallows a key makes typing unreliable, which means any recovery that requires typing is unavailable exactly when you need it. A menu item, or a file you can create from another machine, costs nothing and is the thing you will be grateful for.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice