Programar con IA acelera lo que ya sabes hacer (y disfraza lo que no)
Empecé a utilizar la IA como acompañamiento en mi proceso de programación en 2022, con el lanzamiento al público de ChatGPT, y comencé a usar Codex en 2025, y no lo hice 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í una cosa concreta: que desarrollara componentes nuevos respetando la lógica y el estilo de los míos.
Con la distancia, creo que ese encuadre fue lo que hizo que funcionara. Y también lo que me enseñó dónde deja de funcionar.
Desde entonces uso Codex y Claude, y este artículo es lo que he sacado en limpio: dónde me han devuelto horas, dónde me hicieron perderlas, y por qué la diferencia entre las dos cosas casi nunca está en la herramienta.
🧩 Por qué “respeta lo que ya está” cambia el resultado
Pedirle a un modelo que escriba un componente de cero es pedirle que invente convenciones: cómo nombra las cosas, cómo estructura los estilos, dónde pone la lógica. Y va a inventar algo razonable, que no es lo mismo que algo tuyo.
Cuando le das un proyecto con criterio ya establecido, la tarea cambia de naturaleza. Ya no está decidiendo: está extendiendo un patrón. Y extender un patrón que existe es algo que hace extraordinariamente bien.
El resultado fue una optimización de tiempo maravillosa. No porque escribiera código que yo no sabía escribir, sino porque escribió el código que yo iba a escribir de todos modos, y me dejó a mí las decisiones.
Esa distinción va a volver al final del artículo, porque es toda la historia.
📊 El mejor uso resultó no ser escribir componentes
Lo que más me ha ayudado no es lo que esperaba. Es el trabajo con datos.
En proyectos reales, muchas veces el punto de partida no es una base de datos: es un .csv que alguien exportó de otro sistema, o un .xlsx con hojas, colores y celdas combinadas que sirvieron para algo alguna vez.
Ese material hay que entenderlo antes de poder migrarlo. Qué columnas hay de verdad, cuáles son la misma cosa escrita de dos maneras, dónde están los duplicados, qué campos son en realidad una relación disfrazada de texto.
Ahí la IA ha sido enormemente útil: analizar esos archivos, ayudarme a comprender los datos y convertirlos a .json para después migrarlos a bases de datos reales, optimizando los modelos y normalizando por el camino.
Y creo que hay una razón de fondo para que funcione tan bien justo ahí: es un trabajo tedioso, mecánico y perfectamente verificable. Cuando el resultado se puede comprobar —los registros cuadran o no cuadran, las claves resuelven o no resuelven— el riesgo de que algo se cuele es bajo. Eso lo convierte en el terreno ideal.
🔍 200 GB que nadie había leído
El segundo uso que me ha dado más valor es de otra naturaleza, y no tiene nada que ver con escribir código: es leerlo.
Me tocó revisar servidores con del orden de 200 GB de archivos buscando código obsoleto o peligroso. Ese es un tipo de trabajo que, hecho a mano, no es difícil: es inabarcable. Nadie se lee 200 GB. Lo que haces en la práctica es buscar por patrones que ya sospechas, lo que significa que solo encuentras lo que ya ibas buscando.
Con IA encontré vulnerabilidades importantes que de otra manera me habrían llevado horas localizar — y, sobre todo, corregir sin romper nada más, que en un sistema heredado es la mitad difícil del problema.
Me parece el caso de uso más subestimado de todos. No se habla de él porque no produce nada nuevo ni luce en una captura de pantalla: produce comprensión de algo que ya existía y que nadie tenía tiempo de mirar. Y en código heredado, eso es exactamente lo que falta.
Un matiz importante, porque aquí el riesgo es real: lo que salga de ahí es una lista de sospechas, no un dictamen. Cada hallazgo hay que confirmarlo mirando el código, y cada corrección hay que entenderla antes de aplicarla. Ir a ciegas en algo así es cambiar 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 por completo por el “vibe coding”: pedir cosas y esperar a ver qué sale, sin dirigir, sin revisar a fondo, confiando en que el conjunto se sostenga solo.
No salieron cosas buenas ni funcionales en un plano real. Y no es que produjera basura evidente. Ese es justo el problema.
Sin instrucciones claras y concretas, el modelo “imagina” cosas que en teoría funcionan pero que no aguantan producción. Compila, se ve bien, tiene sentido si lo lees por encima. El fallo no está en la superficie: está en las decisiones que tomó por ti mientras rellenaba los huecos que dejaste en la instrucción.
Un error obvio lo detectas y lo arreglas en dos minutos. Uno plausible entra al repositorio y se queda.
Ahora bien, la conclusión no es que la herramienta no sirva. Es lo contrario, y por eso el experimento me pareció valioso: usadas con cuidado y con un seguimiento estricto de lo que se hace y lo que no, se pueden crear cosas impresionantes. La diferencia entre los dos resultados —el desastre y lo impresionante— no fue el modelo. Fue cuánto criterio puse yo en medio.
🏗️ Colocar componentes no es diseñar un sistema
Aquí está lo que de verdad aprendí, y es la parte que me gustaría que se llevara alguien que empieza.
No es lo mismo poner componentes —gráficas, botones, menús— y ordenarlos de la forma que sea, que diseñar un dashboard real, funcional y escalable.
Parecen la misma tarea. Visualmente producen lo mismo: una pantalla con sus tarjetas, sus gráficas y su menú lateral. Puedes pedirle a un modelo cualquiera de las dos cosas con casi las mismas palabras, y en las dos te va a devolver algo que se ve bien.
Pero la segunda incluye decisiones que no se ven en la pantalla:
- Qué datos se cargan de golpe y cuáles bajo demanda, cuando la tabla crezca 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.
Ninguna de esas preguntas aparece en la captura de pantalla. Todas aparecen seis meses después.
Y 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.
No es que la IA se equivoque más de la cuenta. Es que tú no puedes evaluar lo que te devuelve. Y sin evaluación, lo que estás haciendo no es programar con ayuda: es aceptar propuestas a ciegas y llamarlo velocidad.
La deuda técnica que genera esto no aparece el primer día. Aparece cuando toca añadir la funcionalidad que nadie previó, y descubres que la estructura sobre la que estás construyendo se eligió sola.
💳 La parte económica de la que nadie habla
Hay una consecuencia de todo esto que me parece la más práctica del artículo, y casi no la veo mencionada: el consumo no es el mismo para todo el mundo.
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. Y no porque escriba peores prompts —que también—, sino por algo más de fondo: cada iteración que no sabes evaluar es una iteración que vas a repetir.
Sin criterio, el ciclo es pedir, mirar, no saber si está bien, pedir otra vez. Con criterio, el ciclo es pedir algo acotado, revisar, corregir el rumbo en una frase, seguir. Uno cuesta cinco intentos y otro cuesta uno.
Por eso la habilidad que hace rentable esto no es solo hacer buenos prompts. Es programar, diseñar y aterrizar ideas: saber qué estás pidiendo, reconocer cuándo lo que llega ya sirve, y detectar cuándo se ha desviado antes de gastar tres iteraciones más.
Dicho de otro modo: no dependes completamente de la herramienta, y por eso te sale barata. Es un complemento de ti, de tus habilidades — y el rendimiento de cada crédito es proporcional a lo que tú aportas.
Es, además, la respuesta honesta a la pregunta de si esto sustituye a alguien: el que más provecho le saca es justo el que menos lo necesita.
🧭 Cómo los uso hoy
Sobre Codex y Claude, la verdad es que no tengo un reparto estricto: uso los dos para refactorizar y crear código, tanto en backend como en frontend. Lo que sí tengo claro es el método, y 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 el resultado — y “acotada” no significa corta, significa que no deja huecos importantes por rellenar.
Los suelto enteros en lo verificable. Migraciones de datos, transformaciones, rastrear un servidor entero buscando código muerto. Tareas donde el resultado se comprueba. Aquí gano tiempo sin asumir riesgo.
Reviso todo lo que toca producción, con seguimiento estricto de qué se cambió y qué no. Es la diferencia literal entre mi experimento fallido y los proyectos que sí salieron bien.
Las decisiones de arquitectura las tomo yo. No por purismo: porque son justamente las que no puedo revisar leyendo el resultado. Un componente mal escrito se ve. Una estructura mal elegida no se ve hasta que ya es cara de cambiar.
💡 Para llevarte
- Meterle un proyecto que ya existe, con criterio ya tomado, da mucho mejor resultado que pedirle que invente desde cero. Extiende patrones muy bien; inventarlos es otra cosa.
- Los dos mejores usos que le he encontrado no son escribir interfaz: son entender y migrar datos, y leer código que nadie tiene tiempo de leer. Tedioso, mecánico y verificable es su terreno.
- El vibe coding puro no me dio nada aprovechable. Con seguimiento estricto, las mismas herramientas dan resultados impresionantes. La variable no es el modelo.
- Las instrucciones vagas no producen errores evidentes; producen código plausible, que es el que se queda.
- Colocar componentes y diseñar un sistema se parecen en la captura de pantalla y no se parecen en nada seis meses después.
- Y lo más importante: la IA acelera el criterio que ya tienes, no te lo presta. Si no sabrías hacer lo que estás pidiendo, no vas a poder juzgar lo que recibes — y además te va a costar más caro.
