Как Codex стал моим техническим партнёром, а не просто чатиком для кода

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

С Codex у меня постепенно сложилось другое ощущение.

Он превратился в технического партнёра. Не потому, что всегда прав — далеко не всегда. А потому, что начал работать внутри проекта, а не рядом с ним.

Сначала посмотри, потом трогай

Главное отличие рабочего агента от чат-бота: он начинает с контекста.

Смотрит, где находится. Читает AGENTS.md. Проверяет git status. Ищет файлы через rg. Разбирается, какие документы уже есть. Отличает публичный сайт от project-control repo. Понимает, что Notion write — одно, а production rebuild — совсем другое.

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

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

Увидеть, а не только написать

Старый сценарий: модель написала код, дальше «проверьте сами».

Новый: агент поднимает локальный сервер, открывает страницу, делает screenshot, проверяет API, находит, почему на мобильном граф улетел вниз или почему в Safari поехал блок.

Когда мы делали граф pimenov.ai, красивые идеи быстро столкнулись с реальностью: на десктопе хорошо, на мобильном пустой экран, карточка не видна, граф можно потерять. Чистой фантазией такое не решишь — нужно смотреть.

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

Руками туда не лезть

Пожалуй, самая ценная часть — умение не делать.

В моих проектах есть вещи, которые нельзя трогать без явной команды: Directus writes, Notion writes, production rebuild, deploy, nginx, DNS, секреты, чужие изменения в git.

Если я прошу исследовать проблему — это не «почини прод». Если я говорю «посмотри» — это не «запусти apply». Если у нас грязный git status — это не «сделай cleanup».

Эта дисциплина отличает технического партнёра от опасного автопилота.

Документы после кода

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

Поэтому Codex всё чаще делает правки вместе с checkpoints: что сделано, какие файлы затронуты, какие решения приняты, какие проверки прошли, что нельзя трогать, какой следующий шаг.

Для длинных задач это критично. Graph Opportunities Console уже прошла несколько этапов: v0, semantic snapshot, brief layer, prompt hardening, quality gate. Без документов это быстро стало бы мутной историей. С документами — рабочий проект, к которому можно вернуться через неделю и продолжить с понятной точки.

Думать вместе

Самое неожиданное: Codex стал полезен там, где вообще ничего не нужно писать в файлы.

Он помогает структурировать мысли. Идея с темами для базы знаний родилась из разговора: есть граф, есть перекосы по тегам, есть Notion pipeline — можно быстро закрыть недостающие темы. Codex помог сформулировать список, разложить его, сохранить в Notion, потом сделать Markdown backlog.

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

То же с текстами. Обсуждение структуры статьи, проверка аргументации, поиск слабых мест в логике — всё это Codex делает на уровне, который реально экономит время. Он не заменяет авторский голос, но помогает быстрее добраться до сути.

Где он ошибается

Романтизировать не хочу.

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

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

Именно поэтому вся обвязка — AGENTS.md, границы, checkpoints, session notes — не бюрократия. Это фундамент, на котором агент перестаёт быть случайным генератором и становится предсказуемым партнёром.

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

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

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

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

По теме

• Статья: Как я перестал бояться технической сложности, когда рядом появился агент
• Блог: Codex /goal: locked-in режим для ИИ и 10 готовых сценариев
• База знаний: AGENTS.md / SESSION_NOTES — проектная память для coding-агентов

Если вы уже работаете с кодинг-агентами или думаете, как встроить их в свой проект — тема техпартнёрства раскрывается на конкретных задачах. Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov