Teil von „Entropie bezwingen“

Die meisten Probleme, die ich mit KI-generiertem Code habe, hängen mit Vertrauen zusammen. Vertraue ich der Person, die dieses Ticket geschrieben hat? Vertraue ich darauf, dass der Ingenieur, der diesen PR geöffnet hat, das Ticket verstanden und den Coding-Agenten richtig angeleitet hat, es zu implementieren? Vertraue ich der Implementierung des Coding-Agenten? Vertraue ich unserer Test-Suite, Regressions vor dem Erreichen der Produktion zu erkennen? Vertraue ich unserem CI/CD, unsere Änderungen korrekt zu bauen, zu testen und zu deployen? Vertraue ich unserem Observability-Setup, uns zu warnen, wenn KI-generierter Code die Produktion beschädigt? Vertraue ich dem KI-SRE (Site Reliability Engineer), das Problem richtig zu diagnostizieren und uns bei der Milderung zu helfen? Vertraue ich Git Hub darauf, keinen Vorfall zu haben, wenn wir es am dringendsten brauchen? Vertrauen ist schwer zu verdienen und leicht zu verlieren. Deshalb denke ich, es ist entscheidend, eine Kultur des Vertrauens im Engineering-Team zu fördern. Man muss Ingenieuren vertrauen, das Richtige zu tun.

Verantwortlichkeit fördern

Ich finde es hilfreich, klar zu kommunizieren: „Du bist verantwortlich für das, was du auslieferst. Wenn dies die Produktion kaputt macht und du den PR geschrieben hast, solltest du da sein, um es zu reparieren.“

Wenn Ingenieure für den Code, den sie ausliefern, verantwortlich gemacht werden, sollte man ihnen die Autonomie geben, ihn mit ihren bevorzugten Methoden zu produzieren. Auch wenn du nicht KI-begeistert bist, musst du zugeben, dass KI-Agenten sehr viel Code sehr schnell generieren. Code muss immer noch generiert werden, und die Erwartung ist, dass es jetzt billig ist, viel davon zu generieren. Damit umzugehen, müssen Ingenieure in der Lage sein, Maßnahmen zu ergreifen, um sicherzustellen, dass die Qualität der Codebase nicht abnimmt. In einer gesunden Organisation sollten Ingenieure einander vertrauen, nur Code angemessener Qualität zu pushen. Ich sage angemessen, weil es nicht pragmatisch ist, über Qualität zu obsessieren und immer 100% perfekten Code zu liefern. Selbst vor Coding-Agenten war der meiste Code bereits ein fehlerhaftes Durcheinander! Daher ist es verständlich, wenn eine „gut genug“ Lösung geliefert wird. Oft tauschen wir Liefergeschwindigkeit gegen Qualität ein und nehmen technische Schulden in Kauf.

Hier sind einige Praktiken, die ich nützlich fand, um Engineering-Verantwortlichkeit in diesem neuen Zeitalter des Codierens zu erleichtern:

Coding-Richtlinien

Eine klare Technologie-Strategie haben: Nehmen Sie sich Zeit, um zu entscheiden, was für Ihre Codebase wichtig ist, und investieren Sie in klare Richtlinien. Sowohl für Menschen als auch für Coding-Agenten. Selbst wenn Menschen die Richtlinien nicht lesen, werden ihre Coding-Agenten sie lesen und befolgen (meistens).

Deterministische Werkzeuge

Stark deterministische Werkzeuge nutzen, um Code-Qualität sicherzustellen. Typisierte Sprachen, Linter, Dead-Code-Erkennung, Security-Scans, CI/CD usw. All diese Werkzeuge existierten vor Coding-Agenten und helfen uns im Kampf gegen schlechten Code. (Bleiben Sie dran für einen Follow-up-Post mit spezifischen Empfehlungen!)

Kleine PRs erzwingen

Ingenieure befähigen, nicht reviewbare PRs abzulehnen. Wenn möglich, diesen Kriterium kodifizieren, damit nicht reviewbare PRs sofort abgelehnt werden. Natürlich Raum für Ausnahmen lassen.

Tests besitzen

Testfälle von Hand schreiben. Dies ähnelt der Arbeit eines Business-Analysten. Tief über das Feature nachdenken und passende Test-Szenarien definieren. Dies im Team besprechen. Coding-Agenten können die Tests implementieren, aber sie sollten von Menschen definiert werden.

Produkt-Geschmack

In Tandem mit Product arbeiten, um eine kohärente Produktvision zu haben. Es ist sehr leicht, mit KI verrückt zu werden und jedes Feature zu implementieren, das einem in den Sinn kommt. Stellen Sie sicher, dass Sie nur nützliche Features implementieren, die tatsächlich Wert für Nutzer bringen!

Prototyp

Wegwerf-Code. Da Code jetzt sehr einfach zu generieren ist, ist es eine gute Gelegenheit, verschiedene Ansätze auszuprobieren. Lassen Sie nicht nur den Coding-Agenten eine Lösung generieren. Zum Beispiel drei radikal verschiedene Ansätze versuchen und den wählen, der am besten zum Problem und zum bestehenden System passt.

Auf das Ergebnis fokussieren

Pragmatisch beim Ergebnis sein. Manchmal ist der Code nicht das Ergebnis. Das Ergebnis ist ein Report oder ein Tool, das hilft, etwas anderes zu erreichen. Für solche Fälle ist die Code-Qualität nicht so relevant, solange das Ergebnis nützlich ist.