KI-gestützte Entwicklung.

KI spart dort zuverlässig Zeit, wo die richtige Lösung bekannt ist und ein Mensch das Ergebnis in Sekunden als richtig oder falsch erkennt. Das ist nicht die spannende Hälfte der Arbeit, aber es ist ein grosser Teil davon. Vier Felder tragen den Gewinn.

• Gerüstwerk und Wiederholung. Formulare mit Validierung, Typdefinitionen, Konfigurationen, wiederkehrende Komponentengerüste, Anbindungen an eine dokumentierte Schnittstelle. Alles Aufgaben mit klarem Muster und klarer Prüfbarkeit.
• Tests. Der Gewinn liegt weniger im Hauptfall als in den Randfällen — leere Eingaben, Umlaute, Zeitzonen, doppelte Absendung. Ein Modell schlägt geduldig zwanzig davon vor; ein Mensch schreibt erfahrungsgemäss fünf und hört dann auf.
• Mechanische Migrationen. Eine Bibliotheksversion über hunderte Dateien nach demselben Muster nachziehen, eine Benennungskonvention vereinheitlichen, veraltete Aufrufe ersetzen. Repetitiv, fehleranfällig für Menschen, gut prüfbar.
• Dokumentation. Aus vorhandenem Code eine erste Beschreibung ableiten, eine Schnittstelle beschreiben, ein Übergabedokument entwerfen. Das Ergebnis wird redigiert, aber es entsteht nicht mehr aus dem Nichts.

Der praktische Effekt für ein Projekt ist weniger «alles geht doppelt so schnell» als «die Strecke zwischen Entscheidung und sichtbarem Ergebnis wird kürzer». Genau das verändert Projekte spürbar: Sie sehen früher etwas, Sie ändern früher etwas, und wir diskutieren am laufenden System statt an einer Beschreibung. Bei Landingpages und Rechnern und Konfiguratoren ist dieser Effekt am deutlichsten, weil dort viele Varianten sinnvoll sind.

KI kostet Zeit beim Verstehen und Reparieren von Code, den man nicht selbst geschrieben hat — und sie kostet umso mehr Zeit, je vertrauter das Projekt und je erfahrener die Person ist. Das ist die Hälfte der Geschichte, die in Verkaufsgesprächen selten vorkommt, und sie ist besser belegt als der Zeitgewinn.

Die bisher sauberste Messung stammt vom Forschungsinstitut METR. In einer randomisierten Studie, veröffentlicht im Juli 2025, bearbeiteten 16 erfahrene Open-Source-Entwickler 246 Aufgaben in Projekten, die sie selbst gut kannten. Mit KI-Werkzeugen brauchten sie 19 Prozent länger als ohne. Bemerkenswert ist nicht die Zahl, sondern die Wahrnehmung: Dieselben Personen schätzten hinterher, 20 Prozent schneller gewesen zu sein. Wer den eigenen Zeitgewinn nur fühlt statt misst, irrt sich also in eine vorhersehbare Richtung.

Die Stack-Overflow-Entwicklerumfrage 2025 beschreibt denselben Effekt aus der Innensicht: 66 Prozent der Befragten nennen Lösungen, die «fast richtig, aber nicht ganz» sind, als grösste Reibung im Alltag; 45 Prozent geben an, dass das Debuggen von KI-erzeugtem Code mehr Zeit kostet. Gleichzeitig nutzen oder planen 84 Prozent den Einsatz solcher Werkzeuge. Beides gilt: hohe Verbreitung, verhaltenes Vertrauen — nur 3 Prozent bezeichnen die Genauigkeit als hoch vertrauenswürdig.

Die teuerste Kategorie sind subtile Fehler. Ein Modell erzeugt Code, der syntaktisch einwandfrei ist, im Normalfall korrekt läuft und erst in einer bestimmten Konstellation falsch rechnet — bei einem Sommerzeitwechsel, bei einer leeren Liste, bei gleichzeitigem Zugriff. Solche Fehler entgehen einem schnellen Blick, weil nichts kaputt aussieht. Sie fallen später auf, im Betrieb, bei jemand anderem.

Weil Sprachmodelle darauf optimiert sind, funktionierenden Code zu schreiben, nicht angriffsresistenten — und der Unterschied ist an der Oberfläche nicht sichtbar. Die Datenlage dazu ist inzwischen ungewöhnlich klar.

Veracode prüfte im Frühjahr 2026 über 150 Sprachmodelle an 80 typischen Programmieraufgaben in Java, JavaScript, C# und Python. Ohne ausdrückliche Sicherheitsvorgabe im Prompt bestanden nur 55 Prozent der Ergebnisse die Sicherheitsprüfung. Aufgeschlüsselt nach Schwachstellenart schwanken die Werte stark: Bei SQL-Injection lag die Bestehensquote bei 82 Prozent, bei kryptografischen Verfahren bei 86 Prozent — bei Cross-Site-Scripting jedoch bei 15 Prozent und bei Log-Injection bei 13 Prozent. Nach Sprache reicht die Spanne von 62 Prozent bei Python bis 29 Prozent bei Java.

Der aufschlussreichste Befund ist der Verlauf über die Jahre: Die syntaktische Trefferquote stieg seit 2023 von rund 50 auf 95 Prozent, während die Sicherheitsquote praktisch flach blieb. Bessere Modelle schreiben also zuverlässiger lauffähigen Code, aber nicht zuverlässiger sicheren. Diese Schere schliesst sich nicht von allein, weil Sicherheit selten aus dem Kontext ableitbar ist — sie hängt davon ab, wer die Daten sieht, was ein Angreifer erreichen will und welche Pflichten gelten.

