Выпуск закрытого дайджеста Lenny's Newsletter: лучшие обсуждения недели из Slack-комьюнити продактов и фаундеров.
👋 Привет! Это новый выпуск ✨ Community Wisdom ✨ — email только для подписчиков, выходит каждую субботу и собирает самые полезные обсуждения из нашего закрытого Slack-комьюнити.
Большое спасибо спонсору комьюнити этого месяца — Clerk. Clerk позволяет мгновенно запустить аутентификацию продакшн-уровня — без инженерных спринтов, сожжённых на обвязку логина и регистрации. Мы даём твоему приложению всё необходимое: готовые компоненты, организации для B2B-мультитенантности, встроенный биллинг подписок и многое другое — плюс поддержку MCP-серверов, чтобы AI-агенты могли аутентифицироваться и действовать от имени твоих пользователей. Стройте продукт, а не слой авторизации. Узнать подробнее.
Ближайшие митапы от участников комьюнити — кликай по названию города, чтобы записаться:
Не нашёл свой город и хочешь организовать митап? Напиши в личку @Riya в нашем Slack. Подробнее — здесь.
Head of Growth (Anthropic): «Claude на этом этапе растит себя сам» | Amol Avasare: YouTube, Spotify и Apple Podcasts
Я собрал собственный Slack-инбокс. Это оказалось проще, чем ты думаешь. | Yash Tekriwal (Clay): YouTube, Spotify и Apple Podcasts
В: Ищу лучшие практики по вайб-кодингу в команде. У нас в компании мы сейчас работаем через Claude Code и довольно автономно: у каждого свой репозиторий на GitHub и деплои на Vercel, отдельно от инженерной команды. Хочется понять, как эффективнее сотрудничать и лучше работать вместе как группа. Если видели воркфлоу или сетапы, которые хорошо заходят в таком контексте, буду очень признательна за советы. ↗ — Alice Roussel
Aaron Nichols: Мы сталкиваемся ровно с тем же у себя. Судя по описанию, вы пользуетесь этими инструментами, находясь за пределами инженерной организации. Вам важнее наладить совместную работу со своими коллегами по команде или с инженерами? Здесь появляются новые способы работать, техники и инструменты, но многое по-прежнему сводится к тому, что экспериментируешь сам. Поведение команды тесно связано с тем, какие инструменты доступны и используются, поэтому сейчас самый распространённый подход — сначала подумать, как ты хочешь работать, а потом найти или собрать инструменты, которые этот способ поддерживают. И, мне кажется, всё это ещё и меняется в зависимости от того, над каким материалом вы вместе работаете. Совместная работа над документами для людей — это одно, а если ты хочешь, чтобы в ней ещё участвовали агенты, — уже другое. А совместная работа над кодом между людьми в команде, по-моему, становится только сложнее — если, конечно, не идти в сторону парного программирования. В общем, переменных очень много.
Несколько вещей, которые хорошо работают у нас:
У нас это в основном про то, чтобы с помощью агентов выкладывать то, над чем мы работаем, в общее место — чтобы остальные могли задавать вопросы и подключаться.
Общее пространство для информации — ключевая штука, но оно очень быстро зашумляется — точно так же, как кодовая база, когда туда начинают лезть агенты. В идеале люди используют агентов, чтобы переваривать изменения и отфильтровывать то, что лично им интересно. Если команда большая — это уже челлендж. Мне кажется, какие-то системы для более крупного общего контекста с governance сейчас есть, но мы почти ничего подходящего не нашли — и сейчас сами строим кое-что в этой области.
Про безопасность — отдельно отмечу: это реальный риск, которому надо уделять внимание. Есть очевидные опасения насчёт того, что агенты могут вести себя неправильно, но сейчас ещё и огромный риск — атаки на цепочку поставок, когда все собирают софт прямо у себя на десктопе. Это та проблема, на которую я бы выделил сильных людей и решал её единообразно, потому что решение очень контекстное и должно поддерживаться на уровне организации. Несколько вещей, о которых стоит подумать:
Хорошая новость в том, что агенты с системой общего контекста и какой-то сигнализацией на самом деле становятся очень мощным инструментом прямо на десктопе — они помогают и распространять информацию, и следить за безопасностью. Можно раздавать инструкции, как настраивать окружения разработки, чтобы закрывать эти проблемы. Можно автоматически проверять системы на соответствие требованиям и т. д.
Вторая большая штука, которую мы видим в организациях, — у людей нет времени на то, чтобы учиться. Если ты в организации, где доставка важнее, чем освоение этих инструментов, это реально тяжело. Нужно выделять пространство на обучение, эксперименты и на «потерянную работу», которая этому сопутствует. Выделенное время, когда у всей компании или команды «нет митингов», плюс регулярные шеринг-сессии о том, что у кого работает, обычно очень помогают быстро прокачиваться. Ещё полезно найти человека, который сможет ходить по команде, разблокировать людей и помогать им преодолевать барьеры в работе с этими инструментами. Он же может помогать с задаванием стандартов и сборкой инструментов, про которые я писал выше.
Marshall: Круто! Мы проходим через похожее упражнение, и мне интересно посмотреть, какие паттерны проявятся на разных уровнях — лично, в команде, в компании и в индустрии в целом.
Сильно поддерживаю мысль Aaron о том, что важно экспериментировать самому и смотреть, что из этого вырастает, — каждая команда разная. Мне нравится подход «build → friction → fix», когда паттерн проявляется сам собой: строишь, явно называешь трение, просишь Claude его починить… и по кругу. Я писал о своём опыте с этим подходом здесь. Какие трения вы у себя в команде ощущаете вокруг эффективной совместной работы?
Alice Roussel: Это супер-полезно, огромное спасибо. Уточню: для меня главное — это кросс-командное сотрудничество за пределами инженерки. Нас недавно попросили перейти на AI-first по всей компании, и мне очень не хочется получить ситуацию, когда 100+ человек вайб-кодят каждый в своём углу. Несколько конкретных трений, которые я уже вижу:
Я всё больше склоняюсь к тому, что решение — не в том, чтобы продавливать процессы, а в том, чтобы создавать: общий слой (доки, компоненты, контекст в .md-файлах), лёгкие паттерны сотрудничества (когда лучше строить в одиночку, а когда — консолидироваться) и безопасные пространства для обучения (например, playground-сессии для онбординга). Интересно, видел ли кто-то, как командам в таком формате удаётся балансировать между индивидуальной скоростью и коллективным рычагом.
Sam Montoya: Безопасность — огромная проблема, которую я видел в самых разных формах: секреты (главное — не повторить историю Anthropic), ивентинг, hardening, eval harness, да даже prompt injection — у людей и у практик безопасности здесь большой пробел. А что касается адопции — это всё сводится к change management. Просто сказать, тяжело сделать. В прошлой компании я собрал AI Guild и прогонял все AI-инициативы через неё: SOP, раскатки, обучение и всё остальное.
Gautam Banerjee: Есть пара идей. Я использовал GitLab Pages (в GitHub, кажется, можно так же):
У нас есть набор Python-скриптов, которые вытягивают данные из Jira и Slack, собирают merge-и из репозиториев, считают метрики и генерируют единый HTML-файл — самодостаточную веб-страницу с графиками и таблицами.
Файл автоматически публикуется по URL, который может открыть любой в команде, а раннер при желании может кидать в Slack саммари за прошлую неделю или за прошлый день.
Сам «паблишинг» — это бесплатный хостинг, встроенный прямо в GitLab (и GitHub). Никаких серверов держать не надо.
Каждый день в 8 утра:
GitLab автоматически запускает наши скрипты
→ скрипты тянут свежие данные из Jira + Slack + GitLab
→ скрипты генерируют HTML-отчёт
→ GitLab публикует его как веб-страницу
→ команда заходит по URL и видит свежий дашборд.
С радостью покажу пример в личке.
Ashwin: Добавлю к тому, что сказал Gautam: если у вас уже есть Jira, попробуйте Atlassian Rovo. Он поможет превращать любые рабочие элементы из Jira в код.
Priya Mathew Badger: По поводу того, что часть людей уже внедрили, а многие — нет: мы экспериментируем с ежеквартальным выделенным днём AI-обучения, чтобы всех поставить на Claude Code и пройтись по personal OS, настройке контекста, созданию skills и т. д. С радостью поделюсь, как пойдёт, — пишите в личку.
В: Нанимающие менеджеры, удалось ли вам найти рабочий способ прокачивать навык собеседования в своей команде? Речь не о том, как собеседовать в конкретной компании, а о том, как на самом деле оценить, справится ли кандидат с работой, и как задавать вопросы, которые вытаскивают реальный сигнал, а не отрепетированные ответы. Процессы найма становятся всё длиннее: больше раундов, больше людей вовлечено. Но больше интервью не значит более качественные решения, если никто в панели не умеет оценивать навыки. В какой-то момент ты просто собираешь всё больше и больше мнений «на вайбе». Кто-нибудь разобрался, как последовательно донести этот навык до тех, кто нанимает? ↗—Dana Daniele
Daniel Heo-Lu: В крупных компаниях часто практикуют шадоуинг и обратный шадоуинг — чтобы можно было увидеть интервью в действии и самому потренироваться. Ещё мне очень помогают явные критерии оценки, где прямо прописано, что считается плохим ответом, что хорошим, а что — «хорошо для более сеньорного IC».
Вот пример критериев оценки, которые я недавно написал для одного интервью, которое мы переработали:
Эти критерии заточены под наш конкретный вопрос, но идея, думаю, понятна.
Miroslav Pavelek: Первый шаг — есть ли у вас вообще письменный фреймворк или матрица, по которой вы оцениваете навыки? Когда мы с этим разбирались, всё сводилось к шадоуингу и обмену заметками, включая саму матрицу (мы называли её скоркартой). После нескольких совместных интервью, если мы видели, что оценки сходятся, то отпускали более джуниорного коллегу вести интервью самостоятельно.
Daniel Heo-Lu: На 100% согласен!
Dana Daniele: У нас матрицы нет — ты сам её составлял? И прикладываешь ли список вопросов, которые с этой матрицей стыкуются?
Daniel Heo-Lu: Для меня скоркарта и критерии оценки идут рука об руку. Да, я составлял её сам. С вопросами у меня такая схема: есть основной вопрос (stem) и несколько уточняющих (probes). Stem'ы обязательны, probes — по ситуации, это подсказки, как копнуть глубже. На 45-минутное интервью я беру примерно 3 stem'а, чтобы осталось время на вопросы кандидата. На скриншоте — пример stem'а и трёх probe'ов к нему.
Дальше я смотрю на скоркарты по каждому интервью и проверяю, что весь цикл в целом покрывает то, что нам нужно. Для меня это баланс между кейс-стади, поведенческим/коллаборационным блоком и экспериментами — чтобы каждого типа было достаточно. Технические навыки мы трогаем поверхностно, а аналитику — совсем чуть-чуть. Хотели бы подтянуть и то и другое, но оставляем пока так, чтобы не превращать найм в миллион раундов.
Ben Erez: Я недавно выступал с докладом о том, как оценивать AI-грамотность на PM-интервью, но этот фреймворк вполне можно расширить и на проектирование всего процесса интервью — отталкиваясь от того, что вам действительно важно.
В: Лидерские офсайты бывают либо великолепными, либо абсолютно беспросветными. Чего, на ваш взгляд, не хватало на последних трёх офсайтах, где ты побывал?.. ↗—Adam Thackeray
Joshua Herzig-Marx: Настоящей работы. Почему-то многие убеждены, что если заняться «игрушечной», ненастоящей работой, это улучшит то, как они работают вместе по-настоящему. Это всё равно что горнолыжная команда поедет кататься на санках, чтобы стать сильнее. Или хоккеисты будут играть в настольный футбол. Весело? Да. Узнать друг друга получше? Почему нет. Реально улучшить результат? Ничуть. Если хочешь научиться лучше работать вместе — тренируйся делать именно настоящую работу. (И я имею в виду не просто «делать», а именно тренироваться: составить план, сделать, разобрать, что получилось, повторить. И хорошо, если есть коуч.)
Aaron Nichols: Чаще всего я вижу, что упускают подготовку — никто не определяет заранее, какого сложного результата эта группа не может достичь, пока все не соберутся в одной комнате, и не делает достижение этого результата приоритетом офсайта. Ещё я вижу, что многим офсайтам не хватает нормальной фасилитации со стороны человека, который сам не является участником обсуждаемых вопросов. Я вёл такие сессии для экзекьютив-команд, и там всегда есть план, который по ходу приходится подстраивать. Всплывают новые темы, разговоры затягиваются — и нужен кто-то, чей единственный фокус в том, чтобы время уходило на правильные разговоры ради этого критического результата. Никто из самих участников разговора с этой ролью нормально не справится. И это меняет всё: ты можешь плыть по течению изменений и всё равно прийти к цели. Обычно все эти метания «кого звать, кого не звать» идут оттуда, что заранее не сформулированы ни тема, ни ожидаемый результат. Как только это ясно — обычно и так понятно, кто должен быть в комнате.
Joni Hoadley: Собрать правильный состав. Иногда компании зовут слишком много людей. Иногда — слишком мало. В обоих случаях, как правило, в комнате оказываются те, кому там быть не стоило, и не оказываются те, без кого обсуждение теряет смысл.
Ashwin: У офсайта должна быть одна из трёх целей: сплочение команды, формирование видения или организационная синхронизация. Пытаться смешать всё три в один котёл — плохая идея. Разведите их по разным дням, сделайте отдельные треки. Например, вот программа, которая у нас хорошо себя показала: в понедельник все прилетают, вечером — неформальные посиделки с напитками. Вторник — организационная синхронизация между руководителями. Среда — день сплочения команды, посвящённый совместным активностям. Четверг — кристаллизация видения по каждой группе. Утром в пятницу презентации, и в начале второй половины дня все разъезжаются.
Хорошей и продуктивной недели 🙏
Если кому-то из твоего окружения будет полезна эта рассылка или сообщество — подумай о том, чтобы подарить им подписку 💞 Доступны групповые скидки, варианты подарка и реферальные бонусы.
Искренне твой,
Kiyani 👋