Categoría: Arquitectura & DevSecOps

Buenas prácticas para diseñar y operar soluciones seguras y escalables: contenedores, OpenShift, CI/CD y ciberseguridad incorporada. Visión holística desde el código hasta la estrategia corporativa.

Publicado el

¿Importa la calidad del código en la era del vibe coding?

Artesana cosiendo a mano y un androide cosiendo con máquina en un taller luminoso; las puntadas pasan de irregulares a precisas formando un patrón tipo circuito.

Hace años, en una empresa en la que trabajaba, me contaron un caso muy directo: una empresa generó una aplicación a partir de UML con una herramienta automática que llevábamos nosotros. Cumplieron plazo y coste. Cuando cambiaron los requisitos, en lugar de mantener el código, tiraron la aplicación y la regeneraron: era más barato que tocar un código “raruno”, con nombres extraños. Esto se parece mucho a lo que ya estamos viendo con IA y el llamado vibe coding.

A mí aquello me dejó una idea: cuando regenerar es barato, la calidad se juega más fuera del código que dentro.

La idea en una frase

Si regeneras código a menudo, la calidad que paga la factura no está dentro de cada clase, sino en cómo está montado el sistema alrededor: arquitectura clara, datos bien gobernados, pipelines (build–test–deploy) fiables y reglas sencillas para trabajar. Lo del “código perfecto” importa cuando vas a evolucionarlo a mano; si vas a regenerar, importa menos.

¿Cuándo compensa regenerar?

Suele ganar la regeneración cuando se cumplen varias de estas condiciones:

  • Piezas pequeñas y con bordes nítidos (por ejemplo, un microservicio utilitario).
  • No hay mucho estado ni conocimiento “oculto” en el código actual.
  • El tiempo manda y cuesta más entender el código que volver a generarlo.

La experiencia de aquella herramienta lo anticipó: cuando el código es raro y vas justo de tiempo, regenerar duele menos que mantener. Con IA veremos este patrón más a menudo.

¿Y cuándo tiene sentido cuidar el código “a mano”?

Cuando hay conocimiento embebido (reglas, excepciones, compatibilidades), integraciones con terceros o necesitas trazabilidad y diagnóstico fino. Ahí el código legible y estable sí ahorra dinero. Además, si tu cadena de entrega es débil, cualquier cambio (generado o no) es una ruleta: mejor invertir en el “sistema de trabajo”.

Si la calidad se desplaza… ¿a dónde se va?

A las capas que no puedes regenerar con un clic y a las rutinas que aseguran el día a día:

  • Arquitectura y límites: separar bien piezas y decidir cómo hablan entre sí (lo llamo “cadena de suministro de software”). Es el tipo de decisión donde un perfil puente entre negocio y tecnología aporta más valor.
  • Datos y esquemas: el dato de producción no se regenera. Cambiar un esquema sin gobierno duele siempre. (Sí: aquí la prudencia paga).
  • Pipelines y pruebas (CI/CD): con un pipeline sólido, regenerar es barato y seguro; sin él, cada entrega es “a ver si suena la flauta”.
  • Control de versiones y trazabilidad: reglas simples tipo “lo que no está en el repo no existe” y entregables siempre generados desde el repo. Si no, ni sabrás qué has puesto en producción.

En resumen: menos heroicidad en el IDE y más disciplina en el sistema. Eso es lo que hace que el negocio duerma tranquilo.

Del “código bonito” al “contexto útil”

Otra consecuencia práctica: sube el valor del prompt y, sobre todo, del contexto que das a la IA (estructura, convenciones, restricciones, ejemplos). Cuando pides “algo más que una función”, necesitas explicar el marco: carpetas, naming, dependencias, seguridad… No es brujería; es onboarding bien hecho para una máquina. Lo conté con más detalle en Del Prompt Engineer al Context Engineer: cómo la IA me obligó a reorganizar mi web (y mis esquemas mentales).

Este giro es la parte de mi propuesta de valor en la que más me estoy enfocando últimamente: conectar negocio y tecnología, traduciendo requisitos en decisiones prácticas y riesgos controlados.

Guía rápida para decidir

