Часть серии «Покорение энтропии»

Большинство моих проблем с кодом, сгенерированным ИИ, связаны с доверием. Доверяю ли я человеку, написавшему этот тикет? Доверяю ли я инженеру, открывшему этот PR, что он понял тикет и правильно направил агента по кодированию для его реализации? Доверяю ли я реализации агента по кодированию? Доверяю ли я нашему набору тестов, что он перехватит регрессии до попадания в продакшн? Доверяю ли я нашему CI/CD, что он правильно соберет, протестирует и задеплоит наши изменения? Доверяю ли я нашей настройке наблюдаемости, что она предупредит нас, когда код, сгенерированный ИИ, сломает продакшн? Доверяю ли я ИИ SRE (инженеру по надежности сайта), что он правильно диагностирует проблему и поможет нам ее смягчить? Доверяю ли я Git Hub, что у него не будет инцидента, когда он нам нужен больше всего? Доверие трудно завоевать и легко потерять. Поэтому я считаю критически важным воспитывать культуру доверия внутри инженерной команды. Вы должны доверять инженерам делать правильные вещи.

Поощрение подотчетности

Я считаю полезным четко сообщать что-то вроде: «Вы подотчетны за то, что отправляете. Если это сломает продакшн, а вы написали PR, вы должны быть на месте, чтобы это исправить.»

Если инженеры сделаны подотчетными за код, который они отправляют, им должна быть дана возможность производить его своими предпочтительными методами. Даже если вы не фанат ИИ, вы должны признать, что агенты ИИ генерируют очень много кода очень быстро. Код все еще нужно генерировать, и ожидание в том, что теперь генерация большого количества кода дешева. Чтобы справиться с этим, инженерам должно быть позволено принять некоторые меры, чтобы обеспечить, чтобы качество кодовой базы не деградировало. В здоровой организации инженеры должны доверять друг другу, что они будут пушить только код разумного качества. Я говорю разумного, потому что не прагматично одержимо относиться к качеству и пытаться всегда отправлять 100% идеальный код. Даже до агентов по кодированию большинство кода уже было баганым беспорядком! Поэтому понятно, когда доставляется решение «достаточно хорошее». Часто мы обмениваем скорость доставки на качество и несем некоторый технический долг.

Вот некоторые практики, которые я нашел полезными для облегчения инженерной подотчетности в этой новой эре кодирования:

Руководящие принципы кодирования

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

Детерминированные инструменты

Интенсивно используйте детерминированные инструменты для обеспечения качества кода. Типизированные языки, линтеры, обнаружение мертвого кода, сканирование безопасности, CI/CD и так далее. Все эти инструменты существовали до агентов по кодированию и помогают нам в борьбе с некачественным кодом. (Оставайтесь в курсе для последующего поста с конкретными рекомендациями!)

Принуждение к малым PR

Дайте инженерам возможность отклонять непроверяемые PR. Если возможно, зафиксируйте этот критерий, чтобы любые непроверяемые PR немедленно отклонялись. Конечно, убедитесь, что оставлено место для исключений.

Владение тестами

Пишите тест-кейсы вручную. Это похоже на работу бизнес-аналитика. Глубоко подумайте о функции и определите правильные сценарии тестирования. Обсудите это внутри команды. Агенты по кодированию могут реализовать тесты, но они должны быть определены людьми.

Вкус к продукту

Работайте в тандеме с продуктом, чтобы иметь связное видение продукта. Очень легко сойти с ума с ИИ и реализовать любую функцию, которая приходит в голову. Убедитесь, что вы реализуете только полезные функции, которые действительно приносят ценность пользователям!

Прототип

Одноразовый код. Поскольку код теперь очень легко генерировать, это хорошая возможность попробовать разные подходы. Не просто позвольте агенту по кодированию сгенерировать одно решение. Например, попробуйте три радикально разных подхода и выберите тот, который лучше всего подходит для проблемы и существующей системы.

Фокус на результате

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