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

Привет, Хабр! Меня зовут Влад Кармаков, CEO компании по разработке и внедрению цифровых решений Siberian.pro. Рассказываю, как устроена ИИ-разработка у нас в компании.
Есть такая шутка, что разработка в 2026 году ведется не на C++ или Python, а на английском. Как оказалось, это вовсе не шутка.
Один наш senior-разработчик недавно написал в рабочем чате, что с декабря прошлого года не написал ни одной строчки кода руками. Но как, Холмс? Ведь ИИ галлюцинирует. Забывает требования или выдумывает несуществующие. Портит работающий код. Переписывает эффективные участки кода неэффективно. Не держит в голове структуру проекта, а значит, периодически ее ломает, теряя взаимосвязи. Я ничего не забыл?
Сегодня я пошагово — и очень подробно! — разберу один наш внутренний проект, который мы писали для себя. Он на 100% сделан ИИ. Ни код, ни тесты, ни даже документация руками не делались вообще. Совсем.
Весь этот проект написал ровно один специалист, вооруженный ИИ, используя подход, который я сейчас опишу.
Наш внутренний проект — это инструмент для работы с тендерными площадками и управления тендерами. Мы решили создать такой инструмент для внутреннего пользования, чтобы упростить поиск контрактов, которые подходят под интересный нам бюджет и технологический стек. Раньше эту работу делал руками тендерный специалист.
«Система управления тендерами» звучит мощно, но на деле функциональность у нее довольно базовая:
скачать свежую информацию с тендерной платформы по заранее заданным критериям;
собрать найденные тендеры в список;
для каждого тендера описать его суть, выделить контактные лица, сроки, требования и т.д.;
проставить теги для быстрой фильтрации.
По сути все. Затем этот список можно фильтровать по тегам, по стеку, по тематике. Ну и выполнять какие-то типовые действия с самим тендером: смотреть документацию, условия, добавить комментарий и прочее.