Usa esta lista como “semáforo”. Si la mayoría caen en verde, regenera. Si salen en rojo, mantén y mejora el código.

  1. Horizonte: ¿La pieza es “desechable” en 3–6 meses o vivirá 2 años? (Desechable → verde).
  2. Bordes: ¿Cuántos sistemas/clientes toco si cambio esto? (Pocos → verde).
  3. Estado y conocimiento: ¿Hay reglas “no escritas” en el código? (Pocas → verde).
  4. Cadena de entrega: ¿Tengo build–test–deploy automático y fiable? (Sí → verde).
  5. Trazabilidad: ¿Puedo reconstruir el entregable desde el repo y saber qué incidencia corrige cada versión? (Sí → verde).
  6. Definición clara: ¿Podemos describir el “qué” y “cómo” para que la IA acierte a la primera? (Sí → verde).

Con este enfoque, la discusión no va de gustos (“código limpio sí/no”), sino de coste total de cambio y riesgo de negocio.

Un apunte sobre roles

Todo esto no va solo de herramientas. Hace falta gente que entienda el código y el contexto, y que sepa explicarlo en llano a negocio. Ese perfil híbrido es justo el hueco que más falta hace ahora mismo en muchas organizaciones.

Moraleja

La calidad no muere: se mueve. Si vas a regenerar a menudo, pon tu esfuerzo en arquitectura, datos, pipelines, control de versiones y en dar buen contexto a la IA. Si vas a evolucionar a mano, cuida el código como un jardín. La clave es elegir con criterio dónde pones la energía para que el negocio gane hoy y no se ate las manos para mañana.

Leyendo el artículo de Ricardo Devis en LinkedIn me vino a la cabeza este caso y las reflexiones sobre el efecto que va a tener el vibe coding en el sector. Si te apetece comentarlo, nos vemos en LinkedIn.

Diseñado en la cabeza de Iñigo, made in ChatGPT.

Relacionados sugeridos

Publicado el

Entre el negocio y la IA: el perfil que falta en el nuevo ciclo de vida del software

Reunión colaborativa en oficina moderna con diversidad de género, un androide y gráficos en pizarra

Conocí a Ricardo Devis hace más de 25 años, de hecho el siglo pasado porque llevaba el DESI, Diploma de Especialización en Soluciones Internet de la Universidad de Deusto. Así que le suelo seguir y hace poco leí un artículo que me pareció especialmente acertado: “AI in the SDLC: El ciclo de vida del software intermediado por inteligencia artificial”. No solo por cómo describe los cambios en las fases clásicas del desarrollo de software, sino porque pone sobre la mesa algo que a menudo se pasa por alto: la necesidad urgente de nuevos perfiles que conecten mundos que rara vez conviven bien.

El nuevo SDLC exige un nuevo tipo de profesional

En este nuevo SDLC (software development life cycle o lo que yo llamo cadena de suministro de software), no basta con saber programar ni con entender el negocio. Tampoco vale con “echarle IA” a lo que ya tenemos. Hace falta alguien que entienda las implicaciones técnicas de integrar copilotos, LLMs y automatizaciones, pero que también sepa detectar cuándo tiene sentido, qué riesgos asume el negocio y cómo gestionar la transición sin perder foco ni calidad.

Ese es precisamente el espacio donde me estoy posicionando como evolución de mi carrera: como conector entre tecnología y negocio, ayudando a traducir la innovación en valor real. Lo hice con arquitecturas, con modelos de ciberseguridad y, más recientemente, en dinámicas de innovación donde las PoC ya empiezan a incorporar IA generativa.

Hoy más que nunca, los equipos necesitan figuras que:

  • Entiendan el código pero también el contexto.
  • Sepan detectar patrones y anticipar tendencias sin caer en modas.
  • Traduzcan capacidades técnicas en decisiones informadas.

Porque si el SDLC evoluciona, también lo deben hacer los roles. Y hay uno, el del perfil híbrido, que no puede faltar.

Moraleja

Igual el próximo conocimiento que tienes que añadir a tu curriculum no es un nuevo lenguaje, sino habilidades diferentes.


¿Tú también estás viendo este vacío entre negocio y tecnología con la IA? Me interesa saber cómo lo estáis abordando en vuestros equipos. ¿Lo hablamos por LinkedIn?

Artículo original de Ricardo Devis, si te interesa este enfoque sobre el SDLC, te recomiendo seguirle: sus reflexiones van un paso más allá del titular.

Normalmente los artículos están Diseñados en la cabeza de Iñigo, made in ChatGPT, pero este lo ha escrito el solito… yo solo he editado.

Publicado el

Hacer cosas pensando en el futuro… ¿o no?

Hombre latino acariciando una bola de cristal en su escritorio, intentando visualizar el futuro mientras trabaja con su portátil en una oficina moderna.

