Software 3.0: теория Карпатого vs реальность

«Самый горячий язык программирования сегодня — английский», — заявил Андрей Карпатый в своей лекции о Software 3.0. Звучит как мем, но за этой фразой стоит серьезная концепция эволюции разработки ПО.
Карпатый предложил простую, но мощную модель: как мы дошли от написания кода на C++ до промптов на естественном языке. При этом сама концепция остается спорной — одни называют её «новой операционной системой», другие видят дорогой эксперимент с непредсказуемым поведением ^[1].
Разобрал лекцию, убрал пафос и оставил практические выводы для разработчиков, продакт-менеджеров и CTO, которые решают, когда и как внедрять LLM в свой продукт. Ниже — основные тезисы Карпатого и контраргументы из реальной практики.

1. Три эпохи софта за 10 лет

Software 1.0

• Что такое «код»: C++, Python, JS
• Кто пишет: Разработчик
• Барьеры: Низкие вычисления, ручной труд
• Примеры: CRUD-сервисы, игры, скрипты

Software 2.0

• Что такое «код»: Веса нейросети
• Кто пишет: Данные + ML-инженер
• Барьеры: Датасеты, GPU, время
• Примеры: Автопилот Tesla, CV-системы

Software 3.0

• Что такое «код»: Промпт на естественном языке
• Кто пишет: Любой, кто формулирует
• Барьеры: API-лимиты, UX
• Примеры: ChatGPT-плагины, Dev-ко-пилоты

Тезис Карпатого

Карпатый говорит, что главное отличие — теперь программу может собрать не только инженер, а любой, кто умеет формулировать мысли и писать промпты. По его мнению, даже если человек не знает Python, он может быстро собрать прототип через LLM. Но тут есть нюанс: многие отмечают, что без технической базы и навыков проверки результата такие прототипы часто оказываются сырыми или дорогими в поддержке.

Что на практике

Если верить Карпатому, сейчас MVP можно собрать за выходные, а новые роли вроде «Prompt Engineer» появляются даже в банках. Но на практике всё не так однозначно: спрос на такие навыки есть, но и требования к качеству, и конкуренция только растут.
«Демократизация» не означает бесплатность. По данным GitClear ^[2], в коде, сгенерированном LLM, объём дубликатов вырос в 8 раз. Команды тратят до 30 % рабочего времени на верификацию промптов ^[3] (arXiv, 2025) — новый, но дорогой этап качества.

Как меняется подход к задаче

Software 1.0 (Python):

def has_cat(image):
    # ML-модель или ручная логика
    ...
if has_cat(image):
    print("Милый кот!")

Software 3.0 (Prompt):

На фото кот? Если да — напиши "мяу".

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

2. LLM — новая ОС, ChatGPT — её терминал

Когда появились первые ПК, люди набирали команды в C:> и ждали, что машина послушно ответит. C LLM мы снова в терминале: пишем промпт, смотрим, что вышло. Но операционная система — это не окошко командной строки, а экосистема приложений, драйверов и API. Именно сюда постепенно переезжает AI-рынок.
Представьте: ваш сервис для бухгалтерии обращается к LLM, когда нужно объяснить ФНС-документ «человеческим языком», но считает налоги обычным калькулятором. Пользователь даже не знает, где кончается код, а где начинается промпт.

graph TD;
    LLM[(Ядро/CPU)] -->|контекст| RAM["Контекстное окно (RAM)"]
    LLM --> Tools{{Инструменты}}
    Tools -->|HTTP| API[API]
    Tools --> Calc[Калькулятор]
    Tools --> FS[Файловая система]
    Terminal["ChatGPT == терминал"] --> LLM

• Зарабатывают не «ещё одни терминалы», а приложения поверх этой ОС.
• Ваш продукт должен сам решать, когда вызывать API, когда — считать локально.
• Узкая ниша > универсальный ассистент.

Слабые места «ОС»:

• Latency. Загрузка LLaMA-2-70B на 8 GPU занимает ≈ 84 с; TTFT у Claude Opus > 1 с ^[4], что далеко от привычных 100 мс веб-интерфейсов.
• Приватность и лицензии. Samsung запретила сотрудникам использовать ChatGPT и другие генеративные ИИ после утечки данных ^[5] (TechCrunch, 2023) и Apple запретила ChatGPT для сотрудников ^[6] (9to5Mac, 2023); Ziff Davis подал иск к OpenAI ^[7] за нарушение авторских прав. LLM-код может содержать GPL-фрагменты без атрибуции (дело Doe v. GitHub ^[8]).
• Экономика контекста. Каждый токен — деньги. Даже для сценария (3000 входных + 3000 выходных токенов) одна сессия на GPT-4o ^[9] обходится примерно в $0.002. 10 000 таких сессий — это ~$20–25 только на inference.
  Выиграют те, кто даст «одну кнопку» для конкретной боли ^[10]. Хороший пример — Perplexity: ребята спрятали сложный пайплайн поисковых запросов, валидацию фактов и citations за простой input-box. Пользователь думает, что разговаривает c ChatGPT, а на деле управляет целым роем сервисов.

3. Ползунок автономии

Аугментация

• Кто решает: Человек
• Пример: GitHub Copilot
• Когда применять: Ошибки ^[11] дорогие, нужна 100 % точность

Соруководство

• Кто решает: AI предлагает, человек подтверждает
• Пример: Notion AI
• Когда применять: Быстрый черновик, ручная доработка

Агент

• Кто решает: AI сам
• Пример: Автоматический helpdesk-бот, который сам закрывает простые заявки без участия оператора
• Когда применять: Много однотипных задач, низкие риски

Дайте пользователю UI, где этот «ползунок» — явный или неявный.
Практика показывает: чем выше риск, тем левее ползунок. Текстовый редактор спокойно генерирует абзацы сам, но бухгалтерия попросит подпись главбуха — просто встроите этап «Approve».
Крайний правый край сегодня не работает: AutoGPT и Devin успешно завершают < 20 % задач ^[12], часто уходя в бесконечные и дорогие циклы (The Register, 2025). Поэтому комбо «AI предлагает → человек проверяет» остаётся золотой серединой.

4. Ограничения LLM: как они ведут себя на практике

Карпатый сравнивает LLM с очень умным, но рассеянным стажёром. Модель может выдать блестящую идею, а может ошибиться в простых вещах или поверить любой информации, которую ей подсовывают.
Вот основные проблемы, которые стоит учитывать:

1. Иногда модель отлично разбирается в сложных темах, но может ошибиться в элементарном.
2. Она не запоминает, что происходило в прошлых сессиях — всё, что ей нужно, надо давать в текущем запросе.
3. LLM легко обмануть: если ввести её в заблуждение, она поверит и выдаст ошибку.
   Если используете LLM в продукте, ограничивайте её «песочницей»: давайте только нужные данные и обязательно проверяйте результат. Ключева идея ответственность — ваша. Отсюда две практики:
   • Double-check. Любая критичная операция (деньги, здоровье) проходит верификацию классическим кодом или человеком.
   • Контекст-гигиена. Вставляйте только нужные данные. Чем больше «воды», тем выше шанс, что модель запутается или утечёт конфиденциалку.
   • Стоимость ошибки. Factual-галлюцинации встречаются в ответах LLM ^[13] (eWeek, 2025). Для финтеха или здоровья это прямые убытки — или дорогое ручное ревью.

5. Боль Software 1.0 — ваш шанс

Карпатый «навайбил» iOS-приложение за вечер, но потратил 3 дня на облако, домен и биллинг.

Coding (LLM)      ▇▇▇  4 ч
DevOps (1.0)      ▇▇▇▇▇▇▇▇▇  24 ч

Стартуйте сервис, который сводит DevOps к одной кнопке. Простейший MVP — CLI, который создает
1) репозиторий,
2) CI/CD,
3) Stripe-checkout.
Похожую боль уже решают Railway, Render, Supabase, но места хватает: платежи, legal, GDPR, аналитика. Если упростите хоть один из этих этапов — разработчики принесут вам карточки сами.
Важно помнить и про TCO: self-host Llama-3 70B с приемлемой задержкой требует инфраструктуры уровня 4×A100 или 8×A40 GPU, что по ценам AWS составляет от $100k до $150k в год только за аренду оборудования. Если добавить расходы на хранение данных, трафик, поддержку и команду MLOps, итоговая совокупная стоимость владения (TCO) может превысить $250–300k в год (см. разбор на dev.to ^[14]). Экономия появляется только при очень высокой загрузке GPU и большом объёме токенов; для большинства сценариев облачный API оказывается дешевле.

