Schneller, ohne Abkürzungen

Was schneller heißt und was nicht

Die meisten Softwareprojekte sind nicht langsam, weil Menschen langsam tippen. Sie sind langsam, weil gewartet wird: auf eine Entscheidung, auf ein Review, darauf, dass ein Fehler gefunden und behoben wird, der schon letzten Monat hätte auffallen sollen. Sie sind langsam, weil erfahrene Ingenieure Tage mit Standardcode verbringen, den auch ein Berufsanfänger schreiben könnte, während die schweren Fragen auf sie warten.

Wenn wir also schneller sagen, meinen wir weniger Warten und weniger Nacharbeit. Wir meinen nicht weniger Tests, weniger Reviews oder dünnere Dokumentation. Genau das macht ein Projekt später langsam, meist nach dem Start, wenn die Behebung eines Problems am meisten stört.

Hier finden Sie kein Versprechen, dass ein Projekt nur einen Bruchteil der üblichen Zeit braucht. Jedes Projekt ist anders, und eine solche Zahl sagt Ihnen nichts über Ihres. Was wir beschreiben können, ist, wie die Arbeit organisiert und wie sie geprüft wird, damit Sie selbst urteilen können, und an den Meilensteinen in Ihrem eigenen Zeitplan werden Sie es sehen.

Agenten legen das Fundament, Ingenieure steuern

Jedes Projekt hat einen großen Anteil Arbeit, die nötig, aber nicht neu ist: das Projektgerüst, die Standardseiten und Formulare, die Schnittstellen zwischen den Teilen, der Code, der Datensätze liest und schreibt, die Anbindungen an gut dokumentierte Dienste und die Testsuiten, die all das abdecken. Sie muss gut gemacht werden, braucht aber nicht Zeile für Zeile das Urteil eines erfahrenen Ingenieurs.

In unserem agentischen Entwicklungsablauf bauen KI-Agenten dieses Fundament. Sie arbeiten nach einer Spezifikation, die unsere Ingenieure schreiben, innerhalb der Struktur, die unsere Architekten festlegen, und jede Änderung wird von einem Ingenieur geprüft, bevor sie zusammengeführt wird. Die Agenten entscheiden nicht, was gebaut wird, wie das System aufgebaut ist oder ob eine Änderung akzeptabel ist. Das entscheiden Menschen.

• Gerüst: Projektstruktur, Konfiguration, Build- und Deployment-Pipelines, Umgebungen.
• Schnittstellen: die typisierten Verträge zwischen Frontend, Backend und externen Diensten, zuerst geschrieben, damit sich alle Teile darauf einigen.
• Standardfunktionen: Formulare, Listen, Detailseiten, Einstellungen, Datensätze, die angelegt, gelesen, geändert und gelöscht werden.
• Anbindungen an gut dokumentierte Dienste, hinter Schnittstellen, die unsere Ingenieure festlegen.
• Testsuiten: Unit- und Integrationstests für all das, zusammen mit dem Code geschrieben statt danach.
• Erste Fassungen der technischen Dokumentation, die Ingenieure dann korrigieren und vervollständigen.

Es beginnt mit der Spezifikation

Gesteuerte Agenten sind nur so gut wie ihre Anweisungen. Bevor die Arbeit am Fundament beginnt, schreiben unsere Ingenieure auf, was jeder Teil tun muss: welche Daten er hält, welche Schnittstelle er anbietet, welche Regeln er durchsetzt, welche Fehler er zurückgibt und welche Tests das belegen. Diese Spezifikation ist dasselbe Dokument, das ein menschliches Team bräuchte, und sie wird Teil der Übergabe.

Sie zuerst zu schreiben, hat einen Nutzen über die Agenten hinaus. Unklarheiten in Ihren Anforderungen zeigen sich in den ersten Wochen, als Fragen, die wir Ihnen stellen, statt Monate später als Funktionen, die funktionieren, aber das Falsche tun.

Was unsere erfahrenen Ingenieure behalten

Das Fundament an gesteuerte Agenten zu geben, heißt nicht, weniger Ingenieursarbeit zu leisten. Es heißt, die erfahrensten Leute über mehr vom Projekt dorthin zu setzen, wo ihr Urteil am meisten zählt.

Für Sie heißt das: Die Leute mit der meisten Erfahrung verbringen ihre Woche nicht mit Formularvalidierung. Sie denken darüber nach, wie Ihre Daten geschützt sind, was passiert, wenn zwei Personen denselben Datensatz bearbeiten, wie sich das System verhält, wenn ein Drittanbieterdienst ausfällt, und ob das Produkt tut, was Ihre Nutzer brauchen.

Erst die Tests, und Tests der Tests

Code, der schnell entsteht, muss gründlich geprüft werden, und eine Testsuite nützt nur, wenn sie Fehler tatsächlich findet. Eine Suite kann jede Codezeile ausführen und trotzdem nichts prüfen, was zählt. Also testen wir unsere Tests.

Mutationstests sind der Weg dazu. Ein Werkzeug baut absichtlich kleine Fehler in den Code ein, einen nach dem anderen, und lässt die Tests gegen jede geänderte Fassung laufen. Schlagen die Tests fehl, wurde der Fehler gefunden; bestehen sie, haben die Tests eine Lücke ^[1]. Wir setzen Mutationstests auf den Code an, auf den es am meisten ankommt: Berechtigungen, Geld, Datenintegrität und alles, wonach eine Aufsicht oder ein Prüfer fragen würde.

