Инженер и машина
8 статей о работе с AI, когда за результат отвечаешь ты.
Ко второй статье этого цикла у меня был готов удобный тезис: AI по умолчанию генерирует анемичные модели. Оставалось провести эксперимент и показать результат.
Эксперимент тезис не подтвердил. Среди ответов были богатые доменные модели с закрытым состоянием и поведением внутри агрегата. Но два убедительных решения разошлись в одном правиле: одно разрешало отменять черновик бронирования, другое запрещало. В задаче этого условия не было. Обе модели заполнили пробел сами.
Получилось интереснее запланированного разоблачения. Когда код выглядит хорошо, приходится внимательнее разбираться, какие решения уже приняты внутри него и откуда они взялись.
Этот вопрос проходит через весь цикл. Агент может быстро реализовать интеграцию, найти противоречие в легаси или предложить модель, до которой команда сама не дошла. А дальше нам всё равно нужно выяснить, подходит ли решение продукту, чем его проверить и кто отвечает за последствия. Причём ошибиться здесь может и агент, и разработчик, и техлид. Техлидом, который ошибся, в нескольких историях был я.
Код подешевел. Уверенность в решении – нет.
В цикле "Инженер и машина" я разбираю, как строить работу вокруг этой разницы: от одного незаданного правила в сгенерированном коде до команды, которая умеет принимать решения без постоянного участия техлида.
Из статей можно забрать конкретные приёмы: проверку доменной модели контрпримерами, схему независимых проверок работы агента, матрицу автономии и способ сохранять смысл решений между задачами. Реальные случаи соседствуют с экспериментами и учебными примерами; там, где предлагаю новую практику, прямо обозначаю, что ещё предстоит проверить.
Для кого
Для разработчиков, техлидов и соло-инженеров, которые уже работают с AI и отвечают за то, что доезжает до пользователей. Особенно если агент помогает закрывать задачи, а спорные решения, ревью и вопросы бизнеса всё равно сходятся к тебе.
Отдельная линия проходит через рост людей: какую работу оставить человеку, чтобы он учился думать самостоятельно, и как самому сохранить способность проверять решения, когда всё больше кода пишет машина.
С какой статьи начать
Каждую можно читать отдельно. Выбирай по своей задаче. Если хочется пройти весь путь, начинай с первой: от изменения работы инженера цикл постепенно приходит к тому, как устроить работу команды.
1. AI отнимает работу мидла, а не синьора – и почему это твоя проблема
Интеграцию, которую раньше делал разработчик, теперь собирает агент. Что после этого происходит с работой синьора? И где вырастет следующий синьор, если задачи, на которых учились мы сами, всё чаще уходят машине?
2. AI не всегда генерирует анемичные модели. В этом и проблема
Тот самый эксперимент, который сломал мой исходный тезис. Разбираю, как за аккуратными классами обнаружить придуманное бизнес-правило, а затем закрепить согласованное поведение в типах, тестах и правилах репозитория, чтобы следующий агент не выбирал его заново.
3. Согласованный термин тоже может быть ошибкой: как AI проверяет доменную модель по поведению
Вся команда одинаково говорила "контрагент". Только этот контрагент почему-то создавался ради звонка и завершался после обработки. Как с помощью AI оспорить привычную модель и добраться от спора о слове до изменений в контрактах, хранении и истории операций.
4. Легаси спорило само с собой. Как мы с AI собирали контракт поведения
PHP, интерфейс, админка и Confluence рассказывают разные версии одной системы. Как решить, что сохранять, менять и удалять при переписывании, пока агент ещё не превратил одну из этих версий в новый код.
5. Инженерный harness: почему "готово" недостаточно
Независимое ревью обнаружило нарушения контракта и безопасности, пропущенные самопроверкой агента. На рабочих эпизодах и учебном примере показываю свою модель harness – процесса выполнения и проверки работы: какие доказательства нужны до слияния и кто может его остановить.
6. Делегирование с AI: матрица риска и автономии
Где дать человеку или агенту действовать самостоятельно, а где заранее поставить точку остановки. Моя рабочая матрица учитывает риск задачи, возможность проверить и отменить результат, а для человека – ещё и то, чему он должен научиться.
7. Память проекта: что сохранять между задачами с AI
Проект уже различал неизвестную себестоимость и ноль. При переработке различие потерялось, а тест закрепил ошибку. Что сохранять для следующего исполнителя, чтобы передать смысл правила и при этом не превратить прежний алгоритм в вечный запрет на изменения.
8. Техлид и AI: как выстроить систему решений
Муж продолжает учиться, жена хочет перейти в следующий поток. За этой просьбой стоят две команды и разные представления о семейном доступе. История произошла ещё до нашей работы с агентами. Теперь на её примере собираю свою схему работы техлида с AI: кто принимает спорное решение, как команды проверяют общий результат и что помогает разобрать следующий случай без тебя.
Связь с первым циклом
В цикле "Проектирование, которое работает" я разбирал архитектуру как инструмент общения. Здесь к этому разговору присоединилась машина, которая умеет превращать наши договорённости и недоговорённости в код. Читать первый цикл заранее не нужно: необходимые связи есть в самих статьях.
Что дальше
Третий цикл будет ещё ближе к коду и ежедневной работе: как организовать разработку с AI, чтобы браться за более сложные задачи и доводить их до проверенного результата.
Начнём с контекста и спецификаций, проверим архитектурные варианты на прототипах, соберём повторяемые процедуры и инструменты для агента через Skills, MCP и CLI. Затем разберём ограничения действий, AI-ревью и оценку качества на наборе задач. С этой основой перейдём к работе нескольких агентов: как делить изменение, проверять совместный результат и выбирать конфигурацию, которая оправдывает своё время и стоимость.
В каждой статье будут конкретные способы работы, код или настройки, варианты применения и их ограничения. Можно будет забрать один приём в свой проект или пройти весь путь: от одной сложной задачи с агентом до управляемой работы над большим изменением. Рассчитываю на читателя, который уже попробовал AI в разработке и теперь хочет систематизировать и углубить свой опыт.
Истории между статьями, анонсы продолжения и обсуждение того, что получается у вас, – в Telegram.