En los últimos meses, muchos desarrolladores han sentido que algo ha cambiado en el coding asistido por modelos de lenguaje. Andrej Karpathy lo describe con una claridad poco habitual: no es una mejora incremental, es un giro en el flujo de trabajo. Pasar de “yo programo y el modelo me ayuda” a “yo defino la intención y el agente ejecuta grandes acciones de código” se ha vuelto, para una parte creciente del sector, sorprendentemente normal.
Karpathy lo ilustra con una métrica simple y brutal: en cuestión de semanas, su reparto pasó de un 80% de programación manual con autocompletado y un 20% de agentes, a justo lo contrario (80% agentes, 20% retoques). Traducido: cada vez más gente está “programando en inglés”, pidiendo cambios en palabras y dedicando su tiempo a revisar, corregir supuestos y ajustar el resultado.
La idea clave: “velocidad” no es solo hacer lo mismo más rápido, es hacer más cosas
Uno de los puntos más potentes del hilo es el matiz entre speedup y expansion. Karpathy no dice únicamente “soy más rápido”; dice algo más inquietante: con agentes, acaba construyendo cosas que ni se habría planteado construir. La productividad se mide menos por minutos ahorrados y más por ambición desbloqueada.
Ahí encaja muy bien la intuición que comentas: cuando hablamos de “carencias” de los LLM, muchas veces estamos señalando “lo que probablemente va a mejorar en los próximos meses”. Y por eso mismo, lo inteligente no es discutir si hoy fallan, sino entender qué partes del trabajo cambian primero y cómo se reorganizan los roles alrededor de esos fallos.
El generalista vuelve a tener ventaja (por una razón incómoda)
Karpathy también apunta a algo que muchos han experimentado sin verbalizar: los LLM rellenan huecos de conocimiento “micro” (sintaxis, APIs, patrones comunes), lo que permite que perfiles más generalistas se metan en proyectos híbridos que antes estaban reservados a especialistas.
Tu ejemplo encaja perfecto: un pipeline de vídeo que mezcla filmmaking, montaje por línea de comandos, Inteligencia Artificial, sistemas y pedagogía. No hace falta ser élite en todo para avanzar: hace falta saber qué quieres construir, dónde están los riesgos y cómo revisar.
Pero ojo: los errores ya no son de novato, son de “junior con prisa”
Karpathy también enfría el hype. “No hace falta IDE” y “enjambres de agentes” le parecen exageraciones… por ahora. El problema ya no es que el modelo se equivoque con una coma; el problema es que asume cosas por ti y tira hacia delante sin comprobar, no gestiona bien su confusión y, si no lo vigilas, te entrega una solución larga, frágil o sobre-abstraída.
Es un recordatorio útil para entornos sysadmin y producción: la revisión cambia, no desaparece. Y en software que importa, hay que mirar “como un halcón”.
El “momento AGI” no es magia: es resistencia infinita
Otro fragmento interesante: observar a un agente insistir sin cansarse, probar variantes, encajar piezas y seguir hasta cumplir un criterio. Karpathy lo plantea como una forma nueva de “apalancamiento”: no darle instrucciones paso a paso, sino criterios de éxito, tests, restricciones… y dejarlo iterar.
Esto conecta con prácticas muy “de sistemas”: definir SLOs, health checks, pruebas, condiciones de salida. Cambia el rol humano: menos picar piedra, más diseñar el marco de control.
Y entonces llega Boris Cherny con una declaración que sube la apuesta
La respuesta más comentada no viene de un influencer cualquiera, sino de Boris Cherny, identificado en varios medios como creador de Claude Code. Su mensaje (resumido en artículos y posts que recogen la anécdota) es casi provocador: durante un mes entero no abrió un IDE, y todo lo que “envió” en ese periodo lo escribió Claude Code, con métricas de actividad que se han citado públicamente (cientos de pull requests, decenas de miles de líneas añadidas y eliminadas).
Más allá de la cifra exacta, el impacto es psicológico: la herramienta no solo ayuda, puede convertirse en la mano principal. Y eso obliga a recalibrar expectativas incluso a los primeros adoptantes, justo la idea que tú destacas: lo que hoy parece límite, mañana es baseline.
Una tabla sencilla: el cambio de mentalidad en el “coding con agentes”
| Antes (clásico) | Ahora (con agentes) |
|---|---|
| Programar es escribir código | Programar es definir intención + criterios y revisar resultados |
| El coste está en teclear y depurar | El coste se mueve a validar supuestos, pruebas y arquitectura |
| Los errores suelen ser sintácticos | Los errores suelen ser conceptuales (suposiciones incorrectas) |
| El especialista domina el terreno | El generalista puede avanzar más si sabe revisar y acotar |
| “Ir más rápido” es ahorrar tiempo | “Ir más rápido” es hacer más cosas (expansión) |
| El IDE es el centro | El IDE vuelve como torre de control (observabilidad del código) |
Lo que esto significa para un medio tech y para sysadmins
Si en desarrollo ya se nota, en sistemas se va a notar aún más por una razón: mucha parte del trabajo sysadmin es orquestación de herramientas, pegamento entre piezas y automatización repetitiva. Ahí los agentes brillan… pero también multiplican el riesgo de “automatizar mal” a gran escala.
Dos consecuencias prácticas:
- Más proyectos híbridos (infra + datos + UX + automatización + IA).
- Más necesidad de gobernanza (tests, revisiones, linting, seguridad, control de cambios), porque el volumen de código y scripts puede explotar.
Y aquí aparece el lado oscuro que Karpathy anticipa con su “slopacolypse”: más contenido, más repos, más ruido… y más difícil distinguir lo robusto de lo plausible.
