Почему я перестал использовать редакторы кода на основе ИИ — 2026 (взгляд на апрель 2025)

В начале апреля 2025 года я выложил на Хабре перевод заметки Лучано Ноойена «Почему я перестал использовать редакторы кода на основе ИИ» ^[1] (оригинал от 1 апреля 2025 года ^[2]). Перевод я тогда публиковал между ревью: пока агенты писали код для пары проектов, раз в несколько минут проверял диффы и давал уточняющие задания.

В том же посте я писал про наши долгие прогулки на Самуи с другом, очень крутым кодером, на которого я равняюсь — 0xhyperdust ^[3]. Мы много обсуждали, чем станет наше любимое занятие через несколько лет и что делать прямо сейчас, чтобы не потерять востребованность. Основная гипотеза была в том, что через 2–3 года мы станем операторами AI, задача которых — осмысливать глобальную и локальную логику ^[4] проектов, ставить задачи, писать архитектурные участки кода и вмешиваться, когда что-то идёт не так.

Статья Лучано предлагала противоположный взгляд: удалить LLM-интеграции из редактора и обращаться к моделям только вручную, чтобы не растерять навык. В итоге под постом собралось 26 комментариев ^[5] и 303 голоса в опросе о том, сколько программистов останется через пару лет.

Сейчас, в октябре 2026-го, я перечитал и сам перевод, и весь тред под ним.

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

От ИИ-редакторов к обвязкам для агентов

Весной 2025 года для большинства разработчиков «ИИ в кодинге» сводился к автодополнению внутри IDE или к веб-чату, куда копируют куски кода (кстати, @Spinoza0 тогда резонно поправил Лучано в комментариях ^[6], что ещё до выхода ChatGPT в конце 2022 года уже был доступен GPT-3.0).

Почти вся критика ИИ в том треде била именно по автокомплиту и ручному чату. Лучано писал, что из-за Copilot стал забывать ^[7] синтаксис юнит-тестов. @0x6b73ca рассказывал про embedded ^[8]: «Пишу только самостоятельно, нейронки использую часто только для пояснения не понятных нюансов или иногда вместо даташита… а нейронный автокомплит часто вставляет не то что надо и это только раздражает».

Похожий процесс описывал @itstranger ^[9]: от Copilot он отказался, потому что тот не понимает контекста, а в чате с GPT просил генерировать «не больше одного класса/модуля/компонента» и «не переписывать код при каждой правке, а описать кратко только варианты изменения». Иначе при любой ошибке ^[10] модель уходила в цикл: откатите версию модуля, обновите обратно, переустановите, поставьте версию по несуществующей ссылке — хотя баг вообще в другом месте.

На этом фоне @Volodrippa заметил ^[11], что спокойно пишет с ИИ на Rust, Python, JS и Swift, если брать топовые модели, «а не бесплатный веб-gpt и убогий Copilot». А @dmatora оставил комментарий ^[12], который через полтора года читается интереснее самой статьи:

«Большинство людей и компаний пока не понимают как реализовывать потенциал нейросетей на максимум, в частности такие платформы как Cursor используют, скажем, меньше 10% его потенциала (личное оценочное мнение исходя из профессионального опыта ^[13]). Но те немногие кто уже сегодня использует его на полную катушку получают “нечестное” преимущество в конкурентной борьбе».

Тогда оценка «Cursor использует меньше 10% потенциала» казалась смелой. К осени 2026 года стало понятно, о каких 90% шла речь.

Сам редактор кода создавался для человека, который глазами читает файлы и руками набирает текст. Когда в него добавили LLM, человек всё равно оставался привязан к открытому файлу и курсору. В 2026 году основная работа ушла из IDE в обвязки для агентов (Claude Code, Codex, свои агентские пайплайны с подключением инструментов через MCP).

