Ich habe dieses Jahr bereits zahlreiche Pull Requests reviewed. Bisher kamen alle davon von Softwareentwickler:innen - was sich zuletzt aber geändert hat. Zuletzt landen vermehrt PRs aus unserer Marketing-Abteilung bei mir im Review. Damit hätte ich zuvor nicht gerechnet.

Wir haben kürzlich unsere Website posedio.com neu gelauncht und gleichzeitig auch unseren neuen Blog gestartet (du liest ihn gerade!). Und wir haben das Projekt genutzt, um ein Experiment zu fahren, von dem ich ehrlich gesagt nicht wusste, ob's funktionieren würde. Können unsere Marketing und HR-Abteilung (also keine Softwareentwickler:innen) den Großteil der neuen Seite und des Blogs mit no-code AI bauen, und zeitgleich unseren Qualitätsanspruch erfüllen?

Spoiler: Es hat geklappt 🎉 - aber der spannende Teil ist das Warum - lies weiter für mehr Details.

Wie es bis vor Kurzem war

Jedes Web-Projekt, das ich davor geleitet hab, lief eigentlich nach demselben Schema ab. Die Marketing-Abteilung liefert den Content und das Design, zum Beispiel als Figma-Prototyp. Das Dev-Team macht dann eine fertige Website draus - natürlich iterativ.

In der Praxis hieß das dann: viel Hin und Her. Ich hab oft an kleinen Sachen geschraubt, die noch nicht ganz gepasst haben, oder die Anforderungen haben sich während des Projekts geändert. Die Änderungen an sich waren meistens überschaubar (gute Akzeptanzkriterien helfen da extrem!). Aber einen Screenshot ins Ticket kopieren, das Problem analysieren, dann den Fix ausrollen - das braucht am Ende halt einfach ein wenig Zeit. Und hier und da ein paar Minuten läppern sich über ein ganzes Projekt dann schon zusammen.

Diesmal haben wir das ganze einmal komplett umgedreht.

Was wir diesmal anders gemacht haben

Unser Marketing- und HR-Team hat den Großteil der neuen Seite selbst gebaut, direkt auf ihren eigenen Notebooks, in Claude Code (inklusive Live-Preview der Entwicklungsumgebung). Wenn die Änderungen lokal gepasst haben, haben sie über Claude Code einen Pull Request aufgemacht. Ich habe diesen dann reviewed, manchmal noch einen Cleanup-Commit oben draufgepackt und dann gemergt. Die GCP-Infrastruktur, die Architektur und das Review-Gate sind bei mir geblieben.

Was mich fast genauso überrascht hat wie der Code: Wie schnell unsere Nicht-Entwickler:innen mit dem ganzen Drumherum klargekommen sind. Innerhalb von zwei Wochen waren Wörter wie git, Branches, Pipelines, Merge Conflicts und Pull Requests ein Teil ihres normalen Arbeitsalltags. Sie haben zum Beispiel erwähnt, dass sie den main Branch gepullt haben, bevor sie gepusht haben, und mich gefragt, wann ich denn jetzt endlich ihren PR reviewen würde 😉. Die technische Hürde, von der ich angenommen hatte, sie wäre die größte, war am Ende gar keine.

Ich hätte nicht gedacht, dass das so gut funktioniert.

Die PRs waren gut. Also wirklich solide.

Jeder PR kam mit einem ordentlichen Titel, einem ausformulierten Changelog und einem Test Plan rein. Die Diffs waren sauber abgegrenzt. Wenn man den Namen der Author:in wegnehmen würde und mir den PR kalt zeigen würde, hätt' ich fast geglaubt, der kommt von einem Senior Frontend Engineer. Aber auch nur fast - denn ehrlich gesagt, waren die PR's ein wenig zu detailliert. Keine:r der Entwickler:innen, die ich kenne, schreibt Test Plans in der Detailtiefe, außer es zwingt sie wer dazu. Aber ich muss schon sagen: Die PRs waren so übersichtlich aufbereitet, dass sie sich deutlich besser lesen ließen als ein Großteil der PRs, die ich über die Jahre reviewed habe.

Ich hab trotzdem jedes Diff selber durchgelesen. Wir haben letztens schon einmal darüber geschrieben, warum menschliche Aufsicht bei jedem Projekt wichtig ist (lest euch den Post auch unbedingt durch!) - und das gilt nicht weniger, nur weil der Code größtenteils generiert ist. Im Gegenteil, hier muss umso mehr reviewed werden. Aber das Reviewen an sich war so entspannt wie schon lange nicht mehr, weil mir die Beschreibungen genau gesagt haben, wo ich hinschauen muss. Ich hab jede Änderung trotzdem gegen den Test Plan und das tatsächliche Diff geprüft, aber die Beschreibungen waren sehr akkurat. Der einzige Fall, wo's nicht so gut funktioniert hat: wenn nach dem Öffnen des PRs noch weitere Änderungen reingepusht wurden. Da hat Claude die Beschreibung dann nicht mehr aktualisiert.

Wo ich trotzdem noch echt entwickeln musste

Nicht alles war sauber. Der häufigste Fehler war Code-Duplikation über die Sprachen hinweg. Die Seite ist mehrsprachig, und wenn Claude eine neue Komponente oder einen neuen Content-Block gebaut hat, hat es das gleiche Markup manchmal einfach in jede Sprachversion reinkopiert, statt das in eine gemeinsame Komponente auszulagern. Oder als der Prompt war, dass die Silbentrennung am Handy nicht richtig funktioniert, hat Claude zwar die Mobile-Version gefixt - aber dabei die Desktop-Version kaputt gemacht. Nur, um zwei Beispiele zu nennen.

Wenn sowas passiert ist, hab ich den Branch lokal ausgecheckt, die Duplikate oder die kaputten Stellen sauber refactored, und meine Änderungen dann committed und gepusht. Das mich jedes Mal höchstens fünf bis zehn Minuten gekostet - und es hat dadurch verhindert, dass die Qualität der Codebase langsam und stetig sinkt.

Das war dann schlussendlich unser gemeinsamer Rhythmus. Unser Marketing oder HR machen den PR auf. Claude macht das Meiste richtig, und ich muss manchmal noch ein wenig aufräumen. Der Workflow hat gut funktioniert - aber das menschliche Review nach jeder Änderung ist nicht optional. Genau dieses hält die Codebase nämlich davon ab, in sechs Monaten zu einem Tech-Debt-Albtraum zu werden.

Was das Ganze wirklich möglich gemacht hat

Vieles, was diesen Workflow überhaupt möglich gemacht hat, wurde bereits entschieden, bevor unser Marketing-Team das erste Mal Claude Code aufgemacht hat. Das Dev-Team hat den Stack ausgewählt - Frontend-Framework, CMS, Styling Library, das ganze Infrastruktur-Fundament mit Terraform - und sich dabei an unseren Standards orientiert und an dem, was wir auch in anderen Projekten verwenden. Das heißt: Jeder AI-erstellte Pull Request landet in Code, den der Rest vom Team vom ersten Tag an lesen und weiterentwickeln kann. Und die AI bewegt sich in einem Stack, den wir kennen und debuggen können - nicht in irgendwas, was sie sich selbst zusammengesucht hätte.

Dasselbe gilt für die "langweilige" Infrastruktur drunter. Das Repo wurde zu Beginn sauber aufgesetzt. CI ist bei jedem PR mit den richtigen Checks durchgelaufen. Preview Environments haben funktioniert. GCP war so eingestellt, dass jeder Deploy sofort im Browser auf der Test-Stage anschaubar war. Die Nicht-Dev-Seite dieses Projekts wirkt nur dann magisch, wenn die Dev-Seite drunter halbwegs sauber ist - vorher nicht.

Auch wichtig: Die PRs waren teilweise deswegen so gut, weil ein Mensch sie lesen würde. Die Cleanups sind passiert, weil jemand auf die langfristige Form der Codebase geschaut hat. Wenn man eine dieser Karten aus dem Kartenhaus hinauszieht, fällt es in sich zusammen.

Also - hat es geklappt?

Ja - aber ich will da dennoch vorsichtig sein, wie ich das formuliere, weil sich meine Erfahrungen gezielt auf dieses eine Projekt stützen.

Dieses Projekt ist ein klar abgegrenztes Beispiel: eine öffentliche Marketing-Seite und ein Blog, gebaut von einem Nicht-Entwickler:innen-Team, in einem Stack und auf einer Infrastruktur, die unsere Engineers schon vorher aufgesetzt hatten, mit einem Entwickler, der jede Änderung reviewed hat. Unter diesen Bedingungen war Entwickeln mit AI für uns ein echter Gewinn. Wir haben eine schnellere, schönere Seite gelauncht und einen Blog, auf den wir stolz sind - mit Marketing- und HR-Kolleg:innen, die echten Code ins Repo beitragen. Das wäre vor einem Jahr noch undenkbar gewesen.

Aber genauso klar ist: Ohne Entwickler:in im Prozess wäre da am Ende kein Ergebnis rausgekommen, auf das wir stolz sein könnten. Der Stack muss von Leuten gewählt werden, die unsere Standards kennen. Die Infrastruktur muss gebaut werden. Die PRs müssen von wem reviewed werden, der das Diff auch lesen kann. Die Merge Conflicts müssen per Hand aufgelöst werden. Die architektonischen Cleanups müssen von wem kommen, der weiß, wie es nach unseren Standards aussehen soll. Wenn man die menschliche Komponente aus dieser Geschichte heraus nimmt, kriegst man kein schnelleres Projekt, sondern etwas, was zwar oberflächlich richtig aussehen mag, unseren Engineering-Standards aber in keinster Weise entspricht.

Dennoch denke ich, man muss fair bleiben. Für einen MVP oder einen schnellen Prototyp ist der Code aus diesen PRs auch alleinstehend wirklich erstaunlich solide. Für unseren Anspruch - eine öffentliche, mehrsprachige Seite, die wir über Jahre hinweg pflegen und weiterentwickeln wollen - braucht's aber weiterhin die Kompetenz unserer Engineers.

Ich bin skeptisch in das Projekt herein gegangen. Jetzt am Ende vom Projekt freue ich mich wirklich, wenn ich sehe, wie unser Marketing-Team PRs aufmacht, als wär's das normalse der Welt - und ehrlich gesagt, find ich das ziemlich cool.