Programar con IA acelera lo que ya sabes hacer (y disfraza lo que no)

Empecé a usar la IA como apoyo al programar en 2022, cuando ChatGPT se abrió al público. Codex llegó en 2025, y no lo usé como suele contarse por ahí: no le pedí que me creara una aplicación desde cero.

Le di un proyecto que ya tenía desarrollado, con mis componentes, mis estilos y mis decisiones ya tomadas, y le pedí algo concreto: que desarrollara componentes nuevos respetando la lógica y el estilo de los míos.

Visto con distancia, creo que ese planteamiento fue lo que hizo que funcionara, y también lo que me enseñó dónde deja de funcionar.

Desde entonces uso Codex y Claude. Aquí va lo que he sacado en limpio: dónde me han ahorrado horas, dónde me las hicieron perder y qué tuvo que ver yo en cada caso.

Por qué ayuda que respete lo que ya está

Si le pides a un modelo un componente desde cero, tiene que inventarse las convenciones: cómo nombrar las cosas, cómo organizar los estilos, dónde poner la lógica. Se va a inventar algo razonable, pero no va a ser tuyo.

Cuando le das un proyecto con las decisiones ya tomadas, lo que hace es seguir un patrón que existe, y eso lo hace muy bien.

A mí me ahorró muchísimo tiempo. Lo que escribió no era código que yo no supiera escribir: era el código que iba a escribir de todas formas, y me dejó a mí las decisiones. Sobre esto vuelvo al final, porque es lo que explica casi todo lo demás.

El mejor uso resultó no ser escribir componentes

Lo que más me ha ayudado no es lo que esperaba: ha sido el trabajo con datos.

En proyectos reales, muchas veces no se parte de una base de datos sino de un .csv que alguien exportó de otro sistema, o de un .xlsx con varias hojas, colores y celdas combinadas que en su momento tuvieron sentido.

Antes de migrar eso hay que entenderlo: qué columnas hay realmente, cuáles son la misma cosa escrita de dos formas, dónde están los duplicados, qué campos son en realidad una relación escondida en un texto.

Para eso la IA me ha sido muy útil. Me ayuda a analizar los archivos, a entender los datos y a convertirlos a .json para después migrarlos a bases de datos reales, mejorando los modelos y normalizando por el camino.

Creo que funciona tan bien ahí porque es un trabajo pesado, mecánico y que se puede verificar. Los registros cuadran o no cuadran, las claves se resuelven o no, así que es difícil que se cuele un error sin que lo veas.

200 GB que nadie había leído

El segundo uso que más valor me ha dado no tiene que ver con escribir código, sino con leerlo.

Me tocó revisar servidores con unos 200 GB de archivos, buscando código obsoleto o peligroso. Hecho a mano no es difícil, simplemente es imposible de abarcar. Nadie se lee 200 GB; en la práctica buscas los patrones que ya sospechas, y por lo tanto solo encuentras lo que ya ibas buscando.

Con la IA encontré vulnerabilidades importantes que me habría costado horas localizar. Y, sobre todo, pude corregirlas sin romper nada más, que en un sistema heredado es la mitad del problema.

Me parece de los usos más subestimados. Casi no se habla de él porque no produce nada nuevo ni queda bonito en una captura; lo que produce es entender algo que ya existía y que nadie tenía tiempo de mirar, que en código heredado es justo lo que falta.

Eso sí, aquí el riesgo es real. Lo que te devuelve es una lista de sospechas, no un veredicto. Cada hallazgo hay que confirmarlo mirando el código, y cada corrección hay que entenderla antes de aplicarla. Si no, puedes acabar cambiando un problema de seguridad por otro.

Probé el vibe coding puro, y no

También hice el experimento contrario, y lo cuento porque es lo que menos se publica.

Me dejé llevar del todo por el vibe coding: pedir cosas y ver qué salía, sin dirigir, sin revisar a fondo, confiando en que el conjunto se sostuviera solo.

No salió nada bueno ni que funcionara en un caso real. Y lo peor es que no producía basura evidente.

Sin instrucciones claras y concretas, el modelo se imagina cosas que en teoría funcionan pero que no aguantan en producción. Compila, se ve bien y parece tener sentido si lo lees por encima. El fallo está en las decisiones que tomó por ti para rellenar lo que no le dijiste.

Un error obvio lo ves y lo arreglas en dos minutos. Uno que parece correcto entra al repositorio y se queda ahí.

