Claude e Ralph: duas abordagens para criar um DatePicker complexo com IA no desenvolvimento de produto

A história do DatePicker neste artigo importa menos por si só e mais como modelo de uma escolha que quase toda equipe de produto enfrenta hoje: pedir a uma rede neural que monte rapidamente uma interface funcional, ou primeiro construir um sistema em que a IA escreva código dentro de regras predefinidas. Usando um componente de calendário acessível para React, os autores mostram que a discussão 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 (rascunho com IA). A lógica é simples: pega-se um prompt detalhado, baseado nas recomendações do WAI-ARIA APG, e entrega-se a um modelo como o Claude. O resultado é um DatePicker quase pronto, que de fato resolve boa parte da tarefa logo de saída.

Mas depois surgem problemas que raramente aparecem em uma primeira resposta bonita. Seguir a especificação às cegas pode entrar em conflito com o comportamento de leitores de tela reais, handlers como onBlur e onClick começam a brigar entre si e causam falhas visuais, e ajustes finos de acessibilidade, como o modo de anunciar mudanças via aria-live, não dá para adivinhar sem testes ao vivo. No fim, a equipe fica menos com uma arquitetura completa e mais com um bom rascunho, que depois precisa ser estabilizado manualmente.

O segundo caminho é a engenharia de sistemas. Aqui a IA não recebe uma tarefa do tipo "faça um DatePicker", mas é colocada em um circuito de produção rigidamente projetado. Os autores usaram um agente autônomo baseado na abordagem Ralph, com codex cli e um modelo pequeno, mas o elemento-chave não foi o modelo, e sim o ambiente.

No diretório de trabalho do agente foram colocados um PRD com requisitos fixos, um conjunto de tarefas atômicas em tasks.json e regras de sistema que proibiam desvios da arquitetura-alvo. Entre as condições obrigatórias estavam uma API controlled-only, navegação completa por teclado e marcação ARIA correta.

Após cada passo, o código passava por um circuito externo de verificação: testes unitários e verificações de a11y com Vitest e Playwright, build com Vite e checagem de tipos com TypeScript. Enquanto a tarefa atual não passasse na verificação, o agente não podia avançar.

Esse esquema muda não só a disciplina de desenvolvimento, mas também a forma do próprio código. Em vez de um componente monolítico, surge aos poucos uma estrutura de três camadas: um núcleo puro com datas e lógica de entrada, uma camada de UI separada com componentes o mais simples possível e uma camada de ligação que gerencia estado e interação. Custa mais no início: é preciso escrever requisitos, decompor o trabalho, configurar o verificador e gastar mais tokens.

Em compensação, o custo das mudanças cai com o tempo. Se for preciso adicionar uma função ou corrigir um algoritmo, as alterações entram em uma camada específica, em vez de se espalharem por todo o componente. Os autores também mostram com honestidade que nem uma boa arquitetura protege automaticamente: uma pequena mudança no cálculo das semanas causou uma falha em cascata, o que lembra que entre as camadas são necessários contratos explícitos e validação automática.

A observação mais útil do artigo diz respeito ao tipo de erro. No modo de rascunho com IA, os principais defeitos moram nas junções: eventos, estado, renderização, acessibilidade, a integração de vários trechos de código aparentemente corretos. É difícil enxergá-los de antemão, e a depuração muitas vezes exige manter o componente inteiro na cabeça. Na abordagem sistemática, os erros tendem a descer para o nível de funções e módulos individuais. Se o calendário trata errado o fevereiro de um ano bissexto, a equipe não procura o problema na interface inteira, mas em uma única função pura, que dá para isolar rapidamente com um teste e corrigir sem efeitos colaterais.

Daí vem a conclusão prática: o rascunho rápido funciona bem para MVPs, protótipos, hackathons e utilitários descartáveis, onde a velocidade pesa mais que a manutenção de longo prazo. A abordagem sistemática se justifica quando o componente vai integrar um design system, o núcleo de um produto ou um projeto de longa vida.

O que isso significa na prática

A IA já consegue acelerar bastante a criação de interfaces, mas a principal bifurcação não está entre modelos, e sim entre modos de trabalho da equipe. Se o custo do erro é baixo, dá para escolher a velocidade e aceitar o acabamento manual. Se o componente vai viver por muito tempo e outros desenvolvedores dependerão dele, compensa investir em requisitos, testes, contratos e um processo que limite a liberdade do agente. O próximo passo mais realista é um híbrido: projetar o sistema com regras de engenharia e entregar à rede neural tarefas rotineiras e bem formalizadas dentro desses limites.