Programar con IA: Copilot, Cursor y agentes (módulo 1 gratis)

Programar con IA no es escribir menos código: es pasar de escribir a especificar y revisar. Esta guía es el primer módulo completo de nuestro curso de desarrollo con IA: qué tipo de asistente encaja en cada flujo, cómo funcionan por dentro y por qué inventan APIs, cómo dejar el entorno preparado, cómo pedir código que entre directo al repositorio y qué protocolo de verificación aplicar antes de aceptar nada.

Estás leyendo gratis el primer módulo del curso Programación y Desarrollo con IA: Copilot, Cursor y Agentes de Código. No hace falta registrarse.

Contenido de esta página

• Bienvenida: cómo la IA cambia programar
• Panorama de herramientas
• Cómo funcionan los asistentes de código
• Configurar tu entorno con IA
• Prompts efectivos para código
• Límites, alucinaciones y verificación

Bienvenida: cómo la IA cambia programar

Lo que ha cambiado de verdad

Programar con un asistente de IA no es «escribir menos código». Es un cambio en dónde pasas el tiempo. Antes: buscar cómo se hacía algo, escribir el andamiaje, teclear el bucle de siempre. Ahora: describir lo que quieres, leer lo que te propone y decidir si es correcto.

El oficio se desplaza de escribir a especificar y revisar. Quien sabe leer código con criterio multiplica su productividad. Quien no sabe leerlo, multiplica sus bugs.

Para quién es

• Desarrolladores de cualquier nivel que quieran integrar la IA en su flujo real.
• Perfiles técnicos no desarrolladores (sistemas, datos, QA) que escriben scripts.
• Estudiantes y autodidactas que quieren aprender sin que la IA les impida aprender.
• Responsables técnicos que tienen que decidir qué herramientas adopta el equipo y con qué normas.

Necesitas saber programar algo. Este curso no enseña a programar: enseña a programar con IA.

Dónde se gana y dónde no

Gana mucho	Gana poco o es peligroso
Código repetitivo y andamiaje	Decisiones de arquitectura
Tests unitarios	Optimización fina de rendimiento
Traducir entre lenguajes	Código con requisitos de seguridad críticos
Entender código ajeno	Depurar un fallo intermitente en producción
Expresiones regulares y consultas	Lógica de negocio compleja y específica
Documentar	Cualquier cosa que no sepas verificar
Scripts de una sola vez	Aprender un concepto por primera vez

El riesgo del que poco se habla

Un asistente produce código que parece correcto, compila y pasa el caso feliz. Los fallos aparecen en los casos límite, en la gestión de errores y en la seguridad. Si aceptas sugerencias sin leerlas, estás acumulando deuda técnica a una velocidad que antes era imposible.

Y hay un segundo riesgo, para quien está aprendiendo: si delegas la parte de pensar, no desarrollas el criterio que necesitas para revisar. Es la trampa del principiante productivo.

Qué vas a saber hacer al terminar

1. Elegir y configurar el asistente que encaja con tu entorno y tu equipo.
2. Escribir peticiones que produzcan código utilizable, con contexto suficiente.
3. Usar la IA para tests, refactorización, revisión y documentación.
4. Detectar alucinaciones y código inseguro antes de que entren en el repositorio.
5. Trabajar con agentes que ejecutan tareas de varios pasos, y saber hasta dónde dejarles.
6. Establecer normas de equipo sobre uso de IA, propiedad del código y confidencialidad.

Ejercicio 1: mide tu punto de partida

1. Anota en qué inviertes el tiempo en una jornada normal: escribir código nuevo, depurar, leer código ajeno, tests, documentación, reuniones.
2. Marca las tareas que consideras mecánicas.
3. Si ya usas un asistente, anota cuántas sugerencias aceptas sin leer del todo. Sé honesto.
4. Escribe qué parte de tu trabajo no delegarías nunca, y por qué.

Qué deberías tener al acabar: un reparto de tu tiempo y una lista de límites propios. Volveremos a ella en el módulo 6, cuando hablemos de normas de equipo.

Panorama de herramientas

Tres formas de meter IA en tu flujo

1. Autocompletado en el editor

Sugerencias en línea mientras escribes, a partir del contexto del archivo y del proyecto. GitHub Copilot es el más extendido; hay alternativas como Codeium, Tabnine o Amazon Q. Algunas ofrecen modo local, útil si tu código no puede salir de la empresa.

