Что беспокоит разработчиков

На прошлой неделе вышло сразу несколько интересных исследований, постепенно буду разбирать. Первое – State of Developers, от ребят, которые много лет делают исследования JS экосистемы.

👉Пять главных проблем, с которыми разработчики сталкивались за свою карьеру: плохой менеджмент, выгорание, проблемы с work/life balance, скука и боязнь потери работы.
👉Самый частый вид дискриминации – по возрасту, с ним сталкивались 13% опрошенных.
👉Ловите лайфхак – люди с должностью engineer получают в среднем на 65000$ больше, чем developers.
👉Среди рисков, связанных с AI, количество слоп-кода волнует больше людей, чем использование AI в военных целях😅
👉Самые частые проблемы со здоровьем – плохой сон, лишний вес, менталочка, больная спина и мигрень.

Как в Anthropic делают code review

Ежемесячное количество PR в Claude Code выросло с с 2500 в мае до 30000 в сентябре. Еще раз, тысяча PR в день! Конечно, код такими темпами читать они не будут. Вместо этого вот как они подходят к code review:

1️⃣Локальные проверки, которые выполняет сам агент: прогон тестов, проверка дизайна на соответствие гайдлайнам, агентское ревью для поиска багов.
2️⃣AI ревью на PR. Один агент находит проблемы, другие их перепроверяют, а самые важные уходят на аппрув человеку.
3️⃣Автоматическое security ревью, которое может заблочить PR.
4️⃣Автоматические чеки – линтеры, куча тестов, тайпчеки и все в этом духе.
5️⃣Самое интересное – risk-based человеческое ревью. Тривиальные, либо закрытые фичефлагом изменения вообще его не требуют; средний риск ревьюит один человек; высокий риск - два человека. При этом это разделение касается только списка доверенных авторов. Например, изменения людей из других команд обязательно ревьюятся человеком.
6️⃣Все эти автоматические чеки прогоняются еще раз после того, как подходит очередь слить PR в мастер. Дальше фича обычно раскатывается на аудиторию постепенно.

Если суммировать, то люди чаще всего подключаются к следующим решениям:

👉Надо ли вообще делать какую-то фичу, плюс разные решения по скоупу
👉Изменения в хай риск коде вроде биллинга
👉Архитектура, которая с большой вероятностью может быть повторена где-то еще
👉Ревью свидетельств того, что агент сделал работу – скриншоты, тесты, трейсы

Еще одна эвристика для боттлнека в code review

Продолжаем обсуждать, как справляться с однозначно выросшим количеством кода, который нужно ревьюить. Как и в примере с Claude Code, в этой статье основная идея тоже крутится вокруг того, чтобы определять подмножество PR, которые можно не ревьюить. Для этого CI автоматически помечает часть PR как small-change при выполнении следующих условий:

👉Меньше 1000 строк.
👉Автоматическое ревью не нашло проблем с высоким приоритетом.
👉Автор PR слил хотя бы 10 других изменений, затрагивающих изменяемый модуль. Если PR трогает сразу несколько модулей, проверка опыта запускается для каждого.
👉Затрагивает не больше, чем N отдельных сервисов или приложений. Во фронтовой монорепе N=1, в бэкендной N=3.
👉Не затрагивает общие библиотеки.
👉Не затрагивает файлы, прописанные в отдельном конфиге, для которых обязательно ревью от человека.

Вот с такой эвристикой 10% всех PR попадают под этот фильтр и мерджатся автоматически.

Вы просто неправильно используете фреймворк

Если вы попробовали внедрить модный подход, и у вас не получилось, то самой частой реакцией от его апологетов будет "ну вы просто использовали его неправильно". Да что уж там, я таким же был – ходил по конференциям, рассказывал, как мы в Авито прекрасно жили с OKR, а когда кто-нибудь рассказывал про свой неудачный опыт, то бросался объяснять, что он просто не разобрался, как правильно.

Проблема тут не в том, что OKR не работают или вредны. Как и в случае большинства других подходов (ну кроме холократии конечно), есть много компаний, которым такой подход к целеполаганию полезен.

Ошибка состоит в другом, и мне нравится, как автор статьи ее определяет:

I call this the “Precision Fallacy”: the belief that a more precise understanding or implementation would have worked, where the precision in question is undefined, or so intricate that it’s impossible to follow, and thus it’s an un-dis-provable excuse.

