Eine bestehende Anwendung mit KI weiterentwickeln.

Beschreibe die Änderung aus Sicht des Nutzers.

Auftragsplatz ist unser fiktives Lernprojekt für den Austausch zwischen Auftraggebern und Dienstleistern. Für diesen Artikel nehmen wir eine Ausbaustufe mit bereits vorhandenen Konten und dauerhafter Speicherung an. Mara hat einen Vorschlag als Entwurf gespeichert. Sie möchte einen Satz ändern und danach dieselbe Vorschau mit dem aktualisierten Text sehen. Es soll kein zweiter Vorschlag entstehen.

Halte vor der technischen Planung fest, für welchen Zustand die Bearbeitung gelten soll. Für dieses Beispiel dürfen eigene Entwürfe verändert werden; ein bereits eingereichter Vorschlag bleibt unverändert. Ein fremdes Konto darf Maras Entwurf weder lesen noch bearbeiten.

Diese Regeln geben dem Auftrag eine Richtung. Sie helfen beim Lesen des Projekts und später beim Review. „Bearbeiten hinzufügen“ wäre dagegen zu unbestimmt: Das kann eine neue Oberfläche, einen neuen Datensatz oder einen Eingriff in bestehende Rechte bedeuten. Welche technischen Prüfungen dazugehören, hängt von der tatsächlichen Ausbaustufe ab. Das Anlegen von Konten und Datenbank ist kein zusätzlicher Bestandteil dieses Änderungsauftrags.

Lass den Agenten zunächst das Vorhandene erschließen.

Starte mit den Projektregeln und dem dokumentierten lokalen Ablauf. Welche Befehle bauen und prüfen das Projekt? Wo liegen Vorschlagsformular, Speicherung und Zugriffsprüfung? Welche bestehenden Muster passen zu der gewünschten Änderung?

Bitte den Agenten um eine kurze Analyse mit konkreten Dateiverweisen und offenen Fragen. Überprüfe die entscheidenden Stellen selbst. Eine plausible Zusammenfassung genügt nicht, wenn sie beispielsweise nur die Anzeige im Browser betrachtet und die serverseitige Zugriffskontrolle übersieht.

Halte den Kontext auf das vorbereitete Projekt begrenzt. Produktive Zugangsdaten oder Kundendatensätze sind für diese Übung nicht erforderlich. Wenn du die Methode später in einem Unternehmensprojekt nutzt, müssen Umgebung, Zugriffe und eingesetzte Dienste dafür freigegeben sein.

Passe den folgenden Musterauftrag an dein eigenes, vorbereitetes Entwicklungsprojekt an. Er setzt Konten und dauerhafte Speicherung bereits voraus. Der Artikel beschreibt diese Ausbaustufe als Beispiel; er stellt dafür kein fertiges Repository bereit.

Vereinbare Umfang und überprüfbare Erwartungen.

Aus der Analyse entsteht ein begrenzter Auftrag: den vorhandenen Entwurf laden, den Text bearbeiten, speichern und die aktuelle Vorschau anzeigen. Eine neue Komponentenbibliothek oder ein Umbau aller Formulare folgt daraus zunächst nicht.

Die Erwartungen sollten unabhängig von der späteren Implementierung formuliert sein. Mara ändert einen bekannten Satz; danach zeigt genau ihr vorhandener Vorschlag die neue Fassung. Nach einem Neuladen bleibt sie erhalten. Ein zweites Konto erhält keinen Zugriff auf diesen Entwurf.

Lege außerdem fest, was bei einem Speicherfehler passieren soll. Der bearbeitete Text sollte nicht stillschweigend verschwinden, während die Oberfläche Erfolg meldet. Solche Erwartungen verbinden fachlichen Nutzen und technische Prüfung, ohne jede Codezeile vorzugeben.

Beurteile die Änderung im Kontext des Projekts.

Nach der Implementierung liest du zunächst den Diff als Ganzes: Welche Dateien wurden verändert, und warum gehören sie zum Auftrag? Prüfe anschließend besonders die Übergänge zwischen Oberfläche, gespeichertem Zustand und Berechtigungen.

Führe die relevanten vorhandenen Prüfungen aus und ergänze gezielt fehlende Nachweise. Der erfolgreiche eigene Bearbeitungsweg beantwortet noch nicht, ob fremde oder bereits eingereichte Vorschläge geschützt sind. Die erwarteten Ergebnisse müssen aus deinen Regeln stammen, nicht aus derselben Funktion, deren Verhalten du gerade untersuchst.

Öffne die Anwendung zusätzlich im Browser. Eine technisch korrekte Speicherung kann mit einer missverständlichen Rückmeldung oder veralteten Vorschau verbunden sein. Prüfe, ob Mara die Änderung wahrnimmt und weiß, in welchem Zustand sich ihr Vorschlag befindet.

Übernimm einen Stand, dessen Wirkung du erklären kannst.

Fasse die Änderung aus Sicht eines anderen Entwicklers zusammen: Was kann Mara jetzt tun? Welche bestehenden Regeln bleiben erhalten? Welche Prüfungen wurden tatsächlich ausgeführt? Benenne offene Punkte, statt aus einem grünen Durchlauf eine vollständige Absicherung abzuleiten.

Eine überschaubare Änderung lässt sich leichter besprechen, zurücknehmen und später weiterentwickeln. Größere Folgeaufgaben, etwa das Bearbeiten bereits eingereichter Vorschläge, verdienen einen eigenen Auftrag mit passenden fachlichen Entscheidungen.

So wird KI Teil deiner alltäglichen Entwicklungsarbeit: Sie unterstützt beim Erschließen und Umsetzen, während du die Änderung mit dem Produkt und dem vorhandenen System verbindest. Der Nutzen zeigt sich daran, ob eine passende Funktion entsteht und das Projekt für den nächsten Schritt verständlich bleibt.

• Die Nutzerabsicht und unveränderte Regeln sind beschrieben.
• Projektkontext und betroffene Stellen wurden geprüft.
• Der Diff lässt sich dem vereinbarten Umfang zuordnen.
• Funktion, Berechtigungen und relevanter Fehlerfall sind nachvollziehbar geprüft.
• Änderungsbeschreibung und offene Punkte ermöglichen ein menschliches Review.