Как я писал диплом с агентом

В этом году я писал выпускную квалификационную работу о buildout — CLI и MCP-сервере для работы с документацией в buildin.ai. Сам проект был разработан с помощью Claude Code и Spec Kit. Для написания пояснительной записки я собрал отдельный репозиторий thesis-writing-agent.

Это не история о том, как агент написал диплом за меня. Он не выбирал тему, стек или архитектуру, не формулировал требования и не проверял, действительно ли реализованный результат соответствует замыслу. Его задача была другой: превратить уже выполненную инженерную работу, исходные документы и требования университета в связный, проверяемый и нормально оформленный текст.

В результате получился DOCX, который я распечатал, а затем успешно защитил работу. Но путь к этому результату был скорее инженерным экспериментом, чем одним удачным промптом.

С чего всё начиналось

К моменту создания агента у меня уже были:

  • черновик первой главы;
  • отчёты по учебной и эксплуатационной практике;
  • методические указания университета;
  • исходный код проекта, который был темой диплома.

Отчёты по практике до этого были подготовлены с помощью Claude Cowork, а сам проект разрабатывался в Claude Code с использованием Spec Kit. То есть новый агент начинал не с пустого листа, но и не с аккуратно подготовленной базы знаний. Исходные материалы были в разных форматах и имели разное качество: DOCX, XLS, уже написанный текст, методические документы и исходный код.

Первый этап был поэтому не написанием глав, а упаковкой контекста.

Где работал агент

Claude Code работал не на ноутбуке, а на VPS с Ubuntu. Это было важно по двум причинам. Во-первых, агент мог продолжать работу после закрытия крышки ноутбука и ночью, пока я сплю. Во-вторых, длинные задачи эффективнее использовали мою подписку Claude: не нужно было держать локальную машину включённой и ждать завершения очередного прохода.

К VPS я подключался обычным SSH. Для более быстрых проверок использовал Claude Code Remote — это позволяло взаимодействовать с агентом с телефона, когда под рукой не было ноутбука. Получалась практичная схема: тяжёлые задачи агент выполняет в фоне, а я подключаюсь, когда нужно посмотреть результат, оставить замечания или запустить следующий шаг.

При этом постоянная доступность агента не означала, что он мог без ограничений менять финальный текст. Ограничения задавались структурой репозитория и правилом ручного утверждения, а не тем, открыт ли сейчас ноутбук.

Почему Claude Code

Изначально я рассматривал несколько вариантов. Можно было взять OpenClaw или Hermes, а можно было собрать собственного агента на LangChain. Вариант с LangChain давал бы полный контроль над архитектурой, но требовал бы сначала разработать саму агентскую систему: цикл выполнения, работу с инструментами, память, обработку ошибок и интерфейс. На это не было времени: мне нужно было писать диплом, а не разрабатывать платформу для его написания.

OpenClaw и Hermes тоже не подошли. По своей идее это непрерывно работающие системы, рассчитанные на постоянное присутствие и взаимодействие через Telegram, Slack и похожие каналы. Моя задача была другой.

Работа над дипломом в основном имела пошаговый, или turn-based, характер: агент готовил очередной раздел, записывал результат, сохранял контекст в memory/, CHANGELOG.md и журнале принятых решений, а затем переходил к следующему шагу. Не требовалось, чтобы он постоянно находился в диалоге и сам решал, чем заняться через час.

От агента мне были нужны более приземлённые возможности:

  • надёжно работать с файлами в репозитории;
  • загружать и применять skills;
  • читать инструкции проекта и соблюдать заданную структуру;
  • выполнять команды и работать с исходным кодом;
  • переносить контекст между сессиями через файлы памяти.

С этим Claude Code справлялся достаточно хорошо. Он уже давал среду выполнения, инструменты и модель взаимодействия с репозиторием, поэтому мне оставалось спроектировать предметную часть: skills для диплома, формат памяти, правила ревью и конвейер сборки.

Здесь есть более общий вывод. Перед тем как разрабатывать собственного агента или целую платформу, полезно проверить идею на готовом инструменте вроде Claude Code. Такой proof of concept позволяет понять, действительно ли нужны непрерывная автономная система, отдельный интерфейс и собственный runtime, или задача хорошо раскладывается на последовательность шагов внутри репозитория.

Репозиторий как операционная система агента

