Сколько стоит 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 (этот чувак — просто молодец)
👍 Ну, за мейнтейнеров

Рекомендую отличную статья по оптимизации скорости вставки в БД на примере PostgreSQL https://habr.com/ru/companies/axiomjdk/articles/1010606 .
Виден последовательный, основательный подход.

Я думаю многие откроют для себя что-то новое. Например, unnest.
У меня вообще с ним интересно вышло - примерно с разницей в один день мне AI-шка этот вариант подсказала, а на следующий на статью наткнулся)

Что бы хотелось добавить по своему опыту - есть еще один, достаточно радикальный способ ускорения вставки данных.
Отказаться от их хранения у себя)
Я не шучу.
Примеры:
- считать и сохранять только нужные агрегаты
- вытаскивать только необходимое.
Потенциальный выигрыш может даже превысить тот, что предлагается в статье.

Еще что интересно - на своей инсталляции PostgreSQL, без оптимизаций, и сильно слабее описанной в статье конфигурации, я получил примерно те же 15000 записей в секунду на один поток.

И тема оптимального числа потоков и ее связь с числом ядер и типом диска требует отдельного исследования. RAM как мне видится, особо влиять на запись не должна.

#db #postgresql

G1 - долгая дорога к покорению мира)

Недавно вышла новая Java - 27-я.
Не LTS, изменений не так много, большая часть - мелкие оптимизации. Скорость работы Java - это понятная боль, не зря же появился тот же Rust. Где, кстати, нет Garbage Collector, но это уже другая история.
Так вот. Одно из значимых изменений 27 версии - G1 стал сборщиком мусора по умолчанию.
...
Так, а раньше разве не он был?

Смотрим историю G1.
Появился в Java 6.
Стал выбором по умолчанию в Java 9.
Но ... не для всех.
А только для серверных окружений. Что под этим понимается?
Не менее 2 ядер и 2 Гб памяти, доступных приложению. Т.к. в условиях ограниченных ресурсов Serial GC был эффективнее.
И вот в новой Java 27, вышедшей в сентябре 2026 года, разработчики допилили G1 настолько, что он включается сейчас по умолчанию для любых окружений.
9 лет прошло.
Такой интересный факт.

А выводы такие.
1) Java - это совместимость, это не быстро, и мы про это знаем)
2) Параметры JVM для высоконагруженных приложений лучше задавать явно. И включать в процедуру НТ.

#java #jdk #gc

Еще одно интересное нововведение в Java 27.
Сейчас, благодаря развитию ИИ, тренд на безопасность.
И разработчики JVM решили быть в тренде)

JFR - Java Flight Recorder. Профилировщик - инструмент, сохраняющий набор событий, возникающий в Java приложении, с их таймингом в файл.
Входит в состав OpenJDK, доступен всем.
Казалось бы - при чем тут безопасность?
Вопрос в данных, сохраняемых JFR. Там же могут быть пароли и прочие секреты? Могут.

Так вот, начиная с Java 27 JFR сам маскирует все секреты, которые находит.
Ищет он в следующих местах:
1) jdk.InitialEnvironmentVariable — начальные значения переменных окружения;
2) jdk.InitialSystemProperty — начальные системные свойства, включая информацию о командной строке;
3) jdk.JVMInformation — аргументы запуска JVM и приложения.

Ищет вот такие ключи по умолчанию:
- *api*key*
- *auth*
- *credential*
- *password*
- *private*key*
- *secret*
- *token*
и заменяет в них значения.

Почему по умолчанию?
Можно расширить список ключей для маскирования значений в них через параметр -XX:FlightRecorderOptions:redact-key.
Можно также задать шаблон для значений: -XX:FlightRecorderOptions:redact-argument

Используется glob шаблон, не Regexp.

Как по мне начинание хорошее, облегчает использование JFR на ПРОМ. Благо, накладные расходы у него небольшие.
Не 100% гарантия, но если есть проблема с согласованием от ИБ - должен помочь. Сужает поверхность атаки.