Dónde brilla: código repetitivo, funciones evidentes, tests parecidos a otros que ya existen.
Dónde molesta: cuando estás pensando. La sugerencia constante interrumpe el razonamiento. Aprende el atajo para silenciarlo.

2. Chat integrado en el editor

Cursor, Windsurf, Copilot Chat, Continue y similares. Aquí conversas sobre tu código: le señalas archivos, le pides cambios, le pides explicaciones. La ventaja sobre un chat externo es que ve tu proyecto, así que no tienes que pegar contexto todo el rato.

Dónde brilla: refactorizar, entender código ajeno, generar tests, cambios que tocan varios archivos.

3. Agentes de código

Herramientas que reciben una tarea, planifican, editan varios archivos, ejecutan comandos y comprueban resultados. Claude Code, Codex, Jules, Devin y compañía.

Dónde brillan: tareas bien acotadas y verificables — migrar una dependencia, aplicar un patrón a cincuenta ficheros, escribir la batería de tests de un módulo.
Dónde fallan: tareas ambiguas, o cualquier cosa donde no exista una forma automática de comprobar que ha salido bien. Sin tests, un agente es un becario sin supervisión.

Y el chat de propósito general

ChatGPT, Claude o Gemini en el navegador siguen siendo útiles para pensar en voz alta, valorar enfoques, entender un error críptico o discutir una decisión de diseño. Menos práctico para editar código, muy práctico para razonar antes de escribirlo.

Criterios para elegir

• ¿Puede salir tu código de la empresa? Si no, busca opciones locales o con garantías contractuales. Es el criterio que más decisiones cierra.
• ¿Qué editor usa tu equipo? La integración importa más que las diferencias de modelo.
• ¿Cuánto contexto maneja? Para proyectos grandes, es determinante.
• ¿Qué licencia tiene el código generado? Y qué garantías da el proveedor al respecto.
• Coste por persona y mes, frente al tiempo que recupera.

Recomendación práctica

Empieza con autocompletado + chat en el editor. Domínalos un par de meses. Solo entonces incorpora agentes, y hazlo primero en tareas con buena cobertura de tests, que es donde puedes verificar sin esfuerzo.

Y una advertencia de equipo: si cada persona usa una herramienta distinta, las revisiones de código se vuelven un caos de estilos. Vale la pena acordar una.

Ejercicio 2: prueba comparada

1. Elige una tarea real y pequeña de tu backlog, de una hora aproximadamente.
2. Hazla con autocompletado y cronometra.
3. Haz una tarea equivalente usando chat en el editor y cronometra.
4. Anota, además del tiempo: cuántas sugerencias tuviste que descartar y cuántos errores encontraste después.

Qué deberías tener al acabar: datos propios en lugar de opiniones ajenas. El tiempo bruto engaña: lo relevante es el tiempo hasta tener código que pasa la revisión.

Cómo funcionan los asistentes de código

Qué hace realmente por dentro

Un asistente de código es un modelo de lenguaje entrenado con enormes cantidades de código público. Cuando escribes, predice la continuación más probable dado el contexto que ve. No ejecuta tu programa, no razona sobre tu arquitectura y no sabe si tu función devuelve lo correcto: predice texto que parece el código adecuado.

Entender esto explica todos sus comportamientos: por qué acierta tanto en lo común, por qué inventa métodos que no existen, y por qué su código funciona en el caso normal y falla en el borde.

Qué «ve» el asistente

Su ventana de contexto suele incluir:

• El archivo abierto, o la parte cercana al cursor.
• Archivos abiertos en otras pestañas.
• Fragmentos que considera relevantes de tu proyecto.
• Lo que le hayas dado explícitamente en el chat.
• Ficheros de instrucciones del proyecto, si los tiene.

No ve lo que no está ahí: variables de entorno, el esquema real de tu base de datos, la documentación interna, ni las decisiones que tomasteis en una reunión. Muchas malas sugerencias son en realidad falta de contexto.

Consecuencia práctica: tú controlas el contexto

• Ten abierto lo relevante. Si trabajas en un servicio, abre también el modelo y la interfaz que usa.
• Señala archivos explícitamente en el chat en vez de esperar que los encuentre.
• Nombra bien las cosas. Nombres descriptivos mejoran las sugerencias mucho más de lo que parece.
• Escribe la firma y el comentario antes. Una función bien declarada con su docstring produce implementaciones notablemente mejores.
• Usa un fichero de instrucciones del proyecto con convenciones, versiones y patrones. Es lo que más sube la calidad de forma sostenida.

