A era em que código de teste se torna o novo moat
(saewitz.com)-
O paradoxo do sucesso: à medida que um projeto cresce, ele passa a carregar o fardo da compatibilidade retroativa e de uma base de código gigantesca (The Ship of Theseus). Enquanto isso, concorrentes podem treinar IA com a especificação da API, a documentação e os testes do projeto existente para extrair apenas o valor central e criar em instantes uma “versão mais leve e moderna”.
-
Caso Cloudflare vs Vercel: a Cloudflare aproveitou a vasta documentação e a suíte de testes do Next.js, acumuladas pela Vercel ao longo de anos, para construir em apenas uma semana um runtime enxuto compatível com Next.js baseado em Vite. (Atualmente, isso também é usado no site do governo dos EUA cio.gov)
-
Código de teste como ativo: no passado, o próprio código era o mais importante, mas agora o “contrato de software” (Contract) e os “casos de teste” se tornaram os ativos mais caros. Torná-los públicos é como fornecer ao concorrente um projeto técnico preciso para copiar meu serviço exatamente como ele é.
-
A visão de futuro do SQLite: o SQLite abre o código, mas mantém privada sua enorme suíte de testes — 590 vezes maior que o código-fonte (92 milhões de linhas). Isso se tornou o “moat” que lhes permite sustentar o ecossistema open source e, ao mesmo tempo, manter capacidade de defesa comercial.
-
Conclusão: na era da IA, empresas comerciais de open source chegaram ao momento de decidir entre o “altruísmo completo” (open source) e a “sobrevivência do negócio”. Muitos projetos provavelmente seguirão o SQLite, tornando o código de teste privado para construir sua própria barreira tecnológica.
19 comentários
Por essa perspectiva, talvez documentos como ADR (Architecture Decision Records) ou CIR (Change Intent Records) passem a ser tratados como algo ainda mais valioso do que o próprio código.
Bastante impressionante. Mesmo sendo um texto curto, faz sentido de imediato. Talvez a segurança do código de teste possa ser até mais importante do que a do código-fonte.
Para mim, isso soa como um recado para não deixar de fora os testes e2e; queria saber como os outros interpretam isso.
Sou totalmente não desenvolvedor... mas, pela diversão de mexer com IA, às vezes peço para ela programar um pouco, e ela ficava criando e guardando um monte de código de teste que eu nem tinha pedido... então era por isso.
Quando perguntei por que diabos isso era necessário, ela disse que precisava disso na hora de escrever o código e pediu para eu não apagar.
Oh... acho que faz sentido.
A abordagem do SQLite é realmente impressionante. Manter privada uma suíte de testes 590 vezes maior que o código significa, no fim das contas, que "o verdadeiro valor do software está na especificação de comportamento".
Na prática, quando você tenta criar projetos hoje em dia com ferramentas de IA para programação, se tiver apenas o README + a documentação da API + os testes de um projeto existente, dá para replicar as funcionalidades principais com uma velocidade surpreendente. Falo isso por experiência, operando diretamente 7 projetos: paradoxalmente, quanto melhor testado é um projeto, mais fácil também é copiá-lo.
Mas há um ponto ignorado no caso Cloudflare vs Vercel: "copiar" e "operar" são problemas completamente diferentes. Para reproduzir os edge cases do Next.js, o ecossistema de plugins e até a dependência da comunidade, só o código de testes não basta. No fim, me parece que o verdadeiro moat é a combinação de código de testes + comunidade + know-how operacional.
Como desenvolvedor solo, estou tocando 7 projetos, e este texto me acertou em cheio.
Graças às ferramentas de coding com IA, a velocidade inicial de desenvolvimento ficou absurdamente rápida, mas o código acumulado às pressas sem testes acabou virando um inferno de refatoração. Principalmente quando você opera vários serviços ao mesmo tempo, em projetos sem testes dá medo até de mexer em uma única funcionalidade, porque sempre fica o receio de quebrar outra coisa em algum lugar.
A metáfora de "testes = moat" é precisa. Um concorrente pode até copiar o código, mas dificilmente vai conseguir replicar também uma suíte de testes que cobre milhares de edge cases. Isso é ainda mais verdadeiro porque, embora a IA seja boa em gerar código, criar cenários de teste realmente significativos ainda é uma área que exige conhecimento de domínio humano.
Mas, dependendo da área, há casos em que o código de teste quase não tem cobertura, então fico meio em dúvida. Também parece que, nesse lado, ainda não conseguem fazer código bom tão bem quanto em outras áreas.
Você poderia me dizer qual é essa área? (Não é provocação; é realmente uma curiosidade sincera.)
A área em que eu trabalho também não é tão extrema assim, mas atuo com pesquisa e desenvolvimento na área de IA.
Além dos frameworks mais usados em geral, às vezes o ambiente-alvo onde o modelo é de fato implantado é diferente do ambiente em que ele foi treinado.
Também há casos em que certas operações não são suportadas, então é preciso criar operações customizadas para cada plataforma. Nesses casos, muitas vezes não dá para testar diretamente no ambiente em que foi desenvolvido.
Também há situações em que modelamos o próprio modelo diretamente; dá para escrever testes com determinados dados, mas, dependendo do dataset, os valores mudam de forma probabilística, e fenômenos como explosão de valores em certos momentos são difíceis de cobrir com código de teste.
Imagino que existam muitos ambientes em que testar é ainda mais difícil do que no meu caso.
É só a minha opinião, mas imagino que isso valha mais para áreas em que se usa muito Notebook, ou para áreas de IA em que as respostas saem de forma probabilística... e também para a área de clientes de jogos.
Eu também falo bastante sobre isso com as pessoas ao meu redor, mas no fim das contas, como depois vai ser difícil revisar todo o código, acho que, se a lógica realmente importante não for testada sem falta, isso vai acabar dando um problemão.
Isso também foi adicionado no fim do texto; houve um comentário de que a tldraw também roda os testes de forma privada (parece que era brincadeira).
https://github.com/tldraw/tldraw/issues/8082
Se você vir Como o SQLite é testado,
o SQLite é totalmente aberto, mas tem um código de testes 590 vezes maior que o código-fonte, e isso é totalmente privado.
Há 100% de cobertura de ramificações, centenas de milhões de casos de teste e são executados mais de 1 bilhão de testes de mutação.
Entrei na thread para ler e disseram que “é piada”.
Parece que era um teste de Joke.
Nossa, entendi. Vi só a parte de cima kkk
A ideia central de que "testes acima do código-fonte" parece realmente fazer sentido. Mas não sei se uma estratégia de abrir apenas o código-fonte, sem abrir os testes, vai ser válida. Acho que também conseguiriam fazer bem a extração de casos de teste a partir do código-fonte..
Você também está fazendo isso errado.
Cloudflare, AI로 Next.js를 1주일 만에 Vite로 재구현한 vinext 공개
Parece estar relacionado a este texto. Ao fazer open source, acho que agora talvez possamos nos tornar mais conservadores em relação à divulgação do código de teste.