Недавно я официально открыл исходный код своего Mac-клиента для разработки. Он называется DevFlow.
Я создал этот инструмент главным образом потому, что сам не раз сталкивался с подобными проблемами, разрабатывая проекты с помощью Codex и Claude Code.
Я ведь всего лишь сформулировал простое требование, ИИ долго над ним работал, а в итоге сказал:
«Готово, все тесты пройдены».
Но стоило открыть программу — оказалось, что она работает не так, как я ожидал. Иногда баги никуда не исчезали, а иногда после исправления одной проблемы появлялись две новые.
Больше всего раздражало то, что я совершенно не понимал, что происходило в процессе.
Какие файлы изменились? Какие команды запускались? Действительно ли проводились тесты? Сколько раз они завершались ошибкой? Почему выбрали именно такой способ реализации?
Пока проект небольшой, можно перечитать историю чата. Но когда кода становится всё больше, а разработка затягивается, одной истории чата уже недостаточно, чтобы во всём разобраться.
Поэтому я решил создать инструмент, который позволит мне в любой момент видеть, как работает ИИ, а при обнаружении проблемы — сразу просить его её решить.
Так появился DevFlow.

──── ✦ ────
I. Что вообще умеет DevFlow?
Если коротко, это приложение для Mac, предназначенное для просмотра и контроля процесса разработки с помощью ИИ.
Сейчас оно сосредоточено на пяти вопросах:
① Правильно ли поняты требования?
Можно проверить, какие требования вы изначально сформулировали, на какие задачи ИИ их разбил, ничего ли не упустил и не добавил ли функции без вашего разрешения.

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

③ Действительно ли тесты прошли?
Для меня это особенно важно.
ИИ сообщает, что тесты прошли, но какие функции проверялись? Запускались ли тесты на самом деле? Не менялся ли код после их завершения?

DevFlow связывает план тестирования, фактические результаты запуска и доказательства приёмки, а также отмечает, где доказательств не хватает.

④ Исправлен ли баг?
Все этапы — обнаружение проблемы, изменение кода и повторное тестирование — можно зафиксировать.
Например, ИИ сообщает, что исправил баг, но если результатов повторной проверки нет, проблему всё ещё нужно проверить.

⑤ Можно ли проанализировать историю разработки?
Проект разрабатывался несколько месяцев. Почему тогда выбрали именно такое решение? Какие требования менялись? С какими проблемами сталкивались?
Если нужная информация зафиксирована, к ней всегда можно вернуться.
Я хочу, чтобы в будущем, открывая проект, мне не приходилось искать ответы среди тысяч сообщений в чате.
──── ✦ ────
II. Как это работает вместе с Codex и Claude Code?
Для DevFlow я настроил два независимых набора навыков агента.
devflow-record
Фиксирует требования, декомпозицию задач, действия в процессе разработки, результаты тестирования и связанные с ними доказательства.
devflow-resolve
Помогает разбирать проблемы, обнаруженные разработчиком. На основе обратной связи он заново проверяет факты, исправляет то, что нужно исправить, добавляет необходимые тесты, а затем записывает результат в журнал.
Весь процесс примерно такой:
Постановка задачи → разработка с помощью ИИ и фиксация процесса → проверка в DevFlow → обнаружение проблемы → отправка обратной связи ИИ → исправление, повторная проверка и обновление записей.
Простой пример.
Я прошу Codex добавить функцию, и он сообщает, что всё готово.
Открываю DevFlow и вижу: код действительно изменился, но записей о запуске соответствующих тестов нет.
Тогда я могу прямо сообщить об этой проблеме Codex и попросить его провести проверку.
Когда он закончит, я снова открываю DevFlow и смотрю, какие записи появились и действительно ли проблема решена.
Так мне не приходится каждый раз на глаз определять, хорошо ли ИИ справился с задачей.
Разумеется, сейчас DevFlow ещё не может автоматически знать обо всём, что сделал ИИ. Объём доступной информации зависит от того, какие сессии и записи подключены. Всё, для чего нет доказательств, явно отмечается как неизвестное.
──── ✦ ────
III. Для меня важнее всего то, что он может помогать ИИ совершенствовать процесс разработки
Это идея, которую я постоянно хотел воплотить при проектировании DevFlow.
Когда разрабатываешь проекты с помощью Codex, многие проблемы повторяются.
Например, требования недостаточно подробно разбиты на задачи, для какой-то функции забыли написать тесты, после исправления бага не провели повторную проверку или изменили один модуль, не проверив, повлияет ли это на другие функции.
Если каждый раз разработчику приходится самому замечать такие проблемы и напоминать о них, со временем это действительно утомляет.
Поэтому я хочу, чтобы DevFlow работал вместе с Codex.
Codex занимается разработкой, а DevFlow помогает мне проверять процесс, сообщает о найденных проблемах Codex и позволяет ему продолжить работу над улучшениями.
Например, если во время разработки DevFlow обнаружит, что для какого-то требования нет подтверждения приёмки, я могу передать Codex описание проблемы и связанные записи.
С помощью devflow-resolve Codex заново проверяет факты, добавляет тесты или исправляет код, а после повторной проверки обновляет записи.

