Когда устройство заходит в сеть, то 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 с агентом мы гораздо быстрее обучаемся и сейчас, благодаря опыту с агентами - мои задачи в жире для коллег гораздо более точные и эффективные. Т.к. натренировался на агентах и этих тренировок было на порядок больше и они были более плотные по времени, чем если бы я это делал с людьми.
Источником власти является фактически законодатель. Законодателем является дума. В думе депутаты.
Депутаты являются избранниками народа. Однако многие ошибочно ставят знак равно между избранниками и представителями. Но все на места расставляет закон, который говорит, что депутат избирается народом но действует ИСХОДЯ ИЗ СВОИХ УБЕЖДЕНИЙ, а не представляет народ. И при этом конечно же избиратели не могут вынести вотум недоверия депутату. Депутата может снять только партия, избиратели не могут.
Поэтому, источником власти в РФ является народ, да. Но это не мы с тобой, анон. Мы не народ. Мы - те, кто финансирует весь этот балаган. По ставке 22%
Их задача написать требования и дать публичные разъяснения.
А договариваться с законами физики и здравым смыслом не их задача, а тех кто по закону обязан требования исполнять.
Удалите. Не всем кто читает хабр это стоит видеть 🤣
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?
чем это отличается от нового человека на проекте? :)
Тот самый
Нет. Агенты, сабагенты, плагины.
Claude code как и codex это не просто умногугль. Llm уже давно составляет около 50% ценности продукта.
То есть депутат боярский снес телеграм ещё осенью. Все верно ?
Текущая система права перевирает конституцию.
Источником власти является фактически законодатель. Законодателем является дума. В думе депутаты.
Депутаты являются избранниками народа. Однако многие ошибочно ставят знак равно между избранниками и представителями. Но все на места расставляет закон, который говорит, что депутат избирается народом но действует ИСХОДЯ ИЗ СВОИХ УБЕЖДЕНИЙ, а не представляет народ. И при этом конечно же избиратели не могут вынести вотум недоверия депутату. Депутата может снять только партия, избиратели не могут.
Поэтому, источником власти в РФ является народ, да. Но это не мы с тобой, анон. Мы не народ. Мы - те, кто финансирует весь этот балаган. По ставке 22%