Hace años, en una aplicación corporativa que ya llevaba una década existiendo y que todavía sigue coleando, propuse encapsular las peticiones asíncronas con una etiqueta JSP. La idea era buena: si algún día cambiaban las tecnologías (como había pasado de applets a iframes, luego AJAX), bastaría con tocar esa etiqueta y todo seguiría funcionando como si nada.

Pero la realidad fue más puñetera que mi previsión. Aquello que parecía elegante y mantenible… sigue coleando. El código sigue vivo, pero no siempre por las razones que uno querría 🤷.

Es una situación que me he encontrado en bastantes personas, todas con muy buenas intenciones como yo.

¿Cuándo dejarlo preparado y cuándo no?

Lo reconozco: de joven pecaba de exceso de previsión. Pensaba que dejarlo “preparado para el futuro” era sinónimo de profesionalidad. Pero hay un matiz clave: si no tienes claro lo que va a pasar, prepararte para “todo” es una trampa.

¿Qué aprendí?

  1. El código que no necesitas hoy, te estorbará mañana.
  2. Mañana sabrás más que hoy. Espera. Aprende. Mejora.
  3. La agilidad no es solo Scrum. También es diseño limpio, desacoplado y con margen para evolucionar.

La trampa del “por si acaso”

Desde el manifiesto de extreme programming hasta el puro sentido común que te da la experiencia, todo apunta a lo mismo: optimiza para el cambio, no para la adivinación.

Hoy día no puedes prever ni si tendrás equipo, ni si usarás la misma nube, ni siquiera si tu sector seguirá igual. Si alguien en 2019 hubiese escrito código pensando en que su sistema funcionase bien en el futuro, seguramente habría perdido el tiempo, por la irrupción de los LLMs. Porque nadie los vio venir. Ni los propios investigadores.

¿Y entonces qué hacemos?

Simplifica y déjate todas las puertas abierta que puedas sin incurrir en mucho coste. Deja margen. Y confía en tu yo del futuro: tendrá más experiencia, más información y —si todo va bien— menos ego.

Moraleja

Diseñar con flexibilidad no es renunciar a la calidad. Es reconocer que la calidad técnica incluye la adaptabilidad. No hagas predicciones: diseña para poder decidir con calma cuando llegue el momento.

Si quieres leer más sobre que hacer con el pasado, mira este artículo sobre aplicaciones heredadas. Y si puedes predecir el futuro, mejor lo usas para predecir el numero del euromillones 😉

¿Tú también tienes historias de código que envejece mal? Cuéntamelo en LinkedIn y seguimos la conversación 😉

Diseñado en la cabeza de Iñigo, made in ChatGPT no es bola de cristal es presente.

Publicado el

¿Oscuridad o seguridad? Una historia con linterna

Oscuridad vs seguridad

Cuando diseñé el modelo de seguridad de los canales digitales de i-DE, me tocó una de esas reuniones en las que el PowerPoint se queda corto y toca tirar de metáforas.

¿Y esto para qué sirve?

Muchas veces los equipos de negocio no entienden lo que hacemos en seguridad. Y no es por mala fe, es que usamos un lenguaje que suena a película de espías.

Me explico: en una de esas charlas con negocio, salió el tema de la “seguridad por oscuridad”. Al decirlo vi caras raras. Así que improvisé un ejemplo muy gráfico (o más bien oscuro 😉):

Imagina que tienes una habitación con un tesoro dentro. La habitación está completamente a oscuras. Nadie sabe que el tesoro está ahí, pero… la puerta está abierta.

Si alguien entra con una linterna, se lo lleva. Eso es la seguridad por oscuridad: no hay seguridad, solo ignorancia.

Ahora imagina la misma habitación, pero esta vez con una puerta cerrada con llave. Todo el mundo sabe que hay un tesoro, pero nadie puede entrar. Eso sí es seguridad.

Explicar lo técnico sin tecnicismos

Esta anécdota me recuerda algo importante: muchas veces, más que diseñar sistemas, estamos vendiendo ideas. Y para vender, hay que traducir.

Traducir jerga a metáforas. Riesgos a historias. Seguridad a cerraduras de toda la vida.

Y sí, cuesta. Pero si no lo haces, no te dan el OK. Y sin OK, no hay funcionalidad. Y sin funcionalidad, no hay mejora.

Moraleja

Convencer es tan importante como configurar. Que lo técnico no tape el mensaje.

Podemos seguir la conversación en LinkedIn

Este artículo ha sido Diseñado en la cabeza de Iñigo, made in ChatGPT … pero la linterna le llevaba yo.

