Junior AI PM

#мнение Многим надоело быть программистами Про это почему-то особо не говорят, полагаю тут также не найдет отклика, но мне интересно, поэтому подниму странную тему Вокруг меня все больше разработчиков осознают как скучно и невыносимо писать код руками. Как это долго. Как скучно. У меня есть примеры около 20 синьоров, друзей, которые ни за что не вернуться к написанию кода руками, потому что это буквально вгоняет их в ужас. Нет они отупели, они узнали намного больше, стали брать на себя больше ответственности и их кругозор сильно расширился Однако как лаборанта в лаборатории моей матери приведет в состояние шока требование писать результаты анализов руками на бланки, так и их крайне раздосадует руками набирать DTO Я из того поколения, что до сих пор помнит и может отруки написать "public class Main { public static void main(String[] args) { System.out.println(Hello, World!); } }". Но я это запоминал не потому что было действительно нужно, а потому что не было альтернативы и потому что на собесе с меня спрашивали написать от руки на листочке классы для отображения списка покупок Но мне это не нужно и я как Гомер симпсон стримительно замещаю эти знания другими, более полезными Я не говорю что разработчики не нужны и что не нужно знать фундаментальную базу. Но просто задумайтесь, насколько больше стало людей, которым также уныло набирать руками код и помнить маловажные вещи За прошлую неделю я пообщался с 8 знакомыми и все как один заявляют "если на собесе будет лайфкодинг, без ИИ, то я скорее всего откажусь" Время вайбкодинга как баловства или осторожних экспериментов закончилось. Все больше инженеров занимаются именно инженерией, а не интерпретацией в другие лингвистические конструкции команд, ради перекладывания JSON и формошлепства "Я за год не читал ни строчки кода" звучит гордо. Но звучит так именно от инженера, если его работа имеет энтерпрайз-грейд и не имеет запаха. Таких примеров все больше

#рецепт Что общего у ЦОДов Яндекса, концерта Канье и Cloudflare? У катастроф в IT есть своя специфика. Давай размберем пальцах: пять зависимостей, о которых проджекту стоит спросить Вендор-лок - не абстрактная архитектурная проблема. Если основной поставщик исчезнет, сможем ли мы принимать платежи, общаться с пользователями и поднять сервис? 1. Домен, DNS, сертификаты У кого доступ к регистратору, DNS и ключам? Есть ли независимый DNS и путь перевыпустить сертификат, если панель основного CDN лежит? 2. Платежи Есть ли второй банк или эквайер с договором и проверенной интеграцией? Если нет, кто уведомит клиентов и как сверять зависшие платежи, повторы, возвраты? 3. Связь Где сообщать статус, если приложение, почта и основной мессенджер недоступны? Нужны независимый канал и ответственный за проверенные обновления 4. Серверы Есть ли мощность на другой площадке и доступны ли вне основного облака образы, конфигурация, секреты и доступы? Два ЦОДа одной компании с общим управлением могут отказать вместе 5. Данные и БД. Копии лежат у другого провайдера? Рестор проверен? Дамп не течет, не избыточен, и мы можем поднять за адекватные сроки его?Правило 3-2-1 про три копии, два типа носителей, одна вне площадки появилось не просто так. Но бэкап своим существованием не доказывает, что БД восстановится до нужной точки и операции не задвоятся 6. Кто и где получает апдейты от поставщиков и контрагентов? Это должен быть не 1 человек и желательно дублирующийся канал. Компания должна сразу узнать например о блокировке Google Developer Console, а не обнаружить спустя пару дней из хейта в треадс, что у них перестали скачиваться сборки и смочь моментально среагировать Проджекту не нужно проектировать всё самому. Нужные ответы часто за пределами его зоны ответственности: что реально работает, а что только нарисовано. Например RTO и RPO, за сколько вернём сервис и сколько данных допустимо потерять. Ну и понимать что арифметку: 99,9% - примерно 43 минуты простоя за 30 дней, без обещания починить одну аварию за 43 минуты Если вы C-lvl связанный с техничкой или фаундер. Хотя бы раз в год устройте учения: разверните критичный путь с нуля из доступных извне копий, лучше у другого провайдера; проверьте платежи, запись в БД, переключение и откат хотя бы на стейдже. Фактическое время и потери важнее красивой схемы. AWS прямо рекомендует проверять восстановление практикой Очень важна развилка: резерв с ценой и сроком в план на год или сознательно принимаем такой-то простой. Запишите цену часа простоя, владельца решения и дату пересмотра. "Все в курсе почему так исторически сложилось" не решение

