Etiqueta: Vibe Coding

Calidad de código, deuda técnica, legacy en era IA

Publicado el

Vibe coding: la mejor forma de aprender lo que no hay que hacer

Mujer sonriente sentada en el suelo de su salón con un portátil, del que brotan enredaderas y cables que invaden la habitación como una jungla descontrolada, con un pequeño timón de barco oculto entre las plantas y un androide entregándole otro cable más

Es domingo por la tarde. Mi blog, seamos honestos, es una mezcla rara: una tarjeta de presentación muy cara y un laboratorio donde hago mis pruebitas. Últimamente el laboratorio está muy entretenido: llevo semanas construyendo una bóveda de conocimiento personal que ingesta artículos, los clasifica, genera grafos que conectan ideas entre autores distintos. Lo que empezó siendo una evolución razonable —antes solo editaba posts, ahora quiero que también me ayude a encontrar temas y a aprender— se ha convertido en un jardín. Uno de esos de los que cuesta salir.

De «hazme un script» a «no sé qué he decidido»

El patrón es siempre el mismo. Le pides algo sencillo: que te automatice la ingesta de un artículo. Funciona, así que le pides la clasificación. También funciona, así que vas a por el grafo de conocimiento. Y de ahí a la diarización de hablantes en transcripciones de YouTube —algo que no había tocado en mi vida— escrito todo en scripts de Python, un lenguaje que tampoco he programado nunca.

Claude te va proponiendo cosas que, en principio, parecen razonables. Y como no le dedicas mucho rato —esto es un proyecto de fin de semana, no de trabajo—, tampoco piensas mucho las cosas. Dices «vale, perfecto» y sigues. Ese «vale, perfecto» repetido veinte veces es el problema: te da una sensación de control que no es real. No sabes si lo que acabas de aprobar tiene sentido. Solo sabes que suena bien.

La resaca del domingo con prisa

Y entonces empiezan a aparecer las grietas. No se da cuenta de que la transcripción de un vídeo ya existe en YouTube y no hace falta generarla de nuevo. Cuando transcribes en local, a veces alucina y el resultado es sutilmente incorrecto. Los scripts de Python se han ido llenando de funcionalidad añadida sobre la marcha hasta convertirse en un batiburrillo que ni tú entiendes.

Al final, aprovechando la vuelta del modelo Fable (que es más listo), le pedí que le echara un vistazo a todo aquello, porque tenía la sensación de que se estaba desmadrando. Y, efectivamente, estaba desmadrado: media docena de scripts pequeños que se podían fusionar en un par de ellos, y más cosas.

Lo curioso no es que la IA se equivocara. Es que, como yo tampoco sabía lo suficiente, no me di cuenta de lo que se le había pasado. Vas a la deriva convencido de que llevas el timón, y solo cuando ya no te acuerdas de por qué decidiste algo —y le tienes que pedir a la propia IA que te documente lo que has hecho para no perderte— te enteras de que no lo llevabas.

Lo único que de verdad me está funcionando

De todo lo que he ido probando, una cosa sí ha demostrado su valor: usar OpenSpec para dejar por escrito, antes de implementar, qué se va a hacer y por qué. Parece burocracia de fin de semana, pero no lo es: queda documentada la decisión, así que la propia IA es capaz luego de recordar por qué se tomó, en lugar de que tengas que reconstruirlo tú de memoria (que es justo lo que no funciona cuando decides veinte cosas seguidas sin pararte a pensarlas).

En el trabajo esto no es opcional: ahí sí hay que leer los diseños, prestar atención a lo que la IA propone, no dejarse llevar por la velocidad. En un proyecto personal de fin de semana, en cambio, puedo tirar para adelante y pagar el precio después.

Por eso recomiendo el vibe coding

Con todo el mundo diciendo que no hay que hacer vibe coding, yo lo recomiendo, con un poco de sorna. Una vez. En algo pequeño y sin consecuencias reales. Vas a aprender en un fin de semana lo que ningún curso te va a enseñar de verdad: que la IA, por muchas cosas plausibles que te proponga, no sabe lo que tú no sabes. Y que la sensación de control que te da es, precisamente, el riesgo.

Moraleja

