Arda Akgür
Este texto no explica cómo construir sistemas perfectos. Tampoco creo que existan.
Estos son principios que acumulé a lo largo de años construyendo sistemas, escribiendo código, enseñando a estudiantes y viendo por qué fallan los sistemas que ya funcionaban.
Para mí, la ingeniería de sistemas es resolver problemas antes de elegir tecnología.
1. Lo más importante en un sistema es la estabilidad
Cualquiera que sea la lógica fundamental con la que construiste un sistema, no reescribas esa lógica sin parar una vez que está en marcha.
Los parámetros pueden cambiar. Se pueden hacer pequeñas mejoras. Se corrigen errores. Pero si empiezas a cambiar las reglas centrales a mitad de camino, al cabo de un tiempo no tendrás ni el diseño original ni el nuevo.
Cuando hace falta un cambio mayor, a veces lo correcto no es forzar el sistema actual, sino iniciar una nueva versión.
No cambies las reglas del juego a mitad del juego.
2. Construye el sistema más simple que funcione
No dediques el primer día a diseñar para millones de usuarios, la escala a cinco años y problemas que aún no existen.
Eso suele no ser ingeniería. Es arquitectura de YouTube.
Construye el sistema comprensible que resuelva el problema de hoy lo antes posible y que de verdad funcione.
Si un día tienes un problema real de escala, es un buen problema. Significa que el sistema vivió lo suficiente para llegar ahí.
Cuando haga falta un V2, puedes construirlo de otra forma.
3. Aléjate del statu quo
Que todo el mundo use una tecnología o arquitectura no significa que sea correcta para tu problema.
"El estándar de la industria lo dice" no es por sí solo una justificación técnica.
Define primero el problema. Luego mira qué lo resuelve mejor.
Si la respuesta es lo que usan todos, úsalo. Si no, no tengas miedo de hacer algo distinto.
Sé leal al problema, no a las herramientas.
4. No tomes decisiones importantes con hambre o agotamiento
La herramienta más importante de un arquitecto no es el ordenador. Es la mente.
El hambre y el cansancio serio pueden destruir la calidad de las decisiones. Una solución que normalmente rechazarías puede parecer "suficiente". Puedes asumir riesgos innecesarios, irritarte fácil o aceptar una mala decisión solo para terminar.
A veces ese estado incluso intoxica. Crees que aún puedes decidir, pero el juicio ya se ha derrumbado.
En esos momentos puedes hacer trabajo rutinario: escribir código, lanzar tests, revisar logs. Pero no tomes decisiones arquitectónicas caras si puedes evitarlo.
Si la decisión puede esperar a la mañana y estás agotado, que espere a la mañana.
El hambre y el cansancio son tus enemigos.
Antes de diseñar el sistema, el arquitecto debe estar operativo.
5. Si el código cambia, la documentación debe cambiar
Con cada actualización significativa de código, actualiza también la documentación.
No trates la documentación como una tarea aparte para después. Código y documentación son dos mitades del mismo cambio.
Las herramientas modernas de IA lo facilitan mucho. Tras cada cambio importante, haz que la IA revise el cambio y el código relacionado. Genera Markdown que describa el estado actual del sistema, o actualiza lo existente.
Mantén la documentación en el repositorio como `.md` siempre que puedas. Markdown es simple, se sigue bien en control de versiones y se ve bien en GitHub.
Si un cambio de backend afecta al frontend, comparte el Markdown relevante con el equipo de frontend.
Un desarrollador frontend debería entender cómo funciona un endpoint, su request y response, el comportamiento cambiado y los avisos — sin tener que cavar primero en el código.
El mismo principio vale entre equipos y servicios.
La IA acelera la documentación. La responsabilidad de la corrección sigue siendo del ingeniero que hizo el cambio. No aceptes docs generados por IA sin revisarlos.
Si el código se actualizó y la documentación no, el trabajo no está terminado.
La documentación es la memoria del sistema.
6. Ve primero el sistema terminado en tu cabeza
Antes de escribir código, deberías poder ver el sistema terminado en la mente.
Si no puedes, coge papel y lápiz y dibuja.
No tiene que ser un diagrama ER. No tiene que ser UML. No tiene que seguir el estándar de nadie.
Dibuja cajas. Dibuja flechas. Escribe notas. Dibújalo como te cuadre.
Lo importante no es que el dibujo sea bonito. Es que puedas ver el sistema entero.
Si intentas descubrir un sistema que no ves escribiendo código, empiezas a diseñar e implementar a la vez.
Primero ve. Luego construye.
7. No olvides para quién es el sistema
No desprecies las ideas de managers no técnicos y de usuarios.
A veces una idea que parece técnicamente rara mira el problema desde un ángulo que nunca consideraste.
Su trabajo no es pensar como tú.
Tu trabajo es entender lo que quieren y, cuando sea posible, convertirlo en un sistema que funcione.
Escucha sus sueños e intenta hacerlos reales. A veces el resultado te sorprenderá de verdad.
Construye el sistema para quien lo usará — no para ti.
8. El arquitecto no debe perder el control
Todo sistema serio necesita mecanismos fail-safe.
Debes poder parar el sistema con una sola variable de entorno si hace falta. Ten un endpoint de gestión controlado si es necesario. Diseña vías para desactivar piezas críticas.
No deben ser puertas traseras secretas que rompan la seguridad. Deben estar autorizadas, ser seguras y preferiblemente registradas.
Por muy autónomo que sea el sistema, el arquitecto nunca debe convertirse en espectador de su propio sistema.
El control final permanece en el arquitecto.
9. Sospecha primero de tu propio error
Cuando el sistema se ralentiza, no culpes de inmediato al hardware.
Tal vez haya un deadlock que no ves. Tal vez escribiste una query mala. Tal vez hay una llamada de red innecesaria. Tal vez un error de arquitectura está bloqueando el sistema.
Sí — el hardware puede ser realmente insuficiente.
Pero mide primero.
Un ingeniero debe poder aceptar que puede equivocarse. No hay nada vergonzoso en eso.
Quien no puede admitir que se equivocó tampoco puede corregir su error.
10. Forma estudiantes
No dejes que el sistema viva solo en tu cabeza.
Enseña el sistema a tus estudiantes.
Si mañana no estás, el sistema debe poder continuar. Que otro lo entienda y mejore no reduce tu autoridad. Demuestra que eres un buen arquitecto.
Un sistema que solo una persona entiende no es fuerte. Es frágil.
Transfiere el conocimiento.
11. Trabaja con un equipo pequeño y alineado
No seas arquitecto solitario. Tampoco armes un equipo innecesariamente grande.
Trabaja con gente abierta a aprender, que escuche, pregunte y no haya perdido el espíritu de estudiante.
La crítica vale. Un junior puede ver el bug que tú no viste. Escúchalo.
Pero quien convierte la oposición constante en estilo de trabajo es peligroso al construir sistemas. Relitigar cada decisión sin fin fuerza al arquitecto a cambiar de rumbo y acaba destruyendo la estabilidad.
Debate hasta que se tome la decisión.
Una vez tomada, ejecuta en equipo.
No tienes que trabajar a largo plazo con quien bloquea el avance por oposición constante.
12. Sé creativo, pero mantente simple
Un ingeniero experimentado ante un buen sistema debería poder decir "vaya".
Y un buen junior entrando en ese mismo sistema debería entender más o menos qué ocurre en una semana.
Esas dos cosas no se oponen.
La verdadera maestría no es usar cien servicios ni inventar abstracciones que nadie entiende.
Es resolver un problema complejo con un sistema sorprendentemente simple.
La complejidad no es oficio.
13. No metas cada idea nueva en el sistema viejo
Cuando llega una idea nueva, tu primer reflejo no debería ser engañarla al sistema actual.
A veces hace falta un servicio nuevo. A veces una aplicación nueva. A veces de verdad hace falta un V2.
Si intentas extender el sistema viejo para siempre, acabas apilando años de decisiones y excepciones sobre el sistema simple con el que empezaste.
A veces empezar de cero es más barato, más limpio y más correcto.
El cambio no siempre significa agrandar el sistema actual.
14. Usa la inteligencia artificial como herramienta
La IA puede fortalecer un sistema de verdad.
Sobre todo los motores de reasoning modernos son potentes tanto al construir como en runtime.
Pueden revisar código, encontrar edge cases, apoyar decisiones, entender lenguaje natural y resolver problemas ambiguos donde los algoritmos clásicos fallan.
Pero no descargues todo sobre la IA.
Si basta una solución determinista simple, úsala. Si el reasoning aporta valor de verdad, usa IA. Si juntos funcionan mejor, construye un híbrido.
Dale trabajo a la IA. No le des autoridad sobre el sistema.
15. No esperes milagros de la IA
La IA es tan inteligente como la persona que la usa.
Si describes mal el problema, incluso un modelo muy fuerte puede producir la solución equivocada muy rápido.
Necesitas saber qué quieres. Entender el problema lo bastante para evaluar la respuesta. Notar cuándo se equivoca.
La IA no tiene que ser el ingeniero en tu lugar.
Bien usada, amplía tu capacidad de ingeniería.
No esperes milagros.
16. El hábito tira, y la mierda huele
It is what it is.
No busques significado profundo en todo.
A veces un bug es solo un bug. El código malo es código malo. Una idea que no funciona no funciona. Una decisión errónea es errónea.
Si basta una explicación simple, no adornes el problema con teoría innecesaria.
Mira primero la realidad que tienes delante.
17. No temas imitar al maestro
Como estudiante, no tienes que inventarlo todo.
Cuando era estudiante, reescribí desde cero estructuras como ArrayList para aprender. El objetivo no era inventar una estructura nueva.
El objetivo era hacer yo mismo lo que hacían los maestros, entender cómo funcionaba, compararlo con mi solución y crecer.
Aprender imitando no es plagio.
Primero llega al nivel en el que puedes hacer lo que hizo el maestro. Intenta entender por qué lo hizo así. Luego cuestiona. Luego desarrolla tu método.
Rechazar lo que no entiendes solo para ser distinto no es creatividad.
Aprende primero. Rompe después.
Cierre
La buena ingeniería de sistemas no es el arte de usar la mayor cantidad posible de tecnología.
Es entender el problema, ver la solución en la cabeza, construir lo más simple posible, proteger la estabilidad de lo que funciona y poder admitir el propio error cuando haga falta.
Un buen arquitecto conoce primero el estado de su mente. Negarse a decisiones mayores con hambre, agotamiento o sin pensar con claridad también es ingeniería.
Protege la memoria del sistema tanto como el código. Documenta lo que cambia y comparte ese conocimiento con quienes seguirán construyendo el sistema.
Controla su sistema — no lo adora.
Lidera su equipo — no silencia a sus estudiantes.
Usa inteligencia artificial — no le externaliza el pensar.
Aprende de lo hecho antes — no se rinde al statu quo.
Y lo más importante: si el sistema funciona, intenta entender por qué; si no, intenta entender por qué no.
Todo lo demás es una herramienta.
Arda Akgür
Principios de sistemas ARC
v0.1 Final