Reparar una app creada con IA: acotar el primer arreglo

Has construido una aplicación con ayuda de un agente. Algunas pantallas funcionan, pero una invitación falla, un permiso parece incorrecto o el despliegue no se comporta como tu entorno local. Antes de pedir una reescritura, conviene convertir ese problema en un fallo que otra persona pueda reproducir.

El origen del código no basta para decidir cuánto hay que sustituir. La primera reparación debe permitir averiguar qué está roto y qué parte se puede conservar.

Preparar una reproducción

Describe los pasos, el resultado esperado y el que aparece. Indica la versión y el entorno donde lo has visto. Si hay registros, comparte un fragmento sin credenciales ni datos personales innecesarios.

Una frase como «el registro de usuarios falla» deja muchas posibilidades abiertas. Un ejemplo más útil explica qué tipo de usuario entra, qué acción realiza y dónde deja de avanzar. Cuando no se conoce la causa, investigar esa reproducción puede ser el primer encargo remunerado.

Si has detectado una exposición de credenciales, hay que tratarla antes de seguir probando el recorrido. La guía de OWASP sobre gestión de secretos incluye su revocación y rotación. Borrar una clave de una captura o de un archivo no demuestra que haya dejado de dar acceso.

Definir el primer arreglo

La propuesta debería nombrar un comportamiento que se reparará y las partes que se revisarán para hacerlo. Por ejemplo, una invitación que pierde el contexto de la cuenta. Ese encargo puede incluir comprobar permisos y añadir una prueba del fallo; no obliga a renovar toda la interfaz.

Acuerda un límite para la investigación. Si no se encuentra una reparación viable dentro de ese trabajo, la entrega debe explicar lo aprendido y las opciones. Ampliar el alcance requiere una nueva decisión sobre presupuesto y tiempo.

Pedir una prueba del fallo y de la corrección

El conjunto de pruebas depende del fallo y de su impacto. Una comprobación local puede ser insuficiente si el problema solo aparece con la configuración de despliegue; esa diferencia debe quedar registrada.

Decidir sobre una reescritura

Pide que cualquier recomendación de reescribir señale un obstáculo concreto. Puede que una dependencia impida corregir el comportamiento, que los permisos estén repartidos de forma difícil de revisar o que cada cambio afecte a varias funciones sin una separación clara.

Conviene comparar la reparación acotada, una sustitución parcial y una reescritura. Incluye qué datos habría que trasladar y qué partes del producto necesitarían volver a probarse. La decisión debe apoyarse en el sistema revisado y en el resultado que necesita el negocio.

Qué debe quedar al terminar

Si se ha acordado una reparación, la entrega incluye el cambio revisable, las pruebas y las instrucciones para comprobarlo. Si el encargo termina con la investigación, la entrega contiene los hallazgos y las opciones acordadas. En ambos casos debe quedar claro qué se ha dejado fuera. Las credenciales y cuentas siguen bajo el control acordado; el mantenimiento posterior se contrata expresamente.

Si necesitas ayuda para revisar la arquitectura o una integración de tu aplicación, cuéntame el fallo que puedes reproducir. En Pharosyne puedo hacer una reparación o una revisión técnica con alcance y precio acordados antes de trabajar.