Anton Onufriienko, Managing Director bei Devart – Interview-Serie

Anton Onufriienko, Managing Director bei Devart, ist ein Technologie-Executive und -Operator mit umfassender Erfahrung in der Skalierung von Software-Unternehmen, der Steigerung des Umsatzwachstums und der Leitung großer, cross-funktioneller Teams in den Bereichen SaaS, Enterprise-Software und Finanzdienstleistungen. Im Laufe seiner Karriere ist er von der Aufbau von Vertriebsorganisationen und der Gründung von Start-ups zu der Überwachung von vollständigen P&L-Operationen für große Geschäftsbereiche gewachsen, darunter Devarts größter Bereich mit über 130 Mitarbeitern. Vor seiner Ernennung zum Managing Director war er als Chief Revenue Officer und Leiter des Vertriebs bei Devart tätig, wo er die Go-to-Market-Strategie, die Preistransformation und internationale Wachstumsinitiativen leitete. Er ist auch CEO von TMetric, einer Zeitverfolgungs- und Rentabilitätsplattform, die darauf abzielt, serviceorientierte Unternehmen dabei zu unterstützen, operative Klarheit zu gewinnen.

Devart ist ein Software-Unternehmen, das sich auf die Entwicklung von Datenbank-Tools, Daten-Connectivity-Lösungen, Integration und Produktivitäts-Tools für Entwickler, DBAs, Analysten und Enterprise-Teams spezialisiert hat. Gegründet im Jahr 1997, ist das Unternehmen vor allem für seine dbForge-Suite von Datenbank-Management-Tools bekannt, die große Datenbank-Systeme wie SQL Server, MySQL, Oracle und PostgreSQL unterstützen. Devart entwickelt auch Daten-Connectivity-Lösungen wie ODBC-, ADO.NET-, Python- und Delphi-Connector sowie Skyvia, seine cloudbasierte, kodefreie Daten-Integration-Plattform für ETL, Automatisierung, Backup und Workflow-Orchestrierung. Das Unternehmen bedient über 500.000 Benutzer weltweit, darunter einen großen Anteil von Fortune-100-Unternehmen, und hat sich zunehmend auf die Integration von künstlicher Intelligenz (KI) in seine Produkte konzentriert, wie z.B. dbForge AI Assistant, der Entwicklern hilft, SQL-Abfragen mit natürlicher Sprache zu generieren, zu optimieren, zu debuggen und zu erklären.

Sie haben sich von der Aufbau und Leitung von Vertriebsteams zu der Überwachung von vollständigen P&L-Operationen und jetzt der Leitung von Devarts größtem Geschäftsbereich entwickelt. Wie hat diese Reise Ihre Herangehensweise an die Integration von KI in die Produktstrategie und Entscheidungsfindung im großen Maßstab geprägt?

Der Vertrieb hat mich gelehrt, ROI auf alles zu messen. Als ich in eine CRO-Rolle wechselte, skalierte ich diese Disziplin über Funktionen hinweg. Die Überwachung des Geschäftsbereichs zwang mich, diese Disziplin auf die KI selbst anzuwenden.

Ich habe eine praktische Sicht auf KI. Es ist nicht so, dass ich skeptisch bin: Drei von unseren vier Produktwetten für 2026 sind KI-nativ. Aber ich glaube, dass Hype den Weg zu realen, langfristigen Ergebnissen behindert.

Es gibt ein Meme, das die Situation in der Branche oft falsch darstellt. Unternehmen ersetzen 400-Dollar-SaaS-Abonnements durch selbstentwickelte Tools, die 1.000 Dollar pro Monat an API-Gebühren kosten und ständig repariert werden müssen. Das ist keine echte Veränderung, sondern nur ein teures Schauspiel.

Die Lektion, die ich im Vertrieb gelernt habe, ist einfach: Jede Initiative muss sich selbst finanzieren, oder sie stirbt. Ich führe unseren KI-Rollout genauso durch, wie ich einst ein Vertriebsgebiet geführt habe. Explizite ROI-Hypothese pro Workflow, ein dreiphasiger Rollout und dokumentierter Einfluss vor der Skalierung.

