Engenharia probabilística e o funcionário 24/7

• O desenvolvimento de software está passando silenciosamente de sistemas determinísticos para sistemas probabilísticos, e na era em que agentes de IA geram, revisam e fazem merge de código durante toda a noite, o papel dos desenvolvedores e a estrutura das organizações estão mudando de forma fundamental
• Dentro de equipes nativas de IA, ao mesmo tempo em que os papéis sobem de nível, também ocorre uma fragmentação para baixo, com o risco de que tarefas simples de gerenciar a saída dos agentes se consolidem como novas funções de baixa remuneração
• À medida que o custo de geração de código converge para zero, como no paradoxo de Jevons a quantidade de código explode, mas a assimetria central é que gerar ficou barato, enquanto validar não ficou
• Engenheiros júnior já estão começando a depender da IA para produzir código polido desde o início, tornando real a crise de treinamento em depuração, julgamento e ofício
• Como o modelo atual é o mais fraco entre os modelos que serão usados no futuro, as organizações precisam construir sistemas voltados não para a capacidade de hoje, mas para modelos futuros que ainda nem foram lançados

---

A transição para a engenharia probabilística

• A indústria de software foi construída por décadas sobre um contrato determinístico — você escrevia, testava e lançava código com a garantia de que ele funcionaria
• Esse contrato está se rompendo, e entre os operadores mais avançados de empresas nativas de IA, o codebase está virando algo que se acredita que funciona, sem que se consiga mais declarar probabilidades exatas
• O gatilho para essa percepção foi a experiência de construir um projeto paralelo chamado Compound Loop — um sistema que coloca vários modelos de fronteira uns contra os outros para escrever, revisar e fazer merge de código de forma autônoma
  • Ao rodar o sistema em problemas reais antes de dormir, pela manhã a rotina vira fazer triagem de uma pilha de PRs que não existia na noite anterior
  • Alguns são excelentes, alguns têm erros, e alguns trazem à tona perguntas que ninguém havia feito
• Pela primeira vez na história do trabalho intelectual, quem sai do expediente não leva consigo a única cópia do cérebro
• O conceito de 9-9-6 está, na prática, morto; um funcionário 24/7 não é alguém que trabalha 24 horas por dia, mas alguém cujos agentes trabalham em grande paralelismo
• Em 2026, a maioria das equipes ainda terá gargalos não na digitação, mas na coordenação, e a reorganização das estruturas ainda está só no começo

A fragmentação dos papéis — ascensão e descida ao mesmo tempo

• Dentro de equipes nativas de IA, existe um padrão muito mais complexo do que a narrativa limpa de que “todo mundo sobe de nível”
• Movimento para cima: os melhores engenheiros viram PMs mais eficazes, os melhores PMs se tornam arquitetos de sistemas, e os melhores arquitetos passam a pensar em distribuição, crescimento e estrutura de mercado
  • Para esse grupo, é o ambiente de trabalho com maior alavancagem da história
• Fragmentação para baixo: ao mesmo tempo, muitos engenheiros não estão virando arquitetos, mas se tornando redatores de especificação, revisores e babás de agentes
  • São pessoas que traduzem intenção em prompts legíveis por máquina e avaliam o trabalho da máquina com base em critérios que elas mesmas não dominam por completo
  • Parte disso é trabalho importante, mas parte é apenas a versão 2026 de entrada de dados, embalada em nova terminologia
• A tendência é que esses papéis fragmentados tenham salários mais baixos, menor valorização e, em muitos casos, se tornem becos sem saída de carreira
• A diferença salarial entre o terço superior que consegue operar frotas de agentes com eficiência e a camada intermediária que apenas administra saídas tende a ser maior do que o fosso salarial entre engenheiros e vendedores na era anterior
• Em infraestrutura de IA, desempenho de kernel, design de compiladores e abstração de hardware ainda permanecem como fossos defensáveis — no nível mais baixo da engenharia de sistemas, continua sendo necessária alta precisão determinística

O paradoxo de Jevons — versão código