Когда у моей команды в работе параллельно несколько проектов, мне почти не нужно открывать редактор кода. В репозитории лежат правила проекта (AGENTS.md, CLAUDE.md), архитектурные ограничения и подключённые через MCP инструменты — доступ к базе, логам, задачам, тестовому контуру. Я ставлю задачу головному агенту, а дальше работает цепочка оркестрации: агент сам планирует шаги, создаёт ветку или песочницу, запускает субагентов на поиск по коду, написание реализации, прогон тестов в терминале и первичное ревью.

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

«Автопилот Tesla», потеря навыка и два раунда исследования METR

Лучано сравнивал ИИ-редакторы с автопилотом Tesla FSD, на котором он ездил с 2019 по 2021 год: привыкаешь, что машина сама держит полосу на шоссе, а когда пересаживаешься на обычное авто, первый месяц заново учишься вести «на автомате». Отсюда его главный аргумент — с ИИ уходит Fingerspitzengefühl («чувство в кончиках пальцев»), та самая насмотренность и интуиция ^[14] в деталях кода.

Про этот эффект прямо писал и @dmatora ^[12]:

«Еще на стадии выхода o1 я столкнулся с тем что моя попытка прочитать и понять все правки кода который делает ИИ замедляют прогресс в разы, а отказ от попыток вставить свои 5 копеек безусловно приводит к снижению тренированности мозга ^[15] и параличу при отключении от ИИ».

Там же он сравнил отказ от ИИ ради тонуса мозга с отказом от трактора в пользу мотыги, на что @krendelbok ответил ^[16]:

«Фигня а не сравнение. Тогда уже не трактор а обработка полей с помощью бомб. Потому что сейчас даже после самых лучших моделей надо переписывать код, тратя время на проверку».

Любопытно, что летом 2025 года этот спор проверили экспериментально. Исследовательская группа METR провела рандомизированное исследование (Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity ^[17]) на 16 опытных контрибьюторах крупных open-source проектов (в среднем 5 лет опыта в проекте и более миллиона строк кода). На выборке из 246 реальных задач половину делали с ИИ-редакторами начала 2025 года (в основном Cursor Pro с Claude 3.5 / 3.7 Sonnet), половину — вручную.

Замеры подтвердили правоту @krendelbok для рабочего процесса тех лет: разработчики ожидали ускорения на 24%, после сдачи задач субъективно оценивали выигрыш по времени в 20%, а по таймеру задачи с ИИ заняли на 19% больше времени. Когда опытный инженер сидит в редакторе над огромной кодовой базой, пытается вручную вычитывать каждый кусок сгенерированного кода и поправлять промпты, он тратит на микроконтроль больше времени, чем экономит на наборе текста.

Но уже к началу 2026 года картина изменилась. В августе 2025-го METR запустили новую волну замеров (57 разработчиков, более 800 задач), а в феврале 2026 года выпустили отчёт о том, почему эксперимент по старой методике провести больше не получается (Changing Developer Habits Make Measuring AI Uplift Harder ^[18]). Разработчики начали массово отказываться от участия в контрольной группе, где нужно отключать ИИ, придерживали рутинные задачи до слотов с разрешённым ИИ и перешли к параллельному запуску нескольких агентов одновременно, из-за чего мерить время сидения человека перед одним окном IDE потеряло смысл.

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

Спор про «каменщиков-шабашников», многоэтажки и ТЗ

Самая длинная ветка в комментариях под апрельским постом 2025 года началась с реплики @javax (+7) ^[19]:

«Дело в том, что основное рабочее время художник рисует. А программист (по крайней мере синьор) не программирует (как можно было бы подумать), а общается с людьми чтобы понять что же именно надо программировать».

В ответ @DenSigma написал ^[20], что всё это от недоразвитости ИТ-индустрии:

«В машиностроении такого нет. Там все делается по проекту. Проектная документация ПОЛНОСТЬЮ определяет, каким необходимо изготовить изделие. Нынешний стиль работы сеньора — это как каменщик-шабашник, который обсуждает с частником, как надо выложить дом. В ИТ я даже техническое задание на “изделие” нечасто вижу».

