Durante medio siglo, programar significó escribir.

Una persona frente a una pantalla, un cursor parpadeando, y la lenta construcción de un sistema línea por línea. Función por función. Archivo por archivo.

Esa escena empieza a desaparecer. La máquina también escribe. Completa funciones, propone tests, genera documentación, sugiere refactors. Y cuando eso ocurre, el oficio no desaparece: cambia de centro.

Porque si la IA puede producir texto ejecutable —y lo hace cada vez mejor, cada vez más rápido—, la pregunta deja de ser “quién escribe” y pasa a ser otra, más interesante y más incómoda: ¿quién decide qué merece quedarse?

La máquina ya escribe

No se trata de un futuro especulativo. Es el presente. GitHub Copilot, Claude Code, Cursor, y una constelación creciente de herramientas ya generan una parte significativa del código que termina en producción. Las sugerencias aparecen antes de que terminemos de formular la intención. El código llega antes que la idea esté del todo madura.

Esto no es menor. Durante medio siglo, producir código fue la actividad central —y más costosa— del desarrollo de software. Ahora ese costo se desploma. La máquina puede generar código funcional en segundos. Pero eso no significa que pueda hacerse cargo de su lugar en un sistema. Puede generar una función correcta que resuelva el problema equivocado. Puede proponer una solución eficiente que rompa una convención del equipo. Puede escribir un test que pase siempre y no pruebe nada.

El código llega en segundos. Saber si merece quedarse sigue costando lo mismo.

El oficio nunca fue solo escribir

Hay una tentación de leer este cambio como una pérdida. Si la máquina escribe, ¿qué le queda al desarrollador? Pero esa pregunta parte de una premisa falsa: que el oficio consistía fundamentalmente en escribir.

Nunca fue así. Comprender un sistema siempre valió más que llenarlo de líneas. Los mejores desarrolladores que conocí no eran los que escribían más rápido; eran los que entendían mejor el problema, los que nombraban bien las cosas, los que sabían cuándo no agregar código. Los que leían con atención antes de modificar. Los que protegían la coherencia de un sistema contra la presión de los plazos.

El imaginario heroico del programador como autor absoluto —solo frente a la pantalla, produciendo desde la nada— siempre ocultó que una gran parte del trabajo estaba en otra parte: entender contexto, revisar lo existente, simplificar, integrar, sostener criterios. La IA no inventó esa dimensión del oficio. Pero sí la está volviendo imposible de ignorar.

Tal vez la IA no esté creando un oficio nuevo, sino obligándonos a ver uno viejo con más claridad.

El editor aparece cuando sobra texto

En el mundo editorial, la figura del editor se vuelve imprescindible cuando hay manuscrito. Cuando hay material en bruto, versiones, exceso, desvíos posibles. Nadie necesita un editor frente a una página en blanco. Lo necesita frente a trescientas páginas que todavía no son un libro.

Algo parecido empieza a pasar con el software.

Donde antes había escasez de código —cada función costaba tiempo, cada línea era deliberada—, ahora empieza a haber abundancia. El copiloto puede generar cinco implementaciones de un endpoint en minutos. Pero alguien tiene que decidir cuál respeta la arquitectura, cuál es mantenible, cuál no introduce una dependencia innecesaria, cuál se integra con el resto sin romper la lógica del conjunto.

La abundancia de código vuelve visible una función que antes estaba disuelta dentro del acto de programar: la función editorial. Y esa función no es cosmética ni secundaria. Editar, en el sentido fuerte del término, no es corregir detalles menores ni aprobar superficialmente. Es decidir estructura. Eliminar exceso. Proteger coherencia. Ayudar a que una obra —o un sistema— encuentre su forma.

La máquina puede producir párrafos de software. Alguien todavía debe decidir si pertenecen al libro.

Aceptar no es editar

Existe un riesgo real de imaginar este nuevo rol de forma pobre: el desarrollador como alguien que mira sugerencias y aprieta accept. Que revisa superficialmente lo que el copiloto propone y lo deja pasar si compila y los tests no fallan. Eso no es editar. Eso es administrar una cola de propuestas.

El verdadero editor interviene. Reescribe. Reorganiza. Recorta. Cuestiona. A veces descarta casi todo y vuelve a empezar. No valida texto: le da forma. Protege una intención de conjunto incluso contra la facilidad de aceptar lo que suena razonable.

Un mal editor deja pasar cualquier cosa que parezca correcta. Un buen editor protege la visión incluso cuando la propuesta es tentadora. Aceptar es una acción mecánica. Editar es una responsabilidad intelectual.

¿Cuánto del código generado estamos verdaderamente editando, y cuánto simplemente estamos dejando pasar? ¿Estamos formando desarrolladores-editores o aprobadores de sugerencias? La diferencia no es sutil. La aprobación pasiva produce volumen; la edición consciente produce coherencia. Y a medida que la generación de código se acelera, esa diferencia se vuelve cada vez más costosa de ignorar.

Como escribí cuando hablamos de seniority en la era del copiloto: las disposiciones cognitivas —curiosidad, pensamiento crítico, agencia— son las que se amplifican cuando trabajás con IA. Editar bien exige las tres. Curiosidad para entender qué propone la máquina y por qué. Pensamiento crítico para evaluar si esa propuesta merece un lugar en el sistema. Agencia para intervenir, corregir y sostener una dirección propia.

Las habilidades que ganan valor

