🤓 Martin Fowler в гостях Pragmatic Engineer

https://youtu.be/CQmI4XKTa0U

Мартину уже за 60 лет, из которых он 40 с лишним считает себя инженером; когда опыт исчисляется десятками, то накапливается тот уровень насмотренности, когда можно сравнивать эпохи и видеть глобальные тенденции

⌘⌘⌘

по своему масштабу Мартин сравнивает нынешний скачок с переходом программистов с ассемблера на языки более высокого уровня

сам Мартин не имеет ничего против вайбкодинга как такового (тут он понимает «вайбкодинга» именно как безоглядное принятие любого результата ллм-ки без глубокого осознания написанного), однако чётко ограничивает зону его возможностей: небольшие проекты, прототипы на выброс и т.д.

главный недостаток слепого вайбкодинга — отсутствие цикла обратной связи. не пропуская через себя этот код, нет процесса обучения. новые знания не налипают и не копятся

получается вайбкодер через год останется ровно с таким же уровнем и потом его сменит просто другой вайбкодер (помоложе); или просто следующее поколение агентов, которым не нужна будет «простилка» между клавиатурой и креслом

⌘⌘⌘

при этом в прототипировании аи-помощник показывает небывалые приросты в продуктивности. приводят пример инженера из Антропика, который за 2 дня собрал 20 прототипов, итеративно проверяя и валидируя их об команду.

здесь быстрый цикл обратной связи помог им сразу на практике осознать простанство потенциальных вариантов и найти подходящие векторы для развития, отбросив остальные

⌘⌘⌘

ещё одна проблема ллм-ок — полная неспособность решить задачу «переименования класса»; по своему дизайну она скорее перепишет половину кодовой базы, чем поправит в трёх местах нужное название

при этом современные иде уже давно научились это делать, правда со своей подкапотной магией (которой, видимо, и не хватает ллм-кам)

⌘⌘⌘

общий подход к результатам работы моделей — ничему не верить, всё проверять; вдумчиво читать, внимательно вникать, нещадно тестировать, чтобы добавить чуток детерменированности их безудержной креативности.

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

✍️ о код-ревью

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


⌘ зачем вообще нужно код-ревью

+ это вторая пара глаз с иным контекстом и уровнем погружения: автор и ревьюер смотрят на код в разных когнитивных режимах → ловятся разные ошибки

+ передача знаний в рамках команды: «применяем вот такие паттерны, а вот так не делаем» → в среднем качестве кода постепенно улучшается

+ барьер против энтропии и деградации кодовой базы: без должного присмотра любой проект постепенно превращается в трудно поддерживаемое болото


⌘ как бывает без код ревью

когда команда небольшая, да ещё и допустим без большого опыта, то большой соблазн поспешить с реализацией или смалодушничать при проектировании → в результате получается нагромождение модулей, которые через время проще сжечь, чем исправить


⌘ как задавать вопросы на код-ревью

+ открытые вопросы лучше чётких предложений — во-первых, ревьюер сам можем не осознать что здесь происходит, а, во-вторых,

+ любой код может быть написан множеством способов — прежде чем предложить что-то поправить, надо понять а точно ли оно будет объективно лучше? или просто «ревьюер привык писать по-другому»

+ спорные места должны быть выведены в общие архитектурные соглашения на команду (какие линтеры используем, как ставим отступы и пр.)


⌘ эффект от код ревью

− растёт время на разработку: уходит время на найти ревьюеров и иногда пройти несколько итераций над кодом

+ твои типичные вопросы на код-ревью возвращаются в твои пулл-реквесты — нарабатывается паттерны и начинаешь думать про типовые кейсы заранее

+ повышение качества среднего пулл-реквеста — на ревью не поступает откровенно плохих пулл-реквестов, где какой-то треш или забыли подумать

📢 ищем дата-коллег к себе в Яндекс Финтех

→ дата инженеры
https://yandex.ru/jobs/vacancies/inzhener-dannih-v-finteh-36637

→ дата-партнёры (они же системные аналитики двх)
https://yandex.ru/jobs/vacancies/analitik-dwh-v-finteh-27815

это прям в нашу команду, то есть будем работать вместе)

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

хотим и дальше нести свет в массы, поэтому активно ищем новых коллег


что у нас есть интересного:
→ есть полная документация — наши объекты не идут в прод без описания каждого атрибута
→ на нанейминг полей и объектов — есть конвенция
→ на YQL — есть линтеры
→ на пулл-реквесты — тесты в си-сд (и 4 глаза ревьюеров)