Дальше развернулся классический спор на десяток комментариев. @javax возражал ^[21], что индустрии важнее сделать быстрее, а по многолетнему ТЗ делают разве что софт для кардиостимуляторов. @DenSigma приводил в пример жилые многоэтажки ^[22] и военно-морской флот ^[23], где всё строится и модернизируется по проекту и сметам, и иронизировал над готовностью айтишников переделывать на ходу сайт-визитку в соцсеть на десять миллионов пользователей ^[24].

Ему отвечали @qw1 (+5) ^[25] — о том, что заказчик дома не меняет каждый день форму парадных и грузоподъёмность лифтов, тогда как в ИТ просят «сделать хотя бы одну кнопку побыстрее» ^[26], заселяют три этажа, а потом требуют снести первый этаж под супермаркет без остановки стройки, — и @DezmontDeXa ^[27], заметивший, что проект как раз и составляют сеньоры, а набить код по проекту сможет «простой трудяга/Джун/нейронка», и если заказчик готов платить за переделку ^[28], софт тем и хорош, что позволяет это сделать.

За полтора года агентская разработка неожиданно помирила оба лагеря.

Как только команды попытались масштабировать «вайб-кодинг» с короткими промптами в духе «сделай мне корзину», выяснилось, что без проектной документации агенты быстро разносят архитектуру в щепки. Поэтому в 2026 году ТЗ и проектная документация, о которых писал @DenSigma, вернулись в виде Spec-Driven Development: прежде чем запускать кодящих субагентов, мы пишем спецификацию, фиксируем контракты, схемы данных и тест-планы.

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

Проверяем опрос 2025 года и прогнозы про рынок труда

В конце того поста я повесил опрос: «Насколько меньше нужно будет программистов через 2–3 года по сравнению с 2024 годом». Проголосовали 303 человека (27 воздержались):

Больше 80% проголосовавших тогда поставили на то, что программистов нужно будет столько же или в два раза больше.

В комментариях разброс мнений был ещё шире. @JohnSmith_007 (собравший −12) злорадствовал ^[29], что сеньоры скоро сядут на обочине рядом с компьютерными художниками, пока мечтают «дирижировать ИИ в больших консерваториях». Ему ответил @QTPie ^[30] со ссылкой на исследование британского Society of Authors: даже среди иллюстраторов без работы остались 26%, но при этом вырос спрос на фрилансеров в дизайне упаковки и логотипов. А @nochnoj вообще считал ^[31], что вся тема раздувается CEO компаний ради инвестиций — как недавние сборы чемоданов на Марс.

Отдельный прогноз по грейдам дал @vitalist84 ^[32]:

«Вот в том то и дело, что сениоры код пишут мало, их можно пока не менять. А вот мидлов можно будет заменять, в помощь сеньору останутся джуны — подкручивать промты».

Что в итоге показывают цифры к осени 2026 года? Если взять исследование Стэнфордской лаборатории цифровой экономики (Эрик Бринйолфссон и соавторы, Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence ^[33]) по миллионам зарплатных ведомостей ADP вплоть до 2026 года, то картина получилась очень характерная.

Массового сокращения разработчиков не произошло — занятость сеньоров и опытных инженеров старших возрастных групп осталась стабильной и продолжила расти. А вот прогноз @vitalist84 про то, что «в помощь сеньору останутся джуны подкручивать промпты», сработал с точностью до наоборот. Сильнее всего просела занятость молодых разработчиков 22–25 лет — почти на 20% относительно пика конца 2022 года, причём в основном за счёт резкого торможения найма на начальные позиции. Оказалось, что «подкручивать промпты» без понимания архитектуры бесполезно, а рутинные задачи джунов сеньор теперь закрывает роем субагентов.

Зато полностью подтвердилась гипотеза про кастомный софт, с которой я тогда сам зашёл в комментарии (@awaik ^[34]):

«Одна из гипотез в том, что станут востребованы “кастомные” приложения. Одна командабизнес — несколько приложений созданных специально под потребности ^[35] командыбизнеса. В этом варианте количество занятых в индустрии может вырасти».

