Wie ich unsere Website mit KI mitgebaut habe, ohne Engineering-Hintergrund
Vor einiger Zeit hat Valentin, unser Head of Internal IT, einen Post darüber geschrieben, wie sich sein Alltag verändert hat, seit die Pull Requests auch aus Marketing und HR kommen und nicht mehr nur von den Entwicklern. Hier ist dieselbe Geschichte von meiner Seite.
Ich arbeite im Marketing bei Posedio, Code schreiben war nie Teil meines Jobs. Im März habe ich noch gefragt, was ein Feature Branch ist und ob main aktuell ist. Seitdem sind dutzende Pull Requests für unsere neue Website dazugekommen: das Design über die ganze Seite vereinheitlicht, die Hero-Bilder für Mobile optimiert, unsere Seite Design Document as a Service, eine Newsletter-Landingpage, ein SEO-Durchgang über die Hauptseiten.
Fast nichts davon kam daher, dass ich programmieren gelernt hätte. Geändert hat sich, wie ich frage, wie ich prüfe und wo ich aufhöre und übergebe.
Was die KI nicht für mich bauen konnte
Mein Anteil daran war nur möglich, weil das Dev-Team vorher das Fundament gebaut hat. Sie haben den Tech Stack ausgewählt (Astro, Strapi, Google Cloud), die CI-Pipeline aufgesetzt, Preview-Environments konfiguriert, die i18n-Architektur entworfen und die Coding Conventions in eine CLAUDE.md geschrieben.
Die KI hat mir geholfen, innerhalb von dem zu arbeiten, was sie gebaut haben. Bauen hätte sie es für mich nie können. Alles Weitere ergibt nur Sinn, wenn das steht.
Wie ich frage: von Einzeilern zu brauchbaren Anweisungen
Am Anfang waren meine Anweisungen Einzeiler. "Setz die h1 auf 36 px." "Weg mit dem weißen Balken." Das ging gut, solange die KI richtig geraten hat, was ich meine. Oft hat sie falsch geraten: die falsche Datei, die falsche Sprachversion, das Element neben dem, das ich gemeint habe. Ich wusste damals auch noch nicht, dass "ich hab es im Browser geprüft" oft heißt, dass sie sich die Seitenstruktur angesehen hat und nicht, wie die Seite aussieht. Zweimal bin ich selbst nachschauen gegangen, und es hatte sich gar nichts geändert.
Der Fall, an den ich immer noch denke, war eine Überschrift. "Setz die h1 auf der Blog-Detailseite auf 36 px, nur Desktop." Wir haben eine Weile am CSS herumeditiert, ohne jede Wirkung. Der Blog zieht seinen Body nämlich über die Hauptseiten-Komponente, die Datei, die ich ausgesucht hatte, galt also für gar nichts. Ein Engineer hätte das in Sekunden gesehen. Die KI hat munter weiter genau das editiert, worauf ich gezeigt habe.
Zwei Dinge sind aus dieser Phase geblieben. Meine Anweisungen wurden länger und trockener, weil das, was zurückkommt, davon abhängt, wie genau man fragt. Und ich habe gelernt nachzuhaken: "Ich glaube, wir reden aneinander vorbei." "Was hast du gerade geändert?" Das klingt zu banal, um es zu erwähnen, aber ohne das landet man bei Ergebnissen, die plausibel aussehen und trotzdem falsch sind.
Später habe ich angefangen, den Rahmen vorher abzustecken statt mittendrin. Antworte auf Deutsch. Halt DE und EN gleich. Keine Commits ohne meine Freigabe. Nur Mobile, außer ich sage etwas anderes. Diese vier Zeilen ersparen uns beiden enorm viel Hin und Her.
In meinen Commits sieht man dieselbe Entwicklung. Die ersten sind im März ins Repository gegangen, und sie mir heute anzuschauen, tut ein bisschen weh. Einer heißt "Mobile & design refinements: text clipping, colors, logos, button styles", vier zusammenhanglose Änderungen in einem Klumpen, den Valentin dann reviewen durfte. Damals habe ich auch einfach "create a PR" getippt, ohne zu wissen, was ein Pull Request überhaupt ist. Ich habe die Wörter getippt, weil man es mir am Anfang so gesagt hat, und nicht, weil ich verstanden hätte, was zwischen ihnen und meiner Änderung auf der Seite passiert. Fast achtzig Commits später schauen meine so aus: "fix: keep sticky TOC clear of the site header". Eine Sache pro Commit, und ich könnte dir bei jedem sagen, was drinsteht.
Wie ich prüfe: vom Symptome-Beheben zum Planen
Eine ganze Weile war alles, was ich gemacht habe, eine Reaktion auf etwas Sichtbares. Lighthouse markiert ein Bild, jemandem fällt ein falsch geschriebener Name auf, eine Überschrift wirkt zu klein. Das Hero-Bild war so ein Fall. Die KI hat mir gezeigt, wie man das Cloud-Bild auf 1600 px runterbringt, eine 800-px-Variante für Mobile generiert, ein <picture> Element mit srcset aufsetzt und imagesrcset zum <link rel="preload"> ergänzt. Ich hatte keine Ahnung, dass es das alles gibt, aber das Ergebnis konnte ich selbst prüfen. Das Design zu vereinheitlichen war derselbe Modus, nur länger, Seite für Seite, bis die Website wieder wie ein Stück gewirkt hat.
Dann hat es sich gedreht. Bei der SEO-Arbeit habe ich aufgehört, einzelne Seiten zu fixen, sobald sie mir aufgefallen sind. Stattdessen erst ein Audit der Hauptseiten, dann Prioritäten, dann ein Pull Request. Ich habe auch angefangen, nach Meinungen zu fragen, statt Details zu diktieren. Welche Keywords sich auszahlen, ob diese Meta Description etwas taugt. Ungefähr so, wie ich mit einer Agentur arbeiten würde. Bei der Newsletter-Landingpage stand die erste Version in zehn Minuten, und danach habe ich fünf, sechs Mal an den Details gefeilt.
Die Seite, an der sich das wirklich bewähren musste, war eine größere.
Die Seite, an der ich am längsten gesessen bin
Das Design Document ist das, was ein Kunde von uns bekommt, bevor wir eine Zeile Code schreiben: die geplante Architektur, die Phasen, ein Fixpreis, eine Risikotabelle mit einem Owner pro Eintrag. Das in einem Satz auf der Services-Seite zu beschreiben, ist ihm nie gerecht geworden, also haben wir eine Seite gebaut, die eines zeigt. Hier ist sie live: Design Document as a Service.
Die Seite macht zwei Dinge. Sie erklärt, wie das Dokument entsteht, als Abfolge aus Workshop, Stop-or-Go-Entscheidung, erstem Entwurf, Review-Session und Freigabe. Und sie geht ein komplett durchgerechnetes Beispiel durch: die Architektur, die Phasen auf einer Timeline, non-functional requirements, bewertet über Kategorien wie Reliability und Maintainability, die Maturity Levels vom internen Tooling bis zu etwas Öffentlichem, Kundenseitigem, die Kostenfolgen mit Amortisationsdauer, die Risikotabelle, ein Glossar. Am Ende waren es rund 2.000 Zeilen über sieben Dateien.
Gut funktioniert hat die Arbeitsteilung. Der Inhalt kam von Sales und Technology, weil das die Leute sind, die diese Dokumente für Kunden schreiben und wissen, was hineingehört. Mein Teil hat danach angefangen: daraus eine Seite machen, die sich gut liest. Wie man ein sticky Inhaltsverzeichnis, eine Phasen-Timeline oder Bewertungen mit Tooltips baut, wusste ich nicht, und ich musste es auch nicht wissen. Ich habe beschrieben, was ein Abschnitt können soll, und die erste Version kam meistens nah genug zurück, um darauf zu reagieren.
Nicht gut funktioniert haben Handys. Die Desktop-Version ist in zwei Tagen gestanden. Am Handy ist dann das sticky Inhaltsverzeichnis unter den Site-Header gerutscht und das Hero-Icon auf kurzen Screens aus dem Viewport gefallen, und nichts davon war vorher aufgefallen. Die KI baut dir ein Layout, das bei der Breite funktioniert, auf die du gerade schaust. An einen 375-px-Screen denkt sie nicht, außer du sagst es ihr.
Die erste Version war auch nicht die letzte. In einem Review mit Sales und Technology sind wir das Beispieldokument noch einmal durchgegangen, und die Notes und der Architektur-Abschnitt sind umgeschrieben zurückgekommen. Mein Job war, den neuen Inhalt in die Seite zu bringen. Nach jeder Runde haben Valentin und die Pipeline die Visual-Regression-Baselines neu generiert, also die Referenz-Screenshots, gegen die unsere CI jede Seite vergleicht, damit eine ungewollte Layout-Änderung auffällt, bevor etwas gemergt wird.
Wo ich übergebe
Unsere Seite gibt es auf DE und EN, und die zu verwechseln ist mit Abstand mein häufigster Fehler. Ich ändere etwas auf einer Seite und vergesse, dass es das Gegenstück in /en/ auch gibt. Andersherum passiert es genauso: Ich bearbeite eine gemeinsame .astro-Datei, ohne zu merken, dass die englische Seite sie auch importiert, und dann bricht mit der einen Sprache die andere. Auf der Design-Document-Seite habe ich die deutsche Version mit englischen Kapiteltiteln, englischer Navigation und englischen Section-Chips ausgeliefert und es erst danach bemerkt. Die KI kriegt das zuverlässig hin, sobald man sie darauf hinweist, von allein denkt sie selten daran.
Dann gibt es die Kategorie, die ich bewusst nicht allein anfasse. Das Kontaktformular ans API-Backend anbinden, die Turnstile-Integration. Die KI gibt mir auf beides eine Antwort, und ich will nicht die Einzige sein, die draufgeschaut hat. Das ist dasselbe, was Valentin über Human Oversight schreibt, nur von der anderen Seite des Reviews.
Das Review ist der Teil, der sich nicht geändert hat. Valentin liest immer noch jeden Pull Request im Detail. Wenn etwas nicht passt, sagt er es, ich bessere aus und aktualisiere den PR, und wenn es passt, merged er. Lint, der Build und unsere Visual-Regression-Tests fangen einen Teil ab, bevor er überhaupt draufschaut, ersetzen diesen Schritt aber nicht. Ich habe noch nie selbst etwas in main gemerged, und ich will es auch nicht.
Was sich für den Rest von uns geändert hat
Unsere alte Seite lief auf Wix, und jede Änderung daran war ein Ticket für die interne IT. Eine Zeile Text ausbessern, ein Tag ergänzen, einen Button anpassen, und alles davon ist in der Queue von jemand anderem gelandet. Diese Tickets gibt es nicht mehr. Die, die wirklich einen Engineer brauchen, schon, und dafür ist jetzt mehr Zeit da.
Die Qualitätslatte ist dafür nicht gesunken. Ohne den Review-Schritt wären meine Pull Requests vielleicht funktional gewesen, aber nicht das, was Valentin "Senior-Frontend-Engineer-Qualität" nennt.
Website-Änderungen waren früher etwas, das ich angefragt habe und auf das ich dann gewartet habe. Jetzt sind sie etwas, das ich mache, und sie stehen auf meiner To-do-Liste wie alles andere auch.
Was ich gelernt habe, und was nicht
Entwicklerin bin ich keine geworden. Ich weiß jetzt, wann man rebasen muss, aber nicht, weil ich verstehe, was Git im Hintergrund macht. Ich frage immer noch, wenn ich unsicher bin, und ich gebe immer noch keinen Pull Request weiter, den ich nicht selbst angeschaut habe.
Was ich kann, ist, eine Änderung von der Idee zu einem Pull Request zu bringen, der bereit fürs Review ist, ohne jemanden zu blockieren, in Stunden statt Wochen.
Das funktioniert nur im Team. Die KI allein hätte nie eine PR-Autorin aus mir gemacht, und die Engineers allein hätten nie die Zeit für all diese kleinen Änderungen gehabt, und auch nicht gewusst, was bei SEO oder einer Brand Guideline zu tun ist.
Und wie Valentin am Ende seines Posts schreibt: ehrlich, ich finde das ziemlich cool.
