Code of Leadership 2. Эпизод #2 - Не усложняй. Управление проектами с Дмитрием Ильенковым (Рубрика #Management)

Вышел второй выпуск второго сезона моего подкаста Code of Leadership. В этот раз в гостях был Дмитрий Ильенков - основатель @pmclub, человек с большим опытом в проектном управлении и соавтор книги «Не усложняй! Управление проектами по методу P3.express», о которой я уже рассказывал раньше. Говорили мы в этом эпизоде о проектном управлении без лишнего пафоса и без попытки превратить менеджмент в набор тяжелых ритуалов. Главная тема выпуска - как управлять проектами так, чтобы методология помогала доводить работу до результата, а не превращалась в бюрократический театр.

- P3.express хорошо ложится на роль практического входа в проектное управление
- Простота методологии не минус, а плюс
- Принципы важны, потому что без них методология легко превращается в карго-культ
- Управление проектами - это постоянный поиск слабого звена в цепочке и его оптимизация
- Метрики полезны, но цель нельзя сводить только к цифре
- Хороший процесс нужен не вместо результата, а для того, чтобы можно было получить предсказуемый результат

В общем, выпуск получился не про "еще одну методологию", а про здравый смысл в управлении проектами. Как не усложнять там, где можно сделать проще, но и не скатываться в хаос под видом гибкости. Рекомендую тем, кто управляет проектами, продуктами, командами или просто регулярно оказывается в ситуации, где нужно довести сложную работу до результата вместе с другими людьми.

Выпускк доступен на разных платформах: Youtube, VK, Ya Music, Podster.fm.

#Management #Leadership #ProjectManagement #Processes #Engineering

Measuring the effectiveness of software development tools and practices (Рубрика #Productivity)

Я часто рассказываю про тему продуктивности инженеров, а также подходов к этому крупных компаний (смотри статьи от Google, или статьи запрещенной в России Meta), а также про то, как мы внутри Т-Банка подходим к этому. Но сегодня я хотел рассказать про подход Amazon к этому непростому снаряду - авторы предлагают метод измерения экономического эффекта от инструментов и практик разработки. Они предлагают смотреть на единую метрику CTS-SW (cost-to-serve software) - по сути, сколько ресурсов уходит на доставку единицы ПО до клиента. Эта метрика должна связать привычные engineering-метрики в духе DORA/SPACE с понятным бизнес-результатом: сэкономленной инженерной емкостью или деньгами.

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

1️⃣ Они берут "стоимость доставки ПО" как итоговую метрику, а не пытаются детально оценить каждый шаг разработки
Авторы говорят, что классический activity-based costing для софта слишком хрупок и поэтому они упрощают задачу до "входные затраты → единица результата", а затем уже ищут драйверы этой стоимости по всему жизненному циклу: coding, CI/CD, planning, incident management, maintenance, search for information и т.д. Единица результата тоже подбирается под архитектуру
- Микросервисы - деплои
- Монолит - зашипленный в мастер код
- Библиотеки - коммиты

2️⃣Дальше они строят панельные данные (микс факторов + время) и используют линейные смешанные модели
У них есть телеметрия по тысячам "two-pizza teams" за пять лет, и они моделируют CTS-SW через время разработчиков на деплой. Линейные смешанные модели нужны им потому, что они одновременно ловят общий эффект факторов и различия между командами. Так они нашли основные кандидаты-драйверы CTS-SW:
- Team velocity (сколько отревьювернного кода команда мерджит в неделю на инженера) - самый сильный предиктор
- Здоровье деливери (например, рейт ролбеков)
- Пейджи на on-call инженера

3️⃣ Переходят от корреляции к причинности через causal inference
После нахождения эффектов авторы ищут возможность для эксперимента. Таким естественным экспериментом для них стало внедрение genAI-инструментов, в частности Amazon Q Developer. Для оценки они строят панельную регрессию с dynamic two-way fixed effects: учитывают постоянные различия между командами, общие временные эффекты, лаг прошлой скорости и time-varying covariates вроде доли команды, использующей Q Developer, rollback rate и manual interventions. Цель - не просто увидеть корреляцию, а изолировать именно причинный вклад инструмента в CR velocity и deployment velocity.

4️⃣ Добавляют "страховку" от переоценки эффекта AI
Авторы отдельно признают, что если просто складывать эффекты разных экспериментов, можно завысить реальное влияние. Поэтому они разрабатывают baseline model, чтобы нормализовать оценки влияния AI-инструментов.

В общем, это явно интересный подход, который позволяет
- Решать, какие dev tools и AI tools масштабировать, исходя из измеримого эффекта
- Приоритизировать CI/CD автоматизации и практики надежности, потому что они свзяаны с лучшим CTS-SW.
- Создавать через онбординг условия для высокой team velocity, но использовать это именно как командную, а не индивидуальную метрику.
- Осторожно интерпретировать "полезные" сигналы

В будущем авторы хотят расширить модель, чтобы сравнивать архитектурные решения и давать рекомендации.

#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Software #Agents #Economics

AI Dev Podcast #2: Александр Поломодов, Сергей Баранов / Архитектура в эпоху ИИ (Рубрика #Architecture)

Около месяца назад мы записывали подкаст вместе с Сергеем Барановым (основателем ArchDays) и Андреем Дмтриевым (со-основателем JUG.RU) в рамках подготовки к сегодняшней конфе AI Dev Conf. Так получилось, что дальше я уехал в отпуск и забыл поделиться с вами этим эпизодом, а он был интересным:) Речь в нем шла про то, как LLM и мультиагентные системы меняют software architecture и инженерные процессы. Обсудили двойственную природу ИИ: с одной стороны - демократизация разработки (через lovable.dev и аналоги), с другой - жесткая необходимость в инженерном фундаменте для масштабирования.

