Claude and Ralph: Two Approaches to Building a Complex AI-Enabled DatePicker in Product Development

The DatePicker story in this article matters not for its own sake, but as a model for a choice that almost any product team faces today: ask a neural network to quickly mock up a working interface, or first build a system where AI will write code within pre-established rules. Using an accessible calendar component for React as an example, the authors show that the debate is not about which model is smarter, but about who manages complexity in the process — the engineer or chance. The authors call the first path AI-drafting.

The logic is straightforward: take a detailed prompt based on WAI-ARIA APG recommendations and give it to a model like Claude. The result is an almost finished DatePicker that genuinely solves most of the problem at the start. But then issues emerge that are rarely visible in that beautiful first response.

Blind adherence to the specification can conflict with real screen reader behavior, handlers like onBlur and onClick start quarreling with each other and cause visual glitches, and subtle accessibility tweaks — for example, the aria-live mode for announcing changes — are impossible to guess without live testing. In the end, the team gets not so much a finished architecture as a successful draft, which must then be manually stabilized. The second path is systematic engineering.

Here, AI is not given a task in the style of "make a DatePicker," but placed in a rigidly designed production loop. The authors used an autonomous Ralph-based agent on top of codex cli and a small model, but the key element was not the model, but the environment. The agent was given a PRD with fixed requirements, a set of atomic tasks in tasks.

json, and system rules that forbade deviating from the target architecture. Mandatory conditions included a controlled-only API, full keyboard navigation, and correct ARIA markup. After each step, the code passed through an external verification loop: unit tests and a11y checks via Vitest and Playwright, Vite build and TypeScript type control.

Until the current task passed verification, the agent could not move forward. This scheme changes not only development discipline, but the form of the code itself. Instead of a monolithic component, a three-layer structure gradually emerges: a clean core with dates and input logic, a separate UI layer of maximally simple components, and a binding layer that manages state and interaction.

This costs more upfront: you need to write requirements, decompose the work, set up a verifier, and spend more tokens. But the cost of changes falls over time. If you need to add a new feature or fix an algorithm, changes are made to a specific layer, not scattered across the entire component.

However, the authors honestly show that even good architecture does not automatically protect against errors: a small change in week calculation caused a cascading failure, reminding us that explicit contracts and automatic validation are needed between layers. The most useful observation in the article concerns error types. In AI-drafting mode, the main defects live at the seams: events, state, rendering, accessibility, integration of several seemingly correct pieces of code.

These are hard to spot in advance, and debugging often requires holding the entire component in your head at once. In the systematic approach, errors more often shift down to the level of individual functions and modules. If the calendar incorrectly handles February in a leap year, the team looks for the problem not in the entire interface, but in one pure function that can be quickly isolated with a test and fixed without side effects.

This leads to a practical conclusion: quick drafting works well for MVPs, prototypes, hackathons, and one-off utilities where speed matters more than long-term support. The systematic approach is justified where a component will become part of a design system, the product core, or a long-lived project. What does this mean in practice: AI is already capable of dramatically speeding up interface creation, but the main fork in the road does not lie between models, but between team work modes.

If the cost of an error is low, you can go for speed and accept manual fine-tuning. If a component will live long and other developers will depend on it, it pays to invest in requirements, tests, contracts, and a process that constrains the agent's freedom. The most realistic next step is a hybrid: design the system by engineering rules, and give neural networks routine, well-formalized tasks within those bounds.