из технологии — почти всё яндексовое:
+ YTsaurus как основная система хранения
+ смотрим в сторону ClickHouse рядом
+ придерживаемся подхода инфра-как-код через Terraform
+ логброкер как шина данных для стриминга и дата-трансфер как коннектор (если вам это о чём-то говорит)

любим процессы (но без карго культов)
→ есть дежурство и инцидент-менеджмент с пост-мортемами
→ есть удобный процесс мониторинга и алертов
→ подробный онбординг и прочие документы о процессах команды


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

$ работать над доступностью сервиса и данных: как валидировать данные и мониторить корректность на потоке, чтобы не пробивать общие сла;

$ выяснять, спрашивать, изучать у источников почему данных не было, почему поздние долёты, почему внутри полная шляпа, и вообще где ещё три нужных поля;

$ спорить с дорогими коллегами как оптимальнее перелопатить теробайты в секунду, как лучше описать новый домен, какой кусок вынести в общую либу, голосовать какие фичи больше всего нужны в общей платформе

и делать это всё в максимально подготовленной и комфортной среде, внутри Яндекса развитая культура внутренних инструментов: доступы к основным аи-моделям, рабочие места с Курсором, внутренние вебинар и обучалки на любые темы


понимаю, что процесс найма долгий, поэтому планирую постепенно накидывать заметок о буднях команды; ссылки буду появляться ниже
→ о код ревью
→ ещё о код ревью
→ про культуру ведения тикетов
→ …

можно откликаться на вакансия выше или присылать CV с кратким интро мне в личку @SashaMikhailov

буду рад ответить на вопросы в комментах или так же в личке

📝 о код-ревью (часть 2)

вижу тема ↑ код-ревью хорошо зашла — продолжаю накидывать


⌘ разные авторы — разные вопросы на ревью

+ во время онбордина на первые ревью обычно приходит тьма комментариев; чтобы проверить, что автор достаточно погрузился в новый проект, приходится спрашивать с самых банальностей: «почему тут за Т-2», «почему тут снепшото, а не апсёрт?» и т.д.

+ со временем у авторов набирается «репутация» — вопросы переходят на следующий уровень абстракций (или вовсе пропадают с типовых решений)


⌘ размер имеет значение

− гигантский ПР на 500+ строк кода, затрагивающий множество модулей, имеет шанс погрязнуть в процессе ревью (не говоря уже про увеличенную вероятность пропустить багульку в прод)

+ а вот маленький атомарный ПР легко читать и требует адекватного количества когнитивной энергии ревьюера — а значит не вызывает сопротивления и обычно сходится предсказуемо быстро


⌘ не всегда есть «правильный» ответ

+ иногда вопрос — это предложение к дискуссии или просто любопытство почему выбран именно такой подход

+ хочется проверить, что автор продумал основные кейсы в предлагаемом решении


⌘ проблемы код-ревью

− неконсистентность от ревью к ревью: даже один ревьюер может спросить разное, не говоря уже о нескольких

− код-ревью не случается само — оно занимает время и тратит когнитивную энергию; это буквально конвейер и его надо явно планировать в своём календаре (получается всем в команде)

− ну и в целом — растёт тайм-ту-маркет, в задачу надо закладывать время на схождение код-ревью


⌘ ожидания от код-ревью

+ код-ревью не должно быть узким горлышком — положительные эффекты складываются, когда вся команда ревьюит друг-друга (не только один тимлид по ночам и выходным)

+ LGTM — это тоже ответственность; если код падает прям сразу после релиза — вопросики будут как к автору, так и к ревьюеру;

+ всем в команде (включая ревьюера) потом поддерживать этот код — в общих интересах поддерживать кодовую базу в хорошем виде


⌘ пускай потеет машина

+ проверять синтаксис и опечатки должны машины, а не белковые мешки; поэтому эффективнее настроить линтеры, тесты, вот это всё

+ если команда уже сформировала код-стайл и обсудила архитектурные подходы, то будет проще формализовать и базовые проверки

+ а дальше пускай уже и аи-шные агенты ревьюят код помимо базовых линтеров и тестов — эти уже не только формально, но и по смыслу смогут накидать на вентилятор


---

тем временем мы продолжаем искать дата-коллег — ваши репосты нам очень помогут

🦀 Clawdbot / Moltbot / OpenClaw

там похоже намечается очередной качественный скачок аи-строения: австрийский программист написал автономного (?) ии-агента… и понеслось

формат горячих новостей не мой любимый жанр, но это залетело в моё инфополе с трёх разных сторон:

+ Самат Галимов накидал ссылок для понимания контекста
https://t.me/ctodaily/1995

+ Pragmatic Engineer выпустил интервью с автором
https://youtu.be/8lF7HmQ_RgY

