Die Zukunft der Analysetechnik

Für Analytics Engineers ist SQL der sichtbarste Teil ihrer Arbeit. Es ist das, was übertragen, überprüft und getadelt wird, wenn Pipelines zusammenbrechen. Aber die wahre Kunst liegt unter der Oberfläche.

Letztes Jahr habe ich eine Sitzung zum Wissensaustausch bei Xebia mit einer Frage eröffnet: "Wie oft ist es Ihnen schon schwergefallen, anderen zu erklären, was Sie beruflich tun?" Der Saal lachte, denn jeder hatte es schon einmal erlebt. Wenn Sie im Bereich Analytics Engineering arbeiten, kennen Sie die Antwort, nach der die Leute greifen: "Ich bin die Brücke zwischen der Datentechnik und dem Geschäft". Das ist wahr. Und sie sagt auch fast nichts darüber aus, was der Job eigentlich beinhaltet.

In Wirklichkeit geht es um das Systemdesign. Namenskonventionen. Release-Kadenzen. Entscheidungen darüber, wer für was verantwortlich ist. Datenmodelle, die modular, wiederverwendbar und zuverlässig sind und die sich ändern lassen, ohne kaputt zu gehen. Die Architektur- und Designprinzipien, die erforderlich sind, um Daten zu erzeugen, auf die sich das Unternehmen verlassen und mit denen es handeln kann. Das war schon immer die schärfste Kante der Rolle des Analytics Engineering. Bei SQL ging es darum, wie Sie diese Entscheidungen in Code ausdrücken. Es war nie die Entscheidung selbst.

Das Werkzeug, das die Rolle prägte

Im Jahr 2019 gab ein Beitrag auf Locally Optimistic der Rolle einen Namen: Analytics Engineer. Die dbt-Gemeinschaft übernahm den Begriff und machte ihn zum Vokabular des modernen Datenstapels und stellte SQL als erstklassigen Bürger der Transformationspipelines in den Vordergrund. Das war eine gute Sache. SQL wurde zu einer gemeinsamen Sprache der Datenteams. Die Transformationslogik wurde aus verstreuten Skripten in versionskontrollierte Repositories mit Tests, Dokumentation und Review Gates verlagert.

Aber es hat auch die Rolle erweitert. AEs übernahmen die gesamte Wertschöpfungskette: Aufnahme, Umwandlung, Bereitstellung, Dashboards, Datenerzählung. Umfassende Fähigkeiten, hohe Ausführungslast. Die tiefgreifende architektonische Arbeit war zwar immer noch vorhanden, aber sie musste mit den täglichen Ausführungsanforderungen um Zeit und Aufmerksamkeit konkurrieren.

Als Berater hatte ich einen Vorteil: Ich landete in Teams mit kritischen Augen. Meistens ging es bei den von mir vorgeschlagenen Änderungen gar nicht um SQL. Es ging um den Prozess. "Wie soll unsere Namenskonvention aussehen?" "Wie sollen wir für die Produktion freigeben, in welchem Rhythmus und wer ist dafür verantwortlich?" Diese Prozesse sind das Rückgrat für wiederholbare Ergebnisse. Ich habe gesehen, wie sie Teams von der Brandbekämpfung zur proaktiven Ausführung gebracht haben, und zwar wiederholt, über verschiedene Kunden und Stacks hinweg.

Dieser Instinkt, den Standard zu kodieren und ihn in großem Umfang durchzusetzen, ist genau das, was dbt erfolgreich gemacht hat. Und es ist genau das, worauf die nächste Veränderung im Analytics Engineering aufbaut.

Das erste Mal, dass ich Claude Code verwendet habe

Ich habe schon seit einiger Zeit Agentic Coding in meiner IDE verwendet. Ich begann mit Cline auf VSCode, hatte mein Regelwerk, aber es war ein sehr komplexer und geführter Prozess. Ich war immer noch derjenige, der den Code schrieb. Der Agent half mir bei den Aufgaben und der Überprüfung. Es war wie ein offenes Gespräch, das im Rahmen einer Datei, die geändert wurde, ganz natürlich ablief.

Wenn Sie mit einem Team von Agenten zur agentenbasierten Codierung übergehen, ändern sich die Dinge schnell. Sie ändern das gesamte Repository und berühren viele Dateien auf einmal. Sie haben keine Zeit, die IDE zu öffnen und jede einzelne Änderung zu überprüfen. Sie müssen sehr genau darauf achten, was das Team tut, falsche Annahmen aufdecken, Kontext liefern und die Richtung vorgeben. Die Dynamik ist ganz anders.

