Год назад Андрей Карпатый, один из основателей OpenAI и бывший глава ИИ в Tesla, забросил в Твиттер (он же X) термин "vibe coding" . Он описал новый способ разработки: вы накидываете "вайбовые", что называется, интуитивные подсказки, а ИИ генерирует код. Это было весело, быстро и почти работало. Мем взорвал интернет.
Ровно год спустя, в феврале 2026, Карпатый скорректировал курс:
"Новая норма - вы не пишете код 99% времени. Вы дирижируете агентами, которые это делают, и осуществляете надзор".
Так, на смену vibe coding пришел agentic engineering.
А в начале марта он добавил:
"Трудно передать, насколько программирование изменилось из-за ИИ за последние 2 месяца - не постепенно, а резким скачком".
Это не просто смена названия. Это структурный сдвиг, который меняет все. Я разобрала, что произошло за последние месяцы, почему кодинг "по вайбу" оказался опасной иллюзией, и что теперь делать разработчикам, чтобы не остаться за бортом.
Почему Vibe Coding провалился: суровые цифры
Эйфория от вайб-кодинга прошла быстро. Оказалось, что это прямой путь к техническому долгу и багам. Исследования, вышедшие в конце 2025 - начале 2026 года, нарисовали удручающую картину, я собрала его воедино в таблицу, для вашего удобства:
Исследование (со ссылкой) |
Ключевой вывод |
Разработчики с ИИ-инструментами работали на 19% медленнее, хотя им казалось, что они на 20% быстрее. |
|
Код, написанный с помощью ИИ, содержал на 41% больше багов. |
|
ИИ-сгенерированный код производил на 30% больше предупреждений статического анализа. |
|
Только 2.6% опытных разработчиков "полностью доверяют" ИИ-коду, а 20% - "категорически не доверяют". |
Проблема была не в самом ИИ, а в рабочем процессе. У vibe coding не было структуры, верификации и контроля. Вы, по сути, копипастили код от очень уверенного в себе незнакомца, который иногда галлюцинировал.
Agentic Engineering: новый стандарт
Agentic engineering - это не просто промптить лучше. Это переход от роли исполнителя к роли архитектора и технического директора . Вы больше не пишете код, вы управляете командой ИИ-агентов, которые его пишут:
Vibe Coding (2025) |
Agentic Engineering (2026) |
|---|---|
Человек пишет промпт |
Человек определяет цель и пишет спецификацию |
ИИ предлагает код |
Команда ИИ-агентов планирует, пишет, тестирует, дебажит |
Человек исправляет и вставляет |
Человек ревьюит и утверждает результат |
Один разработчик, один ИИ, один чат |
Один директор, команда ИИ-разработчиков, целый воркфлоу |
За последние несколько месяцев произошел качественный скачок. Инструменты вроде Cursor и Replit Agent научились не просто предлагать фрагменты, а создавать, тестировать и развертывать целые приложения . В феврале 2026 Cursor выкатил Cloud Agents - полностью автономных ИИ-агентов на изолированных виртуалках, которые сами пишут код, записывают демо и готовят pull request'ы . Это и есть agentic engineering в действии.
Практик и ментор Xin Hu, который обучал команды дизайнеров вайб-кодингу, описал эволюцию инструментов в виде 5-уровневой модели зрелости: от текстового поля (уровень 1) через IDE-плагины и low-code платформы к IDE-агентам вроде Cursor и Kiro (уровень 4) и CLI-агентам (уровень 5). Он подметил, что дизайнеры, начинавшие с low-code платформ, добровольно переходили на IDE-агентов, как только осваивали базовые концепции разработки. Low-code упирался в потолок при кастомных дизайн-системах, сложной логике и системной интеграции.
Что это значит для вашей карьеры?
Это часть, которую неприятно слышать. Навыки, которые ценились годами, стремительно теряют в цене.
Что обесценивается:
Написание бойлерплейта
Трансляция спецификаций в код (ключевая задача джуна)
Запоминание синтаксиса и API
Ручной дебаггинг простых ошибок
Что становится в 10 раз ценнее:
Системная архитектура. Агенты пишут код, но не проектируют системы. Умение видеть картину целиком - новый премиальный навык.
Написание спецификаций. Самый ценный навык в 2026 - не кодинг, а написание точных, недвусмысленных спецификаций, которые ИИ-агенты могут выполнить.
Ревью и критическое мышление. Кто-то должен проверять, чтоб агенты не натворили дел. Это требует глубокого понимания, что такое хороший код, а не как его писать.
Оркестрация агентов. Умение настраивать и координировать работу нескольких ИИ-агентов.
Контекст-инжиниринг. Обеспечение агентов правильной документацией, ограничениями и примерами. Это заменяет промпт-инжиниринг.
Если вам интересно, я писала, Какие AI-услуги будут лучше всего продаваться в 2026, там про 7 ключевых навыков, и я выделила 5 конкретных востребованных ниш.
Кризис джуниоров? Или не все так однозначно?
Данные неумолимы. Исследование Гарварда показало резкое падение найма джуниоров в компаниях, внедряющих ИИ. Между концом 2022 и серединой 2025 года занятость на начальных позициях в ИИ-зависимых областях вроде разработки ПО упала примерно на 20%. Но если где-то убыло, значит, где-то прибыло: есть и другой тренд: IBM и Cognizant, наоборот, в разы увеличивают найм новичков. Они наоборот делают ставку на джуниоров, которые сразу учатся работать с ИИ-агентами, и предполагается, что будут продуктивнее сеньоров, которые сопротивляются изменениям.
Что можно сказать начинающим... не учитесь кодить, как в 2020, а учитесь дирижировать, как в 2026. Вход в индустрию смещается, и теперь конкурентоспособный кандидат не тот, кто сможет написать функцию, а тот, кто сможет направить агента, чтобы тот сделал фичу, и проверить его работу.
Вы можете поддержать меня в моем телеграм канале, там я пишу о том, в чем разбираюсь или пытаюсь разобраться сама, тестирую полезные ИИ-сервисы, инструменты для офиса, бизнеса, маркетинга и видео.
Комментарии (67)
Dhwtj
03.03.2026 17:15Карпатый опарашил новый термин.
Вайб кодер может больше не копировать руками ошибки компилятора и стектрейс отладки. Супер достижение!
Где мой полет на Марс? Вместо этого это я получаю смываемую втулку в туалете.©
В нормальной архитектуре нет нужды часами гонять LLM для отладки. Если отладка сложна и многоитерационна, то это говнофикс говнокода.
Dhwtj
03.03.2026 17:15Задачи, где LLM-агенты работают хорошо:
Цена ошибки низкая
Дедлайн мягкий или отсутствует
Обратная связь мгновенная и однозначная
Среда чистая и предсказуемая
"Достаточно хорошо" = приемлемоЗа эти задачи платят мало или не платят вовсе. Бойлерплейт, драфты, скрипты для себя, учебные проекты, хобби-автоматизация. Всё это уже было частично автоматизировано до LLM и потому уже дёшево.
janvarev
03.03.2026 17:15Не совсем - под те же критерии подпадает еще внутренняя бизнес-автоматизация, которая раньше отдавалась на аутсорс агентствам - в штат которых тоже нанимался народ, и немало.
И именно эти агентства теперь сидят без особых заказов...
yahooyaks
03.03.2026 17:15погодите, а нафига вообще разрабатывать приложение для релиза? Можно же на промпте остановиться, а когда надо будет запустить функционал, то обеспечивающий его код будет генерировать на лету по промпту, а после отработки отправляться в /dev/null для обеспечения нужны в следующем акте генерации.
asatost
03.03.2026 17:15а после отработки отправляться в /dev/null для обеспечения нужны в следующем акте генерации
Патентуйте AIdocker-кодинг ;)
rPman
03.03.2026 17:15Текущий путь - это путь в излишние траты токенов, а токены - это стоимость и время. Вместо того, что бы правильно делать, агенты делают не правильно но разными способами, а затем это проверяют и исправляют. Простейшие вещи требуют невероятных затрат ресурсов.
Мне кажется причина банальна - у ИИ требуют работать с кодом целиком, ради этого раздувается контекстное окно а вместе с ним и глюки, когда как человек, со своим мизерным контекстным окошком, работает сфокусированно.
Модели правильно придумывают методы, человек тоже так делает, и это необходимо, что бы знать что искать в документации. Мы открываем список методов и ищем такой метод, который сами бы создали. Но нужно не вставлять метод в код, что бы потом величественно его фиксить, нужно как человек, сначала найти его или что то похожее в документации или других частях кода. Реализовывать это нужно очень хитрыми индексами,..
4ae4eK
03.03.2026 17:15Про контекстное окно не согласен. У человека оно просто гигантское. Если вы писали код сами, то без особых усилий вспомните где и что писали, и как это +- работает. У вас в голове лежат примеры готовых паттернов, которые приняты в команде. У LLM из коробки этих знаний нет. Но, благо это решается системными ароматами. И как я заметил во время работы с ИИ (поправьте, если это не так), большая часть проблем связана с плохой настройкой контекста или её отсутствием + очень много решает сам промпт
rPman
03.03.2026 17:15это долговременная память! И главное, человек умеет обучаться на ходу. Современные llm-ки это существо с антэроградной амнезией, все помнят только до момента их обучения, и только то что попало в их контекстное окно.
Понаблюдайте за собой, как вы работаете с неизвестными вещами, как обращаетесь к документации и примерам. Нужно научиться создавать агентов, способных делать так же
johnnyBoy1984
03.03.2026 17:15мне кажется в этой статье факты подобраны под общий вывод. похоже на рекламу ии агентов в чистом виде.
та же самая модель, которая в режиме чат бота оказывается пишет такой себе код, используется и в агентах. агенты не делают модель лучше, просто экономят время на копипасту.
amazingname
03.03.2026 17:15Системная архитектура. Агенты пишут код, но не проектируют системы. Умение видеть картину целиком - новый премиальный навык.
Этот навык был и остается важным. Правда когда принимаешь решения все равно обсуждаешь с агентом, какие варианты он может предложить.. и потом непонятно, я все еще отвечаю ха архитектуру, или мешаю агенту работать?
Написание спецификаций. Самый ценный навык в 2026 - не кодинг, а написание точных, недвусмысленных спецификаций, которые ИИ-агенты могут выполнить.
Неа. Не существует такого навыка. Если представяешь что нужно и как примерно это может быть реализовано, то как хочешь пиши, хоть двусмысленно, хоть пятисмысленно. Опус все скушает. В крайнем случае, можно заметить что не так и вовремя поправить.
Со старыми моделями тратил часы чтобы написать хорошо поставленное задание и все равно получал черт знает что. Теперь перед обедом пишу задачу так что черт ногу сломит, ухожу на обез и когда прихожу получаю в точности то что ожидал.
Главное не пожелать неосуществимого или не вбросить ошибочную информацию, которая будет сбивать агентов с толку. Чем меньше "спецификаций", тем лучше. Просто по человечески пишешь что нужно.Ревью и критическое мышление. Кто-то должен проверять, чтоб агенты не натворили дел. Это требует глубокого понимания, что такое хороший код, а не как его писать.
Ну, или точнее надо очень быстро читать чужой код, как книгу понимая его логику и ее ровность. Это всегда было востребовано в ревью. Тот же навык.
Оркестрация агентов. Умение настраивать и координировать работу нескольких ИИ-агентов.
Нечего там настраивать. Сложнее не потерять контроль над архитектурой и результатами в целом от неимоверной скорости и эффективности этих всех агентов. Когда продукт прирастает фитчами, но ты уже понятия не имеешь что происходит и чем все это кончится в продакшне.
Контекст-инжиниринг. Обеспечение агентов правильной документацией, ограничениями и примерами. Это заменяет промпт-инжиниринг.
Неа, опять мимо. Нет такого навыка. Нафиг агентам не нужен ваш контекст. Они сами его себе соберут в 10 раз лучше и эффективнее. Они читают код прямо мозгом в отличии от кожаных, читающих код сетчаткой глаза и вся ваша документация скорее их введет в заблуждение чем поможет.
Dhwtj
03.03.2026 17:15Со старыми моделями тратил часы чтобы написать хорошо поставленное задание и все равно получал черт знает что. Теперь перед обедом пишу задачу так что черт ногу сломит, ухожу на обез и когда прихожу получаю в точности то что ожидал
Что же это за задачи?
amazingname
03.03.2026 17:15Из последних, есть GraphQL сервер на hotchocolate. В нем кодогенерация с Roslin для модели данных, которая прилетает в json с конвертацией полученного IQueriable визиторами в кастомный DSL и парсингом результатов с развертыванием обратно в сгенеренные классы. Все это ~10 тыщ строк сплошной логики. Я пишу что-то типа "У меня здесь некоторые ссылки в модели могут быть union из нескольких классов и надо как-то все это пропустить через кодо-генерацию, вписать в концепции hotchocolate (а там ни стандартные union ни интерфейсы близко не подходят) и GraphQL, потом добавить интеграционные тесты, чтобы я посмотрел что все это работает."
И на этом мой супер скилл с AI заканчивается. Через пару часов есть вполне нормальное решение. Самое сложное - разобратся в нем, поправить что не так опять проще простого с агентом. После чего я лихорадочно начинаю вспоминать что я умею делать кроме программирования, когда мы переделаем всю работу и ее больше не останется.
И это уже энтерпрайз продукт. Пол года назад у меня удалалось проворачивать всю фитчу c AI только в пет-проекте и в несколько итераций. С нового года с Opus 4.6 и Sonet 4.6 прям не по себе.
Это конец профессии, как мы ее знаем, если честно.Dhwtj
03.03.2026 17:15конец профессии
переворачивателей пингвинов. Будет работа, только более творческая. Если бы не кастомный DSL (SAP? 1С?) то давно была бы утилита по переводу. Здесь LLM дважды переводит с одного языка описания на другой, с верификацией компилятором.
Есть похожая задача: перевести миллион (реально) строк с net framework + WCF на .net. и с винды на Линукс. Предлагали 2 человеко года. Я не взялся, вернее запросил 5. Хотя, казалось бы задача много раз решалась и LLM в помощь. Каждый вызов может иметь неявные контракты, поведение при ошибках, таймауты, стейт в сессиях. Плюс виндовые специфики: реестр, службы, именованные пайпы, NTLM auth, COM interop возможно. А документации нет, команда разбежалась. Классика.
Robastik
03.03.2026 17:15умею делать кроме программирования
Бро, не ссы: кто умеет в это, тот seamless решает задачи продукта, аналитика, маркетинга, продвижения, финансов. Это эпоха one-person billion-dollar company.
Я тут надысь за полдня собрал ваншот мэйк креатив для маркетинговой коммуникации с учетом психотипа целевого покупателя. В теории рост продаж на 50%. С утра таких слов не знал, к вечеру полный расклад по методике, рынку, и мвп. Вставляет)
AppCrafter
03.03.2026 17:15С нового года с Opus 4.6 и Sonet 4.6 прям не по себе
Полностью согласен, ощущение просто сложно передать, что-то вроде терминатора, который рушит все на своём пути.
Einherjar
03.03.2026 17:15Если представяешь что нужно и как примерно это может быть реализовано, то как хочешь пиши, хоть двусмысленно, хоть пятисмысленно. Опус все скушает.
Говнокодит опус без четких спецификаций. Вплоть до, казалось бы очевидных вещей вроде разделения на слои (view, view model и иже с ними), хреначит бизнеслогику прямо в UI контролы. Ну т.е. написать то напишет, и оно даже работать будет, но если все мелочи не прописать, то это будет одноразовый код. И не то чтобы ситуация с этим как то улучшается с выходом новых моделей. Потому без написания скилов, документации и прочего, увы, никак. Ну или в промтах текста писать придется каждый раз больше чем кода будет на выходе.
Dhwtj
03.03.2026 17:15хреначит бизнеслогику прямо в UI контролы
Есть такое. Нужно сразу обозначить рассчитываешь ты на быстрый ответ одним куском или правильный ответ в нескольких слоях и файлах. В Rust с этим проще: LLM даст набор структур и коротких функций одним куском, потом распихать по зонам ответственности просто. А в C# нужно сразу продумать классы и ответ LLM зависит от быстро или правильно. А потом ещё рефакторить сложнее.
amazingname
03.03.2026 17:15Вплоть до, казалось бы очевидных вещей вроде разделения на слои (view, view model и иже с ними), хреначит бизнеслогику прямо в UI контролы.
Х.з. В существующую архитектуру он вписывает все красиво. Раньше приходилось писать типа "посмотри как сделана фитча какая-то и делай аналогичную архитектуру.", теперь как будто сам догадывается. Логику может унести в неожиданное место, это да, ну так все равно каждую строчку ревьювать. Пишешь куда перенести логику и он переносит.
Проблема пока не в том что он может заменить программиста, проблема что он его может ускорить в разы, чем заменить всех коллег этого программиста.
Einherjar
03.03.2026 17:15В разы ускоряется не работа программиста как таковая, а ее monkey job составляющая. Кодеров заменит, да. Но если работа состоит на 90% из копипаста и набивания очередного бойлерплейта, да и в принципе из набора кода, то тут изначально и без всякого ИИ уже что то не так.
amazingname
03.03.2026 17:15Выше по тексту я описывал задачу. Где в ней бойлерплейт? Это нужно впереть в довольно сложный фреймворк не совсем близкую к нему концепцию. Разобрать как разработчик организовал все визиторы которые разбирают expression tree iqueryable, правильно их поменять, разобрать все нюансы и косяки самопального DSL. Даже учитывая что это мой код я бы просидел неделю, а опус сделал все с тестами за два часа. Мне остаётся только изучить и улучшить. Если то что получилось не понравится PM, мне понадобится ещё два часа чтобы переделать. Это чудо.
Einherjar
03.03.2026 17:15Выше по тексту я описывал задачу. Где в ней бойлерплейт?
Конвертация одного в другое без изменения семантики это хрестоматийный программистский monkey job
Это чудо.
Перевод с одного на другое это блин основной принцип работы LLM, какие чудеса то?
amazingname
03.03.2026 17:15Любая программа это конвертация одного в другое. Это был один из примеров. Какую задачу тогда по вашему не поможет сделать llm?
Cheater
03.03.2026 17:15tl:dr любой код, который требует понимания ментальной модели среды исполнения (aka модели мира) для корректной реализации. Ну вот классический и многим известный пример на c++, про который ни одна LLM мне не смогла ни правильно сказать, что с ним не так, ни предсказать правильный вывод - тк для этого надо понимать внутреннюю логику c++20 filters/ranges:
Дана C++ реализация функции process_data, имитирующей дорогую обработку входных данных (run_paid_request) и затем фильтрацию. Есть ли в ней архитектурные проблемы, проблемы производительности? Что выведет на экран запуск программы?
#include <iostream> #include <ranges> #include <vector> void process_data(std::ranges::forward_range auto &&input) { static const auto run_paid_request = [](auto i) { std::cout << "pay for processing of " << i << std::endl; return i + 1; }; auto output = input | std::views::transform(run_paid_request) | std::views::filter([](auto i) { return i % 2 == 0; }); for(auto o : output) { std::cout << "result: " << o << std::endl; } } int main() { process_data(std::vector<int> {1, 2, 3, 4, 5}); return 0; }amazingname
03.03.2026 17:15Скажем так, я сильно сомневаюсь что современные модели будут иметь какие то сложности с пониманием ranges.
Могу загрузить этот код для ревью и уверен что агент все починит. Пока времени нет.
Cheater
03.03.2026 17:15Что ж, разочарую вас:
https://copilot.microsoft.com/shares/9NoKwVTmdN8Uu1ADR3pMEОсновная проблема с кодом не найдена, предсказание вывода неверное, понимания работы ranges не наблюдаю. Дан ряд несущественных замечаний, причём не всегда верных ("A normal local lambda would be clearer" - ллм буквально не понимает как работает static const).
Так вот, пока LLM не научатся моделировать математически точный процесс исполнения C++ (Python, Go...) кода, я бы не стал делать громких заявлений по поводу того, что LLM может сделать любую задачу.
rPman
03.03.2026 17:15Разочарую вас, бесплатный copilot использует слабую модель или роутер, который по независящим от вас причинам может переключать между средней моделью и слабой.
К сильным моделям бесплатно доступ не предоставляется.
Я не знаю, какие агенты крутятся у openai, если купить 200$/месяц доступ, но слышал что компания экспериментирует в т.ч. с запуском кода, о котором модель тут же размышляет.
Так же я наблюдал, когда даже слабая модель qwen3-coder-30b-a3b при использовании в openhands ai, по мере работы с задачей, сама придумывала снипет на python что бы проверить работоспособность метода и вставить его в тесты, которые он же тут же разрабатывал.
ДА! современные модели все еще не надежны, тупы, переобучены (бенчмарки могут приводить к завышенным ожиданиям, когда как на поверку могут быть простым заучиванием), уж точно не детерменированы, не способны в oneshot решать сложные задачи, но вот у агентов на их основе шансов значительно больше...
в результате, когда у вас что то не получается с ИИ, нужно грешить не только на модель, но и на используемых агентов и на ваш промпт, на сколько полно вы предоставили модели информацию. Я не вижу в вашем промпте даже хотя бы выдержек из документации,.. а значит модель воспринимает код абстрактно.
Cheater
03.03.2026 17:15Я очень часто вижу такой ответ от апологетов llm. Не та модель, возьмите платную модель и всё получится, дайте больше документации... Какой документации??? Там #!!.* написан грёбаный автономный код в десяток строчек! У него вывод предопределён моделью данных STL. Модель или предсказывает его правильно или нет.
В платных моделях есть математическая модель среды исполнения C++ кода и они мне дадут правильный ответ на этот вопрос, особенно если я уберу из кода все толстые подсказки вида печати в cout в определённом месте? Или всё же там внутри всё тот же вероятностный механизм, просто чуть лучше работающий и с обвесом в виде агентов и полаганием на сайд-эффекты типа выхлопа тестов?
rPman
03.03.2026 17:15Повторюсь, я апологет llm и я считаю что они все еще тупы для полной автономии. Поэтому нет никаких гарантий что даже дорогие модели смогут решить вашу задачу. Да какой там, вашу задачу не каждый человек сможет решить, я например не понимаю что вам не нравится, ваши намеки на наличие проблем не помогают... а раз не помогают мне уровню мидл (правда на c/c++ я не писал уже много лет), то модели, тупее среднестатистического человека, хоть и эрудированной, тем более не поможет.
Документация по классам, которые используются в вашем коде, и документации по тем классам, которые использует эта библиотека... вам ведь комплексный анализ нужен производительности?
Судя по рекламе (сам я не пользовался, у меня нет задач, для которых можно 'на поиграть' выкинуть 20-30т.р. в месяц) при использовании pro подписок есть агенты, которые в облачной песочнице умеют запускать код (эти агенты не в опенсорсе, как они работают никто не говорит), и если проводить аналогии я видел как работает открытый агент openhands даже с тупой открытой маленькой моделью,.. очень впечатляюще. Дальше я просто экстраполирую, деньгами и ресурсами уровень качества и возможностей поднимается на десятки процентов.
Гугл заявляли что их собственные решения уже оптимизировали их инфраструктуру, значимо и это было в прошлом году! openai заявляли, что они уже успешно использовали агентное программирование (с людьми само собой) только дорого для обывателя, так как по токенам там получались десятки тысяч баксов в месяц на маленькую команду (читай еще 1-2 такие же команды оплачивать, само собой компании это дешевле, поэтому такие траты оправданы, а вот нам смертным это скорее всего не по карману)
Einherjar
03.03.2026 17:15Какую задачу тогда по вашему не поможет сделать llm?
Не поможет совсем или не ускорит "в разы" ? Мир не то чтобы из одних только бинарных крайностей состоит
amazingname
03.03.2026 17:15Не ускорит, не снизит нагрузку на мой мозг и так далее. Таких задач все меньше.
Einherjar
03.03.2026 17:15Это подмена тезиса, monkey job составляющая есть практически в любой задаче. Потому формально может помочь в любой. Но ее доля разнится - что то ускоряется в разы, а что то вообще медленнее получается.
amazingname
03.03.2026 17:15Ну так вы и вы можете назвать monkey job что угодно. Приведите пример не monkey job.
amazingname
03.03.2026 17:15Ну. Ok, LLM не сильно ускоряет принятие архитектурных решений. Иногда ускоряет, потому что можно себе позволить затупить и заставить агента слепить POC, чтобы понять что так будет плохо и переделать. Но если вы сильны в этом, то да, не ускорит.
Но продумывание архитектуры это совсем небольшой процент работы. Мы изучаем чужой код, пишем новый код в существующую архитектуру, пишем новый код используя принятые решения. Это 99 процентов работы. Раньше я воображал как все будет работать и садился кодить. Теперь я воображаю, потом машу волшебной палочкой, потом ревьюваю что получилось. Это вообще другой уровень.
LiliJulie
03.03.2026 17:15Помню, как все радовались автокомплиту в ИДЕ, а теперь обсуждаем целые команды агентов. По ощущениям, скорость выросла, но и цена ошибки тоже
endeveit
03.03.2026 17:15Как понять что перед тобой ИИ-генерированный контент?
Ищи вот этот маркер: "это не просто X, это <X но сказанный чуть иначе>".
Вычитывайте текст в следующий раз.
arielf
03.03.2026 17:15Не vibe coding, а agentic engineering.
Не проституция, а секс работа. Суть та же, но название более красивое.
asatost
Вам не кажется, что это несовместимые вещи?
Вызовы несуществующих API довольно типичная галлюцинация LLM.
Откуда возьмётся понимание что такое хороший код, если ты его никогда не писал?
... и в 2027 году про вас напишут: "Эйфория от agentic engineering'а прошла быстро. Оказалось, что это прямой путь к техническому долгу и багам."
yahooyaks
Эйфория он agentic engineering тоже может пройти, когда окажется, что для управления агентами, для правильной постановки задач оным, надо уметь в код, в паттерны и в архитектуру, а еще и навыки управления командой агентов. В штат нужны только синьоры теперь.
propell-ant
не, сеньоры - уже не тот уровень, сказано же:
Если серьезно, то понятна мотивация разработчиков, которые толкают это всё вперед - они умеют в архитектуру и стратегическое видение проекта.
Но цепочка роста до этих навыков явно же сломана.
Robastik
В качестве шутки:
Именно поэтому ушли из болонской системы, чтобы вместо цепочки роста сразу получать монолитного сеньора)
DarkGenius
Эйфория пройдет, это просто станет стандартным навыком разработчика ПО.
DarkGenius
Типичная для какого года? Начиная с фронтирных моделей уровня Claude Opus 4.5, в моем обширном опыте AI-assisted разработки уже не происходит таких примитивных галлюцинаций LLM. Агент способен либо сразу писать правильно, либо на шаге валидации своего кода находить вызовы несуществующих API и исправлять их.
Einherjar
Для 2026 вполне типичная, но не на каждом шагу как раньше конечно