Wenn du willst, dass etwas richtig gemacht wird, mach es selbst. Mit KI.

Wenn Ihre Unternehmenswebsite langsam ist, sich nur schwer aktualisieren lässt oder Sie für jede kleine Änderung einen Entwickler brauchen, geht das Problem über die Technik hinaus. Es bremst Sie dabei, Ideen zu teilen, Ihre Leistungen zu erklären und auf Kundenanliegen zu reagieren.

Wie viele kleine und mittlere Unternehmen hatten wir die Entwicklung und Wartung unserer Website ausgelagert. Irgendwann brachten mich langsame Seiten und Änderungen, die Wochen oder Monate dauerten, dazu, den Neuaufbau selbst in die Hand zu nehmen.

Am Beispiel unserer eigenen Unternehmenswebsite teilen wir in diesem Artikel unsere Erfahrungen mit einem Website-Relaunch mithilfe von KI: was wir geändert haben, was schneller wurde und wo menschliche Anleitung weiterhin unverzichtbar war. Ich habe ungefähr 60 Stunden in Entwicklung und Prüfung investiert und dabei Codex, Next.js, Payload CMS und die Figma-Entwürfe unseres Designers genutzt.

Das Problem war nicht nur die Website

Etwa ein Jahr lang hatte ich die technischen und organisatorischen Probleme unserer Website hingenommen.

Das größere Problem war aber, wie schwierig es war, unser Wissen und unsere Ideen direkt an potenzielle Kunden weiterzugeben.

Als Unternehmer und Gründer spreche ich regelmäßig mit Kunden, untersuche ihre Bedürfnisse, verfolge Entwicklungen rund um Salesforce und CRM und tausche technische Ideen mit unseren Entwicklern aus.

Zum Beispiel diskutieren wir intern über Salesforce Data 360, die Architektur oder mögliche Anwendungsfälle und gewinnen dabei interessante technische Erkenntnisse.

Etwas, das ein Entwickler direkt hätte teilen können, musste erst durch mehrere Hände gehen, bevor es veröffentlicht werden konnte.

Ein Teil des Problems war, dass wir nicht viel in unsere Website investierten. Für Wartung und Aktualisierungen setzten wir auf einen Freelancer in Teilzeit, aber dieser Ansatz funktionierte nicht.

Da musste ich an einen bekannten Spruch denken:

Wenn du willst, dass etwas richtig gemacht wird, mach es selbst.

Ich finde, dieser Satz passt besonders gut zu einem Ansatz mit direktem Kundenkontakt.

Denn wir übersehen oft, wie viele Schritte, Personen und Prozesse zwischen den Kunden und den Menschen liegen, die die eigentliche Arbeit leisten.

Wie viele Stationen durchläuft das Problem eines Kunden, bis es einen Entwickler erreicht? Und wie viele weitere, bis dessen Wissen oder Lösung beim Kunden ankommt?

Jeder zusätzliche Schritt schafft Abstand zwischen den Menschen, die Probleme haben, und denen, die sie lösen können.

Und ich glaube, KI ist genau die Technologie, die helfen kann, diesen Abstand zu verringern.

Nicht indem sie Entwickler, Kundenbetreuer oder andere Fachleute ersetzt, sondern indem sie unnötige Zwischenschritte und Routinearbeit beseitigt.

So können die Menschen, die die Leistungen tatsächlich erbringen, näher am Kunden arbeiten, seine Bedürfnisse und Schwierigkeiten direkt verstehen und reagieren, ohne mehrere Kommunikationsebenen zu durchlaufen.

KI sollte die Leistungserbringung näher an den Kunden bringen, statt eine weitere Ebene dazwischenzuschalten.

Genau das wollte ich mit unserer Website erreichen.

Die Verantwortung übernehmen – trotz PHP

Ich beschloss, meine bisherigen Bedenken zum Thema Mikromanagement beiseitezuschieben und die Website selbst in die Hand zu nehmen.

Es gab nur ein Problem.

PHP hatte in meiner bisherigen Arbeit als Softwareentwickler praktisch keine Rolle gespielt.

Ich habe immer versucht, es möglichst zu vermeiden. Für mich ist es so etwas wie Ketzerei oder Gotteslästerung. Meiner Meinung nach ist es nicht einmal eine Programmiersprache.

Natürlich übertreibe ich. Viele Menschen mögen PHP und es wird häufig für Websites eingesetzt.