• Em 1865, o economista William Stanley Jevons observou que máquinas a vapor mais eficientes não reduziram o consumo de carvão — na verdade, aumentaram esse consumo, porque a eficiência ampliou o conjunto de coisas para as quais valia a pena construir motores
• O mesmo está acontecendo com software à medida que o custo unitário de escrever código converge para zero — em vez de escrever menos, estamos escrevendo muito mais e lançando muito mais
• Empresas que acreditam que as leis de escala são ilimitadas estão se estruturando em torno disso, e elas tendem a ser as vencedoras de uma distribuição em lei de potência
• Fenômenos que já estão acontecendo na prática:
  • Agentes abrem PRs, revisam o trabalho uns dos outros e os fecham sem que um humano toque no teclado
  • Suites de teste autocurativas se reescrevem quando o código-base muda
  • Loops autônomos de experimentação executam, medem e desmontam 100 hipóteses enquanto uma equipe, no passado, rodaria 3
  • A documentação se atualiza automaticamente no merge, usando habilidades de IA que se autoaperfeiçoam
• Equipes reestruturadas em torno de agentes já alcançam 3x, 5x, 10x de output em relação a um ano atrás, e a curva não está se achatando — está subindo
• A segunda lição de Jevons: quando a oferta explode, seleção passa a ser o centro de tudo
  • Operadores que orientam a frota de agentes para os problemas certos, filtram o que tem valor na saída e integram os resultados em algo coerente estão realizando hoje o trabalho de maior alavancagem em software
  • O valor do trabalho já não é definido pelo esforço de produção, mas por direção, seleção e coerência

Da engenharia determinística para a engenharia probabilística

• A engenharia determinística foi o contrato que dominou a maior parte da história do software — se você escrevia, testava e revisava o código, conseguia compreender seu comportamento dentro de um intervalo bem entendido, e bugs eram reproduzíveis
• A engenharia probabilística já chegou às equipes de fronteira — a maior parte do codebase é gerada por sistemas probabilísticos, revisada sob pressão de tempo e integrada a um todo que nenhum humano projetou sozinho
• A assimetria central: gerar ficou barato, mas validar não ficou
  • Um agente pode gerar um PR de 500 linhas em menos de 1 minuto, mas capturar bugs sutis como problemas de concorrência, interpretação errada da especificação ou implementações divergentes da intenção ainda pode exigir mais de 1 hora de um engenheiro sênior
  • A revisão escala mais devagar do que a geração e escala pior do que linearmente em relação ao volume de output — quanto mais do codebase é escrito por agentes, maior o contexto necessário para avaliar cada parte
• Depois de certo tamanho, o sistema produz mais do que os humanos conseguem avaliar com confiança, e a exatidão se torna probabilística
• Exemplos concretos: uma condição de corrida que passa na suíte de testes 9 vezes em 10; uma funcionalidade perfeita em staging, mas que falha sob uma distribuição de prompts não prevista; uma migração que corrompe silenciosamente 1 linha em 10 mil e só é descoberta 3 semanas depois
• Proximal e Modular publicaram uma pesquisa conjunta sobre testes de tarefas básicas em sistemas agentes de fronteira, e os padrões de falha documentados correspondem diretamente a esse fenômeno
• O modo de falha não é um colapso dramático, mas uma degradação lenta e silenciosa — mais geração, menos qualidade de revisão, acúmulo de defeitos discretos e uma erosão silenciosa da confiança até que clientes, auditorias ou incidentes em produção revelem o problema
• Ainda não existem ferramentas capazes de resolver isso de forma adequada — respostas culturais como merges pequenos, gates rígidos, ceticismo implacável diante de outputs polidos, observabilidade e disciplina de rollback ajudam, mas cultura não escala além de certo tamanho de equipe
• Quem resolver esse problema definirá o sistema operacional do desenvolvimento sério de software da próxima década

Diferenças na velocidade da transição por setor

• A transição da engenharia determinística para a probabilística não é uniforme, e se organiza em camadas de acordo com setor e perfil de risco