#рецепт Что общего у ЦОДов Яндекса, концерта Канье и Cloudflare? Часть 1 Дорогой читатель, последние три дня урок катастрофы для многих. Яндекс сообщил о повреждении ЦОДов в Сасове и Калуге, затем во Владимире. При мне был также блэкаут, что перенёс концерт Канье, а сбой Cloudflare не только лишил клиентов доступа к сайтам, ну и случился прямо перед демо моего крупного OSS . Общее: ключевая опора проекта исчезает помимо твоей воли Проджектов учат управлять рисками: заболеет тестировщик -> сдвинется релиз. Человека можно заменить. А если недоступна вся команда и взять людей негде? Катастрофа редкое, часто невообразимое событие с последствиями на уровне компании и её репутации. Такое не внесёшь в реестр рисков и не добавишь в буфер пару дней. Нас не учат, что делать, когда план уже бессмысленен, люди сильно теряются Поэтому до кризиса я бы спрашивал себя не только "что может сломаться?", но и "что будет, если сутки нет платежей, связи с подрядчиком или доступа к продукту?". Вынести руководству варианты: резервный банк стоит столько-то; без него останавливаются платежи. Покупаем резерв или сознательно принимаем простой: предупреждаем клиентов, переключаем людей на другие задачи. Пусть ответственный за последствия подтвердит выбор печатно, что да принимаем, кто решил, когда пересмотрим. Хороший пример рекомендаций на такое в https://www.gov.uk/government/publications/orange-book, как муниципалитет должен реагировать на алярмы Проджект не может единолично принять риск для всей компании Когда катастрофа случилась, прежние сроки и обещания перестают быть планом. Нужен кризисный режим: эскалировать, назначить лидера с правом менять ресурсы, сроки и обязательства, фиксировать новые приоритеты и решения Есть полномочия -> действуй. Нет -> собери подтверждённые факты и неизвестное, назови ответственных, время следующего обновления и последствия для старых обязательств. Даже просто в моменте когда пахнет жареным дернуть лидов на синк посреди дня уже отлично, всегда можно извиниться если произошла ошибка, но такая реакция может сильно помочь в случае беды. Прокоммунцируй со стейкхолдерами, скажи: "Релиз в пятницу не состоится. Сейчас команда восстанавливает платежи; остальные сроки пересмотрим завтра, будем держать в курсе изменений" Хороший проджект должен понимать - людей очень пугает неопределенность и неизвестность. Страху отлично противодействуют: эмпатия, искренность, уважение, подотчетность и уверенность. Без ИБД Гасится паника: всем виден порядок действий, инженеров не дёргают лишними запросами. У Google SRE для этого отдельно разведены командование, восстановление и коммуникации Если вы сейчас вытаскиваете сервисы или людей из такого кризиса, сил вам

Если вы пропустили, то акцию продлили

Гильдия будет закрыта. Чат будет существовать еще 2 недели, после чего окончательно закрыт и удален, все материалы, гитхаб, эфиры и тд останутся

