Hochbegabt und leicht dümmlich – Die Superkräfte: Was KI-Agents in der Entwicklung wirklich leisten

Teil 2 der Serie „Hochbegabt und leicht dümmlich – Wie KI-Agents unsere Softwareentwicklung verändern"

Unsere Widget Builder Oberfläche – die stand gefühlt bei jedem Dienstags-Meeting auf der Liste. Müssten wir mal neu machen. Wissen wir. Aber dann kam das nächste Kundenprojekt, der nächste Sprint, und das Thema rutschte wieder nach hinten. Wir haben immer nur mal hier und da ein bisschen was verbessert - immer einen kleinen Schritt weiter.

Irgendwann habe ich dann einfach angefangen. Nicht weil plötzlich Zeit da war, sondern weil ich aus anderen Projekten mit dem KI-Agent schon einiges gelernt hatte – was funktioniert, was nicht, wo man ansetzen muss. Eat your own dogfood: Wenn wir unseren Kunden erzählen, dass KI die Entwicklung beschleunigt, dann sollten wir das auch bei unseren eigenen Produkten zeigen können.

Die Widget-Oberfläche – Warum der erste Anlauf nicht reichte

Der erste Versuch war ernüchternd. Ich habe dem Agent die Aufgabe gegeben, die Oberfläche zu überarbeiten – und das Ergebnis war okay. Nicht schlecht, aber eben auch nicht das, was ich mir vorgestellt hatte. Der Fehler lag bei mir: Ich hatte gehofft, der Agent errät meine unausgesprochenen Vorstellungen. Hat er natürlich nicht. Unser hochbegabter Kollege ist kein Gedankenleser.

Der Durchbruch kam mit einer simplen Frage: Wie würde ich das einem brillanten, aber ahnungslosen Praktikanten erklären?

Also habe ich die eigentliche Arbeit gemacht: nachdenken.

Zuerst ein Style Guide – teilweise mit KI generiert, aber von mir kuratiert und entschieden. Dann Mockups. Mehrere Varianten, gegeneinander angetreten, verglichen, verworfen, verfeinert. Bis eine Vorlage stand, mit der selbst unser dümmlicher Kollege arbeiten konnte.

Ab da hat der Agent innerhalb weniger Stunden eine komplett neue Oberfläche gebaut. Sauber strukturiert, am Style Guide orientiert, nachvollziehbar umgesetzt. Klar brauchte es danach noch Feinarbeit – Kanten glätten, Details justieren. Aber das Projekt, das monatelang auf der Liste stand, war in wenigen Tagen erledigt.

Die Lektion: Die KI wird nicht besser durch ein besseres Modell. Sie wird besser durch bessere Vorgaben. Der Aufwand verschiebt sich – weg vom Coden, hin zum Denken und Spezifizieren.

Kurze Anmerkung: Das sind natürlich nicht alle Erkenntnisse, die die KI besser machen. Aber wenn ich hier alles aufschreibe, wird der Artikel einfach zu lang. Mehr Wissen gibts dann in Projekten mit uns 😄

Vom KI-Dialog zum MCP-Server: Wie Widget-Generierung erwachsen wurde

Die Arbeit an der Oberfläche hat mich auf eine Idee gebracht: Wenn die KI Widgets so gut umbauen kann – kann sie auch neue erzeugen?

Der erste Ansatz war pragmatisch: ein KI-Dialog direkt in unserer Oberfläche. Optionen auswählen, Prompt eingeben, ein N8N-Workflow generiert im Hintergrund das Widget. Hat funktioniert.

Aber dann wurde klar: Da geht mehr. Wenn die ganze Oberfläche per KI steuerbar wäre – nicht nur die Generierung, sondern auch Testen, Konfigurieren, Validieren – dann hätten wir ein anderes Werkzeug in der Hand.

Daraus ist unser MCP-Server für den Widget-Builder entstanden. MCP – Model Context Protocol – ist eine Sammlung von API-Endpunkten, die einer KI alles an die Hand geben, was sie braucht: Welche Funktionen gibt es? Wie ist ein Widget aufgebaut? Welche Regeln gelten?

In der Praxis: Ein Produktmanager beschreibt in normaler Sprache, was er braucht. Der Agent generiert daraus ein funktionierendes Widget. Was früher einen Prototyping-Zyklus von Tagen bedeutete, passiert jetzt in Minuten. „Können wir mal testen, wie das aussieht?" ist kein Aufwand mehr – es ist ein Prompt.

Wenn die KI sich selbst überprüft

Eine Erkenntnis, die banal klingt, aber alles verändert hat: KI-Entwicklung wird erst dann richtig gut, wenn der Agent seine eigenen Ergebnisse validieren kann.

Lange habe ich den Output manuell geprüft. Der Agent generiert, ich schaue drüber. Funktioniert, skaliert aber nicht.

Der Wendepunkt war Playwright – ein Tool für automatisierte Browser-Tests. Der Agent öffnet einen Browser, klickt sich durch die Anwendung, prüft ob alles funktioniert, meldet das Ergebnis zurück. Kein theoretisches „sollte passen", sondern ein echter Test mit echtem Browser.

