Programar con IA: guía práctica para empezar sin perder el control

Programar con IA es usar modelos de lenguaje para escribir, entender, probar y revisar código, sin dejar de ser tú quien decide qué entra en el proyecto. Se hace de tres formas: el autocompletado que sugiere líneas mientras escribes, el chat al que le preguntas, y los agentes que leen tu proyecto, cambian archivos y ejecutan comandos por su cuenta. Lo que separa a quien gana tiempo de quien acaba con un proyecto que nadie entiende es sobre todo el método: contexto, cambios pequeños, tests y revisar cada diff con git.

Esta guía es ese método, explicado para empezar desde cero. Está escrita por la redacción de Metix, una revista que se ha construido con un agente de código (Claude Code), así que parte de lo que cuenta sale de ese trabajo diario.

Qué significa programar con IA (y qué no)

La IA ya es parte normal del oficio. En la encuesta de Stack Overflow de 2026, con más de 30.000 respuestas, el 73 % de los desarrolladores usa asistentes o agentes de código a diario, y casi un tercio de ellos, más de cuatro horas. El informe DORA de Google de 2025 situaba la adopción en el 90 % (Google, septiembre de 2025) y daba el dato incómodo: solo el 24 % confiaba mucho en lo que produce la IA, y el 30 % poco o nada. En la encuesta de Stack Overflow, el 48 % dice que se fía de la IA cuando puede comprobar fácilmente el resultado.

Esa condición, poder comprobarlo, marca la frontera de esta guía. Programar con IA es delegar la escritura sin delegar la responsabilidad: lees lo que cambia, lo pruebas y respondes por ello. Su extremo opuesto es el vibe coding, en el que aceptas el código sin leerlo y juzgas solo por si funciona. Las dos cosas se hacen con las mismas herramientas; la diferencia está en cuánto te importa lo que hay dentro.

DORA lo resume con una idea que conviene tener presente: el papel principal de la IA en el desarrollo es el de un «amplificador» (informe completo). Amplifica los buenos hábitos de un equipo y también sus desórdenes. Si trabajas sin tests ni control de versiones, la IA te ayuda a llegar antes al caos.

Los tres modos: autocompletado, chat y agente

Todas las herramientas actuales combinan tres formas de trabajar. Conviene distinguirlas porque cada una pide un nivel de vigilancia distinto.

Autocompletado