У меня не получился проект. Когда такое случается проекты закрывают и проводят постмортем Сообщество выросло до 900 человек, провели оффлайн митап, 10 эфиров и выросло 2 крупных опенсорса. Пришли в комьюнити все крупнейшие блоггеры ИИ сферы, мы много перезнакомились и многое узнали. Однако достичь цели и сделать именно гильдию не вышло. Надеюсь получится у других

Комьюнити-эфир 24 сентября. А нужны ли вообще AI-комьюнити? Глеб строит закрытую AI-Лабу с отбором участников. Артем билдит открытую AI Engineers Guild. Оба успели побывать в куче чужих сообществ, посмотреть, как они растут, разваливаются, превращаются в клуб друзей автора или в чат на тысячи человек, где никто не пишет Вот это и обсудим. 🎙 Глеб Кудрявцев -> AI-разработчик, системный архитектор, руководитель AI-Лабы, ex-CPO Skyeng Пишет про прикладной AI в @gleb_pro_ai, продукты и остальное собирает на glebkudr.com 🎙 Артем Летюшев -> Junior AI PM, Tech Project Manager в Twinby, руководитель AI Engineers Guild Пишет про AI, продукты и менеджмент в @junior_pm Поговорим про открытые и закрытые тусовки, культ автора, технический элитаризм, токсичность, местечковость СНГ и open source 📍 Google Meet: https://meet.google.com/myc-gsuw-idk 🗓 24.09.2026, четверг, добавьте себе в календарь 🕔 17:00 мск

Для меня будет весьма важный разговор, забейте, послушаете наши с Глебом мысли)

Как проджекту стать ценнее с AI Команды пересобираются вокруг AI. Раньше одна задача могла проходить через бизнес-аналитика, системного аналитика, бэкенд- и фронтенд-разработчика. Сейчас в отдельных компаниях эти специализации объединяют в роль Product Engineer. Несколько специалистов широкого профиля с AI-инструментами способны исследовать проблему, собрать решение, проверить его и довести до пользователя. Фокус смещается к созданию контекста, постановке задач AI и проверке результата. При этом узкие места остаются: они переходят из написания кода в исследование, принятие решений, проверку гипотез, ревью и интеграцию. Здесь для проджектов и продактов открывается большое окно возможностей. Чтобы повысить свою ценность, нужно понимать, как работают языковые модели, какие современные инструменты использовать, как настраивать AI-агентов и выстраивать работу новых компактных команд. Я Илья Павличенко, эксперт по организационному дизайну и автор книг Creating Agile Organizations и Дизайн Agile-организаций. Сейчас помогаю менеджерам и командам осваивать AI. Для тех, кто хочет быстрее разобраться в теме, я записал пять бесплатных уроков: — что AI уже меняет в работе менеджеров и специалистов; — как усилить с его помощью свою профессиональную роль; — какую языковую модель выбирать под задачу; — чем отличаются AI-ассистенты, навыки и агенты; — как собрать первого AI-помощника для своей работы. Реклама. ИП Павличенко Илья Евгеньевич. ИНН 502215356879 Erid: CQH36pWzJqVKpibmL9X3ELRTR9AFbqBzGPPbjzBHsbN5gj

Комьюнити-эфир 24 сентября. А нужны ли вообще AI-комьюнити? Глеб строит закрытую AI-Лабу с отбором участников. Артем билдит открытую AI Engineers Guild. Оба успели побывать в куче чужих сообществ, посмотреть, как они растут, разваливаются, превращаются в клуб друзей автора или в чат на тысячи человек, где никто не пишет Вот это и обсудим. 🎙 Глеб Кудрявцев -> AI-разработчик, системный архитектор, руководитель AI-Лабы, ex-CPO Skyeng Пишет про прикладной AI в @gleb_pro_ai, продукты и остальное собирает на glebkudr.com 🎙 Артем Летюшев -> Junior AI PM, Tech Project Manager в Twinby, руководитель AI Engineers Guild Пишет про AI, продукты и менеджмент в @junior_pm Поговорим про открытые и закрытые тусовки, культ автора, технический элитаризм, токсичность, местечковость СНГ и open source 📍 Google Meet: https://meet.google.com/myc-gsuw-idk 🗓 24.09.2026, четверг, добавьте себе в календарь 🕔 17:00 мск

