DDDevotion

Вижу в индустрии два подхода к внедрению ai разработки. Понятно, что это спектр, но в целом компании кто пробует идут

либо сверху вниз: выделяют хед оф ии, создают отдел/центр экспертизы. Эти ребята пробуют инструменты и директивно внедряют. Они же как-то измеряют эффективность и ответственны за рациональное использование бюджета.

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

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

А как у вас проходит/проходило внедрение?

Записываем в календарики

Когда: завтра, во вторник 16:00 мск

Что: стрим Александра Поломодова и Максима Смирнова с обсуждением Engineering loop

https://www.youtube.com/live/hnFLfiJOtQE?is=pOlF8JVWJr9mspC4

Иногда наше бизнес-правило может выглядеть так:

if (this.Total > 100)

Мы точно знаем, как получить результат. Но понимаем ли мы, что означают эти 100 и какое решение сейчас принимает система?
Можно вынести число в константу. Можно спрятать сравнение за методом с убедительным доменным названием. Но хорошее имя не появляется от самого рефакторинга — его нужно заслужить пониманием домена.
Если такого понимания пока нет, простыня ифчиков будет честнее, чем красивый, но выдуманный (кодогенерация вам в помощь!) RequiresManualApproval().

Имя в коде — это утверждение о нашем понимании системы.

Поэтому хороший нейминг требует честного ответа: мы уже знаем смысл этого правила или пока только умеем его вычислять?

Давно не касался темы инцидентов и постмортемов.

SRE Book вышла уже 10 лет назад, и может показаться, что тема давно полностью раскрыта. Но я всё равно позволю себе небольшой рекап.

Хороший постмортем, на мой взгляд, держится на двух вопросах:

1. Как снизить вероятность повторения инцидента?
2. Как раньше заметить, что в системе происходит что-то нездоровое?

И я часто вижу в обсуждениях сильный перекос в сторону первого вопроса.

После инцидента команда часто приходит к выводам вроде:

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

Все это правильно. Более того, чаще всего это действительно нужно.

Но важно помнить две вещи.

Во-первых, вероятность инцидента невозможно увести в ноль.

Во-вторых, каждая следующая “девятка” надежности может стоить непропорционально дорого. Переход от 0.9 к 0.99, от 0.999 к 0.9999 и так далее в какой-то момент может оказаться экономически не оправдан.

И если мы не можем или не хотим полностью предотвратить инцидент, остается другой путь: снижать ущерб.

А ущерб во многом определяется длительностью инцидента.

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

Именно здесь появляется observability.

Поэтому в хорошем постмортеме, кроме обсуждения “как не допустить повторения”, обязательно должен быть отдельный разговор:

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

Пожалуй, главное изменение за эти 10 лет в том, что часть этой работы теперь можно делегировать агентам.

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

То есть добавляем ещё один вопрос в наш постмортем: что агенты увидели в наших сигналах, что пропустили и какого контекста им не хватило, чтобы раньше поднять тревогу и помочь с расследованием?

Вышел LeadDev Engineering Leadership Report 2026

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

Но также виден следующий слой. Менеджеры/техлиды хотят:
Управлять агентами
Координировать автономные системы.
Понимать, как вообще измерять эффект от ИИ.
Разбираться, где проходит граница между помощью инструмента и ответственностью команды.

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

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

Интересный взгляд на агентскую разработку через DDD-призму.

А как вы работаете с агентами? Знает ли ваш агент, с каким доменом он сейчас работает? Понимает ли, в каком слое системы находится задача?

Я пока часто отдаю задачу «под ключ», надеясь, что агент сам разберётся. Но если мы считаем, что кожаным разработчикам важно понимать тип домена, границы модели и слой, в котором они работают, то для ИИ это тоже важно.

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

https://www.linkedin.com/posts/romanov-pavel_this-article-explores-how-mature-software-ugcPost-7459876259515461632-Uh8G

Такое мы смотрим https://www.youtube.com/watch?v=K-Xv8D8NjTk

Я как дотнетчик со стажем начиная с версии 1.1 очень благодарен ему за язык и платформу

Необычный взгляд на платформы и их роль в разработке. В некоторой степени перекликается с идеей фреймворка Cynefin. Если вы в простом домене (а само по себе создание нового сервиса с дефолтным профилем нагрузки — это простой домен), то best practice (right choice, golden path) в виде платформы и принуждения ее использовать скажется позитивно.