Но самое интересное — это не сама система, а подход, который использовался для разработки. С его помощью один сотрудник полностью создал этот проект с нуля с помощью ИИ. По сути, это было то самое программирование на английском языке (точнее, на русском), но с важными нюансами.
Интересно, что подход легко масштабируется, поэтому с некоторыми оговорками подходит и для крупных проектов, о чем я тоже немного расскажу.
Разработка шла по классической схеме SDLC, однако все этапы от анализа требований и планирования до тестирования выполнил ИИ. Давайте подробно пробегусь по основным этапам.
В агента загрузили созвоны, в которых в свободной форме обсуждалось решение и что оно должно делать. Как ни странно, транскрибации часового звонка с помощью ИИ и нескольких текстовых обсуждений для ИИ вполне хватило, чтобы сформулировать документ с общим описанием проекта.
Получился такой README.MD:
Скрытый текст**Система Управления Тендерами (TMS)**
### Общее описание
Система управления тендерами (TMS) предназначена для автоматизации процессов обнаружения, анализа и управления тендерами. Она автоматизирует загрузку данных о тендерах из внешних источников, использует ИИ для категоризации и описания тендеров, и предоставляет удобный интерфейс для специалистов.
### Основные возможности
* Автоматическая загрузка тендеров с тендерных площадок по настраиваемым фильтрам
* Централизованное управление тендерными процессами с разграничением доступа по ролям
* Автоматизированный документооборот и отслеживание статусов тендеров
* Система комментирования для координации работы между отделами
* Автоматическое присвоение тегов и генерация описаний при помощи ИИ
### Архитектура и технологический стек
#### Технологический стек
* Frontend: Refine.js с библиотекой компонентов Ant Design
* Backend: Python/FastAPI для фоновых задач
* База данных и аутентификация: Supabase (PostgreSQL)
* Искусственный интеллект: LiteLLM Proxy (обеспечивает доступ к различным LLM моделям, включая Gemini, Claude, GPT и другие)
… и т.д.
Что здесь важно? ИИ не выдумывал содержимое этого файла. Он лишь грамотно оформил то, что услышал и увидел в исходных материалах. Уже на этом этапе ревью человеком выявит несоответствия с изначальным виденьем проекта архитектором. Т.е. по факту высокоуровневое проектирование выполняет человек, а не машина.
Под аутлайном я понимаю очень сжатые описания экранов и основных процессов (flow) будущего продукта, которые вытекают из общего описания системы. Обычно они довольно простые и короткие, что имеет два плюса:
проще прочитать человеку, чтобы понять суть проекта, не погружаясь глубоко в бизнес-требования и более детальные проектные документы;
проще скормить нейросети, чтобы задать дальнейший курс проектирования.
В дальнейшем эти описания можно отредактировать, вписав туда конкретные функциональные и бизнес-требования. Но начать работу можно и без них.
На выходе получаем некий frontend_screens.md. Вот кусочек для иллюстрации:
Фрагмент описания экранов будущего проекта# Обзор экранов интерфейса системы TMS
## 1. Введение
Документ описывает структуру и назначение основных экранов
пользовательского интерфейса системы управления тендерами.
## 2. Общая структура навигации
### 2.1. Иерархия экранов
Главная страница (/)
├── Список тендеров (/tenders)
│ └── Просмотр тендера (/tenders/:id)
├── Пользователи (/users)
│ ├── Просмотр Пользователя (/users/:id)
│ ├── Редактирование пользователя (/users/:id/edit)
│ └── Создание пользователя (/users/create)
├── Теги (/tags)
│ ├── Просмотр Тега (/tags/:id)
│ ├── Редактирование Тега (/tags/:id/edit)
│ └── Создание Тега (/tags/create)
├── Фильтры (/filters)
│ ├── Просмотр Фильтра (/filters/:id)
│ ├── Редактирование Фильтра (/filters/:id/edit)
│ └── Создание Фильтра (/filters/create)
├── Описание (/description)
└── Аутентификация
├── Вход (/login)
├── Подтверждение приглашения (/confirm-invite)
├── Восстановление пароля (/forgot-password)
├── Обновление пароля (/update-password)
└── Установка пароля (/set-password)
## 3. Описание экранов
### 3.1. Экран входа
- URL: /login
- Назначение: Аутентификация пользователей в системе
- Основные элементы:
- Форма ввода email/пароля
- Кнопка "Войти"
- Ссылка на восстановление пароля
Экраны — это замечательно, но наше приложение должно что-то делать, запускать какой-то flow. Этот flow тоже нужно описать документально. Делать это, конечно, тоже поручаем ИИ.
В этом приложении всего три ключевых flow:
извлечение данных с тендерной площадки;
обработка с помощью ИИ (описания, теги, категоризация);
условия изменения статусов тендера («открыт», «в обработке», «готово», «отказ» и т.д.).
Вот пример документа, описывающего процесс извлечения данных:
Скрытый текст# Поток 1: Сбор Данных Тендера
Этот поток отвечает за получение и сохранение новых тендеров из внешних источников.
```mermaid
graph TD
A["Планировщик (Ежечасно)"] --> B["Вычисление диапазона дат (клиент)"];
B --> C["Запрос к API с пагинацией (page=0, 1, ...)"];
C --> D["Получение страницы тендеров"];
D --> E{"Дата тендера в диапазоне?"};
E -- "Да" --> F["Добавить в список найденных"];
E -- "Нет (старше)" --> G["Прекратить пагинацию"];
E -- "Нет (новее)" --> H["Пропустить тендер"];
F --> I{"Есть ещё тендеры на странице?"};
H --> I;
I -- "Да" --> E;
I -- "Нет" --> J{"Достигнут конец или старая граница?"};
J -- "Нет" --> C;
J -- "Да" --> K["Сохранение в БД (статус NULL)"];
G --> K;
```
### Описание Потока Сбора Данных:
1. Планировщик: Запускается раз в час.
2. Вычисление диапазона дат: Вычисляются границы date_start и date_end на стороне клиента (скрипта).
3. Запрос к API с пагинацией: Выполняется серия запросов к TenderGuru API с пагинацией. Параметры 'date_start' / 'date_end' НЕ передаются в API - фильтрация по датам выполняется на клиенте.
4. Клиентская фильтрация: Для каждого тендера проверяется поле date. Тендер добавляется в список, только если его дата находится в диапазоне [date_start, date_end].
Обратите внимание на диаграмму в документе. ИИ-шке она не нужна, но для последующего сопровождения и развития проекта будет полезна.
И здесь я сделаю паузу и проговорю, для чего нужно столько предварительной работы. Можно ведь просто задать промпт в духе «Напиши приложение для анализа и управления тендерами. Исходные данные - здесь».
Можно, но зачем у нас цель другая — не навайбкодить решение по-быстрому, а, во-первых, создать масштабируемый и управляемый (manageable) продукт, который в дальнейшем будет легко поддерживать и удобно развивать. А для этого нужны все промежуточные этапы, т.к. они по сути документируют процесс SDLC.
Во-вторых, в компании мы хотим построить информационную инфраструктуру, которая позволит разрабатывать практически любой проект с использованием описанных здесь практик.
Подробнее о выгодах такого подхода я расскажу в самом конце. А сейчас переходим к созданию плана работ.
Теперь агент может составить для самого себя генеральный план работ по проекту.
Т.е. ИИ буквально по шагам расписывает, что он будет делать дальше:
Изучить README.MD
Изучить инструкции по составлению бизнес-требований
Составить бизнес-требования к проекту на основе анализа задачи и экранов
Создать прототипы
Разработать функциональные и нефункциональные требования
Разработать UX
Разработать архитектуру проекта
Разработать план реализации фич
И так далее. Вот фрагмент из реального плана реализации нашего тендерного проекта:
Фрагмент project_plan.md# План работ по реализации проекта "Управление тендерами" (v2.0)
<...>
### [v] Этап 6: Создание модуля администрирования
* 4.1. [v] Страница списка фильтров.
* 4.2. [v] Форма просмотра подробной информации о фильтре.
* 4.3. [v] Форма редактирования фильтра.
* 4.4. [v] Форма создания нового фильтра.
---
### [ ] Этап 7: Разработка фоновых сервисов (Автоматизация)
* Задача: Реализовать автоматическую загрузку и обработку тендеров.
* Ключевые действия:
1. [v] В рамках сервера разработать скрипт для ежечасной загрузки тендеров.
* Детальный план:[plan/phase7_ingest_tenders.md](phase7_ingest_tenders.md)
2. [ ] В рамках сервера разработать скрипт для ежеминутной обработки тендеров с помощью ИИ.
[v] *Детальный план:** [plan/phase7_process_tenders.md](phase7_process_tenders.md)
[ ] 1d *Доработка (Поддержка DOC/DOCX):** [plan/process_tenders_docx_support.md](process_tenders_docx_support.md)
* [ ] 2d Доработка - поддержка zip-архивов.
### [v] Этап 8: Докеризация
* Задача: Реализовать механизм развёртывания всей системы (фронтенд, бекенд скрипты, supabase self-hosted) через docker-compose.
* Документация:[docs/shared/deployment.md](../docs/shared/deployment.md)
* Ключевые действия:
1. [v] Спроектировать архитектуру и написать документацию по развёртыванию.
2. [v] Создать Dockerfile для фронтенд-приложения.
3. [v] Создать Dockerfile для бекенд-скриптов.
4. [v] Создать docker-compose.yml с полным self-hosted Supabase.
Далее этот план пошагово выполняется. По сути, читая этот документ, ИИ уподобляется джуну: последовательно выполняет заранее определенные шаги, чтобы нигде не накосячить. Изучить требования, изучить модель данных, изучить спецификации проекта, начать реализацию первой фичи и т.д.
Каждый выполненный шаг отмечается в плане как успешно выполненный, если после его выполнения он успешно прошел верификацию. Дальше по тексту я не буду это упоминать, но просто держите в голове, что после каждого описанного ниже шага, агент выполняет верификацию.
Что такое верификация и зачем она нужна?
Особенность работы нейросетей в том, что они рано или поздно начинают галлюцинировать. Чтобы этого не происходило, процесс устроен так, чтобы в контексте ИИ всегда были документы регулирующие его работу на каждом этапе. При этом вся работа разбивается на небольшие задачи, выполняемые по отдельности. Так легче контролировать агента и проверять работу.
В ходе верификации агент проходит дерево документов конкретного этапа сверху вниз, чтобы удостовериться, что каждое верхнеуровневое требование или пункт спецификации имеет свою реализацию на нижних уровнях. А затем еще раз, уже снизу вверх, чтобы убедиться, что каждая реализация непременно имеет в основе верхнеуровневое требование.
И теперь важный момент. Quis custodiet ipsos custodes? Кто сторожит сторожей? Почему бы агенту не нагаллюцинировать вообще всю эту историю с требованиями и спецификациями от начала и до конца? А он может, не сомневайтесь! Ведь нейросети натренированы давать одобряемые ответы, даже если они неправильные. Соврет и глазом не моргнет!

