Первый эпизод

Отправной точкой становится предложенный Андреем Карпати термин vibe coding. Разработчик формулирует намерение голосом или в чате, Cursor либо другой ассистент генерирует большие фрагменты программы, а неудачную версию можно без сожаления выбросить и запросить заново. Для личного проекта или прототипа в незнакомой области это снимает цену первого шага: вместо долгого освоения каждого инструмента инженер быстрее проверяет, работает ли сама идея. Такая обратимость отличает исследование от эксплуатации. Пока цена ошибки ограничена временем автора, можно позволить себе несколько быстрых попыток; когда код получает доступ к данным, деньгам или пользователям, каждое непрочитанное решение становится частью риска. Поэтому «не смотреть в код» — описание режима эксперимента, а не новая универсальная инженерная норма.

В обсуждении Y Combinator звучит наблюдение, что около четверти опрошенных основателей создавали до 95% кода продукта с помощью ассистентов. Это помогает быстрее показать демо и проверить спрос, но промышленная эксплуатация требует человека, который понимает программную инженерию, продукт и границы модели. Меняется и собеседование: ценным сигналом становится не чистота кода, а объём функциональности, который кандидат способен получить за ограниченное время с доступным инструментарием. Ассистент может взять рутину и выступить дополнительным рецензентом, но решение остаётся за инженером. Сам процент не сообщает, кто сформулировал архитектуру, проверил крайние случаи и исправил последствия генерации. Для оценки кандидата поэтому важен полный цикл: как он уточняет условие, выбирает компромисс, замечает слабый ответ модели и объясняет получившуюся систему. Скорость набора строк становится вторичным сигналом рядом с качеством суждения.

Новость о том, что 95% объектов российской критической инфраструктуры используют зарубежные решения, ведущие разбирают как пример опасного заголовка. В исходное определение могли попадать любые компоненты с зарубежным участием, включая открытые библиотеки, а не только системы, которые требовалось заменить. Поэтому сама доля мало говорит о зависимости и риске: сначала нужно выяснить, что именно считалось, какую функцию выполняет компонент и существует ли контролируемая замена. Для одного компонента зависимость означает прекращение обновлений, для другого — отсутствие компетенции внутри страны, для третьего — только происхождение репозитория. Складывать эти случаи в одну цифру удобно для новости, но невозможно для плана миграции. Инженерная карта должна связывать происхождение с критичностью, правом изменять код и реальной стоимостью выхода.

История Citi показывает другую крайность: вместо 280 долларов банк провёл перевод на 81 триллион, а аномалию заметил человек примерно через полтора часа. Многоуровневый контроль в итоге позволил исправить операцию, но автоматические барьеры пропустили абсурдное значение. В разговоре о C++ возникает тот же разрыв между обещанием и практикой. Rust предлагает безопасную работу с памятью по умолчанию, тогда как C++ часто полагается на анализаторы и обвязку, доступные не каждой команде. Старый код никуда не исчезнет, однако языку нужен понятный современный рассказ о безопасности, а организациям — реальные защитные практики. В обоих случаях недостаточно сослаться на зрелость организации или популярность технологии. Нужно знать, какой контроль срабатывает до действия, какой обнаруживает аномалию после него и кто способен безопасно восстановить состояние. Человеческая проверка полезна именно как независимый слой, а не как оправдание слабой автоматики.

История Perplexity иллюстрирует важность момента и продуктового фокуса. Первая попытка продавать компаниям поиск по внутренним данным упиралась в нежелание делиться информацией. Потребительский прототип взлетел, когда базовые модели научились лучше следовать инструкциям: годом раньше качество было бы недостаточным, годом позже нишу мог занять другой игрок. Молодая компания могла позволить себе каннибализировать привычный поиск, тогда как Google и Microsoft связаны существующими доходами. Поставщики моделей поэтому инвестируют в стартапы на собственной технологии: каждый новый сценарий расширяет ценность их платформы. Кейс показывает, что модель сама по себе не является продуктовой стратегией. Нужны доступный набор данных, понятная пользовательская привычка и способ показать преимущество в момент, когда технология уже пригодна, а рынок ещё не распределён. Стартап выигрывает скоростью смены гипотез, но одновременно зависит от цен, правил и темпа развития базовой платформы.

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