Wie agentisches Data Engineering unsere Arbeitsweise verändert – und was ein Gesundheitsunternehmen bei der praktischen Umsetzung gelernt hat
von Navdeep Alam und Zhe Sun
Sie kennen das Gefühl. Ihr Team hat eine großartige Idee für eine AI-gestützte Pipeline – vielleicht ein neues Datenprodukt, vielleicht ein Agent, der einen Workflow automatisiert, den niemand manuell erledigen möchte. Der Executive Sponsor ist begeistert. Der Lead Engineer skizziert eine Architektur auf einem Whiteboard. Und dann … vergehen Wochen. Umgebungen müssen bereitgestellt werden. Der Kontext geht zwischen den Teams verloren. Bis der Prototyp fertig ist, hat sich der Executive Sponsor bereits anderen Dingen zugewandt, das Team hat an Schwung verloren und die Initiative schläft still und leise zugunsten von etwas Neuerem ein.
Diese Lücke zwischen „Lass uns das mal ausprobieren“ und einem funktionierenden Prototyp nennen wir die Prototyping-Steuer. Und sie ruiniert mehr AI-Roadmaps, als es jede Modellbeschränkung jemals tun wird.
Der Engpass liegt nicht darin, wie schnell Ihre Engineers Code schreiben – es ist die R&D-Effizienz der gesamten Organisation. Traditionelle R&D ist darauf ausgelegt, von Menschen gesteuert zu werden: Sie hat die Softwareentwicklung im großen Stil ermöglicht, wurde aber nicht für AI-Agenten entwickelt. Drei Faktoren treiben diese Steuer in die Höhe:
Diese Reibungspunkte erklären etwas, das Entwickler ständig berichten: AI-Agenten fühlen sich bei persönlichen Projekten revolutionär an, enttäuschen jedoch bei produktiven Codebases. Der Agent ist nicht dümmer geworden. Die Codebase war einfach nicht darauf ausgelegt, dass er sich darin zurechtfindet.
Das ist die Prototyping-Steuer. Die meisten AI-Roadmaps, die wir sehen, zahlen eine Variante davon. Die Teams, die die Nase vorn haben, sind diejenigen, die herausgefunden haben, wie sie diese Steuer nicht mehr zahlen müssen.
Die Teams, die die Nase vorn haben, nutzen keine besseren Agenten. Sie verschaffen ihren Agenten eine bessere Ausgangsposition: eine, die auf der Geschäftssemantik basiert und nicht nur auf der Syntax. Wenn der Agent diesen Kontext bereits besitzt, verändern sich zwei Dinge bei Ihrer Entwicklung.
Die Absicht wird zur Spezifikation. Eine klare Beschreibung dessen, was Sie wollen, reicht für den Anfang aus. Die alte Übersetzungsebene – auf der Menschen Absichten in technische Anforderungen übersetzten, bevor überhaupt gebaut werden konnte – verschmilzt direkt mit der Build-Session. Governance wird direkt integriert: Lineage, Zugriffskontrollen und Compliance-Vorgaben sind bereits während des Builds aktiv und werden nicht erst im Nachhinein entdeckt, wenn jemand fragt: „Moment, dürfen wir diese Daten überhaupt verwenden?“
Nichts davon ändert, wer die Verantwortung für das Ergebnis trägt. Es ändert nur, wie diese Verantwortung aussieht. Der Entwickler wird vom Autor zum Architekten, Reviewer und Wegweiser: weniger Zeit mit Tippen, mehr mit Entscheiden. Der Agent ist ein Multiplikator für das menschliche Urteilsvermögen, kein Ersatz dafür.
Hier ist die entscheidende Umkehrung: Bei der traditionellen Entwicklung stimmt man sich ab, bevor man baut. Man schreibt eine Spezifikation, verteilt ein Design-Dokument, hält ein Anforderungsmeeting ab – und all das ist nur eine Simulation der Realität. Dann implementiert man, stößt auf unerwartete Probleme, passt den Umfang an, implementiert neu. Wochen vergehen.
Bei der agentischen Entwicklung erfolgt die Abstimmung durch das Bauen selbst. Sie formulieren Ihre Annahmen, der Agent erstellt in wenigen Stunden ein funktionierendes MVP, und die Spezifikation ergibt sich aus dem funktionierenden Code, nicht umgekehrt. Das Design-Dokument wird durch seine Entstehung präzise – weil es auf der Realität basiert, nicht auf der Vorstellungskraft.
Die Anfangsphase verkürzen, die Endphase beibehalten. Der Weg in die Produktion ändert sich nicht – dieselbe CI/CD, dasselbe Code-Review, dieselbe Strenge. Keine Überholspur für AI-generierten Code. Was sich ändert, ist, dass Prototypen die Phase der Konsolidierung und Bereitstellung erreichen, bevor der Schwung verloren geht.
Drei Metriken zeigen Ihnen, ob die Prototyping-Steuer tatsächlich sinkt – oder ob Sie nur einen einzigen guten Workshop hatten.
Was gemessen wird | Metrik | Warum es wichtig ist |
Geschwindigkeit der Verkürzung | Time-to-Prototype – von der Idee zum präsentierbaren MVP | Frühindikator. Wenn sich diese Zeitspanne nicht verkürzt, funktioniert der Kreislauf nicht. |
Qualität der Verkürzung | First-Pass-Akzeptanzrate – % der erfüllten Akzeptanzkriterien ohne Nachbesserungszyklus | Beweist, dass der Agent das Richtige gebaut hat und nicht nur schnell war. |
Nachhaltigkeit des Ergebnisses | PoC-to-Production-Rate – % der Bereitstellungen über CI/CD innerhalb von 90 Tagen | Spätindikator. Beweist, dass Prototypen nicht nur Demos sind, die im Sande verlaufen. |
Erfassen Sie alle drei Metriken pro Team, bestimmen Sie jetzt den Ausgangswert und beobachten Sie den Trend über ein Quartal. Wenn die Time-to-Prototype sinkt, die PoC-to-Production-Rate jedoch nicht folgt, erstellen Sie nur Demos und liefern keine Produkte aus.
Allgemeine Coding-Agenten sind wirklich gut in Syntax, Dateien und APIs. Was sie jedoch nicht kennen, ist Ihr Geschäft – Ihre Schemata und deren Bedeutung, Ihr Governance-Modell, Ihre Deployment-Muster. Also suchen sie mühsam Schritt für Schritt danach, verbrauchen Tokens und Zeit, um den Kontext zu rekonstruieren, den die Plattform eigentlich schon besitzt.
Wir haben Zahlen darüber, wie teuer diese Suche ist. Bei einem Benchmark mit 401 realen Datenaufgaben, erreichte ein plattformnativer Datenagent eine Genauigkeit von 77 % im Vergleich zu 56–72 % bei führenden allgemeinen Coding-Agenten – und das bei etwa der Hälfte der Kosten pro Aufgabe. Der erwartete Kompromiss zwischen Qualität und Kosten blieb einfach aus. Fachwissen zahlt sich gleichzeitig in Genauigkeit, Geschwindigkeit und Kosten aus.
Bei Databricks zeigt sich dies in Form von Genie Code – einem autonomen Datenagenten, der direkt auf Unity Catalog aufbaut – in Kombination mit der Genie Ontology, einer kontrollierten semantischen Ebene, die dem Agenten geschäftliche Bedeutung und nicht nur Spaltennamen vermittelt. Der Agent liest ab, was eine Tabelle bedeutet, anstatt es zu mutmaßen, und übernimmt standardmäßig Ihre Zugriffskontrollen und Governance.
Nirgendwo ist die Ausgangsposition wichtiger als in regulierten Branchen. Wenn Daten sensibel sind und Governance unverzichtbar ist, verschwendet der „Suchen-und-Raten“-Ansatz eines allgemeinen Coding-Agenten nicht nur Zeit – er birgt auch Compliance-Risiken.
Abacus Insights verarbeitet Gesundheitsdaten für über 65 Millionen Mitglieder unter HIPAA-konformen Air-Gap-Kontrollen. Dies ist genau das Umfeld, in dem ein „Suchen-und-Raten“-Ansatz nicht mehr nur Zeit kostet, sondern zum Risiko wird: Der Agent darf nicht einfach so auf PHI zugreifen, er kann das Governance-Modell nicht erraten, und jede falsche Annahme führt zu einer Compliance-Frage statt zu einer schnellen Lösung.
Ihr Team hat Daten-Mapping- und Pipeline-Agenten in die Produktion überführt, wobei Genie Code die tägliche Benutzeroberfläche ist, auf die ihre Engineers zugreifen – weil es ihre Daten bereits versteht und innerhalb ihrer Governance agiert, anstatt dass man ihm alles von Grund auf erklären muss. Und sie verzeichnen bereits erhebliche Effizienzgewinne bei ihrer Data-Intelligence-Arbeit. Der Erfolg zeigt sich in den Zahlen: Das Onboarding neuer Kunden führt jetzt in etwa der Hälfte der Zeit zum ersten Mehrwert, und der manuelle Aufwand für Daten-Mapping und Pipeline-Builds ist um rund 40 % gesunken.
„Unsere Data Engineers arbeiten in enormem Umfang – Milliarden von Abrechnungsdatensätzen im Gesundheitswesen, von denen täglich zig Millionen erfasst werden. Genie Code hat für uns die Spielregeln geändert. Es versteht bereits unsere Schemata, unsere Governance und unsere Air-Gap-Anforderungen. Unsere Engineers verbringen nicht die Hälfte ihrer Zeit damit, einem Tool die Umgebung zu erklären – sie konzentrieren sich auf das eigentliche Problem. 40 % weniger manueller Aufwand ist erst der Anfang. Während wir unsere Bemühungen im Bereich der agentengesteuerten Entwicklung weiter vertiefen, sind wir zuversichtlich, dass sich die Geschwindigkeit, mit der wir neue Kunden zum ersten Mehrwert führen, um ein Vielfaches erhöhen wird.“ - Nav Alam, CTO, Abacus Insights
Die Prototyping-Steuer ist real, sie ist messbar und sie ist optional. Die Teams, die das verstanden haben, warten nicht auf eine Abstimmung, bevor sie bauen – sie stimmen sich durch das Bauen ab und liefern Ergebnisse, bevor der Schwung verloren geht.
(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag
Abonnieren Sie unseren Blog und erhalten Sie die neuesten Beiträge direkt in Ihren Posteingang.