Der Wochenendtrip, der seine eigene App bekam

Ich habe meiner Frau ein Wochenende in Hamburg geschenkt. Als ich sie fragte, wie sehr sie in die Planung involviert sein wollte, sagte sie: gar nicht. Gut. Dann mache ich das.

Also habe ich Perplexity geöffnet und angefangen. Hotel, Restaurants mit Reservationen, Sightseeing, wie man sich fortbewegt, was am Samstagabend läuft. Ein paar Stunden später hatte ich ein Dokument voller nützlicher Notizen — aber es waren eben Notizen. Wann man ins Hotel einchecken kann. Welcher U-Bahn-Ausgang am nächsten am Eingang liegt. Wann der Tisch reserviert ist. Wann im Comedy-Club die Türen öffnen. Die Adresse der Konzerthalle.

Beim Durchlesen wurde mir klar: Das würde während des Trips ein Chaos werden. Zwischen einer Notiz, einer Karten-App, einem Screenshot der Öffnungszeiten und der E-Mail-Bestätigung fürs Restaurant hin und her zu wechseln — nichts davon passte zusammen. Was ich eigentlich wollte, war eine Karte. Eine einzige Karte, mit unseren Sachen darauf, und den Zeiten an den richtigen Pins.

Und dann fiel mir ein: Ich hatte noch gratis Credits aus einer Perplexity-Marketingkampagne für ihr agentisches Computer-Tool. Also bat ich es, eine kleine mobile Web-App für den Trip zu bauen — Android und iOS, einfach ein Browser-Link, kein App Store. Zwanzig Minuten später hatte ich eine funktionierende erste Version, mit unserem Hotel als Basis, jedem Pin, der uns wichtig war, und allen Zeiten fest verdrahtet.

Dieser Guide handelt davon, was mich diese Erfahrung gelehrt hat. Es geht weniger um Hamburg und mehr darum, wozu KI mittlerweile gut genug ist und wo sie noch an eine Decke stösst.

Research-Agents verstehen, was du eigentlich willst

Das war die erste Überraschung. KI-Suche im Allgemeinen gibt es schon eine Weile. Was mir diesmal auffiel: Der Research-Agent in Perplexity beantwortete nicht nur meine Fragen, er beantwortete die Frage hinter der Frage.

Ich konnte Dinge fragen wie: «Finde Restaurants zwischen unserem Hotel und der Konzerthalle, die nach der Show noch offen sind.» Nicht drei separate Suchanfragen. Nicht eine Liste von jedem Restaurant im Stadtteil. Genau die, die zu dem passen, wo wir tatsächlich sein würden und wann.

Als ich zum Hop-on-Hop-off-Bus fragte, brachte der Agent Widersprüche im eigenen Material des Anbieters ans Licht — eine Seite nannte für eine Haltestelle eine Adresse, eine andere legte etwas anderes nahe — und er meldete den Widerspruch, statt einfach eine Version zu wählen und so zu tun, als gäbe es kein Problem. Das ist genau die Art von Sache, für die man früher drei Browser-Tabs gleichzeitig offen haben musste.

Die Lektion: Wenn du einen Research-Agent für etwas wirklich Nützliches einsetzt, behandle ihn wie eine kluge Assistenz, die das ganze Projekt im Kopf behalten kann. Zerlege deine Bedürfnisse nicht in Suchanfragen. Beschreib einfach, was du vorhast.

Der Bau: zwanzig Minuten bis zur funktionierenden App

Die erste Version war fast beschämend schnell fertig. Ich beschrieb, was ich wollte — eine mobile-first Karte mit unserem Hotel als Basis, Pins für jeden Programmpunkt und jede Reservation samt Zeiten, Overlays für begehbare Stadtviertel, GPS-Unterstützung, Links, die Google Maps oder Apple Maps öffnen, damit wir bei Bedarf trotzdem richtig navigieren konnten.

Der Agent wählte einen statischen Web-App-Stack — HTML, CSS, JavaScript, Leaflet für die Karte, OpenStreetMap-Kacheln. Kein Backend, keine Datenbank, kein Login. Nur eine URL, die wir auf unseren Handys öffnen konnten. Zwanzig Minuten nach meinem ersten Prompt hatte ich den Link.

Denk kurz darüber nach, was das bedeutet. Vor drei Jahren wäre «bau mir eine eigene mobile App für ein bestimmtes Wochenende» ein Projekt gewesen. Heute ist es ein Prompt. Die Fähigkeit, auf die es ankommt, ist nicht mehr «kannst du programmieren». Es ist «kannst du das Richtige klar beschreiben».

