🚀 Марсианин

Это лучший фильм и книга, кажется, которые я читал!
Я был в восторге от фильма, но от книги, получил удовольствия раз в 5 больше.

Почему?
Тут все просто, принцип действия совпадает с теми базовыми вещами, что я пытаюсь всем и всегда донести.
1.
Шути и улыбайся, как бы трудно не было
2.
Если в твоей ракете нет крыши, будь первым космонавтом без нее
3.
Сложная проблема? Шаг за шагом, действие за действием и у вас получится.

Решаешь одну проблему. Потом следующую. А потом ещё одну. И если решить достаточно - вернёшься домой

Ну и вперед к книге!

Если бы NASA наняло стендапера-ботана, чтобы он рассказал, как не сдохнуть на Марсе, получился бы «Марсианин».
Энди Вейр написал книгу про то, как один упёртый ботан переводит смерть в список задач и решает одну проблему за другой.

Основная идея
Выживает не сильнейший, а тот, кто умеет:
1. Не паниковать.
«Окей, я остался один на Марсе. Ладно, давайте подумаем…»
2. Декомпозировать.
Еда → вода → энергия → связь → транспортировка → дом.

3. Находить решения в пределах физики и говно-ресурсов.
Тут нет магии. Только химия, математика и бесконечное «ну я щас попробую». И да, из говна и палок собираешь то, что тебе нужно

Почему книга для нердов?
Потому что Вейр играет в одну игру - интеллект как суперсила, а не мечи-драконы.
И да, юмор Уотни - это отдельный эстетический кайф.
Чувак троллит красную планету, слушая диско, которое он тоже не наводит.

Конкретные моменты, которые делают книгу культовой
1) Выживание = непрерывный инжиниринг
Каждая проблема - как «incident».
Нужен кислород? - берём химреактор.
Нужна картошка? - создаём полевую фермочку.
Нужен путь к MAV? - придумываем способ, который порушит половину планеты, но работает.
2) NASA как компания мечты (и стыда)
Вейр показывает NASA как 1) бюрократическое чудовище, 2) но при этом - организацию, способную на невозможное, когда сроки горят. В общем, типичная корпорация.
3) Командная работа без команды
Уотни и NASA вообще не общаются огромное время.
Но книга показывает: эффективная система - это когда все решения спроектированы таким образом, что любой может справиться с их починкой без сложных инструкций. И что еще важнее, из базовых кубиков можно собрать что-то сильно сложнее.

4) Настоящая инженерия
Никаких чудо-технологий.
Только физика, химия, агрономия, механика и огромное терпение.

💡 Главный смысл книги
«Марсианин» - это книга о том, что человек может победить даже абсолютную пустоту, если будет:
• мыслить системно,
• принимать решения быстро,
• не бояться ломать и чинить,
• и, главное - не терять чувство юмора, когда у тебя отказывает очередная жизненно важная система.
Это книга про силу человеческого упорства, замаскированную под survival comedy.

«Разбилось → починил → взорвалось → сделал лучше → чуть не умер → ну зато смешно».

Я прямо обожаю и вдохновляюсь каждый раз, когда читаю книгу или смотрю фильм!

P.S. На фото Демыч в пустыни Иордании под впечатлением от фильма не снимает скафандр 🧑‍🚀

Ну и шутки, шутки!!! Разве это не про каждого инженера, трогающего чужое API???😁

Я делаю с этим оборудованием такое, что технический директор NASA бросил бы в меня стул

Я создаю внутри герметичного помещения облако взрывоопасного газа.
Что может пойти не так?
Ладно, не отвечайте

🔥 - если смотрел/читал и зашло
❤️ - если забрал в бэклог
🦄 - если читал/смотрел и не зашло

Upd, только что закончил еще одну его книгу и вот откуда все эти шутки в стиле нердов (ботанов):

Энди Вейер состоялся как инженер-программист, но успех дебютного романа «Марсианин» позволил ему воплотить мечту – посвятить себя литературному творчеству.

Нате вам СДВГшники еще удар!

Можно теперь прямо на телефоне через нативное приложение код писать!

Я за 1 промпт тетрис сделал 😂

https://apps.apple.com/app/id6751496092

До сих пор не понимаю, почему эти 2 стартапа не объединились?😁

