Маленький разработчик — большие риски? Как выбирать поставщика ПО в эпоху ИИ

Небольшие компании нередко создают технологии, которые затем получают широкое распространение. ИИ-инструменты разработки, включая Claude Code и Codex, расширяют возможности таких команд: они помогают писать код, тестировать продукты и исправлять ошибки.

На этом фоне инвесторы обсуждают перспективу появления «единорога» — компании с оценкой от миллиарда долларов — с единственным сотрудником. Пока это предположение, а не установленная тенденция. Но примеры дорогих компаний с небольшим штатом были и до нынешнего развития ИИ: в 2012 году Facebook, теперь Meta, приобрела Instagram примерно за миллиард долларов, когда в команде сервиса работали всего 13 человек.

Для заказчика важнее другое: способен ли небольшой разработчик обеспечить надежность продукта и выполнять обязательства. Отказ от всех малых поставщиков ограничивает доступ к новым технологиям, а выбор без должной проверки создает зависимость от компании, которая может не справиться с нагрузкой или прекратить работу. Оценивать нужно конкретные риски и способы их снижения.

Что будет с продуктом, если поставщик закроется

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

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

Для продукта, созданного с помощью ИИ, одного исходного кода может быть недостаточно. Стоит определить, какие материалы понадобятся для сопровождения: техническая документация, тесты, инструкции, запросы к ИИ и история взаимодействия с ним. Если требуется доступ к среде разработки, его условия также нужно отдельно согласовать.

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

Как проверяют качество ПО

Заказчику нужно понимать не только функции продукта, но и то, как поставщик проверяет их работоспособность. Демонстрация возможностей не доказывает, что система выдержит эксплуатацию в реальных условиях.

Claude Code и Codex могут помогать создавать и запускать тесты, выявлять ошибки и готовить исправления. ИИ также полезен при поиске пограничных сценариев, которые разработчики могли упустить. Однако само использование этих инструментов еще не подтверждает качество продукта.

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

Кто поможет при сбое

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

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

Кто отвечает за исправления и развитие продукта

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

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

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

Что говорят действующие клиенты

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

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

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

Как устроена защита от киберугроз

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

ИИ-инструменты могут анализировать код, искать слабые места и помогать проводить санкционированные испытания в тестовой среде. Они применимы и в проверках по модели red team и blue team: одна сторона имитирует действия атакующего, другая отрабатывает обнаружение угроз и защиту.

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

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

Оценивать не размер команды, а управляемость рисков

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

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