Написання коду, по суті, вже вирішено

Написано Борисом Черним

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

У цій презентації для підприємців та інженерів він систематично розповідає історію створення Claude Code, чому «кодинг розв’язаний (codingissolved)», і які зміни відбудуться у індустрії програмного забезпечення та командних структурах на цій основі.

Від «непланового проекту» до феноменального продукту

Борис приєднався до Anthropic наприкінці 2024 року, коли в компанії існувала команда, схожа на інкубатор, під назвою AnthropicLabs. Ця невелика команда згодом створила кілька ключових продуктів, таких як Claude Code, MCP і настільний додаток, і після виконання місії розпустилася, але тепер її знову зібрали для «другого раунду».

У контексті 2024 року основна уява про «AI для написання коду» залишалася на рівні «автоматичного доповнення/типової асоціації» у IDE — натиснути Tab, і модель допоможе дописати рядок. Борис інтуїтивно відчуває, що можливості моделей вже значно перевищують цю форму, і справжня «продуктова форма» сильно відстає — це те, що вони називають всередині «продуктовим overhang».

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

Звісно, справа не йшла так гладко. Перші 6 місяців роботи над Claude Code майже ніхто не користувався ним активно, він міг генерувати приблизно 10% коду, і досвід був дуже грубим, навіть у межах Anthropic цей інструмент залишався експериментальним. Лише у травні 2025 року, після випуску моделі Opus 4, використання почало стрімко зростати, і кожне оновлення моделі (4.5, 4.6, 4.7) давало явний «значний покращення».

Поглянувши назад, найцікавіше у цьому продукті — те, що він з самого початку був створений не для «поточних моделей», а для «наступного покоління моделей через 6 місяців». Команда знала, що протягом певного часу не буде ринку для продукту (PMF), але наполягала на тому, щоб спершу створити «правильний інтерфейс», а потім чекати, поки модель наздожене.

Чому кажуть, що «кодинг розв’язаний»?

На презентації Борис прямо запитує програмістів у залі: «Хто ще пише 100% коду вручну?» і «Хто використовує Claude Code або подібних інтелектуальних агентів для написання коду на 100%?» Більшість відповідає, що знаходиться десь посередині, і він жартує: «Тоді це вже 50% розв’язано».

Але для нього особисто відповідь стала дуже радикальною: він зараз пише 100% коду за допомогою Claude Code.

Сам кодовий базис Claude Code повністю створений моделлю, технологічний стек — типовий TypeScript+React, без якихось хитромудрих технологій.

Одна з причин вибору цього стеку — на ранніх етапах, коли можливості моделі ще були слабкими, використовувати «головний технічний стек у розподілі тренувань моделі», що значно підвищує якість генерації.

З часом, з оновленнями моделі, вона вже майже без проблем освоює нові мови та фреймворки, і вибір стеку перестає бути обмеженням.

У його особистому робочому процесі Борис щодня виконує десятки Pull Request, бувало, що за один день «протягнув» 150 PR — просто щоб перевірити, наскільки він може підвищити продуктивність; і всі ці PR фактично пише Claude. Він виконує роль продуктового менеджера, архітектора та рецензента.

Звісно, він визнає, що «100% розв’язано» поки що актуально лише для окремих сценаріїв:

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

Але його простий висновок — більшість цих недоліків з часом будуть вирішені у наступних версіях моделей.

Особистий робочий процес: один телефон + тисячі агентів

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

Зараз він переважно працює з телефону: відкриває ClaudeApp, у лівій частині перемикається на вкладку Code і бачить кілька паралельних сесій. Зазвичай він підтримує 5–10 сесій одночасно, кожна з яких має багато підагентів, і їх загальна кількість легко досягає кількох сотень; увечері — іноді понад тисячу агентів, що виконують довгострокові задачі у фоновому режимі.

Ключова ідея цієї системи — простий наказ: /loop.

Суть /loop у тому, щоб Борис міг за допомогою Claude створити «автоматичне повторюване завдання», яке буде запускатися через певний час — кожну хвилину, кожні 5 хвилин, щодня тощо.

Завдяки такому циклу він побудував цілі системи «автоматичного обслуговування»:

• /loop для «контролю PR»: автоматичне оновлення CI, ребейсинг, щоб список PR був чистим.
• /loop для «моніторингу здоров’я проекту»: автоматичне виявлення та виправлення проблем, таких як flaky tests.
• /loop кожні 30 хвилин збирає відгуки з Twitter, автоматично кластеризує їх і формує короткий звіт для прийняття рішень.

У його описі, цей механізм уже став мовою програмування для майбутнього: найпростіша, але дуже потужна форма. У поєднанні з недавнім запуском routines (довготривалих процесів, що працюють на сервері і продовжують працювати навіть при вимкненому комп’ютері), модель може постійно просувати проєкт у фоновому режимі.

Структура команд: кожен — «універсальний фахівець»

Коли один інженер може писати 100% коду за допомогою AI, продуктивність зростає у 10–100 разів, і структура команд зазнає змін.

