Как должно выглядеть ревью кода в эпоху LLM

[Dhwtj]

Если вам понадобилось защитное программирование, значит у вас плохие (в данном случае, неявные) гарантии инвариантов. Переделайте гарантии инвариантов, чего на LLM пенять то?

Остальную часть статьи не понял

Полез в мр. Так и есть. LLM заштопал то что ему сказали (один случай), но не вылечил (надо было гарантировать отсутствие data race в инвариантах).

Промпт плохой:

"Fix the thread-safety issue in this test"

Промпт лучше:

"There's a thread-safety issue with shared IStreamAdapter.

Analyze if this is a test bug or API design problem.

Suggest fix at the appropriate level."

И желательно самому это увидеть и дать расширенный контекст

"Here's the test, here's ReadAdapterInterface.h,

here's getRecord implementation.

Where should the fix live?"

[ToniDoni]

Что плохого в трай кечах и вообще в защитном программировании?

[Dhwtj]

Как заплатка нормально

Но это плохой дизайн или просто не выразительный язык которые не смогли сделать невалидное состояние непредставимым (невозможным)

try-catch ещё скрывает/ломает control flow, усложняет понимание что может пойти не так. Result/Either делают ошибки явными в сигнатуре - это то что Влашин продвигает в "Domain Modeling Made Functional"

[ToniDoni]

Непонятно так как оно должно выглядеть?

[MDyuzhev]

Хорошая мысль про «память команды». У LLM нет памяти между сессиями, и кто-то должен хранить контекст. Мы это решаем файлом CLAUDE.md в корне репозитория. Туда скидываем архитектуру, правила, текущий статус. Агент читает при старте и не задаёт глупых вопросов.

Но самое ценное тут про сдвиг от «как написано» к «зачем написано». Раньше на ревью ловили баги и стиль. Теперь ловим несогласованность в понимании задачи между людьми. Это и раньше была главная проблема, просто теперь от неё не спрячешься за «ну код же работает».