Einblicke in die KI-Entwicklung nach zwei Monaten bei einem Tech-Giganten

Hintergrund

Auslöser waren mehrere Einzelgespräche mit meinem Team Lead. Er interessierte sich dafür, wie ich KI-Tools nutze, persönliche Harnesses aufbaue und meinen AI-Coding-Workflow strukturiere. Vor allem deshalb, weil ich Anforderungen schnell und zuverlässig umsetze und bereits bei einigen Projekten als Hauptverantwortlicher agiere. Also habe ich die Gelegenheit genutzt, meinen täglichen KI-Workflow zu ordnen. Aktuell entwickle ich in meiner Gruppe hauptsächlich Agents und pflege gleichzeitig bestehende Backend-Geschäftslogik.

Zuvor hatte ich ähnliche Workflows auf Xiaohongshu geteilt. Damals war der Kontext, dass GPT-5.4 und Opus 4.6 Aufgaben bereits gut erledigen konnten, wenn man ihnen präzisen Kontext und sinnvolle Einschränkungen mitgab. Der Aufstieg von Harness Engineering hat allen klargemacht: Man kann leistungsstarke Modelle besser steuern, indem man Constraints hinzufügt.

Skills wie Superpowers bieten beispielsweise eine relativ schwergewichtige Umsetzung, die sich hauptsächlich um Spec und TDD dreht und dabei hilft, Aufgaben leichter zu strukturieren und voranzutreiben.

Das hat allerdings auch Nachteile. Am deutlichsten spürt man das beim Token-Verbrauch: Er steigt extrem schnell an. Skills wie Superpowers enthalten viele Workflows, die dazu dienen, den nächsten Schritt des Modells einzuschränken. Selbst wenn ein bestimmter Schritt aus globaler Sicht gar nicht mehr nötig wäre – etwa weil der Kontext bereits ausreicht und direkt mit der Implementierung begonnen werden könnte –, arbeitet das Modell oft stur den vorgegebenen Prozess ab.

Mit dem Release neuer Modelle sehe ich immer mehr Entwickler, die berichten, dass sie diese sehr schweren Skills kaum noch nutzen. Ein Hauptgrund: Wenn die Fähigkeiten der Modelle wachsen, werden manche Einschränkungen und Prozesse, die wir früher für nützlich hielten, plötzlich zu Rauschen für das Modell. Als OpenAI zum Beispiel Astra veröffentlichte, gab es extra einen Blogpost darüber, wie man unnötige Skills und System-Prompts aufräumt, um das Nutzungserlebnis zu verbessern.

In diesem Artikel möchte ich daher meine Erfahrungen der letzten Monate zusammenfassen und Methoden teilen, die für mich aktuell gut funktionieren. Es geht darum, wie man verschiedene Agents besser nutzt, um die tägliche Entwicklungseffizienz zu steigern.

1. Meine am häufigsten genutzten Skills und Prompts

Meine aktuelle Werkzeugverteilung:

Derzeit nutze ich hauptsächlich Codex + GPT-5.6 Sol für die Code-Implementierung und Astra für die Planung. Bevor Astra erschien, lag die Planungsarbeit vor allem bei GPT-5.6 Sol Max.

Für einfache Anforderungen setze ich pi + DeepSeek V4 Flash zur Umsetzung ein; das Adversarial Review von Lösungen sowie Code Reviews übernimmt größtenteils Claude 5 Fable. In privaten Projekten verwende ich zudem das webbasierte GPT-6 Pro für das grundlegende Lösungsdesign.

Meine am häufigsten genutzten Skills

