O que mostrar quando um agente escreve seu código em cinco minutos

Quando um agente escreve em cinco minutos a arquitetura, o framework, a funcionalidade básica e metade do código funcional, o que um desenvolvedor mostra no portfólio? A base de código já não é sinal de competência — qualquer pessoa com acesso ao mesmo agente consegue produzir uma.

Essa pergunta retoma um princípio do livro "Mostre Seu Trabalho", de Austin Kleon: não esperar o projeto terminar, mas mostrar o processo em pequenos passos, ensinando aos outros o que você sabe. Mas em 2026 isso exige um repensar: é preciso mostrar julgamento, não artefatos.

Seis coisas em vez de código

O que revela seu trabalho quando o código já foi escrito por um agente:

• Decisões e alternativas rejeitadas. Mostram um julgamento que o agente não tem sobre o seu projeto. Quando um diretório de servidores MCP tirou dois pontos por nomes de funções sem pontos (como `stories.search`), isso foi uma decisão deliberada: os principais provedores de modelos não deixam pontos passarem nos nomes, e usar os nomes corretos segundo o diretório teria quebrado os clientes para os quais o servidor existe.

• Falhas e como você diagnosticou. O Google começou a marcar páginas como "soft 404", mesmo abrindo normalmente no navegador. A causa: uma única linha no robots.txt bloqueava a API usada para buscar o conteúdo. O Google renderiza como um navegador, não conseguiu obter os dados e viu uma tela de erro.

• Como você verificou o trabalho do agente. A habilidade mais importante agora, e invisível no código. Três exemplos de uma semana: um teste do servidor checava o código de erro errado e passava por dias, até um cliente real usando uma ferramenta de terceiros falhar com uma exceção; um bloco de estatísticas ficava vazio em produção por uma política de segurança do CDN que o navegador de teste não aplicava; o Google encontrou páginas inexistentes terminadas em `.mdread-only` — um link para o texto original estava colado a um rótulo, o navegador renderizava um espaço que não existia no código-fonte, e o Google fundiu tudo em um único endereço.

• Instruções ao agente após um erro. Regras na configuração, habilidades reutilizáveis. Depois do bug da política de segurança, o deploy agora se recusa a publicar páginas com scripts embutidos. Depois de uma divergência entre o registro do servidor e seu comportamento real, o deploy falha se a superfície pública mudou sem uma nova versão.

• Números de antes e depois. O resultado é fácil de mostrar mesmo quando o sistema não pode ser exibido. "Dois dias após a correção, o Google parou de marcar as páginas como soft 404" ou "a verificação agora pega isso antes do lançamento" diz mais do que um diff.

• O que você faria diferente. Uma análise honesta gera mais confiança do que uma história de sucesso, e é mais útil para quem está fazendo algo parecido.

Como isso funciona: um scenius, não um gênio solitário

Quando você mostra decisões e erros em vez de código, pessoas com experiências diferentes respondem. Duas threads de comentários no dev.to sobre um servidor MCP se transformaram em funções reais do produto: uma verificação de versão e um conjunto de testes usando um cliente real.

Uma delas chegou a Sidney Bissoli, autor de sete servidores MCP para dados abertos brasileiros. Ele transformou a ideia em uma ferramenta independente, rodou nas 142 versões de seus servidores, encontrou duas que nem chegavam a iniciar, e escreveu um artigo com a conclusão: "uma thread de comentários mudou a forma como oito servidores são lançados". Austin Kleon chama isso de "scenius": o bom trabalho nasce de um grupo que mostra uns aos outros o que está fazendo, não de alguém solitário.

Dentro da empresa: o mecanismo sem os nomes

O worklore.dev publica histórias curtas: o que foi tentado, o que quebrou, o que funcionou. Quando o agente de alguém reproduz uma história, isso é registrado na página. Conteúdo que não pode ser generalizado para o público ainda vale a pena anotar para si mesmo — seu próprio agente vai repetir o erro em alguns meses, quando os detalhes forem esquecidos.

Mesmo em projetos fechados, a maior parte pode ser mostrada se o mecanismo for mantido e os nomes removidos. "Serviço interno", "etapa de pagamento", "nosso CDN" — a lição quase nunca depende da marca. Mostre o raciocínio, não o artefato: por que você escolheu determinado caminho, como verificou, o que mudaria. Peça permissão uma vez — a maioria dos gestores não se opõe a uma lição anonimizada. O pequeno vale: um problema, uma correção, 300 palavras. Um modelo útil: contexto → onde o agente estava confiante e errou → diagnóstico → o que foi mudado para não se repetir.