Чем нам конкретно поможет AI?

В данном случае я говорю про помощь в разработке.
Уже писал про написание, а главное поддержание актуальности в документации https://t.me/javaKotlinDevOps/565

Теперь пришло время поговорить про другую важную штуку - TDD.
Что это - Test Driven Development - я думаю знают все.
Знают, но не используют.
Почему?

Особенно хочу подчеркнуть один момент.
С кем бы я не говорил на эту тему - общаясь по работе или на собесах - никто не сказал: "Да фигня этот ваш TDD".
Все знают, все пробовали, но никто не применяет на работе.
Почему?

Ответ видится таким.
Есть задача. Есть ограниченное время. Которое можно потратить на проектирование, кодирование, тесты, отладку, документирование.
Есть такой закон с немного странным названием - закон Паркинсона.
Он гласит: «Работа заполняет всё время, отведённое на неё».
И он применим в ИТ) Увы(

Так вот - что в первую очередь будет выкинуто, чтобы успеть вовремя?
Очевидно документирование и тесты. А оптимизировать тесты (и документацию) проще, если они запланированы на самый конец. И прощай TDD(
Да, все понимают, что тесты - это хороший способ документировать код, это помощь при будущих рефакторингах, это сетка, предотвращающая сползание в легаси.
А TDD - способ гарантировано иметь тесты и тестируемое Java API.
Но ... нет времени.
А далее сервис медленно, но верно превращается в легаси.
Вспоминается грустный анекдот: "... А чё тут думать! Трясти надо!"

К чему я веду?
AI уже берет на себя большУю часть кодирования. AI быстро пишет код.
AI не лень писать тесты.
Точнее как - конечно же лень, любая LLM модель натренирована на получение быстрого результата, это экономика.
Но вопрос решается правильным промтом (контекстом или скилом если быть точным).
И режимом рассуждений (reasoning), предотвращающим забывание агентом правил игры.
Собственно, уже есть фреймворки, например, упомянутый мной https://t.me/javaKotlinDevOps/589 superpowers, в котором TDD встроен как обязательная часть процесса разработки:
brainstorm-планирование-TDD-ревью-commit.

Итог: документирование и TDD - две вещи, которые разработка с AI перемещает из области "надо, но мы не успеваем" в базовую практику.

#ai #tdd #agile #documentation

И вдогонку про superpowers.

Вроде полезная штука для снижения хаоса в разработке с AI.
Уменьшения галлюцинаций. Шаг влево, шаг вправо - стой, стрелять буду)

Но как обычно бывает есть нюанс(
На сильных моделях (ака Claude Sonnet+) все работает идеально.
Процесс идет по шагам brainstorming -> plans -> TDD в subagents -> review (двойное - каждого шага и общее) -> вливание в основную ветку.
И после каждого этапа commit, что тоже очень даже полезно.
Процент прохождения по workflow близок к 100%.

Но... на сильных моделях и так все неплохо работает, даже без workflow.

А вот на слабых (ака Qwen Code 3, Deepseek 4 Flash) процесс сходит с рельс.
Т.е. запускаем brainstorming - он может не перейти к планированию, а сразу написать TODO и пойти писать код.
Запустилось таки планирование - он может спросить: "переходить ли к TDD в субагенте или в основном потоке", но потом забить на ответ и ... снова пойти писать код.
И закоммитить пройденные шаги забудет.
Про то, чтобы по мере необходимости подключались другие скилы из superpowers (продвинутая отладка например) и речи не идет.

А ведь как раз на слабой модели порядок очень нужен.

Причина тут понятна, их по сути две:
1) superpowers писали и отлаживали на сильных моделях
2) слабые модели, особенно без ризонинга (но и с ризонингом тоже) теряют правила, заданные в контексте.
При сжатии контекста, да и просто по мере его заполнения.
Любая модель к моменту заполнения допустимого контекста начинает галлюцинировать, а слабые - сильнее.

Пример. В конце загруженного в контекст скила writing-plans написано:

...
After saving the plan, offer execution choice:

**"Plan complete and saved to `docs/superpowers/plans/<filename>.md`. Two execution options:**
**1. Subagent-Driven (recommended)** - I dispatch a fresh subagent per task, review between tasks, fast iteration
**2. Inline Execution** - Execute tasks in this session using executing-plans, batch execution with checkpoints

**Which approach?"**

**If Subagent-Driven chosen:**
- **REQUIRED SUB-SKILL:** Use superpowers:subagent-driven-development
- Fresh subagent per task + two-stage review
...

А к моменту окончания планирования агент это уже забыл(
Ризонинг помогает, он по сути связывает рассуждения агента в цепочку.
Но и с ним рано или поздно модель забывает о workflow.

Что же делать?

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

Альтернативные варианты:
- больше императивного наклонения в скилах (ОБЯЗАТЕЛЬНО вызови, НИКОГДА не переходи...)
- уменьшение размера обвязки в контексте до минимума
- загрузка скила using-superpowers (используй superpowers всегда) при старте сессии
не работают.

Скорее всего заработает запрет на переход к неправильному этапу через хуки (PreToolUse, сохранение состояния на диски), но видится, что это уже не AI агент, а state machine получится.

Загрузка информации о superpowers при старте сессии, кстати, автоматически настраивается при установке расширения\плагина.
Причем происходит двойная загрузка - и через хук, и через файл контекста (AGENTS.md) внутри расширения.
Т.е. проблема забывчивости присутствует с любыми моделями, даже сильными.
По хорошему же должно быть так - описания всех скилов есть в контексте, модель вызовет их в подходящий момент.
Скил-напоминалка в теории не нужен. А по факту нужен, и по моему опыту проблему решает.

#ai

Вместо этого поста я мог бы просто дать вот эту ссылку https://github.com/affaan-m/ECC/tree/main/skills
И порекомендовать медленно промотать содержимое страницы, обращая внимание на назначение скилов.

Но все же прокомментирую)

Первый набор скилов по ссылке выше:
- accessibility
- article-writing
- benchmark-methodology
- brand-discovery
- content-engine
- cost-tracking
- design-system
- healthcare-phi-compliance
- investor-materials
- scientific-thinking-literature-review
- seo

Что у них общего?
При чем тут разработка вообще?

А вот второй набор:
- android-clean-architecture
- angular-developer
- codebase-onboarding
- cpp-coding-standards
- django-tdd
- frontend-patterns
- golang-patterns
- java-coding-standards
- jpa-patterns
- kotlin-coroutines-flows
- kubernetes-patterns
- perl-patterns
- python-patterns
- quarkus-tdd
- rust-patterns
- springboot-patterns

Да, у skill есть прогрессивное раскрытие - вначале загружается frontmatter - заголовок, потом все остальное.
Но держать в контексте 250+ скилов - такое себе.
А еще там есть команды и субагенты)))
И хуки https://github.com/affaan-m/ECC/tree/main/hooks.

Тут проблема даже в другом - как выбрать необходимое среди 250 скилов?
Я вижу вариант - брать только то, что кто-то тестировал или по знакомым словам - java, kotlin, spring.
Вроде как в выборе должен помочь скил ecc-guide, но мне не помог(
Авторы в readme рекомендуют скопировать только нужное, да.
Но... зачем собирать такой "божественный репозиторий"?
Если ограничений на тематику нет - то сколько там будет скилов через год? 1000?

При этом судя по названию скилов, число звезд репозитория и по тому факту, что авторы выиграли в хакатоне Claude - полезные штуки там есть.
Та же /code-review команда мне понравилась.

Выглядят интересно хуки:
Strategic compact: Suggests manual /compact at logical intervals.
Git push reminder: Reminds to review changes before git push
Pre-commit quality check: linter (JS, Python, Go), validates commit message format, поиск секретов.
Quality Gate after file edit: автоформат, как в IDEA, тоже только для JS, Python, Go
Сonfig protection: запрет на редактирование конфига линтера.

И одна интересный, но спорный хук: Fact Forcing gate.
Не заметить его сложно, т.к. на каждое редактирование файла будет просьба к агенту предоставить факты:
- какие файлы проекта зависят от текущего (imports)
- какие публичные API меняются
- формат изменяемых файлом внешних данных
- исходный запрос пользователя
Идея в том, что собрав эту информацию агент должен сам себе задать вопрос - все ли правильно он делает?
Такая более продвинутая версия вопроса - "ты уверен?"
Срабатывает на первое редактирование файла в сессии, создание нового, а также на выполнение деструктивных команд.
Последнее так не решается, от деструктивных команд нужно защищаться на уровне репозитория git\прав доступа, но пусть будет.
Замедляет работу, очевидно, но возможно польза есть, наблюдаю.

Итого: интересная штука, но ребята, зачем вы плагин в помойку превратили??? Они не для этого.

P.S. Что-то не верится, что все это люди накодили)
P.P.S. Как они это поддерживать собираются?

