Пару слов про хуки в AI агентах.

Набор событий у каждого агента свой.
При этом тут тоже идет унификация и базовый набор хуков, кажется, определился:
* PreToolUse
* PostToolUse
* SessionStart
* UserPromptSubmit - начало обработки пользовательского запроса агентом
* Stop - его завершение.
Я про большую тройку (Claude, Codex, Gemini и примкнувшего к ним Qwen Code).
Тут надо отметить, что PreToolUse/PostToolUse вызываются на любой tool, включая вызов bash, редактирование файла и даже TodoWrite.

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

Для чего можно использовать?
Мои варианты:
1) свой механизм разрешений (PreToolUse)
2) блокировка сессии после проверки среды (SessionStart, только у Codex\Claude)
3) подгрузка контекста в сессию, в т.ч. после ее сжатия (SessionStart)
4) телеметрия, аудит (PostToolUse, Stop)
5) валидация промта пользователя (UserPromptSubmit)
6) валидация ответа модели с возможностью его перегенерации (Stop)
7) замена тула при неправильном ответе (PostToolUse)
8) проверка формата данных, например, при записи в файл (PreToolUse)
9) запуск любых линтеров при окончании работы агента (Stop, SubagentStop)
10) запрет на изменение определенных файлов (PreToolUse)
11) просьба агенту обосновать, зачем он выполняет то или иное действие (PreToolUse)
12) запрет на переход к следующему шагу если не выполнены необходимые действия на текущем, реализация state machine (Stop, SubagentStop)
13) вывод информации о текущей сессии, подсказки о сжатии или начале новой (Stop)
14) кэширование результата работы тулов, включая MCP (PreToolUse)
15) обогащение промта пользователя (UserPromptSubmit)
16) независимое хранилище истории диалогов (PostToolUse, Stop)
и наверняка многое другое, что мне не пришло в голову)

В общем мощный механизм.
Можно использовать готовые хуки из плагинов, а также есть поле для их доработки и создания своих.

#ai #ai_agents

Только сейчас понял, что в канале ни разу не встречается аббревиатура SDD.
Казалось бы не встречается, ну и ... ладно, но SDD сейчас "на хайпе", придется рассказать.
Да и TDD был, DDD был, BDD был.
Тем более штука интересная. Я бы даже сказал полезная.

Вначале расшифровка: SDD - Spec Driven Development.
Т.е. в основе разработки лежит спецификация.
Казалось бы - любая команда, которая пишет аналитику уже работает по SDD?
Нет.
Ключевое отличие - спецификация хранится вместе с кодом, версионируется и поддерживается в актуальном состоянии.
По сути развитие подхода Everything as Code (EaC).
Были Infrastructure As Code, была Architecture As Code, теперь добрались до аналитики.
Отдельные вопросы:
- мы храним спеки по отдельным фичам, как их объединять если новая фича - доработка старой? AI агент или человек?
- как получить все аналитику из отдельных фичей? Отдельный скил?

Тут может возникнуть вопрос - канал то про разработку? Сейчас все будет)

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

Третий важный момент - именно спека, лежащая в проекте идет на вход AI агенту как основной артефакт.
Наравне с описанием проекта в контексте (AGENTS.md) и проектными скилами.

Еще полезный побочный эффект: при SDD больше вероятность, что ADR - architecture decision records - будут сохранены рядом с кодом в процессе совместной проработки фичи.
Вообще говоря, ADR как практика появилась еще в 2021 году, автор Майкл Нюгард (Michael Nygard), но ее широкого распространения я не вижу.
История принятия ключевых архитектурных решений часто живет в головах сеньоров, которые их приняли.
И теряется с их уходом. Или просто со временем. Что не есть гуд.

Что еще важно - тема SDD идет в паре с AI разработкой, поэтому неудивительно, что уже есть готовые SDD фреймворки.
Их много, но самые известные - OpenSpec и SpecKit.
И они предлагают разные workflow для работы над фичей. Но об этом в следующей серии.
Сейчас хотел бы отметить, что если спека пишется AI агентом совместно с аналитиком, это требует меньше участия разработчика.
Т.к. агент видит код проекта, знает язык и фреймворки, и что-то может подсказать сам.
Но конечно же не все.

