A piada funciona porque não é só uma piada

Vamos chamar isso de Meteor development: o destino é anunciado primeiro, as paradas mudam no meio do caminho, o orçamento fica implícito e engineering precisa continuar assentando trilhos quando o trem supostamente já está “quase saindo”.

O meme é engraçado porque essa dinâmica acontece o tempo todo em times reais.

Um fundador promete uma feature antes mesmo de os edge cases existirem. A equipe de produto redesenha o onboarding flow quando design já seguiu adiante. A liderança vê que a AI fez a tela anterior rápido e conclui que “só mais uma integration” deveria ser simples. A rota se move o tempo todo; o prazo não.

A má notícia é que nenhum padrão de arquitetura consegue impedir pessoas de terem expectativas irreais.

A boa notícia é que essas expectativas irreais não precisam mais virar engineering paralysis automaticamente.

A dor real nunca foi só a expectativa

Planejamento ruim é irritante. Queima tempo, aumenta a pressão e força renegociações. Mas, sozinho, ele não destrói a entrega.

O que realmente quebra o time é quando cada mudança tardia de produto vira um risco para o sistema inteiro.

Esse é o failure mode clássico dos codebases AI-generated que andam rápido. A version one sai tão depressa que todo mundo começa a supor que cada mudança futura também deveria ser rápida. Então a realidade chega:

  • o auth provider precisa mudar
  • analytics precisa virar optional
  • um deep link path está errado
  • uma decisão de styling se espalhou por 40 screens
  • uma feature “pequena” atravessa três módulos que não deveriam se tocar

Nesse ponto, o time já não está lidando só com expectativas irreais. Também está preso a uma codebase que não consegue absorver mudança localmente.

Esse é o imposto em dobro. O problema organizacional já era difícil; o problema técnico só piora tudo.

Meteor development quebra primeiro as codebases frágeis

É por isso que o meme acerta engenheiros em cheio.

Todo mundo já viu o mesmo padrão:

  1. A rota é anunciada antes de o mapa existir de verdade.
  2. O escopo continua crescendo enquanto a implementation já começou.
  3. O mesmo prazo permanece na apresentação.
  4. Dizem para engineering “apenas se adaptar”.

Se o sistema tem boundaries fracas, “adaptar” na prática significa:

  • fazer reverse engineering de abstrações AI-generated que ninguém projetou
  • desembaraçar módulos que alcançam a implementation interna uns dos outros
  • corrigir regressões em partes do app que ninguém queria tocar
  • perder uma semana tentando preservar a implementation errada

Nesse momento o time já não está construindo produto. Está fazendo arqueologia sob pressão.

Essa é a parte que já não precisamos mais aceitar.

Autotomy muda o failure mode

Autotomy não transforma estimativas fantasiosas em algo realista. Ele faz algo mais útil: mantém o sistema substituível.

A ideia central é simples. Quando um módulo está errado, atrasado ou já não combina com a rota, você deveria conseguir cortá-lo, substituí-lo e continuar andando.

Para isso, algumas coisas são inegociáveis:

  • interfaces em torno de serviços voláteis como auth, analytics, storage e notifications
  • um composition root que decide qual implementation o app realmente usa
  • dependency boundaries que impedem uma screen de importar vendor details diretamente
  • contract tests e deterministic checks para verificar o comportamento quando módulos são trocados
  • dependency tiers para que tools optional não se comportem como infraestrutura crítica de lançamento

Com isso no lugar, um alvo móvel continua irritante. Mas deixa de ser existencial.

Trocar de provider vira um replacement atrás de uma interface. Um desvio de produto vira uma reescrita local em vez de um refactor do sistema inteiro. Um módulo AI-generated ruim vira algo que você apaga, não algo que tenta preservar com cuidado.

Quando a rota muda, o desenvolvimento ainda pode continuar

Essa é a mudança prática que importa.

Sem Autotomy, Meteor development soa assim:

“Mudamos o onboarding plan de novo, então agora precisamos mexer em auth, profile state, analytics, styling e navigation. Dá uma semana para entender o que vai quebrar.”

Com Autotomy, soa mais assim:

“A expectativa continua irreal, mas a mudança está localizada. Precisamos renegociar escopo ou data, não reconstruir o app.”

Esse é um modo de falha muito melhor.

Você ainda pode precisar empurrar de volta promessas de entrega. Ainda pode precisar dividir o launch, cortar uma parada da rota ou dizer não para uma branch line de última hora. Mas a organização de engenharia não precisa sofrer duas vezes. O problema humano continua humano. O problema de software continua administrável.

A velocidade da AI torna isso mais importante, não menos

AI coding é uma das razões pelas quais Meteor development aparece mais agora.

Quando Cursor ou Claude Code conseguem gerar a first version de uma feature em horas, a liderança começa a presumir que cada iteração futura deveria ter o mesmo comportamento da primeira. Eles veem velocidade na superfície e concluem que mudar também é barato até o fundo.

Não é.

AI é excelente em preencher implementation. Ela não é responsável por manter o sistema estruturalmente seguro quando a realidade do produto muda. Se a codebase não tem boundaries, a velocidade da AI só faz você chegar mais rápido à fragilidade.

É por isso que eu sempre volto ao mesmo ponto: a resposta certa ao AI-native development não é mais otimismo. É mais substituibilidade.

Gere rápido. Faça enforcement de boundaries. Valide de forma determinística. Delete módulos ruins quando a rota mudar. Mantenha o raio de impacto local.

A parte fantasiosa ainda continua sendo sua

Não existe framework que vá entrar na reunião de planejamento e dizer a alguém que a data de lançamento dele é imaginária.

Autotomy não resolve priorização. Não conserta planos fantasiosos. Não impede uma parte interessada de desenhar outra estação no mapa quando a construção já começou.

Essa parte você ainda precisa lidar como engenheiro e como adulto.

Mas essa deveria ser a única parte difícil.

O trabalho não deveria incluir também ressuscitar uma codebase que colapsa toda vez que o plano muda.

Talvez Meteor development seja um clima organizacional permanente. Tudo bem. Que continue sendo um meme sobre gestão de expectativas.

Com Autotomy, ele não precisa continuar sendo um meme sobre sofrimento de engenharia.