ChatGPT para programar: guía práctica con prompts reales

ChatGPT sirve para programar si lo tratas como un compañero rápido pero poco fiable: escribe borradores, explica errores, propone pruebas y documenta, y tú revisas todo. No sustituye el criterio de quien conoce el proyecto. Aquí tienes qué pedirle, cómo pedirlo, con prompts que puedes copiar, y dónde están los riesgos.

¿Para qué sirve ChatGPT al programar y para qué no?

Un asistente como ChatGPT, Gemini o Claude es un modelo de lenguaje. Predice texto plausible a partir de lo que le das. Eso incluye código, pero «plausible» no significa «correcto».

Funciona bien en tareas acotadas y fáciles de comprobar:

• Generar funciones pequeñas, scripts y plantillas (configuración, migraciones, expresiones regulares).
• Explicar código ajeno o un mensaje de error.
• Traducir código de un lenguaje a otro o refactorizar una función concreta.
• Proponer casos de prueba, incluidos los límites que se te olvidan.
• Redactar comentarios, documentación y mensajes de commit.

Funciona mal cuando necesita saber lo que no ve: la arquitectura completa, las reglas de negocio no escritas o el estado real de tu base de datos. También falla con librerías muy recientes o poco usadas. En esos casos suele rellenar huecos con seguridad aparente.

Una corrección sobre algo que se repite mucho: el asistente no «aprende» de ti mientras lo usas hasta volverse más preciso. Dentro de una conversación tiene en cuenta lo que has escrito. Fuera de ella, sus respuestas no mejoran solas.

Tres formas de usarlo

Modalidad	Mejor para	Límites
Chat en el navegador	Dudas, explicaciones, funciones sueltas, depurar un fragmento	Copias y pegas a mano; no ve tu proyecto salvo lo que le muestres
Asistente integrado en el editor	Autocompletado, refactors pequeños, pruebas del archivo abierto	Contexto limitado a lo que el editor envía; sugerencias que se aceptan sin leer
Agente que edita el repositorio	Cambios en varios archivos, tareas repetitivas con pruebas que lo validen	Mayor superficie de riesgo: ejecuta comandos y toca muchos archivos; exige revisar el diff entero

Si empiezas, el chat basta. El resto añade comodidad, pero también más cosas que vigilar. Para una visión de empresa, tienes este análisis sobre la IA en el desarrollo de software.

¿Cómo escribir un prompt que dé código útil?

La diferencia entre una respuesta mediocre y una buena casi siempre está en el contexto. Dile lenguaje, entorno, restricciones y formato de salida. Si quieres profundizar, la guía de prompt engineering cubre la técnica general.

Compara estos dos enfoques. El flojo sería: «hazme un endpoint para pedidos». El que funciona:

Contexto: API en Python con FastAPI y SQLAlchemy 2 (sesiones asíncronas), base de datos PostgreSQL.
Tarea: escribe un endpoint POST /pedidos que valide el cuerpo con Pydantic, guarde el pedido y devuelva 201 con el id.
Restricciones: sin dependencias nuevas. Si el número de pedido ya existe, responde 409 con un mensaje claro.
Formato: primero el código; después una lista de los supuestos que has hecho sobre mi modelo de datos.

Resultado esperado: un esquema Pydantic, una función de ruta asíncrona y un bloque que captura el error de clave duplicada. Debajo, una lista de supuestos del tipo «asumo que existe un modelo Pedido con campo numero único». Esa lista es lo más valioso. Te dice qué debes comprobar antes de integrar nada.

Tres hábitos que mejoran el resultado:

1. Pide supuestos explícitos. Así detectas dónde ha inventado.
2. Trabaja en pasos pequeños. Una función, una prueba, un ajuste. Los bloques enormes esconden errores.
3. Itera con precisión. «Cambia el manejo de errores para usar excepciones propias» rinde más que «mejóralo».

La documentación oficial de OpenAI incluye guías de prompting. Los principios sirven también para otros asistentes. Si empiezas desde cero con la herramienta, repasa cómo usar ChatGPT.

¿Cómo depuro un error con ChatGPT, paso a paso?

Depurar es donde más se nota el ahorro. Pero hay que darle lo mínimo necesario: el código, el error completo y lo que esperabas. Veamos un caso real y habitual.

Tienes esta función en Python:

def anadir_etiqueta(etiqueta, etiquetas=[]):
    etiquetas.append(etiqueta)
    return etiquetas

print(anadir_etiqueta("a"))
print(anadir_etiqueta("b"))

Esperabas ['a'] y luego ['b']. Obtienes ['a'] y ['a', 'b']. Este es el prompt:

Esta función de Python devuelve resultados acumulados entre llamadas. Esperaba una lista nueva en cada llamada.
Explica la causa en 3 frases y propón la corrección mínima. No cambies la firma salvo que sea imprescindible.

[código pegado]

Salida actual: ['a'] y luego ['a', 'b']

Resultado esperado: el asistente identifica que el valor por defecto mutable ([]) se crea una sola vez, al definir la función, y se comparte entre llamadas. Propone usar None como valor por defecto y crear la lista dentro:

def anadir_etiqueta(etiqueta, etiquetas=None):
    if etiquetas is None:
        etiquetas = []
    etiquetas.append(etiqueta)
    return etiquetas

Ahora el paso que no debes saltarte: verifícalo. Ejecuta las dos llamadas y comprueba que salen ['a'] y ['b']. Si el error fuera más enrevesado, pide al asistente que diga qué comprobaría primero y qué hipótesis descarta. Un buen diagnóstico se razona, no se afirma.

