Нарешті, те, чому ми хочемо навчити модель, — це те саме, чому ми навчаємо дітей.

Автор статті, джерело: Machine Learning News

Багато хто каже, що у вік штучного інтелекту смак — це останній рівень захисту людини. Але Борис Черні так не вважає.

Він — технічний фахівець Anthropic, один із ключових розробників Claude Code. Він щодня пише код за допомогою моделей і вивчає моделі за допомогою моделей. Тенденція, яку він спостерігає: так звана «смаковість» також швидко засвоюється моделями.

Якщо навіть «що робити» може бути засвоєно моделлю, то що залишається людству?

У недавньому інтерв’ю Борис розмовляв про цю тему.

Як Claude Code фундаментально змінює системи компаній;

Після того як моделі зможуть писати більшість коду, чи варто наймати інженерів? Якщо варто, то на що слід звертати увагу?

Чому всередині Anthropic багато людей є Member of Technical Staff, без чітко визначених рівнів і розподілу обов’язків?

Протиінтуїтивна порада для всіх підприємців: чому «набирайте менше людей, але давайте більше токенів»?

……

Ці питання на перший погляд стосуються появи та ітерації продукту, але кожна відповідь вказує на одну й ту ж більш фундаментальну зміну: спосіб функціонування організації зараз переозначається самою моделлю.

Відповідь Бориса варта спокійного роздуму.

Як народився Claude Code?

Коли ведучий запитав про походження Boris Claude Code, його відповідь була трохи неочікуваною.

У його розповіді Claude Code не був первісно запланованим ключовим продуктом Anthropic і навіть певним чином можна сказати, що це випадковий продукт.

Наприкінці 2024 року Борис приєднався до команди Labs у Anthropic. Завдання цієї команди — не підтримка існуючих продуктів, а дослідження майбутніх форматів продуктів. З одного боку, вони постійно розширюють межі можливостей моделей; з іншого боку, вони шукають нові продукти, які зможуть справді розкрити цей потенціал.

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

Тоді на ринку інструменти AI для програмування переважно зосереджувалися на двох напрямках: один — автозаповнення, що допомагає розробникам завершити наступний рядок коду; інший — допоміжний асистент для відповідей на запитання, де розробники могли запитувати значення певного фрагмента коду або розв’язання певної помилки. Але Борис вважав, що тоді ще не існувало справжніх Coding Agent.

Тоді команда вирішила зробити більш сміливий експеримент: перестати використовувати модель як допоміжний інструмент і перетворити її на основний елемент розробки. Вони хотіли дізнатися, що відбудеться, якщо створити з нуля програмний продукт, повністю побудований навколо Agent.

Однак Борис також відкрито підтвердив, що початкова версія Claude Code була не зовсім зручною.

Протягом довгого часу він міг виконувати лише приблизно 10–20% його роботи. Більшість коду все ще доводилося писати йому самому. Claude Code, який люди бачать сьогодні, — це зовсім інша річ порівняно з продуктом того періоду.

Чому Anthropic приділяє так багато уваги кодуванню?

Багато людей вважають, що причина, чому Anthropic приділяє увагу програмуванню, проста — ринок програмування достатньо великий і має достатньо високу комерційну цінність. Але Борис дає зовсім інше пояснення.

Він сказав, що якщо випадково зупинити будь-якого співробітника в офісі Anthropic і запитати, чому він сюди прийшов, найімовірніше, відповідь буде однаковою: AI Safety.

За думкою Бориса, найважливішою місією Anthropic з моменту заснування завжди була безпека ШІ. Незалежно від досліджень з інтерпретованості, вирівнювання чи інших напрямків безпеки, суть усіх них полягає у спробі зрозуміти поведінку моделей. Але всі ці дослідження в кінцевому підсумку стикаються з однією й тією ж проблемою: просто спостерігати за моделями в лабораторії недостатньо — дослідникам потрібно також спостерігати, що відбувається з моделями після їх входу у реальний світ.

А кодування є майже ідеальним полем для експериментів.

