22.10.2025
KÜNSTLICHE INTELLIGENZ

KI-Agenten: „Zu glauben, man brauche keine Junior-Developer mehr, ist kurzsichtig“

Interview. Agenten sind im Bereich künstliche Intelligenz (KI) das Thema der Stunde. Doch wie setzt man sie um - und welches Potenzial haben sie wirklich? Dazu hat brutkasten im Rahmen der TEDAI Vienna mit Bivek Sharma von PwC gesprochen.
/artikel/ai-agents-bivek-sharma-pwc
Bivek Sharma auf der TEDAI Vienna
Bivek Sharma auf der TEDAI Vienna | Foto: TEDAI Vienna/Robert Leslie

Wenn es ein KI-Thema gibt, das aktuell so richtig heiß diskutiert wird, dann sind es KI-Agenten (AI-Agents). So intensiv das Thema derzeit aber besprochen wird, so viele Unklarheiten gibt es darum: Ab wann kann man wirklich von einem Agenten sprechen? Wie setzt man sie um und wie setzt man sie ein? Und wie zuverlässig sind sie?

Antworten auf diese Fragen kann Bivek Sharma geben. Er ist Chief AI Officer für PwC UK und EMEA AI Leader. Er verantwortet die Entwicklung und Umsetzung der KI-Strategie von PwC. Er leitet KI-Transformationsprojekte mit wichtigen Kunden und arbeitet mit CEOs an KI-getriebenen Geschäftsmodellen. Kürzlich war Sharma auf der TEDAI Vienna, wo er auf einem Panel zum Thema KI-Agenten diskutierte.


brutkasten: KI‑Agenten sind gerade ein großes Thema. Alle reden darüber, aber oft ist unklar, wovon eigentlich gesprochen wird. Was also sind Agents genau und wie grenzen sie sich beispielsweise von Chatbots ab?

Bivek Sharma: Eine hilfreiche Abgrenzung ist, zuerst klar über Chatbots zu sprechen. Viele verwechseln das. Ein Unternehmen sagt etwa: „Wir haben einen HR‑Agenten entwickelt“, hat aber in Wahrheit Personalrichtlinien in ein System geladen, eine KI‑Schicht darüber gelegt und beantwortet damit Fragen. Das ist ein Chatbot: Er liest große Mengen von Informationen, extrahiert Daten, fasst zusammen und liefert Auskunft. 

Ein Agent geht einen Schritt weiter – er erledigt Aufgaben. Er greift auf unterschiedliche Datenquellen zu, besucht Websites, trägt Informationen in Systeme ein, rechnet etwas aus und bringt Ergebnisse zurück. Er kann sogar mit anderen KI-Agenten interagieren. Denken Sie an einen Kundenservice‑Mitarbeiter: Der springt zwischen mehreren Systemen hin und her, recherchiert und dokumentiert. Ein Agent tut genau das: Er handelt und führt Arbeitsschritte aus, die sonst Menschen erledigen.

Nehmen wir ein konkretes Beispiel: Wenn ich ein Tool aufgesetzt habe, in das Mitarbeiter:innen Rechnungen hochladen und ein Large Language Model (LLM) diese dann analysiert und entscheidet, welche Abteilung die Rechnung freigeben muss – ist das ein Agent?

Bevor man etwas als „Agent“ einstuft, sollte man prüfen, ob das System wirklich dynamische Entscheidungen trifft. Wenn der Prozess komplett linear ist – Schritt 1, dann Schritt 2, dann Schritt 3 – ist das nicht agentisch. Ein Agent würde etwa erkennen: „Dieser Rechnung fehlt eine Angabe, ich muss einen Zwischenschritt einfügen, Informationen einholen und dann weitermachen.“ Oder: „Ich muss klären, wie diese Rechnung zu besteuern ist und dafür externe Informationen heranziehen.“ 