Aber ich bin wohl einfach noch zu jung für PHP-Probleme. Bei der Webentwicklung schlug mein Herz schon immer eher für Node.js oder den .NET-Stack.

Trotzdem beschloss ich, mir unseren Bestand anzusehen.

Erster Versuch: Verbessern wir, was wir schon haben

Am 1. Oktober 2026 begann ich mit dem Umbau der Website.

Meine erste Idee war einfach: die bestehende Website aufräumen, die Codebasis überarbeiten, unnötige Duplikate entfernen und die Performance verbessern.

Da ich aber nicht in kurzer Zeit Unmengen an Code schreiben konnte, entschied ich mich für Codex.

Ich prüfte den PHP-Code und stellte fest, dass fast jede Seitenvorlage erhebliche Code-Duplikate enthielt.

Ähnliche Abschnitte waren von verschiedenen Personen umgesetzt worden, mit unterschiedlichen Ansätzen und Vorstellungen davon, wie sie funktionieren sollten.

Dasselbe Problem zeigte sich im Design. Komponenten mit derselben Aufgabe sahen auf verschiedenen Seiten unterschiedlich aus, mit uneinheitlichen Farben, Rahmen und Abständen.

Gemeinsam mit unserem Designer beschlossen wir, die Stile und Komponenten der Website zu vereinheitlichen. Zuerst wollte ich aber die bestehende Codebasis in einen vernünftigen Zustand bringen.

Mit Codex konnte ich wiederverwendbare Komponenten herauslösen, Duplikate über mehrere Seiten hinweg beseitigen, die Codebasis verkleinern und die Performance verbessern.

Das Interessante daran: Die Prompts waren ziemlich einfach.

Zum Beispiel:

Nimm diesen Abschnitt, [Abschnitts-ID aus der gerenderten HTML-Seite angeben], ersetze ihn und extrahiere ihn als wiederverwendbare Komponente. Prüfe alle anderen Seiten der Website und ersetze die entsprechenden Abschnitte durch die neue Umsetzung. Entferne anschließend sämtlichen alten und ungenutzten Code und überprüfe deine Arbeit.

Im Grunde war das alles.

Dabei fand ich noch etliche weitere Probleme.

Manche Navigationssymbole, die mit 32 Pixeln angezeigt wurden, waren beispielsweise Bilddateien von jeweils etwa einem Megabyte.

Man stelle sich vor: ein Bild mit einem Megabyte laden, nur um ein winziges Navigationssymbol anzuzeigen.

Also bat ich Codex:

Nimm [Bild], analysiere es, skaliere es bei Bedarf hoch und konvertiere es ins WebP-Format. Optimiere es für schnelle Seitenladezeiten, passe es an die tatsächlichen Darstellungsmaße an (zum Beispiel 32 × 32 Pixel) und reduziere die Dateigröße so weit wie möglich, ohne die visuelle Qualität zu beeinträchtigen.

Das wiederholten wir auf der gesamten Website: Wir ersetzten unnötig große Grafiken und räumten die Codebasis auf.

Und es funktionierte.

Das fand ich ziemlich beeindruckend.

An dieser ersten Phase arbeitete ich vom 1. bis zum 10. Oktober ungefähr vier Stunden pro Arbeitstag, Wochenenden ausgenommen.

Das waren insgesamt etwa 28 Stunden, in denen ich die PHP-Codebasis aufräumte und unsere bestehende WordPress-Website optimierte.

Zu diesem Zeitpunkt dachte ich, mit den technischen Änderungen fertig zu sein.

Unser Designer musste nur noch das neue Design abschließen, dann konnten wir weitermachen.

Also legte ich eine Pause von der aktiven Entwicklung ein.

Doch unerwartet wurde alles schlimmer.

14. Oktober: Die Website ging offline

Zwischen dem 10. und dem 14. Oktober arbeitete ich nicht aktiv an der Website, überprüfte aber weiterhin gelegentlich unsere Serverkennzahlen.

Zuerst dachte ich, meine jüngsten Änderungen könnten die Ursache sein.

Also begann ich mit der Untersuchung und nutzte auch ChatGPT, um die bestehende Website und die Serverkonfiguration genauer zu analysieren.

Dabei stellte sich heraus, dass das Problem offenbar nicht durch meine Codeänderungen verursacht wurde.

