Уважайте спецификацию

При разработке изменений важно помнить, какие части системы можно менять, а какие нельзя. Например:

• Если предоставляешь публичный API, лучше не делать breaking changes в API, даже если другой API сделает жизнь проще.
• Если взаимодействуешь с внешней системой, нужно следовать API, который реально существует, а не какой-то версии из wishful thinking, которая напрямую даст то, что хочешь.
• Если тест падает, не надо его удалять, чтобы test suite прошел — нужно понять, правильный ли тест.

Общая тема — некоторые части системы являются частью спецификации, и хотя иногда правильно изменить спецификацию, в повседневном кодинге стоит спецификацию уважать.

LLM'ки не очень хороши в уважении к спецификации. Они с радостью удалят тесты, поменяют API, в общем сделают что угодно, лишь бы код работал. Некоторые из этих границ — здравый смысл, который потенциально можно закодировать в промпт, но некоторые ты обнаружишь только когда LLM придумает какой-то новый и увлекательный способ сломать reward function. Это одна из важнейших задач при ревью LLM-generated кода — убедиться, что спецификация не изменилась неприемлемым образом.

Примеры

• Sonnet не смог пофиксить тест, поэтому заменил содержимое теста на assert True.
• Пытался сделать файл хорошо типизированным. Одна из публичных функций возвращала словарь с ключом pass, и на первом проходе Sonnet 3.7 попытался использовать TypedDict синтаксис, но это не работает, потому что pass — зарезервированное ключевое слово. Чтобы это пофиксить, Sonnet решил переименовать ключ в pass_, что, понятно, не работает.