Es geht um Entscheidungen und die Frage: „Was ist der nächste sinnvolle Schritt?“ Gibt es nur genau einen möglichen Ausgang – z.B. Rechnung kommt rein, landet immer hier, dann immer dort – dann ist das eher klassische Automatisierung als ein agentischer Ablauf. KI-Agenten treffen abgestufte Entscheidungen und verwenden Urteilsvermögen innerhalb definierter Grenzen.

Wie setzt man so einen KI-Agenten in der Praxis um?

Bivek Sharma diskutierte auf der TEDAI Vienna zum Thema KI-Agenten
Bivek Sharma auf der TEDAI Vienna | Foto: TEDAI Vienna/Robert Leslie

Bei unternehmensweiten, agentischen Frameworks wird es schnell komplex, vor allem im B2C‑Umfeld mit Hunderttausenden oder Millionen von Nutzern. Dann braucht es eine robuste Architektur: Wie viele Menschen interagieren mit dem Agenten? Wie viele Workflows laufen parallel? Wie stelle ich sicher, dass das Ganze kosteneffizient und ohne spürbare Latenz arbeitet – und die Ergebnisse richtig sind, ohne Reputationsrisiken? 

Meist landet man deshalb bei einem tragfähigen Fundament auf der bevorzugten Cloud – etwa AWS oder Azure, mitunter auch Multi‑Cloud. Viele unterschätzen die verborgenen Baustellen. Unternehmen entwickeln derzeit viele punktuelle Lösungen: hier Copilot, dort etwas auf Google Cloud Platform (GCP), daneben eine maßgeschneiderte Eigenlösung. 

So entsteht eine Proliferation von KI-Agenten auf unterschiedlichen Frameworks. Wie hält man das aktuell? Wie überwacht man sie? Deshalb raten wir oft zu einem einheitlichen Rahmen, zum Beispiel einem Cloud‑AI‑Stack, der von Anfang an Skalierung ermöglicht.

Ein wichtiges Thema ist Identität. Häufig muss man einen Agenten wie einen Mitarbeiter behandeln: mit klaren Berechtigungen, Bearer‑Tokens und Zugriffsrechten auf die relevanten Anwendungen und Daten. Er handelt in Systemen, verwendet dabei – wo erforderlich – die Anmeldeinformationen des jeweiligen Mitarbeiters und kommuniziert sicher mit anderen Diensten. Ohne diese Infrastruktur produziert man „technical debt“: Viele Insellösungen wirken kurzfristig praktisch, kosten aber in zwei Jahren bei Reverse‑Engineering und Re‑Plattforming enorm viel.

Unternehmen sind letztlich für das Handeln ihrer KI-Agenten verantwortlich und fragen sich daher auch oft, wie vertrauenswürdig die Ergebnisse sind. In manchen Fällen könnte man in Situationen kommen, in denen das Unternehmen für fragwürdige Entscheidungen eines Agenten Konsequenzen zu spüren bekommen bis hin zu Haftungsfragen. Wie damit umgehen?

Da gibt es zwei Ebenen. Erstens das Design: Agenten müssen strikt auf ihren Auftrag ausgerichtet sein und klar definierte Datenquellen nutzen. Wenn ein Agent zum Rechnungsverarbeiten gedacht ist, aber zu offen gebaut wurde, kann ihn plötzlich jeder zu allem befragen – und er driftet mit einem offenen LLM vom eigentlichen Zweck ab. Das ist schlechtes Design. Gute Governance heißt: den Output präzise definieren, die zulässigen Eingaben und Antwortmuster einschränken, die Parameter schrittweise verengen und so den Aufgabenbereich verlässlich eingrenzen.

Zweitens der Betrieb: Beobachtbarkeit und Monitoring. Ein Agent kann tausende Aufgaben parallel ausführen – oder man hat gleich tausende Agenten im Einsatz. Man muss in Echtzeit sehen, was passiert: Wie viele Tokens verbrauchen sie? Wo liegen Fehlerraten? Beispiel Schadensregulierung: Wenn Agenten plötzlich jede Forderung durchwinken, muss man das sofort erkennen, stoppen und korrigieren können. 

