Дискуссия с Гришей Скобелевым про подготовку к System Design Interview (Рубрика #Architecture)

Завтра, 21 февраля, в 11 часов утра по Москве мы с Гришей из клуба { между скобок } решили собраться и поговорить про подготовку к System Design Interview и про то, как я дошел до жизни такой, что собрал сайт system-design.space

Мы точно обсудим вопросы, что есть в программе встречи
• Почему книга не лучший формат для System Design
• Как меняются ожидания на интервью
• Какие ошибки чаще всего допускают кандидаты
• Что на самом деле проверяют на System Design интервью
• Как отличить «рисование кубиков» от настоящего архитектурного мышления
• Какие темы обязательно нужно понимать senior / staff инженеру

Но также думаю, что затронем вопросы системного мышления и фундаментальной подготовки, а не просто запоминания задач.

Встречаемся завтра c кофе ☕️ в 11:00 на YouTube

#SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering

It takes two (Рубрика #Games)

Почти 20 лет я не играл в компьютерные игры, но на этот новый год мы купили детишкам PS 5 с кучей игрушек. Но Настя (моя жена) не обделила и нас и купила эту кооперативную игру. Мы в нее играли иногда по вечерам и за полтора месяца прошли. Игра оказалась очень интересной, веселой, местами психологической и наводящей на мысли о семейном быте. Вся история крутится вокруг родителей маленькой девочки, что решили развестись. Чаяниями их дочки мама и папа оказываются в своем доме в виде игрушек и им нужно пройти большой путь, чтобы стать опять людьми.

В общем, игра была превосходная - мы даже купили игру Split Fiction, которую сделала та же студи и в которой история другая, но кооперативные механики те же.

#ForParents

Understanding Architectural Complexity, Maintenance Burden, and Developer Sentiment - a Large-Scale Study (ICSE’25) (Рубрика #Architecture)

Наконец-то у меня дошли руки написать про этот интересный whitepaper про связь качества архитектуры с нагрузкой на поддержку решения и восприятия инженерами самого проекта. Лид автором этой статьи была Yuanfang Cai, профессор в Drexel University и автор метрик применяемых метрик, а также команда Google Developer Infrastructure / Engineering Productivity Research (Ciera Jaspan и др.)

Авторы взяли данные
- 1200+ проектов внутри Google (C++/Java).
- Логи разработки: commits, LOC (lines of code) и Active Coding Time; отдельно мерили их в разрезе "фичи" vs "багфиксы"
- 7200 ответов инженеров из регулярного опроса: насколько техдолг/избыточная сложность мешали работе (подробнее про этот опрос было в статье ребят из Google "Measuring Developer Experience With a Longitudinal Survey", что я уже разбирал)

Цель всего приседания была в том, чтобы заменить "ощущения техдолга" на измеримые связи: архитектура → бремя сопровождения → настроение разработчиков. Кстати, про техдолг ребята из Google уже публиковали крутую статью "Defining, measuring and managing technical debt", которую я уже разбирал

Измеряли они следующие три категории
1️⃣ Архитектурная сложность
- Propagation Cost (PC): насколько широко расползаются изменения по зависимостям
- Decoupling Level (DL): насколько хорошо система декомпозирована на независимые модули
- Архитектурные запахи: циклические зависимости, co-change без явных зависимостей, нестабильные интерфейсы, проблемы наследования и т.п.
2️⃣ Maintenance burden
- Доля усилий на багфиксы: по commits, LOC (lines of code), ACT (active coding time)
3️⃣ Developer sentiment
- Ответы на вопросы из опросы вида "тормозит ли меня техдолг"

Методология выглядела так
- Для каждого проекта считают PC/DL/запахи по dependency graph + считают "bugfix ratio" по истории изменений
- Дальше делают статистический анализ (корреляции/значимость) между тремя слоями

В итоге у них на выходе получились результаты, что
- Более сложная архитектура (PC↑, smells↑) связана с тем, что команда тратит больше доли усилий на багфиксы и меньше - на развитие
- Чем больше "feature work" у команды, тем реже инженеры говорят, что техдолг их тормозит
- "Архитектура <-> недовольство" во многом проявляется через рост багфиксов: когда вы живёте в поддержке, техдолг становится осязаемым

Отдельно стоит отметить, что исследование нашло корелляцию, но это не причинно-следственная связь. Но это частая картина для сложных методологий исследований, что через a/b тест не катанешь.

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

P.S.
Я рассказывал про многие статьи ребят из Google, у них отлично выстроена методология и есть очень интересные результаты - подробнее можно посмотреть в подборке из двух постов: 1 и 2

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

Как взять идеи Google и построить себе похожий контроль качества архитектуры (Рубрика #Architecture)

В прошлом посте мы разбирали whitepaper от ребят из Google "Understanding Architectural Complexity, Maintenance Burden, and Developer Sentiment - a Large-Scale Study". А сейчас я хотел бы поговорить про практические шаги, что можно сделать у себя в компании, если вы не Google, но тоже хотите контролировать качество архитектуры и размер техдолга.

1️⃣ Сформулируйте "maintenance burden" так, чтобы его можно было считать
Самый практичный вариант - доля багфиксов vs фич за период:
- % задач типа Bug в трекере
- % PR/коммитов, привязанных к Bug
- % LOC (или хотя бы файлов), изменённых ради Bug

2️⃣ Соберите минимум данных (обычно уже есть)
- Git/PR-логи: кто/когда/что менял (changed files, размер).
- Issue tracker (Jira и т.п.): тип задачи (bug/feature), компонент/сервис, команда.
- Dependency graph: зависимости между пакетами/модулями/сервисами (из build graph, import graph, API calls).
- Active coding time по задачам или DAT (Diff Authoring TIme), которым так хвалилась запрещенная в России Meta и про который я уже рассказывал
- Если нет Active Coding Time, то начните с прокси: lead time PR, время ревью, размер batch’ей (а потом все-таки соберите ACT)

3️⃣ Архитектурные метрики: начните "дёшево", потом усложняйте
Метрики из приведенного выше whitepaper конечно крутые, но сложные. Я говорю про
- Propagation Cost (PC): насколько широко расползаются изменения по зависимостям
- Decoupling Level (DL): насколько хорошо система декомпозирована на независимые модули
В академии есть DV8 от авторов оригинального исследования (Yuanfang Cai, Rick Kazman) или условный Sonar в качестве коммерческого инструмента. Но для старта хватит
- Отслеживать циклы на уровне модулей/сервисов (SCC)
- Считать fan-in/fan-out, транзитивный fan-out
- Отслеживать co-change кластеры: файлы часто меняются вместе, хотя "по архитектуре" не должны
По правилу Парето мы так найдем 20% проблем, что приносят 80% боли

4️⃣ Склейте всё в регулярный отчёт (по кварталам/месяцам)
На уровне repo/сервиса/команды:
- Тренд coupling/циклов/co-change
- Тренд bugfix ratio
- Микро-опрос 1 вопрос раз в квартал: "насколько техдолг/сложность мешали вам работать?"
Важно искать не виноватых, а проблему в системе: high coupling + растущий bugfix ratio = кандидат #1 на тех-инвестиции

Если воспользоваться этим алгоритмом, то у вас будет набор карт на руках, с которыми никакой техдолг не страшен
- У вас будут аргументы для рефакторинга в цифрах (и разговор с бизнесом пройдет на понятном им языке)
- У вас будет внятная приоритизация: какие 2–3 hotspot’а чинить в первую очередь
- Вы увидите ранние сигналы деградации: поймаете тренды до того, как команда уйдёт в вечный багфикс
- Вы улучшите DevEx и скорость доставки фич как следствие

Но важно не облажаться и не наступить в анти-паттерны
- Не превращайте метрики в KPI людей/команд - будет гейминг
- Не ставьте одинаковые абсолютные пороги по метрикам - нужны базовые нормы "что ок" для вашего домена;
- Не пытайтесь получить одну метрику техдолга - он многомерен и метрики - это сигнал, а не приговор. Дальше нужны дизайн‑ревью и инженерная оценка найденных проблем

Если бы я делал это в компании, то попробовал бы
- Катануть пилот на 10–20 репозиториях/сервисах
- Собрал бы базовую панель метрик, перечисленных выше
- Подождал сбора результатов, напрмер, квартал
- Дальше сделал бы точечные рефакторинги (благо сейчас рефакторинг становится сильно дешевле, если его делать с помощью AI-инструментов)
- Сравнил бы "до/после" по bugfix ratio и скорости доставки
- Если бы метрики улучшили, то планировал бы дальше раскатку

В общем, с точки зрения алгоритма примерения тут нет никакого rocket science, но дьявол кроется в деталях:)

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

[1/2] OpenClaw Creator: Why 80% Of Apps Will Disappear (Рубрика #AI)

Интересное и короткое интервью Peter Steinberger, создателя OpenClaw (недавно перешедшего в OpenAI) проlocal-first персональных агентов и то, как они могут "съесть" большую часть привычного софта. Интервью у него брал Raphael Schaad, Visiting Partner в Y Combinator; основатель/CEO Cron (проект купил Notion). Ниже представлены основные инсайты

1️⃣ Local-first агент ≠ «ещё один чат-бот»
Агент живёт на вашей машине/вашем сервере, поэтому может быть шлюзом между чатами и вашими инструментами: файлы, shell, браузер, интеграции - "всё, что может пользователь на компьютере". Это принципиально другой класс возможностей по сравнению с облачным ассистентом. Забавно, что создатель Manus AI рассказывал о том, как они ушли от локального агента в браузере в облако, чтобы отвязаться от локальной машинки:)

2️⃣ Магия - это tool-use + выбор кратчайшего пути
Самый показательный кейс из интервью: голосовое сообщение внезапно само транскрибировалось, хотя функциональность "явно не кодили заранее". Агент сам сделал следующие шаиг
- Определил формат аудио по заголовку (даже без расширения)
- Перегнал через ffmpeg
- Не стал ставить локально Whisper, а выбрал быстрый путь - отправить аудио в speech-to-text API через curl, потому что так быстрее получить результат

В итоге, по мнению Питера конкурентное преимущество смещается от "самой умной модели" к инструментам, оркестрации и данным/памяти пользователя

3️⃣ "80% приложений исчезнет" - речь про приложения‑контейнеры данных
Смысл тезиса не в том, что UI умрёт. А в том, что приложения, чья основная функция - ввод/хранение/менеджмент данных, становятся избыточными, если агент:
- Сам собирает контекст (файлы/логи/фото)
- Пишет/читает из хранилищ
- Планирует/напоминает
- И делает результат без отдельного “перехода в приложение”.

Отдельно проговаривается идея, что выживут продукты, сильно завязанные на специфическое железо/сенсоры.

4️⃣ Главная ценность и риск - "память" агента
Если агент становится персональным, то его “memory” - привычки, контекст, история действий, локальные файлы - это новый приватный периметр. В отчёте подчёркнуто, что такие memory‑файлы могут быть "более приватными", чем условная поисковая история. Также упоминаются файлы вроде SOUL.md / AGENTS.md / TOOLS.md как часть "инжектируемого" контекста в workspace.

5️⃣ CLI как универсальный "адаптер" для агента
Одна из инженерных мыслей, что противоречит текущему вектору: вместо специальных протоколов интеграций агентам часто достаточно обычных человеческих инструментов - CLI. Если есть --help, примеры и предсказуемые команды - агент часто "разберётся". В отчёте это подано как практичный вектор (в т.ч. обсуждение CLI vs MCP).

6️⃣ Security - не "потом", а сразу
Агент, который читает чаты/веб и имеет доступ к shell/файлам/браузеру, резко расширяет поверхность атаки. В отчёте много акцентов на базовых контролях: threat model, изоляция, allowlist, аудит, sandboxing, политики для DMs, защита от prompt injection.

В продолжении обсудим, а что из этого интервью могут почерпнуть инженеры и технические руководители

#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture

[2/2] OpenClaw Creator: Why 80% Of Apps Will Disappear (Рубрика #AI)

Интервью было очень интересным и прорывным, но всегда интересно, а как перевести эти идеи в практическое русло.

Для разработчиков отсюда можно извлечь следующее
Если ваш продукт можно выразить как операции - агент сможет "съесть" ваш UI. Поэтому фокус смещается на “agent-ready интерфейсы”:
- Tool-first мышление: превратите ключевые фичи в чёткие операции (CRUD/поиск/экспорт/триггеры), которые можно дергать напрямую. Минимум - хорошая CLI или SDK + примеры.
- Документация "как для агента": понятные help‑тексты, примеры входов/выходов, ошибки, ограничения, idempotency там, где возможно.
- Нормализуйте “опасные входы”: prompt injection и неожиданные действия - это базовый режим, если агент читает DMs/почту/веб. Тестируйте это как часть фичи, а не как edge case.
- Локальная память = новый тип "секрета": думайте, что именно агент сохраняет, где лежит workspace, как чистится и бэкапится.

Если хочется посмотреть а как это работает, то можно поднять OpenClaw локально/на тестовом сервере, подключить один канал, включить pairing/allowlist, запретить опасные tool‑группы и прогнать 3 сценария: "поиск/сводка", "операция с файлами", "задача через браузер". А дальше уже оценить насколько это удобно/безопасно/перспективно.

Что это значит для техлидов и технических руководителей
- Пересоберите threat model: "агент с инструментами" - это RPA + LLM + доступ к секретам. Нужны политики: где хранятся ключи, какие каналы доверенные, какие действия требуют подтверждения, как устроена изоляция сессий/пользователей.
- Вводите governance по памяти: ретеншн, классификация данных, экспорт/удаление, audit trail - это станет не менее важным, чем логирование микросервисов.
- Контроль экономики агентности: агентные циклы могут неожиданно "жечь" стоимость из-за контекста/памяти/инструментов. Нужны лимиты, бюджеты, режимы, мониторинг.
Стратегия продукта: если тезис про "80% apps" хотя бы частично верен, дифференциаторы смещаются в
(а) данные/память
(б) безопасные интеграции
(в) доверие/комплаенс
(г) hardware/sensors/сообщества

#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture

Дискуссия с Гришей Скобелевым про подготовку к System Design Interview (Рубрика #Architecture)

На этих выходных мы с Гришей из клуба { между скобок} поговорили про подготовку к System Design Interview и про то, как я дошел до жизни такой, что собрал сайт system-design.space. Основные моменты, что мы успели обсудить следующие
​
- Книга по System Design быстро устаревает: паттерны и требования меняются, а живой сайт можно непрерывно допиливать под практику, а не под "вечную теорию"
​- Ожидания на интервью сдвигаются от "знаешь ли ты стандартный набор сервисов и buzzwords" к умению думать как архитектор: трезво выбирать компромиссы, задавать вопросы, формализовывать требования
- Разобрали типовые ошибки кандидатов​
- - Сразу рисовать «кубики и стрелочки» без уточнения ограничений,
- - Оптимизировать за пределами реальных bottleneck’ов
- - Заучивать шаблоны задач вместо понимания инвариантов (consistency, durability, latency budgets и т.д.)
​- System Design интервью на самом деле проверяет не "знаешь ли ты Kafka", а: как ты принимаешь решения, как разговариваешь с продакт менеджером, как эволюционируешь систему от MVP до сложной архитектуры
​- Разница между "рисованием кубиков" и архитектурным мышлением: во втором случае ты всегда привязываешь решения к пользовательским сценариям, нагрузке, отказоустойчивости и стоимости владения, а не просто перечисляешь модные технологии
​- Для senior/staff обязательны темы: масштабирование хранения и вычислений, очереди и асинхрованная работа, кэширование, консистентность, observability, эволюция схемы данных и rollouts, а также работа с неопределённостью и неполными требованиями
​- Готовиться нужно не "по чек-листу задач", а системно: строить свой набор инвариантов и шаблонов мышления, прогонять реальные кейсы, а не просто зубрить решения.
​
Если говорить про инсайты для руководителей, которыми можно поделиться, то
- Интервью по SD стоит перестраивать с "угадай сервис" на разбор реального кейса: дать неполные требования, посмотреть, как кандидат уточняет, режет scope и развивает архитектуру итеративно
​Хорошее SD-интервью - это мини-совместное проектирование: вы вместе выходите хотя бы к первому адекватному приближению системы, а не к идеальной картинке из учебника.
​- Стоит явно формализовать, какие уровни архитектурного мышления вы ждёте от middle/senior/staff, и дать людям прозрачную лестницу роста (в идеале - с примерами на внутренних кейсах).
​- Вместо того чтобы ждать от команды "чтения книг по SD", проще дать живую базу практик, чек-листы и разборы постмортемов - то есть institutional knowledge, а не набор ссылок на классические книги.
​
#SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering

Laravel Origins: A PHP Documentary (Рубрика #Engineering)

Интересный документальный фильм про фреймворк Laravel, который по моему ощущению занял нишу Ruby on Rails, но вместо Ruby тут языком выступает PHP. В фильме присуствуюте ключевые люди и именно они рассказывают историю развития проекта. Например, одна из главных ролей за Taylor Otwell, что создал Laravel и сейчас выступает как BDFL фреймворка ("benevolent dictator for life"), также там есть Jeffrey Way (автор образовательного ресурса Laracasts), Dayle Rees (автор первых книг по Laravel) и другие.

Мы видим последовательное развитие истории:
- Сначала жизнь и работу Тейлора в Арканзасе, а дальше старт проекта Laravel от caravel, где была изменена одна буква в названии коробля
- Ранний рост проекта: первые GitHub‑звезды, переход UserScape на Laravel, полугодовой период, когда Тейлор фактически фуллтайм развивал фреймворк в рамках работы
- Формирование экосистемы: очереди, миграции, пакеты, затем вокруг ядра вырастают Laravel Forge, Envoyer, Spark, Nova, Vapor, которые закрывают полный цикл от разработки до деплоя.
- Комьюнити и медиа: книги Dayle Rees, Laracasts, Laravel News, агенства вроде Tighten, появление Tailwind CSS - как побочный эффект культуры "делать инструменты для других девелоперов"
- Конференции и культура: Laracon в США, Европе, Австралии, "Laracation" как неформальные поездки, ощущение "как любимая группа в городе", а не корпоративное мероприятие.
- Социальный эффект: карьеры тысяч людей, компании уровня Apple, госструктуры США и крупные бренды (например, Winter Olympics API, Boston Celtics) на Laravel.

Ключевые инсайты из фильма такие
- Видно, как Laravel вырос как решение собственных болей Тейлора - поэтому факторы скорости, продуктивности и "fun to use" стали ядром продуктового видения, а не были выстроены от маркетинга
- Сильное, единое видение ("benevolent dictator for life") позволяет фреймворку быть цельным, последовательно эволюционировать и избегать scope creep и дрифта базовых концепций
- DevEx как продукт: документация, выразительный синтаксис, консистентная эстетика кода (вплоть до формата комментариев) - сознательно воспринимаются как конкурентное преимущество
- Коммерческая экосистема не подменяет open‑source, а дополняет его: SaaS‑продукты ведёт команда, а Тейлор фокусируется на ядре и R&D, что сохраняет качество фреймворка

Отдельно видно, что коммьюнити вокруг Laravel сложилось крепкое и отсюда тоже можно извлечь инсайты
- Осознанный дизайн культуры: с первого дня цель - "дружелюбное, chill, welcoming" сообщество, где люди чувствуют принадлежность и не боятся задавать вопросы
- Конкуренция за вклад "в плюс миру": участники соревнуются в количестве бесплатных материалов, тулов и библиотек, а не в токсичности или статусе
- Инклюзивность как практическая работа: создание Larabelles и других инициатив для вовлечения всех в профессию и коммьюнити
- Сообщество как социальный капитал: люди обсуждают, как Laravel поменял их жизнь

Для технического руководителя это напоминание о том, что
- Хороший фреймворк - это не только API, но и эстетика, документация, DX и осознанное лидерство; это так же важно, как техническая "чистота"
- Сильное ядро + продуманная коммерческая надстройка позволяют маленькой команде (порядка пяти человек) поддерживать огромную экосистему и влиять на индустрию
- Сообщество и образовательная инфраструктура (типа Laracasts) критичны для adoption не меньше, чем сам код, особенно в мире, где каждые пару лет приходит новая волна девелоперов
- Инклюзивная, по‑настоящему дружелюбная культура вокруг технологии может стать решающим фактором её популярности и longevity, а не только технические фичи

#Documentary #Software #Architecture #Leadership #Culture #Management

How to be a CEO when AI breaks all the old playbooks | Sequoia CEO Coach Brian Halligan (Рубрика #Management)

Интересная серия подкаста Лённи, в котором к нему пришел Брайан Холлиган, со‑основатель и экс‑CEO HubSpot. Они обсудили каким становится лидерство и бизнес в эпоху ИИ: как нанимать, расти и продавать, когда старые плейбуки трещат по швам. Брайан был CEO 15 лет, а теперь выступает как внутренний CEO‑коуч в Sequoia и ведёт подкаст про лидеров Long Strange Trip.

Основные инсайты примерно такие

1️⃣ Стартовая компанию проще, чем когда‑либо; масштабировать - сложнее, чем когда‑либо
ИИ и облака кратно удешевили запуск, поэтому число компаний взлетит в небеса в ближайшие 10 лет, но шум и конкуренция делают масштабирование и дифференциацию всё труднее

2️⃣ Работа CEO → бесконечный найм и орг‑дизайн
"Взрослые CEO" тратят до половины времени на рекрутинг, интервью и конструкцию exec‑команды, а не на продукт или операционку.

3️⃣ Все ужасно переоценивают своё умение интервьюировать
Инстинкт "мне кажется, он классный" почти ничего не стоит; куда важнее жёсткие blind‑references, рабочие сессии с кандидатом и правильные вопросы про повторный найм

4️⃣ Нужно нанимать "острых" (spiky), а не консенсусных людей
HubSpot перестал использовать консенсус в виде "3/4 от всех голосов" и начал брать людей с сильными плюсами и заметными минусами; это улучшило хит‑рейт

5️⃣ Люди из bigtech почти всегда не заходят компаниям на ранней стадии
Найм из Microsoft/Salesforce/Google на компанию в 50–500 человек часто даёт "импеданс‑мисмэтч": ожидания процесса и ресурсов не совпадают с реальностью стартапа

6️⃣ Базовый плейбук - команда как Red Sox‑2004: микс homegrown и пары "звёзд"
Большая часть менеджмента вырастает изнутри, плюс несколько дорогих ветеранов, а не "ковёр‑самолёт" из McKinsey/FAANG.

7️⃣ Фреймворк LOCK(S) для оценки фаундеров
- L (lovable): хочется за этим человеком идти, он вдохновляет последователей
- O (obsession): глубоко одержим проблемой, сильный founder–market fit
- C (chip on the shoulder): идиома про "затаить обиду", когда человек чувствует себя оскорбленным из-за прошлого оскорбления или предполагаемой несправедливости, тогда появляется внутренняя мотивация "доказать". Тут интересно, что я раньше не знал эту идиому и она мне нравится (кажется, что я лучше всего работаю, когда у меня есть такое чувство)
- K (knowledge): глубокое знание домена
- S (student): фанатичный студент игры, копает и историю, и современность

8️⃣ CEO может стать не любой, но одновременно и ими не только рождаются
Есть редкие "5‑tool CEOs", которые умеют кодить, продавать, вдохновлять, иметь вкус и видение (пример - Брет Тейлор), но большинству приходится добирать умения: обратная связь, детектор BS, вдохновение людей.

9️⃣ Боль №1 у фаундеров - давать фидбек и менять ранних сотрудников
Самое тяжёлое - сказать кофаундеру/раннему head of X: "ты больше не управляешь, ты - визионер/CTO, а мы нанимаем операционного лидера над тобой" и сделать это экологично, но жёстко

🔟 ИИ уже сильно бьёт по разработке и саппорту, но не по enterprise продажам
Кодинг, support, legal уже трансформируются, а enterprise‑продажи, где нужно доверие между двумя людьми, будут последними в белых воротничках, кого заменит ИИ.
Но вообще у всех будут свои персональные агенты, подключённые к почте, календарю и заметкам, которых можно звать в митинги как активного участника, а не просто как запись

Ну и финально про воронку go-to-market, которая становится ориентирована на агентов
- Воронка "Google → сайт → demo" сменится на "Gemini/Claude/ChatGPT → глубокое исследование → уже образованный клиент". Сайт станет менее важен
- На сайте будет "всезнающий аватар", который понимает продукт, цены и контекст клиента, ведёт беседу и пишет в CRM
- У сейлза на созвоне будет свой "аватар", который знает всё о продукте и клиенте и помогает отвечать в реальном времени

В продолжении я расскажу про то, а что можно почерпнуть из этого выступления инженерам и техническим руководителям.

#Leadership #Management #Software #AI #ML