Agentic AI: How AI Agents Transformed My Work as a Software Engineer and CEO

Einleitung

Hallo zusammen, mein Name ist Simon Harrer. Ich habe in verteilten Systemen promoviert und sieben Jahre bei INNOQ als Software-Architekt und Berater gearbeitet. Seit 2025 bin ich Co-Founder und CEO bei Entropy Data, einem Spin-off von INNOQ.

Nebenbei habe ich das Buch "Java by Comparison" mitverfasst und das "Data Mesh"-Buch ins Deutsche mitübersetzt. Außerdem bin ich Co-Maintainer der Open-Source-Tools mob.sh und der Data Contract CLI. Und ich bin Mitglied im Technical Steering Committee des BITOL-Projekts der Linux Foundation für Standards rund um Data Contracts und Datenprodukte.

Heute möchte ich darüber sprechen, wie KI-Agenten komplett verändert haben, wie ich arbeite -- sowohl als Software Engineer als auch als CEO.

Mein persönlicher KI-Moment

Es war April 2025. Ich saß mit André Deuerling im Zug nach Berlin. Dank der Deutschen Bahn kamen wir auf über zwei Stunden Verspätung. Also setzten wir uns in den Bordbistro-Wagen und bestellten eine Runde Bier nach der anderen. André hatte Claude Code schon benutzt, also beschlossen wir, es gemeinsam auszuprobieren.

Die Aufgabe: einen Spring-Boot-Service bauen, der sich mit einer MariaDB-Datenbank verbindet, alle Schemas, Tabellen und Spalten ausliest und diese Metadaten in die API unseres Produkts schiebt. Die Regel war einfach -- null Zeilen Code schreiben. Nur prompten.

Wir arbeiteten etwa zwei Stunden daran. Wir reviewten, was es generierte, prompteten weiter, überarbeiteten Architekturentscheidungen. Dann holten wir die API-Keys, konfigurierten manuell, starteten das Ganze -- und es funktionierte. Das ganze Ding lief einfach.

Das war mein persönlicher KI-Moment. Der Moment, in dem mir klar wurde, dass sich etwas Grundlegendes verschoben hatte.

Was ist ein Agent?

Was ist also ein Agent? Es ist eigentlich ganz einfach: ein LLM, das Tools in einer Schleife nutzt.

Claude Code ist genau das. Im Hintergrund läuft ein LLM, und es hat Zugriff auf eine Reihe von Tools: Es kann CLI-Aufrufe machen, Dateien lesen und schreiben, im Internet recherchieren, Tests ausführen, Code kompilieren. Sogar Memory ist nur ein Tool -- im Grunde eine To-do-Liste, auf die der Agent über ein Tool-Interface zugreift.

Das ist das ganze Konzept. Ein LLM, das Tools in einer Schleife nutzt. Und doch hat dieses einfache Konzept, wie du gleich sehen wirst, alles daran verändert, wie ich arbeite.

Der Einstieg

Nach diesem Erlebnis fing ich an, Claude Code immer mehr zu nutzen. Ich muss ehrlich sein: Anfangs war nicht alles toll. Manchmal warf ich den generierten Code komplett weg und programmierte wieder von Hand. Aber ich blieb dran.

Ich buchte den 20-Dollar-pro-Monat-Plan. Es fühlte sich an wie ein Netflix-Abo -- geringe Bindung, hoher potenzieller Mehrwert.

Der Game Changer: die Opus-Modelle

Dann kam im November 2025 Opus 4.5. Das war der echte Game Changer.

Lass mich den METR-Benchmark zeigen. Er misst die Aufgabenlänge, die LLMs in mindestens 50 % der Fälle erfolgreich bewältigen können. GPT-5.1 und Codex Max landen irgendwo bei etwa drei Stunden. Opus 4.5 sprang auf rund fünf Stunden -- ein gewaltiger Sprung. Die Kurve ist exponentiell.

Dann kam im Januar Opus 4.6 und verdoppelte das Ganze noch einmal grob, auf etwa zwölf Stunden. Diesen Unterschied spürt man wirklich, wenn man damit arbeitet. Große, komplexe Aufgaben, die KI vorher schlicht nicht bewältigen konnte, sind jetzt in Reichweite.

