Писать код стало проще. Строить системы — нет. Именно так считает Кирилл Мокевнин, сооснователь школы программирования Хекслет.
ИИ снизил ценность одного навыка и поднял ценность другого. Разбираемся, почему системный дизайн стал главным умением разработчика — и что об этом говорят данные Anthropic, Stack Overflow, METR и DORA.
Еще недавно умение программировать означало, что ты можешь самостоятельно написать код на одном из языков, знаешь его паттерны и принципы. Сейчас значительную часть этой работы способен выполнить ИИ. Современной модели достаточно описать задачу текстом или даже голосом и попросить создать интерфейс, написать функцию, собрать небольшой сервис. Во многих случаях, в результате вы получите работающий результат.
ИИ-модели действительно снижают порог входа в профессию. Для небольших задач уже можно обойтись минимальными знаниями программирования. Но только до тех пор, пока маленький проект не превращается в систему, которой должны пользоваться другие люди. В этот момент выясняется, что написать код и построить работающий продукт — совсем не одно и то же.
ИИ может писать код лучше вас, но это не главное
Небольшой и изолированный кусок кода — как раз тот тип задачи, с которым современные модели справляются достаточно хорошо. И в этом нет ничего удивительного. Большинство типовых функций, обработчиков, запросов к базе данных или компонентов интерфейса уже множество раз написали до нас. Модель видела огромное количество примеров и может за секунды воспроизвести подходящее решение. Более того, оно может быть правильнее и оптимальнее написанного вручную кода.
В результате, теряется ценность навыка идеально писать каждую строчку кода вручную. Это по-прежнему нужно уметь, но доводить этот скилл до совершенства уже не так важно.
Масштаб происходящего доказывает исследование Anthropic. Компания проанализировала около 500 тысяч взаимодействий пользователей с Claude.ai и Claude Code. В Claude Code 79% диалогов относились к автоматизации, то есть модель самостоятельно выполняла задачу, а не просто помогала человеку ее решить. При этом в 35,8% взаимодействий использовался сценарий с обратной связью: ИИ выполнял работу, человек проверял результат и сообщал об ошибках.
Данные: исследование Anthropic об экономическом эффекте ИИ, выборка ~500 тыс. взаимодействий.
Вот вам и пример как написание кода стремительно автоматизируется. Но только проблема разработки никогда не ограничивалась просто кодом.
Между прототипом и продакшеном — пропасть: что ломается при росте системы
Можно попросить ИИ собрать калькулятор для личного использования, небольшой внутренний инструмент или даже прототип приложения. Но если мы строим систему, которой будут пользоваться другие, она должна надежно работать годами. У такой системы появляются данные. Нужно понимать, как их хранить и удалять, соблюдать требования ужесточившегося законодательства, делать резервные копии и восстанавливаться после ошибок.
Затем проект нужно выкатывать в продакшен, вносить изменения, мигрировать данные, оркестрировать компоненты системы. При этом понимать, что произойдет, если сервер выйдет из строя или отключится от питания, суметь масштабировать проект при росте количества пользователей так, чтоб он выдержал нагрузку. И добавлять новые возможности, не ломая уже существующие. Все эти задачи просто существуют, и продолжат существовать, — независимо от того, кто написал конкретную функцию, человек или языковая модель.
Вайб-кодинг: почему разработчики им пользуются, но не считают работой
Тут уместно рассмотреть само отношение разработчиков к вайб-кодингу. В Developer Survey 2025 Stack Overflow 84% респондентов сообщили, что уже используют ИИ-инструменты в разработке или собираются это делать. При этом 72% участников ответили, что вайб-кодинг, то есть разработка приложения преимущественно через запросы к ИИ-агенту, не входит в их профессиональные обязанности. Получается, активное использование ИИ и отказ от инженерного контроля — совершенно разные вещи. Как выглядит работа с агентом на практике, мы показывали в разборе Claude Code и других агентов.
Есть еще одна особенность генеративного ИИ: плохой результат далеко не всегда выглядит плохим. Код может запускаться, а функция отрабатывать в большинстве кейсов. Но со временем накапливаются небольшие ошибки, поломки, нарушения совместимости. В большом проекте появляются дублирование, неоптимальные решения и зависимости между компонентами системы.
В какой-то момент разработчик попадает в цикл: находит ошибку, просит модель исправить ее, исправление ломает что-то еще, в очереди появляется следующий фикс. Если человек не понимает устройство системы, выбраться из этого замкнутого круга становится все сложнее.
Stack Overflow приводит буквальное подтверждение этой проблемы. В опросе 2025 года 66% разработчиков назвали одной из главных сложностей ИИ решения, выглядящие почти правильными, но содержащие ошибки.
Еще 45% пожаловались, что отладка сгенерированного ИИ кода занимает больше времени, чем самостоятельное написание. Точности результата при этом не доверяют 46% респондентов, а доверяют — 33%. Среди опытных разработчиков скепсис еще выше.
Получается парадоксальная ситуация. Генерация очередного куска кода становится дешевле, зато возрастает значение способности понять, насколько этот код вообще соответствует системе и ожиданиям.
Ускорение написания кода ≠ ускорение разработки: эксперимент METR
Эту разницу демонстрирует эксперимент METR. Исследователи пригласили 16 опытных разработчиков крупных open source-проектов. В среднем эти проекты содержали более миллиона строк кода, а сами участники работали с ними несколько лет. Разработчикам дали 246 реальных задач: исправление ошибок, добавление возможностей и рефакторинг. Часть задач они выполняли с ИИ, часть — без него.
До эксперимента разработчики ожидали, что ИИ сократит время работы примерно на 24%. После эксперимента им по-прежнему казалось, что выигрыш составил около 20%. Но после подсчетов выяснилось, что задачи с использованием доступных на тот момент ИИ-инструментов заняли на 19% дольше.
В августе 2025 года METR запустила новый эксперимент уже с более современными агентными инструментами. В нем участвовали 57 опытных open source-разработчиков с медианой в 10 лет опыта, работавших со 143 репозиториями. Исследователи собрали данные более чем по 800 задачам. Десять участников пришли из первого эксперимента, еще 47 набрали дополнительно.
Сырые результаты на этот раз уже указывали на ускорение на около 4%. Но нашлись проблемы в дизайне исследования. Выяснилось, что по мере распространения Claude Code, Codex и других агентных инструментов разработчики все меньше хотят выполнять часть своей работы без ИИ. От 30% до 50% участников сообщили, что намеренно не отправляли в эксперимент некоторые задачи, потому что не хотели получить условие, при котором задачу придется выполнять без ИИ. Стало сложнее и набирать участников: часть разработчиков вообще отказывалась участвовать, если половину работы нужно было выполнять без ассистентов.
В результате, METR посчитала, что полученная оценка занижает реальный эффект ИИ. А в придачу исследователи обнаружили еще одну проблему: разработчики начали запускать несколько агентов одновременно и заниматься другой работой, пока агент выполняет задачу. При таком подходе простое измерение времени выполнения одной задачи уже не отражает производительность.
ИИ настолько встроился в рабочие процессы, что некоторым разработчикам уже сложно искусственно отделить работу с ИИ от работы без него. При этом способность агента быстрее произвести код по-прежнему не снимает вопросов о том, как этот код встроить в большую систему, проверить его и принять архитектурные решения.
Базовые знания разработчика — по-прежнему must have
Профессиональные разработчики сейчас могут писать вручную заметно меньше кода. Но для эффективной работы они все равно должны уметь написать его самостоятельно. Если убрать ИИ, инженер должен понимать, что происходит и как получить такой же результат без ИИ.
Без этого система постепенно становится черным ящиком. Человек в состоянии попросить модель что-то изменить, но не может уверенно оценить последствия этого изменения. Поэтому базовый минимум хорошего разработчика остается неизменным. Нужно понимать, как работают базы данных, сети, серверы и протоколы, разбираться в устройстве приложения и архитектуре кода.
Меняется скорее распределение усилий. Меньше времени можно тратить на оттачивание механического написания небольших участков кода и больше — на понимание того, как устроена система целиком.
Почему системный дизайн вышел на первое место
Если раньше значительная часть работы разработчика находилась внутри кода, сейчас его зона ответственности — на уровень выше. Ему нужно уметь построить приложение, которое выдержит рост нагрузки или отказ одного из компонентов, надежно сохранит данные, переживет разделение системы на подсервисы и добавление новых функций. При этом для любых изменений не понадобится переписывать половину кодовой базы.
Все это — вопросы системного дизайна. И даже самая мощная модель не способна принять подобные решения просто в вакууме. Конечная архитектура зависит от особенностей системы: нагрузки, данных, ограничений, стоимости инфраструктуры и требований бизнеса.
Исследование DORA 2025 года пришло к схожему выводу на уровне инженерных команд. Авторы собрали данные почти у 5000 технических специалистов и описывают внедрение ИИ прежде всего как системную проблему. ИИ в этой модели работает как усилитель: сильная инженерная среда позволяет получить больше пользы, а слабые процессы становятся еще более явными.
Согласно данным DORA, около 90% участников уже используют ИИ в работе, а более 80% считают, что он повысил их продуктивность. При этом исследователи все еще обнаруживают отрицательную связь между использованием ИИ и стабильностью поставки изменений.
В DORA выделяют автоматизированное тестирование, зрелую работу с системой контроля версий и быстрые циклы обратной связи как механизмы, позволяющие справляться с увеличившимся потоком изменений. В тоже время команды со слабосвязанной архитектурой и быстрой обратной связью получают больше выгоды, чем команды, зажатые тесно связанными системами и медленными процессами. То есть чем сильнее ускоряется производство кода, тем важнее инфраструктура вокруг него.
Все это не означает, что ИИ усложняет разработку или что от него нужно отказаться. Множество задач он уже заметно упростил. Например, ту же отладку, которая раньше могла отнимать немыслимое количество времени: приходилось последовательно проверять гипотезы и искать причину того, почему что-то не работает. ИИ ускоряет этот процесс в разы: находит и объясняет ошибку, предполагает возможную причину, помогает локализовать проблему.
Можно провести аналогию с современным заводом. Когда-то большую часть операций непосредственно выполняли люди на конвейере. Сейчас значительную часть делают машины, а специалисты проектируют производственную систему, настраивают ее, чинят, обновляют и оптимизируют.
В разработке происходит похожее движение. Вместо того чтобы вручную писать каждую функцию, инженер все чаще строит среду, в которой код создают агенты. Как устроена такая обвязка изнутри — в материале Анатомия агентного харнесса. А если хочется собрать агента руками, есть разбор с рабочим кодом: Как создать ИИ-агента на Python. Инженер теперь определяет процессы и рамки, задает необходимый контекст, проверяет результаты и постепенно улучшает систему вокруг.
По умолчанию агент далеко не всегда эффективен. Особенно в большом проекте и на большой задаче. Эффективным его делает в том числе среда, которую вокруг него построил разработчик.
Что это значит для программиста: подняться на уровень выше
Постепенно меняется точка приложения инженерных знаний. Когда значительную часть функций можно получить от модели за несколько секунд, конкурентное преимущество все сильнее смещается на иной уровень. Уметь писать код больше недостаточно, важнее способность понять задачу, представить систему целиком, выбрать архитектуру и оценить варианты решений. Чем лучше специалист понимает проект и его структуру, тем эффективнее он может использовать ИИ — и тем меньше кода ему в конечном итоге приходится писать вручную.
Именно этому посвящен бесплатный воркшоп Хекслет по системному дизайну: на реальном кейсе разберем путь от требований и оценки нагрузки до выбора архитектуры, SLA, масштабируемости и защиты принятых решений. А практику работы с ИИ в коде мы собрали в курсах ИИ для разработчиков и Вайбкодинг с Claude Code.
Коротко: ответы на частые вопросы
Заменит ли ИИ программистов? Нет, но он уже меняет содержание работы. Написание типового кода дешевеет, а проектирование системы, проверка результата и архитектурные решения — дорожают. В опросе Stack Overflow 2025 года 66% разработчиков назвали главной проблемой ИИ решения, которые выглядят почти правильными, но содержат ошибки.
Что такое системный дизайн простыми словами? Проектирование системы целиком: как хранить данные, что произойдёт при отказе сервера, как выдержать рост нагрузки, как добавлять функции, не ломая существующие. Это уровень выше отдельных функций и файлов.
Нужно ли учиться писать код, если есть ИИ? Нужно. Без этого система превращается в чёрный ящик: попросить модель что-то изменить можно, а оценить последствия — нет.
Ускоряет ли ИИ разработку? Не всегда. В эксперименте METR опытные разработчики выполнили задачи с ИИ на 19% дольше, хотя субъективно им казалось, что они ускорились примерно на 20%. Но текущее ускорение в 2026 году оценить сложно, так как в обновленном исследовании разработчики не хотели сравнивать часть задач, чтоб не делать их вручную.