Unser Leitstern-Maßstab ist der Umsatz pro Mitarbeiter, und unser Ziel ist es, diesen bis Ende 2028 mehr als zu verdoppeln. Man schließt diese Lücke nicht, indem man neue Mitarbeiter einstellt. Man schließt sie, indem man die Art und Weise ändert, wie man arbeitet, und KI ist das einzige realistische Mittel in diesem Umfang.

Mein Filter für jede KI-Initiative, intern oder produktbezogen, ist derselbe: Was ist der gemessene Wert, wer zahlt dafür, und wie wissen wir, dass es funktioniert hat? Alles, was diesen drei Fragen nicht standhält, gehört nicht in die Produktion. Die Kosten für das Falschmachen dieser Entscheidung summieren sich schnell, und die meisten Unternehmen werden das auf teure Weise herausfinden.

Devart hat einen starken Ruf im Bereich Datenbank-Tools und Entwickler-Produktivität aufgebaut. Wie integrieren Sie KI in diese Produkte, um echten Wert und nicht nur oberflächliche Automatisierung zu liefern?

Unsere Benutzer sind hardcore-technische Spezialisten: DBAs, Senior-Entwickler, Daten-Architekten. Sie erkennen oberflächliche Automatisierung in Sekunden und sind verärgert, wenn man ihnen Marketing-Spielzeuge als Innovation verkauft. Vor zwei Jahren, als die KI-Hype ihren Höhepunkt erreichte und die Konkurrenz sich beeilte, Chat-Panel auf jedes UI-Element zu setzen, war die Versuchung groß, es ihnen gleichzutun. Ich hatte jedoch diesen Trend bereits in der Mobil-, Cloud- und Low-Code-Branche gesehen und weigerte mich, ihn zu wiederholen.

Die Disziplin war einfach: Kundenwert zuerst. Die Entwicklung von KI-Funktionen, die niemand verlangt, die keinen echten Wert liefern, ist der schlechteste mögliche Einsatz von begrenzten Ingenieursressourcen. Das ist besonders wahr, wenn Ihre Zielgruppe den Unterschied sofort erkennen kann.

Was sich 2026 geändert hat, ist, dass KI von der Hype-Phase in eine echte technische Revolution übergegangen ist. Die Lücke zwischen dem, was diese Systeme 2023 und was sie heute können, ist nicht inkrementell. Es ist eine völlig andere Kategorie von Fähigkeiten. Wir können jetzt Probleme lösen, die vorher unlösbar waren: sichere Unternehmensdaten-Zugriffe für KI-Agenten, kontextuelle Datenbank-Intelligenz innerhalb der IDE des Entwicklers und autonome Geschäftsanalyse, die keine dedizierte Analyse benötigt.

Das sind neue Produktlinien, die existieren, weil KI das zugrunde liegende Problem lösbar gemacht hat. Das ist der Maßstab, den wir uns selbst setzen: Ein echtes KI-Produkt ist eines, bei dem die Entfernung der KI-Schicht das Produkt bricht. Die Branche hat zwei Jahre damit verbracht, Chat-Panel als “KI-Produkte” zu bezeichnen. Das sind Funktionen, keine Produkte.

Wir haben länger gebraucht, weil wir es richtig machen wollten. Die nächsten zwölf Monate werden zeigen, ob diese Disziplin sich auszahlt.

KI schreibt, optimiert und debuggt Code immer mehr. Wie sehen Sie die Veränderung der Rolle von Entwicklern, die mit Datenbanken arbeiten, in den nächsten Jahren?

Der Wert des Wissens von SQL-Syntax ist schnell im Wert gesunken. Wenn KI eine komplexe multi-Tabelle-Verbindung in Sekunden generieren und fehlende Indizes aus Protokollen in Minuten identifizieren kann, kommt der Wert eines Entwicklers nicht mehr von der Eingabe von SQL. Dieser Teil der Arbeit wird zu einer Ware.

Aber hier ist die kritische Nuance, die die Befürworter der vollständigen Automatisierung immer übergehen. Ein KI-Fehler auf der Frontend-Seite ist ein falsch ausgerichteter Button, den man neu lädt. Ein KI-Fehler auf der Datenbank-Seite ist ein gelöschtes Produktions-System, ein Datenschutzverstoß oder ein transaktionsbasierter Ausfall des gesamten Unternehmens.