El vibe coding no es peligroso porque la IA se equivoque de vez en cuando. Es peligroso porque tú, si no sabes lo suficiente, no te enteras de cuándo se equivoca. Hazlo una vez, en un proyecto sin nada que perder, y sabrás exactamente por qué no deberías volver a hacerlo así en algo que sí importa.

¿Te ha pasado alguna vez sentir que controlabas tu propio código —o tu propio proyecto— y en realidad ibas a la deriva? Cuéntamelo en LinkedIn.

Relacionados sugeridos

Publicado el

La coherencia que nadie enseña en ingeniería

Hombre joven con camiseta y vaqueros mirándose en un espejo; su reflejo le muestra vestido con camisa, chaqueta y pantalón chino.

Hace unos años di una ponencia en un evento organizado por RedHat, Intel y la empresa donde trabajaba. Hablé de OpenShift: contenedores, agilidad, el presente del desarrollo de aplicaciones. Salió bien. Fui a casa contento.

Unos días después le enseñé las fotos a mi madre. Echó un vistazo y dijo: «Muy bien, hijo. Pero eras el único que no llevaba traje.»

Lo primero que pensé fue que no habría llevado traje de todas formas. El evento giraba en torno a herramientas de agilidad. Aparecer con traje habría resultado contradictorio —casi cómico— con el propio mensaje. Eso lo tenía claro.

Pero el comentario no me salía de la cabeza. No iba sucio, ni roto, ni estrafalario. Tampoco llevaba algo que llamara la atención en sentido positivo. Mi ropa no restaba. Pero tampoco sumaba.

Desde entonces empecé a tomarme la ropa un poco más en serio. No como vanidad. Como coherencia. Años después, con la IA poniendo el sector patas arriba, esa misma lógica me ha vuelto a la cabeza con más fuerza. Te cuento por qué.

Esto no va de moda. Va de posicionamiento profesional. La ropa es solo el ejemplo más visible de un problema más amplio: la coherencia entre todas las señales que emites, y si esas señales están alineadas con el profesional que quieres ser. En un momento en el que la IA está redefiniendo qué perfiles tienen valor, esa coherencia ya no es opcional.

Lo que dices antes de abrir la boca

María Uranga, experta en asesoría de imagen, lo dice sin rodeos en el podcast de Adrià Solà Pastor: la mayor parte de una entrevista de trabajo ya está decidida antes de que el candidato abra la boca.

Tendemos a leer eso como «viste bien para las entrevistas». Pero si lo transponemos al mundo técnico, el dato es mucho más incómodo.

Tu LinkedIn es una primera impresión. Tu primera intervención en una reunión con cliente es una primera impresión. La forma en que escribes un correo con una propuesta técnica es una primera impresión. Y en todos esos casos, la percepción se forma antes de que el interlocutor procese el contenido real.

La pregunta correcta no es «¿llevo la camisa adecuada?». La pregunta es: ¿con qué intención me estoy presentando?

Vístete para el rol que quieres tener

La frase más memorable del episodio es esta:

«Te tienes que vestir como si ya lo fueras. Si voy a ser el director del departamento, me voy a vestir desde el primer día como si ya lo fuera.»

Sustituyamos «vestir» por «comunicar».

Si quieres que te vean como el profesional que conecta negocio y tecnología, tienes que comunicar como ese profesional desde el primer día: en tus conversaciones, en lo que publicas, en cómo introduces un problema técnico ante un directivo. No esperes a tener el título. La percepción precede al reconocimiento formal.

Este principio no es autoayuda: es la misma lógica que usamos cuando hacemos un PoC antes de tener el presupuesto aprobado. Demuestras el valor antes de que te lo pidan.

Sin coherencia, solo hay disfraz

El límite está claro en el podcast: la imagen falla cuando cae en el disfraz. Cuando hay una desconexión entre lo que proyectas, lo que sientes y lo que realmente eres.

Para un profesional técnico, el equivalente del disfraz es el perfil de LinkedIn lleno de buzzwords sin experiencia real detrás, o el consultor que habla de «transformación digital» en cada frase pero no puede explicar un caso concreto.

La autenticidad no es solo una virtud ética. Es una ventaja estratégica: lo que es real, se sostiene; lo que es disfraz, se cae en la primera pregunta incómoda.

