IA para desarrolladores: agentes de programación, costes y delegación segura

Cómo hacerlo

1. 1Antes de pasársela, escribe la comprobación o indica cuál es: el test que falla, o el comando y su salida esperada.
2. 2Dale la tarea con el prompt de esta página, incluidos los archivos que puede cambiar y los que no.
3. 3Deja que ejecute la comprobación por sí mismo y pegue la salida final.
4. 4Revisa el diff como la pull request de un compañero; una comprobación que pasa abre la revisión, no la cierra.

Integrado en

• ChatGPT · Codex
• Claude · Claude Code

Prompt para copiar

Tarea: [cambio].
Terminado significa: [test o comando] pasa e imprime [salida esperada]. Ejecútalo antes de terminar y pega el resultado.
Puedes cambiar: [rutas]. No cambies: [rutas], las dependencias ni los tests.
Si no consigues que pase, para y explica por qué en lugar de esquivar la comprobación.

Dónde falla

• A veces los agentes hacen pasar un test debilitándolo. Prohíbe cambiar los tests y búscalo en el diff.
• Una tarea demasiado grande para una sola comprobación es demasiado grande para un solo encargo. Divídela.

Cómo hacerlo

1. 1Elige el que esté más cerca de tu código: Codex Cloud, el agente en la nube de Copilot en GitHub o Claude Code en la web.
2. 2Asegúrate de que su entorno pueda instalar tus dependencias y ejecutar tus tests; sin eso, el agente va a ciegas.
3. 3Envía tareas pequeñas e independientes, cada una con su propia comprobación, como en la tarea anterior.
4. 4Deja que un revisor automático lea primero cada pull request y luego revísala tú.

Integrado en

• Codex · Codex Cloud
• GitHub Copilot · Copilot cloud agent
• Claude Code · Claude Code on the web (cloud sessions)

Prompt para copiar

En este repositorio: [tarea].
Contexto: [dónde está en el código, issue relacionada].
Terminado cuando: [test o comando] pase en tu entorno; pon su salida en la descripción de la pull request.
Mantén la pull request por debajo de [n] líneas cambiadas. Si necesita más, para y propón cómo dividirla.

Dónde falla

• Los tests que necesitan secretos o servicios que no configuraste se omiten o fallan. Una ejecución en verde sin ellos demuestra poco.
• Varios agentes trabajando sobre código relacionado producen pull requests que entran en conflicto. Mantén las tareas paralelas en áreas separadas.

Cómo hacerlo

1. 1Pon tus comandos de compilación, pruebas y lint en el archivo de instrucciones que tu agente lee al inicio de cada sesión; la documentación de cada agente dice cuál es.
2. 2En Claude Code, añade hooks que ejecuten el formateador y las pruebas después de cada edición, para que el agente vea los fallos y los corrija.
3. 3Haz que un bot revise cada pull request: activa «Automatic review» en Codex o solicita a Copilot como revisor.
4. 4Cuando el agente cometa el mismo error dos veces, conviértelo en una prueba o en una regla del archivo de instrucciones.

Integrado en

• Claude Code · Hooks
• Codex · Codex code review
• GitHub Copilot · Copilot code review

Prompt para copiar

Lee este repositorio y escribe el archivo de instrucciones para agentes de programación:
1. Los comandos exactos para instalar, compilar, ejecutar las pruebas, pasar el linter y formatear.
2. La estructura del proyecto en 10 líneas o menos.
3. Las convenciones en las que se equivocan aquí los recién llegados, con un ejemplo de cada una.
4. Lo que un agente nunca debe hacer aquí, por ejemplo cambiar migraciones o editar archivos generados.
Incluye solo los comandos que hayas ejecutado con éxito; marca el resto como «no verificado».

Dónde falla

• Un archivo de instrucciones con comandos que ya no funcionan enseña al agente a ignorarlo. Vuelve a ejecutarlos cuando cambie la configuración del proyecto.
• Los bots de revisión también cometen errores con total aplomo. Trata sus comentarios como sugerencias.

Cómo hacerlo

1. 1Haz una lista de lo que más pegas en los chats, como incidencias, logs de errores, documentación o el esquema. Conecta eso primero.
2. 2Añade el servidor MCP oficial de cada uno, con un token que solo pueda leer. En Gemini CLI, una extensión puede incluir el servidor MCP y su configuración.
3. 3Dale una tarea que los necesite y comprueba que llamó al correcto.
4. 4Cada pocas semanas, quita los servidores que ya no uses.

Integrado en

• Gemini CLI · Extensions

Prompt para copiar

Antes de cambiar nada: lee la incidencia [id] en el gestor de incidencias, encuentra el error en los logs y consulta la documentación de [biblioteca].
Di qué te dijo cada uno y qué archivo crees que tiene la culpa.
No escribas en ninguna herramienta conectada.

Dónde falla

• Una página web, una incidencia o un documento pueden contener texto escrito para dirigir al agente. No des acceso de escritura a herramientas que leen contenido de fuera.
• Los tokens en archivos de configuración se filtran. Usa el almacén de secretos del cliente o variables de entorno, nunca el repositorio.

Cómo hacerlo

1. 1Revisa lo que ya pagas: los planes de ChatGPT incluyen Codex y los planes de pago de Claude incluyen Claude Code.
2. 2Anota el uso de tokens de algunas sesiones típicas, allí donde tu agente lo muestre.
3. 3Calcula el precio de ese uso en nuestra página de precios de la API y compáralo con la suscripción.
4. 4Para automatización y CI, usa claves de API con un límite de gasto, para que un bucle no dispare la factura.

Integrado en

• ChatGPT · Codex
• Claude · Claude Code

Prompt para copiar

Este es mi uso en [n] sesiones típicas: [tokens de entrada y de salida]. Trabajo unos [días] días a la semana.
Estima mi coste mensual pagando por token con estos precios: [pega desde la página de precios de la API].
Compáralo con una suscripción de [precio] al mes. Muestra los cálculos para que pueda comprobarlos.

Dónde falla

• Las suscripciones también tienen límites de uso. Llegar a uno a mitad de una tarea cuesta tiempo; revisa el límite, no solo el precio.
• El modelo cambia la factura más que cualquier otra cosa. Compara con el modelo que usas de verdad.

Cómo hacerlo

1. 1Ejecuta /init en el repositorio: analiza el código y escribe un CLAUDE.md inicial, o sugiere mejoras al que ya tienes.
2. 2Guarda las reglas del equipo, como los comandos de compilación y pruebas y las normas de código, en ./CLAUDE.md y haz commit. Tus preferencias personales van en ~/.claude/CLAUDE.md para todos los proyectos, o en CLAUDE.local.md para este.
3. 3Remite a los documentos largos en lugar de pegarlos: @path/to/file importa otro archivo al arrancar.
4. 4Cada vez que Claude se equivoque dos veces en lo mismo, añade la línea que lo habría evitado.

Prompt para copiar

Lee este repositorio y mejora CLAUDE.md. Que tenga menos de 60 líneas:
1. Los comandos exactos para compilar, ejecutar las pruebas y pasar el linter.
2. La estructura en pocas líneas.
3. Las convenciones en las que se equivoca aquí un recién llegado.
4. Archivos y carpetas que nunca se deben editar.
Elimina todo lo que ya no sea cierto. Marca los comandos que no hayas ejecutado como «no verificado».

Dónde falla

• Todo lo que hay en CLAUDE.md se carga en cada sesión y ocupa contexto. Pasa los detalles a archivos que importe.
• Unas instrucciones que ya no son ciertas son peores que no tener ninguna. Vuelve a comprobar los comandos cuando cambie la configuración del proyecto.

De la documentación oficial: Claude Code docs: How Claude remembers your project

Cómo hacerlo

1. 1Pulsa Shift+Tab hasta que la barra de estado muestre «plan mode on», o empieza tu prompt con /plan.
2. 2Describe el cambio y lo que no debe cambiar. Claude puede seguir ejecutando comandos para explorar, pero no edita archivos mientras planifica.
3. 3Lee el plan como una nota de diseño: un archivo equivocado, un caso que falta, un cambio demasiado grande. Pide cambios hasta que esté bien y luego apruébalo.
4. 4Antes de pasar a otra tarea sin relación, empieza de cero con /clear.

Prompt para copiar

/plan Cambia [qué] para que [objetivo]. Restricciones: [lo que no debe cambiar].
Enumera los archivos que vas a tocar, el orden de los cambios, la prueba que demuestra cada paso y todo aquello de lo que no estés seguro. No edites nada hasta que yo lo apruebe.

Dónde falla

• Un plan que toca más archivos de los que esperabas es la señal de alarma. Pregunta por qué antes de aprobarlo.
• Plan mode sigue ejecutando comandos para explorar. No hace que un repositorio desconocido sea seguro de ejecutar.

De la documentación oficial: Claude Code docs: Choose a permission mode · Claude Code docs: Commands · Claude Code docs: Best practices

Cómo hacerlo

1. 1Abre /permissions para ver cada regla y de qué archivo de configuración viene.
2. 2Pon las reglas del equipo en .claude/settings.json y haz commit. Las reglas personales van en ~/.claude/settings.json o en .claude/settings.local.json.
3. 3Las reglas se evalúan en este orden: primero las de denegar, luego las de preguntar y luego las de permitir, así que una regla de denegar gana a cualquier regla de permitir.
4. 4Cambia de modo con Shift+Tab: acceptEdits aprueba las ediciones de archivos en el directorio de trabajo. bypassPermissions desactiva las preguntas y las comprobaciones de seguridad; la documentación dice que solo se use en contenedores o máquinas virtuales aislados sin acceso a internet.

Prompt para copiar

Mira los comandos que ejecutaste en esta sesión. Propón reglas de permisos para .claude/settings.json: permite los comandos de solo lectura y de pruebas que usamos a diario, deniega todo lo que lea secretos o borre fuera del proyecto y deja que todo lo demás pregunte. Explica cada regla en una línea.

Dónde falla

• Una regla de permitir que coincide con cualquier comando equivale a desactivar las preguntas. Permite comandos exactos.
• Las reglas de .claude/settings.json se aplican a todo el equipo una vez que haces commit. Revísalas como si fueran código.

De la documentación oficial: Claude Code docs: Configure permissions · Claude Code docs: Settings files and precedence · Claude Code docs: Choose a permission mode

Cómo hacerlo

1. 1Entre tareas sin relación, /clear inicia una conversación nueva con el contexto vacío.
2. 2En una tarea larga, /compact indicando en qué centrarse, por ejemplo «/compact conserva el plan y la prueba que falla», resume lo anterior.
3. 3Pasa las búsquedas amplias a un subagente: cada uno se ejecuta en su propia ventana de contexto, así que a tu sesión solo vuelve su respuesta.
4. 4Claude Code también compacta por su cuenta cerca del límite; si compactas tú en un buen momento, se conserva lo que eliges.

Integrado en

• Claude Code · Subagents

Prompt para copiar

/compact Conserva: el objetivo, el plan, los archivos cambiados hasta ahora y la prueba que sigue fallando. Descarta la exploración.

Dónde falla

• /clear olvida la conversación. Todo lo que vayas a necesitar de nuevo debe ir antes a CLAUDE.md.
• La respuesta de un subagente es lo único que recibes. Pídele rutas de archivo y números de línea, no solo conclusiones.

De la documentación oficial: Claude Code docs: Commands · Claude Code docs: Best practices · Claude Code docs: Create custom subagents

Cómo hacerlo

1. 1Inicia cada sesión con claude --worktree <name> (o -w). Crea un git worktree en .claude/worktrees/<name>/ en la rama worktree-<name>.
2. 2Añade .claude/worktrees/ a .gitignore, como recomienda la documentación.
3. 3Dale a cada sesión una sola tarea con su propia comprobación, para que puedas revisarlas una a una.
4. 4Revisa y fusiona cada rama como cualquier otro pull request.

Prompt para copiar

Estás trabajando en un worktree en la rama worktree-[nombre]. Tarea: [un cambio]. Terminada cuando: pase [prueba o comando]. Haz commit solo en esta rama; no hagas merge ni rebase de otras ramas.

Dónde falla

• Cada worktree es su propia carpeta, así que las dependencias y la salida de compilación no se comparten. Instala en cada uno.
• Dos tareas que tocan los mismos archivos siguen chocando al fusionar, con worktree o sin él.

De la documentación oficial: Claude Code docs: Run parallel sessions with worktrees

Cómo hacerlo

1. 1Pulsa Esc dos veces con el prompt vacío, o escribe /rewind (/checkpoint y /undo también funcionan).
2. 2Elige el punto anterior a que todo se torciera y restaura la conversación, el código o ambos.
3. 3Conoce los límites: los archivos cambiados por comandos de shell como rm, mv o cp no se restauran, y tampoco las ediciones hechas fuera de Claude Code o en otra sesión.
4. 4Haz commit antes de los pasos arriesgados. Los puntos de control sirven para recuperarse rápido dentro de una sesión, no para sustituir a git.

Prompt para copiar

Antes de empezar, haz commit del estado actual con el mensaje «punto de control antes de [tarea]». Luego [tarea]. Pregúntame antes de cualquier comando que borre o mueva archivos.

Dónde falla

• Rewind no recupera un archivo que borró un comando. Solo git lo hace.
• Tampoco se capturan las ediciones que hiciste a mano entretanto. Haz commit de ellas antes de usar rewind.

De la documentación oficial: Claude Code docs: Checkpointing · Claude Code docs: Commands

Cómo hacerlo

1. 1claude -p "..." se ejecuta de forma no interactiva. --output-format json o stream-json da una salida que un script puede analizar.
2. 2Termina con 0 si sale bien y con un valor distinto de cero si falla, así que CI puede actuar según el resultado.
3. 3Añade --bare en CI para las ejecuciones que no dependen de la configuración local.
4. 4Para pull requests, /install-github-app configura Claude Code GitHub Actions (solo repositorios de github.com); después menciona a @claude en un comentario de un pull request o de una incidencia.

Prompt para copiar

claude -p "Lee el diff respecto a main. Enumera cada cambio que añada una dependencia, toque la autenticación o modifique una migración de base de datos, en JSON: {\"files\": [], \"reason\": \"\"}. Devuelve una lista vacía si no hay ninguno." --output-format json

Dónde falla

• Un script se ejecuta con los permisos que le das. Dale a CI lo mínimo que necesite.
• /install-github-app solo funciona con repositorios de github.com.

De la documentación oficial: Claude Code docs: Run Claude Code programmatically · Claude Code docs: GitHub Actions

Cómo hacerlo

1. 1Ejecuta /init en la CLI para escribir un AGENTS.md inicial en la carpeta actual.
2. 2Pon tus indicaciones personales en ~/.codex/AGENTS.md y las reglas del proyecto en el repositorio. Una subcarpeta puede tener su propio archivo; ganan los archivos más cercanos al lugar donde trabaja Codex.
3. 3Mantén los archivos cortos: su tamaño combinado tiene un límite, 32 KiB por defecto.
4. 4Añade una sección «## Code Review Rules»: las revisiones de Codex en GitHub la siguen.

Prompt para copiar

Lee este repositorio y escribe AGENTS.md:
1. Los comandos exactos para instalar, compilar, ejecutar las pruebas y pasar el linter.
2. La estructura en pocas líneas.
3. Las convenciones en las que se equivoca aquí un recién llegado.
4. Una sección «## Code Review Rules» con lo que un revisor siempre debe señalar.
Incluye solo los comandos que hayas ejecutado con éxito; marca el resto como «no verificado».

Dónde falla

• Los archivos largos juegan en tu contra: el tamaño combinado tiene un límite de 32 KiB por defecto.
• Un archivo de subcarpeta que contradice al de la raíz sin decirlo confunde tanto a las personas como a Codex. Indica qué anula.

De la documentación oficial: Codex docs: AGENTS.md · Codex docs: CLI commands · Codex docs: GitHub integration

Cómo hacerlo

1. 1En la CLI, /permissions cambia el modo y /status muestra la política de aprobación y las carpetas con permiso de escritura que están en vigor.
2. 2«Ask for approval», el valor predeterminado recomendado, edita y ejecuta comandos dentro del espacio de trabajo y se detiene antes de ir más allá.
3. 3«Approve for me» mantiene el mismo sandbox, pero envía las solicitudes de aprobación a una revisión automática en lugar de a ti.
4. 4«Full access» quita los límites del sistema de archivos y de la red. La documentación lo acompaña de una advertencia; resérvalo para entornos que puedas desechar.

Prompt para copiar

Antes de empezar, ejecuta /status y dime la política de aprobación y las carpetas con permiso de escritura. Luego [tarea]. Pregunta antes de cualquier comando que necesite la red o escriba fuera de este repositorio.

Dónde falla

• Con «Approve for me», ninguna persona lee cada solicitud. Úsalo donde deshacer una acción equivocada cueste poco.
• «Full access» se aplica a toda la máquina, no solo al repositorio.

De la documentación oficial: Codex docs: Permission modes · Codex docs: Sandboxing · Codex docs: Approvals and security · Codex docs: CLI commands

Cómo hacerlo

1. 1codex exec "..." se ejecuta de forma no interactiva y usa por defecto un sandbox de solo lectura.
2. 2Añade --sandbox workspace-write cuando tenga que editar archivos; --full-auto está obsoleto.
3. 3--json emite un flujo JSON Lines de eventos para los scripts que necesitan cada paso.
4. 4En GitHub Actions, openai/codex-action@v1 ejecuta codex exec por ti.

Prompt para copiar

codex exec "Lee los cambios desde la etiqueta [v1.2.0]. Escribe notas de la versión agrupadas en Añadido, Cambiado y Corregido: una línea por cambio, con palabras que entienda un usuario, sin hashes de commit."

Dónde falla

• Las guías antiguas todavía usan --full-auto. Está obsoleto; usa --sandbox workspace-write.
• Una tarea que solo lee debe quedarse en solo lectura, también en CI.

De la documentación oficial: Codex docs: Non-interactive mode · Codex docs: GitHub Action

Cómo hacerlo

1. 1/review en la CLI revisa tu árbol de trabajo. codex review hace lo mismo sin el chat, respecto a una rama base, un commit o los cambios sin commit.
2. 2En GitHub, comenta @codex review en un pull request.
3. 3Activa las revisiones automáticas en «Personal preferences», dentro de la configuración de Codex; así no hace falta ningún comentario.
4. 4Escribe las reglas de tu equipo en una sección «## Code Review Rules» de AGENTS.md.

Integrado en

• Codex · Codex code review

Prompt para copiar

## Code Review Rules
- Señala cualquier cambio en la autenticación o los permisos.
- Señala las migraciones de base de datos que no se pueden revertir.
- Señala las dependencias nuevas e indica si hacen falta.
- Ignora el formato; de eso se encarga el linter.

Dónde falla

• Las revisiones en GitHub solo señalan problemas P0 y P1. Que no haya comentarios no significa que el diseño sea correcto.
• Una revisión es una segunda opinión, no una ejecución de pruebas. Mantén las pruebas.

De la documentación oficial: Codex docs: CLI commands · Codex docs: GitHub integration

Cómo hacerlo

1. 1Crea un entorno con los repositorios, dependencias, herramientas y ajustes de acceso que necesitan las tareas. Los entornos nuevos registran un script de instalación y una skill de inicio.
2. 2Define el acceso a internet de cada entorno: solo gestores de paquetes, dominios elegidos o todo.
3. 3Inicia tareas desde ChatGPT, desde la extensión del IDE para trabajos más largos o desde la terminal con codex cloud exec; --attempts 1-4 pide varios intentos para compararlos.
4. 4Code Review y las integraciones con GitHub y Linear todavía funcionan en el antiguo Codex Cloud (Legacy), que OpenAI planea retirar.

Integrado en

• Codex · Codex Cloud

Prompt para copiar

codex cloud exec --attempts 3 "Tarea: [cambio]. Contexto: [archivos]. Terminada cuando [prueba] pase en este entorno. Mantén el diff por debajo de [n] líneas."

Dónde falla

• Un acceso a internet sin restricciones permite a una tarea llegar a cualquier sitio, incluidas páginas escritas para dirigirla. Permite solo lo que la tarea necesita.
• Si falta el script de instalación, puede que las pruebas no se hayan ejecutado. Comprueba que la tarea las ejecutó de verdad.

De la documentación oficial: Codex docs: Cloud environments · Codex docs: CLI commands · Codex docs: IDE extension

Cómo hacerlo

1. 1Define el modelo y el esfuerzo de razonamiento por defecto en ~/.codex/config.toml (model y model_reasoning_effort). La CLI y la extensión del IDE lo comparten.
2. 2Crea un perfil como archivo propio, ~/.codex/<name>.config.toml, y arranca con --profile <name>.
3. 3Añade servidores MCP con codex mcp add <name> -- <command>; cada uno se convierte en una tabla [mcp_servers.<name>], y /mcp muestra los activos.
4. 4/status muestra lo que está en vigor, y codex resume --last retoma la última sesión de esta carpeta.

Prompt para copiar

Lee ~/.codex/config.toml y el .codex/config.toml de este proyecto. Dime el modelo, el esfuerzo de razonamiento, el sandbox y los servidores MCP en vigor, de qué archivo viene cada uno y cualquier conflicto.

Dónde falla

• Los ajustes del proyecto solo se cargan en proyectos de confianza. Si uno parece ignorado, revisa eso primero.
• Los perfiles ahora son archivos separados. Las guías que ponen [profiles.name] dentro de config.toml están desactualizadas.

De la documentación oficial: Codex docs: MCP · Codex docs: Config basics · Codex docs: Advanced config · Codex docs: CLI commands