AI Design Engineering: meu processo de Design, Build, Test e Ship com IA

Sou o Gus, AI Design Engineer na Arena, e moro em San Jose. Meu trabalho é desenhar produtos e construí-los em código de verdade, com agentes de IA fazendo o código. Na Arena, crio projetos de engajamento de audiência usados pela ESPN, Reuters, FOX, entre outras grandes empresas. Construo esses projetos em React e Next.js e eu mesmo envio o código para o repositório no Git. A engenharia valida o código e, na maioria dos casos, coloca em produção. Nos meus próprios produtos, como Black Eagle, 2GRW, myCFO, trpFit e GSL Game Zone, faço o caminho inteiro, do primeiro frame no Figma até o deploy.

Meus dias não se parecem em nada com o trabalho que eu fazia há dois anos. Abro um terminal antes de abrir o Figma. Um Mac Studio na minha mesa roda todos os projetos que tenho abertos, e converso com ele pelo Claude Code, usando meu MacBook ou meu iPhone, de onde eu estiver. Descrevo o que quero em palavras simples, um agente constrói, e passo o resto do tempo na parte que nunca foi automatizada: decidir se está certo.

Quem segura tudo isso junto é o GJAI (Jammes), meu agente pessoal. Ele acompanha todos os agentes que tenho rodando, recebe tarefas do meu celular e responde quando chamo por voz. É a maior coisa que construí para mim mesmo, então ganhou uma seção própria logo abaixo.

As pessoas me perguntam se a IA me deixou mais rápido. Deixou, e isso importa. Mas velocidade não é a maior mudança. A maior mudança é onde mora a parte difícil do trabalho. Produzir uma tela, um componente ou uma feature inteira ficou barato. Saber que aquilo funciona de verdade, não. Todo trabalho que faço passa pelas mesmas quatro etapas, Design, Build, Test e Ship, mesmo que nenhum dia seja igual ao outro, e quanto mais a IA faz dentro de cada etapa, mais o meu trabalho vira a prova entre elas.

A IA executa. Eu verifico.

O que é AI design engineering

AI Design Engineering é criar um produto de ponta a ponta e entregá-lo funcionando, em código. Agentes de IA escrevem a maior parte desse código, e o designer é dono das decisões e da prova de que funciona. Em vez de entregar uma imagem do produto para outra pessoa construir, um AI design engineer desenha, constrói, testa e entrega o produto de verdade, depois observa como as pessoas usam e decide o que muda em seguida.

Não é mais um jeito de trabalhar de nicho. Na pesquisa State of Prototyping da UX Tools com designers e builders, feita entre março e abril de 2026, 43,8% disseram que passam mais da metade do tempo de construção fazendo vibe coding, que é o nome que a indústria deu para construir descrevendo para uma IA o que você quer.

GJAI, o agente pessoal por trás do meu trabalho

GJAI quer dizer Gus mais Jammes AI. Jammes é o agente com quem trabalho todo dia, o mesmo com quem construí o Black Eagle, e o GJAI é o cockpit dele. Desenhei e construí tudo eu mesmo, com agentes escrevendo o código, e ele virou a maior coisa que já fiz para mim. Toda sessão do Claude Code que eu inicio, em qualquer um dos Macs, seja pessoal ou da Arena, se reporta a ele por conta própria, então uma única tela mostra o que cada agente está fazendo agora, em qual projeto e se está esperando por mim.

A partir daí, ele virou um jeito de trabalhar sem estar na mesa. Desde julho consigo escrever uma tarefa no celular. Ela entra numa fila, um serviço no Mac Studio pega, roda o Claude Code dentro do projeto certo e devolve o resultado, e uma mensagem de follow up continua a mesma sessão em vez de começar do zero. Também posso chamar o Jammes por voz. Ele me conta o que está rodando, manda trabalho novo para os agentes e procura nas minhas notas a decisão por trás de um projeto. Agora estou ensinando o Jammes a ler minha agenda, meu email e meu Slack, por enquanto só em modo leitura. Por trás dessa única tela, 13 serviços rodam 24 horas por dia no Studio.

O GJAI também me ensinou a regra em que mais confio. Durante semanas, o mapa parecia movimentado com sessões que nunca aconteceram. Um health check que rodava a cada cinco minutos estava sendo registrado como sessão, e quando finalmente medi, 98% do histórico era ruído. Desde então o GJAI tem uma regra que nunca quebra: todo número na tela precisa ter origem em algo que aconteceu de verdade, ou simplesmente não aparece. Essa regra não ficou só no GJAI. É assim que construo todo dashboard agora.

