Основатель Claude Code Борис Черни делится 7 ключевыми суждениями об ИИ на конференции Sequoia

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

Борис Черни, основатель Claude Code, выступил на конференции Sequoia — информация была очень насыщенной, многие идеи я слышал впервые. Этот парень действительно хорошо понимает ИИ.

Я поделюсь своим обобщением.

Для большинства основных сценариев разработки ручное написание кода уже становится неэффективным.

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

Сейчас это работает иначе.

То же самое функциональное требование инженер выполняет примерно так: сначала четко формулирует требования, разбивает задачу на несколько частей и передает их агенту, устанавливает критерии приемки, а затем проверяет, соответствует ли результат, полученный агентом, ожиданиям; если нет — корректирует подсказку и запускает процесс повторно.

ИИ уже может справиться с большинством задач по программированию. Конечно, не на 100% —还有很多巨大又复杂的代码库、冷门语言或特殊环境，今天的模型表现仍然不够。

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

Это изменение действительно очень похоже на промышленную революцию.

До промышленной революции кузнец самостоятельно выполнял все этапы — от ковки и закалки до полировки и сборки. Кузнецы с хорошим мастерством, естественно, пользовались высокой ценностью.

Позже появилась конвейерная линия. Каждый рабочий выполнял только одну операцию, но общий объем производства увеличился в десятки и сотни раз по сравнению с ручным производством.

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

Рабочие не исчезли, но их роль изменилась.

Сфера программной инженерии сейчас переживает аналогичный переломный момент. Сам код больше не является дефицитом. Умение писать код становится базовым навыком, подобным умению работать с PowerPoint.

Настоящая редкость — это способность разбить расплывчатые требования на четкие задачи, выбрать наиболее подходящий вариант из нескольких предложенных агентом решений и заставить группу ИИ работать вместе для достижения одной цели.

На самом деле, многие опытные инженеры изначально не могли принять это. Сама идея написания кода вручную была причиной, по которой многие люди любили эту профессию последние десятилетия.

Передача этого машинам для многих людей — это не просто изменение способа работы, а переосмысление идентичности.

Но тренд — это тренд.

Кодирование превращается из профессионального навыка в базовую компетенцию. Это можно сравнить с печатным станком в Европе XV века.

До изобретения печатного станка в Европе грамотными были лишь около 10% населения. Эти люди, как правило, работали на неграмотных аристократов, выполняя обязанности по чтению и письму за них.

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

Борис считает, что влияние ИИ на программное обеспечение — это ускоренная революция печатного станка. Программное обеспечение станет полностью демократизированным и доступным для всех в течение нескольких десятилетий.

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

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

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

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

Ситуация перевернулась. Теперь каждый может реализовать идею. В этот момент тот, кто действительно понимает рабочие процессы в больнице, становится более ценным. Потому что он знает, какие функции действительно будут использоваться врачами, а какие просто звучат логично.

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

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

Раньше, когда мы говорили о generalist, мы обычно имели в виду инженера, который может писать код для iOS, веба и бэкенда. Такой generalist по сути остается полным стеком внутри инженерной области.

Будущий универсал — это междисциплинарный стек.

Есть люди, которые одновременно разбираются в продукте, дизайне и инженерии. Есть люди, которые одновременно разбираются в продукте, науке о данных и инженерии. Такие сочетания раньше были почти невозможны, поскольку каждая из этих областей требовала длительной специализированной подготовки.

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

Команда Claude Code именно такая: менеджеры по инженерии, PM, дизайнеры, данные ученые, финансисты, исследователи пользователей — все пишут код.

Дизайнеры могут самостоятельно запустить интерактивный прототип для демонстрации команде, а не просто создавать макеты и ждать, пока инженеры их реализуют.

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

Уровень профессионализма каждого по-прежнему высок. Но с помощью ИИ написание кода стало общим языком для всех.

За последние десять лет в отрасли SaaS существовало несколько практически аксиоматических согласий.

Первое — это стоимость переключения. Как только компания использует вашу систему, в ней постепенно накапливаются данные, конфигурации, поля и отношения прав за несколько или даже десятилетий.

Переходить на другую систему — одних только этих вещей, чтобы перенести их как есть и снова ввести, уже достаточно, чтобы не хотелось ничего делать.

Второе — это блокировка рабочего процесса. Ежедневные операции сотрудников, межотдел协作 и узлы согласования полностью выросли вокруг этой SaaS-платформы.

