LLM чинит прод быстрее тебя, просто ты задаёшь тупые вопросы

Ты сидишь смотришь на баг, как баран на новые ворота, и пишешь в Claude: “не работает, помоги” — ну конечно он тебе ответит чем-то размытым, потому что ты сам не понял, что происходит; отладка через LLM — это не про «спросить», это про то, чтобы сначала самому собрать трассировку системы: кто дернул, куда пошло, какое состояние было до/после, где разрыв, иначе ты не инженер, а просто пассажир в чате

Самый грязный хак: LLM не дебажит код — он дебажит твою модель в голове, и если у тебя там каша, он усиливает кашу; поэтому нормальный флоу такой: сначала ты руками раскладываешь цепочку событий, как в моём недавнем кейсе (User → Telegram → handler → FSM → LLM → DB), фиксируешь где ожидание одно, а реальность другая, и только потом кидаешь это в Claude — и он уже не "думает", он валидирует твою гипотезу или ломает её

Sequence diagram: ты рисуешь поток, и внезапно видно, что у тебя не "кнопка сломалась", а состояние сменилось между двумя сообщениями, или контейнер вообще с другим кодом живёт, или LLM скорит raw вместо structured — текстом ты это не увидишь, мозг срежет углы, а диаграмма нет, она тебя же и ловит на вранье

Последняя схема — это твой способ думать: ты показываешь Клоду не симптом (“сбросилось всё”), а расхождение в процессе (“должно было пройти A→B→C, а у меня A→C, B пропало”), и он сразу цепляется за конкретную точку, а не плавает в абстракциях… и да, в этот момент он становится не советчиком, а реально вторым инженером на инциденте

LLM ускоряет дебаг в десятки раз не потому что он умный, а потому что заставляет тебя перестать быть тупым: либо ты формулируешь систему как последовательность состояний и переходов — либо продолжаешь тыкать "перезапусти контейнер" и удивляться, почему опять всё поехало…

——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура