В моём текущем процессе самое инженерное в задаче — это не «как это написать», а «как мы поймём, что это сделано правильно». Когда ответ есть и сформулирован явно, дальше работа с агентом превращается в нормальный инженерный цикл. Когда ответа нет, то получится не инженерия, а получится игра в казино. Если источник правды не сформулирован, агент сделает что-то «своё». Может быть, даже хорошее. Но проверить, то ли это, что нужно, ты не сможешь пока не опишешь свои ожидания о результате.
Потому что «правильно/неправильно» - не абсолютная метрика. Это всегда относительно какого-то эталона. И этот эталон нужно сначала иметь, прежде чем что-то поручать агенту.
Несколько примеров, как это выглядит на практике:
👉 Миграция legacy-кода на новую технологию. Источник правды — поведение старого кода. Приложение должно выглядеть так же и вести себя так же, даже если в старом коде есть баги. Агент не должен ничего «улучшать» по ходу — задача в миграции, а не в фиксе.
👉 Новая фича. Источник правды — спека и требования. Если их нет, агент будет угадывать, и проверить его никак нельзя.
👉 Рефакторинг. Источник правды — внешний контракт (тесты, API). Внутри агент может делать что угодно, но снаружи поведение должно остаться идентичным.
Из этого вышел практический приём, который у меня хорошо работает на миграциях: не переделывать старый код, а написать новую реализацию рядом — параллельно, на новом стеке. Да, в репозитории временно живут два дубля. Но у агента источник правды буквально в соседнем файле — не надо его искать или восстанавливать по памяти. Переключился, сравнил поведение, доделал. Когда новая версия закрывает все кейсы, можно заниматься чисткой.
Ещё один важный момент: агента для реализации и агента для проверки лучше держать разными. Если один и тот же агент и пишет и проверяет, то он имеет свойство подстраиваться под собственное решение и пропускает то, что сам же нарушил.
#AICoding #SoftwareEngineering #ClaudeCode #TechLeadership
Please open Telegram to view this post
VIEW IN TELEGRAM
👍20👎4