Когда я впервые увидел embedded Kafka, то подумал: Круто, жаль, что такого же нет для PostgreSQL.
И был не прав, спасибо, коллега просветил.
Встречаем Zonky Embedded Postgres https://github.com/zonkyio/embedded-postgres

Подключается как Java зависимость. Можно управлять версией PostgreSQL. Поддерживает ОС Darwin, Windows, Linux, Alpine Linux и Intel и ARM архитектуры. Легко подключается в тесты и утилиты миграции БД через rules.

@Rule
public SingleInstancePostgresRule pg = EmbeddedPostgresRules.singleInstance();

@Rule
public PreparedDbRule db =
EmbeddedPostgresRules.preparedDatabase(
LiquibasePreparer.forClasspathLocation("liqui/master.xml"));

Также можно работать напрямую с объектом БД:

try (EmbeddedPostgres pg = EmbeddedPostgres.start();
             Connection c = pg.getPostgresDatabase().getConnection()) {
...
}

Как по мне - крутая штука, и вот почему. Рассмотрим альтернативы:
1) обычная инсталляция PostgreSQL - есть момент с правами, плюс единая инсталляция на компьютере разработчика - это shared ресурс на несколько проектов и риск поломки БД
2) Docker - опять же может не быть необходимых прав, плюс Docker - это тонкая, но все же прослойка. Которую нужно запустить и которая немножко жрет ресурсы.

В нашем случае по факту Постгря ставится в папку target/build, т.е. есть изоляция по проектам, плюс переустановка делается обычным clean.

Ну и отсюда к следуют минусы - на скачивание и распаковку в папку target нужно время.
Ну и время жизни такой инсталляции ограничено.
Поэтому идеальный кейс - тесты на живой БД.

#db #postgrrsql #integration_tests

Два факта про безопасность AI.

Первый - есть исследование, где говорится, что 45% сгенерированного AI кода содержит классические программные уязвимости из OWASP Top 10 https://www.veracode.com/blog/genai-code-security-report/ Причем за 2 года с 23 по 25 год ситуация практически не изменилась. В отличие, например, от процента компилируемого кода.

Второй факт - сообщение агента вчера при работе с Claude Opus, процитирую:

Напоминаю по факту: я запустил sudo cat /etc/gitlab-runner/config.toml, чтобы проверить extra_hosts, и в выводе целиком приехала строка token = "glrt-X…". Надо было сразу grep -v token — дальше я так и делал, но эту строку уже не отменить.

