Материал подготовлен на основе выступления Фионы Фунг (Fiona Fung), главного инженера команды Claude Code. Ссылка на публикацию.

Сегодня я наткнулся на кое-что, что показалось мне весьма ценным.

Это довольно редко встречается — AI-компании вроде Claude действительно делятся мыслями и размышлениями об организационной структуре.

Особенно примечательно, что автор этого материала — Fiona Fung, главный инженер известной команды Claude Code.

Она рассказывает о том, как их команда, как AI-native организация, изменила рабочие процессы и методологию. Я прочитал всё целиком, посмотрел получасовое видео выступления, и мне всё это очень резонировало, потому что многие идеи и подходы мы в нашей команде уже применяем.

Особенно важна привычка, которую она постоянно упоминает: каждый раз, когда их команда встречает проблему, они спрашивают себя: можно ли это автоматизировать? Это совпадает с философией, которую я всегда проповедую, и с привычками многих коллег. Если нужно повторить что-то более трёх раз, найдите способ автоматизировать это с помощью AI.

Когда я увидел, что команда Claude Code использует практически идентичную логику для управления всей инженерной организацией, я очень вдохновился. Поэтому я хочу выделить самые ценные моменты из этого материала и обсудить их, надеясь, что это будет полезно для вас.

Ключевая гипотеза: сдвиг узких мест

В самом начале она высказала очень интересную мысль. Она сказала, что за все эти годы все процессы разработки ПО, будь то водопад или agile, и все методологии были по своей сути сосредоточены вокруг одной фундаментальной стоимости: написание кода дорого обходится. Время инженера дорогое, поэтому нужно много времени на планирование, документирование требований, проведение различных review, созывание совещаний — всё это управление самым дорогим ресурсом.

Я уверен, что многие, кто работал в интернет-индустрии, согласятся с этим. Но в эпоху AI, или эпоху агентов, эта предпосылка меняется. В команде Claude Code написание кода больше не является узким местом.

Тогда возникает вопрос: если написание кода само по себе больше не является узким местом, то все сопутствующие и следующие за ним процессы нужно полностью переосмыслить.

Fiona Fung использовала очень важное слово, ключевое слово всего её выступления: сдвиг. Узкое место не исчезло, оно просто сместилось на проверку, code review и безопасность. Код генерируется слишком быстро, и новая проблема заключается в том, как убедиться, что этот код правильный, как его поддерживать и как люди могут поспевать с темпом review.

Слева серым показаны старые узкие места — производительность написания кода и развёртывания. Справа чёрным — новые узкие места: проверка, review, кросс-функциональная коллаборация, безопасность.

Это понимание сдвига становится более очевидным по мере того, как AI глубже интегрируется в организационную структуру. Наша организационная структура и процессы действительно нуждаются в переосмыслении в соответствии с этим крупным изменением. Это как переход от повозок к автомобилям — дело не только в замене лошадей на двигатель, но и в переосмыслении дорожной системы, правил дорожного движения и планировки городов.

Пять областей, требующих переосмысления

Итак, что конкретно нужно переделать? Fiona составила таблицу.

Она выделила пять областей, где старые процессы молча выходят из строя.

Способ планирования, потому что скорость разработки и объём выпуска совершенно другие.
Владение кодом (Code ownership) — кто является автором кода, становится странным вопросом.
Code review — новый масштаб, новая форма, новые инструменты.
Состав команды — роли становятся размытыми, какие навыки нужны.
Обмен знаниями — документация больше не единственный источник истины.

Затем она описала пять новых норм, которые они внедрили.

Они включают в себя: сосредоточение человеческого суждения на действительно важных местах; снижение стоимости адаптации новых сотрудников (теперь они могут начать производить код уже через неделю); меньше предварительного планирования, больше прототипирования; при найме смотреть в первую очередь на креативность и суждение, а не на чистую производительность; более плоская организационная иерархия, каждый руководитель сначала работает на передовой.

Каждый из этих пунктов она разбирает подробнее.

1. Изменения в планировании

Раньше, поскольку написание кода было дорогим, нужно было много времени на предварительное планирование. Fiona рассказала, что когда она присоединилась к команде Claude Code, они написали красивую дорожную карту на шесть месяцев. Но поскольку сама Claude Code развивается слишком быстро, через три месяца эта дорожная карта устаревала… Так что сейчас их подход называется JIT-планирование, Just-In-Time — как JIT-компиляция, планирование в нужный момент ровно в нужном объёме.

Больше не пишут длинные документы с описанием дизайна, обсуждают всё прямо в PR или прототипе, не проводят долгие продуктовые ревью, сначала создают прототип, дают его попробовать внутренним пользователям, потом быстро итерируют на основе обратной связи.

Слева — то, что они убрали: необходимость написания design-документа перед кодированием. Fiona говорит, что для большинства работ это театр. Теперь прототип идёт первым, документация, если нужна, пишется после кода.

Справа — то, на что они сделали акцент: проверка. Потому что в AI-native рабочем процессе ошибки проявляются по-другому, и единственный способ гарантировать качество — постоянно сдвигать проверку раньше.

Она также поделилась одной точкой зрения, которая мне особенно нравится.

В технических дискуссиях побеждает тот, кто показывает код.

Если два человека не согласны по поводу решения, самый быстрый способ разрешить конфликт — не продолжать спорить, а попросить Claude сделать прототипы обоих решений и судить по реальному продукту.

Building is cheap.
Arguing is expensive.
Многие функции были изменены в процессе использования, команда итерировала на лету.

Честно говоря, в эпоху AI чрезмерное планирование — это пустая трата.

2. Изменения в автоматизации

Fiona говорит, что в команде Claude Code каждый раз, когда они сталкиваются с такой проблемой, они задают вопрос: можно ли это автоматизировать.

Она привела свой собственный пример: каждое утро она брала кофе и вручную суммировала обратную связь от разных каналов клиентов — это была её ежедневная работа. Позже она превратила это в фоновую автоматизированную задачу, кофе остался тем же, но теперь ей не нужно сидеть и листать всё это.

Звучит мелко, правда? Просто суммирование feedback. Но суть не в самой задаче, суть в привычке. В команде Claude Code каждый человек, встречая повторяющуюся работу, условно рефлекторно спрашивает: можно ли это автоматизировать? Она говорит, что это уже почти стало мышечной памятью.

Это то, о чём я всегда говорю. Если нужно повторить что-то более трёх раз, найдите способ автоматизировать это с помощью AI. В компании я постоянно повторяю команде — это не просто совет, это требование.

Но честно, сделать это командной привычкой намного сложнее, чем сказать об этом. Потому что большинство людей всё ещё понимают автоматизацию очень поверхностно — думают, это просто скрипт, scheduled task, я понимаю, но автоматизация в эпоху AI — это совсем другой масштаб.

Сейчас с Claude Code много автоматизаций можно сделать за десять минут, даже быстрее. Например, я просто сказал Claude: "Напиши hook, чтобы каждый раз перед открытием моего проекта XX он скачивал последний код с github", и через несколько минут это работало.

Раньше автоматизация была дорогой, поэтому только высокочастотные, высокоповторяющиеся, высокоценные вещи стоили автоматизации. Но сейчас стоимость автоматизации почти нулевая, логика меняется на противоположную — практически всё, что повторяется больше трёх раз, нужно автоматизировать.

Кроме workflow, hooks как триггеры — очень полезная штука, может быть, потом я напишу отдельный материал о том, как использовать Agent + hooks для автоматизации, там есть много интересных приёмов.

Когда вы собираете много мелких автоматизаций вместе, вы обнаружите, что они вырастают в огромное дерево, и вы можете даже не заметить это.

Поэтому если вы сейчас колеблетесь, мой совет — не думайте масштабно. Не начинайте с идеи построить полную систему автоматизации, это слишком пугающе и ненужно. Начните с сегодня: найдите одну повторяющуюся работу, потратьте десять минут, чтобы Claude Code или Codex помогли её автоматизировать. Завтра найдите ещё одну, послезавтра ещё одну, через месяц ваш способ работы уже совершенно изменился.

3. Изменения в code review

По поводу code review Fiona говорит, что за последние полгода, когда она разговаривала с другими engineering leaders, её чаще всего спрашивали: как ваша команда поспевает с темпом code review?

Её подход называется Trust but verify, доверяй, но проверяй. Команда Claude Code активно использует функции Code Review. Claude справляется со всеми проверками стиля, linting, PR-обратной связью, перехватом багов и их исправлением, добавлением тестов — всем тем, что раньше занимало 60-70% работы review, теперь это делает Claude.

Но человеческий review остаётся незаменим в местах, требующих профессионального суждения. Юридическая и регулятивная составляющая — Fiona говорит, ей всегда нужен её юридический партнёр для оценки рисков. Границы доверия и security-sensitive код требуют специалистов в области. Решения о направлении продукта и эстетика требуют PM и дизайнеров.

И она особенно подчёркивает, что баланс между trust и verify динамичен. То, что сегодня должен делать человек, завтра может сделать следующая модель, поэтому постоянно нужно переоценивать эту линию.

Это как в видеоиграх, в каждой версии ответ другой, вы не можете использовать гайд из прошлой версии для новой, вас просто убьют.

4. Изменения в ролях команды

Fiona говорит, что в команде Claude Code границы ролей уже очень размыты. PM пишут много кода, инженеры занимаются контентом и дизайном, старые чёткие границы исчезают.

