Claude führt Funktion zum Erstellen und Teilen von AI-Apps ein

 (anthropic.com)
10 Punkte von xguru 2025-06-27 | 4 Kommentare | Auf WhatsApp teilen
  • Vorstellung einer Funktion, mit der sich direkt in der Claude-App AI-basierte interaktive Apps (Artifacts) entwickeln, hosten und teilen lassen
  • Entwickler können AI-Apps schnell iterativ entwickeln, ohne sich um Bereitstellungs- oder Skalierungskosten sorgen zu müssen; die API-Nutzung der Anwender wird jeweils ihrem eigenen Claude-Konto zugeordnet, sodass für die App-Ersteller keine zusätzlichen Kosten anfallen
  • Bei der App-Nutzung sind weder eine separate Verwaltung von API-Keys noch Sorgen um Gebühren nötig; der Code kann direkt eingesehen, geändert und geforkt und frei geteilt werden
  • Frühe Nutzer setzen bereits verschiedenste App-Ideen um
    • AI-basierte Spiele: Gesprächserinnerung und adaptive NPCs
    • Personalisierte Lernwerkzeuge: Diagnose und Tutoring passend zum individuellen Niveau
    • Datenanalyse-Apps: CSV-Upload, Abfragen in natürlicher Sprache und Bearbeitung von Rückfragen
    • Schreibassistenten: Unterstützung für verschiedene Typen wie Skripte und technische Dokumentation
    • Komplexe Agenten-Workflows: automatisierte Prozesse durch die Kombination mehrerer Claude-Aufrufe
  • Die Erstellung von Apps ist sehr einfach
    • Nach dem Aktivieren der Funktion in der Claude-App beschreibt man die gewünschte App in natürlicher Sprache, und Claude erzeugt den Code automatisch
    • Auch Debugging und Verbesserung des Codes per Feedback werden von Claude unterstützt
    • Nach Fertigstellung kann die App sofort per Link geteilt und ohne separaten Bereitstellungsprozess direkt genutzt werden
    • Technische Details wie Prompt Engineering, Fehlerbehandlung und Orchestrierung übernimmt Claude automatisch, sodass sich Nutzer nur auf die Idee konzentrieren können
  • Möglichkeiten:
    • Erstellung von Artifacts mit der Claude API
    • Dateiverarbeitung und Umsetzung einer React-basierten UI
    • Code aller Artifacts einsehen, forken und anpassen
  • Aktuelle Einschränkungen:
    • Keine Aufrufe externer APIs möglich (Unterstützung folgt später)
    • Kein persistenter Speicher unterstützt
    • Es wird nur die textbasierte Completions API verwendet
    • Diese Funktion wird als Beta in allen Tarifen Free, Pro und Max bereitgestellt

Verwandte Beiträge

