KI-Coding-Tools im Praxistest: was in echten Projekten funktioniert

Warum wir das aus dem Alltag und nicht aus einer Demo berichten

Über KI-Coding-Werkzeuge wird viel geschrieben, meist von Leuten, die eine glänzende Vorführung gesehen haben. Wir bauen damit jeden Tag Produkte, die danach im Betrieb laufen und Kunden bedienen. Das ist ein Unterschied. Eine Demo darf beeindrucken, ein Produkt muss halten, auch in einem halben Jahr, wenn niemand mehr weiss, wie diese eine Funktion entstanden ist.

Dieser Bericht sagt, wo die Werkzeuge in echten Projekten Zeit sparen, wo sie Schaden anrichten und was sich an der Arbeit tatsächlich ändert. Ohne Zahlenversprechen, denn wer dir sagt, KI mache die Entwicklung um vierzig Prozent schneller, hat sie entweder nie im Ernst benutzt oder verkauft dir etwas.

Wo sie wirklich Zeit sparen

Am stärksten sind die Werkzeuge bei allem, was viele schon einmal geschrieben haben und was sich kaum unterscheidet. Das Gerüst einer neuen Funktion, ein Formular mit Validierung, die immer gleiche Anbindung an eine bekannte Schnittstelle: Solche Arbeit war früher stumpf und langsam, jetzt steht die erste Fassung in Minuten.

Zwei Fälle stechen heraus. Der erste sind Tests. Für bestehenden Code sinnvolle Testfälle zu entwerfen ist Fleissarbeit, die man gern aufschiebt. Hier liefern die Werkzeuge einen Entwurf, den man nur noch schärfen muss, und plötzlich entsteht die Absicherung, die sonst liegen bliebe. Der zweite ist unbekanntes Terrain. Wenn wir in einer Sprache oder mit einer Bibliothek arbeiten, die wir selten benutzen, ersetzt ein guter Assistent das lange Lesen von Dokumentation. Nicht fehlerfrei, aber schnell genug für einen brauchbaren Startpunkt.

Auch beim Aufräumen helfen sie. Eine unübersichtliche Stelle umschreiben, einen Namen überall ändern, eine wiederkehrende Struktur vereinheitlichen: Solche Schritte gehen schneller, weil das Werkzeug den Kontext mitliest. Das macht das Aufräumen von technischen Schulden etwas weniger mühsam, als es früher war.

Wo sie Schaden anrichten

Der gefährlichste Fehler ist nicht der offensichtliche. Wenn ein Vorschlag gar nicht läuft, merkt man es sofort. Teuer wird das, was plausibel aussieht und trotzdem falsch ist. Der Assistent schreibt mit derselben Selbstsicherheit eine korrekte und eine subtil kaputte Lösung. Wer nicht genau weiss, wie es richtig geht, erkennt den Unterschied nicht, und genau da entstehen die Fehler, die erst im Betrieb auffallen.

Ein zweites Muster: Sicherheit. Die Werkzeuge greifen gern zu einem Weg, der funktioniert, aber eine Lücke öffnet. Eine Abfrage, die sich manipulieren lässt, ein Zugang, der zu weit offen steht, ein Geheimnis, das im Code landet. Das läuft im Test tadellos und wird zum Problem, sobald jemand danach sucht. Deshalb lassen wir bei allem, was mit Daten und Zugängen zu tun hat, keinen Vorschlag ungeprüft durch.

Dazu kommt ein leiser Hang zu zu viel. Fragt man nach einer einfachen Lösung, kommt oft eine, die drei Fälle mehr abdeckt, als es je brauchen wird. Diese überflüssige Bequemlichkeit sieht harmlos aus und wird später zu Ballast, den jemand pflegen muss. Und schliesslich hängen die Werkzeuge an dem, was sie gelernt haben. Bei einer Bibliothek, die sich kürzlich geändert hat, schlagen sie manchmal mit voller Überzeugung ein Muster vor, das seit einer Version veraltet ist.

Prototyp und Produktion sind zwei verschiedene Dinge

Das sogenannte Vibe-Coding, bei dem man dem Assistenten locker beschreibt, was man will, und nimmt, was herauskommt, hat seinen Platz. Für einen Prototyp, den man ohnehin wegwirft, für eine schnelle Machbarkeitsfrage oder ein internes Wegwerf-Skript ist es grossartig. Da zählt Tempo, nicht Wartbarkeit.

Für ein Produkt, das in den Betrieb geht, ist derselbe Ansatz riskant. Was schnell zusammengeklickt wurde, niemand verstanden hat und keine Tests absichern, wird zur Last, sobald es sich ändern soll. Wo diese Grenze zwischen schnellem Selbermachen und tragfähigem Bauen verläuft, haben wir im Vergleich KI-Software selbst bauen oder ins Studio geben genauer beschrieben. Die kurze Fassung: Der Weg zum Prototyp ist heute für viele offen. Der Weg zu etwas, das Jahre läuft, ist es nicht geworden.

Was sich an der Arbeit wirklich ändert

Die interessanteste Verschiebung ist nicht, dass wir schneller tippen. Sie ist, dass sich der Engpass verlagert. Code zu erzeugen ist billig geworden, Code zu prüfen nicht. Wer viel generiert, muss viel lesen und beurteilen, und diese Prüfung ist der Teil, der Erfahrung verlangt. Ein Assistent kann einen Entwurf liefern, aber nicht entscheiden, ob er in dieses Produkt gehört.

Damit wird das Urteil einer erfahrenen Person wichtiger, nicht unwichtiger. Wer nicht einschätzen kann, ob ein Vorschlag gut ist, produziert mit KI nur schneller Dinge, die er nicht versteht. Die Verantwortung bleibt beim Menschen, der am Ende seinen Namen unter das Ergebnis setzt. Nebenbei erklärt das, warum Aufwandsschätzungen weiter danebenliegen: Das Schreiben war selten der teure Teil, das Verstehen und Absichern ist es, und daran hat sich wenig geändert.

Was das für dich als Auftraggeber bedeutet

Wenn du ein Produkt bauen lässt, ist die richtige Erwartung nüchtern. Ja, gute Werkzeuge machen manches schneller, und das geben wir weiter. Nein, Software wird dadurch nicht beliebig billig, und wer das verspricht, spart an der Stelle, die später weh tut, nämlich am Prüfen. Der Preis eines Produkts hängt ohnehin mehr am Betrieb über die Jahre als an der ersten Fassung, wie wir im Text dazu zeigen, was Software nach dem Launch teuer macht.

Die entscheidende Frage bei einem Partner ist deshalb nicht, ob er KI einsetzt. Das tun mittlerweile alle. Sie ist, ob jemand da ist, der beurteilen kann, was das Werkzeug ausspuckt. Wir setzen diese Werkzeuge dort ein, wo sie wirklich etwas bringen, und lassen sie dort weg, wo ein Mensch genauer hinschauen muss. Wenn du ein Vorhaben hast, bei dem Tempo und Sorgfalt beide zählen, sprich mit uns, und wir gehen es mit dir durch.