Der wahre Wert professioneller Softwareentwicklung

01Warum für Code bezahlen, wenn ihn auch eine Maschine schreibt?

Diese Frage stellt sich heute jeder, der eine Website, ein Portal oder eine Unternehmenssoftware in Auftrag geben muss, und sie ist berechtigt. Werkzeuge mit künstlicher Intelligenz schreiben in wenigen Sekunden seitenweise ordentlichen, kommentierten Code. Baukästen versprechen eine professionelle Website, indem man Blöcke mit der Maus zieht. Marktplätze bieten fertige Themes für ein paar Dutzend Euro. Alles wahr.

Und doch sind langsame Websites, gehackte Portale und Unternehmenssoftware, die niemand mehr ändern kann, nicht weniger geworden: Es sind mehr geworden. Der Grund ist einfach auszusprechen und weniger einfach zu akzeptieren. Code zu schreiben war nie der schwierige Teil des Handwerks. Schwierig ist es, zu entscheiden, welcher Code gebraucht wird, den vorhandenen zu verstehen, vorherzusehen, was passiert, wenn es tausend Nutzer statt zehn sind, und für das einzustehen, was online geht.

In diesem Kapitel nehme ich den Vergleich Stück für Stück auseinander: was künstliche Intelligenz wirklich gut kann, wo sie sich irrt, ohne es zu melden, warum eine mit Baukasten und Plugins zusammengesetzte Website mehr kostet, als es scheint, und woran man fachgerechte Arbeit erkennt. Nicht, um einen Berufsstand zu verteidigen, sondern um Ihnen die Werkzeuge für die Wahl zu geben.

02Künstliche Intelligenz: ein großartiger Assistent

Zuerst das, was ehrlich gesagt werden muss: Programmierassistenten auf Basis künstlicher Intelligenz sind außergewöhnliche Werkzeuge, und wer beruflich Software schreibt, nutzt sie heute. Sie sparen Stunden bei wiederkehrenden Arbeiten, schlagen Lösungen vor, an die Sie nicht gedacht hätten, und erklären in einfachen Worten ein Stück Code, das jemand anderes vor zehn Jahren geschrieben hat.

Hier bringen sie am meisten:

• die Fleißarbeit: wiederkehrende Strukturen, Formatumwandlungen, Feldlisten, einfache Tests;
• der erste Entwurf: ein Ausgangspunkt, von dem jemand, der programmieren kann, wegnimmt, korrigiert und ergänzt;
• die Erklärung: „Was macht diese Funktion?“, „Warum dieser Fehler?“, Fragen, die sie oft gut beantworten;
• die Recherche: den Namen eines Konzepts finden, eine Bibliotheksfunktion, eine Alternative;
• die Durchsicht: ein zweites Paar Augen, das auf etwas hinweist, das noch einmal geprüft werden sollte.

In all diesen Fällen gibt es ein gemeinsames Element: jemanden, der das Ergebnis beurteilen kann. Der Assistent schlägt vor; wer das Handwerk beherrscht, wählt aus, verwirft, prüft. Nimmt man diese Person weg, bleibt das Werkzeug dasselbe, aber das Ergebnis ändert seine Natur.

03Wo die KI sich irrt, ohne es zu sagen

Ein Sprachmodell erzeugt den wahrscheinlichsten Text zu dem, was Sie gefragt haben. Es weiß nicht, ob der Code, den es schreibt, sicher ist: Es weiß, dass er Code ähnelt, den es gesehen hat. Deshalb ist sein gefährlichster Fehler nicht der Code, der nicht funktioniert, denn das bemerkt man sofort, sondern der Code, der funktioniert und dabei noch etwas anderes tut.

Die OWASP, die internationale Stiftung, die seit zwanzig Jahren die maßgeblichen Standards zur Sicherheit von Webanwendungen veröffentlicht, nennt unter den Risiken von Sprachmodellen ausdrücklich die Erzeugung unsicheren Codes und das übermäßige Vertrauen: wenn man sich auf generierte Inhalte verlässt, ohne sie zu prüfen. So sieht das konkret aus.

