TL;DR:

1. Ändern Sie die Darstellung auf GitHub Copilot von der Konzentration auf Ingenieure hin zu einer soliden (DevOps) Grundlage, um schneller voranzukommen.
2. Die nächste Grenze: der Rest unserer Organisation

Prämisse: Die derzeitige Erzählung ist nicht hilfreich

Meiner Meinung nach müssen wir den Fokus auf die Nutzung von GitHub Copilot durch Ingenieure verlagern. Derzeit liegt der Schwerpunkt auf den Ingenieuren, die mit GitHub Copilot einfacher und schneller Code erstellen können. Das führt dazu, dass Unternehmen denken, sie hätten endlich einen Weg gefunden, 10x Ingenieure zu schaffen. Und selbst Ingenieure preisen dies mit Geschichten über "Vibe Coding" mit KI an: Sie springen mit einer Eingabeaufforderung auf ihre Tastaturen und akzeptieren jeden Vorschlag, der dort steht, und führen dann die Anwendung aus, um herauszufinden, ob ihr ursprüngliches Problem gelöst wurde oder nicht. Letztendlich führt dieser Weg zu einer Enttäuschung: Entweder funktioniert der Code nicht wie erhofft, oder es fehlten entscheidende Informationen und die KI ist irgendwo falsch abgebogen. Schlimmer noch: Wir haben erlebt, dass die generative KI der "Scouting-Regel" folgt und anfängt, hinter sich aufzuräumen und Code zu ändern, der gar nicht geändert werden musste! Dies kann zu Auswirkungen an anderen Stellen in der Codebasis führen, die neue Fehler verursachen können. Noch schlimmer ist, dass wir bei all den "Vibe Coding"-Geschichten Ingenieure sehen, die ihren Code nicht einmal testen, bevor sie ihn in die Produktion überführen. Das ist ein Rezept für eine Katastrophe und führt auf lange Sicht zu viel Frustration und Enttäuschung.

Bessere Erzählung: Konzentrieren Sie sich auf eine solide (DevOps-)Grundlage

Stattdessen empfehle ich, sich darauf zu konzentrieren, die Ingenieure in die Lage zu versetzen, die Stiftung damit sie ihre Anwendungen schneller und mit mehr Aufwand einführen können. vertrauen dass ihre Anwendung wie vorgesehen funktioniert. Ich war schon immer ein DevOps-Anhänger und glaube fest daran, dass die grundlegenden Prinzipien vorhanden sein müssen:

• Automatisierte Pipelines und Tests
• Alles als Code oder Konfiguration
• Mehr Augen Prinzip am Platz
• Genügend Tests, um Vertrauen zu haben Wenn eine Bereitstellung aus irgendeinem Grund fehlschlägt, sollte ein neuer Test in die Pipeline aufgenommen werden, um zu verhindern, dass dies erneut geschieht.
• Kontinuierliche Überwachung und Feedback-Schleifen

Nur wenn ein großer Teil dieser Grundlagen vorhanden ist, kann ein Team von Ingenieuren seine Änderungen schneller einführen, da beispielsweise die Tests vorhanden sind, um sich auf ihre Einsätze verlassen zu können. Beachten Sie, dass dies auf verschiedene Weise erreicht werden kann, z.B. mit Unit-, Regressions- oder Integrationstests. Verwenden Sie das, was für Ihre Anwendung funktioniert.

Generative KI wie GitHub Copilot kann dabei helfen, diese Grundlagen zu schaffen und eignet sich sehr gut für diese Art von unterstützendem System. Ich sehe, dass sich viele Benutzer nur auf die Programmierung mit Copilot konzentrieren und nicht wissen, dass es so viel mehr kann: Ich habe alle möglichen Skripte, Pipelines und sogar Splunk-Abfragen mit Copilot erstellt und es funktioniert wirklich gut, wenn Sie verstehen, wie Sie die richtigen Dinge abfragen.