1. think: Ein Skill von tw93, hauptsächlich für Solution Alignment und Brainstorming.
2. grill me / grill with docs: Dient vor allem der Klärung von Anforderungen. Durch gezieltes Nachfragen werden Ziele, Einschränkungen und Trade-offs herausgearbeitet und je nach Entwicklungsprozess in ADR oder CONTEXT.md festgehalten. Das hilft mir, Punkte aufzudecken, die beim frühen Alignment übersehen wurden.
3. implement: Wird in Kombination mit grill genutzt, ist Teil der Skills-Suite von Matt Pocock und dient dazu, klar definierte Pläne oder Issues umzusetzen.
4. ponytail: Rämt Over-Engineering durch die KI auf und erleichtert so das Review. Ich nutze das häufig, da GPT-5.6 Sol gerne mal über das Ziel hinausschießt.
5. handoff: Überführt den aktuellen Kontext in Dateien, damit Aufgaben in neuen Sessions nahtlos fortgesetzt werden können. Ich nutze es meist, um von Codex zu Claude Code oder zum pi agent zu wechseln.
6. check: Für Code Reviews, typischerweise beim Erstellen von MRs.
7. Eigene Skills aus Arbeit und Privatprojekten: Hauptsächlich wiederverwendbare Prozess-SOPs, etwa für End-to-End-Tests. Mein Tipp: Wenn ein Prozess im Arbeitsalltag mehr als dreimal wiederholt wird, sollte man ihn von Codex in ein Skill überführen lassen, damit er später direkt wiederverwendet werden kann.

Meine am häufigsten genutzten Prompts

Ich schreibe heute kaum noch lange Prompts selbst. Wenn es nötig ist, lasse ich sie meist von Codex strukturieren. Wenn ich zum Beispiel nach mehreren Diskussionsrunden den aktuellen Kontext an GPT Pro für das Lösungsdesign übergeben möchte, lasse ich zuerst von Codex einen vollständigen Handoff-Prompt erzeugen.

Darüber hinaus nutze ich regelmäßig folgende Arten von sehr kurzen Prompts.

Manchmal entfalten sie eine Wirkung nach dem Motto „Ein Satz ersetzt tausend Worte“. Ich verstehe sie als „Denkabkürzungen“ für das Modell.

Es sind keine Zaubersprüche, sondern hochgradig standardisierte Methodiken aus dem menschlichen Wissen. Während des Trainings hat das Modell unzählige Papers, Codebeispiele, Designdokumente und Diskussionen dazu gesehen. Deshalb muss man oft keine hunderten Zeilen Workflow per Hand schreiben, sondern ihm nur sagen, welche Denkmethode es anwenden soll. Hier einige Prompts, die sich in der Praxis für mich bewährt haben:

• First Principles (Erste Prinzipien): Nicht einfach die bestehende Lösung weiter optimieren, sondern neu fragen, wie das Problem eigentlich gelöst werden sollte. Wenn ein Interface langsam ist, kannst du zum Beispiel sagen:

Entwirf nicht weiter auf Basis der festgelegten Lösung „Redis-Cache hinzufügen“. Analysiere aus ersten Prinzipien, warum dieses Interface langsam ist und was die minimal notwendige Lösung wäre.

Der Fokus des Modells verschiebt sich dann von „Wie sollte Redis designed werden?“ zu:

Liegt der Flaschenhals in SQL, Netzwerk, Serialisierung, Lock Contention oder wiederholten Berechnungen? Wenn ein Index in SQL reicht, warum sollten wir dann Redis einführen?

Diese Art von Prompt eignet sich besonders, wenn du vermutest, dass „die Fragestellung selbst falsch sein könnte“.

• Adversarial Review: Suche keine Gründe, die für meine Lösung sprechen, sondern versuche zu beweisen, dass sie falsch ist.

Die übliche Formulierung wäre:

Hilf mir zu prüfen, ob es Probleme mit dieser technischen Lösung gibt.

Besser ist:

Führe ein Adversarial Review dieser Lösung durch und suche gezielt nach Gegenbeispielen, die die Kernannahmen widerlegen könnten.

Nehmen wir an, deine Lösung lautet „Distributed Locks einführen, um doppelte Requests zu verhindern“. Dann sagt dir das Modell nicht mehr nur, wie du das Lock-Timeout setzen sollst, sondern fängt an zu fragen:

Brauchen doppelte Requests wirklich gegenseitigen Ausschluss? Reicht Idempotenz des Interfaces? Was passiert, wenn der Lock-Service abstürzt? Was, wenn der Lock abläuft, aber die Geschäftslogik noch nicht fertig ist? Haben wir einen lokalen Fehler durch einen neuen verteilten Single Point of Failure ersetzt?

Solche Prompts eignen sich hervorragend für Solution Reviews und Code Reviews.

• Ablation Experiments (Ablationsstudien): Nur weil das System besser geworden ist, heißt das nicht, dass jede deiner Änderungen sinnvoll war.

Angenommen, du hast drei Optimierungen gleichzeitig vorgenommen:

Nach dem Hinzufügen von Indizes, Redis-Cache und Batch-Queries sank die Latenz des Interfaces von 800ms auf 100ms.

Dann kannst du direkt fragen:

Entwirf Ablationsstudien für diese drei Optimierungen, um herauszufinden, woher der tatsächliche Gewinn stammt.

Das Modell entwirft Kontrollgruppen für verschiedene Kombinationen, ausgehend von einer Baseline, und vergleicht: nur Indizes, Indizes + Cache, Indizes + Cache + Batch-Queries usw.

Am Ende stellt es vielleicht fest:

Allein die Indizes haben die Latenz bereits von 800ms auf 120ms gesenkt, die beiden anderen komplexen Maßnahmen brachten nur weitere 20ms.

So weißt du viel genauer, welcher Code bleiben darf und welche Komplexität vermutlich überflüssig ist.

• Occam's Razor (Ockhams Rasiermesser): Bei ähnlicher Wirkung haben Lösungen mit weniger Annahmen und geringerer Komplexität Vorrang.

Wenn der Agent zum Beispiel so etwas entwirft:

Kafka + Redis + Distributed Lock + State Machine + Timed Compensation.

Kannst du ergänzen:

Überprüfe dieses Design nochmals mit Ockhams Rasiermesser und entferne alle nicht zwingend notwendigen Mechanismen, solange die Anforderungen erfüllt bleiben.

Oft kommt es dann zu dem Schluss:

Im aktuellen Szenario gibt es nur Schreibvorgänge in einer einzigen Datenbank – eine Transaktion plus Unique Index reichen völlig aus.

Dieser Satz ist besonders bei heutigen Coding Agents Gold wert, denn Modelle neigen leicht zum Over-Engineering, um „vollständig“ zu wirken.

• High Cohesion, Low Coupling (Hohe Kohäsion, lose Kopplung): Verantwortlichkeiten und Grenzen im Code neu prüfen.

Wenn dein OrderService beispielsweise schon 2000 Zeilen hat, kannst du fragen:

Prüfe die Verantwortungsgrenzen des OrderService nach den Prinzipien hoher Kohäsion und loser Kopplung. Teile nichts auf, nur um des Aufteilens willen.

Das Modell beginnt dann meist zu prüfen:

Warum kümmert sich der Order-Service gleichzeitig um Lagerbestand, Coupons, SMS, Zahlungen und Reports? Welche Logik gehört wirklich zur Order-Domäne und was sollte über stabile Schnittstellen an andere Module abgegeben werden?

Dadurch wird nicht einfach nur „die Datei aufgeteilt“, sondern ein ganzes Set an Überlegungen zu Modularisierung, Information Hiding, Abhängigkeitsrichtungen und Zuständigkeiten aktiviert.

Deshalb schreibe ich kaum noch:

Schritt 1: Anforderungen analysieren, Schritt 2: Annahmen prüfen, Schritt 3: Alternativen suchen, Schritt 4...

Viele etablierte Methodiken hat das Modell längst gelernt. Ich sage ihm lieber direkt:

