ИИ уже вполне способен писать функции, обнаруживать ошибки, менять файлы, оборачивать код тестами и самостоятельно запускать команды. Современный агент может даже изучить ваш репозиторий, внести необходимые изменения, прогнать проверки и самостоятельно подготовить pull request. А значит злободневный вопрос «может ли ИИ написать код?» постепенно теряет смысл. Может, и не только это.
Вопрос в том, что теперь должен уметь разработчик, чтобы ИИ-автоматизация действительно экономила время и приносила пользу? А не только генерировала килотонны кода, который потом придётся бесконечно проверять, переписывать и поддерживать. Разбираем семь навыков разработчика, которые выросли в цене, — на данных Anthropic, Microsoft, Carnegie Mellon и работ MSR 2026.
Исследования последних двух лет показывают довольно занятную картину. Чем больше берет на себя модель, тем востребованнее навыки, которые находятся до и после непосредственного написания кода. Речь про понимание задачи, декомпозицию, управление контекстом, выстраивание архитектуры, проверку результата, обеспечение безопасности и настройку самих агентов.
Сооснователь Хекслета Кирилл Мокевнин сравнил происходящее с промышленностью. Раньше люди выполняли операции на конвейере самостоятельно. После автоматизации они занимаются настройкой, контролем, ремонтом и оптимизацией системы. В программировании происходит что-то похожее: разработчик может меньше писать руками, но для этого ему нужно лучше понимать процесс целиком.
Чем больше знает разработчик, тем эффективнее работает агент
На первый взгляд, можно ожидать обратного эффекта: чем сильнее становятся агенты для кодинга, тем меньшую роль должны играть знания самого пользователя.
Но это не так. Свежий анализ Anthropic показывает обратную зависимость. В июне 2026 года компания опубликовала исследование 400 000 сессий Claude Code от 235 000 пользователей, собранных с октября 2025-го по апрель 2026 года. Исследователи обнаружили разделение труда: человек чаще принимал решения о том, что нужно сделать, а агент — о том, как это реализовать. При этом пользователи с большей экспертизой чаще получали успешный результат, а агент под их управлением выполнял больше работы на одну инструкцию.
Выходит, чем лучше специалист понимает проект и знает предметную область, тем больше работы может осмысленно делегировать модели и тем меньше ему в итоге приходится писать код самостоятельно.
Так какие навыки нужны разработчикам в 2026-2027 году, когда нейросети уже взяли на себя часть работы с кодом?
Навык 1. Ставить задачу агенту так, чтобы результат можно было проверить
Агента можно попросить, например, исправить авторизацию. Но если человек давно работающий с продуктом сразу поймет о чем речь, то агент начнет выяснять подробности: где именно ошибка, какое поведение ожидается, какие компоненты нужно изменить, какие ограничения сохранить, каким должен быть результат.
В исследовании CodeScout: Contextual Problem Statement Enhancement for Software Agents, опубликованном в Findings of ACL 2026, исследователи проверили, насколько сильно результат агента зависит от качества исходной постановки задачи.
Перед тем, как выполнить задачу CodeScout сначала исследовал релевантный контекст кодовой базы, а затем превращал исходный запрос в подробное техническое описание: добавлял ожидаемое поведение, шаги воспроизведения проблемы и подсказки, какие части проекта стоит проверить.
На SWE-bench Verified такой подход привел к 20% улучшению resolution rate относительно базового метода, а в отдельных конфигурациях позволил решить до 27 дополнительных задач. То есть, качество результата выросло после улучшения постановки задачи.
Резюмируем: один из важнейших AI-навыков разработчика очень похож на старую добрую инженерию требований (requirements engineering). Нужно суметь распознать текущее и определить ожидаемое поведение, учесть и обозначить ограничения, допустимую область изменений и критерии готовности. Просто попросить сделать обработку ошибок лучше — плохая постановка задачи для агента. Запрос лучше сформулировать конкретнее. Например, при недоступности внешнего API выполнить три попытки с экспоненциальной задержкой, после чего вернуть текущий тип ошибки; формат публичного API при этом не менять, существующие интеграционные тесты должны проходить. Результат поставленной таким образом задачи уже гораздо легче проверить и оценить.
Навык 2. Управлять контекстом: AGENTS.md, CLAUDE.md и project rules
Уже после первых экспериментов с LLM появился популярный совет: чем больше модель знает о проекте, тем лучше. Из этой рекомендации появились AGENTS.md, CLAUDE.md, project rules и другие файлы, куда команды загружают архитектурные правила, команды запуска, соглашения и особенности проекта.
Но в связи между объемом контекста и качеством работы агента все не так просто. Исследователи ETH Zürich проверили файлы контекста уровня репозитория на нескольких моделях и кодовых агентах. Согласно анализу, в совокупности контекстные файлы не улучшили успешность решения задач сами по себе, зато увеличили стоимость инференса более чем на 20%. При этом автоматически сгенерированные файлы в среднем немного ухудшали результат, а написанные разработчиками давали небольшое улучшение. Но суть в том, что и те, и другие заставляли агентов активнее исследовать репозиторий, читать файлы и запускать проверки.
Чтобы и пользу получить, и не потратить кучу денег эксперты советуют оставлять в контекстных файлах минимальный набор действительно важных требований и не перегружать агента избыточными инструкциями. Релевантного контекста должно быть правильное количество, не нужно загружать агентов огромным массивом информации.
Разработчик должен уметь сообщить модели заранее, что она может обнаружить в репозитории сама, какие правила — глобальные, а какие относятся только к текущей задаче. Так и проектируется корректная информационная среда, в которой агент не тонет.
Навык 3. Декомпозировать задачу и работать с агентом итеративно
Когда задача разрастается и становится очень большой, для агента это может оказаться проблемой. Конечно, современные модели технически способны пройтись по десяткам файлов и внести изменения в каждый самостоятельно. Но когда нужно выполнить автономно длинную цепочку действий, это не значит, что нужно сразу передать ему всю работу целиком.
Исследователи Microsoft в работе Why AI Agents Still Need You: Findings from Developer-Agent Collaborations in the Wild наблюдали за 19 разработчиками, которые с помощью агента решали 33 реальные задачи в репозиториях, куда раньше вносили изменения самостоятельно.
Около половины задач удалось решить с помощью агентов. Но при этом участники, двигавшиеся пошагово, справлялись лучше пользователей, пытавшихся решить issue одним большим запросом. Успешно справились и те, кто активно взаимодействовал с агентом, оценивал промежуточные результаты и корректировал направление работы. В числе сложностей участники называли доверие к ответам агента, совместную отладку и тестирование.
Известный в инженерной среде совет «есть слона по частям» актуален и в случае с агентами. Сложную задачу по-прежнему полезно разбивать на небольшие кусочки.
Сперва стоит локализовать проблему, затем определить ожидаемое поведение и ограничить область изменений. Далее изменяем код, проверяем гипотезу, запускаем тесты и только после этого переходим к следующей части.
Агент способен выполнить многие виды операций, но порой ему не под силу увидеть структуру задачи целиком.
Навык 4. Понимать архитектуру и системный дизайн
Изолированный кусок кода модель часто действительно пишет хорошо. Но как только это становится не просто кодом, а появляются усложнения: пользователи, данные, интеграции, миграции, безопасность и отказоустойчивость, все меняется. Задача может оказаться агенту не по зубам.
Ценность системного дизайна как навыка в результате растет. Специалист должен понимать, что произойдет при падении сервера, как и куда сохранятся данные, выдержит ли система рост нагрузки или нужно наращивать мощности, нужны ли отдельные сервисы. И вообще, а как очередное изменение отразится на других компонентах?
Исследование Carnegie Mellon University Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects, опубликованное на MSR 2026, это иллюстрирует. Авторы сравнили GitHub-проекты, использовавшие современный Cursor, с контрольной группой.
После внедрения Cursor число добавляемых строк выросло в среднем на 28,58%, но одновременно число предупреждений статического анализа увеличилось на 30,26%, а сложность кода возросла на 41,64%. Рост скорости оказался краткосрочным, а усложнение — нет.
Получается, скорость производства кода может расти быстрее, чем команды способны контролировать последствия. В такой ситуации архитектурное мышление становится критически важным. Преимущество уже не в том, чтобы быстро «родить» новую функцию, а в том, чтобы понимать, а нужна ли она вообще здесь, не дублирует ли логику, не создает ли ненужную связанность? Потому что несмотря на все навыки ИИ, стоимость неверного архитектурного решения по-прежнему высока.
Кстати, 14 сентября Хекслет проведет бесплатный воркшоп по системному дизайну: на реальном кейсе разберем путь от требований и оценки нагрузки до выбора архитектуры, SLA, масштабируемости и защиты принятых решений. Подробнее о том, почему этот навык подорожал именно сейчас, — в разборе «Системный дизайн: почему ИИ не заменил разработчиков».
Навык 5. Использовать ИИ для тестов, но стратегию определять самому
Тестирование — хороший пример задачи, где агенты уже взяли на себя заметную часть работы. В исследовании Testing with AI Agents: An Empirical Study of Test Generation Frequency, Quality, and Coverage, представленном на MSR 2026, авторы изучили 2232 коммита с изменениями тестов из реальных репозиториев.
ИИ оказался автором 16,4% коммитов, которые добавляли тесты. Сгенерированные агентами тестовые методы обычно были длиннее и содержали больше утверждений, но имели более линейную структуру. При этом вклад ИИ-тестов в покрытие кода в исследованных проектах оказался сопоставимым с теми, что написали люди. Это означает, что генерацию тестов уже вполне можно хотя бы частично автоматизировать. Но важно другое: агенту не стоит полностью отдавать на откуп решение, что именно нужно тестировать.
В другой работе MSR 2026 — Are Coding Agents Generating Over-Mocked Tests? Исследователи проанализировали более 1,2 млн коммитов в 2168 TypeScript-, JavaScript- и Python-репозиториях, включая 48 563 коммита агентов.
Агенты затрагивали тестовые файлы в 23% своих коммитов, остальные авторы — в 13%. Но моки агенты тоже добавляли чаще: в 36% соответствующих коммитов против 26%. Тесты с моками могут быть проще для автоматической генерации, но потенциально хуже проверяют реальные взаимодействия компонентов.
Поэтому на плечи разработчика ложится ответственность решать, какой именно способ тестирования нужен и что именно важно проверить.
Навык 6. Проверять результат независимо от LLM: ревью и безопасность
Очень соблазнительным кажется построить полностью замкнутый AI-процесс. Один агент написал код, второй сделал ревью, первый исправил замечания, и вот несколько таких циклов и задача кажется законченной.
Но ни одна языковая модель не является автоматически независимым источником истины. Особенно хорошо это заметно в сфере безопасности. На Canadian Conference on Artificial Intelligence 2026 исследователи Amena Amro и Manar Alalfi представили работу GitHub’s Copilot Code Review: Can AI Spot Security Flaws Before You Commit? В исследовании проверяли Copilot Code Review на размеченных уязвимых примерах из реальных open-source-проектов.
В результате выяснилось, что система регулярно пропускала критические классы проблем, включая SQL-инъекции, межсайтовый скриптинг и небезопасную десериализацию. Хотя значительная часть замечаний касалась скорее стиля или опечаток, даже несколько упущенных серьезных проблем создают риски. Авторы сделали вывод, что ИИ-ревью обязательно нужно дополнять специализированными инструментами безопасности и ручным аудитом. Для ИИ-разработчика важно уметь превращать требования в машинно проверяемые ограничения, и это тоже навык и отдельное искусство, позволяющее автоматизировать процессы с умом.
Практику работы с ИИ в коде мы собрали в курсах ИИ для разработчиков и Вайб-кодинг с Claude Code.П
Вайбкодинг и инженерия: где проходит граница
Термин «вайбкодинг» закрепился за практикой, когда человек описывает результат словами и принимает то, что выдала модель, не вчитываясь в код. Как способ быстро собрать прототип или проверить гипотезу, это работает. Как способ вести продакшен — нет, и исследование Carnegie Mellon выше показывает, почему: скорость растёт сразу, сложность и предупреждения статического анализа — тоже, но позже за это придется расплачиваться.
Разница не в инструменте, а в том, остается ли человек в контуре проверки. Один и тот же Claude Code или Cursor может использоваться и для вайбкодинга, и для нормальной инженерной работой — зависит от того, есть ли постановка задачи с критериями готовности, тесты, ревью и понимание архитектуры. Собственно, об этом все семь навыков выше.
Навык 7. Настраивать среду агента: MCP, субагенты и скиллы
Понимание, что означает уметь пользоваться ИИ, тоже быстро меняется. Еще недавно это означало использовать правильную модель и хороший промпт. Сегодня агенты для кодинга получают постоянный контекст, доступ к терминалу, инструментам и внешним системам. Появляются субагенты, MCP-интеграции и многоагентные workflow.
Насколько далеко эта практика уже распространилась, исследователи изучили в работе Configuring Agentic AI Coding Tools: An Exploratory Study. Авторы изучили конфигурации Claude Code, GitHub Copilot, Cursor, Gemini и Codex в тысячах GitHub-репозиториев и выделили восемь механизмов настройки. Чаще всего используются контекстные файлы; более сложные возможности вроде скиллов и субагентов пока применяются реже и довольно поверхностно. Вокруг разных инструментов уже начинают появляться собственные практики конфигурации. Как устроена такая обвязка изнутри, мы разбирали в материале «Анатомия агентного харнесса». А если хочется собрать агента руками и увидеть цикл целиком, есть разбор с рабочим кодом: «Как создать ИИ-агента на Python».
Помимо собственных инженерных знаний программисту нужно суметь построить вокруг себя систему, которая позволяет агентам эффективно работать с кодом.
Обязательно ли программисту самому писать код, если есть ИИ?
Профессионал может постоянно пользоваться ИИ и писать руками намного меньше, но все равно должен быть способен понять и реализовать то, что генерирует модель. Иначе код быстро превращается в черный ящик, которым человек не способен управлять.
Базовые проблемы программной инженерии от появления LLM никуда не делись. По-прежнему существуют транзакции, конкурентный доступ, сетевые ошибки, права пользователей, миграции данных, отказ серверов, внешние API и безопасность.
Поэтому и фундамент не меняется. Это понимание TCP/IP, интернета, баз данных, серверов и архитектуры кода. Без этого разработчик не сможет надежно оценить последствия решения, предложенного агентом. Нужно понимать систему достаточно хорошо, чтобы поставить задачу, выбрать допустимое решение и отличить рабочий результат от убедительно выглядящего неправильного.
Разработчик по-прежнему создает обычные приложения и сервисы, но часть работы передает агентам: исследование кодовой базы, реализацию, дебаг, рефакторинг, тестирование, документацию, ревью и отдельные этапы CI/CD.
Именно на этом построена программа Хекслета «ИИ для разработчиков 2.0». В нее включили устройство агентов и их обвязки, MCP и память, контекст: контроль разрешений, Spec Driven Development, верификацию результата, адаптацию проекта под агента, интеграцию ИИ в SDLC, субагенты и мультиагентные пайплайны. Курс рассчитан на бэкенд-, фронтенд- и фуллстек-разработчиков, тимлидов, техлидов и других специалистов, которые уже работают с кодом; требуется владеть хотя бы одним языком программирования, Git и командной строкой.
А еще программист может попробовать самостоятельно создавать продукты и сервисы на базе больших языковых моделей. Тут разработчик уже работает не просто с кодовых агентов в своей IDE, а проектирует AI-функциональность для пользователей и бизнеса: подключает LLM через API, строит RAG, организует вызов инструментов и MCP-интеграции, проектирует агентов и workflow, занимается оценкой качества, защитой от промпт-инъекций, human-in-the-loop, стоимостью токенов и выводом решений в продакшен.
Этому посвящен курс Хекслета «LLM-разработчик». Программа рассчитана на действующих бэкенд-, фронтенд-, Python-разработчиков, тимлидов, архитекторов, DevOps- и ML-инженеров и сфокусирована на инженерной стороне LLM-продуктов: от API и RAG до агентов, безопасности и продакшн-практик. Как это выглядит на стороне бизнеса, показывали в материале «ИИ-агенты и RAG: как компании внедряют LLM в бизнес-процессы».
Коротко: ответы на частые вопросы
Заменит ли ИИ программистов? Нет, но меняет содержание работы. Написание типового кода дешевеет, а постановка задачи, проектирование системы и проверка результата — дорожают.
Исследование Anthropic на 400 000 сессий Claude Code показало разделение труда: человек решает, что делать, агент — как это реализовать, и чем выше экспертиза человека, тем больше работы агент выполняет за одну инструкцию.
Какие навыки нужны разработчику в 2026 году? Постановка задачи с проверяемыми критериями, управление контекстом, декомпозиция, архитектура и системный дизайн, стратегия тестирования, независимая проверка результата и настройка среды агента. Фундамент при этом не меняется: сети, базы данных, серверы, безопасность.
Что такое вайб-кодинг и можно ли так работать? Это подход, когда человек описывает результат словами и принимает вывод модели, не вчитываясь в код. Для прототипа годится, для продакшена — нет: в исследовании Carnegie Mellon после внедрения Cursor объём кода вырос на 28,6%, но предупреждения статического анализа на 30,3%, а сложность на 41,6%.
Нужно ли уметь писать код самому, если есть ИИ? Нужно. Иначе код превращается в чёрный ящик: попросить модель что-то изменить можно, а оценить последствия — нет.