Publicado el

Old Money: cuando el legado es viejo y el presupuesto escaso

Código legacy sin presupuesto en entornos empresarialeS

Hace unos años me tocó evaluar una aplicación que íbamos a reutilizar en varios equipos. Nada más abrir el código, se me escapó un “¡madre mía, qué jardín!”. Pero lo curioso no fue la calidad del código, sino la reacción del responsable: “Sí, está mal, pero sabemos por qué está así… y lo queremos mejorar”. Esa honestidad me pareció más valiosa que muchos frameworks.

El estilo Old Money: ni nuevo ni barato

Hay un patrón que me encuentro más veces de las que me gustaría. Le llamo el “estilo Old Money”. Que no, no va de ricachones con traje slim y zapatillas blancas. Va de aplicaciones viejas (Old) sin un duro para actualizarlas (Money). Resultado: parches, código legacy, frameworks obsoletos… y un equipo que muchas veces ni lo ve.

Creo que el mayor problema no es que la aplicación sea vieja. Me explico:

  • Lo realmente peligroso es cuando el equipo no es consciente de las limitaciones.
  • Como dicen los nutricionistas: lo más insano no es lo que sabes que es malo, sino lo que crees que es sano y no lo es. Pues esto, igual.

Si crees que tu aplicación es decente y no lo es, ni te planteas mejorarla. Y si encima no tienes presupuesto, apaga y vámonos.

La autoconciencia como primer paso

Me encontré una vez con un desarrollador que reconocía abiertamente los problemas de su código. No se excusaba, los asumía. Me explicó cómo había llegado a ese punto. A partir de ahí, pudimos planear mejoras: cada uno rascó algo de dinero de su parte y conseguimos hacer una pequeña inversión para refactorizar el núcleo. Poco, pero suficiente para salir del pozo.

Y lo más importante: el equipo ganó en confianza y visibilidad.

¿Qué hacemos con un Old Money?

  1. Diagnóstico brutal: ¿El código es viejo? Bien. ¿Lo sabemos? Mejor.
  2. Documentar la deuda: Aunque no puedas pagarla, haz inventario.
  3. Buscar aliados: Producto, negocio, compañeros… a veces todos rascamos un poco.
  4. Miniproyectos de mejora: No todo requiere un rediseño total. A veces basta con encapsular, testear, y preparar el terreno.

Moraleja

Si tienes un Old Money en casa, lo primero es dejar de creer que es Gucci cuando en realidad es Primark. Y lo segundo, empezar a rascar euros y voluntades para mejorar.

👉 Si quieres ver cómo empiezo a diagnosticar estos casos, pásate por esta entrada sobre cómo abordar el desarrollo de una aplicación CRUD. Ahí te cuento cómo organizar la casa… aunque esté vieja.

💬 ¿Te has cruzado con un “Old Money” en tu carrera? Cuéntamelo por LinkedIn, me encantará conocer otros casos reales.

Este articulo ha sido Diseñado en la cabeza de Iñigo, made in ChatGPT

Publicado el

Cuando tu equipo se descompensa por culpa de la IA

Robot sentado en un balancín desequilibrado al atardecer, metáfora visual del desajuste que puede provocar la IA en un equipo.

Hace años estuve en un proyecto grande, de esos en los que cada funcional tenía a su pequeño equipo de tres desarrolladores. La cosa funcionaba más o menos bien, hasta que uno del equipo rompió la estadística: era tan rápido programando que el analista funcional no tenía tiempo material para darle más trabajo. Literalmente tuvieron que pedirle que aflojara un poco el ritmo. ¡Menuda paradoja!

Si todos tenemos un copiloto, ¿quién acelera más?

Creo que una de las claves cuando hablamos de IA como asistente es entender el impacto desigual que puede tener según el perfil. Me explico:

  • Un programador puede ver su productividad aumentada en un 20%.
  • Un analista funcional quizá solo un 10%.

Esto, que puede parecer poca cosa, puede romper los equilibrios que tan bien conocemos en los equipos: 1 funcional para 3 programadores ya no cuadra igual si uno avanza a toda mecha y el otro sigue con su ritmo analógico.

Riesgos de descompensar la maquinaria

Las estructuras de equipo no son casuales. Se ajustan con el tiempo, según experiencia y necesidades del proyecto. Pero si ahora metemos un factor externo como la IA, que favorece más a unos perfiles que a otros, podemos encontrarnos con:

  • Sobredimensionamiento de ciertas funciones.
  • Cuellos de botella inesperados.
  • Necesidad de repensar roles y ratios tradicionales.

