Модуль 2 · Урок 5 · ~10 минут

Не строй лишнего

Одна идея этого урока: каждая фича, добавленная «на будущее», – это сложность, которую ты оплачиваешь сегодня.

Знакомая ситуация

Ты заказываешь агенту планировщик для школы. В списке: задачи, календарь – и «а ещё сделай роли для команды, мультиязычность на будущее и интеграцию с CRM, вдруг пригодится». Агент бодро строит всё за вечер. Красота.

Через месяц: ролями пользуешься только ты один, но каждая правка теперь спотыкается о проверку прав. Мультиязычность заставляет менять любой текст в трёх местах. CRM-интеграция сломалась при обновлении – хотя её ни разу не включали. Ты платишь за фичи, которые не работают на тебя.

YAGNI (You Aren't Gonna Need It) – «тебе это не понадобится»: не строй под предполагаемое будущее, строй под известное настоящее. Ошибёшься с прогнозом – заплатишь дважды: за стройку и за жизнь с построенным.

Сколько на самом деле стоит фича

Мартин Фаулер раскладывает цену «фичи на будущее» на три части – и видимая часть тут самая маленькая:

1
Стоимость постройки cost of buildВремя на обдумывание, постройку и проверку. С ИИ-агентом эта часть почти исчезла – и именно это делает ловушку коварнее.
2
Стоимость ношения carrying costПостроенное живёт в системе и мешает всему остальному: каждая новая фича обходит его, каждая правка рискует его сломать, каждый разбор бага требует его учитывать. Платишь ежемесячно, как за аренду.
3
Стоимость задержки cost of delayПока строилось ненужное, не строилось нужное. Фаулер приводит данные: даже у тщательно спланированных фич лишь около трети реально улучшают целевые показатели.

Отсюда следствие для работы с агентом: постройка подешевела, а ношение – нет. Агент с радостью построит всё, что попросишь, и ещё предложит сверху. Единственный фильтр «а надо ли вообще» – у тебя. Список хотелок, растущий на ходу, имеет своё имя – расползание границ (scope creep) – и лечится только словом «нет».

MVP – это эксперимент, а не огрызок

Частое недоразумение: MVP (minimum viable product) понимают как «урезанный продукт, стыдно показать». На самом деле MVP – это минимальный эксперимент для проверки главной гипотезы: «люди вообще хотят записываться на консультации через бота?». Всё, что не помогает ответить на этот вопрос, из первой версии вычёркивается – не потому что лень, а потому что до ответа любая фича может оказаться стройкой не туда.

Важная оговорка Фаулера: YAGNI – не оправдание неряшливости. Он не разрешает пропускать тесты и не запрещает наводить порядок в структуре. YAGNI – только про фичи впрок; порядок в коде как раз и делает возможным «добавим, когда понадобится».

Как думают три уровня

Джун · делает всё из спискаПолучил десять пунктов – построил десять пунктов. Вопрос приоритетов для него решён тем, что «заказчик так написал». Сложность растёт со скоростью списка.
Мидл · закладывает гибкость про запас«Сделаю сразу универсально – вдруг понадобится». Строит настройки, абстракции и переключатели под будущее, которое сам придумал. Благие намерения, тот же carrying cost.
Сеньор · вычёркиваетСмотрит на список и спрашивает у каждой строки: «что сломается, если этого НЕ делать сейчас?». «Нет» для него – архитектурное решение, у которого есть автор и причина, а не отказ работать.

Проверь себя

1. Агент предлагает: «сделаю систему уведомлений сразу с поддержкой Telegram, email, SMS и push – на будущее». Сейчас тебе нужен только Telegram. Ответ сеньора?

2. Что такое MVP в понимании сеньора?

3. Почему с ИИ-агентами принцип YAGNI стал ВАЖНЕЕ, а не менее важен?

Что говорить агенту уже сегодня

Источники