Para quién construimos software en la era de la IA

Poco a poco estamos dejando de darle relevancia al hecho de que usamos inteligencia artificial para programar. A estas alturas es casi como anunciar que tenemos electricidad en la oficina: está, se da por hecho, y contarlo ya no impresiona a nadie. Lo interesante ya no es cómo construimos el software, sino para quién lo construimos.

Y ese “para quién” acaba de cambiar y es la diferencia de cómo se utilizará tu software en el futuro. Ha aparecido un segundo usuario, y no es tu cliente, al menos tu cliente "humano".

Durante décadas diseñamos productos para lo mismo: una persona delante de una pantalla, con su ratón y sus ganas. Llegaron los móviles y las tabletas y cambiamos el ratón por el dedo, pero el guion de fondo no se movió: al otro lado siempre había un humano mirando una pantalla. Ese usuario sigue ahí. Lo nuevo es que ahora tiene compañía: un agente de inteligencia artificial que quiere usar tu producto sin pantalla, sin ratón y sin que nadie le explique nada.

Y si tu aplicación solo sabe comunicarse a través de su interfaz visual, ese segundo usuario se queda en la puerta.

AI-first no es ponerle un chat a las cosas

Conviene aclararlo, porque “AI-first” se ha convertido en una pegatina que muchos colocan sobre lo de siempre. Le añaden un chatbot en una esquina, lo llaman revolución y a otra cosa. Para nosotros, AI-first es algo bastante menos vistoso y bastante más profundo: tener en cuenta a la inteligencia artificial desde el diseño de la arquitectura, no al final.

Significa diseñar primero el núcleo (la lógica de negocio y los datos) y tratar la interfaz visual como una más de las formas de acceder a ese núcleo, no como la única. Y no hace falta creernos: basta mirar hacia dónde se dirigen los grandes. Salesforce es un ejemplo de manual. En 2024 lanzó Agentforce, su plataforma de agentes, pero lo gordo de verdad vino después: está rediseñando la casa entera para que esos agentes operen el CRM por su cuenta. Hasta publicó a finales de 2025 un benchmark para medir cómo se les da hacerlo a base de clics y pantallas, igual que una persona. ¿El resultado? Incluso los mejores agentes fallan más de la mitad de las veces cuando les toca pelearse con una interfaz visual. La conclusión está clara: si quieres que un agente trabaje, no lo puedes sentar delante de tu pantalla, dale acceso a la lógica de debajo.

Hay una señal que lo resume mejor que ninguna. A finales de 2024, Anthropic publicó un protocolo abierto, el MCP (Model Context Protocol), para que los agentes puedan hablar con cualquier herramienta. En menos de seis meses lo adoptaron también OpenAI, Google y Microsoft. Que cuatro empresas que compiten a muerte se pongan de acuerdo tan rápido no suele pasar a menudo.

Tres cimientos que ponemos desde el principio

Cuando decimos “desde la arquitectura”, no es palabrería. Hay tres piezas que intentamos dejar puestas de base, no parchear después.

La primera es una API bien documentada. Es el contrato del producto: lo que se puede pedir, lo que se recibe y bajo qué reglas. Si está bien explicada, da igual quién llame a la puerta (una persona, otro servicio o un agente): todos entienden el idioma. Una API sin documentación es una conversación a oscuras.

La segunda es una interfaz de línea de comandos, una CLI.

La CLI es un mecanismo bastante antiguo para hablar con una aplicación: abres un terminal (esa pantalla negra de las películas de hackers), escribes una orden, pulsas enter y listo. La dimos por jubilada cuando llegaron las ventanas y el ratón, pero resulta que a los agentes de IA les va como anillo al dedo.

Suena retro, lo sabemos, pero es justo lo contrario. Todo lo que un humano puede hacer escribiendo un comando, un agente lo puede automatizar igual. El truco está en que hable dos idiomas a la vez: una salida legible para las personas y otra estructurada, en JSON, para las máquinas. Mismo comando, dos lectores.

La tercera, en la que estamos trabajando ahora mismo, es el MCP del que hablábamos antes. Es la puerta nativa para que un agente use tu producto como una herramienta más, sin tener que adivinar cómo funciona. En lugar de explicarle a la IA cómo es tu API, le das un protocolo que ya entiende.

Aquí no vamos a fingir que lo tenemos resuelto: estamos en plena construcción, aprendiendo a la vez que lo levantamos. Pero tenemos clarísimo que es por ahí por donde va el camino.

Cómo se ve esto en un proyecto de verdad

Todo esto suena muy bonito en un artículo. La pregunta sincera es si solo evangelizamos o ya lo estamos utilizando. Ahora mismo lo estamos llevando a la práctica en un proyecto grande para un cliente, una plataforma de gestión con bastante recorrido por delante.

Sin entrar en las tripas, el orden de las cosas lo dice todo: empezamos por el núcleo y por una API que lo expone con claridad, montamos una CLI para operarlo sin tocar la interfaz, metimos la inteligencia artificial dentro del producto (no como decoración, sino para tareas reales: digerir información que llega en distintos formatos, sugerir decisiones a partir del histórico) y mantenemos la documentación técnica viva, como una base de conocimiento que humanos y agentes consultan por igual. El siguiente hito es precisamente abrir esa puerta MCP nativa. No está terminado. Pero lo estará pronto, y con ello el proyecto hablará desde el primer momento el lenguaje del futuro.

Construir hoy para el usuario que llega mañana

Construir así cuesta un poco más al principio, no lo vamos a negar. Siempre es más cómodo montar la pantalla bonita y dejar el resto para luego. Pero “luego” tiene la fea costumbre de convertirse en “rehacerlo entero”. Y ese segundo usuario, el agente que quiere manejar tu producto por su cuenta, va a aparecer antes de lo que crees. Nosotros preferimos que nos pille con la mesa puesta.

Si tienes un producto y te ronda la cabeza cómo prepararlo para el futuro, o simplemente quieres que alguien te diga, sin venderte humo, por dónde empezar, escríbenos. Puede ser el inicio de una conversación interesante (y de las que no te va a resolver un chatbot).