Copia la lección y pégala en tu chat para resolver dudas.
El error como información: diagnóstico y abducción
Cuando algo falla en tu aplicación, ¿por qué pegarle el mensaje de error al agente diciendo únicamente «arréglalo» suele empeorar el sistema? Si no comprendes qué significa el error ni en qué capa nace, el agente puede silenciar el síntoma —por ejemplo, ocultando el aviso o relajando una restricción importante— en lugar de resolver la causa real. Para una mente analítica, un error no es un estorbo que hay que esconder, sino información precisa sobre una contradicción entre lo que creíamos y la realidad.
Objetivos y conocimientos previos
Partiendo de Especificación y casos límite y del razonamiento abductivo estudiado en Fundamentos de la lógica, aprenderás a distinguir entre síntoma y causa raíz, a clasificar el origen de cualquier fallo en tres niveles y a dirigir un ciclo de diagnóstico por hipótesis y experimentos sin tocar el código a ciegas.
Síntoma frente a causa raíz
El síntoma es el lugar donde el problema se hace visible (por ejemplo, un mensaje de error en la pantalla o un saldo que se muestra en blanco). La causa raíz es el punto exacto de la cadena lógica donde el estado o los datos se desviaron de lo que debía ocurrir.
En un sistema compuesto por varias capas (Curso IV) y componentes comunicados (Curso III), el síntoma casi nunca aparece en el mismo lugar donde nació la causa:
- Una pantalla en blanco en el navegador (síntoma en el cliente) puede deberse a que el servidor devolvió un formato distinto al acordado en el contrato, y eso a su vez ocurrió porque una consulta a la base de datos tardó demasiado y se agotó el tiempo de espera.
Si parcheas el síntoma en la pantalla sin investigar qué pasó en el servidor y en la base de datos, el problema real seguirá activo.
Los tres orígenes posibles de un fallo
Antes de pedirle a un agente que modifique una sola línea de código, determina en cuál de estos tres planos está el origen del fallo:
| Origen del fallo | Qué significa realmente | Ejemplo en un sistema de facturación | Cómo se resuelve con rigor |
|---|---|---|---|
| 1. Error de modelo o especificación | El programa hace exactamente lo que pedimos, pero nuestra regla tenía una contradicción o un vacío lógico. | Pedimos: «aplica un descuento fijo de 20 € a cualquier factura», y al emitir una factura de 15 € el total sale -5 €. El código obedeció nuestra instrucción al pie de la letra; la regla estaba mal pensada. | Corregir primero la regla del dominio («el descuento nunca puede superar el importe base») antes de tocar la implementación. |
| 2. Error de supuesto técnico o entorno | El modelo es correcto, pero asumimos que una herramienta o capa ofrecía una garantía que no tiene. | Creíamos que guardar el estado en una variable en memoria RAM sobrevivía al reinicio del servidor, o que dos operaciones separadas eran atómicas sin usar una transacción. | Contrastar el comportamiento real de la capa o herramienta (Curso IV) y elegir el mecanismo con las garantías necesarias. |
| 3. Error de implementación (Bug de código) | El modelo es sólido y el mecanismo técnico es el adecuado, pero el código escrito se desvió de la regla acordada. | La regla decía «actualizar solo la factura cuyo id_factura coincida» y en el código se filtró por id_cliente, modificando todas las facturas de ese cliente. | Corregir la instrucción exacta y añadir una comprobación automática que impida que esa desviación vuelva a ocurrir. |
El método de diagnóstico abductivo en 5 pasos
Diagnosticar no es probar cambios al azar a ver si por casualidad desaparece el fallo; es aplicar el método científico y la abducción al software:
- 1. Reproducir y acotar: ¿con qué entradas exactas, en qué estado previo y tras qué pasos ocurre siempre el fallo?
- 2. Ubicar la capa y la frontera: ¿el dato ya sale mal del cliente, se altera en el contrato de red, en la lógica de dominio o al persistir en la base de datos?
- 3. Formular hipótesis alternativas (Abducción): ¿qué 2 o 3 causas explicarían exactamente los hechos observados?
- 4. Aislar mediante observación: inspeccionar los valores en la frontera entre capas para descartar hipótesis SIN modificar aún la lógica del sistema
- 5. Aplicar la corrección mínima sobre la causa confirmada y verificar que resuelve el fallo sin romper otros casos
Fíjate en la regla de oro del paso 4: prohíbe cambiar la lógica mientras todavía estás averiguando la causa. Si cambias tres cosas a la vez sin haber confirmado cuál de tus hipótesis era la verdadera, acumularás código innecesario y dejarás la verdadera causa escondida.
Practica
Al probar tu sistema de facturación detectas este comportamiento anómalo:
Una clienta tiene dos facturas pendientes (F-01 de 50 € y F-02 de 50 €). Entra en su cuenta, selecciona pagar únicamente la factura F-02, realiza un pago de 50 € y el sistema responde «Pago registrado con éxito». Sin embargo, al consultar su historial, tanto F-01 como F-02 aparecen ahora en estado PAGADA, aunque solo ha pagado 50 € en total.
Cuando le muestras el problema al agente, este te sugiere:
«Voy a arreglarlo enseguida en el código de la pantalla: haré que la tabla visual solo muestre como PAGADA la última factura sobre la que hiciste clic y oculte el cambio en las demás».
- Explica por qué la propuesta del agente confunde síntoma con causa raíz y en qué capa está intentando maquillar una corrupción de datos.
- Utiliza la abducción para formular dos hipótesis plausibles sobre qué está ocurriendo realmente en el servidor o en la base de datos al ejecutar la actualización de estado (recuerda cómo se identifican los registros en el Curso II).
- Indica qué observación concreta pedirías hacer en el paso 4 (antes de editar el código) para confirmar cuál de tus dos hipótesis es cierta.
Criterio de comprensión: debes rechazar cualquier parche visual en el cliente porque los datos en el servidor seguirían corruptos, plantear como hipótesis principal que la operación de cambio de estado está filtrando por id_cliente en lugar de por la clave única id_factura, y exigir inspeccionar qué identificador llega en la petición al servidor y qué condición de filtro ejecuta la sentencia de actualización en la base de datos.
Profundiza con IA
Este es mi diagnóstico por capas y mis hipótesis abductivas para el fallo en el que pagar una factura marca como pagadas todas las del mismo cliente: [tu respuesta]. Evalúa mi razonamiento. Después, actúa como el sistema donde ocurre un fallo distinto (por ejemplo, una reserva que desaparece cada vez que el servidor se reinicia), dame solo el síntoma inicial que ve el usuario y deja que yo te haga preguntas diagnósticas paso a paso por capas hasta descubrir la causa raíz.
Siguiente lectura
Una vez que hemos diagnosticado la causa raíz y el agente aplica la corrección, suele añadir o ejecutar pruebas y decirnos: «Todas las pruebas pasan en verde». ¿Basta eso para estar seguros, o puede una prueba en verde ser un espejismo? Continúa con Validación técnica y validación lógica.