Wie wir mit LLM-gestützter Implementierung Projekte 10× schneller liefern — und warum Qualität dabei nicht leidet.
Das Wasserfall-Projekt ist tot.
Zwölf Wochen Konzeptphase, sechs Wochen Spezifikation, dann ein halbes Jahr Entwicklung, bei dem am Ende kaum noch jemand weiß, warum eine Anforderung ursprünglich im Lastenheft stand. Wer Software in den letzten zwanzig Jahren so eingekauft hat, kennt das Muster — und das Risiko, dass das Ergebnis am Markt vorbeigeht.
Mit LLM-gestützter Implementierung liefern wir den ersten lauffähigen Stand heute in Tagen statt Monaten. Nicht den Prototyp zum Wegwerfen, sondern eine Codebasis, die produktiv weiterläuft. Das verschiebt nicht nur Zeitpläne, es verändert, wie Entscheidungen getroffen werden.
Denn wenn ein funktionsfähiger Stand nach drei Tagen statt drei Monaten auf dem Tisch liegt, diskutiert man nicht mehr über Mockups — man klickt durch ein echtes System und merkt sofort, was fehlt. Anforderungen, die auf dem Papier plausibel klangen, entlarven sich am laufenden Produkt in Minuten als überflüssig oder falsch gedacht.
Wie der Faktor 10 zustande kommt.
Der Geschwindigkeitsgewinn entsteht nicht durch schnelleres Tippen, sondern durch das Wegfallen von Reibung. Boilerplate, Datenmodelle, API-Anbindungen, Testgerüste — alles, was früher tagelange Fleißarbeit war, generiert ein Modell in Minuten. Unsere Entwickler verbringen ihre Zeit dort, wo Urteilsvermögen zählt: Architektur, Edge Cases, Integration.
In einem typischen Vergleich aus unseren Projekten: Ein Kundenportal mit Auth, Rollen, drei angebundenen Systemen und Reporting brauchte früher rund vier Monate bis zum produktiven Launch. Mit LLM-gestütztem Build standen die ersten zwei Wochen für ein nutzbares MVP, der Vollausbau nach gut sechs Wochen.
Wichtig ist: Das Modell schreibt Code, der Mensch verantwortet ihn. Jede generierte Zeile durchläuft Review, Tests und unsere Sicherheits-Gates. Niemand merged ungelesen.
Der Engpass verschiebt sich damit von der Produktion zur Entscheidung. Nicht mehr die Frage 'Wie lange dauert das?' bestimmt das Tempo, sondern 'Was genau wollen wir bauen?' — und genau diese Frage lässt sich am laufenden System schneller und ehrlicher beantworten als in jedem Workshop.
Warum die Qualität dabei steigt, nicht sinkt.
Der Reflex ist verständlich: schnell heißt schludrig. In der Praxis ist das Gegenteil der Fall. Weil Testabdeckung, Linting und Dokumentation kaum noch Mehraufwand bedeuten, entstehen sie von Anfang an mit — statt am Ende gestrichen zu werden, wenn das Budget knapp wird.
Schnellere Iterationen bedeuten außerdem, dass Fehlannahmen früh auffallen. Ein Konzeptfehler, der im klassischen Projekt erst beim Abnahmetest nach sechs Monaten sichtbar wird, fällt bei uns in der ersten Woche auf — wenn die Korrektur noch Stunden statt Wochen kostet.
Wir messen das: Defect-Density und der Anteil an Nacharbeit nach Launch sind in den schnell gebauten Projekten nicht höher, sondern niedriger als im klassischen Vorgehen.
Wo der Faktor 10 nicht greift.
Ehrlichkeit gehört dazu: Nicht jedes Projekt beschleunigt sich um den Faktor 10. Wo die Komplexität nicht im Code liegt, sondern in Abstimmung, regulatorischen Freigaben oder der Migration gewachsener Altsysteme, ist das Modell nur ein Baustein unter vielen. Die Implementierung war dort nie der Engpass.
Auch bei stark domänenspezifischer Logik — versicherungsmathematische Tarifierung, sicherheitskritische Steuerung — bleibt der Anteil menschlicher Arbeit hoch, weil hier jeder Fehler teuer ist und das Modell ohne tiefes Fachwissen nicht verlässlich urteilt.
Wir kommunizieren das offen, statt überall denselben Faktor zu versprechen. Der ehrliche Gewinn liegt im Schnitt eher bei Faktor 3 bis 5 über das Gesamtprojekt — und beim Standard-Build, wo Reibung dominiert, eben bei 10.
Was das für unsere Kunden heißt.
Newroom ist Umsetzer, kein Berater. Tempo ist für uns kein Selbstzweck, sondern die Grundlage dafür, ein Produkt zu bauen, auszurollen und zu betreiben — und es nach dem Launch weiterzuentwickeln, statt es einzufrieren.
Für den Kunden verschiebt sich das Risiko: Statt ein großes Budget gegen ein Pflichtenheft zu wetten, sieht er nach wenigen Tagen Substanz und entscheidet auf Basis von Funktionierendem. Fehlentscheidungen kosten nicht mehr ein halbes Projekt, sondern eine Iteration.
Das ist die eigentliche Revolution — nicht die Geschwindigkeit, sondern die Sicherheit, die sie schafft. Wer in Tagen sieht statt in Monaten zu glauben, trifft bessere Entscheidungen.