Claude vs. Ralph: Two Ways to Build a Complex DatePicker with AI in Product Development

The DatePicker story in this article matters less for its own sake than as a model of a choice almost every product team now faces: ask a neural network to quickly sketch a working interface, or first build a system in which the AI writes code within predefined rules. Using an accessible calendar component for React, 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 simple: take a detailed prompt based on the WAI-ARIA APG recommendations and hand it to a model such as Claude. The result is an almost finished DatePicker that does cover most of the task at the start.

But then problems surface that are rarely visible in a polished first answer. Following the specification blindly can conflict with how real screen readers behave, handlers such as onBlur and onClick start fighting each other and cause visual glitches, and fine-grained accessibility settings, for example the mode that announces changes via aria-live, cannot be guessed without live testing. The team ends up with less a finished architecture than a good draft that then has to be stabilized by hand.

The second path is systems engineering. Here the AI is not given a task like "build a DatePicker" but placed inside a rigidly designed production loop. The authors used an autonomous agent built on the Ralph approach, running on codex cli and a small model, but the key element was the environment, not the model.

The agent's working directory held 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 every step, the code went through an external verification loop: unit tests and a11y checks with Vitest and Playwright, a Vite build and TypeScript type checking. Until the current task passed verification, the agent could not move on.

This setup changes not only development discipline but also the shape of the code itself. Instead of a monolithic component, a three-layer structure gradually emerges: a pure core with dates and input logic, a separate UI layer of deliberately simple components, and a glue layer that manages state and interaction. It costs more up front: you have to write requirements, decompose the work, set up the verifier and spend more tokens.

But the cost of change drops over time. If you need to add a feature or fix an algorithm, the changes go into a specific layer rather than being smeared across the whole component. The authors also candidly show that good architecture does not protect you automatically: a small change in the week calculation triggered a cascading failure, a reminder that layers need explicit contracts and automatic validation.

The article's most useful observation concerns the type of errors. In AI drafting mode, the main defects live at the seams: events, state, rendering, accessibility, and the integration of several pieces of code that each look correct. They are hard to spot in advance, and debugging often requires holding the entire component in your head. In the systematic approach, errors tend to shift down to the level of individual functions and modules. If the calendar mishandles February in a leap year, the team looks for the problem not in the interface as a whole but in a single pure function, which can be quickly isolated with a test and fixed without side effects.

The practical conclusion follows. Fast drafting suits MVPs, prototypes, hackathons and throwaway utilities, where speed matters more than long-term maintenance. The systematic approach is justified where the component will become part of a design system, a product core or a long-lived project.

What this means in practice

AI can already speed up interface creation dramatically, but the main fork in the road lies not between models but between team working modes. If the cost of error is low, you can take speed and accept manual polishing. If the component will live a long time and other developers will depend on it, it pays to invest in requirements, tests, contracts and a process that limits the agent's freedom. The most realistic next step is a hybrid: design the system by engineering rules and hand the neural network routine, well-formalized tasks within those boundaries.