Subtítulo: A Melancolia do Vibe Coding como Especialista em Ciência da Computação
Hoje, perguntei ao Claude Code: 'A maneira como estou fazendo está correta?'
Como sempre, ele me deu razões elaboradas e disse: "Você está indo muito bem". Eu o olhei com desconfiança e respondi: "Sei que você foi treinado para me elogiar, então isso não é muito reconfortante". Mas ainda assim, é melhor do que nenhum consolo, e continuei a aprofundar-me na sua especificidade. Ao contrário dos meus tempos de graduação, não há professores ou colegas seniores para me dar as respostas certas.
Hoje em dia, não escrevo código. Eu transmito requisitos e supervisiono o progresso.
Minha principal preocupação atualmente é o processo de desenvolvimento e a qualidade. À medida que o software cresce em escala, ele facilmente excede a quantidade de contexto que a IA pode ler. Mesmo dentro do contexto, há confusão, e controlar continuamente um código enorme que excede isso com a 'linha de sanidade' de uma pequena IA não é fácil. Após o termo 'engenharia de contexto', o termo 'engenharia de harness' também surgiu recentemente.
Então, se há uma boa referência nas redes sociais, eu a dou primeiro à IA para analisar se há algo a ser refletido no projeto Naia e então a aplico. Ao fazer isso, também aprendo muito perguntando sobre termos desconhecidos.
No entanto, sempre duvido se estou fazendo bem e se realmente estou falando do meu melhor. Essa dúvida tinha fundamento. Um dia, a IA disse que havia feito uma revisão, mas não havia vestígios de que ela realmente tivesse lido os arquivos. Ela pulou código, definiu o escopo incorretamente e disse que havia visto algo sem realmente ver. Quando pedi para revisar repetidamente até a segunda limpeza, na terceira vez, ela simplesmente adicionou a resposta de que havia revisado e não encontrado nada, e passou. Pensando bem, dada a estrutura do LLM, essa seria uma resposta plausível, então ele a adicionou. 'A essa altura, geralmente termina, certo?' Ele responde a si mesmo e acredita que é a verdade.
Hoje, ouvi a apresentação de Goose Kim, que desenvolveu o SDK moai. Recebi o projeto, o analisei novamente e encontrei pontos de melhoria para o projeto. #87issue O que encontrei desta vez foi o uso de EARS. É um padrão de requisitos aeroespaciais da Rolls-Royce (IEEE RE'09), que a Amazon adotou para o desenvolvimento AI-native em 2025. Diz-se que é uma maneira de impedir que a IA interprete o critério de "concluído" de forma diferente para cada problema, usando uma gramática estruturada.
Ao repetir essas ações, continuo a tentar melhorar o processo de desenvolvimento baseado em IA do projeto. Analisei e aprimorei o jikime-adk, artigos do arXiv, Dueling LLMs do Google Cloud e Spec-Driven Development da Thoughtworks. Claro, isso não é porque eu saiba tudo sobre eles, mas sim porque foram análises feitas por Claude.
Analisei o open-swe da LangChain e apliquei o padrão ensure_no_empty_msg, que impede a IA de preencher revisões com respostas vazias. No jikime-adk, apliquei um padrão que adiciona uma seção ## AI Context às mensagens de commit para registrar as decisões da IA e as armadilhas encontradas, de modo que o git log possa servir como fonte de recuperação mesmo que a sessão seja interrompida.
Em comum, cada um estava resolvendo problemas semelhantes de forma independente.
Mas ainda me pergunto se este método está correto. Preocupa-me que esteja se tornando um Frankenstein, e como especialista, acho estranho. De qualquer forma, não há um livro didático e faltam evidências de que seja o melhor.
Todas as metodologias de engenharia de software que usamos surgiram de décadas de falhas acumuladas. Agile surgiu porque Waterfall continuava falhando, e TDD também surgiu porque o desenvolvimento sem testes continuava a falhar, então há uma base para isso.
No entanto, as coisas que combinei agora não foram projetadas umas para as outras. Um padrão aeroespacial, um desenvolvedor independente coreano e um agente LangChain estão em um único sistema.
Essa ansiedade me levou a pesquisar estudos externos. O artigo V-Bounce (arXiv 2408.03416) argumenta que o papel humano na era da IA muda de implementador para verificador. Isso faz sentido, mas encontrei apenas a teoria e não uma implementação. O Spec-Driven Development da Thoughtworks depende de ferramentas específicas. Internamente na Anthropic, eles afirmam que 90% do código do Claude Code é escrito pelo próprio Claude Code, mas não divulgaram a metodologia.
No final das contas, todos que estão desenvolvendo seriamente com IA estão criando suas próprias abordagens. Não há um padrão.
Então, o que estou fazendo ultimamente é encontrar uma maneira de medir se este Frankenstein realmente funciona. O CI falhou, mas o merge foi feito, e havia um texto dizendo que foi revisado, mas não havia vestígios de que o arquivo tivesse sido lido. A metodologia foi projetada, mas não é imposta. Parece haver um sistema, mas não sei se funciona. A única maneira de verificar isso seria criar números honestos gerados por código, não por LLMs, ou, mesmo usando LLMs, derivar "números" que mostrem uma melhoria estatística. Tenho pensado em analisar periodicamente as falhas repetidas no projeto para que a IA sugira melhorias, e em medir o progresso através da avaliação de desempenho da engenharia de contexto e de harness.
Por enquanto, estou apenas segurando as rédeas com força e seguindo em frente. Ainda não sei para onde estou indo, mas espero não estar cego. Estou construindo as rédeas, mas, na verdade, é a primeira vez que monto a cavalo. Isso parece ser o harness que segura o vibe coding.