Por qué inventa APIs

Porque genera lo más plausible. Si en muchas librerías existe un método getUserById, lo propondrá aunque la tuya no lo tenga. Y lo hará con total naturalidad, incluso importándolo correctamente.

Ocurre más con: librerías poco populares, versiones recientes posteriores a su entrenamiento, y APIs internas de tu empresa. La defensa es simple y no negociable: ejecutar el código.

El sesgo hacia lo mayoritario

Como aprende de código público, tiende a proponer lo más común, que no siempre es lo mejor:

• Patrones anticuados que dominaron durante años.
• Versiones antiguas de librerías.
• Malas prácticas de seguridad frecuentes en tutoriales.
• El estilo mayoritario del lenguaje, aunque tu proyecto use otro.

Si tu equipo tiene convenciones propias, tienes que decírselas explícitamente. No las va a adivinar.

No es determinista

La misma petición puede dar respuestas distintas. No es un fallo: es cómo funciona. Implica dos cosas útiles: si una respuesta no te convence, pídela otra vez; y no esperes reproducibilidad exacta en un flujo automatizado.

Ejercicio 3: provoca una alucinación

1. Elige una librería que uses poco o una API interna de tu empresa.
2. Pide al asistente que escriba código usándola, sin darle documentación.
3. Comprueba método a método si existen de verdad.
4. Repite dándole ahora la documentación real o el fichero de la interfaz en el contexto.
5. Compara ambos resultados.

Qué deberías tener al acabar: la evidencia de que el contexto lo es todo. Casi todos los problemas de calidad que la gente atribuye al modelo son en realidad problemas de contexto que se pueden arreglar.

Configurar tu entorno con IA

La configuración importa más que la herramienta

Dos personas con el mismo asistente obtienen resultados muy distintos según cómo lo tengan montado. Esta lección es la lista de lo que hay que dejar hecho antes de empezar a trabajar en serio.

1. Fichero de instrucciones del proyecto

Es lo más rentable de todo. La mayoría de asistentes leen un fichero en la raíz del repositorio con las reglas del proyecto. Incluye ahí:

• Lenguaje, versiones y gestor de paquetes.
• Framework y librerías principales, con sus versiones.
• Convenciones de nombres, estructura de carpetas y estilo.
• Cómo se ejecutan los tests y el linter.
• Patrones que usáis y patrones prohibidos.
• Cómo se gestionan errores, logs y configuración.
• Qué NO debe tocar nunca (migraciones aplicadas, ficheros generados, secretos).

Media hora escribiendo esto ahorra cientos de correcciones después, y hace que todo el equipo obtenga sugerencias coherentes entre sí.

2. Un entorno donde el error se vea rápido

Con IA generas más código, así que necesitas detectar fallos más deprisa:

• Linter y formateador automáticos al guardar.
• Comprobación de tipos si el lenguaje lo permite. Con IA, el tipado estricto pasa de recomendable a muy recomendable: caza buena parte de las alucinaciones al instante.
• Tests que se ejecuten en segundos y en local.
• Git disciplinado: commits pequeños. Poder revertir sin drama es la red de seguridad de trabajar con IA.

3. Ajustes del asistente

• Aprende el atajo para silenciar el autocompletado. Cuando estés diseñando, apágalo.
• Desactiva sugerencias en ficheros sensibles: configuración, secretos, migraciones.
• Configura la exclusión de ficheros que no deben enviarse al proveedor (.env, claves, datos).
• Revisa la política de privacidad del plan que usas: si es empresa, confirma que no entrena con vuestro código.

4. Normas de equipo

Aunque seas tú solo, escríbelas. Si sois varios, imprescindible:

• Qué herramienta usa todo el mundo.
• Si hay que indicar en el pull request que se ha usado IA (recomendable al principio, para calibrar).
• Qué tipo de código no se genera con IA: criptografía, autenticación, pagos, y cualquier cosa con impacto de seguridad.
• Que quien envía el código es responsable de él, lo haya escrito quien lo haya escrito. Esta frase debería estar en la guía de contribución.

5. Lo que nunca se envía