Но затаскивать платформу туда, где chaos/complex домены — это стрельба по ногам. Вот бы еще научиться легко отличать одно от другого 😅

https://www.linkedin.com/pulse/%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F-%D0%BA%D0%B0%D0%BA-%D0%BC%D1%8F%D0%B3%D0%BA%D0%BE%D0%B5-%D0%BF%D1%80%D0%B8%D0%BD%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5-evgeny-konechnyi-ajcmf/

Вслед за Антропиком, Гитхаб копайлот анонсировал новые тарифы. Формально стоимость планов не поменялась, но мякотка в множителях и они вырастут в 3-9 раз.

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

Но по мне, это говорит, что мы прошли стадию early adoption. Изначально вендоры "доплачивали" за использование, чтобы затащить новую парадигму: собирали сценарии, доказывали ценность, формировали привычку.

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

в свете утекшей кодовой базы claude code в сети опять обсуждают применимость чистого/совершенного кода в современных продуктах.

Основной тейк одной из сторон: фу таким быть, ужасный код и тп.
Им в ответ пишут: ваши паттерны (ооп, солид и прочее) никому не нужны, код и так генерит тонны денег.

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

Можно ли создать прибыльный продукт без процессов, грамотных инженерных подходов на всех уровнях и всего хорошего, что описано в различных книгах от Брукса и ГоФ до Хононова и Клепмана? Конечно можно! Если вам повезло угадать нишу и время, то любой работающий код будет успешен.

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

Предположим, что мы полностью перешли на агентскую разработку и пишем "код" на естественном языке в жире или еще где. Что меняется? Во первых нам становится все равно на devex нашей кодовой базы. Если LLM "понимает" код и может вносить изменения, то может и пусть пишет как вздумается? Если надо, вообще перепишем все заново! Оставим пока что за скобками потраченные токены.

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

Если хочешь, могу разобрать отдельно: как именно должен выглядеть “LLM-friendly код” — там уже появляются довольно конкретные паттерны.

Опять про ллм- разработку.

Сейчас на работе у меня сложилась идеальная ситуация

Есть достаточно большой неизвестный мне проект на плохо известном стеке (джанга)

Есть набор задач без горящих дедлайнов

Есть надежные процессы, которые не пропустят дичь на прод

Есть мое, как мне кажется, неплохое понимание прекрасного в разработке

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

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

Вроде все просто: надо взять токен и в бекграунд таске сходить в другую систему.

Но оказалось:

Тот токен который есть нельзя использовать для этого обращения

Передавать нужный токен в celery таску несекурно

Кэш основной аппки и селери разделен — нельзя использовать просто тот же метод получения токена

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

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

И пока что я не понимаю что делать с подобными задачами. Изначально они все выглядят одинаковыми по сложности

в свете использования LLM для разработки людя много обсуждают покупать или строить. Если смотреть с позиции DDD, то все однозначно: generic сабдомен покупаем, core саюдомен строим сами, supporting -- как получится.

Но LLM -- геймчейнджер, и теперь люди задаются вопросом, зачем нам платить за SaaS $n per months per user, если мы можем просто такой же саас навайбкодить за вечер (и пачку токенов)?

Для меня ответ по-прежнему прост: можете купить зрелое решение -- купите. Дорого? Попробуйте план попроще. Все равно не по карману? Посмотрите на опенсорс!

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

Когда все таки кодить/вайбкодить с нуля имеет смысл?

1. На рынке нет устоявшихся/готовых решений для вашей проблемы. В том числе из-за санкций или других ограничений.
2. У вас какие-то специфические требования (реально специфические, а не просто "мынетакиекаквсе"). Например, требования регулятора или стратегическое решение компании. Но и то я бы начал с обзора опенсорсных решений под подходящей лицензией.
3. Вам нужен какой-то небольшой набор фич от огромного и дорогого сааса. Опять же можно посмотреть на конкурентов.
4. Когда продукт может стать частью портфеля компании. Если сфера SaaS близка компании и есть желание реализовать свою экспертизу в продукте, то вполне хороший повод стартануть такое как внутренний продукт. Но будьте готовы, что будут не только прямые затраты на разработку, но и на косвенные на адаптацию.
5. Вы крупняк и платить даже большой команде разработки заметно дешевле.


