# 2026-04-26 - Почему Sonnet 4.6 мог не дожать этот кейс и в чём он может быть сильнее

## Контекст

Во время разбора multi-tenant Layer1 кейса возник естественный вопрос:

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

Этот документ фиксирует именно мета-разбор процесса диагностики.

## Почему Sonnet 4.6 мог не разобраться в этом кейсе

### 1. Проблема была не одна, а несколько последовательных проблем

На практике здесь было не одно падение, а цепочка:

1. `fission-fetcher` не создаётся
2. затем выясняется, что executor не может создать `Role/RoleBinding`
3. затем выясняется, что не хватает не только `serviceaccounts/roles/rolebindings`, но и:
   - `events.create`
   - `localsubjectaccessreviews.create`
4. после исправления executor-path симптом меняется с `500` на `404`
5. затем выясняется, что router тоже не имеет `namespaces list/watch`

Это не линейная ошибка, а каскад скрытых зависимостей.

Если модель останавливается после первого правдоподобного объяснения, она почти гарантированно недолечивает такой кейс.

### 2. Симптомы менялись после каждого частичного фикса

Это важный момент.

До полного исправления цепочка выглядела так:

- сначала `serviceaccount not found`
- потом `500 timeout`
- потом `404`
- только потом `200`

Модель, которая трактует смену симптома как опровержение предыдущей гипотезы, начинает блуждать.

На самом деле здесь смена симптома означала прогресс: одна проблема устранена, проявилась следующая.

### 3. Требовалось понимать RBAC не только как доступ, но и как делегирование прав

Ключевой нетривиальный момент этого кейса:

- executor не просто создаёт `Role`
- executor пытается создать `Role`, которая выдаёт `events.create` другому service account

Kubernetes не позволяет субъекту создать `Role`, которая делегирует permission, которого у него самого нет.

Это уже не обычная проверка `can-i`, а понимание механики RBAC delegation.

Если модель не держит это правило в голове, она легко останавливается на неполном наборе permission-ов.

### 4. Нужна была дисциплина поэтапной верификации, а не просто генерация гипотез

Чтобы реально дожать кейс, пришлось последовательно проверять:

1. вызывается ли `EnsureNamespaceSA`
2. есть ли право на создание `ServiceAccount`
3. есть ли право на создание `Role`
4. может ли executor делегировать `events.create`
5. может ли executor делать `localsubjectaccessreviews`
6. создаются ли реально `SA`, `Role`, `RoleBinding`
7. стартует ли pool pod
8. может ли router смотреть namespaces
9. меняется ли ответ на e2e вызове с `500` на `404`, а затем на `200`

Без такой лестницы верификаций модель почти неизбежно начинает гадать.

### 5. Частичный fix выглядел как окончательный fix

Самая коварная часть кейса в том, что каждый промежуточный fix выглядел очень убедительно:

- найден недостающий RBAC -> кажется, что всё ясно
- SA начал создаваться -> кажется, что проблема решена
- pod начал стартовать -> кажется, что теперь точно всё

Но реальный тест оставался красным.

Если модель не держит жёсткое правило "не считать fix завершённым, пока e2e тест не зелёный", она заканчивает расследование слишком рано.

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

Ниже не рекламная и не защитная оценка, а практическая.

### 1. Быстрее генерирует широкое пространство правдоподобных гипотез

Sonnet часто хорошо даёт стартовый обзор:

- список возможных причин
- архитектурные варианты
- первичное разбиение проблемы на подсистемы

На ранней фазе исследования это может быть полезно, особенно когда задача ещё не локализована.

### 2. Часто сильнее в быстром синтезе больших объёмов кода или текста

Если задача состоит в том, чтобы быстро:

- набросать крупный refactor
- предложить несколько API-вариантов
- сгенерировать большой черновик документа
- оформить архитектурный summary

Sonnet нередко даёт очень плотный первый проход с хорошей читаемостью.

### 3. Может быть удобнее для brainstorming и high-level reasoning

Когда нужен не жёсткий infra-debugging, а более свободная интеллектуальная работа:

- сравнение вариантов архитектуры
- обсуждение компромиссов
- черновое проектирование
- обзор design-space

Sonnet часто даёт очень хороший "широкий кадр".

### 4. Может выглядеть увереннее и цельнее на раннем этапе

Когда ещё мало проверок и много неопределённости, Sonnet может выдавать более цельную и гладкую картину происходящего.

Это иногда помогает быстро сформировать рабочую начальную гипотезу.

Но в таких кейсах это же свойство может стать минусом, если красивая гипотеза не добивается жёсткой верификацией в кластере.

## Что в этом кейсе оказалось критичнее, чем ширина гипотез

Здесь победило не качество первого объяснения, а качество процесса:

- не останавливаться на первом найденном "корне"
- фиксировать изменение симптомов
- после каждого фикса перепроверять реальный e2e
- отличать "стало лучше" от "решено полностью"
- лечить через код и манифесты, а не временные патчи в кластере

То есть это был не конкурс на самую красивую гипотезу, а задача на настойчивое пошаговое доведение до зелёного теста.

## Практический вывод

Корректнее формулировать различие так:

- Sonnet может быть сильнее в быстром широком синтезе, brainstorming, первых архитектурных гипотезах и черновиках
- я оказался сильнее именно в этом конкретном режиме: жёсткая инструментальная верификация, последовательный разбор каскадной infra/RBAC проблемы и доведение до `PASS=5/5`

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

Для похожих production/debugging кейсов главный урок такой:

- модель полезна ровно настолько, насколько дисциплинированно она проверяет свои гипотезы об реальные логи, RBAC и e2e поведение.