Вот поэтому верификацией занимается другой агент. У него свои инструкции, свои промпты и свой контекст. Я больше скажу: у него своя цель работы. У первого ИИ цель — создать документ, и он так сильно будет стараться это сделать, что запросто наврет с три короба, если ему позволить. Но ему не даст это сделать второй ИИ, задача которого обратная: в ходе верификации найти как можно больше ошибок.
Тут еще есть хитрость. Ведь верификатор тоже запросто может придумать несуществующие проблемы, чтобы выслужиться перед пользователем. Смотри, мол, какой я молодец: нашел кучу багов. Однако если заранее попросить его ранжировать проблемы по важности, то все галлюцинации окажутся где-то внизу списка. Такой вот лайфхак.
Результат верификации передается первому агенту, и тот знает, прошла она или нет. И если нет, то он понимает, что именно нужно переделать и почему.
В итоге все работает. Четко и слаженно.
Возвращаемся к плану. Один из первых шагов реализации плана — формулирование бизнес-требований.
Описание README.MD вновь передаем ИИ, просим сформулировать на его основе business_requirements.md. Получается так:
Скрытый текст## Бизнес-требования (BR) для системы управления тендерами
### 1. Общие сведения о бизнес-потребности
### 1.1. Проблема бизнеса
Компания сталкивается с неэффективностью действующего процесса управления тендерами, которые включают:
* Ручной поиск и обработка данных о тендерах на площадках
* Отсутствие централизованного контроля и отслеживания статусов
* Сложности координации работы между отделами по тендерам
* Высокие временные затраты специалистов на рутинные задачи
### 1.2. Бизнес-цели
Создание автоматизированной системы, которая позволит:
* Сократить время на поиск и анализ тендеров за счет ИИ-анализа
* Увеличить количество обрабатываемых тендеров за счет автоматизации
* Снизить операционные затраты на управление тендерами
* Сохранить качество принимаемых решений
---
## 2. Ключевые бизнес-требования
### 2.1. Автоматизация сбора данных
BR-001:
Система должна автоматически собирать данные о тендерах с внешних площадок по настраиваемым критериям
Обоснование:
Сокращение ручного труда специалистов
Приоритет:
Высокий
…и т.д.
Здесь стоит еще раз ненадолго прерваться, потому что, как я подозреваю, в голове читателя уже возник вопрос: а откуда ИИ знает, как писать документы бизнес-требований? С чего это мы взяли, что он не фантазирует, как Джей Ди из «Клиники», а действительно пишет что-то годное?