Praktisch heisst das bei uns: Sicherheitsrelevante Bausteine — Anmeldung, Rechte, Eingabeverarbeitung, Umgang mit Personendaten nach dem revidierten Datenschutzgesetz — werden von Hand entschieden, mit etablierten Bibliotheken umgesetzt und gesondert geprüft. Für den Betrieb kommen automatische Prüfungen auf bekannte Schwachstellenmuster und veraltete Abhängigkeiten dazu. Diese Arbeit verschwindet durch KI nicht; sie wird durch die grössere erzeugte Codemenge eher wichtiger.

Unser Prozess unterscheidet sich vom klassischen an genau einer Stelle: KI erzeugt Entwürfe, aber jede Änderung durchläuft dieselben vier Prüfschritte wie handgeschriebener Code. Das klingt unspektakulär und ist der eigentliche Punkt — der Gewinn entsteht durch das Werkzeug, die Qualität durch das Verfahren.

• 1. Architektur von Hand. Datenmodell, Modulgrenzen, Schnittstellen und die Frage, was die Wahrheit ist, werden vor der Umsetzung entschieden und aufgeschrieben. Ein Modell optimiert die nächste Datei, nicht das Ganze.
• 2. Umsetzung mit Werkzeugunterstützung. Gerüstwerk, Tests und Wiederholungen entstehen assistiert, die tragenden Teile werden gelesen, oft umgeschrieben, immer verstanden.
• 3. Review durch einen Menschen. Jede Änderung wird von einer zweiten Person gelesen, die sie ablehnen darf. Ohne diese Instanz wird die Methode zum Selbstläufer.
• 4. Messung im Betrieb. Nach dem Start zählen Ladezeit, Fehlerrate und Core Web Vitals unter echten Bedingungen — nicht der Eindruck auf dem Entwicklungsrechner.

Für Sie als Auftraggeberin oder Auftraggeber bedeutet das drei konkrete Zusagen: Der Code liegt in Ihrem Repository und wird mit allen Zugängen übergeben; es gibt eine Architekturübersicht, die auch eine andere Agentur lesen kann; und wir benennen im Projektverlauf, welche Teile wir für stabil und welche wir für vorläufig halten. Wie wir daraus grössere Systeme bauen, zeigt Komplexe Weblösungen; die klassische Umsetzungsseite für die Region ist Webentwicklung Zürich.

Sie kommen früher zu etwas Sichtbarem und zahlen weniger für mechanische Arbeit — aber die Prüfarbeit sinkt nicht, sie wächst mit der erzeugten Menge. Wer Ihnen einen Preis nennt, der im Wesentlichen auf «die KI macht das ja» beruht, hat den zweiten Teil nicht eingerechnet.

Realistisch verschieben sich vor allem drei Dinge. Erstens die Sichtbarkeit: Ein klickbares Ergebnis existiert nicht nach Wochen, sondern nach Tagen — deshalb legen wir den ersten Termin, an dem Sie etwas bedienen können, bewusst früh. Zweitens die Kosten von Änderungswünschen: Eine Variante auszuprobieren ist heute deutlich günstiger als vor zwei Jahren, was frühe Kurskorrekturen begünstigt. Drittens die Gewichtung im Angebot: Weniger Aufwand für Tippen, mehr Aufwand für Konzept, Review und Prüfung.

Unsere Preisanker bleiben davon unberührt, weil sie am Ergebnis hängen und nicht am Werkzeug: Ein Prototyp zur Ideenvalidierung beginnt bei CHF 10'000, eine Website liegt je nach Umfang zwischen CHF 3'000 und CHF 25'000, laufendes SEO beginnt bei CHF 800 pro Monat. Was ein konkretes Projekt kostet, sagen wir nach dem Erstgespräch; eine erste Einordnung liefert unser Projektrechner, ausführlicher wird es unter Webdesign-Preise.

KI-gestützte Entwicklung ist die falsche Antwort, wenn das eigentliche Problem kein Entwicklungsproblem ist — und das ist häufiger der Fall, als der Markt zugibt. Wir sagen das im Erstgespräch, auch wenn es gegen den Auftrag spricht.

• Wenn die Anforderung unklar ist. Schnelleres Bauen macht eine unklare Anforderung nicht klarer, es produziert nur schneller das Falsche. Dann gehört der erste Schritt in ein Gespräch, nicht in ein Repository.
• Wenn Standardsoftware genügt. Für Buchhaltung, Newsletter, Terminbuchung oder einen einfachen Shop existieren bewährte Produkte. Eigenentwicklung lohnt sich erst, wenn ein Ablauf tatsächlich einzigartig ist.
• Wenn niemand die Verantwortung tragen will. Ohne eine Person, die Review macht und ablehnen darf, entsteht ein System ohne Eigentümer. Das rächt sich beim ersten Personalwechsel.
• Bei sehr hohen Sicherheits- oder Regulierungsanforderungen. Dort bleibt der Anteil handgeschriebener, geprüfter und dokumentierter Arbeit hoch — der Zeitgewinn schrumpft entsprechend, und das gehört ehrlich in die Offerte.
• In grossen, gewachsenen Bestandssystemen. Genau hier mass METR den Gegeneffekt. Wir setzen Werkzeuge dort gezielt und begrenzt ein statt flächendeckend.

Und der grundsätzliche Vorbehalt: KI ersetzt kein Produktverständnis. Ein Modell schreibt, was beschrieben wird — es fragt nicht, ob es jemand braucht. Diese Frage stellen wir vor der ersten Zeile Code, meist gemeinsam mit einem Prototyp und einer Validierung mit echten Nutzerinnen und Nutzern. Was wir bisher gebaut haben, steht in den Referenzen.