Richard Sennett, en The Craftsman, define el oficio artesanal como un diálogo entre la mano y la mente. El artesano no piensa primero y ejecuta después: piensa mientras ejecuta. La resistencia del material le devuelve información, y esa información corrige la intención. El carpintero ajusta el ángulo porque la madera se lo pide. El alfarero modifica la forma porque el barro responde. El craft no está en la mano ni en la mente: está en la conversación entre ambas.
Durante décadas, programar fue exactamente eso.
El desarrollador pensaba mientras escribía. La resistencia del código (un error de compilación, un test que fallaba, una abstracción que no encajaba) le devolvía información, y esa información corregía la intención. No había separación entre producir y juzgar. Escribir código era, simultáneamente, un acto de creación y un acto de evaluación. Las dos capas del oficio, la producción y el criterio, estaban fusionadas, inseparables, como la mano y la mente del artesano de Sennett.
Esa fusión se está rompiendo. Y lo que se revela del otro lado es más interesante de lo que parece.
Medio siglo atacando fricciones
Antes de los copilotos, hubo medio siglo de herramientas que transformaron el oficio. No marginalmente: cada una atacó una fricción concreta y el impacto fue medible.
Los lenguajes de alto nivel (Fortran, COBOL, luego C, Java, Python) atacaron la fricción de traducción entre la mente y la máquina. Capers Jones documentó mejoras de 2x a 3x en productividad medida en function points al pasar de ensamblador a lenguajes de tercera generación. No fue confort: fue una transformación del rango de problemas que un programador podía abordar en un tiempo razonable.
Git y los sistemas de control de versiones distribuidos atacaron la fricción de colaboración. Antes de Git, contribuir a un proyecto como Linux significaba enviar parches por email para que Linus los revisara manualmente. Después de Git, Linux pasó de unos 2.000 contribuidores activos a más de 15.000 (Linux Foundation, 2020). No se aceleró lo que ya existía: se habilitó un modelo de colaboración que antes era imposible.
CI/CD atacó la fricción de despliegue y validación. Los reportes DORA (State of DevOps, 2014-2023) documentan que los equipos de elite despliegan bajo demanda con lead times de menos de un día, mientras los equipos de baja performance despliegan entre una vez al mes y una vez cada seis meses. Hace quince años, desplegar era un evento. Hoy puede ser un no-evento. Esa diferencia no es solo velocidad: es un cambio en cómo se diseña, se prueba y se entrega software.
La nube atacó la fricción de infraestructura. Aprovisionar un servidor pasó de semanas a minutos. Lo que antes requería presupuesto, aprobación y un rack físico se volvió una llamada a una API.
Los IDEs modernos (pre-copilotos) atacaron la fricción de navegación y comprensión. Un estudio de Microsoft Research (Murphy et al., 2006) mostró que los desarrolladores pasaban alrededor de un 35% de su tiempo navegando código. Go-to-definition, refactoring automático y búsqueda semántica atacaron directamente esa pérdida.
Cada una de estas herramientas fue transformadora. Ninguna fue solo confort.
Pero ninguna separó las dos capas del oficio.
Con lenguajes de alto nivel, seguías pensando mientras escribías. Con Git, seguías juzgando mientras producías. Con CI/CD, la velocidad del despliegue no separaba la decisión de qué desplegar de la acción de construirlo. La mano y la mente seguían juntas. La producción y el criterio seguían fusionados en el mismo acto.
Hasta ahora.
La separación
Los copilotos son la primera herramienta que separa producción de criterio.
Hubo herramientas que generaban fragmentos: scaffolding, templates, autocompletado inteligente. Pero generaban puntos de partida o detalles triviales. Ninguna producía en el centro del acto de programar, de forma continua, a una escala que convirtiera el juicio en la actividad principal. Eso es lo nuevo.
No porque los copilotos sean más potentes que las herramientas anteriores (cada una fue potente en su dominio), sino porque atacan la complejidad accidental de forma transversal. Los lenguajes de alto nivel atacaron la traducción mente-máquina. Git atacó la colaboración. CI/CD atacó el despliegue. La nube atacó la infraestructura. Los IDEs atacaron la navegación. Cada herramienta fue un bisturí para una fricción específica.
El copiloto no es un bisturí. Es algo más amplio: absorbe la fricción de traducir intención a código, que es la fricción que atravesaba todas las demás. Escribir la función, escribir el test, escribir la documentación, escribir el boilerplate, conectar las piezas. Todo lo que antes requería la mano del artesano.
Y al absorber esa fricción transversal, produce algo que ninguna herramienta anterior produjo: por primera vez, podés juzgar sin estar produciendo al mismo tiempo. El criterio se separa de la producción. La mente se separa de la mano.
Eso suena a liberación. Pero esconde una trampa.
Lo que parece y lo que es
Hay una pregunta que no se puede eludir: ¿los copilotos atacan complejidad accidental o complejidad esencial?
Brooks distinguió ambas en No Silver Bullet (1986). La complejidad accidental es la que surge de nuestras herramientas y procesos: la sintaxis, el build system, el deployment pipeline. La complejidad esencial es inherente al problema: entender el dominio, modelar relaciones, anticipar consecuencias, decidir trade-offs.
La respuesta obvia es que los copilotos atacan complejidad accidental. Traducir intención a sintaxis, generar boilerplate, completar patrones: todo eso es fricción de herramientas, no del problema. Y es cierto.
Pero los copilotos hacen algo que ninguna herramienta anterior hizo: generan código que parece resolver problemas esenciales. Proponen arquitecturas. Sugieren modelos de datos. Recomiendan patrones de diseño. Y lo hacen con una fluidez que hace difícil distinguir “generó una solución” de “resolvió el problema.”
La complejidad esencial no se redujo. Lo que cambió es que se volvió invisible.
Antes, la fricción de producir te obligaba a pensar mientras escribías. Esa lentitud era incómoda, pero también era protectora: te daba tiempo para notar que no entendías el dominio, que el modelo no encajaba, que la arquitectura tenía un problema. La resistencia del material (para volver a Sennett) te devolvía información.
Ahora el código aparece antes de que termines de pensar. Y como compila, y los tests pasan, y se ve razonable, es fácil confundir producción fluida con problema resuelto. Un estudio de McKinsey (2023) lo cuantificó: los copilotos mejoran la velocidad de codificación entre un 20% y un 45%, pero el ciclo completo de desarrollo solo mejora entre un 3% y un 10%. La producción se aceleró. Todo lo demás, que es donde vive la complejidad esencial, apenas se movió.
La simulación es tanto el poder como el peligro del copiloto. Si traés comprensión del problema, te ayuda a explorar el espacio de soluciones más rápido. Si no la traés, te ayuda a ignorar que no la tenés.
Lo que se revela
Ahora que las capas están separadas, podemos ver con más claridad qué era qué.
Había un craft de producción: traducir lógica a sintaxis, escribir boilerplate, implementar patrones conocidos, conectar piezas. Este craft tenía valor y requería habilidad. Pero era la capa visible del oficio, la que se podía observar, medir y, eventualmente, automatizar.
Y había un craft de criterio: nombrar bien (porque nombrar es pensar), decidir qué no construir, evaluar si la solución resuelve el problema real o solo lo parece, proteger la integridad conceptual del sistema, simplificar cuando todo invita a agregar, asumir responsabilidad por las consecuencias. Esta capa siempre existió, pero estaba oculta detrás del esfuerzo de producir. Como la producción era costosa, tendíamos a confundir esfuerzo de escritura con calidad de pensamiento: si costó escribirlo, debía estar bien pensado.
Los copilotos disolvieron esa confusión. Al hacer trivial la producción, dejaron el criterio expuesto. Desnudo. Sin el velo del esfuerzo que lo protegía.
Y eso es incómodo. Porque revela quién realmente tenía criterio y quién solo tenía práctica. Revela que muchas decisiones que parecían deliberadas eran simplemente las únicas que la lentitud permitía. Revela que el oficio real, el que no se puede automatizar, es más raro y más valioso de lo que creíamos.
El craft no desapareció. Lo que desapareció es la ilusión de que el craft estaba en los dedos.
La paradoja del telar
Cada revolución industrial separó capas que antes estaban fusionadas.
El telar mecánico separó el diseño del tejido. Antes, la tejedora decidía el patrón mientras lo ejecutaba con las manos. Cada pasada de la lanzadera era simultáneamente un acto de producción y un acto de diseño. Cuando la máquina asumió la ejecución, el diseño se convirtió en una disciplina separada, visible, con sus propias reglas y su propia exigencia. No desapareció el oficio: se reveló que el oficio real nunca había estado solo en los dedos.
La imprenta hizo lo mismo con el texto. Antes del tipo móvil, el copista decidía mientras transcribía: ajustaba, omitía, reorganizaba. Cuando la copia se mecanizó, surgió la figura del editor como oficio distinto. Alguien que no produce el texto, pero que decide su forma, su estructura, su coherencia. El valor no migró de la mano a la nada: migró de la mano al juicio.
Los copilotos son el telar del código.
Separaron producción de criterio. Y al separarlas, hicieron visible lo que siempre estuvo ahí pero nunca pudimos ver con claridad: que el craft del software nunca estuvo solo en escribir líneas. Estuvo en el criterio que decidía qué líneas merecían existir.
El telar mecánico no creó mejores telas. Creó la necesidad de mejores diseñadores. El copiloto no va a crear mejor software por sí mismo. Va a crear la necesidad de mejor criterio.
Y ese criterio tiene forma concreta. Es nombrar bien, porque un nombre mal elegido contamina la comprensión de todo el sistema. Es podar: resistir la tentación de dejar código solo porque ya está ahí y compila. Es rechazar una solución que funciona pero que no es la correcta para este sistema, en este momento, con estas consecuencias. Es proteger la integridad conceptual contra la presión de aceptar lo que llegó rápido. Es leer el código generado con la misma intensidad con la que antes se lo escribía. Nada de esto es nuevo. Pero antes estaba oculto detrás del esfuerzo de producir. Ahora es lo único que queda.
Durante décadas confundimos velocidad de escritura con calidad de pensamiento. La fricción de producir ocultaba la complejidad esencial detrás de un velo de esfuerzo: si costaba escribirlo, debía estar bien pensado. Los copilotos arrancaron ese velo. Y ahora que el código aparece antes de que terminemos de pensar, la pregunta que siempre importó queda expuesta, sin escapatoria.
¿Sabemos lo que estamos construyendo?
¿Dónde sentís que tu criterio importa más ahora que la producción es barata? ¿Qué parte de tu oficio se reveló cuando dejaste de escribir todo a mano? ¿Qué decisiones que antes parecían obvias ahora descubrís que nunca lo fueron?