Ответ такой: ИИ знает, как писать документ с бизнес-требованиями, а также документы с функциональными и нефункциональными требованиями, спецификации фич и планы тестирования, потому что нейросеть этому обучили на огромном корпусе данных. Ни один аналитик не прочитал столько книг про составление бизнес-требований, сколько ИИ.
Наша задача — просто сделать так, чтобы ИИ не писал лишнего.
Для этого в отдельной папке проекта лежат инструкции, которые загружаются в системный промпт агента. И первая инструкция гласит: НЕ ПАНИКУЙ перед тем, как что-то делать, прочти инструкцию.
Получается агент знает, что перед составлением бизнес-требований он должен сперва прочитать соответствующую инструкцию по составлению бизнес-требований. А уже в ней подробно расписано, как мы хотим, чтобы он это сделал, какие разделы должны быть в этом документе, и т.д.
ИИ-инструкции — это внутренняя разработка Siberian.pro, более или менее стандартизованная. Отчасти они состоят из промптов, но далеко не только. Они сформировались итерационно и концентрируют в себе опыт всей компании, ее сотрудников в сфере ИИ-разработки. Чуть ниже расскажу об этом еще.
А пока еще раз подчеркну важный момент во всей этой истории. На каждом последующем этапе результат работы ИИ подвергается не только человеческому ревью, но и ревью с помощью другой LLM. Такая сверка, с одной стороны, дает мощное ускорение работы, а с другой стороны повышает консистентность всей документации.
Документ бизнес-требований берем за основу и проектируем с помощью ИИ минимальный прототип для обкатки UX/UI. О том, как это делается, я недавно рассказывал. Конкретно в этом проекте было сделано 5 разных прототипов, после чего просто выбрали лучший.
Еще один стандартный шаг разработки. Агент получает ранее созданные бизнес-требования (БТ) и прототипы и сам формулирует на их основе функциональные требования (ФТ) к проекту. Т.е. какие функции продукта будут решать ранее озвученные бизнес-задачи.
Получается примерно такой документ, functional_requirements.md (здесь — фрагмент):
Фрагмент документа функциональных требований#### FR-017:
Система должна применять настройки фильтров при загрузке
- Описание: Использование настроенных администратором критериев
- Приоритет: Высокий
- Связано с: [BR-002](business_requirements.md#br-002)
### 6.2. Автоматическая обработка ИИ
#### FR-018:
Система должна автоматически обрабатывать новые тендеры с помощью ИИ
- Описание: Ежеминутная обработка необработанных тендеров (через ИИ)
- Приоритет: Высокий
- Связано с: [BR-004](business_requirements.md#br-004)
#### FR-019:
Система должна генерировать описания тендеров с помощью ИИ
- Описание: Автоматическое заполнение описаний на основе ИИ анализа
- Приоритет: Средний
- Связано с: [BR-004](business_requirements.md#br-004)
#### FR-020:
Система должна автоматически присваивать теги тендерам с помощью ИИ
- Описание: Категоризация тендеров по настроенным правилам ИИ анализа
- Приоритет: Высокий
- Связано с: [BR-003](business_requirements.md#br-003)
## 7. Интерфейс и навигация
Что здесь важно? Каждое ФТ формируется на основе ранее сформулированного БТ и прямо ссылается на соответствующий документ. BR-004, например, — это бизнес-требование к составлению описаний тендеров.
Тем самым, мы ограничиваем агента рамками требований. Каждый следующий документ явно ссылается на предыдущий и строго следует ему. В итоге каждое бизнес-требование получает соответствующие функциональные требования. А функциональные требования, в свою очередь, основываются на БТ. Следовательно, ИИ не сможет выдумать бесполезный функционал или заигнорить то, что реально нужно.
Впрочем, ситуация, когда какое-то БТ оказывается не имеющим функциональной реализации, сигнализирует, что, возможно, соответствующее бизнес-требование не так уж и нужно в продукте. Или, напротив, где-то в прототипе не учли важные элементы. Во всяком случае, это повод архитектору задуматься.
Аналогично, функциональные требования, не основанные ни на чем, сигнализируют о какой-то несогласованности функционала и бизнес-логики. Например, ИИ прилежно создал ФТ для какого-то элемента экрана, но при этом явной и однозначной бизнес-ценности в нем нет. Такое ФТ следует убрать.
Люди это обычно понимают благодаря тому, что они в контексте — в контексте этого проекта, других проектов, собственных знаний и навыков, а также прошлого опыта работы с аналогичными системами. А вот агентам это все нужно объяснять. Для этого и нужны описанные шаги и супервайзинг архитектором.
Аналогичным образом выполняется и этот этап. Результат — документ, описывающий нефункциональные требования к проекту (non_functional_requirements.md).
Фрагмент документа нефункциональных требований## 4. Требования к безопасности
### 4.1. Аутентификация и авторизация
#### NFR-008:
Система должна обеспечивать безопасную аутентификацию
- Описание: Использование современных протоколов аутентификации,
защита от brute-force атак
- Метрика: Соответствие OWASP Top 10
- Приоритет: Высокий
#### NFR-009:
Система должна реализовывать принцип минимальных привилегий
- Описание: Пользователи имеют доступ только к необходимым функциям и
данным
- Метрика: Отсутствие несанкционированного доступа
- Приоритет: Высокий
### 4.2. Защита данных
#### NFR-010:
Система должна защищать конфиденциальные данные
- Описание: Шифрование данных при передаче (HTTPS), безопасное
хранение паролей
- Метрика: Соответствие GDPR и локальным требованиям защиты данных
- Приоритет: Высокий
## 5. Требования к удобству использования
### 5.1. Пользовательский интерфейс
Далее ИИ создает архитектуру будущей системы, выбирает модель данных и стек: фреймворки для frontend и backend, СУБД, агрегатор данных тендеров, ИИ, интеграции. Собственно, в этой части никаких новостей нет, т.к. архитектура 99% IT-систем типовая.
По сути, ИИ с первого раза способен выдать что-то соответствующее сформулированной цели. Ну, процентов на 80. Остальное легко поправить. В случае описываемого проекта, к примеру, мы добавили промежуточный прокси в виде LiteLLM вместо прямого подключения. Просто потому, что мы уже давно работаем с этой системой, она хорошо себя зарекомендовала и управлять всем ИИ-трафиком через нее элементарно удобнее.
Если нужно что-то еще изменить в архитектуре, просто просим LLM это сделать, объясняя зачем это нужно.
Фрагмент документа architecture_overview.md## 5. Взаимодействие компонентов
<...>
graph TD
A[Пользователь] --> B[Frontend App]
B --> C[Supabase Auth]
B --> D[Supabase Database]
E[Scheduler Service] --> F[Tender Aggregator SaaS]
E --> D
E --> G[LiteLLM Proxy]
G --> H[LLM Models<br>Gemini, etc.]
H --> G
G --> E
D --> E
### 5.1. Пользовательские взаимодействия
1. Пользователь входит через фронтенд -> аутентификация через Supabase Auth
2. Фронтенд запрашивает данные -> прямые запросы к Supabase Database
3. Пользователь выполняет действия -> обновления через Supabase
### 5.2. Автоматические процессы
1. Служба планировщика запускается по cron
2. Чтение конфигураций из базы данных
3. Загрузка тендеров с агрегатора
4. Обработка через ИИ и сохранение результатов
## 6. Безопасность
### 6.1. Аутентификация
Далее прорабатывается модель данных, которая предшествует более детальным спецификациям. Она включает доменную модель, где определяются ключевые сущности системы (Тендер, Пользователь, Комментарий) и логические связи между ними. Понимание этих бизнес-сущностей критично для последующего проектирования схемы БД.
Хотя модель данных включает и детальную ERD (Entity-Relationship Diagram), ее разработку целесообразно синхронизировать с проработкой конкретных фич. Преждевременное создание ERD может привести к множеству изменений в схеме при появлении каждой новой фичи, что несколько усложнит процесс и снизит консистентность документации. Впрочем, не скажу, что это прям критичный момент.
Идем дальше.
Прежде чем составлять спецификацию или писать код, агент снова пишет план. Цель уже понятна: формализовать весь процесс разработки и минимизировать ошибки.
Реализация фич подразумевает создание рабочего плана фичи, который итеративно запускает уже описанные выше шаги, но уже в рамках отдельно взятого компонента продукта.
Возьмем, скажем, реализацию фильтра в нашем приложении. Функциональные требования говорят нам, что у фильтра должна быть возможность редактирования. Поэтому нам нужен план реализации этой фичи.
Начало файла filters_edit.md будет таким:
Скрытый текст# План Реализации: Редактирование Интеграционного Фильтра (Filter Edit)
## Обзор
Фича: Редактирование Интеграционного Фильтра (Filter Edit) Slug: filters_edit URL: /filters/:id/edit (Drawer поверх списка /filters)
Доступ: Только admin Аналогия: Реализация идентична Tags Edit (те же UX подходы, архитектура)
Ключевые требования:
1. Форма редактирования фильтра в Drawer
2. Редактируемые поля: Name, Criteria (JSON редактор или textarea)
3. Кнопка "Сохранить" — сохраняет изменения и переходит на /filters/:id
4. Кнопка "Отмена" — закрывает Drawer без сохранения
5. Валидация: Name обязательное, Criteria должен быть валидным JSON
Модель данных IntegrationFilters:
* id (uuid) — PK
* name (text) — название фильтра
* criteria (jsonb) — JSON объект с критериями фильтрации
* last_run_at (timestamp) — дата последнего запуска (только чтение)
* created_at (timestamp)
* updated_at (timestamp)
RLS политики:
* UPDATE: Только администраторы ((SELECT private.is_admin()))
Связанные требования:
* [FR-015]: Администраторы должны иметь возможность настраивать интеграционные фильтры
* [FR-002]: Разграничение доступа по ролям
## Задачи
### [v] Задача 11.1: Разработка Технической Спецификации для Редактирования Интеграционного Фильтра (filters_edit)
1. Изучение контекста:
* docs/shared/business_requirements.md
* docs/shared/functional_requirements.md (FR-015, FR-002)
* docs/shared/non_functional_requirements.md
* docs/shared/architecture_overview.md
* docs/shared/frontend_screens.md (раздел 3.18)
* docs/shared/data_model_details.md (сущность IntegrationFilters)
* docs/tech_specs/filters/list/spec.md (из phase9)
* docs/tech_specs/filters/show/spec.md (из phase10)
* docs/tech_specs/tags/edit/spec.md (как пример)
2. Изучение инструкции: docs/agents.md/spec_writing_quide.md
3. Создание спецификации:
* Создайте файл docs/tech_specs/filters/edit/spec.md.
* Заполните его, чётко следуя инструкции.
* Особенности:
* Форма в Drawer с полями: Name (input), Criteria (textarea для JSON)
И т.д.
Что здесь происходит? План описывает общие требования к фиче, ссылаясь на документы ФТ. Затем пошагово расписывает, что должен сделать агент: изучить весь контекст и инструкции, затем написать спецификацию этой фичи, сценарии, код, тесты и т.д.
Планы, конечно, тоже сохраняются как документы, что позволяет в дальнейшем их вручную или с помощью ИИ корректировать, либо искать источник проблем, если они возникнут.
После каждого этапа выполнения плана, как обычно, следует верификация.
Зная функциональные и нефункциональные требования, архитектуру проекта и экраны, ИИ может писать спецификации на разработку конкретных фич.
Начинает он снова с плана:
Изучить контекст. Т.е. прочитать документы с БТ, ФТ, НФТ, описание архитектуры, изучить модели данных и предыдущие спецификации.
Изучить инструкции по созданию спецификаций.
Написать спецификацию на такую-то фичу.
Верифицировать в отдельной подзадаче (если есть замечания, повторить исправления). Еще раз подчеркну, что верификация проверяет не только качество самой спецификации на фичу, но и согласованность ее с документами более высоких уровней.
Отметить задачу выполненной.
Дальше агент пошагово выполняет собственный план. Результат — спецификация на конкретную функцию продукта (spec.md).
Начало спецификации на разработку одной из фич продукта# Техническая Спецификация: Создание Интеграционного Фильтра (Filter Create Drawer)
## 1. Введение
### 1.1 Цель
Реализация интерфейса и логики для создания новых интеграционных фильтров администратором системы в
выезжающей боковой панели (Drawer). Drawer открывается поверх списка фильтров (/filters), который остается
видимым на фоне. Позволяет задать название и критерии фильтра (JSON) для настройки интеграции с внешними
площадками.
### 1.2 Область применения
Спецификация покрывает требования:
- [FR-015](../../../shared/functional_requirements.md#fr-015): Администраторы должны иметь возможность настраивать интеграционные фильтры.
- [FR-002](../../../shared/functional_requirements.md#fr-002): Разграничение доступа по ролям (только admin).
- [FR-021](../../../shared/functional_requirements.md#fr-021): Сохранение фильтров в URL.
-[FR-025](../../../shared/functional_requirements.md#fr-025): Поддержка стандартной браузерной навигации.
### 1.3 Связанные документы
-[Функциональные требования](../../../shared/functional_requirements.md)
- [Бизнес-требования](../../../shared/business_requirements.md)
- [Нефункциональные требования](../../../shared/non_functional_requirements.md)
- [Экраны интерфейса](../../../shared/frontend_screens.md)
-[Детальная модель данных](../../../shared/data_model_details.md)
-[Спецификация списка фильтров](../list/spec.md)
- [Спецификация просмотра фильтра](../show/spec.md)
- [Спецификация редактирования фильтра](../edit/spec.md)
---
## 2. Технические Требования (TS Items)
Способы открытия Drawer создания:
- Основной способ: клик по кнопке "+" в заголовке списка фильтров ('/filters')
- Альтернативный способ: прямой переход по URL '/filters/create'
Архитектура:
- Drawer рендерится через React Router '<Outlet />' внутри компонента 'FiltersList'
- URL синхронизируется с состоянием Drawer (паттерн nested routes)
- Query-параметры списка (поиск, пагинация, сортировка) сохраняются при навигации ('keepQuery: true' в
'useGo')
---
### TS-FILTER-CREATE-001: Компонент FilterDrawerCreate
Связано с: [FR-015](../../../shared/functional_requirements.md#fr-015),[FR-002](../../../shared/
functional_requirements.md#fr-002),[BR-001](../../../shared/business_requirements.md#br-001)
Назначение: Создание нового интеграционного фильтра в выезжающей боковой панели (Drawer)
И вновь мы видим, что спецификация написана со ссылками на конкретные документы. Т.е. каждая фича вырастает из конкретного функционального требования. А то, в свою очередь, — из бизнес-задач продукта.
Раз за разом возвращая ИИ-агента к реальности формализованных требований, мы не даем ему уйти в галлюцинации и слепить нам Франкенштейна вместо реально требуемого продукта. Более того — процедура верификации проверяет не только правильность самого документа, но и согласованность его с документами выше по иерархии.

Касательно верификации есть еще один важный нюанс, но о нем я скажу в следующем разделе.
Очень важный этап, который призван проверить, действительно ли экраны и фичи, которые мы создаем, отвечают целям и задачам конечного пользователя.
Здесь ИИ описывает, что именно делает пользователь на каждом экране. Шаги, действия, ожидаемый результат. Пользовательские сценарии ИИ пишет, как и раньше, руководствуясь инструкцией по написанию сценариев.
Получается такой документ (user_scenarios.md):
Скрытый текст# Пользовательские Сценарии: Создание Интеграционного Фильтра (Filter Create Drawer)
Связанная спецификация:[spec.md](./spec.md)
---
## 1. Сценарии навигации и открытия Drawer
### US-FILTER-CREATE-01: Открытие формы создания через кнопку "+"
Связано с: [TS-FILTER-CREATE-001](spec.md#ts-filter-create-001), [TS-FILTER-CREATE-002](spec.
md#ts-filter-create-002), [FR-015](../../../shared/functional_requirements.md#fr-015)
Предусловие:
- Актор: Администратор системы (роль admin)
- Состояние системы: Администратор находится на странице списка фильтров (/filters)
Шаги:
1. Администратор нажимает кнопку "+" в заголовке страницы (рядом с текстом "Фильтры").
Ожидаемый результат:
1. URL меняется на /filters/create.
2. Справа открывается Drawer (выезжающая боковая панель) шириной 500px.
3. В заголовке Drawer отображается текст "Создать фильтр".
4. Отображается пустая форма с полями: Название (Input), Критерии (TextArea).
5. Поле "Название" пустое.
6. Поле "Критерии" пустое, отображается placeholder {"key": "value"}.
7. В футере Drawer отображаются кнопки "Создать" и "Отмена".
8. Таблица списка фильтров остаётся видимой на фоне под полупрозрачным overlay.
Как и раньше, вся работа идет по ранее созданным документам: спецификациям, функциональным требованиям, экранам. И, как и раньше, сценарии не существуют в отрыве от спецификаций, а спецификации прямо привязаны к конкретным пользовательским сценариям. Все связано.

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

Одним из шагов выполнения каждого плана является, естественно, реализация всего запланированного в коде.
Думаю, суть я уже донес: агент читает инструкцию, а затем последовательно выполняет ее, генерируя код необходимых модулей, реализующих ту или иную фичу, согласно ее технической спецификации.
Например, вот как выглядит этот раздел в плане работ для вышеупомянутой фичи редактирования фильтра:
Скрытый текст### [v] Задача 11.4: Реализация Редактирования Интеграционного Фильтра (filters_edit) в Коде
1. Изучение контекста:
* docs/agents.md/coding_guide.md (инструкция которой нужно строго следовать)
docs/tech_specs/filters/edit/spec.md (*Задача 11.1**)
docs/tech_specs/filters/edit/user_scenarios.md (*Задача 11.2**)
* docs/shared/business_requirements.md
* docs/shared/functional_requirements.md
* docs/shared/non_functional_requirements.md
* docs/frontend/project_structure.md
* frontend/src/pages/filters/FiltersList/ (код из phase9)
* frontend/src/pages/filters/FilterShow/ (код из phase10)
* frontend/src/pages/tags/TagEdit/ (как пример реализации)
* frontend/src/App.tsx (для добавления роутов)
2. Написание кода:
* Для агента-разработчика: Проанализируйте спецификацию и сценарии. Самостоятельно продумайте детальные шаги реализации (Vertical Slicing). Отредактируйте этот файл плана: Замените этот пункт на конкретные чекбоксы [ ] с этапами реализации.
* Важно: Каждый шаг должен оставлять приложение в рабочем состоянии.
* Оставляйте комментарии // TODO для мест, требующих доработки в будущем.
3. Анализ архитектурных изменений: При необходимости обновите docs/frontend/development.md, tech_stack.md или project_structure.md.
4. [v] Верификация: в отдельной подзадаче / сабагенте Верифицировать согласно инструкции docs/agents.md/verification_guide.md принимая в качестве ФИЧИ Редактирование Интеграционного Фильтра (Filter Edit).
4.1. Если верификация завершена с замечаниями: в отдельной подзадаче / сабагенте исправьте Блокеры и Мажорные замечания; Вернитесь к пункту 4. Повторяйте этот цикл пока верификация не будет пройдена без замечаний.
5. [ ] Code Review: в отдельной подзадаче / сабагенте Провести ревью кода согласно инструкции docs/agents.md/code_review_guide.md.
5.1. Если кодревью завершено с замечаниями: в отдельной подзадаче / сабагенте исправьте Блокеры и Мажорные замечания; Вернитесь к пункту 5. Повторяйте этот цикл пока кодревью не будет пройдено без замечаний.
6. Отметьте задачу выполненной ([ ] -> [v]) в этом файле в заголовке задачи.
Для упрощения дальнейшей поддержки кода его нужно унифицировать и привести к определенному единообразному стилю и форматированию. Поэтому следующий этап — запуск линтера и форматирование.
Кроме того, каждый билд проекта должен (и мы это зафиксировали в требованиях к проекту) оканчиваться стабильной сборкой проекта. А значит нужно проверить на зависимости, уязвимости, и успешное прохождение всех тестов.
Скрытый текст### Файл: docs/frontend/cli_commands.md
# CLI Команды и Скрипты
## 1. Установка и Запуск
### Установка зависимостей
```bash
# Переход в директорию проекта
cd tms-frontend
# Установка зависимостей
npm install
```
### Запуск dev-сервера
```bash
npm run dev
```
Приложение будет доступно по адресу: http://localhost:5173
### Сборка для production
```bash
npm run build # Сборка проекта
npm run start # Предпросмотр сборки
```
Предпросмотр сборки будет доступен по адресу: http://localhost:4173
## 2. Тестирование (E2E - Playwright)
```bash
npm run test # Запуск E2E тестов
npm run test:ui # Запуск с UI интерфейсом
npm run test:headed # Запуск в headed режиме
```
## 3. Качество Кода
### Линтинг, Форматирование и Безопасность
```bash
npm run lint # Проверка линтинга (ESLint)
npm run lint:fix # Автоматическое исправление линтинга
npm run format:check # Проверка форматирования (Prettier)
npm run format # Автоматическое форматирование (Prettier)
npm run audit # Проверка уязвимостей пакетов (npm audit)
```
### Проверка типов
```bash
npm run build # Сборка с проверкой типов (также используется для production сборки)
```
Используя тест-план, спецификации и код, ИИ-агент пишет автотесты и описывает кейсы для ручного тестирования, а затем их выполняет, отмечая в плане успешно пройденные и проваленные тесты. Ручные тесты, конечно, выполняет человек, а не машина.
В итоге получаем продукт. В нашем случае получился ежедневно используемый ИИ-ассистент по работе с тендерами. Но точно так же это может быть и любой другой продукт (например, ваш), потому что методика разработки универсальна.

Вероятно, все вышеописанное выглядит как гигантский overkill. Но практика нашей компании показывает, что такой детализированный подход дает реальные результаты:
Участие человека в работе над проектом становится минимальным и сводится к проектированию архитектуры на бизнесовом уровне и к супервайзингу агентов.
ИИ допускает значительно меньше галлюцинаций за счет того, что крупные задачи поделены на мелкие, а также за счет подробного документирования каждого шага и перекрестной трассировки референсов.
Меньше ошибок в архитектуре и коде за счет двойной верификации и код-ревью.
Изменения, которые ИИ вносит в код, не ломают бизнес-логику, т.к. ИИ всегда перепроверяет себя по бизнес-требованиям.
Стабильные сборки. Проект никогда не оказывается в разобранном или нерабочем состоянии. Изменения в одной части проекта не ломают другие части, поскольку изменения вносятся по планам, каждый шаг дважды верифицируется, а весь проект покрывается автотестами.
ВАЖНО: полностью учитываются бизнес-требования к проекту. Именно здесь достигается максимальная выгода для заказчика.
Более согласованное взаимодействие с заказчиком. По сути, работа в таком воркфлоу позволяет экономить деньги заказчика за счет исключения лишних технических правок и более полного соответствия бизнес-задачам, причем с первого раза.
Нет вендор-лока. Стандартизованный процесс и полностью документированный проект — это огромный плюс для заказчика, т.к. он не будет привязан к разработчику. В теории такой проект можно допилить и вручную, если вдруг у всех облачных LLM завтра «деградирует» оборудование.
Увеличивается скорость разработки.
При этом проект остается полностью под контролем, его можно развивать, менять, масштабировать. Даже передать другой команде! Потому что все шаги разработки стандартные, а проект документирован.
Сейчас мы активно внедряем описанную методику в работу над проектами. И это уже дает реальную экономию клиентам. Свои внутренние проекты мы делаем так же, скоро расскажу про ИИ-ассистента для планирования отпусков и больничных в компании. Код руками почти не пишем. Чистое «программирование на английском». Ну или на русском, как в нашем случае.
Минусов не вижу, но есть особенности.
Особенности описанного подхода отчасти заключаются в самой идее использования ИИ так же, как мы используем человека: его нужно менеджерить, давать ему инструкции, вести за руку по проекту.
По этой причине подход требует довольно существенной перестройки всех внутренних процессов разработки. Просто сказать «А давайте использовать ИИ» не получится. Возможно, поэтому в сети так много негативных примеров внедрения ИИ в разработку.
Другие важные особенности:
Главный разработчик (вайбкодер) должен очень хорошо представлять себе всю архитектуру проекта и бизнес-требования к нему. Да, формально бизнес-требования пишет ИИ. Однако, если разработчик, грубо говоря, «не шарит», то отделить зерна от плевел на этом этапе он не сможет. В результате чего ИИ, руководствуясь этими оторванными от реальности требованиями, безошибочно и четко реализует совершенно не тот проект, который действительно нужен.

На мой взгляд, это ключевое отличие современной разработки от разработки доИИ-шной эпохи. Специалист сегодня обязан разбираться в бизнес-процессах и архитектурных нюансах. Понимать, как второе зависит от первого, по каким критериям выбирается стек в зависимости от задачи. Видеть, где ИИ может сделать формально правильно, но с позиции бизнеса — недальновидно. Ну и т.д.
При этом компетенции в разработке у такого специалиста нужны сеньорного уровня, что несколько расходится с общепринятым представлением о вайбкодинге как об инструменте для новичков. Но только так можно обеспечить высокое качество и надежность продукта. У нас в Siberian.pro в роли архитекторов выступают именно senior-разработчики.
Токеномика важна. Под каждую задачу и каждый этап нужно выбирать правильную модель, исходя из ее возможностей, размера контекстного окна, скорости работы и стоимости токена. Активное управление выбором моделей оптимизирует стоимость разработки для клиента, позволяя ему получить больше за те же деньги. И наоборот: выбор Claude Opus 4.7 там, где достаточно Gemini Flash, просто уничтожит бюджет заказчика.
Ключевую роль играют инструкции для ИИ. В нашей компании эти документы исторически рождались в рамках работы над совершенно разными проектами и задачами, но в итоге переродились в своего рода корпоративный стандарт, который переиспользуется в разных проектах.
На сегодня все, спасибо, что дочитали. О буднях CEO компании по разработке и интеграции ИИ-решений я пишу у себя в Telegram. Там же можно прочитать про мой личный опыт использования ИИ или задать мне вопросы по описанной выше методике. Приходите.