Schnell Code zu schreiben war einmal ein Skill. Seit KI ihn übernimmt, fragen uns Kunden: Warum kostet mein Projekt dann noch so viel? Weil das Lösen komplexer Probleme nicht billiger geworden ist. Nur das Schreiben von Code.
Einer unserer Entwickler hat einmal erzählt, wie er sich früher vorgestellt hat: Es gebe niemanden, der so schnell Java schreibe wie er. Zigarette anzünden, Tunnelmodus, und der Code floss nur so aus ihm heraus. Das war ein echter Skill, und er war Geld wert, weil Code zu schreiben teuer war.
Diese Zeiten sind vorbei. Seit Werkzeuge wie Claude Code (Ende 2024/Anfang 2025) in der Softwareentwicklung angekommen sind, ist es nicht mehr schwierig, schnell viel Code zu schreiben. Und seitdem hören wir von Kunden und zukünftigen Kunden eine berechtigte Frage: Wenn Code so billig geworden ist und sogar ich selbst mit Claude oder ChatGPT Code schreiben lassen kann, warum kostet mein Projekt dann immer noch so viel?
Die kurze Antwort: Es ist billiger geworden. Aber die Lösung komplexer Probleme ist nicht billig, und genau die nimmt einem die KI nach wie vor nicht ab. Was sich geändert hat: Kleinere Teams können heute viel größere Projekte stemmen. Was das heißt, und was ein Entwickler heute eigentlich den ganzen Tag macht, erklären wir hier.
Täglich wird mehr Code von KI geschrieben, viel mehr
Auch bei den KI-Anbietern selbst stammt der Großteil des neuen Codes inzwischen von KI. Google gibt an, dass drei Viertel des neuen Codes im Haus von KI erzeugt und von Engineers freigegeben werden. Bei Anthropic, dem Hersteller von Claude, stieg die Zahl der täglich übernommenen Codeänderungen zwischen Mai und September 2026 von rund 2.500 auf über 30.000. Das Versionskontrollsystem Git, seit zwanzig Jahren der Standard der Branche, kam nicht mehr mit. Anthropic hat es für sein zentrales Code-Repository durch ein eigenes System ersetzt.
Dario Amodei, der Chef von Anthropic, sagte im Januar 2026 in Davos, in sechs bis zwölf Monaten könnten Modelle das meiste, vielleicht alles tun, was Software-Engineers heute tun. Andrej Karpathy, der den Begriff Vibe Coding geprägt hat, nennt die neue Arbeit inzwischen Agentic Engineering: Man schreibt den Code zu 99 Prozent nicht mehr selbst, man leitet Agenten an und beaufsichtigt sie.
Auf den ersten Blick (und auf LinkedIn) wirkt es deshalb, als könne jetzt jeder selbst Software entwickeln. Das stimmt nur zum Teil. Zwischen einer Demo und einem echten Produktivsystem liegt ein riesiger Unterschied. Die meisten Lösungen, die Laien per Vibe Coding bauen, laufen in der Demo und brechen im Realbetrieb zusammen: 2026 standen tausende solcher Apps mit offen erreichbaren Datenbanken im Netz, Kundendaten inklusive.
Wäre Software-Entwicklung mittlerweile wirklich so einfach, wie es einem der durchschnittliche KI-Enthusiast (vormals Bitcoin-Experte) auf LinkedIn glauben lassen möchte, wären wir schön blöd, regelmäßig Wochenende und Schlaf für die Entwicklung außergewöhnlicher Systeme zu opfern.
Warum Softwareprojekte trotzdem nicht gratis sind
Wenn das Schreiben von Code billig ist, müsste doch Software billig sein? Ist sie aber nicht, und dafür gibt es Messungen.
DORA ist ein Forschungsprogramm von Google, das jedes Jahr tausende Entwicklungsteams befragt und misst, wie schnell und wie stabil sie Software ausliefern. 2024 fand DORA: Je mehr KI ein Team einsetzte, desto instabiler wurde das Ergebnis, und schneller wurde es nicht einmal. 2025 war das Tempo positiv, die Stabilität weiter negativ. DORAs Erklärung: Wer schneller liefert, stößt schneller auf alles, was im Prozess dahinter nicht hält, auf fehlende Tests, auf Freigaben, auf den Betrieb.
METR, ein unabhängiges Forschungsinstitut, das die Fähigkeiten von KI-Systemen misst, hat 2025 sechzehn erfahrene Entwickler mit und ohne KI-Werkzeuge an echten Aufgaben beobachtet. Mit KI brauchten sie 19 Prozent länger. Hinterher schätzten sie, 20 Prozent schneller gewesen zu sein. In einer Folgeerhebung Anfang 2026 waren die Entwickler mit neueren Werkzeugen vermutlich schneller, aber der Abstand zwischen gefühlter und gemessener Geschwindigkeit blieb. Das Gefühl von Geschwindigkeit und die tatsächliche Geschwindigkeit sind zwei verschiedene Dinge.
Und Anthropic selbst schreibt in dem Text, in dem es seinen Git-Ersatz vorstellt: Jede Änderung wird weiterhin von einem Menschen geprüft, nur nicht mehr Zeile für Zeile, sondern auf ihre Absicht.
Auch bei den Unternehmen, die die Frontier-Modelle entwickeln, müssen also noch echte Menschen ran. Die Arbeit, die in einem Projekt wirklich den Mehrwert geschaffen hat, war nie das Tippen von Codezeilen. Es war das Entscheiden: was gebaut wird, was nicht, und wie das System den Realbetrieb besteht. Dieser Teil ist nicht billiger geworden. Er ist vor allem komplexer geworden, weil jetzt durch KI-Systeme mehr und schneller Code entsteht, über den entschieden werden muss. Und das ist auch extrem wichtig. Ein Beispiel aus unserer Praxis:
Ein KI-System sollte für mehrere Firmen gleichzeitig laufen, und jede Firma darf nur ihre eigenen Daten sehen. Unser interner KI-Workflow hat fast alles von selbst gebaut, alles sah fertig aus. Beim Review stellte sich einer unserer Entwickler die Frage: Was passiert, wenn ich mich bei Firma B mit den Zugangsdaten von Firma A anmelde? Antwort: Man sieht die Daten von Firma B. Die Trennung wurde zwar angezeigt, sie wurde auch von der KI behauptet, wurde aber im Hintergrund nie vernünftig implementiert. Das System lief auf den ersten Blick und für den Laien kaum überprüfbar perfekt. Genau hier liegt die Gefahr des klassischen „Vibe Coding".
Nein sagen ist der neue Core-Skill
Die wichtigste Fähigkeit eines Entwicklers ist heute, zu sagen, welcher Vorschlag der KI es nicht ins Produkt schafft. Ein weiteres Beispiel aus unserer Praxis:
In einem unserer Projekte gab es seit Monaten eine automatische Buchungsfreigabe in bestimmten Fällen. Die KI bekam die Aufgabe, einen angrenzenden Ablauf zu erweitern, und baute dabei ungefragt einen kompletten manuellen Freigabeprozess dazu: Rollen, Benachrichtigungen, Statusübergänge. Technisch sauber, funktionsfähig und komplett überflüssig, weil die Regel das längst automatisch erledigt. Ohne einen Entwickler, der das Produkt kennt und sagt „das brauchen wir nicht", wäre das im System gelandet und hätte ab dann zu Problemen geführt.
Das ist kein Einzelfall, sondern ein Muster. Anthropic, der Hersteller von Claude Code, gibt in seiner eigenen Dokumentation an, dass einzelne Modellgenerationen zu Overengineering neigen: Sie bauen mehr, als verlangt wurde, zusätzliche Dateien, Zwischenschichten, Absicherungen. Das Ergebnis löst das konkrete Problem sofort, und in einem Jahr kann es niemand mehr ändern. Analysen des Code-Analyseanbieters GitClear über Hunderte Millionen Codeänderungen zeigen dasselbe: Duplizierter Code hat sich seit 2020 vervielfacht, Aufräumarbeit nimmt ab. Wer das nicht erkennt, bekommt schnell viel Code und langsam ein Problem.
Was ein Entwickler heute tut
Ein großer Teil der Arbeit besteht darin, dem Modell den Plan mitzugeben und den richtigen Weg aufzuzeigen. Softwareentwicklung ist nach wie vor ein Bereich, in dem man vieles erst nach dem Ausprobieren weiß: ob eine Lösung schneller ist, günstiger läuft oder sich besser bedienen lässt. Mit KI kann ein Entwickler an einem Tag mehr Varianten durchspielen als früher in einer Woche. Dafür muss er die Grundlagen guten Software-Designs beherrschen, weil das Modell sie zwar in der Theorie perfekt kennt, in der realen Umsetzung aber oft die falsche Abzweigung nimmt.
Man kann auf ein Problem aus zwei Blickwinkeln schauen: aus der Adlersicht oder aus der Froschsicht. Der Adler sieht den ganzen Wald. Der Frosch sieht den Stein direkt vor sich, dafür sehr genau. Früher war die Adlersicht Sache eigener Rollen, Produktmanager, Architekten, Projektleiter. Der Entwickler war der Frosch, und das war in Ordnung. Er hatte mit dem Schreiben genug zu tun. Heute muss ein Entwickler zwischen beiden Sichten wechseln können: von oben das Problem und das Produkt verstehen, von unten prüfen, ob die KI den richtigen Stein gesetzt hat. Richtig gute Entwickler konnten das schon immer. Jetzt ist es die Voraussetzung.
Warum kleine Teams
Erfahrungsgemäß haben auch in großen Unternehmen immer wenige Schlüsselpersonen den Unterschied gemacht. KI hat das nur beschleunigt. In den Communications of the ACM, der Fachzeitschrift des größten Informatikerverbands der Welt, schreiben zwei Microsoft-Führungskräfte, Generative KI wirke „seniority-biased", ein Begriff aus einer Harvard-Studie: Sie bringt den erfahrenen Entwicklern am meisten, denen, die beurteilen können, ob eine Lösung im Gesamtsystem trägt. Den Unerfahrenen bringt sie deutlich weniger.
Die unbequeme Seite davon: Nach einer Stanford-Studie ist die Beschäftigung von Softwareentwicklern zwischen 22 und 25 seit 2022 um fast 20 Prozent gesunken. Die Werkzeuge ersetzen nicht die Erfahrenen, sie ersetzen die Einstiegsarbeit, an der man früher Erfahrung gesammelt hat. Das ist ein Problem für die Branche. Für dein Projekt heißt es: Es kommt auf wenige Leute an, und die solltest du gut aussuchen.
Erst kürzlich haben wir ein Projekt im Biotech-Bereich abgeschlossen, eine recht komplexe „Data-Pipeline". Nach unserer Erfahrung hätte man dafür früher zwei Jahre, drei Entwickler und mindestens zwei Data Scientists gebraucht. Heute entsteht dasselbe mit einem fähigen Entwickler, einem Domänenexperten und etwas Fachwissen in unter einem Jahr.
Wir haben unser Team bewusst für die neue Ära aufgestellt: schlank, mit Leuten, die ihren Senior-Status in etablierten IT-Unternehmen, großen Agenturen und Beratungshäusern erarbeitet haben.
Was das für den Preis heißt
Zuerst billiger geworden ist alles, was sich ausprobieren lässt: Varianten, Prototypen, Oberflächen, Standardfunktionen. Ein Prototyp, der vor drei Jahren sechs Wochen gedauert hat, steht heute in Tagen. Auch alles, was im Realbetrieb halten muss, wird billiger: die Architektur, die Anbindung an die echten Daten, die Berechtigungen, der Betrieb. Aber nur mit den richtigen Leuten. Ohne sie produziert KI Unmengen an schlechtem Code schneller als je zuvor, und daraus kann mehr Komplexität entstehen als noch in der Zeit vor KI. Die kostet am Ende mehr, als das Schreiben je gekostet hat.
Was das für dein Projekt heißt
Vielleicht hast du schon einen Prototyp, selbst gebaut oder von jemandem bauen lassen, und er funktioniert. Das war sicherlich die richtige Entscheidung. Ihn produktiv zu betreiben, ist meistens die falsche.
Wie wir aus einem Prototyp ein Produkt machen, steht auf unserer Seite zu Individualsoftware, was wir bei bestehenden Systemen tun, auf der Seite zu Software-Modernisierung. Und wenn du vor der Frage stehst, ob du überhaupt etwas Eigenes brauchst: Das haben wir hier beantwortet.
Das Fundament lässt sich nicht nachträglich unter ein fertiges Haus schieben. Wir versprechen dir aber, dass wir mindestens so viel KI in unseren Workflows verwenden wie jeder Vibe Coder.
Quellen
- Anthropic Engineering: Redesigning source control (13.10.2026)
- DORA: 2024 und 2025 State of AI-assisted Software Development
- METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (Juli 2025)
- METR: Update (Feb. 2026)
- Russinovich, Hanselman: Redefining the Software Engineering Profession for AI, Communications of the ACM (Feb. 2026)
- Brynjolfsson, Chandar, Chen: Canaries in the Coal Mine? (Stanford Digital Economy Lab, 2025)
- GitClear: AI Copilot Code Quality (2025) und The Maintainability Gap (2026)
- Anthropic: Prompting best practices, Abschnitt Overeagerness
- Cybernews: 16,000 Supabase databases exposed as vibe-coded apps leak sensitive user data (2026)