Reflection Pattern

1. Visión general del concepto y problema sistémico

Los modelos de lenguaje autoregresivos tienen una característica arquitectónica fundamental: generan tokens de manera secuencial y carecen de un mecanismo de "retroceso" (Backtracking). Si al inicio de una función el modelo elige un enfoque subóptimo, el mecanismo de Self-Attention lo obliga a continuar escribiendo código dentro de esta trayectoria errónea:

1. Ilusión de confianza: El modelo genera código con alucinaciones o verificaciones de null/undefined omitidas con la misma alta confianza.
2. Omisión de casos límite (Edge Cases): Durante la generación de un solo paso (Zero-Shot), la atención del modelo se centra en el escenario básico (Happy Path), mientras que el manejo de errores, condiciones de carrera y límites de memoria se ignoran.
3. Baja calidad del primer borrador: Al igual que un ingeniero humano, la inteligencia artificial rara vez escribe código arquitectónico impecable en el primer intento sin una cuidadosa revisión.

Reflection Pattern introduce un ciclo metacognitivo: el modelo se convierte en su propio revisor de código, evaluando el resultado contra criterios de ingeniería claros antes de devolver la respuesta final.

2. Taxonomía arquitectónica y modelo mental

La implementación clásica del patrón de reflexión consta de tres componentes especializados:

• 1. Generador (Producer / Generator): Acepta los requisitos de entrada del usuario y genera una solución inicial $S_0$. Se centra en resolver la tarea funcional.
• 2. Crítico (Auditor / Critic): Recibe el artefacto generado $S_0$ y lo evalúa desde la perspectiva de un arquitecto o auditor de seguridad minucioso contra una lista de verificación estructurada (complejidad $O(N)$, fugas de memoria, vulnerabilidades OWASP, seguridad de tipos). Forma una lista detallada de observaciones $C_0$.
• 3. Refinador (Refiner): Recibe el código fuente $S_0$ junto con la crítica $C_0$ y genera una versión actualizada $S_1$, en la que se han corregido todos los defectos señalados.
• 4. Tipos de reflexión:
  • Reflexión interna (Internal Self-Reflection): la crítica se lleva a cabo exclusivamente por la propia LLM mediante un prompt especializado.
  • Reflexión fundamentada en el entorno (Grounded / External Reflection): la crítica se basa en hechos objetivos: salida del compilador, errores del linter o fallos de pruebas unitarias.

3. Pipeline técnico y mecánica interna

Ciclo de vida del proceso reflexivo:

1. Initial Drafting (Formación del borrador inicial): El generador crea una solución candidata para el problema.
2. Adversarial Critique (Auditoría crítica): Se invoca el prompt del crítico con la exigencia explícita de ser lo más riguroso posible: «Analiza el código proporcionado. Encuentra al menos 3 puntos potenciales de fallo, fugas de memoria o casos límite que podrían causar errores en producción».
3. Stopping Invariant Evaluation (Evaluación del criterio de parada): Se evalúa el resultado de la crítica: si no hay observaciones críticas o se ha alcanzado el límite de rondas (iterations >= 2), el sistema devuelve la solución actual.
4. Targeted Revision (Revisión dirigida): El generador recibe un mensaje sistemático: «Aquí está el código inicial y las observaciones del auditor. Reescribe la función, corrigiendo cada observación sin perder funcionalidad».

4. Escenarios prácticos de ingeniería en producción

01. Auditoría de seguridad de código y contratos inteligentes

El generador escribe una función de transferencia de fondos en un contrato inteligente de Solidity. El crítico analiza el código y señala: «La línea 14 es vulnerable a un ataque de reentrada (Reentrancy), ya que el cambio de saldo ocurre después de llamar a un contrato externo». El refinador añade el modificador nonReentrant y reordena la actualización de estado antes de enviar los fondos (Checks-Effects-Interactions pattern).

02. Optimización del rendimiento de consultas SQL y ORM

El crítico revisa el código generado para leer entidades relacionadas y advierte sobre el problema de las consultas $N+1$: «Se ha utilizado un bucle para acceder a los perfiles relacionados; reemplácelo por un único JOIN o carga anticipada a través de include».

03. Síntesis de expresiones regulares confiables

Composición de una expresión regular para validar direcciones de correo electrónico o números de teléfono complejos. En la fase de reflexión, el crítico prueba el regex generado con 10 cadenas límite no estándar (ataques ReDoS, cadenas vacías, caracteres especiales) y señala casos de filtrado.

5. Errores comunes, trampas y seguridad

• Sycophancy del crítico: Si el prompt del crítico se formula de manera demasiado suave, el modelo tiende a alabar su propia solución («¡El código se ve genial!»), haciendo que la reflexión sea ficticia. Siempre dictar el papel de un auditor de seguridad implacable.
• Crítica alucinada (Over-Critique): El crítico puede inventar un problema donde no lo hay, obligando al generador a complicar innecesariamente un código simple y funcional con envolturas adicionales. Anclar la crítica en pruebas reales y el compilador.
• Oscilación infinita: En el primer paso, el crítico pide añadir una verificación, en el segundo — eliminarla como redundante. Asegúrese de fijar un número máximo de pasos en el ciclo.