Тогда @Glen5 привёл пример ^[36] крупной компании на 15 тысяч человек, где ещё пять лет назад были десятки внутренних Android-приложений вплоть до голосовалки за отпуск, а @positroid добавил ^[37]: «меньше time-to-market — больше продуктов и решений для большего числа заказчиков».

В 2026 году такие кастомные инструменты перестали быть привилегией корпораций на 15 тысяч сотрудников — теперь их делает под себя любая небольшая команда и даже один человек. По себе вижу: у нас в разработке одновременно несколько проектов, и мне для личной продуктивности захотелось сделать веб-приложение заметок по концепции OBTF (одного большого текстового файла в чистом Markdown). Чтобы оно работало кеш-фёрст без интернета на прогулках, умело вставлять надиктованный голосом текст ровно в позицию курсора, бесплатно распознавало речь на избыточных мощностях нашего сервера дообученной под IT-термины моделью GigaAM-v3 и отдавало файл напрямую в Claude или ChatGPT через MCP (тут подробный пост про само приложение ^[38], а тут — как мы дообучали GigaAM-v3 ^[39]). Раньше городить такой кастомный проект под свои привычки было бы жалко времени, а с агентскими обвязками он спокойно собирается параллельно с основной работой.

Даже вопрос @Alexis_Che из того треда ^[40] — пробовали ли давать нейро-помощнику задачу на отрисовку контура детали для лазерной резки — в 2026 году решается штатно: агент пишет параметрический скрипт на Python (CadQuery / build123d), проверяет геометрию и выгружает готовый DXF.

Безопасность, ответственность и «Soft Factory»

Отдельно стоит вспомнить два комментария про безопасность и отношение бизнеса к разработке.

Лучано в статье писал, что если один AI будет писать код, другой проверять PR, а третий деплоить, мы получим всплеск проблем с безопасностью. @ALexKud (+7) в комментариях добавил ^[41] очень точный аргумент про ответственность:

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

А @milkyway044 описал ^[42] картину мира своего CEO:

«Компания — это “soft factory”, где скорость — главная метрика, качество определяется как “разумная достаточность” (выполнение заявленной функции, не более), а ИИ — обязательный инструмент для достижения этой скорости и выживания в конкурентной борьбе… В его картине мира люди (разработчики) — это заменяемый ресурс. Их ценность измеряется скоростью выполнения плана. Они — “производственные единицы” на “soft factory”».

Оба попали в самую точку. По данным Stack Overflow Developer Survey 2025 ^[43] (около 49 тысяч разработчиков), ИИ-инструменты используют или внедряют 84% респондентов, но доля тех, кто активно не доверяет точности сырого вывода ИИ, выросла с 31% до 46% (безоговорочно доверяют лишь 3%). А тесты Veracode более чем на 100 языковых моделях ^[44] показали, что при синтаксической корректности выше 95% проверку на безопасность без дополнительных ограничений проходит только 55% сгенерированного кода — в остальных 45% встречаются классические уязвимости вроде XSS, инъекций в логи и ошибок авторизации. О том же говорят и исследование группы Дэна Боне из Стэнфорда ^[45], и отчёты GitClear ^[46] о росте дублирования кода.

Компании, которые попытались построить «soft factory» буквально по рецепту из комментария @milkyway044 — заменив инженерный контроль гонкой за скоростью генерации, — быстро закопались в багах и уязвимостях.

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

Что в сухом остатке

Наша с другом гипотеза с прогулок на Самуи про переход разработчиков в роль операторов ИИ сбылась даже быстрее, чем за 2–3 года, только ушла ещё на шаг дальше.

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

Очень интересно послушать, как за эти полтора года изменилась ваша работа — особенно если в комменты заглянут участники той апрельской дискуссии 2025-го. Пишете ли вы код руками, сидите в Cursor или тоже перебрались в агентские обвязки?

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