• Camada determinística

  • Domínios altamente regulados e de alto risco, como aviônica, dispositivos médicos, infraestrutura de negociação financeira, sistemas de controle nuclear e o núcleo de redes de pagamento
  • Adoção cuidadosa do suporte por agentes, por trás de verificação formal, simulações extensas e cadeias de assinatura humana
  • Isso não é falta de imaginação, mas julgamento correto sobre o nível de risco

• Camada probabilística

  • Software de consumo, ferramentas internas, sistemas de marketing, a maior parte do SaaS, infraestrutura de conteúdo e produtos experimentais ou em estágio inicial
  • O custo do bug é um rollback, um pedido de desculpas ou um hotfix, e em troca se ganha uma velocidade de iteração que o mundo determinístico não consegue acompanhar estruturalmente
  • Equipes probabilísticas conseguem aprender 10x mais por trimestre do que concorrentes determinísticos

• Zona de convergência (Convergence Zone)

  • À medida que os modelos ficam mais inteligentes e os harnesses melhoram, a fronteira do que é “seguro o suficiente para ser feito probabilisticamente” continua avançando
  • Métodos probabilísticos já penetram 10% de cada vez por baixo em domínios que hoje ainda parecem determinísticos, como partes de seguros, saúde e infraestrutura corporativa
  • Líderes em engenharia probabilística estão reconstruindo guardrails determinísticos — checagens formais, caminhos críticos verificados e sistemas híbridos nos quais a geração probabilística é cercada por validação determinística
• Os vencedores da próxima década serão as equipes que sabem em qual camada estão, resistem à tentação de fingir que pertencem a outra e definem com precisão os limites dentro do próprio stack

A frota de agentes (Agentic Fleet)

• “Turno de fábrica” não é a metáfora adequada — trabalhadores de fábrica eram o sistema que estava sendo automatizado, e não é isso que temos agora
• A metáfora correta é uma frota de agentes — embora a ordem, a hierarquia e a confiabilidade implícitas em “frota” ainda estejam acima do que a realidade oferece
  • Na prática, o que a maioria dos operadores executa se parece mais com uma multidão frágil de contratados do que com uma marinha bem treinada
  • Os agentes têm capacidades desiguais, comportamento probabilístico, às vezes estão confiantemente errados e custam caro quando executados em escala
  • A camada de orquestração quebra, janelas de contexto explodem e o custo de inferência aparece em faturas que ninguém gosta de mostrar ao conselho
• Ainda assim, o conceito de frota é válido: composição (agentes diferentes para tarefas diferentes), coordenação (handoffs, dependências, escalonamento), cadeia de comando (decisão da missão, regras de engajamento, revisão de resultados) e trabalho em turnos (o comandante dorme enquanto o trabalho continua dentro da faixa de instruções e chega um relatório pela manhã)
• O que define uma boa frota não é volume de produção, mas a consistência do que ela produz
• Novo formato de trabalho:
  • Pela manhã, triagem e merge
  • No meio do dia, trabalho humano de alta alavancagem — conversas com clientes, estratégia, decisões de produto e redação de especificações que vão orientar a execução noturna
  • À tarde, revisão e redirecionamento quando os primeiros agentes começam a voltar
  • No fim do dia, algo que a geração anterior não fazia — handoff — colocar trabalho na fila e passar à frota de agentes as especificações das tentativas noturnas; algumas vão errar, algumas vão brilhar, e só humanos conseguem julgar a diferença

Construir para modelos que ainda não foram lançados

• Um ponto enfatizado de forma consistente nos últimos anos: o modelo que você usa hoje é o mais burro entre os modelos que usará no futuro
• Isso não significa que o crescimento de capacidade será suave — custo, latência, confiabilidade e limites de escala podem tornar a curva mais complexa
• Ainda assim, a aposta direcional é bem sustentada pelo que se observa na camada de infraestrutura: as capacidades de fronteira nos próximos 6 a 12 meses superarão de forma significativa as de hoje, e a diferença entre o melhor modelo atual e o melhor modelo daqui a 1 ano provavelmente será maior do que a diferença entre o ano passado e este ano
• Implicação estratégica: as organizações precisam construir capacidade não para os modelos atuais, mas para os modelos que ainda não têm
  • Saber escrever especificações, cultivar cultura de revisão, instrumentar observabilidade, operar frotas de agentes e manter rituais de treinamento que preservem a habilidade dos juniores — tudo isso é scaffolding não para as capacidades de 2026, mas para 2027–2028
