В последнее время все более популярными становятся CLI агенты.
Claude Code, Codex CLI, Gemini CLI, Qwen Code, OpenCode. GigaCode недавно подтянулся.
OpenClaw туда же, хотя он не заточен под разработку.
Некоторые из них имеют своего IDE аналога, часто даже двух - для IDEA и VSCode, некоторые нет.
Концепции современной CLI (shell) примерно 55 лет.
В 1969 году появился Unix, 3 стандартных потока - stdin, stdout, stderr и перенаправление > и < в файл (концепция "все есть файл").
Чуть позже в 1973 году - концепция pipe (|), т.е передача stdout одного приложения в stdin другого, и т.об. выстраивание команд в цепочку.
И еще чуть позже - в 1975 году - появился vi - редактор с TUI (Terminal UI).
Курсор можно было перемещать в любое место экрана плюс горячие клавиши.
Кроме vim можно вспомнить файловые менеджеры - mc, Norton Commander, Volkov Commander.
И вот сейчас благодаря AI агентам наблюдается некий ренессанс.
Да, CLI API был всегда. git, kubectl, docker, gradle, maven.
Интересна скорее связка TUI + CLI API, т.к. это два разных сценария работы.
TUI - замена IDE. Для каких задач? Видимо тех, где IDE не сильно нужен или вообще не поможет.
Т.е. не работа с кодовой базой, а скорее написание отдельных скриптов.
Если это shell скрипты - то их можно на месте и отладить.
Это DevOps и Ops.
Или быстрые и простые правки в проекте, когда вся мощь IDE не нужна.
А еще проекты, совсем не связанные с кодом. Например, анализ каких-то данных. Создание презентаций и схем.
Ручной анализ ошибок, результата запуска тестов.
Генерация тестовых данных.
Тут агент с TUI побеждает обычный чат за счет режима планирования, скилов, комманд, сабагентов.
И - тут плавно переходим в CLI режиму - разработка и отладка AI агента.
CLI режим по-другому называется headless, head в данном случае терминал.
Вот какие команды поддерживает OpenCode https://opencode.ai/docs/ru/cli/
А вот какие Gemini: https://google-gemini.github.io/gemini-cli/docs/cli/headless.html
Пару примеров из мануала Gemini:
Здесь у нас есть вся мощь CLI - агенту (почти всем CLI агентам) можно передать чей-то stdout.
И передать дальше их stdout, отформатировав его в json. Или сохранить в файл.
Где можно использовать - да везде.
Предварительно настроив сабагентов и скилы.
prCheck, автоматическое code review, автогенерация кода, тестов, документации, отчетов, анализ логов....
Ну и еще два применения:
1) консоль есть в IDE, можно использовать агента там. Правда интеграция будет хуже, чем у нативного IDE агента.
2) если выстрелит протокол ACP https://www.jetbrains.com/help/ai-assistant/acp.html, не путать с другими ACP,
то в IDEA будет стандартное окно AI чата, из которого можно переключаться\выбирать себе агента сохраняя клиентский опыт.
И еще один очевидный, но важный момент: консоль - это инструмент ИТ-шника.
Разработчик, тестировщик, DevOps, Ops, системный аналитик, ИТ менеджер наконец.
Как минимум нужно понимать, почему это установленному скилу потребовался Python, NodeJS и множество пакетов к ним.
Да и с концепцией venv лучше быть знакомым)
И это инструмент локальный - т.е. нужна возможность скачать и установить агента и его секреты (API ключи).
#ai
Claude Code, Codex CLI, Gemini CLI, Qwen Code, OpenCode. GigaCode недавно подтянулся.
OpenClaw туда же, хотя он не заточен под разработку.
Некоторые из них имеют своего IDE аналога, часто даже двух - для IDEA и VSCode, некоторые нет.
Концепции современной CLI (shell) примерно 55 лет.
В 1969 году появился Unix, 3 стандартных потока - stdin, stdout, stderr и перенаправление > и < в файл (концепция "все есть файл").
Чуть позже в 1973 году - концепция pipe (|), т.е передача stdout одного приложения в stdin другого, и т.об. выстраивание команд в цепочку.
И еще чуть позже - в 1975 году - появился vi - редактор с TUI (Terminal UI).
Курсор можно было перемещать в любое место экрана плюс горячие клавиши.
Кроме vim можно вспомнить файловые менеджеры - mc, Norton Commander, Volkov Commander.
И вот сейчас благодаря AI агентам наблюдается некий ренессанс.
Да, CLI API был всегда. git, kubectl, docker, gradle, maven.
Интересна скорее связка TUI + CLI API, т.к. это два разных сценария работы.
TUI - замена IDE. Для каких задач? Видимо тех, где IDE не сильно нужен или вообще не поможет.
Т.е. не работа с кодовой базой, а скорее написание отдельных скриптов.
Если это shell скрипты - то их можно на месте и отладить.
Это DevOps и Ops.
Или быстрые и простые правки в проекте, когда вся мощь IDE не нужна.
А еще проекты, совсем не связанные с кодом. Например, анализ каких-то данных. Создание презентаций и схем.
Ручной анализ ошибок, результата запуска тестов.
Генерация тестовых данных.
Тут агент с TUI побеждает обычный чат за счет режима планирования, скилов, комманд, сабагентов.
И - тут плавно переходим в CLI режиму - разработка и отладка AI агента.
CLI режим по-другому называется headless, head в данном случае терминал.
Вот какие команды поддерживает OpenCode https://opencode.ai/docs/ru/cli/
А вот какие Gemini: https://google-gemini.github.io/gemini-cli/docs/cli/headless.html
Пару примеров из мануала Gemini:
cat src/auth.py | gemini -p "Review this authentication code for security issues" > security-review.txt
result=$(git diff --cached | gemini -p "Write a concise commit message for these changes" --output-format json)
echo "$result" | jq -r '.response'
Здесь у нас есть вся мощь CLI - агенту (почти всем CLI агентам) можно передать чей-то stdout.
И передать дальше их stdout, отформатировав его в json. Или сохранить в файл.
Где можно использовать - да везде.
Предварительно настроив сабагентов и скилы.
prCheck, автоматическое code review, автогенерация кода, тестов, документации, отчетов, анализ логов....
Ну и еще два применения:
1) консоль есть в IDE, можно использовать агента там. Правда интеграция будет хуже, чем у нативного IDE агента.
2) если выстрелит протокол ACP https://www.jetbrains.com/help/ai-assistant/acp.html, не путать с другими ACP,
то в IDEA будет стандартное окно AI чата, из которого можно переключаться\выбирать себе агента сохраняя клиентский опыт.
И еще один очевидный, но важный момент: консоль - это инструмент ИТ-шника.
Разработчик, тестировщик, DevOps, Ops, системный аналитик, ИТ менеджер наконец.
Как минимум нужно понимать, почему это установленному скилу потребовался Python, NodeJS и множество пакетов к ним.
Да и с концепцией venv лучше быть знакомым)
И это инструмент локальный - т.е. нужна возможность скачать и установить агента и его секреты (API ключи).
#ai
OpenCode
CLI
Параметры и команда opencode CLI.
Мы?)
Но что интересно - AI-шка здорово ускоряет создание таких часто одноразовых инструментов. Особенно если это shell скрипты или любой код не на основном языке разработчика. Так что подозреваю, что таких утилит будет больше, а времени на их создание будет затрачиваться меньше. И одноразовость уже не будет блокером.
P.S. Да, это снова флешбеки от Совершенного кода)
#book_review #ai
Но что интересно - AI-шка здорово ускоряет создание таких часто одноразовых инструментов. Особенно если это shell скрипты или любой код не на основном языке разработчика. Так что подозреваю, что таких утилит будет больше, а времени на их создание будет затрачиваться меньше. И одноразовость уже не будет блокером.
P.S. Да, это снова флешбеки от Совершенного кода)
#book_review #ai
🔥2
Цитата из "красной" книги:
И еще:
Т.е. еще в 2000-х годах было понятно, что с ростом кодовой базы мало того, что нелинейно падает скорость разработки,
так еще и практически экспоненциально растет стоимость проработки архитектуры, требований, интеграции и тестирования. Причем если интеграцию и тестирование до какого-то момента можно победить централизацией и регламентом, то контролировать архитектуру на больших объемах невозможно. Нужны "клоны" главного архитектора, а до таких глубин наука (этика?) пока не дошла)
При этом микросервисы вошли в моду где-то в 2015 году, чему способствовало развитие Docker, k8s и облаков.
А для облачных провайдеров больше сервисов = больше денег)
И они быстро подхватили этот тренд и объявили о поддержке микросервисов.
На самом деле микросервисы - это логическое развитие архитектуры ПО.
C одним но - не всегда shift left выгоден)
Уменьшать размер микросервиса до минимума можно. И формально строк кода в год (день, час) будет написано больше. AI поможет)
Но если бы сделать график стоимости разработки всей системы, а не одного сервиса, то я полагаю, что там будет две экспоненты:
одна при размере микросервиса в 1-5K LoC (строк кода), вторая - 1-5M LoC.
#arch #dev_performance
Доля конструирования снижается, потому что с ростом размера проекта все составляющие конструирования:
проектирование, кодирование, отладка и модульное тестирование — пропорционально масштабируются,
однако затраты на другие виды деятельности растут гораздо быстрее (рис. 27-4).
...
В близких по размеру проектах будут выполняться примерно одинаковые операции,
однако при расхождении в размерах виды выполняемых действий тоже начнут различаться.
... если Gigatron Deluxe в 10 раз больше начального Gigatron,
он потребует в 25 раз больше затрат на конструирование,
в 25–50 — на планирование, в 30 — на интеграцию и в 40 — на архитектуру и системное тестирование.
И еще:
Табл. 27-2. Размер проекта и производительность
Размер проекта (число строк кода) Число строк кода на человека в год
1K 2500–25 000
10K 2000–25 000
100K 1000–20 000
1 000K 700–10 000
10 000K 300–5000
Источники: Составлено на основе данных из «Measures for Excellence» (Putnam and Meyers, 1992),
«Industrial Strength Software» (Putnam and Meyers, 1997),
«Software Cost Estimation with Cocomo II» (Boehm et al., 2000),
и «Software Development Worldwide: The State of the Practice» (Cusumano et al., 2003).
Т.е. еще в 2000-х годах было понятно, что с ростом кодовой базы мало того, что нелинейно падает скорость разработки,
так еще и практически экспоненциально растет стоимость проработки архитектуры, требований, интеграции и тестирования. Причем если интеграцию и тестирование до какого-то момента можно победить централизацией и регламентом, то контролировать архитектуру на больших объемах невозможно. Нужны "клоны" главного архитектора, а до таких глубин наука (этика?) пока не дошла)
При этом микросервисы вошли в моду где-то в 2015 году, чему способствовало развитие Docker, k8s и облаков.
А для облачных провайдеров больше сервисов = больше денег)
И они быстро подхватили этот тренд и объявили о поддержке микросервисов.
На самом деле микросервисы - это логическое развитие архитектуры ПО.
C одним но - не всегда shift left выгоден)
Уменьшать размер микросервиса до минимума можно. И формально строк кода в год (день, час) будет написано больше. AI поможет)
Но если бы сделать график стоимости разработки всей системы, а не одного сервиса, то я полагаю, что там будет две экспоненты:
одна при размере микросервиса в 1-5K LoC (строк кода), вторая - 1-5M LoC.
#arch #dev_performance
Forwarded from Фичизм
Реклама в пулл-реквестах
Юзеры заметили, что Github начал эйай-редактировать пулл реквесты юзеров и пихать в них "типа не рекламные рекомендации".
Поясню. Pull request - это запрос на добавление изменений в общий код проекта. Например, есть какой-то опенсорс-проект. Вы можете написать для него кусок кода и попросить "подтянуть" его в основной код проект. Отсюда и pull request - "запрос на подтягивание" чего-то нового в основную версию.
В общем, это ключевая механика всего Github. При этом пулл реквесты есть обычные (от реальных пользователей), а есть от самого Гитхаба.
Сегодня львиная доля реквестов от Гитхаба генерируется через их Copilot, и туда они уже давно добавляют "рекомендации" сторонних сервисов: например, какие-то лаунчеры для Mac, инструменты разработки вроде VS Code, JetBrains и т.д. Иногда рекомендуют совсем малосвязанные с кодом инструменты, вроде Slack или MS Teams.
И это вполне ок. Сами делают реквесты - сами вставляют в них монетизацию. Кто бы спорил.
Но теперь Github стал вставлять такие штуки и в реквесты от юзеров. На скрине видно, как в запрос добавили рекомендацию лаунчера Raycast (внизу на картинке). Пишут, что в ~1,5 миллиона запросов нашли аналогичные вставки с разными продуктами.
Юзеров это жёстко выбесило. Оно и понятно - Github редактирует чужие реквесты через нейронку, добавляя туда монетизацию. А выглядит так, будто сам разраб вставляет туда рекламу.
Реакция самого Гитхаба довольно странная. Продуктовая команда согласилась, что это зашквар, и пообещала оставить рекомендации только в запросах от Copilot. Но вице-президент компании Мартин Вудворд занял более защитную позицию и сказал, что они уже давно такое делают и всем норм.
Вывод (и рекомендация компаниям) тут такая. Мы, юзеры, не против вашей монетизации. В том числе внутри нашего контента. В конце концов, вы владеете платформой, и можете делать, что хотите. Но нужно чётко помечать, что это именно ваша реклама, а не рекомендация самого автора (ясно пишите "Реклама", выделяйте этот блок другой разметкой и т.д.). Тогда на здоровье.
Фичизм
Юзеры заметили, что Github начал эйай-редактировать пулл реквесты юзеров и пихать в них "типа не рекламные рекомендации".
Поясню. Pull request - это запрос на добавление изменений в общий код проекта. Например, есть какой-то опенсорс-проект. Вы можете написать для него кусок кода и попросить "подтянуть" его в основной код проект. Отсюда и pull request - "запрос на подтягивание" чего-то нового в основную версию.
В общем, это ключевая механика всего Github. При этом пулл реквесты есть обычные (от реальных пользователей), а есть от самого Гитхаба.
Сегодня львиная доля реквестов от Гитхаба генерируется через их Copilot, и туда они уже давно добавляют "рекомендации" сторонних сервисов: например, какие-то лаунчеры для Mac, инструменты разработки вроде VS Code, JetBrains и т.д. Иногда рекомендуют совсем малосвязанные с кодом инструменты, вроде Slack или MS Teams.
И это вполне ок. Сами делают реквесты - сами вставляют в них монетизацию. Кто бы спорил.
Но теперь Github стал вставлять такие штуки и в реквесты от юзеров. На скрине видно, как в запрос добавили рекомендацию лаунчера Raycast (внизу на картинке). Пишут, что в ~1,5 миллиона запросов нашли аналогичные вставки с разными продуктами.
Юзеров это жёстко выбесило. Оно и понятно - Github редактирует чужие реквесты через нейронку, добавляя туда монетизацию. А выглядит так, будто сам разраб вставляет туда рекламу.
Реакция самого Гитхаба довольно странная. Продуктовая команда согласилась, что это зашквар, и пообещала оставить рекомендации только в запросах от Copilot. Но вице-президент компании Мартин Вудворд занял более защитную позицию и сказал, что они уже давно такое делают и всем норм.
Вывод (и рекомендация компаниям) тут такая. Мы, юзеры, не против вашей монетизации. В том числе внутри нашего контента. В конце концов, вы владеете платформой, и можете делать, что хотите. Но нужно чётко помечать, что это именно ваша реклама, а не рекомендация самого автора (ясно пишите "Реклама", выделяйте этот блок другой разметкой и т.д.). Тогда на здоровье.
Фичизм
Изучаю Claude Code, как одного из лидеров рынка. Он работает в консоли, смотрю доступные команды.
/batch - выполнение однотипных рефакторингов в параллель
/loop - запуск команды в цикле
Еще напрашивается /sleep - ожидание, например, когда агент запустил CI сборку и ждет результата. Ясное дело, что агент сам может себе закодить sleep, но так и цикл можно закодить.
Так вот - кажется, базовые примитивы программирования протекают в процесс взаимодействия с агентом.
ExecutorService и цикл for в данном случае.
А те же тулы можно рассматривать как методы. Чем они по факту и являются.
Мы программируем агента)
P.S. Интересно, что еще появится?
if?
слишком просто кажется.
try\catch?
Возможно.
P.P.S. В целом и самому с помощью скилов можно сделать)
#ai #lang
/batch - выполнение однотипных рефакторингов в параллель
/loop - запуск команды в цикле
Еще напрашивается /sleep - ожидание, например, когда агент запустил CI сборку и ждет результата. Ясное дело, что агент сам может себе закодить sleep, но так и цикл можно закодить.
Так вот - кажется, базовые примитивы программирования протекают в процесс взаимодействия с агентом.
ExecutorService и цикл for в данном случае.
А те же тулы можно рассматривать как методы. Чем они по факту и являются.
Мы программируем агента)
P.S. Интересно, что еще появится?
if?
слишком просто кажется.
try\catch?
Возможно.
P.P.S. В целом и самому с помощью скилов можно сделать)
#ai #lang
👍2
Вот почему так?
Разработчики лет 10 уже мучаются, пишут свой тормозящий "ком грязи" внутри build.gradle. А стоило появится AI агентам и необходимости ускорить их работу, как Gradle сделали best practices https://docs.gradle.org/current/userguide/best_practices_index.html
А вообще штука полезная. И думаю это скоро станет трендом. Оцифровка знаний.
P.S. Вроде как с Google и JetBrains совместная работа.
#gralde #ai
Разработчики лет 10 уже мучаются, пишут свой тормозящий "ком грязи" внутри build.gradle. А стоило появится AI агентам и необходимости ускорить их работу, как Gradle сделали best practices https://docs.gradle.org/current/userguide/best_practices_index.html
А вообще штука полезная. И думаю это скоро станет трендом. Оцифровка знаний.
P.S. Вроде как с Google и JetBrains совместная работа.
#gralde #ai
🔥2
Расскажу про одну засаду при выборе модели у независимого провайдера на примере openrouter.ai.
Введение.
Агент каждый раз взаимодействуя с моделью шлет ей весь диалог сессии. Думаю, так устроены все агенты, я наблюдаю это на примере Claude Code, флагмана. С ростом сессии размер диалога растет вплоть до размера контекстного окна модели. Контекстного окна модели, доступного у данного провайдера, если быть точным.
Вот тут уже маячит тень "засады")
Но нет. Ведь модель уже кэширует весь диалог в рамках сессии у себя. Область памяти, где находятся эти данные - KV кэш. И она может определить, что большая часть присланных данных уже есть в кэше. И в плане стоимости инференса (используемого ОЗУ) получается передача всего диалога не страшна. И было бы нечестно заставлять пользователя платить за одни и те же данные много раз.
Вроде все ок. Но засада может быть в том, что некоторые модели не умеют кэшировать.
Примеры:
Deepseek умеет, ищи по слову cache https://openrouter.ai/deepseek/deepseek-v3.2
Есть цена кэшированных данных, она сильно меньше, есть cache hit ratio.
А вот новый модный Qwen 3.6 Plus - нет. https://openrouter.ai/qwen/qwen3.6-plus
В его случае получается цена хороша для новой мощной модели. Но с какого-то момента модель становится дороже аналогов)
У него кстати еще и разная цена после прохождения размера контекстного окна в 256k. Double damage) Выглядит как запретительный тариф и принуждение к декомпозиции задач.
Но я лучше выберу другую модель)
P.S. Надо отметить, что Cache Read все же имеет ненулевую цену, и если посмотреть на Cache Hit Rate - реализация механизма проверки кэша сильно зависит от модели и провайдера. Поэтому декомпозиция конечно же нужна.
#ai
Введение.
Агент каждый раз взаимодействуя с моделью шлет ей весь диалог сессии. Думаю, так устроены все агенты, я наблюдаю это на примере Claude Code, флагмана. С ростом сессии размер диалога растет вплоть до размера контекстного окна модели. Контекстного окна модели, доступного у данного провайдера, если быть точным.
Вот тут уже маячит тень "засады")
Но нет. Ведь модель уже кэширует весь диалог в рамках сессии у себя. Область памяти, где находятся эти данные - KV кэш. И она может определить, что большая часть присланных данных уже есть в кэше. И в плане стоимости инференса (используемого ОЗУ) получается передача всего диалога не страшна. И было бы нечестно заставлять пользователя платить за одни и те же данные много раз.
Вроде все ок. Но засада может быть в том, что некоторые модели не умеют кэшировать.
Примеры:
Deepseek умеет, ищи по слову cache https://openrouter.ai/deepseek/deepseek-v3.2
Есть цена кэшированных данных, она сильно меньше, есть cache hit ratio.
А вот новый модный Qwen 3.6 Plus - нет. https://openrouter.ai/qwen/qwen3.6-plus
В его случае получается цена хороша для новой мощной модели. Но с какого-то момента модель становится дороже аналогов)
У него кстати еще и разная цена после прохождения размера контекстного окна в 256k. Double damage) Выглядит как запретительный тариф и принуждение к декомпозиции задач.
Но я лучше выберу другую модель)
P.S. Надо отметить, что Cache Read все же имеет ненулевую цену, и если посмотреть на Cache Hit Rate - реализация механизма проверки кэша сильно зависит от модели и провайдера. Поэтому декомпозиция конечно же нужна.
#ai
openrouter.ai
DeepSeek V3.2 - API Pricing & Benchmarks
DeepSeek-V3.2 is a large language model designed to harmonize high computational efficiency with strong reasoning and agentic tool-use performance. $0.2145 per million input tokens, $0.3218 per million output tokens. 163,840 token context window, maximum…
Доступ к отладке в IDE для AI агента.
Странно, что поддержку отладки в IDE в виде MCP тулов пока не сделал JetBrains. https://www.jetbrains.com/help/idea/mcp-server.html
Просмотр и запуск конфигураций есть, а вот выставление\удаление breakpoints, а также сам процесс отладки: получение данных о строчке остановки, Step Over, Step Into, Run, Watch-и - этого пока нет. Думаю еще сделают. Уже пора)
А пока "лёд тронулся" - https://habr.com/ru/companies/veai/articles/1020760/ Ребята красавцы!
#ai #ide
Странно, что поддержку отладки в IDE в виде MCP тулов пока не сделал JetBrains. https://www.jetbrains.com/help/idea/mcp-server.html
Просмотр и запуск конфигураций есть, а вот выставление\удаление breakpoints, а также сам процесс отладки: получение данных о строчке остановки, Step Over, Step Into, Run, Watch-и - этого пока нет. Думаю еще сделают. Уже пора)
А пока "лёд тронулся" - https://habr.com/ru/companies/veai/articles/1020760/ Ребята красавцы!
#ai #ide
IntelliJ IDEA Help
MCP Server | IntelliJ IDEA
AI - скрытые угрозы.
Два поста для затравки:
https://t.me/orgprog/465
и
https://t.me/seeallochnaya/3513
Первый - что там, где раньше "кожаные мешки" старались не писать "лишний" код, т.к. это дорого по затраченному времени.
А сейчас появляется соблазн это делать, т.к. AI пишет код существенно быстрее.
Далее если логически продолжить - появляется соблазн меньше проверять код, больше доверять этот процесс LLM, чтобы не стать "слабым звеном" в цикле разработки.
И это мы говорим про профессиональных разработчиков. А ведь есть еще PO, менеджеры, ... ставшие на тропу вайб-кодинга.
Второй пост о том, что новая модель Anthropic Mythos сильно круче предыдущих.
Настолько круче, что ее даже не стали выпускать в открытый доступ, т.к. она слишком хорошо ищет уязвимости.
Доступ выдадут ограниченному числу компаний https://t.me/ai_machinelearning_big_data/9829.
Что в итоге?
Больше кода, больше уязвимостей и легче их искать.
К чему это приведет - а хз. Но риски видятся существенные.
P.S. И это я не рассматриваю вариант, что модель выпустят из песочницы и дадут рычаги влияния на реальный мир https://t.me/lovely_it_hell/651
#ai
Два поста для затравки:
https://t.me/orgprog/465
и
https://t.me/seeallochnaya/3513
Первый - что там, где раньше "кожаные мешки" старались не писать "лишний" код, т.к. это дорого по затраченному времени.
А сейчас появляется соблазн это делать, т.к. AI пишет код существенно быстрее.
Далее если логически продолжить - появляется соблазн меньше проверять код, больше доверять этот процесс LLM, чтобы не стать "слабым звеном" в цикле разработки.
И это мы говорим про профессиональных разработчиков. А ведь есть еще PO, менеджеры, ... ставшие на тропу вайб-кодинга.
Второй пост о том, что новая модель Anthropic Mythos сильно круче предыдущих.
Настолько круче, что ее даже не стали выпускать в открытый доступ, т.к. она слишком хорошо ищет уязвимости.
Доступ выдадут ограниченному числу компаний https://t.me/ai_machinelearning_big_data/9829.
Что в итоге?
Больше кода, больше уязвимостей и легче их искать.
К чему это приведет - а хз. Но риски видятся существенные.
P.S. И это я не рассматриваю вариант, что модель выпустят из песочницы и дадут рычаги влияния на реальный мир https://t.me/lovely_it_hell/651
#ai
Telegram
Организованное программирование | Кирилл Мокевнин
Точные типы DTO для ИИ
Есть такая проблема с DTO, что если делать их достаточно универсальными, то почти все поля внутри получаются nullable. Потому что любая сущность в режиме "создаем новую" практически всегда пустая, за исключением может каких-то флагов…
Есть такая проблема с DTO, что если делать их достаточно универсальными, то почти все поля внутри получаются nullable. Потому что любая сущность в режиме "создаем новую" практически всегда пустая, за исключением может каких-то флагов…
Когда я изучал тарифы на доступ к LLM, меня удивила явная асимметрия.
С одной стороны за 18 баксов в месяц можно получить условный безлимит.
Я про оплату 200$ за год.
А безлимит условный, потому что внутри дня и за неделю все же есть лимиты.
Тут кстати прикольные флешбеки.
В детстве я ждал часа Х, чтобы сходить в ВУЗ поработать за компом.
А позже когда был общий комп на двоих с братом - тоже ждал своего времени.
А сейчас многие ждут, когда сбросится пятичасовой лимит Claude Code.
Но я отвлекся.
А с другой стороны - если платить за токены по API, то выходит на порядок дороже, те же 18$ можно сжечь за пару часов.
Это по ценам openrouter.ai. А если его прикрою и\или приходится пользоваться русскими проксями - еще +20%.
Вопрос - это же не выгодно провайдерам LLM моделей?
А вот и ответ https://vc.ru/ai/2851931-obkhod-blokirovki-anthropic-dlya-storonnikh-instrumentov
Anthropic уже начали блочить использование OAuth доступа (безлимитного) в сторонних агентах типа OpenClaw.
Пока это можно обойти.
Но тенденция понятная. Им скоро на биржу выходить, доходность повышать надо.
P.S. Да бывают бесплатные модели, они как правило появляются у всех в одно и тоже время - openrouter, внутри самих агентов.
Но это по сути бета-тест + рекламная акция. И длится она пару дней\недель\максимум месяцев.
#ai
С одной стороны за 18 баксов в месяц можно получить условный безлимит.
Я про оплату 200$ за год.
А безлимит условный, потому что внутри дня и за неделю все же есть лимиты.
Тут кстати прикольные флешбеки.
В детстве я ждал часа Х, чтобы сходить в ВУЗ поработать за компом.
А позже когда был общий комп на двоих с братом - тоже ждал своего времени.
А сейчас многие ждут, когда сбросится пятичасовой лимит Claude Code.
Но я отвлекся.
А с другой стороны - если платить за токены по API, то выходит на порядок дороже, те же 18$ можно сжечь за пару часов.
Это по ценам openrouter.ai. А если его прикрою и\или приходится пользоваться русскими проксями - еще +20%.
Вопрос - это же не выгодно провайдерам LLM моделей?
А вот и ответ https://vc.ru/ai/2851931-obkhod-blokirovki-anthropic-dlya-storonnikh-instrumentov
Anthropic уже начали блочить использование OAuth доступа (безлимитного) в сторонних агентах типа OpenClaw.
Пока это можно обойти.
Но тенденция понятная. Им скоро на биржу выходить, доходность повышать надо.
P.S. Да бывают бесплатные модели, они как правило появляются у всех в одно и тоже время - openrouter, внутри самих агентов.
Но это по сути бета-тест + рекламная акция. И длится она пару дней\недель\максимум месяцев.
#ai
Есть радикальный подход к внедрению AI в разработку.
Звучит он так - считайте, что код на языках общего назначения превращается в ассемблер.
Люди его писать и читать будут только в исключительных случаях, генерировать его будет машина.
Лично я на сегодня (!) этот подход считаю слишком оптимистичным. Или пессимистичным, с какой стороны смотреть)
Хотя, может быть в будущем. Посмотрим.
Но вопрос затрагивается интересный. Весь ли код надо писать самому?
Тут ответ видится очевидным - нет.
Весь ли код нужно построчно проверять после того, как его сгенерил AI - кажется тоже нет.
Есть же у нас generated код. DTO-шки для OpenAPI, например.
Наверное, человек бы написал его лучше. Компактнее, функциональнее, чище.
Но много ли желающих лезть туда руками? Кажется, даже мысли не возникает.
Потому что мы доверяем генератору.
AI конечно не детерминирован, в отличие от hardcoded генератора. Но модели сильно выросли в качестве, и у нас есть тесты.
Соответственно, часть кода приложения также можно сделать ai generated: пометить какой-нибудь аннотацией (или комментарием) и генерировать только с помощью AI.
Какой именно код?
Весь вспомогательный код, помогающий выполнять бизнес-логику приложения.
Тот, который по-хорошему надо бы переиспользовать, но подходящей библиотеки нет. Или она тянет за собой лишние зависимости. Или она заброшена автором. Или библиотека есть, но ее бы немного доработать.
И этот код наверняка есть в куче репозиториев на GitHub, но искать лень.
Ага, значит о нем знает LLM, и значит она его будет хорошо генерировать.
И конечно нужны тесты. Тесты может написать модель, но критерии нужно задавать\проверять самому.
И стиль для тестов задавать - какие библиотеки используем, гранулярность, что тестируем, что не тестируем.
А какой процент кода сервиса в итоге станет AI generated - посмотрим)
#ai
Звучит он так - считайте, что код на языках общего назначения превращается в ассемблер.
Люди его писать и читать будут только в исключительных случаях, генерировать его будет машина.
Лично я на сегодня (!) этот подход считаю слишком оптимистичным. Или пессимистичным, с какой стороны смотреть)
Хотя, может быть в будущем. Посмотрим.
Но вопрос затрагивается интересный. Весь ли код надо писать самому?
Тут ответ видится очевидным - нет.
Весь ли код нужно построчно проверять после того, как его сгенерил AI - кажется тоже нет.
Есть же у нас generated код. DTO-шки для OpenAPI, например.
Наверное, человек бы написал его лучше. Компактнее, функциональнее, чище.
Но много ли желающих лезть туда руками? Кажется, даже мысли не возникает.
Потому что мы доверяем генератору.
AI конечно не детерминирован, в отличие от hardcoded генератора. Но модели сильно выросли в качестве, и у нас есть тесты.
Соответственно, часть кода приложения также можно сделать ai generated: пометить какой-нибудь аннотацией (или комментарием) и генерировать только с помощью AI.
Какой именно код?
Весь вспомогательный код, помогающий выполнять бизнес-логику приложения.
Тот, который по-хорошему надо бы переиспользовать, но подходящей библиотеки нет. Или она тянет за собой лишние зависимости. Или она заброшена автором. Или библиотека есть, но ее бы немного доработать.
И этот код наверняка есть в куче репозиториев на GitHub, но искать лень.
Ага, значит о нем знает LLM, и значит она его будет хорошо генерировать.
И конечно нужны тесты. Тесты может написать модель, но критерии нужно задавать\проверять самому.
И стиль для тестов задавать - какие библиотеки используем, гранулярность, что тестируем, что не тестируем.
А какой процент кода сервиса в итоге станет AI generated - посмотрим)
#ai
Паттернов у нас много, кажется, что паттерны можно придумать для чего угодно)
Поэтому неудивительно, что появляется вот такая книга https://www.piter.com/collection/new/product/patterny-coding-interview-podgotovka-k-slozhnomu-tehnicheskomu-intervyu?utm_campaign=177670675710 )))
P.S. не читал, но по оглавлению можно сказать, что там паттерны для решения задач с leetcode
#patterns
Поэтому неудивительно, что появляется вот такая книга https://www.piter.com/collection/new/product/patterny-coding-interview-podgotovka-k-slozhnomu-tehnicheskomu-intervyu?utm_campaign=177670675710 )))
P.S. не читал, но по оглавлению можно сказать, что там паттерны для решения задач с leetcode
#patterns
www.piter.com
Паттерны Coding Interview. Подготовка к сложному техническому интервью
Эта книга меняет правила игры в подготовке к кодинг-интервью. Алекс Сюй предлагает структурированный подход к распространенным паттернам, разбирает сложные концепции и делает реальные задачи намного доступнее.
Меня радует, как развивается Spring AI.
Если посмотреть на основной функционал - https://docs.spring.io/spring-ai/reference/2.0-SNAPSHOT/index.html - то мы видим поддержку:
0) формирование промта (шаблон, роли)
1) tools calling
2) RAG
3) Chat History
4) MCP
5) structured output
Тут конечно возникает вопрос - это вчерашний день, база, где же тут развитие?
А развитие вот тут: https://github.com/spring-ai-community/spring-ai-agent-utils
Это еще не часть фреймворка, но авторы кода из Spring-а. И есть цикл статей в блоке Spring https://spring.io/blog/2026/04/15/spring-ai-session-management
Ссылка на последнюю статью, т.к. только в ней есть кросс-ссылки на всю серию.
Что добавили:
1) skills
2) субагентов
3) долговременную память (!)
4) работу с сессиями включая их сжатие с разными стратегиями (плавающее окно, суммаризация (!))
5) кросс-агентское взаимодействие (A2A протокол)
6) контроль процесса выполнения через ToDoWrite (формируем список задач и помечаем прогресс)
7) и даже тула AskUserQuestion
В общем авторы все "слизали" у Claude, но это очень даже хорошо, т.к. Claude сейчас во много формирует отрасль.
Единственный потенциальный минус - это preview библиотеки, следовательно, API будет меняться. Но с другой стороны - миграции кода сейчас делать проще)))
А практическая цель создания такого "велосипедного" агента как минимум следующая - собрав "свой Claude Code" можно лучше понять как работают современные агенты.
#ai
Если посмотреть на основной функционал - https://docs.spring.io/spring-ai/reference/2.0-SNAPSHOT/index.html - то мы видим поддержку:
0) формирование промта (шаблон, роли)
1) tools calling
2) RAG
3) Chat History
4) MCP
5) structured output
Тут конечно возникает вопрос - это вчерашний день, база, где же тут развитие?
А развитие вот тут: https://github.com/spring-ai-community/spring-ai-agent-utils
Это еще не часть фреймворка, но авторы кода из Spring-а. И есть цикл статей в блоке Spring https://spring.io/blog/2026/04/15/spring-ai-session-management
Ссылка на последнюю статью, т.к. только в ней есть кросс-ссылки на всю серию.
Что добавили:
1) skills
2) субагентов
3) долговременную память (!)
4) работу с сессиями включая их сжатие с разными стратегиями (плавающее окно, суммаризация (!))
5) кросс-агентское взаимодействие (A2A протокол)
6) контроль процесса выполнения через ToDoWrite (формируем список задач и помечаем прогресс)
7) и даже тула AskUserQuestion
В общем авторы все "слизали" у Claude, но это очень даже хорошо, т.к. Claude сейчас во много формирует отрасль.
Единственный потенциальный минус - это preview библиотеки, следовательно, API будет меняться. Но с другой стороны - миграции кода сейчас делать проще)))
А практическая цель создания такого "велосипедного" агента как минимум следующая - собрав "свой Claude Code" можно лучше понять как работают современные агенты.
#ai
GitHub
GitHub - spring-ai-community/spring-ai-agent-utils: A Spring AI library that brings Claude Code-inspired tools and agent skills…
A Spring AI library that brings Claude Code-inspired tools and agent skills to your AI applications. - spring-ai-community/spring-ai-agent-utils
🔥2
3 способа как один разработчик может работать "одновременно" над несколькими фичами в одном git репозитории.
Для начала, на всякий случай - зачем это нужно?
1) Делаем фичу - прилетел баг, нужно быстро поправить -> в отдельной ветке и вернуться к исходной фиче.
2) Делаем фичу, на пол-пути понимаем, что сейчас довести до конца ее не получается, нужно переключиться на другую.
3) Делаем фичу, нужно поизучать другую ветку локально.
4) Ну и конечно же AI, время такое: кодим c AI, агент умеет параллелить выполнение каких-то простых рефактирингов (а многие уже умеют).
Какие есть варианты, от простого к сложному:
1) checkout.
Если говорить о параллельной работе, то тут только минусы.
Что произойдет с незакомиченными изменениями при переключении?
Варианты такие:
а) они попадут в новую ветку, если зафиксированное в git состояние изменяемого файла одинаковое в обоих ветках.
Или если создается новая ветка git checkout -b <branch>, тогда состояние по определению одинаковое.
В последнем случае это полезный хак - когда по ошибке начал кодить в master. Это наверное главный плюс, но он не относится к параллельной работе над фичами.
Но таким же образом можно по ошибке пронести в ветку лишние изменения.
б) если зафиксированное состояние изменяемого файла отличается в ветках - переключение по checkout не произойдет, изменения придется явно commit-ить или откатывать
в) при использовании git checkout -f <branch> (force) незакоммиченные изменения будут потеряны.
Итого - риск потерять данные, риск закоммитить лишнее. Плюс т.к. все файлы в одной папке - запущенный процесс ОС может блокировать checkout.
Применять имеет смысл если дошел до какой-то логической точки в текущей фиче и надолго переключаешься на новую.
2) stash.
В этом случае diff изменений попадает в локальный стек, работающий по принципу FIFO.
Команды git stash pop и git stash apply.
Вроде как удобно, но по своему опыту знаю, что изменения легко в стеке забыть. Это собственно главный минус, нивелируется при кратковременном переключении.
Плюс - параллельная работа возможна, переключение быстрое, места на диске занимает мало.
Применять имеет смысл для кратковременного переключения на другую фичу, например, для баг-фикса.
3) worktree.
Здесь идея в том, что рабочие файлы каждой ветки хранятся в отдельной папке.
Корневая папка проекта, он же рабочий каталог - всего лишь одна из копий.
А в .git/worktrees хранятся другие копии.
В теории можно не создавать исходники в корневой папке, если вызвать git clone --bare <repository-url>.
Обычно эту команду используют на серверах типа GitHub, Bitbucket, но также полезно и для работы с несколькими worktree.
Команда создания нового дерева для существующей ветки: git worktree add ../<folder> <branch>
и удаления: git worktree remove ../<folder>
Тут может возникнуть вопрос - как git понимает, с какой копией он работает в данный момент?
Ответ: по текущему пути и по наличию папки .git внутри каждой копии.
Самое интересное - многие агенты, а точнее те, кто умеют параллельно работать - используют worktree.
Плюсы: каждая копия изолирована от других, случайно пронести лишнее сложно, невозможно заблокировать файлы из другой ветки (правда остается проблема с открытыми портами).
Минусы: требуется больше места на диске. Но если не хранить бинари в git, а этого делать не нужно, то не критично.
Ну и нужно привыкнуть, что актуальные исходники не лежат в корне проекта.
Итог - применять имеет смысл для AI разработки и для параллельной работы руками.
#git #ai
Для начала, на всякий случай - зачем это нужно?
1) Делаем фичу - прилетел баг, нужно быстро поправить -> в отдельной ветке и вернуться к исходной фиче.
2) Делаем фичу, на пол-пути понимаем, что сейчас довести до конца ее не получается, нужно переключиться на другую.
3) Делаем фичу, нужно поизучать другую ветку локально.
4) Ну и конечно же AI, время такое: кодим c AI, агент умеет параллелить выполнение каких-то простых рефактирингов (а многие уже умеют).
Какие есть варианты, от простого к сложному:
1) checkout.
Если говорить о параллельной работе, то тут только минусы.
Что произойдет с незакомиченными изменениями при переключении?
Варианты такие:
а) они попадут в новую ветку, если зафиксированное в git состояние изменяемого файла одинаковое в обоих ветках.
Или если создается новая ветка git checkout -b <branch>, тогда состояние по определению одинаковое.
В последнем случае это полезный хак - когда по ошибке начал кодить в master. Это наверное главный плюс, но он не относится к параллельной работе над фичами.
Но таким же образом можно по ошибке пронести в ветку лишние изменения.
б) если зафиксированное состояние изменяемого файла отличается в ветках - переключение по checkout не произойдет, изменения придется явно commit-ить или откатывать
в) при использовании git checkout -f <branch> (force) незакоммиченные изменения будут потеряны.
Итого - риск потерять данные, риск закоммитить лишнее. Плюс т.к. все файлы в одной папке - запущенный процесс ОС может блокировать checkout.
Применять имеет смысл если дошел до какой-то логической точки в текущей фиче и надолго переключаешься на новую.
2) stash.
В этом случае diff изменений попадает в локальный стек, работающий по принципу FIFO.
Команды git stash pop и git stash apply.
Вроде как удобно, но по своему опыту знаю, что изменения легко в стеке забыть. Это собственно главный минус, нивелируется при кратковременном переключении.
Плюс - параллельная работа возможна, переключение быстрое, места на диске занимает мало.
Применять имеет смысл для кратковременного переключения на другую фичу, например, для баг-фикса.
3) worktree.
Здесь идея в том, что рабочие файлы каждой ветки хранятся в отдельной папке.
Корневая папка проекта, он же рабочий каталог - всего лишь одна из копий.
А в .git/worktrees хранятся другие копии.
В теории можно не создавать исходники в корневой папке, если вызвать git clone --bare <repository-url>.
Обычно эту команду используют на серверах типа GitHub, Bitbucket, но также полезно и для работы с несколькими worktree.
Команда создания нового дерева для существующей ветки: git worktree add ../<folder> <branch>
и удаления: git worktree remove ../<folder>
Тут может возникнуть вопрос - как git понимает, с какой копией он работает в данный момент?
Ответ: по текущему пути и по наличию папки .git внутри каждой копии.
Самое интересное - многие агенты, а точнее те, кто умеют параллельно работать - используют worktree.
Плюсы: каждая копия изолирована от других, случайно пронести лишнее сложно, невозможно заблокировать файлы из другой ветки (правда остается проблема с открытыми портами).
Минусы: требуется больше места на диске. Но если не хранить бинари в git, а этого делать не нужно, то не критично.
Ну и нужно привыкнуть, что актуальные исходники не лежат в корне проекта.
Итог - применять имеет смысл для AI разработки и для параллельной работы руками.
#git #ai
❤🔥2🔥1
Ты что такое или как AI ревьювит код?
Изучаю сейчас плагин superpowers, который включает в себя много чего интересного, и в т.ч. и код-ревью.
Вижу два интересных момента.
Первый. Модель постоянно берет куски нового кода и запускает их с каким-то параметрами, например, с краевыми случаями.
Для начала куски метода, потом методы целиком.
Это явно плюс в карму AI, т.к. живому человеку это делать долго и дорого.
Кто-то так делал вообще?)
Надо отметить, что в Java это еще и сложнее сделать, чем в том же Python или JS, хотя подвижки есть - https://t.me/javaKotlinDevOps/412
Тут видится хорошая область, где AI ревьювер может дополнить человека.
Для демонстрации второго момента приведу кусок кода - это лог выполнения скрипта, который агент прогонял на этапе ревью. Код python, но он простой:
На первый взгляд бред какой-то. Код ничего не делает, только печатает очевидные вещи, частично как комментарии, частично через print.
Но если подумать - похоже модель проверяет логику на отсутствие ошибки "ошибки на единицу".
Проговаривая ее для себя. Ну и возможно для меня, но видится в первую очередь для себя.
Т.к. это все попадает в историю диалога с LLM и далее в ее контекст, влияющие на результат выполнения последующих запросов.
С таким проговариванием человек справляется успешно, но радует, что модель тоже, хоть и вот так, странненько.
P.S. Ошибка между прочим известная, не у каждой ошибки своя статья в wikipedia есть https://ru.wikipedia.org/wiki/Ошибка_на_единицу
P.P.S. Но импорты явно лишние)
P.P.P.S. Риски самому перестать думать возрастают)))
#ai #code-review
Изучаю сейчас плагин superpowers, который включает в себя много чего интересного, и в т.ч. и код-ревью.
Вижу два интересных момента.
Первый. Модель постоянно берет куски нового кода и запускает их с каким-то параметрами, например, с краевыми случаями.
Для начала куски метода, потом методы целиком.
Это явно плюс в карму AI, т.к. живому человеку это делать долго и дорого.
Кто-то так делал вообще?)
Надо отметить, что в Java это еще и сложнее сделать, чем в том же Python или JS, хотя подвижки есть - https://t.me/javaKotlinDevOps/412
Тут видится хорошая область, где AI ревьювер может дополнить человека.
Для демонстрации второго момента приведу кусок кода - это лог выполнения скрипта, который агент прогонял на этапе ревью. Код python, но он простой:
{"command":"python -c \"
import pandas as pd
import numpy as np
# Probe: does max_pos + 1 in rng.integers allow the window to exceed bounds?
# n = 10, duration = 3, max_pos = 7
# rng.integers(0, max_pos + 1) -> [0, 7] inclusive
# pos=7: index[7], window is [index[7], index[7]+3min)
# If index has exactly 10 rows (0..9), this is index[7], index[8], index[9] -> 3 rows OK
# pos=8: This would only happen if max_pos=8, which requires n-duration=8, so n=11 - fine
print('Boundary logic: max_pos = n - duration_minutes')
print('rng.integers(0, max_pos+1) is [0, max_pos] inclusive')
print('At max_pos, window covers indices [max_pos..max_pos+duration-1], which is valid')
print()
\"
","description":"Verify off-by-one and boundary correctness in random placement logic"},На первый взгляд бред какой-то. Код ничего не делает, только печатает очевидные вещи, частично как комментарии, частично через print.
Но если подумать - похоже модель проверяет логику на отсутствие ошибки "ошибки на единицу".
Проговаривая ее для себя. Ну и возможно для меня, но видится в первую очередь для себя.
Т.к. это все попадает в историю диалога с LLM и далее в ее контекст, влияющие на результат выполнения последующих запросов.
С таким проговариванием человек справляется успешно, но радует, что модель тоже, хоть и вот так, странненько.
P.S. Ошибка между прочим известная, не у каждой ошибки своя статья в wikipedia есть https://ru.wikipedia.org/wiki/Ошибка_на_единицу
P.P.S. Но импорты явно лишние)
P.P.P.S. Риски самому перестать думать возрастают)))
#ai #code-review
Telegram
(java || kotlin) && devOps
Можно ли быстро сделать и запустить single-file прототип на Java?
Как старый джавист я всегда немного с завистью смотрел видео, где человек на Python, PHP, Ruby пишет скрипт, содержащий достаточно сложный код и просто запускает его командой python script.py.…
Как старый джавист я всегда немного с завистью смотрел видео, где человек на Python, PHP, Ruby пишет скрипт, содержащий достаточно сложный код и просто запускает его командой python script.py.…
🔥2
MCP - новая проблема.
Есть такой стандарт для стандартизированного добавления кастомных тулов - MCP.
Он позволяет разрабатывать тулы на любом языке и выставлять их наружу, для использования агентом, по протоколу JSON-RPS через http (независимый удаленный сервис) или stdio (дочерний процесс).
Вроде бы крутая штука. Если бы не детали реализации)
Главная проблема такая - по стандарту MCP сервер выставляет метод tools/list, возвращающий список тулов в формате name, description, inputSchema.
В чем проблема?
Предположим мы выставляем в MCP API какой-то серьезной системы. Например, Atlassian. Сколько там методов? А какого размера у них inputSchema?
А контекст не бесконечен, более того, после заполнения 50% контекста качество ответов ухудшается.
Т.е. подключив пару тяжелых MCP серверов есть шанс сразу же, с первого запроса, снизить качество работы LLM. А MCP могут и не пригодиться в данном сеансе работы.
Вторая проблема - агент подключается ко всем MCP при старте, вызывая ряд методов (initialize, tools/list) что требует времени.
Слышал по этому поводу мнения, что MCP нам вообще не нужны.
Я бы сказал - такие MCP - да, не нужны. А в целом идея хорошая, не все скилами можно реализовать из-за сложности и вопросов безопасности.
Что делать?
1) несколько профилей агента, с разным набором MCP серверов. Возможно даже lite версию вообще без MCP (Claude Code через
2) переписать MCP на skill если это простая прокси к внешнему API. Скил может включать в себя Python скрипты. Агенты такие скилы неплохо пишут.
Скилы сделаны "по уму", там в контекст по умолчанию выставляется только name и description, содержимое SKILL.md и другие файлы добавляются по мере необходимости.
Этап подключения для скилов отсутствует, это просто специализированный промт.
3) lazy load описаний и схем тулов, сделанный на уровне агента. Claude Code, видимо по принципу "Я тебя породил, ..." реализовал это первым https://vc.ru/ai/2864901-claude-code-i-mcp-lazy-loading-uluchshaet-ai-agentov.
Итоги, цитата:
Причем lazy load включается тоже lazy - когда описания MCP tools начинают занимать более 10% контекстного окна. Красиво)
Причем есть предложение дальнейших оптимизаций: https://github.com/anthropics/claude-code/issues/44536
Включая:
а) грузить description скилов тоже лениво. Тут видится противоречие, по стандарту именно description содержит информацию когда подгружать скил. Имя конечно тоже должно быть адекватным, но оно может быть очень коротким.
С другой стороны, если имена нескольких скилов лексически\семантически похожи - ленивая загрузка будет работать, т.к. агент загрузит оба скила и далее уже по описанию выберет правильный.
б) ленивое подключение к MCP - тут понятно
в) профили агентов - это стандартизация решения номер №1. Сейчас это несколько разных папок с агентами, а должны быть - несколько файлов профиля.
г) загрузка тулов\скилов по условию (только при написании тестов, например)
д) динамическая выгрузка
Ну в общем полноценное управление памятью, т.е контекстом)
Есть похожие issues и для других агентов, пока в статусе Open
https://github.com/openai/codex/issues/2335
https://github.com/anomalyco/opencode/issues/17482
4) решение на уровне стандарта MCP. Вот тут все плохо, идут обсуждения, но конкретных предложений нет.
Вот предложение https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1576
Вот еще одно https://github.com/orgs/modelcontextprotocol/discussions/532
Но до реализации дело не дошло.
Вывод - AI агенты активно развиваются.
#ai #ai_agents #mcp #ai_agent_context_management
Есть такой стандарт для стандартизированного добавления кастомных тулов - MCP.
Он позволяет разрабатывать тулы на любом языке и выставлять их наружу, для использования агентом, по протоколу JSON-RPS через http (независимый удаленный сервис) или stdio (дочерний процесс).
Вроде бы крутая штука. Если бы не детали реализации)
Главная проблема такая - по стандарту MCP сервер выставляет метод tools/list, возвращающий список тулов в формате name, description, inputSchema.
В чем проблема?
Предположим мы выставляем в MCP API какой-то серьезной системы. Например, Atlassian. Сколько там методов? А какого размера у них inputSchema?
А контекст не бесконечен, более того, после заполнения 50% контекста качество ответов ухудшается.
Т.е. подключив пару тяжелых MCP серверов есть шанс сразу же, с первого запроса, снизить качество работы LLM. А MCP могут и не пригодиться в данном сеансе работы.
Вторая проблема - агент подключается ко всем MCP при старте, вызывая ряд методов (initialize, tools/list) что требует времени.
Слышал по этому поводу мнения, что MCP нам вообще не нужны.
Я бы сказал - такие MCP - да, не нужны. А в целом идея хорошая, не все скилами можно реализовать из-за сложности и вопросов безопасности.
Что делать?
1) несколько профилей агента, с разным набором MCP серверов. Возможно даже lite версию вообще без MCP (Claude Code через
--strict-mcp-config --mcp-config '{}', Gemini\Qwen Code через --allowed-mcp-server-names '{}').2) переписать MCP на skill если это простая прокси к внешнему API. Скил может включать в себя Python скрипты. Агенты такие скилы неплохо пишут.
Скилы сделаны "по уму", там в контекст по умолчанию выставляется только name и description, содержимое SKILL.md и другие файлы добавляются по мере необходимости.
Этап подключения для скилов отсутствует, это просто специализированный промт.
3) lazy load описаний и схем тулов, сделанный на уровне агента. Claude Code, видимо по принципу "Я тебя породил, ..." реализовал это первым https://vc.ru/ai/2864901-claude-code-i-mcp-lazy-loading-uluchshaet-ai-agentov.
Итоги, цитата:
Контекст при старте: экономия до 95%. В одном реальном кейсе — с 51 000 токенов до 8 500.
Точность на Opus 4: с 49% до 74% на MCP-бенчмарках с большими библиотеками инструментов.
Точность на Opus 4.5: с 79,5% до 88,1%.
Максимальное описание инструмента: ограничено 2 КБ
Причем lazy load включается тоже lazy - когда описания MCP tools начинают занимать более 10% контекстного окна. Красиво)
Причем есть предложение дальнейших оптимизаций: https://github.com/anthropics/claude-code/issues/44536
Включая:
а) грузить description скилов тоже лениво. Тут видится противоречие, по стандарту именно description содержит информацию когда подгружать скил. Имя конечно тоже должно быть адекватным, но оно может быть очень коротким.
С другой стороны, если имена нескольких скилов лексически\семантически похожи - ленивая загрузка будет работать, т.к. агент загрузит оба скила и далее уже по описанию выберет правильный.
б) ленивое подключение к MCP - тут понятно
в) профили агентов - это стандартизация решения номер №1. Сейчас это несколько разных папок с агентами, а должны быть - несколько файлов профиля.
г) загрузка тулов\скилов по условию (только при написании тестов, например)
д) динамическая выгрузка
Ну в общем полноценное управление памятью, т.е контекстом)
Есть похожие issues и для других агентов, пока в статусе Open
https://github.com/openai/codex/issues/2335
https://github.com/anomalyco/opencode/issues/17482
4) решение на уровне стандарта MCP. Вот тут все плохо, идут обсуждения, но конкретных предложений нет.
Вот предложение https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1576
Вот еще одно https://github.com/orgs/modelcontextprotocol/discussions/532
Но до реализации дело не дошло.
Вывод - AI агенты активно развиваются.
#ai #ai_agents #mcp #ai_agent_context_management
GitHub
[FEATURE] Lazy context loading: extend the ToolSearch pattern to all context components · Issue #44536 · anthropics/claude-code
Preflight Checklist I have searched existing requests and this feature hasn't been requested yet This is a single feature request (not multiple features) Problem Statement Claude Code loads ALL...
👍2
В продолжение темы MCP - вот пример переписывания MCP тулов для запуска браузера на скилах и Node.js скриптах https://mariozechner.at/posts/2025-11-02-what-if-you-dont-need-mcp
А все почему? Цитата:
При этом Claude по большей части эту проблему пофиксили.
P.S. Что интересно - многие агенты написаны на Node.js, и они за собой тащат Node.js через скилы. Под соусом - ну у вас же точно установлен Node.js.
#ai #mcp
А все почему? Цитата:
Playwright MCP has 21 tools using 13.7k tokens (6.8% of Claude's context). Chrome DevTools MCP has 26 tools using 18.0k tokens (9.0%). That many tools will confuse your agent, especially when combined with other MCP servers and built-in tools.
При этом Claude по большей части эту проблему пофиксили.
P.S. Что интересно - многие агенты написаны на Node.js, и они за собой тащат Node.js через скилы. Под соусом - ну у вас же точно установлен Node.js.
#ai #mcp
mariozechner.at
What if you don't need MCP at all?
Got Bash and some code interpreter? Skip MCP.
Заменит ли AI разработчика?
Предлагаю посмотреть на этот вопрос позиции - а какие навыки разработчика станут ненужными после внедрения крутого AI? Уровня топовых моделей сейчас и выше.
Я выделил следующие навыки:
1) логическое мышление, нахождение причинно-следственных связей
2) алгоритмическое мышление (а-ка задачки с leetcode)
3) абстрактное мышление, проектирование архитектуры
4) анализ, решение проблем, работа с неопределенностью
5) базовые практики - shell, git, DevOps, Docker\k8s, отладка, профилирование, телеметрия, ...
6) глубокое знание своего стека (Java, Android, JS...)
7) опыт, знание паттернов (паттерны - это по сути концентрированный опыт)
8) работа с заказчиком, софт-скилы
Что становится ненужным с внедрением AI?
Кажется, что ничего)
В теории можно было бы выкинуть 5-7, но есть нюанс.
Если мы считаем, что модель по итогам brainstorm-а с пользователем всегда сгенерирует 100% полные требования, по которым в свою очередь создаст 100% правильный код с 100% тестовым покрытием - то да, выкидываем.
Это реально? Нет.
LLM - повторяет существующий код, на котором обучалась.
А в существующих решениях 100% правильного нет, т.к. задачи и подходы у всех разные.
А если в решении будут ошибки, то чтобы понять, что не так, как раз и требуется опыт, знание стека и практик.
А опыт нужно где-то получить, но это уже отдельный вопрос.
Упадет ли важность опыта, знания стека и практик? Да, как минимум потому, что на простых атомарных задачах AI будет допускать все меньше ошибок. Не не исчезнет.
Сможет ли владелец продукта писать код?
Ну если он владеет логическим, алгоритмическим и абстрактным мышлением - да, до какого-то уровня. Собственно до уровня, когда нужно будет "залезть в код".
А ещё есть мнение (Алан Кей, создатель ООП и языка SmallTalk) - что этими качествами обладают 5% населения https://tinlizzie.org/IA/index.php/End-User_Programming_by_Alan_Kay_(1991)
Нужно ли будет столько разработчиков? Вот тут вопрос, да...
Но очевидно, что хорошие разработчики будут нужны.
P.S. И с увеличением количества кода резко увеличивается важность навыка работы с неопределенностью. Не построчно же весь AI код ревьювить)
#ai
Предлагаю посмотреть на этот вопрос позиции - а какие навыки разработчика станут ненужными после внедрения крутого AI? Уровня топовых моделей сейчас и выше.
Я выделил следующие навыки:
1) логическое мышление, нахождение причинно-следственных связей
2) алгоритмическое мышление (а-ка задачки с leetcode)
3) абстрактное мышление, проектирование архитектуры
4) анализ, решение проблем, работа с неопределенностью
5) базовые практики - shell, git, DevOps, Docker\k8s, отладка, профилирование, телеметрия, ...
6) глубокое знание своего стека (Java, Android, JS...)
7) опыт, знание паттернов (паттерны - это по сути концентрированный опыт)
8) работа с заказчиком, софт-скилы
Что становится ненужным с внедрением AI?
Кажется, что ничего)
В теории можно было бы выкинуть 5-7, но есть нюанс.
Если мы считаем, что модель по итогам brainstorm-а с пользователем всегда сгенерирует 100% полные требования, по которым в свою очередь создаст 100% правильный код с 100% тестовым покрытием - то да, выкидываем.
Это реально? Нет.
LLM - повторяет существующий код, на котором обучалась.
А в существующих решениях 100% правильного нет, т.к. задачи и подходы у всех разные.
А если в решении будут ошибки, то чтобы понять, что не так, как раз и требуется опыт, знание стека и практик.
А опыт нужно где-то получить, но это уже отдельный вопрос.
Упадет ли важность опыта, знания стека и практик? Да, как минимум потому, что на простых атомарных задачах AI будет допускать все меньше ошибок. Не не исчезнет.
Сможет ли владелец продукта писать код?
Ну если он владеет логическим, алгоритмическим и абстрактным мышлением - да, до какого-то уровня. Собственно до уровня, когда нужно будет "залезть в код".
А ещё есть мнение (Алан Кей, создатель ООП и языка SmallTalk) - что этими качествами обладают 5% населения https://tinlizzie.org/IA/index.php/End-User_Programming_by_Alan_Kay_(1991)
Нужно ли будет столько разработчиков? Вот тут вопрос, да...
Но очевидно, что хорошие разработчики будут нужны.
P.S. И с увеличением количества кода резко увеличивается важность навыка работы с неопределенностью. Не построчно же весь AI код ревьювить)
#ai
❤1👍1
distroless образы Docker.
Что такое Docker - это Linux...
Но нет, на самом деле.
Linux-а внутри может не быть.
Это легко проверить, сделав образ
from scratch
Но что полезного в таком образе?
Ок, добавим Java.
Но на самом деле для работы реальных сервисов нужно чуть больше Linux обвязки.
Пользователи, временные настройки, папка /tmp, корневые сертификаты (если нет SSL origination на egress).
Вот для таких случаев и в то же время для упрощения реализации требований по безопасности придумали distroless образы.
Грубо говоря это что-то среднее между scratch и обычным образом. Есть конфиги и структура папок, но практически нет исполняемых файлов. И библиотек C-ных по минимуму.
Детальнее тут https://habr.com/ru/companies/flant/articles/822427/
Плюсы подхода понятны - меньше компонентов в образе = меньше уязвимостей.
Минусы тоже есть.
Для начала - логи локальные никуда не денутся. Stdout/stderr перехватывается драйвером Docker/k8s и сохраняется на хост-сервере.
Будем работать команда
docker cp
ей shell не нужен.
Но изучать файловую систему контейнера так будет сложно.
А уж запустить внутри образа, скажем, curl для проверки локальных endpoints так просто не получится. Ну и из бизнесового сервиса shell команду конечно же не запустишь.
Какие варианты?
1) классический: "хорошо делай - хорошо будет") В смысле пиши достаточно подробные логи, сделай возможность управлять уровнем логирования, отбрасывай метрики и трейсы, отдавай подробные healthcheck. И будет счастье. Или нет)
2) держать рядом нормальный образ сервиса - т.е делать два образа каждый раз. И иметь возможность быстро накатить отладочный образ на ПРОМ. Тур вставк встает вопрос - можно ли итоги тестирования одного образа автоматически применить ко второму? Или тесты гонять дважды? Не хотелось бы.
3) debug ephemeral sidecars. Отличаются от обычных тем, что могут быть добавлены к поду в любой момент и исчезают после его рестарта. Запускаются командой
kubectl debug pod/mypod
-it
--target=myapp
--image=busybox
Ещё надо бы включить в Deployment sharing процессов, чтобы работала ps.
shareProcessNamespace: true
Ну и согласовать все это с безопасниками. Детальнее https://habr.com/ru/companies/timeweb/articles/720510/
Кажется, хороший вариант как раз для distroless контейнеров.
#docker #security
Что такое Docker - это Linux...
Но нет, на самом деле.
Linux-а внутри может не быть.
Это легко проверить, сделав образ
from scratch
Но что полезного в таком образе?
Ок, добавим Java.
Но на самом деле для работы реальных сервисов нужно чуть больше Linux обвязки.
Пользователи, временные настройки, папка /tmp, корневые сертификаты (если нет SSL origination на egress).
Вот для таких случаев и в то же время для упрощения реализации требований по безопасности придумали distroless образы.
Грубо говоря это что-то среднее между scratch и обычным образом. Есть конфиги и структура папок, но практически нет исполняемых файлов. И библиотек C-ных по минимуму.
Детальнее тут https://habr.com/ru/companies/flant/articles/822427/
Плюсы подхода понятны - меньше компонентов в образе = меньше уязвимостей.
Минусы тоже есть.
Для начала - логи локальные никуда не денутся. Stdout/stderr перехватывается драйвером Docker/k8s и сохраняется на хост-сервере.
Будем работать команда
docker cp
ей shell не нужен.
Но изучать файловую систему контейнера так будет сложно.
А уж запустить внутри образа, скажем, curl для проверки локальных endpoints так просто не получится. Ну и из бизнесового сервиса shell команду конечно же не запустишь.
Какие варианты?
1) классический: "хорошо делай - хорошо будет") В смысле пиши достаточно подробные логи, сделай возможность управлять уровнем логирования, отбрасывай метрики и трейсы, отдавай подробные healthcheck. И будет счастье. Или нет)
2) держать рядом нормальный образ сервиса - т.е делать два образа каждый раз. И иметь возможность быстро накатить отладочный образ на ПРОМ. Тур вставк встает вопрос - можно ли итоги тестирования одного образа автоматически применить ко второму? Или тесты гонять дважды? Не хотелось бы.
3) debug ephemeral sidecars. Отличаются от обычных тем, что могут быть добавлены к поду в любой момент и исчезают после его рестарта. Запускаются командой
kubectl debug pod/mypod
-it
--target=myapp
--image=busybox
Ещё надо бы включить в Deployment sharing процессов, чтобы работала ps.
shareProcessNamespace: true
Ну и согласовать все это с безопасниками. Детальнее https://habr.com/ru/companies/timeweb/articles/720510/
Кажется, хороший вариант как раз для distroless контейнеров.
#docker #security
Хабр
Что находится внутри образов distroless-контейнеров
Чтобы вам было проще изучать информацию в области DevOps и Kubernetes из зарубежных источников, мы выбираем интересные англоязычные материалы и переводим их. Очередным таким материалом стала статья...
Куда пропала дешевая память?
Можно даже расширить вопрос - и дешевые SSD?
Про видеокарты все понятно, сначала крипта, потом AI. Геймерам остается только покупать приставки. Учитывая их железо не удивлюсь, если ими в ноль торгуют, отбивая деньги на играх.
Но вернемся к разработке.
Ответ легко найти в интернете - виноват AI.
Первая связь, которая приходит на ум - видеокартам нужна память. А для видеопамяти хотя и используется специальный тип памяти HBM, но эта память, как и ОЗУ, и чипы в SSD часто производят на одних и тех же фабриках. И понятно что сейчас там фокус на память для видеокарт.
Давайте прикинем, сколько памяти нужно для развёртывания LLM модели?
Модель - это набор векторов, вектор - набор float чисел. Количество параметров модели = количеству этих чисел.
Каждому сгенерированному токену (это несколько символов) тоже соответствует вектор, эти вектора сохраняются в KV кэше чтобы не пересчитывать заново.
Сразу важная ремарка - скорость ответа LLM критична к скорости работы с памятью. Поэтому целевой кейс - модель и ее KV кэш находятся в памяти видеокарты, т.к. она самая быстрая.
Еще момент - кэш сессионный, нельзя смешивать данные разных пользователей.
Т.е получаем формулу:
Vllm - объем памяти для модели,
Vkv - для кэша,
sessions - число одновременных сессий,
Vsys - системная память, как некий аналог - в JVM приложении выделяется фиксированная область памяти для JIT компилятора. Можно перенебречь, это единицы Гб.
По умолчанию 2 байта на число.
Тогда для к примеру Qwen-3-Coder-Next со 80B параметров
где params - количество параметров модели
bytes - размерность одного числа, 2 байта.
160 Гб - уже неплохо. Локально не запустим)
Перейдем к KV кэшу.
Типовое число одновременных сессий зависит от мощности GPU. Цель - максимальная утилизация мощности GPU. Ограничение - размер памяти. Пока будем считать для одной сессии.
Вторая важная переменная - размер контекстного окна модели. Это и есть размер кэша. У Qwen - 256k.
К слову, максимум на данный момент - 1 млн. Тут надо понимать, что декларируемый размер окна - теоретический максимум и частично маркетинг. Как говорится - должен, но не обязан)
Для чатов и для code агентов с условно безлимитными подписками провайдеру не выгодно давать полное окно в 1 млн токенов, и скоро станет ясно почему. Хотя при оплате за токены получить его можно.
Поэтому наш пример можно считать типовым.
Далее KV - это key и value. Почему кстати key и value - почему не просто вектор? Модель при генерации очередного токена использует все ранее сгенерированные токены. key определяет вес (важность) данных в старом токене для генерации нового, а value - это собственно сами данные.
Этот механизм называется Attention.
А общая формула для кэша такая:
layers и hidden - число слоев и размер вектора - это представление символа внутри движка инференса. Слой можно представить как этап конвейера генерации символов. Примерно можно считать, что первые этапы отвечают за лексику и синтаксис, последние - за смысл.
Числа отличаются от модели к модели, значения для Qwen Coder - 48 и 2048 соответственно.
bytes такой же, как и для модели - 2 байта, float.
Итого получаем:
Тут уже прикольно, что токен "кот" в LLM превращается в 400kB. gif-ки с котиками они там что ли хранят (шутка)
Итого 260 Гб памяти на одну клиентскую сессию на не самой сильной модели.
Ага, вот куда вся память делась!)
Попросил ты такой перевести LLM страничку на русский и сожрал 260 Гб...
Тут может возникнуть вопрос - а как оно вообще работает?)
Условный Claude Opus вообще ни в одну видеокарту не влезет. Там по оценке 5 триллионов параметров, т.е. в 50 раз больше, и пропорционально увеличившийся KV кэш.
Ответ: оптимизации. Кажется среди AI инженеров сейчас много хороших оптимизаторов)
Можно даже расширить вопрос - и дешевые SSD?
Про видеокарты все понятно, сначала крипта, потом AI. Геймерам остается только покупать приставки. Учитывая их железо не удивлюсь, если ими в ноль торгуют, отбивая деньги на играх.
Но вернемся к разработке.
Ответ легко найти в интернете - виноват AI.
Первая связь, которая приходит на ум - видеокартам нужна память. А для видеопамяти хотя и используется специальный тип памяти HBM, но эта память, как и ОЗУ, и чипы в SSD часто производят на одних и тех же фабриках. И понятно что сейчас там фокус на память для видеокарт.
Давайте прикинем, сколько памяти нужно для развёртывания LLM модели?
Модель - это набор векторов, вектор - набор float чисел. Количество параметров модели = количеству этих чисел.
Каждому сгенерированному токену (это несколько символов) тоже соответствует вектор, эти вектора сохраняются в KV кэше чтобы не пересчитывать заново.
Сразу важная ремарка - скорость ответа LLM критична к скорости работы с памятью. Поэтому целевой кейс - модель и ее KV кэш находятся в памяти видеокарты, т.к. она самая быстрая.
Еще момент - кэш сессионный, нельзя смешивать данные разных пользователей.
Т.е получаем формулу:
V = Vllm + Vkv * sessions + Vsys
Vllm - объем памяти для модели,
Vkv - для кэша,
sessions - число одновременных сессий,
Vsys - системная память, как некий аналог - в JVM приложении выделяется фиксированная область памяти для JIT компилятора. Можно перенебречь, это единицы Гб.
По умолчанию 2 байта на число.
Тогда для к примеру Qwen-3-Coder-Next со 80B параметров
Vllm = params x bytes = 80 x 10^9 × 2 = 160 Гб
где params - количество параметров модели
bytes - размерность одного числа, 2 байта.
160 Гб - уже неплохо. Локально не запустим)
Перейдем к KV кэшу.
Типовое число одновременных сессий зависит от мощности GPU. Цель - максимальная утилизация мощности GPU. Ограничение - размер памяти. Пока будем считать для одной сессии.
Вторая важная переменная - размер контекстного окна модели. Это и есть размер кэша. У Qwen - 256k.
К слову, максимум на данный момент - 1 млн. Тут надо понимать, что декларируемый размер окна - теоретический максимум и частично маркетинг. Как говорится - должен, но не обязан)
Для чатов и для code агентов с условно безлимитными подписками провайдеру не выгодно давать полное окно в 1 млн токенов, и скоро станет ясно почему. Хотя при оплате за токены получить его можно.
Поэтому наш пример можно считать типовым.
Далее KV - это key и value. Почему кстати key и value - почему не просто вектор? Модель при генерации очередного токена использует все ранее сгенерированные токены. key определяет вес (важность) данных в старом токене для генерации нового, а value - это собственно сами данные.
Этот механизм называется Attention.
А общая формула для кэша такая:
Vkv = sessions × context х размер токена = sessions × context × ( 2 × bytes × layers х hidden )
layers и hidden - число слоев и размер вектора - это представление символа внутри движка инференса. Слой можно представить как этап конвейера генерации символов. Примерно можно считать, что первые этапы отвечают за лексику и синтаксис, последние - за смысл.
Числа отличаются от модели к модели, значения для Qwen Coder - 48 и 2048 соответственно.
bytes такой же, как и для модели - 2 байта, float.
Итого получаем:
Vkv = 1 х 256 000 х 2 × 2 × 2048 × 48 = 100 Гб
Тут уже прикольно, что токен "кот" в LLM превращается в 400kB. gif-ки с котиками они там что ли хранят (шутка)
Итого 260 Гб памяти на одну клиентскую сессию на не самой сильной модели.
Ага, вот куда вся память делась!)
Попросил ты такой перевести LLM страничку на русский и сожрал 260 Гб...
Тут может возникнуть вопрос - а как оно вообще работает?)
Условный Claude Opus вообще ни в одну видеокарту не влезет. Там по оценке 5 триллионов параметров, т.е. в 50 раз больше, и пропорционально увеличившийся KV кэш.
Ответ: оптимизации. Кажется среди AI инженеров сейчас много хороших оптимизаторов)