Репозиторий thesis-writing-agent — это не набор общих инструкций вроде «напиши хорошую главу». Он задаёт структуру проекта, роли отдельных skills, правила работы с памятью и границу между черновиком и утверждённым текстом.

Упрощённо рабочая директория выглядит так:

CLAUDE.md
REQUIREMENTS.md
outline/OUTLINE.md
references/
memory/
style/STYLE_GUIDE.md
drafts/
chapters/
converter/
addons/software-thesis/

CLAUDE.md — операционная инструкция. В ней описано, что агент должен делать при старте сессии, какие skills использовать и в каком порядке выполнять работу.

Skills разделяют процесс на роли:

  • thesis-planner поддерживает структуру работы;
  • thesis-researcher ищет и фиксирует источники;
  • thesis-writer пишет текст в drafts/;
  • thesis-reviewer ищет проблемы и записывает результаты ревью;
  • thesis-editor приводит текст к финальному виду;
  • thesis-code-analyst анализирует исходный код проекта для технических глав.

Отдельно есть skills для перенумерации ссылок и очеловечивания текста.

Такое разделение нужно не ради красивой архитектуры. Оно ограничивает ответственность каждого шага. Например, writer не должен самостоятельно переносить текст в финальную директорию, а навык ревью не должен молча исправлять исходный черновик вместо того, чтобы оставить замечания.

Как документы превращались в базу знаний

Исходные документы агент обрабатывал самостоятельно. Я не конвертировал DOCX и XLS в текст вручную перед началом работы.

Результат обработки складывался в references/. Там остались оригинальные файлы, но рядом с ними появились машинно подготовленные сводки:

references/
  summary-guidelines.md
  summary-practice-main.md
  summary-practice-exploitation.md
  summary-life-safety-guidelines.md
  summary-economy-guidelines.md
  BIBLIOGRAPHY.md

Это важное отличие от обычного чата с моделью. В чате контекст постепенно теряется или начинает занимать всё доступное окно. В репозитории он становится артефактом: его можно прочитать, проверить, поправить и использовать в следующей сессии.

BIBLIOGRAPHY.md стал единым реестром источников с аннотациями и указанием, в каких разделах они используются. memory/ хранил текущий статус, решения, заметки по ревью и обнаруженные противоречия в методических материалах.

Например, при подготовке раздела по безопасности агент обнаружил, что разные части одного набора материалов приводят несовместимые выводы о периодичности контроля концентрации NO₂. Это не должно исчезать внутри сгенерированного абзаца. Противоречие было вынесено в память, после чего решение можно было принять явно и сохранить как отдельное решение для текста.

Цикл подготовки главы

Основной рабочий процесс выглядел так:

Explore → Plan → Write → Review → Fix → Edit → Human approval

Сначала агент изучал источники, требования, план и, если нужно, код проекта. Затем писал главу в drafts/. Навык thesis-reviewer проверял содержание, ссылки, соответствие источникам и стилю. После этого агент вносил исправления и повторял ревью, пока текст не был готов к редактуре.

chapters/ был зоной утверждённого содержания. Перенос из drafts/ туда происходил только после моего явного решения. Это простое правило оказалось важнее многих подробных инструкций: модель может быстро переписать текст, но она не должна сама решать, что именно стало частью диплома.

Почему первая схема с pull request не сработала

Изначально я хотел построить процесс по знакомой разработчикам схеме:

  1. агент в фоне готовит главу;
  2. открывает pull request;
  3. я оставляю комментарии в ревью;
  4. агент вносит правки и обновляет PR;
  5. я мержу результат.

С инженерной точки зрения это выглядело естественно. Но на практике модель работала быстрее, чем я успевал читать. Объём текста был большим, изменения появлялись часто, а ревью отдельных diff не помогало держать в голове связность нескольких глав.

В результате узкое место оказалось не в агенте и не в Git, а в человеческой пропускной способности.

Я заменил этот цикл работы с PR на две зоны:

  • агент пишет и свободно перерабатывает текст в drafts/;
  • в chapters/ попадает только то, что прошло моё пакетное ревью.

Обычно я просматривал по две главы за вечер прямо в Zed с предпросмотром Markdown, затем передавал агенту список замечаний. Такой процесс оказался медленнее на уровне отдельных изменений, но лучше соответствовал реальному темпу чтения.

Это, пожалуй, главный практический вывод: процесс с участием человека нужно проектировать вокруг его когнитивной нагрузки. Наличие кнопки утверждения ещё не означает, что результат удобно проверять.

