De Vibe Coding a Agent Engineering: Qué cambió realmente
En febrero de 2025, Andrej Karpathy publicó un tweet que definió una era: “There’s a new kind of coding I call vibe coding, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”
Trece meses después, en el podcast No Priors, retiró su propio término.
“I went from 80/20 of writing code myself versus delegating to agents to like 2/98. I don’t think I’ve typed a line of code since December.”
El hombre que nos dio el “vibe coding” ahora lo llama cosa del pasado. Su nuevo término: agentic engineering. No porque la IA se haya vuelto peor generando código — sino porque generar código nunca fue la parte difícil.
Lo que Karpathy realmente dijo
La entrevista en No Priors vale la pena verla completa, pero tres cambios destacan:
1. La proporción se invirtió. Karpathy pasó de escribir el 80 % de su código a escribir el 2 %. Los agentes se encargan del resto. El cuello de botella se desplazó de la velocidad de tipeo a la habilidad de orquestación — qué tan bien se dirigen múltiples agentes trabajando en paralelo.
2. “El código ya ni siquiera es el verbo correcto.” El desarrollo de software se convirtió en orquestación de macro-acciones. No escribes funciones; delegas funcionalidades. No depuras línea por línea; revisas a nivel de arquitectura. Peter Steinberger gestiona decenas de agentes simultáneamente, cada uno en tareas de 20 minutos a través de múltiples repositorios.
3. AutoResearch elimina a los humanos del ciclo por completo. Karpathy construyó un bucle de investigación autónomo para nanoGPT que corre de noche optimizando hiperparámetros. A pesar de sus años de ajuste manual, el agente encontró mejoras que había pasado por alto — weight decay olvidado en value embeddings, Adam betas insuficientemente ajustados. Su conclusión: “To get the most out of the tools, you have to remove yourself as the bottleneck.”
El hilo común: el valor se desplazó de la ejecución al juicio. El vibe coding era sobre ejecución — promptear, generar, desplegar. El agentic engineering es sobre juicio — arquitectura, verificación, orquestación.
El manual de ingeniería para lo que viene
La misma semana, Tw93 — creador de Pake, Mole y prolífico ingeniero open source — publicó “You Don’t Know AI Agents,” una guía técnica profunda que cubre lo que realmente se necesita para hacer que los agentes sean fiables en producción. Donde Karpathy ofrece la visión, Tw93 ofrece el manual de ingeniería.
Su tesis central: los harnesses importan más que los modelos.
“Using a more expensive model doesn’t always yield the massive improvements you’d expect. Instead, the quality of your harness and validation tests has a far greater impact on success rates.”
Esto no es teórico. El propio equipo de ingeniería de OpenAI lo demostró: tres ingenieros escribieron un millón de líneas de código en cinco meses — diez veces la velocidad tradicional. La clave no fue un modelo mejor. Fueron las decisiones correctas de ingeniería sobre restricciones, validación e infraestructura de agentes.
Cinco principios que separan el Vibe Coding del Agent Engineering
1. Context Engineering, no Prompt Engineering
La complejidad de atención de un Transformer es O(n²). Cuanto más largo el contexto, más fácil es que las señales cruciales se diluyan. El modo de fallo más común no es “el modelo no puede hacerlo” — es el Context Rot: el contenido irrelevante se acumula hasta que la calidad de las decisiones del agente se degrada visiblemente.
La solución es la gestión de contexto en capas:
- Capa permanente: Identidad, convenciones, restricciones duras. Corta, estable, siempre cargada.
- Capa bajo demanda: Habilidades y conocimiento del dominio. Los descriptores permanecen residentes; el contenido completo se carga solo cuando se activa.
- Inyección en tiempo de ejecución: Marcas de tiempo, preferencias del usuario, estado dinámico. Añadido por turno.
- Capa de memoria: Experiencia entre sesiones. Se lee solo cuando es relevante, no metida en cada prompt.
La clave: no pongas lógica determinista en el contexto. Todo lo que pueda expresarse como reglas de código, linters o hooks debe ser manejado por sistemas externos. El modelo debe pensar, no leer manuales de reglas.
2. Diseño de herramientas siguiendo principios ACI
La mayoría de los fallos de herramientas no ocurren porque el modelo elija la herramienta equivocada — ocurren porque la herramienta fue diseñada para ingenieros, no para agentes. El marco Agent-Computer Interface (ACI) cambia la perspectiva de diseño:
| Aspecto | Mal diseño de herramienta | Buen diseño de herramienta |
|---|---|---|
| Granularidad | Mapea a endpoints de API | Mapea a objetivos del agente |
| Devuelve | Datos crudos completos | Campos relevantes para la siguiente decisión |
| Errores | Cadena genérica | Estructurado con sugerencias de solución |
| Descripción | Qué hace | Cuándo usarlo y cuándo NO usarlo |
Un ejemplo práctico: en lugar de ofrecer get_post + update_content + update_title como herramientas separadas, ofrece update_yuque_post que expresa la acción completa en una sola llamada. Los contraejemplos en las descripciones de herramientas aumentan la precisión del 53 % al 85 %.
Al depurar agentes, revisa primero las definiciones de herramientas. La mayoría de los errores de selección de herramientas provienen de descripciones inexactas, no de capacidades insuficientes del modelo.
3. La memoria como infraestructura, no como ocurrencia tardía
Los agentes carecen de continuidad temporal nativa. Cuando una sesión termina, el contexto desaparece. Cuatro tipos de memoria resuelven diferentes problemas:
- Memoria de trabajo (ventana de contexto): Estado actual de la tarea. Gestionada activamente.
- Memoria procedural (habilidades): Cómo hacer las cosas. Cargada bajo demanda.
- Memoria episódica (registros de sesión): Qué ocurrió. Persistida, con capacidad de búsqueda.
- Memoria semántica (MEMORY.md): Hechos estables. Inyectada al inicio.
La decisión de diseño crítica: la consolidación de memoria debe ser reversible. Al compactar conversaciones largas, no elimines los mensajes brutos — archívalos. Mueve un puntero, no destruyas datos. Si la consolidación produce un mal resumen, el agente aún puede recurrir al historial bruto.
4. Evaluación antes de optimización
La evaluación de agentes es fundamentalmente más difícil que las pruebas tradicionales. El espacio de entrada es infinito, los LLM son sensibles a la formulación del prompt, y la misma tarea puede producir resultados diferentes entre ejecuciones.
Dos métricas, dos propósitos:
- Pass@k: Al menos una ejecución correcta de k. Prueba los límites de capacidad. Úsalo durante el desarrollo.
- Pass^k: Todas las k ejecuciones correctas. Prueba la fiabilidad. Úsalo antes del despliegue.
El anti-patrón más peligroso: ajustar el agente cuando la evaluación está rota. Si tu puntuación es defectuosa, estás optimizando contra señales distorsionadas. Cuando el rendimiento cae, revisa la infraestructura primero — límites de recursos que causan fallos, calificadores con errores, o casos de prueba desconectados de la realidad — antes de modificar el agente.
5. La coordinación multi-agente requiere protocolos
Ejecutar múltiples agentes no es sobre paralelismo — es sobre aislamiento y coordinación. Los subagentes deben devolver solo resúmenes; su búsqueda, prueba y error, y proceso de depuración permanece en su propio contexto. El contexto del agente principal recibe solo conclusiones.
El orden importa: define los protocolos primero, establece el aislamiento después, luego habla de colaboración. Sin comunicación estructurada (colas de mensajes JSONL, grafos de tareas, aislamiento de espacio de trabajo), los errores se amplifican entre agentes. El agente A se desvía, el agente B refuerza el sesgo, el agente C lo apila, y los tres convergen en una conclusión incorrecta con alta confianza.
La progresión en una tabla
| Fase | Rol del desarrollador | Calidad del código | Verificación | Escala |
|---|---|---|---|---|
| Codificación manual | Escritor | Alta (tu código) | Tú lo pruebas | Una persona |
| Vibe coding | Prompteador | Variable | Tú lo revisas | Un agente |
| Agentic coding | Arquitecto | Estructurada | El agente se prueba a sí mismo | Múltiples agentes |
| Agent engineering | Orquestador | Con harness | Evaluación automatizada | Equipos de agentes |
Cada fase no reemplazó a la anterior — la absorbió. Todavía necesitas criterio, todavía necesitas pensamiento arquitectónico, todavía necesitas entender el código. Pero la capa de ejecución sigue alejándose de tus dedos.
Qué significa esto en la práctica
Karpathy construyó un agente de automatización del hogar llamado “Dobby the House Elf” — tres prompts que escanearon su red local, hicieron ingeniería inversa de las APIs de dispositivos inteligentes y reemplazaron seis aplicaciones separadas con comandos de WhatsApp. “Dobby, sleepy time” apaga todo.
Su conclusión sobre el software: “These apps shouldn’t even exist. Shouldn’t it just be APIs and agents are the glue of intelligence that tool-calls all the parts?”
Esta es la trayectoria. El software pasa de productos que operas a agentes que operan productos en tu nombre. La interfaz colapsa de GUIs a lenguaje natural. La complejidad no desaparece — se mueve al harness, las herramientas, la evaluación, los sistemas de memoria que hacen que los agentes sean fiables.
El vibe coding nos hizo sentir cómodos con la idea de que la IA escribe código. El agent engineering trata de construir la infraestructura que hace que el código escrito por IA sea confiable, mantenible y autónomo.
Los vibes fueron el paso 1. La ingeniería es todo lo que viene después.
TeamDay ejecuta agentes de IA autónomos en la nube — SEO, contenido, redes sociales, analítica y más. Los mismos principios de agent engineering que describen Karpathy y Tw93 impulsan nuestra fuerza de trabajo de IA. Empieza a construir tu equipo de agentes.