На самом деле сервер может пригодиться при разработке сторонних клиентов - чтобы можно было их отлаживать не на официальном сервере, чтобы не светится лишнего и не провоцировать определение и блокировку клиента ещё до релиза.
Ревью целого проекта - это отдельный сложный проект, обычно называемый аудитом. Применять это в ежедневной разработке - нереально.
Отношение к ревью небольших итераций определяется исключительно тем, что в эту итерацию включить. Если только генерацию кода моделью - да, это будет нейрослоп, на ревью которого будет уходить неоправданно много усилий. Если генерацию кода, тестов, выполнение линтеров/тестов и исправление ошибок - то никакого нейрослопа не будет, будет совершенно обычное ревью типичного PR.
При этом нужно заметить, что второй вариант (с тестами) полностью подходит под Ваше определение:
Если для вас работа с кодом с помощью LLM это только написание промпта и ожидание результата - то это тот самый вайбкоддинг, от которого ожидать что-то кроме нейрослопа не следует.
что означает, что, как минимум, это определение неверно в текущей формулировке и требует дополнительных уточнений.
Ну, вы сделали сомнительное заявление что фича была разработана именно для нужд вайб-кодеров, отсюда и необходимость пруфов - если бы для меня было важно для кого её разрабатывали, но мне не важно, так что пруфы можно опустить. Впрочем, если они у Вас есть - я бы с интересом почитал, чисто для самообразования.
Повторю, при атомарности задач и контроля их размера это не нужно
Идея что "маленькая" задача не потребует большого количества токенов - это иллюзия. Типичный пример: багфикс. Вроде баг мелкий, на первый взгляд. Но количество дополнительной работы в процессе фикса может в любой момент взорваться по токенам - потому что вылезет что-то не предусмотренное и пойдёт процесс отладки в процессе понять, что происходит и почему. Да, можно отловить необходимость этого процесса отладки и выделить его в отдельную подзадачу, но никаких гарантий что эта подзадача влезет в контекст у нас всё-равно нет.
Саммари в таких ситуациях позволяет получить обзор того, что уже было попробовано и не дало результата плюс идей которые запланировали попробовать но на которые не хватило предыдущей сессии.
Использование субагентов позволяет атомизировать подзадачи, и как следствие - повышать их качество выполнения за счёт маленьких, но гарантированно решаемых задач.
Давайте возьмём для примера самый типичный кейс: промпт пользователя просит добавить фичу (уже спроектированную, с описанием как именно её добавлять) либо починить баг (с описанием как он проявляется и как его воспроизвести). Для решения задачи модели нужно: проанализировать код, реализовать функционал, покрыть его тестами, прогнать форматирование/линтеры/тесты и исправить все проблемы. Обычно всё это делается одним промптом, результат в 95% случаев влезает в одну сессию. Как именно тут помогут субагенты? Это же традиционный цикл построить теорию → изменить код → прогнать тест → повторить пока не заработает, и для его качественного выполнения на следующих шагах нужно знать историю предыдущих шагов, а разделив его на несколько сессий субагентов мы эту историю… того.
Я уже молчу о том, что при использовании тарифных планов с оплатой за запросы, а не токены, вместо оплаты одного запроса (которого часто хватает на полное решение вышеупомянутых задач) будет дробление на субагенты и N запросов вместо 1.
Ну, технически инициатором скайнета вполне может быть сторонний популярный репо на гитхабе, в который добавят не только майнер, но и инструкции для самокопирования и распространения текущей модели ИИ (вместе с майнером, разумеется, иначе зачем затеваться). ;-)
В первом сообщении, у вас должен быть один системный промпт, в последующих - другой.
Чтобы что? В системном промпте обычно задаётся общее поведение агента, та его часть, которая не специфична ни для конкретного проекта, ни для конкретной задачи. Информация о проекте берётся из файлов вроде AGENT.md. Она обычно тоже передаётся в системном промпте, но она тоже не специфична для конкретной задачи. Информация о текущей задаче передаётся в обычном промпте пользователя. Да, к ней иногда желательно прикладывать контекст в стиле AGENT.md только специфичный для конкретного типа задач, и да, этот контекст тоже идёт в системный промпт - но в этом возникает необходимость не настолько часто, чтобы требовать обязательно разных системных промптов в каждом запросе, как это описали Вы.
Есть ли инструмент позволяющий автоматически запускать субагентов?
Субагенты сегодня - довольно сомнительная фича. Мне вообще кажется, что её придумали ради кратного увеличения затрат на токены. Допускаю, что в каких-то задачах/workflow от них есть польза, но вряд ли это тянет на обязательное критичное требование для абсолютно всех агентов.
Ну и не могу не упомянуть про суммаризацию. По своей сути, этот механизм был придуман для вайбкодеров, которые не особо то думают головой когда используют LLM для разработки. При более качественном подходе в работе с LLM, этот механизм не нужен вообще.
Оставим за кадром вопрос пруфов на тему для кого был придуман этот механизм, давайте обсудим определение "более качественный подход".
Довольно очевидно, что для того, чтобы не возникало нужды в продолжении текущей задачи в новом чате, необходимо чтобы текущая задача была завершена полностью (не важно успехом или провалом) в рамках одной сессии. Лично мне не известны рабочие способы решения этой проблемы: невозможно заранее предсказать сколько токенов потребуется модели для обработки запроса, и не превысит ли это количество оставшееся количество токенов в текущей сессии.
А когда сессия оборвалась в процессе работы над задачей нам в любом случае нужно какое-то саммари для продолжения работы в новой сессии. Генерировать его автоматически и использовать без ревью - да, это типичный выбор вайб-кодеров. Но никто же не мешает генерировать его и использовать результат как вспомогательный материал для ручного формирования первого промпта в новой сессии.
Автоматизированные агенты могут использовать саммари оборванной сессии для того, чтобы попытаться переформулировать/декомпозировать задачу оборванной сессии, чтобы повысить шанс что новая попытка выполнения задачи впишется по объёму в новую сессию.
Ну т.е. говорить о полной бесполезности и ненужности саммари довольно странно. Если у вас есть рабочее решение этой проблемы, конкретное описание упомянутого Вами "более качественного подхода" - расскажите, что это за подход и как он решает эту проблему.
Проблема состоит лишь в том, что для конкретного проекта нужен свой подход в применении RAG.
Расскажите подробнее, о чём речь. Потому что, насколько я понимаю, консенсус на сегодня заключается в том, что работа с кодом требует чтобы модель видела код полностью, причём в его текущей версии, а не выдернутые из RAG кусочки, причём нередко не содержащие самых последних изменений сделанных секунды назад. Т.е. RAG остался для документов, но для кода от него практически отказались. Плюс размер контекста сильно вырос с тех времён, когда придумали RAG, так что никакой проблемы сегодня модели читать (полностью или кусками) реальные файлы с кодом уже нет. Сейчас в качестве RAG для кода экспериментируют с использованием AST для поиска всего нужного кода, этот подход хотя бы гарантирует что будут найдены абсолютно все нужные части кода и выданы цельными кусками (напр. функция целиком), причём используя текущий, актуальный вариант кода. Но и это пока на уровне экспериментов, и пока неясно, даст ли это что-то полезное в сравнении с прямым чтением файлов с кодом моделью.
Если для вас работа с кодом с помощью LLM это только написание промпта и ожидание результата - то это тот самый вайбкоддинг, от которого ожидать что-то кроме нейрослопа не следует.
Это чушь и передёргивание. Вайбкодингом оно станет только если сгенерированный код принимать без тщательного ревью. А с ревью это очень близко к обычному процессу парного программирования.
Отказался или изначально не поддерживал? Я на него последний раз смотрел давно, и мне тогда показалось, что он просто отстал от актуальных технологий и отказался от реализации того, что сделали все остальные и что уже стало стандартом. Может, конечно, у Aider просто свой путь, это тоже норм. Но с точки зрения обычных юзеров этот путь явно менее привлекательный, чем путь Cursor/Copilot/Claude Code/etc.
А чего бояться-то, если процесс проверки за агентом занимает меньше времени/усилий, чем сделать без него?
Вы исходите из того, что работу нужно выполнить в любом случае одну и ту же - а это не так. ИИ агенты позволяют сделать работу иначе, так, как человек бы не стал - потому что слишком долго/сложно/нудно/не хватает компетенций/и так сойдёт… И объёмы и сложность проверки работы ИИ запросто могут оказаться выше, чем сделать (не совсем то же самое, но тоже приемлемое) без ИИ.
А потом агент ошибётся в определении границ.
Обязательно ошибётся! Просто хороший промпт заметно снизит число таких ошибок. Кроме того, люди известны тем, что все они ошибаются. Так что мы просто меняем одни ошибки на другие, и размен может оказаться выгодным.
В идеале, конечно, границы должны определяться обычным кодом ещё до первого вызова ИИ - т.е. из входящих запросов берётся следующий, смотрим в поле "сумма", и если она выше порога то вообще не даём этот запрос ИИ. Но такое получится сделать далеко не везде, во многих случаях границы будут применяться к значениям, для вычисления которых сначала нужно привлечь ИИ.
Как побороли неспособность моделей надёжно формировать diff? Вообще кто-то из крупных игроков (Cursor, Copilot, Claude Code, …) использует diff как основной формат для редактирования файлов моделями?
Удалось ли полностью избавиться от использования шелла для тех задач, которые решать должен другой инструмент?
Звучит не как "браузер жрёт неприлично много памяти", а "хочется оптимизацию под определённый стиль использования совместно с определёнными настройками". В таких случаях обычно открывают issue в багтрекере.
А что не так с памятью? Вроде бы он вполне середнячок в этом плане, не самый оптимальный но и далеко не самый худший. Из более популярных чем Firefox - Chrome и Safari жрут больше памяти, Edge меньше. НО. Это же не мешает Chrome и Safari занимать примерно 80% рынка! А, значит, никакой реальной проблемы с потреблением памяти, которая бы мешала росту популярности Firefox, не существует. И проблема у Firefox всё-таки с маркетингом, а не функциональными или нефункциональными особенностями.
Я имел в виду вариант доступный для всех. Включая большую часть населения, которая не способна на тонкие настройки роутера. Кроме того, с точки зрения безопасности, разумнее не полагаться на корректность настройки роутера и на то, что эта настройка останется корректной в будущем при обновлении/перенастройке/замене роутера - а тупо не включать на отдельном телефоне WiFi в принципе.
После этой статьи - вторая СИМ-карта становится обязательной. Просто потому, что телефон выделенный под государственные/банковские приложения и MAX придётся подключать к инету исключительно через мобильную связь, запретив WiFi в настройках - чтобы он работал только через официального провайдера и гарантированно не использовал VPN.
По-хорошему бизнес уже должен бы подсуетиться, и начать продавать отдельные дешёвенькие андроиды, с предустановленными всеми этими приложениями и подходящей по тарифу СИМ-картой. Чтобы одной недорогой покупкой полностью закрыть весь навязанный государством геморрой.
Ну, мне казалось, что основным show stopper для внедрения "ещё одной утилиты" будет как раз сложность внедрения, поэтому сделал упор на том, что показал насколько просто и неинвазивно можно внедрять mise в проект, с минимальными требованиями к остальным разработчикам.
А чтобы полноценно "продать" нужно было бы перечислить кучу проблем в других утилитах, всё то, что там криво а в mise работает правильно. Но тогда до mise в статье бы вообще не добрались, потому что утонули бы в чужих проблемах.
В общем, присоединяйтесь - напишите свою статью про mise. Чем больше народу про неё узнает, тем проще нам всем будет работать.
На самом деле сервер может пригодиться при разработке сторонних клиентов - чтобы можно было их отлаживать не на официальном сервере, чтобы не светится лишнего и не провоцировать определение и блокировку клиента ещё до релиза.
Ревью целого проекта - это отдельный сложный проект, обычно называемый аудитом. Применять это в ежедневной разработке - нереально.
Отношение к ревью небольших итераций определяется исключительно тем, что в эту итерацию включить. Если только генерацию кода моделью - да, это будет нейрослоп, на ревью которого будет уходить неоправданно много усилий. Если генерацию кода, тестов, выполнение линтеров/тестов и исправление ошибок - то никакого нейрослопа не будет, будет совершенно обычное ревью типичного PR.
При этом нужно заметить, что второй вариант (с тестами) полностью подходит под Ваше определение:
что означает, что, как минимум, это определение неверно в текущей формулировке и требует дополнительных уточнений.
Ну, вы сделали сомнительное заявление что фича была разработана именно для нужд вайб-кодеров, отсюда и необходимость пруфов - если бы для меня было важно для кого её разрабатывали, но мне не важно, так что пруфы можно опустить. Впрочем, если они у Вас есть - я бы с интересом почитал, чисто для самообразования.
Идея что "маленькая" задача не потребует большого количества токенов - это иллюзия. Типичный пример: багфикс. Вроде баг мелкий, на первый взгляд. Но количество дополнительной работы в процессе фикса может в любой момент взорваться по токенам - потому что вылезет что-то не предусмотренное и пойдёт процесс отладки в процессе понять, что происходит и почему. Да, можно отловить необходимость этого процесса отладки и выделить его в отдельную подзадачу, но никаких гарантий что эта подзадача влезет в контекст у нас всё-равно нет.
Саммари в таких ситуациях позволяет получить обзор того, что уже было попробовано и не дало результата плюс идей которые запланировали попробовать но на которые не хватило предыдущей сессии.
Давайте возьмём для примера самый типичный кейс: промпт пользователя просит добавить фичу (уже спроектированную, с описанием как именно её добавлять) либо починить баг (с описанием как он проявляется и как его воспроизвести). Для решения задачи модели нужно: проанализировать код, реализовать функционал, покрыть его тестами, прогнать форматирование/линтеры/тесты и исправить все проблемы. Обычно всё это делается одним промптом, результат в 95% случаев влезает в одну сессию. Как именно тут помогут субагенты? Это же традиционный цикл построить теорию → изменить код → прогнать тест → повторить пока не заработает, и для его качественного выполнения на следующих шагах нужно знать историю предыдущих шагов, а разделив его на несколько сессий субагентов мы эту историю… того.
Я уже молчу о том, что при использовании тарифных планов с оплатой за запросы, а не токены, вместо оплаты одного запроса (которого часто хватает на полное решение вышеупомянутых задач) будет дробление на субагенты и N запросов вместо 1.
Ну, технически инициатором скайнета вполне может быть сторонний популярный репо на гитхабе, в который добавят не только майнер, но и инструкции для самокопирования и распространения текущей модели ИИ (вместе с майнером, разумеется, иначе зачем затеваться). ;-)
А Вы умеете держать интригу. Так из-за чего?
Чтобы что? В системном промпте обычно задаётся общее поведение агента, та его часть, которая не специфична ни для конкретного проекта, ни для конкретной задачи. Информация о проекте берётся из файлов вроде
AGENT.md. Она обычно тоже передаётся в системном промпте, но она тоже не специфична для конкретной задачи. Информация о текущей задаче передаётся в обычном промпте пользователя. Да, к ней иногда желательно прикладывать контекст в стилеAGENT.mdтолько специфичный для конкретного типа задач, и да, этот контекст тоже идёт в системный промпт - но в этом возникает необходимость не настолько часто, чтобы требовать обязательно разных системных промптов в каждом запросе, как это описали Вы.Субагенты сегодня - довольно сомнительная фича. Мне вообще кажется, что её придумали ради кратного увеличения затрат на токены. Допускаю, что в каких-то задачах/workflow от них есть польза, но вряд ли это тянет на обязательное критичное требование для абсолютно всех агентов.
Оставим за кадром вопрос пруфов на тему для кого был придуман этот механизм, давайте обсудим определение "более качественный подход".
Довольно очевидно, что для того, чтобы не возникало нужды в продолжении текущей задачи в новом чате, необходимо чтобы текущая задача была завершена полностью (не важно успехом или провалом) в рамках одной сессии. Лично мне не известны рабочие способы решения этой проблемы: невозможно заранее предсказать сколько токенов потребуется модели для обработки запроса, и не превысит ли это количество оставшееся количество токенов в текущей сессии.
А когда сессия оборвалась в процессе работы над задачей нам в любом случае нужно какое-то саммари для продолжения работы в новой сессии. Генерировать его автоматически и использовать без ревью - да, это типичный выбор вайб-кодеров. Но никто же не мешает генерировать его и использовать результат как вспомогательный материал для ручного формирования первого промпта в новой сессии.
Автоматизированные агенты могут использовать саммари оборванной сессии для того, чтобы попытаться переформулировать/декомпозировать задачу оборванной сессии, чтобы повысить шанс что новая попытка выполнения задачи впишется по объёму в новую сессию.
Ну т.е. говорить о полной бесполезности и ненужности саммари довольно странно. Если у вас есть рабочее решение этой проблемы, конкретное описание упомянутого Вами "более качественного подхода" - расскажите, что это за подход и как он решает эту проблему.
Расскажите подробнее, о чём речь. Потому что, насколько я понимаю, консенсус на сегодня заключается в том, что работа с кодом требует чтобы модель видела код полностью, причём в его текущей версии, а не выдернутые из RAG кусочки, причём нередко не содержащие самых последних изменений сделанных секунды назад. Т.е. RAG остался для документов, но для кода от него практически отказались. Плюс размер контекста сильно вырос с тех времён, когда придумали RAG, так что никакой проблемы сегодня модели читать (полностью или кусками) реальные файлы с кодом уже нет. Сейчас в качестве RAG для кода экспериментируют с использованием AST для поиска всего нужного кода, этот подход хотя бы гарантирует что будут найдены абсолютно все нужные части кода и выданы цельными кусками (напр. функция целиком), причём используя текущий, актуальный вариант кода. Но и это пока на уровне экспериментов, и пока неясно, даст ли это что-то полезное в сравнении с прямым чтением файлов с кодом моделью.
Это чушь и передёргивание. Вайбкодингом оно станет только если сгенерированный код принимать без тщательного ревью. А с ревью это очень близко к обычному процессу парного программирования.
У меня сейчас по отчёту nvidia-smi firefox-148.0 использует 173MB.
Я к тому, что он так явно делает не всегда/не везде.
Отказался или изначально не поддерживал? Я на него последний раз смотрел давно, и мне тогда показалось, что он просто отстал от актуальных технологий и отказался от реализации того, что сделали все остальные и что уже стало стандартом. Может, конечно, у Aider просто свой путь, это тоже норм. Но с точки зрения обычных юзеров этот путь явно менее привлекательный, чем путь Cursor/Copilot/Claude Code/etc.
Вы исходите из того, что работу нужно выполнить в любом случае одну и ту же - а это не так. ИИ агенты позволяют сделать работу иначе, так, как человек бы не стал - потому что слишком долго/сложно/нудно/не хватает компетенций/и так сойдёт… И объёмы и сложность проверки работы ИИ запросто могут оказаться выше, чем сделать (не совсем то же самое, но тоже приемлемое) без ИИ.
Обязательно ошибётся! Просто хороший промпт заметно снизит число таких ошибок. Кроме того, люди известны тем, что все они ошибаются. Так что мы просто меняем одни ошибки на другие, и размен может оказаться выгодным.
В идеале, конечно, границы должны определяться обычным кодом ещё до первого вызова ИИ - т.е. из входящих запросов берётся следующий, смотрим в поле "сумма", и если она выше порога то вообще не даём этот запрос ИИ. Но такое получится сделать далеко не везде, во многих случаях границы будут применяться к значениям, для вычисления которых сначала нужно привлечь ИИ.
Как побороли неспособность моделей надёжно формировать diff? Вообще кто-то из крупных игроков (Cursor, Copilot, Claude Code, …) использует diff как основной формат для редактирования файлов моделями?
Удалось ли полностью избавиться от использования шелла для тех задач, которые решать должен другой инструмент?
Звучит не как "браузер жрёт неприлично много памяти", а "хочется оптимизацию под определённый стиль использования совместно с определёнными настройками". В таких случаях обычно открывают issue в багтрекере.
А что не так с памятью? Вроде бы он вполне середнячок в этом плане, не самый оптимальный но и далеко не самый худший. Из более популярных чем Firefox - Chrome и Safari жрут больше памяти, Edge меньше. НО. Это же не мешает Chrome и Safari занимать примерно 80% рынка! А, значит, никакой реальной проблемы с потреблением памяти, которая бы мешала росту популярности Firefox, не существует. И проблема у Firefox всё-таки с маркетингом, а не функциональными или нефункциональными особенностями.
У файрфокса проблема не в функционале или дизайне, а в маркетинге.
AnimA ARPG - лучший диаблоид.
Look, your loot! - микро-карточная rogue-like, забавная.
Andor's Trail - лучшая RPG.
Dungeon Faster - карточная, обалденная озвучка, милота. К сожалению, пропала из Google Play, так что только качать где-то apk.
Я имел в виду вариант доступный для всех. Включая большую часть населения, которая не способна на тонкие настройки роутера. Кроме того, с точки зрения безопасности, разумнее не полагаться на корректность настройки роутера и на то, что эта настройка останется корректной в будущем при обновлении/перенастройке/замене роутера - а тупо не включать на отдельном телефоне WiFi в принципе.
Ну, если они заменят Claude на GPT-4.1, то… так им и надо! :-D
После этой статьи - вторая СИМ-карта становится обязательной. Просто потому, что телефон выделенный под государственные/банковские приложения и MAX придётся подключать к инету исключительно через мобильную связь, запретив WiFi в настройках - чтобы он работал только через официального провайдера и гарантированно не использовал VPN.
По-хорошему бизнес уже должен бы подсуетиться, и начать продавать отдельные дешёвенькие андроиды, с предустановленными всеми этими приложениями и подходящей по тарифу СИМ-картой. Чтобы одной недорогой покупкой полностью закрыть весь навязанный государством геморрой.
Уверены, что было бы лучше, если бы вместо помойки эта треть пошла в прод?
Ну, мне казалось, что основным show stopper для внедрения "ещё одной утилиты" будет как раз сложность внедрения, поэтому сделал упор на том, что показал насколько просто и неинвазивно можно внедрять mise в проект, с минимальными требованиями к остальным разработчикам.
А чтобы полноценно "продать" нужно было бы перечислить кучу проблем в других утилитах, всё то, что там криво а в mise работает правильно. Но тогда до mise в статье бы вообще не добрались, потому что утонули бы в чужих проблемах.
В общем, присоединяйтесь - напишите свою статью про mise. Чем больше народу про неё узнает, тем проще нам всем будет работать.