• Empresas que constroem esse scaffolding agora absorverão o próximo salto de capacidade como alavancagem; empresas que esperarem as ferramentas amadurecerem gastarão o primeiro ano aprendendo o que os pioneiros já sabem
• É preciso disposição para investir em excesso em especificação, revisão e disciplina operacional em relação ao que os modelos atuais exigem
• A irrelevância nesta era não se anuncia sozinha — ela chega como uma incapacidade gradual de acompanhar equipes que, um ano antes, nem pareciam claramente melhores

Músculos que serão perdidos

• Quer a IA estratifique a sociedade de forma decisiva, quer em grande parte a democratize, os humanos são excelentes em otimizar o caminho de menor resistência
• A tese central: se você não constrói algo diretamente, também perde a capacidade de avaliar o que foi construído
• Isso já está acontecendo: engenheiros júnior que dependem de IA desde a primeira semana lançam rápido e produzem código polido, mas quando o modelo falha de um jeito imprevisto não conseguem encontrar o bug — porque não desenvolveram o modelo mental interno do sistema que só se forma ao brigar pela centésima vez com um stack trace às 2 da manhã
• Taste não se aprende clicando em aprovar um rascunho polido; judgment não se desenvolve ao aceitar em 5 segundos uma resposta plausível da máquina em vez de passar uma tarde inteira com um problema difícil; craft não se adquire revisando o trabalho de outro agente
• Esta é a crise de treinamento que a maioria das organizações ainda não percebeu
  • O modelo de aprendizado por apprenticeship da engenharia de software (juniores lançam coisas pequenas → sêniors revisam → juniores absorvem taste pela tinta vermelha) está colapsando — juniores lançam por meio de agentes, e sêniors passam a revisar saídas de agentes, não saídas humanas
  • De onde virá o ofício da próxima geração? Como treinar taste sem repetição? Como substituir mentoria sobre algo que o mentorado nem chegou a escrever do zero?
• Em muitas organizações tradicionais, a geração atual de engenheiros sênior é a última coorte totalmente treinada pelos métodos antigos
• A resposta equilibrada: de forma intencional e regular, fazer diretamente, sem frota, alguma coisa importante do jeito difícil — a maioria dos colegas não vai manter esse músculo, e daqui a 10 anos isso pode fazer diferença

A parte inquietante

• Este ensaio deliberadamente não termina em otimismo — fingir que a mudança não virá não impede sua chegada
• O trabalho já mudou para sempre, e de forma evolutiva e gradual, na velocidade da IA
• Os humanos vão recuperar o dia para o trabalho em que são realmente necessários, e as máquinas vão recuperar a noite para o trabalho que sempre foi, na prática, mão de obra simples
• Cenários plausíveis para os próximos anos:
  • Uma camada de trabalhadores exaustos pela carga de revisão
  • Uma camada de papéis fragmentados que o sistema exige, mas não recompensa
  • Uma geração de juniores incapaz de desenvolver o ofício que os sêniors de hoje usam para julgar
  • Equipes que confundem volume de output com qualidade do trabalho e só percebem a diferença quando os incidentes acontecem
  • Um fosso cada vez maior entre organizações que construíram músculos operacionais para o próximo modelo e as que não construíram
• A mensagem central: construa uma organização para os modelos que você ainda não tem, às vezes faça você mesmo as coisas difíceis para lembrar como se faz, despache sua frota noturna e durma bem sabendo que o trabalho está andando — mas continue alerta para a possibilidade de que parte do que volta esteja errado de formas que você já não foi treinado para enxergar
• O funcionário 24/7 não é uma promessa, mas uma realocação e uma aposta no futuro da engenharia probabilística — uma aposta de que o humano dentro do loop continuará afiado, honesto e bem treinado o bastante para merecer estar no loop, e de que a organização ao redor desse humano será construída não para os modelos de hoje, mas para modelos que ainda não foram lançados