He publicado seis artículos esta semana. Uno sobre PostgreSQL. Otro sobre agentes de IA. Otro sobre gestión de contexto. Un tutorial de automatización. Un análisis de debugging. Y un diseño de consejo adversarial para evaluar MVPs.
No fue planeado. Cada artículo salió de un paper, un talk o un proyecto que me pareció interesante por separado. Pero al verlos juntos, hay un hilo conductor que no vi mientras los escribía.
Los seis dicen lo mismo.
El patrón que no busqué
Empezó con el artículo de Bohan Zhang sobre cómo OpenAI escala PostgreSQL. La conclusión era brutal: 800 millones de usuarios, un solo primary, sin sharding. PgBouncer (2007). Read replicas (concepto de los 90). La tecnología más aburrida del planeta, tirando millas en una de las aplicaciones más usadas de la historia.
Luego vino Michael Bolin desmontando las tripas de los coding agents. Codex CLI, Claude Code — da igual. Por dentro son un bucle while con un LLM. Sin grafos de conocimiento. Sin planificadores simbólicos. Un loop, herramientas, y el modelo que decide cuándo parar. La magia era un while True.
Después, los Cookbook articles de OpenAI sobre context engineering. La gestión de lo que el modelo ve resulta importar más que el modelo en sí. Y las técnicas son viejas: inyectar contexto al arrancar (un README), recortar historial (un buffer circular), comprimir lo antiguo (un resumen). Nada que no hiciera cualquier sistema de chat de los 2000.
El tutorial de automatización lo remachó: las Codex Automations de OpenAI son cron + curl + un LLM. Literalmente. El scheduler más aburrido de Unix ejecutando el modelo más avanzado del planeta. La infraestructura tiene 40 años. El cerebro tiene 2.
Y luego los dos posts que no son sobre infraestructura. El puzzle de Jane Street donde una red neuronal de 2.500 capas resultó ser MD5. Se resolvió con debugging clásico: observar la forma de los datos, reducir el problema, acumular restricciones hasta que solo queda una respuesta. Las herramientas eran nuevas (SAT solvers, ChatGPT). El método era viejo (eliminación sistemática de hipótesis).
Y el consejo adversarial para MVPs: simular cinco expertos con un LLM para evaluar ideas antes de construirlas. Suena futurista hasta que te das cuenta de que es un wargame. Los militares los hacen desde los años 50. Los equipos de producto los llaman pre-mortems. La novedad es que ahora el panel cuesta 2 dólares en tokens en vez de 50.000 en consultores.
La tesis (que no es mía)
No estoy diciendo nada original. Esto lo lleva diciendo Dan McKinley desde 2015 con su charla «Choose Boring Technology». Lo dice DHH cada vez que alguien propone Kubernetes para un CRUD. Lo decía Fred Brooks en 1975 cuando escribió que no hay bala de plata.
Pero esta semana confluyen seis ejemplos independientes que lo demuestran en dominios diferentes:
| Dominio | Lo «aburrido» que funciona | Lo «nuevo» que promete más |
|---|---|---|
| Bases de datos | PostgreSQL + PgBouncer | Base de datos distribuida con sharding |
| Agentes de IA | while loop + herramientas | Arquitectura multi-agente con orquestador |
| Gestión de contexto | YAML + README + buffer circular | RAG con vector store + embedding pipeline |
| Automatización | cron + bash + curl | Plataforma de orquestación cloud-native |
| Debugging | Observar → reducir → hipótesis → verificar | Herramientas de interpretabilidad end-to-end |
| Evaluación de ideas | Debate estructurado con frameworks publicados | Plataforma de market research con datos de panel |
La columna izquierda es lo que realmente usa la gente que resuelve problemas a escala. La columna derecha es lo que se vende en las conferencias.
Por qué pasa esto
No es que la tecnología nueva sea mala. Es que la tecnología nueva resuelve problemas que la mayoría de equipos no tienen.
OpenAI no necesita sharding porque su patrón de acceso es 95% lecturas. Un solo primary aguanta todos los writes porque hicieron el trabajo de identificar cuáles eran pesados y los sacaron a otro sitio. No fue sexy. Fue cirugía con bisturí.
Los coding agents no necesitan arquitecturas sofisticadas porque el modelo ya es lo suficientemente bueno como para decidir, dentro de un bucle simple, qué herramienta usar y cuándo parar. La complejidad del orquestador es inversamente proporcional a la inteligencia del modelo.
cron no necesita sustituto porque el 99% de las automatizaciones son «ejecuta esto cada N horas». Si tu automatización necesita más que eso — event sourcing, compensación de fallos, retry con backoff — sí, necesitas algo más. Pero la mayoría no lo necesita. Y lo que no necesitas, sobra.
La trampa del artesano
Hay una trampa cognitiva que explica por qué seguimos buscando la herramienta mágica. Se llama complexity bias: la tendencia a preferir soluciones complejas sobre simples, porque las complejas parecen más adecuadas para problemas difíciles.
Si tu base de datos va lenta, la solución de «mover los writes pesados a otro sitio» suena a chapuza. La solución de «implementar sharding con consistent hashing y rebalanceo automático» suena a engineering. Y como ingenieros, preferimos las soluciones que parecen ingeniería.
Pero la chapuza que funciona es mejor que la ingeniería que no se termina.
OpenAI podría haberse pasado seis meses implementando sharding. En vez de eso, movieron unos cuantos workloads a Cosmos DB y dedicaron esos seis meses a construir funcionalidades para sus 800 millones de usuarios.
Dicho en cristiano: el coste de oportunidad de la solución elegante es la solución que no construyes mientras tanto.
Lo que esto implica para ti
No es que no debas aprender tecnologías nuevas. Es que antes de adoptarlas, deberías preguntarte:
¿Qué problema tengo que la tecnología aburrida no resuelve?
Si la respuesta es «ninguno, pero la nueva es más moderna», estás añadiendo complejidad sin beneficio. Y la complejidad siempre cobra. En bugs, en tiempo de onboarding, en noches de guardia.
Si la respuesta es «necesito X y PostgreSQL no lo hace» — perfecto. Adopta lo nuevo. Pero sé específico sobre qué es X.
¿Puedo resolverlo con lo que ya tengo y un poco de disciplina?
OpenAI resolvió el cuello de botella de conexiones con PgBouncer. No cambiaron de base de datos. No reescribieron la capa de acceso a datos. Pusieron un connection pooler delante. La disciplina fue: identificar el problema real, no el problema que querían resolver.
¿Estoy resolviendo un problema real o un problema futuro?
«No va a escalar» es la frase más cara de la ingeniería de software. Porque casi siempre es verdad — técnicamente, nada escala infinitamente. Pero en la práctica, el 99% de los proyectos mueren antes de necesitar escalar. Y el 1% que sobrevive tiene el tiempo y el dinero para resolver el problema cuando llegue.
La disciplina no es glamurosa
No es que no mole usar una base de datos distribuida escrita en Rust con consensus protocol propio. Mola mucho. Da buenas charlas. Queda genial en el CV.
Pero si lo que necesitas es PostgreSQL con un connection pooler y queries bien hechas, la base de datos distribuida es un coste sin beneficio. Y el coste no es solo técnico — es atencional. Cada hora que pasas configurando el cluster es una hora que no pasas entendiendo tus datos, optimizando tus queries, o hablando con tus usuarios.
La disciplina aburrida — queries simples, timeouts agresivos, aislamiento de workloads, cron que ejecuta scripts, READMEs que se mantienen actualizados, debugging metódico — no sale en los keynotes. No tiene logo. No tiene conferencia propia.
Pero es lo que funciona cuando todo lo demás falla.
Y esta semana, seis artículos independientes me lo recordaron al mismo tiempo. A veces el hilo conductor aparece solo. Solo hay que mirar.
Los seis artículos de la semana:
– OpenAI escala PostgreSQL para 800M usuarios con un solo writer — La base de datos baqueteada que aguanta lo que las nuevas prometen.
– Tu AI coding agent es un while loop con delirios de grandeza — Desmontando la magia de Codex CLI y Claude Code.
– Context engineering: el skill invisible — Lo que el modelo ve importa más que el modelo en sí.
– Codex Automations sin Codex — cron + bash + LLM = agentes nocturnos.
– Una red neuronal de 2.500 capas que resulta ser MD5 — Debugging clásico aplicado a ML.
– Cinco expertos que no existen revisan tu startup — Debate adversarial como herramienta de decisión.
Read this article in English.
