En marzo de 2026, un documento de 1989 titulado «Notes on Programming in C» alcanzó la cima de Hacker News con más de 900 puntos (Hacker News, 2026). Su autor: Rob Pike, co-creador de Unix, UTF-8 y el lenguaje Go. El debate que generó no fue nostálgico. Fue urgente. En un momento donde los agentes de IA generan miles de líneas de código por hora y los frameworks multi-agente prometen resolver cualquier problema, las cinco reglas de Pike sobre cómo escribir software suenan como una advertencia profética. Como señala Kibalka (2026), el documento volvió a la conversación pública precisamente en medio del debate sobre productividad de los desarrolladores y código generado por IA.
Este artículo explora cada una de esas reglas y muestra por qué se han convertido, sin proponérselo, en el manifiesto no escrito del diseño de agentes de IA.
Quién es Rob Pike
Rob Pike nació en Canadá en 1956. Su carrera comenzó en los laboratorios Bell de AT&T, donde trabajó junto a Ken Thompson, Dennis Ritchie y Brian Kernighan — los arquitectos originales de Unix (Wikipedia, 2026). En 1981 escribió el primer sistema de ventanas para Unix. Más tarde co-lideró el desarrollo de Plan 9, el sistema operativo distribuido que pretendía ser el sucesor de Unix.
En 1992, Pike y Thompson diseñaron UTF-8 — la codificación de caracteres que se convertiría en el estándar dominante de la web y el software moderno (Pike & Thompson, 1992). Ya en Google, Pike co-creó el lenguaje Go junto con Thompson y Robert Griesemer, un lenguaje que encarna la misma filosofía que ha defendido toda su vida: claridad sobre cleverness, simplicidad sobre sofisticación, datos sobre algoritmos (Wikipedia, 2026).
En 1989, Pike condensó esa filosofía en cinco reglas dentro de su documento «Notes on Programming in C» (Pike, 1989a). Treinta y siete años después, esas reglas describen con precisión quirúrgica los errores que cometen los desarrolladores al construir sistemas de IA agéntica — y cómo evitarlos.
Regla 1: No puedes saber dónde un programa va a gastar su tiempo
«You can’t tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don’t try to second guess and put in a speed hack until you’ve proven that’s where the bottleneck is.» (Pike, 1989a)
Pike nos dice: no adivines, no asumas. Los cuellos de botella aparecen donde menos los esperas.
Aplicación a sistemas agénticos
Cuando un equipo construye un agente de IA, la tentación inmediata es optimizar lo que parece importante: refinar el prompt del sistema, añadir cadenas de razonamiento chain-of-thought más largas, o implementar un segundo agente «verificador» que revise las respuestas del primero.
Pero los cuellos de botella reales suelen estar en otro lugar. Tal vez el agente falla porque la descripción de las herramientas es ambigua. Tal vez la latencia no viene del modelo sino de una API externa que tarda 3 segundos en responder. Tal vez el contexto se satura con información irrelevante y el agente pierde el hilo.
Anthropic (2024), en su investigación «Building Effective Agents», lo dice directamente: «Empieza con la solución más simple posible y solo aumenta la complejidad cuando se necesite.» No se trata de construir el sistema perfecto desde el día uno. Se trata de construir lo mínimo, observar dónde falla, y actuar sobre evidencia real.
La primera regla de Pike, reformulada para agentes: no optimices tu pipeline agéntico hasta que sepas exactamente qué parte está fallando.
Regla 2: Mide
«Measure. Don’t tune for speed until you’ve measured, and even then don’t unless one part of the code overwhelms the rest.» (Pike, 1989a)
Las reglas 1 y 2 de Pike son una reformulación directa de la máxima que Knuth (1974) popularizó en su trabajo seminal: «Premature optimization is the root of all evil» — frase que frecuentemente se atribuye a Tony Hoare pero que Knuth documentó como principio de ingeniería de software. Pike va un paso más allá: no basta con no optimizar prematuramente. Hay que medir. Y aun después de medir, solo optimizar si una parte domina claramente al resto (Pike, 1989a).
Aplicación a sistemas agénticos
En el desarrollo de agentes, «medir» significa construir evaluaciones rigurosas — evals — antes de iterar. ¿Cuántas llamadas al LLM hace tu agente por tarea? ¿Cuál es la tasa de éxito? ¿Cuánto cuesta cada ejecución? ¿Dónde falla: en el razonamiento, en el uso de herramientas, en el parseo de la respuesta?
Sin evals, estás optimizando a ciegas. Podrías pasar semanas refinando un prompt cuando el verdadero problema es que tu agente tiene acceso a 47 herramientas y no sabe cuál elegir.
La investigación de Google Research (2025) sobre escalamiento de sistemas multi-agente muestra que el rendimiento de los agentes se degrada de forma predecible conforme aumenta la complejidad del contexto — más herramientas, más instrucciones, más historial. Pero esta degradación solo se vuelve visible cuando mides. Un agente que «parece funcionar» en pruebas manuales puede estar fallando silenciosamente el 30% de las veces en producción.
Ronacher (2025a), creador de Flask, lo resume en sus recomendaciones sobre agentic coding: los principios centrales que se mantienen son «simplicidad, estabilidad, observabilidad y paralelización inteligente». Observabilidad es otra forma de decir: mide.
Regla 3: Los algoritmos sofisticados son lentos cuando n es pequeño, y n casi siempre es pequeño
«Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don’t get fancy. (Even if n does get big, use Rule 2 first.)» (Pike, 1989a)
Esta es la regla que más incomoda a los ingenieros ambiciosos. Pike dice: la sofisticación tiene un costo fijo, y ese costo solo se justifica a escala. Como n casi siempre es pequeño, lo simple casi siempre gana.
Aplicación a sistemas agénticos
Entre 2024 y 2025 hubo una explosión de frameworks multi-agente: grafos de estado, orquestadores con DAGs, sistemas donde un agente «manager» delegaba tareas a agentes especializados que a su vez consultaban a sub-agentes. La promesa era que la complejidad distribuida resolvería problemas que un solo agente no podía manejar.
La investigación reciente cuenta otra historia. El estudio de Towards Data Science (2025) sobre el «17x error trap» de los sistemas multi-agente muestra que añadir más agentes no es una bala de plata: la coordinación tiene un costo de overhead que frecuentemente supera los beneficios. En tareas de razonamiento secuencial, las variantes multi-agente degradaron el rendimiento entre un 39% y un 70% comparadas con un agente único (Towards Data Science, 2025).
¿Por qué? Porque n es pequeño. La mayoría de los casos de uso reales involucran pocas herramientas, pocos pasos y poca concurrencia. No necesitas un sistema distribuido de cinco agentes coordinados para responder preguntas sobre una base de datos. Un solo agente con un prompt bien diseñado y las herramientas correctas probablemente lo haga mejor, más rápido y más barato. Incluso la investigación sobre flujos clínicos multi-agente —uno de los contextos de mayor complejidad— concluye que un orquestador ligero sobre modelos existentes supera en eficiencia a arquitecturas densas (PMC, 2025).
La regla de Pike para la era agéntica: no uses un framework multi-agente con orquestación compleja si tu tarea se resuelve con un solo prompt bien construido.
Regla 4: Los algoritmos sofisticados son más propensos a bugs y más difíciles de implementar
«Fancy algorithms are buggier than simple ones, and they’re much harder to implement. Use simple algorithms as well as simple data structures.» (Pike, 1989a)
Si la Regla 3 habla de rendimiento, la Regla 4 habla de fiabilidad. La sofisticación no solo es innecesariamente costosa cuando n es pequeño — también es más frágil. Cada capa de abstracción es un punto de fallo potencial.
Aplicación a sistemas agénticos
Esta es quizás la regla más crítica para el diseño de agentes. Un agente que llama a otro agente, que parsea la salida de un tercero, que decide si escalar al cuarto… eso es una cadena de puntos de fallo donde cada eslabón puede romper la cadena completa.
Anthropic (2024) lo nombra explícitamente: «Mantén la simplicidad en el diseño de tu agente.» Los frameworks, advierten, «a menudo crean capas extra de abstracción que oscurecen los prompts y las respuestas subyacentes, haciendo el debugging más difícil» (Anthropic, 2024).
El movimiento code over configuration que ha emergido en 2025-2026 es una respuesta directa a este problema. PydanticAI (2025) abraza la filosofía de «lo que ves es lo que obtienes»: si sabes Python, sabes PydanticAI. Usa el sistema de tipos nativo del lenguaje en lugar de archivos YAML complejos o abstracciones opacas. El Claude Agent SDK de Anthropic sigue el mismo principio: herramientas implementadas como funciones de Python, sin Docker, sin contenedores, sin configuración de red (Anthropic, 2025).
Ronacher (2025a) ofrece un consejo que podría haber escrito Pike: haz que los agentes hagan «la cosa más tonta que funcione» (the dumbest possible thing that will work). Prefiere funciones con nombres claros y largos sobre clases con herencia. Evita hacks ingeniosos. Usa SQL plano — los agentes producen SQL excelente que además se puede auditar contra los logs. Y en un trabajo posterior, Ronacher (2025b) advierte que los agentes se degradan predeciblemente cuando la carga de contexto supera los umbrales manejables — degradación que solo ocurre cuando hay demasiada complejidad acumulada.
Cuando usas generación de código con IA, la pregunta clave antes de hacer merge no es «¿funciona?» sino «¿encaja en la complejidad existente del sistema?» (Kibalka, 2026). El código generado por IA es trivialmente fácil de producir y difícil de mantener si se acumula sin disciplina.
Regla 5: Los datos dominan
«Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.» (Pike, 1989a)
Esta es la regla más profunda de Pike, y la que más resonancia tiene con el diseño de agentes modernos. No dice «los datos son importantes». Dice: los datos dominan. Si tu estructura de datos es correcta, el algoritmo se vuelve obvio. Si es incorrecta, ningún algoritmo sofisticado la puede compensar.
Aplicación a sistemas agénticos
Traducido al mundo agéntico: si le das a un agente el contexto correcto — un system prompt bien estructurado, herramientas con esquemas claros, datos organizados en el formato adecuado — el comportamiento «inteligente» emerge casi naturalmente. El agente no necesita instrucciones elaboradas sobre cómo razonar. Necesita la información correcta sobre qué razonar.
Go, el lenguaje que Pike co-creó, maneja el contexto de ejecución de forma explícita a través de estructuras de datos (el paquete context). Las interfaces estructurales de Go son, según Ronacher (2025a), «notablemente fáciles de entender para los LLMs». No es coincidencia. Un lenguaje diseñado para que los humanos lo lean fácilmente resulta ser un lenguaje que las máquinas también procesan bien.
Los mejores frameworks de agentes aplican esta misma filosofía. PydanticAI (2025) usa el sistema de tipos de Python para definir entradas y salidas de los agentes. El Claude Agent SDK estructura las herramientas como objetos tipados con descripciones claras (Anthropic, 2025). En ambos casos, la arquitectura de datos es la arquitectura del agente.
Anthropic (2024) señala que los agentes pueden manejar tareas complejas, pero que su implementación suele ser simple — «típicamente solo un LLM usando herramientas en un loop». El trabajo crítico no está en el algoritmo de orquestación. Está en diseñar el conjunto de herramientas y su documentación con claridad. En otras palabras: los datos dominan.
La convergencia: 1989 y 2026
No es coincidencia que las reglas de un programador de C de 1989 describan con precisión las mejores prácticas para construir agentes de IA en 2026. Ambos contextos enfrentan el mismo problema fundamental: gestionar la complejidad en sistemas que los humanos necesitan entender, depurar y mantener.
Pike escribió sus reglas en una época donde los programadores de C se perdían en optimizaciones de bajo nivel que nunca importaban (Pike, 1989a). Hoy, los desarrolladores de agentes se pierden en orquestaciones multi-agente que nunca necesitaron (Google Research, 2025; Towards Data Science, 2025).
La sabiduría es la misma: empieza simple, mide antes de cambiar, desconfía de la sofisticación, y pon tu energía en las estructuras de datos — no en los algoritmos (UBOS, 2025).
O como lo diría Pike: si tus datos están bien, el agente sabrá qué hacer.
Bibliografía
Anthropic. (2024). Building effective agents. Anthropic Research. https://www.anthropic.com/research/building-effective-agents
Anthropic. (2025). Claude Agent SDK documentation. https://platform.claude.com/docs/en/agent-sdk/overview
Google Research. (2025). Towards a science of scaling agent systems: When and why agent systems work. Google Research Blog. https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/
Hacker News. (2026). Rob Pike’s rules of programming (1989) [Hilo de discusión]. https://news.ycombinator.com/item?id=47423647
Kibalka, D. (2026, marzo). Rob Pike’s 5 rules of programming are 35 years old — and more relevant than ever. Medium. https://medium.com/@awcalibr/rob-pikes-5-rules-of-programming-are-35-years-old-and-more-relevant-than-ever-0368eb8bf57a
Knuth, D. E. (1974). Structured programming with go to statements. ACM Computing Surveys, 6(4), 261–301. https://dl.acm.org/doi/10.1145/356635.356640
Pike, R. (1989a). Notes on programming in C. Bell Labs. https://www.lysator.liu.se/c/pikestyle.html
Pike, R. (1989b). Rob Pike’s 5 rules of programming [Archivo en University of Texas at Austin]. https://users.ece.utexas.edu/~adnan/pike.html
Pike, R., & Thompson, K. (1992). The history of UTF-8. Bell Labs. https://doc.cat-v.org/bell_labs/utf-8_history
PMC. (2025). Orchestrated multi agents in clinical workflows. PubMed Central. https://pmc.ncbi.nlm.nih.gov/articles/PMC12393657/
PydanticAI. (2025). PydanticAI documentation. https://ai.pydantic.dev/
Ronacher, A. (2025a). Agentic coding. Armin Ronacher’s Thoughts and Writings. https://lucumr.pocoo.org/2025/6/12/agentic-coding/
Ronacher, A. (2025b). Agents are hard. Armin Ronacher’s Thoughts and Writings. https://lucumr.pocoo.org/2025/11/21/agents-are-hard/
Towards Data Science. (2025). Why your multi-agent system is failing: Escaping the 17x error trap of the bag of agents. https://towardsdatascience.com/why-your-multi-agent-system-is-failing-escaping-the-17x-error-trap-of-the-bag-of-agents/
UBOS. (2025). Rob Pike’s five programming rules: Timeless guidance for modern developers. UBOS Tech News. https://ubos.tech/news/rob-pikes-five-programming-rules-timeless-guidance-for-modern-developers/
Wikipedia. (2026). Rob Pike. https://en.wikipedia.org/wiki/Rob_Pike