Rakhmanov Studio 
Тендеры и лиды
Информация
Хайп вокруг вайбкодинга и обещаний собрать сложный софт за вечер наводнил рынок сырыми решениями и сорванными проектами. Даем 5 прикладных вопросов на первом созвоне, которые помогут не-айтишнику вскрыть некомпетентность подрядчика до подписания договора.
Если сегодня открыть ленту соцсетей, создается стойкое ощущение, что классическая разработка умерла. В трендах ролики с миллионными просмотрами: «Как мой ИИ-агент сам ищет клиентов, сам верстает им сайты за 5 минут, отправляет КП, а я просто лежу на пляже». Или байки инфобизнеса: «Мой ученик прошел двухнедельный курс, сам собрал сайт, а когда понадобилась система учета — за один вечер на промптах с нуля собрал себе CRM».
Для продажи курсов и сбора лайков это работает отлично. Но проблема в том, что этот белый шум ежедневно выливается в реальный сектор экономики.
Предприниматели без глубокого технического бэкграунда смотрят эти видео и начинают примерять их на свои задачи. А когда выходят на рынок за реальным софтом, сталкиваются с ситуацией, которая взрывает мозг: на один и тот же бриф интернет-магазина или B2B-кабинета им присылают сметы с разбросом от 80 000 до 3 000 000 рублей.
Одни уверяют, что соберут всё за три дня на коленке, вторые выкатывают смету с десятком неизвестных терминов. В итоге наступает паралич выбора: заплатить 80 тысяч страшно (а вдруг не заработает?), но и платить 2 миллиона боязно (а вдруг меня разводят, вон же в рилсах за вечер собирают?).
Эйфория от «быстрого кода» уже сменяется суровым похмельем. За последние месяцы в юридической практике всё чаще всплывают споры бизнеса с горе-разработчиками, собравшими решения на сырых промптах.
Когда код генерируется вслепую, наружу вылезают фундаментальные инженерные проблемы, о которых в рилсах не рассказывают:
Полное отсутствие изоляции данных: данные одного пользователя могут утечь другому из-за кривой работы с сессиями.
Игнорирование 152-ФЗ: отправка конфиденциальных клиентских данных в открытые зарубежные API без локализации и шифрования.
Падение при конкурентных транзакциях: в красивой демо-версии кнопка оплаты работает, но когда два клиента одновременно покупают последний товар на складе, база намертво зависает, списывая деньги дважды.
Юридическая пустота: кому принадлежат права на сгенерированный код и кто несет ответственность при взломе — никто в договоре не прописал.
Чтобы не оказаться в ситуации, когда через два месяца после релиза софт приходится переписывать с нуля за двойной бюджет, заказчику не нужно учиться программировать. Достаточно задать подрядчику 5 конкретных вопросов на первом установочном созвоне.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13826 тендеров
проведено за восемь лет работы нашего сайта.
Красный флаг: Подрядчик не видит разницы между секретами сервера и кодом фронтенда. У вайбкодеров классика — зашивать API-ключи от ЮKassa, CloudPayments или токены Telegram-ботов прямо в клиентский JavaScript. Любой пользователь открывает вкладку DevTools в браузере и видит секретные ключи от вашей кассы.
Как должно быть: Все ключи и доступы изолированы в защищенных серверных переменных окружения (.env) на бэкенде. Клиентский браузер никогда не имеет прямого доступа к API эквайринга или базе данных.
Красный флаг: «У нас закрытый сайт, никто ничего не изменит». В коде из нейросетей авторизация часто условная: данные запрашиваются напрямую по ID пользователя. Если подставить чужой ID — открываются чужие контакты, корзины или переписки.
Как должно быть: На уровне базы данных настроена строгая проверка прав (Row Level Security / валидация сессий). Сервер проверяет права на каждое действие: пользователь может запросить только свои данные, даже если вручную подменит параметры в запросе.
Красный флаг: «Нейросеть настроила логику, кнопка нажимается». В демо-версии при тестировании в один поток всё работает. Но если в Черную пятницу два человека одновременно жмут «Купить» на последний товар на складе или один слот брони, код без транзакционных блокировок спишет деньги у обоих.
Как должно быть: Использование строгих транзакций баз данных (SELECT FOR UPDATE в PostgreSQL, ACID-транзакции). Пока одна оплата не зафиксирована, ресурс блокируется, исключая двойные продажи и рассинхрон остатков.
Красный флаг: «Код понятный, там всё комментировано, документация не нужна». Главное проклятие вайбкодинга: первые три дня проект летает, но когда через месяц нужно добавить новую интеграцию, сгенерированный код превращается в кашу, где правка одной строчки ломает авторизацию и платежи. Ни одна нормальная студия потом не берется это поддерживать.
Как должно быть: Чистая модульная архитектура, Swagger-спецификация для API и базовое покрытие интеграционными тестами ключевых сценариев (авторизация, добавление в корзину, чекаут). Любой сторонний разработчик должен мочь развернуть проект по инструкции в README за 15 минут.
Красный флаг: Подрядчик не знает, какие библиотеки подтянула нейросеть, и где развернут сервер (например, в бесплатном зарубежном PaaS без локализации персональных данных).
Как должно быть: Отсутствие критических уязвимостей в зависимостях, базы данных клиентов физически изолированы на серверах в РФ в соответствии со ст. 18 152-ФЗ, трафик зашифрован.
Изоляция секретов: ключи API и доступы к базам скрыты в серверных .env и не утекают в клиентский JS.
Контроль доступа (IDOR): строгая валидация сессий и RLS на уровне БД, исключающие просмотр чужих данных по ID.
ACID и защита от овербукинга: транзакционные блокировки при оплате и списании остатков.
Поддерживаемость и тесты: модульная архитектура, Swagger API и базовые интеграционные тесты для быстрой передачи кода.
Безопасность и 152-ФЗ: проверка зависимостей (npm audit/CVE), серверы в РФ и сквозное шифрование.
Да, и профессиональные студии активно это делают. Нейросети отлично справляются с рутиной: генерацией моковых данных, написанием типовых тестов, первичным рефакторингом и подготовкой документации. Это снижает себестоимость проекта на 20–30%. Но ИИ нельзя слепо доверять архитектуру, изоляцию секретов, транзакционную надежность и безопасность клиентских данных.
Сгенерированный на скорую руку код выглядит рабочим в демо, но таит в себе критические уязвимости: ключи эквайринга в открытом коде, дыры IDOR с доступом к чужим данным, отсутствие транзакционных блокировок при оплате и спагетти-структуру, которую невозможно масштабировать.
В 9 случаях из 10 студии отказываются от доработок чужого сгенерированного кода без документации и тестов. Попытка исправить одну ошибку в такой системе вызывает каскадное падение других модулей. Бизнесу практически всегда предлагают переписать проект заново.
Провести базовый технический аудит: проверить клиентский JS на наличие секретных API-ключей в DevTools, протестировать подмену ID в запросах на чужие данные, проверить логику параллельной покупки и запросить результаты npm audit вместе со Swagger-документацией.
