Фіона Фанг — керівниця команд Claude Code і Co‑work в Anthropic, інженерка з понад 25‑річним стажем, яка раніше будувала Visual Studio та TypeScript у Microsoft, запускала Facebook Marketplace та працювала над AR‑і VR‑продуктами в Meta та Instagram. У розмові на подкасті Lenny’s Podcast вона дивиться не тільки на те, як AI вже радикально змінив інженерію, а й на те, що досі залишається болючим і нерозв’язаним: від автоматичних рев’ю й верифікації досвіду до освіти нових інженерів і збереження командної культури у гіперрості.
Межі автоматизації: коли “авто‑рев’ю” вже занадто далеко
Одна з найбільш практичних, але все ще відкритих дилем — наскільки далеко можна просунутися в бік повністю автоматизованих code review. Anthropic уже сильно розвантажує інженерів Claude‑рев’ю, і вузьке місце “людських” рев’ю істотно послабилося. Але питання не зникає, а радше загострюється:
«How far do you push fully automated reviews?»
Фіона наголошує на принципі “trust but verify”: моделі стають дедалі кращими, проте існують зони, де “глибока предметна експертиза” все ще критична. Для “жорстких” ділянок — системного рівня, складних розподілених сервісів, критичних поверхонь продукту — людський рев’ювер лишається обов’язковим.
Там, де автоматизація працює добре, її вбудовують у рамки, які команда формулює заздалегідь. Claude показує себе сильним тоді, коли отримує чіткий каркас “що таке добре” й звіряє зміни саме з цим каркасом: специфікації, контент‑гайди, дизайн‑правила, чітко описані інваріанти поведінки. Ці “описані стандарти якості” спеціально заносять у репозиторій, щоб модель могла перевіряти код на відповідність не абстрактним принципам, а конкретному договору команди.
Авто‑рев’ю, за цією логікою, не заміняє експерта, а зміщує його роботу на вищий рівень: людина визначає рамки, а модель може відсівати більшу частину порушень, що піддаються формалізації. Але відповідь на запитання “достатньо вже автоматизації чи ні” досі щоразу доводиться шукати заново — для кожної зони коду й кожного продукту.
Найскладніше — перевірити не факт, а досвід
На рівні інженерних метрик — продуктивність, crash‑rate, latency — у Anthropic вже вибудувано помітно більше інструментів: моніторинг, фреймворки “bad vs sad”, експерименти з автоматизацією тестів і контент‑перевірок. Але верифікація “досвіду” користувача залишається набагато важчою задачею.
Фіона формулює це так:
«Basically, how do you solve how do you set up a verification that the experience is what you want it to be?… that one is still a hard one to crack.»
На відміну від класичних eval‑ів точності або технічних метрик, які можна формалізувати й обчислити, досвід — це поєднання коректності, емоції, відчуття “магії” та відсутності тертя. Навіть внутрішні “фан‑метрики” типу лічильника ненормативної лексики в запитах (який команда справді веде як сигнал фрустрації) дають тільки часткову картину.
Тому Anthropic комбінує кілька підходів:
- стандарти “bad vs sad” — чітке розділення між фатальними, нерепарованими провалами (“bad”) і дрібними болями, які окремо терпимі, але у сумі перетворюють досвід на поганий (“sad”);
- автономію команд у визначенні, що саме в їхньому домені вважається “bad” і “sad” (наприклад, для CLI — краш із втратою роботи, для UI — миготіння чи нестабільність);
- постійне “догфудинг‑тиском” лідерів: Фіона свідомо щодня користується продуктами, які будує команда, саме як кінцевий користувач, а не тільки як менеджер, що дивиться в дашборди.
Однак навіть з цими шарами контроль над “тим самим” досвідом лишається одним із головних інженерних відкритих питань.
Асинхронні рутини й нова втома від контекст‑світчингу
Ще одна свіжа проблема виникає не з браку, а з надлишку автоматизації. З появою рутин у Claude Co‑work команда перейшла від ручних ранкових ритуалів до “флоту агентів”, які працюють у фоновому режимі: моніторять Slack‑канали з фідбеком, генерують PR‑и, агрегують інциденти, шукають патерни.
Це кардинально змінює стиль роботи:
«Because with routines and everything being more async… I do see the context switching load increasing.»
Фіона описує власний досвід: спочатку вона запускала окремі запити синхронно й асинхронно, потім — рутини, які самі породжують інші агенти. Згодом з’ясувалося, що замість старої проблеми “не встигаю все зробити руками” приходить нова — “не встигаю все переглянути й осмислити”.
«I think there is starting to be a high load on our context switching… I even remember I myself was like, oh I kicked like I kicked off…»
Навіть якщо агент детально нагадує, що саме відбувається в кожному потоці, когнітивне навантаження на людину росте: потрібно час, щоб повернутися до теми, прийняти рішення, поставити новий поріг для авто‑дій або, навпаки, зупинити автоматизацію.
Парадокс у тому, що старі практики “фокус‑тайму” нікуди не зникають. Навпаки, Фіона знову свідомо блокує у календарі відрізки часу — але вже не “для писання коду”, а для наведення ладу в тому, що напрацювали десятки фонових рутин: проглянути PR‑и від агентів, розібрати звіти, відрефлексувати пріоритети.
Кінцевого рішення тут поки немає. Саме зростання контекстного навантаження Фіона ставить в один ряд із проблемами верифікації досвіду: це те, що ще тільки належить по‑справжньому осмислити й спроєктувати.
Ким стане “молодий інженер”, якщо код пише модель
Найбільш довгострокове й, можливо, екзистенційне запитання, яке турбує Фіону, стосується не поточних практик, а майбутнього покоління інженерів.
«How we grow the next generation just because how you and me got to our engineering path is just so different.»
Її власний шлях — від відсутності комп’ютера в дитинстві до IBM, Microsoft і далі — включав роки ручного програмування, накопичення інтуїції щодо стеку, відчуття “як воно працює під капотом”. Сьогодні значна частина цієї “м’язової пам’яті” перекладається на моделі: молодий інженер може ніколи не провести тижні у відлагодженні низькорівневого коду, а одразу почати працювати з високорівневими описами задач.
Це не обов’язково погано, але змінює запит до освітньої траєкторії. Фіона припускає, що класичні короткі інтернатури й проєкти “на 3 місяці” можуть виявитися недостатніми:
«I wonder if it’s… for software engineering, it’s almost like you go more towards a fellowship or apprenticeship program.»
Її турбує баланс між швидким виходом на продуктивність у світі, де “код — це сіль”, і збереженням глибинного розуміння систем. Вона не впевнена, що відповідь уже є. Можливо, моделі стануть настільки сильними, що цей шар знань справді відійде на другий план. Але зараз здатність “double‑click” на залежності — розуміти, як влаштований шар, на який спирається твій код, — виглядає для неї критичною і для якості продукту, і для довгострокового росту інженера.
Як саме перевчити університети, компанії й самих менторів під нову реальність — поки що відкрите питання, яке Фіона ставить радше як проблему, ніж як завдання з відомою відповіддю.
Головний страх — не технології, а культура однієї команди
Попри весь масштаб технічних і управлінських змін, найбільше Фіону непокоїть не AI‑архітектура, не конкуренція моделей і навіть не кадровий ринок. Її формулювання дуже людське:
«The thing that keeps me up at night is… the culture of the team… as we grow… maintaining the things… that one team mentality.»
Для неї “культура” — не презентація й не постер у переговорці, а те, як люди реально ставляться одне до одного, як обговорюють проблеми, як поводяться “під дедлайном”. Вона підкреслює, що це живий організм, який неминуче змінюється із кожною хвилею зростання: нові люди, нові процеси, нові очікування.
“Ментальність однієї команди” у її розумінні — це готовність, наближаючись до фінішу зі “своїм” завданням, оглянутися й подивитися, кому ще потрібна допомога; а також здатність відкрито говорити не лише про успіхи, а й про те, “що не працює”. Її “нічний кошмар” — ситуація, коли менеджер на запитання “як справи?” формально відповідає “все добре”, хоча команда насправді “сидить у кімнаті, що горить”.
Особливий виклик — зберігати цю відкритість на фоні високого темпу зростання й загальної емоційної напруги навколо AI. І в Anthropic, і в інших швидкозростаючих компаніях порівняно легко створити відчуття, що “всі навколо вистрілили, тільки я відстаю”, що ще сильніше ускладнює чесну розмову про складнощі. Для Фіони протиотрута тут — системна робота менеджерів і лідерів з нормалізації таких розмов і демонстрація власної вразливості: розповідати не тільки про успіхи, а й про те, що їх самих турбує й лякає.
У певному сенсі це ще одна “нерозв’язана задача” епохи AI‑інженерії: як будувати культуру, де надлюдська швидкість і агентна автономія поєднуються з людяністю й почуттям плеча.
Нерозв’язані задачі як дорожня карта
Те, як Фіона говорить про відкриті питання, дає зріз того, де зараз проходять справжні межі AI‑інженерії. Не в здатності моделі дописати функцію чи згенерувати тести, а в набагато складніших речах:
- визначити, де авто‑рев’ю дає виграш, а де потрібен живий експерт;
- навчитися верифікувати не лише правильність, а й досвід;
- приборкати нову хвилю контекст‑світчингу, що приходить разом із флотами асинхронних агентів;
- переосмислити шлях становлення інженера від “новачка” до архітектора в світі, де код може ніколи не бути написаний руками;
- утримати командну культуру, поки все інше змінюється швидше, ніж будь‑коли.
Відповідей на ці питання поки що немає ні в Anthropic, ні деінде. Але саме вони, судячи з розмови, стають не менш важливими, ніж наступний приріст токенів або швидкості інференсу. І від того, як індустрія навчиться з ними працювати, залежить, якою саме стане “епоха AI‑інженерії” — не тільки в слайдах презентацій, а й у повсякденному житті команд.
Джерело
Lenny’s Podcast — Building the most AI-pilled engineering team in the world | Fiona Fung (Anthropic)