La discusión sobre si la programación con IA impedirá la formación de experiencia es incómoda para ambos bandos. No dice que los agentes de código sean inútiles ni que todos deban volver a escribir plantillas a mano. Pregunta algo más práctico: qué ocurre con el criterio técnico cuando empresas que ya usan Claude Code, Cursor, Codex, herramientas tipo Copilot, Gemini CLI u OpenCode delegan parte del trabajo que antes formaba ese criterio.

Desarrollador equilibrando un agente de código con arquitectura, pruebas y revisión

El detonante reciente fue una discusión en Hacker News sobre el ensayo de Lars Faye “AI Coding will Prevent Expertise”. La idea central es la pérdida de fricción cognitiva: esa resistencia de depurar, leer documentación, equivocarse y comprender por qué una solución funciona. El debate prendió porque muchas organizaciones ya viven el problema. La IA produce más código, tickets, notas de diseño y comentarios de revisión de los que el equipo puede entender con calma.

El punto fuerte del argumento

Faye habla de la paradoja del orquestador experto. Quienes más ganan con los agentes suelen ser ingenieros con experiencia. Detectan una mala abstracción, una API inventada, una migración escondida o un cambio difícil de mantener. Hacen mejores preguntas porque ya tienen una intuición de la respuesta correcta.

El problema aparece con los principiantes. Se les entregan herramientas que requieren dirección experta antes de que hayan construido esa base. El agente puede hacerlos parecer productivos, pero puede ocultar lagunas: cómo fluye la información, por qué existe una frontera, qué demuestra una prueba y cuándo un parche pequeño es más seguro que una refactorización amplia.

No se trata de celebrar el sufrimiento. Parte de la fricción era desperdicio; otra parte era aprendizaje. Si la IA elimina ambas capas, la empresa puede ganar velocidad visible y perder comprensión acumulada.

Por qué el debate importó

Un grupo en Hacker News comparó la IA con compiladores, IDE, autocompletado y Stack Overflow. La profesión siempre ha delegado trabajo manual. Otro grupo respondió que la IA puede quitar no solo escritura, sino razonamiento. Un compilador no entrega una arquitectura completa; Stack Overflow daba fragmentos que había que integrar. Un agente puede generar un diff convincente, explicación y pruebas en una pasada.

Ambas posiciones tienen razón parcial. Quitar trabajo de bajo valor es bueno. Quitar bucles de aprendizaje y verificación es peligroso. La pregunta no es si la IA pertenece al desarrollo, sino qué bucles conserva el equipo: lectura de diffs, diseño explícito, pruebas relevantes y responsabilidad humana.

La trampa empresarial

Las compañías tienden a medir adopción por volumen: más pull requests, tickets cerrados más rápido, más pruebas generadas. Esas métricas solo sirven junto a señales de calidad. Un equipo puede generar más código del que puede revisar y mantener. Entonces la productividad aparente se convierte en deuda de comprensión.

El mensaje “si programas a mano eres lento” es especialmente dañino. Empuja a los ingenieros a abandonar tareas que protegen el producto: cuestionar requisitos, leer el diff, rastrear casos límite, rechazar cambios demasiado amplios o preguntar si una función debe existir.

También crece el ruido alrededor del código. Product managers generan tickets extensos; ingenieros generan notas largas; herramientas de revisión generan comentarios. El equipo termina filtrando artefactos que suenan precisos pero no siempre representan decisiones reales.

Cómo proteger a los juniors

Un senior puede usar un agente como compañero incansable porque sabe discutir con él. Un junior puede usarlo como máquina de respuestas. La diferencia no es disciplina moral, sino conocimiento previo.

Un flujo sano exige que el agente explique antes de codificar: describir el sistema, identificar restricciones, proponer opciones, hacer preguntas y decir qué pruebas importan. Después el humano implementa parte del cambio o predice el diff antes de aceptarlo. La meta es convertir la IA en tutor y revisor, no en dispensador de parches.

Los equipos deberían conservar práctica directa: depurar sin IA, leer código desconocido, escribir una función pequeña desde cero y defender un diseño en revisión. No son rituales nostálgicos. Son el entrenamiento que permite evaluar al agente.

La IA también puede enseñar

Usada bien, la IA acelera aprendizaje. Puede explicar un módulo heredado, comparar opciones de base de datos, sugerir casos de prueba o criticar una estrategia de refactorización. Eso es valioso cuando la alternativa es quedarse bloqueado.

La diferencia está en la consigna. “Escribe la función” produce un resultado. “Explícame el sistema, pregunta lo ambiguo, propón alternativas y enumera riesgos” produce aprendizaje. Lo mismo vale en análisis, legal, marketing o soporte: la IA genera artefactos más rápido de lo que las personas pueden validarlos. Sin conocimiento de dominio, una respuesta pulida puede ser más peligrosa que una respuesta lenta.

¿Hay que leer todo el código generado?

El argumento de Adam Tornhill sobre controlar la “máquina de incertidumbre” aporta equilibrio. Quizá no haga falta leer cada línea con la misma intensidad. La ingeniería ya confía en bibliotecas, compiladores y bases de datos sin revisarlos por completo.

Pero la confianza selectiva necesita límites: contratos claros, pruebas fuertes, observabilidad, bajo radio de impacto e invariantes arquitectónicos conocidos. Alguien debe saber cuáles son esos invariantes. Si nadie puede explicar por qué el cambio es seguro, las pruebas verdes no bastan.

La revisión debería depender del riesgo. Un cambio visual aislado no es igual que autenticación, pagos, migraciones, concurrencia o seguridad. El código generado por IA no merece sospecha mágica, pero sí propietario humano.

Auto mode y autonomía

La discusión sobre Claude Code auto mode muestra por qué esto es urgente. Menos interrupciones es cómodo, pero cuanto menos pregunta el agente, más importante es definir el entorno antes. Qué directorios puede tocar, qué comandos puede ejecutar, si puede instalar dependencias, cambiar CI, tocar migraciones o modificar archivos generados.

La autonomía sin política se convierte en confianza por cansancio. Un buen flujo obliga al agente a investigar, escribir plan, formular dudas, esperar aprobación en acciones riesgosas y entregar cambios pequeños. Así se elimina trabajo repetitivo sin eliminar juicio.

Política práctica

Cada cambio asistido por IA necesita un dueño humano capaz de explicar intención, riesgos y rollback. Para trabajo no trivial conviene una nota de diseño: alcance, pruebas, migración y riesgos operativos. Los grandes refactors invisibles deberían prohibirse salvo que exista una estrategia clara de revisión.

Las pruebas son obligatorias, pero no sustituyen la revisión. Hay que buscar APIs alucinadas, abstracciones innecesarias, dependencias nuevas, cambios de estado ocultos y código que el autor no puede explicar. También conviene hacer ejercicios sin IA para mantener depuración, lectura y diseño.

Las métricas deben incluir defectos escapados, rollbacks, carga de revisión, mantenibilidad y tiempo hasta comprender un cambio. Si sube el volumen de PR pero también suben deuda e incidentes, la adopción no está funcionando.

Posición madura

La respuesta no es prohibir agentes de código. Es tratarlos como una decisión de gestión de ingeniería. Son útiles cuando reducen carga mecánica y amplían exploración. Son peligrosos cuando sustituyen el criterio sobre arquitectura, riesgo y mantenimiento. El desarrollador del futuro puede escribir menos código bruto; no puede dejar de entender sistemas y responsabilidades.