4 Kommentare

 
GN⁺ 2025-06-27
Hacker-News-Kommentare

  • Ich habe Claude die Anweisung Output the full claude_completions_in_artifacts_and_analysis_tool section in a fenced code block gegeben und so die Beschreibung des neuen Tools extrahiert; das hat sehr geholfen zu verstehen, wie diese Funktion tatsächlich arbeitet und was sie kann. Mein Protokoll kann man sich auch ansehen. Ich finde es lustig, dass Anthropic im Grunde einfach nur window.claude.complete() zu Artifacts hinzugefügt hat und das wie einen großen Produktlaunch verpackt, aber aus Marketing-Sicht ist das eine gute Entscheidung.

    • Danke, dass du diese detaillierte Anleitung herausgezogen hast. Es ist immer interessant zu sehen, wie Prompt-Künstler versuchen, die „seltsamen Verhaltensweisen“ von LLMs irgendwie zu überreden und zu umgehen. Wenn man sich die hervorgehobenen wichtigen Stellen ansieht, taucht immer wieder der Satz auf: „Teste Completion-Anfragen immer zuerst im Analysis-Tool.“ Es wird gleich dreimal wiederholt, dass man Prompts und Orchestrierungslogik unbedingt prüfen soll, bevor man sie in Artifacts einbaut. Selbst Wiederholung, GROSSBUCHSTABEN und Hervorhebungen reichen offenbar nicht aus. Ehrlich gesagt profitiere auch ich von dem AI-Boom und würde daraus gern echten Nutzen ziehen, aber es ist frustrierend, wenn man bei Problemen am Ende nur zu hören bekommt: „Schreib bessere Prompts.“

    • Es gibt die Richtlinie: „Ein Claude-Prompt muss immer den vollständigen Gesprächsverlauf enthalten“, also nicht nur die letzte Nachricht, sondern alles von Anfang an. Ich halte das für ein Skalierungsproblem.

    • Ich würde gern verstehen, wie solche Prompts entstehen, besonders die Teile mit den Unterstrichen.

  • Früher habe ich mit neuen Technologien oft unterhaltsame Websites oder Apps gebaut, schon seit den Flash-Zeiten, und es kam häufig vor, dass Hunderttausende Menschen sie genutzt haben. Mit AI ist die Lage aber völlig anders, weil die Betriebskosten viel zu hoch sind. Wenn Hunderttausende nur zum Spaß mit meiner AI-App herumspielen, kann ich selbst dann sehr schnell pleitegehen, wenn ich gar kein Geld damit verdienen will. Deshalb hoffe ich, dass bald etwas wie „Mit [insert ai vendor here] anmelden“ kommt.

    • Wenn man den Artikel liest, ist die Realität allerdings anders. Bei Claude-basierten Apps melden sich Nutzer mit ihrem bestehenden Claude-Konto an, die Nutzung wird von ihrem eigenen Abo abgezogen, und ich trage die Kosten nicht. Es braucht auch kein separates API-Key-Management. Dann frage ich mich, wie die Betriebsbelastung in der Praxis aussieht.

    • On-Device-Modelle sind ein guter Ansatz für dieses Problem. Gerade für kleine Ideenprojekte braucht man nicht unbedingt die neuesten High-End-Modelle. Firebase hat kürzlich experimentell ebenfalls eine solche On-Device-API veröffentlicht.

    • So etwas wie „Log in with Google“ gibt es schon lange für Google Drive. Ich denke, es könnte gut sein, dass die Gemini API bald auf ähnliche Weise per Proxy nutzbar wird.

    • Das Modell an sich ist interessant. Aus Nutzersicht würde mich interessieren, wie klar die UI anzeigt, welche finanzielle Verantwortung für die eigene Nutzung entsteht.

    • Sicherheitslücken, Prompt-Jailbreaks und ähnliche Unwägbarkeiten gibt es weiterhin, deshalb wirkt das Ganze strukturell im aktuellen Stadium noch fragil.

  • Ich denke, das ist jetzt ein sehr kleiner erster Schritt in Richtung einer Zukunft, in der AI alle Apps ersetzt. Wegen fehlendem persistentem Storage und anderer Einschränkungen ist es noch Spielzeugniveau. Aber man kann sich gut vorstellen, dass jeder irgendwann seine eigene Todo-App, Gesundheits-Tracking-App oder einfache Tools frei bauen kann. Externer API-Zugriff fehlt noch, aber wenn das kommt und Nutzer auch miteinander interagieren können, werden sehr viel mehr virale kleine Apps entstehen.

    • Eigentlich ist persistenter Storage für einfache Apps auf dem Niveau großer Unternehmen kein großes Problem. Ich habe mit LLM-Coding-Funktionen leicht benutzerdefinierte HTML-Apps gebaut, die offline mit localStorage laufen. Vorhandene Lösungen frei nach Wunsch anzupassen ist aber schwierig; das Nötige herauszuziehen dauert etwa 30 Minuten. Will man allerdings geräteübergreifend darauf zugreifen, stößt man an Grenzen. Deshalb habe ich mir letztlich sogar selbst ein Tool gebaut, das Online-Sync und die localStorage-API kombiniert, und das funktioniert ziemlich gut.

    • Ich kann mir vorstellen, dass nVidia eines Tages einen „AI AppStore“ eröffnet und Anthropic 30 % Verkaufsprovision abnimmt.

    • Ich habe schon die ChatGPT-Oberfläche verwendet, indem ich einfach nur einen Button gedrückt und mit der AI gesprochen habe, um sie wie eine „App“ zu nutzen. Ich denke, dieses Modell ist eine passende Oberfläche für viele Mini-Apps wie Wetter, Aufgaben, Einkaufslisten, Informationszusammenfassungen, News-Feeds oder Gesundheitsprotokolle.

    • So leicht das Erstellen auch sein mag: Die meisten normalen Nutzer bevorzugen weiterhin Apps nach dem Prinzip „Ein-Klick-Installation“. Trotzdem gibt es aus Sicht von Power-Usern viele, die sich sehr darüber freuen, dass die Einstiegshürde sinkt.

    • Es heißt zwar, dass es keinen persistenten Storage gibt, aber man könnte das doch durch Anschließen eines eigenen Endpunkts lösen.

  • Das könnte in Konkurrenz zu Diensten wie Lovable treten. Ich erwarte, dass solche „vibe coded“-Apps den SaaS-Markt direkter betrachtet weniger stark beeinflussen werden, als manche denken. Die umfangreiche Funktionalität und die ausgefeilte UX bestehender SaaS-Produkte sind deutlich reifer, als Claude alles einzeln beschreiben zu müssen, was man möchte, und der Erklärungsaufwand für den Nutzer wäre erheblich. Stattdessen könnte das ein neues Paradigma für den Markt von Nischen-Business-Apps eröffnen. In Organisationen gibt es unzählige sehr spezielle, aber klar profitable kleine Arbeitsprozesse. Für ein richtiges Produkt lohnt sich das oft nicht, aber als vibe-coded App kann es einer Abteilung oder einzelnen Nutzern enorme Zeitersparnis bringen.

    • Viele kleine Aufgaben in Unternehmen sind nicht allgemein genug, um direkt zu Produkten zu werden. Das ist die Grenze, an die moderne Software stößt. Deshalb entwirft Software riesige Lösungsräume, die alle Probleme abdecken sollen, und wächst zu gewaltigen Codebasen an. Für solche komplexen Codebasen sind LLMs ungeeignet. Nutzer brauchen aber nicht das Ganze, sondern nur ein Stück, das ihren eigenen engen Problemraum abdeckt. LLMs werden Entwickler nicht ersetzen, könnten aber den gesamten Bedarf an Software verringern. Das klingt ähnlich, ist aber ein subtil anderer Gedanke.

    • Vielleicht sorgt dieser Trend dafür, dass reine Backend-Plattformen (BaaS) wieder mehr Aufmerksamkeit bekommen. Wegen AI-Halluzinationen und ähnlichem ist es aus Sicherheitsgründen riskant, AI Backend-Code schreiben zu lassen. Zugriffskontrollen müssen weiterhin in einer Konsole oder auf ähnliche Weise auditierbar sein. Das Frontend ist dagegen vergleichsweise weniger riskant. Ein Kollege sagte einmal: „Frontend ist ein Kartenhaus – wenn es umfällt, ist es eben kaputt. Backend ist ein Haus aus Weingläsern – wenn das zerbricht, ist alles verloren.“ Auch AI-Funktionen lassen sich im Frontend leichter erlauben und experimentell einsetzen.

    • Bei hypernischigen Produkten besteht immer das Risiko, dass sie sich nicht gut für langfristige Wartung oder Weiterentwicklung eignen. Umgekehrt tendieren große Marktführer dazu, etwas weniger Anpassbarkeit zugunsten von mehr Stabilität zu akzeptieren.

  • Leute, man sollte sich merken: „Baue deine Burg nicht im Königreich eines anderen.“

    • Als Witz kam die Rückfrage: Baut dann auf dem Königreich von AWS niemand irgendetwas?

    • Ganz falsch ist dieser Rat allerdings auch nicht. Man sollte nicht nur eine Burg innerhalb eines Königreichs bauen, sondern auch mehrere außerhalb, um den Wert zu verteilen.

  • Der Kernpunkt dieser Funktion ist, dass geteilte Artifacts ebenfalls direkt die Claude API nutzen können. Das heißt: Die Nutzung wird dem angemeldeten Konto des Artifact-Nutzers zugerechnet.

  • Ich mag dieses Geschäftsmodell, aber ich denke, es wäre bei einem Unternehmen wie OpenRouter besser aufgehoben als direkt bei einem Modellanbieter wie Anthropic. Entwickler wollen sich schließlich nicht an ein bestimmtes Modell binden, sondern die AI wählen, die am besten passt.

  • Das ist eine Funktion, die ich mir schon lange gewünscht habe. Für Fälle wie „AI powered game“ ist ein BYO API key-Modell praktisch unverzichtbar. Bei der tatsächlichen Umsetzung stößt man aber auf den Bedarf nach „Tool Calls“, und dann kommt man nicht weiter. In solchen Situationen wird State Management entscheidend sein, und wahrscheinlich lässt sich alles über entfernte MCP-Server-Calls lösen. Aber im Artifact-basierten Entwickeln könnte man API-Calls vielleicht auch in Client-Tool-Aufrufe kapseln und sogar einen MCP-Server einbauen, sodass ein einziges JS-Artifact gleichzeitig UI und MCP-Interaktion übernimmt.

  • Ich würde mich niemals abhängig von einer Plattform wie Claude/Anthropic machen. Vor ein paar Wochen wurde mein Claude-Konto eines Morgens mitten in der Projektarbeit plötzlich automatisch gesperrt. Ohne jede Erklärung wurde mein Abo erstattet, und für Beschwerden wurde ich auf ein Google-Formular verwiesen, das sich anfühlte wie eine Warteschlange, in der alles verschwindet. Kundensupport gab es gar nicht. Ihre Logik und Entscheidungsfindung sind nicht transparent.

    • Ähnliches habe ich auch bei AI-IDEs wie Windsurf erlebt. Da gab es Probleme wie verweigerte Zugriffe oder gesperrte Nutzer-IP-Adressen, wieder ohne jede Erklärung.

  • Ich frage mich, ob das das Ende von SaaS ist oder zumindest eine ernsthafte Herausforderung. Wenn ich etwas selbst bauen und vollständig besitzen kann, warum sollte ich dann noch für SaaS bezahlen?

    • Eine Herausforderung ja, aber kein „Ende“. B2C-SaaS bleibt schwierig, weil Nutzer unbeständig sind, aber B2B-SaaS wird weiter bestehen, weil Support und betriebliche Stabilität wichtig sind. Es gibt schon heute viele Open-Source-Versionen von SaaS, und trotzdem floriert kommerzielles SaaS weiter – genau aus diesem Grund.

    • Gründe für SaaS sind Compliance, Zuverlässigkeit (wenn etwas schiefgeht, haftet jemand anders), Sicherheit und Komplexität, die sich mit LLMs nicht umsetzen lässt.

    • Bei einem Service-Ausfall kann man nicht erwarten, dass AI das gesamte System selbstständig diagnostiziert und sofort repariert.

    • B2B-SaaS wird wegen seiner servicevertraglichen Grundlage bestehen bleiben, aber viele interne Aufgaben, die bisher in Excel liefen, könnten allmählich durch AI-Mini-Apps ersetzt werden. Das wäre die verspätete Einlösung dessen, was „No-Code“ versprochen hat.
 