Wir hosteten die Website auf einem Server mit 2 GB RAM und zwei CPUs, was meiner Einschätzung nach für unsere Website ausreichen sollte.

Damit will ich nicht sagen, dass GTranslate ein schlechtes Produkt ist.

Wahrscheinlich kamen mehrere Faktoren in unserer Infrastruktur zusammen. Das Plugin erforderte laufende Wartung und Anpassungen von unserer Seite, damit alles korrekt funktionierte.

Unser Team hatte IP-Freigabelisten aktualisiert, Netzwerkkonfigurationen angepasst und weitere vorläufige Korrekturen vorgenommen.

Eine langfristige Lösung war das aber nicht.

Und ehrlich gesagt wollte ich nicht weiter Infrastruktur rund um ein Übersetzungsplugin pflegen.

Irgendwann nervte mich das so sehr, dass ich wohl eine Art Psychose entwickelte und beschloss, die gesamte Website von Grund auf neu aufzubauen.

Statt noch ein WordPress-Plugin zu reparieren, beschloss ich, WordPress selbst zu ersetzen.

Und PHP gleich mit.

Neuaufbau mit Node.js, Next.js, React und Payload CMS

Am 14. Oktober begann ich also mit dem Neuaufbau der Website.

Ich wollte unsere Abhängigkeit von Plugins reduzieren und eine einheitliche Plattform mit einem Content-Management-System, integrierten Übersetzungen und einer Struktur aufbauen, die ich selbst steuern konnte.

Mit JavaScript und Node.js bin ich vertraut und hatte damit bereits mehrere Projekte umgesetzt.

Warum Payload CMS?

Weil es auf Next.js aufbaut und Next.js für mich nach einer ziemlich guten Option aussah.

Ich wollte etwas, mit dem ich in einem vertrauten Technologie-Stack arbeiten konnte, statt weitere Werkzeuge und Abhängigkeiten einzuführen.

Payload und Next.js lieferten uns außerdem eine vernünftige architektonische Grundlage, sodass ich nicht alles von Grund auf erfinden musste.

Und ja, ich war versucht, dem Agenten einfach zu sagen:

Schreibe die gesamte WordPress-Website mit meinem gewünschten Stack aus Node.js, Next.js, React und Payload CMS neu. Mach es richtig, setze es sauber um, überprüfe alles, nutze Unteragenten und lass mich in Ruhe.

Aber ich musste anders vorgehen.

Die erste Alpha-Version war im Wesentlichen eine Eins-zu-eins-Migration, mit Ausnahme der Datenbank.

Wir führten mehrere neue Entitäten ein und strukturierten die Inhaltsverwaltung neu. Die Bedienung des CMS sollte sich eher wie Pipedrive oder HubSpot anfühlen: Navigation links, Inhalte rechts.

Migration der bestehenden Website

Ein wichtiger Punkt: Wir haben nicht die gesamte Website von null an entwickelt.

Wir hatten bereits Inhalte, Seitenstrukturen, Designideen und jahrelange Vorarbeit.

Tatsächlich ist dies wahrscheinlich die vierte größere Version unserer Website.

2019 starteten wir mit dem WordPress-Theme Flaton. Damals hatten wir sogar noch ein anderes Logo.

Später entwickelten wir unser eigenes Theme, aktualisierten es und verbesserten die Benutzeroberfläche laufend.

Unser Designer hatte bereits vor Beginn dieser Migration am neuesten Designsystem gearbeitet.

Es ging also um die vollständige technische Migration und Neustrukturierung einer bestehenden Website – nicht darum, ein komplett neues Produkt von Grund auf zu entwickeln.

Für die Inhaltsmigration extrahierten wir alles aus WordPress und ließen einen KI-Agenten die Inhalte dem neuen Datenbankmodell von Payload CMS zuordnen.

Der Agent half dabei, die Inhalte an die neue Struktur anzupassen, statt einfach alles in eine andere Datenbank zu kopieren.

Außerdem nutzten wir Agenten, um die neue Website bereitzustellen, von der PHP-Implementierung umzuschalten und die alten PHP-Dateien und Konfigurationen vom Server zu entfernen.

War das der eleganteste Ansatz?

Wahrscheinlich nicht.

Aber für uns war es der schnellste Weg, alles zu migrieren und zum Laufen zu bringen.

Reparieren, was den Neuaufbau nicht überstanden hatte

