Никакого кода до 10 утра: как команда перестроила разработку под агентов

Привет! Хочу обсудить статью о стартапе, который полностью пересмотрел свой подход к разработке после того, как Claude Code и Codex сломали их привычный ритм работы. Они собрали рабочую группу и переписали правила с нуля. Главное из них: никакого программирования до 10 утра. Восемь часов утра отводятся на обсуждение, согласование и совместное написание промптов. Только после этого агенты начинают работать.

Суть нового подхода:

Авторы статьи формулируют несколько ключевых принципов:

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


• Код - это контекст, а не библиотека. Агенты читают код, чтобы понять, что он делает, а затем генерируют свою версию. Не оптимизируйте код для переиспользования людьми. Оптимизируйте его для понимания агентом. Код сам по себе становится документацией.


• Данные - реальный интерфейс. Правильный интерфейс между компонентами - это хорошо структурированный артефакт данных, а не вызов функции. Чистые данные позволяют агентам строить системы без указаний, как это делать.


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

Формулирование задачи:

• Перед началом работы нужно сформулировать цель одним предложением, перечислить ограничения и определить критерии успеха. Если вы не можете уложить цель в одно предложение - вы недостаточно понимаете проблему.


• Не описывайте процесс, описывайте результат. ИИ сам определит процесс. Вы оцениваете результат по отношению к целевой функции. Это заменяет традиционные технические задания.


• Определяйте правила, а не структуру. Не переусложняйте схемы и форматы. Установите соглашения об именовании, требования к метаданным и правила версионирования. Пусть агенты сами разберутся с остальным.


• Проверяйте результат, а не код. Не читайте каждую строку, написанную агентом. Тестируйте код на соответствие цели. Если он проходит проверку - выпускайте. Если нет - пересматривайте цели и ограничения. Код-ревью в привычном виде становится излишним.

Как организовать совместную работу:

• Никакого кода до 10 утра. Первый час-два каждого утра служит для обсуждения, согласования и совместного составления промптов. Как только команда определила, что строить и как настроить агентов, можно начинать кодинг.


• Оптимизируйте время, а не токены. Если в 10 раз больше токенов экономит день - тратьте токены. Узкое место - время принятия решений человеком, а не вычислительные затраты.


• Немедленно указывайте на антипаттерны. Если замечаете, что кто-то возвращается к старым привычкам (разрабатывает решения для людей, а не для агентов, накапливает мертвый код, пропускает спецификации) - отмечайте это. Старые привычки быстро накапливаются.

Вывод автора:

Через полгода, по мнению автора, будет два типа команд: те, кто перестроил работу с нуля, и те, кто все еще пытается вписать агентов в старый сценарий. Вторая группа будет проигрывать командам вдвое меньшего размера. Прямо сейчас самое время создать свою рабочую группу, выбросить старый сценарий и написать новый. Агенты изменили правила игры - пора менять и свои привычки.

Мое мнение:

Мне кажется, эта стратегия работает не для всех. Она предполагает, что команда уже умеет хорошо формулировать задачи и понимает, чего хочет. А если нет? Тогда утро без кода превратится в утро без результата. Промпты будут красивыми, а код - бесполезным.

И еще момент про «проверяй результат, а не код». Звучит круто, но на практике часто бывает, что код работает, но написан так, что через месяц в нем никто не разберется. А следующий агент, который будет его читать, просто сломается от неожиданностей. Так что ручное ревью, наверное, пока рано отменять.

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