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 von uns aus Marketing und HR kommen, 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 habe ich dutzende Pull Requests für unsere neue Website geöffnet: das Design über die ganze Seite hinweg vereinheitlicht, die Hero-Bilder fürs Mobile optimiert, unsere Seite Design Document as a Service, eine Newsletter-Landingpage, ein SEO Audit über die Hauptseiten.
Fast nichts davon kam daher, dass ich programmieren gelernt hätte. Was sich geändert hat, ist, wie ich um Dinge bitte, wie ich sie 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 das Fundament gebaut hatte, bevor ich anfing. Sie haben den Tech Stack gewä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 dessen zu arbeiten, was sie gebaut hatten. Bauen hätte sie es für mich nie können. Alles Weitere ergibt nur Sinn, wenn das schon steht.
Wie ich frage: von Einzeilern zu Anweisungen, die funktionieren
Meine frühen Anweisungen waren Einzeiler. "Setz die h1 auf 36 px." "Weg mit dem weißen Balken." Sie funktionierten immer dann, wenn die KI richtig erriet, was ich meinte, und oft erriet sie falsch: die falsche Datei, die falsche Sprachversion, das Element neben dem, das ich meinte. Ich wusste damals auch noch nicht, dass "ich hab's 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 überhaupt nichts geändert.
Die eine, an die 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, ganz ohne Wirkung, weil der Blog seinen Body über die Hauptseiten-Komponente zieht, die Datei, die ich ausgewählt hatte, galt also für gar nichts. Ein Engineer hätte das in Sekunden gesehen. Die KI editierte munter genau das weiter, worauf ich gezeigt hatte.
Zwei Dinge kamen aus dieser Phase heraus. Meine Anweisungen wurden länger und trockener, weil das, was zurückkommt, davon abhängt, wie präzise man die Frage stellt. Und ich lernte, Widerspruch zu geben: "Ich glaube, wir reden aneinander vorbei." "Was hast du gerade geändert?" Das klingt zu offensichtlich, um es zu erwähnen, und ohne das landet man bei einem Ergebnis, das plausibel aussieht und leise falsch ist.
Später fing ich an, den Rahmen vor der Arbeit 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.
Dieselbe Kurve zeigt sich in meinen Commits. Meine ersten gingen im März ins Repository, und sie mir heute anzusehen, tut ein bisschen weh. Einer heißt "Mobile & design refinements: text clipping, colors, logos, button styles", vier zusammenhanglose Änderungen, zu einem einzigen Klumpen gebündelt, den Valentin reviewen sollte. Damals tippte ich auch einfach "create a PR", ohne wirklich zu wissen, was ein Pull Request ist. Ich tippte die Wörter, weil man es mir am Anfang so gesagt hatte, nicht weil ich verstand, was zwischen ihnen und meiner Änderung auf der Seite passierte. Fast achtzig Commits später sehen 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 tat, eine Reaktion auf etwas Sichtbares. Lighthouse markiert ein Bild, jemand entdeckt einen falsch geschriebenen Namen, eine Überschrift wirkt zu klein. Das Hero-Bild war so ein Fall: Die KI zeigte mir, wie man das Cloud-Bild auf 1600 px runterbringt, eine 800-px-Variante fürs Mobile generiert, ein <picture> Element mit srcset aufsetzt und imagesrcset zum <link rel="preload"> hinzufügt. 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 in die Länge gezogen, Seite für Seite, bis sich die ganze Website wieder wie ein Stück anfühlte.
Dann kippte es. Für die SEO-Arbeit hörte ich auf, einzelne Seiten zu fixen, sobald sie mir auffielen: erst ein Audit der Hauptseiten, dann Prioritäten, dann ein Pull Request. Ich fing auch an, nach Meinungen zu fragen statt Details zu diktieren. Welche Keywords sich lohnen, 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 dann habe ich fünf, sechs Mal an den Details iteriert.
Die Seite, an der sich diese Arbeitsweise wirklich bewähren musste, war eine größere.
Die Seite, an der ich am längsten saß
Das Design Document ist das, was ein Kunde oder potenzieller 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, wurde ihm nie gerecht, also haben wir eine Seite gebaut, die eines zeigt. Sie ist hier 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 komplettes durchgerechnetes Beispiel durch: die Architektur, die Phasen auf einer Timeline, non-functional requirements, bewertet über Kategorien wie Reliability und Maintainability, die Maturity Levels von internem Tooling bis hin zu etwas Öffentlichem, Kundenseitigem, die Kostenfolgen mit einer Amortisationsdauer, die Risikotabelle, ein Glossar. Am Ende waren es rund 2.000 Zeilen über sieben Dateien.
Was gut funktioniert hat, war 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 fing danach an: daraus eine Seite zu machen, die sich gut liest. Ich hatte keine Ahnung, wie man ein sticky Inhaltsverzeichnis, eine Phasen-Timeline oder Bewertungen mit Tooltips baut, und ich musste es auch nicht. Ich beschrieb, was ein Abschnitt tun soll, und die erste Version kam meistens nah genug zurück, um darauf zu reagieren.
Was nicht gut funktioniert hat, waren Handys. Die Desktop-Version stand in zwei Tagen. Am Handy rutschte das sticky Inhaltsverzeichnis unter den Site-Header und das Hero-Icon entkam auf kurzen Screens dem Viewport, und nichts davon war aufgetaucht, während wir es bauten. 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.
Die erste Version war auch nicht die letzte. In einem Review mit Sales und Technology gingen wir das Beispieldokument noch einmal durch, und die Notes und der Architektur-Abschnitt kamen umgeschrieben zurück. Mein Job war, den neuen Inhalt in die Seite zu bringen. Um jede Runde herum generierten Valentin und die Pipeline die Visual-Regression-Baselines neu, 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 existiert in 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. Es passiert auch andersherum: Ich bearbeite eine gemeinsame .astro Datei, ohne zu merken, dass die englische Seite sie ebenfalls importiert, und dann bricht das Fixen der einen Sprache die andere. Auf der Design-Document-Seite habe ich die deutsche Version mit den Kapiteltiteln, der Navigation und den Section-Chips noch auf Englisch ausgeliefert und es erst danach bemerkt. Die KI kriegt das zuverlässig hin, sobald man sie darauf hinweist, aber von allein denkt sie selten daran.
Dann gibt es die Kategorie, die ich bewusst nicht allein anfasse. DSGVO-Fragen, das Kontaktformular ans API-Backend anbinden, die Turnstile-Integration. Die KI gibt mir für all das eine Antwort, und ich will nicht die Einzige sein, die draufgeschaut hat. Das ist dasselbe Argument, das Valentin über menschliche Aufsicht macht, 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 durch. Wenn etwas nicht passt, weist er darauf hin, ich fixe es und aktualisiere den PR, und wenn es stimmt, merged er. Lint, der Build und unsere Visual-Regression-Tests fangen einen Teil ab, bevor er überhaupt draufschaut, und nichts davon ersetzt diesen Schritt. 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ürs interne IT. Eine Zeile Text fixen, ein Tag hinzufügen, einen Button anpassen, und jedes davon ging in die Queue von jemand anderem. Diese Tickets werden nicht mehr eingereicht. Die, die wirklich einen Engineer brauchen, schon, und es ist mehr Zeit da, sie ordentlich zu machen.
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 anfragte und auf das ich dann wartete. Jetzt sind sie etwas, das ich mache, und sie stehen auf meiner To-do-Liste.
Was ich gelernt habe, und was nicht
Ich bin keine Entwicklerin geworden. Ich weiß jetzt, wann man rebasen muss, aber nicht, weil ich verstehe, was Git unter der Haube tut. Ich frage immer noch, wenn ich unsicher bin, und ich weigere mich immer noch, einen Pull Request zu übergeben, den ich nicht selbst angesehen habe.
Was ich kann, ist, eine Änderung von einer Idee zu einem Pull Request zu bringen, der bereit fürs Review ist, ohne jemanden zu blockieren, in Stunden statt Wochen.
Das funktioniert nur als Teamsache. 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, oder 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.
