Cómo trabajar con un desarrollador en una app creada con IA
Para trabajar bien con un desarrollador en una app que creaste con IA, dale el código en un repositorio de Git, un resumen de una página de lo que hace la app y por qué, y una tarea claramente delimitada con una definición 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 a través de los ajustes adecuados, no en 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 encargarse de la app a medida que crece. Si todavía estás decidiendo si contratar, 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 tras varios intentos claros y vueltas atrás.
- Á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 se responsabilice del código.
Tener claro cuál de estos motivos aplica determina todo lo que sigue.
Paso 1: Pon el código en un lugar que se pueda compartir
Los desarrolladores trabajan desde repositorios de Git. Antes de contactar a 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 incorpora 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 nombres), la estructura de carpetas y cualquier cosa 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 visto tu historial de chat. Dale el contexto en una sola 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 has intentado.
- La tarea y cómo sabrás que está terminada.
- Restricciones: presupuesto, plazo, cosas que no deben cambiar.
Una buena «definición de terminado» es comprobable: «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 desde el portal de cliente, se le baja de plan al final del periodo». No «arreglar los pagos».
Paso 3: Da acceso con seguridad
- Código: añade al desarrollador como colaborador del repositorio. No te pases archivos ZIP de ida y vuelta una vez que empiece el trabajo.
- Creador: si tu creador de apps con IA admite miembros del equipo, invítalo a un espacio de trabajo que contenga solo este proyecto.
- Secretos: añádelos en los ajustes de tu servicio de alojamiento, o compártelos a través de un gestor de contraseñas. Nunca pegues claves en el correo ni en el chat.
- 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 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. Elige una regla:
| Enfoque | Cómo funciona | Para qué sirve |
|---|---|---|
| Dividir por áreas | Tú y la IA os encargáis de textos, páginas y estilos; el desarrollador es responsable de los pagos, los datos y la API | Colaboración continua |
| Turnos | Pausas la IA mientras el desarrollador trabaja en una rama, y luego haces pull de sus cambios | Una tarea única y bien definida |
| Entrega completa | El desarrollador se hace cargo; tú envías peticiones e informes de errores | La app ha superado al creador |
Sea cual sea la opción: 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
- Describe los problemas con pasos, resultado esperado y resultado real. Consulta cómo escribir un buen informe de error.
- Mantén las decisiones en un solo sitio: un gestor de incidencias, un documento compartido o comentarios en los pull requests.
- Pídele que explique los cambios en lenguaje sencillo en cada pull request.
- Acordad con qué frecuencia os vais a poner al día.
Paso 6: Revisa su trabajo
No necesitas leer código para revisar un trabajo. Comprueba:
- Que hace lo que pedí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 te ha explicado qué cambió 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 también sirve para código escrito por personas. También puedes pedir a tu creador de IA que te explique, en términos sencillos, el pull request de un desarrollador.
Paso 7: Deja clara la propiedad
- El repositorio, el alojamiento, el dominio y las cuentas de terceros siguen siendo tuyos.
- Deja por escrito la propiedad del código que escriban antes de empezar el trabajo. Consulta las normas locales 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 checkout 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 dedica horas facturadas a adivinar lo que querías.
- Un alcance vago, como «arregla los errores» o «déjala lista 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 cuando termina el trabajo.
Lista de comprobació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 una definición de terminado comprobable.
- El acceso es por invitaciones de colaborador, y los secretos, a través de ajustes o de un gestor de contraseñas.
- Hemos acordado quién cambia qué, y hago pull antes de escribir prompts.
- El trabajo se revisa contra el resumen y los flujos críticos.
- La propiedad está por escrito; el acceso se retira y las claves se cambian al terminar el trabajo.
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. 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. Consulta Invitaciones.
- Sincronización con GitHub y exportación (Pro). Conecta un repositorio y haz push y pull, o exporta el proyecto sin los secretos. Consulta GitHub, exportación e importación.
- Comparte un enlace de vista previa para enseñar trabajo en curso a alguien sin cuenta de Mythex; elimínalo cuando hayas terminado.
- El modo Pregunta responde a preguntas sobre el código sin cambiarlo, lo que resulta ú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 con código que escribió una IA?
Normalmente, sí. Los creadores de apps con IA producen sobre todo código estándar en frameworks habituales, como React y TypeScript, que los desarrolladores ya conocen. Espera que dediquen algo de tiempo a leerlo primero y que sugieran mejoras de limpieza en algunos puntos.
¿Debo seguir usando el creador de IA después de contratar a un desarrollador?
Puedes, pero acordad primero las reglas. La división más sencilla es por áreas: por ejemplo, tú te encargas de los textos y los ajustes de página mientras el desarrollador es responsable de los pagos y los datos. Haz siempre pull del código más reciente antes de escribir un prompt, para que ninguno de los dos sobrescriba el trabajo del otro.
¿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. Deja por escrito la propiedad del trabajo antes de que empiece y consulta las normas locales 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 se haga con la forma en que juzgarás que está terminada, y cuentas de prueba. Comparte los secretos a través de los ajustes de tu servicio de alojamiento o de un gestor de contraseñas, no por chat.