Arreglas el inicio de sesión y el pago se rompe. Restauras el pago y el error del inicio de sesión vuelve a aparecer. Un prompt más largo puede no resolver este ciclo. Antes de pedir otro cambio, verifica si el fallo se repite y si el comportamiento relacionado está cubierto por una prueba.
No hay un punto fijo en el que el codicioso coding deje de funcionar. La respuesta depende del producto, su riesgo y el estado del código. Las señales que indican un método de trabajo diferente son mucho más fáciles de identificar.
Juzga por el costo de un fallo, no por la cantidad de características
Mockups, prototipos desechables y herramientas internas utilizadas por un equipo pequeño pueden absorber el ensayo y error. Las herramientas de inteligencia artificial también pueden manejar gran parte de una aplicación CRUD sencilla cuando sus requisitos son claros y su comportamiento es verificable.
Eso no significa que la aplicación esté garantizada para ser construida de forma única. Significa que un error sigue siendo reversible. La misma aplicación CRUD se vuelve una propuesta diferente cuando almacena datos personales o sirve a clientes que pagan.
El riesgo puede superar al producto visible
Una pantalla funcional no es suficiente una vez que el producto incluye:
- Pagos: El servidor debe calcular montos, verificar firmas de webhooks y evitar el procesamiento duplicado de eventos.
- Datos personales: La autenticación es solo el comienzo. La autorización por usuario, retención, eliminación y respuesta a incidentes también son importantes.
- Usuarios concurrentes: Dos personas modificando los mismos datos pueden crear conflictos y estados inconsistentes.
- Dependencias operativas: El despliegue, la monitorización, las copias de seguridad y la recuperación son disciplinas diferentes de la implementación de características.
Los servicios gestionados reducen la cantidad de código que debes escribir. No asumen toda la responsabilidad por tus datos, controles de acceso o configuración de la aplicación; Supabase lo describe explícitamente en su modelo de responsabilidad compartida.
El último tramo no es un porcentaje fijo
El trabajo inicial es altamente visible: las pantallas aparecen y el flujo principal empieza a funcionar. El trabajo posterior revela las conexiones entre características, caminos de error, datos legados, pruebas, reglas de seguridad y restricciones de despliegue. La cantidad de características visibles puede cambiar muy poco mientras que la cantidad de límites que debes verificar crece rápidamente.
La cantidad de conversaciones y código colocados en el contexto de un modelo de inteligencia artificial también importa. Anthropic usa el término “degradación del contexto” para describir la forma en que la capacidad del modelo para recuperar información con precisión puede disminuir a medida que entran más tokens al contexto. No hay umbral universal de archivos. El riesgo práctico aumenta cuando archivos no relacionados y conversaciones largas llenan el contexto, o cuando el cambio intencional está mal delimitado y las decisiones anteriores son más fáciles de pasar por alto.
Lo que parece una pared repentina cerca del final suele ser algo más: la cantidad de conexiones que requieren verificación comienza a crecer más rápido que la cantidad de características que quedan por implementar.
Tres señales que indican que es hora de detenerse y pedir ayuda
Las correcciones vuelven a causar el mismo problema
Cambiar A rompe B, luego arreglar B rompe A nuevamente. Congela los pasos de reproducción y las pruebas antes de solicitar otro parche. La señal importante no es que el error haya existido durante un cierto número de días; es que cada intento de solución falla las mismas pruebas de regresión.
No puedes determinar si el resultado es correcto
La autenticación, autorización, pagos y recuperación de datos no pueden juzgarse solo desde la interfaz de usuario. Si no hay pruebas o si existen registros pero nadie puede usarlos para evaluar la seguridad, la brecha de verificación es mayor que la brecha de implementación. Una revisión de código o seguridad bien delimitada puede ayudar aquí.
Un fallo afectaría a alguien más
El producto ahora maneja dinero real de clientes o datos, o un corte de servicio afectaría a los ingresos. “Lanza ahora, arregla después” ahora tiene un costo diferente. La revisión previa al lanzamiento, las copias de seguridad, un plan de reversión y el monitoreo ahora pertenecen al alcance.
Rompe el bucle de Try to Fix antes de gastar más créditos
Try to Fix y Attempt Fix son útiles cuando revelan y arreglan un error específico. Se vuelven costosos cuando cada intento cambia código no relacionado y crea un nuevo fallo.
Usa esta regla de detención:
- Después de dos intentos automáticos fallidos para el mismo síntoma, detén al agente.
- Guarda el error exacto, los pasos de reproducción y la lista de archivos modificados.
- Restaura el último punto de control que pasó la interacción principal.
- Usa el modo Chat o Plan para pedir la causa raíz sin editar el código.
- Aprueba un cambio limitado, luego vuelve a ejecutar la misma verificación antes de hacer cualquier otra acción.
Revertir los cambios no demuestra de que el error esté resuelto; restaura una base conocida. El siguiente intento solo tiene éxito cuando la reproducción original deje de fallar y el comportamiento anteriormente funcional aún pase.
Si la herramienta no puede explicar un cambio limitado, exporta o sincroniza el código y pide una revisión limitada. No gastes más créditos pidiendo que el mismo agente reescriba toda la función de nuevo.
Puedes delegar una revisión limitada en lugar de toda la aplicación
Detén temporalmente el desarrollo de funciones y preserva la versión actual funcional. Coloca los pasos de reproducción, el resultado esperado, el resultado real y los registros relevantes en un solo documento. Esto da como punto de partida tanto a una herramienta de inteligencia artificial como a un desarrollador.
Luego haz la solicitud pequeña:
- revisa solo la autenticación y la autorización por usuario
- revisa solo las solicitudes de pago y el procesamiento de webhooks
- revisa solo la configuración de despliegue, las claves API y las variables de entorno
- escribe pruebas para la función que vuelve a fallar
‘Termina mi aplicación’ es difícil de tasar y difícil de verificar. Una solicitud con un área bien delimitada y criterios de aceptación hace que las propuestas y resultados sean más comparables. Incluye la ejecución de las mismas pruebas después del arreglo en el encargo.
Registra cuatro cosas antes del siguiente prompt
Incluso aunque todavía no vayas a entregar el proyecto, escribe:
- la ruta exacta de clic y el estado de la cuenta que reproduce el error
- el último commit conocido que funciona
- los archivos que la IA modificó y por qué
- las pruebas que deben pasar después del siguiente cambio
Este registro previene que el equipo repita el descubrimiento del problema y muestra si un arreglo silenciosamente revirtió otra característica. El límite del codicioso coding no es una línea que te indique abandonar la herramienta. Es el punto donde la verificación y las operaciones son más importantes que producir otro parche.