• Secretos, claves y tokens. Aunque sean de desarrollo.
• Datos personales reales en fixtures o ejemplos.
• Código de terceros bajo licencias restrictivas, si vuestra política lo prohíbe.

Configura un detector de secretos como gancho de pre-commit. Con generación asistida, la probabilidad de que un secreto acabe donde no debe sube.

Ejercicio 4: monta tu entorno

1. Crea el fichero de instrucciones del proyecto con los siete puntos del apartado 1.
2. Comprueba que linter, formateador y tests se ejecutan con un solo comando.
3. Configura la exclusión de ficheros sensibles en tu asistente.
4. Localiza y apunta el atajo para silenciar el autocompletado.
5. Escribe en una página las normas de uso, aunque trabajes solo.

Qué deberías tener al acabar: el proyecto preparado. A partir del módulo 2 todo el trabajo asume que esto está hecho, porque sin ello la mitad de las técnicas rinden la mitad.

Prompts efectivos para código

Pedir código es especificar, no describir

La diferencia entre una sugerencia inservible y una que entra directa al repositorio casi siempre está en cuánta información diste. Un buen encargo de código incluye seis cosas.

Los seis elementos

1. Contexto técnico: lenguaje, versión, framework, librerías disponibles.
2. Qué tiene que hacer: entradas, salidas, tipos, y qué significa cada cosa.
3. Restricciones: rendimiento, memoria, compatibilidad, qué no se puede usar.
4. Casos límite: qué pasa con lista vacía, valor nulo, texto muy largo, red caída.
5. Gestión de errores: ¿lanza excepción, devuelve resultado, registra log?
6. Estilo: convenciones del proyecto, o simplemente «sigue el estilo de este otro fichero».

Antes y después

Mal: «Hazme una función que valide emails.»

Bien: «TypeScript 5, sin dependencias externas. Función validarEmail(valor: string): Resultado donde Resultado es { valido: true } | { valido: false, motivo: string }. Debe rechazar cadena vacía, sin arroba, con espacios, y dominio sin punto. No uses una regex kilométrica: prioriza legibilidad sobre cubrir el RFC entero. Añade tests con Vitest cubriendo esos cuatro casos y dos válidos.»

El segundo produce código que puedes leer en veinte segundos y aceptar.

Técnicas que funcionan

• Enséñale un ejemplo del proyecto. «Escribe este servicio siguiendo el mismo patrón que PedidoService.» Es la forma más rápida de imponer estilo.
• Escribe primero los tests y pídele la implementación que los pase. Además de dar mejor código, te obliga a especificar bien.
• Pide el plan antes del código en tareas grandes: «explícame cómo lo abordarías, no escribas código todavía». Corriges el enfoque antes de que produzca trescientas líneas equivocadas.
• Pide alternativas. «Dame dos enfoques con sus ventajas e inconvenientes.» Muy útil para decisiones de diseño.
• Pide que explique lo que ha escrito. Si la explicación no cuadra con el código, hay un problema.
• Itera en pequeño. «Ahora extrae esa validación a su propia función.» Mejor que reescribir el encargo entero.

Para entender código ajeno

Es de los usos más rentables y menos aprovechados. Peticiones que funcionan muy bien:

• «Explícame qué hace este módulo, en qué orden se ejecuta y qué efectos secundarios tiene.»
• «¿Qué supuestos hace este código que no están comprobados?»
• «Si tuviera que romper esto, ¿por dónde empezaría?»
• «Dibuja el flujo de datos desde la petición hasta la respuesta.»

Para depurar

Dale todo: el error completo con su traza, el código implicado, lo que esperabas, lo que ocurre, y qué has probado ya. El error más común es pegar solo el mensaje de error sin contexto y esperar milagros.

Y una petición muy útil cuando estás atascado: «dame cinco hipótesis de por qué ocurre esto, ordenadas de más a menos probable, y cómo descartar cada una».

Lo que no debes pedir sin revisar a fondo

• Criptografía. Nunca implementes criptografía propia, con o sin IA.
• Autenticación y autorización.
• Consultas construidas concatenando texto: riesgo de inyección.
• Cualquier cosa que maneje dinero o datos personales.

Ejercicio 5: reescribe tres encargos

1. Coge tres peticiones reales que hayas hecho a un asistente esta semana.
2. Reescríbelas incluyendo los seis elementos.
3. Compara resultados: cuenta cuántas iteraciones necesitas con cada versión.
4. Guarda las buenas en un fichero de plantillas del proyecto.

