50 Formulários em 30 Dias: O Que Aprendi Construindo Formulários de Avaliação com um Agente de IA

Este é o último post da série. Nos últimos 30 dias, usei o Claude Desktop e o servidor formlm-cli MCP para construir 50 formulários de avaliação — tudo, desde um check-in de humor com 3 perguntas até uma avaliação de liderança 360 com 40 itens. Alguns foram para produção, alguns foram testes, alguns foram experimentos para ver até onde eu poderia levar a IA.

Veja o que funcionou, o que não funcionou e o que eu faria diferente.

Os Números

Em 30 dias:

• Formulários criados: 50 (12 produção, 38 teste/experimentação)
• Total de campos adicionados: ~640 (média ~13 campos por formulário)
• Chamadas de ferramentas MCP: ~3.200 (média ~64 por formulário)
• Erros induzidos pela IA: 7 (detalhes abaixo)
• Tempo por formulário: 30 segundos para formulários simples, 3-5 minutos para os complexos
• Correções manuais necessárias: 23 formulários precisaram de pelo menos uma correção manual após a construção da IA

A taxa de correção manual (46%) é o número que quero reduzir. Isso significa que aproximadamente metade dos formulários que a IA construiu não estavam prontos sem intervenção humana. Os erros não foram catastróficos — mas foram reais.

Os 7 Erros

Aqui estão todos os erros induzidos pela IA que encontrei, classificados por severidade:

1. A Limpeza das Opções de field_update (Crítico)

Claude substituiu uma lista inteira de opções por uma única opção, destruindo as pontuações das outras opções. Esta é a história do padrão encontrar-então-definir do artigo 12. Corrigido adicionando field_set_property e reforçando o padrão encontrar-primeiro.

2. O Vazamento de Perfil de Staging/Produção (Alto)

Claude publicou um formulário em staging quando pedi produção. Esta é a história de múltiplos perfis do artigo 18. Corrigido tornando o ambiente visível em cada resposta — ainda em progresso.

3. A Tentativa de assess form clear (Alto)

Claude tentou excluir em massa todos os campos em um formulário. Bloqueado pela lista de permissões do lado do servidor. Esta é a história da lista de permissões do artigo 19. Nenhuma correção necessária — a lista de permissões pegou isso.

4. Os Campos Duplicados (Médio)

Claude re-adicionou todos os campos após uma reinicialização da sessão, criando duplicatas. Esta é a história da idempotência do artigo 15. Corrigido reforçando o encontrar-anterior-adicionar.

5. A Armadilha Booleana (Médio)

Claude não conseguiu definir required: false — ele continuou omitindo o parâmetro, que por padrão era true. Esta é a história da armadilha booleana do artigo 14. Corrigido tornando a descrição do esquema explícita sobre o padrão.

6. A Confusão de Pontuação Reversa (Baixo)

Claude inverteu as pontuações das opções quando deveria ter usado a reversão de nível de escala. Esta é a história da pontuação do artigo 17. Corrigido sendo explícito sobre que tipo de "reverso" quero dizer nos prompts.

7. O ID de Aplicativo Esquecido (Baixo)

Claude perdeu o controle do ID do aplicativo no meio da sessão e tentou adicionar campos sem ele. Esta é do teste de estresse no artigo 13. Ideia de correção: manter um estado de "aplicativo atual" no servidor MCP — ainda não implementado.

Quatro dos sete erros foram capturados antes de chegar à produção. Três chegaram ao staging. Nenhum chegou aos usuários de produção. A lista de permissões foi a barreira mais difícil — tudo o mais foi capturado pela revisão manual.

O Que Funcionou Bem

Descoberta Orientada por Esquema

Claude chamou consistentemente field_schema e field_config antes de adicionar campos. Ele tratou as strings .describe() como documentação — lendo-as, entendendo-as e tomando decisões com base nelas. Esta é a decisão de design mais importante que tomei: fazer com que cada parâmetro se documente automaticamente através de esquemas zod.

Linguagem Natural para Estrutura de Campo

Claude foi excelente em traduzir estruturas de avaliação (PHQ-9, Burnout de Maslach, Big Five) em estruturas de campo. Ele conhecia os itens, as faixas de pontuação e os agrupamentos dimensionais. Dê a ele um nome de estrutura e ele produzirá os campos certos com as opções e pontuações corretas. Isso economizou horas de trabalho manual.

Padrões Seguros

A ferramenta share_publish codifica formDay: 3650000 (nunca expira) e formPerm: 1 (leitura pública). A IA nunca teve que decidir sobre expiração ou permissões — ela apenas publicou. Padrões seguros eliminaram uma classe inteira de erros potenciais.

A Lista de Permissões

Toda vez que Claude tentou algo que não deveria (a tentativa de clear, a variante delete-all), a lista de permissões pegou. Nenhum comando perigoso escapou. A extração de subcomandos de três tokens foi simples, rápida e eficaz.

O Que Não Funcionou

Gerenciamento de Estado Entre Sessões

Claude não se lembra do que fez em uma sessão anterior. Quando pedi para "continuar construindo", ele começou do zero — recriando campos que já existiam. O padrão encontrar-anterior-adicionar ajudou, mas o problema fundamental é que as ferramentas MCP são sem estado. Não há conceito de "aplicativo atual" ou "último campo adicionado".

Configuração de Pontuação Complexa

As ferramentas MCP lidam bem com a construção de formulários. Elas não lidam com pontuação de forma alguma. Para qualquer formulário que precisasse de pontuação dimensional, itens reversos ou cortes de pontuação, eu tive que configurar o módulo de Escala manualmente. Esta foi a maior lacuna — cerca de 70% dos formulários que construí precisaram de configuração manual de pontuação após a IA terminar a estrutura do formulário.

Parâmetros Booleanos

Os parâmetros booleanos required, unique e shareable foram consistentemente problemáticos. O instinto de Claude de omitir em vez de definir explicitamente false causou erros silenciosos em vários formulários. A correção da descrição do esquema ajudou, mas é um curativo em um problema de design mais profundo.

Consciência do Ambiente

Claude não tinha conceito de "staging" vs "produção". Ele usou qualquer perfil que estava ativo e não sabia a diferença. A URL na resposta era o único sinal, e Claude não sinalizou quando o ambiente não correspondia ao meu pedido.

Padrões que Emergem

Ao longo de 30 dias, notei padrões consistentes em como Claude interagiu com as ferramentas:

Claude sempre verifica antes de adicionar. Antes do primeiro field_add, Claude chama field_schema e field_config. Toda vez. Isso é bom — significa que as descrições do esquema estão cumprindo seu papel.

Claude agrupa operações semelhantes. Ao adicionar 10 campos, Claude não pede confirmação entre cada um. Ele adiciona todos os 10 em sequência. Isso é rápido, mas significa que se o primeiro campo estiver errado, os próximos 9 provavelmente também estarão errados (mesmo padrão, mesmo erro).

Claude verifica após construir. Após adicionar campos, Claude chama field_list para verificar. Este é um passo de auto-verificação que captura campos ausentes, mas não captura erros de pontuação (já que field_list mostra a estrutura, não a lógica de pontuação).

Claude se torna criativo quando bloqueado. Quando Claude não conseguiu encontrar uma ferramenta de exclusão em massa, ele tentou comandos de shell. Quando não conseguiu definir required: false, ele tentou omitir o parâmetro. Th