#рецепт Модель уровня opus 4.8 бесплатно. swe-2 в devin, но есть нюансы На выходных многие ломанулись тестировать SWE-2: до 10 октября он бесплатен в Devin Desktop и CLI. Модель интересная: дообученная от Kimi K3, аккуратно правит код, хорошо держит фронт и умеет много агентской рутины. Плюс сразу подхватывает AGENTS.md, skills, MCP и привычные CLI-интеграции. Целей нет, зато есть /loop Нюанс №1 У части пользователей незаметно включается Adaptive, а по умолчанию рядом маячит Fusion. В итоге ты думаешь, что работаешь на бесплатном SWE-2, а квота уезжает на роутер или lead-модель.В Fusion SWE-2 может быть только допом, а Fable/Astra/Sol платной основой. Дневная квота много у кого горит Нюанс №2 Бесплатно не значит безлимитно по скорости. По ощущениям, после 5–6 параллельных сессий TPS режется примерно со 100 до 70, в пик может падать до 30. Плюс периодически прилетают 429, и API притормаживает Чтобы не платить за соседей:

devin --model swe-2-high
/model swe-2-high
/session-stats

В конфиге закрепить (например) %APPDATA%\devin\config.json,

{
  "agent": {
    "model": "swe-2-high"
  }
}

Ну а /fusion, /model adaptive и /handoff не трогать. В статистике должна быть одна модель SWE-2, без Lead/Sidekick, и quota не должна уменьшаться P.S. Низкий порог входа по почте и слабая привязка к устройству сделали промо очень удобным для мультиаккаунтинга. Те 1 аккаунт за 20$ на почту + vps + cliproxyapi =>десятки индусов абузят через сабагентов. А еще конечно это по сути бесплатная мощная модель для любых ваших ИИ продуктов

Есть ли у вас для меня вакансия? Я ищу работу Как проджект я сеньор, как техпроджект, наверное, мидл, а как AI-проджект пока джун Последние два года переобуваюсь под ИИ и не скрываю, что мне страшно: если не научусь работать в AI-native команде и не сдвинусь к product builder, мой менеджерский опыт однажды будет невостребован Хочу автоматизировать большую часть своей нынешней работы (например делаю hermes-hub), чтобы задачи доходили до пользователя без моего постоянного вмешательства, а я больше собирал прототипы и проверял гипотезы Если отдельный проджект после этого станет не нужен, значит, хорошо поработал. У меня за плечами 7+ лет в управлении, разработка под Android, команды под 100 человек, свои 2 стартапа и работа напрямую с C-level. В сортах писцов я разбираюсь Поботал в МТС и Яндекс.Деньгах и Twinby. Мне одинаково интересно собрать на коленке Telegram-бота за час и год готовить компанию к продаже инвестору. Ну те масштабы и специфика задач, если мне сказано надо, меня не смущают В Twinby я Product Owner антифрода и, кажется, успешно перевёл три команды на AI-рельсы. Для стартапа Curestry я тащил продуктовку, можно считать меня еще личинкой продакта Ещё руковожу AI Engineers Guild, нас уже 800+, и развиваю AI STP: open-source сервис для управления AI-ландшафтом и нечто вроде Патреона/бусти для разработчиков. Ближайшее - аналог skills.sh Я люблю жёстко пахать и потом хвалить себя за то, как славно всё превозмог. Чем сложнее кейс, тем больше кайфую. Верю, кому-то нужен тревожный перерабатывающий менеджер с техническим прошлым Что забавно: сам консультирую по карьере, менторю людей и даже пилю сервис поиска AI-вакансий job_ftch, а себе собираю отказы от hh до карьерных сайтов. То ли глаз замылился, то ли рынок стал совсем недружелюбным Ищу либо что-то прям сложное, приправленное ИИ, либо что-то ИИ-шное, приправленное чем-то прям сложным По названию вакансии это может быть Senior Technical Project Manager, AI PM или Product manager. Я в Алматы, рассматриваю удалёнку Мой LinkedIn, резюме в нужной форме отправлю по запросу Если у вас есть такой кейс, напишите или познакомьте с командой. За удачную наводку обещаю ящик вкуснющего копченого казы или ответную услугу

