Claude e Ralph: Duas Abordagens para Construir um DatePicker Complexo Habilitado por IA no Desenvolvimento de Produtos

A história do DatePicker neste artigo é importante não por si mesma, mas como modelo de uma escolha que quase qualquer equipe de produto enfrenta hoje: pedir a uma rede neural para mockup rápido de uma interface funcional ou primeiro construir um sistema onde a IA escreverá código dentro de regras pré-estabelecidas. Usando um componente de calendário acessível para React como exemplo, os autores mostram que o debate não é sobre qual modelo é mais inteligente, mas sobre quem gerencia a complexidade no processo — o engenheiro ou o acaso. Os autores chamam o primeiro caminho de AI-drafting.

A lógica é simples: pegue um prompt detalhado baseado nas recomendações WAI-ARIA APG e entregue a um modelo como Claude. O resultado é um DatePicker quase pronto que genuinamente resolve a maioria do problema no início. Mas então surgem problemas que raramente são visíveis naquela primeira resposta bonita.

A adesão cega à especificação pode entrar em conflito com o comportamento real dos leitores de tela, manipuladores como onBlur e onClick começam a discordar entre si e causam falhas visuais, e ajustes sutis de acessibilidade — por exemplo, o modo aria-live para anunciar mudanças — são impossíveis de adivinhar sem testes ao vivo. No final, a equipe obtém não tanto uma arquitetura acabada quanto um rascunho bem-sucedido, que deve ser manualmente estabilizado. O segundo caminho é engenharia sistemática.

Aqui, a IA não recebe uma tarefa no estilo "faça um DatePicker", mas é colocada em um loop de produção rigidamente projetado. Os autores usaram um agente autônomo baseado em Ralph em cima do codex cli e um modelo pequeno, mas o elemento-chave não era o modelo, mas o ambiente. O agente recebia um PRD com requisitos fixos, um conjunto de tarefas atômicas em tasks.

json e regras do sistema que proibiam desviar da arquitetura-alvo. As condições obrigatórias incluíam uma API somente controlada, navegação completa por teclado e marcação ARIA correta. Após cada etapa, o código passava por um loop de verificação externo: testes unitários e verificações a11y via Vitest e Playwright, construção Vite e controle de tipo TypeScript.

Até que a tarefa atual passasse na verificação, o agente não podia avançar. Esse esquema muda não apenas a disciplina de desenvolvimento, mas a forma do próprio código. Em vez de um componente monolítico, uma estrutura de três camadas emerge gradualmente: um núcleo limpo com datas e lógica de entrada, uma camada UI separada de componentes maximamente simples e uma camada vinculante que gerencia estado e interação.

Isso custa mais no início: você precisa escrever requisitos, decompor o trabalho, configurar um verificador e gastar mais tokens. Mas o custo das mudanças cai com o tempo. Se precisar adicionar um novo recurso ou corrigir um algoritmo, as mudanças são feitas em uma camada específica, não espalhadas por todo o componente.

Porém, os autores mostram honestamente que até uma boa arquitetura não protege automaticamente: uma pequena mudança no cálculo de semanas causou uma falha em cascata, lembrando-nos que contratos explícitos e validação automática são necessários entre camadas. A observação mais útil do artigo diz respeito aos tipos de erros. No modo AI-drafting, os principais defeitos vivem nas costuras: eventos, estado, renderização, acessibilidade, integração de vários pedaços de código aparentemente corretos.

Estes são difíceis de detectar antecipadamente, e a depuração frequentemente requer manter todo o componente em sua cabeça de uma vez. Na abordagem sistemática, os erros mais frequentemente descem para o nível de funções e módulos individuais. Se o calendário trata incorretamente fevereiro em um ano bissexto, a equipe procura o problema não em toda a interface, mas em uma função pura que pode ser rapidamente isolada com um teste e corrigida sem efeitos colaterais.

Isso leva a uma conclusão prática: o rascunho rápido funciona bem para MVPs, protótipos, hackathons e utilitários únicos onde a velocidade importa mais que o suporte de longo prazo. A abordagem sistemática é justificada onde um componente se tornará parte de um design system, do núcleo do produto ou de um projeto de longa vida. O que isso significa na prática: a IA já é capaz de acelerar dramaticamente a criação de interfaces, mas o principal bifurcação não fica entre modelos, mas entre modos de trabalho da equipe.

Se o custo de um erro é baixo, você pode ir para velocidade e aceitar ajustes manuais. Se um componente viverá por muito tempo e outros desenvolvedores dependerão dele, compensa investir em requisitos, testes, contratos e um processo que restrinja a liberdade do agente. O próximo passo mais realista é um híbrido: projetar o sistema por regras de engenharia e dar às redes neurais tarefas rotineiras bem formalizadas dentro desses limites.