Вы начали уже вайбкодить что-то своё вместо подписки?

Завидую джавистам в том что у них есть такие спикеры как Алексей Шипилёв (рассказывает всякое про сборку мусора) и Андрей Бреслав

Очень интересный подкаст про котлин и как его делали https://newsletter.pragmaticengineer.com/p/the-programming-language-after-kotlin

Альберто Брандолини с командой выкатили паттерны для проведения Event Storming

https://www.eventstorming.com/patterns/

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

Сегодня так много интересного!!!

1. Стрим с Владом Хононовым Loosely Coupled - Deep dive into coupling with Domain-Driven Design https://www.youtube.com/live/NGENigtNUck 🍾

2. Дискуссия Rebecca Wirfs-Brock и Mathias Verraes https://virtualddd.com/sessions/critically-engaging-with-models-a-conversation-with-rebecca-and-mathias/ 👏

3. Финальный тур ЛЧ 🙈

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

Вопросы, кейсы, комментарии пишите в этом треде или в личку, если нужна анонимность

Youtube
Zoom

Велкам! 🎉

Саша Поломодов запилил книгу сайт про Систем дизайн и все что около. Саша давно форсит эту тему — круто, что у него дошли руки все это скомпилировать.

https://system-design.space/

Сейчас разбираюсь в проекте на не совсем мне привычных Python/Django. Естественно использую агенты для изучения и модификации. Поменял код, поправил, потестил, залил в репу, создал ПР, мне накидали комментов — все как обычно.

Дальше я настроил в копайлоте github mcp, хотел по очереди получать правки, менять код и коммитить. Но промпт получился слишком общим. В итоге агент сам поправил весь код в соответсвии с комментами, запушил, прокомментил в пулл-реквесте через mcp. Ладно я сознательный — посмотрел коммиты, добил промптами пару вещей, которые явно не были проговорены в пулл-реквесте, дополнительно отревьювил код ллмкой и только после этого понес на повторное ревью.

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

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

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

Но на практике обучение и развитие — это не столько про личную мотивацию, но и про социальные отношения. Люди вкладывают силы потому, что считают сам процесс развития осмысленным и безопасным для себя. И одна из задач нас как лидеров (формальных или нет) — как раз придать процессу осмысленность и безопасность

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

Разбираться в этом мне будет помогать Ася Исакова — организационный психолог (магистр Work, Organizational & Personnel Psychology) и приглашённый лектор университета Pompeu Fabra (Барселона).

Почитать Асю можно в её канале: Это База | Компас конгруэнтности

Дата: 26 января 18-00 мск. Добавьте себе в календарь https://addcal.io/e/yd2ty2ewu9m6

Ссылки на стрим
Youtube
Zoom

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

Всем привет!

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

Я уже как-то писал, что тактическая часть DDD особо не развивается. Да, выходят какие-то статьи и даже книги, но они выглядят как компиляция прежних идей. Как будто бы мы выработали общий подход, как писать код в DDD-стиле, и пока что сообществу нечего сказать нового.

Но поднимаясь выше, на уровень архитектуры — уже становится интереснее: event messaging, мультитенантные архитектуры, различные интеграции систем. Есть паттерны/подходы, которые себя хорошо зарекомендовали, но жизнь преподносит новые вызовы, которые как-то надо преодолевать.

А можно заглянуть еще выше — на уровень социотехнических систем. Разработка продукта требует не только качественных технических решений, но и организационных, процессных, продуктовых и т. п. Кажется, именно здесь происходит все самое интересное. Team topologies, оргдизайн, коммуникации, презентация идей, мотивация, развитие доверия, психологическая безопасность — эти вещи могут бустануть разработку значимо сильнее, чем очередной паттерн или новая БД.

Ну и отдельной строкой идут LLM: как построение продуктов на базе AI, так и использование LLM для кодогенерации и сопутствующих процессов. Здесь тоже много неопределенности и hidden gems.

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

1. Team topologies, оргдизайн, организационная психология
2. System design, архитектура
3. LLM для разработки
4. Коммуникации
5. Technical excellence

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