Connect with us

Разработка

Никакого программирования до 10 утра

Инженерное дело сегодня — это уже не просто написание кода. Вот стратегия одного стартапа по созданию проектов в эпоху ИИ-агентов.

Опубликовано

/

     
     

Стартап, с которым я работаю, полностью пересмотрел свою стратегию. Они быстро продвигались вперед, но за последний месяц их метод работы сломался из-за Claude Code и Codex. Поэтому они собрались в «оперативном штабе» и перестроили свою работу с нуля.

Их первое новое правило: никакого кодирования до 10 утра. В течение двадцати лет инженерная культура была направлена ​​на максимизацию времени, затрачиваемого на написание кода. Отмена совещаний. Блокировка календарей. Прекращение всего, что отвлекает инженера от программирования. Эта команда делает прямо противоположное. Каждое утро инженеры теперь работают в парах: они собираются вместе, составляют промпты, определяют цели и настраивают агентов на успех. Только после этого агенты начинают работать.

Их стратегия — это не «использовать ИИ для ускорения кодирования». Это полная инверсия. Теперь работу выполняют агенты, а не инженеры. Инженеры следят за тем, чтобы агенты могли хорошо выполнять эту работу. За последнее десятилетие я видел десятки команд, от DoorDash до моего собственного стартапа. То, что они придумали, — это самая наглядная версия того, как на самом деле работает инженерия сегодня. Я спросил, могу ли я поделиться этим. Вот их руководство:

Агенты — основные пользователи

  1. Создавайте решения для агентов, а не для людей. Каждая система, хранилище данных, соглашение об именовании и артефакт знаний должны быть разработаны для ИИ-агента как основного потребителя. Люди взаимодействуют с системами через агентов, когда это возможно.
  2. Код — это контекст, а не библиотека. Агенты читают код, чтобы понять, что он делает, а затем генерируют свою собственную версию. Не оптимизируйте код для повторного использования разными людьми. Оптимизируйте код для его понимания агентом. Сам код теперь является документацией.
  3. Данные — это реальный интерфейс. Правильный интерфейс между двумя компонентами — это хорошо структурированный артефакт данных, а не вызов функции. Чистые данные позволяют агентам создавать системы, не получая указаний, как это делать.
  4. Максимизируйте использование агентов. Если команда едет на работу, а ничего не работает, это пустая трата ресурсов. Агенты должны работать ночью, в дороге, на совещаниях, асинхронно. Самая дорогая вещь в системе — это агент/вычислительный аппарат, простаивающий в ожидании человека.

Как мы формулируем задачи и разрабатываем решения

  1. Сначала цель и ограничения. Прежде чем что-либо строить: сформулируйте цель одним предложением, перечислите ограничения, определите критерии успеха. Если вы не можете сформулировать цель одним предложением, значит, вы недостаточно хорошо понимаете проблему, чтобы её реализовать.
  2. Не описывайте процесс, описывайте результат. ИИ сам определяет процесс. Вы оцениваете результат по отношению к целевой функции. Это заменяет традиционные нормативные документы. Пишите целевые функции, а не планы реализации.
  3. Определяйте правила, а не структуру. Не переусложняйте схемы и форматы. Установите соглашения об именовании, требования к метаданным и правила версионирования. Пусть агенты сами разберутся с остальным.
  4. Проверяйте результат, а не код. Не читайте каждую строку, написанную агентом. Тестируйте код на соответствие цели. Если он проходит проверку, выпускайте продукт. Если нет, пересматривайте цели и ограничения. Проверка кода в том виде, в каком мы её знали, — это излишние затраты, которые системе больше не нужны.
  5. Когда вы создаёте новый способ, откажитесь от старого. Никаких параллельных реализаций. Старые пути выполнения кода удаляются немедленно. Кодовая база — это контекст агента. Каждый «мертвый путь» — это шум, ухудшающий производительность агента.
  6. Мыслите системно. Если вы делаете что-то вручную более двух раз, автоматизируйте это. Если человек повторяет задачу, система настроена неправильно. Цель: настроить, запустить, проверить результат, двигаться дальше.

Совместная работа

  1. Никакого программирования до 10 утра. Руки прочь от клавиатуры. Первый час или два каждого утра — для обсуждения, согласования и совместного составления промптов. Как только команда согласует, что нужно построить и как настроить агентов, можно начинать кодирование и позволять агентам работать.
  2. Оптимизируйте время, а не токены. Если в 10 раз больше токенов экономит день, потратьте токены. Узкое место — время принятия решений человеком, а не вычислительные затраты.
  3. Индивидуальная автономия, общие интерфейсы. Каждый использует свою IDE, стиль промптов и рабочий процесс. Стандартизируются: шаблоны данных, спецификации целей, обязанности компонентов. Все остальное — личный выбор.
  4. Немедленно указывайте на антипаттерны. Когда вы замечаете, что сами или кто-то другой возвращается к старым привычкам, разрабатывает решения для людей, а не для агентов, накапливает мертвый код, пропускает спецификации, отмечайте это. Старые привычки быстро накапливаются.
  5. Предпологайте, что за 3 месяца все изменится. Технологии сейчас меняются ежемесячно. Каждое ваше сегодняшнее решение вскоре окажется неправильным. Стройте модульно. Минимизируйте зависимость на каждом уровне.

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

Если вы руководите инженерной командой и у вас еще не было своего варианта «оперативного штаба», проведите совещание. Выбросьте старый сценарий. Напишите новый.

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

Источник

Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Telegram

Популярное

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: