116 lines
5.9 KiB
Markdown
116 lines
5.9 KiB
Markdown
# 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 результата
|
||
|
||
То есть различие проявилось не в "умнее/глупее", а в типе задачи.
|