Hay quien lleva esta lógica todavía más lejos. Juan, del canal Huéleme Mucho, lo explica con una imagen que se te queda: si eres Batman, el Caballero Oscuro, no puedes ir oliendo a Nenuco. No porque haya una norma escrita, sino porque en cuanto alguien lo detecta —aunque no lo procese conscientemente— algo no cuadra y eso le pone en alerta. La coherencia no es solo lo que dices o cómo te vistes. Es la suma de todas las señales que emites a la vez.

Si no lo defiendes, lo pierdes

Hay un momento del podcast que resuena especialmente. María explica que si llevas algo que no defiendes —aunque te quede bien— el primer comentario negativo que recibas te desestabiliza. Pero si lo defiendes de verdad, lo que recibes es refuerzo, no crítica.

El mecanismo funciona igual en el posicionamiento profesional.

Si tú mismo no tienes claro qué rol ocupas, qué valor diferencial aportas, cuál es tu área de autoridad… cualquier comentario que cuestione tu valía te afecta de forma desproporcionada. En cambio, cuando hay una narrativa propia consolidada, el ruido externo no encuentra grieta donde entrar.

«Tu imagen es perfecta cuando te defiendes tú mismo», dice. Sin necesidad de validación externa constante.

La estrategia de imagen que nadie enseña en ingeniería

Hay una frase que aparece varias veces en el episodio: «La imagen es dinámica.» No es un estado fijo que alcanzas una vez. Evoluciona con tus objetivos, tu contexto, el rol al que aspiras.

Lo mismo ocurre con el posicionamiento profesional en entornos técnicos.

No es un perfil de LinkedIn que actualizas cada tres años. Es una elección continua sobre cómo te presentas, con qué lenguaje explicas lo que haces, qué proyectos eliges visibilizar y cuáles te quedas para ti.

Nadie nos enseña esto en la ingeniería. Nos enseñan a resolver problemas técnicos. Pero no a comunicar que sabemos resolverlos antes de que nos den la oportunidad de demostrarlo.

El momento de hacer esta revisión es ahora

En el mundo técnico estamos en un momento de reconfiguración acelerada. Muchos perfiles que funcionaban bien hace tres años tienen que redefinir qué valor aportan y cómo comunicarlo. En ese contexto, el posicionamiento no es un lujo: es supervivencia profesional. Y el posicionamiento no empieza en el LinkedIn ni en el discurso. Empieza en cómo te presentas al mundo cada día.

Moraleja

La imagen —física o profesional— no es vanidad. Es el canal por el que el mundo recibe información sobre quién eres y a qué aspiras, antes de que tengas ocasión de demostrarlo.

Si quieres que te vean como un referente en tu área, empieza a comunicar como tal hoy. No cuando tengas el título, no cuando tengas el caso de éxito, no cuando te sientas «suficientemente preparado». La percepción no espera a que estés listo.

Y si no sabes exactamente cómo quieres que te vean, ese es el ejercicio más urgente que tienes pendiente.

¿Tienes claro cómo quieres que te vean —y estás enviando las señales correctas para que eso ocurra? No solo en lo que dices. En todo lo demás también.

Comparte tu reflexión en LinkedIn →

Relacionados sugeridos

Publicado el

Hábitos viejos con herramientas nuevas: ¿sigue teniendo sentido hacer cosas genéricas?

Un hombre a punto de comprar un traje estándar se gira al ver que un sastre androide ofrece ropa a medida al mismo precio, en una sastrería luminosa y elegante.

Hace unas semanas estaba diseñando un pequeño sistema para automatizar una tarea repetitiva. A los cinco minutos ya estaba añadiendo parámetros para que sirviera «también en otros casos». Me detuve. ¿Para quién estaba haciendo eso?

Tengo un hábito que me ha servido durante décadas: cuando algo cuesta construirse, hazlo reutilizable. No sé exactamente cuándo lo interioricé, pero lleva tanto tiempo ahí que casi no lo veo. Últimamente he empezado a preguntarme si sigue siendo la respuesta correcta. O si simplemente lo estoy aplicando por inercia.

La lógica original era impecable. Si construir una solución a medida era caro, había que diseñarla de forma que sirviera para varios casos de uso. Plantillas parametrizables. Componentes configurables. Lógica condicional: «si el proyecto es de tipo A, haz esto; si es de tipo B, aquello». La reutilización era la respuesta racional a la escasez de recursos.