Aun así, no saqué la conclusión de que la herramienta no sirva. Usándola con cuidado, y llevando un control estricto de qué se hace y qué no, se pueden crear cosas muy buenas. Entre el desastre y lo que sí funcionó, el modelo era el mismo; lo que cambió fue cuánto criterio puse yo en medio.

Colocar componentes no es diseñar un sistema

Esto es lo que más aprendí, y lo que me gustaría que se llevara alguien que está empezando.

Poner componentes (gráficas, botones, menús) y ordenarlos como sea no tiene nada que ver con diseñar un dashboard real, que funcione y que pueda crecer.

A primera vista parecen la misma tarea. Las dos acaban en una pantalla con tarjetas, gráficas y un menú lateral, puedes pedir cualquiera de las dos con casi las mismas palabras, y en los dos casos el modelo te va a devolver algo que se ve bien.

Pero la segunda incluye decisiones que no se ven en pantalla:

• Qué datos se cargan de golpe y cuáles bajo demanda, para cuando la tabla llegue a diez mil filas.
• Qué se recalcula cuando cambia un filtro, y qué no debería recalcularse.
• Dónde vive el estado que comparten tres widgets, y quién manda cuando dos lo tocan.
• Qué pasa cuando una petición falla y la mitad del tablero se queda sin datos.
• Cómo se añade el widget número doce sin reescribir los once anteriores.

Nada de eso aparece en la captura, y todo aparece seis meses después.

De ahí sale lo que para mí es la regla:

Si no has tenido experiencia desarrollando o usando el tipo de cosas que le pides, corres el riesgo de crear un “producto” que empiece a arrastrar errores con el tiempo.

El problema no es que la IA se equivoque demasiado, sino que tú no puedes evaluar lo que te devuelve. Y si no lo evalúas, en realidad estás aceptando propuestas a ciegas, aunque vaya rápido.

La deuda técnica que genera esto no se ve el primer día. Aparece cuando hay que añadir algo que nadie previó y descubres que la estructura sobre la que estás construyendo no la eligió nadie.

Lo que cuesta

Hay otra consecuencia que me parece de las más prácticas y que casi no veo mencionada: no a todo el mundo le cuesta lo mismo.

Alguien sin idea de programación que quiere hacer su web o su aplicación va a gastar muchísimo más que alguien con experiencia. En parte porque escribe peores prompts, pero sobre todo porque cada respuesta que no sabes evaluar es una que vas a tener que volver a pedir.

Sin criterio, el ciclo es pedir, mirar, no saber si está bien y volver a pedir. Con criterio, pides algo acotado, lo revisas, corriges el rumbo en una frase y sigues. Uno cuesta cinco intentos y el otro cuesta uno.

Por eso lo que hace que salga rentable no es solo saber escribir buenos prompts. Es saber programar, diseñar y aterrizar las ideas: saber qué estás pidiendo, reconocer cuándo lo que llega ya sirve y darte cuenta de cuándo se ha desviado antes de gastar tres intentos más.

Como no dependes del todo de la herramienta, te sale más barata. Es un complemento de lo que ya sabes hacer, y lo que rinde cada crédito depende de lo que tú aportas.

Y de paso responde a la pregunta de si esto va a sustituir a alguien: quien más provecho le saca es quien menos lo necesita.

Cómo los uso hoy

Entre Codex y Claude no tengo un reparto estricto: uso los dos para refactorizar y crear código, en backend y en frontend. Lo que sí tengo claro es el método, que es el mismo con cualquiera de los dos:

• Le doy contexto en vez de pedirle criterio: mis componentes, mis convenciones, el código que ya existe. Cuanto más acotada la instrucción, mejor sale. Acotada no quiere decir corta; quiere decir que no deja huecos importantes que tenga que rellenar por su cuenta.
• En lo que se puede verificar, lo dejo trabajar solo: migraciones de datos, transformaciones, revisar un servidor entero buscando código muerto. Ahí gano tiempo sin arriesgar.
• Todo lo que va a producción lo reviso, llevando el control de qué se cambió y qué no. Esa fue exactamente la diferencia entre mi experimento fallido y los proyectos que salieron bien.
• Las decisiones de arquitectura las tomo yo. No por purismo, sino porque son justo las que no puedo revisar leyendo el resultado. Un componente mal escrito se ve; una estructura mal elegida no se nota hasta que ya es caro cambiarla.

Al final, la IA acelera el criterio que ya tienes, pero no te lo presta. Si no sabrías hacer lo que le estás pidiendo, no vas a poder juzgar lo que te devuelve, y encima te va a salir más caro.