Stellen Sie es sich so vor: Ein hilfsbereiter Neffe baut Ihnen an einem Nachmittag mit Hilfe künstlicher Intelligenz das Buchungsformular. Es öffnet sich, sendet, die E-Mails kommen an. Alles perfekt, monatelang. Dann schreibt eines Tages jemand in das Feld „Nachname“ etwas, das kein Nachname ist, und die Liste Ihrer Kunden landet dort, wo sie nicht hingehört. Das Formular funktionierte: Es tat nur noch etwas anderes.

1. Die Query, die die Datenbank für jeden öffnet

Sie fragen nach „einer Seite, die Kunden nach Nachnamen sucht“, und bekommen etwas, das funktioniert. Wird der vom Nutzer eingegebene Nachname aber direkt in die Frage an die Datenbank eingefügt, kann jeder anstelle des Nachnamens ein Stück Befehl schreiben und sich die ganze Tabelle ausgeben lassen oder sie löschen. Das ist die SQL-Injection, einer der ältesten Angriffe und noch immer einer der verbreitetsten.

Die erste von der OWASP empfohlene Abwehr sind genau die parametrisierten Queries (Prepared Statements). Ein Assistent verwendet sie oft, aber nicht immer; und wer den Unterschied nicht erkennt, bemerkt es nicht, bis jemand es ausnutzt.

2. Geheime Schlüssel im Code

Um sich mit einem Zahlungsdienst, dem E-Mail-Server oder der Datenbank zu verbinden, braucht man Passwörter und Schlüssel. Generierter Code neigt dazu, sie direkt in die Datei zu schreiben, weil das Beispiel so sofort funktioniert. Aber eine Datei landet in einem Archiv, in einer Sicherungskopie, in einem gemeinsamen Repository: und der Schlüssel mit ihr. Die Leitlinien der OWASP zur Verwaltung von Geheimnissen sagen das Gegenteil: Schlüssel gehören außerhalb des Codes, in geschützte Konfigurationsdateien oder spezielle Dienste, und lassen sich ändern, ohne das Programm anzufassen.

3. Bibliotheken, die es nicht gibt

Auch das kommt vor: Der Assistent schlägt vor, ein Paket mit einem plausiblen Namen zu installieren, das nie existiert hat. Die OWASP beschreibt das Szenario, in dem jemand beobachtet, welche erfundenen Namen am häufigsten vorgeschlagen werden, Schadpakete mit diesen Namen veröffentlicht und wartet, bis sie installiert werden. Wer nicht prüft, woher jede Bibliothek stammt, holt sich mit einem Befehl von Unbekannten geschriebenen Code ins Haus.

4. Der Idealfall und alle anderen

Generierter Code deckt den vorgesehenen Weg gut ab: Der Nutzer füllt alles aus, das Netz funktioniert, die Zahlung geht durch. Echte Software lebt in den anderen Fällen: der Doppelklick auf die Schaltfläche „Bezahlen“, die Verbindung, die mittendrin abbricht, zwei Personen, die in derselben Sekunde denselben Tisch buchen, das leer gelassene Feld, der Name mit Apostroph. Ausnahmen zu behandeln ist die halbe Arbeit, und der Assistent tut es nicht, wenn Sie ihn nicht darum bitten, und Sie wissen nicht, worum Sie bitten sollen, wenn Sie es nicht wissen.

5. Der Kontext, den ihm niemand gegeben hat

Der Assistent kennt Ihre Datenbank nicht, den Verkehr, den Sie haben werden, die Regeln Ihrer Branche, die Datenschutzvorschriften, die Unternehmenssoftware, mit der die Website sprechen muss. Er liefert eine allgemeine Lösung für ein Problem, das nicht allgemein ist. Wer das Projekt kennt, weiß, was zu fragen ist, was zu verwerfen ist und was fehlt.

04Baukästen und Plugins: die Website, die mehr wiegt, als sie zeigt

Ein Page Builder (Baukasten) ist ein Programm, mit dem man Seiten baut, indem man Blöcke zieht: Überschriften, Spalten, Galerien, Schaltflächen. Er ist bequem und liefert sofort Ergebnisse. Der Preis wird später bezahlt, und zwar von den Besuchern der Website.