#java #jdk #profilers

Еще одна интересная штука из последних JDK - правда не 27, а 26 - LazyConstants

https://openjdk.org/jeps/526

В чем суть? Вот пример кода - было\стало:

// OLD:
static final OrderController ORDERS = new OrderController();

// NEW:
static final LazyConstant<OrderController> ORDERS = LazyConstant.of(OrderController::new);

или так:

// OLD:
private static volatile OrderController instance;

public static OrderController getInstance() {
  if (instance == null) {
    synchronized (OrderController.class) {
      if (instance == null) {
        instance = new OrderController();
      }
    }
  }
  return instance;
}

Т.е. мы получаем из коробки:
1) ленивую инициализацию - Lazy
2) технический признак константы над формально обычным полем - Constant
3) однократное вычисление значения - как бонус.

Признак константы (@Stable) дает возможность провести различного рода оптимизации для компилятора и JIT.
Работает как с обычными, так и с static полями.

Можно подумать, что это подсмотрено в Kotlin - конструкция by lazy.
В плане boilerplate-less кода - возможно да.
Но у Kotlin это синтаксический сахар, в котором реализована ленивая инициализация и однократное вычисление.
Но нет признака @Stable, по крайней мере на данный момент.

Как по мне - штука полезная. Вспоминается один монолит, в разработке которого я лет 10 назад принимал участие. Монолит был большой, разрабатывало его под сотню человек. И периодически кто-то добавлял в один из классов static поле с тяжелой инициализацией, которая падала при старте из-за того, что нужных ресурсов еще не было.

#java #jvm #lang

Давно не было провокационных постов от Егора Бугаенко на канале, ловите https://youtu.be/JRMnoQvFfKU

С чем хочется поспорить?

Первое и самое главное - не уверен, что AI разработка приведёт к исчезновению документации к коду. Аргумент Егора: раз код сейчас не читает человек, а машина быстро разбирается в любом коде - документация не нужна.
Тут сразу уточнение - я бы расширил понятие документация. Документация для меня это и Java, и тот же Openspec, и любые другие документы по архитектуре.

И я, кстати, вижу в AI чатах мнения, что OpenSpec не нужен. Так вот, если документацию убрать - получаем 2 проблемы:

1) ок, человек не читает код. Но ему все равно нужно что-то читать, если pull request не элементарный. Егор говорит о неких простых артефактах, из которых сразу видна суть изменений. Типа архитектурной схемы в yaml. Хорошо если такая есть, и она описывает все возможные изменения в проекте. Но если это невозможно - вот тебе новая SDD спецификация или дельта в существующую.

2) идея "код содержит всю правду" IMHO утопична. Причем не важно, кто писал этот код. Всегда есть исключения. Всегда есть то, что в код пока (!) не вошло. Намерения пользователя в конце концов. Этому место в документации.

Как по мне основная проблема сейчас - избегать дублирования в документации, делать ее компактной. Чтобы не было - одна и та же мысль есть и в JavaDoc, и ещё в 3 спеках. AI любит дублировать. А идея отказаться от документации вообще красива, но утопична.

Вторая спорная мысль - все PR делают роботы, разговаривать с ними не надо, делаем своих роботов для отсева кривых PR.
С одной стороны все к этому идёт. А с другой - PR появился из-за чьего-то намерения. Намерение остаётся за человеком. Канал для связи с этим человеком все равно нужен, пусть и не в рамках многодневной переписки в PR.

А вот над чем стоит подумать:

1) с увеличением числа изменений master будет ломаться чаще. Нужны правила для агентов по его автоматической починке.

2) большие pull request всегда были болью, останутся они болью и для AI агентов из-за context rot. Надо думать над тем, как автоматически бить задачи на более мелкие, с AI это сделать должно быть легче

3) настройка своего harness для контроля качества кода - это реально большая задача для всех команд на ближайшие годы.

#ai #dev