Trainieren Sie KI wie Junior-Ingenieure, nicht wie magische Werkzeuge

Devin ist ein KI-Softwareingenieur-Agent, der von Cognition Labs entwickelt wurde und autonome Programmierfähigkeiten besitzt.

Das Wichtigste, was ich sagen würde, ist, dass man Devin wirklich wie einen neuen Junior-Ingenieur behandelt. Ich denke, die Leute kommen rein und sehen die leere Seite und denken sich allerlei Dinge aus, die sie ausprobieren wollen. Aber vieles ist einfach so: 'Ja, lass uns herausfinden, welche Tickets wir heute oder diese Woche erledigen wollen, und lass Devin damit anfangen. Fangen wir mit den einfacheren an und arbeiten dann mit Devin zusammen, um herauszufinden, was Devin braucht, um seinen eigenen Code testen und das gut machen zu können. Und dann können wir das mit der Zeit hochskalieren.'

Devin ist ein KI-Softwareingenieur-Agent, und "was Sie gerade gesehen haben" bezieht sich auf eine Live-Demo, in der Devin einen Newsletter-Link zu ihrer Website hinzugefügt hat.

Sie möchten Devin Aufgaben geben, keine Probleme. Und viele dieser Dinge, wie das, was Sie gerade gesehen haben, also eine schnelle Frontend-Funktionsanfrage oder einen Bugfix oder das Hinzufügen von Tests und Dokumentation oder so etwas. Einer der Dinge, die eine Schleife wirklich schön machen, ist natürlich ein schneller Weg zum Iterieren und Testen.

"Dieses Ding" bezieht sich auf LLMs (Large Language Models), die Komoroske als "weiche Computer" beschreibt, die nicht genau das tun, was man ihnen sagt.

Wenn es einem ins Gesicht schlägt, ist das kein lebensfähiges Produkt. Und wie entwirft man seine Produkte so, dass diese Sache weich und nicht voll genau und voll funktionstüchtig ist?

Herauszufinden, wie man es so herunterbricht, dass ein Agent wirklich versteht, was Erfolg und Misserfolg bedeuten, ist ein großer Teil des Spiels.

"Das" bezieht sich auf die vier Schlüsselkennzahlen des DORA-Frameworks. Mit "Pipeline" sind Software-Entwicklungs- und Deployment-Pipelines gemeint.

Wir können das jetzt nicht einfach blind verwenden, wenn wir KI einsetzen, da wir viel früher Feedback-Schleifen haben, nicht nur in der lokalen Build- und Testphase. Wir haben Feedback-Schleifen überall, manchmal sogar mitten im Pipeline-Prozess.

Wir können nicht einfach einen Befehl eingeben und etwas zurückraten und es akzeptieren. Wir müssen es wirklich bewerten. Sehen wir Halluzinationen? Wie ist die Zuverlässigkeit? Erfüllt es den Stil, den wir normalerweise schreiben würden?