Renascido do fracasso: uma retrospectiva do mundo real sobre o lançamento de um agente de IA para front-end. Hoje, no FEDay, compartilhei um estudo de caso sobre a implementação de um Agente de Frontend. A narrativa principal não era sobre uma comemoração triunfal; era a história de como uma equipe passou do "Sucesso Técnico" ao "Fracasso do Produto" e como esse fracasso levou a uma atualização crucial em nossa estrutura cognitiva. O valor desta história não reside numa metodologia para o sucesso, mas sim nas dificuldades que encontrámos e na evolução do nosso pensamento.
2025 está sendo aclamado como o "Ano do Agente". Com o lançamento de Deep Research, Manus e Claude Code, a comunidade tecnológica está em polvorosa. Muitas equipes estão fazendo a mesma pergunta: "Deveríamos criar um Agente?"
Antes de começarmos, deixe-me esclarecer minha definição de um Agente de IA: Agente de IA: Um Modelo de Linguagem Amplo (LLM, na sigla em inglês) que percorre chamadas de ferramentas para atingir um objetivo específico. - Ferramentas em loop: O modelo chama a ferramenta -> Obtém o resultado -> Continua o raciocínio. - Objetivo final claro: Funciona para atingir uma meta, não para entrar em um loop infinito. - Origem flexível da meta: a meta pode vir de um usuário ou de outro LLM. - Memória básica: Mantém o contexto através do histórico da conversa.
O Desafio: Sistemas de Design Privados A equipe de um amigo estava enfrentando um problema real em empresas: a empresa possuía um Sistema de Design interno completo e um framework de front-end privado. No entanto, como esse código era privado, modelos de IA públicos nunca haviam sido treinados com ele. Modelos de propósito geral simplesmente não conseguiam gerar código que atendesse às suas especificações internas. O objetivo parecia claro: construir uma ferramenta semelhante ao "Lovable", mas com a tecnologia do próprio Sistema de Design. Os usuários fariam o upload de um design do Figma ou de uma captura de tela, e o Agente geraria automaticamente o código de front-end em conformidade com os padrões internos. Parece perfeito, não é?
A realidade se impõe: os desafios foram consideráveis. 1. Construir um sistema de agentes completo é mais difícil do que parece (interação com o usuário, engenharia de contexto, etc.). 2. O modelo precisa entender e usar componentes privados que nunca viu. 3. Precisávamos de pré-visualizações em tempo real do código gerado no navegador. 4. Precisávamos de recursos de autorreparo caso o código falhasse.
O "Sucesso Técnico": Como o Construímos Como consultor técnico, meu primeiro conselho foi pragmático: "Coloque em funcionamento antes de otimizar". Construir o agente não é a parte mais difícil; completar todo o ciclo de execução é.
1. A Base: SDK do Agente Claude Em vez de reinventar a roda, nós nos baseamos no SDK do Agente Claude. - Comprovado: Claude Code provou que essa arquitetura funciona. - Pronto para usar: As ferramentas integradas abrangem 90% dos cenários. - Extensível: Suporta ferramentas personalizadas, MCP (Model Context Protocol) e Skills personalizadas. (Você pode encontrar parte do código protótipo em código aberto aqui: https://t.co/eon1eb3ECD)
2. A solução de pré-visualização: Sistema de arquivos local Inicialmente, tentamos usar o Sandpack (sandbox baseado em navegador) para pré-visualizações de código, mas ele falhou com componentes privados complexos. A solução: fornecemos ao Agente um Sistema de Arquivos Local (uma máquina virtual ou diretório por sessão). Isso permitiu que o Agente lesse, escrevesse, modificasse e compilasse o código livremente.
A única maneira de maximizar as capacidades do Agente é fornecer um sistema de arquivos local.
3. Resolvendo o problema do "componente desconhecido" Como ensinar uma IA a usar uma biblioteca de componentes que ela nunca viu? Trate-o como um novo funcionário. Convertemos as especificações do Sistema de Design, as listas de componentes e a documentação da API para Markdown. Não é necessário um RAG complexo: simplesmente permitimos que o Agente realizasse a recuperação de arquivos em documentação local e em "código de referência de alta qualidade".
4. Garantia da Qualidade: O Ciclo de Verificação Para garantir que o código realmente funcionasse, criamos um loop automatizado: Geração -> Verificação -> Reparo - Ferramentas: Linting estático, verificações de compilação e comparação visual (usando o Chrome DevTool MCP). - Otimização: Colocamos as ferramentas de verificação em uma Skill ou SubAgente para evitar poluir a janela de contexto do Agente principal.
O "fracasso do produto": o silêncio após o lançamento O sistema funcionou. A demonstração foi impressionante. Lançamos o sistema... e quase ninguém o usou. Após o encanto inicial passar, as taxas de abandono dispararam. Realizamos uma análise detalhada e entrevistas com usuários, e percebemos que o problema não era a tecnologia, mas sim um desalinhamento entre a lógica do produto e os hábitos dos usuários.
Por que falhou 1. Resistência a hábitos: Designers e gerentes de produto vivem no Figma, não em janelas de bate-papo. A transição da sua zona de conforto para uma interface conversacional representou um enorme obstáculo. A maioria nem sequer sabia o que digitar. 2. O gargalo 80/20: O agente executava 80% do trabalho perfeitamente. Mas os 20% restantes exigiam modificações manuais, o que demandava um esforço incrivelmente grande. Muitas vezes, esses 20% determinavam se o código era utilizável ou não. 3. Fragmentação do fluxo de trabalho: O ambiente de geração estava desconectado do ambiente de desenvolvimento real. Os desenvolvedores tinham que copiar e colar o código manualmente, tornando o processo tedioso.
A atualização cognitiva: reformulando o problema. Percebemos que fizemos a pergunta errada: "Como construímos um Agente de IA para um Sistema de Design?" Isso fez com que o Agente se tornasse o objetivo, em vez do meio. A pergunta certa era: "Qual é o propósito final do nosso Sistema de Design?" 1. Especificações de projeto unificadas em toda a empresa. 2. Maior eficiência no desenvolvimento.
Mudança 1: Projetar para IA, não para humanos Os fluxos de trabalho atuais são centrados no ser humano: comunicação manual, modificação iterativa, confirmação manual. Os fluxos de trabalho futuros devem ser centrados em IA: Entrada -> Agente de IA -> Saída. Novos princípios de design: - Compatível com IA: Escolha conjuntos de tecnologias que os profissionais de Direito entendam facilmente. - Leve: Mantenha apenas os Tokens de Design. Utilize sistemas de código aberto compatíveis com IA (como shadcn/ui) em vez de manter uma biblioteca privada enorme.
Turno 2: De "Agente" para "Habilidade" A mudança mais crucial foi o abandono da "Plataforma de Agentes Independentes". Modelo antigo (ilha): Um agente independente isolado do desenvolvedor, causando atrito. Novo modelo (Integração): Transformar o sistema de design em uma habilidade que possa ser incorporada em ambientes de desenvolvimento de IA existentes (como Cursor ou Claude Code).
O que é uma habilidade? Trata-se simplesmente de documentação em Markdown (para a IA ler) + scripts de automação (para inicializar projetos e instalar o sistema). Agora, o desenvolvedor trabalha em seu ambiente familiar. Quando precisa do Sistema de Design, o Agente genérico chama essa "Habilidade" e o código gerado vai diretamente para o repositório do projeto. (Abordagem de referência: anthropics/skills/tree/main/skills/web-artifacts-builder)
Análises aprofundadas: 4 principais conclusões 1. Sucesso técnico ≠ Sucesso do produto Muitos engenheiros (eu inclusive) caem na armadilha de pensar "Se funciona, então é um sucesso". Os usuários não se importam com a sua pilha de tecnologias; eles se importam se ela resolve o problema deles sem interromper o fluxo de trabalho. 2. Projetar fluxos de trabalho "centrados em IA" Falamos em "foco no usuário", mas precisamos adicionar uma camada: "foco na IA". Não faça a IA imitar os fluxos de trabalho humanos. Redesenhe o fluxo de trabalho para que a IA possa operar com máxima eficiência e, então, deixe o humano desfrutar do resultado. 3. Habilidade > Agente As plataformas de Agentes Independentes enfrentam grandes barreiras de adoção. Encapsular funcionalidades como uma Skill que se integra ao ecossistema existente é um caminho muito mais pragmático. 4. Ação Embora o produto inicial tenha "falhado", a atualização cognitiva foi inestimável. Não é possível aprender a migrar de um "fluxo de trabalho humano" para um "fluxo de trabalho com IA" sem colocar a mão na massa.
Simplesmente construa! Falhar é aceitável. É infinitamente melhor do que não fazer nada.
