Anton Onufriienko, Managing Director bei Devart – Interview-Serie

Anton Onufriienko, Managing Director bei Devart, ist ein Technologie-Executive und Operator mit langjähriger Erfahrung im Bereich Software-Unternehmen, Umsatzwachstum und 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. Bevor er Managing Director wurde, 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 Profitabilitätsplattform, die darauf abzielt, serviceorientierte Unternehmen bei der Erlangung von operativer Klarheit zu unterstützen.

Devart ist ein Software-Unternehmen, das sich auf die Entwicklung von Datenbank-Tools, Daten-Connectivity-Lösungen, Integrations- 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 (ORCL ) und PostgreSQL unterstützen. Devart entwickelt auch Daten-Connectivity-Lösungen wie ODBC-, ADO.NET-, Python- und Delphi-Connector sowie Skyvia, seine cloudbasierte No-Code-Daten-Integrationsplattform für ETL, Automation, Backup und Workflow-Orchestrierung. Das Unternehmen bedient über 500.000 Benutzer weltweit, darunter einen großen Anteil von Fortune-100-Unternehmen, und hat sich in den letzten Jahren zunehmend auf die Integration von KI-gestützten Funktionen 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 CRO habe ich diese Disziplin auf alle Funktionen ausgeweitet. Die Überwachung des Geschäftsbereichs hat mich gezwungen, 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 die Hype die echten, langfristigen Ergebnisse 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 eine teure Show.

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

Unser Leitstern-Maß ist der Umsatz pro Mitarbeiter, und unser Ziel ist es, diesen bis Ende 2028 um mehr als das Doppelte zu erhöhen. Man kann diese Lücke nicht durch die Einstellung neuer Mitarbeiter schließen. Man muss die Art und Weise ändern, wie die Arbeit aussieht, und KI ist das einzige realistische Mittel, um dies im großen Maßstab zu erreichen.

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 dies auf die teure Tour herausfinden.

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

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-Spielereien 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 bei Mobile, Cloud und Low-Code gesehen und weigerte mich, ihn zu wiederholen.

Die Disziplin war einfach: Kundennutzen zuerst. Die Entwicklung von KI-Funktionen, die niemand verlangt, die keinen echten Wert bieten, ist der schlechteste mögliche Einsatz von begrenzten Ingenieursressourcen. Dies ist besonders wichtig, wenn das Publikum den Unterschied sofort erkennen kann.

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

Das sind neue Produktlinien, die nur deshalb 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-Table-JOIN in Sekunden generieren und fehlende Indizes aus Logs 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 entscheidende Nuance, die die Befürworter der vollständigen Automatisierung immer auslassen. Ein KI-Fehler im Frontend ist ein falsch ausgerichteter Button, den man neu lädt. Ein KI-Fehler in der Datenbank ist ein gelöschtes Produktions-System, ein Datenschutzverstoß oder ein transaktionsbezogener Ausfall des gesamten Geschäfts.

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, über die KI allein nicht nachdenken 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, auf das ich immer wieder zurückkomme, 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, es zu validieren und die Grenzen zu durchsetzen, die KI nicht sicher überschreiten kann.

Die professionelle Chance ist hier 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-Experten verschwindet nicht; er verschiebt sich nach oben in Richtung Design, Governance und Urteilsvermögen, was genau der Bereich ist, in dem KI allein 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 stecken geblieben. 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 Schreiber 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 Ausführungspläne, Index-Fragmentierung, Daten-Verteilungsmuster oder die tatsächliche Geschäftslogik hinter den Daten. Ohne dieses tiefergehende 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 JOIN kann Produktions-Systeme verlangsamen. Ein falscher UPDATE kann kritische Aufzeichnungen löschen. Auf dieser Ebene werden sogar kleine Genauigkeitsfehler sehr schnell sehr teuer.

Das dritte Problem ist Sicherheit und Governance. Kein ernsthaftes Unternehmen wird Produktions-Schemata oder personenbezogene Daten in ein öffentliches KI-Tool einfügen, ohne starke Garantien für Daten-Isolation und -Kontrolle. Bis die 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äfts-Sinn. Nicht nur “table_users”, sondern das Verständnis von Konzepten wie Kunden-Kohorten, Abwanderungs-Risiko oder Q3-LTV-Trends.

