La inteligencia artificial generativa ha cambiado radicalmente la forma de desarrollar software. Hoy podemos pedirle que construya una interfaz, una API, un panel de administración o incluso una aplicación completa en una fracción del tiempo que antes necesitábamos.

Es un avance importante. El problema aparece cuando confundimos la capacidad de generar código con la capacidad de diseñar software.

Una aplicación puede arrancar, mostrar gráficos atractivos y responder a los clics del usuario. Eso no demuestra que su arquitectura tenga sentido, que los datos estén bien modelados o que el sistema vaya a comportarse correctamente cuando aparezcan situaciones reales.

01. La fábrica de aplicaciones instantáneas

Una petición a un asistente generativo puede producir en minutos una aplicación con autenticación, formularios, paneles, gráficos y persistencia de datos. La demostración puede resultar convincente. Pero la velocidad de generación no sustituye las fases de análisis, diseño, pruebas y revisión.

En un proyecto serio hay que entender quién utilizará el sistema, qué información manejará, qué reglas no se pueden incumplir, qué riesgos existen y cómo se mantendrá el producto. Si esas preguntas no se responden, la herramienta puede limitarse a convertir una descripción incompleta en una implementación igualmente incompleta.

02. El síndrome del stack tecnológico

Imaginemos una clínica dental. Necesita gestionar pacientes, profesionales, citas, tratamientos, facturas, pagos y quizá historiales clínicos. Son entidades con relaciones claras y reglas de negocio importantes.

¿Se puede construir con MongoDB? Sí. ¿Significa eso que sea la elección más adecuada por defecto? No. PostgreSQL o MySQL ofrecen un modelo relacional con claves primarias, claves foráneas, restricciones y transacciones que encaja de forma natural con muchos de esos requisitos.

MongoDB, por su parte, es una base de datos documental con un modelo flexible. Su propia documentación recomienda modelar los datos según los patrones de acceso de la aplicación: los datos que se consultan juntos pueden almacenarse juntos, y las relaciones pueden representarse mediante documentos embebidos o referencias. Es una estrategia válida cuando responde al dominio y a las consultas previstas.

La crítica no es «MongoDB es malo». La crítica es elegir cualquier tecnología por costumbre, moda o porque apareció en el tutorial de turno, sin justificar cómo resuelve las necesidades concretas del proyecto.

La doble reserva: una pequeña prueba de realidad

Dos pacientes intentan reservar al mismo odontólogo a las 10:30. Ambos consultan la disponibilidad casi al mismo tiempo. Si el sistema se limita a preguntar «¿está libre?» y después inserta la cita, las dos peticiones podrían observar el mismo estado inicial. Es una condición de carrera.

La solución no consiste en confiar en que el frontend desactive un botón a tiempo. La regla debe protegerse en el servidor y, cuando sea posible, también en la propia base de datos.

PostgreSQL dispone de restricciones de exclusión (EXCLUDE) que permiten impedir solapamientos entre rangos. GiST es el método de índice que puede respaldar esa restricción; con btree_gist se puede combinar la igualdad del identificador del profesional con el solapamiento del intervalo temporal.

CREATE EXTENSION IF NOT EXISTS btree_gist;

CREATE TABLE citas (
    id BIGSERIAL PRIMARY KEY,
    odontologo_id INTEGER NOT NULL,
    inicio TIMESTAMPTZ NOT NULL,
    fin TIMESTAMPTZ NOT NULL,
    CHECK (fin > inicio),
    EXCLUDE USING gist (
        odontologo_id WITH =,
        tstzrange(inicio, fin, '[)') WITH &&
    )
);

El intervalo [) incluye el inicio y excluye el final: una cita de 10:00 a 10:30 puede ir seguida de otra de 10:30 a 11:00. El ejemplo requiere que la extensión btree_gist esté disponible en la instalación.

¿MongoDB puede gestionar reservas concurrentes? También se pueden diseñar soluciones con índices únicos, transacciones y un modelo de reservas adecuado. Lo que no ofrece es una restricción de exclusión temporal equivalente, declarada de la misma manera que en PostgreSQL. Esa diferencia importa al comparar cuánto trabajo adicional exige cada diseño para garantizar la regla.

03. Cuando la demo funciona, pero el sistema falla

El software real no se prueba únicamente en el camino feliz. Hay que preguntarse qué ocurre cuando dos usuarios actualizan el mismo registro, cuando una operación se interrumpe, cuando una petición se repite, cuando faltan datos o cuando un usuario intenta acceder a algo que no le corresponde.

Una interfaz atractiva no demuestra que exista integridad referencial. Una pantalla de inicio de sesión no demuestra que la autorización esté bien implementada. Y una operación que funciona una vez no demuestra que sea segura frente a concurrencia.

La calidad de un sistema depende también de sus límites, sus invariantes, su comportamiento ante errores y la facilidad con la que otros desarrolladores podrán mantenerlo.

04. El desarrollador convertido en operador de prompts

La IAG puede explicar algoritmos, generar pruebas, sugerir arquitecturas, detectar errores y acelerar tareas repetitivas. Utilizada con conocimiento, es una herramienta muy potente.

Pero delegar la escritura de código no debería significar delegar el criterio. Quien desarrolla sigue teniendo que revisar lo generado, comprender sus implicaciones y comprobar que cumple los requisitos.

Saber formular una petición no equivale a dominar modelado de datos, concurrencia, seguridad, estructuras de datos o diseño de sistemas. La herramienta puede producir una implementación convincente de una solución equivocada.

05. La paradoja de la productividad

La productividad no debería medirse solo por líneas de código generadas, pantallas terminadas o aplicaciones publicadas. También importa cuánto trabajo se evita, cuántos errores se previenen y cuánto costará mantener lo construido dentro de dos o tres años.

06. El problema no es la inteligencia artificial

Sería un error concluir que las herramientas generativas son perjudiciales o que debemos renunciar a ellas. Pueden ayudar a explorar alternativas, automatizar tareas, acelerar prototipos y mejorar la productividad de equipos con experiencia.

Pero no convierten automáticamente una mala decisión arquitectónica en una buena. Tampoco eliminan la necesidad de pruebas, revisión humana, documentación y responsabilidad sobre el resultado.