В начале июня 2026 года Simon Willison процитировал мысль Charity Majors, которую давно ждали многие технические руководители. Не очередной манифест «ИИ всё изменит» и не ретроградный призыв притормозить. Трезвый разбор того, почему в одной команде одновременно правы те, кто жмёт на газ, и те, кто жмёт на тормоз — и что с этим делать.
Контекст
Charity Majors — один из наиболее уважаемых голосов в инженерной культуре: CTO Honeycomb, автор книг по observability, человек с репутацией, который говорит неудобные вещи прямо. Её тезис появился на фоне нарастающего разлома внутри технологических компаний: одни команды интегрируют AI-агентов в каждый этап разработки и получают ощутимый прирост скорости, другие смотрят на это с нарастающей тревогой — и у обоих лагерей есть весомые аргументы.
Индустрия уже прошла несколько волн «хайп-технологий», где можно было подождать и вскочить на зрелый поезд. Сейчас картина другая: разрыв в скорости между командами, активно использующими AI-инструменты, и теми, кто держится в стороне, растёт быстрее, чем обычно. Это не нормальный технологический цикл с предсказуемым горизонтом. Именно это пугает энтузиастов — и именно это заставляет их торопиться.
Скептики видят другое. Когда код пишется и мёрджится быстрее, чем инженеры успевают его читать, в областях, где ни у кого нет полного контекста, система незаметно деградирует. Институциональные знания испаряются. Дежурные смены превращаются в мясорубку. Продукт начинает «бормотать в бессмыслицу» — хорошая метафора для состояния, когда никто до конца не понимает, как система работает и почему.
Аналитика
Главный нерв этой дискуссии — отсутствие естественной обратной связи между двумя лагерями. Энтузиаст видит: задача решена, фича выехала, конкурент позади. Скептик видит: on-call пришёл в 3 ночи, баг в коде, который никто не писал руками, и непонятно, где корень. Эти два опыта не складываются в единую картину — они существуют параллельно и не корректируют друг друга.
Это не конфликт ценностей и не поколенческий разрыв. Это архитектурная проблема организации: как спроектировать feedback loops, которые соединяют скорость доставки с качеством системы. Пока таких петель нет, обе стороны будут жить в разных реальностях — и обе будут правы в своей.
На практике это означает, что вопрос «внедрять AI или нет» — неправильный вопрос. Правильный: как внедрять так, чтобы скорость не создавала невидимый долг, который выстрелит через полгода. Это одновременно инженерная задача (observability, тесты, code review на AI-генерированный код) и лидерская (как построить культуру, где энтузиасты и скептики обмениваются сигналами, а не окапываются в своих нишах).
Кейсы применения в бизнесе
B2B-SaaS стартап. Команда из 8 инженеров активно использует Claude и Cursor для ускорения разработки. Проблема: никто не успевает делать полноценный review AI-генерированного кода, а тесты покрывают только happy path. Решение — ввести обязательный «скептик-спринт» раз в две недели: один инженер целенаправленно ищет хрупкие места в коде, написанном за предыдущие две недели. Метрика: время до первого инцидента на новую фичу. Это не замедляет темп — это делает его устойчивым.
Корпорация с legacy. Большая команда, медленные релизы, давление сверху «внедрить AI». Скептики здесь особенно сильны, потому что цена ошибки высока. Вариант — пилот в изолированном домене с чёткими метриками: выбрать один некритичный процесс (например, внутренняя документация или генерация отчётов), дать команде энтузиастов три месяца, договориться о том, что считается успехом. По итогу — живой кейс с данными, который убеждает скептиков лучше любых презентаций.
SMB или локальный бизнес в КР/СНГ. Здесь другая картина: ресурсов на «скептика» нет, один-два технических человека делают всё. Главный риск — зависимость от AI-инструментов без понимания, что происходит внутри. Практичный подход: использовать AI для ускорения, но фиксировать ключевые решения в человекочитаемых документах. Если AI-агент настроил рассылку или автоматизацию — человек должен уметь объяснить логику без помощи инструмента.
Кейсы в личной жизни
Разработчик. Ты используешь Copilot или Claude для написания кода — и это ускоряет тебя в 2-3 раза на рутинных задачах. Но если ты перестал читать то, что генерируется, ты теряешь понимание системы. Практика: раз в неделю намеренно пиши один модуль без AI. Не для производительности — для поддержания «мышечной памяти» и системного понимания.
Контент-мейкер или фрилансер. AI помогает создавать быстро, но аудитория чувствует, когда за текстом нет автора. Энтузиазм к AI-генерации уместен для черновиков, структуры, SEO-текстов. Скептицизм уместен там, где важен голос: личные истории, спорные мнения, нюансированный разбор. Разграничь зоны — и получишь лучшее от обоих подходов.
Технический руководитель или тимлид. Ты в самом центре этого конфликта. Твоя задача — не выбрать сторону, а создать условия, при которых энтузиасты и скептики обмениваются данными, а не риторикой. Конкретно: retro раз в месяц с вопросом «что мы не понимаем в системе, которую сами создали за последние 30 дней».
Как применить сегодня
- Проведи «карту реальности» в команде: попроси энтузиастов и скептиков независимо написать три главных риска текущего подхода к AI — и сравни списки. Разрыв в восприятии виден сразу.
- Введи метрику «читаемость кода»: какой процент PR за последние два спринта был написан с AI-помощью, и сколько из них прошли полноценный review? Без этих цифр дискуссия остаётся абстрактной.
- Определи «хрупкие зоны» — части системы, где потеря контекста наиболее опасна. Именно туда нужны дополнительные слои observability, прежде чем туда заходит AI-ускорение.
- Попробуй «обратную ретроспективу»: не «что пошло не так», а «что мы не заметили, пока не стало поздно». AI-генерированные баги часто попадают именно в слепые пятна.
- Прочитай оригинальный текст Charity Majors и дай его обеим сторонам команды — без предисловий. Реакция сама покажет, где находится ваша команда на этом спектре.
«Нет естественной обратной связи, соединяющей энтузиастов со скептиками» — и именно её проектирование становится главной инженерной задачей следующего года.