La forma segura de pedirle cambios a una IA en GitHub

Primera regla: la IA no empieza en main

En el capítulo anterior dejamos que ChatGPT leyera un repositorio. Pedir una edición cambia el riesgo: el agente ya no se limita a explicar un archivo, ahora puede reescribirlo, borrarlo o tocar otros que no formaban parte del encargo.

La solución es muy concreta. Conserva la versión estable en `main` y haz que cualquier cambio de IA nazca en otra rama. Mientras no la fusiones, la web, la aplicación o el documento principal siguen como estaban.

Codex puede trabajar en un entorno aislado, devolver un resumen y enseñarte el diff, la comparación entre las líneas antiguas y las nuevas. Desde ahí puedes pedir otra vuelta o preparar una pull request. Nada de eso obliga a aceptar el resultado.

Para la primera prueba utiliza `prueba-ia` y encarga una sola modificación del `README.md`. Si no puedes leer todos los cambios en menos de un minuto, el ejercicio es demasiado grande.

Un encargo pequeño que puedes copiar

Un buen encargo responde a cinco preguntas: qué resultado quieres, qué archivo puede tocar, qué debe conservar, cómo se comprueba y dónde tiene que detenerse. No necesita vocabulario técnico.

> Añade a `README.md` una sección breve llamada «Objetivo». Modifica solo ese archivo y conserva todo el texto existente. Comprueba que el Markdown se vea correctamente. Al terminar, enséñame un resumen y el diff. No fusiones la rama.

El límite «solo ese archivo» evita que una mejora del README acabe cambiando la configuración. La comprobación obliga al agente a revisar el formato. La última frase reserva la decisión para ti.

Si durante el trabajo descubre que necesita otro archivo, debe parar y explicar por qué. Puedes ampliar el encargo después, pero ya no será una decisión escondida dentro de la ejecución.

El mismo patrón sirve para documentación, datos o contenido editorial. Como contamos al explicar qué es un agente de IA, la herramienta puede encadenar varias acciones. Un alcance pequeño hace que ese recorrido sea legible.

Lee el diff antes de pulsar Merge

En el diff, el verde señala incorporaciones y el rojo eliminaciones. Lee ambos. Una frase nueva impecable no compensa que el agente haya borrado otra parte del archivo por accidente.

Abre después el archivo completo y ejecuta las pruebas del proyecto si existen. El diff enseña qué cambió, pero el contexto revela si ese cambio rompe algo cercano. La guía de GitHub sobre pull requests muestra el mismo recorrido de propuesta, revisión y fusión.

Antes de aceptar, comprueba cinco cosas: solo cambió lo pedido, entiendes cada línea, el proyecto sigue funcionando, no aparecen secretos o datos privados y sabrías volver atrás. Si una respuesta es «no lo sé», no pulses Merge.

Puedes comentar la pull request, pedir una corrección o cerrarla. Una segunda revisión con IA también puede encontrar fallos, pero no sustituye las pruebas ni tu lectura. En el último capítulo programaremos una publicación ya aprobada sin darle a la automatización permiso para decidir el contenido.