Analysiere neu aus ersten Prinzipien und führe ein Adversarial Review der aktuellen Lösung durch; Kernmechanismen müssen durch Ablationsstudien verifiziert werden; die Lösung folgt Ockhams Rasiermesser, der Code bleibt hoch kohäsiv und lose gekoppelt.

Hinter diesen wenigen Worten verbergen sich fünf völlig unterschiedliche kognitive Anweisungen:

Problem neu definieren → Annahmen angreifen → Beiträge verifizieren → Komplexität streichen → Systemgrenzen ordnen.

Genau darin sehe ich den Wandel von Prompt Engineering im Zeitalter der neuen Modelle: Statt dem Modell einen starren Denkprozess vorzuschreiben, ist es besser, ihm mit präzisen Methodiken zu sagen, „wie es denken soll“, und dann nur die für die aktuelle Aufgabe wirklich nötigen Einschränkungen zu ergänzen.

2. Mein täglicher Entwicklungsworkflow

Nachdem ich eine Anforderung erhalten habe, gebe ich dem Agenten zunächst den relevanten Kontext – PRD, Meeting-Notizen, Chat-Verläufe, Nutzerfeedback – und nutze dann grill, um die Anforderungen mit ihm abzugleichen.

Diese Materialien bilden selten eine vollständige, widerspruchsfreie Anforderung. Das PRD ist vielleicht veraltet, Einschränkungen wurden erst im Meeting ergänzt, Prioritäten im Chat verschoben. Auch mein eigenes Verständnis enthält oft unausgesprochene Annahmen.

Ich lasse den Agenten diese Unterlagen zusammen mit dem Team-Wiki und dem bestehenden Code verarbeiten und kläre dann durch gezieltes Nachfragen Ziele, Grenzen und Trade-offs, die die Umsetzung beeinflussen. Manche Fragen kann ich sofort beantworten, bei anderen muss ich erst Rücksprache mit dem Produktmanagement oder Kollegen halten.

Dabei halte ich mich an eine Faustregel: Sobald die offenen Fragen die Umsetzungsrichtung und die Abnahmekriterien nicht mehr wesentlich verändern, kann die Entwicklung starten.

Ich verlange nicht, dass alle Implementierungsdetails vorab geplant werden – sonst wird allein das Requirements Alignment zum Mammutprojekt.

Die Ergebnisse des Alignments fließen in Spec oder CONTEXT.md. Dort werden vor allem das zu lösende Problem, der Scope, wichtige Entscheidungen und Abnahmekriterien festgehalten. So arbeiten auch die nachfolgenden Agents für Implementierung und Review mit demselben Kontext, ohne alle bisherigen Gespräche neu lesen zu müssen.

Sobald die Lösung steht, entscheidet der Haupt-Agent je nach Komplexität über die Ausführung. Einfache Anforderungen werden direkt umgesetzt; komplexe werden in Issues mit klaren Grenzen zerlegt, die unabhängig abgenommen werden können. Nur Teile, die eigenständig bearbeitet werden können, gehen an Subagents, die parallel in verschiedenen Worktrees entwickeln. Die Integration übernimmt am Ende der Haupt-Agent.

Der Coding Agent schreibt zuerst die Tests. Wenn er meint, lieferfertig zu sein, schalte ich je nach Komplexität weitere Agents für ein Cross-Adversarial-Review hinzu. Gefundene Probleme werden gebündelt an den Haupt-Coding-Agenten (also Codex) zurückgegeben, der sie behebt und erneut prüft.

Vor meinem eigenen Review führe ich zusätzlich End-to-End-Tests durch.

Ich lese mittlerweile nicht mehr den gesamten generierten Code Zeile für Zeile, sondern konzentriere mich auf Testergebnisse und die Kern-Geschäftslogik. Eine wichtige Voraussetzung dafür: Jeder MR ist klein genug im Scope, und vollständige Geschäftspfade werden im Laufe der Entwicklung schrittweise verifiziert.

