O Desenvolvedor “Atleta de Código”

Antigamente eu fazia centenas de exercícios de programação por ano. No ano passado, por exemplo, pratiquei TDD com estruturas de dados, F#, sincronização de threads e diversas outras coisas, porque sempre precisei ter agilidade para codar e conseguir me virar com exceptions, configurações, bibliotecas e toda aquela parte prática do desenvolvimento.

Eu cresci aprendendo programação através de listas de exercícios e prazos. Sempre tive na cabeça o mantra baseado no famoso:

“Talk is Cheap. Show me the Code.”

E também no velho:

“A prática faz o mestre.”

Para mim, ser um bom programador significava praticar muito. Quanto mais código eu escrevesse, mais rápido eu conseguiria resolver problemas.

Meus testes de entrevista, inclusive, muitas vezes eram literalmente horas codando presencialmente na frente de todo mundo. Mais tarde, conforme fui ganhando experiência, os testes passaram a ser muito mais sobre discutir conceitos amplamente.

Mas, mesmo assim, eu ainda precisava ter uma habilidade muito grande de implementação. Precisava conhecer de cabeça APIs, bibliotecas, recursos do .NET, configurações e saber transformar rapidamente uma ideia em código.

Eu era, de certa forma, um “atleta de código”.

🚀 O Choque de Realidade

Então veio o choque.

Quando conheci o Claude Code, ele me fez repensar fortemente essa maneira de enxergar programação.

Eu vi ele fazer implementações como login com Microsoft e Google em menos de uma hora, com pouquíssimas coisas para corrigir — e muitas vezes ele mesmo corrigia os problemas.

Isso é algo que anteriormente poderia facilmente me levar vários dias ou até uma semana.

Eu teria que pensar no layout, descobrir como funcionavam os endpoints, ler a documentação, entender quais APIs deveriam ser configuradas, descobrir as configurações necessárias, implementar, testar e corrigir.

De repente, um prompt relativamente genérico conseguia implementar uma quantidade enorme desse trabalho.

E não era simplesmente código funcionando.

O código produzido seguia padrões, aplicava Clean Code, utilizava padrões de projeto e, principalmente, o agente conseguia analisar os próprios erros e corrigi-los.

Foi aí que surgiu uma pergunta bastante desconfortável:

Se a habilidade braçal de escrever código rapidamente deixa de ser o principal diferencial, o que significa ser um excelente programador?

🧠 O Ponto de Virada "Talk is Cheap Show me the Code" vs "Cognitive Coverage"

Foi então que vi um vídeo no YouTube apresentando o conceito de “cobertura cognitiva”.

Naquele momento eu praticamente reestruturei minha maneira de praticar.

Em vez de continuar gastando uma quantidade enorme de tempo tentando dominar cada detalhe de implementação, comecei a organizar minha prática em tópicos buscando aumentar a amplitude dos conceitos que conheço.

Esse passou a ser meu novo mantra.

Hoje eu não sou um especialista em cloud, mas conheço muitos serviços em nuvem e sei fazer uma infra em duas nuvens.

Não sou especialista em IA, mas conheço muitos conceitos, ferramentas e plataformas como Azure AI Foundry.

Também comecei a estudar novas técnicas como como Spec-Driven Development, Machine Learning, Data Engineering e orquestração de agentes.

Minha preocupação começou a mudar.

Agora não ligo em saber codificar  de cabeça uma API com GRPC ou tela em .NET MAUI mas me importo com cobertura cognitiva. 

Quero saber grande amplitude de conceitos para elaborar specificação no prompt para o agente. E entender o que o agente está fazendo para poder conduzir ele aos meus objetivos e da empresa que trabalho.

⚙️ O Gargalo do TDD e do SDD

Foi nesse processo que comecei a entender melhor por que tantas pessoas não seguem determinadas metodologias rigorosamente.

Lembro de uma pesquisa ou estimativa que vi e que atribuía ao Kent Beck a ideia de que aproximadamente 92% dos desenvolvedores não utilizariam TDD de maneira rígida. Não lembro exatamente a fonte, então não quero afirmar esse número como um dado definitivo.

Mas o raciocínio por trás disso me chamou atenção.

O problema é simples:

pensar no design antes de implementar é difícil.

Em funcionalidades complexas, escrever os testes antes da implementação exige que você consiga antecipar o comportamento, pensar nas interfaces, nos casos de uso e em como aquele código deverá funcionar antes mesmo de construí-lo.

Isso é cognitivamente muito pesado.

E comecei a perceber algo parecido acontecendo com o Spec-Driven Development.

Eu tinha entendido o SDD como uma forma de especificar tudo: requisitos, design, implementação e tarefas organizadas em ordem, chegando até um tasks.md extremamente detalhado.

Só que existe um problema.

Especificar a implementação de baixo nível pode ser ainda mais difícil do que implementar.

Você precisa pensar antecipadamente em como aquela solução será construída, quebrar tudo em tarefas, organizar a sequência e prever detalhes que talvez só fossem descobertos naturalmente durante a implementação.

Por isso comecei a perceber que muita gente acaba trabalhando principalmente com especificações de alto nível, sem necessariamente descrever toda a implementação de baixo nível.

🛠️ O Exemplo Prático: Quando Eu Travei

Isso ficou muito claro para mim no meu próprio site.

Eu estava desenvolvendo funcionalidades relacionadas a Audiobook e ePub e comecei a tentar aplicar o Spec-Driven Development de maneira extremamente perfeccionista.

Queria mapear tudo.

Queria descrever cada etapa.

Queria chegar até o nível das tarefas de implementação.

E simplesmente travei.

Foi um daqueles momentos em que percebi que o processo que deveria me ajudar estava começando a me impedir de avançar.

Foi então que pensei:

Por que estou tentando fazer manualmente uma parte que um agente consegue fazer muito melhor e muito mais rápido?

Passei a delegar a implementação de baixo nível para o Claude Code.

Eu continuava controlando a intenção, a arquitetura, o que queria construir e os resultados esperados, mas deixava o agente navegar por grande parte da implementação.

O resultado foi um ganho de produtividade de dezenas de vezes.

Foi aí que a ficha caiu.

Eu não precisava mais competir com a máquina naquilo que ela estava ficando absurdamente boa em fazer.

🎯 A Nova Realidade

Ao invés de buscar ser um codificador exemplar, escrevendo código diariamente e praticando centenas de exercícios, preciso expandir minha gama de conceitos e fundamentos. Preciso desenvolver uma visão ampla o suficiente para entender e cobrir aquilo que a IA é capaz de fazer, saber revisar suas implementações, conduzi-la aos objetivos corretos e, muitas vezes, aprender com o próprio código que ela produz, entendendo seus prós, contras e limitações.

Grande vantagem de trabalhar em alto nível agora com specificações é que posso expandir o que sou capaz de entregar.

A grande vantagem de migrar o foco para o trabalho de alto nível, fundamentado em especificações claras, é o ganho exponencial de escala no que sou capaz de entregar.

Antes, integrar um novo ecossistema exigia dias debruçado sobre documentações para mapear endpoints, tratar exceções e construir a interface do zero. Hoje, ao compreender conceitualmente soluções como o Azure AI Foundry ou o Microsoft Agent Framework, basta estruturar uma especificação bem definida estabelecendo as entradas, comportamentos e saídas esperadas do agente para que a IA gere a implementação necessária.

Com pouquíssimos cliques e comandos, transformo um conceito arquitetural em uma ferramenta funcional e de alto valor, sem me afogar nos detalhes de baixo nível que levariam semanas.