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.
Publicado el por Iñigo Serrano

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

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