Den ganzen Lebenszyklus neu denken, nicht nur die Programmierphase
- Engineer
- Lead
- Entscheider
TL;DR
Schnelle Codegenerierung gibt es wirklich, nur ist sie eine Phase in einem längeren Prozess. Planung, Anforderungen, Design, Test, Deployment und Wartung bleiben je eine eigene Aufgabe, und bei jeder kann ein Agent inzwischen einen grossen Teil der Arbeit mittragen. Er unterstützt, er übernimmt nicht, denn jede Phase endet in einer Entscheidung, die jemand verantwortet. In vielen Organisationen arbeiten die Agenten am Code, und der Rest des Lebenszyklus ist geblieben, wie er war. Wie viel Agenten zur Softwareentwicklung beitragen, hängt davon ab, wie gut sie in den ganzen Lebenszyklus eingebunden sind: in jede Phase und in die Übergänge dazwischen. Dort zählt, was eine Phase der nächsten übergibt, in welcher Form und ob die nächste darauf zugreifen kann.
Ein Agent entwickelt aus einer kurzen Beschreibung in einem einzigen Durchlauf eine lauffähige Anwendung. Fast jeder hat das inzwischen gesehen, und es leistet tatsächlich, was es zu leisten scheint. Ein Trick steckt nicht dahinter.
Einen zweiten Blick verdient die Frage, wo dieser Durchlauf im liegt, also in der Abfolge von Phasen, die Software von der Idee bis zum Betrieb durchläuft.
Softwareentwicklung durchläuft getrennte Phasen, und jede muss mitgedacht werden.
#Eine verbreitete Einteilung sieht so aus:
- Planung: die Entscheidung, was sich zu entwickeln lohnt, für wen und zu welchen Kosten.
- Anforderungen: die Übersetzung des fachlichen Bedarfs in Vorgaben, nach denen ein technisches Team entwickeln kann.
- Design: der technische Entwurf von Architektur, Daten und Schnittstellen.
- Implementierung: das Programmieren.
- Test: die Klärung, ob das Ergebnis tut, was verlangt war.
- Deployment: die Bereitstellung für die Nutzerinnen und Nutzer.
- Wartung: der laufende Betrieb, Korrekturen und Erweiterungen.
Oft liegen diese Phasen bei verschiedenen Personen oder Teams, und keine davon wurde für Agenten erfunden.
Beim geht der Lebenszyklus im Prompten auf. Was entstehen soll und was es können muss, ergibt sich Prompt für Prompt. Designentscheidungen fallen dabei trotzdem, nur unausgesprochen. Geprüft werden sie nicht, denn den Code liest niemand.
Das Unternehmen ist auf den ganzen Lebenszyklus angewiesen, nicht nur auf das Programmieren.
#Viele Organisationen setzen ihre Agenten beim Schreiben von Code ein, und die übrigen Phasen laufen ohne sie. Die Anforderungen kommen zum gleichen Zeitpunkt und in der gleichen Form wie immer. Die Übergabe von den Anforderungen ins Design läuft wie eh und je, und getestet wird, sobald der Code da ist. Schneller geworden ist also eine einzige Phase. Wann und in welcher Form die Arbeit dort ankommt, hängt weiterhin an Phasen, die sich nicht verändert haben.
Diese Lücke sieht je nach Rolle anders aus. Wer den Code schreibt, wartet jetzt auf das, was davor liegt. Wer ein Team führt, sieht den versprochenen Tempogewinn in den Phasen versickern, die unverändert geblieben sind. Und wer das Unternehmen leitet, hat eine Phase finanziert, beurteilt den Erfolg aber am ganzen Ablauf. Es ist dieselbe Lücke, aus drei Flughöhen gesehen.
Agenten können jede Phase unterstützen, nicht nur das Programmieren.
#Die Phasen vor der Implementierung organisiert jedes Unternehmen auf seine Weise und mit eigenen Werkzeugen, und das agentische Setup richtet sich danach. Liegen die Anforderungen in Confluence, arbeitet der Agent direkt dort mit und hilft, sie zu schreiben und zu verbessern. Dasselbe gilt für die Regeln jeder Phase: wie eine Anforderung formuliert wird und was ein enthalten muss, bevor das Design darauf aufbauen kann. Diese Regeln bekommt der Agent. Er wendet sie an, prüft den Entwurf auf ihre Einhaltung und benennt notwendige Anpassungen.
Das Steuer behält der Mensch. Die Anforderungen legt nicht der Agent fest. Er nimmt die, die ein Mensch geschrieben hat, hinterfragt sie, findet, was fehlt, und bringt sie in eine Form, auf der die nächste Phase aufbauen kann.
Ein Ticket wird samt Anhängen gelesen, anhand des Repositorys analysiert, geplant, umgesetzt und in einem frischen Kontext reviewt. Am Schluss erhält, wer das Ticket erfasst hat, eine Antwort in fachlicher Sprache. Die Analyse läuft ohne Aufsicht. Eine Datei ändert sich aber erst, wenn ein Mensch den Plan gelesen und ihm zugestimmt hat.
Das Ergebnis jeder Phase soll der nächsten als verlässliche Grundlage dienen.
#Behandle jeden Übergang zwischen zwei Phasen als vereinbarte Schnittstelle. Dazu gehören zwei Dinge. Das erste ist die Form: Die Phase legt ihr Ergebnis in einem festgelegten Format vor, und die nächste weiss, was sie bekommt, statt es sich zusammenreimen zu müssen. Gerade für einen Agenten ist das wichtig: Er arbeitet am besten, wenn er weiss, was für einen Input er bekommt. Das zweite ist der Zugriff. Kommt ein Agent selbst an das Ergebnis heran, kann die nächste Phase beginnen, sobald ein Mensch es freigegeben hat. Niemand muss es von Hand weitergeben, und ein grösserer Teil des Ablaufs kann automatisch laufen.
Das heisst nicht, dass es mehr Prozesse braucht. Die Phasen gab es schon immer. Neu ist, dass Agenten jede von ihnen unterstützen können. Deshalb ändert sich die Arbeit für alle, die eine Phase verantworten, nicht nur für die Entwickler. Ein Unternehmen, das will, braucht diesen Wandel in jeder Phase.
Weiter erkunden