Привет, Хабр! Меня зовут Илья Благородов, я 30 лет в разработке, в том числе — выступаю экспертом в онлайн-магистратуре «Фронтенд-, бэкенд-разработка и ИИ-решения» ИТМО в партнёрстве с Яндекс Практикумом. В этой статье я хочу поговорить о том, как я использую ИИ в разработке и почему, несмотря на это, больше программирую. А ещё — чем IDE отличается от ИИ и почему ИИ не заменит хороших специалистов.

Что изменилось в работе с ИИ в 2026 году

Последние полгода я почти ежедневно работаю с Cursor и Claude Code. До этого я тоже использовал ChatGPT для разработки, но скорее точечно: написать отдельную функцию, помочь с ошибкой, подсказать решение, сгенерировать регулярное выражение или объяснить странное поведение кода.

С февраля этого года мой рабочий процесс изменился гораздо сильнее. Сейчас примерно 80% работы я выполняю с помощью ИИ-инструментов. На простых задачах почти не требуется ручная правка кода: CRUD-обработчики, бизнес-логика по заранее описанному алгоритму, тесты, документация, прототипы интерфейсов, админ-панели, конфигурационные файлы — всё это ИИ делает быстро и зачастую достаточно качественно.

И знаете, какой вывод оказался самым неожиданным? Я стал писать меньше кода. Но программировать пришлось гораздо больше.

Почему писать код и программировать — не одно и то же

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

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

• Написание кода — это создание конкретных файлов, функций, классов, компонентов, SQL-запросов, конфигураций.

• Программирование — это понимание задачи, бизнес-логики, архитектуры, ограничений проекта, возможных последствий изменений и способов проверки результата.

ИИ действительно всё лучше пишет код. Иногда очень хорошо. Иногда быстрее и аккуратнее человека. Но это не означает, что он взял на себя всю разработку. На практике он забрал значительную часть рутинного написания кода, но не снял с разработчика ответственность за систему. В онлайн-магистратуре «Фронтенд-, бэкенд-разработка и ИИ-решения» мы учим работать с ИИ-инструментами: делегировать им создание кода, дебаггинг, написание тестов и документации. И, конечно, проверять актуальность написанного кода. Это — неотъемлемая часть работы разработчика в 2026 году. 

Вайбкодинг и агентная разработка — разные вещи

Мне кажется важным разделять вайбкодинг и агентную разработку. Вайбкодинг — это когда человек с помощью ИИ быстро собирает прототип приложения, MVP, лендинг, простой сервис или демонстрационную версию продукта. Часто без глубокого понимания архитектуры, кода и внутреннего устройства системы.

И это не плохо.

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

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

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

Агентная разработка — совсем другая история. Это инструмент профессионального разработчика. ИИ в таком процессе становится помощником, которому можно поручать части работы. Но его нужно контролировать на всех этапах. Если этого не делать, через некоторое время проект может превратиться в набор несвязанных решений, бойлерплейта и случайных архитектурных подходов. Код вроде бы будет работать, но развивать его станет всё сложнее. В какой-то момент стоимость внесения изменений может превысить стоимость создания нового проекта с тем же функционалом.

IDE и ИИ: в чём разница

Я застал времена, когда код писали в обычных текстовых редакторах без нормальной подсветки, автодополнения и удобной навигации по проекту. Когда появились IDE (Integrated Development Environment, интегрированная среда разработки, в которую входят разные инструменты для создания кода), многие тоже говорили, что это уже не настоящая разработка. Мол, редактор тебе подсказывает, сам дописывает методы, помогает с рефакторингом — значит, разработчик становится слабее.

Сейчас это выглядит странно. Никто не считает использование IDE признаком непрофессионализма. Наоборот, это базовый инструмент разработчика.

С ИИ происходит похожая история, только масштаб другой. IDE подсказывала метод — ИИ может написать сервис. IDE помогала найти определение класса — ИИ может предложить план изменений в большом проекте. IDE ускоряла рутину — ИИ берёт на себя значительную часть механической работы. Но принцип остался тем же: инструмент не снимает ответственность с разработчика. Если ИИ сгенерировал плохой код, виноват не ИИ. В проект попадёт не «код нейросети», а код, который разработчик принял, не проверил и разрешил использовать.

Что ИИ действительно делает хорошо

По моему опыту, ИИ уже очень хорошо справляется с рутинными и хорошо формализуемыми задачами. Например:

• генерация CRUD;

• написание тестов;

• рефакторинг кода;

• написание документации;

• создание точечных функций;

• регулярные выражения, SQL код;

• алгоритмы по понятному описанию;

• конфигурационные файлы для деплоя;

• прототипы интерфейсов;

• админ-панели без сложного дизайна;

• исправление типовых ошибок.

Особенно впечатляет способность ИИ разбираться в большом количестве кода и формулировать план изменений по достаточно простому описанию задачи. Раньше на это могло уйти много времени: открыть несколько файлов, понять зависимости, найти места, где нужно внести изменения, проверить, что ничего не забыто. Сейчас ИИ способен быстро собрать контекст и предложить первичный план. Это не значит, что план всегда правильный. Но как стартовая точка он часто очень полезен.

Что ИИ пока делает плохо

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

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

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

• бизнес-логику;

• архитектурные ограничения;

• существующие паттерны проекта;

• структуру базы данных;

• какие файлы можно менять;

• какие подходы нельзя использовать;

• какие решения уже существуют в проекте;

• какие тесты должны пройти после изменений.

ИИ может быть очень сильным исполнителем. Но он не должен становиться бесконтрольным архитектором проекта.

Как я работаю с ИИ сегодня

