Durante años, hablar de asistentes de código era hablar de autocompletado: sugerencias pequeñas, útiles, pero limitadas. En las últimas semanas, sin embargo, una conversación encendida en torno a Andrej Karpathy (investigador y divulgador en IA) y la respuesta de Boris Cherny (responsable de Claude Code en Anthropic) ha cristalizado una idea que muchos ingenieros venían notando en silencio: la programación está entrando en una fase distinta.

No se trata solo de “hacer lo mismo, pero en menos tiempo”. El salto real —el que cambia hábitos— es que el trabajo se reescala. Donde antes una persona se reservaba para tareas “que merecen la pena”, ahora se abren proyectos que, simplemente, no se habrían intentado. No por falta de visión, sino por falta de horas, energía o conocimientos de áreas periféricas.

Del 20 % al 80 %… en cuestión de semanas

Karpathy describe una transición que suena exagerada hasta que se ha vivido: pasar de un flujo dominado por la escritura manual (con algo de autocompletado) a uno en el que los agentes hacen la mayor parte del trabajo, y el humano queda como editor, supervisor y responsable del resultado final. La sensación es ambivalente: potencia enorme… y un pequeño golpe al ego. “Programar en inglés” —dar instrucciones y criterios de éxito en lugar de teclear cada línea— resulta extraño al principio, pero engancha cuando empieza a funcionar.

Esa transición, además, no se apoya en “magia”. Se apoya en algo muy práctico: acciones grandes sobre una base de código (refactors completos, cambios transversales, instrumentación, tests) que antes requerían una concentración sostenida y una paciencia de hierro.

Velocidad vs expansión: la distinción que lo explica todo

La parte más interesante del debate no es si se gana tiempo (que se gana), sino en qué se convierte ese tiempo. Karpathy lo resume con una idea que muchos reconocen: el efecto principal no es correr más, sino ampliar el mapa. Con asistentes capaces de rellenar huecos técnicos, perfiles generalistas se atreven con tareas que mezclan disciplinas: pipelines de vídeo, automatización por línea de comandos, integración de modelos, despliegues, documentación, incluso parte pedagógica o de producto.

En otras palabras: el cuello de botella ya no es siempre “saber escribir código”, sino saber qué construir, cómo validarlo y qué no permitir.

Los modelos siguen fallando, pero fallan “mejor” (y eso es peligroso)

Aquí aparece la advertencia central: quienes celebran el “no hace falta IDE” o los “enjambres de agentes” quizá van demasiado rápido. Karpathy insiste en que los modelos todavía cometen errores, pero han cambiado de forma: ya no son faltas de sintaxis fáciles de detectar, sino equivocaciones conceptuales sutiles, parecidas a las de un desarrollador junior con prisa.

Hay patrones reconocibles:

• Asumen cosas que nadie les pidió asumir.
• No gestionan bien la confusión: no preguntan, no resaltan inconsistencias, no plantean trade-offs.
• Tienden a sobrecomplicar: más abstracciones, más capas, más líneas.
• Dejan “restos”: código muerto, comentarios tocados sin necesidad, cambios colaterales.

La conclusión no es “no usar agentes”. Es usarles con reglas: tests, revisiones, límites de alcance, y una mentalidad de inspección constante. En software que importa, el humano no desaparece: cambia de función.

“Me tengo que recordar que Claude puede hacerlo”

La respuesta que ha dado más gasolina a la conversación llega desde dentro de Anthropic. Boris Cherny, creador y responsable de Claude Code, comentó que esa sensación de estar re-aprendiendo capacidades del modelo le ocurre “la mayoría de semanas”. Su ejemplo es revelador: ante una fuga de memoria, su impulso fue el de siempre (profiler, reproducir, examinar a mano). Un compañero, en cambio, pidió al agente un heap dump, lo analizó y sacó un PR “a la primera”.

Cherny fue aún más lejos al describir una rutina que suena a ciencia ficción para el desarrollo tradicional: periodos en los que no abre el IDE, y una cadencia de decenas —y después cientos— de PRs en poco tiempo, con el agente escribiendo el código y el humano operando el timón. Más allá del titular, el mensaje de fondo es otro: el hábito mental pesa. Quienes vienen “sin memoria histórica” de modelos peores (nuevos empleados o recién graduados) a veces explotan mejor las capacidades actuales porque no cargan con límites aprendidos.

La nueva ventaja competitiva: ser buen editor, no solo buen autor

Si el LLM escribe, ¿qué distingue a los mejores? La discriminación. Leer con criterio, detectar supuestos ocultos, forzar pruebas, simplificar. La habilidad se desplaza de “generar” a “evaluar”. Karpathy incluso apunta un efecto secundario incómodo: la atrofia. Si se escribe menos a mano, la musculatura de teclear soluciones se debilita, aunque la capacidad de revisar se mantenga o incluso mejore.

Este desplazamiento reabre una pregunta antigua con un giro nuevo: ¿qué pasa con el “ingeniero 10x”? Si las herramientas amplifican a todo el mundo, podría reducirse la distancia… o podría aumentar, si los mejores son quienes dominen el arte de dirigir agentes, definir criterios, diseñar arquitectura y exigir limpieza.

2026 y el “slopacolypse”: cuando el problema ya no es producir, sino filtrar

Karpathy lanza una predicción con tono casi inevitable: si ya es fácil generar código, también lo será generar documentación, artículos, repositorios, papers, vídeos y ruido. Un “slopacolypse” —una avalancha de contenido mediocre— que afectaría a GitHub, newsletters, redes y, en general, a cualquier superficie digital.

Esto no es un detalle cultural: es un problema operativo. En un mundo de exceso, la ventaja será curar, verificar y mantener estándares. En equipos de software, eso se traduce en procesos más exigentes: linters, pruebas, observabilidad, revisión de seguridad, control de dependencias, políticas de merge y trazabilidad real de cambios.

Lo que viene: menos tecleo, más dirección… y más ambición

La lectura más útil del hilo quizá no es la nostalgia ni la euforia, sino la reinterpretación de las “carencias” como roadmap: lo que hoy falla —aclarar dudas, discutir alternativas, frenar suposiciones, simplificar— es justo lo que mejorará en los próximos meses. Y cuando mejore, el cambio no será solo cuantitativo, sino cualitativo: proyectos más grandes, equipos más pequeños, ciclos más cortos.

Aun así, hay una regla que se mantiene: cuando el software importa, alguien tiene que hacerse responsable. La IA puede escribir mucho código. Pero la responsabilidad, el criterio y la apuesta estratégica siguen siendo humanos. Por ahora, la revolución no reemplaza al ingeniero: lo empuja a convertirse en director de orquesta.

vía: Karpathy pone palabras al “cambio de fase” del coding con LLM