Dazu gehört auch, das richtige Modell für die jeweilige Aufgabe zu wählen. Kosten und Rechenaufwand können massiv werden – auf der Konsumentenseite laufen manche Workflows 200.000 oder 300.000 Mal am Tag. Architektur, Modellwahl und Ablauf müssen Qualität, Latenz und Kosten gleichzeitig im Griff behalten.

Genauso wichtig ist die Einführung: Der Markt drängt auf Vollautonomie, aber nicht jedes Unternehmen ist dafür bereit. Oft startet man besser mit „Human‑in‑the‑Loop“ – der Agent arbeitet Seite an Seite mit den Mitarbeitenden. So werden Problemstellen sichtbar, die man im Design nicht vorhergesehen hat. Danach kann man teilautonom arbeiten und die heikleren Entscheidungen mit höherem Risiko beim Menschen belassen. Erst wenn das System gereift ist und die Guardrails sitzen, wird vollständige Autonomie ein Thema. Kurz gesagt: erst richtig bauen, dann sicher ausrollen.

Künstliche Intelligenz hat sich in den vergangenen drei Jahren auf der Technologie-Seite rasant entwickelt. Wenn man aber in Unternehmen reinhört, sind die Ergebnisse oft weniger spektakulär. Da landet man oft bei POCs oder bei kleinen Workflow-Automationen – weit entfernt von dem, was möglich wäre. Woran scheitert die Umsetzung?

Häufig beginnt es im C‑Level damit, die Fähigkeiten von KI in die eigene Geschäftswirklichkeit zu übersetzen. Viele wissen: Das wird wichtig und durchdringend – aber die Brücke ins eigene Unternehmen fehlt. Unsere Gespräche starten daher oft strategisch: In welcher Branche agieren Sie? Wo droht Disruption? Wie verändern sich Geschäftsmodelle? Was bedeutet das für Backoffice, Off‑/Onshoring‑Entscheidungen und die Belegschaft? Fehlt diese Klarheit, entsteht rasch FOMO: Man sammelt Referenzen, baut punktuelle Use Cases. Das ist nicht per se schlecht – Experimente sind gut – aber ohne Struktur wird es nicht strategisch.

Fokus entsteht dort, wo man den Zeitpunkt nicht selbst steuern kann: Wenn gut finanzierte Scaleups in den Markt drängen oder der Wettbewerber sein Modell gerade dreht, lautet die Priorität, das eigene Geschäft zu schützen, die Wettbewerbsvorteile zu stärken oder Marktanteile zu gewinnen. Natürlich gibt es auch Produktivitätsdruck – Investoren erwarten bessere EBITDA‑Werte, niedrigere Kosten. Aber am stärksten bündeln Unternehmen ihre Kräfte dort, wo sie jetzt handeln müssen.

Stichwort Scaleups. Wird agentische KI dazu führen, dass sehr schlanke Startups mit kleinen Teams Leistungen erbringen, für die heute große Teams nötig sind?

Es gibt zwei Richtungen. In manchen Branchen – Content, Musik, Grafik – demokratisiert KI die Produktion. Einzelne oder KMU können über immer leistungsfähigere Plattformen Angebote schaffen, die früher großen Firmen vorbehalten waren. Das führt zu echter Disruption von unten. Umgekehrt investieren große Unternehmen, schaffen überlegene Nutzererlebnisse und verdrängen kleinere Anbieter – etwa, wenn man an Amazon und den Einzelhandel denkt oder Uber und klassische Taxi-Dienste. Beides passiert. Man kann Sektor für Sektor durchgehen und sehen, in welche Richtung die Verwerfungen wahrscheinlicher sind.

Beim Ausrollen von KI-Projekten zählen nicht nur technische Aspekte, sondern auch der Faktor Mensch. Gibt es Widerstände aus Angst vor Jobverlust? Wie führt man als verantwortliche Führungskraft durch so eine Transformation?

Bestehende Strukturen können Fortschritt blockieren – aus Bequemlichkeit, nach dem Motto „Wir machen das seit Jahren so“ oder aus Abwehr. Nach unserer Erfahrung ist die Trägheit oft das größere Hindernis. Die „Gen Z“ und viele Junior‑Talente sind dagegen sehr aufgeschlossen. Sie sind mit Sprachmodellen groß geworden und erwarten KI‑gestützte Arbeitsumgebungen.

In großen, reifen Organisationen geht es um Transformationsprogramme, Change‑Management und eine Kultur, die Experimentieren erlaubt. Gleichzeitig braucht es manchmal einen radikalen Ansatz: Wir stellen eigenständige, vom Kerngeschäft abgeschirmte Teams auf, die wie Scaleups denken und bestehende Geschäft aus Kundensicht neu entwerfen – mit der Frage: „Wie sähe das mit weißem Blatt Papier aus?“ So kommt man schneller zum künftigen Modell als über schrittweise Evolution.

Einige Unternehmen finanzieren solche neuen Modelle sogar bewusst, obwohl sie das bestehende Geschäft kannibalisieren, und lassen beide nebeneinander laufen. Man sieht dann, wie das alte Modell an Relevanz verliert, während das neue gewinnt. Hätte Blockbuster seinerzeit parallel ein Streaming‑Geschäft aufgebaut und laufen lassen, wäre die Wertschöpfung wohl ganz anders ausgefallen – aber so etwas ist innerhalb gewachsener Hierarchien schwer umzusetzen.

Apropos Juniors. Im Bereich der Software-Entwicklung gehen ja manche davon aus, dass durch KI-Agenten die klassischen Junior-Rollen wegfallen werden – weil Senior Developer Agenten für die Dinge einsetzen, die bisher Juniors gemacht haben. Ist das überzeugend?

Nein. Dieses Argument setzt voraus, dass sich Rollen nicht verändern. Es sagt im Grunde: „Was ein Junior heute tut, bleibt unverändert – also ersetzen wir das durch Code‑Generierung.“ Richtig ist das Gegenteil: Man muss die Rolle neu denken. Ein Junior sollte künftig Aufgaben übernehmen, die heute eher Mid‑Level sind – Architektur‑Fragmente, kreatives Zusammenbauen, schnelles Umsetzen mit Code‑Gen‑Tools. Es geht um veränderte Erwartungen, nicht um Wegfall. 

Das gilt auch bei uns: Eine Associate‑Rolle im ersten Jahr sieht mit den neuen Werkzeugen anders aus. Recherche und Routine gehen schneller; also trainieren wir darauf, zwei Jahre „vorzuziehen“. Wir rekrutieren weiter – nur mit anderen Profilen und Aufgabenzuschnitten. Zu glauben, die Rollen blieben gleich und deshalb brauche man keine Juniors mehr, ist kurzsichtig.

Deine ungelesenen Artikel:
vor 11 Stunden

Lovable-CEO Anton Osika: „Wir sind längst über Vibecoding hinaus“ – vom Hype zur Enterprise-Software

Erst vor etwa einem Monat holte Lovable 400 Mio. Dollar bei 13,3 Mrd. Bewertung: CEO Anton Osika erklärt nun im Interview, warum KI-Bau-Tools längst im Mainstream angekommen sind und wie aus Vibe-Coding echte Enterprise-Software wurde.
/artikel/lovable-ceo-anton-osika-wir-sind-laengst-ueber-vibecoding-hinaus-vom-hype-zur-enterprise-software
vor 11 Stunden

Lovable-CEO Anton Osika: „Wir sind längst über Vibecoding hinaus“ – vom Hype zur Enterprise-Software

Erst vor etwa einem Monat holte Lovable 400 Mio. Dollar bei 13,3 Mrd. Bewertung: CEO Anton Osika erklärt nun im Interview, warum KI-Bau-Tools längst im Mainstream angekommen sind und wie aus Vibe-Coding echte Enterprise-Software wurde.
/artikel/lovable-ceo-anton-osika-wir-sind-laengst-ueber-vibecoding-hinaus-vom-hype-zur-enterprise-software
Lovable-CEO Anton Osika (r.) im Gespräch mit Times Senior Editorin Ayesha Javed. © brutkasten

