AI для разработки

AI для разработки: как нейросети меняют инженерную работу

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

15 июля 2026 г.·30 мин чтения·

Как AI меняет роль разработчика: от кодера к архитектору

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

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

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

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

Дальше в этом материале разбираю, что конкретно изменилось в инженерной работе: как выбирать инструменты, как тестировать и рефакторить с AI, что происходит с адаптацией новых людей в команде, техдолгом и наймом, и куда движется сама профессия. Практику работы конкретно с Claude Code (настройка, CLAUDE.md, ревью агентного кода) я разбираю отдельно в материале про AI-ассистентов в разработке. Здесь картина шире: вся дисциплина целиком, а не один конкретный инструмент.

Рынок AI-инструментов для разработки

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

Автодополнение следующей строки, вроде классического GitHub Copilot в его первоначальном виде, ускоряет набор текста, но не берёт на себя постановку задачи. Агентные инструменты, такие как Claude Code, Cursor в агентном режиме или Windsurf, получают задачу целиком на естественном языке и сами решают, какие файлы менять. Специализированные помощники для отдельных задач (генерация тестов, ревью кода, миграции) обычно точнее в своей узкой нише, но требуют интеграции нескольких инструментов вместо одного универсального.

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

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

Разные роли внутри команды тоже выигрывают от AI неодинаково. Backend-разработчику, работающему с чётко специфицированным API, agentic-инструмент часто даёт больше автономии, чем frontend-разработчику, который постоянно сверяется с визуальным результатом и требует более тесной, короткими итерациями, обратной связи. Это не повод отказываться от инструмента для одной из ролей, а повод настраивать режим работы (глубину автономии, длину итерации) отдельно под специфику задачи, а не одинаково для всей команды.

DevOps и инфраструктурная работа заслуживают отдельного упоминания именно из-за высокой цены ошибки. Автономная правка конфигурации продакшен-кластера или скрипта деплоя несёт совершенно другой уровень риска, чем автономная правка внутренней утилиты, даже если формально это одна и та же категория "инфраструктурный код". Здесь оправдана заметно более консервативная настройка автономии, чем в среднем по команде, независимо от того, насколько хорошо агент справляется с аналогичными задачами в менее критичных частях системы.

Промпт-инжиниринг для разработчиков: рабочие паттерны

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

Несколько паттернов, которые стабильно работают:

Контекст перед задачей, а не после. Модель обрабатывает информацию последовательно: если сначала дать контекст (какой файл, какая часть системы, какие есть ограничения), а потом саму задачу, результат точнее, чем в обратном порядке.
Явное указание, чего не делать. "Не трогай файлы конфигурации", "не меняй публичный API" отсекают самые частые нежелательные побочные эффекты автономной правки.
Просьба объяснить план перед выполнением для задач выше средней сложности. Пара секунд на чтение плана экономит куда больше времени, чем разбор неправильно выполненной задачи.
Конкретный критерий готовности. "Задача выполнена, когда все тесты проходят и линтер не выдаёт ошибок" работает лучше, чем открытое "сделай хорошо".

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

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

Пример того, как это выглядит на практике, слабая и сильная версия одной и той же задачи:

Слабо: почини баг с авторизацией.

Сильно: в файле auth/middleware.rs пользователи с истёкшим токеном
получают 500 ошибку вместо ожидаемой 401. Воспроизводится: залогиниться,
подождать истечения токена (или вручную протухшую дату в базе),
обратиться к любому защищённому эндпоинту. Ожидаемое поведение:
middleware должен вернуть 401 с телом {"error": "token_expired"}
до того, как запрос дойдёт до хендлера. Не трогай логику самого
хендлера, проблема именно в middleware.

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

Соло-разработка с AI: как один инженер делает работу команды

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

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

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

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

Есть и менее очевидная сторона соло-разработки с AI: пропадает встроенный механизм проверки, который в команде обеспечивался просто наличием других людей. В команде из трёх человек странное архитектурное решение обычно ловится на созвоне или в pull request раньше, чем закрепится в проекте. Соло-разработчик с агентом легко может месяцами двигаться в направлении, которое команда бы остановила на первой неделе, просто потому что некому сказать "погоди, а зачем мы вообще так делаем". Компенсировать это можно осознанно: периодически показывать код кому-то со стороны, вести публичный блог о технических решениях (что дисциплинирует само по себе, см. материал про второй мозг и digital garden), или хотя бы формулировать архитектурные решения вслух агенту и просить явно покритиковать их, а не просто одобрить.

AI и legacy-код: как рефакторить с помощью нейросетей

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

Рабочий подход к рефакторингу legacy-кода с AI:

Сначала объяснение, потом изменение. Попроси модель объяснить, что делает конкретный кусок кода и почему, прежде чем что-то менять. Часто выясняется, что код делает не то, что предполагалось по названию функции.
Тесты для текущего поведения перед рефакторингом. Если тестов нет, первая задача агенту — написать их для того, что код делает сейчас, а не для того, что он должен делать по идее. Это фиксирует базовую линию, от которой можно безопасно отталкиваться.
Маленькие шаги с проверкой на каждом. Легаси-код часто держится на неявных зависимостях, и большой рефакторинг разом увеличивает риск сломать что-то незаметное. Пошаговый рефакторинг с прогоном тестов после каждого шага ловит такие поломки раньше.
Явный список того, что не трогать. В легаси часто встречаются намеренные, хоть и странные на вид решения (обходы багов сторонних библиотек, специфичные workaround). Стоит явно спросить, есть ли в существующем коде комментарии или паттерны, указывающие на такие случаи, прежде чем их "улучшать".

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

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

Тестирование с AI: генерация unit-тестов и покрытие

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

Полезная практика: просить тесты на конкретные категории случаев, а не просто "напиши тесты" в общей формулировке. Happy path, граничные значения, ошибочный ввод, поведение при недоступности внешней зависимости. Модель без явного запроса чаще всего покрывает только happy path, потому что это самый очевидный случай, а именно граничные и ошибочные сценарии обычно и содержат реальные баги.

Отдельно стоит следить за качеством самих тестов, а не только за процентом покрытия. Тест, который проверяет, что функция вызвалась, а не что она вернула правильный результат, формально увеличивает покрытие, но не защищает от регрессий. Быстрая проверка: если закомментировать содержательную часть проверяемой функции, тест должен упасть. Если он всё ещё проходит, это не тест, а иллюзия теста.

Ещё одна практика, которая окупается: попросить агента сгенерировать не только тесты на то, что код должен делать, но и тесты, специально нацеленные на то, чтобы код сломать (fuzzing-подобные крайние значения, неожиданные типы данных, конкурентный доступ там, где это применимо). Модели, которым явно поставили задачу "попробуй сломать эту функцию", генерируют заметно более въедливые тестовые случаи, чем при нейтральной формулировке "напиши тесты", потому что смена роли с "проверяющего" на "атакующего" меняет то, какие сценарии модель вообще рассматривает.

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

AI для документации кода: автоматизация технического письма

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

Что реально работает: генерация первого черновика документации по уже написанному коду (комментарии к функциям, описания API, README для нового модуля) с последующей правкой человеком. Что работает хуже: полностью автоматическая документация без ревью, потому что модель иногда документирует то, что код должен делать по её пониманию, а не то, что он делает на самом деле, особенно если в коде есть скрытые баги или неочевидное поведение.

Практическое правило: документация, сгенерированная AI, требует того же уровня проверки, что и код. Она не освобождена от ошибок просто потому, что это "всего лишь текст".

Особенно опасен один частный случай: документация, которая описывает намерение кода, а не его реальное поведение. Если функция называется validateEmail, но из-за бага пропускает часть некорректных адресов, модель, документирующая по названию и общей структуре, скорее всего опишет корректную валидацию, потому что именно так функция должна работать судя по названию и коду вокруг. Итоговая документация будет чистой, убедительной и неверной одновременно, и именно поэтому документацию критичных частей системы стоит сверять не только с кодом, но и с реальным поведением на тестовых данных, а не только с тем, что код визуально должен делать.

Хорошо работающий частный случай: генерация changelog и release notes из истории коммитов. Здесь риск ошибки ниже (это описательный текст о том, что уже произошло, а не инструкция, которую кто-то будет исполнять), а рутины, наоборот, много, потому что вручную сводить десятки коммитов в связный список изменений для пользователей — одна из самых нелюбимых регулярных задач в любой команде. Единственное условие, чтобы это работало хорошо: сообщения коммитов сами должны быть осмысленными (см. раздел про git-практики в материале про AI-ассистентов), иначе AI просто автоматизирует генерацию бессмысленного текста из бессмысленных исходных данных.

Как AI меняет адаптацию в новом проекте

Вхождение нового человека (или собственное возвращение к проекту после долгого перерыва) традиционно занимало недели на то, чтобы разобраться в структуре, конвенциях и неочевидных решениях. AI сокращает эту фазу заметнее, чем любую другую часть разработки.

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

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

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

AI в code review: что стоит автоматизировать

Автоматизация ревью кода с помощью AI заслуживает отдельного глубокого разбора: инструменты, метрики, где автоматизация реально ловит проблемы, а где создаёт лишний шум. AI code review: как автоматизировать ревью кода разбирает это подробно.

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

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

Риски AI-разработки: технический долг от AI-кода

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

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