Kleine MRs sorgen dafür, dass die Menge an Änderungen, die ich verstehen und bewerten muss, überschaubar bleibt; End-to-End-Tests zeigen, ob diese Änderungen auch im echten Geschäftsprozess standhalten. Beim manuellen Review prüfe ich vor allem die Business-Logik und ob die vorhandenen Testergebnisse für diese Lieferung ausreichen.

3. Wie man Agent-freundliche End-to-End-Tests aufbaut

KI ist bereits sehr gut darin, Testfälle zu schreiben – oft entstehen hunderte Zeilen Tests für einen simplen Bugfix (besonders bei 5.6 sol). Mehr Tests zu schreiben ist grundsätzlich kein Problem, aber nach Deployment und Launch stoßen wir trotzdem immer wieder auf unerwartete Fehler.

In meiner Praxis liegt ein Kernproblem darin: Wir geben dem Agenten keine End-to-End-Testumgebung, in der er diese Probleme schon während der Entwicklung und beim Selbsttest finden könnte.

Wenn wir eine solche Umgebung schaffen, in der der Agent bequem vom echten Einstiegspunkt der Testumgebung aus arbeiten und alles bis zu den Ergebnissen prüfen kann, die der Nutzer braucht, können wir KI-generierten Code viel ruhiger in echten Systemen laufen lassen.

In der Praxis habe ich für unser Business ein Set an End-to-End-Entwicklungstestumgebungen aufgebaut. Der Agent kann bequem Datenbanktabellen und Logs abfragen und sich zur Fehlersuche auf Maschinen verbinden.

Im Kern bedeutet der gesamte Aufbau, dass der Agent meine täglichen Selbsttests extrahiert und verstreute Tools und Fähigkeiten integriert: Was sich als Tool abbilden lässt, wird zu MCP oder CLI; wiederverwendbare Prozesse werden in Skills geschrieben.

Das kostet anfangs natürlich etwas Mühe, aber scheut den Aufwand nicht. Ist es einmal aufgebaut, beschleunigt es die Entwicklung enorm, reduziert Nacharbeiten und die Wahrscheinlichkeit von Problemen in Produktion – und du musst dir nicht ständig Sorgen machen, ob der KI-Code einen Ausfall verursacht.

Rund um Agent-freundliche End-to-End-Tests habe ich vor allem vier Dinge umgesetzt:

1. Den Agenten mit der Umgebung vertraut machen: Zum Beispiel Testumgebungen per Klick starten, Testdaten erzeugen, aktuelle Versionen, Test-Accounts und Berechtigungen klären sowie Cleanup- und Reset-Funktionen bereitstellen.
2. Den Agenten Business-Systeme bedienen lassen: Echte Geschäftsprozesse über Browser, APIs oder CLIs ausführen.
3. Dem Agenten bequemen Zugriff auf Datenbanktabellen und Logs geben: Speichergebgebnisse über Read-only-Datenbank-MCP bestätigen, Probleme über Log-System-Skills und Trace-Queries lokalisieren.
4. Lästige, aber stabile Prozesse wiederverwenden: Stabile Abläufe in Skripte auslagern, Einstiegspunkte und Troubleshooting-Methoden in Skills dokumentieren, um manuelle Eingriffe und Dialoge zu reduzieren.

Auf dieser Basis haben sich für mich aktuell folgende Methoden bewährt:

1. Browser-Automatisierung: Wenn Business-Systeme Browser-Interaktionen erfordern, empfehle ich den Open-Source-Browser ego lite. Er ist einfach zu nutzen und schnell. In Kombination mit pi agent + DeepSeek V4 Flash sind Tests relativ zügig abgeschlossen, was Zeit spart.
2. Operationen in einem CLI vereinheitlichen: Wiederverwendbare Skills, konfigurierte MCPs und geschriebene Skripte in einem einheitlichen Test-CLI bündeln, das Funktionen für Umgebungschecks, Datenvorbereitung, Szenarioausführung, Ergebnisabfragen und Cleanup bietet. Das kann auch intern als Effizienz-Tool dienen. Ich habe dieses Set aktuell als CLI umgesetzt, was auch bei der Fehlersuche sehr praktisch ist.
3. Tools direkt für die Abnahme nutzen: DB-Abfragen bestätigen Status, Logs und Traces erklären Fehler – aber die erwarteten Ergebnisse müssen weiterhin aus den Business-Verträgen kommen. Lass den Agenten nicht annehmen, etwas sei korrekt, nur weil das System es so zurückgibt. Bei komplexer Geschäftslogik kann das System problemlos etwas liefern, das plausibel aussieht, aber fachlich falsch ist. Tools helfen uns, Beweise zu sammeln – sie definieren nicht die richtige Antwort für uns.
4. Wenn das Produkt selbst ein Agent ist, auch die Antwortqualität prüfen: Ist das zu testende Produkt selbst ein Agent, reicht es nicht, nur zu prüfen, ob die Prozesse durchlaufen – auch die Qualität der Antworten zählt. Das ist das, was wir oft als Agent Eval bezeichnen, worauf ich hier aber nicht weiter eingehe.

4. Wie man KI-generierten Code reviewed

Die vorherigen Abschnitte haben gezeigt, wie man KI dazu bringt, hochwertigen Code zu schreiben. Letztlich bleibt aber der Entwickler die primär verantwortliche Person für die Geschäftsanforderungen.

Ohne Review kommt es in großen Systemen schnell zu Problemen.

Und niemand möchte mitten in der Nacht für den On-Call rausgeklingelt werden, nur um festzustellen, dass KI-generierter Code der Auslöser war.

Beim Review gehe ich aktuell wie folgt vor:

1. Erst Abnahmekriterien, dann Testergebnisse: Zuerst prüfe ich die vom Agenten definierten Kriterien und gleiche sie mit den vorherigen End-to-End-Testergebnissen ab, um zu sehen, ob Erwartungen erfüllt wurden und ob etwas fehlt. Es geht nicht nur darum, wie viele Tests grün sind, sondern ob diese Tests auch das geprüft haben, was für die Anforderung wirklich wichtig ist.
2. Geschäftspfaden folgen und Energie auf risikoreiche Stellen konzentrieren: Ich prüfe vor allem Berechtigungen, Zustandsänderungen, Nebenläufigkeit, Retries, Datenkonsistenz sowie riskante Bereiche wie Migrationen und Rollbacks. Für stabiles Standard-CRUD nehme ich mir weniger Zeit – manches davon schaue ich mir mittlerweile gar nicht mehr an.
3. Neue Abstraktionen und Mechanismen gezielt prüfen: Bei neu eingeführten Abstraktionen und Mechanismen lasse ich die KI mit Ansätzen wie Ockhams Rasiermesser nochmals prüfen: Sind sie wirklich nötig? Gibt es eine einfachere Umsetzung? Wurde für ein lokales Problem zu viel Komplexität eingeführt?
4. Bei vielen MRs dedizierte Review Bots in Betracht ziehen: Wenn in der Gruppe viele MRs anfallen, lohnt sich ein eigener Review Bot für das Cross-Review. Anders als beim direkten Aufruf von pi agent / Claude Code für ein Adversarial Review (wie oben beschrieben), kombiniert dieser Git-Änderungen mit vordefinierten Review-Prozessen und schafft so eine wiederholbare Review-Fähigkeit speziell für MRs.

5. Einige Zusammenfassungen und Gedanken

Mein größter Engpass in der aktuellen Entwicklung ist die Review-Geschwindigkeit.

Agents können mehrere Aufgaben gleichzeitig vorantreiben, aber meine Geschwindigkeit, das Business zu verstehen, Lösungen zu bewerten und Lieferungen abzunehmen, wächst nicht proportional mit. Wenn man sie einfach nur mehr schreiben lässt, häuft man am Ende vor allem mehr Code an, der auf ein Review wartet.

Deshalb möchte ich als Nächstes erreichen, dass repetitive Probleme erkannt und behoben werden, bevor sie überhaupt bei mir landen.