In zehn Minuten besser als ein etablierter Anbieter

Dieser Teil hat mich wirklich beeindruckt.

Der Hop-on-Hop-off-Bus erwies sich als die effizienteste Art, sich in der Stadt fortzubewegen, ohne Geld für Taxis zu verbrennen. Ich suchte nach dem digitalen Angebot des Anbieters und fand … eine schlichte Website. Statische Bilddateien der Streckenkarte, einige davon sichtbar an den Rändern abgeschnitten. Keine interaktive Karte. Keine Web-App. Keine mobile App. Nur Bilder.

Also bat ich meinen Agent, die Busroute als Overlay auf meiner eigenen Karte hinzuzufügen: jede Haltestelle als Pin, die Route als Linie eingezeichnet, den Fahrplan an jeder Haltestelle, dazu die Sehenswürdigkeiten in der Nähe jeder Haltestelle, damit wir wussten, wofür wir eigentlich aussteigen sollten. Zehn Minuten später hatte meine private Wochenend-App eine bessere Version des Kernprodukts dieses Busanbieters als der Anbieter selbst.

Ich habe kurz halb ernsthaft überlegt, ihnen eine E-Mail zu schreiben. Dann habe ich darüber nachgedacht, was das tatsächlich bedeuten würde — das ist die nächste Lektion.

Die Iterations-Steuer (und wohin meine gratis Credits gingen)

Die erste Version sah grossartig aus. Dann fing ich an, die tatsächliche Nutzung zu simulieren.

Die Pins lagen 200 Meter daneben. Sogar das Hotel war ein paar Blocks von seinem tatsächlichen Standort entfernt — der Agent hatte ungefähre Koordinaten verwendet, was für einen Screenshot in Ordnung ist und nutzlos, wenn du durch eine Stadt läufst und einen Hauseingang suchst. Fix: auf adressbasiert geokodierte Koordinaten wechseln und die wichtigen Pins nochmals prüfen.

Die «In Google Maps öffnen»-Links öffneten direkt den Navigationsmodus, was falsch ist — man will den Ort zuerst sehen und dann entscheiden, ob man navigiert. Fix: das URL-Muster von /dir/ auf /maps/search/ ändern.

Ich machte Änderungen auf meinem Laptop, sie erschienen auf dem Desktop, aber nicht auf meinem Handy — weil das Handy die alten JavaScript-Dateien gecacht hatte. Fix: die Asset-URLs versionieren, damit der Browser weiss, dass er frische Kopien holen soll.

Auf dem Handy war das untere Panel mit der Pin-Liste praktisch blockiert — man konnte es nicht nach oben ziehen. Fix: explizites Touch-Handling und einen richtigen Scroll-Container hinzufügen.

Und die Bushaltestellen-Daten stimmten immer noch nicht. Am Ende habe ich die offiziellen Haltestellennamen und Koordinaten des Verkehrsbetriebs abgeglichen und die korrigierte Liste zurückgespielt.

Jeder dieser Punkte kostete eine Runde mit dem Agent. Jede Runde frass Credits. Irgendwo dazwischen gingen mir die gratis Credits aus, und ich steckte schon zu tief drin, um aufzuhören, also kaufte ich mehr dazu. Das ist ein echter Kostenpunkt, und er verdient es, benannt zu werden: Ein funktionierendes Ding mit KI zu bauen geht schnell. Aber ein funktionierendes Ding in ein gutes Ding zu verwandeln, braucht immer noch Iteration — und Iteration ist nicht gratis.

Die tiefere Lektion betrifft das Testen. Die Validierung am Desktop übersah sämtliche mobil-spezifischen Probleme. Der einzige Weg, sie zu finden, war die App tatsächlich auf einem Handy zu benutzen, in einer echten Situation, während man so tut, als wäre man die Person, für die sie gebaut wurde. Dafür gibt es keine Abkürzung. Echtes Testen auf dem echten Gerät ist die eigentliche Arbeit.

Wo Vibe Coding aufhört, Magie zu sein

Für ein Wochenende, für zwei Personen, die ich persönlich kenne, für eine einzige Reise — das war ein perfekter Anwendungsfall. Eine Wegwerf-App, eine private URL, ein echtes Problem, gelöst an einem Nachmittag. Dass sie nicht übersetzt ist, keine Zahlungen annimmt, nicht zehntausend gleichzeitige Nutzer bewältigt, keinen Feedback-Kanal hat, ein Update des Handy-Betriebssystems nicht elegant übersteht — nichts davon spielt eine Rolle, weil es nicht musste.