Основными темами выпуска стали
- От SOE 1.0 к SOE 2.0: как люди и агенты будут работать в связке.
- Роль архитектора: больше не "чертежник", а стратег, валидирующий варианты от ИИ и выстраивающий внутренние модели.
- Экономика: почему типовые решения уходят в автоматизацию, а ценность повторного использования компонентов взлетает до небес.
- Болевые точки: бардак с данными и онтологиями, блокирующие зависимости между сервисами и проблема контекста.
- Прогноз: как готовить платформу к "мажорной разработке" с агентами и почему локальные эксперименты с моделями станут базовым навыком архитектора.

В итоге: агенты научатся писать код, делать ревью и документацию. Но ставить цели, изобретать и управлять контекстом останется за человеком. Тех, кто не адаптируется, ждет разорение. Компании уже поняли, что просто заменить людей ИИ недостаточно - им срочно понадобились специалисты, умеющие с ним работать эффективно.

#AI4SDLC #AI #Engineering #Software #Processes #Management #Productivity

SDLC с AI взгляд через метрики - Анна Громова @ AI Dev Conf (Рубрика #AI4SDLC)

Посмотрел майское выступление Анны Громовой из Т-Банка с конференции AI Dev Conf. Мы с Аней часто обсуждаем метрики эффективности AI по работе, поэтому мне особенно полезно, что появилась запись, на которую теперь можно давать ссылку: это актуальный и глубокий разбор того, как мы подходим к этой теме у себя в компании.

Главная мысль там очень практичная: AI в разработке нельзя нормально оценить, если вы не понимаете сам процесс поставки кода. Количество лицензий, MAU, запросов к ассистенту или сгенерированных строк может быть полезным сигналом adoption, но не отвечает на главный вопрос: стал ли SDLC быстрее, надежнее и дешевле для реального production-результата.

Аня начинает с фреймворков, которые многие знают по отдельности, но редко собирают вместе
- DORA - это метрики конвейера: lead time for changes, deployment frequency, recovery time, change failure rate; в докладе рядом с ними обсуждается и unplanned work. То есть как быстро и насколько стабильно команда довозит изменения до production.
- SPACE и DevEx добавляют человеческую сторону: удовлетворенность, коммуникации, flow, cognitive load, feedback loops. Потому что разработка - это не только pipeline, но и люди внутри него: ждут review, переключают контексты, ходят на встречи, разбираются с новым проектом и ищут доступы.
Кстати, я раньше уже подробно рассказывал про все эти подходы DORA, SPACE, DevEx.

Мне нравится, что в выступлении Аня не остановилась на теории, а показала реальные метрики: onboarding time, время до первого MR, pipeline time, testing time, review time, rework, размер MR, доля падающих pipeline, incident recovery, опросы разработчиков. То есть не у нас нет единой магической метрики продуктивности, а карта процесса, по которой можно искать узкие места.

Например, если вырос lead time, причина может быть не в том, что разработчики стали медленнее. Может оказаться, что у людей слишком долго оформляются доступы, документация плохо помогает при onboarding, новые end-to-end тесты замедлили pipeline или MR стали слишком большими и зависают на review.

И вот здесь AI становится интересным не как “ускоритель кодинга”, а как вмешательство в конкретные участки SDLC.

AI review может сократить ожидание первой реакции и часть рутинных итераций по стилю, опечаткам и простым багам. AI в дебаге проблем может быстрее сводить логи, код и симптомы к гипотезе о ключевой причине. Генерация юнит тестов закрывает скучную, но важную работу, до которой часто не доходят руки, и через это влияет на качество pipeline и change failure rate.

Но важная оговорка: если ускорить только написание кода, бутылочное горлышко просто переедет дальше. Сначала senior не успевает проверять сгенерированный код. Потом упираемся в флакающие тесты и CI/CD. Потом в тестовые окружения, релизный процесс или платформенные лимиты. AI не чинит слабую инженерную систему сам по себе, он часто просто ярче подсвечивает ее ограничения.

По словам Анны, в Т-Банке у AI-амбассадоров увидели снижение median merge time на 12% и lead time на 30%. Это не универсальный бенч и не обещание “просто добавьте воды AI и получите минус 30%”: в докладе отдельно проговаривается, что за скобками остаются особенности репозиториев, связность и сложность кода. Но как пример правильного разговора про эффект AI это ценно: не “люди стали чаще нажимать кнопку”, а “что произошло с delivery-процессом”.

Из доклада ясно, что для осмысленного внедрения AI нужен baseline до старта, регулярный сбор метрик, связь количественных данных с опытом разработчиков и понимание, какую часть процесса мы действительно хотим улучшить. И еще важнее - не влюбляться в одну метрику. Adoption нужен, но сам по себе он ничего не доказывает. Throughput нужен, но без quality/risk можно просто быстрее производить проблемы. Экономика нужна, но без инженерного контекста легко начать оптимизировать стоимость токенов вместо стоимости результата.

Практически это означает: прежде чем спорить, какой AI-инструмент лучше, стоит честно описать свой SDLC. Где у вас теряется время? Где ломается feedback loop? Где review превращается в очередь? Где CI/CD съедает выигрыш от генерации кода? Где разработчики чувствуют cognitive load, а граф метрик показывает то же самое? Тогда разговор про AI становится взрослым. Не “магия ускорила разработку”, а “мы изменили конкретный участок инженерной системы, увидели такой эффект, проверили риски и поняли, где следующий bottleneck”.

#AI #AI4SDLC #Engineering #DevOps #Management #Metrics #Software #Processes

AIDev: Studying AI Coding Agents on GitHub (Рубрика #AI4SDLC)

Прочитал короткую статью от 9 февраля 2026 года о том, как изучать coding agents по реальным PR, а не по демкам. В ней представлен публичный датасет, по которому agentic software engineering можно изучать не по демкам, а по следам реальных pull request'ов. Авторы - Hao Li, Haoxiang Zhang и Ahmed E. Hassan из Queen's University. Это хороший сигнал доверия: группа Hassan давно работает в empirical software engineering и mining software repositories. Paper подана на arXiv 9 февраля 2026 года и связана с MSR 2026 Mining Challenge; данные выложены на Hugging Face и Zenodo, код и ноутбуки - на GitHub.

Набор данных AIDev агрегирует 932 791 pull request, которые авторы относят к Agentic-PR: PR, созданным coding agents. В выборке пять инструментов: OpenAI Codex, Devin, GitHub Copilot, Cursor и Claude Code. Эти PR распределены по 116 211 репозиториям и связаны с 72 189 разработчиками; cutoff - 1 августа 2025 года. Для глубокого анализа есть поднабор: 33 596 PR из 2 807 репозиториев с более чем 100 звездами. Там уже есть review comments, review verdicts, commit-level diffs, связанные issues, timeline событий и автоматическая классификация типа задачи по Conventional Commits.

Методологически это dataset paper с главным результатом в виде инфраструктуры для интересных вопросов вида:
- Кто использует агентов (джуны, мидлы, сеньоры)
- Какие PR проходят review и merge
- Совпадает ли описание PR с diff
- Lобавляют ли агенты тесты
- Какие security/quality-паттерны всплывают в agent-authored code

Для меня здесь самый интересный сдвиг в единице измерения. В AI4SDLC долго мерили либо completion в IDE, либо synthetic benchmark вроде «реши issue». AIDev предлагает смотреть на весь lifecycle: issue -» PR -» commits -» review -» comments -» CI/merge/close -» дальнейшая судьба изменения. Это гораздо ближе к реальной инженерной системе. Практическое применение тут довольно прямое. Если компания внедряет кодинговых агентов, то ей стоит строить похожую внутреннюю телеметрию. Не «сколько строк сгенерировано» и не «сколько лицензий активировано», а что происходит с agent-authored PR: размер diff, доля тестов, время до review, число замечаний, merge rate, rollback/hotfix, security findings, соответствие conventions и CI.

Отдельно отмечу, что у исследования есть несколько оговорок:
- Датасет построен по публичному GitHub, поэтому enterprise-разработка и закрытые репозитории почти наверняка выглядят иначе
- Качество выводов зависит от того, насколько надежно определены agent-authored PR для каждого инструмента; в короткой версии paper этот слой описан недостаточно подробно (надо будет копнуть вглубь)
- Поднабор PR из репозиториев с 100+ звездочек смещает картину в сторону заметных open-source проектов.

P.S.
Дальше расскажу про несколько интересных статей, что опираются на инсайты, что были добыты из этого датасета.

#AI #AI4SDLC #Engineering #Research #Agents #Software #DevOps #Processes

Архетипы и стратегирование (Рубрика #Leadership)

Вчера уже в третий раз был на обучении у Андрея Шишакова про архетипы и личное стратегирование. И тут дело не в том, что я не понимаю с первого раза, а скорее в том, что мне нравится как Андрей подает свой материал и докручивает год от года. Для меня такое обучение часто является способом еще глубже уйти в саморефлексию и получить некоторые инсайты: в первый раз я учился у Андрея в 2022 году уже после всем известных событий, второй раз в 2024 году и в третий раз сейчас.

Основной контент вчерашнего обучения напоминал то, что было в 2024 году (о чем я рассказывал в трех постах "Стратегирование и самоактуализация/визионерство": 1, 2 и 3), но после вчерашнего обучения я понял, что мне надо начать ходить к психологу + пойти все-таки учиться по этому направлению + меня заинтересовала тема генеративного транса, которой закончилось вчерашнее обучение.

P.S.
Спасибо Наташе Лосевой, что у нас в компании отвечает за обучение руководителей, а также ее команде - это был отличный MBA Reunion день для выпускников всех наших внутренних программ MBA. А сегодня я еще поеду на день выпускника Сколково, так как наши программы были на базе этой бизнес школы.

#Management #Leadership #Processes #Strategy

Angie Jones про автономную инженерную организацию и ее последствия (Рубрика #AI4SDLC)

Посмотрел вчера выступление Angie Jones "Building an Autonomous Engineering Org", которое начинается как обычная история успеха про AI-агентов, а в конце заканчивается крайне интересными вопросами про будущее таких организаций. Сейчас Angie Jones работает VP of DevEx в Agentic AI Foundation, но в докладе она делится своим опытом работы в Block, где, по ее словам, последние пару лет участвовала в превращении инженерной организации на 3 500 человек в автономную инженерную организацию. У ребят получилось и сначала это ощущалось как реализация мечты ... пока не стало кошмаром и не закончилось сокращением половины штата, которые стали избыточны при такой автономии ...

Но если возвращаться к первой части доклада, то Angie говорит о том, что AI adoption сам по себе почти ничего не доказывает. В Block уже через пару месяцев около 90% инженеров регулярно использовали Goose и Claude Code, были метрики и счета за токены, но features не доезжали до клиентов быстрее. Компания прошла стадию экспериментов внедрения, но не дошла до получения ценности.

И для того, чтобы говорить о степенях движения к агентной инженерной организации (где инженеры используют AI-агентов как основной способ получать engineering outcomes) она вводит шкалу автономности инженера относительно агента
— Stage 0 - AI вообще не используется в рабочем процессе
— Stage 1 - autocomplete и похожие подсказки, но без agent mode
— Stage 2 - чат с агентом, но без реальных PR
— Stage 3 - инженер делегирует агенту задачи и проверяет результат
— Stage 4 - несколько агентов работают параллельно
— Stage 5 - агенту можно отдать целую задачу, и он способен выдать прод результат без постоянного вмешательства людей

До Stage 3 они дошли через использование AI чемпионов, а не массовым обучением всех подряд. Jones выбрала примерно 50 инженеров из критичных команд, которые могли тратить около 30% времени на AI enablement и умели работать с недетерминированностью моделей. Мысль в том, что если стратегия зависит от того, что каждый из 3 500 инженеров сам станет продвинутым пользователем, то широкого эффекта не случится.

Чемпионы сначала делали репозитории AI-ready. Это звучит скучно, но именно там начинается автономность: agents.md, claude.md, файлы с правилами, повторяемые рабочие процессы, позже скиллы для агентов, AI code reviewer и аттрибуция AI инструментов в PR. Агенту нужен контекст, правила, команды сборки и понимание, что именно в этом репозитории считается хорошим изменением. Все эти изменения были не одинаковыми для всех, а учитывали специфику: web, mobile, JVM backend, монорепозитории и маленькие сервисы требовали разных подходов.

Дальше автономность стала нативной для мест, где уже рождается работа: Slack, Jira, Linear, GitHub issues. В одном примере инженер прямо в Slack спрашивает Goose про баг, агент идет в репозиторий, подтверждает проблему, предлагает варианты исправления, команда выбирает вариант, и Goose возвращается с PR. По словам Jones, цикл обсуждение -> диагностика -> согласование -> fix занял около пяти минут. Это уже не coding assistant в IDE, а участник delivery loop. Через три месяца после запуска чемпионской программы, AI-authored code вырос на 69%, reported time savings - на 37%, а автоматические PRs - в 21 раз.

Stage 4 принес новый bottleneck: если инженеры запускают в 3-4 PRs больше, review ломается первым. Block подключил AI code review как обязательную часть контура: Codex на репозиториях, auto-fix loop, где один агент находит проблему, другой исправляет и коммитит изменения в PR. Плюс потребовались cloud workspaces: ноутбуки инженеров переставали выдерживать несколько параллельных агентов.

Stage 5 потребовал уже не инструмента, а модели организации. Команда начала строить Builder Bot - оркестратор с машинно-читаемой мировой моделью всей компании: где какие сервисы лежат, как они связаны, какие зависимости между кодовыми базами. По словам Jones, речь шла о примерно 25 000 репозиториев. Без такой карты агент может написать локальный патч, но не может планировать изменение через несколько продуктов и систем. Технически история закончилась Stage 5 тем, что любой сотрудник мог обратиться к Builder Bot в Slack и попросить исправить баг или реализовать feature, даже без GitHub.

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

#AI #AI4SDLC #Engineering #Agents #Management #PlatformEngineering #Leadership #Processes

Материалы по AMA сессии с Алексеем Литвиновым про AI-Assisted Engineering (Рубрика #AI4SDLC)

Готовы материалы с прямого эфира подкаста Code of Leadership с Алексеем Литвиновым:
- Страничка выпуска
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка
Кстати, у Лёши есть свой tg-канал - @tip_podcast, подписывайтесь на него

P.S.
За одну AMA-сессию мы не справились со всеми вопросами, поэтому на следующей неделе продолжим:)

#AI4SDLC #Agents #Processes #Engineering #Research #Software

Материалы по прямому эфиру с Александром Воронцовым про будущее консалтинга (Рубрика #Consulting)

Готовы материалы с прямого эфира подкаста Code of Leadership с Александром Воронцовым, партнером компании "Ревелио" (@revelio_tech.):
- Страничка выпуска
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка

#AI #Management #Processes #Engineering #Software

Материалы по прямому эфиру с Сергеем Барановым про AI в архитектуре (Рубрика #Architecture)

Готовы материалы с прямого эфира подкаста Research Insights Made Simple с Сергеем Барановым (@blog_sb), партнером компании Скрамтрек и организатором конференции ArchDays (@blog_sb):
- Страничка выпуска
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка

P.S.
Как раз видео на выходные + если кто-то хочет почитать оригинальное исследование, то вот оно + мой краткий разбор

#AI #Management #Processes #Engineering #Software #Architecture #DistributedSystems

Материалы по прямому эфиру с Анатолием Красновским про моделирование надёжности по графу зависимостей (Рубрика #SRE)

Готовы материалы с прямого эфира подкаста Research Insights Made Simple с Анатолием Красновским (@mb3rlab):
- Страничка выпуска
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка
- Репозитории: Sheaft, Bering и Procrustes

#AI #Management #Processes #Engineering #Software #Architecture #DistributedSystems

Материалы по прямому эфиру с Евгением Сергеевым про то, как строить работающие evals (Рубрика #AI)

Готовы материалы с прямого эфира подкаста Research Insights Made Simple с Евгением Сергеевым:
- Страничка выпуска
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка

#AI #Management #Processes #Engineering #Software #Architecture #Evals

Материалы по прямому эфиру с Артемом Бондарем про то, как внедрять AI в операционную работу (Рубрика #AI)

Готовы материалы с прямого эфира подкаста Code of Leadership с Артемом (@artemonml):
- Страничка выпуска
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка

#AI #Management #Processes #Engineering #Software #Architecture

Материалы по второй AMA сессии про AI-assisted Engineering с Алексеем Литвиновым про то, как внедрять AI в разработку (Рубрика #AI4SDLC)

Готовы материалы с прямого эфира подкаста Code of Leadership с Алексеем (@tip_podcast):
- Страничка выпуска
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка

#AI #Management #Processes #Engineering #Software #Architecture

Материалы про AI-разработку как эволюционирующий стек готовы (Рубрика #AI4SDLC)

Оформил все материалы по прямому эфиру, что был в пятницу, где я говорил про ко-дизайн железа, моделей, обвязки, инструментов, трейсов и так далее. Там я показывал как все это связано и что делают провайдеры, а что стоит делать на месте технических директоров обычных компаний
- Страничка выпуска
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка, полный лонгрид

#AI #Management #Processes #Engineering #Software #Architecture #DistributedSystems

Материалы с подкаста "PRD == evals: как AI стирает границу между продактом и ML Engineer" с Альбиной Мунировой из Т-Банка (Рубрика #ProductManagement)

Мы поговорили про изменения в профессии продакт менеджеров, когда граница между ним и ML-инженером становится заметно тоньше.
- Страничка выпуска
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка

P.S.
У Альбины есть свой канал в tg @aimunirova и на Youtube

#AI #Management #Processes #Engineering #Software #Architecture #ML

Материалы с третьей части AMA сессии с Лешей Литвиновым (Рубрика #AI4SDLC)

Мы успешно разобрали последние 6 вопросов и закончили свой марафон
- Страничка выпуска
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка

P.S.
У Леши есть свой канал в tg @tip_podcast и на Youtube

#AI #Management #Processes #Engineering #Software #Architecture

Материалы с первого выпуска подкаста "3 AImigo" (Рубрика #AI)

Наша первая серия о том, где сейчас находится AI-разработка вышла очень бодрой.
Мы обсуждали ее втроём: Евгений Сергеев, Алексей Литвинов и я, а ниже представлены материалы выпуска
- Страничка эпизода
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка
И бонусный лонгрид, что я написал, когда я готовился к этому выпуску.

P.S.
У Леши есть свой канал в tg @tip_podcast и на Youtube, а у Жени пока нет:)

#AI #Management #Processes #Engineering #Software #AI4SDLC #Software #Agents #Leadership

Материалы со второго выпуска подкаста "3 AImigo" (Рубрика #AI)

Наша вторая серия о том, где сейчас находится AI-разработка вышла интересной. Мы разбирались с парадоксом, который всё чаще встречается в командах: AI заметно ускоряет отдельного инженера, кода становится больше, а до пользователей доходит примерно столько же изменений. Локальная скорость не равна принятому результату — и размер компании от этого не защищает.

Мы обсуждали ее втроём: Евгений Сергеев, Алексей Литвинов и я, а ниже представлены материалы выпуска
- Страничка эпизода
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка

P.S.
У Леши есть свой канал в tg @tip_podcast и на Youtube, а у Жени пока нет:)

#AI #Management #Processes #Engineering #Software #AI4SDLC #Software #Agents #Leadership