Datenbanken speichern Zustände. Sie verzeihen keine Halluzinationen.

Diese Asymmetrie definiert die Rolle völlig neu. In den nächsten zwei bis drei Jahren werden Datenbank-Entwickler und DBAs von Codern zu Architekten und Auditoren evolvieren. Ihre Hauptarbeit verschiebt sich auf drei Dinge:

• Das Design von zuverlässigen Architekturen, die KI alleine nicht verstehen kann, weil sie den Geschäftskontext fehlt.
• Das Setzen von harten Sicherheitsrichtlinien und -vorschriften für KI-Agenten, die Produktions-Systeme berühren.
• Das Überprüfen und Auditen des von Maschinen generierten Codes, bevor er die Datenbank erreicht.

Das mentale Modell, an das ich immer wieder zurückkehre, ist: Entwickler werden Armeen von KI-Assistenten verwalten. Tools wie dbForge müssen sich von traditionellen IDEs zu Befehls- und Audit-Zentren entwickeln. Die Arbeit wird weniger darum, SQL manuell zu schreiben, und mehr darum, das zu überprüfen, was KI generiert, zu validieren und die Grenzen zu durchsetzen, die KI nicht sicher überschreiten kann.

Die professionelle Chance hier ist erheblich. Entwickler, die sich auf Architektur und Überwachung umstellen, werden ihren Marktwert vervielfachen. Sie werden die unverzichtbare Schicht zwischen KI-Produktivität und Produktions-Sicherheit.

Der Premium auf Datenbank-Expertise verschwindet nicht; er verschiebt sich nach oben in Richtung Design, Governance und Urteilskraft, was genau der Bereich ist, in dem KI alleine nicht operieren kann.

Was sind die größten Einschränkungen der aktuellen KI-Tools im Datenbank-Management und wo sehen Sie die bedeutendsten Durchbrüche?

Aktuelle KI ist immer noch in oberflächlicher Automatisierung steckengeblieben. Die Generierung einer grundlegenden SELECT-Abfrage oder von Boilerplate-Code ist nicht mehr beeindruckend. Das größere Problem ist, dass die meisten KI-Systeme immer noch wie blinde Schreibkräfte und nicht wie System-Architekten agieren. Sie können Syntax generieren, aber sie verstehen die Umgebung, in der sie operieren, nicht wirklich. Der echte Durchbruch geschieht, wenn KI beginnt, Kontext, Abhängigkeiten, Zustand und Geschäftslogik zusammen zu verstehen.

Im Moment sehe ich drei große Einschränkungen, die KI im Datenbank-Umfeld behindern.

Erstens gibt es das Kontext-Problem. Große Sprachmodelle können Schemata, DDL und Spaltennamen sehen, aber sie verstehen nicht wirklich die Ausführungspläne, Index-Fragmentierung, Daten-Verteilungsmuster oder die tatsächliche Geschäftslogik hinter den Daten. Ohne dieses tiefe Verständnis wird viel Optimierungs-Ratschlag zu statistischem Raten verkleidet als Experten-Rat.

Zweitens gibt es das Halluzinations-Problem, und Unternehmen haben fast null Toleranz dafür auf der Datenbank-Ebene. Eine halluzinierte Verbindung kann Produktions-Systeme verlangsamen. Ein falscher UPDATE kann kritische Aufzeichnungen löschen. Auf dieser Ebene werden sogar kleine Genauigkeitsfehler sehr teuer sehr schnell.

Das dritte Problem ist Sicherheit und Governance. Kein ernstes Unternehmen wird Produktions-Schemata oder personenbezogene Daten in ein öffentliches KI-Tool einfügen, ohne starke Garantien für Daten-Isolation und -Kontrolle. Bis Anbieter dies ordnungsgemäß lösen, wird die KI-Adoption in regulierten Branchen begrenzt bleiben.

Die bedeutendsten Durchbrüche werden kommen, wenn KI über die Syntax-Generierung hinausgeht und mehr wie ein Hintergrund-Architekt oder -Analyst agiert.

Ein Teil davon ist die semantische Schicht: Von rohen Tabellennamen zu tatsächlichem Geschäftsverständnis. Nicht nur “table_users”, sondern das Verständnis von Konzepten wie Kunden-Kohorten, Abbruch-Risiko oder Q3-LTV-Trends.