+ ребята из Шмит16 собрались вместе где-то на Бали и скупают все доступные мак-мини, чтобы устроить ферму из таких аи-агентов

сам автор бота не случайный мамкин вайбкодер — он начинал ещё с веб-приложений в начале 2000-х и потом перешёл на приложения айос для первого айфона.

потом запилил как побочный продукт PSPDFKit — низкоуровневый парсер и рендере пдф-ок; продукт быстро стал приносить денег больше, чем основная работа и он переключился на него фултайм. потихоньку стартап разросся до 70 человек.

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

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

⌘⌘⌘

потом он (традиционно) выгорел и ушёл с радаров на три года, ничего не делал, ничем не занимался; и всё, чтобы «вернуться в интернет» в 2025-м —прямо на рассвете ии-агентов

тут он офигел от новой технологии и по первым ощущениям от продукта он вспомнил все хорошие впечатления от программирования

в итоге к осени он врубился в технологию настолько, что она стала для него «запойной»: работает на десятью пет-проектами сразу и 10 разных агентах / терминалах

⌘⌘⌘

поинты автора про подход к агентам:

⌘ замкнуть цикл обратной связи: задача → план → исполнение → отладка → тестирование → сверка с исходной задачей — всё это агент делает сам в бесконечной итерации, пока результат не достигнут

⌘ «новое» программирование — это верхнеуровневый дизайн, а не написание кода

⌘ из аи-агенты можно собирать локальные мини-команды (и не отдельные тулзы)

⌘ а синьорные инженеры — это теперь аи-менеджеры таких локальных команд для разработки

⌘⌘⌘

сам Moltbot / OpenClaw выглядит как проект на стыке аи- и арт-перфоманса

автономный агент, которому явно дают доступ к локальной системе — это что-то за гранью привычного

причём не каждый догадывается или может позволить себе отдельный мак-мини для инстанса бота — и они грузят их прям на своей основной тачке

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

⌘⌘⌘

агент имеет доступ к своим настройкам и исходному коду

может менять свою конфигурацию, дописывать новые модули

так, у бота не было модуля работы с голосовыми сообщениями, но, получив однажды голосяшку от автора, он через какое-то время дал релевантный ответ (оказалось, он прочитал хедер сообщения, нашёл нужный модуль, установил его и смог декдодировать пришедшее ранее сообщение)

🤯

📁 про культуру ведения тикетов

продолжаю рассказывать про внутрянку нашей команды, привлекая ваше внимание к активным вакансиям >_>

> важный дисклеймер: это не я, это всё наш техлид Кирилл (я тут только документирую и выношу)

думаю, все видели тикеты, прочитав которые, осталось непонятным что́ надо сделать; или задачи, где ты вроде сделал что было написано, но оказалось, что нужно было не то и не так ¯\_(ツ)_/¯

мы в команде стараемся придерживаться культуры ведения задач — попробую описать как я это вижу


⌘⌘⌘

начнём с того, что создать хороший тикет - это отдельная работа; чтобы понятно описать что надо сделать, надо как минимум представлять проблему и целевое решение

есть базовый паттерн, которого мы придерживаемся:
⁃ контекст
⁃ проблема
⁃ что сделать
⁃ допматериалы

небольшие тикеты могут пропускать 1-2 пункта; а большие эпики будут наоборот побольше


⌘⌘⌘

«хорошие» задачи формулируются через глаголы:
сделать …, добавить …, исправить …, пересчитать …

однозначно указан объект изменения: таблица, таск, модуль и пр.

есть перечень связанных действий: в конце …сделать миграцию, …пересчитать историю, и пр.


⌘⌘⌘

задачи на имплементацию проходят через общее техревью на входе, чтобы вместе посмотреть и проверить:
⁃ проверить, что мы в принципе хотим это делать
(тут бинарно; пока без приоритетов)
⁃ задача описана понятно
⁃ ожидаемый результат считывается однозначно
⁃ (опционально) докапывается технических деталей

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

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


⌘⌘⌘

если задача занимает больше нескольких дней, то внутри ожидаются отбивки по текущему статусы; размер отбивок пропорционален масштабу задачи

причём не абстрактный статус «продолжаю работать», а короткий апдейт по фактам: сделано Х / осталось сделать У / открытые вопросы и блокеры …


⌘⌘⌘

в конце каждого тикет исполнитель оставляет резюме о проделанной работе

«сделал таск, пересчитал историю, вот ссылка на итоговый объект» — всё что нужно знать о задаче, осознанно принять результат (и при необходимости вспомнить через полгода что тут было вообще)

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

прозрачность ведения задач особенно важна при ведении инцидентов — для них помимо резюме дополнительно надо сразу заполнить пост-морфем
(инцидент-менеджемент у нас тоже есть — про него в другой раз)

