I Replaced Calendly With Agents. Here Are the Receipts.

The Content Engineer

SubscribeSign in

I Replaced Calendly With Agents. Here Are the Receipts.<br>Ten days, one Cloudflare Worker, $0 a month, 162 commits, 737 tests - and 14 real bugs the tests never saw. What actually decides whether agent-written code is right.

Serge Bulaev<br>Aug 23, 2026

Share

We paid $60 a month for Calendly. Three people, one job: a link that shows when I am free.<br>I asked Claude for an open-source alternative and was told nothing serious was left. Half true. Cal.com did relicense to cal.diy under MIT in April 2026, but the same commit cut teams, workflows, insights and SSO: minus 411,000 lines. The second line of their own README says strictly recommended for personal, non-production use. No release since March, Docker images archived, and standing it up still wants a server with Node and PostgreSQL.<br>So I built one. Started on a Saturday, on Cloudflare, because at our volume it is free and I am still a fan.<br>Ten days later: 162 commits, 30,658 lines of TypeScript across 85 files, 737 test assertions, 60 Linear tickets, one Worker, $0 a month. Google Calendar and Microsoft 365, .ics emails and reminders, teams with round-robin and collective scheduling, REST API, webhooks, an embed widget, and an MCP server so agents can book meetings too. MIT, live at punctual.sh, currently 56 stars.

That is the part people screenshot. Here is the part they do not.<br>TL;DR Agents write code fast. Nothing they produce tells you whether it is right. I bought that answer in two places: a review process adversarial by construction (two models, severity triage, hard time box), and a platform where whole classes of bug are not expressible. When a machine writes the code, prefer a constraint the database enforces over a protocol the code must remember.

1. The number that matters is not 162

On day five I ran the two-model review from chapter 3 against the entire codebase history rather than the latest diff. It surfaced 15 candidate findings. 14 were real.

The headline one: team-owned event types, a flagship feature with green domain tests, returned 404 on every single HTTP request. One join in one query quietly dropped every row that belonged to a team rather than a person. Perfectly tested at the domain layer, completely unreachable through the product.<br>Underneath it: Microsoft conflict-checking silently broken (wrong identifier type fed to Graph's getSchedule), REST cancel and reschedule never firing webhooks, the per-day cap undercounting collective hosts across timezone boundaries. Plus two regressions from my own first round of fixes, caught by a second pass the same day.<br>That is what 737 passing tests look like from the inside. Tests written by the agent that wrote the code check what the agent believed it was building, not whether the feature is reachable from outside the process.<br>So the question stopped being whether agents can write code. It is what independent thing tells you they got it right.

2. The constitution

Every repo has a CLAUDE.md. This one is not documentation, it is enforcement, and four rules earn their place.

The public boundary. engine/ is public the moment it is pushed, so strategy, pricing and customer data never go in, commit messages and code comments included. An agent holding your strategy doc in context will paste it into a public README as helpful background, and git history keeps it forever.<br>A ticket before code. Every non-trivial change gets a Linear issue first, 60 of them in ten days. It is the only place the reasoning survives a context window ending.<br>Commits are per repo, English everywhere. Four repos under one workspace, so one git add never covers it, and private notes stay in English because translating at the boundary is where meaning gets lost.<br>None of this is for the agent's benefit. It is blast radius.

3. Two reviewers that fail differently

tools/review.sh puts Codex and Claude on the same diff, in parallel. Two models because they fail differently: Codex tends to catch driver-level and ordering problems, Claude catches domain-invariant and consistency ones. On that 15-finding run, 8 came from Codex, 7 from Claude, exactly one overlapped.<br>Three rules make it usable instead of a tax.<br>Fix P0 through P2. Never fix P3. P0 is data loss, a security hole or a broken invariant. P1 is a user-visible feature broken or silently wrong. P2 is wrong under a realistic edge case: a DST boundary, a concurrent request, a provider error. P3 is style, naming and "consider", and both reviewers are told to omit it entirely rather than list it. A review that reports everything gets ignored wholesale, which is worse than one that reports less.<br>The time box is hard. 600 seconds each, killed at the deadline, partial report delivered rather than blocking the branch. Re-running until clean is the failure mode this replaces.<br>The script fixes nothing. It emits a report a human acts on. Auto-applying review findings is how a...