Присылаешь что-то умное своей аудитории!

Все такие «фууууууу, что за фигня! Перешлюка я это!»

А где лайки?!

Модель тройного долга от соавтора фреймворка SPACE

Маргарет-Энн Стори, соавтор фреймворка SPACE для повышения продуктивности разработчиков, недавно представила свою модель тройного долга (Triple Debt Model), в которой скрытые человеческие издержки ускоренной с помощью ИИ разработки программного обеспечения рассматриваются в трех категориях:
технический долг, который накапливается в коде.
когнитивный долг, который накапливается в людях, входящих в команду.
долг намерений, который накапливается во внешних знаниях, состоящих из лежащих в основе проекта соображений, целей и проектных ограничений, которые недостаточно задокументированы.


И идея там довольно простая:
AI позволяет нам быстрее производить код, но это совсем не значит, что мы автоматически быстрее производим хорошие и понятные системы.
Просто долг начинает накапливаться немного в других местах😉
Всего Стори выделяет три вида долга:
1. Технический долг
Плохие архитектурные решения, костыли, сложный код, отсутствие тестов и все то, что потом делает систему дорогой в изменении и поддержке.
Причем тут есть забавный парадокс.
Именно этот долг AI потенциально умеет неплохо сокращать:
-отрефакторить код;
-написать тесты и т.п.
То есть код может становиться даже лучше.

2. Когнитивный долг
Это долг, который накапливается уже в голове разработчика: агент написал 1000 строк хорошего кода. И даже тесты все зеленые. Так что вперед и PR в проде.
Только инженер, который этот PR принял, понимает систему чуть хуже, чем если бы писал это изменение самостоятельно. А потом еще один PR. И еще один.
Иииии в какой-то момент получается довольно странная система:
код работает, но никто толком не понимает почему.
Скорость производства кода растет быстрее скорости нашего понимания системы.
Вот это Стори и называет cognitive debt.

И да, тот факт, что скорость производства выросла - это супер! В этом вся суть моей работы, в принципе.
3. Долг намерений — Intent Debt
А вот это типовая проблема, которая всплыла наверх. Раньше она тоже была, но мы особо ей внимание не уделяли.
Можно прекрасно понимать, как работает код, но совершенно не понимать:
почему он работает именно так?
Какие продуктовые ограничения существовали? Что вообще хотел пользователь? Какие компромиссы были приняты?
Все это обычно живет где-то между:
- ADR;
- документацией;
- и, конечно же в голове того самого Тим-лида😁
А теперь представьте AI-first разработку.
Один агент написал изменение.
Через полгода другой агент должен его изменить.
И второй агент пытается понять намерения первого агента… по коду первого агента.
Ну удачи.

В мире AI-разработки документация, ADR, спецификации, acceptance criteria и domain model — это уже не какая-то бюрократия рядом с разработкой.
Это внешняя память вашей системы (на следующей неделе расскажу, как решают и эту задачку)
Причем память нужна уже не только людям, но и агентам.
Последние пару лет мы в основном спрашивали:
как заставить AI писать больше хорошего кода?
Но следующий вопрос будет:
как сделать так, чтобы люди и AI продолжали понимать систему, пока AI пишет все больше кода?
Потому что код становится все дешевле.
А вот понимание:
-зачем система существует;
- почему она устроена именно так;
- какие ограничения нельзя нарушать;
становится только дороже.
И возможно, через несколько лет главным инженерным активом компании будет уже не сам код.
А накопленный контекст вокруг него.

А вот тут мы с Сашей Поломодовым разбирали разные фреймворки и историю их развития

Не грустите там, у нас всегда есть План Б!

Вот такую красоту мне прислали почитать)

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

#пятничное
Ну че, было?

💯 - аххахаха, ваще
❤️ - да, но мне не разрешили смеяться над этой картинкой
🙈 - когда поняла, что это всегда ты)

Наташка водила меня сегодня по музеям!

Главным впечатлением считаю - водный экскаватор!
Вы когда-нибудь такой видели?

Я ваще в восторге!

Сегодня шел 3670 день, как я пытаюсь накачаться😁

И не говорите мне, что у вас получается лучше))

У разработки есть свой налог на масштаб

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

DX выкатили свежие Core 4 бенчмарки по 500+ компаниям. Там есть интересный срез: как отличаются метрики у инженерных организаций разного размера.

Не динамика во времени, а сравнение групп:

— <100 инженеров
— 100–500
— 500–2500
— 2500+

Иииии вот что видно.

1. Change Fail Rate растет с масштабом

У tech-компаний:
<100 инженеров - 4,0%
2500+ - 4,8%

У non-tech:
3,95% → 5,26%

То есть большие организации чаще выпускают некачественные решения.

2. Developer Experience начинает проседать

Медианный DXI у tech-компаний:

— <100: 66
— 100–500: 66
— 500–2500: 67
— 2500+: 64

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

3. PR на инженера тоже становится меньше

— <100: 3,8 PR/неделю
— 2500+: 3,35

Примерно минус 12%.
PR, конечно, не productivity, но сигнал вполне понятный.

И вот тут мне нравится термин:

Налог на масштаб разработки

Чем больше организация, тем больше ресурсов съедают:

— зависимости;
— согласования;
— коммуникации;
— legacy;
— инфраструктурная сложность;
— процессы управления процессами.
Код мы научились производить быстрее, тут спасибище AI.

А вот организация вокруг его производства быстрее пока не стала: все те же процессы, все те же команды, все те же люди.

Поэтому одна из ключевых задач Developer Platform / DevEx - не просто ускорять написание кода, а снижать налог на масштаб.

Иначе дадим каждому инженеру AI-агента…
…а потом они оба будут три дня ждать ревью 😁

ой, ну раз вам нравится, вот вам ПДФка с разбором))))

Вот этим вот всем я +/- и занимаюсь на работе))

Пу-пу-пуууу
То есть нас уже предупреждали 😁