Nach dem ersten Neuaufbau sah ich im Wesentlichen dieselbe Website vor mir, nur mit einigen kleinen Unterschieden.

Dann begann ich, Fehler zu beheben.

Hier funktionierte ein Slider nicht mehr, dort war die Darstellung verschoben. Manche Komponenten verhielten sich nicht mehr genau wie zuvor.

Beim Beheben dieser Probleme stellte ich fest, dass nicht alle Komponenten korrekt ersetzt worden waren.

Einige Seitenvorlagen enthielten noch direkt eingebettetes HTML, während andere neu implementierte Komponenten nutzten, die bereits vorhandenen wiederverwendbaren Komponenten nur ähnelten.

Also begann ich, diese Stellen zu erfassen und sie nacheinander zu bearbeiten.

Der Prompt lautete ungefähr so:

Hier ist ein Abschnitt [Abschnittsname oder ID angeben]. Ersetze ihn bitte durch die vorhandene wiederverwendbare Komponente [Komponentenname angeben]. Behalte dieselbe oder eine ähnliche Semantik und dasselbe oder ein ähnliches Verhalten bei, entferne die alte Implementierung und räume ungenutzten Code auf.

Ich ersetzte weitere alte Implementierungen, verbesserte das serverseitige Rendering, führte Caching ein und optimierte Komponenten.

Vom 14. bis zum 23. Oktober arbeitete ich an dieser zweiten Phase ungefähr vier Stunden pro Arbeitstag, insgesamt etwa 32 Stunden.

Ein Agent erstellt, ein anderer prüft und ein Mensch entscheidet

Interessant war auch, wie ich Entwicklung und Bereitstellung organisiert habe.

Ich arbeitete nicht mit einem einzigen Agenten, der alles erledigte.

Ich nutzte mehrere Agenten für verschiedene Aufgaben und erstellte wiederverwendbare Skills für die Bereitstellung der Website.

Diese Skills enthielten Anweisungen dazu, welche Deployment-Skripte zu verwenden waren, welche Tests ausgeführt werden sollten und wie die einzelnen Prozessschritte abzulaufen hatten.

Während der Entwicklung erstellten die Agenten auch Werkzeuge und Skripte zum Testen und Bereitstellen der Website.

Statt jedes Mal den gesamten Ablauf der Bereitstellung zu erklären, konnte ich dieselben Anweisungen und Prozesse wiederverwenden.

Zur Überprüfung setzte ich stark auf Git, um Änderungen nachzuverfolgen und zu prüfen, was in der Codebasis tatsächlich passierte.

Indem ich Git-Diffs ansah und Änderungen Datei für Datei prüfte, konnte ich doppelten Code, wiederkehrende Muster, unnötige Verzweigungen oder komplizierte if-else-Anweisungen erkennen.

Sobald mir so etwas auffiel, bat ich den Agenten, es zu korrigieren.

Die Architektur war weitgehend durch Payload CMS und Next.js vorgegeben. Deshalb sollten die Agenten den bestehenden Konventionen dieser Frameworks folgen, statt eine völlig neue Architektur zu erfinden.

Außerdem beauftragte ich separate Agenten mit der Prüfung der Implementierung.

Der Ablauf war ziemlich einfach:

Ein Agent erstellt, ein anderer prüft und ein Mensch entscheidet, was richtig oder falsch ist.

Und der Mensch achtet auf die tatsächliche Website, nicht nur auf den Code.

Ich prüfte die Benutzeroberfläche manuell, sah mir die Seitendarstellung an, testete Komponenten und suchte nach visuellen Problemen, die bei einer reinen Codeprüfung möglicherweise unentdeckt blieben.

In diesem Fall übernahm ich die Rollen Entwickler, Code-Reviewer, manueller Tester und Qualitätssicherer.

Etwa 30% meiner Zeit entfielen darauf, Code zu prüfen, Implementierungen zu kontrollieren und Ergebnisse zu validieren.

Vor der Bereitstellung führte ich zusätzliche Prüfungen durch Agenten ein, um verbleibende Probleme zu finden und Code aufzuräumen, der nach wiederholten Iterationen übrig geblieben war.

Denn KI erzeugt Unmengen an Code.

Und wenn niemand genau hinschaut, ersetzt man leicht die alten technischen Schulden durch neue.

Die Website mit KI-Agenten übersetzen