#ai #harness

Похвалю Claude.

1) у них есть страница состояния сервиса https://status.claude.com/
2) см. скрин - они пишут историю изменения статуса по проблеме
3) можно подписаться на обновления

Такая штука вполне могла бы стать стандартом для веб-сервисов

P.S. И да, Claude упал)

В AI разработке только и разговоров что об evals)

Что это за зверь такой?

По сути это приемочные тесты, наличие которых - базовое отличие разработки с AI от вайб-кодинга.
Что это на практике?

Если речь про архитектуру и аналитику:
1) проверки формата полученного артефакта - структура файлов, структура разделов внутри,
2) наличие обязательных элементов
3) единообразие терминов
4) ограничение по размеру
5) банально правильная нумерация разделов и ссылок

Если речь про разработку - сразу стоит подсветить важный нюанс.
Агент сам пишет тесты и даже следует TDD (см. предыдущие серии)
И поэтому рассматривать наличие тестов как eval - неправильно, мы их содержимым особо не управляем.
Но при этом тесты - лучшие eval.
Поэтому в самой постановке задачи должны быть проверяемые требования, которые превратятся в генерируемые агентом тесты.
unit или интеграционные - не критично, зависит от уровня, на котором можно проверить работу фичи.
И вот наличие таких приемочных тестов и их прохождение - это уже evals.

Также evals - это успешные проверки линтеров (Checkstyle к примеру) и внешних статических анализаторов кода (SonarQube, Checkmarx, ...).
Сюда же процент покрытия тестами нового кода из SonarQube.
С линтерами есть важный момент - агент в теории может поменять их настройки. Это запрещается через хуки, есть такой хук в ECC плагине https://t.me/javaKotlinDevOps/610
Можно втащить к себе в проект как часть плагина или просто позаимствовать адаптировав под свои файлы настроек.

Еще в качестве evals могут выступать:
- запрет на использование тех или иных библиотек\классов (по всему проекту или в отдельных модулях)
- запрет циклических ссылок (spring beans, ArchUnit)
- запрет на "ломающие" изменения в API или БД
- наличие JavaDoc в определенных местах
- требования к SQL скриптам, например, наличие CREATE INDEX CONCURRENTLY
- время выполнения вызова
...
В общем все, что выполняется достаточно быстро и без сложных интеграций, имеет смысл сделать evals и проверять пораньше.
Ну и один из самых важных evals - соответствие реализации постановке.
В целом все это уже должно было проверяться в CI pipeline с одним исключением, о котором ниже.

Как оформить evals? Как и все остальное - в виде скила.
И тут еще один важный нюанс.
Любую проверку можно выполнить 3 способами:
- запуск кода (тест или shell скрипт)
- просьба сделать проверку агенту
- запуск нового CLI агента в headless режиме

Всегда, когда это технически возможно, стоит использовать первый вариант.
Почему?
AI все-таки по природе своей ленив - любит быстро достигать результата.
Т.е. на явную просьбу что-то проверить в скиле он может сказать: "все ок"- ничего не проверяя. Или даже написать - проверь сам.
Да, он может "подшаманить" скрипт проверки, чтобы пройти дальше.
С последним нужно бороться хуками с запретом на редактирование.
А с первым как раз помогает "хардкод" проверки.
А еще вызов LLM всегда дороже по времени.

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