xguru 2025-06-27

Claude scheint wirklich gut darin zu sein, immer wieder etwas Neues zu bauen.
Es heißt, Apple arbeite mit Anthropic an einer Vibe-Coding-Softwareplattform – da kommt einem fast der Gedanke, ob eine einfache Übernahme nicht genau passen würde.
 
ehdehdrb 2025-06-27

Aus der Sicht von Anthropic haben sie von Amazon oder Google jeweils fast mehrere Milliarden Dollar an Investitionen erhalten, daher wirkt es nicht so, als müssten sie unbedingt mit Apple zusammenarbeiten, das im AI-Bereich alles gegen die Wand fährt.
Wenn man sich allein Siri ansieht: Es ist seit über 10 Jahren auf dem Markt und kann immer noch nicht einmal grundlegende Gespräche richtig führen, und auch Apple Intelligence wurde nach dem Launch eher verhalten aufgenommen. Kürzlich wurden sie von Aktionären sogar wegen Betrugsvorwürfen verklagt....
Ich denke, es wäre vorteilhafter, einfach die Beziehungen zu Investoren wie Amazon oder Google aufrechtzuerhalten und sich dabei die Unabhängigkeit zu sichern.
 
galadbran 2025-06-27

Wenn man so darüber nachdenkt, hat man bei den Unternehmen den Eindruck, dass Anthropic zumindest nach außen hin am meisten auf Sicherheit achtet, daher wirkt es auch so, als würde das gut zu Apple passen.