Как всё началось задолго до coding agents

Я долго думал, с какой точки начать этот раздел.

Можно было бы начать с Claude Code, Cursor или Codex. С разговоров про AI-агентов, которые уже умеют исследовать проект, писать код, запускать тесты и самостоятельно исправлять найденные ошибки.

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

Сначала: «Помоги мне не писать эту рутину руками».

Потом: «Возьми эту часть разработки на себя».

Сначала AI просто экономил мне время

Мои первые более-менее системные эксперименты с AI в разработке начались задолго до подписки на сервис JetBrains AI в декабре 2023 года. Ничего революционного тогда не происходило.

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

Одним из первых реальных сценариев стала документация. На проектах на Laravel и Битрикс приходилось описывать API и поддерживать Swagger/OpenAPI. Написать сам API было зачастую быстрее, чем подробно зафиксировать весь контракт:

endpoint
    ↓
parameters
    ↓
request body
    ↓
responses · status codes · examples

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

AI оказался здесь очень кстати. Я мог показать ему существующий метод или структуру API и получить основу документации, которую оставалось проверить и привести в нормальный вид.

я пишу код
    ↓
AI помогает с рутиной
    ↓
я проверяю
    ↓
я продолжаю писать код

Полезный инструмент. Но всё ещё именно инструмент.

Потом мне захотелось проверить, сможет ли AI написать код сам

Следующим заметным этапом для меня стал Junie от JetBrains. Здесь эксперимент был уже серьёзнее.

Если раньше я использовал AI для вспомогательных задач, то теперь хотелось отдать ему полноценную задачу. Не попросить написать PHPDoc или сгенерировать OpenAPI-аннотацию, а поручить изменение, которое затрагивает несколько частей проекта: найти связанные классы, изменить backend, добавить проверки и написать тесты.

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

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

Когда отдаёшь задачу целиком, вопрос меняется:

Понимает ли агент устройство проекта, а не только синтаксис PHP?

Оказалось, что написать код — далеко не самая сложная часть разработки

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

До первой изменённой строки нужно понять:

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

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

Мой интерес сместился с вопроса «Насколько хорошо AI пишет PHP?» на другой: «Какую часть процесса разработки ему вообще можно передать?»

Потом появились Claude Code, Cursor и Codex

Следующий этап оказался гораздо серьёзнее. В моём рабочем наборе появились инструменты, которые работают с проектом целиком, а не с одним открытым файлом: Claude Code, Cursor и Codex.

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

задача
    ↓
Cursor
    постановка · среда · сценарии проверки
    ↓
Claude Code
    разработка
    ↓
Codex
    независимая проверка
    ↓
Claude Code
    исправления · review

Иногда Claude Code и Codex меняются местами: один реализует, второй проверяет. Иногда я специально прошу их критиковать решения друг друга.

Эта схема оказалась полезнее попыток найти одну «лучшую AI-модель для программирования».

Мне всё меньше интересна «лучшая модель»

Когда пользуешься такими инструментами постоянно, вопрос «Claude или GPT?» становится слишком простым. Качество результата зависит от всей системы вокруг модели:

model + context + tools
+ project instructions
+ development environment
+ workflow + verification

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

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

Cursor у меня вышел за пределы редактора

Изначально редактор с AI воспринимается достаточно очевидно: IDE плюс AI. Со временем я начал использовать Cursor шире.

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

AI-разработка для меня уже не выглядит как короткая цепочка «человек → AI → код». В ней появились постановка задачи, контекст, исследование проекта, реализация, независимая проверка, автоматические тесты и только потом решение человека.

Это уже другой способ разработки.

Перекрёстная проверка оказалась важнее, чем я ожидал

Есть соблазнительная идея: если AI написал код и тесты проходят, задача выполнена.

Я всё меньше в неё верю.

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

• почему изменён именно этот слой;
• что произойдёт в этом edge case;
• зачем здесь новая abstraction;
• почему не использован существующий сервис;
• действительно ли тест проверяет требование.

Я не считаю, что один AI автоматически исправляет ошибки другого. Но второй взгляд часто меняет оценку результата — почти как обычный code review, только reviewer появляется практически мгновенно.

И здесь началась другая история

В какой-то момент я понял, что экспериментирую уже не с генерацией кода, а с самим процессом разработки.

Раньше я получал задачу, разбирался, проектировал, писал код и тесты, проверял результат. Теперь часть этого маршрута проходит иначе: я формулирую требования и границы, агент исследует проект и предлагает решение, один инструмент реализует, другой делает review, после чего запускаются проверки.

Моя работа никуда не исчезла. Она сместилась.

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

Наверное, именно здесь для меня начинается Vibe-разработка

Термин vibe coding мне нравится и одновременно немного раздражает.

Если понимать его как «попросил AI что-нибудь написать, не посмотрел код и отправил в production», такой подход мне не особенно интересен.

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

Именно эту трансформацию мне хочется наблюдать.

Поэтому раздел называется не «Гайды по Claude Code» и не «Новости AI для программистов», а «Дневник Vibe-Разработчика». Инструменты здесь важны, но гораздо интереснее следить за тем, как меняется моя собственная работа.

Что будет дальше

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

• что я уже готов делегировать AI, а что предпочитаю делать сам;
• почему я перестал сразу просить AI писать код;
• как меняется code review и можно ли доверять тестам того же агента;
• насколько вообще нужно читать код, написанный AI;
• что происходит, когда Claude Code и Codex проверяют друг друга;
• зачем агенту отдельные инструкции проекта;
• почему хороший контекст иногда важнее новой модели;
• где заканчивается помощь AI и начинается ответственность разработчика;
• что значит «писать программу», если значительную часть кода написал не ты.

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

Когда-то всё начиналось со Swagger-документации, которую просто не хотелось писать руками. Потом я попробовал отдавать AI отдельные задачи. Теперь несколько агентов могут участвовать в одном изменении и проверять работу друг друга.

Что будет следующим шагом — пока не знаю.

Но именно за этим мне и интересно наблюдать.