Anthropic сьогодні — одна з небагатьох компаній, яка не просто говорила про «AI‑революцію в розробці», а перебудувала інженерну організацію так, що це видно в цифрах. Компанія публічно показала графік: «Anthropic engineers on average ship eight times as much code per quarter as they did compared to 2021 to 2025». За цим стрибком — перезапуск інструментів для розробників (Claude Code) і роботи (Claude Co‑work), нова роль менеджера і радикально інший підхід до якості.
Про це в подкасті Lenny’s Podcast детально розповідає Фіона Фанг — керівниця команд Claude Code та Co‑work в Anthropic, інженерка з понад 25‑річним стажем, яка до цього будувала Visual Studio й TypeScript у Microsoft, запускала Facebook Marketplace та інфраструктурні команди Instagram. Її досвід робить історію Anthropic цікавим кейсом того, як виглядає «організація, де код пишуть моделі», коли це не теорія, а щоденна робота.
Вісім разів більше коду: коли кодування перестає бути вузьким місцем
Команда Anthropic не приховує: обсяг коду, який інженери шиплять щокварталу, зріс у середньому у вісім разів порівняно з періодом 2021–2025 років. На графіку, яким компанія поділилася в соцмережах, довгий час — рівна лінія, а потім різкий зліт.
Це не результат більш жорсткого менеджменту чи агресивнішої планової дисципліни. Ключова зміна — те, що Фіона формулює дуже прямо: «Coding is no longer the bottleneck… now it’s all about like where has that shift happened?». Писати код швидко тепер може майже кожен у команді завдяки Claude Code; час інженера більше не спалюється на рутинне імплементаційне «друкування».
Насправді змінюється саме визначення «хто такий розробник». За словами Фіони, «now not only engineers but we also have designers, PMs, everybody on the Claude Code team checks in code». Дизайнери та продукт‑менеджери, які раніше були цілком залежні від інженерного бендвічу, сьогодні самі створюють і мерджать зміни, спираючись на моделі як на «соупілота». Сукупний ефект простий: більше людей здатні змінювати продукт, і кожен з них — у рази швидше, ніж два роки тому.
Цей ефект добре відчувається саме в компанії, яка довго жила в традиційному циклі розробки. Фіона згадує, як на початку кар’єри працювала у світі, де софт випалювали на CD і в’язали до виробничих дедлайнів. Тоді «інженерний час» був головним дефіцитним ресурсом, а планування — способом втиснути максимум у жорстке «вікно релізу». У теперішній конфігурації Anthropic «стеля піднялася»: сама дія «написати код» вже не є тим, що обмежує амбіції.
Замість цього виникає нове вузьке місце: верифікація.
Від вузького місця в рев’ю до автоматизованої «рамки якості»
Коли кожен може шипити код, і кодовий потік зростає в рази, найболючішою точкою стає не генерація, а перевірка. Фіона описує минулий рік як час, коли «we didn’t even have Claude Code Reviews last year», і тоді «that was a really really big bottleneck of, you know, the human reviewers». Людські рев’юери просто не встигали переглядати все, що продукували інженери разом з моделями.
З’явлення Claude Code Review змінило структуру навантаження. Люди лишилися там, де потрібна «deep subject matter expertise» і довіра до критичних змін, але все, що можна було формалізувати, почали перекладати на моделі. Ключова ідея — не «AI замість рев’юера», а AI як машина, що постійно звіряє код з явно заданим стандартом.
Фіона формулює це просто: «What helps us though is the more that we can automate to almost check in the framework for what good looks like. Claude is very good when you give it a framework to validate against those frameworks». З практичної точки зору це означає:
- будь-яке «statement of what good looks like» — від специфікації до контент‑гайду — обов’язково потрапляє в репозиторій;
- Claude Code Review під час перевірки PR дивиться не лише на код, а й на ці артефакти й сигналізує, якщо зміни розходяться з тим, що команда офіційно вважає «good».
«Any time you have like a statement of what good looks like, get that into the repo and then Claude code review can make sure it’s still matching what you set up to do», — наголошує Фіона.
Це виглядає як еволюція ідей тест‑драйвен‑девелопменту, але з важливою відмінністю: найтяжчу частину — написання тестів і специфікацій — тепер може брати на себе модель. Фіона згадує, як свій перший баг у Claude Code вона спеціально фіксила в режимі TDD: попросила Claude написати тест, переконалася, що він падає, і лише тоді разом із моделлю реалізувала саму правку. Там, де раніше «написати тест» було сприйняття як «їсти броколі перед десертом», тепер це стає автоматизованим кроком, який не гальмує творчий драйв білдера.
Наслідок: людський час у рев’ю звільняється від перевірки дрібних відхилень від гайдів і концентрується на нетривіальних архітектурних рішеннях, безпеці й тих місцях, де потрібен досвід і інтуїція.
Як менеджмент виживає при 8×‑швидкості
Зростання продуктивності створює новий виклик: як взагалі зрозуміти, що відбувається в кодовій базі, коли «everything is now possible in theory», а команда шипить у рази більше? Для Фіони відповідь — перетворити Claude Code і Co‑work на розширення власних менеджерських очей і рук.
Вона описує, як створила окрему Claude Code‑сесію, прив’язану до всіх репозиторіїв її команд, зі доступом до Slack‑каналів і метрик: «this way I have full visibility into the work that everybody’s doing». Раз на місяць вона влаштовує спільні сесії з підлеглими, де замість звичного «розповідайте, що ви зробили» разом із Claude дивиться:
- які фічі були зашиплені;
- які інциденти трапилися;
- який фідбек приходив через різні канали;
- які патерни й теми повторюються.
Ці огляди перетворюються на розмову не про «кількість PR», а про гіпотези і наслідки: що спрацювало, де з’явилися баги, що це говорить про архітектуру чи процес. Важлива установка Фіони: «Make new mistakes» — помилки неминучі, ключове, щоби команда не застигала в страху і не боялася рухатися.
Ще один шар — автоматизація того, що раніше було «менеджерською рутинною перевіркою». Фіона згадує свій старий ранковий ритуал: кава, прохід усіх фідбек‑каналів, пошук тем, на які варто зреагувати особисто. Після запуску Claude routines цей шматок роботи фактично виконує агент:
- щоранку рутина проходить усі релевантні канали (внутрішні, партнерські, соцмережі, особисті повідомлення, які команда скидає у Slack);
- виділяє ключові теми;
- у простих випадках генерує PR із поліш‑фіксами — до того моменту, коли Фіона прокидається, у неї вже є готові зміни на рев’ю.
Тут знову з’являється мотив «підняття рівня абстракції». Якщо раніше інженер чи менеджер писав промпт і вручну розгрібав відповіді, тепер рутини працюють як «оркестратор промптів і агентів». Фіона вважає, що майбутнє інженерної роботи в Anthropic рухається до все більш асинхронної моделі, де менеджери й інженери не «сидять у терміналі», а проєктують і керують флотом агентів, які працюють у тлі.
Це, однак, породжує нову проблему: контекст‑світчинг. Коли в тебе одночасно працюють десятки рутин і агентів, доводиться спеціально бронювати «фокус‑тайм», щоби просто встигати переглядати результати їхньої роботи. Фіона визнає: «I do see the context switching load increasing» і поки що не має остаточного рішення, як його зменшити.
Моніторинг та тести замість нескінченних рев’ю
При 8×‑зростанні обсягу коду утримати якість суто через рев’ю неможливо. Anthropic відповідає на це тим, що переносить фокус на моніторинг і тестування як основні інструменти контролю.
Фіона прямо формулює висновок: «One of the best tools for staying on top of quality is just… monitoring and tests versus spending more time reviewing». У практиці команд Claude Code та Co‑work це проявляється кількома способами.
По‑перше, структурованим мисленням про «погану» і просто «сумну» якість. Фіона ввела внутрішню рамку «bad vs. sad»: bad — це «really bad irrecoverable error» на кшталт крашу CLI, коли користувач втрачає роботу; sad — «pain point recoverable», досвід, який дратує, але не ламає весь флоу. Важливий нюанс: коли «sads» накопичуються, вони в сумі стають «bad».
Кожна команда в Anthropic має високу агенцію визначати для своїх поверхонь, що конкретно є bad і sad. Для когось bad — це краш, для когось — певний рівень таймаутів чи частоти помилок генерації. Далі навколо цих визначень будуються дашборди й алерти. Такий підхід дозволяє:
- уникати ситуації, коли різні сервіси мають несумірні метрики, і неможливо зрозуміти загальний стан продукту;
- замість «косметичного» полішу фокусуватися на тому, що реально руйнує досвід.
По‑друге, команда активно інвестує в превентивні сигнали. Класичні перформанс‑метрики, стабільність, краш‑рейти, але також менш очевидні індикатори — від Evals до… лічильників нецензурної лексики. Фіона згадує, як інженер запропонував відстежувати swear words у користувацьких сесіях: це виявилося ефективним способом ловити моменти пікової фрустрації, які не завжди видно в голих цифрах.
По‑третє, Anthropic намагається щоразу, коли з’являється новий «зразок того, що вважаємо добрим», формалізувати його так, аби Claude міг його перевіряти. Від спеки до контент‑дизайн‑скейлів — усе потрапляє в репозиторії, і далі уже не потребує постійної уваги людей.
Це не скасовує потреби у фахівцях із глибоким системним досвідом — навпаки, саме вони допомагають перетворювати свій експертний judgment у машиночитаємі рамки. Але дозволяє звільнити їх від безкінечної перевірки тривіальних відхилень.
Висновок: коли «все можливо», виграє той, хто вміє перевіряти
Історія Anthropic показує, що справжня трансформація інженерної організації в епоху LLM починається не там, де модель вміє писати код, а там, де компанія переосмислює все, що навколо:
- ролі (код тепер шиплять не лише інженери, а й дизайнери та PM’и);
- менеджмент (керівники використовують Claude для огляду роботи команд і живуть у режимі флоту агентів);
- якість (головний ресурс — не люди в рев’ю, а чітко задані рамки «what good looks like», моніторинг і тести).
«Coding is no longer the bottleneck» — цей діагноз уже очевидний усім, хто активно користується AI‑інструментами. Питання, яке ставить собі Anthropic, звучить інакше: якщо все «в теорії можливо», то кого ви наймаєте, як ви визначаєте якість і як будуєте процеси так, щоб «вісім разів більше коду» не перетворилося на вісім разів більше техборгу?
Відповідь Фіони Фанг і її команд — у впертій роботі над верифікацією, автоматизацією рамок якості й готовності переписувати навіть базові менеджерські звички. Саме тому цифра 8× для Anthropic виглядає не як маркетинговий сплеск, а як наслідок системної перебудови інженерної культури.
Джерело
Повна розмова з Фіоною Фанг (Anthropic) в подкасті Lenny’s Podcast:
https://www.youtube.com/watch?v=Ybrl4FYM57c