Was das verändert hat: Ich traue mich jetzt, dem Agent größere Aufgaben zu geben. Weil ich weiß, dass offensichtliche Fehler nicht durchrutschen. Und was wir in einem Projekt an Validierungsstrategien aufbauen, lässt sich direkt im nächsten wiederverwenden.

Azure-Kosten: Was seit Monaten unbemerkt mitlief

Cloud-Kosten kennt jeder: Man sollte sie im Blick behalten, tut es aber selten gründlich genug. Zu viele Services, zu viele Stellen, an denen sich unbemerkt Kosten aufbauen.

Ich habe den Agent auf unsere Azure-Infrastruktur losgelassen – mit einem strukturierten Prompt: Infrastruktur erklärt, Suchkriterien definiert. Ungenutzte Ressourcen, überdimensionierte Instanzen, verwaiste Storage-Accounts.

Das Ergebnis war unangenehm erhellend. Ein App Service Plan, der seit einem Umzug auf einer zu hohen Stufe lief. Storage-Accounts ohne aktive Nutzung. Ressourcen-Gruppen mit Überresten aus Testprojekten. Alles Dinge, die einzeln nicht auffallen – aber in Summe kosten. Systematisch hat der Agent jede Zeile durchgearbeitet, ohne Ermüdung, ohne den Überblick zu verlieren.

Die Ersparnis war signifikant genug, um den KI-Einsatz mehrfach zu refinanzieren. Und das war der erste Durchlauf.

Netzwerkanalyse: Was wir für sauber hielten

Eine unserer Umgebungen hat über Monate immer wieder Probleme gemacht. Nichts Dramatisches, aber hartnäckig genug, um regelmäßig aufzufallen. Wir haben hier geschaut, dort geprüft – den Fehler aber nie richtig eingrenzen können. Irgendwann habe ich den Agent einmal die gesamte Netzwerkkonfiguration analysieren lassen. Firewall-Regeln, Routen, DNS, alles auf einmal. Innerhalb von Minuten hatte er die Ursache gefunden. Der Unterschied: Der Agent sieht die gesamte Konfiguration gleichzeitig und gleicht sie gegeneinander ab. Das ist kein Fachwissen-Vorteil, das ist ein Kapazitäts-Vorteil.

Was im Alltag am meisten Zeit spart

Neben den großen Projekten sind es die kleinen Dinge, die sich summieren:

Dokumentation: Der Agent klickt sich durch unser Produkt, macht Screenshots, baut daraus eine strukturierte Anleitung. Was mich sonst einen halben Tag kostet – ein Prompt.

Übersetzungen: Kontextbewusst, mit konsistenter Fachterminologie über das gesamte Produkt. Kein Vergleich zu dem, was Google Translate ausspuckt.

Skripte: „Schreib mir ein Skript, das X tut" – der Agent liefert das Skript mit Fehlerbehandlung und einem Vorschlag, wie es in die bestehende Pipeline passt.

Der Projektleiter, der Code anfasst. Durch die KI-Unterstützung kann bei uns jemand ohne tiefe Programmierkenntnisse kleine Anpassungen vornehmen. Die KI erklärt den Code, schlägt die Änderung vor, prüft sie. Das hat die Teamdynamik verändert – auf eine Art, die keiner erwartet hatte.

Wo die Stärke wirklich liegt

Nach mehreren Wochen im Echtbetrieb wird ein Muster sichtbar. Der Agent programmiert nicht „besser" als ein Entwickler. Nicht bei Architekturentscheidungen, nicht bei domänenspezifischer Logik, nicht bei allem, was Erfahrung erfordert.

Seine Stärke ist eine andere: Er arbeitet große Mengen an Code und Konfiguration in einer Geschwindigkeit durch, die kein Mensch schafft. Er findet Inkonsistenzen, die unter Zeitdruck untergehen. Er wendet Best Practices nicht „meistens" an, sondern jedes Mal. Und er prüft seine eigene Arbeit, bevor ich es tun muss.

Unsere Code-Qualität ist messbar gestiegen – weil der Agent jeden Pull Request gegen unsere Standards prüft und nichts durchrutschen lässt.

Aber genau die Eigenschaft, die ihn so stark macht – er tut was man ihm sagt, ohne Wenn und Aber – ist auch seine größte Schwäche. Darüber reden wir in Teil 3.

Nächste Woche: Die Geschichte vom Abwesenheitsassistenten, der eigenständig Verträge verhandelt hat – und warum das Ergebnis fachlich einwandfrei und trotzdem ein Desaster war.

🔧 Tech Corner: Vom KI-Dialog zum MCP-Server

Für alle, die es genau wissen wollen.

Die Evolutionsstufen

Unsere Widget-Generierung hat drei Stufen durchlaufen – und jede hat uns etwas Wichtiges gelehrt:

Stufe 1: KI-Dialog in der Oberfläche Ein einfaches Chat-Interface in unserem Produkt. Der Nutzer wählt Optionen, gibt einen Prompt ein, ein N8N-Workflow im Hintergrund verarbeitet die Anfrage und generiert ein Widget. Funktional, aber begrenzt – die KI konnte nur das, was wir explizit als Workflow abgebildet hatten.

Stufe 2: MCP-Server Der Sprung von „KI bekommt eine Aufgabe" zu „KI hat Zugriff auf ein ganzes Werkzeugset". Statt vorgefertigter Workflows stellen wir API-Endpunkte bereit, die der Agent flexibel kombinieren kann:

┌─────────────────────────────────────────────────┐
│  MCP-Server: Widget-Builder                     │
│                                                 │
│  API-Endpunkte:                                 │
│  ├── /widgets/create     → Widget anlegen       │
│  ├── /widgets/configure  → Parameter setzen     │
│  ├── /templates/list     → Vorlagen abrufen     │
│  ├── /styleguide/get     → Design-Regeln laden  │
│  └── /docs/reference     → Dokumentation lesen  │
│                                                 │
│  + Kontextinformationen:                        │
│  ├── Was funktioniert, was nicht                 │
│  ├── Grundlegende Anweisungen & Regeln          │
│  └── Bekannte Einschränkungen                   │
└─────────────────────────────────────────────────┘

Stufe 3: Selbstvalidierung Der entscheidende Schritt: Der Agent kann mit Playwright einen Browser öffnen und seine eigene Arbeit testen – wie ein echter Nutzer. Erst dadurch wird der Kreislauf geschlossen: Generieren → Testen → Korrigieren → Fertig.

Die Prompt-Bibliothek: Basis vs. Spezialisierung

Unsere Prompt-Bibliothek im Git-Repository ist in zwei Ebenen aufgebaut:

Ebene 1 – Basis-Prompts (werden immer geladen):

/prompts
  /base
    coding-standards.md     → Code-Konventionen, Naming, Patterns
    git-workflow.md         → Wie Issues und PRs erstellt werden
    documentation-style.md  → Wie Dokumentation aussehen soll
    security-rules.md       → Was der Agent NICHT darf

Ebene 2 – Spezialisierte Prompts (werden je nach Aufgabe geladen):

/prompts
  /specialists
    widget-generator.md     → Widget-Struktur, Komponenten, Styling
    code-reviewer.md        → Review-Kriterien, häufige Fehler
    network-analyst.md      → Netzwerk-Topologie, Sicherheitsregeln
    cost-optimizer.md       → Azure-Services, Pricing, Benchmarks

Beispiel: Widget-Generator-Prompt (vereinfacht)

Du bist ein Frontend-Spezialist in unserem Team.

## Dein Basiswissen
[Basis-Prompt: coding-standards.md wird automatisch geladen]
[Basis-Prompt: git-workflow.md wird automatisch geladen]

## Deine Spezialisierung
Du generierst Widgets für unser Dashboard-System.
Jedes Widget folgt dieser Struktur:
- Komponente: [Framework-spezifische Details]
- Styling: Nutze ausschließlich unser Design-System
- Daten: Verwende das Standard-Datenmodell
- Tests: Schreibe mindestens einen Integrationstest

## Deine Aufgabe
[Wird pro Anfrage dynamisch befüllt]

## Regeln
- Erstelle für jede Änderung ein GitHub Issue BEVOR du Code schreibst
- Begründe jede Designentscheidung im Issue
- Erstelle einen PR mit referenziertem Issue
- Fasse KEINE bestehenden Dateien an, die nicht zu deiner Aufgabe gehören

Warum Selbstvalidierung alles verändert

Ohne Validierung liefert der Agent Code, der plausibel aussieht. Mit Validierung liefert er Code, der funktioniert. Der Unterschied klingt klein, ist in der Praxis aber enorm. Erst wenn der Agent seinen eigenen Output testen kann, traut man sich, ihn auf größere Aufgaben loszulassen – weil man weiß, dass offensichtliche Fehler nicht durchrutschen.

In Teil 3 zeigen wir im Tech Corner, was passiert, wenn die Grenzen trotzdem nicht ausreichen – und warum System-Regeln außerhalb der KI manchmal wichtiger sind als der beste Prompt.

Agent-Akte #2: Die Superkräfte Was: KI-Agent im produktiven Einsatz über mehrere Wochen Ergebnis: Widget-Oberfläche komplett erneuert (in Tagen statt Monaten), MCP-Server für Widget-Generierung gebaut, Azure-Kosten reduziert, Netzwerkfehler gefunden, automatisierte Dokumentation Lektion: Die KI wird nicht besser durch ein besseres Modell – sondern durch bessere Vorgaben. Der Aufwand verschiebt sich vom Coden zum Denken und Spezifizieren. Und der echte Hebel entsteht, wenn der Agent seine eigene Arbeit validieren kann.

Dies ist Teil 2 der vierteiligen Serie „Hochbegabt und leicht dümmlich". Teil 1: „Der neue Kollege" | Teil 3: „Die Fails" erscheint nächste Woche.