На відміну від письма, малювання чи інших відкритих завдань, програмування має надзвичайно чіткий механізм зворотного зв’язку. Код працює чи не працює, програма проходить тести чи ні, компіляція успішна чи невдала — відповіді часто дуже очевидні. Разом із тим, інтернет надає величезну кількість коду як навчальних даних. У порівнянні з завданнями, як створення поезії, де може існувати безліч відмінних відповідей, простір правильних розв’язків для проблем програмування значно більш звужений, тому його легше перевірити на здатність моделі.

Саме через це Anthropic з самого початку приділяла велику увагу кодуванню, використанню інструментів та використанню комп’ютерів. Ці напрямки не лише мають комерційну цінність, але й важливі тим, що надають природне експериментальне середовище для дослідження того, як моделі взаємодіють з реальним світом.

З цієї точки зору Claude Code завжди був не просто інструментом продуктивності для програмістів. У розповіді Бориса він також є важливим експериментальним платформою Anthropic для розуміння майбутніх AI-систем.

Чому Claude Code раптово став сильнішим?

Після представлення походження Claude Code, ведучий поставив питання, яке цікавить багатьох: якщо на початку Claude Code міг виконувати лише приблизно 10–20% роботи Бориса, то що далі відбулося? Бо сьогодні Борис відкрито заявив, що вже півроку не писав код самостійно. Від виконання лише невеликої частини завдань до майже повного перебирання розробки — між цим, звичайно, відбулися величезні зміни.

На це питання відповідь Бориса була дивовижно простою. Він сказав, що зовнішній світ зазвичай зосереджує увагу на функціях продукту, але якщо він згадує моменти, які справді призвели до стрибка в можливостях, то найважливіша причина — лише одна: модель стала сильнішою.

За останній рік команда Anthropic справді постійно вдосконалювала сам Claude Code. Вони виконали величезний обсяг інженерних робіт, додавши різноманітні нові способи взаємодії та формати продукту. Спочатку Claude Code був лише інструментом командного рядка, а потім поступово розширювався на настільні, мобільні, Slack, GitHub та інші сценарії. Команда також постійно експериментувала з новими функціями, наприклад, режимом планування (Plan Mode) та іншими механізмами, що допомагають розробникам співпрацювати з агентами. Але, за думкою Бориса, все це є інкрементальними покращеннями.

Справжнім обмеженням Claude Code є сама базова модель.

Він згадав кілька ключових етапів: від Sonnet 4 та Opus 4 до пізнішого Opus 4.5 — кожне підвищення здатностей моделі безпосередньо відображалося на продуктивності Claude Code.

Після цього ведучий запитав, чи впливає досвід використання Claude Code на розробку моделей. Відповідь Бориса була такою: майже всі в Anthropic використовують Claude Code щодня, включаючи тих, хто розробляє моделі, та тих, хто розробляє продукти… Вся компанія цим користується.

Тому спеціального каналу для зворотного зв’язку не існує. Зворотний зв’язок є невід’ємною частиною щоденної роботи компанії.

Дослідники виявляють проблеми під час використання, і команда моделей бачить ці проблеми; після покращення здібностей моделі всі відчувають зміни у реальній роботі. Продукт і модель — це не дві паралельні лінії, а одночасно еволюціонуючі елементи одного циклу.

На скільки Claude Code підвищив продуктивність Anthropic?

Борис каже, що після тривалої роботи в лабораторіях ШІ люди звикають мислити експоненційними темпами. Багато внутрішніх показників — незалежно від доходів, використання чи здатності моделей — виглядають як експоненційні криві, тому вони навіть звикли використовувати логарифмічну шкалу для спостереження змін.

Також спостерігається подібна тенденція у виведенні коду.

Згідно з даними, які Anthropic раніше публічно розкривала, після широкого впровадження Claude Code всередині компанії обсяг коду, що генерує кожен інженер, збільшився приблизно втричі. Але Борис особливо підкреслив, що це вже застарілі дані. Фактичний зростання значно перевищує цю цифру.

Цікаво, що цей ріст відбувався на тлі швидкого розширення компанії.

Згідно з традиційним досвідом, чим більше інженерів у компанії, тим нижчою, як правило, є середня продуктивність. Новачки повинні вивчати систему, а досвідчені співробітники повинні відповідати на запитання, що призводить до постійного зростання витрат на організаційну комунікацію.