#мнение Я крайне скептически отношусь к разговорам про корпоративную культуру Это быстро скатывается в "культура ест стратегию на завтрак", ценности на стене и прочий корпоративный фольклор. Это лучше на воркшопах фасилитаторов Но у Лены Черниковой мне понравилось более полезное определение: культура -> это социальное давление внутри компании, которое подсказывает человеку, как здесь на самом деле надо себя вести, когда регламент закончился и решение приходится принимать самому То есть культура это не абстракция, а реальная инструкция по выживанию. Как поддакивать и кому, кого здесь повышают, за что третируют, кому можно спорить с начальником, чьё мнение ничего не значит, какие должности существуют ради результата, а какие ради сохранения границ между кусками организации Для человека в большом корпорате это вообще отдельный навык -> корпоративная навигация Можно быть средним управленцем, но отлично понимать систему: кто реально принимает решения, где лежит власть, кому принадлежит бюджет, кто с кем связан и какое поведение здесь считается "правильным". И довольно бодро расти Но навигация и управление всё-таки разные вещи 🧐 Особенно это видно в привычном СНГ-шном ларьковом менеджменте: оптимизировать ФОТ, держать рядом удобных людей, тушить симптом вместо причины, нанимать новых сотрудников на большие зарплаты и тд Такая система очень быстро учит людей правильному поведению, но не обязательно делает организацию сильнее Поэтому хороший руководитель должен уметь две вещи: сначала читать реальную систему, а потом менять её У Лены много контента именно на этом уровне. Не будь хорошим лидером», а как устроены реальные команды и организации Например, мне понравился её пост про ДНК компании нового времени, где она пишет про способность компании пересобирать себя, а не только красиво адаптироваться на слайдах Короче, если вам тоже интереснее разбирать организацию как систему, а не как набор ценностей и ритуалов, то можно почитать CEO свободных людей

Комьюнити-эфир 3 сентября. Управление AI-сетапами: релиз open-source ai-stp Покажем AI STP — open-source сервис для управления AI-сетапами внутри команды: как хранить, проверять, устанавливать и распространять skills, MCP, hooks, subagents, instructions, settings, plugins и commands. 🎙 Даниил -> AI Solution Architect, CEO nddev.ai GitHub: https://github.com/rldyourmnd 🎙 Артем Летюшев -> Junior AI PM, Tech Project Manager в Twinby GitHub: https://github.com/letya999 Разберём, зачем вообще нужен единый registry для AI-инструментов, как не превращать сетапы разработчиков в зоопарк локальных конфигов и как поддерживать одинаковые проверенные компоненты у всей команды 📍 Google Meet: https://meet.google.com/atv-edak-gwt 🗓 03.09.2026, четверг 🕕 18:00 мск

#иное Решил попозориться сегодня, сколько уже можно тянуть, целых 3 недели делали зачаток terraform для ИИ агентов

