Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 47
Прочитал по диагонали, ничего не понял так как не программист, но было интересно.
Теперь у меня вопрос: насколько реально один раз настроить такую систему пользователю, плохо разбирающемуся в программировании чтобы она работала? (Ну и обучить его азам)
Правильно я понял что это 3 api , встроенные в VSCode? Есть какой-то удобный интерфейс? Или всё через командные строки?
Идея в том, что это не просто плагин для VSCode, а автономный «цех»: вы кидаете задачу (например, в ТГ), а оркестратор-дирижер сам управляет агентами через API, прогоняя их работу через Docker. Настроить всё с нуля без базы в IT сейчас сложновато. Нужно уметь поднять скрипты и инфраструктуру, но разобраться в азах управления реально за пару вечеров. Здесь навык постановки четких ТЗ становится важнее умения писать код, по большей части сам код за вас напишут и проверят агенты.
насколько реально один раз настроить такую систему пользователю, плохо разбирающемуся в программировании чтобы она работала?
Не получится. Здесь нужно постоянно следить за тем, что поломалось и чинить это.
Всё может поломаться при следующем релизе ИИ, например, когда OpеnAI выкатит новую версию ИИ и отключит старые.
Сами агенты тоже постоянно обновляются и активно развиваются, т.е. ещё одна точка поломки.
Агенты при своей работе могут удалить себя или поломать свою конфигурацию.
Также есть риск внешнего вмешательства, когда кто-то сделает Prompt Injection и ваш агент будет выполнять работу для другого человека.
Куча проблем с разделением прав и обязанностей, а также общей безопасностью.
При проблемах или галлюцинациях ИИ вам нужно будет править системный промт, чтобы это как-то обойти.
В общем, точек, где всё может сломаться, тут слишком много.
Хорошо, поставлю вопрос по-другому:
Сможете ли Вы мне настроить такую сборку чтобы она хотя бы запустилась? 50% ошибок, возможно решу сам, 50% обращусь за помощью
Вариант с телегой мне не подходит по многим причинам
У меня есть много монотонной работы с текстом, завернутым в код (LaTeX), которые надо преобразовывать. Ии справляются, но автоматизировать я это не могу. Нужен второй ии с плетью, который будет заставлять продолжать работать первого
N8N тебе в помощь...
вот вы минусуете и смеётесь, а на самом деле есть очень много задач которые можно было бы решить.
Сейчас любой инженер работает в САПР, в которой уже встроен язык программирования, который позволят автоматизировать рутину.
И ты можешь быть крутым инженером, но в яп- новичок. и набросать и отладить скрипт- это пару тройку дней минимум.
Если данный подход бы стал удобен и доступен- я за.
Но как всегда, как только ты хочешь попробовать- настроить сложно, ты не из программистской тусовки и проще забить и снова сидеть ручками работать, а не "вот это ваше все с волшебной кнопкой"
Если вы спросите почему, то отвечу что у инженера есть такие же дедлайны и роадмапы только звучат по другому и разбираться в пермудростях иногда просто нет времени.
Толстый троллинг. Три Иии лучше одного весь смысл. И дальше переписка детали. Сводится к анекдоту. Один чел в состоянии ИИ куча умных мыслей но когда возвращается назад не помнит. Ну и решил в состоянии ИИ записать карандашом. Ну когда в себя пришел читает: банан большой а кожура еще больше!
Спасибо, очень интересно!
Я сейчас разрабатываю похожий конвейер, но с несколько иной архитектурой. В системе используются специализированные агенты, каждый из которых отвечает за отдельную область проекта: админку, фронтенд, WMS и т.д.
Перед передачей задачи агенту-кодеру модель-диспетчер вызывает соответствующего доменного агента, чтобы обогатить контекст и предоставить релевантную информацию.
При этом сами доменные агенты не пишут код - они работают исключительно с базой знаний и выполняют роль экспертов по своим направлениям.
пришел к похожим идеям - осталось только запихать это в курсор каким-то образом
А чем агент-деплоер отличается от настройки CI/CD?
Судя по описанию и логике вы создали рабочий вариант агентов. Пусть они и работают не идеально, но уже более-менее свои задачи решают, т.е. время на их создание и поддержку вы потратили меньше, чем то время, что они вам сейчас экономят.
Проблема тут в другом. Всё это ожидаешь получить в готовом виде, как это рекламируют OpenAI и Anthropic, т.е. не тратя своё время на то, что должны были реализовать ИИ компании.
Всё, что сделали вы, это создали поверх ИИ надстройку, которая фиксит часть проблем самого ИИ. А хочется, чтобы OpenAI и Anthropic изначально построили свои ИИ с учётом этих нюансов, чтобы потом проблемы не возникали изначально, а также чтобы у OpenAI и Anthropic были такие же развитые ИИ агенты, как это удалось реализовать вам.
Иными словами до массового применения агентов в разработке должно пройти ещё несколько лет, пока не поумнеют агенты от OpenAI и Anthropic, пока не появится ролевая модель разработки (как это сейчас реализовано у вас) и прочее.
А ведь проблем с ИИ и агентами сейчас полно: маленькие контексты, забывание информации, первоначальная подгрузка состояния, кэширование токенов, оптимизации для уменьшения сжигания токенов, галлюцинации, зацикливание на чём-то одном и работа по кругу, подвисание, долгое "думание" и прочее.
. А хочется, чтобы OpenAI и Anthropic изначально построили свои ИИ с учётом этих нюансов, чтобы потом проблемы не возникали изначально, а также чтобы у OpenAI и Anthropic были такие же развитые ИИ агенты, как это удалось реализовать вам.
Не смотря на улучшения типа deep reasoning, thinking, MoE, в само ядро того же Opus никто не будет закладывать подобные циклы: "Ответ(код) - Ревью - Исправление - Тестирование". Ответы получаются дольше и дороже, сравните даже ценники API на модели типа o1.
Поэтому и приходится на практике рассматривать LLM как очень умную амёбу и помещать её в экзоскелеты из внешнего кода и внешней памяти.
Так они и обучают новые модели каждый год. Представьте что вы хотите сварить свой сорт пива, и каждый раз получается всё лучше и лучше, так зачем тратить время и деньги на исправляющие вкус текущей промежуточной жижи добавки, когда ее и так можно местным алкашам продать.
>должно пройти ещё несколько лет, пока не поумнеют агенты от OpenAI и Anthropic
Они же уже в режиме агентов работают сутками и пишут всякие браузеры и компиляторы. Да, не идеально, но и задачи для одного человека непосильные.
Да и в целом тут вопрос не к моделям, а к инструментам их использующим - рои агентов и сейчас могут быть эффективны, просто надо заморочиться с их конфигом и запуском, как ТС.
Пожалуй, первый популярный в массах инструмент для агентов в этом плане - OpenClaw. Дальше - будет больше, может и от вендоров моделей что-то увидим своё.
А не пробовал 2 - 3 кодера параллельно по одной задаче, потом архитектор сравнивает и берет лучшее?
Большинство проблем решается четкой и понятной архитектурой проекта + mcp документация по фреймворку + нужные скиллы по требованию. Если использовать клод, то он сам может создать сколько угодно агентов с изолированным контекстом. А еще вы удивитесь, что если гонять по кругу ревьюера из вашего пайплайна, то каждый раз он будет находить critical/high баги)
Большинство проблем решается четкой и понятной архитектурой проекта
Не решается. Ии неплохо умеет в популярную архитектуру и Фреймворки, например запили эндпоинт или микросервис, архитектура понятна, проста и известна в общем почти всем.
А частные случаи, какие то нестандартные решения, это уже он берет с скрипом. Я могу привести пример подобных задачь с прошлой работы.
На проекте самописные протоколы связи, проект активно работает с интеграцией оборудования на очень разном инструментарии от modbus в том числе с самописными библиотеками и can до байтовой передачи и драйверы. Часто это стоит на дурнопахнущих вещах но альтернатив нет. И в таком окружении ии уплывает. Когда ему контекст, архитектура и тд. Знакомы плохо. Там как не переписывай это не поможет. А кейс реальный.
пруфов нет?
То что в промпте написали не хардкодь, гарантий не даёт. Я думаю надо ИИ ке в команду все таки давать чисто алгоритмического контролёра.
я до CLAUDE.md додумался сам, чем искренне горжусь : )
ну, т.е. я буквально спросил LLM, — а может сделать какой-то файл, типа README или CHANGELOG, только для LLM? — оно мне и подсказало.
учитывая, что в предыдущем сообщении к тому же LLM я вообще узнал про то, что вместо чат-бота стоит использовать агента — вполне себе достижение (нет, потом я узнал, что это стандартная практика, но сам же додумался, радость).
в итоге сейчас делаю не CLAUDE.md, а CONTEXT.md, делает то же, выглядит не настолько vendor-lock. Ну и да, контекст там для любой нейронки — хоть цифровой, хоть мокрой.
Антигравита такое понимает?
теоретически должна.
попробуйте на CONTEXT.md из моего пет-проекта, интересно.
если ревьюер не знает суть таска, как он проверит исполнение? например, в задаче было "сделай фичу 1 так чтобы она использовала фичу 2". кодер сделал фичу 1, она работает, но совсем другими путями. ревьюер оценит код, но не зная о задаче, не скажет, что исполнение неверное.
Ну я щас пищу систему на 100 агентов с маштобируемостью до 1000-2000 агентов. Что могу посоветовать : делай таски разбитые на атомарные задачи и мониторь все что можно и нельзя, плюс спизди дифы с антигравити от гугла. А если хочешь запариться то можно даже сделать общую память вынесеную в github репозиторий, и каждые 10-15 минут её обновлять пюподгоняя её исходя данных на пк.
Имеет смысл писать ИИ систему которая сама будет находить оптимум в количестве агентов, работающих над задачей. И скорее всего это уже не написание системы, а написание системного промпта
Начал только изучать подобную связку, когда понял ограничения одного ии для своего пет проекта. И тоже пришел к идеи внешней памяти, только не github. А вынести это в полноценные внешние БД, у многих есть интеграции и доступ к ним, что то например Airtable и тд. Именно с структурированной таблицей где лежат нужные данные, да если в идеале оно имеет что то осмысленное вроде индексов, это гораздо эффективнее чем если ии тратит контекс на понимание а что лежит в репозитории, где ему искать, что искать, понимание контекста оного.
Пока обкатываю эту мысль и идею, свои минусы тоже бывают. Поиск, удобство, внешние сервисы иногда подтверждения требуют, лимиты и тд. Но сам концепт внешней памяти работает с специализированными таблицами намного лучше.
Зачем Вам 100-2000 агентов?
Автор молодец 😎 построил удобную и работающую систему с 0, но сейчас очень много разных оркестраторов я смотрю в сторону проекта Claude-flow/RuVector
Не понимаю почему это выгодно. Даже если я формирую задачу, то не выполняют быстрее, чем я сформирую новую задачу , соответственно конвейера нет, я даю задачу, почти сразу надо проверять.
и кто решит удовлетворило ли оно бизнес требованиям или нет.
И как написать неочевидные тесты, где важна внешность кнопок, поехавший интерфейс, мазок нарисованный от руки, экран скриншотить тестами? Мне кажется создание таких тестов , а именно каждого нового, дольше самого приложения будет.
Да и тесты создавать кто будет, они же? А проверять создание ими тестов?
Вопрос постановки задач не раскрыт - как это происходит, сколько раз надо уточнять саму постановку, чтобы на выходе получить что-то полезное и кто это делает?
Респект автору! Материал сильный и, что важно, инженерно честный. Это не «вау-демо», а разбор работающей системы с шрамами.
А все же, если завтра этот же конвейер начнёт стабильно делать логически корректный, хорошо протестированный, но бизнес-вредный код (например, оптимизировать не ту метрику или убирать “избыточные” проверки, которые нужны только из-за реальных пользователей), на каком этапе система вообще способна это поймать — и должен ли это ловить агент или человек по определению?
Сильный материал, спасибо!
Давно хотел спросить - а есть ли в природе агент или модель, которая не просто "универсальный программер", а "конкретный программер на Python"? Чтобы он не средние проги на десятке языках, а серьезные - но на одном?
Скорей всего придётся самостоятельно собирать, либо попросить какого нибудь мейнтернера типа https://huggingface.co/mradermacher
Некоторые модели бывают заточены только на популярные языки типа Qwen Coder около 90, а есть монстры наподобие Codestral у которых под капотом знания о 150+
Поинтересуйтесь у ии по этой теме.
Странно это всё)
Разве сейчас в большинстве расширений именно так и не сделано, всё разбивается на агенты под каждую задачу и автоматом переключается. У каждого свой системный промпт с описанием его роли. Ну и собственно можно роли подредачить под свои нужды.
Так например в
https://sourcecraft.dev/portal/docs/ru/code-assistant/
потом ещё в
https://roocode.com
и
https://marketplace.visualstudio.com/items?itemName=kilocode.Kilo-Code
и 100500 других
По сути сейчас такая тактика становится по умолчанию.
Не знаю может в каких то устаревших расширениях до подобного ещё не дошли.
Можно в список задач после "Docker-sandbox с write-доступом" проверить, не были ли модифицированы файлы вне разрешённой области.
Кажется помимо кода нейронка успела ещё и эту статью написать, пока Вы пили кофе целых 23 минуты😅
Статья топ! Отправил ее коллегам на изучение сразу после прочтения)
Вопрос - примерно оценивали, сколько времени заняла настройка и отладка до текущего состояния? Интересно, если подобную логику реализовывать для другмх блоков задач (а она в плане недостатков ИИ, кажется, подходит в целом на все задачи - от копирайтинга до генерации изображений, дизайна или вотэвер)
Нравятся ваши статьи, живой стиль написания, интересные идеи и полезный опыт. У меня было как и у многих сейчас представление о таком как об открытых вкладках чата с помощниками, теперь же видно что можно подойти к процессу гораздо более вдумчиво и построить целую команду.
Эх... Надеюсь Хабр не превратится из гик IT сообщества, в помойку дилетантов вида "Прочитал по диагонали, ничего не понял так как не программист, но было интересно... Помогите настроить так же. Хочу взмахнуть палочкой и всё само" Это какой-то пиздец.
Отличная статья, спасибо (подписался на ваш канал) - особенно ценно, что вы поднимаете проблему архитектурной деградации именно в контексте AI-кодинга, а не абстрактного "плохого кода". Из практики: в эволюционно развивающемся боевом проекте LLM ускоряет локальные изменения, но резко увеличивает риск: размытия границ модулей, скрытого дублирования логики, нарушения направлений зависимостей, роста неявной связанности. Мы столкнулись с этим и родился наш побочный open-source проект.
Проблема в том, что ИИ оптимизирует фрагмент, а не архитектуру целиком. В результате технический долг накапливается быстрее, чем при ручной разработке.
Мы как раз решаем это через автоматический архитектурный контроль. В нашем open-source инструменте https://github.com/ArchiCore-Team/archicore мы формализуем архитектурные правила (слои, зависимости, ограничения) и проверяем их статически. Это позволяет: фиксировать нарушения сразу после генерации кода, не полагаться на "архитектурную память" команды, безопаснее интегрировать AI в CI/CD.
По сути, если LLM ускоряет кодирование, то архитектурные инварианты должны быть машинно проверяемыми - иначе система деградирует экспоненциально.
Было бы интересно обсудить, как вы видите роль автоматизированных архитектурных проверок в эпоху AI-разработки.
Это новый уровень вайб кодинга)
Но видно что это по сути довольно сложная в реализации игрушка для опытных, большое количество не очевидных проблем которые могут возникнуть и которые нужно ловить и отлаживать, для чего нужен навык. Я лично для своего проекта использую гпт кодекс и просто не даю ему делать ни одного комита, переношу и тестирую каждое решение в движке в ручную, но гпт стал плох в последнее время. Бывает какие то совсем глупые решения предлагает, или то что можно решить за 5 строк он предлагает решение на 25 строк. Я периодически проверяю себя, когда хочу что то добавить, думаю "ну допустим я бы сделал это так" и спрашиваю кодекс как решить или сделать вот это, иногда совпадает, иногда он предлагает лучше, а иногда хуже.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Три агента, один репозиторий, ноль менеджеров. Как я построил конвейер, где ИИ пишет, ревьюит и деплоит код