From 76b9fee3649f40beba6a17c7891de71514e3170c Mon Sep 17 00:00:00 2001 From: Naeel Date: Sun, 26 Apr 2026 09:11:19 +0300 Subject: [PATCH] doc: add notes on debugging model tradeoffs --- .../2026-04-26-sonnet-vs-gpt-debugging.md | 153 ++++++++++++++++++ 1 file changed, 153 insertions(+) create mode 100644 doc/thinking/2026-04-26-sonnet-vs-gpt-debugging.md diff --git a/doc/thinking/2026-04-26-sonnet-vs-gpt-debugging.md b/doc/thinking/2026-04-26-sonnet-vs-gpt-debugging.md new file mode 100644 index 0000000..e5ca721 --- /dev/null +++ b/doc/thinking/2026-04-26-sonnet-vs-gpt-debugging.md @@ -0,0 +1,153 @@ +# 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 поведение.