«Самый горячий язык программирования сегодня — английский», — заявил Андрей Карпатый в своей лекции о Software 3.0. Звучит как мем, но за этой фразой стоит серьезная концепция эволюции разработки ПО.
Карпатый предложил простую, но мощную модель: как мы дошли от написания кода на C++ до промптов на естественном языке. При этом сама концепция остается спорной — одни называют её «новой операционной системой», другие видят дорогой эксперимент с непредсказуемым поведением.
Разобрал лекцию, убрал пафос и оставил практические выводы для разработчиков, продакт-менеджеров и 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, в коде, сгенерированном LLM, объём дубликатов вырос в 8 раз. Команды тратят до 30 % рабочего времени на верификацию промптов (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 с, что далеко от привычных 100 мс веб-интерфейсов.
- Приватность и лицензии. Samsung запретила сотрудникам использовать ChatGPT и другие генеративные ИИ после утечки данных (TechCrunch, 2023) и Apple запретила ChatGPT для сотрудников (9to5Mac, 2023); Ziff Davis подал иск к OpenAI за нарушение авторских прав. LLM-код может содержать GPL-фрагменты без атрибуции (дело Doe v. GitHub).
- Экономика контекста. Каждый токен — деньги. Даже для сценария (3000 входных + 3000 выходных токенов) одна сессия на GPT-4o обходится примерно в $0.002. 10 000 таких сессий — это ~$20–25 только на inference.
Выиграют те, кто даст «одну кнопку» для конкретной боли. Хороший пример — Perplexity: ребята спрятали сложный пайплайн поисковых запросов, валидацию фактов и citations за простой input-box. Пользователь думает, что разговаривает c ChatGPT, а на деле управляет целым роем сервисов.
3. Ползунок автономии
Аугментация
- Кто решает: Человек
- Пример: GitHub Copilot
- Когда применять: Ошибки дорогие, нужна 100 % точность
Соруководство
- Кто решает: AI предлагает, человек подтверждает
- Пример: Notion AI
- Когда применять: Быстрый черновик, ручная доработка
Агент
- Кто решает: AI сам
- Пример: Автоматический helpdesk-бот, который сам закрывает простые заявки без участия оператора
- Когда применять: Много однотипных задач, низкие риски
Дайте пользователю UI, где этот «ползунок» — явный или неявный.
Практика показывает: чем выше риск, тем левее ползунок. Текстовый редактор спокойно генерирует абзацы сам, но бухгалтерия попросит подпись главбуха — просто встроите этап «Approve».
Крайний правый край сегодня не работает: AutoGPT и Devin успешно завершают < 20 % задач, часто уходя в бесконечные и дорогие циклы (The Register, 2025). Поэтому комбо «AI предлагает → человек проверяет» остаётся золотой серединой.
4. Ограничения LLM: как они ведут себя на практике
Карпатый сравнивает LLM с очень умным, но рассеянным стажёром. Модель может выдать блестящую идею, а может ошибиться в простых вещах или поверить любой информации, которую ей подсовывают.
Вот основные проблемы, которые стоит учитывать:
- Иногда модель отлично разбирается в сложных темах, но может ошибиться в элементарном.
- Она не запоминает, что происходило в прошлых сессиях — всё, что ей нужно, надо давать в текущем запросе.
- LLM легко обмануть: если ввести её в заблуждение, она поверит и выдаст ошибку.
Если используете LLM в продукте, ограничивайте её «песочницей»: давайте только нужные данные и обязательно проверяйте результат. Ключева идея ответственность — ваша. Отсюда две практики:
- Double-check. Любая критичная операция (деньги, здоровье) проходит верификацию классическим кодом или человеком.
- Контекст-гигиена. Вставляйте только нужные данные. Чем больше «воды», тем выше шанс, что модель запутается или утечёт конфиденциалку.
- Стоимость ошибки. Factual-галлюцинации встречаются в ответах LLM (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). Экономия появляется только при очень высокой загрузке 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 (оригинал), машинный перевод на русский
- Оригинальная «Software 2.0» — https://karpathy.medium.com/software-2-0-a64152b37c35
TL;DR
Концепция Software 3.0 Карпатого разбивается о практику. Реальность — это убыточная экономика, технологическая нестабильность и правовое минное поле. Вместо «новой ОС» мы получили волатильное ядро, требующее дорогой защитной оболочки из кода 1.0. Как будто будущее за гибридными системами, где LLM — мощный, но тщательно изолированный инструмент, а не замена разработке. А красивые концепты на то и нужны, чтобы оставаться красивыми и вдохновлять людей.