Але Борис спостерігав зовсім протилежне. Раніше новому інженеру могло знадобитися кілька тижнів, щоб добре ознайомитися з внутрішніми системами. Зараз цей процес часто займає лише два дні.

Причина не в революційних змінах у системі навчання, а в тому, що люди вже звикли безпосередньо запитувати Claude. Новачкам не потрібно знати, як запитувати базу даних. Вони навіть не повинні знати, до кого звертатися. У Anthropic, коли хтось запитує: «Як запитати базу даних?», часто відповідають: «Відкрий Claude і дай йому запитати базу даних». Багато прихованих знань, які раніше мали володіти досвідчені інженери, почали переноситися на агентів. За думкою Бориса, це, можливо, й є найважливішою зміною.

Claude Code підвищує не лише швидкість генерації коду, а й поступово зменшує витрати на передачу знань всередині організації. Раніше підприємства залежали від багатоетапного передавання досвіду. Зараз все більше знань безпосередньо інкапсулюються в моделі.

Від перфокарт до Vibe Coding людство знову підняло рівень абстракції програмування

Оскільки Claude Code настільки потужний, чи все ще пишуть код інженери, яких найняв Anthropic? Коли ведучий поставив це питання, фокус обговорення відразу змістився на: як ви визначаєте «написання коду»?

За думкою Бориса, історія розвитку програмної інженерії є суттєво історією постійного підвищення рівнів абстракції.

Його дідусь у часи СРСР програмував за допомогою перфокарт. У ті часи програмісти мали просвердлювати отвори на паперових картках, а потім вставляти їх у комп’ютер і чекати результату. Потім з’явилися асемблери. Потім — Fortran, Cobol. Потім — Java, Python, JavaScript. Кожен підйом рівня абстракції супроводжувався думкою: «Це вже не справжнє програмування». Програмісти, що писали на асемблері, презирали тих, хто писав на мовах високого рівня; ті, хто писав на C, вважали Python надто простим. А Борис вважає, що сьогодні відбувається те саме за суттю. Люди знову підвищили рівень абстракції програмування.

Він описав зміни, які відбулися в його роботі за останній рік. Спочатку він, як і більшість розробників: відкривав IDE, писав код і іноді використовував автодоповнення — це була традиційна розробка програмного забезпечення.

Після появи Claude Code його підхід змінився на такий: описувати вимоги Claude, дозволяти Claude писати код і самостійно перевіряти та виправляти його. На цьому етапі людина все ще безпосередньо керує моделлю — лише код генерується моделлю. Але Борис вважає, що це лише перехідний етап.

Справжні зміни відбулися недавно. Він каже: зараз я навіть більше не пишу прямі запити для Claude. Його робота перетворилася на інший формат. Він створює різні автоматизовані процеси та цикли, які відповідають за постановку запитань Claude, розбиття завдань, управління контекстом та координацію роботи між кількома екземплярами Claude.

Іншими словами: раніше люди давали команди Claude. Зараз програми дають ці команди за нього. Його робота перетворилася на проектування цих автоматизованих систем. Він стисло сформулював це так: моя робота тепер полягає у написанні Loops.

Здається, Борис не просто вивів код на замовлення до Claude, а автоматизував сам процес спілкування з Claude. Це вже не та відома всім модель Copilot. Це ближче до системи, яка постійно працює з кількома агентами.

Борис згадав, що в листопаді минулого року він навіть видалив свою IDE. Причина не була символічним жестом, а полягала в тому, що він зрозумів, що уже місяць не відкривав IDE. Оскільки він повністю не користувався нею, логічно було її видалити. Тоді він зазвичай одночасно запускав п’ять-десять екземплярів Claude, де різні Claude виконували різні завдання, а він основну увагу приділяв нагляду за процесом.

Інженери перестали писати код, що дивитися при наймі?

Тоді ведучий задав цікаве питання: якби сьогодні інженер хотів приєднатися до Anthropic, як би Anthropic оцінив його? Або: у світі, де все менше хто пише код власноруч, яких людей шукають компанії?

Відповідь Бориса майже безпосередньо призвела до обговорення організаційної структури. Він сказав, що найулюбленішою категорією людей у команді Claude Code є: Generalist (універсал).

Причина проста: раніше програмні організації мали дуже чітке розподілення обов’язків — дослідники користувачів відповідали за розуміння користувачів, дизайнер — за проектування продукту, менеджер продукту — за планування вимог, інженери — за реалізацію функцій, і кожен працював у своєму етапі, як у конвеєрі.

Але команда Claude Code за останні шість місяців виявила, що таке розподілення обов’язків швидко руйнується. Майже щодня кожен інженер у команді виконує різноманітні завдання, які раніше не входили до обов’язків «інженера». Хтось безпосередньо спілкується з користувачами, хтось займається дизайном інтерфейсу, хтось збирає дані, проводить аналіз даних та створює дашборди. Ніхто не обмежується вузьким етапом.

Борис навів ще більш екстремальний приклад: дизайнери Anthropic також пишуть код, а фінансові колеги також пишуть код. Сатя Наделла називає такі ролі «Builder». Цей термін може бути точнішим, ніж «інженер», оскільки справжня межа — не «чи вмієш ти писати код», а «чи здатен ти перетворити ідею на реальність».

З погляду Бориса, ШІ не просто замінює програмістів — він справді змінює стосунки між знаннями та виконанням. Раніше людина не могла одночасно виконувати кілька ролей, насамперед через надто високі витрати на навчання. Зараз моделі постійно знижують витрати на перенесення між цими здібностями. Тому найбільш перевагу в майбутньому матимуть не ті, хто є найглибшими експертами в одній галузі, а ті, хто зможе швидко пересуватися між різними галузями та постійно інтегрувати ресурси.

Також саме тому Борис вважає: ми входимо у золотий вік генералістів. Для тих, хто готовий робити багато речей, зараз може бути найкращим часом в історії.

Member of Technical Staff — це не хайп, а передвісник майбутнього

Господин ведучий переніс тему з продукту на культуру та організаційний дизайн. Він зауважив, що посада Бориса — не «директор з продукту» чи «директор з інженерії», а Member of Technical Staff, і багато людей у Anthropic мають саме таку посаду. Він хотів дізнатися: які переваги це має? Чи є недоліки?

Борис дуже відкритий. Він сказав, що найгіршим моментом було те, що ти надсилаєш повідомлення людині в Slack, у якої титул MTS, і зовсім не знаєш, чи є ця людина дизайнером, інженером чи менеджером, або над яким проектом вона працює. Але йому дуже подобався цей титул.

Він згадує свій досвід у Meta. Усі програмісти-інженери у Meta мали лише одну посаду: Software Engineer, без рівнів senior, principal. Спочатку він не розумів цього, але згодом зрозумів, що це було культурним рішенням. Якщо надати комусь титул «старшого», інші через повагу (deference) не наважаться сперечатися з його поганими ідеями. А коли всі перебувають у рівному середовищі, це змушує людей конкурувати саме ідеями, а не стажем.

Звичайно, він визнає, що рівні не зникають просто тому, що титули прибрано. Ви знаєте, що людина — L7, просто титул не вказаний. Але цікаво те, що часто ви справді не знаєте.

Він розповів історію про те, як працював інженером L4 у Facebook. У нього з’явилася ідея, він прямо пішов до віце-президента, відповідального за connectivity, і сказав: «Ось моя ідея, давайте зробимо це разом». Цей віце-президент взагалі не знав, якого рівня він є. Він звернувся до іншого віце-президента — і знову невдало. Третій раз — вдалося. Вони сформували команду й почали розробляти продукт.

Борис каже, що зараз щодня бачить те саме в команді Claude Code: досвідчені інженери з 20–30 роками досвіду витрачають місяці на те, щоб «забути» — відкинути застарілі звички, які більше не підходять. А новоначатий студент-випускник може навчити його, як краще використовувати Claude Code, бо молодь природньо мислить моделями.

З кожним новим моделлю всі повинні перекалібруватися. Досвід у цю епоху не накопичується лінійно, іноді він навіть є боргом.