P.S. ну осталось встроить туда шортсы, мини-игры, заказ еды, рекламу и прочее. А то чем людям заняться, пока AI код генерит 😂

Upd вот вам танчики примитивные с самого простого промпта. Работают прямо в браузере https://www.lingguang.com/share/FLASH_APP-bbb4736c-2a03-45b3-8766-c674c03fc7a353

#пятничное
❤️ - если ты такой же и надо поддержать
🐳 - если ты на совещаниях как рыба в воде «молчишь»
😎 - если ты не такой и самый крутой, и сын маминой подруги

Любопытно

1. Сегодня за много лет у меня был день без встреч.

Ну как без встреч:
- всего 2 созвона по 30 минут
- 60 минут с челом, который занимается DevEx в Microsoft
- 100 минут участия в круглом столе на коференции (уже после 19:00, не понимаю, считать ли это рабочим временем).

Ощущения слегка странные.

2. Ну и окончательно добивает: мы с Наташкой сидим смотрим телек, а Демыч укладывает спать Тею❤️

P.S. Пряня тоже в шоке 😁

Сегодня один из самых теплых праздников: День матери!
С праздником, мамуль!

Спасибо за всю ту заботу, что дала мне! ❤️

Пу-пу-пуууу
Можно отрицать, можно спорить, но как будто без продуктовых скиллов и AI денег сейчас не заработать.

Почему?

Рынок меняется быстрее, чем когда-либо: конкуренция растет, стоимость привлечения увеличивается, а клиенты подходят к выбору все критичнее.
То, что работало раньше, теперь дает все меньший эффект.
Да если говорить прямо, мы все пресытились и устали от стандартных механик.

Что нужно, чтобы и бизнес, и карьере двигались?


1. Сильный продукт или компетенция
Когда ценность очевидна, продукт продает себя сам: через удержание, рекомендации, партнерства, сарафан.

Тоже самое и с вашей карьерой: если все вокруг понимают, что вы реально крутой эксперт, то и народ к вам сам потянется)

2. Скорость как конкурентное преимущество
Быстро тестировать гипотезы, анализировать данные, адаптироваться к изменениям. Создавать продукты и агентов с AI.

Можете спорить, что AI не помогает, но смеритесь.
Теперь это часть рынка.
Считаете, что вы как эксперт должны говорить другое и утверждать «да я ваш этот AI»…
Нет, не должны…
Инвесторы/работодатели хотят AI: дайте им его и делайте дальше, что считаете нужным и верным.

Под эти задачи наши ребята из Product Lab создали форматы, которые помогают и бизнесу, и специалистам расти быстрее рынка.

1. Курс “Полное погружение в продакт-менеджмент”

Подходит тем, кто хочет освоить продуктовый подход, чтобы сделать рывок в карьере.
Всем настоятельно советую. Это супер критичный скилл. Без него на уровне C-level, вас просто не поймут.

2. Лаборатория сильных продуктов

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

3. Курс “Нейросети для работы с продуктом”

Для тех, кому нужна скорость: AI помогает быстрее анализировать данные, генерировать решения, тестировать идеи, собирать MVP через вайбкодинг, создавать агентов и автоматизировать рутину.
Ну это реально скилл 2026, я вас уверяю. Никто не говорит, про продакшен решение, но вот сделать пилот😉

Чуть не забыл про промокод на 15%: BADPROJECT

Короче, вот вам гарантированно работающий прием.

🤔Кейс

вам нужно спланировать какую-нибудь миграцию крупную: с одной платформы на другую, с одной базы на другую и прочее и прочее.

🤜Решение

Все вот эти вот: подумайте, спланируйте и прочее очень плохо работают. Практически не выявляются гэпы между новым и старым решением, технологические развилки проходят по столько по скольку. Те, кто пилят новое решение сильно оторваны от того, что реально нужно.
Те, кто отвечают за старое решение мыслят: «ой, да оно там сейчас само уляжется и будет жить как жили».

🆘А работает вот это

С 1 декабря на старом все доработки запрещаем, все новые сервисы только на новой платформе, а если требуется сделать доработку старой, то, внезапно, тоже сразу переносите на новое.

И вот тут то вы и узнаете все нужные блокеры и проблемы.
И чем раньше вы так сделаете, тем будет лучше.