И вот как раз возможность проверки кода LLM моделью и есть важный бонус, которого ранее не было в CI pipeline.
Но, повторюсь, использовать с осторожностью)

У кого был опыт написания evals для агента - делитесь, что еще можно проверить?

#ai #harness #ai_agents

Почему в Python "неправильная" документация.

Если посмотреть библиотечный Python код, то там можно увидеть вот такое:

class IntervalArray(IntervalMixin, ExtensionArray):
"""
Pandas array for interval data that are closed on the same side.


Или такое:

@classmethod
def _validate(cls, left, right, dtype: IntervalDtype) -> None:
"""
Verify that the IntervalArray is valid.

Что-то к так с документацией, да?)
Зачем питонисты решили сделать все наоборот - комменты после кода???
До кода же логичнее - вначале читаешь доки, потом если надо смотришь код?

Не от балды, нет.
Интерпретатор при загрузке модуля читает первое выражение в теле класса/функции/метода и, если это строковый литерал, помещает его в атрибут ___doc___ соответствующего объекта. Работает принцип convention over configuration.

Также документация выводится с помощью метода help(obj) - если надо прямо в коде. Или через рефлексию - inspect. Или с помощью CLI утилиты pydoc.
Описывается формат документации стандартом PEP 257. Т.е. все продумано.

Причём поля класса документируются точно также для единообразия. Хотя на них стройная система, описанная выше рушится.
И появляется интересный нюанс - если по привычке писать документацию к полям в JavaDoc стиле, то она сопоставится с другим полем)

Мне конечно привычнее JavaDoc стиль, но признаю красоту идеи с автоматическим обогащением метаданных сущности документацией, причём средствами языка.

P. S. Как я обратил на это внимание? Один агент написал документацию в формате JavaDoc, другой на ревью заметил, что это не по стандарту Python)

#lang #python #java #conv_over_conf

Расширим AI агента?)
Я про extension, они же plugins.

По сути это способ упаковки обвязки - скилов, команд, субагентов, промтов, хуков и MCP серверов.

Единого стандарта нет. Да что там, названия даже единого нет) Но делает плагин плагином по сути один файлик с метаданными. Структура папок задается в этом файле. Поэтому совместимость обеспечивается созданием N таких файликов под каждого агента.

Есть ещё нюансы по возможному содержимому. Рассмотрим на примере большой тройки агентов - Claude Code, Codex, Gemini CLI.
Скилы, MCP, хуки разрешают все.
У Codex нет субагентов.
Возможность упаковать файл контекста (AGENTS.md) есть только у Gemini CLI и его наследников.
А вот у Claude куча уникальных возможностей:
1) можно упаковать скрипты, которые будут добавлены в PATH для команд плагина,
2) добавить monitors https://code.claude.com/docs/ru/plugins-reference#monitors - интересная штука для наблюдения за внешним процессом, например, через логи, и выдачи сигналов в агента
3) указать тему. Да, у AI агентов тоже есть темы.
4) добавить LSP сервера (Language Server Protocol). По сути это протокол для работы с standalone AST парсером. Агент шлёт кусок кода и задачу, LSP сервер парсит код и возвращает ответ.

Может возникнуть вопрос - а как внутрь расширения запихнуть MCP сервер, это же не промт, а Node.js или Python пакет? Есть такие штуки, как npx (uvx) - скачивают и запускают пакет без инсталляции.

Но вернётся к главному - зачем использовать плагины?
1) единица деплоя для распространения связанного набора компонентов.
2) единый набор компонентов для нескольких проектов, например, всех проектов на Java
3) пакетное включение/выключение компонентов агента одним ключом командной строки
4) кладём все плагины в git - получаем версионирование своего harness. Если захотеть - всегда можно понять с какой обвязкой написана та или иная строчка кода

Итог: использую сторонние (superpowers), создаю свои и всем рекомендую

#ai #ai_agents

Пару слов про хуки в 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