Wenn Sie Agentenprogrammierung auf die gleiche Weise versuchen wie ein Tool wie ChatGPT, werden Sie sehr schnell überfordert sein. Generische Eingabeaufforderungen, unscheinbare Kontextfenster und Anfängerfehler wie die Tatsache, dass Sie Ihre Absichten vor einem Verdichtungsereignis nicht dokumentieren, nehmen Ihren Agenten den Speicher, der ihnen zur Verfügung steht, was durch die Anzahl der parallel laufenden Agenten noch verstärkt wird. Ich habe all diese Fehler gemacht.

Was mich die Arbeit mit einem echten Team gelehrt hat

Die Veränderung, die alles veränderte, war einfach: Ich hörte auf, sie wie eine bessere Autovervollständigung zu behandeln und begann, sie wie ein Team zu behandeln.

Das bedeutete, dass ich die gleichen Werkzeuge anwenden musste, die ich bereits aus der Arbeit mit menschlichen Teams kannte. Planung, Verfeinerung und Dokumentation. Architektur-Entscheidungsprotokolle, die vor einer einzigen Code-Zeile geschrieben wurden. Geschäftsanforderungen, die gesammelt und in atomare, in sich geschlossene, gut eingegrenzte Tickets übersetzt werden. Agile Techniken, die genau deshalb existieren, weil es schwierig ist, Software mit anderen Menschen zu entwickeln.

Bevor Sie mit dem Programmieren beginnen, müssen viele Dinge geschehen. Dieser Satz klingt offensichtlich. In der Praxis ist es am schwierigsten, diese Disziplin aufrechtzuerhalten, wenn der Agent da sitzt, bereit zum Loslegen, und die Versuchung groß ist, einfach loszulegen.

Was mich am meisten überrascht hat, war der Umfang der Produktion. Das Agententeam war schnell. Der Code stapelte sich. Es war nicht mehr möglich, alles zu überprüfen. Also tat ich, was jeder Teamleiter tut, wenn die Qualität des Outputs nachlässt: Ich führte Retrospektiven ein.

"Was ist schief gelaufen und wie können wir es besser machen?" Gehen Sie dieser Frage in jedem Zyklus nach, beheben Sie die festgestellten Probleme und machen Sie weiter. Die Qualität der Ergebnisse verbesserte sich erheblich. In Kombination mit TDD (Schreiben von Tests, bevor der Code existierte), CI/CD-Zyklen und kontradiktorischen Code-Reviews, die ausdrücklich angewiesen waren, brutal ehrlich zu sein, entdeckte das Team echte Fehler, die ich selbst nie gefunden hätte.

Wenn Sie ein Agententeam als Gedankendump verwenden, erhalten Sie einen schönen Konzeptnachweis. Wenn Sie produktionsreifen Code wollen, müssen Sie produktionsreife Frameworks auf Ihre Arbeit anwenden. Die gleichen Frameworks, die Softwareentwicklungsteams seit dreißig bis vierzig Jahren verfeinern.

Kodierung des Standards

Ich ertappte mich dabei, wie ich zu Beginn jeder Sitzung die gleichen Anweisungen wiederholte. "Denken Sie daran, TDD zu verwenden. Befolgen Sie die besten DevOps-Praktiken. Schreiben Sie die ADR vor der Implementierung." Dieselbe Einweisung, Sitzung für Sitzung, verschiedene Modelle, verschiedene Kontexte.

Das ist nicht nachhaltig. Und es ist auch ein Muster, das ich erkannt habe. Es ist genau das, was passiert, wenn ein Team wächst und der leitende Ingenieur, der alle Standards im Kopf hat, in den Urlaub fährt. Die Dinge driften ab.

Die Lösung ist dieselbe, die dbt für SQL gefunden hat: kodieren Sie den Standard, nicht die Erinnerung. Ich habe eine Arbeitsweise-Fähigkeit entwickelt, die beim Start einer Aufgabe ausgelöst wird. Eine Reihe von Hard Gates wird erzwungen. TDD, kontradiktorische Überprüfung, Architekturdokumentation, phasenweise Lieferung, Retrospektiven. Die Agenten folgen den vereinbarten Mustern konsequent über alle Sitzungen und Modelle hinweg. Ich wiederhole mich nicht. Die Arbeit kann in einer völlig neuen Sitzung fortgesetzt werden, ohne dass die Qualität oder die Richtung verloren geht.

Diese Fähigkeit ist die natürliche Erweiterung des AE-Instinkts. Den Konventionen, die Sie in Ihrer dbt-Projektstruktur kodiert haben, war es egal, welcher Analyst das Modell geschrieben hat. Die Fähigkeit kümmert sich nicht darum, welches Modell die Sitzung durchführt.

