Cómo hacer que ChatGPT programe como un senior: 3 trucos que cambian por completo el resultado

Hay una pregunta que se repite muchísimo cuando alguien empieza a usar IA para programar: ¿por qué dos personas con el mismo ChatGPT obtienen código tan distinto?

Uno recibe un script espagueti que medio funciona, se rompe con cualquier caso raro y no aguantaría ni la más suave de las code reviews. El otro saca una solución limpia, estructurada, testeada y con pinta de haberla escrito alguien con tablas.

No es magia. No es suerte. Y tampoco es que uno tenga acceso a una versión secreta del modelo.

La diferencia está en cómo se pide. La mayoría usa la IA como si fuera un buscador glorificado. Le piden un script, copian lo primero que devuelve y tiran millas. Pero cuando haces eso, lo normal es que recibas código de becario complaciente. Código que intenta quedar bien rápido, no código pensado para producción.

Si quieres que ChatGPT, Claude, Gemini o Copilot te devuelvan algo serio, necesitas cambiar el enfoque. Y ese cambio se resume en tres técnicas muy concretas.

El problema de fondo: ChatGPT improvisa cuando tú no diriges

Por defecto, ChatGPT intenta darte una respuesta que suene bien y llegue rápido. Ese es el primer gran error conceptual. Mucha gente cree que está hablando con una máquina expendedora de código, cuando en realidad debería comportarse como si estuviera dando instrucciones a un ingeniero junior.

Si no le das contexto, improvisa. Y cuando improvisa, adivina.

No sabe qué versión de Python usas. No sabe si tu equipo trabaja con pandas o polars. No sabe si exigís type hints, docstrings, PEP 8, arquitectura por capas o patrón repositorio. No sabe si el código debe ser rápido, mantenible o fácil de testear.

Así que rellena los huecos como puede. Y eso casi siempre te deja con algo funcional a medias, pero flojo en lo importante.

Un ejemplo clásico es pedir algo como esto:

• “Dame un script en Python para procesar un CSV de ventas”.

¿Qué suele salir? Un bloque plano de código con rutas hardcodeadas, columnas asumidas a mano, lectura completa del CSV en memoria, cero validaciones y ni rastro de tests. Puede que funcione con un archivo pequeño y bien formado. En el mundo real, eso no pasa una revisión seria ni de casualidad.

La mentalidad senior empieza justo aquí: el primer output no es la solución final, es un borrador.

Técnica 1: Context Seeding

La primera técnica es la más importante porque cambia por completo el punto de partida. Se llama context seeding, que básicamente consiste en sembrar el contexto antes de pedir una sola línea de código.

En vez de lanzar una petición vaga, defines las reglas del juego desde el principio.

Qué conviene especificar

• Rol o seniority: “Eres un desarrollador senior de Python”.
• Stack concreto: Python 3.12, pandas, pytest.
• Arquitectura: patrón repositorio, separación por servicios, modelos definidos.
• Estilo y calidad: type hints completas, docstrings, PEP 8.
• Requisitos no negociables: cobertura de tests alta o total.

Un prompt mucho mejor para la misma tarea sería algo parecido a esto:

• “Eres un senior Python developer. Quiero un pipeline de datos usando patrón repositorio con pandas, type hints completas, docstrings y tests con pytest”.

Solo con eso, el salto es brutal.

De repente, en lugar de un script pegado con cinta adhesiva, la IA propone una estructura de proyecto más seria. Separa repositorios, transformadores, modelos, tests y configuración. Organiza mejor los imports. Documenta métodos y parámetros. Piensa en responsabilidades distintas en lugar de meterlo todo en una sola función gigante.

¿Ha cambiado ChatGPT? No. Ha cambiado el contexto.

Este es un principio que conviene tatuarse mentalmente: si entra basura de contexto, sale basura de código.

Cuando le das una identidad técnica y unos estándares claros, ChatGPT deja de adivinar y empieza a trabajar dentro de unas restricciones profesionales. Ahí es cuando deja de parecer un becario improvisando y empieza a comportarse como alguien con criterio.

Técnica 2: Test-Driven Prompting

Ya tienes una estructura mejor. Perfecto. Pero ahora toca la gran pregunta: ¿ese código aguanta casos reales o solo funciona en un ejemplo bonito?

Aquí entra la segunda técnica, y es probablemente la que más valor aporta si quieres robustez de verdad. En lugar de pedir primero la implementación, pide primero los tests.

Sí, exactamente igual que en TDD.

Cómo plantearlo

Siguiendo con el pipeline de ventas, la instrucción sería algo así:

• “Escribe primero los tests unitarios con pytest para este pipeline. Cubre casos clave: CSV vacío, columnas faltantes, tipos incorrectos, archivos de 100000 filas, etc. Luego escribe el código que pasa esos tests”.

Esto obliga a ChatGPT a pensar al revés. Antes de implementar, tiene que imaginar qué puede fallar. Y eso cambia totalmente la calidad del resultado.

Qué consigue esta técnica

• Hace que la IA contemple casos edge desde el principio.
• Le obliga a definir expectativas observables.
• Evita implementaciones ingenuas que solo cubren el happy path.
• Convierte los tests en documentación viva del comportamiento esperado.