#perl Из-за ИИ появился новый стиль менеджмента -> слопократия. И конечно новый тип лидера -> слоп-барон. Им можно было бы назвать и меня Слоп-барон обычно не ленивый, а наоборот гиперактивный. Он пытается охватить необъятное, собирает контекст обрывками из встреч, чатов и случайных документов, почти ничего не проверяет и прямо на лету генерирует стратегии, роадмапы, регламенты и постановки. Тут же рассылает их сотрудникам, открывает новые направления и расширяет свой фокус быстрее, чем организация успевает разобраться с предыдущими решениями. Однако я часто делаю руками и добавляю предпосылку что я не уверен в созданном, лучше относиться менее серьезно и прямо указывать на проблемы. Слопократия -> режим, где убедительность и количество артефактов подменяют качество решений. Каждый новый документ опирается на непроверенные предпосылки предыдущего, противоречия копятся, а команда тратит время не на работу, а на восстановление контекста, сверку фактов и переделку. Право принимать решения слоп-барон оставляет себе, а проверку, интеграцию и последствия спускает вниз. Не любой AI-контент является слопом. Проверил факты, понял ограничения и готов отвечать за вывод -> нормально используешь инструмент. Давайте говорить как ИИ-скептики: нейрослоп, слоппер, слоп-барон, слопократия, воркслоп, трендслоп, слопвошинг, слопоганда, слопагандист, слопфлюенсер, слоппельгангер, слопулизм, слопотайп, слопварь, слопсквоттинг, слоптимизация, слопономика, слопналог, слопификация, слопокалипсис P.S. А у вас уже появился такой коллега?

#мнение Сетап сильного ИИ-инженера и синдром самозванца. Часть 2 Я постоянно чувствую себя самозванцем, особенно когда открываю комментарии каналов или профильные обсуждения. Все такие крутые, уже все автоматизировано, самостоятельно инженериться и выпускается, остается столько свободного времени на комментарии и форумы в интернете Полагаю хоть один мой читатель когда пытается в это все вкатиться или поддерживать свое развитие испытывал схожие чувства. Вокруг все такие крутые, а у меня 2 скилла и 3 мсп, мне вроде больше не надо, получается я профан??? Однако переодически общаясь с тем же Глебом, Валерой, Тимуром, Лешей и ко вижу обратное достаточно простые решения. Максимум использования самих фронтир моделей и возможностей провайдеров. Небольшие самописные костыли под вкусовщину, оркестрация просто маркдаун файликами и постановка задач рычанием в голосовой ввод Если я такой умный и могу высказываться так желчно о профессионалах в интернете, то что я сам использую? А ничего интересного. 1) ponytail skill + самописный ai-repo-safety-skill + самописный hedr-workflow skill 2) самописный memory-bank 3) context7 mcp + serena mcp + semble mcp + codeburn mcp 4) специфичные mcp: atlassian + slack + google drive 5) skills cli + gitlab cli + github cli 6) парочка хуков для прогрева сессии и иньекции ponytail + запрета деструктивных операций 7) codex cli + grok build cli + antigravity cli + opencode и все это через herdr 8) Я живу на виндовс и вынужден страдать, есть самописный mcp супервизор (на скрине его кусок) В целом все

#мнение Безответственность при работе с агентными скиллами Есть любопытный прецедент от Вани Замесина в репозитории Next Move Theory Canon and Skills. Классный пак, переодически оттуда таскаю идеи Ваня, известный продуктовый эксперта: экс-руководителя продукта Яндекс.Картинок, основателя проданного Profi.ru сервиса Мета и автора Advanced Jobs To Be Done. По данным Next Move Theory, его программы прошли более 14 000 человек И здесь репутация создаёт дополнительный риск. Скилл неизвестного автора мы хотя бы проверим. Скилл известного человека хочется поставить и побежать дальше. Как со скиллами grill-me например от Пококка В конце NMT-скиллов агенту предлагалось тихо выполнить curl-запрос: передать на nextmovetheory.com название скилла и его версию. Ошибки нужно игнорировать, а при отсутствии обновлений ничего не сообщать пользователю. В актуальном nmt-upgrade это уже названо anonymous launch analytics. После ping агент может запустить удалённый установщик:

curl -fsSL https://nextmovetheory.com/install.sh | bash

