Coding-Agenten steuern

Der Product Engineer nutzt Coding-Agenten, um freigegebenes beabsichtigtes Verhalten in funktionierende Software zu überführen, und behält die Verantwortung für das Ergebnis. Die Implementierungsschleife sollte inkrementell, beobachtbar und mit den dauerhaften Projektbeschränkungen vereinbar sein.

Verantwortliche Rolle: Product Engineer.
Teilnehmer: Coding-Agent; Architekt oder UX-Designer, wenn Entscheidungen sie erfordern.
Eingaben: Aktuelle Funktionsspezifikationen, Projektziele, freigegebene Anweisungen und Bausteine, bestehendes Produktverhalten, identifizierte Beschränkungen.
Ergebnisse: Funktionierende Implementierung, zugehörige gewöhnliche automatisierte Tests, aktualisierte Spezifikationen bei Verhaltensänderungen und klare Darstellung offener Probleme.

1. Einen implementierbaren Ausschnitt wählen. Wählen Sie einen zusammenhängenden Satz von Funktionsverhalten mit genügend umgebendem Kontext. Große Funktionen können schrittweise implementiert werden; der Bezug zur maßgeblichen Spezifikation muss erhalten bleiben.

2. Die maßgebliche Quelle bereitstellen. Weisen Sie den Agenten an, dauerhafte Projektanweisungen und relevante Spezifikationen zu lesen. Benennen Sie erforderliches Verhalten, Akzeptanzbedingungen und Grenzen, die nicht bereits aus dem Projektkontext hervorgehen.

3. Implementierung statt unbefugter Richtlinienentscheidungen anfordern. Der Agent darf eine Implementierungsstrategie vorschlagen und vorhandene Komponenten wiederverwenden. Er sollte weder fachliche Berechtigungen erfinden noch neue Abhängigkeiten, Architektur- oder Designsystemkonventionen ohne nötige Freigabe einführen.

4. Funktionierendes Verhalten prüfen. Erproben Sie das Ergebnis selbst mit realistischen Abläufen und repräsentativen Daten. Prüfen Sie Normalfall und wesentliche Ausnahmen. Das Lesen einer Zusammenfassung generierter Dateien entspricht nicht der Validierung der Benutzererfahrung.

5. Mit konkretem Feedback iterieren. Berichten Sie beobachtetes Verhalten und was stattdessen geschehen sollte. Unterscheiden Sie Implementierungsfehler von geänderter Stakeholder-Absicht. Ändert sich beabsichtigtes Verhalten, aktualisieren Sie die Spezifikation vor oder zusammen mit der nächsten Implementierungsiteration.

6. Wartbarkeit erhalten. Verwenden Sie freigegebene Bibliotheken und Komponenten, halten Sie Code verständlich, pflegen Sie regelmäßige automatisierte Prüfungen und vermeiden Sie unnötige Vervielfachung ähnlicher Implementierungen. Beziehen Sie den Architekten bei strukturellen oder sicherheitsrelevanten Folgen außerhalb der Befugnisse des Product Engineers ein.

7. Offene Arbeit klar dokumentieren. Verbergen Sie keine unvollständigen Abläufe, Zugriffsbeschränkungen, fehlgeschlagenen Tests oder nicht freigegebenen Annahmen. Machen Sie diese für anschließende Prüfung und Verifikation sichtbar.

„Implementiere das Verhalten aus Funktionsspezifikation SPEC-002 anhand der bestehenden Projektanweisungen und freigegebenen Komponenten. Erfinde keine neuen Genehmigungsregeln und führe keine Abhängigkeiten ein. Zeige offene Unklarheiten vor ihrer Implementierung auf. Ergänze geeignete automatisierte Prüfungen und fasse zusammen, welches Verhalten jetzt erprobt werden kann.“

Dies ist ein Beispiel einer hilfreichen Anfrage, keine vorgeschriebene Prompt-Syntax. Die Spezifikation bleibt die dauerhafte Produktreferenz, nicht die Formulierung der Anfrage.

Das relevante Verhalten ist demonstrierbar, akzeptierte Anforderungen bleiben korrekt spezifiziert, gewöhnliche automatisierte Prüfungen wurden ausgeführt und wesentliche Probleme sind vor Übergang zur technischen oder Stakeholder-Prüfung benannt.

Generierte Zusammenfassungen blind übernehmen; große, nicht überprüfbare Änderungsblöcke erzeugen; die Vermutung eines Agenten als Richtlinienentscheidung behandeln; bequeme individuelle Komponenten an freigegebenen Bausteinen vorbeiführen; und Spezifikationen nach freigegebenen Verhaltensänderungen nicht abgleichen.