Si el oficio se desplaza hacia la edición, entonces también cambian las habilidades que pasan a ser decisivas.

Lectura crítica de código. Tal vez la habilidad más subestimada y la que más valor gana. Leer código generado con la misma intensidad con la que antes se lo escribía. No solo verificar que funciona, sino entender por qué funciona y qué implica que funcione así.

Criterio arquitectónico. La capacidad de ver más allá del fragmento. De evaluar cómo una pieza se integra en el todo. De proteger decisiones de diseño que costaron semanas de discusión contra la erosión de sugerencias que las ignoran.

Sensibilidad por coherencia. Un sistema también tiene voz. Tiene convenciones, patrones, un lenguaje de dominio. El desarrollador-editor protege esa voz contra la tendencia de la IA a producir código genérico que funciona pero no pertenece.

Capacidad de simplificación. Editar también es sacar. Podar. Resistir la tentación de dejar código solo porque ya está ahí. Douglas McIlroy lo dijo hace décadas: “The real hero of programming is the one who writes negative code.” En un mundo de generación abundante, la simplificación se vuelve un acto de diseño.

Juicio para descartar. Quizá lo más difícil: decir que no a una solución que funciona pero que no es la correcta. Que compila pero introduce deuda. Que resuelve el caso inmediato pero compromete el futuro.

Cuando producir se vuelve fácil, el juicio deja de poder esconderse detrás del esfuerzo de producción.

Editar sistemas vivos

La metáfora del editor se vuelve todavía más poderosa cuando salimos del fragmento local y miramos el sistema completo. Porque editar no es solo tocar una función o una clase. En software, editar también significa intervenir sobre sistemas vivos: productos en uso, arquitecturas en evolución, convenciones compartidas, flujos que conectan decenas de componentes.

El desarrollador-editor no solo corrige una función; también mantiene consistencia a escala, protege acuerdos del equipo, preserva legibilidad futura, evita que cada interacción con IA descomponga el lenguaje común del sistema. Es un trabajo de integración, de cuidado arquitectónico, de responsabilidad sostenida.

Y acá aparece una dimensión que no podemos esquivar: si el valor se desplaza hacia el juicio, la coherencia y la responsabilidad, ¿cómo los medimos? Las métricas centradas solo en output —pull requests mergeados, líneas de código, features entregados— empiezan a quedarse cortas. Porque el nuevo valor no está solo en cuánto código sale, sino en cuánto desorden se evita, cuánta coherencia se preserva, cuánta deuda se rechaza. ¿Cómo se mide la coherencia que alguien preservó? ¿Cómo se cuantifica la deuda técnica que un equipo no introdujo? ¿Cómo se reconoce el valor de haber descartado cinco sugerencias del copiloto antes de escribir la solución correcta? Hoy no tenemos buenas respuestas. Pero la pregunta es urgente, porque si seguimos midiendo solo producción en una era donde producir se volvió trivial, vamos a premiar exactamente lo que menos importa.

Y hay una pregunta todavía más profunda acechando detrás de esta: ¿tiene sentido seguir hablando de deuda técnica cuando escribir código se volvió barato? Hay quienes ya proponen la idea de software descartable: si regenerar es tan fácil, ¿por qué preocuparse por la deuda? Tiralo y volvé a generarlo. El argumento no es absurdo. Pero tampoco es obvio que cierre. Porque el código puede ser barato, pero las decisiones que encarna —las dependencias que introduce, las convenciones que rompe, las expectativas que crea en el resto del sistema— no necesariamente lo son. Podés regenerar una función en segundos. ¿Podés regenerar en segundos la comprensión de por qué esa función existe y qué consecuencias tiene para todo lo demás? No lo sé. Quizás en algunos casos sí, quizás en otros no. Lo que sí sé es que la pregunta merece más que una respuesta rápida. Si la deuda técnica cambia de naturaleza en esta era —o si directamente deja de ser una metáfora útil—, todavía no lo sabemos. Y actuar como si ya lo supiéramos es, en sí mismo, una forma de deuda.

¿Cómo se entrena esta capacidad editorial? ¿Cómo se diseña code review cuando el código viene en parte de modelos generativos? ¿Cómo se protege integridad conceptual —Brooks nos advirtió hace medio siglo sobre esto— en equipos donde todos generan mucho más? ¿Cómo se evita que la abundancia de código colapse la coherencia del producto?

La IA no suprime la necesidad de dirección. La vuelve más urgente.

La pregunta ya no es solo quién puede escribir software. La pregunta es quién puede darle forma, sostener su coherencia y hacerse responsable de sus consecuencias. En la era del copiloto, ese trabajo no desaparece. Se vuelve más visible, más exigente y más estratégico.

Tal vez el desarrollador del futuro escriba menos líneas, pero eso no lo hará menos importante. Lo hará responsable de algo todavía más difícil: editar sistemas vivos en colaboración con máquinas que producen cada vez más. Aunque el código venga sugerido por una máquina, el sistema sigue llevando la firma del equipo que lo aceptó.

La IA no vacía el oficio. Lo obliga a revelar su capa menos visible. Y esa capa —la del criterio, la forma, la responsabilidad— siempre fue la más importante.

¿Cómo está cambiando tu forma de trabajar con código generado? ¿Sentís que tu oficio se desplaza hacia la lectura y la edición? ¿Qué habilidades creés que ganan más valor en este nuevo contexto?