Один senior-разработчик, система управления тендерами с нуля, ни строки кода вручную — ни в логике, ни в тестах, ни в документации. Это не маркетинговый тезис: CEO Siberian.pro Влад Кармаков опубликовал подробный разбор на Хабре с реальными фрагментами документов, планов и диаграмм. Ключевой вопрос — не «можно ли», а «как именно» это работает без хаоса и галлюцинаций.
Контекст
Siberian.pro — российская компания по разработке и внедрению цифровых решений. Внутренний инструмент, о котором идёт речь, автоматизирует работу с тендерными площадками: скачивает свежие лоты по критериям, обрабатывает их через LLM (описания, теги, категоризация), предоставляет интерфейс для фильтрации и типовых действий. Стек — Refine.js + Ant Design на фронте, Python/FastAPI на бэке, Supabase (PostgreSQL) как БД, LiteLLM Proxy как роутер к разным LLM.
Контекст важен: это не «поиграть с vibe-coding», а production-инструмент, который заменил ручную работу тендерного специалиста. Задача была построить не просто работающее, но масштабируемое и сопровождаемое решение. Именно это разграничение — «навайбкодить по-быстрому» vs. «построить manageable продукт» — и определяет весь подход.
AI-first разработка в 2025–2026 году перестала быть экспериментом. Вопрос сместился: не «использовать ли LLM», а «как не потерять контроль над проектом, который LLM написала». Статья Кармакова — один из немногих честных публичных разборов с реальными артефактами.
Аналитика
Главная проблема LLM-разработки — не галлюцинации сами по себе, а отсутствие структуры, при которой галлюцинации некуда просочиться. Если скормить модели размытый промпт и ждать готовый продукт, она додумает всё, что не знает: требования, архитектуру, бизнес-логику. Подход Siberian.pro решает это через классический SDLC, где каждый этап завершается конкретным документом, а каждый документ проходит двойную верификацию — человек плюс отдельный LLM-агент с противоположной задачей.
Двухагентная схема — ключевая находка. Агент-создатель нацелен на результат и склонен приукрашивать. Агент-верификатор натренирован искать ошибки. Хитрость в том, что верификатору дают инструкцию ранжировать проблемы по важности — это «топит» галлюцинированные баги на дно списка. Проверка идёт в обе стороны: сверху вниз (есть ли реализация для каждого требования) и снизу вверх (есть ли требование для каждой реализации). Такая симметрия ловит и недоделки, и «лишний» код.
Другой системный элемент — папка с инструкциями внутри проекта. Перед каждым типом документа агент читает соответствующую инструкцию: как писать бизнес-требования, как строить flow-диаграммы, как формулировать функциональные спецификации. Это корпоративная база знаний, накопленная итерационно. По сути — то, что в RAG-системах называют «knowledge base», но заточенное под процесс разработки. Масштаб этого инсайта выходит за рамки одной компании: компании, которые сейчас инвестируют в структурированные AI-инструкции, строят долгосрочное конкурентное преимущество.
Кейсы применения в бизнесе
B2B-SaaS стартап. У вас два разработчика и пять фич в бэклоге. Внедрить этот подход означает: завести папку ai-instructions/ в репозитории с шаблонами для каждого типа документа (BR, FR, спека фичи, план тестирования). Каждый новый модуль начинается с README-черновика от LLM, который разработчик правит за 20 минут. Верификацию можно автоматизировать через второй вызов модели с системным промптом «найди несоответствия». Результат: снижение времени на документацию на 60–70%, при этом документы реально читаемы — не формальность.
Корпорация с legacy. Самая болезненная точка — не написать новый код, а понять старый. LLM-агент с доступом к кодовой базе и инструкцией «опиши бизнес-логику этого модуля» генерирует документацию, которой никогда не было. Дальше двухагентная схема: один агент документирует, второй задаёт уточняющие вопросы по неясным участкам. Для команд, наследующих легаси-системы без документации, это снижает onboarding нового разработчика с нескольких недель до нескольких дней.
SMB и локальный бизнес в КР/СНГ. Небольшая команда (иногда один разработчик-фрилансер) берёт заказ на автоматизацию бизнес-процесса. Подход применим напрямую: провести созвон с клиентом, транскрибировать его (Whisper или любой локальный инструмент), скормить транскрипт LLM для генерации README и outline экранов. Клиент получает читаемый документ уже через час после звонка — это само по себе производит впечатление и снижает количество правок на финальных этапах. Для рынка КР, где IT-студии конкурируют в основном ценой, такая скорость и структурированность — реальный дифференциатор.
Кейсы в личной жизни
Разработчик, который работает в одиночку или ведёт pet-проект: попробуй один раз пройти полный цикл — от транскрипта идеи до функциональных требований — прежде чем писать первую строку. Не ради формализма, а чтобы увидеть, где твоя идея рассыпается ещё до кода. LLM-верификатор найдёт дыры, которые ты не заметил, потому что слишком близко к проекту.
Контент-мейкер или менеджер продукта без технического бэкграунда: этот подход означает, что вы можете участвовать в постановке задач на том же уровне, что и разработчик. README, outline экранов, flow-диаграммы — всё это читаемо без знания кода. Попробуй описать свою идею для инструмента или сервиса в свободной форме, затем попроси LLM сформировать из этого структурированный документ. Ты увидишь дыры в собственном мышлении.
Студент или джун, осваивающий разработку: двухагентная верификация — это в том числе обучающий инструмент. Если первый агент написал код, а второй нашёл пять несоответствий с требованиями — это не провал, это обратная связь. Изучай паттерны ошибок: где LLM чаще всего отклоняется от спецификации, где интерпретирует расширительно. Это прокачивает навык написания точных промптов быстрее, чем любой курс.
Как применить сегодня
- Создай папку
ai-instructions/в своём проекте. Положи туда шаблоны для трёх типов документов: бизнес-требования, функциональные требования, план тестирования. Это займёт два часа, сэкономит десятки. - Для следующей задачи начни с транскрипта обсуждения (даже голосового сообщения в мессенджере), а не с промпта «напиши мне X». Дай LLM сформулировать README из реального контекста — получишь артефакт, который сразу можно ревьюить.
- Внедри двойную верификацию: после генерации любого документа запускай второй вызов с системным промптом вида «ты критик, найди все несоответствия и пробелы, ранжируй по важности». Первые три пункта в списке — реальные проблемы, остальное — шум.
- Используй LiteLLM Proxy или аналогичный роутер, чтобы не привязываться к одной модели. Для генерации документов и кода — Sonnet или GPT-4o. Для верификации и классификации — более лёгкие и дешёвые модели.
- Фиксируй план работ в живом документе внутри репозитория (
PLAN.mdс чекбоксами). LLM-агент обновляет его по мере выполнения шагов — это и трекер, и контекст для следующей сессии, и документация для команды.
«У нас цель другая — не навайбкодить решение по-быстрому, а создать масштабируемый и управляемый продукт, который в дальнейшем будет легко поддерживать и удобно развивать» — Влад Кармаков, CEO Siberian.pro