Код стал дешёвым. Софт — нет

Порог входа в создание софта рухнул. Порог для создания чего-то действительно важного не сдвинулся ни на дюйм.

Это AI-перевод статьи, сделанный каналом Про AI: Лучшие Статьи и Исследования.

Код стал дешёвым. Софт — нет

Code Is Cheap Now. Software Isn't. Автор: Chris Gregori Оригинальный текст:

Claude Code и Claude Opus 4.5 подлили масла в огонь хайпа. Инструменты на базе больших языковых моделей существовали и раньше, но сейчас они лучше, чем когда-либо, поэтому гораздо больше людей обращает на них внимание. Но мы не вступаем в золотой век SaaS. Мы вступаем в эру персонального, одноразового софта — где инженерия смещается от написания кода к проектированию систем, и инженеры по-прежнему необходимы именно по этой причине.

Сдвиг в современной разработке

Claude Code сейчас заполонил мою ленту, и на то есть веские причины. Интересно не только то, что разработчики активно его осваивают — интересно, что «билдеры» и мейкеры, которые раньше полагались на платформы вроде Lovable или Replit, переходят на него.

Не поймите неправильно — эти инструменты по-прежнему отлично подходят для быстрого запуска. Но мы видим чёткий сдвиг: люди заново открывают для себя красоту CLI-first подхода (работа через командную строку). Когда вы переносите взаимодействие в терминал, слой абстракции становится тоньше. Вы больше не следуете заданному пути управляемого UI — вы сами контролируете процесс.

Обвал порога входа

Что именно люди создают с помощью этих инструментов? Если оглядеться — практически всё. Фактически мы достигли точки насыщения. С одной стороны, мы наблюдаем настоящую демократизацию создания софта. Порог входа фактически рухнул. Впервые не-разработчики — это не просто потребители софта, они стали архитекторами собственных инструментов.

Раньше, если у вас была специфическая проблема, вы часами искали SaaS-продукт, который решал 80% задачи. Сегодня рабочий процесс изменился. Люди открывают CLI или голосовой интерфейс и просто описывают, что им нужно. Мы наблюдаем всплеск «персонального софта»:

• Трекер подписок, заточенный под конкретный стиль бюджетирования
• Расширение для Chrome, решающее одну очень узкую задачу ввода данных
• Фитнес-приложение с интерфейсом именно таким, как хочет пользователь

Это масштабный сдвиг. Софт становится персональной утилитой, которую вы генерируете, а не товаром, который покупаете.

От SaaS к черновикам

Мы вступаем в новую эру разработки софта, где цель — не всегда долговечность. Годами индустрия была одержима созданием «платформ» и «экосистем», но волна смещается к чему-то более эфемерному. Мы переходим от SaaS к черновикам.

Большая часть этого нового софта не предназначена жить вечно. На самом деле — всё наоборот. Люди всё чаще создают инструменты для решения единственной, конкретной проблемы ровно один раз — а потом выбрасывают их. Это софт как одноразовая утилита, спроектированный для непосредственного «сейчас», а не для далёкого «потом».

То, что делает это возможным сегодня — конкретная техническая философия: CLI-first интерфейсы, локальные данные и нулевой онбординг. Когда вы убираете трение от регистрации, настройки базы данных или навигации по сложному UI, стоимость создания инструмента падает настолько низко, что «временность» становится фичей, а не багом. Если на создание кастомного решения для разовой задачи уходит пять минут — не нужно, чтобы оно существовало дольше.

Контраст с традиционной SaaS-моделью разителен. SaaS по своей природе оптимизирован для удержания, привязки и расширения. Это бизнес-модель, созданная, чтобы держать вас внутри экосистемы и наращивать ваше присутствие. Персональные инструменты, напротив, оптимизированы для немедленности и контроля. Им плевать на вашу пожизненную ценность как клиента — им важно только решить задачу.

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

В этом новом ландшафте Claude Code — это Excel для разработчиков: мощная, гибкая утилита для решения насущных задач, а не Shopify для основателей, который создан быть постоянным фундаментом для бизнеса. Это про «сделать дело и отпустить инструмент».

