Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 86
Эйфория он agentic engineering тоже может пройти, когда окажется, что для управления агентами, для правильной постановки задач оным, надо уметь в код, в паттерны и в архитектуру, а еще и навыки управления командой агентов. В штат нужны только синьоры теперь.
не, сеньоры - уже не тот уровень, сказано же:
"Это переход от роли исполнителя к роли архитектора и технического директора"
Если серьезно, то понятна мотивация разработчиков, которые толкают это всё вперед - они умеют в архитектуру и стратегическое видение проекта.
Но цепочка роста до этих навыков явно же сломана.
Эйфория пройдет, это просто станет стандартным навыком разработчика ПО.
Вызовы несуществующих API довольно типичная галлюцинация LLM.
Типичная для какого года? Начиная с фронтирных моделей уровня Claude Opus 4.5, в моем обширном опыте AI-assisted разработки уже не происходит таких примитивных галлюцинаций LLM. Агент способен либо сразу писать правильно, либо на шаге валидации своего кода находить вызовы несуществующих API и исправлять их.
Карпатый опарашил новый термин.
Вайб кодер может больше не копировать руками ошибки компилятора и стектрейс отладки. Супер достижение!
Где мой полет на Марс? Вместо этого это я получаю смываемую втулку в туалете.©
В нормальной архитектуре нет нужды часами гонять LLM для отладки. Если отладка сложна и многоитерационна, то это говнофикс говнокода.
Задачи, где LLM-агенты работают хорошо:
Цена ошибки низкая
Дедлайн мягкий или отсутствует
Обратная связь мгновенная и однозначная
Среда чистая и предсказуемая
"Достаточно хорошо" = приемлемо
За эти задачи платят мало или не платят вовсе. Бойлерплейт, драфты, скрипты для себя, учебные проекты, хобби-автоматизация. Всё это уже было частично автоматизировано до LLM и потому уже дёшево.
Не совсем - под те же критерии подпадает еще внутренняя бизнес-автоматизация, которая раньше отдавалась на аутсорс агентствам - в штат которых тоже нанимался народ, и немало.
И именно эти агентства теперь сидят без особых заказов...
погодите, а нафига вообще разрабатывать приложение для релиза? Можно же на промпте остановиться, а когда надо будет запустить функционал, то обеспечивающий его код будет генерировать на лету по промпту, а после отработки отправляться в /dev/null для обеспечения нужны в следующем акте генерации.
Текущий путь - это путь в излишние траты токенов, а токены - это стоимость и время. Вместо того, что бы правильно делать, агенты делают не правильно но разными способами, а затем это проверяют и исправляют. Простейшие вещи требуют невероятных затрат ресурсов.
Мне кажется причина банальна - у ИИ требуют работать с кодом целиком, ради этого раздувается контекстное окно а вместе с ним и глюки, когда как человек, со своим мизерным контекстным окошком, работает сфокусированно.
Модели правильно придумывают методы, человек тоже так делает, и это необходимо, что бы знать что искать в документации. Мы открываем список методов и ищем такой метод, который сами бы создали. Но нужно не вставлять метод в код, что бы потом величественно его фиксить, нужно как человек, сначала найти его или что то похожее в документации или других частях кода. Реализовывать это нужно очень хитрыми индексами,..
Про контекстное окно не согласен. У человека оно просто гигантское. Если вы писали код сами, то без особых усилий вспомните где и что писали, и как это +- работает. У вас в голове лежат примеры готовых паттернов, которые приняты в команде. У LLM из коробки этих знаний нет. Но, благо это решается системными ароматами. И как я заметил во время работы с ИИ (поправьте, если это не так), большая часть проблем связана с плохой настройкой контекста или её отсутствием + очень много решает сам промпт
это долговременная память! И главное, человек умеет обучаться на ходу. Современные llm-ки это существо с антэроградной амнезией, все помнят только до момента их обучения, и только то что попало в их контекстное окно.
Понаблюдайте за собой, как вы работаете с неизвестными вещами, как обращаетесь к документации и примерам. Нужно научиться создавать агентов, способных делать так же
мне кажется в этой статье факты подобраны под общий вывод. похоже на рекламу ии агентов в чистом виде.
та же самая модель, которая в режиме чат бота оказывается пишет такой себе код, используется и в агентах. агенты не делают модель лучше, просто экономят время на копипасту.
Системная архитектура. Агенты пишут код, но не проектируют системы. Умение видеть картину целиком - новый премиальный навык.
Этот навык был и остается важным. Правда когда принимаешь решения все равно обсуждаешь с агентом, какие варианты он может предложить.. и потом непонятно, я все еще отвечаю ха архитектуру, или мешаю агенту работать?
Написание спецификаций. Самый ценный навык в 2026 - не кодинг, а написание точных, недвусмысленных спецификаций, которые ИИ-агенты могут выполнить.
Неа. Не существует такого навыка. Если представяешь что нужно и как примерно это может быть реализовано, то как хочешь пиши, хоть двусмысленно, хоть пятисмысленно. Опус все скушает. В крайнем случае, можно заметить что не так и вовремя поправить.
Со старыми моделями тратил часы чтобы написать хорошо поставленное задание и все равно получал черт знает что. Теперь перед обедом пишу задачу так что черт ногу сломит, ухожу на обез и когда прихожу получаю в точности то что ожидал.
Главное не пожелать неосуществимого или не вбросить ошибочную информацию, которая будет сбивать агентов с толку. Чем меньше "спецификаций", тем лучше. Просто по человечески пишешь что нужно.
Ревью и критическое мышление. Кто-то должен проверять, чтоб агенты не натворили дел. Это требует глубокого понимания, что такое хороший код, а не как его писать.
Ну, или точнее надо очень быстро читать чужой код, как книгу понимая его логику и ее ровность. Это всегда было востребовано в ревью. Тот же навык.
Оркестрация агентов. Умение настраивать и координировать работу нескольких ИИ-агентов.
Нечего там настраивать. Сложнее не потерять контроль над архитектурой и результатами в целом от неимоверной скорости и эффективности этих всех агентов. Когда продукт прирастает фитчами, но ты уже понятия не имеешь что происходит и чем все это кончится в продакшне.
Контекст-инжиниринг. Обеспечение агентов правильной документацией, ограничениями и примерами. Это заменяет промпт-инжиниринг.
Неа, опять мимо. Нет такого навыка. Нафиг агентам не нужен ваш контекст. Они сами его себе соберут в 10 раз лучше и эффективнее. Они читают код прямо мозгом в отличии от кожаных, читающих код сетчаткой глаза и вся ваша документация скорее их введет в заблуждение чем поможет.
Со старыми моделями тратил часы чтобы написать хорошо поставленное задание и все равно получал черт знает что. Теперь перед обедом пишу задачу так что черт ногу сломит, ухожу на обез и когда прихожу получаю в точности то что ожидал
Что же это за задачи?
Из последних, есть GraphQL сервер на hotchocolate. В нем кодогенерация с Roslin для модели данных, которая прилетает в json с конвертацией полученного IQueriable визиторами в кастомный DSL и парсингом результатов с развертыванием обратно в сгенеренные классы. Все это ~10 тыщ строк сплошной логики. Я пишу что-то типа "У меня здесь некоторые ссылки в модели могут быть union из нескольких классов и надо как-то все это пропустить через кодо-генерацию, вписать в концепции hotchocolate (а там ни стандартные union ни интерфейсы близко не подходят) и GraphQL, потом добавить интеграционные тесты, чтобы я посмотрел что все это работает."
И на этом мой супер скилл с AI заканчивается. Через пару часов есть вполне нормальное решение. Самое сложное - разобратся в нем, поправить что не так опять проще простого с агентом. После чего я лихорадочно начинаю вспоминать что я умею делать кроме программирования, когда мы переделаем всю работу и ее больше не останется.
И это уже энтерпрайз продукт. Пол года назад у меня удалалось проворачивать всю фитчу c AI только в пет-проекте и в несколько итераций. С нового года с Opus 4.6 и Sonet 4.6 прям не по себе.
Это конец профессии, как мы ее знаем, если честно.
конец профессии
переворачивателей пингвинов. Будет работа, только более творческая. Если бы не кастомный DSL (SAP? 1С?) то давно была бы утилита по переводу. Здесь LLM дважды переводит с одного языка описания на другой, с верификацией компилятором.
Есть похожая задача: перевести миллион (реально) строк с net framework + WCF на .net. и с винды на Линукс. Предлагали 2 человеко года. Я не взялся, вернее запросил 5. Хотя, казалось бы задача много раз решалась и LLM в помощь. Каждый вызов может иметь неявные контракты, поведение при ошибках, таймауты, стейт в сессиях. Плюс виндовые специфики: реестр, службы, именованные пайпы, NTLM auth, COM interop возможно. А документации нет, команда разбежалась. Классика.
умею делать кроме программирования
Бро, не ссы: кто умеет в это, тот seamless решает задачи продукта, аналитика, маркетинга, продвижения, финансов. Это эпоха one-person billion-dollar company.
Я тут надысь за полдня собрал ваншот мэйк креатив для маркетинговой коммуникации с учетом психотипа целевого покупателя. В теории рост продаж на 50%. С утра таких слов не знал, к вечеру полный расклад по методике, рынку, и мвп. Вставляет)
С нового года с Opus 4.6 и Sonet 4.6 прям не по себе
Полностью согласен, ощущение просто сложно передать, что-то вроде терминатора, который рушит все на своём пути.
Если представяешь что нужно и как примерно это может быть реализовано, то как хочешь пиши, хоть двусмысленно, хоть пятисмысленно. Опус все скушает.
Говнокодит опус без четких спецификаций. Вплоть до, казалось бы очевидных вещей вроде разделения на слои (view, view model и иже с ними), хреначит бизнеслогику прямо в UI контролы. Ну т.е. написать то напишет, и оно даже работать будет, но если все мелочи не прописать, то это будет одноразовый код. И не то чтобы ситуация с этим как то улучшается с выходом новых моделей. Потому без написания скилов, документации и прочего, увы, никак. Ну или в промтах текста писать придется каждый раз больше чем кода будет на выходе.
хреначит бизнеслогику прямо в UI контролы
Есть такое. Нужно сразу обозначить рассчитываешь ты на быстрый ответ одним куском или правильный ответ в нескольких слоях и файлах. В Rust с этим проще: LLM даст набор структур и коротких функций одним куском, потом распихать по зонам ответственности просто. А в C# нужно сразу продумать классы и ответ LLM зависит от быстро или правильно. А потом ещё рефакторить сложнее.
Вплоть до, казалось бы очевидных вещей вроде разделения на слои (view, view model и иже с ними), хреначит бизнеслогику прямо в UI контролы.
Х.з. В существующую архитектуру он вписывает все красиво. Раньше приходилось писать типа "посмотри как сделана фитча какая-то и делай аналогичную архитектуру.", теперь как будто сам догадывается. Логику может унести в неожиданное место, это да, ну так все равно каждую строчку ревьювать. Пишешь куда перенести логику и он переносит.
Проблема пока не в том что он может заменить программиста, проблема что он его может ускорить в разы, чем заменить всех коллег этого программиста.
В разы ускоряется не работа программиста как таковая, а ее monkey job составляющая. Кодеров заменит, да. Но если работа состоит на 90% из копипаста и набивания очередного бойлерплейта, да и в принципе из набора кода, то тут изначально и без всякого ИИ уже что то не так.
Выше по тексту я описывал задачу. Где в ней бойлерплейт? Это нужно впереть в довольно сложный фреймворк не совсем близкую к нему концепцию. Разобрать как разработчик организовал все визиторы которые разбирают expression tree iqueryable, правильно их поменять, разобрать все нюансы и косяки самопального DSL. Даже учитывая что это мой код я бы просидел неделю, а опус сделал все с тестами за два часа. Мне остаётся только изучить и улучшить. Если то что получилось не понравится PM, мне понадобится ещё два часа чтобы переделать. Это чудо.
Выше по тексту я описывал задачу. Где в ней бойлерплейт?
Конвертация одного в другое без изменения семантики это хрестоматийный программистский monkey job
Это чудо.
Перевод с одного на другое это блин основной принцип работы LLM, какие чудеса то?
Любая программа это конвертация одного в другое. Это был один из примеров. Какую задачу тогда по вашему не поможет сделать llm?
tl: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;
}
Скажем так, я сильно сомневаюсь что современные модели будут иметь какие то сложности с пониманием ranges.
Могу загрузить этот код для ревью и уверен что агент все починит. Пока времени нет.
Что ж, разочарую вас:
https://copilot.microsoft.com/shares/9NoKwVTmdN8Uu1ADR3pME
Основная проблема с кодом не найдена, предсказание вывода неверное, понимания работы ranges не наблюдаю. Дан ряд несущественных замечаний, причём не всегда верных ("A normal local lambda would be clearer" - ллм буквально не понимает как работает static const).
Так вот, пока LLM не научатся моделировать математически точный процесс исполнения C++ (Python, Go...) кода, я бы не стал делать громких заявлений по поводу того, что LLM может сделать любую задачу.
Разочарую вас, бесплатный copilot использует слабую модель или роутер, который по независящим от вас причинам может переключать между средней моделью и слабой.
К сильным моделям бесплатно доступ не предоставляется.
Я не знаю, какие агенты крутятся у openai, если купить 200$/месяц доступ, но слышал что компания экспериментирует в т.ч. с запуском кода, о котором модель тут же размышляет.
Так же я наблюдал, когда даже слабая модель qwen3-coder-30b-a3b при использовании в openhands ai, по мере работы с задачей, сама придумывала снипет на python что бы проверить работоспособность метода и вставить его в тесты, которые он же тут же разрабатывал.
ДА! современные модели все еще не надежны, тупы, переобучены (бенчмарки могут приводить к завышенным ожиданиям, когда как на поверку могут быть простым заучиванием), уж точно не детерменированы, не способны в oneshot решать сложные задачи, но вот у агентов на их основе шансов значительно больше...
в результате, когда у вас что то не получается с ИИ, нужно грешить не только на модель, но и на используемых агентов и на ваш промпт, на сколько полно вы предоставили модели информацию. Я не вижу в вашем промпте даже хотя бы выдержек из документации,.. а значит модель воспринимает код абстрактно.
Я очень часто вижу такой ответ от апологетов llm. Не та модель, возьмите платную модель и всё получится, дайте больше документации... Какой документации??? Там #!!.* написан грёбаный автономный код в десяток строчек! У него вывод предопределён моделью данных STL. Модель или предсказывает его правильно или нет.
В платных моделях есть математическая модель среды исполнения C++ кода и они мне дадут правильный ответ на этот вопрос, особенно если я уберу из кода все толстые подсказки вида печати в cout в определённом месте? Или всё же там внутри всё тот же вероятностный механизм, просто чуть лучше работающий и с обвесом в виде агентов и полаганием на сайд-эффекты типа выхлопа тестов?
Повторюсь, я апологет llm и я считаю что они все еще тупы для полной автономии. Поэтому нет никаких гарантий что даже дорогие модели смогут решить вашу задачу. Да какой там, вашу задачу не каждый человек сможет решить, я например не понимаю что вам не нравится, ваши намеки на наличие проблем не помогают... а раз не помогают мне уровню мидл (правда на c/c++ я не писал уже много лет), то модели, тупее среднестатистического человека, хоть и эрудированной, тем более не поможет.
Документация по классам, которые используются в вашем коде, и документации по тем классам, которые использует эта библиотека... вам ведь комплексный анализ нужен производительности?
Судя по рекламе (сам я не пользовался, у меня нет задач, для которых можно 'на поиграть' выкинуть 20-30т.р. в месяц) при использовании pro подписок есть агенты, которые в облачной песочнице умеют запускать код (эти агенты не в опенсорсе, как они работают никто не говорит), и если проводить аналогии я видел как работает открытый агент openhands даже с тупой открытой маленькой моделью,.. очень впечатляюще. Дальше я просто экстраполирую, деньгами и ресурсами уровень качества и возможностей поднимается на десятки процентов.
Гугл заявляли что их собственные решения уже оптимизировали их инфраструктуру, значимо и это было в прошлом году! openai заявляли, что они уже успешно использовали агентное программирование (с людьми само собой) только дорого для обывателя, так как по токенам там получались десятки тысяч баксов в месяц на маленькую команду (читай еще 1-2 такие же команды оплачивать, само собой компании это дешевле, поэтому такие траты оправданы, а вот нам смертным это скорее всего не по карману)
Поэтому нет никаких гарантий что даже дорогие модели смогут решить вашу задачу.
что ж, неплохой прогресс по сравнению с исходным посылом "попробуйте показать мне задачу, которую не решит LLM"
Документация по классам, которые используются в вашем коде, и документации по тем классам, которые использует эта библиотека... вам ведь комплексный анализ нужен производительности?
Нет там используемых классов с документацией. Там код в 10 строчек, 1 функция, вызывающая ranges::transform и ranges::filter. Весь нужный здесь контекст - это указание на возможную дороговизну ф-и run_paid_request. Никакой комплексный анализ не нужен, это не про ассемблерную оптимизацию вопрос. Там тупо дорогая функция вызывается больше раз чем надо.
а раз не помогают мне уровню мидл (правда на c/c++ я не писал уже много лет), то модели, тупее среднестатистического человека, хоть и эрудированной, тем более не поможет.
Говорят, помогает запустить код и проверить, правильно ли LLM его предсказала? https://godbolt.org/z/e783T6sq5 - дорогая функция вызывается для нечётных элементов 2 раза.
ага, спасибо, сделал один запрос с тупейшим промптом:
вот код, помоги найти в чем он не оптимален
получил в ответе первым пунктом:
openai:gpt-5.2 api
Вот где в этом коде «не оптимально» (в смысле лишняя работа/лишние ограничения), и что можно улучшить.
1) Главная неэффективность: платная операция делается до фильтра
Сейчас пайплайн такой:
input
| transform(run_paid_request) // "платим" за каждый элемент
| filter(even) // часть результатов выбрасываем
То есть run_paid_request вызывается для всех входных значений, даже для тех, которые потом не пройдут filter.
Если run_paid_request реально дорогая операция (как намекает название), это ключевая проблема.
Можно ли переставить filter перед transform?
Не напрямую, потому что фильтрация у вас по преобразованному значению:
фильтр: (i + 1) % 2 == 0.
Но это условие можно переписать через исходное i:
(i + 1) % 2 == 0⇔i % 2 == 1(то естьiнечётный)
Значит можно сначала отфильтровать нечётные входы, а потом платить только за них:
auto output = input | std::views::filter([](int i){ return i % 2 != 0; }) // оставили только те, что дадут чётный результат после +1 | std::views::transform(run_paid_request);
Это уменьшает число вызовов “платной” функции примерно вдвое (для равномерных данных).
2) std::endl — лишний flush (медленно)
std::endl делает и перевод строки, и принудительный flush буфера. В циклах это сильно тормозит.
Заменить на '\n':
std::cout << "..." << '\n';
3) Слишком сильное требование к диапазону: forward_range
Вы используете диапазон ровно один раз, и вам достаточно input_range:
void process_data(std::ranges::input_range auto&& input)
forward_range более строгий (мультипроходность), и этим вы отсекаете часть потенциальных источников данных (например, некоторые потоковые/генераторные ranges).
4) static const auto run_paid_request = ... обычно не нужно
static тут не даёт выигрыша производительности, но:
усложняет (один объект на программу, а не на вызов),
может быть нежелательно для потоков/тестов/переиспользования.
Обычно достаточно обычной локальной лямбды:
auto run_paid_request = [](int i) { ... };
Вариант с исправлениями (минимально меняя смысл)
#include <iostream>
#include <ranges>
#include <vector>
void process_data(std::ranges::input_range auto&& input) { auto run_paid_request = [](int i) { std::cout << "pay for processing of " << i << '\n'; return i + 1; }; auto output = input | std::views::filter([](int i) { return i % 2 != 0; }) // чтобы (i+1) было чётным | std::views::transform(run_paid_request); for (int o : output) { std::cout << "result: " << o << '\n'; }
}
int main() { process_data(std::vector<int>{1,2,3,4,5});
}
Если скажете, что именно в реальном коде является “платной” операцией (I/O? сеть? CPU?), можно подсказать ещё более подходящую архитектуру (кэширование, батчинг, параллелизм, materialize в vector и т.п.).
Главная неэффективность: платная операция делается до фильтра
Это by design. В условии задачи не говорится, что в общем случае возможно произвести фильтрацию до платной операции. Run_paid_request я сделал операцией увеличения на единицу для простоты, в реальности это чёрный ящик.
2-3 формально верно, но несущественно.
4 просто неверно. Второй раз уже это говорю. Static const это прямое указание как компилятору, так и читающему код человеку, что лямбда одна и та же при любом запуске, и во многих похожих случаях приводит к инлайнингу лямбды. Что хочет выразить автор кода, сделав run_paid_request неконстантной или нестатической? Она может измениться между запусками? Она может быть переприсвоена?
В целом рефакторинг конечно замечательный, но напомню, что в исходный вопрос входило также "Что напечатает данный конкретный код"?
Если скажете, что именно в реальном коде является “платной” операцией (I/O? сеть? CPU?)
Платной операцией является run_paid_request.
Что ж, разочарую вас:https://copilot.microsoft.com/shares/9NoKwVTmdN8Uu1ADR3pME
Ok, давайте развеем ваши сомнения.
Первое - LLM создают для реальных задач а не разгадывания загадок. Ваш код сам по себе абсурден, потому что если вы фильтруете по результату, то вероятно вы еще не знаете как этот результат будет считаться и не можете избежать вызова тяжелой функции.LLM работает хорошо когда ясно понимает что и зачем вы делаете. Она не для собесов, а для работы.
Тем не менее, давайте попробуем. Я немного поменяю вашу задачу.
Я создаю файл cpp:
#include <iostream>
#include <ranges>
#include <vector>
void process_data(std::ranges::forward_range auto &&input) {
static const auto run_paid_request = [](auto i) {
// here we are planing some heavy calculation
// ...
return i + 1;
};
auto output = input
| std::views::transform(run_paid_request)
| std::views::filter([](auto i) {
return i % 2 == 0; // here will be some complicated filter
});
for(auto o : output) {
std::cout << "result: " << o << std::endl;
}
}
int main() {
process_data(std::vector<int> {1, 2, 3, 4, 5});
return 0;
}
Промпт:
Я начал создавать функцию для выполннеия задач обработки с фильтрацией.Исправь, если я где-то ошибся.
Ответ:
Код синтаксически корректен, но содержит логическую ошибку: transform (дорогая операция run_paid_request) выполняется до filter, а значит тяжёлые вычисления запускаются для всех элементов, включая те, которые потом отбрасываются фильтром.
Нужно поменять порядок — сначала фильтровать, потом обрабатывать:
Edited
f.cpp+2-2
Теперь filter идёт первым — фильтр отсеивает ненужные элементы, и только прошедшие попадают в transform (run_paid_request). Это избавляет от лишних дорогих вычислений.
С входом {1, 2, 3, 4, 5}:
filter (чётные) →
{2, 4}transform (+1) →
{3, 5}Вывод:
result: 3,result: 5
И вот правки:
Не вникал как работают эти ranges.
Все правильно? Похоже, что LLM знает как это работает?
Нет, неправильно, так как исходная задача (если убрать отладочную печать "pay for processing") выведет result: 2, result: 4, result: 6, а ваше изменение приводит к выводу: "result: 3, result: 5". Патч изменил наблюдаемое поведение. На сём предлагаю закончить дискуссию о волшебном умении ллм решить любую задачу.
Да, согласен, она затупила. И именно по той причине, что задача далека от задач с понятной целью. LLM просто не догнала что и зачем я делаю. В реальнй работе я даже не встречал такого поведения LLM - чтобы поменяла работу алгоритма при улучшении. При работе с агентом через несколько месяцев вырабатывается своебразное чувство локтя - что и как ему поручать. Своей постановкой задачи вы его немонго ломаете, поэтому я не справился.
Продолжим тогда.
Промпт:
"Ты уверен что здесь все так просто и нет никагого подвоха? "
Ответ:
Нет, подвох тут есть. Моя правка была правильной только при одном важном предположении: фильтр можно применять к исходным данным, а не к результату run_paid_request
...
и дальше когда я просил не менять поведение:
Как вам?
На сём предлагаю закончить дискуссию о волшебном умении ллм решить любую задачу.
А вы можете решить любую задчу?
Каждый месяу LLM становятся лучше и поверьте, эти дискуссии в самом начале.
Ну слава богу догадался наконец, но говорить "решит любую задачу" про систему, которая с одинаковой легкостью выдаёт и правильный анализ и решение, меняющее поведение программы, и не видящую в этом проблемы, - это перебор.
И если придираться, то решение с вектором тоже так себе. Если в инпуте миллион элементов, он аллоцирует вектор на миллион элементов, хотя можно обойтись обычным поэлементным циклом с условием.
А вы можете решить любую задчу?
Я-то нет, но вы вроде говорили, что LLM на это способна?
поверьте, эти дискуссии в самом начале.
Стандартный ответ. Ну что ж, я готов продолжить дискуссию, когда внутри LLM будет модель исполнения C++ кода и когда они не будут галлюцинировать.
Я утверждал, что использую ее для создания почти 100% кода уже в любой задаче. И это так и есть. При этом мои задачи обычные для программиста - не простые не сложные. Вайбкодить в классическом смысле - просто в общих чертаъхх ставить задачи я не пробовал, не знаю насколько хорошо это рабтает. Я обычно описываю довольно детально как экономить ресурсы в местах где их имеет смысл экономить.
Знаю, что мой коллега который вынесет мозг любому за малейшую неоптимальность в коде уже вайбкодит безудержно. А значит оно работает.
Вы утверждали, что модель не понимает как оно работает внутри. Но как раз это абсолютно неверно. У моделей есть куча "психологических" проблем - она слишком верит сказанному, она предположит не переспрашивая, она упростит себе задачу без спроса если что-то не стыковалось и так далее.
Но что несомненно - что у нее в нейронной сети есть те же самые абстрактные образы любой программистской концепции, что и у человека.
Она знает о ranges в точности то же что и вы. Только тупит в других ситуациях.
Если в инпуте миллион элементов, он аллоцирует вектор на миллион элементов, хотя можно обойтись обычным поэлементным циклом с условием.
Если мы зачем-то вперли туда ranges, то модель верит что он нужен и пляшет от этого. Если бы вы давали эту задачу на собесе, метания бедного кандидата были бы примерно в том же духе.
Стандартный ответ. Ну что ж, я готов продолжить дискуссию, когда внутри LLM будет модель исполнения C++ кода и когда они не будут галлюцинировать.
Это анекдот про сибирских мужиков и японскую бензопилу. Вам предлагают инструмент который валит лес, а вы ищите лом которые ее сломает.
а вы ищите лом которые ее сломает.
Разумеется. Так работает примерно вся математика и в значительной мере тестирование ПО.
Мне не очень важно знать, насколько хорошо система кодогенерации работает на happy path и насколько много кода она может при этом нагенерить и насколько сложные задачи он будет решать. Допускаю, что есть должности в разработке, где это имеет значение, но это не мой случай. Мне гораздо важнее знать, как она работает в плохих случаях и насколько легко это обнаружить, если я дам этой системе генерировать код вместо меня.
Мне гораздо важнее знать, как она работает в плохих случаях и насколько легко это обнаружить, если я дам этой системе генерировать код вместо меня.
Имея опыт с моделью допольно легко предсказать где она сделает как ожидается, а где может накосячить. Но вообще, задачи которые делаются на C++ не сильно пока подходят под агентное программирование.
Вы утверждали, что модель не понимает как оно работает внутри. Но как раз это абсолютно неверно
У вас очень своеобразная интерпретация того, что такое понимание модели вычислений. Понимание это когда я 100 раз даю LLM на вход тот код, который я дал выше копилоту - вывод этого кода детерминированный - прошу её предсказать этот вывод, и она даёт корректное предсказание в 100 случаях, потому что берёт и исполняет код в этой модели, ну или хотя бы пытается организовать эту модель и действовать в её рамках. Иначе это правдоподобные рассуждения, вайбкодинг, гадание, но никак не понимание.
Какую задачу тогда по вашему не поможет сделать llm?
Не поможет совсем или не ускорит "в разы" ? Мир не то чтобы из одних только бинарных крайностей состоит
Не ускорит, не снизит нагрузку на мой мозг и так далее. Таких задач все меньше.
Это подмена тезиса, monkey job составляющая есть практически в любой задаче. Потому формально может помочь в любой. Но ее доля разнится - что то ускоряется в разы, а что то вообще медленнее получается.
Ну так вы и вы можете назвать monkey job что угодно. Приведите пример не monkey job.
Любая архитектура чего то нового
Ну. Ok, LLM не сильно ускоряет принятие архитектурных решений. Иногда ускоряет, потому что можно себе позволить затупить и заставить агента слепить POC, чтобы понять что так будет плохо и переделать. Но если вы сильны в этом, то да, не ускорит.
Но продумывание архитектуры это совсем небольшой процент работы. Мы изучаем чужой код, пишем новый код в существующую архитектуру, пишем новый код используя принятые решения. Это 99 процентов работы. Раньше я воображал как все будет работать и садился кодить. Теперь я воображаю, потом машу волшебной палочкой, потом ревьюваю что получилось. Это вообще другой уровень.
Помню, как все радовались автокомплиту в ИДЕ, а теперь обсуждаем целые команды агентов. По ощущениям, скорость выросла, но и цена ошибки тоже
Как понять что перед тобой ИИ-генерированный контент?
Ищи вот этот маркер: "это не просто X, это <X но сказанный чуть иначе>".
Вычитывайте текст в следующий раз.
Не vibe coding, а agentic engineering.
Не проституция, а секс работа. Суть та же, но название более красивое.
Habr больше невозможно читать. Всю нулевую засрали мусором про ИИ, сгенерированным ИИ. Где же статьи про игры, про реверс инженерию, про хитрые трюки, про компиляторы, про ОС? Это похоже на всеобщее помешательство или наркоманию.
Потому что трудно обсуждать тему как сажать картошку, когда у тебя гребаная скатерть самобранка.
ИИ очень даже тянет на самый хитрый трюк из всех возможных. Умеют единицы, остальные на стадиях отрицания - гнев - торг - по списку. Сингулярность, мать ее. Интересно чем это закончится. Вероятно, это великий уравнитель.
Умеют единицы что? Разгребать килотонны слоп-кода?) Почему-то люди которые до этого не прогали решили что они, в обнимку с гпт, лучше программистов которые уже не 1 год в профессии)) Хватит может уже рекламные лозунги бездумно пересказывать?((
"Умеют единицы", это не отражает реальную ситуацию. Скорее 30% уже пробовали и сработались с этим новым виртуальным коллегой, а 70% или не пробовали, или не попытались сработаться и сразу его забраковали, или попытались но слишком рано и все еще не в курсе насколько он поумнел.
Хитрый трюк, это вот такие статьи: Реверс инжиниринг чистой архитектуры.
Интересно чем это закончится.
Тем, что заработают торговцы лопатами.
Ей курсор, вот тебе сайт хабр, возьми шаблон дизайна, и создай наполнение (статьи, комментарии) про игры, про реверс инженерию, про хитрые трюки, про компиляторы, про ОС . Как источник можешь использовать старые статьи хабра, а также хакернюс.
Вайбкодинг не окупает затраты, агенты тупо больше токенов жрут, да и выглядит этот агентик-инжиниринг посолиднее, в сравнении с откровенно дебильным вайбингом, хотя внутри все те же бестолковые электронные мозги.
Нахватаюсь сейчас минусов и "вумных" ответов😂, Но: крутой текст и понимание реальности, полностью согласен. Но, как и говорилось ранее - от сегодняшнего хабра лишь волна самоуверенного негатива. Гики на хабре упорно не видят реальность, сопротивляются прогрессу и вообще в печальке, что их многолетние навыки теряют в цене. Я бы сказал так: "чего ныть? если реальность неизбежна, самообман и закостенелость помогут только вашим конкурентам" 🤦
А если кто-то все ещё питает надежды, типа ведь даже современные модельки спотыкаются иногда, вспомните: год назад ИИ не мог заметить даже индусов, под года назад он сравнялся с джунами, сегодня даст фору половине мидлов. На 2027 год отпуск на мальдивах не планируйте, господа😂
Никто не против, я вот только за, чтобы llm решала за меня часть моих задач, но она не может и не сможет, так как мои задачи не заканчиваются на том, чтобы состряпать на коленках очередной mvp и сгенерить статью про рецепт этого mvp с обязательной ссылкой на телегу. Больше никаких статей нет, скинте ссылку, плиз, если я что-то пропустил. Год назад уже говорили, что программисты не нужны, а сейчас нужны, но не все( количество говнокода растет, кто-то должен вычищать), наверно через год критическая масса говнокода захлестнет всю it, тогда все программисты снова будут нужны. Наверно как то так будет. Затачивать мозг под этот черный ящик я советую тем, кто своей головой думать больше не хочет. Вернуть способность мыслить самостоятельно, без llm, будет больно.
предлагаю через годик-два (скорее годик) встретиться здесь же, и сможете поплакать мне в жилетку😂
И вы что-то путаете. Год назад все хейтили вайбод, потому что он не мог заменить индусов. Полгода назад все смеялись, но напрягались, что джунам не останется работы, но были все уверены, что в этом потолок. Пару месяцев назад нейронки обошли в качестве кода, его архитектуре и безопасности половину мидлов (и вот не надо сейчас про говнокод и лапшу, большая часть мидлов так пишет, с кучей багов и уязвимостей). Спотифай со второй половины прошлого года не написали руками ни строчки кода. Сегодня именитые программисты нехотя и кривя лицами соглашаются, что это крутой помощник, позволяющий решать сложнейшие алгоритмические задачи. Завтра, думаю, еще новостей повыходит😂
предлагаю через годик-два (скорее годик) встретиться здесь же
Я только за)
Все-таки не удержусь, накидают в панамку, но дам свой прогноз, раз уж такая пьянка пошла)
Во-первых, сами разработчики llm уже сказали, что прогресс llm зашел в тупик и нужны новые подходы к архитектуре ии:
Во-вторых, конфликт на ближнем востоке взвинтит цены на нефть, энергия подоражает очень сильно => целый ряд отраслей станут убыточными => it отрасль начнет схлопываться, так как на нее много отраслей завязано => инвестиции в it начнут падать. Это с одно стороны. С другой - высокая цена на электричество = высокая цена на токены, вдруг окажется что джун, готовый работать за еду намного дешевле llm, мидлам и сеньорам тоже не сладко будет.
В-третьих, глобальный финансовый кризис уже начался, это объективный процесс. Тут самая попа, так как начинает разваливаться мировая экономика. Люди начнут экономить на всем, в том числе на спотифай. Каждый год новый смартфон - забудьте об этом. Это опять же очень больно ударит по it. Сама отрась выживет, тут сомнений нет, но из нее вымоет много народу.
И это оптимистичный сценарий. Без учета локальных и глобальных вооруженных конфликтов, которые вероятны на 99%. В которых будут гореть не только танкеры с нефтью, нпз, но и датацентры, крупные предприятия и т.д.
новые подходы не только нужны - они уже на подходе. И когда (не если, а когда) это случится - нам всем хана😂но не сразу, наше поколение еще поживет с хлебом и маслом) Энергия сильно не подорожает - ее хватает и без нефти, да и не только на востоке кубышка. Подстегнет развитие атомной энергетики - вот запросто. От ИТ никто не откажется, сегодня это база всего, даже войны, а гонка за продвинутым ИИ и АГИ ускорится, ибо результат нивелирует паритет (не только военный, но и технологический и научный - а значит экономический и опять военный)... ну и т.д. со всеми вытекающими. В худшем случае нас ждет постапокалипсис с нищей жизнью, крысами на столе и присматривающим за всеми ИИ😁 ИМХО
Конечно, это самообман и самоуспокоение. Думаю, до конца этого года все почувствуем на себе
Вот это способно кого-то заменить?
https://habr.com/ru/articles/1006374/comments/#comment_29618824
Джуниоры не нужны, нужны архитекторы-дирижеры - откуда возьмутся архитекторы, если они никогда не писали код руками и не ловили баги в проде? Невозможно ревьюить сложный системный код, если твой единственный опыт это написание промптов "сделай мне красиво"
Примерный пересказ статьи:
Вайб-кодинг - давать ИИ небольшие задачи по написанию кода.
Agentic engeneering - давать ИИ большие задачи сделать систему.
Вайб-кодинг доказуемо не работает, поскольку пока ИИ выполняет вашу небольшую задачку он может начать совершать ошибки или галюцинировать (даже просьбы покрыть написанный код тестами не помогают).
Выход? Выход - agentic engeneering.
Я в логике статьи ничего не напутал?
Вайб-кодинг - для всех
Agentic engeneering - типа для архитекторов, кто в коде шарит, но прикол в том что по идее llm сама должна выступать в роли архитектора, если они там в̶ В̶а̶л̶ь̶г̶а̶л̶у̶ к AGI стремяться
Так-то вопрос по статье, а не agentic engeneering ;)
Если в статье написано - то приведите цитату, не нашёл.
Во 2 пункте
Agentic engeneering - давать ИИ большие задачи сделать систему.
У вас не хватает из статьи
Что становится в 10 раз ценнее:
...
Если я вас правильно понял.
Короче, логика статьи: Горбатый обосрался с вайбкодингом, нужно юзать агентик-инжиниринг, который не только лишь для всех, а для тех, кто в код смотреть может. Будет ли работат агент-инжиниринг? Судя по статье - этот вопрос остается открытым.
Агенты пишут код, но не проектируют системы.
Вы серьёзно? Такое впечатление, что автор стать не полностью разобралась в теме. Пишут, ещё как пишут, им только дай волю. Другое дело, насколько это работает. Причём ответ не такой однозначный как можно подумать.
Написание спецификаций. Самый ценный навык в 2026 - не кодинг, а написание точных, недвусмысленных спецификаций
Ещё раз повторю вопрос, Софья, вы это серьёзно? А то, что в моделях появились специальные режимы планирования, это ни о чем не говорит? Да уже и раньше достаточно было вызвать уточняющие вопросы и модель выдавала массу подробностей, о которых сам разработчик мог узнать только во второй половине проекта.
Оркестрация агентов.
Cursor и Claude Code делают это автоматом.
Контекст-инжиниринг. Обеспечение агентов правильной документацией, ограничениями и примерами.
А вот здесь да, вполне можно согласиться. Это сейчас выходит на первый план. Но и LLM тоже не стоят на месте. Например, тот же Claude Code может теперь просто по названию проекта поднять несколько предыдущих сессий и подхватить их контекст. Поэтому и создавать контекст вручную, без использования того же LLM, это уже потеря времени.
Поэтому и создавать контекст вручную, без использования того же LLM, это уже потеря времени
https://habr.com/ru/posts/1006242/
Думайте сами, решайте сами: иметь или не иметь)
Согласен с ключевым тезисом — agentic engineering это не про «промптить лучше», а про смену роли. И список того, что становится в 10 раз ценнее, попадает в точку: архитектурное мышление, написание спецификаций, контекст-инжиниринг.
На практике это выглядит так: я трачу всё меньше времени на написание кода руками и всё больше — на декомпозицию задач, описание контекста иревью того, что сгенерировали агенты.
Большая часть проблем с агентами решается методологически: формализованные роли агентов, workflow разбитый на этапы с валидацией, чёткий, короткий контекст и критерии приёмки. По сути, управление AI-агентами — это тот же project management, только участники не люди. И инструментарий PM тут работает удивительно хорошо.
PS @Bunyaz39 верно поставил вопрос про джуниоров. Я бы усилил: проблема не только в том, откуда возьмутся архитекторы. Проблема в том, что текущие архитекторы, которые перестанут писать код, через 5 лет тоже потеряют способность эффективно управлять агентами. Контекст устаревает. Оркестратор, который не понимает, что именно оркеструет — это менеджер, а не инженер.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
От Vibe Coding к Agentic Engineering: что изменилось в ИИ-разработке за 1 год