Эта шутка работает именно потому, что это не просто шутка
Назовём это Meteor development: пункт назначения объявляют сначала, остановки меняются по ходу, бюджет как будто сам собой должен сойтись, а engineering продолжает прокладывать рельсы, когда поезд якобы уже “вот-вот отправится”.
Мем смешной, потому что этот сценарий постоянно происходит в реальных командах.
Основатель обещает feature ещё до того, как появились edge cases. Продуктовая команда перерисовывает onboarding flow, когда design уже ушёл дальше. Руководство видит, что AI быстро собрал предыдущий screen, и решает, что “ещё одна integration” тоже должна быть дешёвой. Маршрут всё время меняется. Сроки — нет.
Плохая новость в том, что никакой архитектурный паттерн не заставит людей перестать строить нереалистичные ожидания.
Хорошая новость в том, что эти нереалистичные ожидания больше не обязаны автоматически превращаться в engineering paralysis.
Настоящая боль была не только в ожиданиях
Плохое планирование раздражает. Оно сжигает время, усиливает давление и заставляет снова и снова торговаться. Но само по себе оно ещё не уничтожает delivery.
Команду ломает по-настоящему другое: когда каждое позднее изменение продукта превращается в риск для всей системы.
Это классический failure mode быстрых AI-generated codebases. Version one выходит так быстро, что все начинают верить: и каждый следующий change тоже должен быть быстрым. А потом приходит реальность:
- нужно поменять auth provider
- analytics нужно сделать optional
- один deep link path оказывается неверным
- одно styling-решение расползлось по 40 screens
- одна “маленькая” feature проходит через три модуля, которые вообще не должны были зависеть друг от друга
В этот момент команда борется уже не только с нереалистичными ожиданиями. Она ещё и застревает с codebase, которая не умеет локально поглощать изменения.
Вот это и есть двойной налог. Организационная проблема и так тяжёлая. Техническая проблема делает её ещё хуже.
Meteor development первым ломает хрупкие codebases
Именно поэтому этот мем так точно попадает в engineers.
Мы все видели один и тот же pattern:
- Маршрут объявляют раньше, чем карта становится реальной.
- Объём работ продолжает раздуваться, хотя implementation уже началась.
- Тот же самый срок остаётся на слайде.
- Engineering говорят: “просто адаптируйтесь”.
Если у системы слабые boundaries, то “адаптироваться” на практике значит:
- reverse-engineering AI-generated abstractions, которые никто осознанно не проектировал
- распутывать модули, которые лезут во внутреннюю implementation друг друга
- чинить regressions в частях app, которые никто не хотел трогать
- терять неделю на сохранение implementation, которую вообще не стоило сохранять
На этом этапе команда уже не строит продукт. Она занимается археологией под давлением сроков.
И вот это как раз больше не нужно терпеть.
Autotomy меняет failure mode
Autotomy не делает фантазийные оценки реалистичными. Он делает кое-что полезнее: сохраняет систему replaceable.
Идея проста. Если модуль неверный, опоздал или больше не соответствует маршруту, вы должны иметь возможность отсечь его, заменить и продолжить движение.
Для этого нужны несколько вещей, по которым нельзя торговаться:
- interfaces вокруг volatile services вроде auth, analytics, storage и notifications
- один composition root, который решает, какую implementation реально использует app
- dependency boundaries, которые не дают screen напрямую импортировать vendor details
- contract tests и deterministic checks, которые проверяют поведение при замене модулей
- dependency tiers, чтобы optional tools не вели себя как launch-critical infrastructure
Когда это есть, постоянно движущаяся цель всё ещё раздражает. Но она перестаёт быть экзистенциальной угрозой.
Смена provider превращается в replacement за interface. Продуктовый объезд становится локальным rewrite, а не системным refactor. Плохой AI-generated module становится тем, что вы удаляете, а не тем, что пытаетесь бережно сохранить.
Когда маршрут меняется, development всё равно может продолжаться
Вот это и есть практический сдвиг, который важен.
Без Autotomy Meteor development звучит так:
“Мы снова поменяли onboarding plan, поэтому теперь нужно трогать auth, profile state, analytics, styling и navigation. Дайте нам неделю, чтобы понять, что именно сломается.”
С Autotomy это звучит иначе:
“Ожидание всё ещё нереалистичное, но изменение локализовано. Нам нужно заново договориться об объёме или дате, а не перестраивать весь app.”
Это гораздо лучший режим отказа.
Да, вам всё ещё, возможно, придётся спорить с обещаниями по delivery. Возможно, придётся дробить launch, убирать одну остановку из маршрута или говорить “нет” на last-minute branch line. Но engineering-организация больше не обязана страдать дважды. Человеческая проблема остаётся человеческой. Проблема software остаётся управляемой.
Скорость AI делает это важнее, а не менее важным
AI coding — одна из причин, почему Meteor development сейчас встречается чаще.
Когда Cursor или Claude Code могут собрать first version feature за часы, руководство начинает считать, что и каждая следующая итерация должна вести себя так же, как первый черновик. Они видят скорость на поверхности и принимают её за дешёвые изменения на всей глубине системы.
Это не так.
AI отлично заполняет implementation. Но он не отвечает за то, чтобы система оставалась структурно безопасной, когда меняется продуктовая реальность. Если у codebase нет boundaries, AI speed просто быстрее доведёт вас до fragility.
Поэтому я снова и снова возвращаюсь к одной мысли: правильный ответ на AI-native development — не больше оптимизма, а больше replaceability.
Быстро генерировать. Жёстко enforce-ить boundaries. Детерминированно validate-ить. Удалять плохие модули, когда меняется маршрут. Держать радиус воздействия локальным.
С фантазийной частью вам всё равно придётся разбираться самим
Не существует framework, который войдёт на встречу по планированию и скажет кому-то, что его дата запуска выдумана.
Autotomy не решает приоритизацию, не лечит фантазийные дорожные карты и не мешает заинтересованной стороне дорисовать новую станцию на карте уже после начала стройки.
С этой частью вам всё равно придётся разбираться как инженерам и как взрослым людям.
Но это и должно быть единственной трудной частью.
Работа не должна ещё и включать в себя оживление codebase, которая рушится каждый раз, когда сдвигается план.
Если Meteor development останется чем-то вроде постоянной организационной погоды, пусть. Пусть он остаётся мемом про управление ожиданиями.
С Autotomy он больше не обязан быть мемом ещё и про инженерные страдания.