Сегодня мой рабочий процесс выглядит примерно так.

1. Получаю задачу.

2. Изучаю бизнес-логику, которую нужно изменить или создать.

3. Декомпозирую задачу, если она достаточно большая.

4. Планирую изменения.

5. Даю агенту небольшой объём работы по плану.

6. Проверяю результат.

7. Корректирую архитектуру.

8. Запускаю тесты.

9. Провожу код-ревью с помощью ИИ в нескольких разных моделях.

10. Повторяю цикл.

Если посмотреть на этот список внимательно, становится заметно: написание кода занимает в нём далеко не главное место. Основная работа — понять задачу, правильно её разложить, выбрать архитектурный подход, направить агента, проверить результат и не дать проекту превратиться в набор случайных решений. Всё это студенты тоже изучают в онлайн-магистратуре «Фронтенд-, бэкенд-разработка и ИИ-решения». 

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

Почему учиться программировать стало не менее, а более важно

На первый взгляд может показаться, что если ИИ пишет код, то учить язык программирования уже не обязательно. На практике всё наоборот. Чем больше кода пишет ИИ, тем важнее уметь этот код читать, понимать и проверять. Если разработчик не знает язык, стек, архитектурные паттерны и принципы проектирования, он не сможет отличить хорошее решение от плохого. Он будет принимать на веру всё, что сгенерировала модель. А это опасно.

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

Более того, теперь это стало сложнее. У начинающего разработчика появляется соблазн отдать ИИ вообще всё: задачу, решение, код, проверку, объяснение. Но если человек не научился создавать системы без ИИ, ему будет сложно управлять ИИ как инструментом. Он не будет понимать, где модель помогает, а где ведёт проект в неправильную сторону.

Как изменилась роль разработчика

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

• хорошо понимать бизнес-логику;

• видеть архитектуру проекта;

• декомпозировать задачи;

• формулировать алгоритмы;

• ставить задачи агентам;

• контролировать результат;

• знать промпт-инжиниринг и исправлять ошибки ИИ;

• проводить ревью;

• думать о развитии системы.

Сегодня разработчики стали ближе к архитекторам, системным аналитикам и техническим владельцам решений, чем к кодерам в старом смысле слова. И это, на мой взгляд, главный сдвиг. ИИ не просто ускорил написание кода, он изменил центр тяжести профессии. Программа онлайн-магистратуры «Фронтенд-, бэкенд-разработка и ИИ-решения» учитывает это фундаментальное изменение и составлена таким образом, чтобы навыки выпускников соответствовали требованиям рынка.

Кого я выберу: сильного программиста без ИИ или менее сильного, но умеющего работать с ИИ

Если представить двух кандидатов, где первый идеально знает язык, но не использует ИИ, а второй знает язык слабее, но великолепно работает с ИИ, я выберу второго. Не потому, что знание языка больше не важно. Оно важно. Но ИИ — это уже данность. Это конкурентное преимущество, которое постепенно станет стандартом.

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

Конечно, есть важное условие: он должен понимать, что делает. Если человек просто копирует ответы модели, это не профессиональная работа. Но если он умеет использовать ИИ как усилитель собственных инженерных навыков, это очень сильное преимущество.

Как ИИ делает код лучше

Обычно про ИИ говорят в контексте скорости. Мол, раньше задача занимала день, теперь занимает два часа. Это правда. Но для меня не менее важным оказалось другое: код может становиться качественнее. Я стал писать больше тестов. Быстрее разбираться в проблемных ситуациях. Чаще формулировать алгоритмы до начала реализации. Больше времени уделять проектированию.

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

Но снова важное уточнение: это работает только при контроле со стороны разработчика. ИИ может улучшить качество кода, если разработчик понимает, что именно он проверяет. И может ухудшить проект, если разработчик перестал быть ответственным за результат.

Что должен изучать начинающий разработчик в 2026 году

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

• язык программирования;

• структуры данных;

• работу с базами данных;

• Git, Docker и Linux;

• HTTP и API;

• основы архитектуры;

• тестирование;

• отладку;

• работу приложения в продакшене.

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

• декомпозировать задачи;

• формулировать требования;

• описывать ограничения;

• проверять результат;

• читать сгенерированный код;

• искать ошибки;

• понимать, почему решение хорошее или плохое.

ИИ не отменяет обучение. Он меняет его структуру. Раньше новичок учился писать всё руками. Теперь он должен учиться писать руками и параллельно учиться управлять инструментом, который может писать быстрее него. Все вышеперечисленные навыки входят в программу онлайн-магистратуры «Фронтенд-, бэкенд-разработка и ИИ-решения».

Что будет дальше

Я не знаю, до какого уровня дойдут инструменты разработки через пять или десять лет. Вполне возможно, что ИИ сможет решать всё более крупные задачи по простым промптам и сам вносить изменения по всему проекту. Но чем сильнее станут инструменты, тем важнее будет навык контроля за системой. Кто-то должен понимать, что происходит внутри проекта, направлять развитие архитектуры, видеть связь между бизнес-задачей, кодом, инфраструктурой, безопасностью и поддержкой продукта. Если этот человек исчезнет, проект быстро превратится в набор автоматических решений, которые никто по-настоящему не понимает.

Вместо заключения

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

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

Поэтому вопрос «зачем учиться программировать, если ИИ уже пишет код?» поставлен не совсем правильно. Правильнее спросить иначе: если ИИ уже пишет код, кто будет понимать, что именно он пишет, зачем он это пишет и можно ли это вообще выпускать в продакшен? Вот для этого хорошие разработчики всё ещё нужны. И, возможно, будут нужны ещё больше, чем раньше.