Почему качество программного обеспечения теперь — проблема на уровне основателя, а не только инженерная

Ключевые выводы

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

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

Благодаря распространению "интуитивного" кодирования (vibe coding), почти любой может стать разработчиком, и рынок уже демонстрирует это. Например, 25% стартапов Y Combinator в Зимнем потоке 2025 года имели кодовые базы, на 95% сгенерированные ИИ.

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

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

Когда качество страдает, страдает и бизнес

Анализ 470 запросов на слияние из открытых источников в декабре 2025 года показал, что код, написанный с участием ИИ, содержал примерно в 1,7 раза больше проблем, чем код, написанный человеком, а уязвимости безопасности встречались до 2,74 раза чаще.

При текущих скоростях выпуска продуктов, стоимость низкого качества проявляется в формах, от которых трудно оправиться:

• Нарушения безопасности: Предположение о том, что код, сгенерированный ИИ, готов к производству, является одной из самых дорогостоящих ошибок, которые может совершить команда. Например, популярная платформа для "интуитивного" кодирования имела критические уязвимости безопасности более чем в 10% приложений, представленных в ее витрине. Основной причиной был не сложный взлом, а просто сгенерированный ИИ код, который пропускал базовые конфигурации безопасности.
• Доверие клиентов: Пользователи не читают отчеты об инцидентах. Им все равно, произошла ли ошибка из-за человека или ИИ; они просто знают, что продукт их подвел. Одна из нашумевших социальных сетей, использующих ИИ, раскрыла 1,5 миллиона токенов API и 35 000 адресов электронной почты из-за одной неправильно настроенной базы данных в коде, сгенерированном ИИ. Репутационный ущерб распространился быстрее, чем удалось выпустить исправление.
• Репутация и доверие инвесторов: Сбои в качестве не остаются внутри инженерной команды. Они обсуждаются на заседаниях совета директоров, в отчетах для инвесторов и в прессе. В 2026 году качество программного обеспечения стало деловым риском, и основатели несут ответственность за деловые риски.
• Регуляторные и комплаенс-риски: ИИ не понимает обязательств по соблюдению нормативов; он просто пишет код. GDPR, HIPAA, требования к резидентности данных — эти аспекты не заложены в подсказки. И в отличие от нарушения безопасности, которое быстро обнаруживается, сбой в комплаенсе может месяцами тихо присутствовать в кодовой базе, прежде чем кто-либо его заметит. К тому времени это уже не просто инженерное исправление, а юридическая проблема.

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

Пробел в ответственности, о котором никто не говорит

В большинстве компаний на бумаге кажется, что вопросы качества учтены. Есть команда QA, процесс ревью, определение готовности. Но процесс, который работал, когда люди писали каждую строку, не подходит автоматически, когда ИИ генерирует 95% кода, а человек лишь бегло просматривает остальное.

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

Они доходят до руководителя продукта, до технического директора и, в конечном итоге, до основателя. И к тому времени, когда проблема доходит до них, это уже не просто техническая проблема, а проблема всей компании.

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

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

Что меняется, когда ответственность берет на себя основатель

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

Во-первых, качество становится метрикой, отслеживаемой руководством, а не просто отчетом QA раз в спринт. Если у доходов и расходов есть своя приборная панель, то у количества дефектов, обнаруженных проблем безопасности и времени до их обнаружения тоже должна быть такая же.

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

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

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

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