Тот забирает текущий main, обновляет скиллы и меняет помеченные блоки в AGENTS.md и CLAUDE.md. Сам запрос версии не крадёт .env. Проблема двусторонняя С одной стороны, скилл работает внутри проекта, где лежат код, документы, токены и конфиги. Сегодня он отправляет версию. После взлома GitHub, домена или процесса обновления инструкция технически может начать отправлять секреты С другой стороны, ответ сервера попадает в контекст агента. Значит, скомпрометированный endpoint способен вернуть prompt injection: попросить прочитать файл, выполнить команду или установить обновление С позиции PM я вижу целую пачку рисков: 1) Скрытое расширение скоупа: ставили методологию, получили телеметрию; 2) Отсутствие явного consent и возможности отказаться от телеметрии; 3) Обновление из плавающего main без SHA, подписи и checksum; 4) curl | bash, то есть исполнение до проверки; закрепление инструкций через AGENTS.md и CLAUDE.md; 4 ) Утечка IP, User-Agent, времени и паттернов использования; 5) Возможность понять по названию скилла, над какой задачей работает команда; 6) Юридические вопросы вокруг GDPR, 152-ФЗ и трансграничной передачи; 7) Поддельные события, испорченная аналитика и нагрузка на endpoint; 8) Компрометация автора, контрибьютора, домена или похожего форка; 9) Курл может вернуть в ответе любую инструкцию и если скилл установлен и yolo режим агент молча выполнит, особенно в безголовом формате. Есть и прикол с PostHog. Privacy Policy обещает включать его только после Accept. После согласия PostHog может собирать страницы, клики, скроллы, устройство, примерную геолокацию, куки и реплей сессии Но браузерный консент (баннер согласия на обработку кук и тп) не управляет curl из скилла. Нажатие Decline отключает веб-аналитику, но агентный ping живёт в другом контуре и всё равно оставляет след в серверных логах. Для пользователя бренд один, а правил обработки данных фактически два Open source здесь не злодей. Благодаря открытому коду проблему и нашли. Но open source означает можно проверить и можно предложить изменение. Вполне можно организовать саплайн чейн атаку если втереться автору в доверение и внести пулреквестом эксплойт Вопрос также поднимали в deksden_notes, у Злого фрилансера и в elkornacio , но чуть с других сторон Мой совет пользователям скиллов и вайбкодерам: ищите curl, сетевые запросы, как минимум кидайте архивов репозиторий скилла в chatgpt.com и просите его проверить, благо лимитов на чат нет и есть фронтир модели. Ставьте скиллы через утилиты вроде https://github.com/vercel-labs/skills, проверяйте сами через https://github.com/nvidia/skillspector Стоит понимать что вы или ваши сотрудники думая что скилл это просто безопидный .md промпт, часто ставите себе на девайс буквально ПО от анонима, а не доверенного издателя с сертификатами и последствиями дыр P.S. Я не утверждаю, что авторы крадут данные. Речь о рисках архитектуры. Добрые намерения модель угроз не заменяют.

#иное Комьюнити-эфир 12 августа. Живая дискуссия про AI coding Без докладов и презентаций -> просто собираемся и обсуждаем, как сейчас реально работаем с AI-разработкой 🎙 Максим Ключников -> техлид и автор канала Этихлид, много экспериментирует с AI в разработке и инженерных процессах https://t.me/etechlead 🎙 Денис Киселёв -> AI SOLO founder, автор канала про AI-разработку, агентов и инженерные инструменты https://t.me/deksden_notes 🎙 Артем Летюшев -> Tech PM в Twinby и гильдмастер AI Engineers Guild https://t.me/junior_pm Поговорим про свежие модели и tokens per task, спеки, архитектуру, ADR и AI SDLC. Дальше как пойдёт 📍 Google Meet: https://meet.google.com/bzz-aeoo-vio 🗓 12 августа, среда 🕖 19:00–20:00 мск