fission-src/doc/thinking/2026-04-26-sonnet-vs-gpt-debugging.md

2026-04-26 - Почему Sonnet 4.6 мог застрять на Layer1 и в чём он может быть сильнее

Зачем этот документ

После успешного завершения кейса возник мета-вопрос:

• почему другая модель могла не дойти до рабочего решения
• в чём она всё же может быть объективно лучше

Документ нужен как заметка о процессе расследования, а не о самом кодовом fix.

Почему Sonnet 4.6 мог не дожать именно этот кейс

Кейс был каскадным

Здесь не было одного простого корня.

Последовательность была такой:

1. отсутствует fission-fetcher
2. потом выясняется недостаток прав на Role/RoleBinding
3. потом выясняется, что не хватает ещё и делегируемых permission-ов (events.create)
4. потом выясняется, что не хватает localsubjectaccessreviews.create
5. потом executor-path становится рабочим, но router-path всё ещё сломан
6. затем обнаруживается отсутствие namespace watch/list у fission-router

Модель, которая мыслит в режиме "нашёл корень -> исправил -> готово", на таком сценарии часто останавливается слишком рано.

Симптомы менялись и маскировали прогресс

Промежуточные симптомы были:

• serviceaccount not found
• 500 timeout
• 404
• 200

Это классический случай, где изменение симптома означает не провал, а смену активного bottleneck.

Если интерпретировать это неправильно, расследование начинает метаться.

Нужно было понимать RBAC delegation, а не только RBAC access

Ключевая тонкость кейса:

• executor создаёт Role для fetcher
• эта Role выдаёт events.create
• Kubernetes запрещает создавать Role, делегирующую permission, которого нет у самого вызывающего субъекта

Следовательно надо было догадаться, что executor обязан получить events.create, хотя сам код падал не на "events usage", а на создании Role.

Это не самый очевидный вывод без жёсткой опоры на лог и знание RBAC semantics.

Нужен был именно инструментальный debugging loop

Решение появилось не после одной сильной гипотезы, а после цикла:

1. найти симптом
2. проверить конкретное право
3. воспроизвести в новом namespace
4. подтвердить создание реальных объектов
5. перезапустить e2e test
6. перейти к следующему симптому

Без этого модель легко даёт хорошее объяснение, но не доводит задачу до зелёного результата.

Что Sonnet 4.6 может делать лучше меня

1. Быстрый широкий синтез

Sonnet часто хорошо работает на старте, когда нужно быстро:

• разложить проблему по подсистемам
• набросать несколько гипотез
• предложить архитектурные альтернативы
• собрать большой черновик текста

2. High-level проектирование и brainstorming

На задачах вида:

• "какую архитектуру выбрать"
• "какие trade-off у подходов"
• "как разложить крупный рефактор"

он может давать очень сильный первый проход.

3. Большие гладкие черновики

Для первых версий:

• design-doc
• proposal
• API draft
• architecture summary

Sonnet нередко удобен именно скоростью и связностью первой версии.

Что оказалось важнее в этом кейсе

В этом расследовании решающим было не качество первого explanation, а жёсткость процесса:

• не верить первому найденному root cause
• валидировать каждый шаг через cluster state
• считать fix завершённым только после PASS=5/5
• вносить изменения в код/манифесты, а не лечить кластер временными patch-командами

Итоговая формулировка

Корректно говорить так:

• Sonnet может быть сильнее в широком синтезе, brainstorming, архитектурных черновиках и быстрых первых гипотезах
• в этом конкретном кейсе я оказался сильнее в последовательной инструментальной диагностике, удержании нескольких меняющихся симптомов и доведении расследования до рабочего e2e результата

То есть различие проявилось не в "умнее/глупее", а в типе задачи.