На тестах отлично всё находит. Учитывая что катофф у моделей обычно 12 месяцев назад - то даже искать в инете ничего не нужно. Все популярные тулзы уже есть.
Благодаря принципам из статьи, цвет ручки, которым написан код будет еще более правильный.
Насчет написания тулчейна правда не уверен, что это так уж нужно. Я скормил агенту статью (до точки, где упоминались репы, чтоб он не пошел тупо в них и не скопировал). дал такой промпт :
у тебя есть lsp pyright, у тебя есть ast-grep, и есть ccc. так же у тебя есть python, ты можешь использовать pandas или какую-то другую библиотеку для работы с кодом как с кодом/смысловыми блоками а не просто как с текстом. теперь проведи мне анализ качества и поддерживаемости кода и архитектуры с использованием этих и других подобных метрик и использованием этих и других инструментов, которые есть в наличии. сделай анализ этого компонента https://github.com/garuda-tunnel/router/tree/main/kube/image/ipt-server
Получил такое заключение.
ipt_server (Python) — анализ качества кода и архитектуры
Какие инструменты реально использовал агент Честный список (по содержимому сохранённого скрипта docs/artifacts/ipt_server_analyze.py + bash-запуски):
Инструмент Зачем Python ast (stdlib) Парсинг исходников, обход ClassDef, Import, ImportFrom, разрешение относительных импортов, оценка MRO-глубины классов radon (cc_visit, mi_visit, raw.analyze) Цикломатическая сложность по функциям, Maintainability Index по файлам, SLOC (строки кода без пустых/комментариев) networkx Граф зависимостей модулей: in_degree/out_degree (fan_in/fan_out), betweenness_centrality, simple_cycles (детект циклов импортов), edge density pandas Агрегации, сортировки top-N, экспорт в CSV pyright Запущен отдельно через bash для статической типизации (244 диагностики, отфильтровано до 58 в production-коде) pathlib.rglob + ручные exclude-фильтры Поиск .py-файлов в дереве Не использовал (из того, что я ему предлагал):
ccc (cocoindex-индекс) — обошёлся без семантического поиска, файлы нашёл через rglob ast-grep — не понадобился, для количественных метрик хватило stdlib ast Это разумно: для quantitative analysis ast+radon+networkx достаточны и точнее (структурный обход), а ccc/ast-grep сильнее в смысловом поиске и поиске паттернов — нам это было не нужно.
Объём анализа Корень: kube/image/ipt-server/ 32 файла, 3 203 SLOC, 821 единиц CC, 34 класса в 14 модулях Исключены: tests/, powerdns_test/, dev/, scripts/, helm-чарт-дубликаты, worktree-зеркало
Методика (зафиксированные допущения) scale = min(1, sloc/5000) = 0.6406 k = 0.5 (штраф за дисбаланс) Граф зависимостей — на уровне модулей; per-class fan_in/fan_out наследуют значения своего модуля (это огрубление — см. §9) depth — статический обход MRO, внешний базовый класс считается за +1 Нормализация min-max по проекту; coupling — edge-density графа с потолком 0.30
Итоговые цифры Метрика Значение Из чего складывается RP 40.14 Peak=48.24, Base=27.99, max_cc=24, p90_cc=7.7, density=25.63 OP 31.16 coupling_density=0.0494, avg_class_score=40.95 Score 75.79 штраф = 4.49 Вердикт умеренный перекос в RP, OP слегка повышен давление сконцентрировано в 3 файлах, один структурный «pivot» (Config) Не катастрофа на таком размере, но заметно выше уровня «чисто» (<25). Главное — длинный хвост: max_cc=24 против p90=7.7, то есть проблема не размазана, а сидит в горстке толстых функций.
Худшие места Топ файлов по сложности Файл SLOC total CC max CC density MI Config.py 366 134 14 36.6 30.9 Router.py 471 127 20 27.0 25.9 (единственный «B» по MI) tasks/nexthop_monitor.py 343 100 24 29.2 35.1 nftables/nftables.py 274 74 8 27.0 45.7 ipt_server/main.py 366 64 8 17.5 46.2 Топ функций по CC Файл Функция CC tasks/nexthop_monitor.py tick (строка 252) 24 tasks/nexthopmonitor.py resolvedirect_router_nexthop (154) 23 tasks/interface_monitor.py monitor_interfaces (83) 21 Router.py Router.on_a_record (483) 20 Router.py Router.add_route (153) 18 tasks/nexthop_monitor.py findrouter_owning_address (55) 17 Config.py MySettings.parse_routes (435) 14 Router.py Router._cleanup_expired_routes (28) 14 11 из 15 худших функций — в трёх файлах: Router.py, tasks/nexthop_monitor.py, tasks/interface_monitor.py.
Топ классов по class_score Структурный pivot — Config.py: 14 Pydantic-моделей, цепочка наследования глубины 3 (BaseRoute → NetRoute/DomainRoute/CountryRoute), модуль импортируется 5 другими (fan_in=5). Класс-оценки 68–80. Дальше идут хабы по fan_out: Router.Router (52, fan_out=8) и PdnsRuntimeConfig (56, fanout=9).
Граф зависимостей 32 узла, 49 рёбер, плотность 0.0494 (разрежённый) 2 кластера циклов: Router ↔ Config ↔ route ↔ ipt_server.state (4 проекции одного четырёхугольника) rule_resolvers ↔ Config (обратная связь через Pydantic-валидатор)
Диагноз — три источника давления Router.py — MI 25.9, один класс с fan_out=8, сидит в импорт-цикле. Самый крупный одиночный драйвер RP. tasks/nexthop_monitor.py — два гигантских async-хэндлера (CC 24 и 23), которые внутри одного тела делают и классификацию, и сравнение, и сайд-эффекты. Пин-фактор max_cc. Config.py + legacy-модули верхнего уровня — pivot для OP. 14 моделей в одном файле с fan_in=5; весь кластер (Router.py, route.py, rule_resolvers.py, …) живёт вне пакета ipt_server/ и подгружается через рантайм-хак sys.path.
Что починить в первую очередь (3 вещи с максимальным leverage) Разобрать жирные async-хэндлеры: nexthop_monitor.py::_tick (CC 24), resolvedirect_router_nexthop (CC 23), interface_monitor.py::monitor_interfaces (CC 21), Router.on_a_record (CC 20) → на pure-функции без сайд-эффектов. Снижает max_cc до ≤17, Peak падает на ~10 пунктов → RP ≈ 33. Разбить Config.py на подпакет config/: base.py, routes.py, rules.py, route_health.py, settings.py. Партиционирует унаследованный fan_in=5, снижает avg_class_score. Переложить legacy-модули в пакет ipt_server/ и убрать PACKAGEROOT.append(…) в main.py:38-40. Ломает цикловой кластер, чинит все 6 reportMissingImports, разблокирует Optional-narrowing для большинства из 37 pyright-ошибок. Ожидаемый Score после всех трёх: ≈ 50 (RP ≈ 30, OP ≈ 22)
Когда устройство заходит в сеть, то z2m его джойнит по квиркам. Итог - устройство показывается джойненым, но само оно в это не верит и может выйти само.
Вторая проблема, если устройство теряет сеть на 10-15 минут, то оно может начать джойн заново для поиска новой сети либо лучшего роутера.
Современные модели блистательно овладели искусством мимикрии. Они генерируют убедительный код, пишут складные тексты, набрасывают тесты и с непоколебимой уверенностью могут убедить человека, что работа почти закончена. Проблема в том, что «выглядит как рабочий код» и «работает на проде» — это две непересекающиеся вселенные.
Если попросить зеленые тесты, агент с радостью соберет вам зеленую гирлянду из моков, которая не проверяет ровным счетом ничего. Если попросить "чтобы не падало", он услужливо обернет всё в один гигантский try/catch. В этом нет злого умысла. Это просто бездушная исполнительность. Поэтому хорошее качество в AI-разработке не возникает от удачного промпта — оно выковывается жестким процессом. Надежда — плохая инженерная стратегия.
Здесь кроется важный трюк: если сказать агенту «вот функция, напиши для нее автотест», вы получите вменяемый результат с вероятностью 10–30%. Но если добавить в пайплайн независимого агента-аудитора с задачей: «Проверь, реально ли этот автотест качественно проверяет функцию, и напиши замечания», а потом вернуть этот фидбек первому кодеру со словами «чисти баги» — за 2–3 итерации код скует форму крепкого мидла.
По опыту на сетях более серьезного размера (200+) результаты следующие : 1. Используем только стек EFR. Он гораздо гибче (и дальше будет понятно почему это важно). 2. Расположение координатора - в какой-то мере важно, но не совсем так. Координатору важно, чтоб рядом с ним было 2-3 хороших роутера, чтоб всё не шло на координатор. Но с другой стороны, если рядом с координатором стоит только один роутер (у меня так было - координатор в щитке, там же стоит счетчик) - роутер может стать единственным next-hop координатора и весь трафик тогда пойдет через него, если роутер так себе, то это приведет к проблемам. 3. binding и спаривание. С кем вы спарили устройство не влияет на то с кем устройство будет работать. через 15-30 минут сеть перестраивается и устройство может выбрать любой parent router. Но, если вы настроите биндинг с желаемым роутером - совсем не обязательно "по делу", можно какой-нибудь genBasic биндить, то тем самым повысите вероятность, что parent будет тот который хотите. 4. Память и прошивки. Современные железки - очень мощные и могут держать большие таблицы. Но прошивки для этих железок такие, буд-то авторы прошивок сетей больше чем на 15-20 устройств не видели. Берите прошивку для EFR и подгоняйте под ваши размеры сети. Например так : https://github.com/AlexMKX/silabs-firmware-builder/blob/sonoff-zigbee-dongle-e-mega-router/manifests/sonoff/sonoff_zbdonglee_mega_router.yaml 5. Репитеры. Мантры вроде : Лампочки IKEA - хорошие репитеры, поставьте больше мощных репитеров - не больше чем мантры. Репитеры - нужны хорошие и это факт. Хорошие репитеры это не какие-то лампочки/розетки правильных брендов. Хороший репитер - это тот же ZB DongleE или SMLight с прошивкой под вашу сеть (в большинстве случаев просто с мощной прошивкой).
Диагностика сети. Даже в хорошо спроектированной сети кто-то будет дурить и ломать всю сеть. Может быть из-за брака. Возьмите хорошего агента (GPT/Opus) включите дебаг логи в z2m. Пусть сеть поработает, выделите проблемы которые вам мешают жить и отправьте его в логи разобраться - какой перент портит всю картину.
Когда команда делает по правилам то и людям и агентам просто.
По правилам это :
Наличие докстрингов, наличие аналитики в текстовом формате в не только в головах, наличие понятных регламентов разработки. Наличие документации. Соответствующее комментирование коммитов и мров. Наличие сваггера. Наличие описания инфры. Наличие кодстайловых документов.
Мы обычно ленимся с этим, в итоге да - мешкам приходится дергать тимлидов, продуктоводов и они кое как справляются.
Когда у агента есть все написанное выше, промпт в духе "почини тикет из жиры T12335, раскати его на стейдж и проверь e2e" работает прекрасно.
Вот кстати еще немножко бонусов использования агентов : стандартизация. Сейчас кунг-фу при работе с агентами не только "что-то получить", но и получить это максимально эффективно - минимум токенов и максимально быстро. А это значит - минимум велосипедов где они не нужны. Минимум отсебятины.
У нас правило, в т.ч. в инфре - агент не должен рыскать и искать кишки. все кишки должны быть там где агент их ожидает (если это не нарушает best practices)
Причем, тут вопрос даже не столько и не только в агенте. В конце концов - вот на примере, берем нового человека, ему надо metrics-server (что бы это ни было) найти/посмотреть в этих ваших кубернетиксах. Что он сделает? Он пойдет в stackoverflow, и поищет - а где эта хрень должна быть. Ну и пойдет искать в kube-system и будет тратить оплачиваемое время на повторные поиски. В случае с агентом - это опять же гораздо ярче становится - он же под рукой, у него моментальный фидбек-луп. Человек может не сказать, что оно не там, может не сказать, что долго искал. Тут-то в чатике сразу видно - тыкнулся туда, тыкнулся сюда - наконец-то нашел - вывод : нужно сделать, чтоб тыкался по минимуму. Люди так же будут меньше тыкаться если что.
Я неверно выразился ) многие пишут : агент начинает генерить отсебятину. код становится как франкенштейн - где-то ооп, где-то функции, где-то CamelCase где-то snake_case. ну и прочие суеверия. В этом случае я всегда задаю вопрос - ЧЕМ ЭТО ОТЛИЧАЕТСЯ ОТ НОВОГО ЧЕЛОВЕКА НА ПРОЕКТЕ? Обычно, начинается - ну ему коллеги расскажут и т.д. Код и процесс должен быть документирован, если проект уйдет в прод, будет работать и т.д. а через год надо будет поправить - НИКТО УЖЕ НИКОМУ НИЧЕГО НЕ РАССКАЖЕТ. А если документировать - какая разница, кто будет ему следовать кожмешок или модель?
От себя могу сказать, что благодаря быстрому feedback loop с агентом мы гораздо быстрее обучаемся и сейчас, благодаря опыту с агентами - мои задачи в жире для коллег гораздо более точные и эффективные. Т.к. натренировался на агентах и этих тренировок было на порядок больше и они были более плотные по времени, чем если бы я это делал с людьми.
уже утащил.
Модель сама разберется что ей нужно.
https://github.com/GFN-CIS/global-rules/blob/main/code-health-check.md#step-2--tooling-discovery-do-not-use-a-hardcoded-list
На тестах отлично всё находит. Учитывая что катофф у моделей обычно 12 месяцев назад - то даже искать в инете ничего не нужно. Все популярные тулзы уже есть.
Отличная статья! Спасибо, многое утащу себе сюда https://github.com/GFN-CIS/global-rules/blob/main/code.md.
Благодаря принципам из статьи, цвет ручки, которым написан код будет еще более правильный.
Насчет написания тулчейна правда не уверен, что это так уж нужно.
Я скормил агенту статью (до точки, где упоминались репы, чтоб он не пошел тупо в них и не скопировал).
дал такой промпт :
у тебя есть lsp pyright, у тебя есть ast-grep, и есть ccc. так же у тебя есть python, ты можешь использовать pandas или какую-то другую библиотеку для работы с кодом как с кодом/смысловыми блоками а не просто как с текстом. теперь проведи мне анализ качества и поддерживаемости кода и архитектуры с использованием этих и других подобных метрик и использованием этих и других инструментов, которые есть в наличии. сделай анализ этого компонентаhttps://github.com/garuda-tunnel/router/tree/main/kube/image/ipt-serverПолучил такое заключение.
Что смешно на сайте РКН насчитал около 15 нарушений от отработки персональных данных до биометрических.
Их задача написать требования и дать публичные разъяснения.
А договариваться с законами физики и здравым смыслом не их задача, а тех кто по закону обязан требования исполнять.
Удалите. Не всем кто читает хабр это стоит видеть 🤣
Loki2. С помощью его предшественника в 90-х утащили исходники sunos из их офиса
Реджойны бывают это нормально.
Когда устройство заходит в сеть, то z2m его джойнит по квиркам. Итог - устройство показывается джойненым, но само оно в это не верит и может выйти само.
Вторая проблема, если устройство теряет сеть на 10-15 минут, то оно может начать джойн заново для поиска новой сети либо лучшего роутера.
Тут детально расписано.
https://github.com/AlexMKX/ai-sdlc/blob/master/10-practice.md
А тут лекарство
https://github.com/GFN-CIS/global-rules/blob/main/testing.md
Там проблема с джойном начинается. Тк на джойн пакеты жёсткие тайминги. Поэтому все и пишут - джойнть лучше возле координатора.
Потом работать должно. Вот правда лаги жуткие.
Это к сожалению так не работает.
Современные модели блистательно овладели искусством мимикрии. Они генерируют убедительный код, пишут складные тексты, набрасывают тесты и с непоколебимой уверенностью могут убедить человека, что работа почти закончена. Проблема в том, что «выглядит как рабочий код» и «работает на проде» — это две непересекающиеся вселенные.
Если попросить зеленые тесты, агент с радостью соберет вам зеленую гирлянду из моков, которая не проверяет ровным счетом ничего. Если попросить "чтобы не падало", он услужливо обернет всё в один гигантский
try/catch. В этом нет злого умысла. Это просто бездушная исполнительность. Поэтому хорошее качество в AI-разработке не возникает от удачного промпта — оно выковывается жестким процессом. Надежда — плохая инженерная стратегия.Здесь кроется важный трюк: если сказать агенту «вот функция, напиши для нее автотест», вы получите вменяемый результат с вероятностью 10–30%. Но если добавить в пайплайн независимого агента-аудитора с задачей: «Проверь, реально ли этот автотест качественно проверяет функцию, и напиши замечания», а потом вернуть этот фидбек первому кодеру со словами «чисти баги» — за 2–3 итерации код скует форму крепкого мидла.
По опыту на сетях более серьезного размера (200+) результаты следующие :
1. Используем только стек EFR. Он гораздо гибче (и дальше будет понятно почему это важно).
2. Расположение координатора - в какой-то мере важно, но не совсем так. Координатору важно, чтоб рядом с ним было 2-3 хороших роутера, чтоб всё не шло на координатор. Но с другой стороны, если рядом с координатором стоит только один роутер (у меня так было - координатор в щитке, там же стоит счетчик) - роутер может стать единственным next-hop координатора и весь трафик тогда пойдет через него, если роутер так себе, то это приведет к проблемам.
3. binding и спаривание. С кем вы спарили устройство не влияет на то с кем устройство будет работать. через 15-30 минут сеть перестраивается и устройство может выбрать любой parent router. Но, если вы настроите биндинг с желаемым роутером - совсем не обязательно "по делу", можно какой-нибудь genBasic биндить, то тем самым повысите вероятность, что parent будет тот который хотите.
4. Память и прошивки. Современные железки - очень мощные и могут держать большие таблицы. Но прошивки для этих железок такие, буд-то авторы прошивок сетей больше чем на 15-20 устройств не видели. Берите прошивку для EFR и подгоняйте под ваши размеры сети. Например так : https://github.com/AlexMKX/silabs-firmware-builder/blob/sonoff-zigbee-dongle-e-mega-router/manifests/sonoff/sonoff_zbdonglee_mega_router.yaml
5. Репитеры. Мантры вроде : Лампочки IKEA - хорошие репитеры, поставьте больше мощных репитеров - не больше чем мантры. Репитеры - нужны хорошие и это факт. Хорошие репитеры это не какие-то лампочки/розетки правильных брендов. Хороший репитер - это тот же ZB DongleE или SMLight с прошивкой под вашу сеть (в большинстве случаев просто с мощной прошивкой).
Диагностика сети. Даже в хорошо спроектированной сети кто-то будет дурить и ломать всю сеть. Может быть из-за брака. Возьмите хорошего агента (GPT/Opus) включите дебаг логи в z2m. Пусть сеть поработает, выделите проблемы которые вам мешают жить и отправьте его в логи разобраться - какой перент портит всю картину.
Когда команда делает по правилам то и людям и агентам просто.
По правилам это :
Наличие докстрингов, наличие аналитики в текстовом формате в не только в головах, наличие понятных регламентов разработки. Наличие документации. Соответствующее комментирование коммитов и мров. Наличие сваггера. Наличие описания инфры. Наличие кодстайловых документов.
Мы обычно ленимся с этим, в итоге да - мешкам приходится дергать тимлидов, продуктоводов и они кое как справляются.
Когда у агента есть все написанное выше, промпт в духе "почини тикет из жиры T12335, раскати его на стейдж и проверь e2e" работает прекрасно.
Дуров! Обнови сервера. А то они деградировали.
Ровно то же самое и с той же темой (про почту) написал хертлинг в 2014-м. Только там Клода звали Elope.
Пока что все развивается ровно так как описано у него 12 лет назад.
Вот кстати еще немножко бонусов использования агентов : стандартизация.
Сейчас кунг-фу при работе с агентами не только "что-то получить", но и получить это максимально эффективно - минимум токенов и максимально быстро.
А это значит - минимум велосипедов где они не нужны. Минимум отсебятины.
У нас правило, в т.ч. в инфре - агент не должен рыскать и искать кишки. все кишки должны быть там где агент их ожидает (если это не нарушает best practices)
Причем, тут вопрос даже не столько и не только в агенте. В конце концов - вот на примере, берем нового человека, ему надо metrics-server (что бы это ни было) найти/посмотреть в этих ваших кубернетиксах. Что он сделает? Он пойдет в stackoverflow, и поищет - а где эта хрень должна быть. Ну и пойдет искать в kube-system и будет тратить оплачиваемое время на повторные поиски.
В случае с агентом - это опять же гораздо ярче становится - он же под рукой, у него моментальный фидбек-луп. Человек может не сказать, что оно не там, может не сказать, что долго искал. Тут-то в чатике сразу видно - тыкнулся туда, тыкнулся сюда - наконец-то нашел - вывод : нужно сделать, чтоб тыкался по минимуму. Люди так же будут меньше тыкаться если что.
Я не думаю что будет AgentOS, я скорее верю в AgentSwarm - т.к. MCP это будут новые апишки например.
Я неверно выразился )
многие пишут : агент начинает генерить отсебятину. код становится как франкенштейн - где-то ооп, где-то функции, где-то CamelCase где-то snake_case. ну и прочие суеверия.
В этом случае я всегда задаю вопрос - ЧЕМ ЭТО ОТЛИЧАЕТСЯ ОТ НОВОГО ЧЕЛОВЕКА НА ПРОЕКТЕ?
Обычно, начинается - ну ему коллеги расскажут и т.д.
Код и процесс должен быть документирован, если проект уйдет в прод, будет работать и т.д. а через год надо будет поправить - НИКТО УЖЕ НИКОМУ НИЧЕГО НЕ РАССКАЖЕТ.
А если документировать - какая разница, кто будет ему следовать кожмешок или модель?
От себя могу сказать, что благодаря быстрому feedback loop с агентом мы гораздо быстрее обучаемся и сейчас, благодаря опыту с агентами - мои задачи в жире для коллег гораздо более точные и эффективные. Т.к. натренировался на агентах и этих тренировок было на порядок больше и они были более плотные по времени, чем если бы я это делал с людьми.
security-assessor agent?
чем это отличается от нового человека на проекте? :)
Тот самый