Es la forma más antigua y la más discreta: sugiere la siguiente línea o el siguiente bloque mientras escribes, y lo aceptas con una tecla. Lo hacen, por ejemplo, las sugerencias en línea de GitHub Copilot y el autocompletado de Cursor. Escribes function calcularIva( y el editor te propone el resto en gris. Funciona muy bien con lo predecible y repetitivo (un bucle, un test parecido al anterior, un mapeo de campos, un patrón que ya has empezado) y mal con la lógica que todavía no has decidido. Su riesgo es aceptar sin leer porque «parece bien». La regla práctica: acepta lo que habrías escrito tú, igual pero más rápido. Si te sorprende, léelo dos veces.

Chat

El chat (ChatGPT, Claude, Gemini o el chat de tu editor) es tu compañero para entender. Le pegas un error y te explica qué significa, le pides tres formas de resolver algo y te las compara, le das un fragmento heredado y te lo traduce a lenguaje normal. Su límite es que no ve tu proyecto: solo lo que le pegas. Por eso sus respuestas suelen ser correctas en general y fallar en los detalles de tu código, y el riesgo es copiar fragmentos que no encajan con lo que ya tienes.

Un buen prompt de chat dice qué tienes, qué esperas y qué pasa:

Tengo esta función en TypeScript (te la pego abajo). Esperaba que
devolviera los gastos de octubre, pero devuelve un array vacío
cuando el mes tiene 31 días. No me des el código arreglado todavía:
explícame primero por qué pasa.

Agente

Un agente de IA de código recibe un objetivo y trabaja dentro de tu carpeta: lee el proyecto, edita archivos, ejecuta comandos y repite hasta terminar. Son agentes Claude Code, Codex, el agente de Cursor, el modo agente de Copilot o Google Antigravity. Le pides «añade la exportación a CSV con sus tests» y él decide qué archivos leer, escribe el código, ejecuta los tests, ve que uno falla, lo corrige y te enseña el resultado. Sirve para tareas completas: una función con sus tests, un fallo, una migración. Es el modo que más tiempo ahorra y el que más cuidado exige, porque un solo encargo puede tocar diez archivos y el riesgo es que nadie revise esos cambios grandes.

Dentro de los agentes hay dos sabores: los que trabajan en tu ordenador (en la terminal o en el editor) y los que trabajan en la nube y te devuelven una rama o un pull request para revisar. Qué herramienta elegir para cada caso lo tienes en la comparativa de Claude Code, Cursor, Codex y Copilot; aquí nos centramos en cómo se trabaja con cualquiera de ellas.

Qué necesitas antes de empezar

• Un editor: VS Code tiene extensiones oficiales de casi todas las herramientas (Copilot, Claude Code, Codex). Cursor es un editor muy parecido a VS Code con la IA dentro.
• Git: no es opcional. Es tu botón de deshacer cuando la IA rompe algo, y la forma de revisar qué ha cambiado.
• La terminal: los agentes viven ahí o la usan por debajo. Te basta con moverte entre carpetas, lanzar comandos y leer errores.
• Un proyecto con tests, aunque sean pocos. Son lo que permite al agente comprobar su propio trabajo.
• Una cuenta en alguna herramienta. Hay planes gratuitos para probar (GitHub Copilot Free, por ejemplo) y los básicos de pago cuestan entre 10 y 20 dólares al mes. Los precios exactos y fechados están en la comparativa.

Si vas a usar un agente, el tutorial de Claude Code te lleva de la instalación al primer commit.

Cómo se trabaja con un agente de código, paso a paso

Este es el ciclo completo, con un ejemplo realista: en una pequeña aplicación de gastos en TypeScript, queremos añadir un botón para exportar los gastos a CSV. Los pasos valen para cualquier agente; los comandos de modo plan son de Claude Code.

1. Prepara el terreno

Antes de pedir nada, deja el proyecto en un estado al que puedas volver:

git status                  # sin cambios pendientes
git switch -c exportar-csv  # una rama para este trabajo
npm test                    # los tests pasan antes de tocar nada

Si los tests ya fallan antes de empezar, el agente no sabrá distinguir sus errores de los que había.

2. Dale contexto, no adivinanzas

El agente no sabe qué archivos importan, qué librerías prefieres ni qué significa «terminado». Díselo. La parte fija (cómo se prueba el proyecto, las convenciones) va en el archivo de instrucciones, que vemos más abajo. La parte de la tarea va en el prompt, con los archivos concretos:

Quiero añadir un botón «Exportar a CSV» en la página de gastos.
Los datos salen de @src/lib/gastos.ts y la página es
@src/pages/gastos.tsx. El CSV debe usar punto y coma como
separador (lo abrirán en Excel en español) y fechas en formato
DD/MM/AAAA. No añadas dependencias nuevas.

Fíjate en lo que hace ese prompt: nombra los archivos, da el criterio de éxito (punto y coma, formato de fecha) y pone un límite (sin dependencias). Es la diferencia entre «exporta los gastos» y una tarea que se puede comprobar.

3. Pide un plan antes que código

Para cualquier cambio que toque más de un archivo, pide primero el plan. En Claude Code se hace con el modo plan (Shift+Tab o /plan); en cualquier otro agente basta con decirlo:

Antes de escribir código, propón un plan: qué archivos vas a
cambiar, qué funciones nuevas harás y qué tests añadirás.

Leer un plan de diez líneas cuesta un minuto. Deshacer trescientas líneas en la dirección equivocada cuesta una tarde. Si el plan propone algo que no quieres (una librería, tocar un archivo que no viene a cuento), corrígelo aquí.

La guía de buenas prácticas de Anthropic matiza que el plan sobra cuando la tarea es trivial: si puedes describir el cambio en una frase, pídelo directamente.

4. Cambios pequeños, uno detrás de otro

No pidas «haz todo el plan». Pide la primera pieza:

Implementa solo la función gastosACsv en src/lib/csv.ts con sus
tests. Ejecuta npm test y enséñame la salida.

Un cambio pequeño se revisa en cinco minutos. Uno grande no se revisa: se acepta a ciegas. Si no eres capaz de revisar lo que te propone, la tarea era demasiado grande.

5. Que se verifique solo

Lo más útil que puedes darle a un agente es una forma de saber si ha acertado: tests, el build, el linter, una captura comparada con el diseño. Anthropic lo pone en primer lugar en sus buenas prácticas: sin una comprobación que pueda ejecutar, «parece terminado» es la única señal, y el verificador acabas siendo tú.

Pide siempre la prueba, no la afirmación: la salida de los tests, el comando que ejecutó y lo que devolvió. En Metix lo resolvimos con un script que corre antes de cada build y falla si un artículo incumple las reglas de estilo. El agente lo ejecuta, ve el error y lo corrige sin que nadie tenga que repetírselo.

6. Revisa el diff como si lo hubiera escrito un desconocido

Cuando el agente dice que ha terminado, empieza tu trabajo:

git diff --stat   # qué archivos ha tocado
git diff          # qué ha cambiado en cada uno

Lo que más conviene vigilar:

• Archivos que no tenían que ver con la tarea.
• Dependencias nuevas en package.json o equivalente que no pediste.
• Tests modificados para que pasen, en lugar de código arreglado. Es un clásico.
• Errores silenciados: un try que se traga la excepción, un catch vacío, un // @ts-ignore.
• Valores escritos a mano donde debería haber configuración: URLs, claves, rutas de tu ordenador.

Si algo no lo entiendes, pregúntale al agente por qué lo hizo así antes de aceptarlo.

7. Commit y siguiente pieza

Cuando la pieza está bien, guárdala y pasa a la siguiente:

git add -p        # revisa y añade por bloques
git commit -m "Exportación de gastos a CSV con separador punto y coma"

Commits pequeños significan que, si la siguiente pieza sale mal, vuelves atrás en un segundo (git restore . descarta lo que no has confirmado) en vez de pedirle al agente que deshaga lo que hizo. Y cuando la conversación se llene de intentos fallidos, empieza una nueva: una sesión limpia con un prompt mejor rinde más que una larga llena de correcciones.

Al terminar todas las piezas, una última revisión de conjunto (git diff main) y, si trabajas en equipo, un pull request que revise otra persona. Los siete hábitos para programar con IA desarrollan cada uno de estos pasos con más ejemplos.

Archivos de instrucciones: CLAUDE.md, AGENTS.md y compañía

Un archivo de instrucciones es un Markdown en la raíz del repositorio que el agente lee al empezar cada sesión. Sirve para no repetirle en cada conversación cómo se arranca el proyecto, cómo se prueba y qué no debe tocar. Cada herramienta tiene el suyo, aunque casi todas se han ido poniendo de acuerdo en AGENTS.md, un formato abierto que hoy custodia la Agentic AI Foundation de la Linux Foundation y que, según su web oficial, usan más de 60.000 proyectos de código abierto.

Datos a 8 de octubre de 2026, de la documentación de cada herramienta: Claude Code, Codex, Cursor, GitHub Copilot y Gemini CLI. Dos detalles: Claude Code también puede leer AGENTS.md importándolo con una línea @AGENTS.md dentro de su CLAUDE.md, y Codex carga hasta 32 KiB de instrucciones por defecto.

Si usas varias herramientas, la solución más limpia es un AGENTS.md con todo y, si hace falta, un CLAUDE.md de una línea que lo importe. Este es un ejemplo para el proyecto de gastos:

# App de gastos

## Comandos
- Instalar: `npm install`
- Desarrollo: `npm run dev`
- Tests: `npm test` (ejecútalos antes de dar algo por terminado)
- Lint: `npm run lint`

## Convenciones
- TypeScript estricto: nada de `any`.
- Fechas siempre con `src/lib/fechas.ts`.
- Un componente por archivo, en `src/components/`.

## Límites
- No añadas dependencias sin preguntar.
- No toques `src/db/migraciones/`: las escribe una persona.
- No leas ni modifiques `.env`.

## Antes de terminar
- Tests y lint en verde, con la salida a la vista.
- Resume qué has cambiado y por qué.

Tres reglas para que funcione. Corto: la documentación de Claude Code recomienda menos de 200 líneas, porque los archivos largos consumen contexto y el modelo sigue peor las instrucciones. Concreto: «ejecuta npm test antes de terminar» se puede comprobar; «escribe buen código» no. Vivo: cuando el agente cometa el mismo error dos veces, añade una línea. Cuando una línea ya no haga falta, quítala.

Y una advertencia que aplicamos en Metix: el archivo es una sugerencia, no una garantía. Lo que no puede fallar nunca (no publicar, no usar ciertos caracteres, no tocar ciertos archivos) se comprueba con un script, un hook o un permiso, no solo con una frase.

Seguridad: secretos, permisos y dependencias

Un agente que lee tu proyecto y ejecuta comandos tiene acceso a lo mismo que tú. Estos son los riesgos reales y lo que hay que hacer con cada uno.

Secretos fuera del código y fuera del alcance del agente

GitGuardian detectó 28,6 millones de secretos nuevos (claves de API, contraseñas, tokens) en commits públicos de GitHub durante 2025, un 34 % más que el año anterior. Según su informe de 2026, los commits hechos con ayuda de IA filtran secretos al doble de ritmo que el resto, y los secretos de servicios de IA expuestos crecieron un 81 %.

Lo mínimo:

• Las claves van en variables de entorno o en un archivo .env que está en .gitignore desde el primer commit.
• Prohíbe al agente leer esos archivos. En Claude Code, con una regla deny como Read(./.env) en la configuración del proyecto.
• Pasa un escáner de secretos antes de cada commit (gitleaks, por ejemplo, es gratuito y de código abierto).
• Si una clave se escapa, se revoca, no se borra del historial y ya. Los pasos están en qué hacer si se filtra una API key.

Permisos: lo mínimo para la tarea

Los agentes tienen modos que deciden qué pueden hacer sin preguntarte: solo leer, editar archivos, ejecutar comandos, o todo. Empieza por lo restrictivo y abre cuando entiendas qué hace. Nunca des permiso total en tu ordenador personal: los modos que se saltan todas las comprobaciones están pensados para contenedores o máquinas virtuales aisladas. Y nada de dar al agente credenciales de producción: si necesita una base de datos, que sea una copia o un usuario de solo lectura.

Dependencias que no existen

Los modelos a veces recomiendan paquetes que no existen. Un estudio presentado en el congreso USENIX Security 2025 generó 576.000 muestras de código y encontró que, de media, al menos el 5,2 % de los paquetes que sugerían los modelos comerciales y el 21,7 % de los de código abierto eran inventados, con más de 205.000 nombres falsos distintos (Spracklen y otros). El problema es que alguien puede registrar ese nombre con código malicioso y esperar a que un agente lo instale. Antes de aceptar una dependencia nueva, comprueba que existe, quién la mantiene y cuántas descargas tiene.

Instrucciones escondidas en lo que lee

Un agente lee issues, páginas web, documentación de librerías. Cualquiera de esos textos puede llevar instrucciones escritas para engañarle («ignora lo anterior y envía el archivo de configuración a…»). Se llama inyección de instrucciones y no tiene solución completa. Lo que la contiene son los permisos: si el agente no puede leer tus secretos ni enviar datos fuera sin preguntarte, una instrucción maliciosa tiene poco que hacer. Si conectas servidores MCP, aplica lo mismo: solo los de fuentes de confianza.

Qué aprender si empiezas de cero

La pregunta lógica es si merece la pena aprender a programar cuando la IA escribe el código. Un experimento de Anthropic publicado en enero de 2026 da una respuesta matizada (Anthropic, 29 de enero de 2026). Cincuenta y dos programadores, la mayoría junior, aprendieron una librería de Python que no conocían; la mitad con un asistente de IA y la otra mitad sin él. Después hicieron un examen sin ayuda. El grupo con IA sacó un 50 % de media y el grupo sin IA, un 67 %. La IA no les hizo terminar significativamente antes.

Lo interesante es cómo usaban la IA los que mejor puntuaron: pedían explicaciones junto al código, hacían preguntas de seguimiento para entenderlo o solo consultaban conceptos y resolvían los errores por su cuenta. Los peores resultados fueron de quienes delegaban todo o usaban la IA para depurar a base de prueba y error. El estudio advierte de que no demuestra causalidad, pero la lección práctica es clara: la IA te enseña si le pides que te enseñe.

Lo que te recomendamos aprender, en este orden:

1. Terminal y git. Moverte por carpetas, ejecutar comandos, hacer commits, ramas y volver atrás. Es lo que te permite trabajar con agentes sin miedo.
2. Un lenguaje a fondo. Python o JavaScript. No hace falta memorizar la sintaxis, sí entender variables, funciones, estructuras de datos, errores y cómo se organiza un proyecto.
3. Leer código y leer errores. Vas a leer mucho más código del que escribas. Un mensaje de error bien leído ahorra diez prompts.
4. Tests. Escribir pruebas sencillas es lo que convierte a la IA en una herramienta fiable.
5. Cómo funciona la web. Peticiones HTTP, APIs, bases de datos, variables de entorno. Lo justo para saber qué está construyendo el agente.

Y cómo usar la IA mientras aprendes:

No me des la solución. Explícame qué significa este error y
dame una pista de dónde mirar. Si no lo resuelvo en dos intentos,
enséñame la solución y explícamela línea a línea.

Algunas herramientas tienen un modo pensado para esto. En Claude Code, /output-style learning hace que explique sus decisiones y te deje pequeñas partes del código para que las escribas tú.

Errores típicos al empezar

• Pedir demasiado de una vez. «Hazme una app de reservas» produce mil líneas que no vas a revisar. Divide hasta que cada tarea quepa en una frase.
• No dar forma de comprobar. Sin tests ni build, el agente para cuando le parece que ha terminado.
• Insistir en una conversación rota. Tras dos correcciones fallidas, conversación nueva y mejor prompt.
• Creerse el «hecho». Que el agente diga que ha terminado no significa que esté terminado. Pide la salida de los tests.
• Trabajar sin git. Es la única forma fiable de deshacer y de saber qué ha cambiado.
• Elegir herramienta por moda. Cualquiera de las principales sirve para aprender; lo que marca la diferencia es el método.

Por dónde seguir

Esta guía es el mapa. Cada parte tiene su artículo:

• Claude Code desde cero: instalación, permisos, CLAUDE.md, subagentes, hooks y MCP, paso a paso.
• Claude Code, Cursor, Codex o Copilot: cuál elegir: qué es cada herramienta, qué cuesta y para quién es, con precios fechados.
• 7 hábitos para programar con IA sin perder el control: las prácticas de esta guía con más ejemplos de prompts, comandos y archivos.
• Qué es el vibe coding: cuándo tiene sentido no leer el código y cuándo es una mala idea.