Операция выполнена!
Закрыть
Хабы: Блог компании Axenix (ex-Accenture), Подготовка технической документации

Меня зовут Антон Богун, я старший разработчик ПО в Axenix. В прошлой статье мы говорили о Doc as Code как об инженерной практике: документация живет в Git, проходит review, проверяется автоматически и становится частью процесса разработки. Это важная база, но сегодня у нее появляется следующий уровень применения.

Разработчик подключает ИИ-агента уже не к абстрактной документации, а к собственному проекту: к кодовой базе, OpenAPI спецификациям, Markdown страницам, release notes, задачам в трекере и интеграционным схемам. От агента ждут не пересказа документации, а понимания текущего поведения системы.

Именно здесь возникает новая проблема. Метод API может называться так же, путь может остаться прежним, request body может почти не измениться, но поведение системы уже стало другим. Например, заказ больше не создается сразу в финальном статусе, часть заказов уходит на дополнительную проверку, после создания публикуется событие, а обработка продолжается в другом сервисе через брокер сообщений.

Для человека такие изменения часто понятны из задачи, pull request, обсуждения или кода. Для ИИ-агента это неочевидно, если код, спецификация, документация и задачи не связаны между собой.

Doc as Code отвечает на вопрос: как хранить и проверять документацию. Но для ИИ-агента важнее следующий вопрос: как понять, что изменилось в поведении системы и где это отражено.

ИИ-агенту нужен контекст проекта, а не просто набор файлов

Когда мы говорим «дадим ИИ-документацию», часто подразумевается, что достаточно открыть агенту доступ к репозиторию, где лежат openapi.yaml, README и несколько Markdown страниц. Но в реальном проекте этого мало.

Читать далее
Читайте также
НОВОСТИ

ПИШИТЕ

Техническая поддержка проекта ВсеТут

info@vsetut.pro