Power Query mit GitHub Copilot

Ein Erfahrungsbericht

Agentische Entwicklung hält auch im BI-Umfeld langsam aber sicher Einzug. Microsoft Power BI ist mit dem Power BI Modeling MCP Server zwar gut positioniert, doch nicht jede Aufgabe muss zwingend über diesen Weg gelöst werden. Dieser Erfahrungsbericht zeigt, dass sich Anpassungen an einem Power-BI-Semantikmodell heute auch direkt auf Datei-Ebene mit GitHub Copilot effizient vorbereiten und umsetzen lassen.

Ausgangslage

Ich war mit der Aufgabe betraut, unser internes Demo-Semantikmodell an den letzten Stand unserer Entwicklungsleitlinien für Power BI anzupassen, die Teil des Power BI Starter Pakets sind. Im Zentrum stand dabei nicht die fachliche Neugestaltung des Modells, sondern die Frage, wie sich bestehender Power-Query-Code systematisch analysieren, vereinfachen und auf bessere Wartbarkeit sowie Performance ausrichten lässt.

Rahmenbedingungen

Die Arbeiten erfolgten auf Basis eines .pbip-Projekts direkt auf Datei-Ebene in VS Code mit GitHub Copilot. Verwendet wurde das Modell GPT-5.4 Medium im agentischen Modus. Microsoft stellt mit dem Power BI Modeling MCP Server ein hervorragendes Tool zur Verfügung, um Änderungen an Semantikmodellen vorzunehmen. Allerdings sind alle Tabellen, die aus Power Query nicht ins Semantikmodell geladen werden, in der expressions.tmdl definiert und dieser Code ist eben gerade nicht zugänglich über den Modeling MCP Server. Da in unserem Fall viel der Logik genau dort verbaut war, blieb einzig der Weg, alle Analysen und Anpassungen durch den Agenten direkt auf den .tmdl-Dateien durchführen zu lassen. Versionierung über Git war dabei eine wichtige Voraussetzung, um Änderungen nachvollziehen und im Zweifelsfall rückgängig machen zu können.

Vorgehen mit GitHub Copilot

Der erste Schritt bestand darin, die relevanten M-Skripte in den Tabellen- Partitionen und der expressions.tmdl-Datei im Semantic Model systematisch zu identifizieren. Darauf aufbauend wurde der bestehende Code analysiert, um wiederkehrende Muster, unnötige Komplexität und mögliche Schwachstellen im Ladeprozess sichtbar zu machen. Anschliessend half GitHub Copilot dabei, aus diesen Beobachtungen konkrete Optimierungsziele abzuleiten und in einen strukturierten Arbeitsplan zu überführen.

Das Optimierungsziel war dabei mitnichten von vornherein klar. Auf was sollten wir optimieren? Möglichst wenige Schritte? Optimale Performance? Oder möglichst konsequente Einhaltung einer bestimmten Lade-Systematik? Mit dem Agenten einigte ich mich nach einer eingehenden Abwägung auf folgende Punkte:

• Reduzieren von Doppelspurigkeiten: Transformationen sollen nach Möglichkeit nur einmal durchgeführt werden. Dies hilft sowohl Performance als auf der Lesbarkeit des Codes.
• Standardisierung: z.B. beim Laden aus der Quelle durch folgenden Code-Block:
  let
src_Item = "Product",
Source = Sql.Database(src_Server, src_Database),
Entity = Source{[Schema=src_Schema,Item=src_Item]}[Data]
in
Entity
  Auch dies ein Pattern, welches Lesbarkeit und Wartbarkeit erhöht.
  Ausserdem sollte ein Augenmerk darauf gelegt werden, möglichst viele initiale Transformationsschritte foldable zu machen, so dass sie – prinzipiell – direkt auf die SQL-Quelle durchgereicht werden könnten.
• Layering: klare Aufteilung der Queries in Source, Intermediaryund Target (mit entsprechenden Query Groups), ein wenig analog einer Mini-«Medallion»-Architektur

Nachdem wir uns auch über Namenskonventionen einig geworden waren, wurden abschliessend die vorgeschlagenen Anpassungen umgesetzt und laufend überprüft. Besonders hilfreich war dabei, dass Copilot nicht nur einzelne Codeblöcke erklären oder anpassen konnte, sondern den gesamten Arbeitsablauf von der Analyse bis zur Umsetzung mittrug. Dadurch entstand nicht bloss eine Sammlung technischer Hinweise, sondern ein nachvollziehbarer und priorisierter Verbesserungsprozess.

Erkenntnisse aus der Praxis

Aus fachlicher Sicht zeigte sich schnell, dass die grössten Optimierungspotenziale nicht in den Dimensionen, sondern im Aufbau der Fact-Loads lagen. Insbesondere die Logik zur Generierung der Surrogate Keys wurden in eigene Queries ausgelagert, und zwar möglichst schmal (im Wesentlichen nur ein Mapping Business Key auf Surrogate Key) und möglichst «quellnah» und «foldable». GitHub Copilot war besonders stark darin, die Optimierungs-Möglichkeiten rasch zu identifizieren und die Lösungsmuster konsequent umzusetzen.

Dabei war ich erstaunt, dass für alle von Copilot vorgenommenen Änderungen an den .tmdl-Dateien kein einziges Mal ein Fehler auftrat, wenn man diese neue Version danach in Power BI Desktop zur Überprüfung öffnete. Dies demonstriert, wie zuverlässig die neuesten LLMs Code ausgeben und ihre eigenen Ausgaben dann als Teil der agentischen Implementierung auch selbst zu überprüfen imstande sind. In der Endkontrolle auf den Dateninhalten präsentierte sich das Resultat im wesentlichen fehlerfrei, was umso erstaunlicher ist in Anbetracht der Tatsache, dass alle Änderungen nur auf Ebene der reinen Queries / Metadaten erfolgt waren!

Gleichzeitig wurde aber auch klar, wo die Grenzen liegen. Ob veraltete Tabellen tatsächlich entfernt werden können, welche Logik besser auf SQL-Ebene aufgehoben ist und welche fachlichen Änderungen angestrebt werden sollen, bleibt eine Aufgabe für erfahrene Entwicklerinnen und Entwickler. Copilot beschleunigt die Analyse und Strukturierung erheblich, ersetzt aber die fachliche Validierung nicht.

Fazit

Für mich war diese Arbeit ein überzeugendes Beispiel dafür, dass agentische Entwicklung auch im Power-BI-Umfeld einen praktischen Mehrwert liefern kann. Gerade bei bestehenden Semantic-Model-Projekten mit vielen M-Ausdrücken und TMDL-Dateien kann GitHub Copilot helfen, sich schneller zu orientieren, Optimierungspotenziale zu identifizieren und Änderungen strukturiert vorzubereiten.

Zusammengefasst nehme ich vor allem vier Punkte mit:

1. . GitHub Copilot eignet sich gut für die systematische Analyse bestehender Power-Query- und TMDL-Strukturen.
2. Die Arbeit direkt auf Datei-Ebene ist in einem sauberen .pbip-Setup praxistauglich und effizient. Komplementär dazu bietet Git ein Sicherheitsnetz und erleichtert die Nachvollziehbarkeit.
3. Der grösste Nutzen liegt in der Beschleunigung von Analyse, Strukturierung und Umsetzungsvorbereitung.
4. Fachliche Verantwortung, Testing und die abschliessende Bewertung der Änderungen bleiben klar beim Entwicklungsteam.

Falls Sie mehr zum Thema „KI-unterstützte BI Entwicklung“ erfahren wollen, zögern Sie nicht, uns zu kontaktieren.