Introducción
Durante los últimos años hemos visto una explosión de herramientas basadas en Inteligencia Artificial. Cada semana aparecen nuevos modelos, agentes, frameworks y promesas sobre cómo la IA cambiará por completo la forma en que desarrollamos software.
Sin embargo, después de trabajar en proyectos reales, llegué a una conclusión diferente.
La IA genera valor cuando resuelve problemas concretos del negocio y cuando mejora la productividad de los equipos de ingeniería. Todo lo demás es ruido.
En uno de los proyectos que lideré tuvimos la oportunidad de comprobarlo desde dos perspectivas diferentes: utilizando IA para mejorar la experiencia de los usuarios finales mediante una solución RAG y utilizando IA para acelerar el desarrollo de software mediante Specification-Driven Development (SDD) y OpenSpec.
Ambas iniciativas tenían un objetivo común: generar resultados medibles sin sacrificar la calidad técnica.
El problema: un buscador tradicional había llegado a su límite
Uno de nuestros clientes contaba con un buscador basado en Apache Solr.
El motor cumplía correctamente su función cuando los usuarios conocían exactamente las palabras clave que debían utilizar. Sin embargo, la experiencia comenzaba a deteriorarse cuando las consultas eran más naturales o estaban formuladas como preguntas.
Un usuario no siempre busca utilizando el nombre exacto de un producto, un servicio o una sección del sitio.
Muchas veces simplemente pregunta:
- ¿Cómo puedo realizar determinado trámite?
- ¿Qué requisitos necesito para...?
- ¿Dónde encuentro información sobre...?
En ese escenario un buscador tradicional basado únicamente en coincidencias de texto empieza a mostrar sus limitaciones.
El reto consistía en ofrecer una experiencia conversacional sin perder el control sobre la información que podía responder el sistema.
Diseñando una arquitectura RAG para un entorno empresarial
Antes de escribir una sola línea de código dedicamos tiempo al diseño de la solución.
Como ocurre con cualquier proyecto de arquitectura, la tecnología era solo una parte del problema.
Había que responder preguntas como:
- ¿Cómo garantizar que las respuestas provinieran únicamente del contenido autorizado?
- ¿Cómo reducir las alucinaciones del modelo?
- ¿Cómo mantener actualizado el conocimiento?
- ¿Cómo integrar la solución con la plataforma existente?
- ¿Cómo asegurar una experiencia de usuario intuitiva?
A partir de estas preguntas definimos una arquitectura basada en Retrieval-Augmented Generation (RAG), separando claramente cada responsabilidad dentro de la solución.
La arquitectura quedó compuesta por varios componentes principales:
- Procesamiento del contenido del sitio.
- Generación de embeddings.
- Base de datos vectorial para recuperación semántica.
- Integración con un modelo de lenguaje (LLM).
- Ingeniería de prompts para controlar el comportamiento del asistente.
- Integración con la interfaz del nuevo buscador.
Este enfoque permitió construir una solución desacoplada y preparada para evolucionar con el tiempo.
Más que un chatbot: un buscador con comprensión semántica
El objetivo nunca fue construir un chatbot genérico.
La prioridad era mejorar la búsqueda de información dentro del sitio.
Para lograrlo implementamos un proceso donde cada documento del portal era transformado en embeddings, permitiendo representar su significado semántico más allá de las palabras exactas.
Cuando un usuario realizaba una consulta, el sistema seguía un flujo como el siguiente:
- Interpretar la intención mediante un LLM.
- Convertir la consulta en un embedding.
- Buscar los documentos más relevantes dentro de la base vectorial.
- Construir un contexto únicamente con esa información.
- Generar una respuesta utilizando exclusivamente ese contexto.
Este patrón permitió que el modelo respondiera utilizando únicamente información disponible dentro del sitio.
Reduciendo las alucinaciones
Uno de los mayores desafíos al trabajar con modelos de lenguaje es controlar sus respuestas.
En aplicaciones empresariales no basta con obtener respuestas creativas.
Las respuestas deben ser correctas.
Durante el proyecto dedicamos una parte importante del trabajo al refinamiento de prompts para establecer reglas claras de comportamiento.
Entre ellas:
- responder únicamente utilizando el contexto recuperado;
- indicar cuando no existía suficiente información;
- evitar responder preguntas ajenas al dominio del sitio;
- mantener un tono consistente con la organización;
- limitar respuestas ambiguas o especulativas.
Este proceso fue tan importante como la integración del propio modelo de lenguaje.
La calidad de una solución RAG depende tanto de la arquitectura como de las reglas que gobiernan al modelo.
La experiencia del usuario también hace parte de la arquitectura
La implementación técnica fue solo una parte del proyecto.
También trabajamos junto al equipo de UX/UI para rediseñar completamente la experiencia del buscador.
El objetivo era que la interacción fuera natural para usuarios acostumbrados a asistentes conversacionales, sin perder la simplicidad de un buscador tradicional.
Una buena solución de IA no solo necesita buenos modelos.
Necesita una experiencia de usuario que inspire confianza.
IA para usuarios... e IA para desarrolladores
Mientras el equipo desarrollaba la solución RAG, surgió otra pregunta interesante.
Si la IA podía ayudar a los usuarios finales, ¿por qué no utilizarla también para mejorar nuestra forma de desarrollar software?
Fue entonces cuando comenzamos a incorporar IA dentro del propio proceso de ingeniería.
No como reemplazo de los desarrolladores.
Como acelerador del trabajo.
Specification-Driven Development
Uno de los cambios más importantes fue adoptar un enfoque basado en Specification-Driven Development (SDD).
En lugar de comenzar desarrollando funcionalidades directamente, primero construíamos especificaciones claras que definían:
- objetivos de negocio;
- reglas funcionales;
- restricciones técnicas;
- criterios de aceptación;
- decisiones de arquitectura;
- dependencias.
Estas especificaciones se convirtieron en la fuente principal de conocimiento para todo el equipo y para los asistentes de IA utilizados durante el desarrollo.
OpenSpec como organizador del proceso
Para estructurar el flujo de trabajo utilizamos OpenSpec.
El concepto de Vertical Slice se convirtió en la unidad principal de desarrollo.
Cada tarea representaba una funcionalidad completa, desde la definición del problema hasta su implementación y validación.
Este enfoque permitió mantener un contexto mucho más claro tanto para el equipo como para las herramientas de IA.
En lugar de generar código aislado, cada interacción seguía una secuencia bien definida:
- comprender el requerimiento;
- analizar las especificaciones;
- construir un plan;
- implementar la solución;
- validar resultados;
- actualizar el estado del trabajo.
La IA dejó de ser un simple generador de código para convertirse en un asistente que entendía el contexto completo del proyecto.
Documentación como contexto para la IA
Otro aprendizaje importante fue que una IA solo puede ser tan útil como el contexto que recibe.
Por esta razón organizamos el conocimiento del proyecto mediante una estructura de archivos Markdown donde documentábamos aspectos como:
- decisiones de arquitectura;
- estándares de desarrollo;
- convenciones del proyecto;
- reglas de negocio;
- habilidades requeridas;
- patrones reutilizables;
- lineamientos técnicos.
Esta documentación no solo ayudaba a nuevos integrantes del equipo.
También proporcionaba contexto consistente para los asistentes de IA.
Automatizando tareas repetitivas
A medida que el proceso maduraba comenzamos a integrar diferentes herramientas mediante MCP (Model Context Protocol).
Esto permitió automatizar actividades como:
- análisis inicial de tareas;
- generación de planes de trabajo;
- consulta de especificaciones;
- apoyo en la maquetación de componentes;
- seguimiento del flujo de desarrollo;
- actualización del estado de los tickets.
La automatización permitió reducir tareas repetitivas y dedicar más tiempo a decisiones que realmente requieren criterio técnico.
La supervisión humana sigue siendo indispensable
Aunque la IA aceleró muchas actividades, nunca dejamos que las decisiones importantes fueran completamente automáticas.
La revisión humana siguió siendo una parte obligatoria del proceso.
Las decisiones de arquitectura, las revisiones de código, la validación funcional y la aceptación de cambios continuaron siendo responsabilidad del equipo.
La IA aceleraba el desarrollo.
La calidad seguía siendo responsabilidad de las personas.
Reflexión final
Después de participar en estos proyectos confirmé algo que hoy considero fundamental.
La verdadera transformación no consiste en incorporar un modelo de lenguaje porque está de moda.
Consiste en identificar dónde la IA puede aportar valor real.
En nuestro caso, ese valor apareció en dos frentes muy distintos.
Por un lado, mejoramos la experiencia de búsqueda mediante una arquitectura RAG capaz de comprender preguntas en lenguaje natural y responder utilizando únicamente información autorizada.
Por otro, transformamos nuestro propio proceso de desarrollo utilizando Specification-Driven Development, OpenSpec, documentación estructurada y asistentes de IA para reducir retrabajo y aumentar la productividad del equipo.
En ambos casos la tecnología fue un medio, no el objetivo.
Porque al final, la mejor implementación de Inteligencia Artificial no es la que utiliza el modelo más grande, sino la que ayuda a las personas a tomar mejores decisiones, construir mejor software y entregar más valor al negocio.