Я собрал агента-программиста. Главное в нём - недоверие к собственному коду

С AI-кодом у меня долго была одна проблема.

Он может выглядеть слишком убедительно.

Ты пишешь в чат: “сделай мне маленькое приложение”. Через минуту на экране уже файлы, функции, папки, какие-то команды запуска. Визуально всё похоже на работу программиста.

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

Что именно поменялось? Какие файлы трогались? Можно ли откатить назад? Запускались ли тесты? Куда агент вообще имел право лезть? Он проверил результат или просто написал, что проверил?

Если этих ответов нет, мне такой код не нужен.

Потому что проблема не в том, что AI не умеет писать код. Умеет. Проблема в том, что код без контура быстро превращается в ручной разбор для человека.

Поэтому я собрал себе отдельного агента-программиста.

Не “чат, который пишет код”. А технического исполнителя с рабочими границами.

Его работа начинается с preflight.

Я могу написать обычным языком:

“Создай новую папку под проект.”

“Проверь репозиторий.”

“Почини ошибку.”

“Собери маленький инструмент.”

“Разберись, почему тест падает.”

“Добавь проверку, но аккуратно, не ломая остальное.”

Раньше я бы пошёл с такой задачей в обычный чат. Получил бы кусок кода, а дальше сам думал, куда его положить, как запускать и не сломал ли он что-то рядом.

С агентом-программистом порядок другой.

Он сначала смотрит на рабочую папку. Проверяет, есть ли git. Понимает структуру проекта. Фиксирует, что можно трогать, а что запрещено. Отдельно держит в голове секреты, env-файлы, cookies, боевые доступы и всё, куда лезть нельзя.

Потом он готовит задачу для Codex CLI, запускает работу, следит за процессом и после этого не просит поверить ему на слово.

Он должен вернуть след.

Что поменялось. Где diff. Какие команды запускались. Что прошли тесты или сборка. Что не удалось доказать. Где остался риск. Как откатиться назад.

Вот это для меня и стало нормальной точкой.

Агент-программист полезен не потому, что он “умный”. Он полезен, когда после его работы остаётся проверяемый артефакт.

Многие слышат “агент-программист” и сразу закрывают тему: “я же не пишу код”.

Но в обычной работе технические задачи есть почти у всех.

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

Маркетологу нужно переименовать пачку файлов, обработать CSV, проверить ссылки, вытащить данные со страниц, подготовить JSON, быстро собрать лендинг-прототип или валидатор UTM.

Методологу нужно разложить папку материалов, собрать manifest, проверить, где не хватает описаний, привести файлы к одному виду, сделать маленький инструмент для проверки шаблонов.

Автору нужно обработать расшифровки, собрать оглавление, конвертировать форматы, проверить битые ссылки, подготовить пакет файлов к публикации.

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

Обычно такие задачи застревают между двумя мирами.

Для разработчика они слишком мелкие.

Для обычного человека они слишком технические.

А для AI-чата они вроде бы простые, пока не доходит до запуска, файлов, проверок и ответственности.

Агент-программист как раз живёт в этой зоне.

Он не делает человека senior-разработчиком. Он помогает довести маленькую техническую задачу до состояния, где результат можно проверить.

Допустим, у вас есть папка с материалами курса.

Внутри PDF, markdown, картинки, старые версии, расшифровки, таблицы. Нужно привести всё к одному виду: проверить названия, найти пустые описания, собрать manifest, показать список проблем и ничего не удалить.

Обычная модель может написать скрипт.

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

Я бы поставил задачу агенту иначе:

“Вот папка. Работать можно только внутри неё. Удалять нельзя. Сначала dry-run. Покажи список будущих изменений. Реальное переименование только после подтверждения. В конце дай отчёт.”

И это уже рабочая постановка.

Не потому что агент стал гением. Просто ему дали нормальные условия работы.

У вас есть процесс, который каждую неделю делает человек.

Например, менеджер выгружает таблицу, чистит данные, переносит цифры в отчёт и отправляет руководителю.

Это не всегда полноценный IT-проект. Иногда там нужен маленький скрипт, проверка входных данных, шаблон отчёта и короткая инструкция для сотрудника.

Агент-программист может собрать первый безопасный вариант: посмотреть структуру файлов, предложить скрипт, добавить проверку, сделать README, запустить тест на примере и показать, где человек всё ещё принимает решение.

Без обещаний, что компания автоматизируется за вечер.

Нормальный результат может быть маленьким.

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

Для меня это нормальное место AI-агента в работе.

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

Мой агент-программист работает как оператор Codex CLI.

Он не просто получает мою просьбу и сразу пишет код. Он превращает просьбу в рабочее задание для кодового исполнителя.

Для серьёзных задач остаётся пакет следов:

- input.json с задачей; - policy.yaml с правилами; - prompt.md с точной постановкой; - codex.log с ходом выполнения; - diff.patch с изменениями; - verify.log с проверками; - receipt.json с итогом; - report.md с человеческим отчётом.

Звучит инженерно, но здесь нет лишней красоты.

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

Codex может отчитаться, что всё сделал. Но self-report в коде не считается доказательством.

Проверка или не считается.

Потому что это было бы враньём.

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

У него другая роль.

Он помогает быстрее пройти путь от “у меня есть техническая хотелка” до “у меня есть проверяемый артефакт”.

Артефактом может быть скрипт, тест, маленький сервис, validator, README, прототип, исправление, технический отчёт или безопасный план изменений.

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

Это отдельный навык агента.

Не фантазировать. Не трогать запрещённое. Не публиковать. Не удалять. Не лезть в секреты. Не делать вид, что проверил, если проверки не было.

Я стал быстрее вытаскивать из головы мелкие технические идеи.

Раньше многие штуки висели в формате: “когда-нибудь надо сделать”.

Сейчас я могу превратить это в рабочую задачу:

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

Дальше агент-программист может взять маленький кусок и попробовать довести его до результата.

Даже если он не решит всё, он часто делает полезную часть: разбирает проект, находит место поломки, предлагает аккуратный план, пишет первый вариант, запускает проверку, показывает стоп-точку.

Это уже сильно лучше, чем держать идею в голове или просить обычный чат: “сделай как-нибудь”.

“Сделай мне хорошо” - это не задача.

Для агента задача должна быть собрана как мини-регламент: цель, входные данные, разрешённые файлы, запреты, критерий готовности, команда проверки, формат отчёта и стоп-правила.

Я бы начал не с выбора модели.

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

Не “сделать стартап”. Проще.

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

Потом для каждой задачи написал бы запреты.

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

После этого нужен критерий готовности.

Команда запускается. Файл создан. Тест прошёл. Отчёт лежит в нужном месте. Список изменений показан. Человек подтвердил следующий шаг.

И только потом можно отдавать это агенту.

Начинать лучше с маленьких задач. Один скрипт. Один отчёт. Один dry-run. Один validator. Потом проверка. Потом следующий кусок.

AI-программист становится полезным не в момент, когда он пишет код.

Код сейчас пишут многие модели.

Он становится полезным, когда вокруг него есть рабочая среда: задача, папка, ограничения, diff, лог, проверка, отчёт и human approval там, где без человека нельзя.

Я сейчас именно так собираю свою агентскую систему.

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

Не идеальную фантазию про “AI всё сделает сам”.

А маленькие проверяемые куски, которые можно встроить в жизнь и работу.

И чем больше я с этим работаю, тем сильнее вижу простую вещь.

Будущее не в самом хитром промпте.

Будущее в том, чтобы научиться давать агентам нормальные рабочие задачи.