De pronto empiezan a aparecer pruebas para cosas que el prompt básico ni olía:

• Archivos vacíos.
• Columnas obligatorias ausentes.
• Filas malformadas.
• Valores numéricos que llegan como texto.
• Problemas de encoding.
• Escenarios de rendimiento y carga.

Cuando después pides la implementación, el código cambia de naturaleza. Ya no se limita a “hacer algo”. Ahora tiene que pasar pruebas concretas.

Eso suele traducirse en validaciones de entrada, manejo explícito de errores, excepciones más precisas y una lógica bastante más robusta. La diferencia con el primer script plano es abismal.

Además, hay un beneficio extra que mucha gente infravalora. Los tests cuentan una historia. Si vuelves al proyecto dentro de tres semanas, o si entra otra persona al equipo, puede leer esos tests y entender qué se espera de cada pieza sin tener que rastrear todo el código.

Ese es el tipo de detalle que separa el código “que funciona hoy” del código “que sigue siendo útil mañana”.

Técnica 3: restricciones de rendimiento en zero-shot

El tercer truco es donde de verdad se ve la diferencia entre pedir código y dirigir ingeniería. Aquí ya no hablamos solo de limpieza o tests, sino de rendimiento.

La idea es muy simple: especifica restricciones concretas sin decirle cómo cumplirlas.

No hace falta darle la solución. Solo hay que fijar los límites.

Ejemplo de prompt

• “Este pipeline debe procesar 1 millón de filas en menos de 5 segundos usando menos de 500 MB de memoria RAM. Optimiza para complejidad O(n) y utiliza procesamiento por chunks”.

Aquí ocurre algo muy interesante. ChatGPT reestructura el código desde arriba hasta abajo para adaptarse al objetivo.

Desaparece la idea de cargar el CSV entero de golpe. Empieza a plantear lectura por bloques, procesamiento por chunks, operaciones vectorizadas y liberación progresiva de memoria. Es decir, deja de pensar como script rápido y pasa a pensar como pipeline serio de análisis de datos.

Con estas restricciones, el resultado puede pasar de algo torpe que tarda decenas de segundos y dispara el consumo de memoria, a una solución mucho más eficiente, capaz de procesar grandes volúmenes sin despeinarse.

Y lo mejor es que esto no es exclusivo de una sola herramienta. Se puede aplicar con GPT, con Claude, con Gemini o incluso como criterio general al trabajar con asistentes de código.

Qué modelo lo hace mejor

Aquí conviene ser muy pragmático. No hay una herramienta que gane siempre en todo.

• ChatGPT (GPT-4 o GPT-5) suele ser muy fuerte proponiendo arquitectura, separación de responsabilidades y mejoras no pedidas.
• Claude tiende a seguir mejor las restricciones y a producir código más limpio y directo, con menos florituras.
• Copilot va muy bien para autocompletar mientras programas, pero se queda corto cuando le pides generar una arquitectura completa con restricciones complejas.

Ahora bien, el veredicto importante es otro: un buen prompt en un buen modelo vale muchísimo más que un mal prompt en el mejor modelo del mercado.

La técnica importa más que la herramienta. No es la flecha. Es el indio que la dispara.

La mentalidad correcta: deja de pedir código, empieza a dirigirlo

Todo esto no va realmente de prompts. Va de mentalidad.

La transformación de verdad ocurre cuando dejas de tratar la IA como una máquina expendedora y empiezas a tratarla como un ingeniero junior al que estás mentorizando. Le das contexto. Le exiges pruebas. Le pones límites de rendimiento. Le marcas el estándar.

Ese flujo de trabajo de tres pasos debería convertirse en tu nueva base:

1. Siembra contexto.
2. Pide tests antes que implementación.
3. Acota rendimiento y complejidad.

Haz esto de forma consistente y el nivel del código que recibes cambia por completo.

Mientras muchos siguen copiando y pegando lo primero que les devuelve el modelo, tú estarás generando soluciones que podrían sostener una revisión seria en cualquier equipo profesional. Esa diferencia importa muchísimo. Es la diferencia entre usar IA de forma pasiva o usarla para elevar de verdad tu criterio y tu productividad.

Un reto práctico para comprobarlo hoy mismo

Haz la prueba con algo real. Coge un script que hayas generado hace poco con ayuda de IA y vuelve a pedirlo aplicando estas tres técnicas.

Compara:

• La estructura del proyecto.
• La calidad del código.
• La presencia de tests.
• La robustez ante errores.
• El rendimiento con datos grandes.

La diferencia suele ser tan grande que cuesta creer que salga del mismo modelo.

Si quieres profundizar de verdad en este enfoque y llevarlo a un nivel mucho más serio, merece la pena echar un vistazo al curso de Vibe Coder, donde se trabaja prompt engineering para developers e inteligencia artificial agéntica con una mentalidad mucho más profesional. Y si además te interesa seguir aprendiendo sobre IA aplicada, programación y desarrollo de producto, también puedes explorar la formación de inteligencia artificial y los cursos de programación de Frogames.

Al final, ChatGPT es el mismo para todo el mundo. Lo que cambia es cómo le hablas.

Y ahí, precisamente ahí, está el verdadero oro.