Ein weiterer Schritt ist, dass KI mehr wie ein erfahrener DBA im Hintergrund agiert. Kontinuierlich Workloads analysieren, Engpässe identifizieren, Indizes vorschlagen, riskante Abfragen erkennen und Probleme auffangen, bevor Systeme ausfallen.

Dann gibt es maschinelle Operationen, bei denen autonome Agenten 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 Preisstrategien, Produkt-Paketierung und Kunden-Akquise in Software-Unternehmen verändern?

Das traditionelle Go-to-Market-Handbuch ist gebrochen. Wir sehen es in unseren eigenen Zahlen und im gesamten dev-Tools-Segment.

Der Tod der klassischen Akquise. Trotz bedeutender Verbesserungen in den Suchmaschinen-Rankings für unsere Produkte im Jahr 2026 stoßen wir an 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 sie es noch vor zwei Jahren taten.

Vor fünf Jahren war eine starke Content-Strategie ausreichend, 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 konsistent 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 B2B-SaaS-Generation finanziert haben, verlieren schnell an Effizienz. Jeder, der noch auf diese 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. Sitzplätze-Preise brechen zusammen, wenn ein KI-Agent die Arbeit von mehreren Mitarbeitern erledigen kann. In dieser Umgebung hört es auf, Sinn zu machen, nach Kopfzahl zu berechnen. Unternehmen, die ihre Produkte nicht um die Wert- und nicht um die Kopfzahl herum neu paketieren, werden in den nächsten 24 Monaten MRR verlieren.

Der nächste Schritt ist PLG 3.0: Der Moment, in dem ein autonomer KI-Agent und nicht ein Mensch Unternehmens-Software bewertet, 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.

Warum haben viele Organisationen Schwierigkeiten, 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 brauchen 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 der ursprüngliche Fehler der meisten KI-Initiativen, und er prägt alles, was folgt.

Ich sehe immer wieder die gleichen Fehler bei 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 Benutzer-Bedarf 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 Auto-Vervollständigen, das im Weg ist, oder ein “Zusammenfassen”-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 Ingenieurs-Kapazitäten verbrauchen, die für Funktionen hätten verwendet werden sollen, die Benutzer tatsächlich verlangt 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 Chaos von Kunden-Daten: Duplikate, fehlende Felder, zehn verschiedene Schreibweisen für denselben Produktnamen, 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. “Würden Sie KI verwenden, um X zu tun?” erhält höfliche Ja-Antworten, die keine Vorhersage-Kraft für die Adoption haben. Effektive KI-Produkt-Forschung erfordert das Zeigen von Prototypen, das Beobachten von echter 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ß, kein Einfluss-Maß. Echter Einfluss ist Zyklus-Zeit, die reduziert wird, Qualität, die verbessert wird, Umsatz, der generiert wird, oder Kosten, die entfernt werden. Wenn Sie keine direkte Linie vom KI-Feature zu einer Zahl auf der Gewinn-und-Verlust-Rechnung ziehen können, haben Sie keinen Produktions-Einfluss. Sie haben eine teure Aktivität.

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

Compliance und der KI-freie Bau-Weg. Ein bedeutender Anteil von Unternehmens-Benutzern in Finanzen, Gesundheitswesen, Regierung, Verteidigung und Recht operiert unter Richtlinien, die KI-Funktionen in Vendor-Software verbieten oder einschränken. Wenn Ihr Produkt KI fest in die Kern-Erfahrung integriert, ohne einen Weg zu bieten, es zu deaktivieren oder zu umgehen, verlieren Sie nicht nur einen Teil Ihres Publikums. Sie verlieren einen Teil Ihres bestehenden Publikums.

Das ist genau das Problem, das wir mit KI-Connectivity lösen. Compliance-Teams in regulierten Branchen haben nichts gegen KI selbst einzuwenden. Sie haben etwas gegen Daten-Verlassen ihres Perimeters einzuwenden. Die Lösung ist nicht, KI herauszureißen; es ist, 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 angenommen, anstatt in der dritten.