Design: decidir o que é bom

Design ainda começa com uma decisão, e essa a IA não toma por mim. Às vezes a decisão acontece no Figma, quando preciso ver uma forma antes de me comprometer com ela. Hoje, com mais frequência, ela acontece direto no código, porque só uma tela rodando me mostra os estados que um frame estático esconde: o carregamento, a lista vazia, o erro, o celular lento, o nome comprido demais para o espaço que eu dei a ele.

Na Arena, uma tarefa muitas vezes chega como uma linha e um vídeo curto. Então meu primeiro passo de design é ler o código que já está em produção, para entender o que a tela realmente faz hoje antes de propor o que ela deveria fazer amanhã. Depois verifico quais dados existem de fato. Se um número não pode ser buscado, o design não mostra. Um dashboard lindo cheio de números inventados é o mockup mais caro que existe, porque todo mundo acredita nele.

O hábito que mais mudou meu trabalho de design é um arquivo. Todo projeto pesado em interface em que trabalho tem um DESIGN.md que o agente lê antes de tocar em qualquer tela. Ele não repete as cores nem a escala tipográfica, isso mora no código. Ele guarda as decisões que o código não consegue dizer, e a seção mais valiosa é a lista do que a gente nunca faz. Nenhum efeito de escala quando você passa o mouse num botão. Nenhum focus ring em input. Nenhum dado inventado. Cada linha dessa lista existe porque algo deu errado uma vez.

Build: os agentes escrevem o código, eu escrevo as regras

Construo com o Claude Code, e não uso um único modelo para tudo. O Opus roda minhas sessões e faz a maior parte da construção. O Fable, o modelo mais capaz, fica fixo nos agentes que cuidam de decisões de design, arquitetura, code review e debugging difícil, onde a qualidade extra se paga. Um pequeno roteador também lê cada pedido que escrevo e pontua qual modelo ele precisa. Desde 10 de outubro, ele pontuou 1.567 pedidos: 55% Opus, 29% Haiku, o rápido e barato, e 16% Fable. Qualidade onde importa, economia no resto.

A parte que ninguém vê são as regras. Tenho 19 arquivos de regras que toda sessão lê antes de começar, e cerca de metade deles traz a data da coisa que deu errado. Toda tabela nova de banco de dados recusa acesso anônimo desde o momento em que é criada, porque uma tabela aberta parece exatamente igual a uma fechada até alguém testar de fora. Todo campo de texto no mobile usa fonte de pelo menos 16 pixels, porque o iPhone dá zoom na página inteira quando você toca num campo menor. A barra de rolagem nativa fica escondida em todo lugar, porque o Windows pinta, sobre uma interface escura, uma barra branca grossa que ninguém que trabalha num Mac chega a ver. Como essas regras são escritas é uma história que contei em Agora todo mundo é gestor de agentes.

A pesquisa sobre essa etapa é honesta sobre aquilo em que você está se metendo. A Faros AI analisou a telemetria de mais de 10.000 desenvolvedores e descobriu que times com alta adoção de IA fazem merge de 98% mais pull requests. O mesmo relatório encontrou pull requests 154% maiores, tempo de review quase dobrado e 9% mais bugs por desenvolvedor. Essa é a etapa de Build em quatro números. O volume de entrega subiu, e subiu também a quantidade de trabalho que alguém precisa ler com cuidado. No meu trabalho, esse alguém sou eu.

Test: check verde não é prova

É nessa etapa que a IA mais mudou meu trabalho, e não na direção que as pessoas esperam. Um typecheck pode passar, um build de produção pode dar certo e o console pode ficar em silêncio enquanto a página está quebrada na tela de alguém. Já vi os três concordarem entre si enquanto a página no meu navegador estava disparando um erro. Tudo verde nas ferramentas diz que o código compila. Não diz que o produto funciona.

Então testo do jeito que um usuário chega ao produto. Abro a página real num navegador real, muitas vezes pilotado pelo Playwright, e olho para ela, num build de produção e não só no servidor de desenvolvimento. Num site, seis títulos de seção mostravam só metade da frase, o que parecia o pior tipo de bug numa página no ar. Só acontecia em desenvolvimento. Em produção, todo título estava inteiro. A correção que eu tinha escrito para isso foi para o ar, quebrou o build de desenvolvimento e não mudou nada, e eu a reverti no mesmo dia. Quando construo qualquer coisa que guarda dados, ataco de fora como um estranho faria, e a única resposta que aceito é permission denied. Uma lista vazia não prova que uma tabela está segura. Só significa que ninguém pediu do jeito certo ainda.

