Есть странное ощущение, которое я давно не испытывал.
Ты много лет занимаешься разработкой. Знаешь PHP. Работал с Laravel и Symfony. Понимаешь, как устроены приложения, где обычно возникают проблемы, почему некоторые архитектурные решения через два года начинают причинять боль и почему «быстро поправить одну маленькую штуку» иногда заканчивается несколькими часами чтения чужого кода.
И вдруг снова чувствуешь себя начинающим.
Не потому, что появился очередной framework.
Не потому, что нужно выучить новый синтаксис.
И даже не потому, что очередной инструмент умеет писать код быстрее тебя.
Приходится заново учиться тому, как вообще теперь разрабатывать software.
Казалось, что основной навык уже сформирован
В какой-то момент профессия разработчика становится довольно предсказуемой.
Разумеется, технологии меняются. Появляются новые версии PHP, фреймворков, библиотек, подходов к инфраструктуре.
Но сам процесс долгое время оставался узнаваемым.
получить задачу
разобраться в требованиях
посмотреть существующий код
продумать решение
написать реализацию
добавить тесты
запустить всё локально
исправить ошибки
отправить код на reviewМожно менять IDE, язык, framework или даже компанию, но фундаментальная схема остаётся примерно той же.
Поэтому с опытом появляется довольно приятное ощущение: ты уже понимаешь, как работать.
Ты можешь не знать конкретную библиотеку, но знаешь, как её изучить. Можешь впервые увидеть проект, но примерно понимаешь, где искать нужный код. Можешь столкнуться с незнакомой ошибкой, но знаешь, как постепенно сузить область поиска.
Это и есть одна из главных вещей, которые даёт опыт. Не знание всех ответов. А понимание процесса поиска этих ответов.
И именно этот процесс сейчас начал меняться. Часть этого пути я уже описывал в заметке про то, как всё началось задолго до coding agents.
Сначала AI прекрасно укладывался в старую модель
Первые сценарии были очень понятными.
Есть разработчик. Есть задача. Есть AI, который помогает разработчику быстрее её решить.
Нужно написать регулярное выражение — спросил модель. Нужно вспомнить параметр какой-нибудь функции — спросил модель. Нужно быстро набросать DTO, тест или миграцию — можно попросить AI. Нужно разобраться в ошибке — вставил stack trace в чат.
В таком варианте почти ничего не меняется. AI просто занимает место где-то рядом с Google, Stack Overflow, документацией и autocomplete.
Очень мощный инструмент. Но всё ещё инструмент внутри привычного процесса разработки.
Я формулирую небольшой вопрос. Получаю небольшой ответ. Проверяю его. Вставляю в проект. И продолжаю работать.
Долгое время именно так я AI и воспринимал. И, наверное, поэтому не сразу заметил главное изменение.
В какой-то момент AI перестал отвечать только на вопросы
Постепенно задачи становились больше.
Сначала:
Напиши этот метод.
Потом:
Посмотри этот класс и предложи рефакторинг.
Потом:
Найди, почему здесь возникает ошибка.
Ещё позже:
Разберись, как устроен этот модуль.
А затем появляется запрос, который ещё несколько лет назад звучал бы довольно странно:
Вот задача. Посмотри проект, найди нужные места, предложи решение, внеси изменения и запусти тесты.
И вот здесь происходит важный сдвиг.
Ты больше не просто используешь AI, чтобы писать код. Ты начинаешь работать вместе с системой, которая сама читает код, ищет зависимости, строит гипотезы, вносит изменения и проверяет результат.
Формально ты всё ещё программируешь. Но сам способ программирования становится другим.
Самым непривычным оказалось не писать меньше кода
Можно подумать, что главное изменение заключается в том, что разработчик теперь меньше печатает.
Для меня это оказалось далеко не самым интересным. Количество набранных вручную строк вообще не очень хороший показатель работы программиста. Можно за день написать две тысячи строк плохого кода. А можно изменить пять строк после трёх часов анализа и решить настоящую проблему.
Поэтому вопрос «кто теперь пишет код — я или AI?» довольно быстро перестал казаться мне важным.
Гораздо интереснее другой вопрос:
Какую часть инженерного процесса теперь должен выполнять человек?
Раньше между мыслью и кодом почти всегда находился я сам. Я изучал проект. Я находил нужные файлы. Я строил план изменения. Я писал код. Я запускал тесты. Я исправлял ошибки.
Теперь между задачей и результатом может находиться агент. И моя работа всё чаще начинается не с открытия файла. Она начинается с объяснения задачи.
Оказалось, что хорошо поставить задачу сложнее, чем хорошо написать функцию
Когда работаешь сам, огромное количество контекста существует только у тебя в голове.
Ты знаешь: почему этот сервис устроен именно так; почему старый кусок кода лучше пока не трогать; почему здесь нельзя использовать очевидное решение; какое поведение считается корректным с точки зрения бизнеса; где находится технический долг; какие тесты ненадёжны; что написано в документации, но уже давно не соответствует реальности.
Человек использует весь этот контекст почти автоматически. AI его не знает.
И внезапно становится видно, насколько значительная часть разработки всегда существовала где-то между кодом, документацией и памятью команды.
Поэтому первое, чему приходится учиться заново, — делать этот контекст явным.
Не просто:
Добавь возможность отмены заказа.
А скорее:
Сначала разберись, как сейчас меняются статусы заказа. Найди все места, где состояние считается финальным. Отмена возможна только до передачи заказа во внешнюю систему. Публичный API менять нельзя. Существующие события должны продолжить отправляться. Перед реализацией покажи план изменений.
Это уже немного другая работа. И забавно, что многолетний опыт разработки здесь не исчезает. Наоборот. Он становится особенно полезным. Потому что хороший запрос к AI часто является просто хорошо сформулированной инженерной задачей.
Я начал гораздо чаще просить сначала ничего не писать
Это, пожалуй, одно из самых неожиданных изменений моего процесса.
Когда впервые появляется инструмент, который умеет писать код почти мгновенно, естественная реакция: пусть пишет. Есть задача — генерируем реализацию.
Но довольно быстро выясняется, что скорость генерации кода сама по себе ничего не гарантирует. AI может очень быстро написать вполне качественное решение неправильной задачи. Или выбрать архитектурно разумный подход, который совершенно не подходит конкретному проекту. Или исправить симптом, не заметив причину.
Поэтому всё чаще первая инструкция выглядит примерно так:
Пока ничего не меняй. Сначала исследуй проект.
Потом:
Опиши, как сейчас работает эта часть системы.
Потом:
Предложи несколько вариантов решения.
И только потом:
Теперь реализуй выбранный вариант.
То есть парадоксальным образом хороший способ использовать систему, которая умеет быстро писать код, иногда заключается в том, чтобы как можно дольше не позволять ей писать код.
Старый опыт никуда не делся
Иногда разговор об AI-разработке строится так, будто всё, чему программисты учились раньше, внезапно стало ненужным.
Я вижу почти обратную картину. Чем больше задач выполняет AI, тем важнее становится способность оценить то, что он сделал.
Если ты не понимаешь архитектуру — сложно заметить плохое архитектурное решение. Если плохо знаешь SQL — трудно увидеть запрос, который будет прекрасно работать на тысяче строк и развалится на миллионах. Если не сталкивался с production — легко согласиться с решением, которое идеально выглядит локально. Если не понимаешь предметную область — можно принять технически корректную реализацию неправильного бизнес-процесса.
AI сильно снижает стоимость получения реализации. Но стоимость правильного решения от этого не исчезает.
Поэтому опыт неожиданно начинает работать немного иначе. Раньше он помогал быстрее написать решение. Теперь он всё чаще помогает быстрее понять, можно ли доверять написанному решению.
Код становится одним из результатов работы, а не всей работой
Наверное, самое заметное изменение моего собственного восприятия разработки связано именно с этим.
Раньше задача почти автоматически превращалась в код. Теперь между ними появилось гораздо больше явно выделенных этапов.
исследование
контекст
план
реализация
review
тестирование
проверка предположенийИногда эти этапы выполняют разные AI-инструменты. Один исследует проект. Другой пишет реализацию. Третий проверяет diff.
А я всё меньше ощущаю себя человеком, который непосредственно переводит требования в строки PHP. Скорее человеком, который управляет процессом превращения требования в изменение системы.
Возможно, звучит немного слишком громко. Но на практике это проявляется в очень бытовых вещах.
Я могу двадцать минут вообще не открывать редактор кода. Вместо этого обсуждать с агентом архитектуру. Проверять найденные им зависимости. Корректировать план. Просить посмотреть ещё один модуль. А потом получить изменение, которое раньше сам писал бы час.
И основная работа за эти двадцать минут всё равно была инженерной. Просто выглядела она иначе.
Приходится учиться отпускать контроль
Это отдельная проблема для человека, который много лет привык сам держать весь процесс в голове.
Когда пишешь код самостоятельно, ты знаешь происхождение практически каждой строки. Ты принимал каждое маленькое решение. Почему здесь интерфейс. Почему здесь отдельный сервис. Почему этот запрос написан именно так.
При работе с AI появляется код, который технически является частью твоего проекта, но путь к нему был другим.
И первое желание — проверить абсолютно всё. Открыть каждый изменённый файл. Пройти каждую строку. Перепроверить каждое решение.
Пока я во многом именно так и делаю. Но уже понятно, что такой подход плохо масштабируется.
Если AI действительно становится полноценным участником разработки, нет смысла ускорять создание кода в пять раз, чтобы затем вручную читать его в пять раз больше.
Значит, придётся учиться строить другую систему доверия. Через тесты. Через ограничения. Через независимый review. Через небольшие изменения. Через понятные правила проекта. Через инструменты проверки. И, вероятно, через постепенное изменение собственной роли.
Для меня это пока одна из самых интересных открытых проблем.
И снова появляется ощущение эксперимента
Наверное, именно этого ощущения мне давно не хватало в программировании.
Не новизны технологий — их всегда достаточно. А ощущения, что сам рабочий процесс ещё не устоялся.
Нет одной очевидной схемы. Не очень понятно, насколько большой должна быть задача для агента. Когда нужно вмешиваться. Когда лучше дать ему ещё несколько минут самостоятельно разобраться. Стоит ли одному агенту позволять проверять собственный код. Как хранить инструкции проекта. Как делить работу между несколькими моделями. Как понимать, что результат действительно правильный. Где заканчивается полезная автономность и начинается потеря контроля.
На многие из этих вопросов у меня пока нет окончательных ответов. И это как раз интересно.
Я снова учусь программировать
Только теперь обучение выглядит немного иначе.
Я не читаю очередную книгу «PHP за 21 день». Не изучаю новый MVC-framework. Не пытаюсь запомнить API новой библиотеки.
Я экспериментирую с тем, как декомпозировать задачи для AI. Как передавать ему контекст. Как заставлять сначала исследовать, а потом реализовывать. Как проверять результат. Как использовать несколько агентов. Как строить процесс, в котором AI может работать достаточно самостоятельно, но при этом не превращается в генератор очень убедительных ошибок.
И самое интересное — всё это происходит поверх тех знаний, которые уже накоплены за годы разработки.
Получается странная комбинация: ты опытный разработчик и одновременно снова новичок.
И, пожалуй, именно поэтому сейчас особенно интересно заниматься программированием. Потому что приходится заново отвечать на вопрос, который когда-то казался давно закрытым:
А как вообще нужно писать software?