Qué deberías tener al acabar: tres plantillas reutilizables y una idea clara de cuánto tiempo cuesta no especificar bien.

Límites, alucinaciones y verificación

Los cuatro fallos característicos

1. Alucinación de API

Métodos, parámetros o librerías que no existen. Es el más frecuente y, afortunadamente, el más fácil de detectar: no compila o falla al ejecutar. La defensa es ejecutar siempre.

2. Código plausible pero incorrecto

El peligroso. Compila, pasa el caso normal y falla en el borde: un desplazamiento de un índice, una comparación con el signo cambiado, una zona horaria mal tratada, un redondeo. Solo lo cazan los tests y la lectura atenta.

3. Vulnerabilidades

Aprende de código público, y en el código público hay muchísimas malas prácticas. Vigila especialmente: consultas construidas por concatenación, falta de validación de entrada, secretos incrustados en el código, permisos demasiado amplios, dependencias antiguas y gestión de errores que filtra información interna.

4. Desactualización

Propone la forma de hacer las cosas de hace tres versiones, o usa funciones ya obsoletas. Contrasta con la documentación oficial cuando la librería sea crítica.

El protocolo de verificación

Antes de que cualquier código generado entre en tu rama:

1. Léelo entero. Si no lo entiendes, no lo aceptes. Esta regla no admite excepciones y es la más incumplida.
2. Ejecútalo. Incluido el camino de error, no solo el feliz.
3. Comprueba que las APIs existen en la versión que usas.
4. Prueba los casos límite: vacío, nulo, negativo, enorme, con acentos, con emojis.
5. Repasa la seguridad si toca entrada de usuario, base de datos, ficheros o red.
6. Pasa el linter y los tests.
7. Revisa la coherencia con el resto del proyecto: ¿duplica algo que ya existe?

Un truco que funciona: que se revise a sí misma

Pídele, en una conversación nueva y sin el contexto de haberlo escrito: «revisa este código buscando errores, casos límite no cubiertos y problemas de seguridad; sé exigente». Encuentra bastantes de sus propios fallos. No sustituye tu revisión, pero es un primer filtro barato.

El problema de la revisión a escala

Si generas cinco veces más código, necesitas revisar cinco veces más. Como eso no es posible, los equipos acaban revisando peor. Formas de mitigarlo:

• Commits pequeños. Revisar 50 líneas se hace bien; revisar 800, no.
• Automatiza lo automatizable: tipos, linter, análisis estático, escáner de dependencias y de secretos en el pipeline.
• Concentra la revisión humana en lógica de negocio, seguridad y diseño. Deja el estilo a las herramientas.
• Resiste la tentación del volumen. Producir más de lo que puedes revisar no es productividad: es deuda.

Licencias y propiedad

Es un terreno todavía en evolución y conviene saber dónde pisas:

• El código generado puede parecerse a código de entrenamiento. Algunos asistentes ofrecen filtros de coincidencia con código público: actívalos.
• La protección por derechos de autor de lo generado por máquina es un asunto no cerrado en muchos ordenamientos.
• Varios proveedores ofrecen indemnización en sus planes de empresa. Si esto os importa, léelo antes de firmar.
• Si tu empresa tiene política sobre código de terceros, aplícala también aquí.

Sobre aprender

Si estás aprendiendo a programar, invierte el orden: intenta resolverlo tú, y solo después pregunta. Usa la IA como profesor («¿por qué mi solución es peor que esta?») y no como fotocopiadora. La productividad a corto plazo se paga con falta de criterio a medio.

Ejercicio 6: caza los fallos

1. Pide una función con lógica no trivial: parsear fechas en varios formatos, calcular días laborables entre dos fechas, o paginar resultados.
2. Antes de ejecutarla, léela y anota los casos límite que crees que fallan.
3. Escribe tests para esos casos y ejecútalos.
4. Pídele en una conversación nueva que revise ese mismo código con ojo crítico.
5. Compara: lo que viste tú, lo que vieron los tests, lo que vio ella.

Qué deberías tener al acabar: una idea calibrada de cuánto puedes fiarte. La mayoría de la gente descubre que su instinto de revisión es mejor de lo que creía, y que el problema no es la calidad del modelo sino la tentación de no leer.