Andrej Karpathy, cofundador de OpenAI, dijo esta semana que no escribe código desde diciembre de 2025.
Yo lo leí y pensé: yo hice exactamente eso hoy.
Esta semana construí un plugin de WordPress completo — LeanAutoLinks — usando un equipo de 6 agentes IA coordinados con Agent Teams de Claude Code. El plugin procesa 16,000+ posts y genera internal links en 90 segundos. Los plugins existentes que encontré en el mercado tardaban minutos, bloqueaban el servidor o simplemente no funcionaban a esa escala.
No escribí una sola línea de PHP.
Lo que sí hice fue diseñar roles, definir métricas, establecer reglas de autonomía y orquestar el equipo. Eso es exactamente lo que Karpathy describe cuando dice que pasó de programador a director de agentes.
Este post es el framework completo que usé. No teoría. Lo que funcionó.
El Cambio que Karpathy Describe (y Por Qué Importa)
Andrej Karpathy no es un influencer de IA. Es uno de los investigadores más serios del campo: cofundador de OpenAI, exdirector de IA en Tesla, creador de cursos de deep learning que usamos en universidades de todo el mundo. Cuando habla, vale la pena escuchar.
Lo que dijo esta semana fue contundente:
«Yo antes hacía el 80% del código manualmente y delegaba el 20% a la IA. Ahora es al revés: los agentes hacen el 80% y yo el 20%. Y sigo sin saber exactamente cuándo se dio ese cruce.»
Usó la frase «state of psychosis» para describir lo que siente un individuo que ahora puede construir lo que antes requería un equipo entero. No porque sea inestable — sino porque la escala de lo que es posible rompe las intuiciones previas sobre cuánto esfuerzo requiere hacer cosas.
El Economic Times reportó que Karpathy pasa ahora horas literalmente dirigiendo agentes IA en lugar de escribir código. No es metáfora. Es su workflow real.
Y Forbes fue más directo: los junior developers están pagando el precio. Cuando alguien con el background de Karpathy puede orquestar equipos de agentes para producir código de calidad, ¿qué pasa con el desarrollador que acaba de salir de un bootcamp y sabe hacer CRUDs en React?
Pero el punto más importante, el que Fortune enfatizó, es este:
El cuello de botella ya no es la computación. Es la habilidad de dirigir agentes.
Esto cambia todo. La pregunta ya no es «¿sabes programar?». La pregunta es «¿sabes qué pedirle a los agentes? ¿Sabes diseñar el equipo? ¿Sabes cuándo darles autonomía y cuándo poner restricciones?»
Esas son las habilidades que importan ahora.
Mi Experiencia Real: De 0 a Plugin en Producción
El Problema
ecosistemastartup.com tiene más de 16,000 posts publicados. Es un medio de noticias para emprendedores latinoamericanos que corre automatizado con n8n, WordPress y un stack de IA.
El problema: los internal links en ese volumen de contenido son inexistentes o inconsistentes. Los plugins de auto-linking que probé en el mercado hacían una de estas tres cosas:
Procesaban 5-10 posts por request y bloqueaban el servidor
Tardaban horas para procesar el sitio completo
Generaban links tan ruidosos que degradaban la experiencia de usuario
Necesitaba algo que:
Procesara el inventario completo en segundos, no minutos
No degradara el performance del servidor en producción
Fuera inteligente sobre qué linkear (no spam, internal linking real)
Tuviera poder para revertir si algo salía mal
No existía. Decidí construirlo.
La Decisión: Agent Teams de Claude Code
Conocía Agent Teams desde que Claude Code lo lanzó. La idea es simple: en lugar de un solo agente que hace todo, defines un equipo con roles especializados. Cada agente tiene contexto, responsabilidades y restricciones específicas. Pueden coordinarse, pasarse información y hacer check-ins entre ellos.
Diseñé un equipo de 6 agentes:
Los 6 Agentes
1. Estratega (Orchestrator)
El director. Define la arquitectura general, coordina el flujo entre agentes, toma decisiones de alto nivel. Tiene acceso a todos los outputs del equipo. No escribe código directamente.
2. Research Agent
Investiga plugins existentes, analiza el código de los competidores, identifica qué funciona y qué falla. Documenta hallazgos antes de que nadie escriba una línea de código. Su output es un brief técnico que el Arquitecto consume.
3. SEO Agent
Define las reglas de internal linking: qué keywords linkear, qué posts tienen prioridad, cómo evitar over-optimization. Tiene poder de veto sobre cualquier decisión que afecte el perfil SEO del sitio.
4. Performance Agent (con poder de veto)
El agente más crítico del equipo. Su única obsesión es performance: tiempo de ejecución, queries a base de datos, consumo de memoria. Tiene poder de veto absoluto — si una implementación no pasa sus benchmarks, el Arquitecto debe rehacer.
5. Arquitecto
Diseña e implementa el código. Trabaja con las constraints del Performance Agent y las reglas del SEO Agent. Construye en fases, no monolíticamente.
6. QA Agent
Testing. Define casos de prueba, ejecuta validaciones, documenta bugs. No aprueba ninguna fase hasta que pasa sus criterios.
Las Reglas de Autonomía
Esto es lo que más diferencia un equipo de agentes que funciona de uno que se paraliza o produce basura:
REGLA 1: No preguntar, proponer y ejecutar.
- Cada agente puede tomar decisiones dentro de su dominio sin aprobación
- Si hay ambigüedad, elige la opción más conservadora y documenta el criterio
REGLA 2: Fases estrictas. Nadie salta pasos.
- Research → Diseño → Implementación → Performance Check → QA → Deploy
- Si el Performance Agent hace veto en la fase 4, se vuelve a Implementación
REGLA 3: Power of veto es absoluto para Performance y SEO.
- Si Performance Agent dice "esto es lento", se rehace. Sin excepciones.
- Si SEO Agent dice "esto over-optimiza", se ajusta.
REGLA 4: Métricas primero, código después.
- El objetivo no es "crear un plugin de auto-linking"
- El objetivo es "procesar 16,000 posts en menos de 2 minutos sin degradar performance"
- Si el código cumple la métrica, ganamos.
REGLA 5: Documenta todo.
- Cada decisión de diseño tiene un comentario que explica el porqué
- Futuros agentes (o yo mismo) necesitan entender el razonamiento
El resultado: LeanAutoLinks — en producción, procesando 16,000 posts en 90 segundos.
El Framework Completo: Cómo Diseñar un Equipo de Agentes IA
Esto es lo que aprendí. Lo puedes aplicar a cualquier proyecto de software.
Paso 1: Define el Problema con Métricas (No con Features)
El error más común: «Necesito un plugin que haga internal linking automático».
Eso es una feature, no un problema.
El problema real: «Tengo 16,000 posts sin internal links consistentes. Los plugins existentes tardan 4+ minutos y bloquean el servidor. Necesito procesar el inventario completo en menos de 120 segundos sin impacto en el servidor de producción.»
¿Ves la diferencia? El segundo tiene:
Escala del problema (16,000 posts)
Benchmark de éxito (menos de 120 segundos)
Constraint crítica (sin impacto en producción)
Cuando los agentes tienen métricas claras, pueden tomar decisiones autónomas. Si la métrica es «que funcione», cada agente tiene una interpretación diferente de «funcionar». Si la métrica es «90 segundos para 16,000 posts», todos miden lo mismo.
Paso 2: Diseña Roles, No Tareas
La diferencia entre dar tareas y dar roles:
Tareas: «Agente 1: escribe la función de scraping. Agente 2: escribe la función de inserción de links.»
Roles: «Performance Agent: eres responsable de que ninguna función en el codebase degrade el tiempo de respuesta del servidor. Tienes poder de veto sobre cualquier implementación.»
Las tareas producen agentes ejecutores. Los roles producen agentes que piensan.
Un agente con rol de Performance tiene incentivo para examinar todo el código, no solo «su función». Hace preguntas que ninguna tarea le habría pedido: «¿Estamos usando índices en las queries? ¿Qué pasa si este proceso se ejecuta mientras hay tráfico alto?»
Los roles crean ownership. Y el ownership produce mejor software.
Paso 3: Establece Reglas de Autonomía Explícitas
Dos extremos que matan el rendimiento de un equipo de agentes:
Demasiada autonomía: Los agentes van en direcciones diferentes, producen código inconsistente, nadie tiene visión global.
Demasiado control: Los agentes preguntan para todo. «¿Puedo usar esta librería? ¿Qué indentación prefieres? ¿Confirmas antes de continuar?» Eso ya no es un agente, es un chatbot con pasos extra.
El punto medio: autonomía dentro de constraints explícitas.
Define qué pueden decidir solos:
Elegir entre dos implementaciones técnicas equivalentes → autónomo
Usar una librería externa no mencionada → propone y ejecuta si pasa los criterios de performance
Cambiar la arquitectura general del plugin → requiere check-in con Estratega
Define qué requiere veto:
Cualquier cosa que toque queries a la base de datos → Performance Agent aprueba
Cualquier cosa que afecte URLs o meta tags → SEO Agent aprueba
Con estas reglas claras, los agentes avanzan sin paralizarse.
Paso 4: Investigación Antes que Código
Este paso lo saltan el 90% de las personas que usan agentes IA para programar. Y es el que más diferencia hace.
Antes de que el Arquitecto escribiera una línea de PHP, el Research Agent pasó tiempo analizando:
Los 5 plugins de auto-linking más populares en WordPress.org
Sus reviews de 1 estrella (¿por qué fallan?)
El código fuente de los top 2 (¿qué queries usan? ¿cómo manejan el volume?)
Los límites conocidos de la API de WordPress para este tipo de operaciones
Ese research produjo hallazgos críticos:
Los plugins populares usan str_replace() en el contenido post-query. Con 16,000 posts, eso es 16,000 operaciones en PHP. Lento.
La alternativa: usar MySQL directamente con un single UPDATE que haga el regex en la base de datos. Órdenes de magnitud más rápido.
El límite real no es PHP, es la conexión a MySQL. El batch size óptimo para este servidor es ~500 posts por transaction.
Sin ese research, el Arquitecto habría empezado con la implementación obvia (PHP loop) y habríamos llegado a los mismos problemas que los plugins existentes. El Research Agent identificó el camino correcto antes de escribir código.
Paso 5: Power of Veto — Constraints que Producen Mejor Software
El Performance Agent tenía una regla simple: ninguna implementación que tarde más de 100ms por post promedio pasa a QA.
Esto produjo algo interesante: el Arquitecto, sabiendo que había un veto, diseñó diferente desde el inicio. En lugar de «hacer que funcione y luego optimizar», diseñó para performance desde la primera línea.
El poder de veto no es burocracia. Es un mecanismo de diseño.
Cuando alguien (o algo) tiene autoridad para rechazar tu trabajo, cambias cómo trabajas. Los agentes con poder de veto bien definidos crean presión productiva en el equipo.
Nota importante: el poder de veto debe ser específico. «Agente de Calidad con poder de veto sobre todo» produce parálisis. «Performance Agent con poder de veto sobre queries y loops que afecten tiempo de ejecución» produce software rápido.
Paso 6: Fases Estrictas en Orden
Nada de desarrollo paralelo sin sincronización. Las fases fueron:
Research → Brief técnico documentado
Diseño arquitectónico → Schema de base de datos, interfaces, contratos entre módulos
Implementación → El Arquitecto construye módulo por módulo
Performance Check → El Performance Agent mide y hace veto si es necesario
QA → El QA Agent define y ejecuta casos de prueba
Revisión final → Estratega valida que el output cumple las métricas originales
Si la fase 4 hace veto, se vuelve a la 3. Si la fase 5 encuentra bugs críticos, se vuelve a la 3. No se salta a la 6 por comodidad.
Este orden importa. Cuando el Research está incompleto, el Diseño es frágil. Cuando el Diseño es frágil, la Implementación se cae. Las fases existen por una razón.
5 Casos de Uso Donde Agent Teams Cambia Todo
1. Plugins y Extensiones (WordPress, Chrome, VSCode)
El caso que viví. Un plugin de WordPress es territorio ideal para Agent Teams porque tiene capas bien definidas: base de datos, lógica de negocio, UI de admin, REST API, hooks de WordPress. Cada capa puede tener un agente especializado.
Lo mismo aplica a extensiones de Chrome o VSCode: hay capa de UI, capa de lógica, capa de comunicación con APIs externas. Roles naturales para un equipo.
2. APIs y Microservicios
Cuando necesitas construir una API con endpoints, validación, autenticación, documentación y tests, un equipo de agentes produce resultados significativamente mejores que un agente solo. El agente de Seguridad veta endpoints sin autenticación. El agente de Documentación asegura que todo tiene OpenAPI spec. El agente de Tests no aprueba nada sin coverage.
3. Migración de Datos a Escala
Tengo pendiente migrar contenido entre sistemas varias veces al año. Este es el caso de uso donde Agent Teams brilla más: hay un agente que entiende el schema origen, otro que entiende el destino, uno que valida integridad de datos, uno que maneja errores y rollbacks. Sin este tipo de equipo, las migraciones son las operaciones más propensas a desastres silenciosos.
4. Auditorías SEO Automatizadas
Un agente revisa títulos y meta descriptions. Otro analiza internal link profile. Otro identifica contenido duplicado. Otro verifica que los sitemaps estén actualizados. Orquestados, producen una auditoría SEO completa del sitio en minutos. Esto es algo que normalmente tomaría horas de trabajo manual o una herramienta SaaS de $100/mes.
Si usas n8n para automatización, puedes conectar estos agentes con workflows que corran periódicamente y te entreguen reportes sin intervención manual.
5. Prototipos de Productos SaaS
El caso más disruptivo. Lo que antes requería 2-3 semanas de un desarrollador para armar un MVP funcional — autenticación, CRUD básico, dashboard, integración con Stripe — ahora puede ser un Agent Team de 5-6 agentes trabajando en paralelo con fases coordinadas. No estoy diciendo que el código sea perfecto. Estoy diciendo que el prototipo que necesitas para validar con usuarios reales es alcanzable en horas, no semanas.
Si tienes un servidor para hostear tus proyectos, Hostinger tiene planes de VPS que corren Docker perfectamente para este tipo de deployments.
Los Números Reales
Esto no es teoría. Acá están los benchmarks de LeanAutoLinks:
Métrica
LeanAutoLinks
Plugin A (popular)
Plugin B (premium)
16,000 posts completos
90 segundos
4-8 minutos
3-5 minutos
Impacto en servidor
Ninguno
Bloqueo temporal
Degradación 30%
Posts por segundo
~178
~33
~53
Modo batch configurable
✅
❌
✅ (limitado)
Rollback/revert
✅
❌
❌
Dry-run mode
✅
❌
❌
Tiempo de desarrollo:
Enfoque
Tiempo estimado
Desarrollador PHP senior (solo)
3-5 días
Equipo de 2 devs
2-3 días
Agent Teams (lo que hice)
~4-6 horas de orquestación
El código está en GitHub, open source, con MIT license: github.com/ctala/Wordpress-Lean-Auto-Links
¿Por qué open source? Porque el valor no está en el código. El valor está en saber construir así. El proceso que acabo de describir es lo que vale. El plugin es el resultado.
Errores Comunes al Dirigir Agentes IA
Los cometí todos antes de encontrar lo que funciona. Te los paso.
Error 1: Dejar que los Agentes Pregunten Demasiado
El síntoma: el agente responde con «¿Quieres que use la librería X o la Y?» o «¿Confirmo antes de continuar?»
El problema: lo configuraste para preguntar en lugar de decidir. Un agente que pregunta para todo no tiene autonomía real. Tienes que responder sus preguntas, y en ese punto tú estás haciendo el trabajo, no él.
La solución: en el prompt del agente, define criterios de decisión. «Si tienes que elegir entre dos librerías equivalentes, elige la que tenga más stars en GitHub y menos dependencias.» Ahora puede decidir solo.
Error 2: Un Solo Agente para Todo
«Agente, construye este plugin» es el equivalente a contratar a una persona y pedirle que sea CEO, CTO, desarrollador, QA y diseñador al mismo tiempo.
El resultado es siempre el mismo: lo hace todo, nada bien. Un agente sin rol específico no tiene criterios para priorizar. Mezcla concerns. Toma atajos.
Diseña roles. Aunque sean 2-3 agentes, los roles cambian la calidad.
Error 3: No Definir Métricas Antes de Implementar
«Quiero que sea rápido» no es una métrica. «Procesar 16,000 registros en menos de 120 segundos» sí lo es.
Sin métricas, no sabes si el agente tuvo éxito. Y el agente tampoco lo sabe. Sin criterio de éxito, el trabajo nunca termina de verdad.
Error 4: Prompts Vagos = Software Vago
El prompting para code generation es diferente al prompting para texto. En texto, la vaguedad produce creatividad. En código, produce inconsistencia.
«Haz un plugin que agregue links automáticamente» puede producir 10 implementaciones radicalmente diferentes, todas «correctas» desde la perspectiva del agente. Necesitas ser específico sobre el contrato: inputs, outputs, constraints, casos edge.
El tiempo que inviertes en escribir un prompt detallado lo recuperas 10x en revisiones que no tienes que hacer.
Error 5: No Incluir un Performance Agent con Poder de Veto
Este es el más crítico y el más ignorado.
Todo proyecto de software eventualmente enfrenta el problema de performance. La diferencia es cuándo: si tienes un Performance Agent desde el inicio con poder de veto, el problema se resuelve en la fase de diseño. Si no lo tienes, se convierte en deuda técnica que encuentras en producción cuando ya tienes usuarios.
El Performance Agent no necesita ser sofisticado. Necesita tener una métrica y autoridad para rechazar código que no la cumple.
El Futuro: ¿Qué Viene Después?
El Prompt es el Nuevo Código
No en sentido metafórico. En sentido literal.
Cuando el código lo escribe un agente y tú escribes el prompt que guía al agente, el prompt es la fuente de verdad. Es donde vive tu intención, tus constraints, tu arquitectura de alto nivel. El código generado es el compilado.
Los ingenieros que entienden esto antes tienen ventaja. No porque programar vaya a desaparecer completamente, sino porque el código que escribes tiene que ser para las cosas que los agentes no pueden hacer bien aún: las decisiones de arquitectura profunda, los problemas de dominio específico, la integración de sistemas legacy complejos.
Junior Devs: Adaptarse o Quedarse Atrás
Forbes fue directo: AI agents wrote 80% of Karpathy's code, and junior developers are paying the price.
No estoy disfrutando esto — soy profesor universitario y he visto a cientos de jóvenes aprender a programar. Pero la realidad es que las tareas que antes ocupaban a un junior dev 40 horas a la semana ahora las puede hacer un equipo de agentes en horas.
La oportunidad para los junior devs que quieran sobrevivir a esto no es competir en velocidad de escritura de código. Es aprender a diseñar equipos de agentes, a establecer constraints, a evaluar outputs. Esas son habilidades de nivel senior que ahora son accesibles a cualquiera que esté dispuesto a aprenderlas.
La paradoja: los que van a sufrir más son los que saben cómo programar pero no entienden por qué se programa así. El razonamiento sobre arquitectura, performance y diseño de sistemas — eso sigue siendo humano.
La Paradoja de Jevons Aplicada a Programación
La Paradoja de Jevons dice que cuando la eficiencia de un recurso aumenta, el consumo total de ese recurso generalmente también aumenta, no disminuye.
Cuando los motores a vapor se hicieron más eficientes con el carbón, no consumimos menos carbón. Consumimos más, porque más cosas usaron motores.
Lo mismo va a pasar con el código. A medida que los agentes puedan construir software más rápido y barato, no vamos a necesitar menos software. Vamos a construir más. Más herramientas, más automatizaciones, más integraciones, más productos.
El mercado de software no se va a contraer. Se va a expandir. Lo que va a cambiar es quién puede participar en él.
Otro Ejemplo: Un Micro SaaS de SEO en un Día
Y LeanAutoLinks no fue el único proyecto de esta semana.
También construí una herramienta interna de keyword rank tracking y gap analysis usando el mismo enfoque de agentes. El problema era simple: necesitaba monitorear las posiciones de mis keywords en Google y detectar oportunidades de contenido automáticamente. Las herramientas existentes (Ahrefs, Semrush, Serpstat) cuestan $100-400/mes y la mayoría de sus features no las uso.
Así que construí un sistema que:
Sincroniza ranked keywords de mis dominios conectándose a APIs de datos SEO (~$0.01 por request vs $100+/mes de herramientas tradicionales)
Detecta content gaps automáticamente: queries donde tengo impresiones en Google pero no tengo contenido cubriendo ese tema
Crea entradas de glosario automáticamente cuando detecta términos que la gente busca y no tenemos cubiertos
Corre como cron — cada lunes analiza, detecta oportunidades, y genera los posts que faltan
El primer run detectó 742 queries con oportunidades, creó 4 entradas de glosario automáticamente, y identificó una guía de alto volumen (19,000+ impresiones) que no teníamos cubierta.
Cero interfaz gráfica. Cero dashboard bonito. Solo scripts que hacen el trabajo y un agente IA que los orquesta.
Este es el punto que Karpathy describe: la capacidad de un individuo para construir herramientas a medida se multiplicó exponencialmente. Antes necesitabas un equipo para construir un SaaS de SEO. Ahora puedes construir exactamente lo que necesitas en un día, con agentes que ejecutan mientras tú defines el problema.
La misma lógica de siempre: define el problema con métricas, diseña los agentes, deja que ejecuten.
Build in Public con IA como Estrategia de Contenido
Lo que estás leyendo ahora mismo es una consecuencia directa de eso.
Yo construí LeanAutoLinks con agentes IA. Documenté el proceso. Ese proceso se convierte en contenido que muestra cómo funciona el framework en la práctica. El contenido genera visibilidad. La visibilidad genera conversaciones y preguntas. Las preguntas generan más proyectos donde aplicar el framework.
Es un loop que se retroalimenta.
Si estás construyendo con IA, documenta. No el código — el proceso, las decisiones, los errores, los resultados. Eso tiene un valor que el código solo no tiene.
Conclusión
Karpathy dice que el cuello de botella ya no es escribir código. Es dirigir agentes.
Llevo una semana haciendo exactamente eso, y los resultados son reales: un plugin en producción, procesando 16,000 posts en 90 segundos, con cero tiempo en un equipo tradicional de desarrollo.
El framework que usé no es complicado:
Define el problema con métricas
Diseña roles, no tareas
Establece reglas de autonomía explícitas
Investiga antes de implementar
Incluye un Performance Agent con poder de veto
Respeta el orden de las fases
Lo que hace la diferencia no es la herramienta. Es el diseño del equipo y las constraints que le das.
Próximos Pasos
Si quieres profundizar en esto, tengo dos recursos:
El post completo sobre cómo construí LeanAutoLinks — con todos los detalles técnicos, el código del prompt de cada agente y cómo configuré Agent Teams desde cero: Construí un Plugin WordPress con un Equipo de Agentes IA
Mi comunidad en Skool — ahí estoy publicando en tiempo real los proyectos que construyo con agentes, el proceso, los errores y los resultados. Si quieres aprender a hacer esto mismo, es el lugar donde lo trabajamos juntos: Cágala, Aprende, Repite
El futuro del desarrollo de software no es escribir menos código. Es saber qué construir, para qué, con qué constraints — y dejar que los agentes lo ejecuten.
Eso siempre fue el trabajo del arquitecto. Ahora todos podemos serlo.
Publicado originalmente en cristiantala.com
Top comments (0)