Hay una sensación que seguramente más de un desarrollador viene experimentando en estos meses: la inteligencia artificial nos da una velocidad que entusiasma y, al mismo tiempo, una velocidad que puede confundir. Le pedimos que genere una función, que explique un error, que arme un test, que escriba una query o que nos ayude a pensar una arquitectura, y muchas veces responde rápido. Muy rápido. El problema es que en software, como en tantas otras cosas, ir más rápido no siempre significa llegar mejor. Podemos escribir más código en menos tiempo, resolver dudas sin abrir veinte pestañas y destrabar tareas que antes llevaban horas; pero si usamos la IA sin contexto, sin revisión, sin arquitectura y sin criterio, también podemos acelerar errores, deuda técnica y decisiones que alguien va a terminar pagando en producción. Sobre eso quiero detenerme acá: no mirar la IA como enemiga ni como magia, sino como una herramienta poderosa que necesita límites, método y responsabilidad.
La IA ya entró en el día a día del desarrollo#
En lo que va del año quedó bastante claro que la inteligencia artificial dejó de ser una curiosidad para meterse en el trabajo real de muchos desarrolladores. Ya no se trata solo de preguntarle algo a un chat para que explique un concepto: hablamos de asistentes dentro del editor, autocompletado avanzado, generación de código, revisión de errores, documentación, tests, refactors, análisis de logs, ayuda con comandos y consultas SQL, entre tantas tareas que forman parte de la rutina.
La encuesta de Stack Overflow publicada en julio puso un número sobre esa sensación: el 76% de los encuestados decía que ya usaba o planeaba usar herramientas de IA en su proceso de desarrollo durante este año. No es un dato menor. Marca que la IA dejó de estar en la periferia de la conversación técnica para entrar al flujo normal de trabajo. Y desde los grandes jugadores también llegaron señales fuertes: GitHub presentó Copilot Workspace en technical preview, con la idea de pasar de una tarea expresada en lenguaje natural a un plan y luego a código, manteniendo al desarrollador en control del proceso; y OpenAI presentó o1-preview hace pocos días, una serie de modelos orientados a razonar mejor en problemas complejos, incluyendo código, matemática y ciencia. Todo eso empuja una idea potente: cada vez más, parte del desarrollo puede empezar desde una conversación. Pero una conversación no es todavía una especificación, y una respuesta rápida no es necesariamente una buena solución.
La parte buena: cuando la IA ayuda de verdad#
Sería injusto entrar al tema solamente desde el miedo, porque la IA, usada con criterio, es una herramienta excelente para desarrollar software. Sirve para destrabar a alguien que está peleando con un error poco claro, para explicar una librería, para proponer una primera versión de una función, para escribir tests o sugerir mejoras sobre un fragmento, para traducir lógica de un lenguaje a otro o para documentar eso que todos usan pero nadie escribió nunca.
También funciona como una especie de compañero de pensamiento. No porque siempre tenga razón, sino porque obliga a ordenar la pregunta: muchas veces, cuando uno intenta explicarle a la IA qué necesita, termina entendiendo mejor el problema, y eso solo ya tiene valor. La ayuda se vuelve muy concreta en cosas como armar esqueletos iniciales, generar ejemplos de uso, crear tests unitarios básicos, explicar stack traces, entender código heredado, proponer refactors chicos o acelerar la investigación sobre librerías y patrones. Para un equipo técnico todo esto puede valer mucho, sobre todo cuando se combina con experiencia, revisión y contexto real del proyecto. El problema empieza cuando confundimos asistencia con delegación total.
La IA escribe código, pero no conoce tu producción#
Una herramienta de IA puede generar código que parece correcto: nombres prolijos, patrones conocidos, explicaciones convincentes, incluso un tono seguro al responder. Pero no vive dentro de tu sistema. No conoce las decisiones históricas que llevaron a tu arquitectura actual, no sabe qué partes son frágiles, qué integración falló tres veces el mes pasado, qué servicio carga más, qué tabla no se toca sin avisarle a alguien de datos, ni qué decisión técnica responde a una restricción de negocio y no a una preferencia del equipo. Puede tener todo ese contexto si se lo damos, pero no lo trae por defecto. Y en proyectos grandes, esa diferencia es enorme.
Un código puede compilar y estar mal ubicado. Puede pasar un test y romper una regla de arquitectura. Puede resolver el caso feliz y fallar en escenarios reales, sumar una dependencia que no deberíamos arrastrar, repetir lógica que ya existe en otra capa, saltarse convenciones del equipo o funcionar perfecto en un ejemplo chico y no escalar en el sistema real. Por eso vale la pena repetirlo: la IA puede escribir código, pero todavía no se hace cargo de producción. Producción se hace cargo sola, con usuarios, carga, datos reales, integraciones, tiempos de respuesta, incidentes y gente tratando de entender qué pasó cuando algo se cae.
El riesgo de programar solo a base de prompts#
Todavía no está tan instalado el concepto de programar “por impulso”, dejándose llevar por una conversación con la IA hasta que algo funcione, pero en la práctica ya empieza a aparecer. Uno escribe un prompt, la IA devuelve código, uno prueba y falla, le pega el error, la IA corrige, vuelve a fallar, pedimos otra variante, y otra, hasta que en algún momento funciona. O parece funcionar.
Ahí aparece la trampa. Cuando ese proceso no está guiado por una idea clara, la solución termina armada por acumulación de parches conversacionales y no por diseño. Para un prototipo, una prueba rápida o un experimento personal puede alcanzar; en software de empresa, con arquitectura, equipos, integraciones y mantenimiento a largo plazo, esa forma de trabajar es peligrosa. El código generado puede inventar APIs o métodos que no existen, usar versiones incorrectas de librerías, ignorar patrones del proyecto, duplicar lógica en vez de reutilizar, resolver el problema en la capa equivocada, mezclar responsabilidades, omitir validaciones de seguridad o generar tests que prueban lo obvio y no lo importante. A veces el problema no es que la IA no sepa programar; es que no sabe qué estamos intentando construir realmente. Y si nosotros tampoco se lo explicamos bien, el resultado es esa mezcla rara entre velocidad, ilusión de avance y deuda técnica nueva.
El prompt no reemplaza al criterio técnico#
Hay una idea que para mí es central: escribir buenos prompts ayuda, pero no reemplaza saber de software. Pedirle a una IA “haceme esta pantalla”, “creame esta API” o “arreglame este error” puede funcionar en casos simples, pero cuanto más grande es el sistema, más pesa el contexto. El desarrollador sigue teniendo que entender dónde vive esa funcionalidad, qué responsabilidades tiene cada capa, qué contratos existen entre servicios, qué datos son confiables, qué reglas de negocio no se pueden romper, qué impacto tiene un cambio, y cómo se prueba, se despliega, se monitorea y se revierte si algo sale mal.
La IA ayuda en muchas de esas cosas, pero necesita dirección, y ahí el rol del programador cambia un poco. No desaparece: se vuelve más exigente en otro sentido. Antes buena parte del trabajo estaba en escribir código línea por línea; ahora, cada vez más, está también en explicar bien, revisar bien, validar bien y decidir bien. Y para revisar bien hay que saber, para decidir bien hay que entender, para validar bien hay que tener criterio. La IA puede acelerar a un buen desarrollador, pero también puede darle demasiada confianza a alguien que todavía no entiende lo que está aceptando.
Darle reglas a la IA, no solo pedidos sueltos#
Con el tiempo, una práctica que se vuelve natural es dejar de pedirle cosas sueltas y empezar a darle reglas claras. No alcanza con “agregá esta funcionalidad”; conviene explicarle qué arquitectura debe respetar, qué patrones usa el proyecto, qué convenciones seguir, qué dependencias están permitidas, qué no debe tocar, qué estilo de tests se espera, qué reglas de seguridad son obligatorias y qué archivos tiene que revisar antes de proponer un cambio.
Esto se parece bastante a algo que en software ya conocemos hace años: trabajar con especificaciones, contratos, documentación técnica, guías de arquitectura y criterios de aceptación. La diferencia es que ahora esos documentos no sirven solo para humanos: también empiezan a orientar a la IA. Y me parece una idea importante, porque si la IA tiende a completar huecos con supuestos, nuestra responsabilidad pasa a ser reducir esos huecos. Si queremos que no delire, no alcanza con pedirle “no delires”; hay que darle contexto, límites, ejemplos y reglas.
Requerimientos más estructurados, menos magia#
Tal vez uno de los aprendizajes más interesantes de esta etapa es que la IA nos vuelve a recordar algo que solemos olvidar: los requerimientos importan. Durante años muchos equipos intentaron moverse rápido con tickets pobres, descripciones vagas o historias de usuario demasiado livianas; eso ya generaba problemas entre humanos, y con IA esos problemas se amplifican. Lo vi en prácticamente todos los lugares donde aporté mi granito de arena. Si una persona interpreta mal un requerimiento, puede preguntar, discutir o apoyarse en la experiencia del negocio; la IA también puede preguntar, pero si no se lo pedimos, muchas veces completa el vacío por su cuenta.
Por eso empieza a tener sentido trabajar con piezas más estructuradas. No documentos enormes ni burocráticos, sino algo claro que indique el objetivo de la funcionalidad, el problema que se quiere resolver, el alcance y lo que queda fuera, las reglas de negocio, los criterios de aceptación, el impacto en datos y APIs, las consideraciones de seguridad, las reglas de arquitectura, los casos borde y las pruebas esperadas. No es volver a procesos pesados ni a documentos eternos que nadie lee; es entender que, si vamos a pedirle a una IA que nos ayude a construir software, tenemos que darle mejores instrucciones que un simple “hacelo”. En proyectos chicos, un prompt alcanza. En proyectos grandes, necesitamos contexto versionado, reglas y acuerdos.
La arquitectura como baranda#
Me gusta pensar la arquitectura como una baranda: no está para frenar al equipo, sino para evitar que cada uno se caiga por cualquier lado. Cuando sumamos IA al desarrollo, esa baranda se vuelve todavía más importante. Si el proyecto tiene una arquitectura clara, la IA trabaja mejor porque hay límites; si las responsabilidades están bien separadas, es más fácil pedirle cambios concretos; si hay patrones repetibles, puede imitarlos; si hay tests, puede validar; si hay documentación, entiende mejor el contexto. Pero si el proyecto ya es caótico, la IA copia ese caos muy rápido, y además lo hace con mucha prolijidad visual. Ese es un riesgo interesante: el código generado puede verse ordenado y estar conceptualmente mal integrado.
Por eso, antes de pensar en “usar más IA”, algunos equipos harían bien en preguntarse si su arquitectura está suficientemente clara, si tienen convenciones documentadas, si los módulos tienen responsabilidades entendibles, si los tests protegen el comportamiento que de verdad importa, si saben qué partes del sistema son críticas y si tienen criterios para aceptar o rechazar código generado. La IA no elimina la necesidad de arquitectura; la vuelve más necesaria.
Más código también puede ser más deuda técnica#
Uno de los efectos secundarios de la IA es que baja el costo de generar código. Suena muy bien, y en parte lo es, pero también significa que podemos generar más código innecesario, más rápido. Y en software el costo real no siempre está en escribir la primera versión: muchas veces está en mantenerla, entenderla, probarla, modificarla, operarla y corregirla cuando falla. Un equipo puede empezar a producir más pull requests, más archivos y más soluciones alternativas, pero sin revisión, estándares y criterio, ese aumento de velocidad se transforma en más superficie de mantenimiento.
La deuda técnica no aparece solo por escribir mal; también aparece por escribir de más: por duplicar lógica, por resolver rápido sin entender, por aceptar código que nadie termina de comprender, por sumar dependencias innecesarias o por dejar decisiones importantes escondidas dentro de una respuesta generada. La IA puede ser una gran aliada para reducir deuda si la usamos para refactorizar con cuidado, documentar, detectar duplicaciones, escribir tests y analizar impacto. Pero también puede crear deuda nueva si la tratamos como una fábrica automática de código sin control.
El rol del senior cambia, pero no desaparece#
A veces se plantea que la IA va a reemplazar programadores. Es probable que transforme muchos roles, no lo dudo, pero mirando el desarrollo de software real —el que vive en producción— me cuesta pensar que el criterio técnico vaya a perder importancia. Más bien lo contrario: el rol del desarrollador con experiencia se vuelve más relevante para definir buenos límites, revisar soluciones generadas, detectar errores sutiles, cuidar la arquitectura, pensar en seguridad, priorizar simplicidad, evitar sobreingeniería, enseñar al equipo a usar la IA sin depender ciegamente de ella y convertir requerimientos ambiguos en instrucciones claras.
La IA puede escribir una función, pero alguien tiene que saber si esa función tiene sentido. Puede proponer una arquitectura, pero alguien tiene que saber si encaja con el negocio, el equipo, los tiempos y la realidad del sistema. Puede generar tests, pero alguien tiene que distinguir si protegen algo importante o solo están ahí para decorar el coverage. En ese sentido, la IA no reduce la necesidad de experiencia: la cambia de lugar.
Usarla bien también es una habilidad de equipo#
Otra cosa que me parece importante es que el uso de IA no debería quedar solo en decisiones individuales. Si cada desarrollador usa una herramienta distinta, con criterios y prompts distintos y sin acuerdos comunes, el equipo empieza a trabajar desordenado sin darse cuenta. No digo controlar todo ni matar la experimentación, pero sí tener algunas conversaciones sanas: para qué tareas usamos IA, qué tipo de código no aceptamos sin revisión humana, qué información sensible no se puede pegar en una herramienta externa, cómo documentamos decisiones tomadas con su ayuda, qué nivel de test exigimos al código generado, qué reglas de arquitectura se respetan siempre y qué hacemos cuando la IA propone algo que no entendemos. La IA no debería ser una práctica clandestina dentro del equipo; debería incorporarse con responsabilidad, como cualquier otra herramienta potente.
Una forma práctica de trabajar con IA en proyectos reales#
Si tuviera que describir una manera razonable de usar IA en desarrollo, la pensaría más o menos así: primero entender el problema, después escribir el objetivo y el alcance, definir reglas de negocio y criterios de aceptación, darle a la IA contexto del proyecto y sus restricciones, pedirle una propuesta antes que código, revisar esa propuesta, recién entonces pedir la implementación, exigir tests, revisar manualmente el resultado y validarlo contra arquitectura, seguridad y operación.
Parece más lento que pedir directamente “haceme esto”, pero en la práctica puede ser más rápido si nos ahorra tres rondas de errores, código mal ubicado, decisiones incorrectas y refactors posteriores. La velocidad buena no es escribir más rápido; es llegar antes a una solución que se pueda mantener.
La IA como acelerador, no como piloto automático#
Me gusta pensar la IA como un acelerador, pero un acelerador necesita dirección, freno y alguien mirando el camino. Usada bien, mejora mucho la forma de trabajar: reduce tareas repetitivas, abre caminos, explica código, genera alternativas y nos deja más tiempo para los problemas de mayor valor. Usada como piloto automático, corremos el riesgo de dejar que tome decisiones que después no vamos a saber defender. Y en software profesional cada decisión técnica, tarde o temprano, pide explicaciones: por qué se hizo así, por qué se eligió esa dependencia, por qué este servicio llama directamente a este otro, por qué ese dato se guarda duplicado, por qué este proceso no tiene retry, por qué este endpoint no valida permisos, por qué este cambio rompió producción. La IA puede ayudarnos a construir, pero seguimos siendo nosotros los responsables de lo que integramos, desplegamos y mantenemos.
Si un equipo quiere empezar a usar IA para programar sin caer en el caos, yo arrancaría por algo bastante simple: definir reglas mínimas de uso, crear guías de arquitectura y estilo que también puedan leer las herramientas, usar archivos de contexto por proyecto, pedir propuestas antes que código, no aceptar código que nadie entiende, exigir tests útiles y no decorativos, revisar seguridad y permisos desde el inicio, medir si realmente mejora el flujo o solo genera más revisión, y documentar los aprendizajes para ajustar sobre la marcha. No se trata de frenar la IA, sino de usarla mejor, porque lo más probable es que la programación asistida no sea una moda pasajera: va a seguir evolucionando e integrándose cada vez más en editores, repositorios y pipelines.
Por eso la pregunta no es si vamos a usar IA para programar, sino cómo vamos a hacerlo sin perder calidad, criterio y responsabilidad. Puede hacernos más rápidos, ayudarnos a aprender, acompañarnos en análisis, documentación y pruebas; pero no deberíamos confundir velocidad con excelencia. El buen software no nace de escribir código rápido, sino de entender problemas, diseñar soluciones, tomar decisiones conscientes, cuidar la arquitectura, probar bien, operar con responsabilidad y aprender de lo que pasa en producción. La IA puede ser una gran compañera en ese camino, siempre que no apaguemos el criterio justo cuando la herramienta empieza a responder más rápido. Porque, al final del día, el código puede haberlo sugerido una IA, pero la responsabilidad de ponerlo en producción sigue siendo nuestra. Y esa, me parece, es la parte que conviene seguir pensando: no cuánto código más podemos generar, sino qué tipo de criterio queremos conservar a medida que la herramienta se vuelve cada vez más capaz.
Fuentes consultadas#
- Stack Overflow, “2024 Developer Survey — AI”, resultados publicados en julio de 2024 sobre uso de herramientas de IA por desarrolladores.
- GitHub, “Welcome to the Copilot-native developer environment”, 29 de abril de 2024.
- OpenAI, “Introducing OpenAI o1-preview”, 12 de septiembre de 2024.