Четвёртый источник, менее очевидный, чем первые три: избыточные, никогда не срабатывающие проверки на ошибки. Модели, обученные писать "безопасный" код, склонны добавлять обработку ошибок для случаев, которые в конкретной системе физически не могут произойти, просто потому что в общем случае такая проверка выглядит как хорошая практика. Раздутый код с десятками невозможных веток обработки ошибок не менее опасен, чем код без обработки ошибок вовсе: он маскирует реальную логику под слоем защитного кода, который никогда не понадобится, но который приходится читать и поддерживать при каждом изменении рядом.

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

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

Парное программирование с AI: как это работает на практике

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

Работающий формат: держать роль "штурмана", который постоянно проверяет и направляет, а не роль пассивного наблюдателя за тем, что делает модель. Задавать вопросы по ходу ("почему ты выбрал именно такой подход", "что будет, если условие X"), а не только принимать или отклонять готовый результат постфактум. Это не только страхует от ошибок, но и сохраняет то самое понимание кода, которое легко потерять при полностью пассивном режиме.

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

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

AI-инструменты для дебага: как быстрее находить баги

Дебаг с AI работает лучше всего, когда модель получает конкретные симптомы, а не общую жалобу "что-то не работает". Подробно техника формулировки описана в материале про работу с AI-ассистентами в разработке.

Реальный пример из практики этого самого проекта: генератор слага в CMS транслитерировал заголовки статей неправильно, теряя мягкий и твёрдый знак не там, где нужно, а буквально. Причина оказалась в одной строке: код брал перевод буквы из словаря транслитерации и, если значение оказывалось пустой строкой (а для мягкого и твёрдого знака оно намеренно пустое), откатывался на оригинальный символ вместо пустой строки, потому что пустая строка в JavaScript считается ложным значением. Без конкретного примера сломанного слага AI искал бы проблему долго. С конкретным входом и ожидаемым выходом причина нашлась за один проход.

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

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

Сравнение AI-моделей для кода: Claude, GPT, Gemini

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

Модель	Сильная сторона в коде	Где не так хорош
Claude	Длинный контекст без деградации, аккуратность в многошаговых агентных задачах, реже "додумывает" несуществующий API	Иногда более консервативен в предложениях там, где нужен смелый рефакторинг
GPT	Широкий охват языков и фреймворков, быстрые точечные правки	Может терять контекст в длинных многофайловых сессиях сильнее, чем конкуренты
Gemini	Работа с мультимодальным контентом (скриншоты UI, диаграммы архитектуры) в связке с кодом	Агентные возможности исторически развивались позже, чем у прямых конкурентов

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

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

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

Как AI меняет найм и оценку разработчиков

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

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

Некоторые команды экспериментируют с форматом "реши задачу вместе с AI-ассистентом, как в реальной работе" вместо запрета инструментов на собеседовании. Это точнее отражает рабочую реальность, хотя и требует пересмотра критериев оценки: важно не то, решил ли кандидат задачу (это почти всегда возможно с хорошим агентом), а как именно он направлял процесс и заметил ли ошибки в результате.

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

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

AI-driven разработка: с чего начать команде

Переход команды на agentic-разработку требует больше организационной подготовки, чем кажется на первый взгляд, потому что затрагивает не только инструменты, но и процессы ревью, распределение ответственности и структуру самого репозитория. Архитектура для AI-driven разработки разбирает архитектурную сторону этого перехода подробно.

Практический минимум для старта: единые инструкции для агента на уровне репозитория, а не личные настройки у каждого разработчика по отдельности. Явные правила о том, какие типы изменений требуют повышенного внимания при ревью (см. раздел про технический долг выше). И постепенное расширение области применения, начиная с задач с низкой ценой ошибки (тесты, документация, мелкий рефакторинг), а не сразу с критичной бизнес-логики.

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

Этика и AI-код: как не потерять инженерные навыки

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

Ответ зависит от того, как именно используется AI. Пассивное принятие результата без понимания действительно ведёт к атрофии навыков, тот же паттерн, что описан в статье про обучение с нейросетями применительно к учёбе в целом. Активное использование AI как усилителя, с постоянным ревью, вопросами "почему так" и периодической самостоятельной практикой без ассистента, наоборот, может углублять понимание быстрее, чем работа в одиночку, потому что модель постоянно предлагает альтернативные подходы, о которых разработчик мог не думать сам.

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

Есть и менее обсуждаемая сторона этой же темы: ответственность за код, который формально "написал" не человек. Если агент сгенерировал уязвимость или ошибку, которая привела к инциденту, ответственность за это несёт разработчик, который принял и задеплоил результат, а не инструмент. Это прямое продолжение давно существующего принципа, а не новая этическая норма: инженер отвечает за код, который он выпускает в прод, независимо от того, откуда этот код взялся, скопирован ли он со Stack Overflow, сгенерирован ли автодополнением или написан агентом. Смена инструмента не меняет распределение ответственности.