Ein weiterer Schritt ist, dass KI mehr wie ein erfahrener DBA im Hintergrund agiert. Kontinuierliche Analyse von Workloads, Identifizierung von Engpässen, Vorschlagen von Indizes, Erkennen von riskanten Abfragen und Erkennen von Problemen, bevor Systeme ausfallen.

Dann gibt es maschinelle Operationen, bei denen autonome Agenten die Datenbank-Last überwachen, Optimierungs-Strategien in isolierten Umgebungen testen und Verbesserungen unter menschlicher Aufsicht bereitstellen.

Das sind die Entwicklungen, die die nächsten fünf Jahre der Datenbank-Tooling prägen werden.

Wie wird KI die Preis-Modelle, Produkt-Verpackung und Kunden-Akquise in Software-Unternehmen verändern?

Das traditionelle Go-to-Market-Handbuch ist gebrochen. Wir sehen es in unseren eigenen Zahlen und über die gesamte dev-Tools-Kategorie hinweg.

Der Tod der klassischen Akquise. Trotz bedeutender Verbesserungen in den Suchmaschinen-Rankings für unsere Produkte im Jahr 2026 erreichen wir die Null-Klick-Realität. KI-Suchmaschinen liefern Antworten direkt auf der Ergebnisseite und entziehen Webseiten den Verkehr. Starke Rankings führen nicht mehr zu Leads, wie es noch vor zwei Jahren der Fall war.

Vor fünf Jahren reichte eine starke Content-Strategie aus, um Wachstum zu erzielen. Heute ist es ein Muss. KI-Modelle wiegen Markenstärke, positive Erwähnungen und Community-Dichte ab, wenn sie Antworten bilden. Wenn Ihre Marke nicht sichtbar und vertrauenswürdig ist, werden KI-Systeme Sie nicht konsequent auf der Oberfläche halten. Sie verlieren nicht nur Verkehr. Sie verschwinden vollständig aus dem Kaufprozess.

Dieser Wandel trifft traditionelle dev-Tools-Unternehmen besonders hart. SEO-getriebene Akquise-Kanäle, die ein ganzes Jahrzehnt von B2B-SaaS finanziert haben, verlieren rapide an Effizienz. Jeder, der noch auf sie als primären Wachstumshebel setzt, muss aktiv Alternativen aufbauen: Ökosystem-Verteilung, Community und Partnerschaften.

Preis-Evolution: Von Sitzplätzen zu PLG 3.0. Wir betreten die nächste Phase von PLG. Sitzplatz-Preise brechen zusammen, wenn ein KI-Agent die Arbeit von mehreren Mitarbeitern erledigen kann. In dieser Umgebung macht es keinen Sinn, nach Kopfzahl zu berechnen. Unternehmen, die ihre Produkte nicht um die Wert- und nicht um die Kopfzahl neu verpacken, werden in den nächsten 24 Monaten massiv MRR verlieren.

Der nächste Schritt ist PLG 3.0: Der Moment, an dem ein autonomer KI-Agent und nicht ein Mensch Unternehmens-Software auswertet, testet und kauft. Die Massen-Adoption dieses Musters ist noch einige Jahre entfernt, aber die Architektur von Produkten und Preisen für den maschinellen Käufer ist eine Aufgabe für 2026, nicht für 2028.

Viele Organisationen kämpfen darum, von KI-Experimenten zu echtem Produktions-Einfluss zu gelangen. Was sind die Schlüsselfaktoren, die bestimmen, ob KI-Initiativen tatsächlich erfolgreich sind?

Die meisten KI-Funktionen scheitern, bevor sie gebaut werden. Sie scheitern im Raum, in dem jemand sagt: “Wir benötigen KI in diesem Produkt”, nicht weil Benutzer danach gefragt haben, sondern weil der Vorstand eine KI-Geschichte will oder Marketing denkt, es wird ein neues Publikum anziehen. Das ist die ursprüngliche Sünde der meisten KI-Initiativen, und sie prägt alles, was folgt.

Ich sehe immer wieder dieselben Fehler in Unternehmen, die Schwierigkeiten haben, KI von Experimenten zu echtem Produktions-Einfluss zu bringen.