⌘⌘⌘

лайк-шер-репост
👉 https://t.me/data_days/400

🦄 руководитель Claude Code об AI в разработке

послушал интервью Бориса Чёрного в подкасте Ленни. Борис написал первую версию Claude Code и теперь руководит этим направлением в Anthropic.

https://youtu.be/We7BZVKbCVw

по их данным сейчас уже 4% всех коммитов в Гитхаб создаются через Claude Code (ожидают 20% к концу года)

интересно, что первую версию Claude Code Борис сделал прошлой весной и это не был сиюминутный успех; популярность инструмента росла постепенно и взрывной рост случился после выхода модели осенью (Опус 4.5 кажется)

и с ноября 2025 Борис не написал ни строчки кода вручную — всё через Клода; так же приводит в пример «лучших программистов Spotify», мол, они тоже больше не пишут код руками.

Борис видит, что в будущем профессии будут теснее переплетены: не будет программистов или дизайнеров, все будут builder («создатель»?) — задавать ви́дение, раздавать задачи аи-агентам и принимать результат их работы.

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

🥷 DHH об agent-first подходе

DHH — известный ии-скептик и сторонник написания кода вручную; в своём сетапе он не использует IDE с их подсказками и навигацией по коду — всё набивает ручками (и радуется)

ещё DHH известен своими сильным мнением и радикальными взглядами — он говорит что думает, не взирая на мнения большинства или отдельных авторитетов

недавно зашёл к Pragmatic Engineer на интервью
https://youtu.be/JiWgKRgdgpI

и вот наступил действительно переломный момент:

⁃ июль 2025 — DHH не верит и не использует агентов

⁃ январь 2026 — DHH переходит на agent-first разработку

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

если уже DHH «распробовал» агентский подход — значит, результаты работы становятся действительно достаточно хорошими

⌘⌘⌘

DHH делится историей, как агент помогает ему разбирать ишью в его проекте на Гитхабе: из 250 открытых пулл-реквестов агент за пару часов разобрал 100.

какие-то единицы можно было мержить «как есть» — они уже были достаточно хорошего качества; другую часть агент провалидировал как «правильно опознанный баг, но реализация не идеальная» — такие он адаптировал/переписал согласно принятому стилю репо; и ещё часть агент смог аргументированно зареджектить.

при этом сам DHH потратил бы на эту работу несколько дней (и не получил бы большого удовольствия от неё).

мне кажется последние два интервью отлично смотрятся вместе и дополняют друг друга >_>

и отдельно мысль, которая где-то проговаривалась в этих интервью: токены — новый вид бенефита для сотрудников.

большие компании готовы вливать миллионы в токены для своих разработчиков.

а сами поставщики фундаментальных моделей в принципе ограничены только внутренними мощностями для своих сотрудников.

в подкастах Кирилла Мокевнина @orgprog упоминали, что в долине у каждого второго безлимит на модели OpenAI / Anthropic по тем или иным каналам

🤩 delirious dhh

итак, прослушал ~5ч одного небезызвестного программиста с сильными взглядами; ушло у меня на это всего где-то неделя: пара походов в спортзал и комьютов.

чем примечательно это интервью?

во-первых, dhh известен своими взглядами за чистоту кода; это тот ещё художник и скульптор, который «вручную вытачивал» каждый кусочек своих программ. за свою карьеру с 90х он успел понабраться и опыта, и мнений

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

получается такой идеальный маркер для 2025-26 годов - даже самые сильные программисты стали признавать возросшие возможности и качество кода от агентов.

There are decades where nothing happens
and weeks where decades happen

и вот с ноября 2025 dhh ведёт отсчёт, когда он впервые поймал себя на том, что выхлоп агента _достаточно_ похож на то, что он бы сам написал

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

поэтому нет особого смысла гнать на «нейрослоп» — агенты хотя бы не будут отпираться и готовы пройти стопицот итераций, чтобы его исправить. а ещё написать сколько угодно тестов и обложить всё понятной и актуальной документацией.

⌘

в проектах dhh есть места, где он даже не смотрит на итоговой код — типа если оно работает по заданным спекам, то детали не важны. при этом в ядро проектов он внимательно ревьюит каждую строку (хоть и не пишет сам теперь)

и чтобы понимать масштаб его текущих амбиций — он теперь пишет не очередной веб-фреймворк, а прям собственную ос, пускай и осованную на линуксе. это агентно-центричная система: её пишут агенты (под надзором dhh) для удобства использования другими агентами

⌘

спросите вашего агента про детали интервью — dhh у лекса фридмана от августа 2026