В следующий раз, открыв DevFlow, я смогу снова проверить результат.
Разработка с ИИ → проверка в DevFlow → обнаружение недочётов → обратная связь Codex → исправления и повторная проверка → новая проверка.
Этот процесс можно повторять снова и снова.
Что ещё важнее, по мере развития проекта мы можем анализировать записи и выявлять часто повторяющиеся проблемы.
Какие требования чаще всего упускают? Для каких тестов часто не хватает проверок? Какие этапы разработки нужно дополнительно регламентировать?
Этот опыт можно постепенно накапливать и использовать для улучшения дальнейшего процесса разработки.
В итоге я хочу, чтобы DevFlow помогал фиксировать ход каждой разработки, давать обратную связь по каждой проблеме и обосновывать каждое улучшение.
──── ✦ ────
IV. Почему я решил сделать приложение для Mac?
В основном потому, что сам обычно разрабатываю на Mac.
Я хочу, чтобы приложение напрямую управляло материалами локальных проектов, без регистрации аккаунта и загрузки кода или записей о разработке на сторонние платформы.
Сам DevFlow не обращается к внешним моделям ИИ и не отправляет команды в Codex или Claude Code автоматически.
Вы можете сами проверить и отредактировать обратную связь, а затем решить, поручать ли ИИ продолжить работу.
Сейчас можно вручную подключать локальные сессии Codex, а другие агенты могут создавать записи в едином формате с помощью соответствующих навыков.
Кроме того, я сделал ещё кое-что:
Использую DevFlow, чтобы контролировать разработку самого DevFlow.
По возможности я фиксирую изменения требований, проблемы с тестами и процесс исправления ошибок, возникавшие при разработке этого инструмента, тем же способом.
Сначала испробую собственный инструмент на своём проекте.
──── ✦ ────
V. Проект уже открыт, приглашаю всех попробовать
Сейчас доступна предварительная версия DevFlow для macOS.
Поддержка Apple Silicon / macOS 14+
Установочный пакет DMG
В комплект входят два навыка: devflow-record и devflow-resolve
Открытая лицензия MIT
Обработка материалов проекта локально, без аккаунта
Приложение пока не прошло нотариальную проверку Apple. При первой установке следуйте инструкциям в README.
Установить приложение и подключить его довольно просто.
Можно даже просто передать Codex ссылку на репозиторий GitHub: он прочитает документацию проекта и поможет выполнить подключение по инструкциям.
Открытый репозиторий на GitHub:
https://github.com/damobianyuan0325/DevFlow-Mac

Если вы тоже часто пишете код с помощью ИИ, скачайте и попробуйте.
Если возникнут вопросы, создайте Issue. Если проект оказался полезен, буду рад звёздочке.
──── ✦ ────
VI. Напоследок — анонс моего второго открытого проекта: Harness Engineering
На самом деле во время разработки DevFlow я постоянно думал ещё об одном.
Раз уж мы можем проверять процесс разработки с помощью ИИ и обнаруживать пропущенные требования, недостаток тестов или незавершённые исправления, можно ли сделать так, чтобы ИИ старался избегать этих проблем уже в процессе разработки?
Именно поэтому я готовлю к публикации второй проект.
Harness Engineering (навыки разработки и инженерия Harness).
Я хочу собрать в повторно используемый набор навыков разработки и инженерных процессов опыт, накопленный при работе с Codex: декомпозицию требований, правила выполнения, тестирование и приёмку, разбор ошибок и проверку результатов.
В будущем его можно будет использовать вместе с DevFlow:
Harness Engineering задаёт правила разработки для ИИ.
DevFlow проверяет, как ИИ справился на практике.
Затем обнаруженные проблемы можно передавать Codex с помощью навыков, чтобы он добавлял проверки, исправлял ошибки и помогал постепенно совершенствовать наши стандарты разработки.
Вместе эти два проекта образуют замкнутый цикл разработки: от требований и реализации до проверки, обратной связи и постоянного улучшения.
Разумеется, эта полноценная система взаимодействия всё ещё находится в разработке. Позже я расскажу о создании второго проекта и поделюсь ссылкой на его открытый репозиторий.
──── ✦ ────
За время разработки проектов с помощью ИИ я понял главное: ИИ уже пишет код очень быстро. Многие задачи, на которые раньше уходило несколько дней, теперь можно выполнить за несколько часов.
Но чем сложнее становятся проекты, тем больше меня волнует ещё один вопрос:
Каждый раз, когда ИИ говорит, что закончил, я хочу точно понимать, что именно он сделал, какие результаты подтверждены доказательствами и что ещё нужно выполнить.
DevFlow — моя первая попытка в этом направлении.
Я продолжу его улучшать и постепенно рассказывать о других проектах, которые разрабатываю и публикую в открытый доступ.
Надеюсь, эти инструменты помогут таким же разработчикам, как я, увереннее создавать проекты с помощью ИИ.

