Почему я веду разработку в чатах ChatGPT, а не в Codex

Сейчас у нас работает несколько проектов: контроль заказов в CRM, анализ звонков, отчёты для руководителей, AI-ассистент из прошлых статей, парсеры соцсетей. Код для них написала нейросеть в обычных чатах — в основном ChatGPT, часть в Claude.

Многие советуют другой путь — агентов вроде Codex, которые сами пишут и запускают код. Я сознательно выбрал чат.

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

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

В чате нейросеть не видит ни сервер, ни файлы проекта. Она пишет команду или целый файл, человек запускает его и показывает ей результат. Следующий шаг нейросеть предлагает только по тому, что ей показали.

Если сравнить с машиной: агенту отдают руль, а чат работает штурманом. Маршрут прокладывает нейросеть, но руль всё время у человека.

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

У нейросети в чате нет доступа ни к серверу, ни к 1С, ни к CRM. Каждую команду запускает человек, и ни одно изменение не попадёт в рабочую систему мимо него. Ключи доступа в чат не передаются: скрипты показывают только «ключ есть» или «ключа нет».

Нейросети не нужен доступ к 1С, серверу и рабочим компьютерам — мостом между ними работает человек. Так у нас переехал один проект со старого компьютера на сервер, и нейросеть не получила доступа ни к одному из них.

Агенту, наоборот, доступ нужен: к файлам, командам, а иногда и к рабочим системам. Его можно ограничить настройками, но за ними нужно следить.

В апреле 2026 года агент в Cursor за 9 секунд удалил рабочую базу стартапа PocketOS вместе с резервными копиями (источник). Он нашёл ключ доступа, который к задаче не относился, и подтверждения у человека не спросил.

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

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

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

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

Совет владельцу: если в компании работает система, устройство которой никто не может объяснить, это риск. В день сбоя её будет некому чинить.

ТЗ почти никогда не бывает полным с первого раза — это известная проблема всей отрасли. По данным PMI, международного Института управления проектами, почти половина неудачных проектов (47%) не достигает целей из-за плохой работы с требованиями. Поэтому один из принципов гибкой разработки (Agile Manifesto) прямо говорит: изменения требований нужно принимать даже на поздних этапах.

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

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

Совет владельцу: правила — что считать выручкой, нарушением, хорошим клиентом — утверждает человек из бизнеса. Нейросеть может их предложить, но решать не должна.

Наш первый проект в июле начался с одной фразы в чате — без ТЗ, резервных копий и истории изменений. Сейчас на самом сложном проекте каждое обновление ставится только после точки отката и более чем 300 автоматических проверок. Если хоть одна не прошла, система сама возвращается к прежней версии.

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

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

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

Совет владельцу: спросите исполнителя, какие правила появились у него после ошибок. Если таких нет, скорее всего, ошибки просто никто не разбирал.

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

Чат со временем забывает начало переписки, поэтому память проекта хранится отдельно — в журнале. В нём решения с датами, все изменения и то, что проверено. К журналу мы пришли на самом сложном проекте, и теперь он для нас обязателен.

Новому чату передаётся журнал вместе с кодом, и он продолжает с того места, где остановился прошлый. Так проект можно перенести из ChatGPT в Claude или передать другому исполнителю. Подробнее о журнале — в первой статье.

Чем журнал отличается от памяти агента. У агентов тоже есть память в файлах проекта — например, у Codex это файл AGENTS.md. Но это разные вещи, и разница видна, если положить их рядом:

Формат записей решений называется ADR. Его предложил инженер Майкл Найгард, а британская государственная цифровая служба рекомендует вести такие записи своим командам.

Записи решений при любом способе ведёт человек: агент может описать, что изменил в коде, но почему бизнес решил именно так, знает только человек. В чате это получается естественно: каждое решение и так проходит через него. У нас запись в журнал — условие приёмки: её делает сам установщик после успешного обновления.

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

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

Длинный чат забывает начало, а ручной перенос иногда даёт сбои. От первого спасает журнал, от второго — правило «одна команда за раз».

Чтобы сравнение было не на вкус, два способа разложены по десяти критериям. Для каждого — основание: исследования, отраслевые отчёты, реальные случаи. Ссылки — в конце статьи.

Агент сильнее там, где важны скорость и порядок в коде. Чат — там, где ошибка стоит дорого: безопасность, понимание системы, стабильность, бизнес-правила.

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

Перед передачей комплект сверяют с реальностью: у нас при такой сверке старое описание прав доступа оказалось устаревшим.

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

Один работает через агента, другой — через чат. Программировать ни тому, ни другому не придётся: код напишет нейросеть.

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

Разработчики называют это инженерной дисциплиной. Без неё система работает до первой ошибки, а потом её трудно и починить, и объяснить. Вопрос в том, кто из двоих освоит эти привычки быстрее.

Одна задача — два пути. Нужен ежедневный отчёт о продажах из CRM в мессенджер руководителю. Вот чем закончится первый месяц:

Что говорят исследования. Прямых исследований «чат против агента» для непрограммистов пока нет, но косвенные данные сходятся:

Наш пример. За четыре месяца — путь от проекта без резервных копий до обновлений с точкой отката и более чем 300 автопроверками. Каждое правило в этой цепочке появилось из собственной ошибки.

Кто будет сильнее через полгода. У того, кто работал с агентом, скорее всего, будет больше готовых решений. У того, кто работал в чате, — больше понимания, как они устроены, и привычка к дисциплине. По-моему, для собственника второе важнее: решения можно заказать, а понимание своей системы — нет.

Условие одно — спрашивать «почему так». Если только пересылать ошибки и вставлять исправления, понимание не растёт ни в чате, ни с агентом.

С чего начинать. Начинать стоит с чата: он заставляет выстроить дисциплину своими руками. Агента, если захочется его скорости, лучше подключать позже — когда уже есть история изменений, автопроверки, точка отката и записанные правила. Тогда он усилит порядок, а не хаос.

Если разработку ведёт кто-то внутри компании или вы сами, вот что стоит сделать сразу:

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

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

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