Как и многим инженерам‑разработчикам ПО, мне безусловно интересно, и где‑то беспокоит будущее нашей профессии. А тут как раз вышла хабр‑заметка, по отчёту о внедрении ИИ в индустрию. Открыл отчёты, посмотрел графики. Получается, что в среднем внедрение идёт не так уж и быстро. И, если новые модели не предложат качественного скачка, ситуация вряд ли изменится.
Вот ссылки на сами отчёты (анг) за первый квартал и за второй, оба доступны бесплатно и не особо большие, полсотни страниц. Кстати оказалось, что поменялась методология в отчётах. В первом квартале они сравнивали тех, кто использует ИИ, с теми, кто не использует. А во втором это уже потеряло актуальность — 90% программистов пишут код с помощью ИИ.
Мне хотелось сравнить с собственными ощущениями и с нашей компаний (мы попадаем в корзину «индустриальной разработки», 100–300 программистов, северная Америка, не долина). Внедрение ИИ началось больше года назад, когда лицензии на copilot начали раздавать. Но боле‑менее активно использовать начали только прошлой осенью, с постепенным нажимом «сверху» на переход AI‑driven разработку, когда инженер сам «код уже не пишет, а командует агентами».
Но я вижу, что это внедрение идёт прямо таки со скрипом. Вроде руководство поощряет и использование в работе, и эксперименты разрешает и приветствует. И, в общем и целом, разработчики гоняют агентов только в путь. Код, минимум на половину, написан иишкой, а где‑то и на 100%, где маленькие команды в 1–2 человека используют spec‑driven dev. Но вот каких‑то серьёзных прорывов, особенно в сложных проектах, как‑то не заметно. Velocity выросла но не в разы.
Почитал отчёт и выдохнул — это не мы такие, это жизнь такая. В целом, как я понимаю, наша компания в разрезе метрик полностью совпадает с аналогичными, кто участвовал в опросах. Интересно, что покажут последующие отчёты, но сдаётся мне, большого различия со втором кварталом можно пока не ждать.
Взять например, график сводной «эффективности» (там совокупно и velocity, и code diff и тому подобное).
Разработка ускоряется, но не сильно. При этом, качество софта особо не меняется (по субъективной оценке):
При этом, количество AI кода уже перевалило за половину и явно будет только расти
Самый большой рост, можно сказать, по экспоненте, показывает график роста затрат на ИИ.
Но в итоге, времени освобождается не сильно много, как нет и особого роста новых проектов или других инноваций. Стало уходить много времени на координацию и проверку кода. Появился новый расход времени на «настройку ИИ обвязки», её меж‑командная стандартизация.
И выводы отчёта косвенно и напрямую подтверждают то, что я вижу у нас. Наибольший успех AI‑lead разработки показали проекты, где «команда» — это один разработчик. Иногда в паре с product owner, он не сильно мешает. Проблемы начинаются, где в рамках одного проекта нужно координировать разработку с разными людьми. Backend/Frontend команды, синхронизация спецификаций и обвязок, code review (и на качество и на правильность и на соответствие обвязкам).
В отчёте упоминается «Парадокс эффективности ИИ», который сейчас можно видеть по всей отрасли: «производительность труда отдельных сотрудников резко возрастает и в то же время человеческий ресурс становятся новым узким местом в разработке». Или, как озаглавили обзорную статью на хабре — «ИИ ускорил разработчиков, но не разработку».
Но вообще, лично мне, этот отчет вернул утраченный было оптимизм за будущее.
Не ну вот реально, я же вижу, насколько хороший код пишут продвинутые иишки. И чем дальше — тем лучше. Я и сам за выходные легко могу поднять практически любую идею.
Взять хотя бы последний пример
Читал статью на хабре, про изучение английского, задумался. Метод предлагаемый автором мне не нужен, но незнакомые слова и в субтитрах и в статьях, да, встречаются. Решил, что мне нужна небольшая программа на десктопе с возможностью выделить текст или через OCR, стянув область на экране. Текст попутно перевести и, по клику на неизвестном слове, добавить его в список на повторение. Сам список положить в облако, откуда программа на телефоне его будет подтягивать и с заданной периодичностью показывать на фитнес часах Amazfit, где по тапу можно посмотреть и перевод, если надо.
Три программы, (win app, server api, zepp app) — полдня на создание, полдня на допил. Ни строчки сам не написал и всё работает прекрасно. Конечно, если публиковать, пилить пришлось бы больше, но мне нужно «ехать, а не шашечки», меня и dev mode прекрасно устраивает.
Да что там свои поделки — весной была замечательная статья (анг) от Stephen Toub из Microsoft.NET team. «10 месяцев с copilot agent в dotnet/runtime». Там честные примеры с сcылками на PR (в основном на dotnet/runtime repo) и выводами по уровню доверия к AI коду. Где и когда он хорош, и какие перспективы.
И всё темнее как‑то мне виделась моя будущая карьера, как инженера‑разработчика. До пенсии еще далеко, не пора ли переквалифицироваться в управдомы?
Но смотрю на отчёт и немного успокаиваюсь. Чтобы ИИ заменила инженера, это должна быть очень хорошая ИИ. Дорогая. И «думать» (сжигать токены) нужно тем больше, чем больше связей и чем объемней контекст. Пропорции роста затрат к росту эффективности (пока) дают надежду что «инженер ПО», как профессия, какое‑то время еще поживёт. Пусть и с трансформацией от написания кода к его контролю. Думаю, плато достигнуто, революция переходит в эволюцию.
Комментарии (24)
oproptrop
08.09.2026 19:59Еще одна статья от человека не в теме.
Кто в теме в курсе, что качества достаточно даже не самых передовых и больших моделей. Всё упирается в харнес, то есть обвязку. Нет сейчас харнеса коробочного. Если много сидеть в вайбкодинге или аналитике видно, что постановка и выделение скиллов и mcp закрывают качество
Как гитлаб закрыл коробочно ci/CD вместо самописных скриптов, так и здесь
WhiteBehemoth Автор
08.09.2026 19:59Да нас таких, кто не в теме, целая индустрия.
Теоретически да, грамотная обвязка решает проблемы. Вот только обвязать не то, что несколько команд на сложном проекте, несколько людей - уже сложно. Хоть весь день "сиди в вайбкодинге и аналитике". Что-то где-то получается, и то - с компромиссами. Убираешь человека с Code Review - очень быстро словишь ситуацию, что агент не так понял и не то сделал. Про мусор в коде я уже молчу, любые скилы и инструкции спасают лишь отчасти. Если же все расписывать в обвязке, она становится обузой, забивает контекст, начинаются конфликты. Вот и остаётся или жертвовать качеством кода и продукта или (пока) смериться с необходимостью контроля человеком. И отчёт показывает, что компании, очевидно, выбирают второе...
foldr
08.09.2026 19:59Вот обычно пишут про ускорение разработки. То есть человеко-часов на разработку некой фичи уходит меньше. А если соотнести с дополнительными финансовыми тратами (эти самые токены), интересно, на сколько дешевле/дороже стала разработка той же самой фичи?
abve_san
08.09.2026 19:59Судя по убыткам всех участников забега, кроме производителя лопат. Результат видимо, мягко говоря так себе. И постоянные рассказы про мифические метрики типа "эффективности", толсто на это намекают.
Almaz-kh
08.09.2026 19:59более того, когда рассказываю про рост эффективности в 4 10 20 раз, то это всегда вызывает вопросы целесообразности. ведь деньги на ии тратятся, но рост эффективности не гарантирует кратный рост продаж и прибыли. иногда всё утыкается в банальные пределы самого рынка. ты можешь повысить производительность, стать в 4 раза быстрее и банально уткнутся в то, что твоя скорость никому не нужна. рынок не готов потреблять твой подукт с такой скоростью и не готов к столь частым изменения софта на стороне пользователя.
abve_san
08.09.2026 19:59Изначально была куча разговоров про "мы уволим всех человеков" и на разнице между зарплатами и ценой токенов будем жить. В процессе дней выяснилось, что уволить всех человеков не получилось, токены совсем не дешёвые и очевидно будут дорожать. И ещё несколько нюансов. То есть "светлое будущее" опять благополучно не наступило.
abve_san
08.09.2026 19:59И в результате программирование разделится на несколько направлений. Одно где нужно на "отвали". Где качество никому не интересно, да и собственно результат никому не нужен. Будет вайб-кодинг. А где нужно чтобы действительно работало, будут люди. Ну и очевидно разные сочетания этих двух. Так что на мой взгляд профессия программиста никуда не денется, а вот качество программистов (как бы это не казалось странным) вырастет. И всё это что происходит в программировании в контексте ИИ мне лично показывает, что дальше некоторых областей IT ИИ мало куда пойдёт. Пойдёт туда, где результат не очень важен и так сойдёт.
Dhwtj
08.09.2026 19:59По моему опыту LLM оправдано:
Свистоперделки/демо/смотри, как я умею!
Дендрофекальная индустрия/пластиковые одноразовые инструменты низкого качества
Подняли и перенесли на новый стек без изменений
Гонять агентов по быстрой и чёткой петле обратной связи, набивая шишки об стенд
В остальных случаях грустно и сомнительно.
Kot_na_klaviature
08.09.2026 19:59На новый стек не так просто перенести. Я однажды переносил проект на новую архитектуру с топовыми моделями курсора, потратил 2 мес, упоролся и потом ещё месяц выхватывал разные баги. Хотя по идее это как раз ллм задача
WhiteBehemoth Автор
08.09.2026 19:59Помимо кодописания, ИИ агенты, как инструмент, очень полезен для понимания кода. В отчёте указано несколько метрик, связанных с этим - "10ый PR", например - как быстро новый член команды вливается в разработку, ускорился в 2 раза.
Документирование опять же. Не создание многостраничных документов, а "интерактивная документация", когда я оперативно могу получить актуальную информацию (со схемами и графиками, если надо) по произвольному вопросу.
И это, и то, что Вы сказали, укладывается в текущую реальность "ИИ в разработке - хороший индивидуальный инструмент, но не более того"
amaksr
08.09.2026 19:59У нас в компании все очень похоже. Сказали отныне будет спек-дривен девелопмент. Пригнали контрактников с большим опытом (ну то есть они этим занимаются очень долго, больше года). Контрактники нам паписали скилы вокруг spec-kit, внедрили CodeRabbit, показали каким быть новый процесс, и учат как правильно запускать агентов параллельно в полностью автоматическом режиме, чтобы ты ему эпик из джиры даешь, а утром у тебя все сделано.
Простые тикеты, типа поменять текст на лейбле, агенты щелкают на ура. Ну как щелкают... Генерируют спеки, планы, таски, тесты, код, playwright-тесты, запускают CodeRabbit (локально, затем на сервере, когда PR создан), затем самописный код-ревью скил, затем человек еще на всякий случай проверяет, затем в тикет дописывается простыня что и как сделано (для аудита), пяток тестовых сценариев для QA, и через полдня и энное количество токенов текст поменян, и тикет уходит в QA, где люди тоже уже подустали от общения в стиле wall-of-text, поэтому не читают а сразу скармливают все Клоду, чтобы тот все разьяснил, а лучше сразу сделал.
В прошлые времена это бы тоже заняло полдня, была бы заметка для QA где и что смотреть, и не было бы всего остального нагенерированного слопа.
Делается ли все теперь в 3-5 раз быстрее, как мечтает менеджмент? Смотря как мерять. Если по сгенерированному объему и покрытию бессмыссленными тестами то да.
С более сложными тикетами узкое место обычно ревью. Так как мы хотим надежный код, то мы на него натравливаем максимальное количество ревью-агентов, которые часто не согласны с кодом, друг с другом, и даже если просто перезапустить, то могут дать разные результаты. Обычно это признак того, что требования слишком размыты. Но узнаем мы об этом поздно, приходится править PR. Но править теперь требуется не только код, но и все связанные нагенерированные артефакты: спеки, план, таски, тесты, сам тикет. Клод при этом всегда что-то пропускает, несоответствия спекам всплывют на ревью снова, и получаем цикл. Можно в принципе оставить агентов гонять этот цикл на ночь, но результат как правило плохой и дорогой в смысле сожженных токенов.
Один из подходов, который тестируем, и пока вроде успешно, это показать агенту "идеальный код" : какое-то простое приложение, где ИИ может почерпнуть все недостающие требования: как генерировать фронтенд (фреймворки, библиотеки, элементы, поведение, и т.д.), как выглядит типичный бэкенд (фреймворки, библиотеки, хранилище, транзакционность, пагинация, параметры ендпоинтов, и т.п.). Но правда писать его приходится ручками...
В общем мы пробуем, работа идет, но ускорится в разы пока не получается...
Dhwtj
08.09.2026 19:59затем в тикет дописывается простыня что и как сделано
Мы стараемся разделить diff на несколько коммитов и описание по каждому отдельно. Задача разбивается на
Предварительное построение тестов/гардов чтобы не сломать старое
Смысловое ядро изменений с коротким и прозрачным diff. Он должен читаться за 5 минут. Исполнитель презентует его на дейлике.
Догоны по частным случаям, не предусмотренные в изначальной задаче и описание / патч к изначальным требованиям. Они не должны сломать основную часть. Если их много то это видно и возможно проще вернуть на уточнение требований чем ревьювить это.
WhiteBehemoth Автор
08.09.2026 19:59Пригнали контрактников с большим опытом (ну то есть они этим занимаются очень долго, больше года).
Контрактники нам паписали скилы вокруг spec-kit, внедрили CodeRabbit, показали каким быть новый процесс, и учат как правильно запускать агентов параллельно в полностью автоматическом режиме, чтобы ты ему эпик из джиры даешь, а утром у тебя все сделано.
Мне вот что интересно, а эти контрактники, у них работа "научить, как надо"? Они и сами-то пишут и поддерживают проекты? Или там всё по закону Мерфи "Кто умеет - делает, кто не умеет - учит"?
js2me
08.09.2026 19:59Забавно что пришли ИИ умельцы все настроили и сделали , а агенты все равно делают ошибки и процесс не создался удобный.
abve_san
08.09.2026 19:59Один из подходов, который тестируем, и пока вроде успешно, это показать агенту "идеальный код" : какое-то простое приложение,
Извините , а "идеальный код" он откуда берётся?
WASD1
08.09.2026 19:59Я бы сказал, что скорее мы ПОКА ЧТО ситуация напоминает: поставили ДВС на телегу и увидели, что телега быстрее 20км/ч не едет.
А проектирование нормальных ЯП и flow разработки (и разработчиков умеющих ими пользоваться) - ещё впереди.Я лично вижу несколько затыков (и даже несколько сценариев затыков) в ИИ-разработке. И даже несмотря на то, что "в принципе" эти затыки понимаю - не до конца могу с ними справится. Грубо если объяснять ВСЁ - будет не быстрее чем кодить. А если объяснять не всё - периодически приходится "gvim TASK.md, new task" (у нас правда аппаратная разработка - программная часть симуляторы \ драйвера \ библиотеки) - т.к. примерно половину из 100 нюансов он уловил, а остальные не понял и это конкретно сейчас оказалось критичным.
CrashLogger
Удовлетворения такая работа все равно не приносит. Программист из творца стал прокладкой между клиентом и ИИшкой. Тем, кто привык работать головой и получает от этого удовольствие, все равно рано или поздно придется искать новое занятие. Вот только какое ?
WhiteBehemoth Автор
У меня за 25 лет карьеры (немного в рф, в основном канада), творить на работе приходилось не часто. Ну так, чтоб думать над архитектурой, обсуждать решения. Это в начале проекта, когда с нуля вырастает продукт. В основном же - поддержка, доработка, исправление. Ремесленник, не творец. Как отдушина - проекты для себя, конкурсные задачки, учёба. Хобби, не работа.
Да, соглашусь, через какое-то время, умение читать и понимать код может стать ненужным. Но мой прогноз на это пока сдвигается с краткосрочной (до 3 лет) перспективы на среднесрочную (5+). Вопрос куда смотреть дальше, пока открыт...
SabMakc
Смотря что именно приносит удовольствие.
Если писать код в радость - то да, ИИ отберет эту часть. Если нравилось решать проблемы - то ИИ скорее в помощь. Если же по проработке архитектуры фанател - то ИИ вообще незаменим (как исполнитель экспериментов).