Forward from: Уставший техдир
Я попробовал — агенты пишут дерьмовый код
Допустим, а что ты сделал, чтобы они писали хороший код?
Представьте, что к вам пришел очень продуктивный и крайне способный разработчик. Но есть нюанс — у него амнезия. Ага. Ну то есть его обнуляет каждое утро
Вот тут и кроется жопа. Оказывается, ему недоступно все что мы, человеки, накапливаем в разговорах про красоту кода и архитектурные решения. Именно эти негласные правила и есть требования к коду. «не используй DTO модели», «используй стейтменеджер ххх», «сначала тесты, потом багфикс». Именно по ним мы сравниваем результаты и корчим недовольное лицо, когда агент "не угадал", как надо было сделать работу
Чтобы это исправить, вам нужно сформулировать и положить в репу рядышком:
1. Соглашения. Вы договорились, что используете конкретный фреймворк, практику, подход, паттерн, конкретные библиотеки в угоду другим? Запишите все свои конвенции, в отдельные файлики
2. Архитектурные решения. Решили сменить сборщик? Запретить складывать модели в общую либу, сделать асинхронную загрузку всех страниц? Вынесли DI и вывернули внешние зависимости? Фиксируем в ADR: решение, альтернативы, последствия (MADR формат Майкла Найгарда)
3. Процедурные знания и скрипты. Как профайлить, что запускать, вот тебе скрипт, а вот бейслайн, на что смотреть, как действовать дальше. Все знания которых не хватает модели. Обычно такое пакуют в скиллы, но можно и просто положить файликом
4. Цепочки действий. Если тебе пришли с багом: то делай раз, используй два, не забудь прочитать три, сходи в систему четыре, запусти скрипт, заведи таск, напиши, протестируй, про валидируй, пересобери, пашни, дождись сборки, почини если сломалась, открой в браузере, прокликай, актуализируй статус связанных задач по спеке из файла такого-то
5. Директивы. Фиксируй принципы, поведенческие ожидания. «Следуй DRY, но балансируй здравый смысл KISS”, «Если делаешь интерфейсы, сначала прочитай specs/UX.md», «заработай миллион долларов, не делай ошибок»
И внезапно, после всей проделанной работы оказывается что агент способен выдавать результаты, получше некоторых синьоров, способен брать работу и часами автономно писать код, отлаживать, тестировать, оптимизировать, крутить производительность, фиксить сборки в пайплайнах и так далее
Допустим, а что ты сделал, чтобы они писали хороший код?
Представьте, что к вам пришел очень продуктивный и крайне способный разработчик. Но есть нюанс — у него амнезия. Ага. Ну то есть его обнуляет каждое утро
Вот тут и кроется жопа. Оказывается, ему недоступно все что мы, человеки, накапливаем в разговорах про красоту кода и архитектурные решения. Именно эти негласные правила и есть требования к коду. «не используй DTO модели», «используй стейтменеджер ххх», «сначала тесты, потом багфикс». Именно по ним мы сравниваем результаты и корчим недовольное лицо, когда агент "не угадал", как надо было сделать работу
Чтобы это исправить, вам нужно сформулировать и положить в репу рядышком:
1. Соглашения. Вы договорились, что используете конкретный фреймворк, практику, подход, паттерн, конкретные библиотеки в угоду другим? Запишите все свои конвенции, в отдельные файлики
2. Архитектурные решения. Решили сменить сборщик? Запретить складывать модели в общую либу, сделать асинхронную загрузку всех страниц? Вынесли DI и вывернули внешние зависимости? Фиксируем в ADR: решение, альтернативы, последствия (MADR формат Майкла Найгарда)
3. Процедурные знания и скрипты. Как профайлить, что запускать, вот тебе скрипт, а вот бейслайн, на что смотреть, как действовать дальше. Все знания которых не хватает модели. Обычно такое пакуют в скиллы, но можно и просто положить файликом
4. Цепочки действий. Если тебе пришли с багом: то делай раз, используй два, не забудь прочитать три, сходи в систему четыре, запусти скрипт, заведи таск, напиши, протестируй, про валидируй, пересобери, пашни, дождись сборки, почини если сломалась, открой в браузере, прокликай, актуализируй статус связанных задач по спеке из файла такого-то
5. Директивы. Фиксируй принципы, поведенческие ожидания. «Следуй DRY, но балансируй здравый смысл KISS”, «Если делаешь интерфейсы, сначала прочитай specs/UX.md», «заработай миллион долларов, не делай ошибок»
И внезапно, после всей проделанной работы оказывается что агент способен выдавать результаты, получше некоторых синьоров, способен брать работу и часами автономно писать код, отлаживать, тестировать, оптимизировать, крутить производительность, фиксить сборки в пайплайнах и так далее