Засновник Claude Code Борис Черні ділиться 7 ключовими висновками про ШІ на конференції Sequoia

Організовано: Айнг

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

Я поділюся своїм підсумком.

Для великої кількості основних сценаріїв розробки написання коду вручну вже починає ставати непродуктивним.

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

Зараз це працює інакше.

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

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

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

Ця зміна дуже схожа на промислову революцію.

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

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

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

Робітники не зникли, але їхня роль змінилася.

Інженерія програмного забезпечення зараз переживає подібний перелом. Сам код більше не є рідкісним. Вміння писати код стає базовою навичкою, подібно до вміння користуватися PPT.

Справжньою рідкістю є здатність розбити нечіткі вимоги на чіткі завдання, здатність вибрати найкращий із кількох варіантів, запропонованих агентом, та здатність залучити групу ШІ до спільного виконання завдання.

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

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

Але тренд — це тренд.

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

До винаходу друкарства лише приблизно 10% населення Європи вміли читати і писати. Ці люди часто працювали на неграмотних аристократів, виконуючи обов’язки читання і письма за них.

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

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

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

Після того як ІІ знизила бар’єр для написання коду до мінімуму, справжнім різницею між людьми стає їхнє відчуття продукту та справжнє розуміння конкретної галузі.

Наприклад, дві людини одночасно розробляють продукт для лікарів. Одна — інженер, який швидко пише код, а інша — людина, яка працювала кілька років у інформаційному відділі лікарні.

Раніше інженер мав більше шансів зробити річ, бо він міг реалізувати ідею.

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

Тобто, коли AI знищує бар’єри для виконання, різниця в судженні стає більш вираженою.

Це прямо змінило значення слова generalist.

Раніше, коли ми говорили про generalist, ми зазвичай мали на увазі інженера, який може писати код для iOS, веб-додатків і бекенду. Такий generalist за суттю все ще є повноцінним фахівцем всередині інженерної галузі.

Майбутній полімат — це міждисциплінарний стек.

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

Але зараз ШІ знизив бар’єри для входу в кожну галузь, і одна особа може охоплювати кілька сфер, зберігаючи професійну глибину.

Команда Claude Code — це саме так. Менеджери з інженерії, PM, дизайнері, науковці з даних, фінансисти, дослідники користувачів — кожен пише код.

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

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

Глибина професійних знань кожного залишається. Але за допомогою ШІ написання коду перетворилося на спільну мову для всіх.

Протягом останніх десятиліть у сфері SaaS існувало кілька узагальнень, майже вважаних аксіомами.

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

Переїхати на іншу систему — однієї лише ідеї перенести все це без змін вже достатньо, щоб зробити це непривабливим.

Другий пункт — блокування робочого процесу. Щоденні операції співробітників, міжвідомчої взаємодії та точки затвердження всі виникли навколо цієї SaaS-системи.

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

Разом ці дві речі утворювали найглибший захист у минулому SaaS-індустрії. Але з достатньо потужною моделлю логіка речей починає змінюватися.

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

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

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

Ті угоди, які працівники мають у голові щодо того, хто хто має затверджувати та на якому етапі щось зупиняється, не можна просто перенести.

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

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

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

Компанії, які справді змінять індустрію протягом наступних 10 років, можуть бути в 10 разів більшими, ніж за останні 10 років.

Причина насправді не складна.

Малі команди можуть за допомогою ШІ створити продукти того ж рівня, а навіть кращі, ніж великі компанії. Навпаки, велиkim компаніям, щоб справді використовувати ШІ, це стає вантажем.

Як сказати?

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

Але справжнє впровадження ШІ означає, що все це потрібно переглянути з нуля: процеси бізнесу треба перебудувати, усіх працівників — переосвітити, і кожен крок вперед зустріне величезний внутрішній опір, потрібно буде координувати N відділів, N рівнів схвалення.

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

Ця різниця в швидкості раніше також існувала. Стартапи завжди мали перевагу в швидкості над великими компаніями. Але ШІ збільшив цю різницю в багато разів.

Чому?

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

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

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

MCP не помре.

Після того як Skill став популярним, багато людей вважали, що MCP більше не потрібен. Засновник OpenClaw має схожу думку.

Але Борис не думає так. Він вважає, що MCP стане програмним шаром з’єднання в епоху ШІ.

Раніше програмне забезпечення в інтернеті підключалося за допомогою API.

Але основна проблема API полягає в тому, що він створений для інженерів. Щоб використовувати API, потрібно спочатку вивчити документацію, отримати токен, написати код, зіставити поля та обробити винятки. Простими словами, API призначений для розробників-людей.

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

Тоже Boris назвав API Human Developer Interface, а MCP — Model Interface Protocol. Один призначений для людей, інший — для моделей.

Це дуже схоже на той час. У епоху мобільного інтернету всі сервіси за замовчуванням мали бути API-орієнтованими. У епоху ШІ всі сервіси за замовчуванням мають бути MCP-орієнтованими.

Багато людей зараз, обговорюючи Computer Use, вважають, що цей напрямок може не працювати.

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

Але Борис бачить це з іншого боку.

Він справді цінує те, що Computer Use вирішує одну з найбільших проблем реалізації ШІ: у реальному світі існує велика кількість систем, які не мають ні API, ні MCP.

Зокрема у світі бізнесу.

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

Чому б просто не створити для них API?

Тому що це неможливо зробити. Постачальники цих систем, ймовірно, вже не існують. Відділ ІТ не має ні мотивації, ні бюджету на рефакторинг.

Відділи бізнесу ще менше зможуть зупинитися на півріччя або рік. Ці системи ніколи не почекають ідеального API, щоб врятувати себе.

У короткостроковій перспективі основні моделі продовжать покращувати свою здатність використання комп’ютера.