6 причин, почему вам, возможно, не нужен SRE-отдел
(и да, это нормально)

SRE - близкая и любимая мной тема. Если помните, то карьеру свою я начинал с того, что занимался надежностью платформы Сбербанк онлайн.
И я считаю SRE практики супер важными, но нужными далеко не всем компаниям. И да, вам, с вероятностью 90% они не нужны.

Не верите мне?

А что если один из авторов этой книжки напишет, что вам этот SRE нафиг не нужен?😉

1. Вы не Google - даже не Google 2004
У Google в 2004 было две сверх способности:
Нерешаемые проблемы. Никто не строил кластеры на сотни тысяч машин, никто не мониторил такие объемы, не деплоил такие нагрузки. Prometheus? Docker? Terraform? Их еще даже не было в скетчбуках.
Безлимитный бюджет. Можно было строить всё своё - от дата-центров до шедулеров.
Мы с вами живем в другой реальности. Хотите глобально-консистентную, шардированную базу? Платите и получаете. Хотите балансировщик уровня Google? Покупаете. Хотите CI/CD с автоскейлом? Берете SaaS.
И главный вывод:
👉🏼 Оценка «нужен ли SRE» должна быть вашей, а не импортированной из книжки
Если вам предлагают завести SRE «потому что так делают большие», бегите. Это не стратегия, это карго-культ.

2. Вы не так уж сильно цените надежность
Все компании любят говорить, что reliability - это важно.
Но реально ли?
Если ваш CEO не готов жертвовать фичами ради надежности - как это делали в Google - то говорить про «культуру SRE» бессмысленно.
Спросите себя честно:
Нужно ли вам 99.99% аптайма или и 5 минут падений раз в месяц никто и не заметит?
Что стоит выше: новый фичерелиз или инвестиции в Error Budget?
С вероятностью 90% вы выберите фичи.
SRE-команда лишь создаст краси́вую иллюзию контроля.

3. Вы сами не знаете, чем будет заниматься SRE
Самая частая причина провала SRE-инициатив - туманность мандата.
Формулировка «SRE отвечает за надежность» - это то же самое, что сказать «DevX отвечает за счастье разработчиков». Вроде звучит, но вообще непонятно, что делать руками.
Если вы не можете за 2 предложения описать:
что именно SRE делает;
где проходит граница «девы делают это, SRE делает то»;
что SRE не делает при любых обстоятельствах, то команда обречена стать помойкой для всего неудобного.

4. Вы хотите спрятать неудобные истины
SRE часто создают как костыль под культуру, а не под инженерные задачи.
Потому что главный неудобный факт звучит так:
👉🏼 Ответственность за надежность лежит на продуктовых командах. Всегда.
Но гораздо приятнее нанять «команду взрослых», чтобы они:
починили ваши алерты,
писали ваши runbook’и,
закрывали ваши пробелы в инженерной культуре,
принимали огонь за ваши архитектурные компромиссы.
SRE превращается в «группу спасателей», а продуктовые команды в пассажиров.
Это не модель Google.
Это модель «спрятать технический долг под ковер».

5. SRE может стать идеальным оправданием бездействия
Есть в индустрии комичная схема:
«Пусть SRE сделают платформу надежной… когда-нибудь… мы потом…»
Это идеальный рецепт нескончаемого технического долга.
SRE-команда очень быстро превращается в:
место, куда «сливают» задачи без дедлайна,
группу, которую обвиняют в любом падении,
удобный аргумент, чтобы не менять процессы в продуктовых командах.
А затем наступает финальный твист:
Если бы SRE не было, то нельзя было бы на них сваливать ответственность.
Но они есть и значит, можно.

6. Вы просто испугались большого падения
Самая честная причина появления SRE в компаниях:
🔥 произошла просадка, все перепугались, бросили деньги в сторону „надежности“.
появляется SRE,
нанимаются люди,
им дают туманный мандат,
им не дают полномочий,
через год спрашивают: «А почему у нас все еще проблемы?»
Потому что SRE-команда - это не операция "пожар потушили".
Это культурный слой, который нужно выращивать. А не покупать.

Что точно не работает:
❌ копировать Google 2004 года в условиях 2025.
❌ заводить SRE, чтобы кто-то другой решал ваши проблемы.
❌ делать SRE заглушкой для незрелости.
Мы живем в мире, где надежность покупается, CI/CD не пишется руками.