6. Выводы: Software 3.0 — пока не революция, но уже налог на хайп

Видение Андрея Карпатого о Software 3.0 подкупает своей простотой: будущее, где код пишется на английском, а барьеры для входа рухнули. Однако, как показывают обобщенное мнение, за этим фасадом скрывается реальность, в которой каждая изящная идея натыкается на жёсткие ограничения.

1. Экономика убыточна. Модель «плати за токен» создаёт «штраф за успех»: чем популярнее ваш продукт, тем быстрее растут ваши издержки. В отличие от Software 1.0, где предельные затраты на нового пользователя стремятся к нулю, здесь каждый вызов API — это реальные, ненулевые расходы. Добавьте сюда стоимость GPU для self-host, подготовку данных и «налог на верификацию» — обязательную ручную проверку каждого результата — и TCO (совокупная стоимость владения) становится запретительной для всех, кроме гигантов, способных субсидировать эксперименты.

2. Технология нестабильна. Метафора «LLM как ОС» оказывается перевёрнутой. Настоящая ОС — это надёжный, детерминированный фундамент. LLM — это волатильное, вероятностное ядро, которое для безопасного использования в продакшене требует массивной «защитной оболочки» из кода Software 1.0: кэширования, валидаторов, систем безопасности и сложных пайплайнов для обработки данных.

3. Юридические риски огромны. Неразрешённые вопросы авторского права (дело Doe v. GitHub), риски утечки проприетарных данных (запреты в Apple, Samsung) и соответствия GPL-лицензиям создают правовое минное поле. Использование LLM в корпоративной среде — это неприемлемый риск для любого юридического отдела.

4. «Низкий порог входа» — это миф. Барьер не исчез, а сместился. Вместо написания кода теперь требуются ещё более редкие и дорогие навыки: MLOps, системная инженерия, инжиниринг данных и умение строить сложные RAG-системы. «Вайб-кодинг» позволяет создать демо, но не надёжный продукт. Рынок труда это подтверждает: спрос на Senior Software Engineer’ов, способных строить инфраструктуру, никуда не делся.

Идея Software 3.0 не является заменой классической разработке. Это мощный, но сырой и дорогой компонент. Будущее не за чистым «программированием на английском», а за гибридными системами, где LLM — тщательно изолированный и контролируемый инструмент для узкоспециализированных задач, встроенный в надёжную архитектуру Software 1.0. Революция откладывается.

7. Что делать завтра (в реальности)

• [ ] Оцените TCO, а не API-прайс. Посчитайте полную стоимость вашего use-case: inference, хостинг, затраты на команду для верификации и поддержки, стоимость подготовки данных.
• [ ] Проектируйте «защитную оболочку». Вместо того чтобы доверять LLM, стройте вокруг неё систему валидации, кэширования и безопасности. Думайте о ней не как об ОС, а как о небезопасной внешней зависимости.
• [ ] Проведите юридический аудит. Привлеките юристов для оценки рисков, связанных с лицензиями на данные, авторскими правами и конфиденциальностью, прежде чем писать первую строку кода.
• [ ] Инвестируйте в инфраструктуру 1.0. Ваш главный актив — не промпты, а надёжная архитектура, которая может пережить хайп и адаптироваться к новым моделям. Именно она создаёт реальную ценность и защищённость бизнеса.

8. Полезные ссылки

• Видео лекции — https://youtu.be/LCEmiRjPEtQ ^[15] (оригинал), машинный перевод на русский ^[16]
• Оригинальная «Software 2.0» — https://karpathy.medium.com/software-2-0-a64152b37c35 ^[17]

---

TL;DR
Концепция Software 3.0 Карпатого разбивается о практику. Реальность — это убыточная экономика, технологическая нестабильность и правовое минное поле. Вместо «новой ОС» мы получили волатильное ядро, требующее дорогой защитной оболочки из кода 1.0. Как будто будущее за гибридными системами, где LLM — мощный, но тщательно изолированный инструмент, а не замена разработке. А красивые концепты на то и нужны, чтобы оставаться красивыми и вдохновлять людей.