Introducción
En el panorama en constante evolución del desarrollo de software, hemos visto cambios significativos en cómo las aplicaciones se comunican e interactúan. Desde los primeros días de las arquitecturas monolíticas hasta el auge de los microservicios, cada evolución tenía como objetivo hacer el software más eficiente y fácil de usar. Sin embargo, a medida que la tecnología avanza, también lo hace la complejidad de las interacciones.
Aquí es donde entran en juego las Interfaces Conversacionales de Aplicación (ACIs), y me gustaría compartir algunos pensamientos sobre un nuevo paradigma que podría reducir la carga cognitiva y hacer que la interacción con el software sea más intuitiva que nunca.
Los Large Language Models están transformando la forma en que interactuamos con la tecnología. Estamos entrando en una era donde comunicarse con las máquinas es tan natural como conversar con un colega. Los usuarios ahora pueden expresar sus necesidades en lenguaje cotidiano, y los sistemas responden en consecuencia. Y esta es la base de las ACIs.
Esta propuesta no es solo una actualización tecnológica, es un cambio de paradigma que también plantea preguntas profundas: ¿cómo remodelará esto la experiencia para usuarios, desarrolladores y agentes de IA?
La interfaz que se disuelve
En una era donde los LLMs pueden responder con texto, formatos estructurados, imágenes, voz o incluso código que genera interfaces visuales dinámicas, debemos preguntarnos: ¿cuánto tiempo más seguiremos construyendo capas entre nosotros y el software? ¿Qué pasaría si dejáramos de desarrollar user interfaces y application programming interfaces tradicionales por completo?
Hoy en día, todo parece converger en una interfaz de prompt o chat. Aunque no todos los problemas se resolverán por estos medios, esto es solo el comienzo. La clave no es la interfaz en sí, sino lo que representa: un cambio fundamental en cómo interactuamos con la tecnología.
Por ejemplo, integrar una API relativamente compleja requiere navegar por una extensa documentación, entender esquemas, respuestas, excepciones; esto no solo consume tiempo valioso, sino que también desvía el enfoque de la construcción de características principales.
Ahora, imagina eludir estas complejidades a través de una interfaz que entiende tu intención mediante lenguaje natural. Aquí es donde podemos ver que la era de las UIs y APIs podría estar evolucionando hacia un nuevo paradigma: las ACIs.
Antes de profundizar en el qué, cómo y por qué de las ACIs, revisemos brevemente el viaje que nos ha llevado a este momento crucial.
Todo es una API
Tracemos la evolución de las APIs para entender por qué fueron inventadas. Inicialmente, cuando teníamos sistemas con algoritmos y estructuras de datos específicos resolviendo problemas en ciertos dominios, era eficiente encapsularlos y exponerlos a través de interfaces - Interfaces de Programación de Aplicaciones (APIs). Para evitar confusiones más adelante, llamemos a estas APIs específicas "APIs de Dominio". Luego, encima de eso, agregamos otra interfaz, una Interfaz de Usuario, que capturaría las intenciones del usuario y las traduciría en llamadas API correspondientes.
En esencia, implementamos una interfaz (UI) para interactuar con otra interfaz (API de Dominio).
Eventualmente, también necesitamos interactuar con programas que se ejecutan en lugares remotos en todo Internet, por lo que nuestras interfaces o incluso nuestros sistemas backend interactuarían con estas interfaces remotas. Y así nuestro viaje de construcción de interfaces nos llevó a donde estamos hoy:
Entonces, todo es una I(nterfaz)... ¿y?
Bueno, no solo todo es una interfaz, sino que cada una opera en un nivel de abstracción diferente, escrita en varios lenguajes, por diversos autores que toman decisiones de diseño distintas (y no siempre coherentes) que responden a casos de uso únicos.
Como desarrolladores, al navegar por toda esta interfaz, pasamos un tiempo considerable moviéndonos a través de las diferentes capas de un sistema y sus dependencias. Esencialmente, estamos traduciendo datos de una interfaz a otra, todo mientras intentamos mantener la vista en nuestra intención original. En muchos casos, implementar correctamente estas interfaces es más desafiante y tedioso que escribir la lógica de dominio real que resuelve el problema!
Una parte sustancial de este esfuerzo se dedica principalmente a los pasos 2 y 3 a continuación:
- Los desarrolladores implementan sistemas backend.
- Los desarrolladores exponen interfaces de programación en esos sistemas backend.
- Los desarrolladores consumen interfaces de programación para construir sistemas backend y/o interfaces de usuario.
- Los usuarios finales interactúan con interfaces de usuario para lograr sus tareas.
Esta complejidad a menudo oscurece nuestro objetivo principal: resolver eficientemente el problema del usuario.
El Amanecer de las Interfaces Generadas Dinámicamente
En los últimos, ¿qué, 16 meses?, hemos observado un avance: aplicaciones LLM como ChatGPT han comenzado a usar acciones que consumen APIs y devuelven datos en múltiples formatos, incluyendo JSON estructurado y código HTML, CSS y JavaScript.
Vemos de nuevo una interfaz de usuario, en este caso, en forma de prompt o chat. Esta es una UI que, como cualquier otra UI, está escrita de antemano por un grupo de ingenieros. Pero esta tiene una característica especial: esta interfaz de prompt genera nuevas interfaces sobre la marcha, particularmente UIs (pero no limitado a ellas, como veremos más adelante).
Hoy puedes pedirle a modelos como Sonnet o ChatGPT que creen interfaces interactivas con entradas y salidas, visualizaciones de gráficos, SVGs, lo que quieras. Combinado con acciones que permiten al modelo conectarse con APIs, esto proporciona al usuario una interfaz de usuario inmediata, bajo demanda y ad-hoc para abordar cualquier tarea particular.
Pero eso no es todo. Con capacidades más potentes de Tool Calling y Structured Output, estas interfaces no solo pueden generar UIs sino también APIs. Devuelven datos en cualquier formato y esquema que especifiques.
Y esto es solo el comienzo.
Las capas que se sientan entre el usuario final y los algoritmos reales que resuelven las necesidades del usuario —las interfaces intermediarias diseñadas para traducir la intención del usuario en llamadas API programáticas— se están volviendo redundantes.
Claro, la mayoría de los humanos son visuales; y las personas visuales todavía quieren dashboards, paneles y botones. Pero el punto no es reemplazar las UIs con Prompts; el punto es en qué se convertirán realmente estas UIs de ahora en adelante, quién tendrá que implementarlas, cuándo y cómo?
¿Es realmente necesario construir una UI lo suficientemente común para atender al usuario promedio? ¿Intentar anticipar casos de uso? ¿Agregar localización para múltiples idiomas? ¿Garantizar la accesibilidad? ¿Siempre limitarse a una interfaz visual?
Todas estas tareas podrían abordarse dinámicamente de una manera que se ajuste mejor a Cada. Único. Usuario.
Estos usuarios pueden recibir exactamente la interfaz que necesitan, mostrando la información precisa que requieren, en un formato que coincida con sus preferencias y necesidades de accesibilidad: visual, audio o texto.
Hacia una Interfaz Única
Con estas capas colapsando y las interfaces siendo generadas dinámicamente sobre la marcha, podemos visualizar una única interfaz que sirva para todos los propósitos:
- Sirve a los desarrolladores que buscan integrar funcionalidad en sus aplicaciones.
- Sirve a los usuarios finales que buscan interactuar directamente con el sistema.
- Sirve a los agentes de IA que realizan tareas o buscan información de forma autónoma.
Llamaría a esta interfaz única una Interfaz Conversacional de Aplicación (ACI).
Aunque su impacto puede ser remotamente comparable a cómo GraphQL cambió las interacciones de API en comparación con REST, las ACIs van mucho más allá al proponer un paradigma completamente nuevo.
Podemos esbozar varias diferencias radicales en comparación con las APIs tradicionales:
Interacción basada en intención
Las ACIs no tienen contratos fijos o preestablecidos, esquemas, métodos o flujos de trabajo precisos. Son basadas en intención en lugar de basadas en llamadas procedurales.
En lugar de llamar a métodos específicos con parámetros predefinidos, los desarrolladores y usuarios pueden expresar sus intenciones en lenguaje natural. Por ejemplo, "Crear una nueva cuenta de usuario con privilegios de administrador" es más intuitivo que construir una o dos llamadas API con el endpoint y los parámetros correctos.
Dado que las ACIs no están limitadas por contratos rígidos, pueden entender y adaptarse a nuevas solicitudes sin requerir actualizaciones explícitas o cambios de versión. Esta flexibilidad reduce la sobrecarga de mantenimiento y acelera los ciclos de desarrollo.
Solo imagina cómo construirías un endpoint de API para convertir nombres en codificación base64, que responda a diversas necesidades del consumidor:
# Llamada simple, podría ser hecha por un cliente ACI o incluso por el usuario final
curl localhost -d "¿Cómo se ve mi nombre en base64? Es John"
Tu nombre "John" en base64 es: Sm9obg==
# Llamada con una respuesta estructurada que puede ser usada por un cliente ACI
curl localhost -d "Escribe un documento JSON con `code: (base64 de 'OpenACI')`"
{"code":"T3BlbkFDSQ=="}
# Llamada con un cuerpo de solicitud JSON y una respuesta JSON
# – no diferente a una API JSON normal (¡podría incluso
# ser usada durante una fase de transición de API a ACI!)
curl localhost -d '{"intent":"convertToBase64","name":"OpenACI"}'
{"name":"OpenACI","base64":"T3BlbkFDSQ=="}
# Llamada con múltiples parámetros (ACI llama al manejador
# de intención múltiples veces - ¡no hay necesidad de cambiar
# la implementación!)
curl localhost -d "Muéstrame una tabla ascii con la representación en base64 de estos nombres: John Connor, Sarah Connor, Kyle Reese"
| Nombre | Base64 |
|---------------|-----------------------|
| John Connor | Sm9obiBDb25ub3I= |
| Sarah Connor | U2FyYWggQ29ubm9y |
| Kyle Reese | S3lsZSBSZWVzZQ== |
Ahora compara la API que imaginaste, con la implementación ACI que realmente respondió a las solicitudes ilustradas arriba:
import { HttpAci } from '@openaci/http';
import { z } from 'zod';
const app = new HttpAci({ llmName: 'gpt-4o-mini' });
const schema = z.object({
name: z.string(),
});
app.intent('Convert name to base64', schema, ({ entities }) => {
const { name } = entities;
return Buffer.from(name).toString('base64');
});
Diseño centrado en el humano
Estas interfaces posicionan a los humanos como los principales consumidores, apoyándolos en cualquier rol, ya sea como usuarios finales o desarrolladores. Esto es crucial: las ACIs sirven a ambos a través del mismo marco conversacional. Esta unificación simplifica la arquitectura y reduce la necesidad de interfaces separadas como UIs o APIs especializadas.
Para los desarrolladores, como se dijo anteriormente, podemos integrar rápidamente funcionalidades sin gastar tiempo aprendiendo una nueva API. Simplemente podemos escribir código cliente que establezca lo que queremos lograr, y la ACI interpreta y ejecuta la intención.
Para los usuarios finales, pueden personalizar su interacción con el sistema sobre la marcha. Por ejemplo, un usuario podría pedir, ya sea por chat o voz, "Muéstrame todos los documentos que creé ayer" sin navegar a través de múltiples pantallas de UI. Las aplicaciones aún podrían ofrecer una UI visual predeterminada, pero los usuarios podrían aprovechar las ACIs para personalizar y adaptar la interfaz a sus necesidades y preferencias, al detalle.
Accesibilidad y conveniencia
Teniendo en cuenta el punto anterior, la accesibilidad es un aspecto fundamental de las ACIs. No solo por inclusividad, sino también por conveniencia. Las ACIs son multilenguaje y multimodales. Al soportar múltiples idiomas y modalidades (texto, voz, visuales), las ACIs hacen que los sistemas sean más accesibles para una diverse gama de usuarios, incluidos aquellos con discapacidades.
Más allá de la interacción humana
A medida que los LLMs continúan evolucionando y los agentes de IA se vuelven más sofisticados, también se convierten en consumidores de ACIs. En este sentido, un consumidor no es solo humano, sino cualquiera capaz de interactuar con estas interfaces usando lenguaje natural. Esto abre posibilidades para sistemas multi-agente distribuidos que pueden colaborar y negociar usando lenguaje natural, aunque lo que probablemente sucederá es que los agentes de IA aprovecharán la flexibilidad de las ACIs para acordar el mejor formato de datos e intercambiarán mensajes de la manera más optimizada sin nuestra intervención.
El Camino por Delante
Las ACIs representan un enfoque transformador para la interacción con el software, alineando la tecnología más estrechamente con los patrones de comunicación humana. Tienen el potencial de reducir la sobrecarga de desarrollo al eliminar la necesidad de múltiples capas intermediarias; definitivamente empoderarán a los usuarios, quienes ganarán acceso directo y personalizado a las capacidades del sistema sin depender de que alguien más piense en una interfaz que podría no satisfacer todas las necesidades o preferencias del usuario. Las ACIs también fomentarán la innovación, ya que con menos barreras para la integración, nuevos servicios y colaboraciones pueden surgir más rápidamente.
Ahora bien, todavía hay un camino por recorrer. Aunque creo que las ACIs podrían implementarse hoy para algunos casos de uso, la realidad es que el rendimiento, incluso para los modelos más rápidos, y las economías de escala, aún tienen que inclinarse a favor de una adopción generalizada para aplicaciones de alto tráfico. Todavía no estamos en una etapa donde podríamos reemplazar una API que recibe cientos de solicitudes por segundo. La estructura de costos actual sigue siendo prohibitiva para muchos casos de uso.
Pero por supuesto, esto es solo cuestión de tiempo. Hemos visto el impresionante avance en los últimos 12 meses. Creo que el cambio de APIs a ACIs ya nos permite reimaginar cómo interactuamos con el software.
Conclusión
Las Interfaces Conversacionales de Aplicación podrían ser un cambio transformador en cómo interactuamos con el software. Al disolver las capas tradicionales entre usuarios y aplicaciones, las ACIs prometen un futuro donde la interacción es más intuitiva, personalizada y accesible que nunca. No veo esto solo como una mejora incremental, es una reimaginación fundamental de nuestra relación con la tecnología.
Sin embargo, como con cualquier cambio de paradigma, las ACIs plantean preguntas y desafíos que creo que nosotros, como comunidad, necesitamos abordar:
¿Cómo remodelarán las ACIs los roles de desarrolladores y diseñadores? Con interfaces siendo generadas dinámicamente, ¿qué nuevas habilidades necesitarán cultivar los profesionales?
¿Cuáles son las implicaciones para la privacidad y seguridad del usuario en un mundo dominado por interacciones basadas en intención? ¿Cómo aseguramos que la conveniencia de las ACIs no comprometa la protección de datos?
¿Cómo podemos superar las barreras actuales de rendimiento y costo para hacer que las ACIs sean viables para aplicaciones de alto tráfico? ¿Qué innovaciones se necesitan en hardware o software para apoyar este cambio?
Estas preguntas no son solo técnicas, tocan dimensiones éticas, sociales y económicas que darán forma al futuro de nuestro mundo digital.
Únete a la conversación
El viaje hacia la plena realización del potencial de las ACIs está apenas comenzando, e invita a la colaboración y al diálogo. Tus ideas, experiencias y pensamientos son invaluables para navegar este nuevo panorama.
La especificación OpenACI
Con este paradigma en mente, queremos proponer una especificación abierta para Interfaces Conversacionales de Aplicación. Se llama OpenACI y su primer borrador será publicado la próxima semana.
Mientras tanto, puedes jugar con un prototipo muy temprano (y simplista) de una implementación HTTP OpenACI en nuestro repositorio de GitHub:
Application Conversational Interfaces (ACIs) introduce a new paradigm, in a way comparable to what GraphQL was for RPC or RESTful APIs, but in this case proposing something entirely different to replace the term “API”.
We can enumerate a few radically different points when compared to APIs:
-
ACIs don't have a fixed or pre-established contract, schema, methods or a precise workflow. They are intent-based rather than procedural call-based.
-
These interfaces put humans as the main consumer, without making a distinction whether they are end-users or developers.
-
With the previous point in mind, accessibility is an important aspect of ACIs. Not only for inclusivity but also for convenience. ACIs are multi-language and multi-modal.
-
As LLMs continue evolving and AI agents perform better at reasoning, they will also qualify as consumers of ACIs. In this sense, we can iterate over the concept and think of a consumer as anybody capable…
¡Esperamos tus comentarios! Si quieres unirte para discutir y definir la especificación OpenACI, escríbeme a lfarzati@gmail.com or contáctame por LinkedIn.
[Anthropic Claude 3.5 Sonnet fue utilizado para revisar, corregir y mejorar la legibilidad de algunas secciones de este artículo, así como su traducción al Español]
Top comments (0)