Как разглядеть инженера за AI-агентом?
У вашего удалённого коллеги может быть идеальное резюме, GitHub, живой аватар в корпоративном чате и безупречно заполненные документы любого вида - да хоть на японском. Количество кода и даже его функциональность тоже мало что о нём скажут: результат его труда, весьма вероятно, произведён или основательно переработан LLM и несёт её характерный «акцент». Да, известно, что все носят маски. Однако теперь эту маску обеспечивает технология.
Распределённые инженерные команды уже стали нормой: доступ к широкому рынку труда перевешивает неудобства. Однако лёгкой такая работа не бывает - фокус, общий ритм, культура команды и обмен опытом на удалёнке держатся плохо, и оптимальной схемы мы, похоже, так и не нашли. А AI-агенты ещё и добавляют сложности в эту, несовершенную, систему.
Казалось бы, ничего нового — но разница в масштабе. Раньше фасад требовал усилий и рано или поздно трещал. Теперь его можно производить систематически, в промышленных объёмах и без видимых швов. Всё, что приходит от коллеги асинхронно — коммиты, тесты, документация, - теперь говорит скорее о том, как он настраивает своё LLM-приложение и подбирает ему скиллы, чем о нём самом. Понять человека и оценить его вовлечённость остаётся возможным только в моменты прямой коммуникации. Поэтому сейчас совершенно непонятно, как устанавливать контакт с удалённым коллегой и чувствовать пульс инженерного процесса.
Зачем нам вообще знать реальное положение дел? Что в действительности умеет коллега? Насколько он вдумчив и ответственен, насколько критичен к результатам своего труда? Без ответов нельзя планировать, оценивать трудоёмкость и прикидывать сроки. Но важнее другое: нельзя решить, кому доверить архитектурно значимый кусок системы.
Внимательный читатель резонно спросит: если результат проекта — это продукт, и он создаётся по графику, какая разница, что происходит на стороне удалённого коллеги?
Разница в том, что AI напишет не только код, но и регрессионные и нагрузочные тесты — вне зависимости от квалификации инженера. И часть этой большой работы может оказаться подгонкой под результат, чем AI частенько грешит: тест, подкрученный так, чтобы позеленеть, выглядит ровно как честный. Какие шаги предпринимает коллега, чтобы этого не случилось, мы не знаем, его техпроцесс работы с AI непрозрачен. И ещё: расширяемость кода, простота поддержки и количество потенциальных проблем - слищком абстрактные понятия для нынешного AI. А как решил эти вопросы инженер и почему из кода не видно.
Приведу пример из практики — Self-Join Elimination в PostgreSQL. Фича шла в ядро семь лет, один раз откатывалась уже после коммита и после релиза 18 продолжала собирать багфиксы. Недавно Tom Lane переделал её. Раньше, обнаружив самосоединение, Postgres удалял избыточный JOIN и перестраивал все ссылки на него в дереве запроса и структурах плана. Tom от этого отказался: новая реализация правит только дерево запроса и перезапускает планирование с нуля уже по новому дереву. По формальным меркам решение выглядит хуже - планирование дорожает. Выигрыш в другом: исчезает целый класс ошибок, которыми фича успела обрасти.
Заметьте, где здесь виден инженер. Ни диф, ни зелёные тесты не покажут, что человек осознанно заплатил скоростью планирования за надёжность. Мы знаем об этом только потому, что он это проговорил. И это, пожалуй, единственная зацепка, которая у нас остаётся: требовать от коллеги не код с тестами, а сформулированные компромиссы — почему так, чем заплатили, от чего отказались. Ровно то, чего pgsql-hackers требует от любого патча: без обоснования он принят не будет.
Таким образом, качественный и сложный код сам по себе перестал быть мерилом уровня инженера и что должно придти этому на смену, пока непонятно. А какие методы работают у вас при управлении распределённой командой в эпоху AI-агентов? Что помогает, а что уже очевидно устарело?
THE END.
11 сентября 2026 г., Утрехт, Голландия.