А вы знали про SRE?
😎 - я и есть SRE
🔥 - у нас 99.99 и команды сами это драйвят
❤️ - чувак, нам вот не до надежности!

Разработчики теряют 2–3 часа в день только из-за переключения контекста

Продолжая тему СДВГ 🤣🤣🤣

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

А есть то, что делает то же самое, но тихо.
Медленно.
Незаметно.

И это контекстные переключения.

Вот эти:
«А глянь плз»,
«У тебя минутка?»,
«Привет, а что по той задаче?»,
«Скинь ссылку»,
«Проверишь PR?»
и, конечно, вечное: Tg → Jira → IDE → CI → документация → обратно Tg.

По отдельности все это мелочи жизни. А потом ррраз и нет недели.

🤯 Почему одно переключение это не “минутка”, а 10–30 минут возвращения в контекст ?

Так, читатель, перестань отвлекаться и вернись сюда

Статья шикарно подчеркивает простую мысль:

👉 Чтобы вернуться в поток, мозгу нужно заново собрать весь контекст.
Не просто «вернуться к работе». А вспомнить всю модель задачи:
данные, зависимости, состояние, код, ограничения.

Каждый пинг = выкинули всю эту модель в мусорку.

Снова загрузка.
Снова компиляция в голове.
Снова попытка понять «а что я вообще делал?».

Если разработчик в день переключается десятки раз, он работает не в «процессе разработки», а в «процессе возвращения к работе».

И мы такие сидим на демо:
- А почему так долго фича делалась?
- Ну… сложная… много нюансов…

Нет, ребята.
Просто нас дергали 40 раз, и мы 35 раз «загружали контекст» с нуля.

Сложная фича тут вообще ни при чем.

🔥 Где скрыт основной ад?

Статья выделяет самые токсичные места и я прям подпишусь каждым.

1) Tg, как фабрика отвлечения!

Каждое сообщение звучит как "супер пупер важно".
Но реальность - 70% можно было не писать.

2) Jira как генератор лишних прыжков

Прыгаешь туда не за реальной пользой, а чтобы обновить статус «для кого-то».

3) Code Review, которое не асинхронное

«А посмотри прям щас» - лучший способ убить поток.

4) Фрагментированная экосистема

Система не помогает, а создаёт ещё один набор кнопок, которые надо помнить.

5) Микротаски, которые выглядят безобидно

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

🧠 А теперь важное: мозг разработчика работает как CPU

Переключение контекста = context switch
Каждая вкладка - новый процесс
Каждое уведомление - interrupt
Каждый звонок - non-maskable interrupt

И пока CPU загружается, фреймворк в голове крутит idle.

Какой уж тут DevEx.

🏗️ Что реально нужно делать компаниям (но почти никто не делает)

И вот где статья прям бьёт точно в точку:

1. Убрать мультиканальность

Один канал поддержки.
Один SLA.
Один источник правды.

2. Делать платформу не «набором сервисов», а единым пространством работы

Не «идите в этот UI».
А «вы там живёте».
Пока нет единой точки входа переключения будут расти как плесень.

3. Закрыть рутину автоматизацией

Автогенерация конфигов, автозапуск окружений, автофиксы, autoPR — всё, что убирает “мелочи, на которые жалко внимание”.

4. Проектировать CJM, которые не ломают поток

Любая дыра в CJM - это прямой билет в Tg.
Tg = контекстное самоубийство.

5. Давать инженерам длинные непрерывные слоты

Хочешь velocity?
Давай тишину и uninterrupted time.

🎯 Итог, который нужно написать крупным шрифтом в офисе

Самая дорогая вещь в разработке не compute и не storage.
Самая дорогая вещь - это внимание инженеров.

И пока его продолжают дробить на осколки, никакие SLO, DevOps практики и LLM-ассистенты не поднимут скорость.

Средняя продолжительность рабочего дня:
8 часов (480 минут)
Прерывания в день: ~155 прерываний
Время восстановления после прерывания: 23 минуты

Конечно, прерывания не накладываются друг на друга идеально (некоторые происходят до того, как вы полностью восстановитесь после предыдущего), но даже по самым скромным оценкам разработчики теряют 2–3 часа в день только из-за переключения контекста.

