In der Reihe „Creator Highlight“ unterhalten sich TDS-Redakteure mit Mitgliedern unserer Group über ihren Karriereweg in den Bereichen Datenwissenschaft und KI, ihr Schreiben und ihre Inspirationsquellen. Heute freuen wir uns, unser Gespräch mit Ihnen zu teilen Mike Hüls.
Mike ist ein technischer Leiter, der an der Schnittstelle von Datentechnik, KI und Architektur arbeitet und Unternehmen dabei hilft, komplexe Datenlandschaften in zuverlässige, nutzbare Systeme umzuwandeln. Mit einem starken Full-Stack-Hintergrund entwirft er Finish-to-Finish-Lösungen, die technische Tiefe mit geschäftlichem Nutzen in Einklang bringen. Neben der Kundenarbeit entwickelt und teilt er praktische Instruments und Erkenntnisse zu Datenplattformen, KI-Systemen und skalierbaren Architekturen.
Sehen Sie sich als Full-Stack-Entwickler? Wie verändert Ihre Erfahrung im gesamten Stack (vom Frontend bis zur Datenbank) Ihre Sicht auf die Rolle des Datenwissenschaftlers?
Das tue ich, aber nicht in dem Sinne, dass ich jede Schicht persönlich aufbaue. Für mich bedeutet Full-Stack zu verstehen, wie Architekturentscheidungen auf einer Ebene das Systemverhalten, das Risiko und die Kosten im Laufe der Zeit beeinflussen. Diese Perspektive ist bei der Gestaltung von Systemen, die Veränderungen überstehen müssen, von entscheidender Bedeutung.
Diese Perspektive beeinflusst auch, wie ich die Rolle des Datenwissenschaftlers sehe. In Notebooks erstellte Modelle sind nur der Anfang. Ein echter Wert entsteht, wenn diese Modelle in Produktionssysteme mit geeigneten Datenpipelines, APIs, Governance und benutzerorientierten Schnittstellen eingebettet werden. Die Datenwissenschaft wird wirkungsvoll, wenn sie als zentraler Bestandteil eines größeren Programs und nicht als isolierte Aktivität behandelt wird.
Sie decken ein breites Themenspektrum ab. Wie entscheiden Sie, worauf Sie sich als nächstes konzentrieren möchten, und woher wissen Sie, wann es sich lohnt, ein neues Thema zu erkunden?
Ich neige dazu, wiederkehrenden Reibungen zu folgen. Wenn ich sehe, dass mehrere Groups mit den gleichen Problemen zu kämpfen haben, sei es technischer oder organisatorischer Artwork, werte ich das als Zeichen dafür, dass das Drawback eher struktureller als individueller Natur ist und es sich lohnt, auf Architektur- oder Prozessebene angegangen zu werden.
Ich experimentiere auch bewusst mit neuen Technologien, nicht aus Neuheitsgründen, sondern um ihre Kompromisse zu verstehen. Ein Thema ist es wert, darüber geschrieben zu werden, wenn es entweder ein echtes Drawback löst, mit dem ich derzeit konfrontiert bin, oder Risiken aufdeckt, die noch nicht allgemein verstanden sind. Schließlich schreibe ich über Themen, die ich persönlich interessant und erforschenswert finde, denn anhaltendes Interesse ermöglicht es mir, tiefer einzusteigen.
Sie haben über LangGraph, MCP und selbst gehostete Agenten geschrieben. Was ist Ihrer Meinung nach das größte Missverständnis, das die Menschen heutzutage über KI-Agenten haben?
Agenten sind wirklich mächtig und eröffnen neue Möglichkeiten. Das Missverständnis ist, dass sie einfach sind. Heutzutage ist es einfach, eine Cloud-Infrastruktur aufzubauen, ein Agent-Framework zu verbinden und etwas zu produzieren, das scheinbar funktioniert. Diese Zugänglichkeit ist wertvoll, verbirgt jedoch viel Komplexität.
Sobald Agenten über Demos hinausgehen, kommen die wahren Herausforderungen zum Vorschein. Zustandsverwaltung, Berechtigungen, Kostenkontrolle, Beobachtbarkeit und Fehlerbehandlung werden oft unterschätzt. Ohne klare Grenzen und Eigenverantwortung wird die Arbeit der Agenten unberechenbar, teuer und riskant. Es handelt sich dabei nicht nur um Eingabeaufforderungen mit Werkzeugen; Sie sind langlebige Softwaresysteme und müssen entsprechend entwickelt und betrieben werden.
In Ihrem Artikel über Geschichtete ArchitekturSie erwähnen, dass sich das Hinzufügen von Funktionen oft wie eine „Operation am offenen Herzen“ anfühlen kann. Was ist Ihr wichtigster Rat für einen Anfänger oder ein kleines Datenteam, das dies vermeiden möchte, zum Aufbau einer Architektur?
„Die einzige Konstante ist der Wandel“ ist aus gutem Grund ein Klischee. Optimieren Sie additionally eher für den Wandel als für die anfängliche Liefergeschwindigkeit. Selbst eine minimale Kind des mehrschichtigen Denkens hilft: die Trennung von Domänenlogik, Anwendungsfluss und Infrastrukturbelangen.
Das Ziel ist nicht die architektonische Perfektion vom ersten Tag an oder die perfekte Kategorisierung. Es geht darum, klare Grenzen zu schaffen, die es dem System ermöglichen, sich ohne ständige Neufassungen weiterzuentwickeln. Eine geringe Disziplin im Vorfeld zahlt sich deutlich aus, wenn die Systeme wachsen.
Sie haben einen Benchmark durchgeführt PostgreSQL-Einfügestrategien und stellte fest, dass „schneller nicht immer besser ist.“ In welchem Szenario würden Sie in einer Produktions-ML-Pipeline bewusst eine langsamere und sicherere Einfügemethode wählen?
Wenn Korrektheit, Rückverfolgbarkeit und Wiederherstellbarkeit wichtiger sind als der reine Durchsatz. In vielen Pipelines bietet eine Verkürzung der Laufzeit um einige Sekunden kaum Vorteile im Vergleich zu dem Risiko, das durch schwächere Garantien entsteht.
Beispielsweise profitieren Pipelines, die behördliche Berichte, Finanzentscheidungen oder langlebige Schulungsdatensätze einspeisen, von Transaktionssicherheit und expliziter Validierung. Die stille Datenbeschädigung ist weitaus kostspieliger als das Eingehen bescheidener Leistungseinbußen, insbesondere wenn Daten zu einem langfristigen Vermögenswert werden, auf dem andere aufbauen können.
In deinem Persönliche, vermittlerische Assistenten Artikel, Sie haben eine 100 % personal, selbst gehostete Plattform aufgebaut. Warum struggle es für Sie wichtiger, „Token-Kosten“ und „Datenlecks“ zu vermeiden, als ein leistungsfähigeres, cloudbasiertes LLM zu verwenden?
In meiner täglichen Arbeit habe ich die Erfahrung gemacht, dass Vertrauen in ein System für die Systemeinführung von grundlegender Bedeutung ist. Token-Kosten, undurchsichtige Datenflüsse und externe Abhängigkeiten beeinflussen subtil die Artwork und Weise, wie Systeme genutzt und wahrgenommen werden.
Ich habe mich auch bewusst dafür entschieden, meine persönlichen oder sensiblen Daten nicht über externe Cloud-Anbieter weiterzuleiten, da es nur begrenzte Garantien für den langfristigen Umgang mit Daten gibt. Indem ich das System selbst gehostet halte, könnte ich einen Assistenten entwickeln, der vorhersehbar und überprüfbar ist und den europäischen Datenschutzerwartungen entspricht. Benutzer haben die volle Kontrolle darüber, worauf der Assistent Zugriff hat, und dies senkt die Hürde für die Nutzung des Assistenten.
Schließlich erfordert nicht jeder Anwendungsfall das größte oder teuerste Modell. Durch die Entkopplung des Programs von einem einzigen Anbieter können Benutzer das Modell auswählen, das ihren Anforderungen am besten entspricht und Leistungsfähigkeit, Kosten und Risiko in Einklang bringt.
Wie wird sich Ihrer Meinung nach der Arbeitsalltag eines Datenprofis im Jahr 2026 verändern?
Entgegen verbreiteter Stereotypen sind Daten- und Software program-Engineering äußerst soziale Berufe. Ich bin fest davon überzeugt, dass der wichtigste Teil der Arbeit vor dem Schreiben von Code stattfindet: die Abstimmung mit den Stakeholdern, das Verstehen des Problembereichs und das Entwerfen von Lösungen, die zu vorhandenen Systemen und Groups passen.
Diese Vorarbeit wird noch wichtiger, da die agentengestützte Entwicklung die Implementierung beschleunigt. Ohne klare Ziele, Kontexte und Einschränkungen verstärken Agenten eher die Verwirrung als die Produktivität.
Im Jahr 2026 werden Datenexperten mehr Zeit damit verbringen, Systeme zu gestalten, Grenzen zu definieren, Annahmen zu validieren und verantwortungsvolles Verhalten in Produktionsumgebungen sicherzustellen.
Mit Blick auf den Relaxation des Jahres 2026: Welche großen Themen werden Ihrer Meinung nach das Jahr für Datenprofis bestimmen? Warum?
Generative KI und agentenbasierte Systeme werden weiter wachsen, aber der größere Wandel ist ihre Reifung zu erstklassigen Produktionssystemen und nicht zu Experimenten.
Dieser Übergang hängt von vertrauenswürdigen, qualitativ hochwertigen, zugänglichen Daten und robusten technischen Praktiken ab. Infolgedessen werden Full-Stack-Denken und Design auf Systemebene für Unternehmen, die KI verantwortungsvoll und maßstabsgetreu einsetzen möchten, immer wichtiger.
Um mehr über Mikes Arbeit zu erfahren und über seine neuesten Artikel auf dem Laufenden zu bleiben, können Sie ihm folgen TDS oder LinkedIn.