Elige un caso que puedas razonar
Mantén visibles la función relevante y, si es posible, el lugar desde donde se llama. Describe por separado el resultado esperado y el observado. “Esto falla” es un comienzo; “estos tres valores deberían sumar 13, pero devuelve 4” ofrece un recorrido concreto para investigar. Usa un ejemplo pequeño en lugar de un registro real con información privada.
En la ilustración, una suma termina con un return dentro del bucle. La operación es sencilla a propósito: permite concentrarse en el flujo sin distraerse con el cálculo. Otro error podría necesitar una entrada vacía, un valor repetido o un orden inesperado.
Distingue lo observado de la explicación propuesta
Rayito puede revisar el código visible, narrar un paso breve y señalar una línea o relación relevante. Pídele que muestre cómo cambia un valor durante el recorrido. Esa secuencia es una explicación para examinar, no una prueba de que la aplicación se haya ejecutado exactamente así.
Si el problema depende de una función que no se ve, ábrela antes de aceptar una conclusión. El asistente debería pedir el contexto que falta en lugar de inventar una definición. Mantén legibles los mensajes de error: una ubicación concreta suele orientar mejor que una petición general para mejorar el código.
Haz que la imagen avance con el razonamiento
En un bucle, un marcador puede seguir el elemento actual mientras cambia la etiqueta del resultado. En una condición, dos ramas pueden mostrar qué expresión eligió el camino. En un proceso asíncrono, una línea de tiempo permite distinguir cuándo empieza cada operación y cuándo llegan sus resultados.
Detente en el primer estado inesperado. Intenta predecir el siguiente valor antes de continuar. Ese momento comprueba si entendiste la causa. Cuando una explicación resalta todas las líneas a la vez, resulta más difícil relacionar cada marca con la frase que estás escuchando.
Haz una corrección pequeña que tenga sentido
Cuando el fallo esté claro, plantea una edición limitada. Mover un return es una decisión distinta de reescribir toda la función o cambiar las entradas. Sepáralas para poder relacionar el cambio con el caso que fallaba. Revisa cualquier acción propuesta en la aplicación seleccionada antes de autorizarla.
Ejecuta la prueba relevante en tu entorno de desarrollo y revisa su resultado real. Después considera un caso cercano que el cambio también pueda afectar. Un ejemplo correcto no demuestra que todo funcione, pero aporta evidencia de que la explicación y la corrección coinciden.
Quédate con una regla que puedas reutilizar
Termina expresando la condición que debería mantenerse. Aquí, el resultado debe devolverse después de incorporar todos los elementos. En otro error, la regla importante puede referirse al orden, a la propiedad de un recurso o a un estado vacío.
Vuelve a la conversación en el Historial para repasar el razonamiento visual. El Historial de Rayito puede reproducir las anotaciones guardadas; esa reproducción no vuelve a ejecutar la edición ni la prueba. La diferencia evita que una explicación útil se convierta en un segundo cambio accidental.
Una pregunta para probar“Ayúdame a entender este error con una entrada concreta. Muéstrame dónde se desvía del resultado esperado y deja que compruebe el siguiente paso.”