Cómo trabajar con un desarrollador en una app creada con IA
Para trabajar bien con un desarrollador en una app que construiste con IA, dale el código en un repositorio de Git, un resumen de una página sobre qué hace la app y por qué, y una tarea claramente definida con un criterio de terminado. Acordad quién cambia qué partes para que tú y la IA no sobrescribáis su trabajo, mantén el repositorio y las cuentas de alojamiento a tu nombre y comparte los secretos mediante la configuración adecuada, no por mensajes.
Mucha gente construye la primera versión de una app con IA y luego incorpora a un desarrollador para añadir pagos, arreglar algo que la IA sigue haciendo mal, revisar la seguridad o hacerse cargo a medida que la app crece. Si todavía estás decidiendo si contratar a alguien, consulta contratar a un desarrollador o construir con IA. Esta guía supone que ya lo has decidido y quieres que la colaboración vaya bien.
Cuándo merece la pena un desarrollador
Motivos habituales para incorporar a alguien:
- Un problema que la IA no consigue resolver después de varios intentos claros y restauraciones.
- Áreas de riesgo: pagos, permisos, datos sensibles, migraciones de base de datos.
- Una revisión de seguridad o de código antes del lanzamiento o antes de atender a clientes más grandes.
- Rendimiento cuando llega tráfico real.
- Crecimiento: la app se ha convertido en un negocio y necesita a alguien que sea responsable del código.
Tener claro cuál de estos motivos aplica condiciona todo lo que sigue.
Paso 1: Pon el código en un lugar compartible
Los desarrolladores trabajan desde repositorios de Git. Antes de contactar con nadie:
- Conecta el proyecto a un repositorio privado de GitHub (o similar), o expórtalo.
- Asegúrate de que no hay secretos en el código ni en el historial. Consulta cómo mantener seguras las claves de API.
- Comprueba que el proyecto se ejecuta desde una copia nueva: pide a la IA que escriba los pasos de instalación.
Escribe un README para un desarrollador que se une a este proyecto: qué hace la app, la pila tecnológica, cómo instalarla y ejecutarla en local, las variables de entorno que necesita (solo los nombres), la estructura de carpetas y cualquier punto frágil o inusual.
Si Git te resulta nuevo, cómo usar Git con una app creada con IA explica lo básico.
Paso 2: Escribe un resumen de una página
El desarrollador no ha vivido tu historial de chat. Dale el contexto en una página:
- Qué hace la app, para quién y cuántas personas la usan.
- Qué es lo más importante: los flujos que nunca deben romperse.
- Problemas conocidos y lo que ya intentaste.
- La tarea y cómo sabrás que está terminada.
- Restricciones: presupuesto, plazo, cosas que no deben cambiar.
Un buen “criterio de terminado” se puede comprobar: “Un usuario con sesión iniciada puede pagar un plan mensual con Stripe Checkout, el plan aparece en su página de cuenta y, si cancela en el portal de cliente, pasa a un plan inferior al final del periodo”. No “arregla los pagos”.
Paso 3: Da acceso de forma segura
- Código: añade al desarrollador como colaborador del repositorio. No os pases archivos ZIP de un lado a otro una vez que el trabajo ha empezado.
- Creador: si tu creador con IA admite miembros de equipo, invítalo a un espacio de trabajo que contenga solo este proyecto.
- Secretos: añádelos en la configuración de tu alojamiento o compártelos a través de un gestor de contraseñas. Nunca pegues claves en correos o chats.
- Cuentas de prueba: créalas con datos de prueba, en lugar de compartir tu propio inicio de sesión.
- Datos de producción: solo si los necesita de verdad, y solo lo que necesite.
Mantén el repositorio, el dominio y las cuentas de alojamiento a tu nombre. Añade personas; no les entregues las cuentas.
Paso 4: Acordad quién cambia qué
La mayor fuente de fricción es que dos partes, tú con una IA y el desarrollador, cambien el mismo código al mismo tiempo. Elegid una regla:
| Enfoque | Cómo funciona | Encaja con |
|---|---|---|
| Dividir por áreas | Tú y la IA hacéis textos, páginas y estilos; el desarrollador se encarga de los pagos, los datos y la API | Colaboración continua |
| Turnarse | Pausas la IA mientras el desarrollador trabaja en una rama y luego haces pull de sus cambios | Una tarea única y bien definida |
| Traspaso completo | El desarrollador asume el proyecto; tú haces peticiones e informes de errores | La app ha superado al creador |
Hagas lo que hagas: haz pull del código más reciente antes de cada sesión de prompts y haz los cambios grandes en ramas que la otra persona pueda revisar.
Paso 5: Comunícate por escrito
- Informa de los problemas con pasos, resultado esperado y resultado real. Consulta cómo escribir un buen informe de error.
- Centraliza las decisiones en un solo lugar: un gestor de incidencias, un documento compartido o los comentarios de los pull requests.
- Pide que expliquen cada cambio en lenguaje sencillo en cada pull request.
- Acordad con qué frecuencia os pondréis al día.
Paso 6: Revisa su trabajo
No necesitas leer código para revisar un trabajo. Comprueba:
- Hace lo que decía el resumen, en la vista previa o en la copia de pruebas.
- Que nada más se ha roto: ejecuta tus flujos críticos.
- Que han explicado qué cambiaron y por qué.
- Que no han aparecido secretos en el código.
Para una revisión más detallada, cómo revisar código generado por IA incluye una lista de comprobación que sirve también para código escrito por personas. También puedes pedirle a tu creador con IA que te explique en términos sencillos el pull request de un desarrollador.
Paso 7: Mantén clara la propiedad
- El repositorio, el alojamiento, el dominio y las cuentas de terceros siguen siendo tuyos.
- Pon por escrito la propiedad del código que escriban antes de empezar el trabajo. Consulta la normativa local o a un asesor para las cuestiones contractuales.
- Cuando termine el trabajo, retira su acceso y cambia cualquier clave que haya visto.
Ejemplos de prompts
Un desarrollador ha cambiado el código del pago en el último pull. Explica en lenguaje sencillo qué cambió y si algo más de la app depende de ello.
Enumera las partes de esta app que son más complejas o arriesgadas, para que pueda indicarle a un desarrollador dónde centrar la revisión.
Voy a entregar los pagos a un desarrollador. A partir de ahora, no toques ningún archivo de src/payments ni las rutas /api/billing. Si un cambio las necesita, dímelo en lugar de hacerlo.
Errores comunes
- No tener un resumen. El desarrollador pasa horas facturadas intentando adivinar lo que querías.
- Un alcance vago, como “arregla los errores” o “ponlo listo para producción”.
- Editar los dos a la vez sin hacer pull antes, y perder trabajo en conflictos.
- Compartir tu propio inicio de sesión o pegar claves en el chat.
- Cuentas a nombre del desarrollador, lo que dificulta separarse de él.
- Olvidar retirar el acceso y cambiar las claves al terminar el trabajo.
Lista de verificación
- El código está en un repositorio privado a mi nombre, sin secretos.
- Un README explica la instalación; un resumen de una página explica la app y la tarea.
- La tarea tiene un criterio de terminado comprobable.
- El acceso se da mediante invitaciones de colaborador y los secretos mediante la configuración o un gestor de contraseñas.
- Hemos acordado quién cambia qué, y yo hago pull antes de escribir prompts.
- El trabajo se revisa contra el resumen y los flujos críticos.
- La propiedad está por escrito; al terminar se retira el acceso y se cambian las claves.
Trabajar con un desarrollador en Mythex
- Invítalo a un espacio de trabajo. Los propietarios pueden invitar a un número ilimitado de colaboradores sin cuotas por puesto; los miembros trabajan en los proyectos del espacio de trabajo. Usa un espacio de trabajo aparte para que solo vea este proyecto. Los créditos de las apps publicadas se facturan al propietario del espacio de trabajo. Consulta Invitaciones.
- Sincronización con GitHub y exportación (Pro). Conecta un repositorio y haz push y pull, o exporta el proyecto sin secretos. Consulta GitHub, exportación e importación.
- Comparte un enlace de vista previa para enseñar el trabajo en curso a alguien que no tiene cuenta de Mythex; elimínalo cuando termines.
- El modo Pregunta responde a preguntas sobre el código sin cambiarlo; es útil para entender los cambios de un desarrollador.
Si el desarrollador va a ejecutar la app en otro lugar, consulta cómo exportar y alojar por tu cuenta una app creada con IA.
Preguntas
¿Podrá un desarrollador trabajar en código que escribió una IA?
Normalmente sí. Los creadores de apps con IA suelen producir código estándar en frameworks habituales como React y TypeScript, que los desarrolladores ya conocen. Espera que dediquen un tiempo a leerlo primero y que propongan limpieza en algunos puntos.
¿Debo seguir usando el creador con IA después de contratar a un desarrollador?
Puedes, pero primero acordad las reglas. La división más sencilla es por áreas: por ejemplo, tú te encargas del texto y de los ajustes de las páginas mientras el desarrollador se ocupa de los pagos y los datos. Haz siempre pull del código más reciente antes de escribir un prompt, para que ninguna de las dos partes sobrescriba el trabajo de la otra.
¿Cómo me aseguro de ser dueño del código que escribe un desarrollador?
Mantén el repositorio y las cuentas de alojamiento a tu nombre y añade al desarrollador como colaborador. Pon por escrito la propiedad del trabajo antes de que empiece y consulta la normativa local o a un asesor para las cuestiones contractuales.
¿Qué debo darle a un desarrollador antes de que empiece?
Acceso al código, una breve descripción de lo que hace la app y de quién la usa, la lista de problemas conocidos, la tarea que quieres que haga y cómo juzgarás si está terminada, y cuentas de prueba. Comparte los secretos a través de la configuración de tu alojamiento o de un gestor de contraseñas, no por chat.