Should I vibe code
AI calendar and task scheduler that auto-plans your workday
Writing the scheduler is a weekend. Believing it at 8am on a Monday six months later is the whole product.
?
Their verdict, the Pro AI (Individuals) price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
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
There is a scheduler in here that an agent will write in an afternoon: sort by deadline and priority, walk the free/busy list, drop blocks into the gaps. It works, and watching your week assemble itself is a real thrill. But the product is not the scheduler — it is the willingness to close the task list and believe the calendar. That requires stability (same inputs, same plan, no thrash), a hard line around events it must never move, and a loud failure when a deadline stops fitting rather than a quiet shuffle past it. Yours will re-plan at 6am, move a block that turned out to be your dentist, and drop one task with no error anywhere. You will find out the week after the deadline.
What actually breaks
not "if". the specific failures.
- Thrash. A greedy re-planner produces a different arrangement on almost every run, and if those blocks live on a real calendar, every run is a fresh set of change notifications to anyone who shares it
- The silent drop. A task that fits nowhere is simply not placed. No exception, no banner, no row anywhere saying 'this deadline is now unreachable' — it just quietly stops appearing
- The line between what it owns and what it must not touch. Without a tag on every event it created, 'clear the afternoon' also clears the appointment you made in person three weeks ago
- Free/busy read as a snapshot. You accept an invite on your phone while the solver is running, and it schedules straight over it because it planned against a view that was ninety seconds old
- Your duration estimates, which are wrong. Auto-scheduling is a rubbish-in problem, and the real products spend their effort on nudging humans toward better inputs rather than on the solver
- The bill, if there is a model in the planning loop. Re-planning every fifteen minutes across every open task is a background job with a credit card attached
Is that you?
the verdict is a default, not a law
- It proposes a plan and you press accept — no autonomous writes, ever
- It writes only into a dedicated calendar it owns, with nothing else in it and nobody else on it
- You would still notice a missed deadline without it, because your real list lives somewhere else
- A cron job rewrites your calendar while you are asleep
- It can move or delete an event it did not create
- You would trust it to remember a filing date, a renewal or anything with a penalty attached
- Colleagues subscribe to the calendar it writes to
If you build it anyway
the checklist, then the prompt that enforces it
- Propose, don't apply. A plan the human accepts is 95% of the value and 5% of the risk, and it is the version you will still be running next year.
- Every event your scheduler creates carries your own identifier. Anything without that tag is immovable, full stop, and that rule gets a test before the solver gets a feature.
- Make the planner deterministic and idempotent: same inputs, same output. Then diff plan-to-plan and refuse to apply a change below a churn threshold.
- Unschedulable tasks are the most important output. Surface them at the top of the UI as 'this will not fit', never as an empty result.
- Re-read free/busy immediately before writing, not at the start of the planning run, and abort on any conflict that appeared in between.
- Cap writes per day and put a kill switch in an environment variable, so a runaway loop is one restart rather than four hundred calendar notifications.
- Use a real RRULE library, store UTC plus an IANA zone, and encode working hours explicitly instead of assuming 9 to 5 in your own timezone.
I am building an auto-scheduler that places my tasks into my calendar. Apply these before writing the solver, and push back if I ask you to relax one.
1. Default to propose-and-confirm. The scheduler produces a plan; I approve it;
only then does anything get written. Do not add autonomous or scheduled
application until I ask for it by name.
2. All writes go into one dedicated calendar that this app creates and owns.
Never write to my primary calendar, and never to an event with attendees.
3. Tag every created event with an application id in the provider's extended
properties. Treat any event without that tag as immovable. Write that test
before any scheduling logic exists.
4. The planner must be deterministic: identical inputs produce an identical
plan. No randomised tie-breaking, no wall-clock in the ordering key.
5. Before applying, compute a diff against the currently applied plan and show
it to me. If fewer than N blocks changed, apply nothing — calendar churn is
the failure mode I care about most.
6. Unschedulable tasks are a first-class result, not an empty list. Return the
set of tasks that did not fit, with the reason, and render it above the
calendar.
7. Re-fetch free/busy immediately before each write and abort the whole apply
if anything changed since planning. Never trust a snapshot taken at the
start of the run.
8. Hard cap the number of event writes per day and read that cap plus a global
kill switch from the environment, so a loop costs me one restart rather
than four hundred notifications.
9. Never delete an event. Move it, or mark the block cancelled, so that every
destructive action is recoverable from the calendar's own history.
10. Store times as UTC instants plus an IANA timezone, use a real RRULE
library for recurrence, and make working hours, buffers and minimum block
length explicit configuration rather than constants in the solver.
11. If a model is used for planning, log every call with its cost, cap spend
per day, and never re-plan more often than the config allows.
12. Say in the README that this is a planning aid and not a system of record
for deadlines, and that Motion is $29 a month on the annual individual
plan if I want to actually trust one.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
When you want to stop checking its work. Motion is $49 a month month-to-month for a solo user, $29 if you commit to a year, and it is expensive precisely because the hard part is behavioural rather than algorithmic: stability, sane defaults, and the nagging that makes your estimates less fictional. Reclaim covers the same ground more cheaply, and both are worth more than a scheduler you have to audit every morning.
$49/mo is cheaper than your weekend.
Keep tasks in a store that is not the scheduler — a plain table, a Todoist project, anything with its own export — so that the planner is a stateless function over data you still own. Then the exit is deleting the dedicated calendar it wrote to, which removes every block in one action and leaves your real appointments untouched. If your tasks only exist inside the scheduler, you do not have an exit, you have a migration.
Self-hostable open-source auto-scheduler explicitly built as a Motion alternative; its own README still warns that it is in active development and buggy.
Questions
Auto-scheduling is just bin packing. Why isn't this a solved weekend?
Bin packing is solved. Bin packing that a human will trust is not. The scheduler has to produce nearly the same plan every run so your week stops moving under you, has to know which blocks are sacred, has to fail loudly when a deadline no longer fits, and has to be right about durations it was never given honestly. None of that is algorithmically hard and all of it is where the months go.
What is the version actually worth building?
A proposer. It reads your tasks and your free/busy, prints tomorrow's plan, and you either accept it into a dedicated calendar or ignore it. You keep the whole interesting problem, nothing writes without a human, and if the solver has a bad day you close the tab instead of apologising to a meeting.
How do I stop it from moving things it shouldn't?
Ownership tags, enforced as an invariant rather than a filter. Every event your app creates gets your identifier in the calendar's extended properties, and the mutation layer physically refuses to touch anything else. Do this before the scheduler exists, because retrofitting it after the first accidental deletion is not the same as having had it.
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.
Read-only calendar tools give advice. This one holds a write token to a calendar your colleagues can see.
A booking link publishes your availability to the internet. Rate-limit it before you share it.
The overlay is the product. Drawing it means holding a stranger's calendar credential, for the sake of a nicer grid.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice