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

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 поведение.