Что находилось на ревью

Текст после нескольких проходов обычно был связным, но это не означало, что он был готов к сдаче.

Источники

Некоторые источники выглядели формально подходящими, но не соответствовали уровню академической работы. Другие ссылки были просто битыми.

Особенно показательный случай: сайт может открыть страницу «404 Not Found» и при этом вернуть HTTP-статус 200 OK. Если проверять только статус, такая ссылка выглядит рабочей и легко попадает в библиографию.

В таких случаях я передавал проблему агенту для повторного поиска. Но финальная оценка пригодности источника всё равно оставалась моей задачей. Модель может найти публикацию, которая подтверждает предложение, но это ещё не означает, что публикация достаточно надёжна для конкретной работы.

Лишний и недостающий текст

Агент иногда добавлял подробности, которые не усиливали аргумент. Это обычная «вода», только с хорошей грамматикой.

Иногда происходило обратное: текст был слишком кратким, и в него стоило добавить объяснение, пример, ссылку или явный вывод по поставленной задаче.

Поэтому ревью было не только проверкой ошибок. Я решал, какие утверждения нужно сжать, какие — подтвердить, а какие — раскрыть подробнее.

Связь с реальным проектом

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

Именно для этого в системе есть отдельный thesis-code-analyst: он должен анализировать код, фиксировать пути к файлам и привязывать фрагменты к версии репозитория. Это лучше, чем просить языковую модель «вспомнить», как устроен проект.

DOCX оказался отдельным продуктом

Markdown был удобен для агента и для Git, но университету нужен был Word-файл. Поэтому конвертация в DOCX быстро превратилась в отдельный инженерный проект.

Для сборки использовался Pandoc с Lua-фильтрами и шаблоном reference.docx, задающим стили. Более дорогие модели Opus 4.7/4.8 помогали с ревью и подготовкой плана этой системы, а основную работу по тексту выполнял Sonnet 4.6.

Самые болезненные проблемы были такими:

  • добавление оформленного титульного листа;
  • стили Word для основного текста, подписей, таблиц и кода;
  • таблицы, у которых нужно было получить нормальные границы;
  • Mermaid-диаграммы, которые иногда не помещались на страницу;
  • Markdown-синтаксис, который Pandoc обрабатывал не так, как ожидалось;
  • несовпадение уровней заголовков;
  • нумерованные списки с 1) вместо 1.;
  • ненумерованные списки с * вместо ожидаемого формата - .

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

Это ещё один полезный принцип: генерация текста и сборка конечного артефакта — разные задачи. Первую можно поручить языковой модели, вторую лучше сделать детерминированной и тестируемой.

Что в итоге автоматизировалось

Агент хорошо справлялся с рутинной частью:

  • извлекал и структурировал содержание исходных документов;
  • собирал рабочую библиографию;
  • поддерживал план и память проекта;
  • готовил описательные разделы по уже выполненной разработке;
  • находил внутренние несоответствия и места, требующие уточнения;
  • выполнял повторяющиеся редакторские проходы;
  • помогал поддерживать единый стиль и форматирование;
  • участвовал в сборке DOCX и презентации для защиты.

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

Презентация для защиты тоже была подготовлена с помощью Claude Code и Gamma, но это не изменило распределение ответственности: инструменты помогали оформить и упаковать результат, а не принимали инженерные решения вместо меня.

Итог

Получившаяся система дала мне не «автоматический диплом», а рабочий способ переработки инженерного опыта в формальный документ. Самыми полезными оказались не отдельные промпты, а структура вокруг них:

  • исходные материалы превращаются в проверяемую базу знаний;
  • роли агента разделены на отдельные skills;
  • черновик отделён от утверждённого текста;
  • человек контролирует переход между ними;
  • сборка конечного DOCX вынесена в воспроизводимый конвейер;
  • ошибки и решения сохраняются в репозитории, а не исчезают в истории чата.

Если делать такую систему заново, я бы сразу начал не с PR на каждую главу, а с оценки процесса человеческого ревью. Для длинных документов скорость генерации — не главный показатель. Важнее, может ли человек вовремя прочитать, понять и проверить то, что агент произвёл.

И, конечно, агентская система не отменяет авторство. Она хорошо пишет о том, что уже сделано, но не освобождает от необходимости самому выбрать, что именно делать, почему это решение разумно и как доказать, что результат работает.