Модель тройного долга от соавтора фреймворка 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 пишет все больше кода? Потому что код становится все дешевле. А вот понимание: -зачем система существует;

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