Cinco decisiones de ingeniería que hay que tomar antes de generar código con IA

El ingeniero toma decisiones, unas veces dentro del código y otras antes de escribirlo. Si la primera pregunta se le plantea a la IA de inmediato, el resultado funcionará, pero su coste se disparará ya en el segundo lanzamiento.

Vibecoding vs. trabajo de ingeniería

El vibecoding es un proceso en el que la persona describe el resultado deseado, pide ajustes según lo que observa y, cuando la pantalla funciona, se detiene. El trabajo de ingeniería con IA incluye además las restricciones del sistema existente, los cambios admisibles, las condiciones de fallo y las formas de verificación. El código puede generarse en ambos casos. La diferencia está en qué decisiones se toman de forma consciente.

No se trata de niveles de experiencia: un desarrollador principiante puede trabajar del segundo modo, y uno experimentado, del primero. Lo que importa es la experiencia convertida en comprensión de las dependencias. Cuando ya has tenido que revertir un lanzamiento o has tenido que analizar un registro concurrente en una base de datos, en una tarea nueva surgen por sí solas preguntas adicionales, antes del código y antes del primer defecto.

Para un prototipo puede bastar una verificación visual. Para un servicio con usuarios reales, la petición de "añade una función más" ya modifica un sistema en funcionamiento, y su coste no se reduce al tiempo de generación.

Cinco decisiones antes de la primera línea de código

1. Integraciones: definir el límite del contrato externo

En un producto en funcionamiento, esto suele traducirse en tres servicios independientes: A recibe los datos del proveedor, B implementa la regla de negocio y C muestra el resultado. Si el formato externo se filtra en las tres partes, un nuevo proveedor implica modificar A, B y C al mismo tiempo. Si A transforma los datos a un contrato interno, un nuevo proveedor solo requiere un nuevo adaptador, y B y C no cambian.

Ejemplo: un catálogo de juegos con dos fuentes. La primera describe el juego como `{id, name}`, la segunda como `{code, title}`. El enfoque incorrecto es que los consumidores conozcan ambos formatos y elijan el campo según el tipo de fuente. Cada nuevo proveedor añade una nueva rama en cada función, y en un año nadie sabrá decir cuántos lugares hay que modificar. El enfoque correcto es que los adaptadores transformen los datos a un contrato común `{key, title}`, de modo que los consumidores no sepan nada del proveedor. Añadir una nueva fuente no exige una regresión de todo el sistema.

2. Plataforma multimarca: definir los límites de la variabilidad

Cada marca de la plataforma era un producto independiente, no una copia de una plantilla con otro logotipo. Tenían sus propias licencias, mercados, equipos de producto y calendarios de lanzamiento. Había que desarrollarlas todas sobre una única base de código, conservando las diferencias reales.

El modelo inicial parecía suficiente: un tema base, que cada marca concreta podía sobrescribir. Las sobrescrituras fueron más allá de los colores. Una misma tarea se resolvía de forma distinta en varios lugares, las particularidades locales se acumulaban y la coherencia del estilo se perdía.

Hubo que pasar a mixins de SCSS, cuyas rutas se resolvían en el contexto de cada marca durante la compilación. Para productos ya en funcionamiento, esa transición resultó más costosa que elegir el modelo adecuado desde el principio.

3–5. Operaciones concurrentes, topología y garantías de entrega

Una recarga de saldo con dos reintentos simultáneos requiere que el efecto sea único y que existan límites transaccionales claros. Un mensaje de chat tras un reinicio requiere una topología de almacenamiento y de recuperación. La eliminación de datos antiguos ante un retraso de la tarea requiere un tiempo de vida definido y una reejecución segura. Un lanzamiento listo para producción requiere señales del escenario de negocio y condiciones de parada.

La experiencia no se traduce en puntos dentro del prompt, sino en preguntas concretas en el planteamiento. La longitud del prompt, por sí sola, no aporta nada. Si la tarea es local y reversible, el planteamiento puede ser breve. Si afecta a un contrato compartido, a un saldo o a permisos, un par de aclaraciones previas a la implementación cambian el modelo de datos, la transacción y el escenario de prueba.