Человек ставит задачу
Формулирует цель, принимает требования и назначает ответственного.
Архитектура CodeGraph
CodeGraph ведёт проект от продуктовой задачи до выпуска: хранит требования, распределяет работу между людьми и ИИ, проверяет изменения и собирает результаты перед релизом.
ЗадачаЦель и критерии
РаботаИсполнитель и результат
ПроверкиТесты, ревью и риски
ВыпускОтветственный и решение
Архитектурный принцип
CodeGraph хранит связи между проектом, требованиями, изменениями, проверками, рисками и решениями. Git, трекер и CI/CD остаются источниками исходных данных.
Люди задают цель, утверждают требования, принимают риски и решают вопрос выпуска. ИИ выполняет повторяемые действия с заданными правами и условиями остановки.
Разработке часто мешает разрыв между этими записями. Требование обсуждали в одном месте, код изменили в другом, тесты запускали на отдельной ревизии. Перед выпуском команда заново выясняет, что проверено и кто готов принять оставшийся риск. Когда код готовят ИИ-агенты, количество изменений может расти быстрее, чем способность команды их проверять.
CodeGraph связывает результат с его основанием: задачей, версией требования, изменением, проверкой и ответственным решением. Это позволяет вернуться к конкретной проверке и увидеть недостающие данные. Смысл платформы в том, чтобы сделать работу и её приёмку понятными при передаче между людьми, агентами и инструментами.
Контекст системы
CPO, CTO и команда принимают решения. CodeGraph связывает их с Git, трекером, CI/CD, документами, ИИ-моделями и анализаторами.
Команда может начать с одной задачи в существующем репозитории. Git хранит код, CI — результаты запусков, а трекер — задачи. CodeGraph связывает эти записи с требованиями и результатами ролевой работы. При подключении проекта команда выбирает источники данных, права доступа и необходимые проверки.
Поток данных
Каждый этап сохраняет версию, результат и ответственного: задача → требование → изменение → тест → риск → решение.
Каждый результат проверки связан с конкретной ревизией. Руководитель видит, какие требования проверены для текущего изменения, какие проверки ожидают запуска и какие результаты нужно обновить. Из этой информации складывается готовность выпуска: команда может открыть основание статуса и назначить следующий шаг.
Как проходит проект
Сначала команда определяет ожидаемое поведение и критерии приёмки. Затем назначает ограниченную работу и необходимые проверки. Так разработчик получает понятную задачу, а проверяющие — вопросы, на которые должны ответить. Для небольшого сервисного изменения достаточно соответствующей задачи; полный продуктовый процесс нужен там, где меняется продуктовый контракт.
| Этап | Действие | Результат |
|---|---|---|
| Продуктовая задача | Зафиксировать цель, пользователя и ожидаемый результат | Согласованная задача |
| Требования | Описать поведение, ограничения и критерии приёмки | Версия требований |
| План | Определить работы, зависимости и затронутые системы | План работ |
| Выполнение | Изменить код и подготовить тесты | Изменение и связанные тесты |
| Проверки | Провести тесты, ревью, архитектурную и AppSec-проверки | Результаты и открытые риски |
| Выпуск | Рассмотреть результаты и риски | Решение ответственного |
Какие данные хранит платформа
| Объект | Состав | Основные пользователи |
|---|---|---|
| Проект | Цель, срок, ответственный, зависимости и обязательства | CPO и руководитель проекта |
| Задача | Исполнитель, разрешённые действия, результат и критерии приёмки | Менеджер продукта и команда |
| Требование | Версия, ожидаемое поведение и ограничения | Менеджер продукта и CTO |
| Изменение | Запрос на слияние, затронутые функции и сервисы | Разработчик и архитектор |
| Тест | Сценарий, версия запуска и результат | QA и ответственный за требование |
| Риск | Последствие, срок, ответственный и решение | Архитектор, CISO и CPO |
| Решение | Автор, дата, выбранное действие и комментарий | Ответственный за соответствующий этап |
Как работают люди и ИИ
ИИ выполняет отдельный шаг
Разбирает документы, ищет связи, готовит изменение или собирает результаты.
Проверку выполняет другая роль
Ревью, AppSec и QA дают заключения по своему предмету проверки.
Условия следующего шага
Перед запуском проверяются входные данные, права и результаты обязательных проверок.
Для цифровой роли задаются владелец, права, входные данные, результат и условия остановки.
У каждой роли свой вопрос. Разработчик готовит изменение, архитектор исследует границы и зависимости, AppSec проверяет риски безопасности, QA подтверждает поведение. Каждое заключение имеет автора, результат и ссылку на проверенную ревизию. Сводный отчёт собирает эти заключения для решения о следующем шаге.
Совместимый агент, например Codex, выполняет действия этих процессов. Принятая передача задачи подтверждает ответственность следующей роли. Запуск автоматического исполнителя, результат работы и формальная приёмка — отдельные состояния, которые проверяются по своей версии и доказательствам.
Что показывает граф свойств кода
При проверке изменения инженер исследует вызовы, зависимости и передачу данных между частями программы. Граф свойств кода, или CPG, связывает элементы программы и отношения между ними. На этом контексте работают анализ влияния, структурный поиск и проверки безопасности.
| Входные данные | Что получает команда | Что проверяет инженер |
|---|---|---|
| Требование и версия репозитория | Затронутые функции, сервисы и зависимости | Динамические вызовы и конфигурационные связи |
| Изменение кода | Затронутые функции и зависимости | Соответствие ожидаемому поведению |
| Правило безопасности | Пути данных, точки входа и найденные нарушения | Допустимость исключения и остаточного риска |
Связь изменения с проверками помогает найти связанные тесты и сопоставить результат с ревизией кода.
Граф свойств кода показывает структуру и возможные последствия изменения. Решение принимает ответственный сотрудник.
Например, команда исследует, может ли значение из HTTP-запроса повлиять на SQL-запрос. Система гипотез задаёт проверяемое предположение, выполняет запросы по графу и фиксирует результат. Инженер проверяет найденные места, условия выполнения и возможность эксплуатации. По результату он выбирает следующий шаг: проверить найденный путь данных или собрать сведения для дальнейшего анализа.
Результат анализа содержит область проверки, ревизию кода и найденные связи. По ним инженер переходит от изменения к вызывающим функциям, зависимостям и затронутым участкам программы. Команда выбирает проверки для языка и задачи проекта, а для критичных путей добавляет тесты поведения. Так граф помогает определить, что проверить и где искать причину.
Компоненты платформы
Проекты и требования
Хранят цели, сроки, требования, зависимости и решения.
Выполнение задач
Передаёт работу людям и ИИ с указанными правами и результатом.
Граф кода
Связывает элементы программы, вызовы и потоки данных.
Интеграции
Получают данные из Git, трекера, CI/CD и документов.
Хранилища и аудит
Сохраняют результаты проверок, версии источников, права и журнал действий.
Где находятся основные записи
| Источник | Основная запись | Что хранит CodeGraph |
|---|---|---|
| Git | Код и история изменений | Ссылку на версию и затронутые элементы |
| Трекер | Задача, срок и исполнитель | Идентификатор и связь с требованием |
| CI/CD | Запуск и результат теста | Ссылку, время и состояние проверки |
| Документы | Требования и решения | Версию и источник |
| CodeGraph | Связи и журнал анализа | Связи объектов, открытые риски и журнал решений |
Один проект от требования до решения
Ограничить административные действия
Тестовые данныеТребование: роль администратора проверяется до изменения лимита.
Изменение: PR-842 затронул маршрутизатор и сервис политик.
Тест: AC-14 — 18 из 18 сценариев пройдены.
Риск: у общей библиотеки аудита нет назначенного владельца.
Решение: архитектор принимает риск или блокирует выпуск.Тестовые данные показывают формат связи требования, изменения, теста, риска и решения.
Руководитель видит пройденные сценарии и вопрос, который требует решения: кто отвечает за общую библиотеку аудита. Архитектор открывает затронутые зависимости, назначает владельца или оформляет принятие риска. QA возвращается к результатам сценариев для проверяемой ревизии. После этих действий команда собирает результаты обязательных проверок и принимает решение о выпуске. Все участники работают с одной цепочкой записей, сохраняя ответственность за свой этап.
Что проверить на пилоте
Выберите понятную проблему: долго собирать основания для ревью, сложно оценить влияние изменения или теряется контекст при передаче задачи агенту. Зафиксируйте исходное состояние и критерий полезности. Сравните время разбора задачи, подготовки изменения и проверки результата до и после внедрения.
- Пилот проводится для одного проекта с заранее согласованными показателями.
- До запуска фиксируются затраты времени, сроки, переделки и дефекты.
- Качество результата проверяется по тем же правилам до и после внедрения.
- Решение о расширении принимается после сравнения результатов.
Сверить архитектуру
На встрече сверим этапы проекта, основные данные, компоненты платформы и правила доступа.
Обновлено: 16 октября 2026