Нет ничего плохого в том, чтобы пробовать решения, которые сработали где-то еще, подкручивать их под ваши обстоятельства, и быстро выкидывать, если пользы нет. И что бы в этот момент вам ни говорили их сторонники, помните, что проблема скорее всего не в том, что вы сделали что-то не то, а в том, что конкретное решение не очень хорошо подходит конкретно вашим обстоятельствам.

Должен ли руководитель делать команду счастливой

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

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

Ошибка периферийного примера

Я принес новое когнитивное искажение в вашу копилку, чтобы вы могли эффективнее отбривать своих оппонентов в спорах. Суть в следующем:

👉Предмет спора можно отнести к категории, архетипичные примеры которой вызывают сильную эмоциональную реакцию.
👉Предмет спора при этом по факту находится где-то на периферии категории.
👉Так как предмет формально относится к категории, то эту эмоциональную реакцию автоматически распространяют и на него.

Несколько примеров, чтобы было понятнее:

1️⃣Мартин Лютер Кинг сидел в тюрьме, а и значит он плохой человек.
2️⃣Генетическая инженерия это евгеника, а значит неэтична.
3️⃣Дублирование одной и той же функции в двух классах нарушает DRY, а значит – говнокод, и вредит системе.

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

The Power Broker – лучшая книга для менеджеров

Я пару месяцев назад дочитал, кажется, САМУЮ БОЛЬШУЮ книгу в своей жизни – Power Broker. Это невероятно подробная биография Роберта Мозеса – человека, занимавшего довольно смешные должности вроде "главный за парки Лонг-Айленда", который при этом перестроил половину Нью-Йорка по своему чувству прекрасного, сломал об колено демократию, и подчинившего себе длинную череду мэров, губернаторов и президентов.

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

• Как вообще работает власть и как ее получить, когда у тебя нет никаких прямых рычагов.
• Как добиваться результатов в проектах, которые все считают невыполнимыми.
• Как использовать политические механизмы для пользы дела.
• Как власть меняет и самого человека, и превращает благие намерения во что-то отвратительное и разрушительное.

Чтобы вас заинтересовать, буквально несколько замечательных историй из книги:

👉Чтобы получить финансирование для строительства мостов (а Мозес ну очень любил строить мосты), он выпускал облигации. Облигации сопровождались большим количеством дополнительных условий, среди которых было и описание конкретных полномочий Мозеса. Купленная облигация по сути является подписанным контрактом, а сила контракта охраняется конституцией. Таким образом, после продажи пачки облигаций, формальное подчинение Мозеса мэру не значило ровным счетом ничего – никто не мог контролировать его решения.
👉Мозес был королем получения государственных грантов для своих проектов. Он получал их не потому, что занимался самыми полезными вещами (на самом деле многие из его инициатив, наоборот, активно вредили городу). Секрет был в другом – он всегда приходил за грантом с готовым просчитанным до мелочей проектом строительства, в то время как все остальные вбрасывали вялые неоформленные идеи. Короче говоря, побеждают не лучшие идеи, а наиболее готовые к реализации.
👉Мозес никогда не ждал формального одобрения полного бюджета для своих проектов. Вместо этого он начинал работать с доступным минимумом денег, закладывал базовую инфраструктуру, рассказывал прессе о том, как все будет прекрасно, и только потом шел запрашивать дополнительный бюджет. И ответственные за выделение денег были в тупике – если они бюджет не выделят, их распнут за то, что они заморозили перспективную стройку, результатов которой уже ждут все вокруг. Иначе говоря, чем больше людей и ресурсов уже включено в проект, тем политически сложнее его остановить.

Готовьтесь к тому, что чтение может быть не самым простым – например, целая глава посвящена описанию опор одного из построенных Мозесом мостов. А другая рассказывает во всех деталях про зонирование Лонг-Айленда и то, кому из нефтяных баронов какой участок принадлежал. Тем не менее, читать это все равно невероятно интересно – автор, Роберт Каро, получил Пулицера за эту книгу во многом благодаря тому, насколько захватывающе он может писать о, казалось бы, очень скучных вещах.

Короче говоря, я правда очень-очень рекомендую вам ее прочитать.

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

Разберите эти вопросы с топовым экспертом из Яндекса и НИУ ВШЭ на бесплатной консультации при покупке любой программы ИИ-тренингов до конца ноября.