Борис вважає, що у майбутньому «універсальні фахівці» стануть більш поширеними.

Сьогодні, під «generalist» зазвичай розуміють «інженера, що охоплює кілька сфер» — наприклад, той, хто може працювати з iOS, вебом і сервером одночасно. Але новий тренд — це:

• фахівці, що перетинають межі функцій: інженер + дизайнер, інженер + продукт + дата-сайєнс, інженер + фінанси/операції тощо.

У команді Claude Code вже з’явилися такі фахівці: менеджери з інженерії, продуктові менеджери, дизайнери, дата-сайєнтисти, фінансисти, дослідники користувачів — всі пишуть код і активно використовують Claude для просування своїх задач.

Інакше кажучи, кожен з них зберігає свою спеціалізацію, але «писати код» вже не є привілеєм обмеженого кола — це базова навичка, як сьогодні Office або PowerPoint.

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

Наприклад, у розробці бухгалтерського софту головним експертом у продукті і логіці може бути не найкращий інженер, а бухгалтер, що добре розуміє бізнес і вміє керувати AI для написання коду — адже «програмування» стане відносно легким, а «глибоке розуміння галузі» — цінним ресурсом.

Від «програміста-елітки» до «народного програмування»: аналог друкарства

Щоб пояснити глибину цієї трансформації, Борис навів улюблений історичний аналог: вплив AI на виробництво програмного забезпечення буде схожий на вплив друкарства у XV столітті.

До появи рухомих літер у Європі лише близько 10% населення вміли читати і писати, і їх наймали для «читання та писання за інших» — у ролі секретарів, писарів, переписувачів. Це була дуже вузька професія, і більшість людей ніколи не мали доступу до неї.

З появою друкарства за 50 років кількість опублікованих текстів у Європі перевищила за кілька тисячоліть, а вартість книги знизилася у 100 разів. Наступні століття, завдяки розвитку освіти і соціальних структур, рівень грамотності зріс до приблизно 70%, і читання з писання стали базовими навичками для більшості.

Борис вважає, що програмування і створення софту проходять ту саму криву, і швидше.

Раніше написати програму — це була «високоспеціалізована, дуже складна професія».

Зараз, писати код стане так само просто, як «набирати текст» або «відправляти SMS».

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

Чи чекати «великого зникнення SaaS»?

Що станеться з існуючими SaaS-продуктами, якщо AI знизить вартість створення софту у 10 або 100 разів? Чи настане «велике зникнення SaaS»? Це одне з найпопулярніших питань Бориса.

Він відповідає не так просто «так/ні», а використовує рамки «Seven Powers» з подкасту Acquired для аналізу.

На його думку, AI швидко знецінить деякі бізнес-бар’єри:

• Вартість перемикання (Switching Costs): коли можна швидко перенести дані і відновити робочі процеси за допомогою моделі, складні інтеграції і налаштування стануть менш важливими.
• Процесна здатність (Process Power): багато компаній змагаються за конкурентоспроможність через дизайн процесів і складні робочі потоки, але моделі все краще розуміють і покращують ці процеси, особливо такі, що можуть автоматично «оптимізувати» їх.

Разом із тим, деякі більш фундаментальні бар’єри залишаться важливими:

• мережеві ефекти
• економіка масштабу
• унікальні ресурси (наприклад, особливі дані, канали, спеціальні сертифікати)

Ще один важливий тренд — у найближчі 10 років кількість стартапів, здатних створювати продукти, що конкурують із великими компаніями, значно зросте — у 10 разів і більше.

Причина — великі компанії будуть стикатися з великим опором і інерцією при перебудові процесів і навчанні співробітників AI, тоді як нові команди з самого початку будуть «AI-орієнтованими», з мінімальним штатом і високою цінністю.

Для Бориса цей час — один із найкращих для запуску продуктів і стартапів.

Як Anthropic «їсть свою собаку»?

Багато вважають, що компанії, що створюють моделі, використовують у себе «найновішу та найпотужнішу версію», щоб бути на крок попереду інших. Але Борис каже навпаки:

У внутрішніх процесах вони використовують ті самі версії моделей, що й усі інші (наприклад, багато використовують Opus 4.7), рідко — дослідницькі моделі Mythos, і не покладаються на приватні версії, які важко отримати.

Головна перевага — не у моделях, а у глибокій інтеграції AI у всю організацію.

Зокрема:

• Внутрішні процеси вже не базуються на «чистому ручному коді», навіть SQL-запити генеруються моделлю.
• Різні команди спілкуються у Slack через Claude, допомагаючи один одному, обмінюючись інформацією.
• Багато процесів побудовані навколо механізмів loop, підагентів і routines, що дозволяє моделям постійно просувати роботу у фоновому режимі.

Через це він вважає, що найбільший «розрив» зараз — не у технологіях, а у організаційних структурах і процесах. Для нових компаній це — величезна можливість: замість поступового перероблення старих процесів, краще з самого початку проектувати організацію «AI-native».