Der erste Fehler ist, KI-Funktionen zu bauen, die niemand wirklich verlangt. Sobald eine KI-Funktion ohne echten Benutzerbedarf angeordnet wird, arbeitet das Team rückwärts von der Technologie, um einen Anwendungsfall zu erfinden. Das Ergebnis ist vorhersehbar: Ein Chat-Panel, das auf eine bestehende Benutzeroberfläche gesetzt wird, ein Autocomplete, der im Weg ist, oder ein “Zusammenfassung”-Button, der schlechtere Ausgabe produziert, als der Benutzer selbst schreiben könnte. Diese Funktionen werden ausgeliefert, erhalten eine Pressemitteilung und unterperformen stillschweigend jede Adoptions-Prognose. Der tiefere Schaden ist, dass sie Ingenieurskapazitäten verbrauchen, die für Funktionen hätten verwendet werden sollen, die Benutzer tatsächlich angefordert haben.

Das zweite Problem ist, dass Teams die Differenz zwischen sauberem Demo-Daten und echten Produktions-Daten massiv unterschätzen. KI-Demos laufen auf sauberen, kuratierten Beispielen. Produktions-Daten laufen auf dem tatsächlichen Durcheinander von Kunden-Daten: Duplikate, fehlende Felder, zehn verschiedene Möglichkeiten, denselben Produktnamen zu schreiben, fünfzehn Jahre Legacy-Edge-Fälle. Ein Modell, das in der Bewertung beeindruckende Genauigkeit erreicht, kann auf Live-Daten stark abnehmen, und die meisten Teams entdecken dies erst, wenn Benutzer sich beschweren. Die Kosten dieser Entdeckung in der Produktions-Vertrauenswürdigkeit sind selten wieder gutzumachen.

Ein weiterer häufiger Fehler-Punkt ist die Benutzer-Forschung. Standard-Produkt-Interviews funktionieren nicht für KI-Funktionen. Benutzer können nicht artikulieren, was sie von KI wollen, weil sie nicht wissen, was möglich ist. Die Frage “Würden Sie KI verwenden, um X zu tun?” erhält höfliche Ja-Antworten, die keinen Vorhersage-Wert für die Akzeptanz haben. Effektive KI-Produkt-Forschung erfordert das Vorzeigen von Prototypen, das Beobachten der tatsächlichen Nutzung und das Messen, ob Benutzer nach dem Neuartigkeits-Effekt zurückkehren. Wenige Produkt-Teams haben ihre Forschungs-Praxis für dieses Problem umgebaut. Sie führen noch immer 2019-Playbooks für 2026-Probleme aus.

Und schließlich messen viele Unternehmen KI-Aktivität anstelle von Geschäftseinfluss. “Zweihundert Leute haben diese Woche die KI-Funktion verwendet” ist ein Adoptions-Maßstab, kein Einfluss-Maßstab. Echter Einfluss ist Zykluszeit-Reduzierung, Qualitätsverbesserung, Umsatz-Generierung oder Kosten-Entfernung. Wenn Sie keine direkte Linie vom KI-Feature zu einer Zahl auf der P&L ziehen können, haben Sie keinen Produktions-Einfluss. Sie haben eine teure Aktivität.

Es gibt einen fünften Faktor, der immer kritischer wird und den die meisten Produkt-Teams vollständig übersehen.

Konformität und der KI-freie Bau-Weg. Ein bedeutender Anteil von Unternehmens-Benutzern in Finanzen, Gesundheitswesen, Regierung, Verteidigung und Rechtswesen operiert unter Richtlinien, die KI-Funktionen in Vendor-Software verbieten oder einschränken. Wenn Ihr Produkt KI hart in die Kern-Erfahrung einbaut, ohne eine Möglichkeit, es zu deaktivieren oder zu umgehen, verlieren Sie nicht nur einen Teil Ihrer bestehenden Zielgruppe, wenn Sie KI hinzufügen. Sie gewinnen auch nicht.

