"Nunca usaré IA para programar": el argumento que sigue sin desaparecer

Cada cierto tiempo reaparece en Hacker News una variante del mismo argumento: la IA no debería tener lugar en el flujo de trabajo de un programador. El último ejemplo llega de la mano de un artículo titulado "I Will Never Use AI to Code", publicado el 9 de mayo de 2026. No acumuló puntos ni comentarios en el momento de su indexación, pero eso no lo hace irrelevante. Al contrario: representa una posición que muchos profesionales sostienen en privado y rara vez articulan en público.

Merece atención precisamente porque va a contracorriente. En un ecosistema donde Claude Code, los servidores MCP y los subagentes se han convertido en parte habitual del trabajo de muchos equipos de ingeniería, alguien que dice «no, gracias» de forma razonada obliga a hacer explícitas cosas que solemos dar por supuestas.

El argumento de fondo

El artículo original —cuya lectura recomendamos directamente— defiende que delegar escritura de código o texto a una IA supone externalizar precisamente las capacidades que un profesional debe ejercitar para no perderlas. El razonamiento no es nuevo, pero tampoco está agotado. La versión más sólida del argumento tiene dos patas:

• Degradación cognitiva por desuso. Si un modelo genera el código y tú lo revisas, estás entrenando una habilidad distinta a la de escribirlo. Con el tiempo, la brecha entre ambas puede crecer sin que lo notes.
• Comprensión superficial del output. Aceptar código generado sin entenderlo al detalle introduce deuda técnica de un tipo difícil de auditar: no sabes lo que no sabes que no sabes.

Son objeciones legítimas. No son irrebatibles, pero sí merecen una respuesta honesta en lugar de un descarte rápido.

Qué responde la práctica habitual

Quienes trabajan a diario con herramientas como Claude Code suelen distinguir entre usos que sustituyen razonamiento y usos que lo amplían. Hay una diferencia operativa entre pedirle a un subagente que refactorice un módulo complejo mientras tú defines los criterios y revisas el resultado, y pedirle que escriba una función de la que no tienes ni idea de cómo debería funcionar.

La crítica del artículo apunta con más precisión al segundo caso. Y en ese caso, tiene razón.

Donde el argumento se debilita es en la asunción implícita de que cualquier uso de IA en el código cae necesariamente en esa categoría. En la práctica, el nivel de supervisión, el dominio previo del programador y el tipo de tarea determinan si el resultado refuerza o erosiona la comprensión. Un desarrollador senior que usa Claude Opus 4.7 para explorar alternativas de diseño arquitectónico está haciendo algo cualitativamente distinto a un junior que acepta sin leer lo que sugiere el autocompletado.

Para quién importa este debate

Este tipo de artículos tiene un público más amplio de lo que sugiere su escaso tráfico inicial. Es relevante para:

• Equipos con desarrolladores junior, donde la adopción acrítica de herramientas de generación puede sustituir el aprendizaje en lugar de acelerarlo.
• Educadores y bootcamps, que están rediseñando currículos y necesitan argumentos en ambas direcciones para tomar decisiones informadas.
• Ingenieros de software que trabajan solos y no tienen la fricción natural del code review para detectar código que no entienden bien.
• Cualquiera que use Claude Code y no se haya hecho explícitamente la pregunta: ¿estoy usando esto para pensar mejor o para pensar menos?

Lo que el debate suele omitir

La discusión pública sobre IA y programación tiende a polarizarse entre adopción entusiasta y rechazo categórico. Lo que falta casi siempre es granularidad: qué tipo de tarea, con qué nivel de supervisión, en qué fase del proyecto, con qué perfil de desarrollador.

El artículo en cuestión elige el rechazo total como posición, lo cual tiene la virtud de la coherencia pero el coste de ignorar esa granularidad. «Nunca» es una política fácil de defender y difícil de justificar en términos absolutos.

---

Desde EP, la posición que nos parece más útil no es ni el entusiasmo sin fricción ni el rechazo por principio. Es la que obliga a cada profesional a ser explícito sobre qué delega, por qué y con qué supervisión. Ese ejercicio, incómodo como es, vale más que cualquier postura tomada de antemano.