Статья подготовлена на основе доклада Фионы Фунг (Fiona Fung), ведущего инженера команды Claude Code. Первоисточник.
Недавно я наткнулся на материал, который показался мне крайне любопытным. Крайне редко AI-компании уровня Anthropic делятся инсайтами об устройстве своих внутренних процессов.
Особенно ценно, что спикером выступает Фиона Фунг — ключевой инженер, стоящая за развитием Claude Code.
Фиона рассказывает, как их команда трансформировала методологию разработки, став по-настоящему «AI-native» организацией. Ознакомившись с докладом, я поймал себя на мысли, что многие из озвученных принципов уже давно прижились в нашей собственной команде, что лишь подтверждает правильность выбранного вектора.
Фундаментальный принцип, который красной нитью проходит через все выступление: при возникновении любой задачи следует задаться вопросом: «Можно ли это автоматизировать?». Это созвучно моей профессиональной догме: если какое-то действие повторяется чаще трех раз — пора внедрять AI-автоматизацию.
То, что команда Claude Code применяет эту логику к управлению всей инженерной структурой, — мощный стимул развиваться дальше. В этой статье я разберу ключевые тезисы доклада, которые будут полезны любому современному инженеру.
Гипотеза сдвига узких мест
Фунг начинает с провокационного тезиса: все существующие методологии разработки (от Waterfall до Agile) исторически строились вокруг допущения, что написание кода — это дорого. Инженерный ресурс стоил больших денег, поэтому процессы были «заточены» на минимизацию рисков через бесконечные согласования, документацию и совещания.
В эпоху AI-агентов эта парадигма разрушена. Генерация кода перестала быть узким местом.
Фиона использует ключевой термин — «сдвиг». Узкое место не исчезло, оно переместилось в плоскость верификации, код-ревью и безопасности. Код создается настолько стремительно, что основная сложность теперь заключается в контроле качества и способности команды «переварить» такой поток изменений.
Переход к AI-native модели сродни смене лошадиной тяги на двигатель внутреннего сгорания: нельзя просто сменить «двигатель», нужно полностью перестраивать инфраструктуру, правила движения и планирование.
Пять направлений для трансформации
Фунг выделяет пять сфер, где традиционный подход уже не работает:
-
Планирование: прежние циклы неактуальны из-за скорости разработки.
-
Владение кодом: в условиях AI-генерации понятие автора становится размытым.
-
Ревью: требуется новый масштаб и инструменты.
-
Структура команды: роли трансформируются.
-
База знаний: документация перестает быть единственным источником истины.
Вот какие нормы внедрили в Claude Code:
Главное — смещение фокуса человеческого внимания на критические области, быстрое вовлечение новичков (они могут приносить пользу уже через неделю), отказ от избыточного планирования в пользу быстрого прототипирования и акцент на креативности при найме.
1. Новый подход к планированию
Фиона отмечает, что длинные дорожные карты (roadmap) устаревают через пару месяцев. Теперь они перешли к методу JIT (Just-In-Time) планирования — планировать ровно столько, сколько нужно здесь и сейчас.
Вместо бесконечных дизайн-доков (которые зачастую являются лишь «театром») они сразу делают прототипы. Документация пишется только постфактум. В спорах о реализации побеждает тот, кто предъявляет рабочий код.
Создавать — дешево. Спорить — дорого.
2. Автоматизация как инстинкт
В команде Claude Code автоматизация — это не разовая акция, а «мышечная память». Даже мелкие рутинные задачи, вроде суммаризации фидбека, делегируются скриптам и AI-агентам.
Раньше автоматизация была «дорогим удовольствием», доступным лишь для критических задач. Сейчас, когда стоимость создания автоматизаций стремится к нулю, логика меняется: если что-то требует более трех итераций — автоматизируйте немедленно.
3. Code Review: доверяй, но проверяй
На вопрос «как вы справляетесь с темпом ревью?», ответ прост: «Trust but verify».
Claude забирает на себя 70% рутины: линтинг, проверку стиля, базовое тестирование. Человеческий интеллект остается востребованным там, где нужно суждение: юридические риски, эстетика продукта, безопасность архитектуры.
4. Стирание границ ролей
PM’ы пишут код, инженеры занимаются копирайтингом. Это больше не разрыв между отделами, а синергия. Главным критерием найма становится не умение печатать код (этого добра навалом), а «вкус» (taste) и способность принимать решения: *что именно* нужно строить.
5. Культура отмены процессов
Организации склонны «обрастать» процессами. Фиона призывает безжалостно отменять то, что перестало быть полезным. Пример с еженедельными статус-митингами, где все смотрят в экран, крайне показателен: если совещание не несет ценности, оно подлежит удалению.
Итоговые мысли
Быть AI-native — это не про покупку API-ключей, а про полную перестройку философии компании: от планирования до обмена знаниями.
Даже сама команда Claude признается, что они всё еще в поиске оптимальной модели. Технологический сдвиг требует организационной адаптации. Главное, с чего стоит начать — это простая привычка: автоматизируй повторения, удаляй лишнее, делегируй рутинные решения ИИ.