Смена системы — это не просто перенос данных, а полный снос мышечной памяти компании, накопленной за последние несколько лет.

Вместе эти два элемента составляли самую глубокую защитную барьеру в истории SaaS-индустрии. Но после появления достаточно мощных моделей логика вещей начала меняться.

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

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

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

Такие неформальные договоренности, кто кого должен утверждать и на каком этапе возникают задержки, нельзя просто перенести.

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

Таким образом, конкурентное преимущество, построенное на накоплении данных и процессов, разрушается.

Это может быть плохая новость для тех, кто занимается SaaS. Но для всех клиентов, использующих SaaS, и команд, готовящихся создать SaaS нового поколения, это настоящее окно возможностей.

Компании, которые действительно изменят отрасль в ближайшие 10 лет, могут быть в 10 раз больше, чем за последние 10 лет.

Причина на самом деле не сложна.

Небольшие команды могут с помощью ИИ создавать продукты того же или даже более высокого уровня, чем крупные компании. Наоборот, крупным компаниям, чтобы действительно использовать ИИ, это становится обременением.

How to say it?

Компания с более чем десятилетним опытом сформировала целый набор собственных бизнес-процессов, распределения обязанностей, привычек сотрудничества, системы обучения и системы оценки KPI. Раньше всё это было активами и барьерами для входа.

Но действительно встроить ИИ означает пересмотреть всё это: необходимо перестроить бизнес-процессы, переобучить всех сотрудников, на каждом шаге вперёд будут встречаться огромные внутренние препятствия, нужно согласовать действия N отделов и N уровней утверждения.

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

Такая разница в скорости ранее также существовала. Стартапы изначально имеют преимущество в скорости над крупными компаниями. Но ИИ значительно усилил этот разрыв.

Почему?

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

Однако организационная масса крупных компаний не стала легче, а, наоборот, стала тяжелее из-за необходимости интегрировать ИИ. Чем мощнее ИИ, тем больше разрыв между ускорением небольших команд и сопротивлением крупных компаний.

Вот что Борис называет отрицательными активами. Это не то, что у крупных компаний нет денег, людей или желания — это то, что их прежние прибыльные навыки сейчас как раз мешают AI раскрыть свою настоящую ценность.

MCP не умрет.

После того как Skill стал популярным, многие посчитали, что MCP больше не нужен. Основатель OpenClaw разделяет аналогичное мнение.

Но Борис не так думает. Он считает, что MCP станет программным слоем связи эпохи ИИ.

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

Но основная проблема API в том, что он создан для инженеров. Чтобы использовать API, нужно сначала изучить документацию, запросить токен, написать код, сопоставить поля и обработать исключения. Проще говоря, API предназначен для человеческих разработчиков.

MCP другое. Он позволяет моделям подключаться напрямую — модель сама понимает и вызывает их, не требуя программиста для перевода.

Таким образом, Борис назвал API Human Developer Interface, а MCP — Model Interface Protocol. Один предназначен для людей, другой — для моделей.

Это действительно очень похоже на то время. В эпоху мобильного интернета все сервисы по умолчанию должны были быть API-ориентированными. В эпоху ИИ все сервисы по умолчанию должны быть MCP-ориентированными.

Многие сейчас, обсуждая Computer Use, считают, что это направление может не сработать.

Причина также вполне обоснованна: слишком много токенов расходуется, работает медленно и нестабильно. Это выглядит скорее как демонстрация навыков, а не как готовое рабочее решение.

Но Борис видит совершенно другой уровень.

Он действительно ценит то, что Computer Use решает одну из главных проблем внедрения ИИ: в реальном мире существует множество систем, у которых нет ни API, ни MCP.

Особенно в корпоративном мире.

Только проработав в компании, можно понять, насколько устарели ее ключевые системы: ERP, OA, финансовые системы, внутренние утверждения, фоновые системы цепочки поставок и различные кастомизированные системы. Многие из них не имеют открытых интерфейсов, документации или возможностей автоматизации. Они просто существуют, и каждый день тысячи сотрудников вручную их используют.

Почему бы просто не создать для них API?

Потому что это невозможно сделать. Поставщики, разработавшие эти системы, возможно, уже не существуют. У ИТ-отдела нет ни мотивации, ни бюджета на рефакторинг.

Отделы бизнеса еще меньше будут ждать полгода или год. Эти системы никогда не будут ждать идеального API, который спасет их.

В краткосрочной перспективе крупные модели продолжат совершенствовать свои возможности использования компьютера.