Should I vibe code
Watch selected folders and apply transparent file rules with previews and logs
A file rule with a bad glob doesn’t warn you. It quietly moves your tax returns somewhere.
?
Their verdict, the Hazel 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
Watching a folder and applying rules is a fifty-line script. The problem is that the script’s mistakes are silent, immediate and applied to every matching file before you notice the pattern was wrong.
What actually breaks
not "if". the specific failures.
- A glob that matches more than you intended, applied instantly to everything
- A rule that fires on partially-written files while they are still downloading
- Two rules that disagree, moving a file back and forth forever
- Silent operation — you find out weeks later that something has been quietly filing your documents wrong
You are looking for last year’s tax return. It is not in Documents. It is not in the folder the rule was supposed to put it in either, because the rule matched on a substring that also appears in a client’s name, and eleven months of paperwork has been sorted into a directory you have never opened. Nothing errored. Nothing was logged. It just worked, confidently, on the wrong pattern.
Is that you?
the verdict is a default, not a law
- Rules only ever move files, never delete them
- Every action is logged somewhere you will actually look
- You have run it in dry-run mode over your real folders first
- Any rule can delete, and there is no trash
- It watches a folder that syncs to cloud storage, where a rename becomes a re-upload
If you build it anyway
the checklist, then the prompt that enforces it
- Move to trash, never unlink. The OS trash is a free undo and you should use it.
- Dry-run is the default. Live mode needs an explicit flag every time.
- Log every action with source and destination paths, to a file you keep.
- Debounce on file stability — do not act on a file whose size changed in the last few seconds.
- Cap actions per run and bail out loudly if a rule suddenly matches far more than usual.
- Never let two rules claim the same file. Detect the conflict and stop.
I want a folder-watching file automation tool. The danger here is silent wrongness, so: 1. Dry-run is the default mode and prints a table: file, matched rule, intended action, destination. Live mode requires an explicit --live flag on every invocation. 2. Never call unlink. Deletion means moving to the OS trash, always, with no configuration option to change that. 3. Before acting on a file, confirm it is stable: the size and mtime must be unchanged across two checks a few seconds apart. Do not act on partial downloads. 4. Append every action to a log file with an ISO timestamp, the rule name, the source path and the destination path. Then write an 'undo' command that reads that log backwards and reverses moves. 5. Add a sanity cap: if a single run would act on more than N files (default 20), stop and print what it would have done instead. A rule that suddenly matches everything is a bug, not a busy day. 6. Detect overlapping rules at load time — if two rules could match the same file, refuse to start and tell me which ones. 7. Rules live in a plain config file I can read and diff. No binary state, no hidden database. 8. Add a --explain flag that takes a path and tells me which rules would match it and why, without doing anything.
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
Not really necessary here — this is a good build. The paid tools mostly win on the rule-editing interface, which matters less when you are the only person writing rules.
The action log is the exit plan. As long as every move is recorded with both paths, you can reverse the entire history of the tool with a script, which is the difference between a bad rule being an annoyance and being a loss.
Active open-source cross-platform text expansion utility with system integration.
Questions
Why is a file organiser riskier than the tools rated below it?
Because it acts without being watched, its mistakes are silent, and by the time you notice, the pattern has been applied hundreds of times. Most tools fail loudly. This category fails quietly, which is worse.
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