Desenvolvedores buscam o que mostrar quando um agente escreve o código em 5 minutos

Cinco minutos. É o tempo que, segundo a estimativa do autor da coluna no Habr, o agente do vizinho leva para reproduzir o código que você escreveu com a ajuda do seu próprio agente. Disso ele conclui que a forma habitual de se apresentar na profissão, ou seja, publicar código, funciona cada vez pior. O texto abre com uma pergunta que, na introdução publicada, ainda não tem resposta: o que um desenvolvedor deve mostrar em 2026?

A ideia de Kleon e os três conselhos

O ponto de partida é o livro curto «Mostre seu trabalho!», de Austin Kleon. Sua tese central: não esperar pelo resultado pronto, mas mostrar o processo. Pequenos passos, o que você está aprendendo, o que o inspira, como caminha rumo ao objetivo. É preciso compartilhar aos poucos e todos os dias, ensinar o que se sabe e cuidar para que isso não vire spam. A lógica é simples: as pessoas encontram você pelo que você compartilha, e parte delas passa a ajudar.

Para desenvolvedores, essa filosofia costuma ser aplicada de três maneiras:

• publicar código em open-source;
• manter um diário público do que foi feito no dia;
• descrever como pensou sobre a tarefa.

O autor observa que até os defensores da primeira opção admitem: o resultado parece entediante.

Onde cada opção falha

A principal crítica recai sobre o código, e ela tem duas partes. A primeira é jurídica e prática: se o código pertence ao empregador, não é possível compartilhá-lo. Para a maioria dos desenvolvedores contratados, isso é a maior parte do trabalho diário. A segunda parte é econômica. Se o código foi gerado por um agente de qualquer forma, ele deixa de ser uma evidência única de habilidade. Qualquer pessoa que passar uma tarefa parecida a uma ferramenta parecida obterá o mesmo resultado.

É uma mudança no próprio objeto da demonstração. Antes, um repositório no GitHub era uma prova indireta de que a pessoa sabia resolver problemas: commits, arquitetura, estilo. Quando há um agente entre a definição da tarefa e o código funcionando, fica mais difícil entender, pelo repositório, onde terminou a contribuição humana. O empregador ou o colega vê o artefato, mas não vê as decisões que levaram a ele.

O diário do dia e a descrição do raciocínio estão mais próximos do que Kleon propõe, mas também não resolvem o problema por completo. Sem um resultado concreto, esses registros viram com facilidade uma autodescrição, e não uma demonstração de valor.

O que isso significa na prática

Na parte disponível do texto, o autor não apresenta uma resposta pronta. A partir daqui, só é possível supor uma direção, com base na própria formulação do problema. Se o valor se desloca do texto do programa para as decisões em torno dele, faz sentido mostrar justamente essas decisões:

• que tarefa você escolheu e quais descartou;
• como formulou o enunciado e verificou o resultado do agente;
• que erros do modelo encontrou e como os corrigiu;
• o que aprendeu sobre o processo, algo que dá para contar sem revelar código corporativo.

Esse conjunto não viola o NDA, porque não exige publicar o código-fonte. O agente do vizinho não o reproduz: são registros de julgamento, e não de sintaxe. E ele está de acordo com o conselho original de Kleon de compartilhar o processo, e não apenas o resultado final.

Para quem constrói agora uma presença pública, a conclusão é prática. Não vale esperar por um projeto perfeito para o portfólio. É possível começar com notas curtas sobre decisões concretas, removendo delas tudo o que pertence à empresa. A resposta completa do autor estará no artigo principal no Habr, no link da publicação original. Por enquanto, a própria pergunta já é reveladora: o setor começa a discutir a sério o que comprova o profissionalismo quando escrever código deixa de ser algo que só uma pessoa pode fazer.