¿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  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

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.

El peligro de que tu IA sea un pelotilla

Androide complaciente botando una pelota frente a una trabajadora desconcertada en una oficina moderna

Llevo trabajando desde el siglo pasado y después de una docena de empresas, muchos proyectos y aún más jefes, uno desarrolla un radar para detectar a los que no aceptan críticas. Porque con según qué jefes, discrepar era sinónimo de jugarte el cuello.

Lo mismo pasa con las IA

Las IA pueden parecer muy listas, pero si no tienen criterio propio (y no lo tienen), pueden acabar siendo igual de pelotas que el típico compañero que siempre decía “sí, jefe”. Da igual que le digas al modelo que actúe como nutricionista o como desarrollador senior: su tendencia será complaciente. ¿Por qué? Porque ha aprendido a ser “útil”, no a tener criterio.

Yo mismo probé a pedirle a ChatGPT que me hiciera una entrevista de trabajo. Todo eran flores, todo perfecto. Pero no es realista. El problema es que si usamos estas herramientas para tareas operativas, vale. Pero si las usamos para decidir, contrastar o explorar caminos… necesitamos que cuestionen, no que aplaudan.

Las cámaras de eco también se digitalizan

Si tienes un copiloto que te dé siempre la razón, acabas encerrado en una burbuja de autocomplacencia digital. Y eso, en entornos donde se toman decisiones que afectan a presupuestos, personas o seguridad, puede ser directamente peligroso.

¿Solución? Recordar que la IA no tiene intuición. Ni experiencia. Ni contexto emocional. Puede procesar más datos que tú, pero no sabe qué importa de verdad. Y ahí, todavía, tenemos ventaja los humanos.

Moraleja

No dejes que tu copiloto sea un pelotilla. Rodéate de gente —y de máquinas— que te lleven la contraria con criterio. Ahí es donde nace la innovación de verdad 😉


¿Y tú? ¿Has detectado cámaras de eco en tu trabajo con IA? Hablemos en LinkedIn.

Este post, como otros recientes, no existiría sin una decisión y una ayuda artificial.  Diseñado en la cabeza de Iñigo, made in ChatGPT.

En que se parecen las rebajas y la innovación

Mujer en rebajas que no encuentra su talla

Una de las decisiones más prácticas que he tomado en mi vida adulta tiene que ver con las rebajas. Solo compro cosas en rebajas si no son imprescindibles. Lo que necesito de verdad, lo compro cuando lo necesito. No me espero. Porque si esperas, llegas a las rebajas y… ¡sorpresa! Ya no queda tu talla.

¿Y esto qué tiene que ver con la innovación?

Más de lo que parece. Cuando estaba trabajando como consultor de innovación para Iberdrola, solía decir que innovar es preparar hoy lo que tu empresa va a necesitar dentro de cinco años. Pero claro, eso cuesta dinero. Y la reacción más común —especialmente en perfiles más orientados a gestión— es posponer las decisiones hasta que «sea el momento». Es perfectamente entendible, pero es lo mismo que esperar a las rebajas.

¿Qué puede salir mal?

Pues que cuando por fin decidas sacar ese nuevo servicio o producto, no puedas. Porque para hacerlo necesitas tener los datos en condiciones. O porque los sistemas no están preparados. O porque te faltan permisos, o integraciones, o formación. Y esos previos, esos «ya lo haremos», pueden llevar meses.

Lo he visto más de una vez: la prueba de concepto en sí era facilísima, pero el trabajo para dejar todo listo por debajo era otro cantar. Si decides que no te interesa, perfecto. Pero si el mercado sí lo lanza y tú no puedes, vas con el pie cambiado. Y duele.

Moraleja

La innovación no es un gasto caprichoso, es una forma de asegurarte de que cuando llegue el momento, tengas tu talla. Porque lo que duele no es haber hecho una PoC que no llega a nada… es necesitar algo y no tenerlo ni por asomo.