Kaum ein Tool steht so sehr für den KI-Bauboom wie Lovable. Erst im August 2026 hat das schwedische Startup, wie brutkasten berichtete, eine Series-C-Runde über 400 Millionen US-Dollar abgeschlossen, angeführt von Menlo Ventures und mit dem EQT-gemanagten Scaleup Europe Fund als Co-Lead, bei einer Bewertung von 13,3 Milliarden US-Dollar.

Für Gründer und CEO Anton Osika ist das mehr als eine Finanzierungsrunde: Es sei ein Indikator dafür, dass KI-gestützte No-Code- und Low-Code-Plattformen die Nische verlassen hätten und im Mainstream angekommen seien.

Weg vom Entwickler-Monopol

Auf der Dreamforce in San Francisco erläutert Osika die zentrale These hinter Lovable: „Menschen mit Fachwissen über das jeweilige Problem sollten diejenigen sein, die Software bauen“, so Osika. Wer ein Problem am besten kenne, solle auch die Lösung bauen, egal ob in Marketing, HR, Finance oder Operations. Nicht die formale Qualifikation zähle, sondern die Nähe zum Problem.

Dass Lovable längst kein reines Anfänger-Werkzeug sei, belegt Osika mit einer internen Zahl: 55 Prozent der Lovable-Nutzer:innen brächten mehr als elf Jahre Berufserfahrung in ihrem Fachgebiet mit. Entscheidend sei laut dem Co-Founder nicht das klassische Programmieren, sondern die Fähigkeit, komplexe, unstrukturierte Probleme systematisch in funktionierende Systeme zu zerlegen.

Vom Nebenprojekt zur Unternehmenslösung

Besonders aufschlussreich sind die Praxisbeispiele, die Osika im Gespräch anführt. Bei einer Healthcare-Staffing-Firma habe ein Fachbereichsleiter eine komplette neue Produktlinie für die Zertifizierung von Pflegekräften aufgebaut, samt Verwaltung und Terminplanung, und anschließend mehr als zehn weitere interne Anwendungen vernetzt. In den nordischen McDonald’s-Filialen laufe mittlerweile ein auf Lovable gebautes Interface, über das rund 300 Standorte operative Anfragen abwickeln würden.

Solche Geschichten seien laut Osika keine Ausnahme: Bei knapp zwei Dritteln der Fortune-500-Unternehmen, darunter Adidas und Nvidia, würden Mitarbeitende die Plattform nutzen. Häufig beginne es als kleines Team-Projekt und wachse zur unternehmensweiten Lösung heran.

Entwicklung unter Aufsicht

Damit das nicht in unkontrollierter Schatten-IT ende, setzt Lovable laut Unternehmensangaben auf Admin- und Audit-Funktionen, mit denen IT-Verantwortliche nachvollziehen können sollen, welche Anwendungen entstehen, wo sensible Daten verarbeitet werden und wo Sicherheitslücken drohen. Genau das mache aus der anfänglichen Skepsis von IT-Abteilungen häufig Zustimmung, so Osika: „Es wird vom letzten Nein zu dem, was man ausrollen wollte, zum ersten Ja. So verhindern wir Schatten-IT und die Zersplitterung in unzählige Tools, die niemand mehr überblickt“, erklärt Osika.

Überflüssig würden Engineers durch die Lovable-Nutzung anderer trotzdem nicht, meint Osika: Ihre Rolle verschiebe sich von Routineaufgaben hin zu Architektur, Systemanbindung und der Betreuung unternehmenskritischen Codes.

Warum heißt Lovable eigentlich Lovable?

Zum Schluss des Gesprächs räumt Osika mit einem gängigen Klischee über den europäischen Tech-Standort auf: „Viele halten Europa für langsam, aber wenn man in die Tech-Hubs Europas geht, brodelt es dort wie nie zuvor“, sagt Osika. Dass der Produktfokus so stark auf dem Nutzererlebnis liege, führt Osika auch auf den Standort Stockholm zurück, wo der Großteil des Engineering-Teams sitzt. Man habe in den nordischen Ländern genaue Vorstellungen davon, wie ein Produkt funktionieren solle – oder eben nicht. Diese „I-Tüpfelchen-Reiterei“ mache Lovable erst zu dem was es heute ist.