Паттерны…паттерны…паттерны
Чем дольше работаешь, тем больше замечаешь, насколько ими все пронизано.

Мы привыкли мыслить паттернами проектирования, управления, формирования вижена и т.п. и т.п.

А есть ли такое в маркетинге? В коммуникации?

И да, есть!
Ребята из сервиса развития бизнеса Calltouch запустили Карту коммуникаций!

И вот почему вам это нужно!
1. Клиент заходит на сайт, что - то смотрит, ищет и вот «он поймал триггер» и теперь он у вас на крючке.
2. Клиент тут же получает поп ап с вашим особенным предложением.
3. Его отвлек звонок и он закрыл сайт? Не беда! Рррраз, и вот мы ему уже отправляем смс.
4. Клиент вам позвонил, но вновь где-то потерялся? И тут мы ему опять напоминаем про скидочку и особые условия в мессенджер.
5. И все это преднастроенные шаблоны сразу для 10 индустрий.

Короче, бежим к ребятам в Calltouch. 

#пятничное

🔥 - демпинговал и продолжу демпинговать
🐳 - продалбывался и продолжу
❤️ - давайте уже это, после праздников разберетесь!

Что будет, если в 39 лет вылететь из айтишной позолоченой клетки?

Честно говоря, я Антону всегда говорю, что считаю его поступок слегка безумным.
Лично я бы точно не решился.

Причем не с простого карьерно паровозика спрыгнул, а там: бигтех, должность хорошая, продукт растущий.
Антон короче спрыгнул год назад, чтобы делать свои проекты и развивать телеграм-каналы. Отказался от всех артефактов стабильности и успеха: зарплата, ДМС и главное — от бесконечного запаса глазированных сырков на офисной кухне. Но остались обязательства: содержать семью, кредит на другой бизнес и долг по ипотеке на 16 млн₽. А чтобы сильно не расслабляться, на половину финансовой подушки купил машину.

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

В своём канале Антон рассказывает про жизнь начинающего предпринимателя во всех аспектах:
• Почему мы бежим из айтишки?
• Работай с тем, что есть: как не проваливаться, когда над тобой не стоит начальник
• Сотрудник рывкового типа или тупо прокрастинатор?
• Обратная сторона предпринимательского майдсета
• Первые финансовые успехи (спойлер — рано радовался)

А ещё Антон честно пишет про работу с психотерапевтом, делает разборы популярных продуктов, рассказывает про бэкстейдж корпоративной карьеры и обучение на роль СЕО.

Аутентичный контент, интересно наблюдать: @undisrupt

Проблемы всех стратегий

Рисую я тут стратегию и хочу поделиться одной мыслью

Проблема всех стратегий в том, что их готовят оптимисты, а значит, они не реалистичны по своей природе.

Почему оптимисты?
Потому что менеджеры по природе своей такие.

Что делать, если вы хотите реалистичную стратегию?
Пусть ее пишут пессимисты!

Но хотите ли вы такую?

А вы к кому себя относите?

😎 - я оптимист
👍 - я реалист
🔥 - я пессимист

Одно из лучших решений, которые срабатывают второй раз - поставить открытый книжный шкаф на видном месте.

Мы это делали с Демычем - пацан, просто, невероятно обожает читать.

А вот и Тея - регулярно лазит в книжный шкаф себе что-то выбрать.
Правда, на данном фото она «ищет папе книгу побольше»😁

Формат конференций «инженеры для инженеров» — это топ.
Я прям фанат таких.

10 декабря пройдёт «Салют, Гига!» - день, когда говорят те, кто реально делает AI в проде.

Разработчики GigaChat и Kandinsky расскажут и покажут, что сделали за этот год, поделятся тем, как они подходят к исследованиям и продакшену.
В программе доклады, постеры, живые демонстрации и воркшопы от команд разработки.

Можно будет посмотреть онлайн или прийти очно в Москве 10 декабря, регистрируйтесь 😉

AI и 100 тыс. разработчиков в исследованиях от Егора Денисова

Это исследование противоположно тому, что сделали в METR: тут наблюдали 100 тыс. разработчиков из 600 компаний.

Че по результатам?