• Unit-Tests für Logik, Integrationstests für das Zusammenspiel der Teile und End-to-End-Tests für die Wege, die Ihre Nutzer gehen.
• Tests gegen eine echte Datenbank, jedes Mal aus den Migrationen neu aufgebaut, nicht gegen einen vereinfachten Ersatz.
• Mutationstests für kritischen Code, wobei überlebende Mutanten als Mängel in den Tests gelten.
• Fuzzing und eigenschaftsbasierte Tests, wo Eingaben von außen kommen: Uploads, Importe, öffentliche APIs und Smart Contracts.

Reviews auf jeder Ebene

Das Secure Software Development Framework des NIST hält fest, dass sichere Entwicklungspraktiken einem Team meist bewusst hinzugefügt werden müssen, um Schwachstellen in ausgelieferter Software zu verringern und ihre Ursachen anzugehen ^[2]. Reviews sind dafür unser wichtigstes Mittel, auf drei Ebenen.

1. 01

   Jede Änderung

   Ein Ingenieur prüft jede Änderung, bevor sie zusammengeführt wird, egal ob ein Mensch oder ein Agent sie geschrieben hat. Er prüft, dass sie tut, was die Spezifikation sagt, dass sie getestet ist und dass sie nichts in ihrer Umgebung schwächt.

2. 02

   Jeder Meilenstein

   Bevor ein Meilenstein Sie erreicht, wird er als Ganzes auf einer Staging-Umgebung getestet: die Funktionen, die Randfälle und die Wege von Anfang bis Ende.

3. 03

   Jede Phase

   Am Ende jeder Phase führen wir einen vollständigen Satz gegnerischer Reviews durch: Menschen, die gezielt versuchen, Sicherheit, Berechtigungen, Datenverarbeitung und Annahmen zu brechen. Befunde werden behoben, bevor die nächste Phase beginnt.

Bei Webanwendungen prüfen wir die Sicherheit gegen einen veröffentlichten Standard. Der OWASP Application Security Verification Standard ist eine Liste von Anforderungen zum Testen der Sicherheitskontrollen einer Web-App ^[3], und er gibt beiden Seiten eine gemeinsame Sprache dafür, was geprüft wurde und was nicht.

Prüfungen, die Sie sehen können

Nichts davon sollten Sie uns einfach glauben müssen. In unseren Projekten sind die Nachweise Teil der Lieferung.

• Jede Änderung durchläuft automatisch die vollständige Testsuite, bevor sie zusammengeführt werden kann, und Sie sehen die Ergebnisse.
• Jeder Meilenstein wird auf einer Staging-Umgebung vorgeführt, die Sie selbst nutzen können, bevor Sie ihn abnehmen.
• Review-Befunde und ihre Lösung werden festgehalten, sodass ein Prüfer oder Ihr eigenes Team sie nachvollziehen kann.
• Code, Tests und Verlauf liegen ab der ersten Woche in einem Repository auf Ihren Namen.

Wo wir absichtlich langsamer werden

Manche Arbeit sollte nie überstürzt werden, und wir versuchen es auch nicht. Eine Datenmigration aus Ihrem alten System wird an einer Kopie geprobt, bevor sie das Original berührt. Ein Smart Contract, der Werte halten wird, wird eingefroren, geprüft und, wo es angebracht ist, vor dem Deployment extern auditiert, weil er danach nicht still nachgebessert werden kann. Ein Modell, das Ihren Kunden antwortet, wird vor jeder Änderung an einem Prüfsatz gemessen. Berechtigungen und Zahlungen bekommen einen zweiten Prüfer.

Schnell beim Fundament zu sein, schafft den Raum, hier sorgfältig zu sein. Dieser Tausch ist der ganze Sinn des Ablaufs.

Was das für Sie bedeutet

• Funktionierende Software früher. Das Fundament steht schnell, also sehen Sie früher echte Seiten und echte Daten und können umsteuern, solange es noch leicht ist.
• Mehr erfahrene Aufmerksamkeit für das Wichtige. Architektur, Sicherheit und Kernlogik Ihres Projekts bekommen mehr Zeit unserer erfahrensten Leute.
• Weniger Überraschungen nach dem Start. Getestete Tests und Phasen-Reviews finden Probleme, solange sie noch leicht zu beheben sind.
• Eine Codebasis, die ein anderes Team übernehmen kann. Einheitliche Struktur, typisierte Schnittstellen und gründliche Tests machen die Übergabe einfach.

Nichts davon ändert, wer verantwortlich ist. Unsere Ingenieure stehen für jede ausgelieferte Zeile ein, egal wie sie zuerst geschrieben wurde.

Fragen an jedes Studio zu KI in seinem Ablauf

1. 01

   Wer prüft von KI geschriebenen Code?

   Jede Änderung sollte von einem Ingenieur geprüft werden, bevor sie zusammengeführt wird. Fragen Sie, wie das durchgesetzt wird.

2. 02

   Was wird nie abgegeben?

   Sicherheit, Zahlungen, Datenmodelle und alles andere Kritische sollten bei erfahrenen Leuten bleiben. Fragen Sie nach der Liste.

3. 03

   Wohin gehen mein Code und meine Daten?

   Fragen Sie, welche Werkzeuge Ihren Code sehen, zu welchen Bedingungen, und ob etwas gespeichert oder zum Training genutzt wird.

4. 04

   Woher wissen Sie, dass die Tests funktionieren?

   Abdeckung allein ist keine Antwort. Mutationstests oder etwas Vergleichbares sind es.

5. 05

   Was bekomme ich zu sehen?

   Testergebnisse, Review-Aufzeichnungen und eine Staging-Umgebung sind vernünftige Erwartungen.