El problema de lo genérico

Cuando algo tiene que servir para muchos casos, inevitablemente se complica. Aparecen condiciones, excepciones, opciones que «depende». Y el resultado, aunque técnicamente reutilizable, traslada la complejidad al usuario: ahora eres tú quien tiene que interpretar qué aplica a tu situación y qué no.

Durante décadas ese coste fue aceptable porque la alternativa —construir algo completamente a medida— era cara, lenta o directamente inviable en el día a día.

Pero eso ha cambiado.

Mi flujo de publicación, como ejemplo

Tengo un sistema para gestionar el proceso de creación y publicación de entradas en mi blog. No es especialmente complejo, pero sí está completamente adaptado a cómo trabajo yo: tiene en cuenta mis temas habituales, artículos y vídeos que me han inspirado, mi tono de voz, los objetivos que persigo con cada publicación. Incluso el hecho de que no me preocupa especialmente el SEO —porque la mayor parte de mis lectores llegan a través de LinkedIn, no de buscadores— es algo que está integrado en cómo está construido ese flujo.

No tiene sentido para nadie más, y lo digo sin matices. No porque sea un sistema secreto, sino porque está construido sobre mi contenido, mis prioridades y mi forma de escribir. Intentar hacerlo genérico para que le sirviera a otra persona significaría añadir tantas capas de configuración y condiciones que dejaría de ser útil para cualquiera de los dos.

Y lo interesante es que construirlo a medida no fue especialmente costoso. Fue más rápido y más útil que buscar una solución estándar y adaptarla.

La IA invierte la ecuación

Ahí está el cambio que creo que no estamos terminando de asimilar: con las herramientas de inteligencia artificial actuales, generar algo ajustado a tu caso concreto ya no es caro.

Si tienes el criterio —si sabes lo que necesitas— puedes obtener una solución adaptada a tu contexto en mucho menos tiempo del que llevaría entender y configurar la versión genérica. La restricción que justificaba la genericidad ha desaparecido en muchos casos. El cuello de botella ya no es construir: es saber qué quieres construir.

Cuando los sistemas se diseñan para generar, no para ser genéricos

Lo veo también en cómo están diseñadas las herramientas que más uso. No están construidas para cubrirlo todo: están construidas para ayudarte a construir lo que tú necesitas. El Skill Creator de Claude Code es un buen ejemplo: en lugar de un sistema que contempla todos los casos de uso posibles, tienes algo que genera la solución específica para tu contexto. Llaman a esto meta-agentes —sistemas que crean otros sistemas—. El nombre es nuevo; la lógica, no: si generar algo adaptado ya no cuesta más que usar algo genérico, ¿por qué conformarse con lo genérico?

El hábito que merece revisarse

No estoy diciendo que la reutilización haya muerto. Hay contextos donde sigue siendo la estrategia correcta: cuando los requisitos son estables y compartidos, cuando el volumen justifica la inversión, cuando la solución estándar es suficientemente buena para el caso.

Lo que sí creo es que necesitamos cuestionar cuándo aplicamos ese hábito por inercia. Cuándo estamos construyendo algo genérico no porque sea lo más útil, sino porque es lo que siempre hemos hecho.

La IA no nos quita la necesidad de pensar. Al contrario: nos exige tener más claro qué queremos, porque sin ese criterio no se puede aprovechar la capacidad de generar soluciones adaptadas. Pero si tienes ese criterio, la genericidad como respuesta por defecto empieza a cuestionarse seriamente.

Cuando cambia la restricción, cambia la respuesta

Los hábitos que construimos a lo largo de años tienen una lógica detrás. La reutilización, la parametrización, las soluciones genéricas: todo eso nació de una restricción real.

Pero cuando cambia la restricción, merece la pena preguntar si la respuesta sigue siendo válida.

Yo llevo haciéndome esa pregunta con más frecuencia últimamente. No siempre la respuesta me gusta.

Relacionados sugeridos

¿Tienes algún hábito de este tipo —algo que construiste con toda la lógica del mundo y que ahora te preguntas si todavía tiene sentido? Me interesa leer tu perspectiva en LinkedIn.

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

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

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.