AI действительно помогает, но не так, как нам обещали в промо-роликах. Средние +15–20% - это не революция. Всё упирается в зрелость кода, тип задач и размер вашей кодовой помойки.

Откуда я это все взял?
Посмотрел 20-минутное выступление Егора Денисова-Бланша из Stanford - и это, пожалуй, один из самых аккуратных, честных и приземлённых разборов реальной продуктивности инженеров под воздействием LLM.

1. Почему все предыдущие замеры продуктивности - так себе авантюра?
Потому что:
1) Исследования финансируют сами вендоры.
OpenAI и прочие ребята очень стараются показать, что вырастили «+как минимум 2x productivity». Но выборка перекошена, метрики подкрашены - всё как обычно.

Ну вы же сами работаете в корпорациях, не мне вам рассказывать)))

2) Коммиты и PR - плохая метрика.
Бум output, но линия качества - вниз.
Можно удвоить количество строк кода, не трогая полезность ни на йоту.
3) Greenfield-эффект.
На игрушечных проектах LLM выглядит богом.
А в реальной компании 90% задач - это старый код, грязь, зависимости и боль. Ну и куча требований безопасности, надежности.

4) Опросы?
«Кажется, я стал продуктивнее» ≠ «стал».
Самооценка - круто для well-being, но не для метрик.

Это ваще супер важная штука, когда регулярно занимаешься DevEx понимаешь, что есть большая разница между реальной производительностью и тем, как она ощущается. По сути, тут совпадает с ощущением многозадачности, как у менеджера: весь день делал кучу вещей, вроде, молодец, но есть ли результат?

2. Как Стэнфорд это мерил?
1) Подключили настоящие git-репы компаний.
Не игрушки, а живой корпоративный код.
Контекст команд - сохранён.
2) Собрали пул архитекторов и заставили их руками ставить оценки.
10–15 экспертов на качество, сложность, поддерживаемость.
И оценки очень хорошо коррелировали - то есть разметка надёжная.
3) Натренировали ML-модель, чтобы она воспроизводила экспертную оценку.
С высокой корреляцией.
То есть дальше можно масштабировать без сумасшедшей стоимости ревью.
4) Классифицировали типы изменений:
- добавление фичи
- удаление
- рефакторинг
- rework (переделка свежего кода) ← важный индикатор «кажется, ИИ ошибся, давайте исправим».
5) Прогнали всё ретроспективно за 2019–2025.
От COVID до появления LLM - чёткое сравнение «до» и «после».

3. Что показало исследование? Здесь многие ахнут
1) Сырой прирост кода: +30–40%.
Но туда же входит и мусор.
2) Реальная продуктивность: +15–20%.
После вычета багфиксов и rework.
И это среднее - иногда намного хуже.
3) На сложных задачах: почти ноль.
И огромная дисперсия.
Иногда AI даже замедляет.
4) Картинка в начаое поста хорошо иллюстрирует это: сложность × зрелость проекта

5) Язык имеет значение.
Популярные - выиграли.
Эзотерика - страдает, потому что моделей просто не на чем было учить.
6) Размер репозитория работает против вас.
Рост выгоды падает логарифмически.
Причины: шум, coupling, ограничения контекста.
Чем больше кодовая база - тем хуже LLM понимает, «что тут вообще происходит».

Тут ожидаемый эффект, конечно)

4. Че делать то, со всем этим?
1) Определите сложность типовых задач и зрелость своего проекта.
Если у вас legacy-монолит - чудес не будет.
2) Используйте популярные технологии.
LLM по ним лучше обучены → подсказки лучше.
3) На больших старых системах начинайте с пилота.
Маленький модуль, короткий эксперимент.
«Из коробки» Cursor или Copilot может не давать прироста.
4) Следите за долей rework.
Если вдруг резко вырос объём кода - это не рост продуктивности, а рост переделок.

Мы, кстати, часто такое обсуждаем а ребятами, потому что рост объема кода, это, конечно, скорее вред.

5) Комбинируйте количественные сигналы git с качественным ревью.
Не сводите всё к «команда довольна/недовольна».

А вот тут по ссылочке можно найти презу.

А у вас в компании как с AI в разработке?
🔥 - активные эксперименты и уже многое в проде
🦄 - пробуем тестируем, но не активно и не верим
💊 - мы явно на другом уровне