Две двери, одни ворота: управление за пределами EDD
Правила онбординга и трения при разработке часто кажутся одной и той же проблемой. Но это не так.
Когда ваша команда разрастается до сорока разработчиков, вы не можете использовать одни и те же методы обучения для всех. Одни разработчики — эксперты в работе с ИИ-агентами. Другие — новички. Если вы напишете один набор правил для всех, вы потерпите неудачу.
Опытные разработчики будут игнорировать правила. Новички будут с ними бороться.
Вам необходимо разделить свой подход на два четких уровня:
Инструменты информирования (Awareness tools) Эти инструменты меняют то, что человек знает. Примеры включают комментарии ИИ при ревью или предупреждения линтера. Они работают как администратор на ресепшене: замечают детали и предлагают действия. Они эффективны только в том случае, если человек к ним прислушивается.
Инструменты управления (Governance tools) Эти инструменты меняют то, что человек может делать. Примеры включают защиту веток (branch protection) и шлюзы слияния (merge gates). Они работают как турникет. Они не ведут переговоров. Они останавливают процесс, если требования не выполнены.
Ошибка заключается в том, что вы используете администратора там, где нужен турникет. Предложение ИИ, которое разработчик игнорирует, — это не управление. Это просто шум.
Чтобы исправить это, используйте два отдельных уровня:
Уровень управления (The Governance Layer) Этот уровень компактен и универсален. Он применяется ко всем, независимо от навыков. Он включает такие правила, как запрет прямых пушей в защищенные ветки и обязательное ревью. Речь идет не о доверии, а о защите кодовой базы от высоких рисков, связанных с изменениями, вносимыми агентами.
Уровень вспомогательных структур (The Scaffolding Layer) Этот уровень персонализирован и гибок. Он включает такие шаги, как детальное планирование и подробное обоснование решений. Новички активно используют его для формирования профессионального суждения. Опытные разработчики могут снижать интенсивность его использования по мере роста. Это не награда за выслугу лет, а инструмент, который становится ненужным по мере роста мастерства.
Вам также следует учитывать риск самого изменения. Когда senior-разработчик касается сложного, сильно связанного файла, это создает больше рисков, чем когда junior-разработчик правит простую утилитарную функцию. Система должна реагировать на код, а не только на человека.
Наконец, сосредоточьтесь на ответственности. ИИ-агент может написать код, но результат принадлежит разработчику. Если разработчик не может объяснить причину внесенного изменения во время ревью, это изменение не должно быть принято (merge).
Перестаньте делить людей на уровни. Вместо этого предоставьте инструменты, которые позволят им самостоятельно управлять своими рисками.
Source: https://dev.to/karlheinz_reichel_7ee08d/two-doors-one-gate-navigating-governance-beyond-edd-5clj
Optional learning community: https://t.me/GyaanSetuAi