Fehler, die durch Type Checking, Tests und Business-Assertions auffallen, sollte der Agent möglichst schon während der Entwicklung selbst beheben. Meine Beurteilung brauche ich vor allem für die Fragen: Wurden die Anforderungen richtig verstanden? Hält die Kern-Geschäftslogik? Welche unbestätigten Risiken bleiben in dieser Änderung?

Dedizierte Review Bots können dabei helfen, aber ihr Wert misst sich daran, ob sie echte Übersehensfehler und manuellen Aufwand reduzieren – nicht daran, wie viele Kommentare sie hinterlassen.

Dadurch wird auch mein Verständnis von Harness konkreter: Agents brauchen nicht nur den richtigen Kontext, sondern auch Umgebungen, in denen sie Aufgaben ausführen können, sowie Grundlagen, um Ergebnisse zu bewerten.

Ich habe Abläufe, die ich bei täglichen Selbsttests immer wieder manuell gemacht habe, in CLIs, Skripte und Skills überführt. So kann der Agent Systeme selbst ausführen, Ergebnisse prüfen und Fehlerbeweise finden. Bei zukünftigen, ähnlichen Aufgaben lassen sich diese Fähigkeiten weiter nutzen und schrittweise auch an Kollegen zur Wiederverwendung übergeben.

Gleichzeitig braucht dieser Workflow regelmäßig eine Entschlackungskur.

Manche Schritte gleichen lediglich Schwächen einer bestimmten Modellgeneration aus. Wenn sich die Modelle ändern, muss der Nutzen dieser Schritte neu bewertet werden. Einfache Aufgaben werden direkt erledigt, komplexe bekommen Planung, Aufteilung und Cross-Review. Nach den Astra-Updates habe ich beispielsweise einige zu strikte Einschränkungen in AGENTS.md entfernt. Modelle iterieren – und unsere Workflows müssen entsprechend mitwachsen.

Natürlich reduzieren Tests und Reviews Unsicherheiten, aber die korrekten Abnahmekriterien müssen weiterhin vom Menschen kommen. Selbst wenn Code und Tests perfekt zueinander passen, können beide gemeinsam die Anforderungen falsch verstanden haben. End-to-End-Tests decken nur Verhalten in ausgewählten Umgebungen und Szenarien ab; Traffic, Nebenläufigkeit und Datenverteilung in der Produktion können trotzdem neue Probleme bringen.

Als Entwickler, der gerade erst ins Berufsleben gestartet ist, hoffe ich, durch die Arbeit weiterhin fundiertes Fachwissen aufzubauen. Allerdings nimmt KI mir tatsächlich einige Gelegenheiten, selbst in Fallen zu tappen. Wertvolle Erfahrungen, die man früher durch eigene Fehler und Ursachenforschung gesammelt hat, schrumpfen heute manchmal auf eine Antwort der KI zusammen:

„Da lag ich falsch, ich passe es gerade an.“

Deshalb

reserviere ich mir mittlerweile täglich Zeit zum Lernen und Reflektieren und frage mich: Welche Fähigkeiten brauchen Entwickler im KI-Zeitalter wirklich?

Dieser Artikel hält eine Reihe von Methoden fest, die ich in meinen ersten Monaten schrittweise in meinem Projektbereich entwickelt habe. Wo sie greifen und wo ihre Schwächen liegen, erkunde ich noch.

Jeder kann sich zunächst einen gängigen Selbsttest-Ablauf schnappen, versuchen, ihn vom Agenten eigenständig ausführen zu lassen, die Beweise sichern und anschließend die funktionierenden Schritte als Skill festhalten.

Aufgrund von Vertraulichkeitsrichtlinien meines Unternehmens kann ich viele Details hier nicht nennen. Ich hoffe, dieser Artikel dient als Inspiration, und freue mich darauf, von euren Best Practices aus der echten Entwicklung zu hören~