Cómo entregar a un desarrollador un proyecto hecho con IA
Qué preparar antes de que un desarrollador tome un proyecto hecho con Cursor, Claude Code u otro agente de IA: accesos, un resumen, archivos y claves.
Read in English →
Antes de entregarle a un desarrollador un proyecto hecho con IA, asegúrate de que todo el código esté subido a un repositorio que sea tuyo, invítalo a cada servicio que usa la app con su propio usuario y escribe un resumen de una página: qué hace la app, quién la usa, qué está roto y qué no se puede tocar. Suma los archivos de instrucciones del agente, una lista con los nombres de las variables de entorno y una cuenta de prueba. Bien hecho, el desarrollador puede empezar el primer día sin que nadie le pase una sola contraseña.
En esta guía repasamos la lista de accesos, qué debe incluir el resumen, por qué importan los archivos y el historial del propio agente, cómo manejar las claves y qué pedirle al desarrollador a cambio.
¿Qué necesita el desarrollador desde el primer día?
Casi todas las demoras de una entrega no son técnicas: son esperar una invitación, un archivo que falta o a la única persona que sabe la contraseña de Stripe. Repasa esta lista antes de la primera reunión.
| Qué | Por qué importa | Cómo dárselo |
|---|---|---|
| Todo el código en un repositorio | Los agentes suelen dejar archivos sin confirmar; lo que no se subió no se ve | Ejecuta git status, haz commit, sube los cambios y revisa el repositorio en GitHub |
| El hosting (Vercel, Netlify, Replit…) | Para leer los registros de compilación y las variables de entorno | Invítalo al equipo o al proyecto |
| El backend (Supabase, Firebase…) | Para ver la base de datos, las políticas y las funciones | Invítalo como miembro del proyecto |
| Los pagos (Stripe) | Para revisar webhooks y productos | Invítalo con un rol acorde al trabajo |
| Correo, analítica, registro de errores | Ahí está la evidencia cuando algo falla | Invitación o acceso de solo lectura |
| Dominio y DNS | Muchos problemas de lanzamiento están ahí | Acceso de lectura, o estar disponible cuando haga falta |
| Una cuenta de prueba | Para usar la app sin tu usuario personal | Un usuario con datos ficticios en un entorno de pruebas |
Para el código, agrégalo como colaborador en lugar de mandarle un zip. La guía de GitHub sobre cómo administrar el acceso a tu repositorio muestra dónde hacerlo.
¿Qué debe decir el resumen de una página?
Un desarrollador lee código rápido; lo que no puede leer en el código es tu intención. Que el resumen ocupe una página, con estos apartados:
- Qué hace la app, en dos o tres frases, y quién la usa.
- Qué funciona y no se puede romper, por ejemplo "el registro y el reporte semanal se usan todos los días".
- Qué está mal, cada problema con los pasos para reproducirlo, qué esperabas y qué pasó. Nuestra guía sobre cómo reportar un error a un desarrollador muestra el formato.
- Qué quieres después, por orden de prioridad, y qué puede esperar.
- Plazos y límites: una fecha de lanzamiento, un tope de presupuesto, una demo con un cliente.
- Quién decide: quién aprueba los cambios y responde las dudas.
¿Por qué incluir los archivos y el historial del agente?
Un proyecto hecho con un agente arrastra decisiones que nunca quedaron en los comentarios del código. Pásale al desarrollador:
- Los archivos de instrucciones:
.cursor/rules,AGENTS.md,CLAUDE.mdo el equivalente de tu herramienta. Muestran las convenciones que se le pidió seguir al agente. - Las conversaciones importantes: si un chat armó el flujo de pagos o la estructura de la base de datos, exporta o copia las partes clave. Explican por qué algo se hizo de cierta forma.
- Los parches conocidos: "la página de administración solo funciona si recargas dos veces" es justo lo que un desarrollador necesita saber.
- Lo último que tocó el agente: si las sesiones más recientes fueron un desorden, dilo. Ahí hay que mirar primero.
Si no tienes claro qué hay en el proyecto, enumera las herramientas que usaste y en qué orden. "Empezó en Lovable, se exportó a GitHub y luego tres meses con Cursor" le dice mucho a un desarrollador.
¿Cómo manejo contraseñas y claves de API?
No las mandes. Invita al desarrollador a cada servicio con su propia cuenta, así puedes quitarle el acceso después sin cambiar nada más.
Para la configuración de la app, dale una lista con los nombres de las variables, no los valores, en un archivo como .env.example:
VITE_SUPABASE_URL=
VITE_SUPABASE_PUBLISHABLE_KEY=
STRIPE_SECRET_KEY=
STRIPE_WEBHOOK_SECRET=
RESEND_API_KEY=Si alguna clave se pegó en un chat con la IA, se subió al repositorio o se compartió por correo, planifica cambiarla durante la entrega. Un desarrollador casi siempre lo nota igual; mira qué hacer con una clave de API expuesta en el frontend.
¿A nombre de quién deben estar las cuentas y el código?
A tu nombre o al de tu empresa. El repositorio, el hosting, el backend y la cuenta de pagos deben ser tuyos, con el desarrollador como miembro, no al revés. Así el proyecto sigue contigo pase lo que pase con la relación de trabajo. Las preguntas sobre quién es dueño legal del código generado con IA las explicamos en lenguaje simple en quién es dueño del código hecho con IA; para cualquier tema de contrato, consulta con un abogado.
¿Sigo dándole instrucciones al agente mientras trabaja el desarrollador?
No sobre el mismo código. Si tú y el agente siguen editando mientras el desarrollador arregla, se generan conflictos que cuesta tiempo desenredar. Acuerden una pausa, o deja tus pruebas en una rama aparte y que el desarrollador decida qué se fusiona.
¿Qué le pido al desarrollador a cambio?
- Un resumen escrito y breve de lo que encontró, ordenado por riesgo.
- Una estimación o un precio cerrado por cada arreglo antes de empezar.
- Cambios en pull requests pequeños, para que veas qué cambió.
- El README y los archivos de instrucciones actualizados al final, para que tu próxima sesión con el agente arranque con la información correcta.
- Que te recuerde quitarle los accesos cuando termine.
Respuestas rápidas
¿Tengo que limpiar el código antes de entregarlo? No. Súbelo tal como está. Limpiarlo con más mensajes al agente suele hacer más difícil la primera lectura del desarrollador.
¿Alcanza con compartir pantalla en lugar de dar acceso? Para una primera conversación, sí. Para trabajar de verdad, necesita su propio acceso.
¿Cuánto tiempo lleva preparar una buena entrega? Normalmente una tarde: las invitaciones, el resumen y la lista de variables.
¿Le paso mi usuario de Lovable o Bolt? No. Exporta o sincroniza el código con GitHub, compártelo desde ahí e invítalo a los servicios que hay detrás.
¿Listo para entregarlo?
Nuestra guía sobre cómo documentar tu app para que otra persona la tome profundiza en la documentación a largo plazo. Si quieres que seamos nosotros el desarrollador del otro lado, en la página de ayuda con proyectos de Cursor explicamos cómo tomamos proyectos hechos con agentes de IA, empezando por una revisión escrita del código. Puedes pasar primero la app por la revisión gratuita o mandarnos el resumen.
