- OpenAI presentó Apps SDK, un framework que permite desarrollar aplicaciones que funcionan dentro de ChatGPT
- Ofrece un entorno para que los desarrolladores usen este SDK para crear nuevas apps que funcionen dentro de ChatGPT y probar libremente funciones experimentales
- Apps SDK se ofrece actualmente en versión preview y el envío de apps junto con su distribución oficial está previsto para más adelante este año
- Se espera que este framework abra oportunidades de escalabilidad de la plataforma ChatGPT y desarrollo de apps personalizadas, haciendo posible la integración y automatización de diversos software y servicios
- Se espera que la expansión del ecosistema de desarrollo impulse la productividad y fomente la creación de servicios innovadores
1 comentarios
Opiniones de Hacker News
Es interesante que ChatGPT se esté convirtiendo cada vez más en el punto de partida para navegar la web; pronto ni siquiera hará falta buscar, porque ofrecerá flujos de trabajo básicos como mapas, pagos con Stripe y reservaciones de vuelos, cubriendo la mayoría de las tareas cotidianas que la gente hace normalmente.
El mayor cuello de botella de estos avances durante los últimos dos años no ha sido el modelo, sino la ingeniería, la infraestructura y la disposición de las empresas para colaborar directamente con OpenAI.
Ahora que OpenAI ha crecido y su base de usuarios es mayor, las empresas quieren invertir o participar de forma mucho más activa.
Este cambio no solo afectará el uso de internet centrado en el usuario; si aparecen más herramientas basadas en SDK, también hará que los flujos de trabajo humanos se dividan entre el tráfico que pasa por chatbots y una nueva web optimizada para SEO y para chats/agentes.
Creo que también hay mucha gente como yo que no quiere usar IA.
Especialmente al comprar boletos de avión, no porque desconfíe de que la IA vaya a equivocarse, sino porque quiero gestionarlo yo mismo.
Es parecido a cómo, aunque uno sabe que manejar es más peligroso que volar, manejar se siente más seguro.
Al final, lo importante es tener el control.
No entiendo por qué habría que forzar el uso de apps dentro de una caja de chat, mostrarlas en un formato extraño y luego terminar enlazando a la app real.
Sería más estándar poner una caja de chat dentro de la app.
Si llega el día en que una sola empresa controle, filtre y administre todo el uso de internet, creo que se pierde el sentido mismo de internet.
Claro, entiendo el argumento de que Google ya hace algo parecido, pero al menos con Google Search sí puedes ir a los sitios reales.
Esa estructura de ida y vuelta a través de ChatGPT, como una especie de “teléfono descompuesto”, me parece terrible.
Así como jamás dejaría compras en manos de un asistente de voz, tampoco le confiaría decisiones importantes a un LLM.
Ni hablar de darle acceso a mis pagos con tarjeta de crédito o hasta dejarle hacer una reservación de vuelo.
OpenAI ha tenido esta oportunidad desde que su número de usuarios explotó, pero en realidad no supo aprovecharla bien con los plugins y los GPTs.
Irónicamente, el MCP de Anthropic podría terminar siendo el cambio de juego en esta área.
Si uno cree que ChatGPT será la interfaz de usuario universal del futuro, esta idea suena plausible.
Pero en la práctica, la tendencia actual de los agentes más bien muestra que sería mejor ocultar la interfaz de chat detrás de paradigmas de UI más estrictos.
Creo que hay muchísimas áreas donde el chat puede ser una interfaz excelente.
Si ChatGPT se convierte en el distribuidor de esas áreas, podría reemplazar a Google.
Aun así, en dominios específicos la aproximación correcta sigue siendo una interfaz hecha a la medida, y si ese sector tiene suficiente valor, sin duda aparecerá alguien que construya una interfaz dedicada.
Hoy en día el principal caso de uso de los agentes es la generación de código, y el usuario objetivo ya está acostumbrado a IDEs o editores de código.
Eso representa una gran parte del consumo de tokens, pero no significa que refleje las necesidades o deseos de los usuarios comunes.
Estoy convencido de que la interfaz de chat se ha vuelto tan común porque tiene ventajas propias.
Incluso en usos generales de agentes, el chat ofrece la comodidad de escribir o usar entrada por voz.
También se integra fácilmente con usos de audio a audio o video.
Incluso cuando la generación de video en tiempo real sea posible, en la mayoría de los casos seguirá siendo más cómodo consumir el resultado en texto.
No creo que la gente quiera decirle a ChatGPT que vaya a hablar con Zillow o Canva por ellos.
Quizá sí le pedirían consultar precios de casas en Zillow o crear un gráfico en Canva, pero no sentirían necesidad de invocar la app específica como tal.
Al final, si las apps dependen de ChatGPT para recibir usuarios, ChatGPT no tendrá más remedio que ofrecer la función directamente y reemplazar a la app.
O sea, si expones tu servicio en ChatGPT bajo la idea de que el chat es la interfaz universal, terminas complicando tu propia supervivencia.
Creo que la interfaz de voz y el chat son una combinación realmente buena; por ejemplo, al caminar y tomar una lección de idioma o hacer una búsqueda web por voz resulta muy útil.
También uso una o dos veces por semana formatos de app de notas como NotebookLM.
Se pueden hacer muchos experimentos, como conectar modelos abiertos pequeños a sistemas más grandes para extraer datos estructurados.
Sigo siendo escéptico sobre la utilidad real de los sistemas agentic actuales (MCP y similares).
De todos modos, me alegra que hoy no se haya hablado de AGI.
Aferrarse por FOMO a fantasías de ASI y AGI puede terminar solo en bancarrota.
La interfaz del futuro será una IA local integrada al hardware, con funciones entrenadas sobre datasets.
Trabajo en EE y en modelos de energía, y al pensar en las propiedades geométricas de un osciloscopio, una ecuación puede reconstruir esa estructura.
El usuario puede obtener fácilmente el resultado deseado mediante una UI de parámetros.
Los sistemas operativos de hoy son máquinas virtuales para procesar cadenas, pero el futuro será una máquina virtual vectorial que manipule coordenadas.
Si se simplifica como una sincronización entre la matriz de memoria y la matriz de visualización, los desarrolladores por fin podrán alejarse del viejo procesamiento de cadenas.
Cuando lo ves en la práctica, no resulta tan innovador como parecía.
Las “apps” en realidad no son más que servidores MCP, con la única diferencia de que tienen la opción de devolver HTML.
Tiene los mismos problemas de fondo que MCP: es de un solo jugador, el usuario siempre tiene que “jalar” la información y la estructura de conexión no es tan intuitiva como simplemente abrir una app.
Idealmente, cada app debería tener un punto de entrada propio, poder enviar notificaciones push al usuario y mantener persistencia en la UI.
La interfaz principal también debería ser HTML, no chat.
Creo que esto va a terminar parecido a los GPTs.
Si el servicio vincula de forma proactiva al usuario y al LLM de manera continua, un servidor MCP puede adquirir una capacidad de retención realmente fuerte.
El proceso de instalación y autenticación también se volverá cada vez más fácil para usuarios no técnicos.
Me pareció interesante porque me recordó cuando, al crear Phind 2, insertábamos directamente widgets dinámicos en las respuestas.
La debilidad de ese enfoque es que los esquemas de entrada y salida de las apps/widgets están hardcodeados.
Mientras te mantengas dentro del alcance del widget, funciona muy bien, pero si quieres usar filtros avanzados especiales de Zillow o integrarlo con StreetEasy, enseguida se notan los límites.
Desde el punto de vista del usuario, si faltan funciones avanzadas, simplemente no se puede usar.
Lo que sí me parece realmente innovador es una “UI generada al momento”.
Pronto habrá una actualización sobre esto en Phind (soy el fundador de Phind).
Phind de verdad está muy bien.
Antes, cuando me cansaba de los buscadores tradicionales como Google que solo arrojaban resultados irrelevantes, encontraba rápido lo que quería en Phind.
Pero últimamente los propios LLM ya buscan bastante bien, así que ahora casi solo uso LLMs.
Viendo que ya existen proyectos MCP-UI, no sorprende que esto sea posible.
Aun así, para uso real sigue siendo demasiado lento, así que hace falta mejorarlo.
Yo también estoy pensando si construir algo parecido en nuestro producto, y como solución a las limitaciones del esquema estoy considerando diseñar widgets lo más genéricos posible, como bloques reutilizables.
Todavía está en etapa de idea, pero me pregunto si el modelo podría elegir y combinar varios widgets modulares según la tarea.
Por ejemplo, dividir resultados de búsqueda en elementos individuales, comparaciones tipo matriz, secciones de filtrado, etc., y permitir tratarlos de distintas maneras dentro de la sesión cambiando el contexto.
Si Phind tiene algún texto sobre experiencias reales con algo así, me gustaría leerlo.
Creo que estas limitaciones se resuelven combinando chat con widgets preconstruidos o bajo demanda.
En la demo del keynote, desde la interfaz de chat era posible hacer filtrados avanzados, como quedarte solo con casas de Zillow cerca de parques para perros, sintetizando información de varias fuentes.
Esto se puede resolver con MCP.
Se puede actualizar dinámicamente el esquema del servidor MCP sin tocar la app.
La app reconocerá automáticamente el nuevo esquema.
Este anuncio de OpenAI realmente era una oportunidad para crear algo nuevo, pero da la impresión de que se quedó solo en incrustar pantallas existentes de apps dentro del chat de forma fija.
La verdadera fortaleza sería que el usuario describa una tarea, la IA determine qué herramientas necesita, las combine por su cuenta y muestre el resultado en una forma de flujo de trabajo o canvas editable por el usuario.
Frameworks como LlamaIndex Workflow o LangGraph ya ayudan a implementar manualmente este tipo de gráficos (workflow-DAG) en Python, y si un LLM pudiera construir esos DAG en tiempo real, sería realmente poderoso.
Los LLM ya generan muy bien código de UI y siguen bastante bien los sistemas de diseño, así que no hay razón para hardcodear la pantalla.
Ojalá Google no siga este camino.
Hace poco hubo un texto sobre qué tan profundamente está grabada la interfaz de chat dentro de la propia organización de OpenAI, y este anuncio me hizo sentir todavía más esa obsesión.
La verdadera pregunta es: “¿de verdad a la mayoría de los usuarios les gusta comunicarse solo por conversación en vez de usar elementos visuales?”.
En particular, tener que recordar varios nombres de apps (como Zillow) para escribirlos en el chat, además de la posibilidad de estrategias de cobro vía anuncios o “prioridad de exposición” (app discovery), me parece sumamente desagradable.
Personalmente espero que ese futuro no llegue.
Se siente como volver a debatir si una GUI o una terminal (o CLI) es más poderosa.
Para muchas tareas que encajan bien con un flujo de tokens, la línea de comandos o el chat podrían ser superiores.
También podrían aparecer funciones como autocompletado con Tab para invocar rápido bots o MCP...
En cambio, para explorar contenido nuevo o cuando hace falta interacción gráfica, una interfaz visual y especializada resulta mucho más intuitiva.
Al final, creo que se asentará una mezcla y abstracción adecuada de varias UIs según la tarea.
Creo que el enfoque centrado en interfaces de chat en realidad limita de forma sustancial el uso de los LLM.
A una persona no técnica es dificilísimo incluso explicarle cómo se construye la ilusión de continuidad en una conversación (manejo de contexto, cómo prompts previos van saliendo de la memoria, etc.).
El consejo que normalmente les doy a mis amigos no técnicos es: “empieza una conversación nueva para cada prompt”.
Solo así puedes entender claramente qué funcionó y qué no.
Esperaba que Apple liderara una innovación de UX aquí, pero parece que todavía no.
Como contraargumento, mucha gente que conozco simplemente escribe “zillow” en Google cuando quiere entrar a Zillow, así que quizá teclear el nombre de una app en el chat tampoco sea algo tan absurdo.
Aunque hay muchas reacciones negativas, personalmente la dirección de OpenAI me parece bastante obvia.
A la larga, se convertirá en una plataforma donde el usuario dice lo que quiere y OAI se encarga de conectarse con apps (correo, calendario, pagos, etc.) para resolverlo.
Con ese modelo, OAI solo tendría que compartir ingresos y no necesitaría anuncios.
Si alguien cree que las apps de correo y calendario van a generar ingresos impresionantes, eso podría ser un golpe duro para los inversionistas.
Eso de que no habrá anuncios es falso.
Los anuncios estarán escondidísimos, disfrazados de consejos útiles o algo parecido.
Está claro que OpenAI querrá ambas cosas: compartir ingresos y publicidad.
Ya está armando un equipo de anuncios y tiene suficiente capital, así que intentará probar todos los modelos de negocio escalables posibles.
Va a intentar todo lo que históricamente ha funcionado: app stores, feeds algorítmicos, etc.
Para convertirse en plataforma, necesitas lock-in de usuarios o alguna ventaja injusta.
Simplemente tener mejor calidad de modelo no basta.
Hasta ahora no siento que este enfoque realmente mejore nada.
Alguien mencionó la integración con Spotify, pero eso ya lo podían hacer asistentes de generaciones anteriores.
Parece simplemente una forma mucho más cara de hacer exactamente lo mismo.
Al final, todo apunta a que todos terminarán volcando apps gratis al ecosistema de herramientas de OpenAI.
Ese movimiento fortalece la defensa de OpenAI y sacrifica otras oportunidades.
Al principio, el iPhone solo tenía 6 apps y ni siquiera existía la App Store.
En 2024, el App Store de iOS generó 1.3 billones de dólares en ingresos, y el 85% de eso fue para los desarrolladores.
Me pregunto cuál es el “moat” de OpenAI.
En realidad, ese flujo no deja de tener sentido.
No hay motivo para que desaparezca la ayuda real que brindan al usuario los datos en tiempo real y las acciones MCP.
Conectar una app puede requerir autenticación, pero si no hay pago de por medio, es un canal de distribución enorme.
Este anuncio de OpenAI es un experimento interesante desde el punto de vista de marca.
Llamar “apps” al MCP hace que se sienta familiar y fácil de usar, mientras que decir herramienta/servidor/utilidad suena demasiado técnico.
Agregar demos con Expedia y Spotify da la sensación de que ya existe un MCP terminado que el usuario puede usar de inmediato.