Ein weiterer wichtiger Teil der Umsetzung waren die Übersetzungen.

Zuvor hatten wir GTranslate genutzt, um unsere Inhalte in Echtzeit zu übersetzen.

Diesmal sollten die Übersetzungen direkt in unserer Plattform verwaltet werden.

Ein KI-Agent übersetzte unsere englischen Inhalte in alle anderen Sprachversionen der Website.

Der Prompt lautete:

Du übersetzt Inhalte aus dem Englischen in die [Zielsprache].

Analysiere die englische Fassung und identifiziere Markennamen, technologiespezifische Begriffe, Produktnamen und andere Eigennamen.

Stelle vor dem Übersetzen sicher, dass du die ursprüngliche Absicht und die genaue Bedeutung der Inhalte verstehst. Bleibe in der Übersetzung so nah wie möglich an der ursprünglichen Bedeutung und Absicht und beachte dabei die sprachlichen Regeln der [Zielsprache].

Bewahre Markennamen, Produktnamen und technologiespezifische Begriffe, wo dies angemessen ist.

Prüfe nach dem Übersetzen, ob die Bedeutung erhalten geblieben ist, die Sprache natürlich klingt und keine Inhalte ausgelassen wurden.

Übersetze sämtliche Inhalte, einschließlich Artikeltitel, Überschriften, Fließtext und aller zugehörigen Metadaten.

Es ging nicht nur darum, Wörter zu übersetzen. Die Inhalte sollten den Regeln der jeweiligen Sprache folgen und für Menschen vor Ort natürlich klingen.

Außerdem trennten wir markenspezifische Angaben von übersetzbaren Inhalten, damit Firmennamen, Produktnamen und andere wichtige Begriffe nicht falsch übersetzt würden.

Jetzt können wir Übersetzungen direkt in unserem CMS verwalten, ohne von einem Plugin abhängig zu sein, das alles in Echtzeit übersetzt.

Natürlich sind KI-Übersetzungen nicht perfekt, gerade bei technischen Inhalten über Salesforce, CRM und Softwareentwicklung.

Wenn ihr unsere Website in eurer Sprache besucht und etwas unnatürlich klingt, schlecht formuliert ist oder keinen Sinn ergibt, schreibt mir einfach eine Direktnachricht.

Ich kümmere mich darum.

Als Figma, Codex und GPT-6 zusammenkamen

In der Zwischenzeit stellte unser Designer das neue Designsystem in Figma fertig. Ab da wurde es interessant.

Figma unterstützt die MCP-Integration und wir nutzen OpenAI bereits mit Salesforce und anderen Plattformen. Also verband ich Figma mit meinem OpenAI-Konto.

So konnte ich den Link zu einem Figma-Knoten – etwa einem Button, einem Abschnitt oder einer anderen Komponente – an Codex mit GPT-6 weitergeben. Codex übernahm den Entwurf und setzte ihn direkt auf unserer Website um.

Dank der Vorarbeit beim Herauslösen wiederverwendbarer Komponenten konnte es das neue Designsystem seitenübergreifend anwenden, statt dieselben Änderungen überall einzeln umzusetzen. Statt CSS manuell zu schreiben und jeden Innenabstand, Eckenradius oder jedes Komponentenlayout anzupassen, konnte ich die Figma-Entwürfe unseres Designers in der Codebasis umsetzen lassen.

Natürlich lief das nicht vollständig automatisch. Ich musste weiterhin den Code, die HTML-Struktur, das Verhalten der Komponenten und die Stellen prüfen, an denen OpenAI möglicherweise Abkürzungen genommen oder Anforderungen missverstanden hatte.

Im Durchschnitt brauchte jede Komponente ungefähr zwei Iterationen.

Darauf richtete ich den größten Teil meiner Aufmerksamkeit.

Was wir tatsächlich erreicht haben

Mit der neuen Node.js-Implementierung, Caching, serverseitigem Rendering und weiteren Optimierungen laden Seiten jetzt im Durchschnitt in unter einer Sekunde – verglichen mit ungefähr fünf oder sechs Sekunden vor dem Umbau.

Wir betrachteten Performance-Kennzahlen im Browser, darunter das Rendering der Seiten, Largest Contentful Paint und Layout-Verschiebungen. Mit Semrush-Audits bewerteten wir den technischen Zustand der Website, die Crawlbarkeit, die Navigation und weitere technische Aspekte.