E testo num celular de verdade, porque nenhum simulador reproduz um app instalado num iPhone. Uma vez passei quatro rodadas no myCFO com o app instalado no iPhone aparecendo cortado embaixo. Cada correção parecia certa no código. A causa era uma única linha que eu tinha adicionado de propósito, para o app ocupar a tela inteira. Remover essa linha resolveu tudo, porque o celular cuida desse espaço melhor do que qualquer código que eu pudesse escrever para isso. Nenhuma verificação automática teria encontrado isso, porque nada estava tecnicamente errado.

As pesquisas mostram que a maioria das pessoas sabe que deveria fazer isso e muitas não fazem. Na pesquisa 2026 State of Code da Sonar, com mais de 1.100 desenvolvedores, 96% disseram que não confiam totalmente que o código gerado por IA está funcionalmente correto, mas só 48% sempre verificam antes do commit. Acessibilidade mostra a mesma lacuna. Quando a Microsoft testou oito modelos líderes em componentes de interface comuns sem nenhuma instrução de acessibilidade, só 12% dos resultados passaram em todas as verificações. Com uma skill de acessibilidade dedicada escrita para o modelo, quase sete vezes mais passaram. Escrever o padrão onde o agente é obrigado a ler é a maior parte da solução.

Ship: pequeno, reversível e depois medido

Nos meus próprios produtos, o Ship é chato de propósito. Mudanças pequenas vão direto para produção. As maiores ou mais arriscadas ganham uma branch própria, que gera um preview no seu próprio endereço, e esse preview é o meu ambiente de staging. Cada commit carrega uma única intenção, então qualquer mudança pode ser desfeita sem levar outra junto. Depois do deploy, eu mesmo abro a página no ar. Um deploy verde é uma afirmação, não um resultado. Na Arena funciona do mesmo jeito: envio o código numa branch com o preview dela, a engenharia valida e, na maioria dos casos, coloca em produção.

É no Ship também que o processo começa a se medir. Construí um dashboard privado que reúne num só lugar Google Analytics, Search Console, gravações de sessão e os assistentes de IA que leem meu site. Ele já me corrigiu uma vez. Uma visita que mostrava vinte minutos no site acabou tendo quatro minutos e quarenta e um segundos de uso real. O resto era uma aba esquecida aberta. Agora o dashboard mostra tempo em uso, não tempo aberto, porque um número com o rótulo errado é pior do que número nenhum.

Os desenvolvedores parecem estar chegando ao mesmo lugar. Na Stack Overflow 2026 Developer Survey, a resposta mais comum sobre confiar em IA não foi sim nem não. Foi que eles confiam quando conseguem verificar o resultado com facilidade. Verificação não é um imposto sobre o trabalho com IA. É a condição para confiar nele.

De volta ao Design: por que este post existe

Este post é o processo rodando sobre si mesmo. Alguns dias atrás, meu dashboard mostrou que uma dúzia de buscas sobre IA e design de produto, coisas como ai product designer e product design with ai, estavam caindo num post mais antigo meu, um ensaio pessoal curto de junho sobre a mudança do meu título. O Google estava testando esse post para perguntas que ele nunca foi escrito para responder, e ele ficava entre as posições 40 e 60, da quarta à sexta página dos resultados.

Então voltei ao Design. A decisão foi escrever a página que essas buscas merecem, sobre como o trabalho é feito de verdade. O Build é o que você está lendo. O Test foi ler numa página real antes de qualquer outra pessoa. E em algumas semanas o mesmo dashboard vai me dizer se funcionou, que é onde começa a próxima rodada de Design.

O que continua humano

A IA escreve todo o meu código, e eu verifico se tudo está funcionando como planejei. Ela não decide qual sensação um produto deve passar. Ela não percebe que a parte de baixo da tela está errada num celular de verdade. Ela não sabe que o número num dashboard está medindo uma aba aberta. Essas são as partes que guardei para mim, e elas acabaram sendo o trabalho. Se você quiser a história de como cheguei aqui, escrevi em De Product Designer a AI Design Engineer, e como esse papel funciona pela Bay Area em Como os product designers da Bay Area trabalham de verdade com IA em 2026. As ferramentas mudaram. A responsabilidade pelo que vai para o ar, não. A IA executa. Eu verifico.