Например, раньше, когда инженер чинил баг, нужно было ждать, когда UX-копирайтер освободится и напишет текст для пользователей. Ожидание в очереди, как вы понимаете, могло занять несколько дней, иначе получался текст, написанный в спешке. Теперь процесс другой: инженер чинит, Claude пишет черновик текста, человек принимает финальное решение — и это можно выпустить в тот же день.

Кросс-функциональные разрывы больше не узкое место, они становятся сотрудничеством. Человек остаётся тем, кто принимает финальное решение, но больше не тем, кто пишет черновик.

Потом она рассказала о точке зрения, которую я очень разделяю. Теперь при найме она смотрит два типа качеств.

Один — креативный builder с product sense, может определить, что нужно делать, может быстро сделать прототип. Она также специально подчеркнула в описании:

Taste is scarce, typing is not.
Вкус редок, печатание — нет.

Другой — инженер с глубокой системной подготовкой, отвечающий за части "trust but verify", где человек действительно нужен, потому что subtly wrong is still wrong, ошибка, даже тонкая, остаётся ошибкой.

Она сказала, что её вообще не волнует, сколько строк кода вы напишете в час, её волнует, какой выбор вы сделаете (что делать) и как вы узнаёте, что это правильно. Когда AI может ускорить выполнение в 10 раз, решающим фактором становится то, знаете ли вы, что нужно делать, и что для вас означает действительно хорошо.

Это вкус.

5. Как продвигать изменения в команде

В команде Fiona есть интересные основные принципы.

Она разделила принципы на две категории. Слева серым — обязательные требования, справа чёрным — место для собственных экспериментов каждой команды. По сути, это как направляющий фреймворк для команды: суть в том, что крупные направления единые, но конкретная реализация — за каждой командой.

Fiona выделила три вещи, которые она считает самыми важными.

Держать команду как можно более плоской, менеджеры поддерживают работу групп, но остаются гибкими, чтобы люди могли переходить туда, где нужна работа.
Если Claude может это сделать, позвольте Claude это делать, это освобождает нас для более сложной работы.
Люди не будут сами удалять процессы, они просто будут добавлять новые поверх старых, так что вы должны сами встать и прямо сказать, какие процессы уже не нужны.

Эти три пункта звучат просто, но они сложные в исполнении, особенно третий.

Fiona рассказала, что раньше в одной команде было еженедельное review-совещание, в комнате сидела куча народу, но все смотрели в компьютеры, только рассказывали свой статус, когда приходила их очередь, потом опускали голову обратно в экран (я думаю, многие наши совещания такие же).

И она спросила: зачем нам эта встреча?
Тогда все осознали, что на самом деле она абсолютно бесполезна.
И с тех пор её отменили.

Это происходит везде, в компаниях по всему миру много процессов и совещаний, у которых была причина, когда их создавали, но когда окружение изменилось, инструменты изменились, они потеряли смысл, но по инерции продолжают существовать. Никому не кажется, что это полезно. Но, похоже, часто никто не встаёт и не говорит, что это совещание — пустая трата времени и его нужно отменить.

Чем глубже AI интегрируется в вашу организацию, тем больше вы будете видеть, что много старых шагов и процессов уже можно автоматизировать, и если вы не будете активно это пересматривать, они останутся там, в конечном счёте становясь чистым формализмом.

Финальные размышления

Fiona поделилась тремя вопросами, над которыми она размышляет, но ответов у неё нет. Но они очень интересны.

Первый: вам ещё нужны отдельные iOS и Android команды? Потому что инженеры теперь могут быть гибче в кросс-платформенной работе.

Второй: как далеко можно зайти с полностью автоматизированным review, где линия между "достаточно быстро" и "мы что-то важное пропустили"?

Третий: когда роли становятся всё более размытыми, как гарантировать, что все роли уверены в своём вкладе?

Я думаю, что сам факт того, что она выложила эти три вопроса, очень ценен. Потому что вы видите, что даже команда Claude Code, её создатель, не разобралась во всём. Они тоже ищут пути, и часто это не вопрос с одним правильным ответом.

Каждое крупное технологическое изменение — это не только обновление инструмента, часто организационный процесс нужно полностью переосмыслить.

Так называемый AI Native в сущности не просто покупка подписки Claude или API Key, и вот вы AI-native. Истинная AI-native организация переосмысляет всё заново: от планирования до управления знаниями, от процессов review до структуры команды.

Мы тоже не полностью это освоили, но постоянно стараемся. Недавно присоединившиеся коллеги, их любопытство и самомотивация, не обремененные старыми традиционными способами работы, уже показывают наброски этого подхода.

И суть всех этих изменений — это самая простая привычка мышления. Встречаешь повторение — автоматизируй. Встречаешь ненужный процесс — удали. Встречаешь суждение, не требующее человека — дай AI. Один за одним, без спешки, но без остановок.

И в конце, давайте закончим последней фразой Fiona.

Когда написание кода перестаёт быть дефицитом: опыт команды Claude Code