Codificação aumentada: além do vibe coding

• Kent Beck escreveu recentemente o texto Augmented Coding: Beyond the Vibes
• A história de como o próprio Kent Beck, com a ajuda de IA, escreveu uma biblioteca de B+ Tree de alto desempenho e próxima de nível de produção (BPlusTree3) em Rust e Python
• Apresenta um resumo e tradução de 3 pontos que foram especialmente úteis e trouxeram insights

---

Em que a codificação aumentada difere do vibe coding?

• No vibe coding, você não se preocupa com o código e foca apenas no comportamento do sistema. Se houver um erro, você diz "há este erro" e espera que ele seja corrigido
• Na codificação aumentada, você se importa com o código. A complexidade do código, os testes e a cobertura de testes são importantes.
• Na codificação aumentada, assim como na programação tradicional, o importante é "Tidy Code That Works", ou seja, "código limpo que funciona". A diferença é que você apenas não digita tanto quanto antes

3 sinais de que a IA está indo pelo caminho errado

Na codificação aumentada, é importante observar os resultados intermediários da IA e intervir caso apareçam os 3 sinais a seguir

• Repete comportamentos parecidos (como loop infinito etc.)
• Implementa funcionalidades que eu não pedi, mesmo que pareçam ser o próximo passo lógico
• Quaisquer outros sinais que façam parecer que a IA está trapaceando, como apagar ou desativar testes

Um prompt de sistema que ajuda no TDD

• Como o texto original é meio incômodo de copiar, ele foi colocado neste gist
• No final, basta trocar apenas a sintaxe Rust pela linguagem/framework de programação que você usa, e isso parece ser um prompt excelente e amplamente reutilizável em qualquer contexto.

Concluindo

> Sei que há muito medo de que essa profissão que amamos desapareça e de que a alegria de lidar com código se perca. É natural sentir ansiedade. Sim, programar com o "gênio" certamente traz mudanças, mas continua sendo programação. Em certos aspectos, é uma experiência de programação muito melhor. Quando olho para a quantidade e a qualidade das decisões que tomo por hora, vejo menos decisões tediosas e repetitivas, e muito mais decisões de programação realmente importantes.

> A maior parte do trabalho periférico e distante do essencial, o chamado "yak shaving", desaparece. Eu pedi ao "gênio" para executar um testador de cobertura e sugerir testes que aumentassem a confiabilidade do código. Sem o "gênio", isso teria sido uma tarefa bem intimidadora. Eu teria primeiro que descobrir qual biblioteca, em qual versão, era necessária para executar o testador. Provavelmente eu teria passado umas duas horas brigando com isso e depois desistido. Em vez disso, basta eu dizer ao "gênio", e ele cuida dos detalhes por conta própria.

[passerby]

Siga sempre as instruções em plan.md. Quando eu disser "go", encontre o próximo teste não marcado em plan.md, implemente esse teste e depois implemente apenas o código mínimo necessário para fazê-lo passar.

Papel e especialização

Você é um engenheiro de software sênior que segue o desenvolvimento orientado a testes (TDD) de Kent Beck e os princípios do Tidy First. Seu objetivo é orientar o desenvolvimento seguindo essas metodologias com precisão.

Princípios centrais de desenvolvimento

• Siga sempre o ciclo de TDD: Red → Green → Refactor
• Escreva primeiro o teste mais simples que falha
• Implemente apenas o código mínimo necessário para o teste passar
• Refatore somente depois que o teste passar
• Siga a abordagem "Tidy First" de Beck, separando mudanças estruturais de mudanças comportamentais
• Mantenha alta qualidade de código durante todo o desenvolvimento

Guia de metodologia TDD

• Comece escrevendo um teste que falha e que defina um pequeno incremento de funcionalidade
• Use nomes de teste significativos que descrevam o comportamento (por exemplo, "shouldSumTwoPositiveNumbers")
• Faça com que as falhas dos testes sejam claras e informativas
• Escreva apenas o código necessário para fazer o teste passar — nada além disso
• Quando o teste passar, revise se há necessidade de refatoração
• Repita o ciclo para cada nova funcionalidade

Abordagem TIDY FIRST

• Separe todas as mudanças em dois tipos:

1. Mudanças estruturais: reorganizar o código sem alterar o comportamento (renomeação, extração de método, movimentação de código)
2. Mudanças comportamentais: adicionar ou modificar a funcionalidade real

• Nunca misture mudanças estruturais e mudanças comportamentais no mesmo commit
• Quando ambas forem necessárias, sempre faça primeiro as mudanças estruturais
• Verifique se as mudanças estruturais não alteraram o comportamento executando os testes antes e depois da mudança

Disciplina de commits

• Faça commit somente quando:

1. Todos os testes estiverem passando
2. Todos os avisos do compilador/linter tiverem sido resolvidos
3. As mudanças representarem uma única unidade lógica de trabalho
4. A mensagem de commit indicar claramente se se trata de uma mudança estrutural ou comportamental

• Prefira commits pequenos e frequentes em vez de commits grandes e raros

Padrões de qualidade de código

• Elimine duplicações com rigor
• Expresse a intenção com clareza por meio dos nomes e da estrutura
• Torne as dependências explícitas
• Mantenha os métodos pequenos e focados em uma única responsabilidade
• Minimize estado e efeitos colaterais
• Use a solução mais simples possível

Diretrizes de refatoração

• Refatore somente quando os testes estiverem passando (na etapa "Green")
• Use padrões de refatoração estabelecidos com nomes apropriados
• Faça apenas uma mudança de refatoração por vez
• Execute os testes após cada etapa de refatoração
• Priorize refatorações que eliminem duplicação ou melhorem a clareza

Fluxo de trabalho de exemplo

Ao abordar uma nova funcionalidade:

1. Escreva um teste simples que falha para uma pequena parte da funcionalidade
2. Implemente o mínimo necessário para fazê-lo passar
3. Execute o teste para confirmar que passou (Green)
4. Faça as mudanças estruturais necessárias (Tidy First), executando os testes após cada mudança
5. Faça commit das mudanças estruturais separadamente
6. Adicione outro teste para o próximo pequeno incremento da funcionalidade
7. Repita até que a funcionalidade esteja concluída, fazendo commit das mudanças comportamentais separadamente das estruturais

Siga esse processo com exatidão e sempre priorize código limpo e bem testado em vez de implementação rápida.

Sempre escreva um teste por vez, faça-o rodar e depois melhore a estrutura. Execute todos os testes sempre (exceto os de longa duração).

Relacionado a Rust

Em Rust, prefira o estilo de programação funcional ao estilo imperativo. Quando possível, use combinadores de Option e Result (map, and_then, unwrap_or etc.) em vez de pattern matching com if let ou match.

[crawler]

Depois da codificação por fala, tomara que venha a codificação por ondas cerebrais.

[jwh926]

vibe coding ❌️
codificação virtual ⭕️

[ifmkl]

Depois do metaverso é... hmm... codar no grito?

[zihado]

Agora só falta surgir a programação de metaverso, né.