A ascensão do fundador probabilístico

(dannguyenhuu.substack.com)

1 pontos por GN⁺ 2 시간 전 | Ainda não há comentários. | Compartilhar no WhatsApp

Na era AI-native, à medida que o software se transforma em um sistema probabilístico, as qualidades exigidas dos fundadores também estão mudando de forma fundamental
Antes, o alvo de investimento era o fundador determinístico, capaz de executar fielmente um roadmap de 2 anos; agora, ganha força o perfil que experimenta rapidamente em meio à incerteza
Em equipes AI-native, cerca de 70% do trabalho de engenharia é experimento e 30% é roadmap, invertendo a proporção
O fundador probabilístico, quando um agente falha, conclui que o problema não está na ferramenta, mas na sua própria especificação, revisão e orquestração
Qualidade dos experimentos, disciplina de seleção e velocidade de execução surgem como novos critérios de avaliação de investimento

Da transição de sistemas determinísticos para sistemas probabilísticos

Durante a maior parte da história do software, tudo foi construído sobre sistemas determinísticos, nos quais a mesma entrada garantia a mesma saída
Em linha com isso, investidores também preferiam fundadores estruturados, sistemáticos e metódicos, que executavam roadmaps trimestre a trimestre
No estágio seed, a “clareza de visão” era o principal critério de avaliação
Os sistemas que estão sendo construídos hoje já não são determinísticos e, com isso, o tipo de fundador que tem sucesso também está mudando

O ensaio Probabilistic Engineering and the 24-7 Employee, publicado por Tim Davis, cofundador da Modular, expressa com clareza essa transição
Tese central: em equipes AI-native, uma parte significativa da base de código é gerada por modelos probabilísticos, revisada sob pressão de tempo e integrada sem que uma única pessoa tenha projetado tudo
O código ainda funciona e vai para produção, mas o intervalo de confiança de que “funciona como pretendido” ficou mais amplo
Gerar ficou barato, mas validar não
A base de código passou de “saber que funciona” para “acreditar que funciona”, sem que seja possível explicitar com precisão essa probabilidade
Engenheiros seniores sempre viveram parcialmente nesse estado, mas quando a maior parte do código não foi escrita por quem o revisa, a correção baseada em confiança deixa de ser exceção e vira padrão

Os fundadores que constroem as melhores empresas AI-native têm características parecidas com os sistemas que estão criando
Experimento como padrão: preferem 10 experimentos de baixo custo a um único plano caro, e o ciclo de iteração é de dias, não de trimestres
Mantêm o roadmap de forma deliberadamente, quase provocativamente, leve
Vários fundadores dizem a mesma coisa: “temos uma visão de plataforma de longo prazo, mas tudo pode mudar em 2 ou 3 meses”
Aceitam como algo natural que um lançamento de modelo ou uma nova capacidade possa invalidar o plano do trimestre anterior
Mesmo dentro da organização de engenharia, a proporção tradicional ao estilo Google de 80/20 (80% roadmap, 20% experimento) se inverteu
Nas equipes mais avançadas, observa-se cerca de 70% experimento e 30% roadmap como realidade prática do trabalho, e não como política formal
O roadmap se ajusta ao modelo, e não o contrário

Um traço filosófico observado repetidamente no fundador probabilístico: a postura agent-default
Parte-se do pressuposto de que todo trabalho pode ser realizado com agentes; se o agente não funciona, isso é visto não como falha do sistema de agentes, mas como falha do operador (humano)
Antes, uma ferramenta que não funcionava era classificada como uma ferramenta ruim; o fundador probabilístico presume que a ferramenta melhora toda semana e verifica se sua especificação, revisão e orquestração estão acompanhando isso
Trata-se de uma forma fundamentalmente diferente de atribuir responsabilidade em comparação aos fundadores tradicionais

Se continuarmos encaixando fundadores no molde determinístico, podemos perder os melhores fundadores deste ciclo
Sinais que, há 5 anos, seriam lidos como “falta de sistema” ou “falta de rigor” correspondem hoje com precisão ao tipo de trabalho exigido no ambiente atual
- disposição para descartar uma funcionalidade no dia seguinte ao lançamento de um modelo
- capacidade de agir sem se abalar em meio à incerteza
- tratar o roadmap não como promessa, mas como hipótese
O rigor não desapareceu, ele apenas mudou de lugar: o rigor importante agora está na qualidade dos experimentos, na disciplina de seleção, em alocar a frota de agentes nos problemas certos e em distinguir resultados excelentes de resultados plausíveis, mas errados
É um músculo diferente de cumprir um roadmap de 5 trimestres, e ainda estamos aprendendo a avaliá-lo

“Probabilístico” não significa “solto”
O fundador probabilístico precisa ser um executor ainda mais implacável — em um ambiente onde se executam 10 experimentos em vez de 1, quem não consegue concluir é punido com dureza
Velocidade é o preço de entrada: lançar toda semana, fechar o loop e crescer de forma composta continuam sendo exigências inegociáveis
O critério de atração de talentos sobe ainda mais: em um mundo onde uma equipe enxuta somada a uma frota de agentes pode superar uma equipe de 50 pessoas, o prêmio por garantir operadores do top 1% fica ainda maior
Os melhores fundadores probabilísticos, sem exceção, são o tipo de pessoa com quem outros grandes talentos querem trabalhar, mesmo que precisem redirecionar a própria carreira para isso
Experimento sem execução é ruído, e velocidade sem talento é evasão

Citação da conclusão do ensaio de Tim Davis: a aposta desta era é se o humano dentro do loop consegue permanecer afiado, honesto e suficientemente treinado para valer a pena estar no loop
A versão dessa mesma aposta para fundadores: se o operador que comanda a frota tem gosto, velocidade e conforto com a incerteza para crescer de forma composta mais rápido do que concorrentes que ainda tentam avançar por meio de planejamento
O fundador probabilístico é a forma como essa aposta se encarna em uma pessoa