Das versteckte Gewicht jedes Blocks

Damit Sie alles überallhin ziehen können, muss der Baukasten alles vorsehen. Jedes Element wird in mehrere Container gehüllt, jeder mit eigenen Klassen und Stilen. Das Ergebnis ist eine Seite mit einer riesigen Zahl von HTML-Elementen (dem sogenannten DOM) und großen Stylesheets und Skripten, die vollständig geladen werden, auch wenn die Seite nur einen kleinen Teil davon nutzt.

Lighthouse, das in Chrome integrierte Analysewerkzeug von Google, gibt eine Warnung aus, wenn der Seitenkörper etwa 800 Elemente überschreitet, und einen Fehler ab etwa 1.400. Mehr Elemente bedeuten mehr Speicher, mehr Stil- und Layoutberechnungen, langsamere Reaktionen auf Berührungen: alles, was der Browser tun muss, bevor er Ihnen die Seite zeigt und während Sie sie nutzen.

Code, der geladen und nicht genutzt wird

Neben den Elementen gibt es das Gewicht der Dateien. Ein Baukasten lädt seine Stylesheets und Skripte für alle Blöcke, die er anbietet, auch für die, die die Seite nicht nutzt: den Slider, den es nicht gibt, das Karussell, die Animation. Chrome selbst nennt in seinen Analysen ungenutztes CSS und JavaScript als eines der ersten Dinge, die man entfernen sollte, um eine Seite zu beschleunigen. Mehr und größere Dateien bedeuten längeres Warten, bis die Seite lesbar ist, besonders auf einem Smartphone mit normaler Verbindung. Wie man diese Wartezeiten misst, erkläre ich im Kapitel über die Core Web Vitals.

Für alles ein Plugin

Das zweite Problem kommt mit den Plugins: eines für das Kontaktformular, eines für den Cache, eines für die Sicherheit, eines für SEO, eines für die Cookies, eines für die Galerie, eines für die Übersetzungen. Zwanzig, dreißig, manchmal mehr. Jedes ist:

• von anderen geschriebener Code, der auf Ihrem Server mit denselben Rechten wie die Website läuft;
• etwas, das aktualisiert werden muss, bei kommerziellen Versionen oft mit einem Jahresabo;
• eine mögliche Unverträglichkeit mit den anderen, die sich an dem Tag zeigt, an dem eines aktualisiert wird und das andere nicht;
• eine Tür mehr: Jede in einem verbreiteten Plugin entdeckte Schwachstelle betrifft alle Websites, die es nutzen, bis sie aktualisiert werden.

Die Zahlen bestätigen es. Laut dem Jahresbericht von Patchstack, einem auf WordPress-Sicherheit spezialisierten Unternehmen, wurden 2025 im WordPress-Ökosystem 11.334 neue Schwachstellen entdeckt: 91 % in Plugins, 9 % in Themes und nur 6 im Core, alle von geringem Schweregrad. Der Kern des Systems, gepflegt von einer sehr großen Community, ist solide; das Risiko liegt in dem, was man hinzufügt. Jedes Plugin, das „weil es bequem ist“ installiert wird, ist eine Wette auf die Sorgfalt dessen, der es pflegt.

05WordPress richtig gemacht: Der Core bleibt unangetastet

WordPress ist nicht das Problem. Es ist ein solides System, das von einem riesigen Teil des Webs genutzt wird, mit einer Community, die es regelmäßig aktualisiert. Das Problem ist, wie es genutzt wird. Und hier gibt es eine Regel, die professionelle Arbeit stärker von Amateurarbeit trennt als jede andere.

Der Core von WordPress, also die Dateien des Systems, wird nie verändert. Die offizielle Dokumentation sagt es ausdrücklich: Es wird nicht empfohlen, die Core-Dateien zu ändern, abgesehen von der Konfigurationsdatei. Der Grund ist praktisch: Bei jedem Update werden die Systemdateien ersetzt, und jede dort vorgenommene Änderung verschwindet, oder, schlimmer noch, sie verhindert das Update und lässt die Website den Lücken ausgesetzt, die das Update geschlossen hätte.

