Claude y Ralph: dos enfoques para crear un DatePicker complejo con IA en el desarrollo de producto

La historia del DatePicker en este artículo importa menos por sí misma que como modelo de una decisión que hoy afronta casi cualquier equipo de producto: pedir a una red neuronal que esboce rápido una interfaz funcional, o construir primero un sistema en el que la IA escriba código dentro de reglas predefinidas. Con un componente de calendario accesible para React como ejemplo, los autores muestran que el debate no es qué modelo es más inteligente, sino quién gestiona la complejidad en el proceso: el ingeniero o el azar.

Los autores llaman al primer camino AI drafting (borrador con IA). La lógica es sencilla: se toma un prompt detallado basado en las recomendaciones de WAI-ARIA APG y se entrega a un modelo como Claude. El resultado es un DatePicker casi terminado que, en efecto, cubre buena parte de la tarea al arrancar.

Pero luego afloran problemas que rara vez se ven en una primera respuesta vistosa. Seguir la especificación a ciegas puede chocar con el comportamiento de los lectores de pantalla reales, manejadores como onBlur y onClick empiezan a pelearse entre sí y provocan fallos visuales, y los ajustes finos de accesibilidad, por ejemplo el modo que anuncia los cambios mediante aria-live, no se pueden adivinar sin pruebas en vivo. El equipo acaba con un buen borrador más que con una arquitectura cerrada, y después tiene que estabilizarlo a mano.

El segundo camino es la ingeniería de sistemas. Aquí no se le da a la IA una tarea del tipo «haz un DatePicker», sino que se la coloca en un circuito de producción rígidamente diseñado. Los autores usaron un agente autónomo basado en el enfoque Ralph, sobre codex cli y un modelo pequeño, pero el elemento clave no fue el modelo, sino el entorno.

En el directorio de trabajo del agente se dejaron un PRD con requisitos fijos, un conjunto de tareas atómicas en tasks.json y reglas de sistema que prohibían desviarse de la arquitectura objetivo. Entre las condiciones obligatorias figuraban una API solo controlada (controlled-only), navegación completa por teclado y un marcado ARIA correcto.

Tras cada paso, el código pasaba por un circuito externo de verificación: pruebas unitarias y comprobaciones de a11y con Vitest y Playwright, compilación con Vite y control de tipos con TypeScript. Mientras la tarea en curso no superaba la verificación, el agente no podía avanzar.

Este esquema cambia no solo la disciplina de desarrollo, sino también la forma del propio código. En lugar de un componente monolítico, surge poco a poco una estructura de tres capas: un núcleo puro con las fechas y la lógica de entrada, una capa de UI aparte con componentes lo más simples posible y una capa de enlace que gestiona el estado y la interacción. Cuesta más al principio: hay que redactar requisitos, descomponer el trabajo, configurar el verificador y gastar más tokens.

A cambio, el coste de los cambios baja con el tiempo. Si hay que añadir una función o corregir un algoritmo, los cambios se hacen en una capa concreta y no se reparten por todo el componente. Eso sí, los autores muestran con honestidad que ni una buena arquitectura protege de forma automática: un cambio pequeño en el cálculo de las semanas provocó un fallo en cascada, un recordatorio de que entre capas hacen falta contratos explícitos y validación automática.

La observación más útil del artículo tiene que ver con el tipo de errores. En el modo de borrador con IA, los defectos principales viven en las uniones: eventos, estado, renderizado, accesibilidad, la integración de varios fragmentos de código que parecen correctos por separado. Son difíciles de ver de antemano, y depurarlos suele exigir tener todo el componente en la cabeza. En el enfoque sistemático, los errores tienden a desplazarse hacia abajo, al nivel de funciones y módulos individuales. Si el calendario gestiona mal febrero de un año bisiesto, el equipo no busca el problema en toda la interfaz, sino en una sola función pura, que se puede aislar rápido con una prueba y corregir sin efectos secundarios.

De ahí la conclusión práctica: el borrador rápido encaja con MVP, prototipos, hackatones y utilidades desechables, donde importa más la velocidad que el mantenimiento a largo plazo. El enfoque sistemático se justifica cuando el componente formará parte de un sistema de diseño, del núcleo de un producto o de un proyecto de larga vida.

Qué significa en la práctica

La IA ya puede acelerar de forma drástica la creación de interfaces, pero la bifurcación principal no está entre modelos, sino entre modos de trabajo del equipo. Si el coste del error es bajo, se puede apostar por la velocidad y aceptar el retoque manual. Si el componente va a vivir mucho tiempo y otros desarrolladores dependerán de él, compensa invertir en requisitos, pruebas, contratos y un proceso que limite la libertad del agente. El siguiente paso más realista es un híbrido: diseñar el sistema con reglas de ingeniería y encargar a la red neuronal las tareas rutinarias y bien formalizadas dentro de ese marco.