Формат: 1 час с предварительным брифингом. Тему согласуем заранее.

Что вас ждёт:
▪️ Обсудим ваши реальные задачи или типовые сценарии — подготовка к встречам, работа с документами, внедрение ИИ в команде.
▪️ Покажем, какие инструменты попробовать, как повысить личную эффективность, какие процессы автоматизировать и как проверить результат.
▪️ После встречи вы получите письменные артефакты — промты, рекомендации, чек-лист, роадмап или список шагов.

Оставить заявку

Реклама, ООО Яндекс, ИНН 7736207543, erid: 2VtzqviVCB7

Задавайте больше вопросов

Когда мы действительно пытаемся что-то понять, то строим в голове модель описываемого предмета. Единственный способ эту модель откалибровать – задавать вопросы, чем больше, тем лучше. Именно большое количество вопросов всегда было главным инструментом менеджера, которому надо было погрузиться в те части проекта, которые он не трогал руками сам.

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

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

Смерть письменной культуры Amazon

Если попросить любого из подписчиков канала назвать три отличительные особенности культуры Amazon, то он почти точно вспомнит про повышенную любовь Безоса, а, значит, и всей компании, к написанию документов. Мы даже выпуск Подлодки с Александром Ложечкиным про это записывали!

Основная идея за такой культурой была в том, что сложно написать ясный документ, не вложив в него достаточное количество мыслительных усилий. Тот же Безос объяснял это так:

Full sentences are harder to write. They have verbs. The paragraphs have topic sentences. There is no way to write a six-page, narratively structured memo and not have clear thinking.

AI полностью меняет это уравнение – большие документы теперь наоборот показывают, что сгенерировавший их человек не потратил ни минуты на то, чтобы выделить важное или хотя бы прочитать их. И это довольно сильно ломает кучу процессов, завязанных на идее writing is thinking – согласование новых идей, перфоманс ревью, промо, да даже подготовка дизайн документов.

Несмотря на громкое название статьи, у автора не то чтобы были конкретные истории о том, что именно происходит в Amazon – он уволился оттуда еще в 2024, до настоящего взлета AI. Но подумать о том, может ли такая культура выжить, и как она трансформируется, все равно интересно.

Про потерю связности

Ну очень классное эссе про то, почему decoherence, потеря архитектурной связности, всегда была одной из самых опасных проблем в разработке софта, и стала еще более насущной из-за агентов.

Основная мысль такая – агенты работают по жадному алгоритму, выбирая самый короткий путь к решению локальной проблемы, при этом приводя к постепенной эрозии архитектуры. Из-за этого каждое следующее изменение становится дороже, а поведение менее предсказуемым.

При этом автор критикует и подход брать этот технический долг в расчете на "ну мы просто бросим больше компьюта" или "модели следующего поколения все проблемы порешают". Не порешают, так как пресловутая архитектурная целостность и качество софта не задаются простой функцией, которую легко оптимизировать.

Расскажу про SDD на AI Dev Live 2026

С тех пор, как я пошел работать в CodeSpeak, я довольно плотно закопался в Spec-Driven Development – и сам начал использовать разные фреймворки, и пообщался с кучей компаний разного масштаба, чтобы понять, а как они живут с SDD в больших реальных проектах.

А выяснилось, что, как и от любого другого подхода, от SDD часто ожидают очень странного – кто-то уверен, что это поможет полностью отказаться от чтения кода, кто-то – что это поможет передать разработку продактам и аналитикам, кто-то – что они получат самооновляемую продуктовую документацию. На самом деле все, конечно же, не совсем так.

На основе вот этих наблюдений, собственного опыта и разных идей, которые мы обсуждаем в CodeSpeak, у меня получился классный доклад, который я рассказывал внутри нескольких компаний, которые подумывали пойти в SDD. И вот пришло время наконец-то выступить с ним публично!

Где: Онлайн-конференция AI Dev Live 2026
Когда: 11–12 ноября 2026 (ср-чт), с 14:00 до ~19:15 Мск
Формат: онлайн-эфир на русском с лекциями (всего будет 15 докладов), будет возможность задавать вопросы в чате
Как попасть: бесплатно, подписавшись на каналы спикеров через бота, либо платно

🔗Регистрация и подробности