Ich sehe GitHub Copilot als einen Enabler, der den Teams die Zeit gibt, ihr Fundament in Ordnung zu bringen. Da die normalen Aufgaben beschleunigt werden, kann die zusätzliche Zeit für Initiativen zur Verbesserung der Dinge verwendet werden, die oft an das Ende des Backlogs oder zumindest aus dem Sprint verschoben werden. Ich empfehle Teams, diese Art von technischen Schulden immer mit einzubeziehen und sie entweder in ihre Arbeitsweise einzubeziehen oder in jedem Sprint speziell Zeit für ihre Verbesserung einzuplanen. Ich habe gesehen, dass erfolgreiche Teams immer 10 % ihrer Zeit auf die Beseitigung technischer Schulden als Teil ihres Sprints verwenden.

Mit dieser Grundlage können Teams schneller und mit mehr Vertrauen Werte schaffen und weniger Probleme in der Produktion haben.

Nächste Stufe der Erleuchtung: Teamarbeit

Danach können wir anfangen, an die anderen Dinge zu denken, die unsere Teams tun. Im Durchschnitt kann sich ein Ingenieur schon glücklich schätzen, wenn er sich für etwa zwei Stunden am Tag auf das Schreiben von Code konzentrieren kann: ActiveState's 2019 Entwicklerumfrage. Der Rest der Zeit wird für Vorbereitungen, Diskussionen, Architekturarbeit, Dokumentation usw. verwendet. Und dann gibt es immer noch Teams, die den größten Teil ihres Tages in Meetings verbringen, die sich manchmal sogar überschneiden und parallel laufen. Es ist immer wieder erstaunlich zu sehen, wie manche Organisationen Meetings wichtiger machen als die eigentliche kreative Arbeit wie das Programmieren!

Die nächste Veränderung, die ich sehe, betrifft die Art und Weise, wie die Arbeit an die Ingenieure herangetragen wird. Wir sind ständig damit beschäftigt, die Änderungen zu beschreiben, die wir an der Anwendung vornehmen möchten, und müssen die Benutzeranfragen in umsetzbare Beschreibungen übersetzen. Danach müssen wir dafür sorgen, dass alle Teammitglieder diese Änderungen und die Auswirkungen auf die Anwendung verstehen. Teams arbeiten mit verschiedenen Interessengruppen und vielleicht einem Product Owner zusammen, der die Arbeit an das Team weiterleitet.

Meiner Meinung nach müssen wir uns jetzt darauf konzentrieren, Rollen wie Product Owner in die Lage zu versetzen, Arbeit mit einem besseren Umfang einzusenden. Die eingehenden Arbeitsbeschreibungen sollten dann von einem Ingenieur überprüft werden, der sich mit der Anwendung auskennt, um ihr den letzten Schliff zu geben.

Wenn die eingehende Arbeit hinreichend klar ist, kann KI verwendet werden, um die Änderungen vorzuschlagen, die in Codeänderungen umgesetzt werden. Die nächste Iteration von Tools wie GitHub Copilot wurde bereits mit dem Projekt Padawan angekündigt (Blogpost hier), wo Copilot versuchen kann, die Änderungen selbst vorzuschlagen, alle Tests in der Pipeline erneut durchzuführen und bei Bedarf zu wiederholen. Wenn die Tests erfolgreich verlaufen sind und die Änderungen implementiert wurden, wird ein Pull Request zur endgültigen Überprüfung eingereicht.

Fazit

Es wird immer Arbeit für hochqualifizierte Ingenieure geben, und ja, ich denke, sie werden in der Zukunft der KI-Agenten, die große Teile der Arbeit erledigen können, eher eine Art Orchestrator sein. Die Ingenieure werden dafür sorgen, dass dem System genügend Vertrauen entgegengebracht wird, um mit den nächsten Schritten fortzufahren. Es ist wichtig, dass neue Ingenieure auf eine gute Art und Weise geschult werden, damit sie die vorhandenen Tools und Prozesse beherrschen und verstehen, welche Auswirkungen die Änderungen auf die Anwendungen haben, an denen sie arbeiten. Wenn Sie es versäumen, neue Techniker zu schulen, führt dies zu noch mehr (nachgelagerten) Problemen und Frustration sowohl bei den Technikern als auch bei ihren Stakeholdern. Wenn Sie sich auf die neue Arbeitsweise einlassen, wird dies zu einer effizienteren Arbeitsweise und letztlich zu einer besseren Erfahrung für die Endbenutzer der von uns entwickelten Anwendungen führen.