Reflection Pattern

1. Concept Overview & Systemic Problem

Autoregressive language models have a fundamental architectural trait: they generate tokens sequentially and lack a hardware 'backtracking' mechanism. If the model selects a suboptimal approach at the beginning of a function, the Self-Attention mechanism forces it to continue writing code along this erroneous trajectory:

1. Illusion of Confidence: The model generates code with hallucinations or missing checks for null/undefined with equally high confidence.
2. Ignoring Edge Cases: In single-pass generation (Zero-Shot), the model's attention is focused on the base scenario (Happy Path), while error handling, race conditions, and memory limits are ignored.
3. Low Quality of First Draft: Like a human engineer, artificial intelligence rarely writes flawless architectural code on the first attempt without careful review.

The Reflection Pattern introduces a metacognitive cycle: the model transforms into its own code reviewer, evaluating the output against clear engineering criteria before returning the final response.

2. Architectural Taxonomy & Mental Model

The classic implementation of the reflection pattern consists of three specialized components:

• 1. Generator: Accepts user input requirements and generates the initial solution $S_0$. Focuses on solving the functional task.
• 2. Critic: Receives the generated artifact $S_0$ and evaluates it from the perspective of a meticulous architect or security auditor against a structured checklist (complexity $O(N)$, memory leaks, OWASP vulnerabilities, type safety). Produces a detailed list of remarks $C_0$.
• 3. Refiner: Receives the source code $S_0$ along with the critique $C_0$ and generates an updated version $S_1$, addressing all identified shortcomings.
• 4. Types of Reflection:
  • Internal Self-Reflection: Critique is conducted solely by the LLM using a specialized prompt.
  • Grounded Reflection: Critique relies on objective facts — compiler output, linter errors, or unit test failures.

3. Technical Pipeline & Internal Mechanics

The lifecycle of the reflective process:

1. Initial Drafting: The generator creates a candidate solution to the problem.
2. Adversarial Critique: The critic prompt is invoked with an explicit requirement to be as stringent as possible: "Analyze the provided code. Identify at least 3 potential failure points, memory leaks, or edge cases that could lead to errors in production."
3. Stopping Invariant Evaluation: The result of the critique is evaluated: if there are no critical remarks or the round limit has been reached (iterations >= 2), the system returns the current solution.
4. Targeted Revision: The generator receives a system message: "Here is the initial code and the auditor's remarks. Rewrite the function, correcting each remark without losing functionality."

4. Production Engineering Scenarios

01. Security Audit of Code and Smart Contracts

The generator writes a fund transfer function in a Solidity smart contract. The critic analyzes the code and points out: "Line 14 is vulnerable to a reentrancy attack, as the balance change occurs after calling an external contract." The refiner adds the nonReentrant modifier and rearranges the state update before sending funds (Checks-Effects-Interactions pattern).

02. Performance Optimization of SQL and ORM Queries

The critic reviews the code generated for reading related entities and warns about the $N+1$ query problem: "A loop is used to access related profiles; replace this with a single JOIN or eager loading via include."

03. Synthesis of Reliable Regular Expressions

Constructing a regular expression for validating complex email addresses or phone numbers. In the reflection phase, the critic tests the generated regex against 10 unconventional edge cases (ReDoS attacks, empty strings, special characters) and identifies cases that break the filter.

5. Pitfalls, Common Mistakes & Security

• Sycophancy of the Critic: If the critic prompt is phrased too gently, the model tends to praise its own solution ("The code looks great!"), rendering reflection superficial. Always dictate the role of an uncompromising security auditor.
• Over-Critique: The critic may invent problems where none exist, forcing the generator to overcomplicate simple and functional code with unnecessary wrappers. Ground critiques in real tests and the compiler.
• Oscillation: In the first step, the critic requests an addition of a check, and in the second, asks to remove it as redundant. Always fix the maximum number of cycle steps.