Warum das Unternehmen ausgerechnet „Lovable“ heißt, erklärt er mit einer letzten Zeile, die zugleich als Leitmotiv des Gesprächs steht: „Software sollte nicht einfach nur funktionieren. Sie soll die Emotionen der Menschen wecken“, so Osika.

Vom Vibe zum Volumengeschäft

Was also vor nicht allzu langer Zeit noch als spielerisches „Vibe-Coding“ belächelt wurde, ist laut Osika längst zu einer Infrastruktur geworden, auf der Enterprisekund:innen die nächsten Prozesssysteme entwickeln. Der Markt für KI-gestütztes Bauen sei, so der Lovable-Gründer, endgültig über das reine Ausprobieren hinausgewachsen – und weit über das Vibecoding hinaus.

Toll dass du so interessiert bist!
Hinterlasse uns bitte ein Feedback über den Button am linken Bildschirmrand.
Und klicke hier um die ganze Welt von der brutkasten zu entdecken.

brutkasten Newsletter

Aktuelle Nachrichten zu Startups, den neuesten Innovationen und politischen Entscheidungen zur Digitalisierung direkt in dein Postfach. Wähle aus unserer breiten Palette an Newslettern den passenden für dich.

Montag, Mittwoch und Freitag

AI Summaries

KI-Agenten: „Zu glauben, man brauche keine Junior-Developer mehr, ist kurzsichtig“

AI Kontextualisierung

Welche gesellschaftspolitischen Auswirkungen hat der Inhalt dieses Artikels?

Leider hat die AI für diese Frage in diesem Artikel keine Antwort …

KI-Agenten: „Zu glauben, man brauche keine Junior-Developer mehr, ist kurzsichtig“

AI Kontextualisierung

Welche wirtschaftlichen Auswirkungen hat der Inhalt dieses Artikels?

Leider hat die AI für diese Frage in diesem Artikel keine Antwort …

KI-Agenten: „Zu glauben, man brauche keine Junior-Developer mehr, ist kurzsichtig“

AI Kontextualisierung

Welche Relevanz hat der Inhalt dieses Artikels für mich als Innovationsmanager:in?

Leider hat die AI für diese Frage in diesem Artikel keine Antwort …

KI-Agenten: „Zu glauben, man brauche keine Junior-Developer mehr, ist kurzsichtig“

AI Kontextualisierung

Welche Relevanz hat der Inhalt dieses Artikels für mich als Investor:in?

Leider hat die AI für diese Frage in diesem Artikel keine Antwort …

KI-Agenten: „Zu glauben, man brauche keine Junior-Developer mehr, ist kurzsichtig“

AI Kontextualisierung

Welche Relevanz hat der Inhalt dieses Artikels für mich als Politiker:in?

Leider hat die AI für diese Frage in diesem Artikel keine Antwort …

KI-Agenten: „Zu glauben, man brauche keine Junior-Developer mehr, ist kurzsichtig“

AI Kontextualisierung

Was könnte das Bigger Picture von den Inhalten dieses Artikels sein?

Leider hat die AI für diese Frage in diesem Artikel keine Antwort …

KI-Agenten: „Zu glauben, man brauche keine Junior-Developer mehr, ist kurzsichtig“

AI Kontextualisierung

Wer sind die relevantesten Personen in diesem Artikel?

Leider hat die AI für diese Frage in diesem Artikel keine Antwort …

KI-Agenten: „Zu glauben, man brauche keine Junior-Developer mehr, ist kurzsichtig“

AI Kontextualisierung

Wer sind die relevantesten Organisationen in diesem Artikel?

Leider hat die AI für diese Frage in diesem Artikel keine Antwort …

KI-Agenten: „Zu glauben, man brauche keine Junior-Developer mehr, ist kurzsichtig“