- Viele AI-Produkte bleiben Wrapper, die externe Modelle wie ChatGPT per API aufrufen, und holen damit Risiken bei Differenzierung, Kosten, Geschwindigkeit und Anpassbarkeit direkt ins Produkt
- Ein einfacher LLM-Aufruf lässt sich schnell bauen, kann aber von jedem kopiert werden; wenn OpenAI dieselbe Funktion in ChatGPT integriert, wird es schwer, den eigenen Mehrwert zu schützen
- Allgemeine LLMs sind teuer im Betrieb: Es kann eine Struktur entstehen wie bei GitHub Copilot, das 10 US-Dollar pro Monat verlangt, während die durchschnittlichen Kosten 20 US-Dollar betragen und einige Nutzer bis zu 80 US-Dollar pro Monat kosten
- Builders Visual Copilot versuchte, Figma-Designs ausschließlich mit LLMs in Code zu verwandeln, wechselte wegen Antwortlatenz und Qualitätsgrenzen aber zu einer eigenen Toolchain
- Praktisch ist es schneller, günstiger und besser kontrollierbar, Probleme zuerst mit normalem Code zu lösen und spezialisierte AI-Modelle nur für enge Bereiche einzusetzen, die mit Standardcode schwer abzudecken sind
Grenzen des einfachen LLM-Wrapper-Ansatzes
- Viele AI-Produkte, die derzeit entstehen, sind eher Wrapper auf anderen Modellen und funktionieren so, dass sie natürlichsprachliche Eingaben an die ChatGPT-API senden und natürlichsprachliche Ausgaben erhalten
- Das ist leicht zu implementieren und ermöglicht schnell interessante Funktionen, doch wenn der einzigartige Wert des Produkts in fortschrittlicher AI-Technologie liegt, steigt das Kopierrisiko
- Wie bei PDF-Chat-Apps: Wenn eine Person so etwas baut, erstellen mehrere andere ähnliche Apps, und später integriert OpenAI die Funktion direkt in ChatGPT — ein Muster, das entsteht, wenn differenzierende Technologie fehlt
- Wenn ein Produkt im Wesentlichen nur per Button eine Anfrage an ChatGPT sendet und die Antwort dem Nutzer zeigt, ist seine Verteidigungsfähigkeit am schwächsten
- Wenn die eigene Technologie substanziell ist und ein LLM nur einen kleinen, aber wichtigen Teil unterstützt, ist die Position besser; Kosten- und Geschwindigkeitsprobleme bleiben jedoch bestehen
Kosten und Geschwindigkeit sind reale Hürden für Produktisierung
- LLMs sind groß und komplex geworden, um eine breite Allgemeingültigkeit zu erreichen, und entsprechend hoch sind die Betriebskosten
- Laut Wall Street Journal verlangte GitHub Copilot von Nutzern 10 US-Dollar pro Monat, die durchschnittlichen Kosten lagen jedoch bei 20 US-Dollar; einige Nutzer verursachten GitHub Kosten von bis zu 80 US-Dollar pro Monat
- Viele Produkte benötigen kein riesiges Modell, das mit dem gesamten Internet trainiert wurde; 99,9 % des Trainingsumfangs können für einen konkreten Use Case irrelevant sein
- Es kann passieren, dass die Betriebskosten eines LLM-basierten Dienstes höher sind als der Betrag, den Nutzer zu zahlen bereit sind
- Auch Geschwindigkeit beeinflusst die Produkterfahrung erheblich
- Bei einer Erfahrung wie ChatGPT, bei der man Wort für Wort mitliest, ist eine langsame Ausgabe bis zu einem gewissen Grad akzeptabel
- In Apps, die eine vollständige Antwort brauchen, bevor der nächste Schritt im Workflow möglich ist, führt Latenz direkt zu schlechterer Nutzbarkeit
- Builders Visual Copilot versuchte, Designs per LLM-Transformation in hochwertigen Code zu überführen, doch der Prozess, die komplette Designspezifikation einzugeben und tokenweise eine neue Repräsentation zu erhalten, dauerte mehrere Minuten und war daher unpraktisch
- Die vom LLM zurückgegebene Repräsentation war nicht menschenlesbar, sodass der Ladezustand im Grunde nur einem einfachen Spinner ähnelte; die User Experience war schlecht
Fine-Tuning allein reicht für echte Anpassung schwerlich aus
- LLMs unterstützen Fine-Tuning, sodass sie in gewissem Maß näher in die gewünschte Richtung angepasst werden können
- Builder wandte Fine-Tuning auf einen Ansatz an, bei dem Figma-Designs als Input eingegeben und Code als Output erzeugt werden, doch selbst mit vielen Beispielen verbesserte sich die Qualität nicht
- Das Ergebnis war ein langsamer, teurer und qualitativ schwacher Ansatz; es wurde eine andere Methode nötig
- Die gewählte Alternative war der Aufbau einer eigenen Toolchain
- fine-tuned LLM
- selbst geschriebener Custom Compiler
- selbst trainiertes Modell
- Heute ist das Training eigener Modelle nicht mehr nur Datenwissenschaftlern oder Machine-Learning-PhDs vorbehalten; auch Entwickler mit angemessener Erfahrung können es tun
- Dieser Ansatz ist schneller, zuverlässiger und hilft, ein günstigeres sowie stärker differenziertes Produkt zu bauen
Komplexe AI-Produkte bestehen nicht aus einem riesigen Modell, sondern aus Toolchains
- Ein häufiges Missverständnis über AI-Produkte ist die Vorstellung, dass eine einzige intelligente Kerntechnologie alles erledigt
- Auch selbstfahrende Autos funktionieren nicht so, dass eine einzige riesige AI Kameras, Sensoren und GPS-Eingaben empfängt und direkt eine Handlung wie Rechtsabbiegen ausgibt
- Tatsächlich werden mehrere spezialisierte Modelle und gewöhnlicher Code miteinander verbunden
- Computer-Vision-Modelle finden und identifizieren Objekte
- Modelle für prädiktive Entscheidungsfindung antizipieren das Verhalten anderer
- Natural-Language-Processing-Modelle verstehen Sprachbefehle
- Viel gewöhnlicher Code und Logik erzeugen das Endergebnis
- Selbstfahrende Autos sind ein deutlich komplexerer Fall, und zum Start eines typischen AI-Produkts ist ein solcher Komplexitätsgrad nicht nötig
- Auch Autofunktionen wurden nicht auf einmal fertiggestellt, sondern begannen mit Funktionen wie automatischem Einparken und automatischem Stoppen bei Nähe; später kamen Ebenen wie Spurhaltekorrektur und vollständige Fahrentscheidungen hinzu
- Wie bei Software werden auch AI-Funktionen gebaut, indem eine Ebene auf die nächste gesetzt wird
Erst mit gewöhnlichem Code lösen, AI nur dort ergänzen, wo sie nötig ist
- Ein wichtiger Ausgangspunkt im Visual-Copilot-Ansatz ist, zunächst keine AI einzusetzen
- Man sollte den Problemraum mit normalen Programmiertechniken erkunden und zuerst herausfinden, in welchen Bereichen tatsächlich ein spezialisiertes Modell nötig ist
- Der „Supermodell“-Ansatz, große Mengen Figma-Daten in ein Modell zu geben und direkt fertigen Code zu erhalten, ist zu komplex
- Es müssen viele Frameworks unterstützt werden
- Es gibt viele Styling-Optionen und Anpassungen
- Es ist schwierig, kontinuierlich mit neuen Daten nachzutrainieren
- Es kann komplex, langsam und teuer werden und dadurch den Produktlaunch selbst erschweren
- Builder erkundete zunächst, wie weit man ohne AI kommen kann
- Jeder Design-Node musste in ein Objekt umgewandelt werden, das sich als Code ausdrücken lässt
- Elemente wie Bilder, Hintergründe und Vordergründe mussten detailliert verstanden werden
- Es musste präzise behandelt werden, wie beliebige Inputs responsiv gemacht werden
- Mit handgeschriebener Logik wurden mehrere ausgefeilte Algorithmen erstellt, etwa damit vertikal gestapelte Elemente zu einer flex column und nebeneinanderliegende Elemente zu einer flex row werden
- AI wurde dort ergänzt, wo Standardcode an seine Grenzen stieß
- Automatisch zu erkennen, welche Layer zu einem einzigen Bild zusammengeführt werden sollten, ist für menschliche Wahrnehmung einfach, aber mit imperativem JavaScript-Code nicht leicht
- Gut etablierte Modelltypen wie Objekterkennung lassen sich in Produkten wie Google Vertex AI über eine GUI auswählen, mit vorbereiteten Daten hochladen und trainieren
- Für die Datenerzeugung kann das Internet genutzt werden
- Mit puppeteer Websites im Browser öffnen und Screenshots erstellen
- HTML durchlaufen und
img-Tags finden - Bildpositionen als Ausgabedaten und Website-Screenshots als Eingabedaten verwenden
- So erhält man Koordinaten von Teilbildern und Originalbilder und nutzt sie als Trainingsdaten für ein Objekterkennungsmodell
- Kombiniert man Code und spezialisierte AI-Modelle, kann man ein Design auswählen, auf Generate code klicken und nach etwa einer Sekunde zu Builder.io wechseln
- In Builder erhält man eine vollständig responsive Website und anpassbaren, hochwertigen Code; verschiedene Frameworks und Optionen werden unterstützt
Produktvorteile durch Kontrolle über eigene Modelle
- Mit eigenen Modellen endet man nicht dabei, externe Modelle nur zu umhüllen, sondern kann die Modelle kontinuierlich verbessern
- Wer ausschließlich von externen Modellen wie denen von OpenAI abhängt, kann nicht garantieren, wann sie für einen bestimmten Use Case intelligenter, schneller oder günstiger werden
- Auch der per Prompt Engineering und Fine-Tuning kontrollierbare Bereich ist begrenzt
- Visual Copilot befindet sich in der Beta, daher gibt es noch Designs, die nicht gut importiert werden; auf Basis von Nutzerfeedback werden täglich Verbesserungen ausgeliefert
- Wenn man die eigene Technologie kontrolliert, lassen sich auch Privacy-Anforderungen besser erfüllen
- Große datenschutzorientierte Unternehmen geben häufig das Feedback, dass sie OpenAI oder Produkte, die OpenAI verwenden, nicht nutzen können
- Es gibt die Anforderung, dass Daten nicht in nicht erlaubte Systeme gelangen dürfen
- Da Builder die gesamte Technologie kontrolliert, kann es hohe Datenschutzstandards anwenden
- Der LLM-Schritt ist nicht zwingend, sondern eher optional und kann deaktiviert werden
- Unternehmen können auch ihr eigenes LLM anbinden
- ein vollständig internes Modell
- ein
llama2-Fork - eine eigene Enterprise-OpenAI-Instanz
- andere Modelle
- AI sollte so sparsam wie möglich eingesetzt werden; gewöhnlicher Code sollte als schnelle, zuverlässige, deterministische Grundlage erhalten bleiben, die leicht zu debuggen, zu ändern, zu verwalten und zu testen ist
- Die Magie des Produkts entsteht nicht dadurch, alles durch AI zu ersetzen, sondern dadurch, AI-Modelle in kleinen, aber entscheidenden Bereichen einzusetzen
1 Kommentare
Hacker-News-Meinungen
Ich stimme der allgemeinen Stoßrichtung des Artikels zu, würde aber vermutlich nicht den vom Autor vorgeschlagenen Implementierungsansatz wählen.
Meine Schlussfolgerung ist, sich nicht zu stark auf LLMs zu verlassen. Das gilt sowohl für den Umfang der Aufgaben, die man ihnen überlässt, als auch dafür, sich nicht an ein bestimmtes LLM zu binden.
Selbst wenn man OpenAI intern nutzt, kann ein Produkt, das direkt mit ChatGPT konkurriert, langfristig im Nachteil sein. Wenn man eine App baut, mit der man Hotels und Flüge per Chatbot bucht, ist die Wahrscheinlichkeit groß, dass ChatGPT oder Microsoft, Google irgendwann ähnliche Funktionen besser anbieten und ein kleines Geschäft aushebeln.
Eine zu starke Abhängigkeit von Dingen wie dem OpenAI SDK halte ich ebenfalls für Zeitverschwendung; direkte Aufrufe der REST API sind flexibler.
Eine andere Frage ist allerdings, einen Compiler in die Toolchain aufzunehmen. Jedes Mal, wenn man einen Compiler hinzufügt, steigt die unnötige Komplexität und die Abhängigkeit von einem bestimmten Tool. Wenn React oder Svelte ausreichen, wirkt ein Komponenten-Cross-Compiler wie noch etwas Zusätzliches, das man lernen muss, um Web-Apps zu bauen.
Die eigentliche Botschaft des Artikels sollte meiner Meinung nach sein: „Baue die Toolchain, mit der du dein Ziel am effizientesten erreichst.“ Mehr Tools anzuhängen schafft nicht automatisch Wert, und dem zu folgen, was alle anderen tun, schafft ebenfalls keinen Wert. Das gilt nicht nur für die Integration von LLM-Apps, sondern für Software Engineering insgesamt.
Ich bin mir nicht sicher, wie AI das anders machen soll – oder ob es am Ende nicht auf dieselben Beschränkungen stößt.
Es wäre zwar einzigartig und nicht leicht zu kopieren, aber angesichts der unterstützten Sprachen dürften die Wartungskosten enorm sein.
Diese zusätzliche Abstraktionsschicht hat ein bisschen etwas von Factory-Factory-Factory.
Eher bietet AI sogar mehr Spielraum für Spezialisierung als die Flugsuche.
Bei Chatbots für Fachaufgaben ist die Qualität des allgemeinen Sprachmodells nicht der wichtigste Faktor, sobald die grundlegende Sprachinterpretation gut genug ist. Ein Reisebuchungs-Chatbot, der auf meine Vorlieben abgestimmt und mit relevanten Nischen-APIs integriert ist, wird nicht so leicht von einem allgemeinen Tool verdrängt, das Fragen etwas besser parst, aber alles über Expedia buchen will.
In solchen Märkten entstehen durch eine einzelne gute oder schlechte Empfehlung auch Markentreue oder Ablehnung, sodass es schwer ist, sie als nahezu Winner-takes-all zu betrachten.
Das war eigentlich nicht der Kern des Blogposts.
Ihr Produkt ist ein Tool, das Figma-Designdateien automatisch in React-Code umwandelt. Das Mittel, um dieses Problem mit normalem Code zu lösen, ist eben ein Compiler.
Es sagt niemand, dass alle Compiler verwenden sollen.
In diesem Kontext passt die Kritik an Compilern im Allgemeinen nicht besonders gut. Die Alternative wäre, ChatGPT wie einen Compiler zu verwenden, und der Artikel erklärt ziemlich überzeugend, warum das schlechter ist. Oder soll damit gemeint sein, dass ein Produkt, das React-Code generiert, grundsätzlich schlecht ist?
Der Artikel gibt Denkanstöße, und ich stimme der Kernaussage zu: „Nutze AI so lange wie möglich nicht.“
AI setzt man am besten für Dinge ein, die nur mit AI möglich sind. Wenn es eine Möglichkeit gibt, eine Funktion zu bauen oder ein Problem ohne AI zu lösen, ist das meist besser.
Da inzwischen alle nahezu denselben Zugang zu Spitzenmodellen haben, werden gute Produkte am Ende zwangsläufig durch Nicht-AI-Dinge definiert: Workflow, UI, Nutzererfahrung, Performance und andere klassische Faktoren.
Beim Rat „Trainiere dein eigenes Modell“ bin ich allerdings nicht überzeugt. Das kann ein Weg sein, ein Produkt schnell veralten zu lassen. Kurzfristig kann es differenzieren, aber wenn OpenAI oder ein massiv finanzierter Wettbewerber innerhalb von 6 bis 12 Monaten ein deutlich besseres Modell herausbringt, wird dieses differenzierende Modell direkt zu technischer Schuld.
Dass ein kleines Startup über Modelle konkurrieren will, wirkt wie eine große Ablenkung. Es ist vergleichbar damit, eine eigene Datenbank zu bauen, statt Postgres oder MySQL zu nutzen. Natürlich braucht man einen Burggraben und ein Produkt, das schwer zu kopieren ist, aber es sollte ein Bereich sein, in dem man mit den vorhandenen Ressourcen realistisch der Beste werden kann.
Dann kam ChatGPT heraus, die Arbeit der Wettbewerber war schlagartig veraltet, und er konnte die AI-Funktionen innerhalb weniger Wochen nachziehen.
Er lag richtig damit, was gebaut werden sollte, aber aus den falschen Gründen – und am Ende war das ein enormer Gewinn für das Geschäft.
Differenzierung ist tatsächlich ein ziemlich wichtiger Faktor.
Guter Beitrag, und ich denke, er dürfte die meisten neuen AI-Startups ansprechen. Mein Rat wäre, gar kein AI-Produkt zu bauen.
Das Raster „X-Produkt“ führt selten in eine Richtung, die Kund:innen mehr Wert bringt. Beispiele wären Web3-Produkte, Observability-Produkte, Machine-Vision-Produkte oder AI-Produkte.
Wie bei allen guten Startup-Ideen geht es im Kern darum, von einem echten Nutzerbedarf auszugehen, statt ein Problem zurechtzubiegen, weil man eine aufkommende Technologie einsetzen will. Nur eine UI auf eine überhypte Technologie zu setzen, erfüllt noch keinen Nutzerbedarf.
Ich sage das nicht, weil ich LLMs nicht mag, aber die meisten Menschen, die ich offline kenne, hassen es, mit Chatbots als Produkt zu interagieren. Ich bin kürzlich umgezogen und musste mit Support-Bots von Energie-, Wasser- und Internetanbietern umgehen; alle waren schrecklich.
Ausgehend von „GPT ist cool“ einen maßgeschneiderten Chatbot zu bauen, wird meiner Ansicht nach kaum einen echten Nutzerbedarf lösen oder zu einem nachhaltigen Geschäft führen.
Schon ein Problem zu entdecken, das real genug ist, um technische Kosten zu rechtfertigen, liegt für viele Techniker:innen außerhalb ihrer Komfortzone. Wir nehmen an, dass ein Problem real ist, oder schlimmer noch: Wir hoffen, dass es real ist, und stürzen uns direkt auf die Lösung. Denn Bauen ist unser vertrautes Terrain.
Diese Haltung oder dieser Prozess ist nicht grundsätzlich falsch. In vielen Fällen, in denen Techniker:innen echte Probleme gelöst haben, zeigte sich das reale Problem zufällig im Prozess des Bauens, Iterierens und Abbrechens.
Deshalb kann die beste Methode für Techniker:innen, echte Probleme zu finden, weniger darin bestehen, lange in der Problemfindung zu verharren, sondern in einem besseren Launch-Iterate-Stop-Zyklus: die aktuelle Nutzung beobachten, daraus die Zukunft abschätzen und schnell entscheiden, was man nicht bauen sollte.
Nachdem ich Biografien mehrerer Tech-Leader gelesen habe, sehe ich die zentrale Fähigkeit, die sie unterscheidet, darin, mit einem sehr einfachen MVP zu beginnen und ihre Intuition für künftige Nachfrage in kurzer Zeit exponentiell zu verfeinern.
Chatbots gab es schon vor ein paar Jahren, und fast jedes große Unternehmen hatte eine Strategie dafür. Die Idee war, Callcenter-Personal drastisch zu reduzieren und die Customer Experience zu verbessern.
Das Problem war nicht nur die Gesprächsqualität. Für viele Nutzer:innen ging es nicht nur darum, eine Antwort auf ihr Problem zu bekommen, sondern auch um das menschliche Gefühl von Verbindung, dass jemand zuhört.
Was ich will, ist, dass die Sache so schnell wie möglich erledigt wird; ob ich mit einem echten Menschen spreche, ist mir nicht wichtig.
Der Grund, warum Chatbots bisher nicht hilfreich waren, ist, dass sie dem Prozess Zeit und Frust hinzugefügt haben. Der erste Schritt bestand darin, den Chatbot dazu zu bringen, eine Telefonnummer auszuspucken oder einen endlich zu einem Support-Mitarbeiter durchzustellen.
Natürlich waren Chatbots vor OpenAI miserabel. Aber wenn Chatbots nach OpenAI wirklich großartig sind, sehe ich keinen Grund, warum Menschen sie nicht nutzen sollten.
Vor ein paar Jahren war es Blockchain. Ich weiß nicht, was als Nächstes kommt, aber man sieht schon, wie das LinkedIn-Netzwerk der „Techniker“ von Krypto-Startups zu AI-Startups gewechselt ist.
Das wirkt wie ein großer Trade-off zulasten der Launch-Geschwindigkeit.
Wenn man nach 6–12 Monaten launcht, könnten andere Teams bereits direkt gehostete Modelle nutzen, zweimal iteriert haben und eine echte Kundenbasis aufgebaut haben. Dann zeigst du deinem ersten Kunden v0.1, und der Kunde sagt vielleicht, dass er eigentlich etwas anderes wollte.
Dann geht es nicht darum, den Prompt ein wenig anzupassen, sondern darum, Compiler und Toolchain sowie den Stack von oben bis unten neu zu coden.
Wenn man Kund:innen und Anforderungen wirklich gut kennt, kann das sinnvoll sein. Aber in einer so einfachen Ausgangslage bin ich eher skeptisch, warum man nicht mit einem generischen und teuren, aber gehosteten Modell früh das Konzept validiert. Das ist so ein Fall von voreiliger Optimierung als Wurzel allen Übels.
Es gab viel Gerede über Technologie und Pipelines, aber ohne ein zu bauendes Produkt und ein zu lösendes Problem bedeutet das nichts.
Es ist ähnlich, als würde man mit Nutzer:innen darüber streiten, ob SOAP oder REST besser ist. Den Nutzer:innen ist egal, wie es gebaut wurde.
Aus Wettbewerbsperspektive wird hier viel zu kompliziert gedacht. Man muss einfach etwas bauen, das nicht leicht zu kopieren ist.
Es gibt viele Wege dahin, aber aus Wettbewerbssicht ist das die einzige nötige Regel.
In fast jedem vertikalen Markt ist noch nahezu 100 % des Gesamtmarkts offen.
Technische Differenzierung ist nur ein kleines Stück; zuerst kommt meiner Meinung nach Reichweite.
Es ist ein Rennen zu einer Milliarde Nutzer:innen, und wenn es wie bei uns B2B ist, wahrscheinlich ein Rennen zu einer Million Nutzer:innen. Gleichzeitig ist es ein Rennen um den höchsten Wert, also um das gelöste Problem und die User Experience, nicht um die besten technischen Spezifikationen.
Wenn der Unterschied etwas ist, das andere nicht mit OAI nachbauen können, ist es sicher, OAI zu nutzen.
Wenn der einzige Unterschied darin besteht, OAI zu nutzen, ist man ohnehin erledigt.
Dem im Fazit vorgeschlagenen Zustand stimme ich im Großen und Ganzen zu. Unser Produkt nutzt LLMs ebenfalls innerhalb eines Kontrollflusses wie einer State Machine, und das funktioniert gut.
Der Haltung des Autors stimme ich allerdings nicht zu. Entwickler:innen, die nur die ChatGPT-Web-UI genutzt haben, sollten die Technologie von „AI-Wrappern“ unbedingt selbst ausprobieren und bauen.
Denn bevor man die Grenzen der Top-Modelle selbst ausgelotet hat, ist es schwer zu erkennen, wo und wie man LLMs in einem traditionellen Software-Stack einsetzen sollte.
Auch die Firma des Autors scheint letztlich diesen Weg gegangen zu sein. Zunächst baute sie einen LLM-basierten Prototyp, der von Figma in Code umwandelte, und nachdem er „bis zu einem gewissen Grad“ funktionierte, entdeckte sie die Lücken im Prozess.
Deshalb halte ich es für besser, mit etwas wie GPT-4-Vision ein „AI-basiertes Bewertungssystem für Trading Cards“ oder was auch immer man will zu bauen und danach herauszufinden, wie man es wie builder.io zu einem tatsächlich funktionierenden Produkt macht.
Es sieht so aus, als würde KI bald in viele Softwareprodukte eingebaut werden. Dann wird es wirklich cool – und auch beängstigend.
Ein einfaches Beispiel ist ein E-Mail-Client. Wenn jemand um eine Entscheidung oder Bestätigung bittet, könnte die KI die Frage extrahieren und Radiobuttons anbieten.
Beispiel: Vorgeschlagene Terminzeit akzeptieren: [Freitag 10:00] [Montag 11:30] [Andere Zeit vorschlagen]
George fragt, ob er den Entwurf vorstellen kann: [Ja] [Nein]
Kundensupport-Ticket-Software wie Zendesk hat offenbar bereits KI. Es ist gut möglich, dass viele Supportanfragen schon nahezu automatisch beantwortet werden.
Auch Personalabteilungen könnten KI nutzen, um Bewerbungen vorzusortieren, im Internet zusätzliche Informationen über Bewerber zu recherchieren und daraus standardisierte Datenbankeinträge zu erstellen. Natürlich kann das sehr fehleranfällig sein.
Interessant sind Anwendungen dieser Art, nicht noch eine weitere ChatGPT-Erweiterung oder ein weiteres Plugin.
Für jede neue E-Mail will ich eine Pipeline ausführen lassen, die einige Aktionen vorschlägt.
Ich wälze noch mehrere Ansätze im Kopf, aber es wirkt schon jetzt gut machbar.
Die Einleitung wirkt etwas zu blumig und übertrieben. Zum Beispiel sind LLMs gar nicht so teuer, die WSJ-Behauptung, Copilot mache pro Nutzer Verlust, überzeugt mich kaum, und LLMs sind auch nicht immer „quälend langsam“.
Die eigentlichen Empfehlungen des Artikels sind trotzdem ziemlich vernünftig.
Man sollte so viel wie möglich in Code erledigen und für die Teile, die sich nicht mit Code lösen lassen, spezialisierte KI einsetzen.
Das ist sinnvoll, aber nicht besonders neu.
Ich hatte gehofft, der Artikel würde tiefer darauf eingehen, wie man wirklich nützliche und gute KI-Produkte baut. In letzter Zeit gab es viele Versuche wie den Launch von Humane, aber bislang offenbar nicht viele Erfolge.
Dieser Artikel konzentriert sich stark darauf, wie man KI-Produkte baut. Persönlich glaube ich jedoch, dass Erfolg und Misserfolg von „KI-Produkten“ weniger von Differenzierung, Kosten, Geschwindigkeit oder Modellanpassung abhängen als davon, ob sie wirklich nützlich sind.
Leider wirken die meisten Produkte, die ich bisher gesehen habe, wie Lösungen auf der Suche nach einem Problem.
Meiner Ansicht nach sollten Unternehmen jetzt die langweiligsten und repetitivsten Teile der Nutzung ihrer Produkte identifizieren und Wege finden, sie mit KI zuverlässig zu vereinfachen.
Wie bei jedem Hype-Zyklus gilt: Wenn man nur einen Hammer hat, sieht alles wie ein Nagel aus.
Der Hammer von vor Kurzem war Blockchain, jetzt ist es KI.
Wenn man naiv genug war, auf die Versprechen der Blockchain hereinzufallen, ist es nur folgerichtig, enttäuscht zu sein, dass KI kein Schnell-reich-werden-Pyramidensystem ist, das einem ohne Zeit, Energie oder eigenständiges Denken Millionen einbringt.
Wenn man nur danach sucht, wird man weiter enttäuscht werden – und das zu Recht.
KI hat viel mehr zu bieten als Blockchain. Die beiden auf eine Stufe zu stellen, bedeutet, dass man keines von beiden richtig verstanden hat.