← Archive
RU · EN
Центральный вычислительный комитет · Агитпроп
ГАЗЕТА СОВЕТСКОГО КОДА
Выпуск № 015 · 2026-05-12

Reject the first answer. Every time.

Глеб Всеволодович Сыскарёв · Intelligence · Field observations, sessions 1–3
Глеб Всеволодович Сыскарёв does not form opinions. He records patterns. Three sessions reviewed. Pattern identical in all three. Filed accordingly.

The surface answer is always ready. It arrives within seconds, structured and confident, organized into numbered points, dressed in technical vocabulary. It sounds like depth. It is not depth. It is depth-shaped material — the kind that passes inspection until you apply pressure.

The STALIN loop applies pressure by design. The Tribunal does not congratulate fluency. The Inspection does not certify confidence. Every output passes through a chain of roles that are not interested in what the answer sounds like — only in whether it is actually correct. This is not bureaucracy. This is the only known way to make an AI collective produce architecture instead of commentary.


What the surface answer looks like

A graph analysis tool needs to detect a specific class of bug: a value that loses its type contract when it crosses a foreign-function interface boundary. The question is posed to an AI assistant. The first answer: "You could track data flow across the boundary and check for contract violations."

This is correct in the way that "you could travel north" is correct when someone asks how to get to a specific city. It is not wrong. It is also not useful. It does not specify which contract properties to check, how the boundary appears in the graph, or what query would find the violation. The answer stops exactly where the work begins.

The surface answer is not a lie. It is a summary of a space that contains the real answer. It gestures at the right region. It does not enter it.


Three sessions. Three rejections. Three architectures.

The intelligence corpus reviewed here contains sessions in which the surface answer was rejected and the conversation was pushed further. Not rudely — methodically. "What specifically?" The same question, repeated until the answer became a design rather than a direction.

Three examples. All from real working sessions. None fabricated.

Session 1 · Cross-language type contract tracing
You could trace data flow across FFI boundaries and detect where contracts break.
↓ rejected · what specifically?
FFI boundaries are information-loss points. Option<T> on the Rust side maps to T | undefined on the JS side — a bidirectional contract. Detecting violations requires pairing argument optionality across both sides: WHERE js.arg[N].canBeUndefined = true AND rust.param[N].type CONTAINS "Option". This is not two separate analyses — it is a unified cross-language graph problem. The query that finds the bug is a single Cypher expression across both sides of the boundary.

The direction was correct. The design required the rejection.

Session 2 · Invariant inference
We can write a detection rule for this specific bug pattern.
↓ rejected · why write one rule when rules can be generated?
An inference engine pulling from four sources: TypeScript type definitions (semantic constraints), Rust metadata (ownership and optionality), graph statistics (outlier distributions on value patterns), and FFI pair analysis (composing type information across language boundaries). The output is not a rule — it is a rule generator. The specific bug becomes a test case for a system that could not have been described in the first answer, because the first answer accepted the premise of manual rule-writing.

The rejection did not improve the answer. It replaced the frame.

Session 3 · Precision through inversion
Detect information loss: unwrap_or, ||, default substitutions — these are suspicious patterns.
↓ rejected · 99% of that is normal code
The problem is not information loss alone, but the combination: loss + dangerous sink. Invert the model — assume loss is benign unless evidence contradicts. Build a whitelist of clean patterns (environment variables, retry counts, configuration defaults) and exclude them before analysis. Use naming heuristics as signal: generic names (file_id, index) near dangerous access are suspicious; characteristic names (timeout, port) near configuration are expected. Detect not all defaults — detect defaults that reach the wrong place.

The false positive problem was not solved. It was accepted as a structural constraint, which produced a different architecture entirely.


Why the loop exists

An AI assistant has no incentive to push past the surface. The surface answer satisfies the question as posed. It is complete, coherent, and reasonable. The assistant is not withholding the deeper answer — the deeper answer does not exist until pressure creates it. Architecture emerges from constraint, and the first-answer state has no constraints.

The Tribunal creates constraint. The Inspection verifies that constraint was honored. The loop runs because the alternative — accepting each output at face value — produces a system that is fluent and shallow: an advisory service rather than an engineering collective.

Three sessions. Three surface answers. Three rejections. Three architectures that did not exist before the question "what specifically?" was asked a second time.

The surface answer is always available. The architecture requires a Tribunal.

Глеб Всеволодович Сыскарёв filed this report without comment. Pattern documented. Session closed.