Есть задачи, которые я никогда особенно не считал отдельной работой.
написал endpoint
добавил validation
написал response
добавил тест
обновил Swagger
следующая задачаSwagger здесь воспринимался примерно как одна из обязательных операций после написания API.
Так было не всегда. До 2022 года я практически ничего не знал о Swagger. На одном из проектов столкнулся с ним уже как с существующей частью рабочего процесса: нужно понять API — открываешь документацию и смотришь контракт.
Позже я принёс этот подход в свои проекты. А спустя несколько лет поймал себя на мысли:
Почему Swagger вообще должен писать я?
Не потому, что мне лень
Здесь легко всё свести к желанию меньше работать. Но дело немного в другом.
Представим, что я уже написал StoreOrderRequest. Есть CreateOrderData, OrderResource, OrderStatus, исключения и тесты.
Компьютер уже имеет практически всю необходимую информацию о контракте endpoint. Но после этого я ещё раз вручную рассказываю ему:
customer_id integer · required
delivery_date date · required
quantity integer · minimum 1
status enumВопрос «зачем?» в такой ситуации перестаёт быть оправданием лени. Это уже вопрос к устройству процесса.
Раньше я просто не замечал эту работу
Наверное, в разработке таких вещей гораздо больше, чем кажется:
создать DTO
создать Resource
добавить mapping
добавить validation
добавить Swagger
написать похожий тест
обновить README
добавить migration
обновить changelogМы настолько привыкли выполнять эти действия, что воспринимаем весь список как одно слово — «программирование».
Хотя внутри смешаны разные типы работы. Сначала нужно решить, как должен работать API. Потом спроектировать контракт и встроить реализацию в архитектуру. А после начинается механическое продолжение уже принятого решения: теперь опиши тот же контракт ещё вот здесь.
Последняя часть кажется мне прекрасным кандидатом для AI.
От запроса к ответственности
Раньше я использовал AI примерно как очень быстрый Stack Overflow с autocomplete. Просил написать функцию, объяснить ошибку или подготовить Swagger для уже готового endpoint.
Сейчас мне интереснее другая постановка:
Ты отвечаешь за то, чтобы после изменения публичного API его OpenAPI-контракт оставался актуальным.
Разница не в длине промпта. В первом случае разработчик сам помнит о дополнительной задаче, отдельно формулирует её и вызывает AI. Во втором агент знает workflow и проверяет связанные обязанности без очередного напоминания.
Например, я говорю: «Добавь поле external_id для заказа». Дальше агент должен сам пройти цепочку:
DTO
↓
validation
↓
application layer
↓
response
↓
API contract
↓
OpenAPI + testsВот это мне намного интереснее генерации ещё одного PHP-класса.
Потому что код я и сам могу написать
В этом один из парадоксов моего нынешнего отношения к AI. Самые очевидные вещи, которые он умеет делать, мне иногда хочется делегировать меньше всего.
Написать метод, SQL или PHP-класс я умею. А вот просьбы другого типа дают больше пользы:
- найди все места, которые должны измениться вместе;
- проверь, что я ничего не забыл;
- поддерживай документацию синхронно с кодом.
Здесь AI перестаёт соревноваться со скоростью моих пальцев и начинает снимать нагрузку с памяти.
Swagger оказался хорошим примером
В нём хорошо видна граница между решением и механической работой.
Я должен выбрать POST /orders или POST /customers/{customer}/orders. Определить, вернёт создание 200 или 201. Решить, какие ошибки входят в публичный контракт и как версионировать API.
Это инженерная часть. Но когда решение принято, перенос типов, полей и ограничений из PHP DTO в OpenAPI Schema уже не выглядит работой, которую обязательно должен выполнять человек.
Техническую сторону этой истории я отдельно разобрал в двух материалах на almdev: сначала — как Swagger стал для меня контрактом API, затем — что именно в документации можно делегировать AI. Здесь мне важнее другой вопрос: как при этом меняется моя собственная роль.
Я всё меньше хочу управлять отдельными строками работы AI
Сначала процесс выглядел просто:
задача → я → кодПотом между мной и кодом появился AI. Сейчас схема становится другой:
я
│
▼
правила и решения
│
▼
AI
┌─────┼─────┐
▼ ▼ ▼
research code проверки
└─────┼─────┘
▼
результат
│
▼
яМне хочется определить не каждое следующее действие, а то, что считать правильно выполненной задачей.
Один endpoint ничего не меняет
В этом месте профессиональная привычка сопротивляется. Я действительно могу быстрее добавить Swagger Attribute, чем подготовить агенту хороший контекст. Могу быстрее поправить тест или создать DTO.
Если смотреть на одну операцию, AI выигрывает далеко не всегда. Интерес начинается на повторении.
Допустим, Swagger вручную занимает десять минут. Настраивать ради одного endpoint отдельный процесс бессмысленно. Но потом появляется ещё двадцать методов, новые поля, изменённые responses и дополнительные ошибки. Кто-нибудь забывает обновить документацию — и она постепенно перестаёт соответствовать коду.
Автоматизировать нужно не эти десять минут, а процесс, который должен повторяться следующие несколько лет.
AI начинает получать не команды, а роль
Вопрос «может ли AI сделать эту задачу?» стал для меня слишком простым. Практически всегда ответ будет: в каком-то виде может.
Полезнее спросить: есть ли здесь повторяющийся процесс, ответственность за который можно передать AI?
Не «напиши тесты», а «после изменения application service проверь, какие тесты должны измениться или появиться». Не «добавь Swagger», а «следи за синхронностью API и OpenAPI-контракта». Не «сделай code review», а «перед завершением задачи самостоятельно проведи review по правилам проекта».
Когда меняется публичный API, агент получает не список случайных просьб, а постоянный контур:
- проверить обратную совместимость;
- обновить тесты и validation;
- синхронизировать OpenAPI и ответы с ошибками;
- сообщить о несовместимых изменениях.
Это уже не хороший промпт. Это процесс разработки.
Но насколько этому доверять?
Это следующий уровень проблемы.
Агент говорит: «Swagger обновлён. Тесты проходят. API-контракт соответствует реализации». Я всё ещё должен решить, чему именно верю.
Проверять каждую строку? Смотреть только diff? Валидировать сгенерированный OpenAPI? Полагаться на contract tests? Какая степень проверки достаточна?
Чем больше повторяющейся работы я передаю AI, тем важнее этот вопрос. Делегирование не снимает ответственность. Наоборот: чем меньше операций я выполняю вручную, тем точнее должен понимать, что проверяю в результате.
Я не хочу перестать программировать
Мне всё ещё нравится писать код. Я не стремлюсь построить процесс, в котором разработчик только формулирует требования и никогда не открывает IDE.
Мне хочется убрать достаточно повторяющейся механики, чтобы больше времени осталось на понимание задачи, архитектуру, сложные ошибки, производительность, границы системы, компромиссы и эксперименты.
А всё, что выглядит как «мы уже приняли решение, теперь повтори его ещё в пяти местах», постепенно отдавать машине.
Vibe-разработка для меня начинается именно здесь
Не тогда, когда я пишу: «Сделай мне интернет-магазин» — и жду готовое приложение. И даже не тогда, когда AI генерирует половину моего PHP-кода.
А когда я начинаю воспринимать его как ещё одного участника инженерного процесса. У него появляются контекст, правила, обязанности, границы и проверки.
Я уже рассказывал, как прошёл путь от первых подсказок до coding agents. Теперь этот переход стал для меня конкретнее: моя задача не выполнить каждый шаг самостоятельно, а построить процесс, в котором правильные шаги вообще не забываются.
Swagger оказался просто хорошим примером.
Но чем внимательнее я смотрю на обычный рабочий день, тем чаще задаю себе один вопрос:
Какую ещё работу я всё ещё выполняю вручную только потому, что привык считать её частью программирования?