La disrupción no pregunta, entra con fuerza

Llamamos “disruptiva” a una tecnología porque rompe el statu quo. Y la IA tiene potencial para hacerlo, no solo en lo que hacemos, sino en cómo nos organizamos para hacerlo.

Ya no basta con meter herramientas nuevas. Hay que repensar los engranajes del equipo: ¿quién marca el ritmo?, ¿quién necesita refuerzo?, ¿quién va a empezar a quedarse esperando?

Moraleja

No hay que temer al cambio, pero sí mirarlo de frente. Si estás liderando un equipo, como ha sido mi caso muchas veces, empieza a medir bien cómo impacta la IA en cada perfil. Y si ves que se descompensa… toca reequilibrar.

¿Te ha pasado algo parecido? ¿Has tenido que ajustar estructuras por la entrada de nuevas tecnologías? ¿Te está afectando ya la irrupción de la IA en tu equipo? Me encantará seguir la charla en LinkedIn.

La IA no solo te puede aumentar la productividad de un programador, también la de generar una entrada de un blog, ya sabes Diseñado en la cabeza de Iñigo, made in ChatGPT.

Publicado el

Productividad: de programadores junior a IAs

Vista cenital de escritorio dividido entre un boceto desordenado de código a mano y un plano holográfico pulcro, metáfora de la evolución de la productividad del programador junior a la IA.

Recuerdo una época en la que estaba de arquitecto software («analista técnico», que decíamos entonces) en un proyecto lleno de formularios de mantenimiento: listados, búsquedas, altas, bajas y modificaciones. Lo típico, vaya. Aquello era un festival de pantallas. Así que antes de encontrarme con un problema decidí hacer lo que suelo hacer en estos casos: cuadricular.

Cuadricular para sobrevivir (y escalar)

Creo que uno de los mejores enfoques para industrializar bien este tipo de aplicaciones CRUD es imponer una estructura. Me explico con un ejemplo de lo que hice:

  • Cada mantenimiento tendría siempre las mismas tres páginas: filtro, resultado y detalle.
  • Cada una con su nombre, su carpeta y su clase asociada.
  • Y en servidor, según el stack de turno (Struts, en aquella época), sus beans, controladores o lo que tocase.

Esto hacía que el programador, sobre todo el más junior, no tuviese que inventar la rueda. Ya sabía cómo se debía llamar cada clase, dónde iba cada cosa, qué JSP tocaba y cómo se enlazaban entre sí. Lo importante no era la tecnología, sino el patrón, la cuadrícula.

El objetivo no es el programador: es el sistema de trabajo

Porque el verdadero truco no era facilitarle la vida al programador. Bueno, un poco sí, pero no solo por eso. El objetivo era conseguir que la persona más barata posible, pudiese hacer bien el trabajo. Y para eso hay dos palancas:

  1. Que lo que hay que hacer sea tan sencillo que lo entienda cualquiera sin explicaciones, pero cada vez las aplicaciones son mas complejas porque les pedimos cada vez más cosas.
  2. Que aunque sea complejo esté tan bien explicado y estructurado que ni haga falta pensar… mucho

Esta estrategia ha funcionado durante años con personas. Pero ahora el reto es mayor: que funcione con inteligencias artificiales.

¿Vale también para IA?

Esa es la pregunta que me ronda últimamente. Porque al final, muchos de estos CRUDs son variaciones de la misma plantilla: cambian los datos, pero no la lógica. Si conseguimos estructurar bien el qué y el cómo, ¿podríamos darle a una IA las piezas y que nos monte el mantenimiento entero? ¿Y que el programador solo revise?

Creo que sí. Pero hay que volver a los básicos: pensar mucho, cuadricular, automatizar. En ese orden. Como ya conté en «Cómo abordar el desarrollo de una aplicación CRUD», sin estructura no hay industrialización que valga.

Moraleja

Si algo te funciona expandelo. Y si ya no son personas quienes programan, sino IAs… igual la estructura de siempre te sirve más que nunca. ¿Has probado a cuadricularle el trabajo a tu IA?

👉 Si te interesa este tema, echa un vistazo también a Gestión del conocimiento para ver cómo sistematizar más allá del código.

Tu eres de cuadricular o no, te leo en LinkedIn

La IA me ha ayudado a cuadricular estas entradas Diseñadas en la cabeza de Iñigo, made in ChatGPT.