Dies ist genau das Problem, das wir mit KI-Connectivity lösen. Konformitäts-Teams in regulierten Branchen haben nichts gegen KI selbst einzuwenden. Sie haben etwas gegen Daten einzuwenden, die ihre Perimeter verlassen. Die Lösung besteht nicht darin, KI herauszureißen, sondern darin, diesen Organisationen eine KI-Architektur zu bieten, die ihren Einschränkungen entspricht. Deshalb wird KI-Connectivity als On-Premise-Produkt ausgeliefert: Die KI-Fähigkeit bleibt, die Daten verlassen nie die Kunden-Infrastruktur, und die Beschaffung wird in der ersten Runde anstelle der dritten genehmigt.

Die Teams, die dies richtig machen, bauen von Tag eins an für Konformität. Die Teams, die es falsch machen, entdecken das Problem während der Beschaffungs-Überprüfung, wenn der Deal bereits verloren ist.

Devart operiert in mehreren Datenbank-Ökosystemen. Wie kann KI dabei helfen, die wachsende Komplexität des Daten-Managements über verschiedene Plattformen hinweg zu vereinfachen?

Der Schmerz ist real. Ein typisches Fortune-500-Unternehmen führt acht bis zwölf verschiedene Datenbank-Engines gleichzeitig aus: Legacy-Oracle für Finanzen, PostgreSQL für neue Dienste, SQL Server für Betrieb, Snowflake oder BigQuery für Analytics und zunehmend ein Vektor-Speicher für Embeddings. Jeder hat seine eigene Dialekt, seine eigene Tooling, seine eigene Governance-Regelung. Ein Entwickler, der in diese Umgebung eintritt, kann drei Monate damit verbringen, nur zu lernen, wo Daten leben und wer sie berühren darf.

KI allein löst diese Komplexität nicht. Es verstärkt, was immer es bekommt. Acht nicht verbundene Datenbanken mit keiner einheitlichen Metadaten produzieren acht nicht verbundene Sätze von oberflächlichen Vorschlägen. Das ist genau der Fehler-Modus, den wir in den meisten Unternehmens-KI-Rollouts auf Stacks sehen.

Die Chance liegt in einer Kontext-Schicht, die zwischen KI-Agenten und den zugrunde liegenden Datenbanken sitzt. Eine, die mit allen spricht, Metadaten normalisiert, einheitliche Governance-Richtlinien durchsetzt und eine saubere MCP-Schnittstelle bietet, damit jeder KI-Agent, ob Claude, GPT oder internes Modell, über das gesamte Anwesen mit konsistenten Regeln arbeitet.

Das ist die Architektur, auf die wir mit KI-Connectivity hinarbeiten: Ein On-Premise-MCP-Server mit Multi-Datenbank-Unterstützung, einer semantischen Schicht, die Geschäfts-Definitionen einmal und nicht für jeden KI-Agenten erneut erfassen muss, rollenbasierte Zugriffs-Kontrolle auf SQL-Operationen-Ebene und vollständige Audit-Logs.

Die Vereinfachung ist nicht kostenlos. Jemand muss immer noch die semantische Schicht modellieren und Richtlinien setzen. Aber diese Arbeit geschieht einmal, nicht wiederholt für jeden KI-Agenten, den Sie hinzufügen.

Sie haben große cross-funktionelle Teams geleitet. Wie verändert KI die interne Zusammenarbeit und Entscheidungsfindung zwischen Produkt, Engineering, Marketing und Vertrieb?

Die meisten cross-funktionellen Reibungen waren wirklich nur Menschen, die auf Informationen von anderen Teams warteten. KI reduziert diese Reibung schneller als jedes Management-Rahmenwerk es je könnte.

Die Verschiebungen sind praktisch und sofort spürbar.

In Produkt und Engineering: Ein Produkt-Manager stellt eine Datenbank-Frage in klaren Geschäfts-Begriffen, “Was ist die LTV-Varianz über unsere Top-Drei-Preis-Stufen?”, und erhält eine handhabbare Antwort auf der Stelle, anstelle eines Jira-Tickets an Analytics zu senden und drei Tage zu warten.

In Marketing und Daten: Kohorten-Analyse geschieht inline, nicht durch eine Anfrage-Queue. Der Marketing-Manager fragt, erhält Zahlen und baut die Kampagne, alles in einem Morgen.

