Braucht das ein Produkt, oder braucht das eine gute Anweisung?
Vier Tage Entwicklung, dann das Gespräch mit dem Journalisten, für den das Werkzeug gedacht war. Warum ich es gestoppt habe und woran man erkennt, dass man zu früh baut.
Vier Tage Entwicklung, dann das Gespräch mit dem Journalisten, für den das Werkzeug gedacht war. Warum ich es gestoppt habe und woran man erkennt, dass man zu früh baut.
Aus dem eigenen Vibe-Coding-Chaos zur klaren Reihenfolge: warum Design Tokens das Fundament sind und mit welchen rund 60 Tokens ich anfange, bevor die erste Komponente entsteht.
Ich bin spezialisiert. Aber ein Thema allein hat mir nie gereicht: 80 % Hauptsache, 20 % Ausprobieren, und wie KI das Lernen verändert.
Begonnen in Webflow, dann umgezogen. Warum mir das Tool zu langsam wurde und was es nicht mitliefert: Grundlage, Auge und ein Gefühl für das Wichtige.
Vier Tage Arbeit, ein fertiges Produkt, und dann die Rückmeldung des Journalisten, für dessen Arbeit ich es gebaut hatte. Danach habe ich es gestoppt. Nicht weil die Technik versagt hätte, sondern weil ich die wichtigste Frage zuletzt gestellt habe statt zuerst.
Dieser Text ist kein Erfolgsbericht. Er beschreibt einen Fehler, den ich inzwischen bei vielen sehe, die mit KI-Werkzeugen arbeiten. Er ist neu in seiner Form, und er hat eine einfache Ursache: Bauen ist billiger geworden als Fragen.
Ein befreundeter Fernsehjournalist dreht Reportagen für Arte, ZDF, Galileo und Spiegel TV. Seine Themen sucht er verstreut: eigene Feeds, Instagram, ausländische Medien, Hinweise aus dem Umfeld. Nichts davon liegt an einem Ort.
Die Idee lag nahe. Ein Assistent, der diese Quellen automatisch durchsucht, redaktionell filtert und Vorschläge liefert. Ich habe ihn gebaut.
Ein kuratiertes Quellenset aus 50 Feeds in neun thematischen Blöcken, geografisch eingegrenzt.
Ein Regelwerk aus redaktionellem Fachwissen. Das war der eigentliche Kern der Arbeit, denn ein Sprachmodell mit Websuche findet in Minuten interessante Geschichten. Nur ist interessant nicht dasselbe wie verkäuflich. Also habe ich rekonstruiert, wie eine Redaktion tatsächlich entscheidet: ein hartes geografisches Tor, ein deutscher Anknüpfungspunkt als Pflichtkriterium, eine Prüfung gegen bereits Gesendetes, Sendeprofile mit Belegpflicht. Jeder Vorschlag musste einen vergleichbaren aktuellen Titel des Zielsenders nennen, als Beleg dafür, dass der Sendeplatz überhaupt existiert.
Dazu eine Rückmeldeschleife, weil es bei generierten Inhalten keine richtige Antwort gibt, an der sich Qualität messen ließe. Jedes Thema wird von 1 bis 10 bewertet, bei niedrigen Noten erscheinen typisierte Absagegründe.
Und schließlich der Betrieb: Zeitplan, Speicher, Mailversand, eine Auswertung, die Reibung misst statt Zufriedenheit.
Alles lief. Dann habe ich es dem Journalisten gezeigt.
Er nahm sich die neun Vorschläge einzeln vor, bewertete jeden und fasste es dann in einem Satz zusammen: die Themen sind zu allgemein.
Das ist kein vernichtendes Urteil, sondern ein präzises. Ein Stoff, den eine Redaktion kauft, braucht einen konkreten Ort, einen konkreten Menschen, einen konkreten Zugang. Was mein Werkzeug lieferte, waren gut begründete Themenfelder. Themenfelder kauft niemand.
Dazu kam ein zweiter Satz, der mehr wog als der erste: ihm war nicht klar, wozu das Werkzeug dient und was es leisten könnte.
Wer ein Werkzeug nicht versteht, kann es nicht steuern und auch nicht verbessern. Er geht einfach weg.
Er hatte sich nicht widersprochen. Er beschrieb seine Anforderungen ehrlich, so wie er sich die Aufgabe zu diesem Zeitpunkt vorstellte. Erst am fertigen Werkzeug bekam er die Sprache dafür, was ihm fehlt.
Genau dafür ist ein früher Prototyp da. Nicht um zu treffen, sondern um ein Nein möglich zu machen. Meine Aufgabe wäre gewesen, ihm dieses Nein früher zu ermöglichen.
Was ich gebaut hatte, war ein Produkt, kein MVP. Die Grundannahme, ob dieser Journalist überhaupt vorgeschlagene Themen braucht, hätte eine halbe Stunde Prüfung gekostet: eine Liste mit fünf Stoffen, per Nachricht geschickt, eine Frage dazu. Alles Weitere waren Aufbauten auf einer Annahme, die niemand bestätigt hatte.
Der Wert lag im Quellenset und im Regelwerk. Nicht in Oberfläche, Speicher, Zeitplan und Versand.
Beides hätte als Anweisung innerhalb eines bestehenden KI-Assistenten leben können. Ohne Hosting, ohne laufende Kosten, ohne Deployment, ohne Domainverifizierung für den Mailversand. Der Aufwand für ein eigenes Produkt lohnt erst, wenn geklärt ist, dass die Inhalte taugen und die Form zum Nutzer passt.
Diese Frage stelle ich mir seitdem zuerst: Braucht das ein Produkt, oder braucht das eine gute Anweisung?
Ein Tag Recherche kostete 1,68 Millionen Eingabe-Token bei 80 Websuchen, umgerechnet rund sechs Dollar. Der Grund liegt in der Mechanik: Inhalte aus der Websuche werden nicht nur bei ihrem Fund abgerechnet, sondern in jedem weiteren Schritt erneut als Eingabe.
Daraus folgten drei Eingriffe, die das Produktverhalten veränderten: eine Obergrenze für Suchen je Anfrage, gleichbleibende Regeln in den zwischengespeicherten Systemteil verlagert, Rhythmus von fünf auf drei Ausgaben pro Woche reduziert.
Bei einem KI-Produkt ist der Preis je Durchlauf keine Größe, die man am Ende ausrechnet. Er bestimmt mit, wie oft das Produkt überhaupt arbeiten darf.
Ich habe drei Tage lang über Schriftgrößen, Linien und Abstände entschieden, ohne dass zur inhaltlichen Qualität der Vorschläge eine belastbare Rückmeldung vorlag.
Detailarbeit an der Oberfläche ist ein verlässliches Zeichen dafür, dass die darüberliegende Frage noch offen ist. Sie fühlt sich nach Fortschritt an, weil sie sichtbare Ergebnisse produziert. Und sie ist angenehmer als ein Gespräch, in dem jemand sagen könnte, dass die ganze Idee nicht trägt.
Früher hielt der Aufwand das Gleichgewicht. Eine funktionierende Anwendung kostete Wochen, also prüfte man vorher grob, ob sich das lohnt. Diese natürliche Bremse gibt es nicht mehr.
Mit KI-Werkzeugen entsteht in vier Tagen, wofür man früher ein Team gebraucht hätte. Das ist ein Gewinn, aber er hat einen Preis: Die Prüfung, die früher erzwungen war, muss heute als Entscheidung getroffen werden. Jedes Mal neu, gegen den eigenen Impuls, einfach loszubauen.
Ich halte das für die wichtigste Disziplin in der Arbeit mit KI. Nicht die Werkzeugkenntnis. Die holt man in Wochen auf.
Wann lohnt sich ein eigenes KI-Tool und wann reicht ein Assistent mit guter Anweisung?
Ein eigenes Produkt lohnt, wenn mehrere Menschen es nutzen, wenn Daten dauerhaft gespeichert werden müssen oder wenn etwas ohne menschliches Zutun laufen soll. Für alles andere genügt in der Regel eine sorgfältig formulierte Anweisung innerhalb eines bestehenden Assistenten. Diese Prüfung spart erfahrungsgemäß mehrere Tage Arbeit.
Wie validiere ich eine KI-Idee, ohne etwas zu bauen?
Indem man das Ergebnis von Hand erzeugt und dem künftigen Nutzer zeigt. Fünf Beispiele reichen meist aus, um zu erkennen, ob die Richtung stimmt. Erst wenn die Trefferquote überzeugt, beginnt die Produktarbeit.
Was kostet ein KI-Assistent im laufenden Betrieb?
Das hängt stark von der Websuche ab. In meinem Fall lag ein Rechercheduchlauf bei etwa 55 bis 65 Cent, weil gefundene Inhalte in jedem weiteren Schritt erneut als Eingabe berechnet werden. Bei drei Durchläufen pro Woche ergibt das rund 15 bis 20 Dollar im Monat, zuzüglich Hosting.
Woran erkenne ich, dass ich zu früh baue?
Wenn Sie über Details der Oberfläche entscheiden, bevor eine belastbare Rückmeldung zur inhaltlichen Qualität vorliegt. Das ist das zuverlässigste Warnzeichen, das ich kenne.
Ich bin End-to-End-Designerin in Hamburg und arbeite an der Schnittstelle von Gestaltung, KI-gestützten Abläufen und Automatisierung. Wenn Sie vor der Frage stehen, ob eine Idee ein eigenes Produkt braucht oder eine gute Anweisung genügt, schreiben Sie mir gern.
Beim Vibe-Coding ist mir mein eigenes Chaos aufgefallen: Farben, Abstände und Radien, jedes Mal ein bisschen anders. Also habe ich mir angeschaut, was ein Design System wirklich trägt und in welcher Reihenfolge man es aufbaut, bevor die erste Komponente entsteht.
Die wichtigste Erkenntnis zuerst: Design Tokens sind das Fundament, nicht das Detail. Sie sind die Sprache, in der auch die KI arbeitet. Sage ich Claude nicht ausdrücklich, dass er die vereinbarten Tokens nutzen soll, schreibt er die Werte hart in den Code, am System vorbei.
Mit rund 60 Tokens starten und wachsen, wenn eine echte Komponente es braucht. Nicht umgekehrt.
Was mir Ordnung gebracht hat, ist eine dreistufige Architektur. Jede Ebene hat eine klare Aufgabe:
Als Grundgerüst orientiere ich mich an Material Design 3. Sieben Bausteine, die jedes System braucht:
Der Community-Konsens 2026 ergänzt das noch um zwei Punkte: Barrierefreiheit nach WCAG 2.1 AA und ein sauberes Raster mit Breakpoints.
Der Trick ist, nichts zu überspringen. Ich baue von unten nach oben:
Für meine eigene Website reicht ein schlankes Set, das an einem Arbeitstag in Figma Variables steht:
Zusammen sind das rund 60 Tokens. Genug, um konsistent zu starten, und schmal genug, um nicht daran zu ersticken.
Am Ende geht es nicht um mehr Regeln, sondern um weniger Entscheidungen im Alltag. Wenn die Grundlage steht, wird jede spätere Wahl leichter, für mich und für die KI.
Meine Seite habe ich in Webflow begonnen. Dann habe ich ein anderes Projekt mit Claude Code gebaut. Und gemerkt: für mich ist Webflow inzwischen zu langsam. Also habe ich meine eigene Seite auch umgezogen.
Mit Claude Code entsteht eine Seite schnell. Das stimmt. Aber damit sie gut wird, muss ich schleifen. Iterieren. Varianten wegwerfen.
Und dafür brauche ich ein paar Dinge, die das Tool nicht mitliefert:
Die Frage bleibt dieselbe wie vor der KI:
Erfüllt die Seite ihre Aufgabe und ihr Ziel, das am Anfang gesetzt war?
Nicht „ist sie schön". Nicht „ist sie modern". Nicht „ist sie schnell gebaut". Sondern arbeitet sie für das, wofür sie gemacht wurde.
Ich habe die Spezialisierung auf nur eine Sache nie verstanden.
Für mich war es immer spannend, ein Problem aus verschiedenen Perspektiven zu betrachten. Design, Marketing, Programmierung, Social Media. Wie sie sich gegenseitig beeinflussen. Wo die Grenzen sind. Wo eine Lösung aus einer Disziplin unerwartet in einer anderen funktioniert.
Man hat mir beigebracht, der richtige Weg sei Tiefe in einer Sache. Ich habe es versucht. Und mir wurde langweilig.
Heute teilt sich mein Arbeitstag ungefähr so auf. 80 % für die Hauptsache, in der ich meinem Kunden ein Ergebnis liefere. 20 % für Experimente in anderen Bereichen. Ich lese über Marketing Analytics, probiere ein neues AI-Tool aus, schaue mir an, wie irgendeine unbekannte Library funktioniert. Nicht um darin Expertin zu werden. Sondern um die Gesamtlandschaft zu verstehen.
Das hilft mir auch in der Kommunikation. Mit einem Marketing-Kollegen über CTR sprechen können. Mit einem Entwickler über Component-Struktur. Mit einem Kunden über sein Geschäftsmodell.
Wer nur in einer Sache zuhause ist, verliert einen Teil des Gesprächs, ohne es zu merken.
Früher waren diese 20 % ein Luxus. Neues zu lernen brauchte Zeit, Bücher, Kurse, Monate an Praxis. Heute gibt mir eine Session mit Claude oder ChatGPT ein grundlegendes Verständnis eines Themas in einer Stunde. Keine Expertise-Tiefe, aber genug, um mit einem Experten zu sprechen und die richtigen Fragen zu stellen.
Das hat die Regeln verändert.
Das klassische Modell Diffusion of Innovations (Everett Rogers) teilt Menschen in Gruppen ein, je nachdem, wie sie mit Neuem umgehen. Innovators und Early Adopters, die regelmäßig suchen und ausprobieren, machen zusammen etwa 16 % aus. Der Rest wartet, bis Neues bewährt ist.
Es geht nicht um gut oder schlecht. Menschen sind einfach unterschiedlich verdrahtet. Für manche ist Tiefe wichtiger, Stabilität, Mastery in einer Sache. Für andere sind es Neugier und Neues.
Jede Woche taucht etwas Neues auf, das ich wirklich mal ausprobieren möchte. Nicht alles funktioniert. Manches probiere ich aus und merke, es ist nichts für mich. Aber die 20 % Aufwand bringen regelmäßig Funde, die später Teil meiner 80 % werden.
Vor einem Jahr wusste ich nicht, dass man eine Website von Webflow zu Claude Code migrieren kann. Vor sechs Monaten waren AI-Agenten für mich noch keine Kolleg:innen. Vor drei Monaten habe ich noch nicht darüber nachgedacht, wie ich meinen Briefing-Prozess automatisieren könnte.
Tragen Sie Ihre geschäftliche E-Mail ein, ich schicke das Passwort innerhalb von 24 Stunden persönlich zu.
Verantwortlich i.S.d. § 18 Abs. 2 MStV: Viktoria Karasek (Anschrift wie oben).
Die Europäische Kommission stellt eine Plattform zur Online-Streitbeilegung (OS) bereit: ec.europa.eu/consumers/odr. Zur Teilnahme an einem Streitbeilegungsverfahren vor einer Verbraucherschlichtungsstelle bin ich nicht verpflichtet und nicht bereit.
Als Diensteanbieter bin ich gemäß § 7 Abs. 1 TMG für eigene Inhalte auf diesen Seiten nach den allgemeinen Gesetzen verantwortlich. Nach §§ 8 bis 10 TMG bin ich als Diensteanbieter jedoch nicht verpflichtet, übermittelte oder gespeicherte fremde Informationen zu überwachen.
Diese Website enthält Links zu externen Websites Dritter, auf deren Inhalte ich keinen Einfluss habe. Für die Inhalte der verlinkten Seiten ist stets der jeweilige Anbieter verantwortlich.
Die durch die Seitenbetreiberin erstellten Inhalte und Werke unterliegen dem deutschen Urheberrecht. Vervielfältigung, Bearbeitung und Verbreitung bedürfen der schriftlichen Zustimmung.
Viktoria Karasek, Hamburg · webkarasek@gmail.com. Kontaktdaten siehe .
Diese Website verwendet ein cookieloses Webanalyse-Werkzeug, um die Nutzung zu verstehen und die Inhalte zu verbessern. Es werden keine Cookies gesetzt und keine personenbezogenen Daten gespeichert; eine Einwilligung ist daher nicht erforderlich. Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an einer datensparsamen Reichweitenmessung).
Wenn Sie mich über Kontaktformular, Calendly oder direkt per E-Mail kontaktieren, werden die übermittelten Daten (Name, E-Mail, Nachricht, ggf. Telefon) zur Bearbeitung Ihrer Anfrage und für mögliche Anschlussfragen gespeichert (Art. 6 Abs. 1 lit. b und f DSGVO).
Diese Website setzt keine einwilligungspflichtigen Cookies (kein Tracking, keine Werbe- oder Marketing-Cookies). Verwendet wird ausschließlich technisch notwendiger lokaler Speicher für Session- und Oberflächeneinstellungen gemäß § 25 Abs. 2 Nr. 2 TTDSG. Ein Cookie-Banner ist daher nicht erforderlich.
Server-Logs werden nach 7 Tagen gelöscht. Die cookielose Webanalyse speichert keine personenbezogenen Daten. Kontaktanfragen werden nach Abschluss innerhalb von 6 Monaten gelöscht, soweit keine gesetzlichen Aufbewahrungspflichten bestehen.
Sie haben jederzeit das Recht auf Auskunft (Art. 15), Berichtigung (Art. 16), Löschung (Art. 17), Einschränkung der Verarbeitung (Art. 18), Datenübertragbarkeit (Art. 20) und Widerspruch (Art. 21 DSGVO). Anfragen bitte formlos per E-Mail.
Sie können sich bei einer Aufsichtsbehörde beschweren, insbesondere beim Hamburgischen Beauftragten für Datenschutz und Informationsfreiheit (HmbBfDI).