Отладка логики через логи рассуждений (Reasoned Logs)

A system can pass every unit test, follow Spec-First methodology perfectly, yet still lose customers because its reasoning lattice contains invisible holes that only appear when real money and real timing collide.

Imagine you work at a small fintech startup that sends automatic reminders when a customer’s credit card fails. You and the team used component integration patterns to build the renewal and dunning flow. Every separate piece looked correct. Yet customers kept writing angry emails saying they never received a second chance to update their card. The code was never touched, but the outcome was broken.

This lesson shows how to read the invisible thinking process an AI leaves behind. These reasoned logs are the written trace of every decision the AI made. They let us find structural deficiency detection problems without opening the source code.

Problem

The real task is to fix a broken subscription renewal flow in our fintech SaaS product. A customer’s card is declined on day 1. The system should send a polite email on day 1, a stronger notice on day 3, and block service on day 7. Instead, some customers receive only the first email and then disappear. The bug lives in the logic that decides when and how to escalate, not in any single line of code. We need a way to see inside the AI’s mind without reading JavaScript.

Concept

Reasoned logs are step-by-step written explanations that an AI (such as Claude) produces before it generates code. Each line shows what the AI believed, what data it considered, and which rule it applied next. This creates a trace-based debugging record that is richer than traditional logs.

Think of it like a video camera recording every thought a detective has while solving a case. If the detective forgets to check the back door, the video reveals the mistake immediately. We call the complete map of these thoughts an AI reasoning lattice. Each node is a decision point; each edge is a conclusion that leads to the next decision.

Structural deficiency detection means spotting missing nodes or broken connections inside that lattice. Non-code failure modes are bugs that happen even when the generated code matches the architectural specifications. The logic is sound on paper but fails when real timing, real users, and real money interact.

Minimal working example

Here is a short reasoned log that Claude produced while writing the dunning flow. Every line is kept exactly as the AI wrote it.

// Claude's reasoned log for dunning step1. Input: subscription.status = 'past_due', days_overdue = 1, last_email_sent = null2. Rule from spec: if days_overdue <= 3 then send 'soft_reminder'3. Decision: days_overdue qualifies → choose soft_reminder template4. Action: queue_email('soft_reminder', customer.email)5. Expected next check: 48 hours later

Example breakdown

Line 1 shows the exact data the AI examined. This matches the architectural specifications we created earlier in the full-stack assembly phase. Line 2 recalls the rule we gave it using Claude Code prompting patterns. Line 3 is the AI’s own conclusion. Line 4 is the action it decided to take. Line 5 reveals what the AI expected would happen later. Each line exists so we can trace exactly where the reasoning chain broke. The comment at the top labels this log so future readers know its purpose. The structure follows Spec-First methodology by linking every step back to the original written rules.

Extended example

Now we extend the same log to a full three-step dunning sequence, showing how the lattice grows more complex.

// Extended reasoned log - full dunning sequenceDay 1:1. status=past_due, days=12. Rule: send soft_reminder when <=3 days3. Decision: soft_reminder4. Record sent_timestamp=now, next_check=day+2
Day 3:5. days=3, previous_email=soft_reminder6. Rule: if previous=soft and days>=3 then send hard_notice7. Decision: upgrade_escalation8. queue_email('hard_notice')9. Record next_check=day+4
Day 7:10. days=7, no_successful_payment11. Rule: if no payment after hard_notice then suspend12. Decision: trigger_subscription_suspend13. call suspend_service(subscription.id)

This longer example shows how each new day builds a fresh node in the reasoning lattice. The AI must remember what it did two days earlier and decide whether its own previous action allows the next escalation. When any of these remembered facts is missing, a non-code failure mode appears.

The node diagram above lets you click any decision point inside the AI reasoning lattice. Notice how each node references the previous one. That chain is the reasoning chains concept we learned earlier.

This step-through debugger shows the exact moment the trace-based debugging surface appears. Watch how the lattice changes when a required decision node is missing.

The side-by-side panel reveals how structural deficiency detection works. The healthy side contains every decision required by the architectural specifications; the deficient side silently skips the check that links day one to day three.

Common mistakes

1. Treating reasoned logs as optional decoration instead of the primary debugging tool. Without them you cannot see non-code failure modes.
2. Stopping analysis at the first line that looks wrong. The real bug may live three steps earlier in the lattice.
3. Changing the generated code before fixing the missing node in the reasoning. This usually creates new integration problems inside the component integration patterns.
4. Assuming the AI understood timing constraints that were never written into the original Spec-First methodology document.

Each mistake can be recognised by a gap in the AI reasoning lattice that contains no node for a required real-world condition.

Real-World Application

Finance teams at growing SaaS companies constantly add new payment methods and compliance rules. After you master reasoned logs, you will be able to review an entire renewal and dunning system in minutes instead of days. The next lesson, “Передача в эксплуатацию и деплой”, will show how these clean reasoning lattices become the living documentation carried into production, so that operations staff never have to guess why the system made a particular decision.