Die Aufgabenlänge verdoppelt sich alle sechs Monate

Das Muster ist eindeutig: Die Aufgabenlänge verdoppelt sich ungefähr alle sechs Monate. Was sich vorher unmöglich anfühlte, wird schnell zur neuen Normalität.

Als ich das sah, habe ich sofort auf den 100-Dollar-pro-Monat-Plan upgegradet. Das ist eine Verfünffachung der Ausgaben, und es gab null internes Hin und Her. Der Wert war offensichtlich.

Wofür ich Agenten einsetze

Lass mich die konkreten Use Cases durchgehen. Ich nutze Agenten für:

• Features mit Tests entwickeln -- das tägliche Brot.
• UX-Testing mit dem Playwright MCP Server -- automatisiertes, browserbasiertes Testen.
• Infrastruktur-Provisioning mit Terraform -- ich muss nie wieder Terraform-Docs lesen.
• Performance-Optimierung mit dem Dash0 MCP Server -- angebunden an OpenTelemetry-Logs, -Traces und -Metriken. Ich kann sagen "Analysiere meine Performance, schau dir den Code an, können wir automatisch Verbesserungen vornehmen?" und es tut es.
• Ticket-Umsetzung per GitHub CLI -- der Agent liest das Ticket und setzt es um.
• Changelog-Generierung aus Git-Commits.
• Dokumentation mit automatisierten Screenshots -- niemand muss mehr eingestellt werden, um Handbücher zu erstellen.
• Exploratives Testen -- die Produktiv-App auf Bugs testen, inklusive visueller Bugs und der Einhaltung des Design Guides.
• Patentschreiben -- ich habe mit einem Kollegen mithilfe von KI ein Patent geschrieben. Einen Patentanwalt hätten wir uns schlicht nicht leisten können.
• Vertragsprüfung für Enterprise-Kunden.

Die Bandbreite ist enorm. Und sie wächst jede Woche weiter.

Wie sich meine Arbeit verändert hat

Ich schreibe nie mehr Git-Commit-Messages. Ich sage einfach "claude push" und es erstellt die Message aus dem Kontext. Ich schreibe keinen Code mehr -- ich lasse Code schreiben und reviewe ihn dann. Viel. Das ist jetzt meine Haupttätigkeit: Anweisungen geben und reviewen.

Und sei mir nicht böse, ich bin ehrlich: Ich reviewe nicht mehr alles. Ich reviewe selektiv, risikobasiert. Das ist ein Trade-off, und der ist mir bewusst. Aber hier der Spoiler: Ohne diesen Trade-off würde die Software schlicht nicht existieren. Es hätte zu lange gedauert.

Ich arbeite außerdem mit zwei bis drei Terminals parallel, weil es natürliche Wartezeiten gibt, während die KI verarbeitet. Während ein Agent an einer Aufgabe arbeitet, reviewe oder prompte ich in einem anderen.

YOLO-Modus

Seit etwa drei bis vier Wochen habe ich den YOLO-Modus aktiv. Das heißt, Claude darf alles tun, was es will -- außer allem, was Produktion berührt.

Davor hatte ich das Sicherheitsmodell aktiviert, bei dem Claude um Erlaubnis fragt, bevor es Befehle ausführt. Aber ich entwickelte das, was ich "Approve-Müdigkeit" nenne. Die KI hielt ständig an, um triviale Fragen zu stellen wie "Darf ich diesen find-Befehl ausführen?" Ich ertappte mich dabei, einfach Enter zu drücken, ohne den Prompt überhaupt zu lesen. An diesem Punkt ist das Sicherheitsmodell Theater, keine Sicherheit.

Also drehte ich es um: Ich lasse die KI autonom arbeiten, bis sie meint, die Aufgabe sei erledigt. Ich will nicht zurück. Ich wünsche mir trotzdem ein besseres Sicherheitsmodell -- Sicherheit ist nicht irrelevant -- aber das ist aktuell der beste Trade-off für die Produktivität.

Innehalten und reflektieren

Halten wir kurz inne. Das war eine Menge Veränderung, und sie geschah schnell.

