اکنون در دسترس! پژوهش تلگرام ۲۰۲۵ — مهمترین بینشهای سال 
Marat @ Predictable.Team
رفتن به کانال در Telegram
Привет! Я Марат, Agile Coach в финтехе на 50 команд в ядре банка. В этом канале пишу про процессную культуру и метрики в айти и не только, фасилитацию, бизнес, изменения и системный подход. Если вы в Уфе, приходите ко мне в ufaitcoworking.ru :)
نمایش بیشترکشور مشخص نشده استدسته بندی مشخص نشده است
340
مشترکین
+124 ساعت
+287 روز
+3330 روز
آرشیو پست ها
Prosci в AI Adoption Guide 2026 называет четыре главные причины сопротивления AI.
Потихоньку закрываю темы, которые не успеваю озвучить на конференциях.
Исходя из новостей о стремительной замене людей ИИ-агентами думаешь: там страх увольнений, безопасность и недоверие к качеству моделей.
В отчёте причины лежат ближе к обычному рабочему дню:
1. человек не понимает, зачем это лично ему;
2. боится неизвестности и неловкости;
3. не знает, как начать;
4. чувствует, что его исключили из решения.
В нашей практике картина почти совпала.
Дали доступ всем — пришли единицы. Провели вебинары — люди послушали и вернулись к обычной работе. Сделали реестр инструментов — он стал ещё одной ссылкой, которую никто сам не открывает.
После этого фокус сместился с доступа к первому рабочему опыту.
🧩 1. Личная польза появляется на живой задаче
Для инженера (это любой сотрудник айти-команды) «AI-стратегия» слишком далека от реальной задачи. А уж как она далека линейным сотрудникам - думаю не надо и описывать :) Лучше работает конкретика: 30 boilerplate-классов за 2 минуты (не спрашивайте, зачем это надо), тест-кейсы по реальному тикету, разбор старого модуля перед задачей.
Практика: Это как научить рыбачить, вместо того чтобы сразу кормить. Примеры и выгоду показываем типовые для нужной когорты людей (ведь у всех ролей разные запросы), связанный с конкретными и рутинными задачами.
⛑ 2. Первый опыт должен быть безопасным
Люди редко задают простые вопросы на большом вебинаре. Маленькая группа, эксперт рядом, можно останавливаться, ошибаться и спрашивать про установку, доступы, промпт, ошибку в терминале.
В посте выше есть формат воркшопа и хакатона, которые тут помогут. Но пререквизит к этому: обязательно упростите установку кодинг-агента + доступов + нужных инструментов и mcp. В идеале shell-скриптом. А для сотрудников на винде сразу закажите админские роли. А для сотрудников на VDI - проработайте решение с безопасниками.
🎢 3. Первый маршрут лучше собрать заранее
Одна команда установки. Готовый сценарий запуска. Пример на реальном тикете. Понятные ограничения. Чеклист проверки результата.
Человек должен быстро дойти до первого маленького успеха.
Практика: Даем примеры, которые можно решить (чтоб не разочаровать, если пример не решится). Прогоняем воркшоп на подопытных, чтобы отловить типичные проблемы на каждом шаге. Не грузим кучей теории
🧠 4. Практика приживается, когда команда собирает её сама
QA собирают свои сценарии. Аналитики описывают свои артефакты. Разработчики формируют скилы для кода и ревью. Техлид показывает пример на собственной работе. Продакт учится самостоятельно делать прототипы.
Так AI становится темой нормального инженерного разговора: какие задачи отдаём агенту, где держим стандарт, где финальное решение остаётся за человеком.
Сопротивление AI часто начинается с нормальных вопросов команды.
Практика: Мы в обучении и вовлечении даем самый минимум. Скелет, фреймворк для использования. Когда у людей есть желание улучшаться (а в agile мы его воспитываем ретроспективами и культурой непрерывного развития) - при необходимых инструментах они сами учатся оптимизироваться. Важно создать среду для поддержки подобных благих намерений.
💅 Короче говоря: Хорошее внедрение даёт человеку первый маленький результат — и право попробовать самому.
Больше про работу с командами и внедрение ИИ в инженерку в блоге Марата Киньябулатова predictable.team
🤝 Всем привет, сегодняшняя презентация с People Sense - мы обсуждали проблемы перехода в Agentic Engineering.
Мы, вероятно, не успели покрыть темы:
- топ причин сопротивления внедрению ИИ в организациях;
- почему ИИ может привести к тому, что ваша компания станет Feature Factory на стероидах;
- как двигаться в сторону AI Adoption и Agentic engineering - если вы не готовы менять структуру команды.
Дополнительные материалы в этом посте
🤖 Маленькие AI-команды, которые радикально меняют SDLC это гипотеза, которая апробируется. А не аксиома, как многие сейчас думают.
Я очень много слышу (и сам привожу примеры) о том, как AI двигает нас к микро-командам (по разным причинам: например сокращение координационной цепочки).
🚀 Кейсы, которые у всех на слуху: как строили Sora for Android в 4 человека, 28 дней, #1 в Google Play — это все кейсы от OpenAI и Anthropic. То есть компании, которые сами строят AI-инструменты, их продают, и сами же ими пользуются.
И почему-то когда мы приводим их в пример, мы забываем что там нет legacy, нет трёх уровней согласований, самый ранний доступ к моделям и инфраструктуре. Потом еще можно вспомнить uptime сервисов Anthropic (он невысокий) и понять, что они-то на стадии роста могут им жертвовать (а я в финтехе - не могу).
Это важный контекст, если думаешь о переносе паттерна в свою компанию.
🐻 Большинство компаний в 2026-м осторожно движутся к небольшим, измеримым AI-проектам (а не оголтелому перенарезанию оргструктуры). Прирост продуктивности на уровне задач, когда ты выстраиваешь агентский SDLC вокруг конкретного бизнес процесса реальный (15–40%). А вот конвертация этого в результат на уровне всей компании — отдельная работа, которая зависит от структуры, legacy и культуры в самой организации. Потому что ускорив одну команду, ты тупо упрешся в соседние.
Где точно круто работают микрокоманды - это прототипирование через vibe coding. Путь же от прототипа до прода — это тесты, security, observability, CI/CD, feature флаги, рефакторинг. И это все упирается в правильную обвязку, а выстроить ее - это понимать и исповедовать инженерную культуру.
🚵♀️ Третий год мы зачеркиваем предыдущие подходы: prompt engineering → context engineering → и вот сейчас harness engineering: проектирование сред, ограничения, циклы обратной связи, жизненный цикл агентов. OpenAI в феврале 2026-го написали, что их самые сложные задачи теперь именно здесь — в проектировании среды для агентов.
Когда harness engineering перечеркнем, интересно?
Короче говоря, команды из 2–4 человек работают в специфических условиях: greenfield, автономия, senior-состав, нет legacy. Это живой эксперимент, результаты которого ещё накапливаются. А работают ли они на масштабе в других средах: brownfield, зарегулированных и отчетных - это пока еще вопрос.
❓ Есть ли у вас примеры того, как микро-команды работают или не работают
🚫🐞 Zero Bug Policy: как мы сократили бэклог багов в 4 раза
- Уменьшили бэклог с 77 → 18 багов за месяц.
- 80% всех багов - с датами фиксов, которые сбываются.
- Разбор всех новых багов в течение 2 дней.
📝 Контекст
Кейс с прошлой работы: в MetaMap мы быстро росли. Команд добавлялось, фичей становилось больше, клиентская база расширялась. Бэклог багов рос - 77 открытых, у 60 ни сроков, ни ответственного.
Приоритизировали хаотично:
- кто громче кричит,
- у какого клиента больше ARR,
- насколько панически звучит запрос 😅.
Поддержка не могла обещать клиентам конкретики. Разработка откладывала баги из спринта в спринт (знакомо?). Дефект попадал в бэклог и пропадал куда-то за горизонт событий черной дыры.
⚙ Что сделали
Ввели Zero Bug Policy. Три правила:
• Critical — production down, data loss, security breach. Бросаем всё, чиним сейчас
• Moderate — следующий спринт, 30% capacity
• Low багов нет — мы их сразу закрываем и информируем, почему не будем чинить
• Баг висит > 2 спринтов — останавливаем фичи, разбираемся с долгом
Каждому багу — Due Date или хотя бы «дата, когда мы назовём дату».
Результат
Через месяц: 77 → 18. Поддержка впервые стала говорить клиентам «исправим тогда-то» — и сдерживала слово. Доверие между отделами и пользователями восстановилось.
Наконец-то собрал этот опыт в полноценный пост на Хабре — с механикой, SLA и тем, как это работает на практике.
Всем бодрого понедельника!
📣 На следующей неделе выступаю на People Sense (в Москве и онлайн) про Agentic Engineering (когда агенты делают за вас всю работу). А именно:
- Как сокращать время на разработку с помощью Agentic Engineering,
- Что такое AI-first команда,
- Почему всем это не подходит,
- Как трансформируются роли в команде при переходе в Agentic Engineering
🗞 Последние два месяца у нас была куча экспериментов, из которых я раскрою:
- Какие первые метрики для измерения эффектов от внедрения ИИ можно поставить в инженерных командах,
- Почему, несмотря на все ускорение команд мы все еще можем сталкиваться отсутствием системных изменений,
- Какие челленджи нам припасли руководители команд и почему все упирается в них.
Буду рад увидеть всех. Если есть какие-то конкретные вопросы, можно кидать их в комменты :)
👉 Регистрация по ссылочке 👈
Всем хорошей рабочей недельки (а жителям 🗺 Башкортостана - хорошей сокращенной рабочей недельки)
🔫 AI-агент удалил базу данных за 9 секунд. А потом написал явку с повинной.
Пока готовлю большой материал по Zero Bugs Policy, сравниваю OpenClaw vs Hermes, бенчмаркаю аналог Deep Research и судорожно перед отпуском готовлюсь к People Sense (буду рассказывать про челленджи AI-native команд) почитываю в фоне новостные дайджесты. В очередной раз поржал:
В апреле стартап PocketOS попросил Cursor с Claude помочь с рутинной задачей. Агент нашёл в соседнем файле production-токен, решил «заодно всё поправить» — и за 9 секунд снёс всю базу данных вместе с бэкапами. 30+ часов даунтайма. Клиенты приходили забирать арендованные машины — данных нет.
Когда основатель спросил, что произошло, Claude ответил: «Я нарушил каждый принцип, который мне дали. Я угадывал вместо того, чтобы проверять. Я выполнил деструктивное действие, которого меня никто не просил».
Инженеры из Railway назвали это vibe deletion — по аналогии с vibe coding.
🎲 Когда работаешь на ощущениях, без guardrails (системы ограничений) и least privilege (у агента минимум прав) — иногда получаешь фичу, иногда 30-часовой даунтайм. И это не единственный случай: за 8 месяцев таких инцидентов уже семь (и назвали это production destruction pattern).
Хорошая пятница, чтобы проверить: а ваш агент сейчас чем занимается? Роняли прод агентами на работе?
Я вот в энтерпрайзе пока придерживаюсь позиции на пушечный выстрел к деплоям не подпускать агентов.
🚀 Парадокс 2026 года: мы стали писать код быстрее, но качество летит в пропасть
Каждую неделю у меня по расписанию агент подкидывает все последние новости из AI + SDLC + Management исследований. Сегодня поделюсь отчетом от Faros AI: я наблюдаю очень похожие выводы на своем масштабе - а тут они подтверждаются сильнее). Отчет приложил.
Вышел мощный отчёт Faros AI, основанный не на опросах в духе «как вам кажется?», а на суровой телеметрии 22 000 разработчиков. Аналитики назвали новый феномен «Acceleration Whiplash» (травма хлыстом от ускорения).
Суть: ИИ-инструменты (Copilot, Cursor, Claude Code и другие) позволяют двигать роудмапы, но при этом ломают на части процессы ревью и тестирования. Наш старый процесс просто не рассчитан на новую скорость генерации кода (раз, два).
📈 Что хорошего в отчете про ИИ (где AI реально ускоряет):
- Закрытых эпиков на разработчика: +66%
- Количество закрытых задач (throughput): +34%
📉 Где скрыта боль (тот самый Whiplash):
- Количество багов на разработчика: +54%
- Инциденты на один PR: +242% (каждый мёрдж стал почти втрое опаснее!)
- Средний размер PR вырос на 51%
- Время ревью одного PR увеличилось в 5 раз
🧠 Почему так происходит?
ИИ отлично генерирует код, но не понимает ваш архитектурный контекст. Инженер быстро (если долго смотреть станет плохо) принимает сгенерированный блок и отправляет его дальше. Главный защитный механизм индустрии — «маленькие PR до 400 строк» — сейчас сломан.
На ревьюера падает огромный кусок логики. Его когнитивная нагрузка зашкаливает (об этом я говорил на докладе на прошлой неделе). Итог: на 31% выросла доля PR, которые мёрджатся вообще без содержательного ревью (просто не глядя).
🛠 Что с этим делать тимлидам и руководителям?
1. Верните жёсткие лимиты на размер PR
Исследования (в т.ч. от Microsoft) показывают: PR больше 400 строк ревьюить бесполезно, мозг переходит в режим слепого скроллинга. Вшивайте в обвязку (agent harness) автоматические гайды и алерты на огромные многофайловые коммиты от ИИ.
2. Меняйте метрики.
«Строки кода» и «количество PR» больше ничего не значат (AI легко их накрутит). Смотрите на Code Churn (сколько строк пришлось удалить/переписать после мёрджа) и Incidents per PR (ошибок на PR - и аварий, и багов).
3. Инженеры-люди нужны как никогда.
Сокращать штат с мыслью «AI напишет код за них» — фатальная ошибка. Вам нужны сильные (senior) инженеры именно как надёжный буфер на код-ревью между ИИ-генератором и вашим продакшеном. Именно такие синьоры, которые умеют выстроить систему, которая будет справляться (качественно) с новым объемем артефектов от агентов.
В 2026 году выигрывает не та команда, которая генерирует больше кода, а та, которая смогла перестроить пайплайны ревью под эти сумасшедшие объёмы - заключает исследование
👍 Больше про системную работу с эффективностью команд + AI в блоге Марата Киньябулатова про предсказуемые команды
Привет старичкам и всем новичкам <3
Преза с выступления сегодня на DUMP (о чем она - пост выше).
Доп. материалы:
• Мысли вслух: Как AI-агенты меняют процесс разработки в разных типах проектов (Хабр)
• ИИ-ассистенты не ломают поддерживаемость кода. Но есть нюансы (выжимка из исследования Echoes of AI) (Хабр)
• Что такое ADKAR. - фреймворк управления изменениями в организациях
• Серия постов про внедрение AI (цель, изменения, мероприятия, события, ограничения)
🤖 Почему внедрение ИИ не делает разработку быстрее? Наш опыт на масштабе моего подразделения (500 человек)
Все ждут, что AI автоматически ускорит Time-to-Market, но на практике всё гораздо сложнее. Мы проверили три гипотезы ускорения Lead Time (LT) с помощью ИИ на 500 инженерах, и ни одна не сработала так, как ожидалось.
Вот как эволюционировал наш подход:
❌ Гипотеза 1: Дать доступ к LLM = ускорить работу
Мы просто раздали доступы и получили красивый рост использования (MAU) до 50%, но Lead Time не сдвинулся. Оказалось, что использование ИИ в формате чата — это просто «туризм» без формирования привычки. Люди ситуативно играются, но барьер для применения ИИ непосредственно в написании кода остается огромным.
❌ Гипотеза 2: Обучить кодингу через агенты = ускорить работу
Поняв ошибки, мы применили фреймворк изменений ADKAR: заменили рассылки на воркшопы и добились того, что 40% инженеров стали регулярно использовать API агентов. Разработчики стали быстрее писать код, но метрика Lead Time снова не сдвинулась.
Причина: Локальная оптимизация. Мы ускорили только одно звено, но общее время ожидания аналитики и тестирования осталось прежним, поэтому вся цепь не ускорилась.
❌ Гипотеза 3: Agentic Engineering (ИИ забирает весь цикл)
В пилоте 2 разработчика с помощью ИИ взяли на себя e2e ответственность и сделали объем работы фиче-команды из 5 человек. Жизненный цикл разработки (SDLC) сжался, но появилось новое бутылочное горлышко — человек. Чем быстрее агенты генерируют код, тем сильнее перегружаются бизнес-эксперты на валидации требований и лиды на ревью.
💡 Главные системные выводы, которые мы вынесли:
- Считайте людей, а не токены: Количество запросов в дашбордах легко раздувается автоматизацией одного инженера. Поэтому мы смотрим на регулярность. Главная метрика, которая предвосхищает готовность команды к переходу на Agentic Engineering — это когда 80% команды использует агентов 80% рабочих дней (с поправкой на отпуска и выходные).
- ИИ внедряется через Pull, а не Push: Насильно заставить использовать ИИ не получится, это вызывает только сопротивление. Сработали малые демо-группы и демонстрация конкретной пользы («сделаешь 30 DTO за 2 минуты вместо 2 часов»).
- AI не чинит сломанное: Недостаточно ускорить одну команду, нужно работать с системными ограничениями всего потока поставки ценности.
А на каком этапе внедрения AI находится ваша команда: пока просто тестируете чаты или уже решаете проблему перегруза на код-ревью сгенерированного кода? Делитесь в комментариях! 👇
Материалы к сегодняшнему выступлению на MergeConf Tatarstan 2026,
50 команд и 1 Учпочмак: масштабируемый рецепт эффективности
Статьи на Хабре • Что такое эффективная команда, почему 91% сотрудников работают вслепую и причем тут «эчпочмак»? Модель «Учпочмак» подробно: три вершины, чек-лист диагностики, статистика. Текстовая основа доклада. • Предсказуемость и метрики потока Throughput: как научиться перестать гадать сроки и начать их предсказывать через Monte-Carlo Как использовать Throughput для вероятностных прогнозов. Закон Литтла в действии, Lead Time перцентили, симуляции. • 5 причин, почему ваши Story Points не работают (и что делать) Почему переход на flow metrics (Cycle Time, Throughput, Lead Time, Aging) даёт более объективную картину, чем Story Points. • Цели и Feature Factory Уводим стартап от «конвейерной штамповки фичей». Включаем продуктовый подход и начинаем считать ROI Feature ROI Check и Engineering Cost Check — как понять, какие фичи создают ценность, а какие уходят в никуда. Источники и литература по вершинам модели Вершина 1: Цели • Gallup — State of the Global Workplace gallup.com/workplace Ежегодное исследование вовлечённости. • McKinsey & Company — исследования по strategy execution mckinsey.com/capabilities/people-and-organizational-performance • Axios HQ — Employee Communication Report 2024 axioshq.com Исследование о степени согласованности целей сотрудников. Ищите их Annual Employee Communication Report. Вершина 2: Люди • Книга: The Fearless Organization (2018) — Harvard Business Review Press amazon.com → "Amy Edmondson Fearless Organization" • Оригинальное исследование: "Psychological Safety and Learning in Work Teams" (1999) scholar.google.com → "Edmondson 1999 psychological safety" • Реально виновных в намеренном вредительстве — 1–4% Google — Project Aristotle rework.withgoogle.com • Spotify Squad Health Check Model Авторы: Henrik Kniberg, Anders Ivarsson (Spotify). «Spotify Squad Health Check» → оригинальный пост Kniberg на Spotify Engineering blog • Gallup — роль менеджера. В лучших организациях вовлечённость менеджеров достигает 79% против глобального среднего 22%. gallup.com/workplace Вершина 3: Предсказуемость • Daniel Vacanti — Actionable Agile Metrics for Predictability Книга — главный источник по flow metrics для Kanban/Agile. • David J. Anderson — Kanban Книга: Kanban: Successful Evolutionary Change for Your Technology Business (2010) • Little's Law L = λW → Lead Time = WIP / Throughput Оригинал: Little, J.D.C. (1961). «A Proof for the Queuing Formula L = λW». Работает для любых стабильных систем. • Troy Magennis — Monte Carlo для Agile focusedobjective.com Вероятностное прогнозирование на основе исторического Throughput. Шаблоны и инструменты — на сайте (бесплатно). QBR (Quarterly Business Review) Atlassian — гайды по QBR atlassian.com/team-playbook Практические шаблоны для квартальных ревью с командами. Инструменты • Jira + OKR-плагины для трассировки задач (OKR Board, BigPicture) • Predictable Team - анализ и рекомендации по метрикам потока, прогнозирование выполненной работы методом монте-карло • ActionableAgile Analytics - Flow metrics (Lead Time, Throughput) - из РФ нет доступа • Monte Carlo Excel шаблоны, вероятностные прогнозы - focusedobjective.com Марат Киньябулатов • Телеграм-канал t.me/predictableteam предсказуемость, метрики, управление командами. • Habr: habr.com/ru/users/Eskimo • LinkedIn: linkedin.com/in/maratkinyabulatov
🏳️🌈 Google теперь требует от PM-ов вайб-кодить прототипы прямо на собесах
🍷Классическая романтика продуктовой разработки полна уютных ритуалов:
- многостраничные описания в Google Docs,
- стратегические сессии,
- бесконечные груминги,
- детальные диаграммы пользовательского пути.
🧱Индустрия решила добавить в этот процесс щепотку сурового реализма и максимальной прикладной пользы.
TL;DR: Google обновил формат собеседований для продакт-менеджеров — кандидатов просят открыть Cursor и собрать работающий прототип фичи ровно за 45 минут.Акаш Гупта любезно подсветил этот новый тренд в X. Процесс оценки уверенно перешел в плоскость создания осязаемых артефактов. Кандидаты демонстрируют уверенное владение ИИ-инструментами и способность буквально на лету превращать концепции в кликабельный код. Привычные продуктовые фреймворки и красивые презентации теперь дополняются навыком быстрого «вайбкодинга». Практика для команд: Способность продакта самостоятельно собрать демо-версию радикально повышает прозрачность процессов. Прототип, созданный за час с помощью Cursor или Bolt, переводит обсуждение гипотез в предметное русло. Команда разработчиков сразу получает осязаемый контекст, количество слепых зон на планировании стремится к нулю, а идеи обретают форму задолго до попадания в бэклог. Это отличный инструмент для снижения рисков и повышения общей предсказуемости поставки ценности. Навык самостоятельного ИИ-прототипирования уверенно занимает свое место в резюме рядом с CustDev-ом. Чо как у вас с ИИ? Уже собираете прототипы сами, или пока просто изучаете инструменты? 👇
+3
В продолжение темы про ИИ — наш второй пост о хакатоне персональных агентов-помощников BitGN. Платформу для него сделал наш бывший коллега Ринат Абдуллин, который сейчас живет в Вене. Огромное ему спасибо за такие классные инициативы!
В этом мероприятии я выступил как соорганизатор
- с Айгизом (автором колонки Homai и ML Engineer в TimeToAct),
- Вадимом (тимлидом TYIN и активным контрибьютором в AI community).
- Школа 21 Уфа (предоставили площадку).
а заодно прочитал мини-лекцию.
Ожидания и реальность
Помните, в прошлом посте я говорил про низкий уровень владения ИИ? На хакатоне это подтвердилось наглядно: около 80% пришедших участников до этого не ставили вообще никаких оболочек для работы с LLM.
Мой коллега и идейный вдохновитель хакатона сначала думал, что с установкой софта участники справятся сами и париться не стоит. Но я, наученный опытом внедрения ИИ в своем отделе, понимал, что без базы мы далеко не уедем.
Лекция и долгая установка
Пришлось сделать подробный вводный гайд. Мы разобрали, что такое LLM, токены и контекст, а затем пошагово ставили opencode (CLI/UI) и шли в OpenRouter. Отдельно учились брать бесплатные модели (nemotron 30b free), так как платные мало кто использует, а до китайских сеток люди вообще не добираются.
На прикрепленной фотке я в полуспящем состоянии читаю этот самый гайд по настройке оболочек. В итоге установка, которая в идеальном мире занимает 10 минут, растянулась на добрые полтора часа. 😄
Практика с агентами
Когда мы справились с инфраструктурой, началось самое интересное — запуск Python-агента сначала в песочнице, а потом в проде. Агент должен был выполнять задачи разного профиля, но делал это с заранее заложенными ошибками.
Участникам нужно было разобраться в его логике, найти баги и заставить агента работать правильно.
Крутые итоги
Получилось очень здорово! Мы фактически с нуля научили 35 человек пользоваться opencode и оплатили им доступ к модели GLM (за это отдельное спасибо @listl). Наши ребята попали в топ лидерборда и прокачались в создании агентов.
Дело за малым — осталось обучить технологиям ИИ остальные 1,1 миллиона жителей Уфы! 😄
Митап “Роль QA в эпоху ИИ” (как иронично пошутил мой знакомый, эпоха ИИ - это как будто историческая специфика Японии).
Прошлая неделя ознаменовалась сразу двумя событиями в Уфе ИИ-направленности (провели митап + хакатон по персональным агентам).
По митапу: посмотрели на то, как меняется роль QA. 44 человека в мини-группах обсуждало:
В связи с ИИ и агентизацией:
- Целевой сетап: Как должна поменяться роль QA?
- Целевой сетап: Как должны поменяться другие роли?
- Какие сейчас есть блокеры?
- Что надо начать сейчас, чтобы прийти к целевому сетапу?
Краткая сводка по опросу в заголовке поста (картинка) , а вот выводы в презентации (в комментах).Я делю с легкой руки Adoption на следующие категории - LVL1: Общаются с LLM в чатик - LVL2: Пытаются кодить с одним агентом - LVL3: Используют несколько агентов со скилами - LVL4: Оркестрируют агентские системы Что я из этого подчерпнул: - В целом уровень внедрения ИИ низкий (90% - LVL1). - Люди привыкли общаться с LLM в чатике. - Только процентов 20 пользуется в работе Anthropic/OpenAI модельными. - Китайскими модельными по подписке пользуется от силы процентов 5. - Все еще много недоверия к локальным LLM, потому что в РФ локально разворачивать сложно: нужны железки к нам не поставляющиеся + нормальные модельки. - Одобрение ФСБ модельки в крупной нефтянке и около-госухе порождают много скепсиса и показывают плохие результаты. - По API и платными открытыми и закрытыми сетками пользуется мало народу, в основном разработчики в стартапах где можно. - Даже дома чаще всего люди используют чат для пет проектов. - Ну и рассуждения уровня “для QA нужна специализированно обученная LLM” тоже показывает, что никто агентами и скилами не пользуется. Было очень интересно. Отрезвляюще. Надо продолжать.
🪙 Токенмаксинг — новая религия Silicon Valley
Статья на хабре: https://habr.com/ru/articles/1020648/
Пока вы работаете, ваш коллега уже сжёг 210 миллиардов токенов за неделю. Это 33 Википедии. Он не написал ни строчки в продакшн — но возглавил корпоративный лидерборд и получил звание «Token Legend».
Разработчик в Meta* создал внутренний рейтинг сотрудников по потреблению AI-токенов. За месяц — 60 триллионов токенов на ~$9 млрд (если смотреть на тарифы Claude). Jensen Huang предлагает выдавать токен-бюджет как часть зарплаты.
Добро пожаловать в эпоху, где метрика продуктивности — это сколько денег ты потратил на нейросеть. 🙈
Строки кода накручивали в 2000-х. Теперь накручивают токены. Только теперь это стоит $72 000 в месяц из кармана компании.
Полгода назад я писал, почему мы отказались смотреть на AI-adoption через токены и количество запросов к LLM. А антипаттерн-то цветет и пахнет.
BitGN PAC1 — Хакатон по AI-агентам в Уфе 🤖🔥
📅 11 апреля
📍 Школа 21 (Сбер), Уфа, ул. Заки Валиди, 32/2Б
Собираемся оффлайн, чтобы вместе прокачать своих персональных AI-агентов и посоревноваться на платформе BitGN!
Расписание:
🕐 12:00 — Старт. Разбор кейсов, обмен опытом, помощь друг другу, донастройка агентов
🕐 15:00–17:00 — Соревнование
🕐 18:00 — Объявление победителей и награждение 🏆
Что нужно от вас:
— Ноутбук с доступом к LLM
— Заранее написанный агент (на месте будем дорабатывать и тюнить)
Воду обеспечим, остальное — ваш скилл и желание побеждать 💪
Мероприятие проходит при поддержке Уфа IT Коворкинг и Школа 21 от Сбера.
Если есть вопросы - вступайте в нашу группу.
Если ещё не смотрели — познакомьтесь с платформой и примерами агентов заранее:
🔗 Платформа: https://api.bitgn.com
🔗 Примеры агентов: https://github.com/bitgn/sample-agents
До встречи 11 апреля!
В этом году со-спонсорствую BitGN (от автора ERC - enterprise rag challenge) в Уфе!
Приходите, будет весело 🚀
Всем привет и богоподобных выходных!
В рамках сообщества Agile Ufa делаю небольшое исследование и нужен ваш опыт и мнение:
• 🗳 Уделите пару минут на опрос (гугл формы): Как меняется работа с качеством и какой становится роль QA с приходом ИИ-инструментов в нашу работу.
Результаты я опубликую в этом канале ровно через неделю + напишу что наблюдаю в своей работе.
• 📍 Если вы в Уфе + хотите поучаствовать в митапе - вот анонс с регистрацией (напишите мне в личку, если мест не хватает).
• 🤗 Ну, а если хотите стать частью сообщества: велком в @agileufa 🙂
Рассуждаем, как меняется цикл разработки. Когда он схлопывается в один-два этапа, а когда - не сильно меняется:
- в проектах без исторической кодовой базы (с нуля, greenfield)
- в существующих продуктах (brownfield)
- в зарегулированных индустриях (regulated)
https://habr.com/ru/articles/1015004/
🤝️️️️️️ Что такое устойчивая (sustainable) команда?
• "Хьюстон, у нас проблема с мотивацией."
• Окей. А с чем конкретно? С целями? С лидером? С нагрузкой? С признанием? С ростом?
Устойчивая команда (Sustainable team) - это система показателей.Мы уже рассматривали почему цели - самые важные в модели командой эффективности. Теперь время обсудить тех, кто эти самые цели и реализует. 💠 Концепция Устойчивая команда — команда, которая: • Достигает результатов • Не выгорает • Сохраняет людей • Растёт в capability Это точно не "довольная команда". Пожалуйста, не путайте. Нам важно постоянное достижение результатов на длинной дистанции (а не то, что все довольны и радостны). 🏗 Составные части устойчивой команды Формат: Аспект, Что это, Почему важно • Психологическая безопасность: Можно говорить правду без страха. Это фундамент для всего остального. • Качество управления: Качество работы руководителя | 70% вариативность в вовлеченности. • Цели и их значение: Понимание зачем и куда. Внутренняя мотивация важнее денег. • Стабильность состава команды: Стабильность состава. Важно так как стабильный состав влияет на концетрацию знаний и стадию зрелости команды. • Рост и развитие: очевидное название. 3% уходят из-за скуки • Признание: Признание вклада. Повышает вовлеченность в 2.5 раза. • Work-life Balance: Баланс нагрузки. 76% сотрудников испытывают выгорание • Компенсация: Справедливая оплата. Гигиенический фактор. ⛓️ Как это связано Всё влияет на всё. Примеры цепочек: Цепочка 1: Безопасность → Выгорание. > Низкая безопасность → скрывают проблемы → копится техдолг → перегрузка → выгорание → уход людей → потеря знаний → ещё ниже безопасность Цепочка 2: Leadership → Everything > Слабый лидер → нет четкости целей → нет признания → нет проф. развития → люди уходят Цепочка 3: Цели → Motivation > Непонятные цели → нет смысла и ценности → нет вовлеченности → "просто работаю" → ищу где интереснее 🧬 Какие модели устойчивых команд бывают и из чего они состоят Формат: Модель: Фокус. Из чего состоит • Google Aristotle: модель командной эффективности. Безопасность - это главное. Потом зависимость, структура, смыслы, влияние на результат. • Хакманн: модель архитектуры команды = Настоящая команда + Направление + Структурность + Контекст + Коучинг • SPACE (Microsoft): Для эффективной команды важен опыт разработчиков. А это удовлетворенность, Продуктивность, Проактивность, Коммуникация, Эффективность • 👍 Spotify Health Check: Самодиагностика. 8 измерений, команда сама оценивает, без сравнений. Самое простое, с чего можно начать уже завтра. Короче говоря: все модели признают, что здоровье команды - многомерная штука, и фиксить одно без другого не работает.
