Deitelhoff_Fabian.jpg

Fabian Deitelhoff

arbeitet als IT-Leiter bei Sportnavi.de GmbH. Darüber hinaus ist er Gründer im Bereich der digitalen Bildung. Seine Schwerpunkte sind generative KI, Low- und No-Code sowie die digitale Unterstützung von Lehrenden und Lernenden. Daneben ist er als freier Autor, Dozent und Softwareentwickler im .NET- und Web-Umfeld tätig.

Beiträge von Fabian Deitelhoff

Laufzeitgewinn messen - Schnellere .NET-CI-Pipelines mit Test Sharding, Teil 4
Mehr Shards können das Feedback beschleunigen, aber auch zugleich die CI-Kosten erhöhen. Ein Vergleich mit zwei Referenzläufen zeigt, wo sich zusätzliche Runner lohnen. Ebenso wichtig ist der Nachweis, dass weiterhin alle vorgesehenen Tests laufen.
6 Minuten
GitLab CI mit Testreports einrichten - Schnellere .NET-CI-Pipelines mit Test Sharding, Teil 3
GitLab liefert die Shard-Nummern direkt an Meziantou.ShardedTest. Für aussagekräftige Ergebnisse im Merge Request braucht es zusätzlich passende Reports. Bei Integrationstests entscheidet die Trennung der Testdaten über zuverlässige Parallelläufe.
6 Minuten
GitHub Actions umstellen - Schnellere .NET-CI-Pipelines mit Test Sharding, Teil 2
Eine Jobmatrix bringt die lokale Testaufteilung auf mehrere Runner. Damit daraus ein verlässlicher CI-Lauf entsteht, müssen Shard-Nummern, Fehlerstatus und Ergebnisdateien zusammenpassen. Der Workflow zeigt die nötigen Schritte.
6 Minuten
Tests gezielt verteilen - Schnellere .NET-CI-Pipelines mit Test Sharding, Teil 1
Lange Testsuiten verzögern das Feedback im Pull Request. Meziantou.ShardedTest verteilt die Testfälle auf mehrere CI-Jobs und verspricht dadurch mehr Geschwindigkeit. Dieser Einstieg zeigt, wie die Aufteilung funktioniert und welche Voraussetzungen nötig sind.
6 Minuten
Offen, aber nicht leicht - Kimi K3 – das Modell hinter dem Agenten, Teil 6
Ein offenes Modell lässt sich herunterladen, aber noch lange nicht beiläufig betreiben. Zwischen technischer Kontrolle und praktischem Nutzen zeigt sich, ob Kimi K3 den Sprung vom Benchmark in produktive Anwendungen schafft.
8 Minuten
Vom Sub-Agenten zum Schwarm - Kimi K3 – das Modell hinter dem Agenten, Teil 5
Mehr Agenten versprechen mehr Tempo, vervielfachen aber auch Abstimmung und Risiko. Ob aus paralleler Aktivität tatsächlich Fortschritt entsteht, entscheidet sich dort, wo spektakuläre Schwarmdemos meist enden.
5 Minuten
Sichtkontakt: Coding-Driven Design - Kimi K3 – das Modell hinter dem Agenten, Teil 4
Zwischen fehlerfrei kompiliert und überzeugend gestaltet liegt eine Lücke, die reine Codeanalyse kaum erfasst. Sobald ein Agent seine eigene Oberfläche betrachtet, beginnt eine andere Art der Entwicklung mit neuen Möglichkeiten, aber auch neuen Maßstäben.
5 Minuten
Planen, patchen, prüfen mit Kimi - Kimi K3 – das Modell hinter dem Agenten, Teil 3
Ein starkes Modell allein schreibt noch keinen verlässlichen Code. Erst im Repository zeigt sich, ob aus künstlicher Intelligenz ein brauchbarer Entwicklungspartner entsteht oder aber ein Risiko mit Shell-Zugriff.
5 Minuten
Die Kunst der langen Aufgabenläufe - Kimi K3 – das Modell hinter dem Agenten, Teil 2
Ein guter Code-Generator löst eine klar umrissene Funktion. Ein Coding-Agent muss dagegen ein Repository erkunden, Hypothesen bilden, Werkzeuge auswählen, Tests auswerten und nach Fehlschlägen den Kurs ändern. Kimi K3 zielt auf diese zweite Klasse von Aufgaben.
8 Minuten
Gebaut für lange Läufe - Kimi K3 – das Modell hinter dem Agenten, Teil 1
Kimi K3 kombiniert 2,8 Billionen Parameter, native Bildverarbeitung und ein Kontextfenster mit einer Million Token. Das sind tolle Zahlen. Seine Besonderheit liegt aber darin, dass Architektur, Training und Laufzeitumgebung auf Agenten zielen, die über viele Schritte handeln, Werkzeuge aufrufen und Ergebnisse prüfen.
6 Minuten