- OpenAI hat das Apps SDK veröffentlicht, ein Framework zur Unterstützung der Entwicklung von Apps, die innerhalb von ChatGPT laufen
- Entwickler können mit diesem SDK neue Apps erstellen, die in ChatGPT laufen, und erhalten eine Umgebung, in der sie experimentelle Funktionen frei testen können
- Das Apps SDK ist derzeit als Preview-Version verfügbar; die Einreichung von Apps und die offizielle Veröffentlichung sind für später in diesem Jahr geplant
- Dieses Framework eröffnet Erweiterbarkeit der ChatGPT-Plattform und Möglichkeiten zur Entwicklung maßgeschneiderter Apps, wodurch die Integration und Automatisierung verschiedener Software und Services voraussichtlich möglich werden
- Es wird erwartet, dass durch den Ausbau des Entwickler-Ökosystems Produktivitätssteigerungen und die Schaffung innovativer Services gefördert werden
1 Kommentare
Hacker-News-Kommentare
Es ist interessant, dass ChatGPT immer mehr zum Ausgangspunkt für das Surfen im Web wird. Bald wird man vielleicht gar nicht mehr separat suchen müssen, sondern bekommt direkt Workflows für einfache Karten, Stripe-Zahlungen, Flugbuchungen usw. bereitgestellt, sodass die meisten alltäglichen Aufgaben der Menschen abgedeckt werden.
Der größte Engpass dieses Fortschritts lag in den letzten zwei Jahren nicht bei den Modellen, sondern bei Engineering, Infrastruktur und der Bereitschaft von Unternehmen, direkt mit OpenAI zusammenzuarbeiten.
Jetzt, da OpenAI wächst und die Nutzerbasis größer wird, wollen Unternehmen deutlich aktiver investieren oder sich beteiligen.
Diese Veränderung wird nicht nur die nutzerzentrierte Internetnutzung beeinflussen, sondern auch dazu führen, dass sich mit mehr SDK-basierten Tools menschliche Workflows, über Chatbots laufender Traffic sowie ein auf SEO-Optimierung und Chat-/Agenten ausgerichtetes neues Web voneinander abspalten.
Ich denke, es gibt viele Leute wie mich, die AI gar nicht nutzen wollen.
Gerade beim Kauf von Flugtickets geht es nicht darum, dass ich AI wegen möglicher Fehler misstraue, sondern darum, dass ich es selbst in der Hand haben will.
Das ist ähnlich wie beim Autofahren: Obwohl man weiß, dass es gefährlicher ist als Fliegen, fühlt es sich sicherer an.
Am Ende ist die eigene Kontrolle entscheidend.
Ich verstehe nicht, warum man Apps unbedingt in einer Chatbox erzwingen und sie in einem seltsamen Format anzeigen muss, nur um am Ende doch auf die echte App zu verlinken.
Viel eher wäre es der Standardweg, eine Chatbox in die App einzubauen.
Wenn ein einziges Unternehmen die gesamte Internetnutzung kontrolliert, filtert und verwaltet, verliert das Internet für mich seinen Sinn.
Natürlich verstehe ich das Argument, dass Google ähnlich sei, aber zumindest kann man über die Google-Suche noch auf echte Websites gelangen.
Diese Struktur des Hin-und-Her über ChatGPT wie bei einer Art „Stille Post“ ist einfach furchtbar.
So wie ich niemals einen Sprachassistenten für Einkäufe einsetzen würde, kommt es für mich überhaupt nicht infrage, wichtige Entscheidungen einem LLM zu überlassen.
Weder meine Kreditkartenzahlungen noch Flugbuchungen würde ich jemals so etwas anvertrauen.
OpenAI hatte diese Chance schon seit dem explosionsartigen Nutzerwachstum, hat sie mit Plugins und GPTs aber nicht wirklich genutzt.
Ironischerweise könnte Anthropics MCP hier zum Gamechanger werden.
Wenn man daran glaubt, dass ChatGPT die universelle Benutzeroberfläche der Zukunft wird, wirkt diese Idee plausibel.
In der Praxis zeigt der aktuelle Agenten-Trend aber eher, dass man Chat-Interfaces besser hinter strengeren UI-Paradigmen versteckt.
Ich denke, es gibt sehr viele Bereiche, in denen Chat eine großartige Benutzeroberfläche sein kann.
Wenn ChatGPT zum Distributionskanal für solche Bereiche wird, könnte es Google ersetzen.
Trotzdem ist für bestimmte Domänen ein maßgeschneidertes Interface der richtige Ansatz, und wenn das Feld wertvoll genug ist, wird definitiv jemand ein spezialisiertes Interface bauen.
Der wichtigste aktuelle Anwendungsfall für Agenten ist Codegenerierung, und die Zielgruppe ist mit IDEs oder Code-Editoren vertraut.
Das macht zwar einen großen Anteil des Token-Verbrauchs aus, steht aber nicht stellvertretend für die Bedürfnisse oder Wünsche normaler Nutzer.
Ich bin überzeugt, dass sich Chat-Interfaces so stark verbreitet haben, weil sie eigene Vorteile mitbringen.
Auch bei allgemeinen Agenten-Anwendungen bietet Chat den Komfort von Tippen oder Spracheingabe.
Audio-zu-Audio- oder Video-Anwendungen lassen sich ebenfalls leicht kombinieren.
Selbst wenn Videogenerierung künftig in Echtzeit möglich wird, wird es für die meisten Ergebnisse bequemer sein, sie als Text zu konsumieren.
Ich glaube nicht, dass Leute ChatGPT bitten wollen, an ihrer Stelle Zillow oder Canva anzusprechen.
Sie lassen vielleicht Immobilienpreise bei Zillow nachschlagen oder ein Grafikprojekt in Canva anstoßen, aber sie haben nicht unbedingt das Bedürfnis, die konkrete App selbst aufzurufen.
Wenn Apps sich am Ende darauf verlassen, dass ChatGPT ihnen Nutzer zuschiebt, wird ChatGPT die Funktionen zwangsläufig irgendwann selbst anbieten und die Apps ersetzen.
Wer also seine Dienste unter der Annahme, Chat sei das universelle Interface, für ChatGPT sichtbar macht, erschwert damit letztlich das eigene Überleben.
Ich halte Voice-Interfaces und Chat für eine wirklich gute Kombination, zum Beispiel wenn man beim Gehen per Sprache Fremdsprachenunterricht nimmt oder im Web sucht.
Auch Notiz-Apps im Stil von NotebookLM nutze ich ein- bis zweimal pro Woche.
Man kann viele Experimente machen, etwa kleine Open-Modelle an größere Systeme anzuschließen und für strukturierte Datenextraktion zu nutzen.
Bei der praktischen Nützlichkeit heutiger agentischer Systeme (MCP usw.) bin ich allerdings skeptisch.
Immerhin bin ich froh, dass heute nicht über AGI gesprochen wurde.
Wenn man sich aus FOMO an ASI-/AGI-Fantasien klammert, könnte am Ende nur der Bankrott bleiben.
Das Interface der Zukunft ist lokale AI, bei der auf Datensätzen trainierte Funktionen in die Hardware eingebettet sind.
Als EE und jemand, der im Bereich Energiemodelle arbeitet, denke ich an die geometrischen Eigenschaften eines Oszilloskops: Gleichungen können diese Struktur rekonstruieren.
Nutzer können dann mit einer Parameter-UI leicht die gewünschten Ergebnisse erzielen.
Die heutigen Betriebssysteme sind virtuelle Maschinen zur Verarbeitung von Zeichenketten, aber die Zukunft sind Vektor-Virtual-Machines, die Koordinaten manipulieren.
Durch die Synchronisierung von Speichermatrix und Displaymatrix wird alles vereinfacht, und Entwickler werden sich künftig von veralteter String-Verarbeitung lösen.
Wenn man das tatsächliche Produkt sieht, wirkt es weniger revolutionär als erwartet.
Die „Apps“ sind im Grunde nur MCP-Server, mit der zusätzlichen Option, HTML zurückzugeben.
Das grundlegende Problem von MCP bleibt bestehen: Es ist Singleplayer-artig, der Nutzer muss immer selbst „ziehen“ (pull), und die Verbindungsstruktur ist weniger intuitiv, als einfach eine App zu öffnen.
Im Idealfall hätte jede App einen eigenen Einstiegspunkt, könnte Push-Benachrichtigungen senden und würde innerhalb der UI Persistenz besitzen.
Auch die Hauptoberfläche sollte eher HTML als Chat sein.
Ich erwarte gerade deshalb ein ähnliches Ende wie bei GPTs.
Wenn ein Dienst Nutzer und LLM dauerhaft aktiv miteinander verknüpft, bekommen MCP-Server eine wirklich starke Bindungswirkung.
Auch Installation und Authentifizierung werden für Nichtfachleute schrittweise immer einfacher werden.
Es ist interessant, weil ich mich erinnere, bei Phind 2 dynamische Widgets direkt in Antworten eingebettet zu haben.
Die Schwäche dieses Ansatzes ist, dass Ein- und Ausgabeschemata von Apps/Widgets fest hardcodiert sind.
Solange man innerhalb des Widget-Umfangs bleibt, funktioniert es sehr gut, aber sobald man bei Zillow spezielle erweiterte Filter verwenden oder StreetEasy einbinden will, spürt man schnell die Grenzen.
Aus Nutzersicht heißt das dann: Wenn fortgeschrittene Funktionen fehlen, kann man es schlicht nicht verwenden.
Was ich wirklich revolutionär finde, ist „on-the-fly generierte UI“.
Dazu wird es bald ein Update von Phind geben (ich bin Gründer von Phind).
Phind ist wirklich gut.
Früher habe ich oft schnell die gewünschten Informationen über Phind gefunden, wenn ich von klassischen Suchmaschinen wie Google genervt war, die mir nur irrelevante Ergebnisse geliefert haben.
In letzter Zeit suchen LLMs aber selbst so gut, dass ich inzwischen nur noch LLMs nutze.
Dass es möglich ist, ist nicht überraschend, wenn man bedenkt, dass es bereits bestehende MCP-UI-Projekte gibt.
Trotzdem ist es für den realen Einsatz noch viel zu langsam und muss klar verbessert werden.
Ich überlege auch, ob ich etwas Ähnliches für unser Produkt bauen soll, und denke als Lösung für die Schema-Beschränkungen darüber nach, Widgets möglichst als allgemeine Bausteine zu entwerfen, um ihre Verwendbarkeit zu erhöhen.
Es ist noch eine Idee, aber ich frage mich, ob das Modell nicht mehrere modulare Widgets je nach Aufgabe passend kombinieren und auswählen könnte.
Zum Beispiel könnte man Suchergebnisse in Einzelelemente, Matrixvergleiche, Filtersektionen usw. aufteilen und dann erforschen, wie sie in derselben Sitzung in verschiedenen Kontexten unterschiedlich genutzt werden können.
Falls es bei Phind einen Text über solche realen Erfahrungen gibt, würde ich ihn gern lesen.
Ich denke, diese Grenzen lassen sich lösen, wenn Chat mit vorgefertigten oder On-Demand-Widgets kombiniert wird.
In der Keynote-Demo war es möglich, in der Chat-Oberfläche unter den Immobilien von Zillow nur die in der Nähe von Hundeparks zu filtern, indem Informationen aus mehreren Quellen zusammengeführt wurden.
Mit MCP lässt sich dieses Problem lösen.
Man kann das MCP-Server-Schema dynamisch aktualisieren, ohne die App anzufassen.
Die App erkennt das neue Schema dann automatisch.
Diese OpenAI-Ankündigung hätte die Chance geboten, wirklich etwas Neues zu schaffen, aber stattdessen scheint es bei einer starren Einbettung bestehender App-Oberflächen in den Chat geblieben zu sein, was enttäuschend ist.
Die eigentliche Stärke wäre, dass der Nutzer eine Aufgabe beschreibt, die AI erkennt, welche Tools nötig sind, sie selbst kombiniert und das Ergebnis als bearbeitbaren Workflow oder in Form einer Canvas zeigt.
Frameworks wie LlamaIndex Workflow oder LangGraph helfen schon heute dabei, solche Graphen (Workflow-DAGs) manuell in Python zu implementieren; wenn ein LLM solche DAGs in Echtzeit erstellen könnte, wäre das wirklich mächtig.
LLMs erzeugen bereits guten UI-Code und halten sich gut an Design-Systeme, daher gibt es keinen Grund, Bildschirme fest zu hardcodieren.
Ich hoffe, Google folgt diesem Weg nicht.
Vor Kurzem gab es einen Text darüber, wie tief das Chat-Interface intern bei OpenAI tatsächlich verankert ist, und diese Ankündigung hat diese Fixierung noch stärker spürbar gemacht.
Die eigentliche Frage ist: „Wollen wirklich die meisten Nutzer lieber ausschließlich per Konversation als über visuelle Elemente interagieren?“
Besonders unangenehm finde ich, dass man sich mehrere App-Namen (Zillow usw.) merken und in den Chat tippen muss, sowie die Möglichkeit von Werbe- oder „Priority Placement“-Monetarisierung bei der App-Entdeckung.
Ich persönlich hoffe, dass diese Zukunft nicht eintritt.
Es fühlt sich an, als würde wieder einmal diskutiert, ob GUI oder Terminal (bzw. CLI) mächtiger ist.
Für viele Aufgaben, die gut zu Token-Streams passen, könnten Kommandozeile oder Chat tatsächlich überlegen sein.
Es könnte auch Tab-Autovervollständigung geben, um Bots oder MCPs schnell aufzurufen, aber …
Wenn es dagegen um das Erkunden neuer Inhalte oder grafische Interaktion geht, sind visuelle, spezialisierte Interfaces viel intuitiver.
Letztlich wird sich je nach Aufgabe wohl eine passende Mischung und Abstraktion verschiedener UIs etablieren.
Ich denke, der Fokus auf Chat-Interfaces behindert den praktischen Nutzen von LLMs tatsächlich.
Nichtfachleuten lässt sich kaum erklären, wie die Illusion von Gesprächskontinuität entsteht, also wie Kontextverwaltung funktioniert oder warum frühere Prompts aus dem Gedächtnis verschwinden.
Mein üblicher Rat an technisch weniger versierte Freunde lautet deshalb: „Für jeden Prompt eine neue Unterhaltung beginnen.“
Nur so lässt sich klar erkennen, was tatsächlich funktioniert.
Ich hatte gehofft, Apple würde die UX-Innovation anführen, aber bisher ist das wohl nicht passiert.
Als Gegenargument könnte man sagen, dass viele Leute, die ich kenne, einfach „zillow“ bei Google eingeben, wenn sie auf Zillow wollen, also ist es vielleicht gar nicht völlig abwegig, App-Namen in einen Chat einzugeben.
Es gibt viele negative Reaktionen, aber persönlich erscheint mir OpenAIs Richtung sehr naheliegend.
Letztlich wird es zu einer Plattform, bei der Nutzer einfach sagen, was sie wollen, und OAI verbindet sich selbstständig mit Apps wie E-Mail, Kalender, Bezahlen usw., um es zu erledigen.
So könnte OAI ganz ohne Werbung auskommen und einfach am Umsatz beteiligt werden.
Wenn man glaubt, dass E-Mail- und Kalender-Apps enorme Umsätze bringen werden, dürfte das für Investoren ein Schock werden.
Dass es keine Werbung geben wird, stimmt nicht.
Werbung wird extrem subtil und tief versteckt sein, etwa in Form nützlicher Tipps.
OpenAI wird ganz sicher auf beides abzielen: Umsatzbeteiligung und Werbung.
Sie bauen bereits ein Werbeteam auf und haben genug Kapital, um jedes skalierbare Geschäftsmodell auszuprobieren.
Alles, was historisch erfolgreich war — App Store, algorithmische Feeds usw. — werden sie testen.
Um eine Plattform zu werden, braucht man Nutzer-Lock-in oder einen unfairen Vorteil.
Nur eine bessere Modellqualität reicht dafür nicht aus.
Bis jetzt habe ich nicht den Eindruck, dass dieser Ansatz tatsächlich etwas verbessert.
Jemand hatte Spotify-Integration erwähnt, aber das konnten auch ältere Assistenten schon.
Es wirkt einfach so, als würde exakt dasselbe wie bisher nur viel teurer ausgeführt.
Am Ende scheinen alle dazu bestimmt zu sein, kostenlose Apps in OpenAIs Tool-Ökosystem zu kippen.
Dieser Trend stärkt OpenAIs Verteidigungsfähigkeit und opfert andere Chancen.
Beim frühen iPhone gab es nur sechs Apps und nicht einmal einen App Store.
Im Jahr 2024 erzielte der iOS App Store 1,3 Billionen Dollar Umsatz, davon gingen 85 % an Entwickler.
Ich frage mich, worin OpenAIs „moat“ eigentlich besteht.
Eigentlich ergibt diese Entwicklung keinen Sinn.
Es gibt keinen Grund, warum Echtzeitdaten und MCP-Aktionen keinen echten Nutzen für Nutzer mehr liefern sollten.
Bei App-Verbindungen kann zwar Authentifizierung nötig sein, aber wenn keine Zahlung anfällt, ist das ein enormer Distributionskanal.
Diese Ankündigung ist aus Branding-Sicht ein interessantes Experiment.
Wenn man MCP als „App“ bezeichnet, wirkt es vertraut und einfach zu benutzen, während Begriffe wie Tool/Server/Werkzeug zu technisch klingen.
Mit zusätzlichen Demos mit Expedia und Spotify entsteht der Eindruck, dass sofort nutzbare MCPs schon fertig sind.