Командная разработка с ИИ. Часть 1 — диагностика проблем

[dkfbm]

Онбординг деградирует до фольклора: «поставь какую‑нибудь модель, настрой какой‑нибудь harness, попробуй такой промпт».

Ну, в командах, где работа действительно организована таким образом, всё вышеуказанное справедливо. Только вот это означает, что там и до ИИ был бардак. Реально нужно делать строго наоборот:

• Единая среда разработки. У каждого разработчика поднимается идентичная виртуалка или докер, и код запускается/проверяется только там.

• Правила, скиллы, хуки общие, лежат в гит.

• Задачи ставятся не промптами, а либо спецификациями в .md (которые тоже лежат в гит), либо прямыми ссылками на тикеты.

• Все в команде следуют правилу: за исключением мелких коррекций, агенты никогда не пишут код сразу; сначала уточнённую спецификацию и план исполнения (которые становятся артефактами гит), и только потом код.

• Настроен CI пайплайн, включающий в себя ревью независимым агентом.

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

Если эти условия выполнены, то проблем, подобных описанным в статье, быть не должно вовсе. Разве что вопрос балансировки расхода токенов между разными эккаунтами сохраняется – но по моему опыту, не так уж он и критичен.

[Tr0sT]

по сути ты предлагаешь ужасную унификацию: у всех идентичные скиллы/окружение/модели - кому захочется так работать, как в такой ситуации развиваться? Зачем в этой ситуации вообще разные разработчики, достаточно оставить только одного, который и будет развивать/ревьювить в этом пайплайне. Плюс такой подход не решает проблему взаимодействия разных отделов между собой - мясной прокси по-прежнему необходим, чтобы задать вопрос чужому агенту.

[dkfbm]

по сути ты предлагаешь ужасную унификацию

Понятно: сначала сами создаёте себе проблемы, а потом пишете статьи о том, что инструмент, отказывающийся поддерживать бардак плох. Унификация окружения – краеугольный камень профессиональной разработки. Иначе через раз будут споры из серии "у меня на компе работает, а что там у вас на проде, понятия не имею, спрашивайте у админов".

кому захочется так работать

У меня буквально всем. И даже мысли ни у кого не возникает, что может быть иначе – кому охота регулярно разбираться, почему явный баг на проде локально не воспроизводится.

Зачем в этой ситуации вообще разные разработчики, достаточно оставить только одного

Если объём работы таков, что один справится – значит, одного. Зачем тогда больше?

[Tr0sT]

Мне кажется, ты смешиваешь две совершенно разные вещи.

Унификация окружения, в котором код собирается, запускается и проверяется, — да, тут я вообще не спорю. Docker/VM/Nix, единые версии зависимостей, воспроизводимый CI — всё это как раз и нужно, чтобы не было «у меня работает, а на проде нет».

Но унификация того, как именно разработчик производит код, — это уже совсем другая история. Требовать от всех один harness, одну модель, один набор скиллов и один способ взаимодействия с агентом — примерно как требовать от всех одну IDE, одинаковые плагины, хоткеи и цветовую схему просто потому, что код в итоге должен одинаково собираться.

[dkfbm]

примерно как требовать от всех одну IDE, одинаковые плагины

Разумеется, IDE тоже. Всем покупается по лицензии, а в гит лежит конфигурационный файл – чтобы у всех всё было одинаково. А как иначе? На фига мне, например, гемор с тем, что у одного в IDE два пробела, а у другого таб – и из-за этого каждый коммит меняет сотни файлов? Плагины – дело относительно индивидуальное, а вот линтеры у всех должны быть идентичными – что в разных IDE далеко не всегда возможно.

просто потому, что код в итоге должен одинаково собираться

Озадачен. А зачем мне разработчик, у которого код собирается иначе, чем у других? Он же и работать будет не так, как мне нужно.

[Tr0sT]

Табы или пробелы — это вообще не вопрос выбора IDE, а вопрос кодстайла. Чтобы гарантировать единый формат кода, совершенно не требуется заставлять всех пользоваться одной IDE с одинаковым конфигом.

Хочет один работать в VS Code, другой в IDE от JetBrains, третий в Visual Studio — какая мне разница, если на входе у них одна задача, а на выходе код соответствует одним требованиям и проходит одни проверки?

Если конкретная компания умеет закупить всем только одну IDE, но не умеет купить разные лицензии разным разработчикам — окей, это ограничение конкретной компании, но из него совершенно не следует, что одинаковая IDE — краеугольный камень профессиональной разработки.

И «код должен одинаково собираться» это был пример абсурдного обоснования требования одинаковых хоткеев/плагинов и прочего.

[dkfbm]

Если конкретная компания умеет закупить всем только одну IDE, но не умеет купить разные лицензии разным разработчикам

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

То же самое и с AI-assisted development: базовые правила едины, а для однотипных задач делаются общедоступные скиллы – дабы каждому не приходилось изобретать их заново, да ещё и со своими отличиями. И программистов такой подход более, чем устраивает: он значительно сокращает количество рутины. А вот составление грамотного описания фичи для передачи ИИ, подготовка критериев готовности и т.п. – работа весьма творческая, всем нравится.

[Tr0sT]

Не надо всё-таки говорить за всех: вкусовщина конкретного лида вполне может устраивать его команду, но из этого не следует, что она нравится программистам вообще :) Я могу понять стандарт предприятия для ОС, IDE и плагинов — максимум кому-то будет неудобно. Но AI унификация harness/model уже непосредственно влияет на результат и потому гораздо опаснее. Если всем навязать один harness, одну модель и общий набор скиллов, ты сильно ограничиваешь разработчиков в возможности экспериментировать с тем, как вообще решать задачи с помощью AI. А в настолько быстро меняющейся области зафиксировать один «правильный» способ работы сверху — по-моему, заведомо тупиковый путь.

[dkfbm]

Но AI унификация harness/model уже непосредственно влияет на результат и потому гораздо опаснее.

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

[Tr0sT]

Как вы развиваете свой ИИ пайплайн в команде? Например,кто-то настаивает на том, что спеку нужно делать не фэблом, а свармом из квенов. Как вы такие противоречия улаживаете?

[dkfbm]

Как вы такие противоречия улаживаете?

Нет таких противоречий вообще. Есть team account Claude Code, он всех устраивает. Ловить блох в разнице моделей – непродуктивная трата времени. Ну найдётся какой-то единичный случай, где Codex отработает чуть лучше. Пускай, время дороже, а результат и так устраивает – иначе он ни ревью, ни QA не прошёл бы.