Die Teams, die dies richtig machen, bauen von Tag eins an für Compliance. 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 die wachsende Komplexität der Daten-Verwaltung über verschiedene Plattformen hinweg vereinfachen?

Der Schmerz ist real. Ein typisches Fortune-500-Unternehmen führt acht bis zwölf verschiedene Datenbank-Engines gleichzeitig: Legacy-Oracle für Finanzen, PostgreSQL für neue Dienste, SQL-Server für Betrieb, Snowflake oder BigQuery für Analytics und zunehmend einen 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 löst diese Komplexität nicht allein. 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 muss nur einmal und nicht für jeden KI-Agenten wiederholt werden.

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 Leute, die auf Informationen von anderen Teams warteten. KI eliminiert diese Reibung schneller als jedes Management-Modell es je könnte.

Die Verschiebungen sind praktisch und sofort.

Im 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-Tiers?”, und erhält eine handhabbare Antwort auf der Stelle, anstatt ein Jira-Ticket zu Analytics zu stellen und drei Tage zu warten.

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

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

Entscheidungen bewegen sich in die Konversation und nicht in das Follow-up. Das Muster “Lass mich zurückkommen, wenn ich diese Zahl habe” stirbt. Meetings schrumpfen, weil KI Vor- und Zusammenfassungen übernimmt, die früher die erste Hälfte jedes Meetings einnahmen.

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

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

Wir bewegen uns explizit zu True Result-Oriented Management, wo Leistung strikt nach Outcome und Urteilsvermögen gemessen wird. Brutal in der Praxis, weil die meisten Leistungssysteme nicht dafür gebaut sind. Leute, 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-Routing-Schichten komprimieren. Organisationen, die sich am schnellsten anpassen, werden mit strukturell weniger Leuten bei höherer Hebelwirkung operieren.

Wir bewegen uns in Richtung einer Zukunft, in der Datenbank-Verwaltung für nicht-technische Benutzer zugänglich wird?

Es gibt eine gefährliche Verwirrung in der Branche. Leute behandeln ein Side-Project-Datenbank und eine Unternehmens-Legacy-Datenbank, als wären sie dasselbe. 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 kleinen Skalen bauen, 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 Code-Basen: 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 einpassen. Wenn KI den Kontext auf einer großen Datenbank verliert, multiplizieren sich Halluzinationen exponentiell.

Das Risiko, das unterdiskutiert wird, ist falsche Zuversicht im großen Maßstab. Natürliche Sprach-Schnittstellen sind besonders gut darin, plausibel aussehende, aber subtil falsche 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, die Verwaltung von Unternehmens-Datenbanken 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: Eine kontrollierte Vokabular, in der 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.

Was sieht ein “KI-natives” Entwickler-Toolkit aus, und wie sollten Teams sich heute auf diesen Wandel vorbereiten?

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 Auto-Vervollständigungs-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 und nicht nur durch Prompts in einem Chat-Fenster verstehen. 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 Wiederaufbau.

Zweitens müssen die Tools selbst ordentlich miteinander sprechen. Ihre IDE muss mit Ihrer Datenbank sprechen, die Datenbank mit Ihrem Observability-Stack und der CI/CD mit Ihrem KI-Reviewer usw. Das Model-Context-Protokoll wird hier zum Standard-Layer, mit 97 Millionen SDK-Downloads pro Monat im Q1 2026, auf 100.000 im späten 2024. Das ist eine 970-fache Zunahme in fünfzehn Monaten und die steilste Adoptions-Kurve, die ich in der Entwickler-Infrastruktur gesehen habe.

Drittens erfordert Produktions-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.

Wie man sich vorbereitet, konkret.

Überprüfen Sie Ihren Stack anhand dieser drei Komponenten. Exponiert jedes Tool APIs und MCP? Spricht es mit anderen oder sitzt es in einer Nische? Hat es Sicherheits-Steuerungen? Tools, die zwei von drei Punkten verfehlen, 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 dies 2027 hat, sind diejenigen, die heute dokumentieren.

Führen Sie KI in der Produktion ein, bevor Sie denken, dass Sie bereit sind. Teams, die auf eine formelle “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-risikos Fall. Liefern Sie ihn aus. Bauen Sie das Muskel-Gedächtnis 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.

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.