Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 45
Я дал плохие инструкции или кривой контекст, раз мидл-разработчик (а современные модели это уверенный мидл) не справился"
А может быть не такая уж она и мидл, если мидлы всегда справлялись, а модель не справляется?
А не встречались в жизни с такой ситуацией: заказали команде какую то софтину, они приносят результат - а там ерунда какая то, которая заказчику не нравится и вообще он не то имел ввиду? По мне так распространенная ситуация
Только с агентами ситуация немного сложнее - они не все переспрашивают и уточняют. В план-модах некоторых агентов не даром добавили инструмент "задать вопросы польователю".
Поэтому - да. Агенты могут делать хорошо, но пока не волшебники, и не могут угадывать. И у них не такой промптинг чтобы отказываться делать, пока им самим задача не до конца ясна. Входите в ситуацию
А когда в плане все указано, а он берет и делает совсем другое?
так бывает крайне редко, я в последнее время такого не встречал. Раньше такое бывало с небольшими локальными кодинговыми моделями
У нынешнего поколения gpt моделей (и базовых, и -codex версий) весьма неплохо со следованием инструкциям. Клод тоже нормально слушается инструкций, только ему надо их немного строже ставить и верифицировать.
Поэтому я не встречался с такими кейсами - когда "берет и делает совсем другое". Бывало что в большом плане не все делает, но в моих влоу всегда есть этап верификации на такой случай.
А у вас с каким агентом и моделью такие случаи бывали?
Может быть везло, но обычно больше всего сложностей с тем, чтобы получить внятные требования от заказчика, а вот в коммуникации между инженерами уже минимум таких проблем, так как есть некая общая база, а если они что-то не поняли, то попросят выражаться яснее. И это это одна из характеристик, которые отличают мидла от джуна – мидл лучше понимает, чего именно у него просят, и какие моменты лучше сразу уточнить, если они ему непонятны.
Ну вот ровно как с моделями сейчас - агенты уже в план-моде спрашивают у пользователя если им что то непонятно. Кодекс бывает спорит по решениям. Так что технологии развиваются. Я оцениваю их по поыту как уверенных мидлов, хотя еще несколько месяцев назад это были скорее джуны. Но уровень gpt 5.2/opus 4.6 какую то границу перешел.
Агент это не просто мидл, а мидл вышедший в 1 рабочий день на вашем проекте.
Зависит от системы работы с контекстом на вашем проекте.
В моих проектах с меморибанком и флоу агенты себя чувствуют "в теме". Для этого используем progressive disclosure на старте сессии, и "прогрев" сессии вопросами по теме работы (я называю этот процесс праймингом).
Всем советую! Рещультаты работы будут совсем другие
Такое впечатление, что статью написал не разработчик, а очередной «вайб-кодер». Во-первых, LLM это немного не ИИ. Во-вторых, текущие LLM - это джуны, а в некоторых случаях весьма дремучие джуны. В-третьих, LLM подвержены галлюцинациям, самодеятельности, забыванию контекста и игнорированию плана, вне зависимости от уровня подготовки задания. Opus 4.6 сейчас стал +- походить на какого-нибудь свежего мидла
>Во-первых, LLM это немного не ИИ
А тогда что такое LLM и что такое ИИ?))
>Во-вторых, текущие LLM - это джуны, а в некоторых случаях весьма дремучие джуны
Ну у кого как, но на мой взгляд, когда нечто довольно самостоятельно и может выполнить задачу по плану, то это вполне хороший миддл
> В-третьих, LLM подвержены галлюцинациям, самодеятельности, забыванию контекста и игнорированию плана, вне зависимости от уровня подготовки задания
Ага, работу с контекстом никто не отменял, но с современными моделями gpt этого требуется меньше, чем с моделями claude, даже с opus 4.6
разумеется это вайбкодинг :)
профессионал рассказал бы про belief state, позиционные кодировки, семантические разметки, автогенерацию многоуровневых доков, семантические графы приложений, да хотя бы про MCP-доступ к документациям фреймворков. В общем все то что позволяет агенту реально автономно работать с проектами из сотен файлов и сотен тысяч строк кода не теряя контекст.
Ничего из этого не используется в реальной практике и в большинстве своем несёт ненужный оверхед.
Если человек разберется с базой, о которой написано в статье, то он может добавлять все эти модные слова по мере необходимости
Вы описываете какой то вымышленный флоу
Позиционные кодировки используют модели в работе с контекстом внутри, это не технология пользвоательского уровня.
Семантические графы - есть любители, но это один из подходов. Если вы не финтех со строгим регулированием и требованиями полной трассируемости кода и RLM, то смысла особого в графе нет.
MCP доступ к документации - возможно context7 можно упомянуть. Но его заменяет в грамотном флоу веб поиск в случае вопросов. Либо нормальная модель со свежим knowledge cutoff. К тому же отрасль движется от MCP к библиотекам Skills и обвязке CLI в скиллы. Так что это не для начинающих - это для продолжающих
И проект из сотен файлов и сотен тысяч строк кода - это не уровень начинающего. Не путайте целевую аудиторию.
Современное поколение моделей - начиная с gpt 5.2 и opus 4.5 - уже ни разу не джуны. В нормальном флоу и с нормальной подготовкой проекта к ИИ разработке все работает весьма толково.
Проблем с галлюцинациями в текущем поколении моделей на распространенных стеках нет от слова совсем.
Самодеятельность - зависит от качества промптинга. С гпт все просто, а вот для Опуса требуется некоторый навык и понимание его особенностей.
Забывание контекста в пределах свежей сесси до компакта отсутствует, а до компакта доводить ее непрофессионально.
План современными моделями не игнорируется
Ваше мнение построено или на устаревшей информации, или на работе со слабыми моделями. Текущий фронтир такими особенностями "давно" не обладает (уже пару релизов). И опус 4.6 - не вершина в кодинге.
Вычитывать тысячи строк кода за AI утомительно и опасно — глаз "замыливается".
Ой, все
Зачем вычитывать тысячи строк кода, когда можно открыть соседнее окно консоли и попросить его же сделать ревью)
Не только ревью
Если говорить о флоу, то сначала делаем чеки (lint/typecheck/build/test:unit/test:integration/test:e2e), потом - верификацию (сверим план с фактом), а потом - можно и ревью
Я в канале как раз последний эвал делал на ревью кодовой базы раными моделями. Тестили свежих китов против фронтира
А ещё лучше модель другого вендора...
А вы читаете и контролируете агентов?)
Это вайбкодинг. Признак, по которому его отличают от более здоровых практик – принципиальный отказ от человеческого ревью, просмотра специалистом сгенерированного кода.
Если агент ошибается, это почти всегда проблема процесса:
Контекст: не собран, противоречив или содержит мусор.
Инструкции: их мало, они не директивные, слишком абстрактные или, наоборот, перегруженные деталями.
Критерии: нет автотестов, вы не объяснили, что такое "хороший результат".
Если вот это все мешает мидлу решить задачу, то это не мидл ) мидл приходит с правильными вопросами
Быть может, стоит по TDD тогда писать, раз все равно надо про тесты думать?
Вот да. Тут пропагандируют генерировать агентами и код, и тесты и ревью. Точка контроля размывается. Ну, может, и так можно сделать надёжную систему, посмотрим.
Интересно, сколько это в итоге будет обходиться. Магия вне Хогвартся не бесплатна
Как раз сегодня был ответ: $118 за один запрос ☺
https://habr.com/ru/news/1000302/
Круто! Но если нет денег на агента, можно воспользоваться схемой уменьшения контекста — это очень хорошо работает. Просто пишем задание, он его делает, а потом делаем прогрев из прошлой сессии или калибруем его прямо в чате и просим переписать задание под систему. Иногда можно обойтись и без этого, если написанная функция имеет достаточно большую автономию.Еще я заметил, что машина часто врет, говоря, что все готово. Если автотест написан ею же, она может сгенерировать код, который будет проходить только этот тест — так сказать, сделает именно то, что попросили. Поэтому, если есть возможность протестировать все вручную, это будет идеальным планом. Однако тут уже все индивидуально.Я бы сказал, что самое важное в работе с ИИ — точно понять, что должно быть в конце и как к этому нужно прийти. После этого это можно описать максимально декларативно и подправить углы. Если со второй попытки ничего не получится, то придется смириться и работать самостоятельно — так будет быстрее.
в целом - норм, но есть замечания
делаем прогрев из прошлой сессии
Это как? продолжить прошлую сессию? неэффективно - она же на прошлую задачу потрачена
машина часто врет, говоря, что все готово
Это отдельные модели склонны, в частности Клод - но там немного не так линейно. Он "срезает углы", а не впрямую врет. Но у openai моделей нет таких вопросов.
Точно понять, что должно быть в конце
Да - но не надо придумывать как к этому придти - это задача агента. Нужно придумать как сделать тест, чтобы проверить что пришли. И с тестом агент прийдет
придется смириться и работать самостоятельно
Не стоит - лучше разобраться что вы делаете не так! Это эффективнее. Любая неудача или сложность - повод повысить свой уровень
У меня по прочтении всего этого возникает один вопрос. А не быстрее будет самому написать код, чем вот это всё? (в моей практике ОБЫЧНО получается быстрее).
Какой-нибудь скрипт интеграции средней сложности любая современная модель напишет Вам за минуту. А Вы - нет ) Причем он у нее заработает с первого раза.
Вот только чтобы она его за минуту написала, мне придется сначала два дна собирать правильный контекст, писать вИдение, планы, правила, тесты ... а потом да, она за минуту напишет ... может быть.
Если реализация нужна на незнакомом языке или тебе совсем не хочется думать о всяких нюансах, которые базовые, просто тебе совсем лень, то LLM подойдет идеально
Вот надо тебе баш скрипт написать, ты конечно можешь пойти вспоминать или изучать команды, синтаксис и так далее, а можешь попросить модельку, она с башем хорошо работает. А если ты не можешь сформулировать к ней запрос, то сам то как собрался писать?
так все такого рода писули публикуют те, кто вообще ничего в программировании не понимает. и принципиально не хочет учиться.
поэтому ужасный недоджуновский код LLM для них это код мидлов )
Нет.
Разница в скорости гиганская. Среднего размера системы пишутся за недели, а не месяцы
Данная статья не решает главные проблемы, когда у модели заканчивается контекст она перестает помнить старые фичи и при вводе новых постоянно что-то ломает или удаляет, из-за чего на крупном проекте кол-во ошибок от модели растет диаметрально.
А все перечисленное я использую и да оно работает .
Вы невнимательно прочитали. Именно пункт 2 в статье про прогрев и подготовку контекста решает ваши вопросы. Агент должен работать на подготовленном контексте. Да, подготовка "вручную" более хлопотна и требует некоторого навыка - но ничего ракетнокосмического. Просто гоняете агента по системе "сверху вниз", он ее изучает. Потом гоняете подробнее про подсистему с которой работаете/ее зависимостям. Если агент норм познакомился с подсистемой, он не будет делать никакого дублирующего кода.
Конечно, меморибанк решает эти задачи системнее.
И этап проектирвоания - это в том числе проработка интеграции доработок в систему. Не даром в агентах появляются субагенты-исследователи. Как раз для изучения вопросов, например для интеграции.
Очень узнаваемо: “агент пишет код” - это не фича, это смена роли инженера на организатора процесса. Самая сильная мысль тут - про тесты как критерий приемки. Я бы её усилил ещё одной штукой: контур доказательства (артефакт - проверки - короткий отчёт “что сделано и чем подтверждено”). Вопрос: вы пробовали жёстко ограничивать “инициативу” агента (например, bounded loop: N итераций - стоп - эскалация человеку с фактами), чтобы он не превращал задачу в вечный рефакторинг?
Вы уже затрагиваете продвинутую тему - это флоу разработки
В целом все верно написали
Для своих флоу у меня стандартный паттерн - 2 цикла агентного фикса после проблемы, если не получается, то эскалация до пользователя. Это в оркестраторе при процессах/флоу планирования, реализации, верификации или ревью.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
6 советов от практиков AI coding