El chiste funciona porque en realidad no es solo un chiste
Llamémoslo Meteor development: primero se anuncia el destino, después cambian las paradas, el presupuesto se da por resuelto y engineering tiene que seguir tendiendo vías cuando el tren supuestamente ya está “a punto de salir”.
El meme hace gracia porque esa dinámica ocurre constantemente en equipos reales.
Un fundador promete una feature antes de que existan los edge cases. El equipo de producto redibuja el onboarding flow cuando design ya siguió adelante. La dirección ve que AI sacó la pantalla anterior muy rápido y concluye que “una integration más” debería ser trivial. La ruta se mueve todo el tiempo; la fecha límite no.
La mala noticia es que ningún patrón de arquitectura puede impedir que la gente tenga expectativas irreales.
La buena noticia es que esas expectativas irreales ya no tienen por qué convertirse automáticamente en engineering paralysis.
El dolor real nunca fue solo la expectativa
Una mala planificación fastidia. Quema tiempo, añade presión y obliga a renegociar. Pero por sí sola no destruye la entrega.
Lo que realmente rompe a un equipo es que cada cambio tardío de producto se convierta en un riesgo para todo el sistema.
Ese es el failure mode clásico de los codebases AI-generated que se mueven rápido. La version one sale tan deprisa que todo el mundo empieza a asumir que cada cambio futuro también debería ser rápido. Y entonces llega la realidad:
- hay que cambiar el auth provider
- analytics tiene que pasar a ser optional
- un deep link path está mal
- una decisión de styling se propagó a 40 screens
- una feature “pequeña” atraviesa tres módulos que no deberían tocarse
En ese momento el equipo ya no lidia solo con expectativas irreales. También está atrapado con un codebase que no puede absorber el cambio de forma local.
Ese es el doble impuesto. El problema organizacional ya era suficientemente duro; el problema técnico solo lo empeora.
Meteor development rompe antes a los codebases frágiles
Por eso el meme le pega tan directo a los engineers.
Todos hemos visto el mismo patrón:
- La ruta se anuncia antes de que el mapa sea real.
- El alcance sigue creciendo cuando la implementation ya empezó.
- La misma fecha límite permanece en la diapositiva.
- A engineering se le pide “simplemente adaptarse”.
Si el sistema tiene boundaries débiles, “adaptarse” en realidad significa:
- hacer reverse engineering de abstracciones AI-generated que nadie diseñó
- desenredar módulos que meten mano en la implementation interna de otros
- arreglar regresiones en partes del app que nadie quería tocar
- perder una semana intentando preservar la implementation equivocada
En ese punto el equipo ya no está construyendo producto. Está haciendo arqueología bajo presión.
Esa parte es la que ya no tenemos por qué aceptar.
Autotomy cambia el failure mode
Autotomy no vuelve realistas las estimaciones fantasiosas. Hace algo más útil: mantiene el sistema reemplazable.
La idea central es simple. Cuando un módulo está mal, llega tarde o ya no coincide con la ruta, deberías poder cortarlo, sustituirlo y seguir avanzando.
Para eso hacen falta varias cosas no negociables:
- interfaces alrededor de servicios volátiles como auth, analytics, storage y notifications
- un composition root que decida qué implementation usa realmente el app
- dependency boundaries que impidan que una screen importe vendor details directamente
- contract tests y deterministic checks para verificar el comportamiento al intercambiar módulos
- dependency tiers para que las tools optional no se comporten como infraestructura crítica de arranque
Con eso en su sitio, un objetivo móvil sigue siendo molesto. Pero deja de ser existencial.
Cambiar de provider pasa a ser un replacement detrás de una interface. Un desvío de producto se vuelve una reescritura local en vez de un refactor de todo el sistema. Un mal módulo AI-generated se convierte en algo que borras, no en algo que proteges con cuidado.
Cuando cambia la ruta, el desarrollo todavía puede continuar
Ese es el cambio práctico que importa.
Sin Autotomy, Meteor development suena así:
“Cambiamos otra vez el onboarding plan, así que ahora hay que tocar auth, profile state, analytics, styling y navigation. Dadnos una semana para averiguar qué se rompe.”
Con Autotomy, suena más bien así:
“La expectativa sigue siendo irreal, pero el cambio está localizado. Tenemos que renegociar alcance o fecha, no reconstruir el app.”
Ese es un modo de falla mucho mejor.
Puede que todavía necesites empujar de vuelta contra promesas de entrega. Puede que aún tengas que partir el launch, quitar una parada de la ruta o decir que no a una branch line de última hora. Pero la organización de ingeniería ya no sufre dos veces. El problema humano sigue siendo humano. El problema de software se mantiene manejable.
La velocidad de AI vuelve esto más importante, no menos
AI coding es una de las razones por las que Meteor development aparece más ahora.
Cuando Cursor o Claude Code pueden generar la first version de una feature en horas, la dirección empieza a asumir que cada iteración futura debería comportarse igual. Ven velocidad en la superficie y asumen que el cambio es barato hasta el fondo.
No lo es.
AI es excelente rellenando implementation. No es responsable de mantener el sistema estructuralmente seguro cuando cambia la realidad del producto. Si el codebase no tiene boundaries, la velocidad de AI solo te hace llegar antes a la fragilidad.
Por eso vuelvo siempre al mismo punto: la respuesta correcta al AI-native development no es más optimismo. Es más reemplazabilidad.
Genera rápido. Haz enforcement de boundaries. Valida de forma determinista. Borra los módulos malos cuando cambie la ruta. Mantén el radio de impacto local.
La parte de fantasía sigue siendo tu problema
No existe ningún framework que vaya a entrar a la reunión de planificación para decirle a alguien que su fecha de lanzamiento es imaginaria.
Autotomy no resuelve la priorización. No arregla las hojas de ruta ilusorias. No impide que una parte interesada dibuje otra estación en el mapa cuando la construcción ya empezó.
Esa parte todavía la tienes que manejar como ingeniero y como adulto.
Pero esa debería ser la única parte difícil.
El trabajo no debería incluir además resucitar un codebase que colapsa cada vez que se mueve el plan.
Meteor development quizá sea un clima organizacional permanente. Bien. Que siga siendo un meme sobre gestión de expectativas.
Con Autotomy, ya no tiene por qué ser también un meme sobre sufrimiento de ingeniería.