- Серия voir-pages
- стр. 12 / 26
- отдел 2 из 8
- реализовано 0 этапов
AI-разработка — это не «модель пишет код». Это конвейер из шести этапов, где независимый гейт важнее скорости, а откат — не авария.
Отдел разработки в VOIR AI превращает задачу в работающий код по записанному маршруту: спецификация, генерация кода, тесты, независимая приёмка, деплой, мониторинг. Ключевое слово — «записанному»: каждый этап оставляет артефакт, который можно проверить, а не пересказ. Гейт приёмки выполняет роль, которая работу не писала, — иначе проверка вырождается в самоотчёт. Если тесты падают, задача возвращается назад, а не доезжает до прода «под честное слово». Ниже — честная картина: что отдел должен делать по целевой архитектуре, что уже работает у нас внутри как собственный инструмент (этот сайт сделан именно так), и как отдел встроен в цикл AI CEO.
Продукт VOIR AI · реализовано ноль этапов Экосистема Marisova · агенты пишут код, харнесс проверяет
Демонстрация · конвейер разработки
Одна задача, шесть этапов, два исхода
Конвейер, в котором задача всегда доходит до деплоя, выглядит идеально и врёт. Реальная схема включает второй исход: тесты или гейт находят дефект, и задача возвращается на этап кода с описанием проблемы — прод при этом не тронут. Переключите сценарий, чтобы увидеть оба маршрута. Демонстрация проигрывает заранее записанный сценарий и не подключена к живому AI-сервису; этапы описаны текстом в разделе «Шесть этапов».
Структурные числа страницы: 6 этапов конвейера, 2 сценария демонстрации, 8 отделов в архитектуре, 0 реализованных этапов в продукте.
Конвейер · задача → код → тесты → гейт → деплой → мониторинг
Демонстрация · подготовленный сценарийШесть этапов Целевая архитектура
Каждый этап оставляет артефакт, который можно проверить
«AI пишет код» — это не процесс, а событие. Процесс начинается там, где у каждого шага есть вход, выход и записанный артефакт: спецификация, коммит, отчёт харнесса, вердикт гейта, журнал деплоя, отчёт мониторинга. Артефакты нужны не для бюрократии: по ним независимая приёмка сверяет заявленное с фактическим, а владелец видит, где именно остановилась задача. Все шесть этапов ниже — целевая архитектура продукта; как они устроены, мы знаем по собственной практике разработки этого сайта.
-
SPEC
Спецификация задачи
Целевая архитектураЗадача от AI CEO переводится в спецификацию: какие файлы затрагиваем, какие критерии приёмки, какие границы нельзя пересекать. Без этого этапа «сделай красиво» превращается в лотерею: исполнитель и заказчик расходятся уже на формулировке результата. Артефакт — записанная спецификация, по которой позже можно однозначно сказать, выполнена задача или нет.
Артефакт: спецификация · вход: задача AI CEO · выход: критерии закрытия
-
CODE
Генерация кода
Целевая архитектура работает в экосистемеМодель пишет код строго по спецификации: структура, стили, логика, правки существующих файлов — аддитивно, ничего не удаляя без явной задачи. Каждое изменение фиксируется как коммит с человекомочитаемым сообщением, чтобы diff можно было прочитать без запуска кода. Генерация «одним большим файлом без истории» в архитектуре запрещена: непроверяемое изменение — это не работа, а риск.
Артефакт: коммит + diff · вход: спецификация · выход: кандидатура на тесты
-
TEST
Тесты и проверки
Целевая архитектура работает в экосистемеАвтоматический харнесс проверяет то, что проверяется машиной: ссылки не ведут в никуда, якоря существуют, языковые пары ru/en на месте, SEO-минимум соблюдён, скриншоты на трёх ширинах не показывают вылезший текст. Отдельный принцип — негативный контроль: проверке подсовывают заведомо сломанный вариант, чтобы убедиться, что она вообще умеет краснеть. Зелёный отчёт без негативного контроля ничего не стоит.
Артефакт: отчёт харнесса + скриншоты · вход: коммит · выход: кандидат на гейт
-
GATE
Независимая приёмка
Целевая архитектура работает в экосистемеКлючевой этап конвейера: роль, которая работу не писала, сверяет заявленное с фактическим — по диску, git-истории и живым URL, а не по отчёту исполнителя. Вердикт бинарный: VERIFIED или возврат на CODE с описанием дефекта. Исполнитель не проверяет сам себя — это принципиально: самопроверка всегда находит способ быть зелёной. Именно гейт отличает конвейер от конвейерной имитации.
Артефакт: вердикт приёмки · вход: отчёт харнесса · выход: допуск к деплою или откат
-
DEPLOY
Деплой
Целевая архитектура работает в экосистемеПубликация только после гейта и только аддитивно: бэкап целевой директории, выкладка новых файлов, соседние страницы не трогаются, конфигурация сервера не меняется. После выкладки — обязательная проверка: новые URL отвечают 200, старые продолжают отвечать 200. Деплой, после которого не проверили живые адреса, считается незавершённым, даже если «файлы скопировались».
Артефакт: журнал деплоя + curl-коды · вход: вердикт VERIFIED · выход: живой URL
-
WATCH
Мониторинг после деплоя
Целевая архитектура работает в экосистемеРабота не заканчивается публикацией: пробы по расписанию следят, что живые страницы отвечают, а содержимое не деградировало. Мониторинг «когда кто-то заметил» — это не мониторинг, а надежда. Финал этапа — отчёт владельцу: что сделано, что отклонено гейтом, что сломалось после, какие выводы ушли в следующую спецификацию. Здесь петля замыкается на следующий прогон цикла.
Артефакт: отчёт владельцу · вход: живой URL · выход: петля следующего прогона
Гейт приёмки · как он читает работу
Гейт смотрит не на отчёт исполнителя, а на diff
Отчёт исполнителя — это заявление. Гейт работает с доказательствами: что фактически изменилось на диске, что показывает git, что отвечают живые адреса. Ниже — тот самый diff, который гейт хотел бы видеть вместо красивых обещаний: слева зачёркнуто то, как задачи закрываются без приёмки, справа — как это выглядит в нашей практике.
Правило независимости
Приёмку выполняет роль, которая не писала работу и не заинтересована в её зелёном свете. Тот же агент, который написал код, находит в нём ровно столько проблем, сколько готов признать.
Правило доказательств
Гейт принимает только проверяемое: состояние диска, git-история, HTTP-коды живых адресов, скриншоты. Пересказ «всё работает» доказательством не считается и к деплою не допускает.
Правило отката
Провал гейта — нормальный исход, а не авария: задача возвращается на CODE с описанием дефекта, прод не тронут. Конвейер, который никогда ничего не отклоняет, либо не проверяет, либо врёт.
Правило негативного контроля
Периодически проверке подсовывают заведомо сломанный вариант. Если гейт пропустил и его — значит, проверка не работает, и её зелёные отчёты нужно читать как пустые.
Деплой и мониторинг Целевая архитектура
Публикация — это середина, а не конец работы
Деплой в архитектуре устроен как операция с гарантиями, а не как копирование файлов: сначала бэкап того, что трогаем, затем аддитивная выкладка — только новые и изменённые файлы, без удалений на сервере, затем проверка. Проверяются не только новые адреса: соседние страницы обязаны продолжать отвечать, иначе «выкатили фичу» на деле означает «сломали чужое». Конфигурацию сервера деплой не трогает вообще — это отдельная зона ответственности человека.
Бэкап до выкладки
Каталог назначения копируется до изменений, чтобы любой деплой был обратим. Правило простое: нет бэкапа — нет деплоя. «Изменения маленькие» исключением не является.
Аддитивность
Выкладка только добавляет и обновляет свои файлы. Живые страницы, чужие каталоги и конфигурация сервера не затрагиваются: чужая работа на общем сервере не наша собственность.
Проверка живых URL
После выкладки — HTTP-коды: новые страницы отвечают 200, ключевые соседние страницы отвечают 200. Файл «скопировался» и страница «работает» — два разных факта.
Пробы по расписанию
Мониторинг запускается планировщиком, а не вниманием человека: регулярные проверки живых страниц, журнал срабатываний, эскалация владельцу при деградации. Подробности — в отделе AI-операций.
Статусы
Два столбца статуса: чертеж и наш собственный цех
Отдел разработки — особенный случай: его этапы мы ежедневно выполняем собственными инструментами, делая этот сайт. Именно поэтому таблица разделена на два столбца. Левый — что реализовано в продукте VOIR AI (сейчас ни одного этапа конвейера). Правый — что уже работает у нас внутри экосистемы Marisova. Правый столбец нельзя читать как обещание клиенту: наши внутренние инструменты не продаются и не предоставляются — они лишь доказывают, что архитектура не выдумана, а опробована на себе.
| Функция | В продукте VOIR AI | В экосистеме Marisova (внутреннее) |
|---|---|---|
| Спецификация задачи (SPEC) | не реализовано Целевая архитектура: задача → записанные критерии закрытия |
работает Каждая задача на разработку страниц этого сайта приходит файлом с требованиями, границами и критериями закрытия. Внутренний инструмент, не продукт |
| Генерация кода (CODE) | не реализовано Целевая архитектура: генерация по спецификации с журналом |
работает Код этого сайта пишет AI-агент в сессии разработки; каждое изменение — коммит с сообщением в git. Так сделаны все опубликованные страницы ai.voir.su |
| Автоматические проверки (TEST) | не реализовано Целевая архитектура: единый харнесс продукта |
работает Локальный харнесс проверяет ссылки, якоря, языковые пары, SEO-минимум; Playwright делает скриншоты 1280/768/375; есть практика негативного контроля |
| Независимая приёмка (GATE) | не реализовано Целевая архитектура: вердикт роли, не выполнявшей работу |
работает Практика приёмки существует: заявленное сверяется по диску, git и живым URL отдельной проверкой, а не по отчёту исполнителя. Продуктом не является |
| Деплой (DEPLOY) | не реализовано Целевая архитектура: публикация как часть продукта |
работает Скрипт деплоя этого сайта: бэкап docroot, аддитивный rsync, после выкладки — проверка HTTP-кодов новых и соседних страниц. nginx-конфиг не трогается |
| Мониторинг (WATCH) | не реализовано Целевая архитектура: пробы, пороги, записанная реакция |
работает Планировщик запускает пробы живых страниц по расписанию; для этого сайта после каждой публикации проверяются живые URL. Наши собственные инструменты |
| Интерактивная демонстрация конвейера на этой странице | Демонстрация Записанный сценарий в браузерном скрипте |
не живой сервис Не подключена к AI-сервису, ничего не исполняет и не собирает; оба сценария написаны заранее |
| Конвейер как услуга клиенту | не реализовано Целевая архитектура: клиент запускает свой конвейер разработки |
не существует Клиентов нет, продукт не запущен; внутренние инструменты экосистемы клиенту не передаются |
Связь с AI CEO
Отдел разработки — исполнитель в цикле AI CEO
Конвейер разработки не живёт сам по себе: он встроен в цикл AI CEO — постановка задачи, анализ и распределение, исполнение, независимая приёмка, отчёт. Разработка — это этап исполнения: она получает спецификацию от CEO-контура и возвращает ему вердикт гейта и отчёт о прогоне. Ниже — пять шагов цикла и роль отдела разработки на каждом.
-
шаг 1
Постановка задачи
Владелец формулирует задачу AI CEO; тот превращает её в поручение отделу с границами и критериями.
Разработка получает: проект спецификации (SPEC) -
шаг 2
Анализ и распределение
CEO-контур решает, какая задача — разработка, и назначает её отделу, а не маркетингу или кадрам.
Разработка получает: назначенную задачу с приоритетом -
шаг 3 · здесь работает отдел
Исполнение
Наш конвейер: SPEC → CODE → TEST. Каждый этап оставляет артефакт; провал тестов возвращает задачу на CODE, а не наверх.
Разработка отдаёт: коммит, diff, отчёт харнесса -
шаг 4
Независимая приёмка
Роль приёмки сверяет заявленное с диском, git и живыми URL. Наш GATE — техническая часть этой приёмки, вердикт уходит в CEO-контур.
Разработка отдаёт: вердикт VERIFIED / REJECTED -
шаг 5
Отчёт владельцу
CEO-контур сводит прогон в отчёт; выводы разработки (что отклонено, что сломалось) уходят в следующую спецификацию.
Разработка получает: задачи следующего прогона
Точки взаимодействия с другими отделами: AI-операции дают регламенты и мониторную шину для WATCH, AI-исследования — данные для спецификаций, AI CEO — постановку и распределение задач. Как роли устроены внутри — на странице AI-агентов.
Границы
Что эта страница НЕ утверждает
Честность — требование владельца проекта, а не маркетинговый ход. Фиксируем границы явно, чтобы их нельзя было прочитать двояко.
- Продукта не существует. В коде VOIR AI не реализован ни один из шести этапов конвейера. Всё описание выше — целевая архитектура: чертеж, по которому мы строим.
- Клиентов и внедрений нет. На странице нет кейсов, потому что нет кейсов. Мы не придумываем компании, метрики и отзывы.
- Демонстрация записана заранее. Конвейер в разделе выше проигрывает подготовленный сценарий в браузере и не подключён к живому AI-сервису: он ничего не исполняет, не деплоит и не собирает.
- Внутренние инструменты ≠ продукт. Правый столбец таблицы статусов описывает наши собственные наработки экосистемы Marisova. Они не продаются, не передаются клиенту и не превращаются в возможности продукта автоматически.
- Неработающих кнопок нет. Все интерактивные элементы страницы — переключатели сценариев демонстрации, якоря и ссылки на реальные страницы. Форм сбора данных на странице нет.
Вопросы и ответы
Частые вопросы об отделе разработки
Отдел разработки VOIR AI уже работает?
Как продукт VOIR AI — нет. Все шесть этапов конвейера на этой странице описывают целевую архитектуру: в коде продукта не реализован ни один. Демонстрация проигрывает заранее подготовленный сценарий и не подключена к живому AI-сервису. Отдельно существует экосистема Marisova, где генерация кода агентом, QA-харнесс, независимая приёмка и деплой-скрипты используются нами для разработки этого сайта. Продуктом VOIR AI они не являются и клиентам не предоставляются.
Кто пишет код — модель или человек?
В нашей собственной практике код генерирует AI-агент в сессии разработки, а человек-владелец задаёт задачу, границы и принимает результат. Именно поэтому в конвейере есть отдельный гейт независимой приёмки: исполнитель не проверяет сам себя, заявленное сверяется с диском, git-историей и живыми URL.
Что происходит, когда тесты падают?
Задача не доезжает до деплоя: гейт возвращает её на станцию кода вместе с описанием дефекта, прод при этом не тронут. Этот сценарий показан в демонстрации вторым переключаемым вариантом — «откат на гейте». Деплой брака с последующим извинением в архитектуре не предусмотрен.
Мониторинг после деплоя — это живой сервис?
В продукте VOIR AI — нет, это целевая архитектура. В экосистеме Marisova у нас работают планировщик с пробами по расписанию и E2E-аудит живого сайта; для этого сайта проверка после публикации — HTTP-коды соседних страниц и скриншоты трёх ширин. Это наши внутренние инструменты, клиенту они не передаются.
Можно купить этот отдел разработки сегодня?
Нет. Продукт VOIR AI находится в разработке, клиентов нет. Страница описывает архитектуру, к которой мы идём, и честно разделяет: что спроектировано, что уже работает как наш внутренний инструмент и что не существует ни в каком виде. Тарифы на странице цен — это план запуска, а не действующее предложение.
Чем отдел разработки отличается от AI-операций?
Операции держат повторяющиеся процессы компании (регламент → план → исполнение → контроль → отчёт), а разработка превращает задачу в новый работающий код (спецификация → код → тесты → гейт → деплой → мониторинг). В целевой архитектуре это разные конвейеры с разными артефактами; общий у них принцип независимого контроля. Подробности — на странице AI-операций.
Следить за строительством — честно
Продукт VOIR AI в разработке, клиентов нет. Мы не собираем заявки «в лист ожидания» через эту страницу: напишите нам напрямую, и мы расскажем, на каком этапе конвейер находится сейчас. Архитектуру системы в целом смотрите на странице AI Operating System, состав отделов — на главной, планы запуска — на странице тарифов.