P.S. Еще 22 буквы свободно)))

#ai #dev_workflow

В продолжение предыдущего поста.
Давайте сравним два AI SDD фреймворка - OpenSpec и SpecKit.

Сравнивать будем в первую очередь по составу скилов, которые выстраиваются в линейный workflow по работе над фичей.

OpenSpec - вот базовый вариант:
- /opsx:propose (написание аналитики в составе: proposal, спецификация, дизайн, план)
- /opsx:apply (реализация)
- /opsx:archive (проверка выполнения плана, слияние спек при необходимости, архивация ненужного, перемещение спеки в статус "выполнено")

Просто, всего три шага, после первых двух нужно ревью со стороне человека.

Вот максимально полный вариант:
- /opsx:explore (предварительное исследование, аналог brainstorming в superpowers)
- /opsx:new (создание только proposal.md - документ с секциями "Зачем?", "Что?", "Что меняем?", "Критерий успеха?")
- /opsx:continue 3 раза - создание остальных документов: spec.md (сценарии и требования), design.md (архитектура), tasks.md (план реализации, минимум технических деталей).
- /opsx:apply
- /opsx:verify (ревью реализации)
- /opsx:archive

Тут добавляется брейнштоминг, контроль аналитики по каждому документу отдельно и шаг ревью реализации по трем критериям: полнота, корректность и консистентность с архитектурными (design.md) и code style требованиями.
Т.е. это некий аналог code-review скила, расширенный проверкой соответствия реализации и архитектуры по фиче.

Теперь SpecKit, базовый flow:
/speckit.constitution (некий аналог /init у AI агентов, выполняется один раз)
/speckit.specify (аналитика без архитектуры и плана - spec.md)
/speckit.plan (создается технический план, по сути - архитектура, разбитый на части: contracts\*, data-model.md, plan.md, quickstart.md, research.md)
/speckit.tasks (полный аналог tasks.md)
/speckit.implement (реализация)

Расширенный flow:
/speckit.constitution
/speckit.specify
/speckit.clarify (уточнение задачи, исследования)
/speckit.plan
/speckit.tasks
/speckit.analyze (ревью консистентности аналитики)
/speckit.checklist "что проверяем" (создание чек-листа для проверки реализации в каком-то разрезе: unit tests, security)
/speckit.implement
/speckit.converge (ревью реализации)

Что хочется отметить:
- названия шагов (скилов) не совпадают от слова совсем
- у SpecKit появляется /speckit.constitution, более интерактивный init проекта, позволяющий задать базовые принципы разработки, а кроме того инициализирующий шаблоны, по которым создается аналитика, адаптируя их под текущий проект.
- у SpecKit даже в базовом варианта аналитика создается пошагово с четким разделением на бизнес и техническую части, плюс план.
- набор создаваемых артефактов отличается: совпадают spec.md и tasks.md. У SpecKit файлов больше, т.к. технические документы разделены: API, схема данных, research и собственно архитектура, почему-то названная планом.
- у OpenSpec брейншторминг идет до создания спецификации, у SpecKit - после.
- у SpecKit есть шаг ревью аналитики и шаг создания evals - приемочных чек-листов
- ревью реализации есть у обоих, но OpenSpec пишет замечания и в зависимости от их критичности предлагает сразу исправить, а SpecKit на основе расхождений заводит новые таски
- у OpenSpec есть понятие архивации, которое помечает спеку как выполненную и перемещает ее в архив.

Но как раз на архивации видно ключевое отличие этих фреймворков. В OpenSpec спецификация - это дельта-спецификация.
Что это значит? Что вначале анализируется набор существующих спек в проекте, и для новой сразу же определяется что это - новая фича, изменение или удаление существующей. И на этапе архивации происходит синхронизация - правится или удаляется существующая спецификация, или добавляется новая.
Еще одно отличие - в OpenSpec важной считается только spec.md (сценарии и требования), остальные файлы архивируются - остаются в проекте, но помещаются в папку archive.
У SpecKit такого шага нет, соответственно, слияние аналитики происходит вручную и все создаваемые файлы остаются в папке со спецификацией.