Ich beurteilte die Performance aber auch auf viel einfachere Weise.

Bei der alten Website konnte ich die Verzögerungen auf Mobilgeräten wie am Desktop tatsächlich sehen. Die Seiten brauchten Zeit zum Laden und die Nutzung war nicht besonders angenehm.

Bei der neuen Implementierung war der Unterschied sofort spürbar.

Die Website fühlt sich einfach deutlich schneller an.

Natürlich ersetzt der visuelle Eindruck keine technischen Messungen. Für mich war er aber ein wichtiger Indikator, weil genau das die Besucher erleben.

Eine weitere wichtige Verbesserung war die Zahl der technischen Probleme.

Im September und Oktober meldete Semrush ungefähr 2.000 Probleme, mit Spitzenwerten von fast 3.000.

Jetzt liegen wir bei ungefähr 400 Problemen. Etwa 200 davon hängen mit dem E-Mail-Schutz von Cloudflare zusammen, den Semrush als defekte interne Links meldet.

Es gibt noch einiges zu verbessern, aber im Vergleich zum Ausgangspunkt ist die Situation eine völlig andere.

Von der Website-Wartung zu Inhalten direkt für Kunden

Die Performance war nicht die einzige Verbesserung.

Wir erreichten auch etwas, das wahrscheinlich noch wichtiger ist: eine wesentlich angenehmere Möglichkeit, Inhalte zu erstellen und zu verwalten.

Früher musste für eine Seitenänderung jemand manuell Vorlagen aktualisieren, Inhalte anpassen und die technischen Arbeiten erledigen.

Statt mehrere Personen einzubeziehen, um unsere Erfahrungen in Website-Inhalte zu verwandeln, können wir den Großteil der Routinearbeit über die Plattform abwickeln.

Der Entwickler muss kein Texter werden. Der Kundenbetreuer muss kein Entwickler werden. Und wer eine Idee hat, sollte nicht monatelang darauf warten müssen, dass sie jemand auf der Website umsetzt.

Das heißt auch nicht, belanglose KI-Massenware zu erzeugen.

Nehmen wir diesen Artikel als Beispiel.

Er wird nicht von Hand geschrieben. Die Ideen und Gedanken werden diktiert, in Text transkribiert und anschließend überarbeitet.

Wir können zum Beispiel sagen: „Formuliere das um, lass diesen Teil besser klingen, entferne unnötige Wörter, drücke dich höflicher aus.“

Aber die Ideen, Erfahrungen und die Geschichte stammen weiterhin von uns.

KI hilft uns, unsere Gedanken in lesbaren Text zu verwandeln – so wie sie dabei geholfen hat, unsere Designvorgaben und technischen Anforderungen in funktionierenden Code umzusetzen.

Genau diesen Arbeitsablauf wollten wir.

Derselbe Ansatz eignet sich für technische Artikel, Kundenerfolgsgeschichten, Leistungsbeschreibungen und andere Inhalte, die wir teilen möchten.

Früher verließen wir uns stark auf Texter und Website-Administratoren, um aus wenigen Worten technischer Experten vollständige Artikel zu machen.

Ein technischer Experte erklärt in wenigen Minuten, was er gemacht hat, und ein Texter macht daraus Tausende Wörter.

Große, selbstbewusste Artikel mit viel Text, Erklärungen und häufig auch viel heißer Luft.

Der Entwickler selbst würde dasselbe Projekt wahrscheinlich in wenigen Sätzen beschreiben:

„Ja, wir haben das gemacht. Es war einfach. Es war interessant. Es hat Spaß gemacht.“

Vielleicht erwähnt er nebenbei noch einige geschäftliche Vorteile. Obwohl ein Kundenbetreuer diese wahrscheinlich viel besser erklären können sollte.

Wir möchten, dass unsere Entwickler kurz erklären, was an der Umsetzung interessant war, was technisch anspruchsvoll war und was nützlich war – und sich dann wieder anderen interessanten Aufgaben widmen.

Statt jemandem stundenlang alles zu beschreiben, der daraus irgendwann einen Artikel macht.

Genau diese Routine wollten wir abschaffen.

Und genau das meine ich damit, die Leistungserbringung näher an den Kunden zu bringen.

KI kann helfen, die Routinearbeit zwischen diesen Menschen zu reduzieren, damit Wissen viel direkter von denen, die es besitzen, zu denen gelangt, die es brauchen.

