Introdução — o equívoco da especificação em inglês
- Inspirado pelo texto “uma especificação suficientemente detalhada é código”. Especificações em inglês parecem intuitivamente precisas, mas, quando tentamos implementá-las de fato, a ambiguidade aparece
- “Tudo é vago até que você tente torná-lo preciso” — Bertrand Russell
- Programar é como escrever: uma atividade iterativa que vai sendo refinada e afiada ao longo do processo (este ensaio também passou por inúmeros rascunhos)
Vibe coding — por que funciona e por que é perigoso
- Como a IA está cada vez melhor e mais rápida em converter inglês → código executável, ficou possível criar código no nível da “sensação (vibe)” do inglês
- Reagindo ao resultado produzido pela IA — “move esse botão para lá, deixa mais azul” — o processo vai ganhando precisão aos poucos
- A expressão “vibe coding” é perfeita justamente por isso: manter a vibe no nível do inglês enquanto se aguça o pensamento a partir da saída da IA
- Problema central: a vibe cria a ilusão de ser uma abstração precisa. Quando as funcionalidades aumentam ou a escala cresce, a abstração começa a vazar (
leaky abstraction) e bugs inesperados acabam com o seu dia inteiro
Caso real — o app de vibe coding de Dan Shipper
- O app de editor de texto que Dan Shipper criou com vibe coding viralizou → servidor caiu
- Causa: “colaboração em tempo real (live collaboration)” parece intuitivamente simples, mas na prática tem complexidade de nível pesadelo
- Todos nós já usamos Google Docs e Notion, então “colaboração em tempo real” dá a sensação de ser algo especificado com precisão. É extremamente difícil perceber de antemão por que não é
- O próprio autor, 10 anos atrás, viveu o pesadelo de uma complexidade inesperada ao tentar criar um editor colaborativo. O que exatamente era difícil? Ele nem lembra! Isso já é parte do problema — complexidade é entediante, ninguém quer pensar nela, e é difícil lembrar detalhes e edge cases
- Exemplo: o fluxograma clássico do Slack para decidir se deve enviar uma notificação — esse nível de complexidade está escondido atrás de uma frase aparentemente simples como “enviar notificação”
Abstração — a única ferramenta para lidar com complexidade
- Limite fundamental do cérebro humano: conseguimos lidar com apenas 7±2 itens de uma vez
- A única maneira de lidar com mais de 7 itens é comprimir vários em um só. Como isso pode ser repetido recursivamente infinitamente, os humanos conseguem lidar com complexidade infinita. Essa etapa de compressão é justamente a abstração (
abstraction)
- “O propósito da abstração não é ser vago, mas criar um novo nível semântico no qual se possa ser absolutamente preciso” — Dijkstra
- O caso em que Sophie Alpert refatorou o infame fluxograma de notificações do Slack em algo muito mais simples por meio de abstrações inteligentes
- A melhor parte da programação: conquistar a complexidade criando abstrações cada vez melhores, como ReactJS e TailwindCSS fizeram em seus respectivos domínios
- O fato de um editor de texto colaborativo ser intrinsecamente complexo só significa que precisamos continuar encontrando abstrações melhores
AGI — mesmo assim, código bom não vai desaparecer
- Se imaginarmos 1, 2, 5, 10 ou 100 anos no futuro: a IA vai ficando cada vez melhor/mais rápida/mais barata, e em algum momento chegará o ponto em que a inteligência de máquina será indistinguível da humana (AGI)
- Um mundo com AGI pode parecer um mundo de vibes. Se você pudesse usar 100 gênios do nível do Karpathy por US$ 1000/mês, por que se preocupar com detalhes chatos?
- “Isso é uma bobagem realmente engraçada.” Esse tipo de pensamento só parece possível quando a tecnologia ainda não chegou e existe apenas em abstrato
- Se tivéssemos acesso a esse nível de inteligência, 0% das pessoas o usariam para produzir mais slop. Claro que não
- O motivo da confusão: pensamos (erroneamente) que código serve apenas para produzir software. O código em si também é um artefato central. Quando é bem feito, é poesia
- “Ninguém fala em ‘vibe writing’, fala?” — ninguém acredita que o ChatGPT vá substituir grandes romancistas ou jornalistas. Com código é a mesma coisa, mas a “mágica” de ele ser executável cria essa ilusão
- A IA produz código ruim (cada vez menos ruim). Todos sabemos disso. Usamos IA apesar do código ruim, não por causa dele
- Citação de Simon Willison: “A IA deveria ajudar a criar código melhor”
- A primeira coisa a fazer quando AGI chegar: resolver os problemas de abstração mais difíceis. Criar abstrações melhores para entender e conquistar melhor a complexidade
- Dizer que, quanto mais inteligente a IA ficar, menos precisaremos de código bom? Isso é o mesmo que dizer que vamos usar ChatGPT para produzir mais slop
- Caso real: o Opus 4.6 resolveu de primeira um problema em aberto na criação do framework full-stack React da Val Town (
vtrr). O resultado foi uma demo de app full-stack em arquivo único com 50 linhas
Conclusão — o código está apenas começando
- Parece que 99% da sociedade concorda com a ideia de que “o código morreu”. Ontem mesmo ouvi o podcaster Sam Harris dizer com confiança que “todos concordam que programação morreu; ninguém precisa aprender a programar”
- “Isso é triste. É como dizer ‘contar histórias morreu’ depois da invenção da prensa. Seus tolos, o código está apenas começando. A IA será uma bênção enorme para a programação.”
- Citações finais:
- “A obrigação de usar símbolos formais não deve ser vista como um fardo, mas como um privilégio. Graças a isso, estudantes conseguem fazer coisas que antes só gênios conseguiam” — Dijkstra
- “Ser capaz de usar sua língua materna ‘naturalmente’ significa apenas que você consegue produzir com facilidade sentenças cujo nonsense não é óbvio” — Dijkstra, “Sobre a tolice da programação em linguagem natural”
- “Há duas maneiras de construir um projeto de software: uma é fazê-lo tão simples que obviamente não haja deficiências; a outra é fazê-lo tão complicado que não haja deficiências óbvias” — Tony Hoare
- “A quantidade de significado comprimida em um pequeno espaço por símbolos algébricos facilita o raciocínio que realizamos por meio deles” — Charles Babbage
7 comentários
Antes mesmo de falar de edição colaborativa, só implementar direito um editor para uso individual já envolve uma quantidade enorme de complexidades inesperadas, como tratamento do cursor, pilha de undo/redo e entrada via IME. Como o texto aponta, há poucos tipos de software em que a armadilha de uma "especificação que parece intuitivamente precisa" fique tão evidente quanto em editores. No fim, o que parece fácil não é realmente fácil; a complexidade apenas foi bem abstraída e escondida.
Na verdade, o motivo de a Anthropic ter feito um compilador C como demonstração provavelmente também foi o fato de que compiladores têm especificações precisas e casos de teste bem preparados. Ao mesmo tempo, eles também parecem extremamente difíceis.
Já criei alguns compiladores e estou trabalhando em outro agora; do ponto de vista de vibe coding, também tentei fazer um editor, mas o compilador pareceu mais fácil. Como você escreveu, sinto que a especificação é menos precisa e há muito mais variáveis causadas pelos usuários. Também é mais difícil testar.
Embora a especificação se torne mais importante, desde antes eu penso que é impossível escrever tudo em detalhes e cobrir todas as situações. Ainda acho melhor ir refinando a especificação ao longo do trabalho, como fazemos com o código; por outro lado, fico pensando se não daria para fazer vários agentes fazerem isso entre si. Mas, no fim, sem intervenção humana, não parece possível sair das situações e dos conhecimentos em que foi treinado, então imagino que seja difícil lidar com situações e funcionalidades totalmente novas.
Isso me lembra a sensação de quando os robôs aspiradores apareceram pela primeira vez e eu ouvi que era preciso fazer uma "limpeza simples" de guardar as coisas do chão para o robô. Escrever uma especificação detalhada para a IA também já dá bastante trabalho, então parece que estamos trabalhando para a IA.
IDE e PR já morreram, mas o código ressuscitou?
O código é, no campo dos sistemas simples, a especificação logicamente mais precisa.
Mas a pegadinha é que o mundo real é um sistema complexo... no fim, só os dados acabam sendo a especificação mais precisa possível
Acho que é preciso ver se isso pode ser substituído por outros métodos de validação. Quanto mais próximo do front, talvez dê para validar bem o funcionamento só com E2E pelo comportamento do navegador. Mas, quanto mais o código se aproxima do back-end e da infraestrutura, mais indispensável a revisão de código parece ser. Caso contrário, fica difícil verificar efeitos colaterais, como transações invisíveis sendo abertas e fechadas ou chamadas de API sendo disparadas.
Nos navegadores, há uma enorme quantidade de problemas que nem mesmo testes E2E conseguem detectar.