AI-native Softwareentwicklung: Was sich für Sie als Auftraggeber ändert

Jedes Softwareunternehmen sagt heute, dass es KI nutzt. Die meisten meinen damit, dass ihre Entwickler einen Coding-Assistenten im Editor offen haben. Das ist nützlich, und es ist nicht das, was wir AI-native nennen. Der Unterschied ist für alle wichtig, die Software einkaufen, denn er zeigt sich darin, wie ein Projekt geplant und geprüft wird und was Ihnen am Ende gehört.

Dieser Artikel erklärt, was sich ändert, wenn KI in den gesamten Lieferprozess eingebaut ist, was genau so bleibt wie bisher und welche Fragen Sie jedem Anbieter stellen sollten, der behauptet, so zu arbeiten.

Assistent im Editor oder KI im Prozess

Ein Coding-Assistent beschleunigt das Tippen von Code. In einem typischen Projekt ist das Tippen von Code der kleinere Teil des Aufwands. Der Rest besteht darin, das Problem zu verstehen, bestehende Systeme zu lesen, einen Ansatz zu wählen, Tests zu schreiben, Änderungen zu prüfen, zu dokumentieren, Daten zu migrieren und zu reparieren, was in Produktion kaputtgeht.

AI-native zu arbeiten heißt, jeden dieser Schritte anzusehen und zu fragen, wo ein Modell unter Aufsicht echte Arbeit leisten kann:

• Analyse. Modelle lesen die bestehende Codebasis, API-Dokumentation, Datenbankschemata und Tickets und erstellen eine Karte davon, wie das System tatsächlich funktioniert. Was früher eine Woche Archäologie war, dauert einen Tag, und die Senior-Engineerin prüft die Karte, statt sie zu zeichnen.
• Spezifikation. Anforderungen werden so präzise festgehalten, dass man sie prüfen kann, oft mit Beispielen, aus denen Tests werden.
• Umsetzung. Agenten arbeiten parallel an klar abgegrenzten Aufgaben, jeweils in einem eigenen Branch, und jede Änderung wird von einem Menschen geprüft.
• Tests. Testfälle entstehen aus der Spezifikation und aus Grenzfällen, die ein Modell im Code findet, und werden von Engineers kuratiert.
• Review. Jede Änderung durchläuft ein automatisches Review auf Fehler, Sicherheitsprobleme und Widersprüche, bevor ein menschlicher Reviewer sie sieht.
• Dokumentation und Übergabe. Dokumentation entsteht zusammen mit dem Code und bleibt aktuell, weil der Aufwand dafür nahezu verschwunden ist.

Keiner dieser Schritte ersetzt einen Menschen. Jeder verändert, womit der Mensch seine Zeit verbringt.

Was sich für Sie ändert

Mehr Zeit für die Entscheidungen, die zählen

Teure Fehler in Software sind selten Tippfehler. Es sind falsche Annahmen über das Geschäft, ein Datenmodell, das nicht passt, eine Schnittstelle, die sich anders verhält als dokumentiert. Wenn die mechanische Arbeit schrumpft, fließt mehr Zeit der Senior-Engineers genau in diese Fragen und in das Gespräch mit Ihnen darüber.

Kürzere Feedbackschleifen

Ein funktionierender Prototyp auf echten Daten in den ersten Wochen statt eines Foliensatzes verändert die Qualität der Diskussion. Sie reagieren auf etwas, das man anklicken kann. Missverständnisse zeigen sich, solange ihre Korrektur noch billig ist.

Tests und Dokumentation, die Sie tatsächlich bekommen

In vielen Projekten werden Tests und Dokumentation als Erstes gestrichen, wenn die Deadline näher rückt. Wenn sie wenig kosten, sind sie keine Verhandlungsmasse mehr. Sie erhalten eine Codebasis, die ein anderes Team übernehmen könnte, und das ist der beste Schutz vor Abhängigkeit von einem Anbieter, auch von uns.

Eine andere Wirtschaftlichkeit

Denselben Umfang schneller zu liefern ist ein Teil davon, aber nicht alles. Der größere Effekt: Arbeit, die früher zu teuer war, lohnt sich plötzlich. Eine ordentliche Testsuite für ein Altsystem, bevor man es anfasst, ein vollständig verifiziertes Migrationsskript, ein internes Tool, das einem Team täglich eine Stunde spart. Wir sagen das lieber ehrlich, als einen festen Prozentsatz zu versprechen: Der Gewinn hängt stark von der Art der Arbeit ab und ist dort am größten, wo sie gut spezifiziert und gut getestet ist.

Was sich nicht ändert

AI-native heißt nicht unbeaufsichtigt. Ein paar Regeln gelten in jedem unserer Projekte:

1. Für jede Änderung ist ein Mensch verantwortlich. Mit KI geschriebener Code wird von einem Engineer geprüft, der ihn versteht und dafür geradesteht, genau wie handgeschriebener Code.
2. Architektur ist eine menschliche Entscheidung. Modelle schlagen gut Optionen vor und tragen schlecht Abwägungen, die von Ihrem Geschäft, Ihrem Team und Ihrem Budget abhängen.
3. Sicherheit und Datenschutz werden nicht delegiert. Secrets, Zugangsdaten und personenbezogene Daten gehören nicht in Prompts. Code für Authentifizierung, Zahlungen oder personenbezogene Daten erhält zusätzliches menschliches Review.
4. Was wir bauen, gehört Ihnen. Code, Infrastrukturdefinitionen, Prompts und Evaluationssets sind Ihr Eigentum.

Fragen an jeden Anbieter

Wenn Sie Softwarehäuser vergleichen, trennen diese Fragen Marketing von Praxis:

• Welche Schritte Ihres Prozesses nutzen KI, und wer prüft das Ergebnis bei jedem Schritt?
• Wie verhindern Sie, dass unser Code oder unsere Daten zum Training fremder Modelle verwendet werden?
• Was passiert mit der Qualität, wenn ein Modell falsch liegt? Zeigen Sie mir, wie Review und Tests das abfangen.
• Bekommen wir Tests, Dokumentation und Infrastructure as Code, nicht nur die Anwendung?
• Wie gehen Sie mit Lizenzen und der Herkunft generierten Codes um?

Gute Antworten sind konkret und ein wenig langweilig. Vage Versprechen von „10-facher Produktivität“ sind ein Warnsignal.

Wie wir arbeiten

Bei em27code ist KI Teil jeder Phase der Lieferung, vom Lesen Ihrer bestehenden Systeme bis zum Review jedes Pull Requests, und Senior-Engineers bleiben für jede Entscheidung und jede ausgelieferte Zeile verantwortlich. Den ganzen Prozess beschreiben wir auf der Seite Arbeitsweise, und wenn Ihr Produkt selbst KI-Funktionen braucht, baut unser KI- und LLM-Team auch diese. Wenn Sie sehen möchten, wie das in Ihrem Projekt aussähe, schicken Sie uns ein kurzes Briefing.