In Vertrieb und Engineering: Technische Antworten für Prospekte benötigen nicht mehr die Terminierung eines Anrufs mit einem Senior-Entwickler. Der Vertriebs-Vertreter erhält eine glaubwürdige technische Antwort in Echtzeit, und der Deal-Zyklus komprimiert sich.

Entscheidungen verlagern sich in die Konversation und nicht in das Follow-up. Das Muster “Lass mich zurückrufen, wenn ich diese Zahl habe” stirbt. Meetings werden kürzer, weil KI Vorlese- und Zusammenfassungsaufgaben übernimmt, die früher die erste Hälfte jedes Meetings einnahmen.

Diese Kollaps der Reibung erzwingt eine tiefere Management-Verschiebung, und es ist die, die die meisten Führungsteams unterschätzen.

Jedes Unternehmen behauptet, ergebnis-orientiert zu sein. Schauen Sie unter die Oberfläche, und die meisten laufen immer noch auf Proxy-Metriken: Story-Points, Code-Zeilen, geschlossene Tickets, geloggte Stunden. Wir verwendeten Aktivität als Proxy für Wert, weil echter Wert schwer zu messen war. KI bricht diesen Proxy dauerhaft. Wenn ein Agent 10.000 Code-Zeilen schreiben oder 500 Support-Tickets in einer Minute schließen kann, wird die Messung von Aktivität gefährlich irreführend.

Wir bewegen uns explizit zu True Result-Oriented Management, wo Leistung strikt nach Outcome und Urteilskraft gemessen wird. Brutal in der Praxis, weil die meisten Leistungssysteme nicht dafür gebaut sind. Menschen, die sich hinter hoher Aktivität versteckt haben, werden sofort sichtbar, und Führung muss bereit sein, auf diese Sichtbarkeit zu reagieren.

Die strukturelle Konsequenz sind flachere Organigramme. Koordinations- und Informations-Weitergabe-Ebenen komprimieren. Organisationen, die sich am schnellsten anpassen, werden mit strukturell weniger Menschen bei höherer Hebelwirkung operieren.

Mit dem Aufkommen von KI-gestützter Entwicklung und No-Code-Tools: Bewegen wir uns in Richtung einer Zukunft, in der Datenbank-Management für nicht-technische Benutzer zugänglich wird?

Es gibt eine gefährliche Verwirrung in der Branche. Menschen behandeln eine Seiten-Projekt-Datenbank und eine Unternehmens-Legacy-Datenbank, als ob sie dasselbe wären. Sie sind es nicht.

Für kleine Grünfeld-Projekte ist die Demokratisierung bereits da. Ich habe persönlich kleine Anwendungen von Grund auf aufgebaut, ohne tiefe Datenbank-Management-Fähigkeiten. Wenn Ihr gesamtes Schema in das Kontext-Fenster eines LLM passt, funktioniert KI wie Magie. Citizen-Entwickler, die interne Tools auf kleiner Skala aufbauen, werden eine reale und wachsende Kategorie sein.

Unternehmens-Realität ist völlig anders. Große Legacy-Datenbanken haben das gleiche Problem wie große monolithische Codebasen: Die Kontext-Wand. Sie können fünfzehn Jahre unzureichend dokumentierter Schema-Evolution, Datenbank-übergreifende Abhängigkeiten und benutzerdefinierte Trigger-Logik nicht in einen Prompt einfügen. Wenn KI auf einer großen Datenbank den Kontext verliert, multiplizieren sich Halluzinationen exponentiell.

Das Risiko, das unterdiskutiert wird, ist falsche Sicherheit im großen Maßstab. Natürliche Sprach-Schnittstellen sind einzigartig gut darin, plausibel aussehende, aber fehlerhafte Antworten zu produzieren. Wenn eine SQL-Abfrage einen Syntax-Fehler hat, erhalten Sie eine Fehlermeldung. Wenn eine natürliche Sprach-Schnittstelle “aktive Kunden” falsch interpretiert, weil Ihre Daten sechs verschiedene Definitionen von Aktivität haben, erhalten Sie eine Zahl. Die Zahl sieht in Ordnung aus. Sie könnte um 30% falsch sein. Der Benutzer hat keine Möglichkeit, es zu wissen.