Это также объясняет, почему важна следующая часть: быстро сгенерировать софт — это одно; сделать так, чтобы он выжил при столкновении с реальным миром — совсем другое.

Код дешёвый. Софт по-прежнему дорогой

Вот реальность текущей «AI-native» эры: код стал дешёвым, но софт остаётся невероятно дорогим.

Большие языковые модели фактически убили стоимость генерации строк кода, но они не затронули стоимость истинного понимания проблемы. Мы видим поток «приложений, созданных за выходные», но большинство из них — просто тонкие обёртки вокруг базовых CRUD-операций и сторонних API. Они выглядят впечатляюще в Twitter-демо, но часто рассыпаются в момент столкновения с трением реального мира.

Реальная стоимость софта — не в первоначальном написании; она в поддержке, краевых случаях, накапливающемся UX-долге и сложностях владения данными. Эти «быстрые» решения хрупкие.

Трекер подписок ломается в момент, когда банк меняет формат экспорта CSV. Расширение для Chrome умирает, как только целевой сайт меняет структуру DOM. Фитнес-приложение становится непригодным, как только пользователю нужна надёжная офлайн-поддержка или синхронизация данных.

В последнее время я видел много мрачных пророчеств на Hacker News, Reddit и Twitter о «конце программной инженерии». Это полностью мимо сути. Мы не наблюдаем конец профессии — мы вступаем в её новую эру.

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

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

Иллюзия дистрибуции

Но есть и обратная сторона. С исчезновением порога входа уровень шума достиг рекордных высот. Мои ленты сейчас переполнены «AI-предпринимателями», заявляющими о пятизначном ежемесячном регулярном доходе (MRR) за приложения, которые они создали за день.

Во многих случаях эти заявления крайне сомнительны. Когда вы видите создателя без существующей аудитории и без явного «рва», заявляющего о $10 000 MRR на проекте выходного дня — это обычно игра на вовлечение, а не отражение бизнес-реальности.

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

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

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

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

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

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

Кто выигрывает

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

И да — такие инструменты, как Claude Opus 4.5, Claude Code и Cursor, действительно полезны для инженеров. Они замечательно справляются с устранением boilerplate (шаблонного кода), реализацией функций и написанием юнит-тестов. Один из моих любимых сценариев использования в последнее время, особенно после смены работы — генерация персонализированной документации и пошаговых разборов функций, чтобы быстрее освоить кодовую базу продукта и понять все нюансы — это было чрезвычайно полезно для вхождения в курс дела.

Но вот реальность: большие языковые модели не идеальны в написании кода — даже если он компилируется с первого раза. Даже при качественном промптинге и чётких правилах эти модели всё ещё ошибаются. Говоря как человек, использующий эти инструменты каждый день — вы не можете просто доверять выводу напрямую. Вам всё равно нужно ревьюить код, как если бы это был pull request от коллеги. Нужно читать логику, проверять предположения и часто вносить ручные правки, чтобы всё работало правильно.

В конце концов, вы, скорее всего, отправите это коллеге на ревью (и, может, Code Rabbit тоже) — справедливо ли заставлять их ревьюить то, что вы не писали и даже не удосужились проверить?

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

Хайп создаёт впечатление, что мы вступаем в золотой век SaaS. Это не так. Мы вступаем в эру персонального софта: инструментов, которые вы генерируете для решения проблемы, а потом двигаетесь дальше.

За двадцать долларов, несколько часов свободного времени и немного терпения практически любой может выпустить работающее приложение. Мы вступаем в эру «персонального софта», где разрыв между изначальной идеей и работающим продуктом меньше, чем когда-либо.

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

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

Суть в том, что хотя инструменты изменились, основы хорошей инженерии — нет.

Порог входа, возможно, исчез — но суждение, вкус и ответственность по-прежнему остаются работой.

Подпишитесь на канал и каждый день читайте лучшие материалы про AI переведенные на русский!

Нашли интересную статью для перевода? Пришлите нашему боту: @ailongreadsbot