Vorstellung der Yaju Software Factory: vom Backlog zum Pull Request

Jedes Ingenieurteam hat den gleichen ruhigen Haufen. Nicht die interessante Arbeit und auch nicht die dringende Arbeit: die Tickets, die klar, klein und nie einen Sprint wert sind. Der Abhängigkeitsschub, der vierzig Dateien betrifft. Der Endpunkt, der dieselbe Validierung benötigt wie die anderen sechs. Den Test hat niemand geschrieben, da die Funktion an einem Freitag ausgeliefert wurde.

Auf diesem Stapel beginnt die Software Factory.

Was es tatsächlich tut

Sie verweisen auf ein Backlog-Element. Es liest das Problem, liest die Codebasis um es herum, erstellt einen Plan, schreibt die Änderung, führt die Tests aus und öffnet eine Pull-Anfrage mit einer Beschreibung dessen, was es getan hat und warum. Eine Person überprüft diese Pull-Anfrage genau so, wie sie die eines Kollegen überprüfen würde.

Dieser letzte Satz ist das gesamte Design. Die Software Factory verschmilzt nicht. Es entscheidet nicht darüber, ob ein nicht bestandener Test akzeptabel ist. Es erweitert nicht stillschweigend seinen eigenen Wirkungsbereich gegenüber dem Ticket, das ihm gegeben wurde. Es produziert etwas, das ein Mensch beurteilen kann, und hört dann auf.

Warum es sich im Agent Orchestration System befindet

Wir hätten es als eigenständiges Tool liefern können. Es gibt viele davon, und die meisten von ihnen zeigen sich wunderbar. Das Problem taucht in der dritten Woche auf, wenn vierzig davon in sechs Teams laufen und niemand drei Fragen beantworten kann: Was haben sie geändert, was haben sie gekostet und wer ist für denjenigen verantwortlich, der gerade den Abrechnungsdienst berührt hat?

Der Aufbau auf dem Agent Orchestration System bedeutet, dass es auf diese Fragen bereits Antworten gibt. Jeder Lauf, den die Software Factory durchführt, ist ein Agentenlauf wie jeder andere, was bedeutet, dass er die Dinge erbt, die wir über drei Generationen aufgebaut haben:

• Die pro Agent zugeordneten Ausgaben werden in Währung und nicht in Token angegeben, sodass ein Team sehen kann, was seine Backlog-Automatisierung tatsächlich pro zusammengeführter Änderung kostet.
• Budgets, die eine Überschreitung stoppen, während sie stattfindet, mit einer Warnung, wenn sich das Limit nähert, und einer harten Sperre, wenn es erreicht wird.
• Die Richtlinie wird zum Zeitpunkt der Aktion durchgesetzt, sodass ein Agent, der niemals Produktionsanmeldeinformationen berühren sollte, diese nicht berühren kann, unabhängig davon, was im Plan steht.
• Evaluiert bei jedem Lauf, bewertet die Ausgabe anhand von Verhaltens-, Struktur-, Latenz- und Kostenkriterien und stoppt den Lauf, wenn eine Prüfung fehlschlägt.
• Ein vollständiger Prüfpfad, sodass die Antwort auf die Frage „Warum kam es zu dieser Änderung“ eher in einer Aufzeichnung als in einer Rekonstruktion liegt.

Nichts davon ist eine Funktion der Software Factory. Es ist ein Merkmal der Plattform darunter, und das ist der Punkt.

Der Teil, den die Leute unterschätzen

Das große Problem bei der automatisierten Codegenerierung bestand darin, nie den Code zu generieren. Modelle sind schon seit einiger Zeit in der Lage, eine plausible Funktion zu schreiben. Das schwierige Problem ist alles, was die Generation umgibt: zu wissen, welches Ticket sicher ausgehändigt werden kann, den Agenten innerhalb der von Ihnen festgelegten Grenzen zu halten, die Änderung zu erkennen, die technisch korrekt und kontextuell falsch ist, und anschließend beweisen zu können, was passiert ist.

Teams, die diesen Teil überspringen, haben einen schnellen Start und ein langsames Jahr. Die Ausgabe kommt schnell an, und dann muss jemand sie für immer sehr sorgfältig lesen, denn es gibt keinen systematischen Grund, einem bestimmten Lauf mehr zu vertrauen als jedem anderen. Evaluierungen machen daraus einen überschaubaren Prozess. Wenn jeder Lauf anhand der von Ihnen definierten Kriterien bewertet wird, ist die Überprüfung kein einheitlicher Verdacht mehr, sondern eine Triage.

Mit Absicht klein anfangen

Die Teams, die das Beste daraus machen, sind nicht diejenigen, die am ersten Tag auf ihren gesamten Rückstand hingewiesen haben. Sie wählten eine Arbeitskategorie aus, die gut spezifiziert war und wenig Einsatz erforderte, ließen sie dort laufen, bis die Bewertungsergebnisse langweilig waren, und erweiterten dann die Grenze.

Das ist langsamer als die Demo vermuten lässt. Es ist auch die einzige Version, die wir über den ersten Monat hinaus gesehen haben.

Wo es läuft

Die Software Factory wird dort ausgeführt, wo auch der Rest Ihrer Yaju-Bereitstellung ausgeführt wird. Wenn Ihr Code Ihre Infrastruktur nicht verlassen kann, wird er selbst gehostet, in Ihrer eigenen Cloud oder vollständig Air Gap ausgeführt, wobei auf jeden Agenten die gleiche Governance angewendet wird. Anmeldeinformationen werden zur Laufzeit aus dem Tresor auf Organisationsebene aufgelöst, sodass der Agent nie ein Geheimnis im Klartext sieht und Sie nie einen Schlüssel in einer Konfigurationsdatei haben.

Probieren Sie es aus

Die Software Factory ist ab sofort verfügbar. Wenn Sie es mit Ihrem eigenen Backlog und nicht mit einem Beispiel-Repository vergleichen möchten, buchen Sie eine Demo und wir gehen es mit Ihrem Code und Ihren Einschränkungen durch. Wenn Sie lieber zuerst lesen möchten: Auf den Seiten zum Agent Orchestration System werden die Governance-, Kosten- und Bewertungsebenen behandelt, auf denen es aufbaut.