Итог - workflow достаточно сильно отличается, при этом оба соответствуют всем принципам, описанным в предыдущем посте.
У каждого есть плюсы и минусы. OpenSpec проще из коробки и частично берет на себя вопрос упорядочивания фич в проекте. SpecKit заточен на контроль и детализацию.
Я лично использую OpenSpec в связке с superpowers, но об этом в следующей серии.

#ai #ai_harness #dev_workflow

И последнее по SDD. Последнее, но важное.

SDD - это упор на актуальную спецификацию. Т.е. на аналитику.
Из 5-10 шагов по SDD workflow к чистой разработке относится один - /opsx:apply и /speckit.implement соответственно.

Достаточно ли этого?
Для простых фичей, но при этом имеющих свою аналитику - да.
А для более сложных есть superpowers) С TDD, параллельной разработкой в разных worktree, с расширенным код-ревью и отладкой

И в обоих случаях он отлично ложится в workflow, заменяя собой упомянутые выше шаги. И ложась т.об. в середину процесса.

Два нюанса:
1) brainstorming из superpowers в такой схеме становится ненужным и заменяется аналогами из SDD фреймворков
2) writing-plans (из superpowers) нужно оставить, так как это разная детализация.
В SDD таски написаны на уровне аналитика, а writing-plans пишет классы, импорты, тесты, команды запуска скриптов.
По сути из плана, созданного через superpowers, написать код может любой джун. И ему даже скучно будет)
Или самая дешевая модель.

Тогда может возникнуть другой вопрос - а нужен ли план, созданный SDD фреймворком?
В целом не обязателен. Но если он создается одной командой с другими артефактами - можно и оставить. Или подтюнить соответствующий скил.

Еще одно важное замечание. Я встречал случаи, когда superpowers тоже относят к SDD.
Нет, ну формально конечно спека по итогу brainstorming создается, как и план по итогу writing-plans.
Но это спека и план с деталями реализации, т.к. superpowers прям заточен под разработку.
Поэтому на мой взгляд по факту это не SDD фреймворк. Ну или как минимум - не SDD для команд, где есть явная роль аналитика.

И последний момент - нужно ли использовать два фреймворки - OpenSpec + superpowers - в связке?
А точнее когда нужно их использовать?
Ответ в общем очевиден - для достаточно больших фичей, когда в репозитории по итогу разработки фичи должна остаться спецификация. Либо это требование организации, либо решение команды.

#ai #ai_harness #dev_workflow

Небольшая иллюстрация чем отличаются superpowers и OpenSpec на примере артефакта tasks.

OpenSpec, план работ по одной task-е

## 1. Chain и policy

- [ ] 1.1 `data/label_policy.yaml`: добавить `service_id_chain` (дефолт `[service, service.name, app, app.kubernetes.io/name, job]`); загрузчик policy сохраняет порядок, поставляет дефолт при отсутствии поля
- [ ] 1.2 Функция извлечения `extract_service_id(labels, chain) -> (service_id, service_source)` — чистая, ≤N dict-lookup'ов; юнит-тесты: порядок приоритета (`service` бьёт `app`), fallback на `app`/`job`, пустой chain → `('', 'none')`, provenance-значения

superpowers, кусочек плана по той же task-е

### Task 1: Service ID Extraction Chain + Policy

**Files:**
- Create: `src/meta/service_id.py`
- Modify: `data/label_policy.yaml`
...

**Interfaces:**
- Produces: `extract_service_id(labels: dict[str, str], chain: list[str]) -> tuple[str, str]` — returns `(service_id, service_source)`
...

#### Step 1: Add `service_id_chain` to `label_policy.yaml`

- [ ] **Step 1.1: Edit `data/label_policy.yaml`** — append after `max_virtual_series`:

```yaml
# service_id_chain — ordered keys for deriving a metric's service identity
# (T2-22). The first key present in observed labels wins. Chain order:
# intentional instrumentation labels → infra labels → scrape labels.
# Changing the chain requires re-profiling affected metrics + regenerating
# templates (chain is part of the metric-identity contract).
service_id_chain:
- service
- service.name
- app
- app.kubernetes.io/name
- job
```

#### Step 2: Write failing tests for `extract_service_id`

- [ ] **Step 2.1: Create `tests/meta/test_service_id.py` with failing tests:**

```python
"""Unit tests for service_id extraction chain (T2-22)."""
from meta.service_id import extract_service_id

DEFAULT_CHAIN = ["service", "service.name", "app", "app.kubernetes.io/name", "job"]

def test_intentional_key_wins_over_infra():
labels = {"service": "payments", "app": "payments-prod-1"}
sid, src = extract_service_id(labels, DEFAULT_CHAIN)
assert sid == "payments"
assert src == "label:service"
...

ну и далее по TDD.
В плане даже команды запуска тестов и git add\git commit будут.

Детализация мягко говоря сильно отличается)

#ai

compact vs clear

Я снова про AI-шку и две типовые команды у большинства агентов /compact vs /clear.
Первая сжимает контекст, вторая начинает новую сессию.
По сути это два способа борьбы с энтропией - раздутием размера контекста и последующим ухудшением качества ответов агента.
А ухудшается оно по статистике где-то в районе 50% контекста.
Ну и борьбы со стоимостью тоже, если вы сами платите за модель)
Т.к. весь контекст при каждом запросе уходит на сервер, хоть и считается по особому тарифу (cashed).

Если запустить /compact в Claude Code - удивляет (неприятно) скорость его работы. У меня это обычно более минуты, ближе к 2.
Почему так - сжатие стало умным, т.е. вся история сессии скармливается LLM, и она выбирает важное. Можно указать это важное, явно передав текстом /compact "сохрани план работ и архитектурные требования".
Для сжатия похоже используется та же модель, что и сейчас в сессии - по крайней никакой другой информации я не вижу.
Это точно есть в Claude Code, и думаю скоро будет у всех)
К слову, есть готовые хуки, определяющие оптимальную точку для /compact с простой, я бы даже сказал "наивной" реализацией: создается PreToolUse hook для операций Edit|Write, счетчик, как только число вызовов превышает порог (50 по умолчанию) - пишем в контекст рекомендацию вызвать /compact.

Но вернемся к сжатию. Умное - это хорошо, но вместе с этим долгое и более дорогое. Плюс что-то важное все равно может пропасть из контекста.

К чему я веду - /compact видится костылем, помогающим, если вы неправильно декомпозировали задачу (story). Или пошли на поводу у модели, когда она предложила добавить в план работ еще А, Б, С... Решив, что раз это дешево - почему бы не сделать сразу)
А ведь преждевременную оптимизацию и YAGNI никто не отменял.

Итог: навык декомпозиции задач с AI остается таким же важным, как и был без нее. Бейте задачи на части, план работ и текущее состояние храните в файле (а SDD фреймворки так и делают), чаще вызывайте /clear.

#ai #ai_agents

Рубрика: "Полезное из Python"

Как вы думаете, что делает команда: uv run pytest --durations=20 ?

Ответ не очевиден (для меня): выводит 20 наиболее медленных тестов.
Вот так бы было более очевидно: uv run pytest --durations-min=1.0

Второй вопрос: что меня в этом больше всего расстраивает?)

Ответ: то, что ни в Maven, ни в Gradle тестовых плагинах ничего такого нет. Хотя можно легко завайбкодить с помощью AI.
Если быть точным: в Gradle легко, в Maven придется плагин или внешний скрипт писать.

P.S. Еще такой же паттерн использует PostgreSQL - FROM pg_stat_statements
ORDER BY total_exec_time DESC, а еще есть slow query log с фильтрацией по предельной длительности

#python #junit #unit_tests

Я не рассказал про ключевой вопрос по SDD - где находится source of truth?

До сих пор источником правды был код. По понятной причине - именно код работает на ПРОМе, не аналитика. Аналитика лежит в wiki и медленно, но верно расходится с кодом.
Сейчас мы этот разрыв пытаемся убирать, и кладем аналитику поближе к коду.

Но разрыв остается, т.к. LLM при разработке фичи условно правит 3 места:
1) спеки
2) код
3) документацию к коду
Тот факт, что правка идет в одной сессии (на одном контексте) увеличивает вероятность, что все три источника будут одинаковы.
Но не доводит ее до 100%.
А главное - зачем нам три источника?

Сложный вопрос.
Где спека точно нужна?
Спека на входе агента - да, т.е. в течение рабочей сессии.

Нужна ли она далее - вопрос?

Накину аргументы за спецификацию как источник правды:
1) спецификация упрощает совместную работу над фичей для ВП, аналитиков, разработчиков и тестировщиков. Тут наверное не поспоришь, пока в команде есть все эти роли.
Разве что тестировщики сейчас автоматизируются и идут "в код".
2) актуальная спецификация может дать возможность выкинуть код и переписать сервис с нуля. В целом да, но вообще говоря спеку можно вытянуть из кода и JavaDoc.
3) агенту (и человеку) проще дорабатывать проект. Под вопросом - при хорошо структурированном коде и наличии документации там, где она нужна. А еще индексаторы кода есть.

Про минусы я уже сказал - массовое нарушение DRY.
Почему массовое?
Потому что по факту источников больше, чем три. Новый реализуемый алгоритм появляется в:
1) коде
2) тестах
3) JavaDoc
4) spec.md
5) design.md (здесь и далее в терминологии OpenSpec)
6) proposal.md (верхнеуровнево)
7) tasks.md (на своем шаге реализации)
8) в файле с tasks от superpowers.md (при использовании superpowers)
9) AGENTS.md (такое возможно, если алгоритм влияет на требования к остальному коду. или в виде описания алгоритма как комментарий к параметрам вызова сервиса)
10) какой-нибудь скил валидации, проверяющий, что алгоритм вызывается там, где должен вызываться

И если мы поменяли название алгоритма - где его менять? Везде? Или исторические документы не трогаем? А если их кто-то прочитает?
Ясно, что это решается отдельным скилом синхронизации, но что делать с DRY?

Я пока окончательного ответа для себя не нашел, но точно понятно, что дублирование надо уменьшать.

code or not code, вот в чем вопрос?

#ai #ai_agents

Рубрика: "малоизвестные фичи IDEA".

В меню "File" можно найти такой пункт как "Remote Development". Сразу скажу - только в Ultimate версии.
Два основных вопроса - что это и зачем это?

Начнем с первого.
Это клиент-серверная IDEA. На вашем компе поднимается компонент Gateway - тонкий клиент IDEA с идентичным интерфейсом, являющийся, как следует из его названия, шлюзом к серверу.
К серверу можно обращаться по 3 протоколам:
1) ssh - удаленный сервер
2) WSL - для тех, кому нужен полноценный Linux на Windows, как бы странно это не звучало
3) Dev Containers - если нужна изолированная среда локально. Про Dev Containers, к слову, стоит написать отдельно, эта штука менее популярна, чем те же Test Containers.
У Gateway к слову отдельный бинарник и отдельный файл настроек (vmoptions).

Что за сервер?
Это по сути полноценная инсталляция IDEA на Linux. При настройке подключения в родительской IDEA нужно выбрать версию remote IDEA, она должна совпадать с версией на рабочем месте. Там опять же свои настройки (idea.properties и vmoptions). Занимает порядка 3 Гб.
Перед инсталляций будет проверка на системные требования, из важного - минимум 4 Гб ОЗУ должно быть свободно. В вылетающием warning есть слово "рекомендовано", но по факту при несоблюдении этого требования инсталляция падает.
Это логично, т.к. основная работа будет на сервере, при оценке требуемой ОЗУ нужно отталкиваться от ресурсов, требуемых при обычной локальной разработке по вашим проектам.

По функционалу - из того, что заметил работает все. Плагины, рефакторинги, генерация, поиск, переходы между классами, run configurations, встроенные linter-ы (вкладка Problems), полноценная работа с git, консоль (естественно, доступны те консоли, что есть на удаленном сервере)...
Т.к. это разные бинарники с обычной IDEA - это разные окна, причем открыть новое окно Remote Development можно только из основной IDEA или прямым запуском.

Теперь главный вопрос - зачем это нужно?
Для начала зачем нужно было до эры AI - ага, не опять, а снова))):
1) запуск сборки на полноценном Linux если рабочий комп на Win
2) разработка на слабом ноуте - монитор правда все равно нужен нормальный, как и клавиатура с мышью
3) запуск сборки в песочнице (чтобы не ставить серверное ПО на рабочий комп)

Ну а в настоящий момент к этому всему добавляется одно важное применение - запуск AI агента на зарубежном сервере с постоянным IP, без VPN (но с регистрацией), что дает нам:
а) уменьшение вероятности блокировки
б) не нужно постоянно перещелкивать VPN для доступа к ресурсам разработки, к которым нет доступа из-за санкций и\или VPN
в) AI агента можно запуска в yolo режиме (без подтверждений), предварительно настроив запрет force push и удаления master ветки
г) в такой схеме можно вести "non-stop" разработку в 2 режимах: полное погружение (анализ и ревью кода) с компа в IDE и контроль работы агента в остальное время - переписка с агентом с телефона, например, в дороге или на прогулке.
Можно даже голосовухи агенту записывать, если мобильный клиент позволяет)

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

Подводные камни:
а) коннект по ssh, который обычно режут в корпоративной сети
б) местонахождение удаленного сервера стоит синхронизировать с VPN, используемым для оплаты подписки и локального доступа
в) сервер стоит денег, но небольших, сравнимых со стоимостью базовой подписки на AI.

#idea #ai

Минутка удивления способностям AI.

Сегодня при работе с Claude Code и Opus 5 стал замечать одну интересную штуку.

Задача - написать сложный тест. В ответе модели в CLI:

Мутационно проверен — обе попытки «сдать» тест валят его:
- убрать финальный пулл → live metric lost points;
- оставить метрику ingest_enabled=false после apply → onboarded metric is not being pulled after the flip.

Первая версия ассертов, кстати, мутацию пережила (точки новой метрики приходили от backfill'а) — отсюда шаг 4.

Кто из вас включил в CI пайплайн фреймворк для мутационного тестирования (PITest, например)?
Кто пытается сломать свои тесты перед коммитом?
А AI агент делает.
Причем в требованиях к проекту в контексте этого нет - да, позор на мою седую голову)))

P.S. Причем раньше я периодически замечал, что assert-ов в написанных AI тестах не хватает.

P.P.S. В context конечно требования стоит добавить, это часть Evals.

#ai #ai_agents #unit_tests

Агент работает по TDD, но делает ли он это с уважением правильно?

Недавно говорил с коллегой по поводу superpowers и TDD, и возник интересный вопрос.
Формально да, процесс идет по TDD - red-green-refactor - пишется тест, он падает, пишется код, тест зеленеет.
Но становится ли такой код качественнее, ведь LLM всегда может подогнать код под результат?

Давайте посмотрим на основные аргументы в пользу TDD.

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

2) т.к. тесты пишутся до кода, то код гарантированно выставляет более согласованное и более тестируемое API.
Тут TDD помогает, с двумя ремарками:
а) модель может смухлевать и подогнать тесты под существующий код. Как с этим бороться - отдельная тема
б) если говорить про superpowers - он пишет сразу план с тестами и кодом.
Поэтому тот факт, что вначале идет тест, важен, но не так критичен.
AI работает в одной сессии, а при разработке человеком - сессии разные, между написанием кода и тестов могут пройти дни.
А т.к. сроки ограниченны => плохое API остается навсегда.

3) короткий цикл разработки, быстрая обратная связи, как итог - правильная декомпозиция задач.
Это очень важно, и TDD в исполнении AI агента тут помогает собственно AI разработке.
Если подзадачи мелкие - на них проще сделать evals (приемочные тесты), не забыть ничего.
Некоторые задачи можно распараллелить, если агент это поддерживает
И т.об. снизить время ревью человеком и превратить преимущество в скорости кодирования агента в уменьшение Lead Time.
Ремарка - блокер тут не только время ревью, но это оно оказывает существенное влияние.

4) благодаря TDD тесты становятся документацией.
Исходя из моего опыта с superpowers - "из коробки" это не так, нужно дополнительно настраивать контекст, чтобы тесты были читаемы.
И второй ключевой момент - задание evals со стороны разработчика на этапе проектирования.
Именно тесты, являющиеся приемочными - лучшая документация.

Вывод: да, с AI важность TDD меньше, чем без нее.
Но все равно TDD остается полезен если не забывать про evals (приемочные тесты) и донастроить обвязку под читаемость тестов и запрет хаков со стороны модели.
Главные плюсы: тесты как документация на основе заданных evals и короткие контролируемые циклы разработки.
Т.е. само написание тестов до кода тут не так важно, как качество тестов и написание их в одной сессии с кодом.
И да, при таком подходе тесты можно было бы писать после кода в одной сессии. Но зачем?)

#ai #ai_agents #tdd

Рубрика - приколы с AI агентами.
Есть шанс, что станет постоянной.

И сразу преамбула - да, агенты часто смешно косячат. Даже самые сильные, типа Claude Code с Claude моделью.
Но это не значит, что они бесполезны.
Правильный подход - понимать причины этих косяков и нивелировать их правилами в контексте и evals-ами.

Так вот, AI очень любит нарушать принцип DRY - Don't Repeat Yourself.
Вот прямо хлебом не корми.
При создании новой фичи с большой вероятностью там появится копия существующего инфраструктурного кода.
Или даже несколько - в каждом новом классе\файле.

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

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

Что вы думаете?

В скиле эти примеры появились в 3 местах!)))

После моего ревью агент признал косяк, поиронизировал над собой, убрал один дубль и сделал автогенерацию другого из единого источника правды.
Но сам факт...

Что касается причин такого поведения.
Мне видится такая: для LLM дублирование - это сигнал. Сигнал, повышающий важность информации.
Даже есть такая техника промтинга.
Т.е. пока ей явно не скажешь, что это проблема - LLM это проблемой не считает.
Есть еще идеи, почему они так работают?

#ai #ai_agents #dry #ai_fuckup

Сколько на самом деле стоит AI coding agent?

Вот тут интересные цифры сравнения стоимости подписки и доступа по API https://habr.com/ru/news/1046644/

Разрыв конечно впечатляет. Можно сказать, что по подписке нам дают AI практически бесплатно.
Возможно это так, но себестоимость мы не знаем.

Но это не так важно, основной вопрос - не закроют ли подписки, раз это так не выгодно для провайдеров LLM моделей.

На мой взгляд нет. Почему? Конкуренция.
Claude vs ChatGPT vs Gemini vs Grok.
Да, последние двое пока проигрывают, но сдаваться не собираются. И если один из них подписку отменит, то люди уйдут к конкуренту.

Но. Есть же ещё Китай.
Как минимум это Kimi, Qwen, GLM, Deepseek, Minimax.
Это ещё 5 конкурентов. Итого 9. У большинства есть подписки.

В общем - конкуренция - двигатель торговли. Возможно, подписки будут подкручивать - уменьшать лимиты. Но как по мне - отказаться от них не смогут.

Чему лично я буду очень рад)))

P.S. А что насчёт окупаемости? Мне видится, что все оплатят инвесторы - те, кто сейчас покупает акции Anthropic, Tesla и т.д

#ai

Когда я впервые увидел 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