¿Te ha pasado algo parecido? Me encantaría leerlo en LinkedIn 😉

Diseñado en la cabeza de Iñigo, made in ChatGPT es también innovación y usar una herramienta para facilitarte el trabajo es como ir de rebajas, obtienes lo mismo por menos precio. Y si le pides que te genere una imagen con el prompt es español, igual la chica tiene seis dedos…

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

¿Quién entrena a tu IA? La nueva guerra del conocimiento

Dos personas encajan piezas de puzzle translúcidas con borde naranja en la cabeza de un robot sobre una mesa de cristal; estanterías azul oscuro al fondo. Metáfora de quién entrena la IA.

Hace unos años, cuando llegaba un nuevo programador al equipo, lo normal era darle un portátil, acceso al repo y un documento de onboarding que nadie había leído desde 2015. A partir de ahí, a remar. Tareas sencillas, mucho copy-paste, y a ver si con el tiempo aprendía algo entre commits. Esto era así en muchas consultoras. Y funcionaba… más o menos.

La IA como junior eterno (que no se va a otra empresa)

Creo que estamos ante una disrupción silenciosa. Me explico:

Al principio, la IA se va a parecer mucho a un perfil junior. Uno que no cobra, no se queja y no se va con la competencia cuando le ofrecen un poco más. Le puedes encargar tareas repetitivas, simples, y poco a poco va mejorando. Pero no porque “aprenda”, sino porque tú, o alguien, le vas dando más contexto, más ejemplos, más datos. En definitiva: lo entrenas.

Ahora bien, en los humanos está claro: si te vas, el conocimiento que tienes se va contigo. Pero con una IA, la pregunta se vuelve jugosa: ¿quién es el dueño del conocimiento que va acumulando?

Y aquí es donde entra el riesgo: si no defines bien desde el principio cómo y para quién aprende esa IA, puedes estar entrenando gratis a un activo que ni te pertenece ni te protege.

¿Quién entrena al entrenador?

Aquí hay dos modelos que se están empezando a perfilar:

  1. Proveedor-entrenador: tú pones la IA, la entrenas, y eso se convierte en tu ventaja competitiva. Es decir, el valor añadido ya no es solo el equipo humano, sino ese “junior digital” que sabe cómo quiere el cliente sus informes, su código, su documentación. Y eso no se lleva el cliente si decide cambiarte por otro proveedor más barato. Touché.
  2. Cliente-propietario: el cliente pone la IA, asume el coste y la entrena según sus procesos. Así, si cambia de proveedor, el conocimiento no se pierde. Porque está en su “junior digital”, que no se va con nadie, ni le ficha otra consultora.

Un nuevo campo de batalla: la propiedad del conocimiento

Este escenario cambia muchas cosas:

  • La lógica de fidelización de clientes.
  • El rol de los proveedores.
  • La propia estructura de costes del conocimiento.

Y todavía no tenemos todas las respuestas. Solo sé que estamos en un punto similar a cuando empezamos a usar máquinas virtuales y se rompieron muchos esquemas. Esto va a ser igual.

No es solo una cuestión técnica, es estratégica: quien entrena mal, replica errores. Y quien entrena sin marco, entrega ventaja competitiva sin saberlo.

Moraleja

Si vas a introducir IA en tus procesos, pregúntate desde ya: ¿quién va a entrenarla? ¿Quién va a pagar ese coste? ¿Y quién se queda con el conocimiento si el proveedor o el cliente cambia?

Aquí es donde entra la paradoja: retener conocimiento solía ser una estrategia… hasta que llegó la IA. Como expliqué en mi artículo [Cuando esconder el conocimiento ya no es estrategia] —donde planteo si tu saber vive solo en ti o también en una IA—, esa dinámica está cambiando radicalmente.


¿Tú cómo lo ves? ¿Quién debería quedarse con el conocimiento en la era IA? Me encantará leerte en LinkedIn.

