Hay una frase que se repite en cualquier conversación sobre desarrollo asistido por IA: "escribe código sorprendentemente bien". Es cierta, y también es la parte menos interesante del fenómeno. Lo que cambia de verdad no es la velocidad de tecleo — es que el trabajo del desarrollador deja de parecerse a programar y empieza a parecerse a dirigir a alguien más.
No es una metáfora bonita. Es literal, y se nota en los mismos hábitos que exige dirigir a una persona: revisar el trabajo antes de asumir que está bien, dar contexto explícito en vez de esperar que se adivine, y desconfiar exactamente lo suficiente como para verificar, no tanto como para no delegar nada.
Antes de escribir, hay que leer lo que ya existe
El primer instinto equivocado es pedirle a la IA que resuelva un problema desde cero. El instinto correcto es primero hacer que lea el código existente y replique el patrón ya establecido. En un proyecto real, antes de construir una funcionalidad nueva, el paso que más tiempo ahorra no es escribir la funcionalidad — es revisar cómo se implementó la funcionalidad más parecida que ya existe en el mismo proyecto: su controlador, sus rutas, sus permisos, el nombre de sus variables. Copiar ese patrón deliberadamente produce código consistente con el resto del sistema. Improvisar una solución "elegante" y distinta produce una isla de estilo que alguien tendrá que mantener después, sin entender por qué es diferente.
La IA puede fallar de formas que un compilador nunca fallaría
Un compilador, cuando algo está mal, se detiene y avisa. Un asistente de IA, cuando algo sale mal, puede producir un resultado que se ve perfectamente bien y no serlo. El ejemplo más claro no viene de generar código, sino de mover datos: al transferir un archivo grande codificado en una sola línea de texto a través de una conversación, el contenido llegó corrupto — mezclado, con caracteres rotos — sin ningún mensaje de error visible. La página seguía existiendo, el servidor respondía, nada gritaba que algo estaba mal. Solo al revisar el log de errores del servidor apareció la causa real: un error de sintaxis en un punto específico del archivo.
La lección no fue "ten cuidado al copiar texto". Fue más específica: cualquier transferencia de contenido generado por IA hacia un sistema en producción necesita una forma de verificar que lo que llegó es exactamente lo que se envió — comparar un checksum antes y después, no solo confiar en que "se copió bien". Esa verificación se volvió un paso estándar, no una excepción.
Las restricciones del sistema importan más que la solución "ideal"
Pedirle a un asistente de IA que resuelva un problema sin decirle las restricciones reales del entorno es la forma más común de terminar con una solución técnicamente correcta e inutilizable. Un ejemplo concreto: al construir un editor de texto enriquecido para un panel de administración, la solución más simple habría sido cargar la librería del editor desde un CDN público — es lo que sugeriría cualquier tutorial genérico. Pero ese proyecto tenía una política de seguridad de contenido (CSP) que bloqueaba explícitamente los CDNs externos de scripts, por una razón de seguridad ya decidida de antemano. La solución correcta no era la más simple — era empaquetar la librería con el sistema de build ya existente en el proyecto, como parte del mismo pipeline que ya construía el resto del JavaScript del sitio.
Ese tipo de restricción rara vez está escrita en un solo lugar obvio. Dirigir bien a un asistente de IA significa, antes de aceptar su primera propuesta, preguntarse qué restricción del entorno real podría estar ignorando — y revisarla activamente, en vez de descubrirla cuando algo se rompe en producción.
Dar permiso de alcance acotado, no acceso total
Dirigir un equipo también implica decidir cuánto poder de decisión le das a cada persona según su rol. Lo mismo aplica al construir sistemas donde un asistente de IA va a operar de forma recurrente: no toda cuenta necesita el mismo nivel de control. Al diseñar un flujo donde un colaborador de IA redacta contenido de forma regular para revisión posterior, la decisión de diseño no fue solo "qué puede crear", sino específicamente "qué puede publicar sin supervisión" — y la respuesta fue: nada. Puede crear y dejar listo, pero el cambio de estado a "publicado" quedó reservado a un rol distinto, verificado tanto en la interfaz como del lado del servidor, para que ningún atajo técnico pudiera saltarse esa aprobación.
Ese tipo de decisión no es un detalle de permisos menor. Es exactamente la misma pregunta que se hace al delegar responsabilidad a una persona nueva en un equipo: ¿qué puede decidir sola, y qué necesita una segunda revisión?
La habilidad que realmente se vuelve escasa
Nada de esto reduce la importancia de saber programar — la reduce, sí, frente a otra habilidad que se vuelve más escasa: describir con precisión qué problema se está resolviendo, qué restricciones son innegociables, y qué patrón ya establecido conviene seguir en lugar de improvisar uno nuevo. Un desarrollador que delega la escritura pero no delega el criterio termina revisando y dirigiendo constantemente. Uno que delega ambos termina con un sistema que funciona por casualidad, hasta que deja de funcionar.
Conclusión práctica
La IA multiplica la capacidad de quien ya sabe qué preguntar, qué verificar y qué restricciones no se pueden ignorar. No sustituye ese criterio — lo pone a prueba con más frecuencia, porque genera resultados plausibles mucho más rápido de lo que antes se generaban resultados incorrectos.
Antes de medir cuánto código produjo un asistente de IA en un proyecto, mida cuántas veces tuvo que corregirse una suposición equivocada — esa cifra dice más sobre el criterio del equipo que sobre la herramienta.