Entwicklungsaufwand und Kosten

Das bedeutet natürlich nicht, dass die Website für insgesamt €245 neu aufgebaut wurde.

Darin sind weder meine Zeit noch die Arbeit unseres Designers, die Infrastruktur oder die Investitionen der vergangenen Jahre enthalten.

Seit 2019 entwickeln und verbessern wir unsere Website: Wir wechseln Themes, aktualisieren Designs, erstellen Inhalte und passen die Struktur an.

Bei der jüngsten Migration konnten wir einen großen Teil dieser Arbeit wiederverwenden.

Interessant ist aber, wie viel ich in ungefähr 60 Stunden eigener Mitarbeit erreichen konnte – mit KI für Entwicklung, Refactoring, Tests, Bereitstellung und Code-Reviews.

Was sich in der Praxis verändert hat

Der folgende Vergleich bezieht sich auf die verstrichene Umsetzungszeit bei der Zusammenarbeit mit einem freiberuflichen Entwickler. Er ist weder ein Budgetvergleich noch ein direkter Vergleich der geleisteten Arbeitsstunden.

Beispielsweise kann eine Seite ungefähr 40 Stunden Entwicklungsarbeit erfordern, die sich über mehrere Wochen und laufende Verbesserungen verteilen.

Diese Schätzungen beginnen, nachdem Idee und Anforderungen feststehen. Ideenentwicklung und Anforderungsdefinition sind eigenständige, wichtige Phasen und hier nicht enthalten.

Wie geht es weiter?

Die technische Grundlage steht jetzt.

Wir haben eine Plattform, die wir pflegen können, ohne jede einzelne Änderung auf der Website manuell vornehmen zu müssen.

Natürlich können wir weiterhin alles direkt bearbeiten, wenn wir möchten. Jetzt können wir aber auch einfach dem Agenten, der unsere Website betreut, sagen:

Ergänze [Artikel], verwende [Bilder], erstelle aus diesen Inhalten einige Infografiken oder Tabellen und veröffentliche sie als [Fallstudie oder Blogartikel].

Dasselbe gilt für die Aktualisierung bestehender Seiten.

Zum Beispiel:

Nimm diese Seite [URL oder Seitentitel angeben], finde diesen Abschnitt [Abschnittsname, Überschrift oder ID angeben], aktualisiere ihn. Ersetze das Bild, aktualisiere oder ergänze den Text gemäß meinen Anweisungen und stelle sicher, dass alles unserem bestehenden Designsystem folgt. Bewahre die Funktionalität der Komponente und überprüfe die Änderungen.

Ob wir ein Bild ersetzen, eine Leistungsbeschreibung ergänzen, einen Artikel veröffentlichen oder einen ganzen Abschnitt aktualisieren möchten: Wir können erklären, was wir erreichen wollen, das Ergebnis prüfen und es bei Bedarf anpassen.

Das spart Stunden an Routinearbeit, die wir in neue Ideen, die Erforschung von Kundenbedürfnissen und nützliche Inhalte investieren können.

Und ja, die Situation ist jetzt aus so ziemlich jeder Perspektive deutlich besser.

Die Infrastruktur steht. Die Plattform lässt sich einfach warten. Man muss nur formulieren, was man braucht, und der Agent kann es in wenigen Minuten ergänzen. Inhalte lassen sich leichter veröffentlichen und wir haben viel mehr Kontrolle darüber, wie die Website funktioniert.

Jetzt können wir uns auf Ideen statt auf technische Einzelheiten konzentrieren.

Die wichtigere Veränderung betrifft aber die Zusammenarbeit mit unseren Kunden.

Statt Entwickler, Kundenbetreuer, Marketing und Website-Administratoren durch zahlreiche Schritte und Prozesse voneinander zu trennen, können wir den Wissensaustausch viel direkter gestalten.

Die Menschen, die die Probleme der Kunden verstehen, können ihr Wissen weitergeben. Und diejenigen, die Lösungen entwickeln, erfahren direkt, was Kunden tatsächlich brauchen.

Technologie sollte nie das Problem sein, mit dessen Lösung wir die meiste Zeit verbringen.

Sie sollte uns helfen, unsere Ideen zu den Kunden zu bringen.

Und jetzt ist die Technik endlich kein Ärgernis mehr.