AI для миграции и апгрейда стека

Миграции (обновление мажорной версии фреймворка, переход на новую библиотеку, смена языка для части системы) традиционно относились к самым нелюбимым задачам в разработке: много механической работы, высокий риск сломать что-то незаметное, и результат, который для бизнеса выглядит как "то же самое, но дольше".

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

Рабочая последовательность для крупной миграции: сначала попросить агента составить полный список всех мест, затронутых изменением, прежде чем менять хоть одну строку. Это даёт реалистичную оценку объёма работы до её начала, а не после, когда уже поздно менять план. Дальше миграцию стоит разбивать на пачки по смысловому признаку (один модуль, одна фича), а не по случайному порядку файлов, чтобы после каждой пачки можно было прогнать полный набор тестов и быть уверенным, что система остаётся рабочей на всём протяжении миграции, а не только в самом конце.

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

Частые ошибки при внедрении AI в разработку

Доверять результату без ревью, потому что "код же работает". Работающий код и правильный код не одно и то же. Код может проходить все тесты и всё равно содержать логическую ошибку, которую тесты не покрывают, или незаметно нарушать конвенции проекта.
Ставить расплывчатые задачи и удивляться расплывчатому результату. Чем меньше контекста и конкретики в постановке, тем сильнее итоговый результат будет отличаться от того, что реально имелось в виду.
Использовать один и тот же диалог для десятков разных задач подряд. Контекст замусоривается так же, как и в обучающих сценариях, и агент начинает путать, о какой части системы вообще идёт речь.
Игнорировать накопление технического долга от AI-кода, потому что каждая отдельная задача выглядит нормально. Дублирование и несогласованность стиля видны только при взгляде на проект целиком, а не на один pull request.
Не давать агенту инструкций проекта, полагаясь на то, что модель сама угадает конвенции по коду вокруг. Иногда угадывает, иногда нет, и разница в качестве результата между явными и неявными инструкциями обычно велика.
Внедрять agentic-инструменты сразу во всей команде без пилота на небольшой её части, из-за чего ошибки конфигурации и неподходящие для конкретного проекта настройки масштабируются на всех сразу, вместо того чтобы быть пойманными и исправленными на малой группе.
Полностью прекращать писать код руками. Периодическая самостоятельная практика без ассистента остаётся единственным надёжным способом проверить, что базовые навыки не атрофировались незаметно.

Экономика: когда AI-разработка реально быстрее

Ускорение от AI-инструментов не универсально, и честная оценка требует признать, где оно реально есть, а где это скорее ощущение, чем измеримый факт.

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

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

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

Будущее профессии разработчика в эпоху AI

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

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

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

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

Куда двигаться дальше

Всё описанное здесь — общая картина того, как AI меняет инженерную работу. Практика конкретно с Claude Code (настройка, инструкции для агента, ревью, границы автономии) разобрана в отдельном материале про AI-ассистентов в разработке.

Если интересна именно автоматизация проверки качества кода, AI code review: как автоматизировать ревью кода разбирает это отдельно и подробно. Если стоит вопрос, как перестроить архитектуру и структуру репозитория под эффективную работу с AI-агентами, а не только процессы, Архитектура для AI-driven разработки продолжает эту тему на техническом уровне. А если интересно, куда движется профессия в целом за пределами конкретных инструментов, AI и будущее инженерной профессии разбирает это без привязки к сегодняшнему стеку технологий.

Заключение

Роль разработчика смещается от написания кода к постановке задач, ревью и архитектурным решениям. Это не отменяет необходимость понимать код, а меняет то, где именно нужно глубокое понимание.
AI даёт наибольший выигрыш там, где раньше уходило больше всего рутинного времени: legacy-код, тестирование, документация, адаптация новых людей в команде, миграции.
Новый тип технического долга (дублирование, несогласованность стиля, код без учёта общего контекста системы) требует такого же осознанного управления, как и любой другой технический долг.
Собственные навыки не деградируют от использования AI автоматически, но и не остаются на месте сами по себе: это зависит от того, работаешь ли ты с моделью активно, с постоянной проверкой и вопросами, или пассивно принимаешь результат не глядя.
Ускорение от AI неравномерно: велико на рутинных, чётко специфицированных задачах и скромно там, где узкое место — само принятие решения, а не написание кода. Оценивать эффект стоит по категориям задач, а не усреднённо по всей работе сразу.
Профессия проходит структурно похожий переход на то, что уже случалось при переходе от ассемблера к языкам высокого уровня: убирается рутина одного уровня абстракции, но не убирается ценность понимания того, что и зачем строится.

Далее по теме

16 июля 2026 г.·4 мин чтения

Почему малые команды выигрывают в скорости разработки

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

AI для разработки

15 июля 2026 г.·30 мин чтения