Итог: токен в 2 файлах транскрипта сессий (~/.claude/projects/**.jsonl) плюс в бэкапе /etc/gitlab-runner/config.toml.bak.20260810, который создал я.

Главное, а не файлы на диске: он был в моём контексте, то есть ушёл в API Anthropic. Локальной утечкой это уже не назвать.

Дайте новый токен — впишу и перезапущу, privileged/volumes не тронув. Или сделайте сами, если не хотите гонять его через меня второй раз — что, учитывая причину ротации, разумнее.

Что меня удивило?
1) я не спрашивал агента про уязвимость
2) он понимает, что утечка токена на сервера Anthropic (не в репозиторий с кодом) - это все равно утечка
3) в сообщении мне секрет был замаскирован
4) он предлагает заменить токен мне самому

Лед тронулся)
А ведь тот же SAST\DAST и сканирование на секреты в CI pipeline никто не отменял.
Плюс скилы на проверку безопасности кода.

P.S. Я в посте немного сгустил краски, есть менее известное, но более новое исследование, где процент уязвимого кода у лучших моделей снизился до 24 - https://aclanthology.org/2026.acl-long.1107/
Что лишь подчеркивает мою мысль. Т.е статистика подтверждает изменения к лучшему.

P.P.S. Как бы не прийти к тому, что основной задачей разработчика станет получение и подстановка токенов)

#ai #security

Новости стандартизации AI агентов

Я уже писал про плагины, они же расширения https://t.me/javaKotlinDevOps/614
И из этого поста видно, что стандартизации особой не было. Даже названия два.

И вот, стандарт появился - https://agent-plugins.org/

Стандартизируется структура папок и файлов, структура предлагается такая:

my-plugin/
├── plugin.json
├── skills/
│   └── summarize/
│       ├── SKILL.md
│       ├── scripts/
│       └── references/
├── mcp.json
└── com.example.client/
    └── hooks/

Есть возможность добавить в плагин скилы, MCP и описание.

Стандарт можно расширять: настройками в plugin.json и скриптами в com.example.client - хуки, например.
Расширения опциональны, AI агент может игнорировать, если не понимает формат.

Почему стандартизировали только skills и MCP?
Это уже зрелые стандарты, в отличие от хуков, субагентов, команд.
Хотя AGENTS.md тоже стандартизирован, но его поддержки почему-то нет.

И определились наконец с названием - все же плагины. Буду теперь их так называть)

Вот список поддерживающих стандарт AI агентов https://agent-plugins.org/compatible-clients
Из известных для разработки - Cursor, Codex, VSCode и Copilot.
Не хватает Claude Code, Gemini, Qwen.

Резюме - стандартизация неизбежна.

P.S. Но это не решает проблему - как одновременно пользоваться разными AI агентами. Папки то у них разные, и внутри не все стандартизировано. Но тут тоже есть наработки.

#ai #ai_agents

Тренды агентостроения.

Уже был пост про общие команды у топовых coding агентов https://t.me/javaKotlinDevOps/603

Так вот, на примере Claude Code и Codex появился новый кандидат на унификацию.

Встречаем ... /import

Что именно импортируется?
Оба умеют импортировать скилы, файлы контекста (напомню, Claude еще не поддерживает AGENTS.md, поэтому импорт пока актуален), MCP, команды и субагенты.
Codex еще умеет импортировать хуки, настройки, плагины, проекты и чаты. В общем практически все.
Импортируют у друг друга, а еще Claude у Gemini, а Codex у Cursor. Видимо, именно их считают основными конкурентами.
Другие агенты импортировать не умеют, пока что, и я уверен, скоро подтянутся)

Почему решил обратить внимание на эту команду.
1) конкуренция между агентами и стоящими за ними LLM моделями усиливается. Покупка Grok-ом Cursor-а в эту же копилку.
2) стандартизации пока нет - субагенты, команды, хуки, настройки, проекты и история чатов - явные кандидаты
3) как решение для одновременной работы в нескольких агентах - лучше, чем ничего, но не идеально. Т.к. при любом изменении в любом из агентов нужен новый ручной импорт и не факт, что он ничего не поломает.
4) ну а переход от одного агента к другому конечно же сильно облегчается

#ai #ai_agents

Можно ли чему-то научиться у AI?

Базовый ответ - да, т.к. в LLM в процессе обучения попало множество документации и кода, который я, например, никогда не видел.
Да, в сжатом виде, возможно искаженном, но в любом случае это огромный объем знаний.

Но я сейчас про более конкретные вещи.

Например, тесты.
Ключевой момент, что агент пишет десятки тестов на каждую фичу.
Кроме стандартных unit и интеграционных я заметил парочку новых типов.

1) тесты на миграцию БД - включая откат миграции. Простые, накатывают миграцию, проверяют, что новый объект появился\исчез в БД. Польза не то, чтобы большая, но есть. Ломаться часто не должны, т.к. каждый такой тест проверяет свою версию БД.

2) AST тесты - т.е. тесты с синтаксическим анализатором кода, проверяющие, что в методе не делается что-то лишнее. Или делается что-то обязательное. Часто такие тесты можно реализовать передачей в тестируемый метод spy-объекта. Но не всегда. Для меня было открытием. Самому такие тесты писать сложно, AI - примерно также, как и другие. Тесты скорее всего будут хрупкими, т.к. зависят от структуры кода. Но для проверки отдельных ключевых инвариантов проекта, над которым работает множество людей - это лучше, чем JavaDoc.

3) тесты, проверяющие документацию, генерация которой - тоже функция приложения. Например, admin guide. Наличие, формат. Тоже свежая мысль, IMHO. Самому - точно руки бы не дошли до таких тестов, а с AI - почему бы и нет.

Последний кейс пограничный - то же самое можно сделать и скилом. И такие приемочные скилы (они же evals) - это тоже своего рода тесты, просто реализованные в другой форме. Просто они могут не просто вызвать скрипт, а еще и проверять требования к проекту с помощью LLM. И даже в случае LLM, которая недетермирована, это лучше, чем просто пару строк в README.md.

#ai #ai_agents #testing

Заметки про LiteLLM.

Во-первых - это не LLM) Это SDK, предоставляющий унифицированный доступ к LLM провайдерам - типа Spring AI - и AI прокси.

Вот второй use case и рассмотрим.

Для чего нужна прокси?

1) независимый от провайдера подсчет токенов. В теории и стоимости токенов, если это API тарифы. Т.к. у подписок свои абстрактные единицы измерения. Даже если они называются одинаково - кредиты - они не равны между собой и не переводимы в токены.
2) конвертация API, например, Anthropic-OpenAI, для тех провайдеров, кто не поддерживает Anthropic API нативно. На всякий случай - единого API к разным LLM нет, несмотря на некую похожесть. Ну и OpenAI API наиболее распространен сейчас, т.к. они были первые.
3) единая точка для настройки различных провайдеров LLM - URL, секреты, список доступных моделей. И, соответственно, легкое переключение между провайдерами.

Это мои кейсы, а еще можно организовать многопользовательский доступ, лимиты, подключить для всех MCP серверы и даже умную балансировку между моделями. Последнее особо интересно, но руки пока не дошли.

Теперь собственно заметки:
1) поддерживает подписки Anthropic и вроде бы OpenAI. Ну и API ключи, но это опция по умолчанию. Важно отметить, что все китайцы дают доступ к своим подпискам по API ключу - Qwen, Kimi, GLM. А вот у Claude и OpenAI подписка = OAuth авторизация, которую несколько сложнее проксировать из-за наличия нескольких ключей и их постоянной ротации. А подписки - это наше все, цена в 4-10 раз дешевле, чем при оплате за токены у одного и того же провайдера.
2) документация - отстой
3) есть UI, там можно смотреть логи, статистику, настраивать модели, проверять их доступность. Логировать может как в формате access logs, так и с данными - последнее включается отдельно
4) есть своя база моделей и провайдеров, но ориентация на американский рынок, китайских провайдеров мало
5) большая часть проблем возникает на стыке агента и прокси. Хотя этот момент в документации постарались раскрыть - вот пример отдельная статья по подключению Claude с подпиской https://docs.litellm.ai/docs/tutorials/claude_code_max_subscription

Ну и на примере этой же статьи можно разобрать ряд проблем:
1) в заголовке статьи явно указана Claude Max, что сразу вызывает вопрос о Pro подписке. А она работает)
2) названия моделей. Они устаревшие, при этом они подаются как список поддерживаемых моделей. На самом деле поддерживаются все актуальные, это же обычный прокси.
3) LITELLM_MASTER_KEY - что это, зачем, как генерировать? Генерировать, к слову, также, как и другие виртуальные ключи - из консоли или в UI. Но виртуальные ключи - это способ разделения трафика от разных агентов в отчетах, а зачем нужен мастер ключ?
4) судя по статье для Anthropic - как преднастроенного провайдера - API endpoint указывать не нужно... Это собственно была главная проблема. Пока я не указал url явно - прокся отправляла запросы по подписке сама на себя, выдавала ошибку аутентификации 401, т.к. второй запрос шел с кредами Anthropic, а не со своими. А ошибка аутентификации вводила в заблуждение, т.к. говорила, что не найден ключ для LiteLLM. И более того, эта ошибка была обвернута в (видимо) стандартную ошибку - что-то типа выбранная модель не настроена. Что еще больше вводило в заблуждение, т.к. она же настроена по инструкции) Еще больше ввела в заблуждение весенняя новость о запрете использования подписки Claude в сторонних агентах и контроле агента на стороне сервера. Я уже начал думать, что и прокси зарубили, но нет)

Ну и самое главное на стыке агента и прокси, в моем случае Claude Code:
1) у Claude Code есть 2 режима работы - OAuth и API токены. Переключает их наличие переменной среды ANTHROPIC_AUTH_TOKEN. В целом понятно, но об этом нужно помнить. Секрет LiteLLM либо в ANTHROPIC_AUTH_TOKEN (API), либо в ANTHROPIC_CUSTOM_HEADERS (OAuth). Рабочая схема - завести отдельный shell скрипт для API режима.
2) у Claude Code есть model discovery (включается CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1) - запрос доступных моделей у провайдера, прокси в нашем случае. Но агент запоминает только модели, начинающиеся с claude. Зачем, почему - хз. Но пришлось заводить claude-deepseek и т.д)
3) discovery запускается только для API режима. Это логично. И сохраняет список моделей при дальнейшей работе в любом режиме
4) агент не умеет запрашивать характеристики модели, в частности размер контекстного окна. А от его размера зависит в какой момент запустится автосжатие. А для неизвестных агенту моделей (всех в нашем случае) агент считает размер контекста равным 200к токенов. Все способы настройки выглядят как костыли https://code.claude.com/docs/en/model-config#correct-the-window-for-a-gateway-or-custom-model-id Я завел каждую модель с контекстом более 1m в 2 экземплярах - с суффиксом [1m] и без. Первая удобнее, вторая - дешевле. Отображаются в агенте они криво, но главное - работает.

Stay tuned, об остальном позже.

#ai #ai_agents

Заметки по LiteLLM - вторая часть.

1) в лучших традициях open-source из коробки LiteLLM запускается на 0:0:0:0 - т.е. доступна снаружи. Решается параметром --host 127.0.0.1

2) логирование ошибок на троечку - вместо одного конкретного сообщения они логируют исключения на нескольких уровнях, в итоге часть сообщений об ошибках нужно просто игнорировать. В debug режиме много дублирования - одно и тоже http сообщение появляется в логах несколько раз. Справедливости ради, как раз debug режим позволил мне найти причину ошибки с зацикливанием запроса на прокси.

3) очевидно, чтобы хранить статистику - нужна БД. В инструкции по инсталляции об этом сказано вскользь. Как и том, что кроме отдельной database еще нужно ставить Prisma - Node.js ORM с функционалом миграции БД. Это при том, что приклад написан на Python. И более того - из исходников Prisma нужно собрать бинарь для накатывания миграции. Как это сделать - я выяснил с AI-шкой.

4) цену запросов для неизвестных для системы провайдеров LLM можно вбить прямо в config.yaml - файл настроек. Это хорошо. Плохо то, что после этого LiteLLM все равно будет ругаться на отсутствующие тарифы. Т.е. понять что все работает можно запустив агента и посмотрев статистику по тарифам

5) для подписки Anthropic стоимость считается по тарифам API. На первый взгляд странно. Но с другой стороны - у подписки вообще нет стоимости токена, вместо этого есть оставшийся лимит. А видеть стоимость полезно для оценки насколько выгодна подписка.

6) LiteLLM смешивает понятие формат API и провайдер. Т.е. невозможно задать провайдер Deepseek и формат API Anthropic. В данном примере:

  - model_name: deepseek-v4-flash
    litellm_params:
      model: anthropic/deepseek-v4-flash
      api_base: https://api.deepseek.com/anthropic

оба этих параметра определяются по model: anthropic/
Т.е. либо преобразуем формат в OpenAI (как нативный формат Deepseek) и есть раздельный учет по провайдерам в статистике, либо без преобразований, но все сидят на одном провайдере.

7) есть важная настройка

general_settings:
  forward_client_headers_to_llm_api: true

Она позволяет пробрасывать к провайдеру клиентские заголовки, начинающиеся с x-.
Нужна, например, для пробрасывания заголовков Claude Code со списком поддерживаемых клиентом фичей.
Вроде бы все хорошо, штука полезная.
Но как выяснилось при разборе логов - в процессе пробрасывания есть фильтрация (вырезание) неизвестных для LiteLLM заголовков.
Как я понял, это нужно, чтобы резать заголовки с секретами, которые клиент шлет, а в LLM провайдер передавать нельзя по каким-то (каким?) причинам.
Резали бы только свои заголовки, типа x-litellm-api-key - ключ для аутентификации в LiteLLM.
Это еще пол-беды. Плохо то, что ни отключить, ни настроить эту фильтрацию нельзя.
Сейчас у меня все работает, но учитывая борьбу того же Anthropic с не-родными клиентами - потенциально опасная штука.

Получилось как список проблем, но конечно же есть и плюсы)

#ai #ai_agents

Еще про стандартизацию AI.

Как говорил ранее - стандарта для настроек агентов сейчас нет.
.claude, .codex, .qwen, .gigacode, и внутри структура немножко отличается, как минимум название файла с контекстом и расположение настроек MCP.

Когда же наступит счастье, в смысле стандартизация?
Точно не скажу, но процесс идет)

Пока идет в разных направлениях, увы.
1) https://agentsstandard.com
2) https://dotagentsprotocol.com/
3) https://github.com/jackby03/agentic-collaboration-standard
4) https://github.com/bgreenwell/dotagents

И это я особо не искал)

у всех папка называется .agents, у всех внутри есть папка skills. Далее - разнообразие.

Из интересного - поддержка .agents есть в Kilo Code и Codex.
Из практических рекомендаций - вполне можно уже сейчас хранить скилы в .agents/skills тем более, что и сам формат скилов стандартизирован.
И делать симлинки на родные папки для несовместимых агентов.

#ai #ai_agents

И снова рубрика "Находки из Python".

Как вы думаете, что делает вот такая конструкция?

@pytest.mark.xfail(strict=True, reason = "будет исправлено в задаче TASK-100") 
def test_function():

Она "фэйлит" прогон, если тест пройден)
Зачем это нужно - если из-за частичного рефакторинга некий код перестал работать. И нужно отследить момент починки в следующих релизах.
Т.е. как только чиним код - тест начинает падать, мы снимаем xfail.
Если тест просто "скипнуть" - это можно забыть сделать. Плюс если упала группа тестов - то ее можно пометить одинаковым описанием и убедится, что починились все. Стандартного функционала для этого нет, но можно поиском по проекту.
Видится, что полезно в плане контроля тестов.
Есть конечно радикальный вариант - вообще избегать отключения тестов, но жизнь - сложная штука).

Отдельно про параметр strict.
Если его поставить в false - получаем тест, который не ломает запуск ни при успешном прогоне, ни при падении.
Зачем это может быть нужно?
Для flaky тестов, которые невозможно починить здесь и сейчас.
Тут конечно у меня вопросики, т.к. такое действие - прямой путь к тому, что про flaky тест мы просто забудем.
А в итоге контроль над тестовым набором, наоборот, ухудшится.

Я сразу стал искать - есть ли аналог в Java?

В JUnit из коробки нет, иначе бы этого поста не было)

Но есть в JUnit Pioneer:

@Test
@ExpectedToFail("будет исправлено в задаче TASK-100")
void testFunction() {

Это аналог strict режима. Не strict режима нет, что IMHO к лучшему.

Обе аннотации позволяют задать исключения, с которыми тест должен упасть.

Python вариант также позволяет задать condition:

@pytest.mark.xfail(condition="not config.getvalue('db')")
def test_function(): ...

В Python интерпретатор есть в runtime, в отличие от Java (там в runtime только компилятор из байт-кода в нативный), поэтому это проще сделать.

Мой вердикт - штука полезная.

#python #java #python_gems #unit_tests #junit

Еще один пост о вреде Boolean флагов)

Почему еще один - я за последние пару лет точно видел несколько таких постов)
Но хочется немного обобщить и накинуть практических советов.

В чем суть?

Есть такая рекомендация - вместо нескольких Boolean флагов у одной сущности лучше использовать поле state с Enum типом.
Почему?

Я бы даже поставил вопрос по другому - по каким признаком можно понять, что пора заводить state?

1) есть запрещенные или не имеющие бизнес-смысла комбинации флагов. А число комбинаций растет линейно. Например 3 Boolean поля = 8 комбинаций
2) при установке одного из флагов приходится сбрасывать другие
3) при установке приходится проверять другие флаги
4) флаг X1 был сделан для использования в guard условии специально в модуле Y1. Флаг X2 - в модуле Y2. Но со временем в модуле Y2 приходится проверять оба флага. Это может быть альтернативой для одного из двух предыдущих вариантов.

Видится, что при любой такой проблеме стоит задуматься о добавлении единого state и расписывании переходов между его значениями (state machine).
В идеале - линейной цепочки переходов.

И вообще говоря правило можно обобщить.
Если у сущности есть несколько Boolean или Enum полей, для которых начинают возникать проблемы, описанные выше - это повод к их объединения в один большой Enum.
И Enum тут усугубляет ситуацию: 3 Enum с минимальными 3 значениями у каждого - это уже 27 комбинаций.
Можно даже это паттерном назвать - схлопывание состояний)

#antipatterns #patterns

PostgreSQL наносит ответный удар)

Я думаю все слышали про NoSQL, предлагающие альтернативные реляционной структуре способы хранения данных.
И отъедающие долю рынка у реляционных СУБД.
Но есть и обратный процесс.

Уже писал про расширения для PostgreSQL. Так вот, возможность хранить NoSQL данные добавляются, как правило, с их помощью.

Что у нас есть на данный момент?

Рассмотрим работу с разными типами данных:

1) time series - TimescaleDB. time series = временная метка и значение какого-то показателя. Самый яркий пример - метрика. Особенности при работе с такими данными: объем данных - т.е. автоматический retention и сжатие, быстрая работа с длинными рядами - простое разбиение на партиции\чанки, агрегация данных из коробки

2) embeddings - pgvector. Хранение embedding в базе и конечно же векторный поиск по ним

3) полнотекстовый и нечеткий поиск по тексту - встроенные типы данных tsvector и методы из pg_trgm - получаем упрощенный аналог ElasticSearch (OpenSearch). На объемах уровня логов скорее всего упадет, но на меньших...

4) графы - в 19-й версии появилась поддержка SQL/PGQ. Т.е. по сути простой графовый VIEW. Данные хранятся по классике в таблицах, но есть удобный синтаксис для запросов по графу. https://www.postgresql.org/docs/19/sql-create-property-graph.html

5) пространственные данные (spatial) - PostGIS

6) document oriented DB - jsonb конечно не полноценный аналог, но запросы по вложенному JSON писать можно. А если еще добавить сюда Citus - то и шардирование получим, что для таких данных видится частым требованием из-за объема.

К чему это я? Не к тому, что все базы данных убьет PostgreSQL. Вряд ли.
А к тому, что если техстек ограничен и там есть PostgreSQL (а он там есть) - до какого-то масштаба можно обойтись одной базой данных.

И здесь появляется жирный плюс. Рядом - в той же или даже соседней схеме - можно положить реляционные данные и менять все вместе в одной транзакции.
Никаких оркестраторов и хореографии, докатов, никакого двухфазного коммита.

P.S. Кроме того, из PostgreSQL можно сделать key-value storage (но не нужно, кэш и БД вместе все равно держать нет смысла). И объекто-ориентированную БД (но зачем, даже не слышал про использование объектных БД, хотя они есть).
Если смотреть на основные типа БД https://db-engines.com/en/ranking - разве что Wide column не покрыты. Но там не просто произвольный набор столбцов у каждой записи, там еще и append only запись как в Kafka для собственно скорости записи.

#postgresql #data #rdbms #nosql

Сколько стоит AI агент?

Для кого-то - бесплатно. Платит работодатель.

Кому-то хватает минимальной подписки. 20 баксов в месяц.

Ну или 2-3 минимальных подписки. Для переключения аккаунтов и агентов даже специальные утилиты придумали - CAAM — Coding Agent Account Manager и CASR — Cross-Agent Session Resumer.

Кому-то нужен план подороже - за примерно 100 баксов в месяц.
Подороже, но в целом не дорого. Ему в минус разве что увеличенная вероятность блокировки играет.

Но ведь есть ещё доступ по API. А там миллион входных токенов может стоить те же 20 баксов. Например, у ChatGPT Astra или Claude Fable. А хватит этот миллион на одну задачу. Да и то, декомпозированную)
Ладно, это все же топ модели.

А сколько будет в месяц стоить работа по API с обычными моделями тех же Claude и Codex?
Разница же навскидку многократная. Вдруг подписки прикроют. Датацентры же окупать надо)

Мой эксперимент - пустить трафик Claude подписки через LiteLLM прокси и поработать в обычном режиме 2 недели. Claude прокся всегда считает по API-ным тарифам.

Поработал. Примерно 700 баксов насчитал.
А у меня в параллель ещё Codex с ChatGPT с такой же нагрузкой и ценами. Т.е умножаем на 2.
И ещё на 2 чтобы месяц получить.
Уже 2800.
А ещё у меня на подхвате 2 китайские модели для кодинга по плану и в случаев, когда упираюсь в лимиты основных моделей. Баксов 100 накинуть надо.

Итого округлим 3000$.
А это между прочим зарплата миддла в России. Если ЗП белая - то затраты работодателя будут x2.

Для чего работодатель платит за AI? Чтобы было больше фичей. И чтобы сэкономить. Точно от внедрения AI не ждут повышения расходов в средне и долгосрочной перспективе.

А это значит, что чтобы дать топовые модели за "честную" стоимость 2 миддлам нужно уволить третьего(

И хочу подчеркнуть, что это не безлимит. Я с такой схемой периодически в лимиты упираюсь. Условный безлимит я думаю ещё в x2 обойдётся. Но тут важно понимать, что при разработке с AI свободное время вроде бы появляется, но при этом когнитивная нагрузка растёт. Поэтому брать больше задач в параллельную проработку сложно. Поэтому как оценка для миддла точно ок.

Вот такая вот дешёвая разработка AI. Пока подписки есть)

P.S. Для внутренних моделей тоже было бы интересно стоимость прикинуть.

P.P..S. Если покупать API через российских агрегаторов в белую то ещё 20% накинуть надо.

P...S. Плачу сейчас я в итоге 70-80 баксов в месяц

#ai

Забавный факт, цитата:

AI context windows have grown from 512 tokens in 2017 to 2,000,000 tokens by 2026 (factor ~3,906; fitted lambda = 0.59/yr; doubling time ~14 months). Over the same period, human Effective Context Span (ECS) -- a token-equivalent measure derived from validated reading-rate meta-analysis (Brysbaert, 2019) and an empirically motivated Comprehension Scaling Factor -- has declined from approximately 16,000 tokens (2004 baseline) to an estimated 1,800 tokens (2026, extrapolated from longitudinal behavioural data ending 2020.

Или не забавный(

Отсюда: https://arxiv.org/abs/2603.26707

Хотя конечно же конкретное окно - лишь один из параметров, определяющих силу LLM. И 2 млн сейчас - это не эффективное окно, а максимальное. Но все равно сравнение интересное.

#ai

Блеск и нищета AI разработки.

Мне легко понять эйфорию менеджеров по поводу AI. Без разработчиков, в диалоге с AI можно создать работающее приложение. Только за токены плати. Ну да, конечно, надо выбрать workflow для разработки, evals настроить, контекст проекта. И, вуаля, роботы работают, отдыхает человек)
И сроки ускоряются.

Но ещё я использую AI для реальной разработки. Сделал свой workflow из двух фреймворков - OpenSpec и Superpowers. Написал свои evals скилы под каждый проект и универсальные. Настроил контексты - проектные и глобальный. Провожу ревью создаваемых спецификаций, смотрю код периодически. Разработка идёт конечно же быстрее. Но при этом я чётко понимаю, что качество кода ниже, чем если бы я его писал полностью руками.

Почему так?

Если свести все причины в одну, то может сформулировать так - очень сложно построить полноценный контекст проекта.

Сильная модель с 100% настроенными правилами работы в проекте с большой вероятностью написала бы код, близкий к моему. Но есть нюанс - 80+% правил находится в головах разработчиков. Некоторые из них разработчики не осознают как правила работы в проекте) И это как раз становится заметно, когда модель делает что-то не так. Конечно, чем больше работаешь над проектом с ИИ - тем больше эти правила будут формализаться. Но это не дни, скорее месяцы. К правилам относятся и ADR - когда-то принятые в проекте решения, которых надо придерживаться. И архитектурные и инфраструктурные требования компании. И многое другое.

Можно на эту проблему посмотреть с другой стороны. Воспомним количество принимаемых во время разработки решений.
Это могут быть десятки на простой фиче. При разработке с ИИ очевидно часть этих решений будет принимать агент. Иначе человек будет блокером в процессе. А чтобы агент принял правильное решение - под каждый кейс должно быть настроено правило. Рецепт если хотите. Если рецепта нет - модель примет решение сама. Может хорошее, а может увеличивающее техдолг и превращающее сервис в legacy.

Очевидно, что при разработке с ИИ не техническим специалистом эффект может нарастать лавинообразно.

Вывод - на данном этапе развития разработки с ИИ мы
1) либо жертвуем скоростью работы и тогда возникает вопрос - зачем нам вообще ИИ
2) либо что более вероятно - жертвуем качеством кода. И хорошо если сервис маленький - тогда его можно просто переписать. Или прототип - тут конечно ИИ идеален.А если нет?

Может возникнуть вопрос - не забыл ли я про третью переменную - деньги?
И да, и нет.
Дорогая модель не гарантирует качественный код. Хотя может его улучшить, особенно при применении на этапе проектирования.

Речь про выбор точек на трех осях - качество, скорость, деньги. А harness - его нужно постоянно настраивать.

#ai

Ещё про небезопасный AI)

Задача - запустить трафик в k8s с Istio через egress для 2 интеграций. Плюс egress отвечает за SSL origination. Обязательное условие: маршруты должны быть отдельными - порты и все манифесты.

Агент меня понял, обсудили делали, он написал спецификацию на основе моих вводных.

Вычитываю спецификацию... 2 VirtualService, 2 ServiceEntry... Вроде все ок. И вдруг - 2 ergress?!? Вопрос агенту - что это? Ответ: ну ты же просил разделить маршруты. Плюс у каждого маршрута в теории свои сертификаты, и т.об. мы физически разграничили доступ к ним.

Даже наша кибербеза никогда не была такой безопасной)

Агента удалось переубедить вопросом: интересно, с таким подходом - отдельный прокси на порт - сколько миллионов проксей в Google?)

Ладно, это скорее курьез. Но вот еще пример. Когда проектировали интеграцию с Vault агент предложил для каждого клиента - приклад и egress - сделать свой ServiceAccount. Развести по разным пользователям по сути. Ровно по той же причине - разграничить доступ к секретам. Кто до такого уровня безопасности доходил?)
Идея, кстати, хорошая, но есть минус - нужно прописывать все эти кастомные ServiceAccount в Vault. С default проще.

И вишенка на торте - агент не только предложил установить права на файл секрета 400 (это база), но ещё и на каталог с секретом 700 поставить. А в прикладе проверить эти права! Т.е такими правами мы запрещаем удаление и создание нового секрета каким-то взломанным sidecar-ом. Круто!
Но есть же ещё родительский каталог - /vault/secrets в случае Vault. И если там есть права на запись - уязвимость остаётся? Нет - в прикладе предлагается ещё и owner секрета проверять. А т.к у нас естественно runAsNonRoot: true и запрет повышения привилегий (это тоже база), то сменить пользователя невозможно. И если все сайдкары кроме Vault запускать под другим пользователем - подмену сразу будет видно.

P.S. Проверять за агентом конечно же нужно в любом случае

#ai

Хотел бы прокомментировать новость в следующем посте и выводы Алексея по ней.

Для начала - согласен с выводами.
Релиз PG задержался впервые за много лет не из-за того, что AI нашел баги в новых фичах (а раньше не находил). А потому, что с AI стало сильно легче искать и эксплуатировать уязвимости.
Раньше до нахождения уязвимости и появления риска проходили годы - сейчас недели.

И это еще одно подтверждение следующей мысли.
Главная проблема внедрения AI для разработчика не в том, что AI еще слаб, а менеджеры требуют больше фичей, обосновывая это требование появлением AI.
Точнее на данном этапе в отдельных командах это так, но это явление временное.
Т.к. AI улучшается.

Основная проблема в том, что сильный AI забирает у человека относительно простую работу - писать код. Подчеркну - относительно!
А вот самая трудная работа - проектирование и ревью - остается за человеком.
И ее станет сильно больше. Почему? AI пишет много кода)
Причем проблема сильнее именно в ревью - объем ревью растет сильнее, чем количество фичей и кода, т.к. LLM хороши в поиске уязвимостей.
В общем случае, чем больше этапов производственного процесса мы отдаем машине - тем сильнее растет объем ревью.

Когнитивная нагрузка растет.
Как ее уменьшить - писал выше, тут важно найти баланс между качеством и временем на ревью.
Что тоже является отдельной задачей, повышающей когнитивную нагрузку на разработчика)))

#ai #postgresql

Почему PostgreSQL 19 не вышел в сентябре и каким боком тут AI?

Октябрь уж наступил, а постгреса всё нет! Последние пять лет мажорные версии Постгреса аккуратно выходили в сентябре. Как часы — у меня это всегда вызывало восхищение.

В этом году будет задержка, причем часть новых фич будто в спешке откатывают. А в блоге Snowlake (облачная дата-платформа) появилась статья, примерно следующего содержания.

Мол, PostgreSQL 19 не выйдет в привычный осенний срок и задержится на недели, а возможно, и на месяцы. Главная причина в том, что в ходе беты откатили много крупных функций (53 отката против примерно 44 у PG18), а другие ещё серьёзно перерабатываются. Большинство откатов вызваны ошибками в дизайне, неверными результатами запросов или проблемами совместимости, обнаруженными при ревью уже после коммита. Отличие от прошлых лет, по её словам, в том, что откаты пришлись на поздний этап и затронули громкие функции вроде графовых запросов SQL/PGQ и GROUP BY ALL. Значительную роль сыграли ИИ: инструменты помогают находить баги и готовить воспроизводимые тест-кейсы, а исправления слишком велики, чтобы успеть к релизу.

Томаш Вондра, один из коммиттеров PostgreSQL, написал блестящий ответный пост, в котором оспаривает утверждение из блога Snowflake, будто функции Postgres 19 откатывают из-за того, что ИИ-инструменты находят в них сложные ошибки. Автор считает, что неверное определение причины мешает решить настоящую проблему.

Проанализировав историю предыдущих откатов, Томаш замечает (и приводит даже графики), что в целом количество откатов не то чтобы какое-то необычное, но необычно то, когда именно они произошли. Обычно откаты происходят сразу после апрельской “заморозки” релизной ветки для нового функционала, а в этом цикле почти ничего не происходило вплоть до резкого всплеска в сентябре.

Изучив все 12 недавних откатов и обсуждения в почтовых рассылках, только 4 случая можно отнести к «ИИ» или «возможно ИИ». Большинство же откатов вызваны обычными ревью от людей, а также большим количеством исправлений после коммита. В чем же дело? Автор считает, что AI виноват, но иначе: разработчики в 2026м году были “завалены” исправлениями по отчётам об уязвимостях (CVE). Число CVE резко выросло в 2026м: 5 в прошлом году против 44 в этом, и большая часть из них найдена конечно с помощью ИИ. Опытные разработчики заняты исправлениями безопасности, и на обычное ревью в период стабилизации не хватает сил.

Вондра считает это примером «инверсии ИИ», и это эффект известный всем мейнтейнерам популярных открытых проектов. Раньше чтобы прислать патч или ревью, человеку нужно было разобраться в коде, компромиссах и сценариях использования и сформулировать мнение, связно, используя верхнюю голову. Это естественным образом ограничивало нагрузку на опытных мейнтейнеров и отсеивало немотивированных участников. ИИ кардинально ломает этот баланс: правдоподобно выглядящий патч, ревью или отчёт об ошибке теперь можно сгенерировать почти даром, но проверять его всё равно должен человек, причём самый опытный и самый занятый. Инверсия состоит в том, что затраты сместились со стороны автора на сторону мейнтейнера.

Сообщения об уязвимостях создавать стало дёшево, но разбирать и исправлять их приходится тем же немногочисленным опытным разработчикам. У них не остаётся времени на обычное ревью во время стабилизации, поэтому проблемы всплыли поздно и привели к волне откатов в сентябре.

PostgreSQL в Devhands | что за Рыбак | Devhands AI Club

🔥 Ten týpek je prostě borec (этот чувак — просто молодец)
👍 Ну, за мейнтейнеров