Die Barriere, die es nicht mehr gibt

Hier ist ein Detail, das es wert ist, direkt genannt zu werden. Vor einiger Zeit musste ich eine Dokumentationsplattform für dbt erstellen: eine einseitige Anwendung mit Navigation, Lineage-Exploration und Health-Dashboards, erstellt in React und TypeScript. Das Problem war, dass ich so gut wie keine TypeScript-Erfahrung hatte. Die Aufgabe erforderte Fähigkeiten, über die ich nicht verfügte.

Mein Agententeam hat das getan. Sie haben das TypeScript geschrieben, bei jeder Gelegenheit Leitplanken und bewährte Praktiken der Branche angewendet und den Code unter Kontrolle gehalten. Ich musste nicht jeden Typ validieren oder jedem Semikolon hinterherlaufen. Ich arbeite jetzt an einem separaten Tool, das in Rust entwickelt wurde. Dieselbe Situation. Ich habe so gut wie keine Erfahrung in dieser Sprache.

Was ich habe, ist ein Verständnis dafür, wie Programmierung funktioniert: die Muster und Frameworks, die zuverlässigen, testbaren und wartbaren Code erzeugen. Das architektonische Gespür, das ich bei der Arbeit mit Python und SQL entwickelt habe, lässt sich übertragen. Aber ich werde nicht behaupten, dass Wissen allein ausreicht. Die andere Hälfte ist zu wissen, was man nicht weiß.

Wenn ich auf eine Entscheidung stoße, die ich nicht nach den ersten Prinzipien treffen kann, bitte ich die Agenten, die Recherche zu übernehmen: Schlagen Sie den Industriestandard vor, bewerten Sie, was für den Anwendungsfall geeignet ist, und schreiben Sie ein ADR, das die Wahl und die dahinter stehenden Überlegungen dokumentiert. Das ist kein Workaround. Das ist genau das, was ein guter technischer Leiter mit einem Team macht, das über tiefere Fachkenntnisse in einem bestimmten Bereich verfügt.

Die Sprachbarriere war die letzte Ausführungsabhängigkeit, die die AE-Rolle mit sich brachte. Die agentenbasierte Kodierung hat sie beseitigt. Was bleibt, ist das Urteilsvermögen: zu wissen, welche Entscheidungen Sie treffen müssen und welche delegiert werden können.

Was aus der Rolle wird

Wenn die Ausführungsebene delegiert wird, kann der Analytics Engineer mit voller Tiefe arbeiten. Ich kann mit einem Kunden in Echtzeit über Ideen für das Datenmodell iterieren, die Daten simulieren, um die Auswirkungen auf das Geschäft zu zeigen, und automatisierte Diagramme und Dokumentationen haben, die mit den Änderungen Schritt halten. Arbeit, die früher Monate dauerte, kann in wenigen Wochen erledigt werden, und zwar mit einer Lösung, die das Problem tatsächlich löst und nicht das Problem, wie es vor sechs Monaten verstanden wurde.

Die menschliche Schnittstelle, das Sammeln von Anforderungen, die Iteration mit dem Unternehmen, die Übersetzung zwischen dem, was die Daten sagen können und dem, was das Unternehmen hören muss, wird zur Hauptarbeit. Die schwierigsten Probleme, endlich ohne die Warteschlange.

Der Wandel ist bereits im Gange

Experimentieren Sie mit agentenbasierter Programmierung, haben aber das Gefühl, dass Sie nicht mehr so viel programmieren? Wenn es Ihnen Spaß macht, mit Ihrem agentenbasierten Team über Ziele und Projekte zu sprechen, bedeutet dies, dass Sie den Wechsel zum agentenbasierten Analytik-Engineering bereits vollzogen haben.

Wenn Sie es noch nicht ausprobiert haben, ein Wort der Warnung. Es kann süchtig machen, wie schnell und wie gut Sie etwas liefern können, das eine Frage beantwortet, die ein paar Minuten zuvor nur eine Idee in Ihrem Kopf war.

Die Zukunft von Analytics Engineering ist keine Vorhersage. Für einige von uns ist es bereits Dienstag.

(Natürlich erfordert die Übergabe der Ausführung an autonome Agenten ernsthafte Leitplanken, um sicher und effektiv zu sein. In meinem nächsten Beitrag erzähle ich Ihnen, wie ich eine Sicherheits-Basislinie und Challenge-Protokolle erstellt habe, um agentische Workflows für den täglichen Dauereinsatz zu härten).