Cuando la respuesta no te convence, no repitas la pregunta idéntica. Añade datos: versión del lenguaje, traza completa, qué has probado ya.

¿Puedo usarlo para pruebas, revisión de código y documentación?

Sí, y suelen ser los usos con mejor relación esfuerzo-resultado. Son tareas donde un borrador mediocre ya te ahorra tiempo.

Pruebas

Pide casos límite, no solo el camino feliz:

Escribe pruebas con pytest para esta función. Incluye: caso normal, lista vacía, valores negativos, tipos incorrectos y un caso con decimales.
Usa parametrize cuando haya varios casos similares. No modifiques la función; si ves un fallo probable, indícalo aparte.

[función pegada]

Resultado esperado: un archivo de pruebas legible y una nota con posibles fallos. Ejecútalas. Si alguna falla, puede ser un fallo de la función o una prueba mal planteada. Decidir cuál es cosa tuya.

Revisión de código

Pega un diff pequeño y pide una revisión con criterios claros:

Revisa este cambio como revisor exigente. Busca, por este orden: errores lógicos, problemas de seguridad (inyección, validación de entradas, secretos), manejo de errores y legibilidad.
Responde con una lista: línea o fragmento, problema, severidad (alta, media, baja) y sugerencia. Si no ves problemas en una categoría, dilo.

[diff]

Tómalo como una segunda opinión, no como aprobación. Verá cosas que a ti se te escapan, pero también marcará falsos problemas y dejará pasar otros reales.

Documentación

Aquí rinde mucho: docstrings, un README inicial, un resumen de qué hace un módulo heredado. Pide siempre que se base solo en el código que le das y que marque lo que no pueda saber. Así evitas descripciones inventadas de comportamientos que el código no tiene.

¿Qué riesgos de seguridad y licencias debo tener en cuenta?

Seguridad del código generado

El código que sale del asistente puede compilar, pasar una prueba simple y aun así ser inseguro. Cosas que conviene vigilar:

• Consultas construidas con texto concatenado, abiertas a inyección SQL. Exige consultas parametrizadas.
• Validación de entradas insuficiente o gestión de errores que filtra datos internos.
• Dependencias que no existen. Un asistente puede recomendar un paquete inventado. Comprueba en el registro oficial que existe, quién lo mantiene y que es el que buscas.
• Secretos en el código de ejemplo, como claves y contraseñas, que luego acaban en el repositorio.

Si usas agentes que leen issues, páginas web o documentos externos, añade otro riesgo: instrucciones ocultas en ese contenido pueden manipular al asistente. El proyecto OWASP sobre riesgos de aplicaciones con LLM describe estos problemas con detalle. Pasa el código por tus herramientas habituales de análisis estático y revisión, igual que el de una persona.

Privacidad y datos de la empresa

No pegues claves, datos personales de clientes ni código confidencial en una herramienta que tu empresa no haya aprobado. Mira qué hace el servicio con lo que envías y si hay opciones de uso profesional con condiciones distintas. Si trabajas en Europa, conviene conocer el Reglamento europeo de inteligencia artificial y la política interna de tu organización.

Licencias y propiedad

Aquí hay incertidumbre legal y conviene ser prudente. El código generado puede parecerse a código existente con licencia, y el marco jurídico sobre autoría y entrenamiento sigue en discusión y varía según el país. Esto es información general, no asesoramiento legal.

Prácticas razonables:

• Consulta la política de tu empresa o a su asesoría jurídica antes de usar código generado en productos comerciales.
• Revisa si tu herramienta ofrece filtros o avisos de coincidencia con código público.
• No pidas que reproduzca fragmentos largos de proyectos concretos con licencias restrictivas.
• Identifica las licencias de tus dependencias con identificadores estándar, como los de la lista de licencias SPDX.

Para el debate más amplio sobre normas y responsabilidad, tienes la sección de ética y regulación.

¿Por dónde empiezo?

Si quieres integrar ChatGPT en tu trabajo sin sustos, empieza por el chat y por tareas que puedas comprobar en un minuto: explicar un error, generar pruebas para una función que ya conoces o documentar un módulo. Fija una regla desde el primer día: nada entra en el repositorio sin que lo hayas leído, ejecutado y probado. Cuando esa rutina sea automática, prueba un asistente integrado en el editor. Deja los agentes que modifican varios archivos para el final.

Preguntas frecuentes

¿ChatGPT me va a quitar el trabajo de programador?

Automatiza parte de las tareas, sobre todo las repetitivas y las bien delimitadas. Quedan en tus manos entender el problema, decidir el diseño y responder por el resultado. Quien sabe programar saca más partido que quien no, porque detecta cuándo la respuesta está mal.

¿Puedo aprender a programar con ChatGPT?

Sí, como tutor que explica y propone ejercicios. Funciona mejor si intentas resolver tú primero y le pides pistas, no la solución completa. Si solo copias, no aprendes y no sabrás detectar sus errores.

¿Qué lenguajes entiende mejor?

Suele rendir mejor en los lenguajes y frameworks muy extendidos, con mucha documentación pública. En tecnologías minoritarias, muy nuevas o internas de tu empresa, es más probable que invente funciones. Contrasta siempre con la documentación oficial.

¿Es mejor ChatGPT, Gemini o Claude para programar?

Cambia con el tiempo y según la tarea, así que conviene probarlos con tu propio código. Usa el mismo prompt en dos o tres asistentes y compara la corrección, las explicaciones y los supuestos que declaran. Decide con ese ejemplo real, no con listados ajenos.