Let AI Write the Booking Logic, Then Review It Like a Senior Developer

When AI Takes Over the Trickiest Piece of a Booking System

The hardest part of a booking system isn't the UI—it's the logic that decides whether a given time slot can actually be booked. It has to handle 30-minute time steps, time-range overlap detection, past-time filtering, and correct conversion across time zones. In episode 16 of this series, the author had already hand-written the time slot selector; now the same task is handed to AI to redo, and then verified item by item the way a senior developer would.

The workflow itself is worth noting: the value of AI-written code isn't getting it right the first time—it's how quickly and systematically you can find where it's wrong.

The Prompt Sets the Floor for the Code

The author's prompt explicitly lists several key inputs: a 30-minute time step, overlap detection, past-time filtering, and a specified time zone library. The original article has a very blunt warning about this: vague prompts get you 3 a.m. bookings.

This is the most typical failure mode for booking-type features. Constraints like time slot boundaries, time zone attribution, and past times, if not written into the prompt, will lead the model to generate code based on the "smoothest" default logic—and those defaults are almost always wrong in real-world scenarios. Making constraints explicit is essentially translating test cases into requirement descriptions ahead of time.

Three Reviews: Verifying Like a Senior Developer

After the code was generated, the author didn't just run it to see the result—he performed three targeted checks.

Check One: Is the Time Zone Attribution Correct?

The produced function constructs times using the time zone the booking belongs to, not the server time zone. This distinction is critical: servers typically run in UTC, and if you directly do new Date(9am), the entire daylight saving time period will be off by an hour. Bugs like this often go unnoticed during local development and only surface in bulk after launch during specific seasons.

Daylight Saving Time (DST) is the practice in many regions of advancing clocks by one hour in summer to make better use of daylight. For a booking system, this means the same local time (e.g., 9 a.m.) may correspond to two different UTC moments over the course of a year. If the code uses the server's default UTC time zone to construct local times, then during the entire DST period, all bookings will be shifted by one hour. More insidiously, this kind of offset only appears during specific seasons—if local development happens to fall in a non-DST month, it's completely unreproducible until launch, when it erupts in bulk once DST begins. Therefore, using a date library that explicitly specifies time zones (such as Luxon, date-fns-tz) and always constructing times in the booking's own time zone is key to avoiding this type of seasonal bug.

Check Two: The Boundary Operators in Overlap Detection

The overlap test logic is: the new booking's start time is earlier than the existing booking's end time, and its end time is later than the existing booking's start time. If either inequality has its operator direction reversed, back-to-back tight bookings will be falsely flagged as conflicts. This kind of error doesn't completely break functionality—it shows up as "occasionally can't book," which is very costly to troubleshoot.

Overlap detection typically uses the classic interval intersection formula: two half-open intervals [start1, end1) and [start2, end2) overlap if and only if start1 < end2 and start2 < end1. Note that strict less-than (<) is used here, not less-than-or-equal (<=). If mistakenly written as <=, then when the new booking's start time exactly equals the existing booking's end time (i.e., back-to-back), it will be falsely flagged as a conflict, causing tight but bookable slots to be rejected. Conversely, if mistakenly written as > or with reversed directions, genuinely conflicting bookings could be allowed through. This kind of boundary operator error doesn't completely crash functionality—it manifests as "occasionally can't book" or "occasionally double-booked," and troubleshooting often requires constructing precise boundary cases to reproduce, so you must confirm the inequality direction character by character during review.

Check Three: Database Constraints as a Backstop

Even if this function has a bug, constraints at the database layer will still reject duplicate bookings. The principle the author draws from this is: never let a single piece of code be your only line of defense. Application-layer validation handles experience and clear error messages; database constraints handle final correctness. Each layer does its job. This is defense in depth concretely applied to business logic.

Defense in Depth is a core principle in security and reliability engineering: don't rely on a single protective layer—let multiple independent layers each provide protection so that even if one fails, others still prevent errors. In a booking system, application-layer validation handles user experience—quickly giving clear error messages and avoiding invalid requests hitting the database; database constraints (such as unique indexes and exclusion constraints) handle final correctness—even if application-layer code has bugs, is bypassed, or races under concurrency, the database will still reject duplicate or conflicting bookings. The two layers have different responsibilities and neither can be omitted. With only application-layer validation, a single concurrent request could write duplicate data; with only database constraints, users would receive obscure low-level errors instead of friendly messages.

A Take on AI Programming

This case demonstrates a pragmatic collaborative posture: let AI handle boilerplate-heavy logic implementation and focus human effort on verification. The three review points—time zones, boundary operators, and backstop constraints—aren't things you can find by "gut feeling"; they come from clearly knowing where this kind of code tends to break. In other words, AI lowers the cost of writing code, but it doesn't lower the cost of judging correctness—that latter skill actually becomes a developer's more core competitive advantage.

The author mentions at the end that the main product is complete, and the next step is integrating Stripe subscriptions to start charging. For those following this series to build a SaaS, going from feature completion to a commercial loop makes the payment step the next hurdle.

FAQ

Why can't booking times use the server time zone?

Servers generally run in UTC. Directly using server time to construct local moments produces a one-hour offset during daylight saving time, and it only surfaces during specific seasons.

The application layer already validates—are database constraints still necessary?

Yes. Application-layer logic can be changed, bypassed, or race under concurrency. Database constraints are the final correctness guarantee that doesn't depend on business code.

What's most easily missed when letting AI write this kind of logic?

Boundary conditions. Which inequality gets the equals sign in overlap detection, back-to-back time slots, and the reference point for determining past times—these are the parts that must be explicitly stated in the prompt.

One-line Summary

AI rewrites the booking time slot logic, and a senior developer's three reviews reveal that verification is the core.

Paragraph Summary

The article describes the author handing the trickiest time slot selection logic in a booking system to AI for rewriting, then verifying it item by item like a senior developer. The prompt must explicitly state the 30-minute step, overlap detection, past-time filtering, and time zone library; otherwise, erroneous bookings like 3 a.m. will be generated. The author focuses on three areas: whether times are constructed based on the booking's time zone rather than server UTC (avoiding a one-hour DST offset), whether the direction of the two inequalities in overlap detection and which one gets the equals sign are correct (avoiding back-to-back slots being falsely flagged as conflicts), and whether database constraints serve as a backstop beyond the application layer. The conclusion is that AI lowers the cost of writing code, but the judgment to verify correctness remains a developer's core value.