Wo professionelle Entwicklung stattdessen arbeitet

WordPress ist dafür gebaut, erweitert zu werden, ohne angefasst zu werden, in Schichten:

• Das Child-Theme erbt alles vom Haupt-Theme und enthält nur die Unterschiede. Die Dokumentation von WordPress sagt es klar: Es erlaubt, das Parent-Theme zu aktualisieren, ohne die Änderungen zu verlieren.
• Maßgeschneiderte Plugins enthalten die spezifischen Funktionen des Betriebs, für genau dieses Projekt geschrieben, ohne die tausend Optionen eines kommerziellen Produkts, das für alle gedacht ist.
• Die Hooks (Actions und Filter) sind die vom System vorgesehenen Andockpunkte: Sie erlauben, ein Verhalten zu ändern, ohne die Datei neu zu schreiben, die es enthält.

So lässt sich die Website mit einem Klick aktualisieren, sie bleibt sicher, und die Anpassungen bleiben erhalten. Wer Ihnen vorschlägt, etwas „direkt im Core zu richten“, schlägt Ihnen, ohne es zu sagen, eine Website vor, die nicht mehr aktualisiert werden kann.

Wann WordPress die richtige Wahl ist, und wann nicht

WordPress passt bestens, wenn häufig Inhalte veröffentlicht werden sollen, mit mehreren Personen, die schreiben, und die Funktionen die typischen einer redaktionellen Website sind. Es wird zur Zwangslösung, wenn man es als Grundlage für eine Unternehmenssoftware, ein komplexes Buchungssystem oder ein Portal mit eigener Logik verwendet: Dann kämpft man am Ende gegen das Werkzeug und fügt Plugin um Plugin hinzu. In diesen Fällen kostet eine maßgeschneiderte Anwendung auf Dauer weniger.

06Was sauberer Code Ihnen wirklich bringt

„Sauberer Code“ klingt nach Fachjargon. In Wirklichkeit steht er für drei sehr konkrete Vorteile für alle, denen die Website oder die Software gehört: Sicherheit, Wachstumsfähigkeit und Sichtbarkeit bei Google.

Sicherheit: weniger Code, weniger Lücken

Jede Codezeile ist ein Ort, an dem sich ein Fehler verstecken kann. Ein schlankes Projekt, das nur enthält, was gebraucht wird, hat weniger Schwachstellen als eines, das mit generischen Komponenten aufgebläht ist. Ordentlicher Code ist auch Code, den man prüfen kann: Wenn niemand ihn lesen kann, kann niemand sagen, ob er sicher ist.

Wachstum: hinzufügen, ohne neu zu schreiben

Ein Betrieb verändert sich: ein neuer Service, ein zweiter Standort, eine weitere Sprache, eine Anbindung an die Unternehmenssoftware oder an die Steuerberatung. Bei gut entworfener Software zwingt das Hinzufügen einer Sache nicht dazu, eine andere neu zu schreiben: Es gibt einen vorgesehenen Punkt, an dem sie andockt. Bei Software, die in Schichten aus Flicken gewachsen ist, zerstört jede Änderung etwas anderes, und irgendwann lohnt es sich, bei null anzufangen. Genau dort wird die anfängliche Ersparnis zu den höchsten Kosten.

Technisches SEO: sich von Google gut lesen lassen

Google liest den Code der Seite, bevor es Ihre Texte liest. Sauberer Code hilft ihm zu verstehen:

• die Struktur: eine einzige Hauptüberschrift, Abschnittsüberschriften in der richtigen Reihenfolge, echte Listen statt von Hand formatierter Zeilen;
• die Bedeutung: strukturierte Daten, die sagen „Das ist ein Artikel“, „Das sind häufige Fragen“, „Das ist die Adresse des Betriebs“;
• die Geschwindigkeit: schlanke Seiten, die schnell antworten, auf dem Server und im Browser (darüber spreche ich im Kapitel über die Infrastruktur und in dem über die Geschwindigkeit);
• die Sprachen: übersetzte Seiten, richtig deklariert, damit jemand, der in einer anderen Sprache sucht, die richtige Seite findet. Darüber spreche ich im Kapitel über die mehrsprachige Website.