Zehn Jahre lang habe ich auf dieselbe Weise gearbeitet. Dann hat sich in nur elf Monaten -- von April 2025 bis März 2026 -- alles verändert. Ich baue immer noch ein Softwareprodukt. Aber wie diese Software entsteht, ist komplett anders.

Und es ist "nur" ein LLM, das Tools in einer Schleife nutzt. Mehr ist es nicht. Und trotzdem hat es alles verändert.

Subagenten und Agenten-Teams

Aber damit hört es nicht auf. Die nächste Evolutionsstufe sind Subagenten: Der Hauptagent erzeugt kleinere Agenten für Recherche-Aufgaben. Zum Beispiel "Finde heraus, wie man diese Library am besten instrumentiert." Der Subagent zieht los, recherchiert und liefert die Ergebnisse zurück. Das schützt den Kontext des Hauptagenten vor Rauschen. Ein Teil davon passiert schon automatisch -- zum Beispiel Claudes eingebauter Researcher.

Darüber hinaus gibt es Agenten-Teams: Du setzt ein Team auf mit einem Architekten, der das Design kritisiert, einer UX-Person, die das Interface kritisiert, und einem Coder, der baut. Du lässt sie interagieren und iterieren. Ich habe das ein- oder zweimal ausprobiert. Es ist noch zu früh für ein Urteil, und es kostet deutlich mehr Tokens. Aber die Richtung ist klar.

Ab in die Cloud

Der Weg führt ganz natürlich in die Cloud. Alles, was ich bisher beschrieben habe, lief auf meinem lokalen MacBook. Aber jetzt gibt es ein Web-Interface. Ich kann Aufgaben vom Handy oder Browser aus starten. Ich kann Arbeit anstoßen, bevor ich schlafen gehe, während ich unterwegs bin oder sogar direkt vor einer Keynote wie dieser hier.

Der Agent arbeitet, und wenn er fertig ist, zeigt er mir so etwas wie "69 Zeilen hinzugefügt, 5 gelöscht". Ich kann die Änderungen reviewen und einen Pull Request erstellen. Der Agent arbeitet, während ich nicht am Schreibtisch sitze.

Event-getriebene Agenten

Auch der Auslöser verändert sich. Es ist nicht mehr nur ein Mensch, der sagt "Mach das." Wenn wir über unsere Observability-Tools einen Alert bekommen, kann ein Agent ihn automatisch auswerten. Wenn es eine Exception ist -- sagen wir, jemand hat in einem Template etwas verwendet, das es nicht gibt -- kann der Agent automatisch einen Fix erstellen und einen Pull Request öffnen. Wir klicken nur noch auf Merge.

Dasselbe gilt für fehlgeschlagene CI-Pipelines, Post-Commit-Checks (etwa die Prüfung, ob die Dokumentation mit dem Code synchron bleibt) und tägliche oder wöchentliche Cron-Jobs für Agenten. All das läuft aus ganz normalen GitHub- oder GitLab-CI/CD-Workflows. Die Agenten werden Teil der Infrastruktur.

Spec-getriebene Entwicklung: Agenten arbeiten, während du schläfst

Inspiriert hat mich eine Stellenanzeige von Anthropic -- die mit 500.000 Dollar pro Jahr, die "maximale Claude-Nutzung" verlangte. Das brachte mich zum Nachdenken: Wie lasse ich Agenten arbeiten, auch wenn ich nicht arbeite?

Die Antwort ist spec-getriebene Entwicklung mit einem Tool namens AutoClaude. Es ist im Grunde ein Kanban-Board-UI: Ich werfe Aufgaben rein, beschreibe sie (die KI kann mir sogar beim Schreiben der Beschreibungen helfen), setze ein Work-in-Progress-Limit von drei und lasse es über Nacht laufen. Ich musste auf den 200-Euro-Plan upgraden, weil die Token-Limits im niedrigeren Plan nicht ausreichten.

Technisch klont es das Repository, erstellt für jede Aufgabe per git worktree einen Branch und arbeitet lokal. Ich starte zehn Aufgaben, bevor ich ins Bett gehe, und reviewe sie am Morgen.

Der Workflow ist: planen, dann coden, dann eine QA-Schleife, dann KI-Review und schließlich menschliches Review. Das Tool generiert eine Spec, erzeugt ein QA-Sign-off und kann sogar dabei helfen, die Produkt-Roadmap zu definieren, durch Wettbewerbsanalyse und das Aufspüren von Feature-Lücken.

