El punto de partida
La ingeniería de software moderna es una disciplina de la que cada año cuesta más hablar. El vocabulario se ha hinchado más rápido de lo que ha cambiado el oficio subyacente: cada framework se dice un paradigma, cada cloud se dice una plataforma, cada asistente se dice un agente.
Detrás del ruido, el trabajo ha seguido siendo reconocible. Un equipo toma una necesidad de negocio, elige una arquitectura con la que puede vivir, entrega una primera versión que sobrevive al contacto con los usuarios, y luego la mantiene a través de tres años de cambio sin reescribirla. Los equipos que hacen esto de forma constante en 2026 comparten un pequeño número de hábitos, y casi ninguno tiene que ver con la elección del framework.
Este texto trata de lo que la ingeniería de software moderna entrega de verdad, y de dónde ha cambiado, y no ha cambiado, la IA la ingeniería misma.
El coste de una mala arquitectura no ha bajado
Los frameworks han evolucionado. El coste de una mala decisión fundamental, en cambio, no ha bajado.
Una afirmación habitual en 2026 es que el desarrollo asistido por la IA ha vuelto barato el software. Ha vuelto más rápido cierto software. Más rápido no es lo mismo que más barato, porque el trabajo que comprime la asistencia de la IA (el tecleo) rara vez era la parte cara. Las partes caras siguen siendo las mismas: elegir la arquitectura adecuada, modelar correctamente el dominio, decidir qué entregar y qué rechazar, y mantener el resultado durante años.
Un modelo de datos mal juzgado sigue siendo un problema extendido por varios trimestres. Una frontera de autenticación mal juzgada sigue dejando escapar los datos de los clientes. Una historia de despliegue mal juzgada sigue despertando al ingeniero de guardia a las 3:14 de la madrugada. Ninguna de esas clases de error se resuelve con un tecleo más rápido. Se resuelven con el criterio senior en la fase de diseño, la parte del trabajo que la IA asiste, pero no reemplaza.
Los equipos que entregan software en 2026 pasan más tiempo en las decisiones arquitectónicas tempranas que hace cinco años, porque el coste de equivocarse se compone más rápido a través de un código aumentado por la IA.
Valores por defecto aburridos, asumidos donde importa
El stack por defecto de SDEN para la web y el móvil es deliberadamente conservador: Next.js con TypeScript en el frontend, PostgreSQL con Prisma o Drizzle en la capa de datos, Node.js o un framework como NestJS en la superficie de API. El móvil pasa por defecto a Flutter o React Native salvo que el producto necesite una integración profunda con la plataforma. El objetivo no es que sean las opciones más de moda. Es que son las opciones que un equipo senior pequeño aún puede mantener dentro de tres años.
Donde somos asumidos es en las fronteras: API tipadas de extremo a extremo, renderizadas en servidor por defecto, ningún dato sin tipar que cruce entre el servidor y el cliente, un pipeline de CI que compila y despliega cada commit en la rama principal, y un proceso de publicación lo bastante automatizado para que el ingeniero que entregó el cambio no sea el ingeniero que vigila el despliegue.
No son opciones emocionantes. Son las opciones que hacen posible el trabajo emocionante más tarde, porque el equipo no gasta su energía en los fundamentos.
Los patrones que sobreviven al segundo año
La mayoría de los proyectos de software parecen ir bien en los primeros seis meses. Las pruebas interesantes llegan en el segundo año, cuando los ingenieros originales han cambiado de puesto, el producto ha acumulado casos límite, y la clientela se ha extendido más allá de las hipótesis de diseño. Los patrones que sobreviven a esa prueba son los aburridos: fronteras de módulos explícitas, un modelo de dominio documentado en el código en lugar de en un wiki, un registro de decisiones arquitectónicas para cada elección no obvia, y una suite de tests que alguien aún puede ejecutar.
Los patrones que no sobreviven son los que dependían de la memoria de un solo ingeniero, de que los valores por defecto de un framework se mantengan constantes, o de la hipótesis de que nadie querría nunca volver a ver ese código. Siempre se quiere.
El sesgo de SDEN en cada proyecto va hacia el patrón aburrido, aceptado explícitamente y documentado. Cambiaremos el truco por la legibilidad en el segundo año de cada proyecto.
Tres hábitos detrás de cada código que entregamos
No son aspiraciones. Son los valores por defecto de operación en cada proyecto, inscritos en el contrato de proyecto.
Tipado de extremo a extremo
TypeScript en todo el stack, sin frontera sin tipar entre el servidor y el cliente. Si un campo cambia en la base de datos, el frontend se niega a compilar mientras el cambio no se reconozca. Es la red de seguridad más barata para un equipo grande que conocemos.
Registros de decisiones arquitectónicas
Cada elección no obvia obtiene un ADR de una página en el repositorio: qué decidimos, qué consideramos, por qué elegimos uno en lugar del otro. Los futuros ingenieros (incluidos los nuestros) los leen desde el primer día.
Despliegue aburrido
El despliegue es automatizado, observable y reversible. Cualquier ingeniero del equipo puede entregar en producción; cualquier ingeniero del equipo puede hacer rollback. El proceso de publicación no es un ritual.
El código que aún puedes leer dentro de tres años
La medida honesta de un proyecto es lo que el próximo equipo piensa del código.
Un código que envejece bien no tiene un truco único. Tiene un centenar de pequeñas bondades: nombres significativos, módulos dimensionados para que una persona los tenga en la cabeza, tests que explican la intención detrás del código, ningún código muerto rondando para confundir al próximo lector, y un registro de decisiones arquitectónicas en cada cruce donde un futuro ingeniero tendría que adivinar de otro modo.
Cuando SDEN entrega un código, la prueba es concreta: un ingeniero senior que se incorpora al proyecto debería ser productivo en menos de una semana, sin visita guiada. Si no puede, no hemos terminado.
Es la mitad aburrida del trabajo. Es también la mitad que determina si el producto sobrevive al próximo cambio en el equipo.
Software y móvil
las preguntas que más nos hacen.
Respuestas directas a las preguntas que más nos hacen. Si la tuya no está, escribe al equipo.