07Die echten Kosten: die Rechnung über drei Jahre

Der Vergleich zwischen professioneller Arbeit und Eigenbau wird fast immer über den Anfangspreis gezogen. Das ist der falsche Vergleich. Die Kosten einer Website oder einer Software misst man über die Jahre, in denen Sie sie nutzen, und zählt Dinge zusammen, die man am Anfang nicht sieht.

08Woran man professionelle Entwicklung erkennt

Sie müssen nicht programmieren können, um zu verstehen, ob Ihr Gegenüber gut arbeitet. Es genügen einige Fragen und Aufmerksamkeit für die Antworten: Wer professionell arbeitet, antwortet konkret, gibt die Grenzen der Werkzeuge zu und spricht zuerst über Ihr Problem und erst dann über die eigene Lieblingstechnologie.

1. „Was passiert, wenn ich eine Funktion hinzufügen muss?“ Die gute Antwort zeigt, wo sie andocken wird, ohne den Rest neu zu schreiben.
2. „Wie schützen Sie die Daten meiner Kunden?“ Es müssen präzise Begriffe kommen: verschlüsselte Verbindung, parametrisierte Queries, Passwörter nie im Klartext gespeichert, Backups außerhalb des Servers.
3. „Wie viele Komponenten von Dritten werden Sie verwenden, und wer aktualisiert sie?“ Besser wenige, ausgewählte, mit einer verantwortlichen Person.
4. „Wem gehören der Code und die Domain?“ Ihnen, schwarz auf weiß.
5. „Nutzen Sie künstliche Intelligenz?“ Es ist nichts Schlimmes, wenn die Antwort Ja lautet: Wichtig ist, dass gesagt wird, wer prüft, was sie erzeugt.
6. „Zeigen Sie mir eine Arbeit und wie sie innen gebaut ist?“ Wer gut arbeitet, hat keine Angst, den Code zu zeigen.

Der Wert maßgeschneiderten Codes zeigt sich vor allem dann, wenn die Website mehr tun muss, als Seiten anzuzeigen: wenn sie Buchungen ermöglichen, Kunden in ihren Bereich lassen, sich mit einer Unternehmenssoftware abgleichen und auf dem Smartphone wie eine App funktionieren soll. Genau dort erlaubt maßgeschneiderter Code, ein Buchungsportal und eine PWA sicher zu integrieren, ohne sich auf einen Stapel von Plugins zu stützen, die sich um dieselben Daten streiten. Das ist das Thema des nächsten Kapitels: integrierte Portale, Direktbuchungen und PWA.

Häufige Fragen

Quellen

1. OWASP GenAI Security Project, „LLM09:2025 Misinformation“: Erzeugung unsicheren Codes, von Modellen vorgeschlagene nicht existierende Bibliotheken, übermäßiges Vertrauen.
2. OWASP, „SQL Injection Prevention Cheat Sheet“: parametrisierte Queries als erste Abwehr.
3. OWASP, „Secrets Management Cheat Sheet“: warum Schlüssel und Passwörter nicht in den Code gehören.
4. Chrome for Developers, „Avoid an excessive DOM size“: die von Lighthouse verwendeten Schwellen von etwa 800 und 1.400 Elementen.
5. Chrome for Developers, „Remove unused CSS“: die Kosten geladener, aber ungenutzter Stylesheets.
6. Patchstack, „State of WordPress Security in 2026“: die 2025 entdeckten Schwachstellen, aufgeteilt nach Plugins, Themes und Core.
7. WordPress Developer Resources, „Child Themes“: das Parent-Theme aktualisieren, ohne die Änderungen zu verlieren.
8. WordPress Developer Resources, „Editing Files“: Es wird nicht empfohlen, Core-Dateien außer wp-config.php zu verändern.

Kapitel aktualisiert im Oktober 2026. Die Code- und Strukturbeispiele in den Tafeln sind vereinfacht, um das Prinzip zu zeigen; die genannten Schwellenwerte und Empfehlungen stammen aus der angegebenen offiziellen Dokumentation.