Aber ich ertappte mich dabei, wie ich mir die E-Mail an den Busanbieter vorstellte. Hier ist, was tatsächlich nötig wäre, um mein Wochenend-Spielzeug in etwas zu verwandeln, das sie ausliefern könnten:

• Es müsste gewartet werden — Haltestellen ändern sich, Routen ändern sich, Fahrpläne ändern sich.
• Es müsste sicher sein — öffentlich zugänglich, zahlungsrelevant, DSGVO-relevant.
• Es bräuchte Übersetzungen — Hamburg hat Touristen aus aller Welt.
• Es bräuchte eine Möglichkeit, Tickets zu kaufen, Support zu kontaktieren, Feedback zu geben.
• Es müsste auf jedem Handy, jedem Browser, jedem Viewport funktionieren — nicht nur auf den zwei Geräten, die ich zufällig getestet habe. Jeder Bugfix würde die Möglichkeit für neue Bugs an anderer Stelle schaffen.
• Es bräuchte Analytics, Fehler-Reporting, einen Release-Prozess.

Genau hier hört Vibe Coding auf und fängt Software Engineering an. Es hört nicht bei der ersten funktionierenden Version auf. Es hört bei allem auf, was danach kommt. Das Verhältnis, das mir immer wieder auffällt: KI bringt dich in zwanzig Minuten zu «funktioniert für mich» und zu «funktioniert für alle, zuverlässig, dauerhaft» in … nun, ungefähr derselben Zeit, die es schon immer gebraucht hat, plus/minus. Der Agent hilft auch bei dieser zweiten Reise wirklich weiter, aber er ist nicht mehr die Hauptfigur. Das bist du.

Das ist keine Klage. Es ist das nützlichste mentale Modell, das ich gefunden habe, um zu entscheiden, wann man sich auf KI-gebaute Tools verlassen kann und wann man einen Schritt zurücktreten sollte. Wenn die Nutzerzahl klein und die Lebensdauer kurz ist, vibe-code es. Wächst eines von beidem, meldest du dich für die volle Disziplin des Software-Bauens an — und das solltest du vorher wissen.

Was ich wieder genauso machen würde

Auch mit den verbrannten Credits war das eines der schönsten Nebenprojekte, die ich seit langem gemacht habe. Ein paar Dinge, die ich beim nächsten Mal genauso machen würde:

1. Mit Recherche beginnen, nicht mit Bauen. Die Stunde, in der der Agent den Trip kartierte — Programmpunkte, Alternativen, Stadtviertel, Widersprüche —, machte den Bau trivial. Direkt mit «bau mir eine App» loszulegen, hätte etwas Generisches ergeben.
2. Erst kuratieren, dann bauen. Ich habe bewusst Pins entfernt. Nicht jedes Restaurant. Nicht jede Sehenswürdigkeit. Nur die, die uns tatsächlich wichtig waren, plus eine kleine Auswahl guter Alternativen. Der Wert der App lag darin, dass sie enger war als Google Maps, nicht breiter.
3. Auf dem Gerät testen, das du tatsächlich nutzt. Klingt offensichtlich. War es nicht, bis ich es getan habe.
4. Die Iterationskosten von Anfang an einplanen. Zeit und, falls du bezahlte Agents nutzt, Credits dafür budgetieren. Die erste Version ist der einfache Teil.
5. Wissen, wann man aufhört. Ich habe mich ein paar Mal dabei ertappt, wie ich Features hinzufügen wollte, die für ein einziges Wochenende keine Rolle spielten. Zurückhaltung ist hier eine Fähigkeit für sich.

Die ganze Erfahrung war ein kleines, prägnantes Beispiel dafür, was KI gerade mit der Grenze zwischen Konsument und Erbauer macht. Vor fünf Jahren war «eine eigene App für unser Wochenende» nichts, was eine normale Person selbst gebaut hätte. Heute ist es ein Nachmittag. Und die Frage ist nicht mehr «kann ich das bauen», sondern «ist es meine Zeit wert, das zu bauen, angesichts dessen, was ich danach warten muss?»

Für ein Wochenende in Hamburg, mit meiner Frau, auf einer Karte, die ich selbst gebaut habe? Absolut.

---

Wenn du sehen willst, was KI-Agents in einem allgemeineren Workflow leisten können: Der Recherche-Pipeline-Guide zeigt, wie ich Perplexity und Claude im Alltag zusammen nutze. Und wenn du daran denkst, etwas Dauerhafteres als eine Wochenend-App zu bauen: Der Guide zur gratis Website führt durch den GitHub-basierten Stack, der tatsächlich mitwächst.