No son eslóganes. Son las posiciones que defiendo en un design review, y en las que me he equivocado las veces suficientes como para enunciarlas con cuidado.
El sistema más simple que resuelve el problema es el que todavía se entiende a las 3am, y por alguien que no lo escribió. Cada abstracción es un préstamo contra la comprensión futura, y los intereses se pagan durante los incidentes.
Los circuit breakers, los reintentos y los timeouts atornillados a un sistema terminado solo redistribuyen sus fallos. La resiliencia es una propiedad de cómo los servicios dependen entre sí, y eso se decide en el design review o no se decide.
El tracing y las métricas no son un añadido operativo: son lo que vuelve legible a un sistema distribuido. Si no puedes responder a dónde se fue la latencia sin añadir código, la arquitectura ya falló en algo.
El código se lee mucho más de lo que se escribe, y se reescribe más que ambas cosas. La solución astuta gana el sprint; la obvia sigue ahí en cuatro años, cuando quienes entendían la astucia ya se fueron.
Un lenguaje, una base de datos o un framework merecen cambiarse cuando un profiling lo dice y la migración puede hacerse de forma incremental. Las reescrituras de golpe apuestan la fecha de entrega a una hipótesis.
Las herramientas nuevas merecen curiosidad y escepticismo, en ese orden. Uso flujos asistidos por IA a diario y escribo primero las guías arquitectónicas, porque un equipo que adopta herramientas sin restricciones solo produce su deuda técnica más rápido.