Nein, Unternehmens-Datenbank-Management wird nicht zu einem Spielplatz für nicht-technische Benutzer.

Der Citizen-DBA ist ein Mythos im großen Maßstab.

Die Zukunft gehört Experten-Daten-Architekten, die professionelle Tools verwenden, um die Kontext-Lücke zu überbrücken und Infrastruktur zu bauen, die es KI ermöglicht, sicher aufzusetzen.

Die strukturelle Lösung ist die semantische Schicht: Ein kontrolliertes Vokabular, in dem Geschäfts-Definitionen einmal und nicht für jede KI-Interaktion neu festgelegt werden. Das ist die Kern-Architektur, die wir in Insightis aufbauen. Ohne sie wird Zugänglichkeit zu einer Belastung.

Aufblickend, was sieht ein “KI-natives” Entwickler-Toolkit aus, und wie sollten Teams heute beginnen, sich auf diesen Wandel vorzubereiten?

Ein KI-natives Toolkit ist nicht ein Chatbot, der auf ein IDE gesetzt wird. Das meiste, was heute als “KI-nativ” beworben wird, ist eine Chat-Schnittstelle plus ein Autocomplete-Modell. Das ist ein Muss, nicht das Ziel.

Ein echtes KI-natives Toolkit benötigt drei Dinge.

Erstens benötigt KI tiefen Kontext. Es muss Ihren Code-Bestand, Ihre Infrastruktur, Ihre historischen Entscheidungen und Ihre Daten-Umgebung kontinuierlich verstehen, nicht nur durch Prompts, die in ein Chat-Fenster eingefügt werden. Die meisten aktuellen Tools scheitern an diesem Test. Ihr Kontext wird mit jeder Sitzung neu aufgebaut, und der Benutzer zahlt den Preis für den kontinuierlichen Wiederaufbau.

Zweitens müssen die Tools selbst ordnungsgemäß miteinander kommunizieren. Ihre IDE muss mit Ihrer Datenbank sprechen, die Datenbank mit Ihrem Überwachungs-Stack, und der CI/CD mit Ihrem KI-Reviewer usw. Das Model-Context-Protokoll wird hier zum Standard. Mit 97 Millionen SDK-Downloads pro Monat im ersten Quartal 2026, aufgestockt von 100.000 im späten 2024, ist das die steilste Adoptions-Kurve, die ich in der Entwickler-Infrastruktur gesehen habe.

Drittens erfordert Produktions-Grad-KI ernsthafte Sicherheits-Schutzmaßnahmen. Blast-Radius-Vorschau vor destruktiven Operationen. Abhängigkeits-Analyse. Automatisierte Rollback-Pläne. Audit-Logs standardmäßig. KI ohne diese ist in Ordnung für Prototypen und gefährlich in der Produktion.

So bereiten Sie sich konkret vor.

Überprüfen Sie Ihren Stack anhand dieser drei Komponenten. Exponieren alle Tools APIs und MCP? Kommunizieren sie miteinander oder sitzen sie in einer Nische? Haben sie Sicherheits-Steuerungen? Tools, die zwei von drei Punkten nicht erfüllen, sind kurzfristige Vermögenswerte.

Bauen Sie Kontext-Infrastruktur jetzt auf. Dokumentieren Sie Schemata, Geschäfts-Definitionen und architektonische Entscheidungen in maschinen-lesbaren Formaten. Reicher Kontext wird nicht in einem Quartal aufgebaut. Die Teams, deren KI 2027 Kontext hat, sind die, die heute dokumentieren.

Führen Sie KI in der Produktion aus, bevor Sie denken, dass Sie bereit sind. Teams, die auf eine formale “KI-Strategie” warten, bevor sie ausliefern, werden achtzehn Monate hinter Teams zurückbleiben, die bereits aus realen Produktions-Fehlern lernen. Wählen Sie einen niedrig-riskigen Anwendungsfall. Liefern Sie ihn aus. Bauen Sie das Muscle auf.

Die Teams, die diese Entscheidungen heute treffen, werden das nächste Jahrzehnt bestimmen, wie Software gebaut wird. Das Fenster ist eng, und es ist jetzt offen.

Vielen Dank für das großartige Interview. Leser, die mehr erfahren möchten, sollten Devart besuchen.