Tecnología Aburrida, Prácticas Audaces
Hillel Wayne argumenta que la tecnología aburrida combinada con prácticas innovadoras supera a la combinación inversa. Por qué la elección de tu stack y la elección de tus procesos no son la misma decisión.
Hay un artículo que circula discretamente en Lobste.rs hoy y que merece más atención de la que está recibiendo. Hillel Wayne publicó "Choose Boring Technology and Innovative Practices" — y complica algo sobre lo que la comunidad de desarrolladores ha debatido durante una década sin llegar nunca a resolverlo del todo.
La versión canónica del argumento, que se remonta al ensayo de Dan McKinley de 2015, es simple: usa tecnología aburrida. Postgres en lugar de CockroachDB. Redis en lugar de tu almacén en memoria personalizado. MySQL en lugar de lo que salió de un batch de YC el trimestre pasado. No gastes tus "fichas de innovación" en infraestructura cuando el trabajo real es el producto.
Wayne coincide con la mitad de la tecnología aburrida. La parte que la mayoría de la gente se salta: la mitad de las prácticas en la ecuación debería ser exactamente la contraria.
Lo Que No Debería Congelarse, Se Congela
La mayoría de los equipos de ingeniería hacen esto exactamente al revés.
Adoptan cada nuevo framework, base de datos y runtime que aparece en GitHub Trending — y luego lo ejecutan con la misma estructura de standup, la misma planificación de sprints, el mismo proceso de revisión de PRs que tienen desde 2018. El stack es emocionante. La forma en que trabaja el equipo está congelada en el tiempo.
El argumento de Wayne invierte eso. Las decisiones de infraestructura tienen costos acumulados enormes — riesgo de migración, fricción al contratar, complejidad operativa, la carga de estar de guardia a las 2am cuando algo en tu base de datos exótica falla de una manera que ninguna respuesta en Stack Overflow ha abordado jamás. Ahí es donde el conservadurismo da sus frutos.
Pero tus prácticas — cómo haces las retrospectivas, cómo haces revisión de código, cómo estructuras la responsabilidad, cómo decides qué construir — estas tienen costos de cambio mucho más bajos. Puedes hacer un experimento de seis semanas con un nuevo enfoque de planificación y revertirlo con casi ningún daño si fracasa. No puedes hacer eso con tu almacén de datos.
La asimetría es obvia una vez que la ves. Pero casi ningún equipo la optimiza.
Por Qué los Desarrolladores Siguen Haciéndolo al Revés
En parte es por visibilidad. Las decisiones de infraestructura son públicas y legibles — puedes leer sobre ellas en charlas de conferencias y ofertas de trabajo. "Usamos Kubernetes, Kafka y un service mesh" anuncia algo sobre la cultura de ingeniería de una empresa, para bien o para mal.
Las decisiones de proceso son invisibles desde afuera. El perfil de LinkedIn de nadie dice "hacemos retrospectivas semanales asíncronas y lanzamos en ciclos de descubrimiento de dos semanas." Nadie es contratado a causa de cómo un equipo gestiona sus reuniones.
Así que la estructura de incentivos premia la novedad en infraestructura e ignora la innovación en procesos. La cobertura de InfoQ sobre QCon London 2026 ha estado llena de equipos hablando sobre herramientas y decisiones de plataforma. Las conversaciones a nivel de proceso son más cortas y más raras.
También hay un mecanismo de comodidad en juego. Probar una nueva base de datos se siente como innovación. Produce artefactos: una rama de spike, un documento de benchmarks, un plan de migración. Parece que se hizo trabajo. Cambiar cómo tu equipo toma decisiones es más difícil de justificar, más difícil de medir y más incómodo a nivel personal porque requiere que la gente realmente se comporte de manera diferente.
La Relación con la Programación en Pareja con IA
Aquí es donde esto se conecta con algo que está reshaping activamente la manera en que los equipos operan en 2026: la brecha entre las herramientas de programación en pareja con IA y los procesos que las rodean.
La mayoría de los equipos que han adoptado herramientas de codificación con IA — Copilot, Cursor, Claude Code, lo que sea que tengas en tu stack — adoptaron la herramienta de inmediato y no adaptaron el proceso en absoluto. El standup sigue preguntando "¿en qué trabajaste ayer?" como si la unidad de trabajo fuera la misma. La revisión de PRs sigue tratando cada línea como equivalente, aunque el costo de generar una línea de código se redujo en un orden de magnitud. La estimación de sprints sigue valorando las tareas aproximadamente por complejidad, aunque la programación en pareja con IA ha hecho que ciertos tipos de complejidad sean casi gratuitos.
La discusión reciente de Changelog sobre "the mythical agent-month" apunta a esto — cuando los agentes autónomos empiecen a enviar miles de PRs, ¿qué significa siquiera un sprint? Los equipos que luchan con esa pregunta no lo hacen por culpa de su stack tecnológico. Lo hacen porque sus prácticas nunca se actualizaron.
El enfoque de Wayne te da la palanca. El lado de la tecnología aburrida de la IA de codificación está resuelto: los proveedores de modelos de frontera son tu Postgres. No vas a superar a OpenAI o Anthropic en modelos fundacionales. Elige uno, comprométete, deja de perseguir cada nueva versión. El lado de las prácticas innovadoras está completamente abierto.
¿Cómo es la revisión de código cuando la IA para codificación genera el primer borrador y un humano revisa la intención, no la sintaxis? ¿Cómo es la estimación cuando la variable principal ya no es "cuánto tiempo tardará en escribirse esto"? ¿Cómo es la responsabilidad cuando tu herramienta de codificación con IA ha tocado el 40% del código base?
Esas son preguntas de proceso. Tienen costos de cambio más bajos que tu base de datos. Podrías ejecutar un experimento sobre una de ellas en este sprint.
Lo Más Difícil de "Aburrido"
Hay un costo psicológico que Wayne no aborda completamente, y es real: la tecnología aburrida se siente como quedarse atrás.
Esto es especialmente agudo en las herramientas de IA ahora mismo. El ritmo de lanzamientos es genuinamente asombroso. Simon Willison ha estado siguiendo el flujo constante de novedades durante años, y su blog se lee como una manguera de incendios de nuevos modelos, nuevas capacidades, nuevos lanzamientos de herramientas, nuevas integraciones. Cada semana hay algo que parece que cambia el panorama.
La mayor parte no lo hace. La curva de capacidad subyacente avanza, pero para cualquier equipo dado, la decisión de adoptar un nuevo modelo o cambiar a una nueva herramienta de codificación con IA conlleva costos de cambio reales: prompts actualizados, nuevos flujos de trabajo, capacitación, trabajo de integración. El principio de tecnología aburrida dice: deja que la frontera se mueva, espera a que las cosas se estabilicen, elige algo que claramente esté funcionando y quédate con ello el tiempo suficiente para aprenderlo de verdad.
La práctica de "escribir pequeñas pruebas mentales" — un hilo separado de Lobste.rs hoy sobre mantener modelos mentales incluso cuando el código se genera por ti — es en sí misma una innovación de práctica. No requiere ninguna herramienta nueva. Es simplemente una forma diferente de pensar mientras trabajas.
Ese es el patrón. Conservadurismo en el stack, experimentación en las prácticas.
Un Test que Vale la Pena Hacer
Antes de tu próxima sesión de planificación de sprint, intenta hacerte dos preguntas:
- ¿Qué decisión de infraestructura estamos considerando que tiene un alto costo de cambio y un soporte a largo plazo incierto? Si la respuesta honesta es "no estamos seguros de que esta tecnología exista en tres años", eso es una señal de que quizás estás quemando una ficha de innovación que no puedes permitirte.
- ¿Qué práctica hemos estado ejecutando en piloto automático durante más de un año? Si no recuerdas por qué haces tu retro de la manera en que lo haces, eso es una señal de que tienes una ficha de innovación sin usar.
El argumento de la tecnología aburrida no es un argumento a favor del estancamiento. Es un argumento sobre dónde pones tu energía. Postgres sigue funcionando. Tu equipo sigue aprendiendo. El cuello de botella, casi siempre, es el segundo.
Fuentes: Hillel Wayne sobre tecnología aburrida y prácticas innovadoras · InfoQ QCon London 2026 · Blog de Simon Willison · Writing little proofs in your head · Changelog podcast