Armin Ronacher — создатель Flask, один из основателей Sentry — написал эссе «The Tower Keeps Rising». Simon Willison, один из авторов Django и создатель Datasette, выделил из него одну цитату. Она разошлась по профессиональному сообществу, потому что попала точно в нерв: все строят AI-first команды, никто не говорит вслух о том, что при этом теряется.
Контекст
У каждого программного проекта есть общий язык — не английский и не Python. Это живое понимание того, что делает система, где проходят границы, какие инварианты критичны, кто за что отвечает и почему всё устроено именно так. Этот язык нигде не записан полностью. Он живёт в code review, в разговорах, в спорах, в том опыте, который возникает, когда ты объясняешь своё изменение другому человеку.
До агентов этот общий язык поддерживался трением. Хочешь изменить storage layer чужого компонента? Читай код, задавай вопросы, координируйся с командой, чьи сервисы от него зависят. Медленно. Раздражает. Но в этом процессе твоё понимание становилось чужим — и оба выясняли, согласны ли вы всё ещё насчёт того, как работает система. Ronacher формулирует это прямо: «This friction synchronizes people».
Его эссе вышло в момент, когда agentic-разработка перестала быть экспериментом и стала производственной практикой. Willison сам недавно писал, что разрабатывал sqlite-utils 4.0 совместно с Claude Fable — и именно эта конкретика даёт цитате Ronacher дополнительный вес. Это не абстрактная тревога, это наблюдение практикующих инженеров.
Аналитика
Агенты убирают трение. Они читают код без вопросов, делают изменения без объяснений, не проводят координационных встреч. С точки зрения скорости — прекрасно. С точки зрения передачи понимания внутри команды — уязвимость, которую не сразу видно. Можно назвать это phantom understanding: система работает, тесты зелёные, фичи выходят — но никто в команде не держит полную картину. Агент соединяет куски быстро, но не создаёт общего языка.
Это не аргумент против агентов. Это аргумент против наивного взгляда на автоматизацию как на чистый выигрыш. Каждый раз, когда агент делает изменение без «объяснения себе», часть контекста не передаётся. Накапливается архитектурный долг другого типа — не технический, а когнитивный. Tower keeps rising. Но основание — уже не общее понимание команды, а только то, что кодифицировано в тестах и контрактах.
Для AI-first компаний вывод парадоксальный: чем агрессивнее вы автоматизируете разработку, тем важнее сознательно проектировать механизмы передачи контекста. Не потому что агенты плохи — а потому что они оптимизированы под скорость выполнения, а не под синхронизацию понимания. Это принципиально разные задачи, и одна не вытекает из другой автоматически.
Кейсы применения в бизнесе
B2B-SaaS стартап с агентной разработкой: у вас 3 разработчика и несколько AI-агентов в pipeline. Введите артефакт Architecture Decision Record (ADR), который агент обязан создавать при каждом изменении архитектурного уровня. Агент не просто делает PR — он пишет, почему изменение именно такое и какие инварианты теперь важны. Стоимость: несколько дополнительных секунд и токенов. Результат: команда сохраняет общий язык, onboarding нового человека ускоряется.
Корпорация с legacy: в больших системах неписаное знание критично — особенно там, где годами накапливались неочевидные ограничения. Перед тем как запускать агентов на рефакторинг, проведите сессию «knowledge extraction»: каждый сеньор описывает агенту все неочевидные ограничения своего компонента. Один раз дорого — но дешевле потом разгребать сломанные инварианты, которые никто не задокументировал.
SMB и локальный бизнес в КР и СНГ: небольшие команды особенно уязвимы — уйдёт один человек и унесёт с собой половину понимания системы. Агент как документатор в реальном времени: настройте workflow, где после каждого sprint review агент пишет 1-2 абзаца о том, что изменилось в системе и почему. Это дешевле штатного технического писателя, а артефакт остаётся в команде навсегда.
Кейсы в личной жизни
Разработчик: если ты работаешь с агентом вместо пар-программинга — ты не проходишь через «трение объяснения». Компенсируй это: после каждой сессии с агентом пиши в заметки «что я понял про систему сегодня». Звучит как дедовский способ — но именно это формирует глубокое понимание вместо иллюзии понимания.
Контент-мейкер и продюсер: та же проблема на уровне контентных систем. Если агент пишет скрипты, монтирует, публикует — можно потерять понимание того, почему контент работает. Раз в месяц делай ретроспективу вручную: просматривай топ-видео и формулируй паттерн без помощи AI. Это восстанавливает «общий язык» с аудиторией.
Студент или джуниор-разработчик: соблазн отдать агенту всё огромен. Но именно трение — читать документацию, объяснять себе, почему код работает, пробовать сломать — формирует настоящее понимание. Используй агента как тьютора: задавай ему вопросы, а не просто проси «напиши мне это».
Как применить сегодня
- Добавить в агентный workflow обязательный шаг «explain this change»: агент пишет 3-5 предложений о том, что изменилось и почему именно так.
- Для каждого компонента системы создать invariants.md — список неочевидных ограничений, который обновляется при каждом архитектурном изменении.
- Раз в sprint проводить «no-agent review»: один из разработчиков объясняет вслух, что делает система — без помощи AI. Не ретро, а диагностика общего языка.
- При онбординге нового человека первые 1-2 недели намеренно ограничить доступ к агентам: пусть читает код и задаёт вопросы живым людям — восстанавливает классическое трение.
- Prompting-шаблон для агентного PR: «Опиши это изменение так, чтобы разработчик без знания кодовой базы понял: что изменилось, почему, и какие инварианты теперь важно знать».
«This friction synchronizes people» — Armin Ronacher, The Tower Keeps Rising