Diseñado en la cabeza de Iñigo, made in ChatGPT, de momento el conocimiento lo tengo yo, ya veremos por cuanto tiempo 🤷‍♂️

¿Y tú, en qué sigues siendo mejor que la IA?

Hace unos días estaba revisando código con un compañero. Había dejado un fragmento que, como diría cualquier auditor de ISO o CMMI con media sonrisa, “tiene margen de mejora”. Me acerqué, y le dije tranquilamente: “Este trocito… me ha dicho el Sonar que necesita un poco de cariño, ¿puedes encargarte?”. Sin más pistas.

🧠 Deja que piensen. Crecen más.

Creo que a la gente hay que darle espacio para pensar. Me explico: si te dan la solución mascadita, no desarrollas el “olfato técnico”, que es lo que más vale a medio plazo, creo que es parte del mentoring. Y efectivamente, al cabo de un par de días, me encuentro que el compañero había refactorizado el código tal como yo lo habría hecho… ¡y con algún truquito del lenguaje que yo ni conocía! Para nota. 🤯

Cuando le pregunté, me dijo que había tirado de ChatGPT. Y ahí fue cuando me saltó la reflexión.

⚙️ La IA ya compite contigo… y lo hace por 20 pavos al mes.

Siempre he tenido claro que si quieres ganar más, no puedes estar al mismo nivel que un junior recién aterrizado. Tienes que subir escalones: más conocimiento, más criterio, más responsabilidad.

Pero ahora ya no es solo competir contra gente que cobra menos… es que compites contra cacharros que trabajan 24/7, que no piden vacaciones y que, encima, aprenden rápido y cuestan cuatro duros.

Estas cosas suelen gustar al negocio, pero…

🎯 ¿Qué aportas tú que no pueda hacer una IA?

Hay que ir haciendo el ejercicio (incómodo, pero necesario) de tachar tareas en las que ya no aportas valor diferencial. Lo que quede en blanco, eso eres tú. Y si la lista empieza a encogerse… toca reinventarse. No es postureo de gurú de LinkedIn. Es pura supervivencia profesional.

Moraleja

No luches contra la IA. Lucha por seguir siendo útil. No se trata de ser más rápido que la máquina, sino más humano, más estratégico, más versátil. Si sabes en qué destacas, no hay algoritmo que te tumbe.


👀 Si te has quedado con ganas de profundizar, echa un vistazo a «Productividad: de programadores junior a IAs» (un manual de cómo cuadricular tu trabajo para que incluso un LLM rinda), a «Cuando tu radar profesional se queda sin señal» (ideal para recalibrar el hype-metro) ¡Luego me cuentas en LinkedIn qué te ha resonado!

Este artículo ha sido Diseñado en la cabeza de Iñigo, made in ChatGPT y sí, en algunas cosas la IA es mejor que yo, que tampoco era muy difícil.

¿Que es la innovación?

Fotografía realista, formato horizontal 16:9, oficina luminosa y moderna. En primer plano, una ingeniera joven —protagonista femenina, piel morena— explica ideas en un cristal con post-its de colores y diagramas de flujo. A su alrededor, equipo diverso (mujer asiática, hombre afrodescendiente, hombre caucásico) escuchando y tomando notas en tablets. Sobre la mesa, prototipos y herramientas sencillas que sugieren mejoras incrementales, mientras en segundo plano se proyectan sutilmente iconos holográficos que insinúan soluciones disruptivas. Sin logotipos ni marcas visibles. Estilo fotográfico limpio, colores cálidos y mucha luz natural.

En la anterior ocasión ya hablamos de que, en realidad, la innovación es la modernización de unas prácticas muy comunes desde hace mucho tiempo. Pero ¿qué es realmente la innovación? Podemos preguntarle a ChatGPT y lo que nos dice es lo siguiente:

«La innovación es el proceso de introducir nuevas ideas, métodos, productos o servicios que resultan en mejoras significativas o cambios positivos en diversas áreas. Puede ocurrir en distintos contextos, tales como tecnología, negocios, educación, salud y muchos otros. La innovación puede implicar la creación de algo completamente nuevo (innovación disruptiva) o la mejora de algo existente (innovación incremental).»

Pero ¿Que es la innovación?

La experiencia que he adquirido me hace ser de la misma opinión y me gustaría compartirte algunas reflexiones que se desprenden de esta definición.

Como la innovación supone algo nuevo o, al menos, una mejora, implica que para cada persona u organización «innovador» puede significar cosas distintas. Me explico: supongamos que una empresa gestiona sus proyectos con una metodología clásica en cascada; implantar una metodología más moderna basada en el agilismo le supondría una mejora y, consecuentemente, sería innovación. En cambio, para otra empresa del mismo sector que ya utilice agilismo no habría mejora y, por tanto, el agilismo no sería innovador. En definitiva, tú defines qué es innovador para ti.

El concepto de que algo suponga una mejora significativa es muy amplio, así que casi cualquier cosa puede ser innovadora. Por ejemplo, si un equipo desarrolla una aplicación de software sobre una versión de un lenguaje de programación y la migra a una versión superior que le permite mejorar su productividad gracias a las nuevas características del lenguaje, también se consideraría innovación. Eso es una suerte podrás seguir haciendo lo de siempre y decir que eres innovador… 😉 o no.

Que es la innovación para mi

Con esta definición prácticamente todo encaja dentro de la innovación, pero para mí lo que marca la diferencia a la hora de considerar si una empresa es innovadora o no es el hecho de si tiene un proceso de innovación definido, sistematizado y auditado… o si, simplemente, son unos colegas haciendo una prueba mientras se toman un café de máquina en la oficina.

Innovación disruptiva vs incremental

Creo que es esencial interiorizar que la innovación no tiene que ser necesariamente disruptiva; es decir, no tiene por qué poner patas arriba tu empresa o tu sector. Puede ser perfectamente incremental, con pequeñas mejoras, porque esto suele alejar a demasiadas personas de la innovación y si es el negocio que suele ser el patrocinador, tienes un problema.

Si lo tuviésemos todo claro, no sería innovación: sería un proyecto

Moraleja

Al final, innovar no es saltar al vacío, sino acotar riesgos y aprender deprisa.


¿Conoces mucha gente que piensa que la innovación debería ser disruptiva? Cuéntamelo en LinkedIn; me encantará conocer tu visión.

Diseñado en la cabeza de Iñigo, made in ChatGPT también es innovación.

SonarQube, uso desde eclipse

Segunda entrada sobre el SonarQube, en este caso y a diferencia de la primera entrega, en la que vimos la instalación y primer uso, en esa ocasión vamos a ver el uso desde el entorno de desarrollo Eclipse.

Este tipo de herramientas son muy útiles para tener un cierto control sobre el código fuente de nuestros desarrollos.

Pueden llegar a ser un poco delicados si se abusa del número de reglas que apliquemos, pero con una configuración inteligente puede resultar una herramienta muy útil.

Os dejo el vídeo.

Cadena de suministro de Software

Lo primero decir que me encanta la imagen destacada de esta entrada. Primero porque representa una cadena y segundo porque me parece muy bonita estéticamente hablando.

El concepto de cadena de suministro de Software no es muy usado, está mas de moda el de devops. Pero a mi la verdad es que el de devops no me gusta tanto, porque hace referencia a desarrolladores y operadores y prefiero utilizar el de cadena de suministro de software, como hacen referencia en Nexus de Sonatype.

Me gusta mas porque desde que nuestro cliente tiene una necesidad, hasta que esa necesidad se pone en producción en forma de un programa, hay que pasar por una serie de fases o una cadena para suministrar ese Software.

Por eso me gusta mas, porque creo que representa mejor lo que pasa, pero claro devops es un nombre mas cortito.

Os dejo bastantes reflexiones mas sobre este concepto en el vídeo