Der springende Punkt: Der Agent arbeitet, während ich schlafe, und ich komme morgens zurück, um die Ergebnisse zu reviewen.

Der Qualitäts-Trade-off

Ich will bei etwas Wichtigem transparent sein: Die Qualität ist nicht so hoch wie damals, als ich alles von Hand programmiert habe. Die Architektur ist nicht so sauber. Das Naming könnte besser sein. Der Code ist nicht so geschliffen.

Aber der Punkt ist -- die Software würde ohne KI nicht existieren. Hätte ich darauf bestanden, alles nach meinem früheren Standard zu machen, hätten wir nichts ausgeliefert.

Wenn du in einem Business bist, in dem absolute Perfektion nötig ist -- Flugzeugsteuerungen oder Zugsicherungssysteme bauen -- mag dieser Trade-off nicht funktionieren. Aber für B2B-Business-Software? Das ist mehr als in Ordnung. Der Geschwindigkeitsgewinn überwiegt die Qualitätslücke bei Weitem.

CEO-Perspektive: das KI-Budget

Lass mich die Perspektive wechseln, zu meiner Rolle als CEO. So hat sich unser KI-Budget pro Person und Monat entwickelt:

• 2025: 20 EUR/Person/Monat
• 2026: 100 EUR (eigentlich schon 200)
• 2027: 1.000 EUR (konservative Schätzung)
• 2028: 2.000 EUR

Im Silicon Valley kalkulieren Unternehmen KI-Budgets bereits mit 10-20 % des Gehalts. Das ergibt etwa 20.000 EUR pro Jahr. Sie sind schon dort, wo ich uns 2028 erwarte.

Ist die IDE tot?

Wir werden unsere IntelliJ-Lizenzen nicht verlängern. Wir hatten sogar 50 % Startup-Rabatt. Aber ich sehe den Wert nicht mehr. Ich nutze IntelliJ nur noch aus Gewohnheit und um Codeänderungen zu reviewen. Warum dafür 1.000 EUR pro Jahr zahlen? Claude Code kostet 100 EUR pro Monat und ist eine viel bessere Investition. Es ist eine Frage der Opportunitätskosten. Und da die Community Edition für kommerzielle Nutzung keine echte Option mehr ist, wird die Rechnung noch eindeutiger.

Vor Kurzem sah ich einen LinkedIn-Post von Ralf Müller, der argumentierte, dass "The IDE Is Dead." Er hatte 27 Likes, aber über 53 Kommentare (Update 12. März 2026: 113 Kommentare) -- alle verteidigten ihr IntelliJ, weil sie es lieben. Es ist ein emotionales Thema. Menschen hängen an ihren Tools. Aber diese Bindung sollte keine Budgetentscheidungen treiben.

6 Engineers = 60

Du kannst ein B2B-SaaS-Startup mit nur sechs Engineers bauen. Diese sechs schaffen, wofür früher sechzig nötig waren. Wir werden nicht viele weitere Leute einstellen. Unternehmen werden einen viel höheren Gewinn pro Mitarbeiter sehen. Die Skalierung passiert über KI-Kosten, nicht über Headcount.

Dadurch werden viele kleine Unternehmen entstehen. Wir liefern Features unglaublich schnell, weil unsere Engineers Product Engineers sind, nicht nur Software Engineers. Sie treffen schnelle Produktentscheidungen. Sie verstehen den Kunden. Das ist der entscheidende Unterschied -- die Fähigkeit, Produktentscheidungen an Menschen zu delegieren, die sowohl die Technologie als auch den Kunden wirklich verstehen.

Bauen ist jetzt fast kostenlos. Der eigentliche Engpass ist die Entscheidung, was gebaut werden soll, und das Delegieren der Verantwortung für diese Entscheidungen.

Wen wir einstellen

Wir stellen nur selektiv ein. Unsere Top-Optionen sind:

• Juniors -- sie sind KI-nativ. Sie müssen keine alten Workflows verlernen. Sie sind mit diesen Tools aufgewachsen.
• Principals -- sie bringen Produktfokus, tiefes Kundenverständnis und strategisches Denken mit. Sie sind die Investition wert.
• Seniors -- dritte Wahl. Nicht schlecht, aber in einer KI-nativen Welt sind die anderen beiden Profile wertvoller.

Die größere Chance: Unternehmensdaten

Aber die Chancen sind woanders sogar noch größer. Agentisches Coding nutzt nur Code, Telemetriedaten und Tickets. Als Developers leben wir in unserer Coding-Welt -- aber Business-Leute denken in Daten. Der wirklich spannende Teil ist, wenn du Unternehmensdaten ins Spiel bringst.

Stell dir die Frage vor: "Warum haben die Energiekosten in der Produktion in den letzten zwölf Monaten stärker geschwankt?" (Quelle: BARC) Ein Agent könnte diese Frage in einer Stunde beantworten. Er würde Produktionsdaten analysieren, mit Energiepreisen abgleichen, Schichtmuster betrachten und eine Antwort synthetisieren.

Denk dran: Ein Agent ist immer noch nur ein LLM, das Tools in einer Schleife nutzt. Er kann auch Business-Fragen beantworten -- nicht nur Coding-Fragen. Aber jetzt arbeitet er mit Unternehmensdaten: Kundendaten, Gesundheitsdaten, Finanzdaten, operativen Daten.

Über Tools können Agenten Unternehmensdaten abrufen und alles damit anstellen. Genau hier liegt der echte Wert für die meisten Organisationen.

Der Governance-Layer

Eine Armee von Agenten kommt, und sie alle wollen Zugriff auf Unternehmensdaten. Achtzig Prozent der Mitarbeiter wollen das. Aber es gibt ernsthafte Herausforderungen zu lösen:

• Zugriffskontrolle -- wer darf auf was zugreifen?
• Auffindbarkeit -- wie finden Agenten die richtigen Daten?
• Datensemantik -- was bedeuten diese Daten eigentlich?
• Nutzungsbedingungen -- unter welchen Bedingungen dürfen diese Daten genutzt werden?
• Datenqualität -- wie verlässlich sind diese Daten?
• SLAs und Garantien -- welche Performance und Verfügbarkeit sind zu erwarten?

Du brauchst einen Governance-Layer zwischen den Agenten und den Unternehmensdaten und -APIs. Ohne ihn blockierst du die Agenten entweder komplett oder erzeugst einen Sicherheits- und Compliance-Albtraum.

Live-Demo: Agenten treffen auf Unternehmensdaten

Lass mich eine Live-Demo zeigen. Ich frage den Agenten: "Welche Support-Tickets kommen am häufigsten vor?"

Der Agent sucht nach verfügbaren Datenangeboten und findet eine relevante Tabelle in einer Datenbank. Er fragt Zugriff an -- der automatisch freigegeben wird, da es sich um nicht-sensible Daten handelt. Dann führt er SQL-Queries aus und analysiert die Daten aus mehreren Perspektiven.

Das Ergebnis: Incidents machen 40 % der Tickets aus, gefolgt von Requests, dann Problems und schließlich Changes. Von hier aus könnte der Agent weiterarbeiten -- tiefer bohren, mit anderen Datenquellen abgleichen oder Empfehlungen generieren. Der Governance-Layer macht all das möglich und hält es zugleich sicher und kontrolliert.

Ein Aufruf an die Architekten

Architekten. Du.

Das ist im Kern ein Software-Architektur-Problem. Es geht um Qualitätsziele, Komponentenintegration, Schnittstellenmanagement, Sicherheitsgrenzen und Organisationsdesign. Es ist wahrscheinlich die wichtigste Architekturaufgabe der nahen Zukunft.

Die Agenten darüber sind nur so gut wie dieser Governance-Layer darunter. Ohne ordentliche Data Governance können Agenten entweder nicht arbeiten oder es kann ihnen nicht vertraut werden.

Mein Appell: Wenn es in deiner Organisation eine Initiative gibt, diesen Layer zu bauen, mach mit. Hilf, ihn zu gestalten. Er wird die Zukunft bestimmen. Denn die Agenten kommen -- das ist schlicht zu mächtig und zu nützlich, als dass es nicht passieren würde.