Отже, наразі загадковий титул Member of Technical Staff, за думкою Бориса, є попередженням про надходження реальності: до кінця року межі між інженерами, PM, дизайнерами та дослідниками користувачів практично зникнуть. Замість пасивного прийняття цієї зміни, варто активно об’єднати всіх під одним титулом: Builder.

Рекомендація для всіх засновників: наймайте менше людей, розподіляйте більше токенів

Ведучий просить Бориса надати більш загальну рекомендацію для засновників і компаній з погляду Anthropic: як організації повинні змінити свій погляд до кінця 2026 року?

Перше речення Бориса було з жартом: «Дайте всім якомога більше токенів.» Як знаменита фраза Хуань Ренъюнь: «Чим більше купуєте, тим більше економите.»

Це не жарт. Він серйозний. Його конкретні рекомендації стосуються двох речей:

По-перше, надавайте якомога більше токенів, щоб усі могли безперервно експериментувати.

Друге: кожен проект навмисно «виділяє менше людей». Якщо ви вважаєте, що проекту потрібно чотири інженери, виділіть лише двох і надайте їм велику кількість токенів, щоб вони самі знайшли рішення. Ви помітите, що вони, найімовірніше, дійсно зможуть це зробити. Вони автоматизують усе, що можна, і через це наступні завдання будуть виконуватися швидше й дешевше. Це ефект складного відсотка.

Ведучий стисло узагальнив цю пропозицію: використовуйте менше людей і перерозподіліть бюджет з зарплат на токени. Це збільшить ваші початкові витрати, але значно знизить постійні витрати. Як попереднє компілювання — ви одноразово виконуєте всю важку роботу, і кожна наступна повторна операція майже безкоштовна.

Борис повністю згоден. Ведучий задав більш гострий питання: раніше люди дуже пишалися своєю дисципліною. PM пишалися своїми написаними статтями про продукт, дизайнири — своїми витонченими портфоліо. Чи треба за 12 місяців усім відмовитися від ідентичності «я — це хтось» і перетворитися на «гнучкий мішок, що споживає токени»?

Борис сказав: «Можливо, я б використав трохи інші формулювання, але… так, приблизно так».

Чи може смак бути знищений моделлю? Наостанок залишається лише «цінності»

Гостя згадав тему, про яку раніше розмовляв із іншим учасником Anthropic, Джаредом, і хотів почути думку Бориса: як ви розумієте «смак»?

Відповідь Бориса була дуже відкритою. Він сказав, що кожен раз, коли він вважав, що має «особливий смак» у програмуванні, це виявлялося помилковим.

Він дуже любив функціональне програмування, мови на кшталт Haskell і Scala. У ранніх версіях коду Claude Code він встановив правило: не використовувати class, лише function. Інженери викрадливо комітили код із class у вихідні, а в понеділок він їх відхиляв. Пізніше, коли модель почала масово писати код, вона безпосередньо створювала class. Він довго дивився, а потім сказав: «Гаразд, можливо, модель права. Моя ця прив’язаність, мабуть, взагалі не мала сенсу — бізнес-результат досягнуто, швидше, і код не гірший».

Потім він зробив ще більш сміливий висновок. Зараз усі завжди кажуть: «Смак продукту — останній альфа». Але він вважає, що ця альфа також швидко зникає.

Зараз він одночасно запустив сотні екземплярів Claude. Деякі з них аналізують відгуки у Twitter, інші — питання на GitHub, треті — Slack, а потім самостійно визначають, які функції слід реалізувати на наступному етапі. Наразі більшість ідей — погані, приблизно 20% — хороші. Але через наступну модель, ще через 3–6 місяців — більшість ідей, ймовірно, будуть хорошими.

Ведучий додав: А якщо так, то що ж залишається у людей унікального? Чи існує щось, чого модель ніколи не зможе досягти?

Борис подумав і сказав: «Цінності».

Він сказав, що в кінцевому підсумку ми навчаємо моделі тому самому, чому навчаємо дітей: як стати доброю істотою. Як робити правильні речі, а не просто правильно робити речі.