Lead Architect Reveals His Rules for Coding Agents

Die von mir gefundenen Agenten können schlecht Änderungen vornehmen, sind aber gut darin, es in einem Anlauf zu tun. Ich gehe so groß wie möglich vor

tun. Ich gehe so groß wie möglich vor .

Siehst du dir den Output an?

Überprüfst du den Code?

Oh ja, und wenn er mir nicht gefällt, werfe ich ihn weg. Wenn ich ihn nicht verstehe, werfe ich ihn weg.

Das ist Carlos Kelp Bone, einer der besten Ingenieure, die ich kenne. Sein

Haupt-Agent berührt nicht einmal Dateien.

Wow, er konzentriert sich nur auf eine Sache. Wie soll ich jemals eine gute

Sache. Wie soll ich jemals eine gute Antwort bekommen, wenn er nur darauf schaut, ob er den Code sofort für mich schreiben kann? Also habe ich ihn

schreiben kann? Also habe ich ihn einfach gezwungen, das nie wieder zu tun. Sie sind gut darin, Code zu

tun. Sie sind gut darin, Code zu schreiben, aber nicht darin, eine Anwendung zu entwickeln. Ich denke, wir müssen die Hitze loswerden. Die Hitze

muss einfach komplett weg. Wir brauchen

keine Zeiger, wir brauchen keinen dynamischen Speicher. Wenn KI aus

dynamischen Speicher. Wenn KI aus irgendeinem Grund verschwindet, wird alles zusammenbrechen.

Glaubst du, dass das passieren wird?

Ich sehe drei Dinge, die passieren werden.

Was ist das Wichtigste, worauf sich das Engineering deiner Meinung nach wirklich verlagert hat, was anders ist als vor ein paar Jahren?

Also, das Erste, was ich sehe und was mir nicht wirklich gefällt, ist, dass Kooperation und Koordination langsam schwinden. Die Bedeutung von Pull

schwinden. Die Bedeutung von Pull Requests, dass Leute zusammenarbeiten, Kommentare zu eigenen oder fremden Pull Requests abgeben–manche sagen sogar, Pull Requests könnten verschwinden.

Und was ich sehe, ist eine eher individuelle Art der Entwicklung und weniger Kooperation. Man arbeitet mit

weniger Kooperation. Man arbeitet mit seinen Agenten zusammen, aber nicht mehr mit seinem Team. Oder zumindest

ist das der Trend, den ich sehe, und ich halte ihn für gefährlich.

Mhm. Warum glaubst du, ist das spezifisch so? Und ich gehe davon aus,

spezifisch so? Und ich gehe davon aus, dass es in der Praxis vielleicht das ist, was wir online sehen, etwa auf Reddit–das ist meine Blase–oder YouTube, weil es viele Solo-Entwickler gibt, die an vorderster Front stehen.

Mhm.

Aber ich weiß nicht, ob das widerspiegelt, was in größeren Organisationen passiert, wo es noch größere Teams gibt und Menschen mit Agenten und untereinander zusammenarbeiten.

Ja, ich habe das Privileg, in keinen sozialen Medien zu sein. Ich habe kein Reddit-Konto. Ich meine, ich benutze

Reddit-Konto. Ich meine, ich benutze LinkedIn nur, um mit dir zu sprechen.

Ich habe absolut null, ähm, Interesse daran, sozialen Medien zu folgen, aber ich lese viel, ich lese Artikel, ich lese Whitepapers und ich spreche mit vielen Firmen und vielen Leuten in Firmen. Und daher gibt es einen

Firmen. Und daher gibt es einen Unterschied zwischen etwas schnell zu bauen und es nicht fertigzustellen, und etwas zu bauen, von dem man hofft, dass es Bestand hat. Es ist also diese klassische Sache von Marathon gegen

Sprint, und Leute, die Dinge alleine bauen, bringen sie meist nicht den letzten Schritt zur Fertigstellung. Und

das ist meiner Meinung nach der Unterschied. Etwas in den sozialen

Unterschied. Etwas in den sozialen Medien oder auf YouTube zeigen. Wie zum

Beispiel, man sieht viele Leute, die sehr schnell Spiele bauen. Und der

Grund, warum ich die Anführungszeichen in der Luft mache, ist, dass das größte Problem bei Spielen das Zuhören bei den Nutzern ist, das Spieldesign korrekt umzusetzen, und das ist immer noch etwas–ja, man kann mit seinem Agenten iterieren, aber man muss mit der Welt kommunizieren. Ich denke

also, dass Menschen, die in ihrer Blase arbeiten und nicht mit anderen kommunizieren müssen, das war schon immer eine der schwierigsten Aufgaben.

Ich glaube, das wird jetzt nur noch verstärkt, weil man zwar eine Menge Fortschritt zeigen kann, das aber alleine macht. Und sich daran zu

alleine macht. Und sich daran zu erinnern, warum man eine Software baut oder für wen man sie baut, deshalb sagte ich, dass das Produkt immer wichtiger wird. Ich glaube, das ist die

wichtiger wird. Ich glaube, das ist die Sache, die momentan wirklich stark unter Druck gerät.

Hast du irgendwelche Ideen, wie man das lösen kann? Weil ich denke, es ist

lösen kann? Weil ich denke, es ist sehr einfach. Ich bin in meiner kleinen

sehr einfach. Ich bin in meiner kleinen Blase, ich dachte früher, Dinge anzufangen sei eines der schwierigsten Dinge überhaupt, das war es für mich.

Jetzt habe ich viele Dinge angefangen, die ich nie beendet habe. Leute sagten

mir das früher, und ich dachte nur: Ich verstehe das nicht. Ich fange nur an, wenn ich es auch beenden kann.

Jetzt ist mir das Anfangen noch nie so leicht gefallen.

Ja.

Sogar mit meiner Lizenz habe ich Credits. Ich denke mir, oh, ich habe

Credits. Ich denke mir, oh, ich habe diesen kleinen Balken und am Ende des Monats möchte ich, dass mein Balken am Ende der Woche so nah wie möglich bei 100%liegt.

Ja.

Also, bevor ich schlafen gehe, denke ich: Was, was kann ich bauen? Ein Spiel

. Ich habe definitiv Spiele gebaut. Ich

habe eine Struktur gebaut, die Spiele baut, damit andere Leute Spiele bauen können. Es ist wie eine Meta-Ebene.

können. Es ist wie eine Meta-Ebene.

Ähm, ich versuche Probleme zu lösen, von denen ich glaube, dass sie in der Zukunft auftreten werden, und sehe mir quasi die Ergebnisse davon an.

Mhm.

Aber dann gehe ich nicht die Extrameile . Ich härte es nicht ab. Ich mache es

. Ich härte es nicht ab. Ich mache es nicht fertig. Ich baue das nicht zu

nicht fertig. Ich baue das nicht zu einem Produkt aus, das ich dann verkaufe. Ich fange viele Dinge an, ich

verkaufe. Ich fange viele Dinge an, ich mache viele Dinge nicht fertig.

Ja. Aber das war schon immer so. Ich

habe also, ach Gott, fünf Compiler gebaut. Ich habe sie alle angefangen.

gebaut. Ich habe sie alle angefangen.

Sie waren alle fast fertig. Und es gibt nur einen, bei dem ich sagen kann, dass er wirklich fertig war. Dinge

anzufangen und sie nicht zu beenden, war also schon immer Teil der Softwareentwicklung, weil man eine coole Idee hat, lernen will und anfängt zu bauen. Der einzige

Unterschied ist jetzt, warum man das Projekt startet. Startest du das

Projekt startet. Startest du das Projekt, um zu lernen, mit Agenten zu experimentieren oder um wirklich ein Problem zu lösen?

Mhm.

Produkt. Ich denke also, die Absicht hinter dem, was du in Zukunft tun wirst , muss sich festigen. Und sobald sich diese Absicht festigt, verschwindet die Frage, die du gerade gestellt hast, ein wenig.

Mhm.

Wenn die Absicht also nur darin besteht , Spaß zu haben, Mann, dann hast du dein Ziel bereits erreicht. Wenn die

Absicht darin besteht, eine Firma daraus aufzubauen, dann musst du etwas fertigstellen.

Ja.

Und für Leute, die das erleben: Ich und mein Agent waren irgendwie in einer Blase. Wenn ich eine Frage habe, würde

Blase. Wenn ich eine Frage habe, würde ich sie statt dich anzusprechen, meinen Agenten fragen. Das ist die Art zu

Agenten fragen. Das ist die Art zu arbeiten, die ich in meinem Umfeld sehe . Was wäre dein Rat an Leute, um da

. Was wäre dein Rat an Leute, um da rauszukommen und wieder mehr zusammenzuarbeiten?

Ähm um ehrlich zu sein, darüber denke ich schon sehr lange nach. Und ich

glaube, die Art, wie wir zusammenarbeiten und Software bauen, muss sich ändern. Es gibt diese Open-Source-Bewegung ja schon sehr lange. Ich glaube, wir müssen uns mehr

lange. Ich glaube, wir müssen uns mehr auf Dinge wie Meetups konzentrieren, Informationen und Wissen teilen, zusammenarbeiten und Gruppen haben, die die Produkte der anderen überprüfen

wollen. Ich meine, wir müssen wirklich

wollen. Ich meine, wir müssen wirklich zusammenkommen und zusammenarbeiten.

Und das bedeutet, dass wir, auch wenn es einfacher ist, in der eigenen Blase zu bleiben, einen Weg finden müssen, die Hürde zu senken, Leute zu finden, die einfach neugierig auf das sind, was man tut. Und das bedeutet auch, dass

man tut. Und das bedeutet auch, dass wir etwas offener sein müssen und keine Angst haben sollten, unsere Ideen preiszugeben, denn Ideen–man sagt immer, Ideen seien billig, aber für die Person, die die Idee hat, fühlen sie sich nicht billig an. Im globalen

Kontext sind sie billig, aber sie fühlen sich persönlich an. Also, eine

Idee zu teilen und diese Angst, dass jemand anderes damit abhaut oder man etwas falsch gemacht hat oder so etwas.

Ich denke, das ist der Punkt, auf den wir uns konzentrieren müssen, indem wir eine sehr inklusive Community aufbauen. Und das coolste Beispiel, das

aufbauen. Und das coolste Beispiel, das ich nennen kann, ist–ich weiß nicht, ob Sie World of Warcraft kennen, das gerade herausgekommen ist. Ich meine,

wenn man in die Beta geht und einfach eine dumme Frage stellt: Wie schalte ich diese Einstellung aus? Man bekommt

vier oder fünf Leute, die einem helfen .

Mhm.

Das ist das Gefühl, das wir brauchen, aber eben für Leute, die Software entwickeln wollen.

Ja. Ja, der Trend, den ich sehe, ist, dass man seinen Agenten fragt, oder? Es

gibt keinen Grund, einen Menschen zu fragen. Weil manche Leute auch generell

fragen. Weil manche Leute auch generell keine Geduld haben Ja.

für Leute, die Fragen stellen, die sie für dumm halten. Ich habe Leute sagen hören: „Frag zuerst deinen Agenten, bevor du mich fragst.“ Was irgendwie Ja.

auf eine sehr schreckliche Art irgendwie lustig ist. Ähm Aber genau das machen die Leute jetzt. Sie sind

mehr in Isolation. Das

Hochstapler-Syndrom war noch nie so verbreitet wie heute, habe ich das Gefühl.

Mhm.

Und die Leute verlassen sich auf ihre Agenten, um Orientierung zu bekommen, auch wenn sie vielleicht in die falsche Richtung gelenkt werden oder das große Ganze nicht sehen oder aus Lernperspektive vielleicht nicht so viel lernen Ja.

wenn sie mit Agenten interagieren statt mit Menschen.

Ja. Ich meine, man würde Menschen nicht...es dauert länger, einen

nicht...es dauert länger, einen Menschen zu fragen. Weil man keine sofortige Antwort bekommt. Äh, aber

Agenten neigen dazu, einem die Antwort geben zu wollen, die man hören möchte . Äh, man kann das ein wenig lösen,

. Äh, man kann das ein wenig lösen, indem man mehrere Modelle hat, mit denen man sprechen kann, die sich dann gegenseitig herausfordern, und man kann Dinge wie gegnerische Setups nutzen,

aber was passiert, ist, dass, ähm, man nur noch anfängt, mit diesen Maschinen zu kommunizieren, die sehr schnell antworten, und man nimmt sich nicht mehr die Zeit, alleine mit den eigenen

Gedanken zu sitzen. Lass einfach das Chaos der Welt durch deinen Kopf gehen, bis du ein wenig Klarheit findest, die du nutzen kannst, um eine gute Idee zu haben oder zu wissen, wie man Dinge anders macht. Ich meine, wir können

anders macht. Ich meine, wir können auch darauf eingehen, wie ich mit Agenten Software schreibe. Aber ich

denke, dass diese ursprüngliche Idee von Kreativität, wie John Cleese sagte , die offene und die geschlossene Kreativität–die offene erfordert einen Zustand und einen mentalen Zustand der Offenheit. Und das erreicht man nur, wenn man inneren Frieden

findet, nichts tut und all das Chaos aus seinem Kopf verbannt. Und bei

diesem ständigen Informationsstrom, den dir soziale Medien, KI und deine Agenten liefern, und all diesen Dingen, gibt es keinen Moment mehr, um einfach nur dazusitzen, die Augen zu schließen

und sich selbst kennenzulernen.

Mhm. Was ist der Nachteil daran? Wenn

ich eine Frage habe: sofortige Befriedigung, ich habe meine Antwort, ich kann zum nächsten Punkt übergehen . Vollgas. Für mich ging es bei

. Vollgas. Für mich ging es bei Software schon immer um Geschwindigkeit . Und mit Agenten können wir ziemlich

. Und mit Agenten können wir ziemlich schnell beschleunigen. Wir können auch

schnell beschleunigen. Wir können auch schneller Dinge kaputt machen, aber wir können sie auch schneller reparieren, also ist Geschwindigkeit für mich immer noch das A und O. Wenn ich mir als Einzelperson nicht die Zeit nehme, über bestimmte Dinge, die ich tue, nachzudenken und zu reflektieren, was ist dann der Nachteil?

Ich denke, der Nachteil ist, dass wir nicht mehr so viel lernen wie früher.

Mhm.

Ich glaube, man braucht Zeit, um Dinge zu verinnerlichen. Und wenn man sich

zu verinnerlichen. Und wenn man sich den Code einfach von einem Agenten ausspucken lässt, lernt man nichts.

Und ich glaube, die Leute, die es gelernt haben und jetzt Agenten nutzen, werden einen Vorteil gegenüber denen haben, die es nicht gelernt haben und nur Agenten nutzen. Lernen, neue Dinge lernen und kontinuierlich dazulernen, ist das, was Technik und

Softwareentwicklung so spaßig gemacht hat. Sich in einen neuen Bereich

hat. Sich in einen neuen Bereich einarbeiten, eine neue Spezifikation lernen, eine neue Sprache lernen, eine neue Anwendung auf einem neuen Framework aufbauen–es gibt einen Grund, warum es so viele JavaScript-Frameworks gibt. Jeder lernt

JavaScript-Frameworks gibt. Jeder lernt etwas von jemand anderem. Und der

einzige Weg dorthin führt darüber, sich die Zeit zu nehmen, es zu verinnerlichen.

Ja. Zählt es aus deiner Sicht auch dazu, zu lernen, wie ich meine Agenten, Unteragenten und all die Artefakte bediene, wenn neue Funktionen herauskommen?

Ja.

Ja. Was ist die wichtigste Erkenntnis, die du im Umgang mit Agenten gewonnen hast, oder wie bist du bei dieser Arbeitsweise effektiv?

Das sind für mich zwei verschiedene Fragen. Fangen wir also mit der ersten

Fragen. Fangen wir also mit der ersten an: Wie arbeite ich mit Agenten? Ich

erstelle jetzt das Grundgerüst des Codes selbst. Ich lege also weiterhin

Codes selbst. Ich lege also weiterhin die Dateien in der Verzeichnisstruktur an. Ich schreibe einige Kommentare in

an. Ich schreibe einige Kommentare in diese Dateien. Manchmal schreibe ich

diese Dateien. Manchmal schreibe ich sogar Klassennamen, Funktionsnamen oder eine Funktionssignatur hinein. Das kann

sehr formlos sein. Aber dadurch, dass ich das tue, leite ich die Agenten an, es so zu implementieren, wie ich es haben möchte. Denn was ich bemerkt und

haben möchte. Denn was ich bemerkt und gelernt habe, ist, dass Agenten zwar sehr gut darin sind, eine Lösung per Brute-Force zu erzwingen, sie aber vergessen, wie sie sich in den Rest der Anwendung einfügt. Man bekommt also

Anwendung einfügt. Man bekommt also Codeduplizierung, man bekommt Kohäsionsprobleme, man bekommt Gott-Objekte, all diese lästigen Dinge , die wir nicht im Code haben wollen, weil sie ihn unflexibler machen. Also

erstelle ich das Grundgerüst manuell.

Und das kostet mich 20, 30 Minuten, manchmal eine Stunde, um es aufzusetzen , wenn ich einen Compiler starte. Ich

schreibe meine Ordner, ich schreibe einen Lexer, ich schreibe ein bisschen von der Sprachspezifikation, wissen Sie , ich lege einige Ordnerstrukturen an, wie ich möchte, dass die Zwischenrepräsentation vom abstrakten Syntaxbaum fließt, all diese Dinge.

Und dann schreibe ich viele Beispiele in der Sprache, die ich haben möchte.

Und dann ist der Agent ein Meister darin, genau den Compiler für die Sprache auszuspucken, die ich brauche.

Wegen des Grundgerüsts?

Ja.

Wow.

Ja. Ja. Und wenn ich das nicht tue, also ich habe es mit reinem Brute-Forcing durch Agenten versucht.

Dann verbringt man ein oder zwei Monate damit, eine Anwendung zu bauen, und man hat jedes Mal das Gefühl, gegen eine Wand zu laufen. Sie werden langsamer, man bekommt nicht, was man will, Dinge gehen kaputt, wenn man die Dateien öffnet, erkennt man seine Anwendung

nicht mehr wieder, man weiß nicht, was passiert ist. Ich hatte oft den Fall,

passiert ist. Ich hatte oft den Fall, dass ich zum Beispiel ein Deploy-Skript hatte. Und aus irgendeinem Grund

hatte. Und aus irgendeinem Grund entschied der Agent, dass wir das Deploy-Skript nicht mehr verwenden, aber er erstellte ein paar andere Skripte, von denen niemand wusste, was sie taten. Und deshalb diesen Teil zu

sie taten. Und deshalb diesen Teil zu überspringen und sehr explizit zu sein , was der Agent tun soll, ist meiner Meinung nach eine Fähigkeit, die einen 10 x-Agenten-Ingenieur zu einem 100

x-Agenten-Ingenieur macht. Sehr

x-Agenten-Ingenieur macht. Sehr zielgerichtet vorzugehen.

Ich wüsste, wie das geht, weil ich vergangene Erfahrungen habe und eine Meinung zu bestimmten Projektstrukturen besitze. Aber auch ganz spezifisch in

besitze. Aber auch ganz spezifisch in der Sprache, mit der ich mich wohlfühle, weil ich damit die meiste praktische Erfahrung habe.

Mhm.

Wenn ich etwas tun würde, was ich noch nie zuvor gemacht habe, wie einen Compiler zu bauen, wie würde ich diese Fähigkeit und diesen Geschmack entwickeln, diese Meinung darüber, was ein gutes Grundgerüst ausmacht?

Ja. Ja, tolle Frage. Ähm Nun, wie hätten Sie es vor den Agenten gemacht?

Ich hätte andere Leute gefragt, weil ich zu Beginn eines Projekts, ich starte nie Projekte. Ich habe das gehasst. Der Großteil meiner

gehasst. Der Großteil meiner Berufserfahrung stammt aus Projekten, die bereits begonnen hatten. Wenn es

also Konventionen gibt, kann ich sehr effektiv arbeiten. Aber das Erstellen

effektiv arbeiten. Aber das Erstellen solcher Konventionen war nicht wirklich ein Muskel, den ich trainiert habe.

Also verließ ich mich auf andere Leute , bei denen ich gesehen habe, dass sie die Fähigkeit besitzen, Konventionen zu etablieren. Und ich habe mit ihnen

zu etablieren. Und ich habe mit ihnen zusammengearbeitet oder sie gefragt, was wirklich wichtig ist. Ich habe

diese Dinge nie wirklich verinnerlicht, weil ich heutzutage nicht in diesen repetitiven Kreislauf geraten bin, das selbst tun zu müssen. Wenn ich das jetzt tun müsste, würde ich wahrscheinlich meinen Agenten fragen.

Ja.

Ja.

Aber ich würde auch um Hilfe bitten, wenn ich feststecke.

Ja. Wie ich es heutzutage machen würde , wenn ich etwas komplett Neues lernen müsste: Ich würde zuerst nach Open-Source-Projekten suchen, die es schon gibt.

Mhm.

Und ich würde dieses Projekt herunterladen, und wenn du innerhalb dessen arbeiten willst, was ich eine Agenten-Blase nenne, dann würdest du den Agenten fragen: „Okay, destilliere die großartigen Muster aus diesem Projekt, destilliere die großartigen Muster aus jenem Projekt.

“ Und dann würde ich eine Art Fähigkeit nutzen, wenn du Claude oder so etwas verwendest, mit einem „grill mich“-oder „bring es mir bei“- Ansatz. Also: Bring mir die Grundlagen

Ansatz. Also: Bring mir die Grundlagen dieser Projekte bei und erkläre mir, warum du glaubst, dass diese Projekte funktionieren, oder was die schlechten Seiten an diesem Projekt sind. Und das

würde dich einen oder zwei Tage kosten , und dann würdest du die Schwachstellen des Systems, aber auch die Stärken des Systems kennenlernen.

Und dann würde ich tun, was ich immer tue: Ich würde einfach nach draußen gehen, mir eine Tasse Kaffee holen und dort sitzen und ins Leere starren. Und

ich würde einfach warten, bis all das Zeug verinnerlicht ist.

Mhm.

Und wenn ich Fragen habe, kann ich wieder reingehen, diese Fragen stellen und mich dann wieder nach draußen setzen, um sie zu verinnerlichen. Und

erst wenn ich ein gutes Gefühl dafür hatte, was ich tun wollte, würde ich mit sehr kleinen Machbarkeitsstudien ( POCs) beginnen. Wie ein bestimmtes

POCs) beginnen. Wie ein bestimmtes Gerüst, und dann den Agenten fragen: „Ist das ein Gerüst, das funktionieren würde?“ Würde das

funktionieren würde?“ Würde das beide Probleme lösen? Und dann einfach in dieser Schleife weitermachen. Und

sobald ich mich mit der Lösung wohl fühle, würde ich den Agenten bitten, es zu bauen. Weil ich über die Jahre gelernt habe, dass man diesem frühen Dopamin-Kick widerstehen muss, sofort ein Ergebnis zu erhalten. Und

Nur zu meinem Verständnis: Wenn ich das Grundgerüst nicht habe, ist die Konsequenz daraus, dass der Agent gewissermaßen interpretiert, was ein gutes Gerüst ist, und einfach loslegt und die Sache baut. Es versucht sehr proaktiv, die Aufgabe zu erledigen, ungeachtet der Struktur.

Ja, aber auch ungeachtet dessen, was man in der Zukunft haben möchte. Es

wird also bauen, es wird...deshalb

sagte ich, es wird genau das erzwingen, was man jetzt gerade verlangt.

Ja. Und das ist ein Problem, weil die Zukunft irgendwie formbar ist, oder wie siehst du das?

Ja. Ja, Veränderung ist immer noch das Einzige, was in der Software beständig ist. Und wenn man zum Beispiel einen

ist. Und wenn man zum Beispiel einen Compiler hat, schreibt niemand einen Compiler und lehnt sich dann zurück mit dem Gedanken, er sei fertig. Er

wird sich immer weiterentwickeln. Man

wird ein anderes Sprach-Feature haben oder eine andere Art der Optimierung oder Ähnliches. Und lass mich dir ein

oder Ähnliches. Und lass mich dir ein konkretes Beispiel geben. Ich habe

einen ganzen Compiler mit einem sehr einfachen Listensystem darin gebaut.

Ähm und dann wollte ich, dass dieses Listensystem erweitert wird. Und ich

habe, glaube ich, einen Monat lang mit dem Agenten an diesem Compiler gearbeitet. Und ich habe das in einer

gearbeitet. Und ich habe das in einer Sprache gemacht, die ich nicht besonders gut verstanden habe. Und am

Ende fragte ich den Agenten: „Okay, bitte überprüfe die Listenfunktion.

“ Und er sagte, sie sei fünfmal implementiert worden. Und genau das

implementiert worden. Und genau das passiert, wenn man es einfach mit einem Agenten erzwingt. Man braucht also

Agenten erzwingt. Man braucht also Iterationen, um die Dinge wieder zu bereinigen, aber zum Bereinigen muss man erst einmal erkennen, was das Problem ist.

Ja. Ja, für mich ist das der schwierige Teil. Ich mag deinen Ansatz,

schwierige Teil. Ich mag deinen Ansatz, sich anzusehen, was es bei Open Source so gibt. Und dann zu fragen, was gute

so gibt. Und dann zu fragen, was gute Muster sind, und dem Agenten wirklich dabei zu helfen, einem Dinge besser zu erklären oder verständlich zu machen.

Du hilfst also dem Agenten, und er muss die Dinge erklären, damit du sie besser verstehst und verinnerlichen kannst. Und bei jeder Frage, die du

kannst. Und bei jeder Frage, die du hast, gefällt mir die Funktion, dass man einfach in eine Frage-Antwort-Runde gehen kann, bis man den Grund oder die Spitze–je nach mentalem Modell– deiner Neugier und dem Verständnis erreicht hast, das du haben willst,

bevor du anfängst. Ich mache das nicht oft genug, glaube ich, aber ich mag dieses Muster und werde es wahrscheinlich übernehmen. Wenn ich

wahrscheinlich übernehmen. Wenn ich dann darüber nachdenke, okay, wie würde ich ein Grundgerüst erstellen, wenn ich die Sprache nicht gelernt habe , denn ich kenne nicht viele Sprachen, du aber schon. Mache ich das mit meinem Agenten? Ist das in Ordnung? Kann ich

Agenten? Ist das in Ordnung? Kann ich

so anfangen? Oder was wäre dein Rat?

Ja.

Ja.

Ja. Fang einfach mit dem Agenten an.

Fragen Sie den Agenten aber auch: „ Okay, was sind die wichtigsten Konzepte hinter dieser Sprache?“ und bitten Sie ihn: „Erkläre mir diese Sprache bitte anhand der Sprache, die ich bereits kenne.“

bereits kenne.“ Mhm.

Wenn Sie zum Beispiel C#kennen und Go lernen wollen, fragen Sie den Agenten einfach: „Okay, ich kenne C#, was muss ich wissen, um idiomatisch in Go zu programmieren?“

zu programmieren?“ Mhm.

Was sind die Unterschiede? Was mache

ich falsch? Erstellen Sie dann ein Grundgerüst an Code. Er muss nicht korrekt sein. Das ist das Tolle an

korrekt sein. Das ist das Tolle an Agenten. Ihr Code muss nicht korrekt

Agenten. Ihr Code muss nicht korrekt sein. Der Agent wird ihn korrigieren.

sein. Der Agent wird ihn korrigieren.

Wenn Sie jedoch ein Gerüst erstellen, selbst wenn es nur eine schnelle Skizze mit einigen Kommentaren ist, und den Agenten bitten, Ihr Gerüst zu überprüfen, wird er eine Bewertung vornehmen und Ihnen normalerweise ehrlich sagen: „Das ist falsch, das

ist falsch, das ist falsch.“ Und dann fangen Sie an, kritisch nachzufragen.

Mhm. Macht es überhaupt noch Sinn, eine Sprache zu lernen?

Ich glaube, wir stehen kurz davor, eine neue Programmiersprache zu benötigen.

Ich weiß, das sagt jeder. Aber es gibt ein paar grundlegende Dinge, die sich meiner Meinung nach in der Programmierung allgemein ändern müssen. Das erste ist, dass wir den

müssen. Das erste ist, dass wir den Heap loswerden müssen. Ich glaube, der Heap muss einfach komplett verschwinden . Wir brauchen keine Zeiger mehr, wir

. Wir brauchen keine Zeiger mehr, wir brauchen keinen dynamischen Speicher, wir brauchen das alles nicht mehr. Ich

denke also, wir brauchen eine sehr deterministische Sprache. Und wir

deterministische Sprache. Und wir müssen diese Sprache in drei Phasen unterteilen. Man braucht also eine

unterteilen. Man braucht also eine Sprache, in der der Mensch den Code schreibt. Eine Kombination aus

schreibt. Eine Kombination aus natürlicher Sprache und einer Form von strukturierter Sprache. Vielleicht

strukturierter Sprache. Vielleicht sogar nur mit einem Schlüsselwort wie „Komponente“, gefolgt vom Namen der Komponente, und innerhalb dieser Komponente können Sie in eingerückter Form Markdown verwenden, um festzulegen , was die Komponente tun soll. Dann

eine Art Zwischenphase, in der wir Dinge wie ein Diagramm, ein Video oder etwas Visuelles oder Audio erzeugen, bei dem der Agent versucht zu erklären , was Sie erreichen wollen. Und dann

haben Sie vielleicht eine Zwischenebene , auf der Sie per Sprache oder auf andere Weise eingreifen und das Ganze von dieser visuellen Ebene aus strukturieren können. Zurück zu der

strukturieren können. Zurück zu der ersten Sprache. Und ich denke, daraus

ersten Sprache. Und ich denke, daraus brauchen wir eine Darstellung, die auf einer Maschine läuft, bei der alle alten Annahmen entfernt wurden. Und was

ich damit meine, ist, dass wir begrenzte While-Anweisungen brauchen, wir brauchen begrenzte Schleifen, wir brauchen das Akteur-Modell, wir müssen den Heap loswerden und zu dieser Struktur von Datensätzen zurückkehren , die früher mal Plex genannt wurde.

Und wir müssen zu einer Situation zurückkehren, in der wir nachvollziehen können, was tatsächlich auf dem Rechner läuft, anstatt dieses nicht-deterministische Ding, das wir derzeit haben.

Ist das der Grund? Speziell wegen des nicht-deterministischen Verhaltens?

Ja, aber auch die Performance wird extrem hoch sein, wenn man eine solche Laufzeitumgebung hat.

Mhm.

Und zweitens, ähm unsere Systeme sind ein wenig weitläufig. Wenn man also für eine GPU entwickeln will, muss man völlig anders programmieren, in einem komplett anderen Stil, als wenn man

für eine CPU schreibt. Das liegt daran , dass CPUs extrem hoch auf Pfadfindung und das Vorladen von Daten und all diese Dinge innerhalb der CPU optimiert sind. Und eine GPU ist sehr

sind. Und eine GPU ist sehr deterministisch. Man reserviert also

deterministisch. Man reserviert also einfach einen Speicherbereich, füllt ihn, führt einige Funktionen darauf aus, und das war's. Man hat keinen Heap , keine dynamische Speicherverwaltung, nicht all diese Komplexität, die man auf einer CPU hat. Nun ist es sehr

schwierig, die GPU auf das Niveau der CPU zu heben. Und ich halte das auch für einen schlechten Ansatz. Ich

glaube, wir müssen die CPU auf deterministische Weise zurück zu dem führen, was eine GPU tut, aber mit anderen Rechenmodellen obendrauf. Und

das wird sicherstellen, dass wir mehr dieser Möglichkeiten wie SIMD nutzen können und mehr Strukturen wie: „ Okay, du willst eine Art Graphstruktur haben?“„Okay, lass uns das irgendwo

haben?“„Okay, lass uns das irgendwo projizieren.“„Und das ist meiner

projizieren.“„Und das ist meiner Meinung nach der Kern dessen, was wir in Zukunft brauchen. Wir müssen sehr deterministische Sprachen haben. Ähm

Ich glaube, ich habe vergessen zu sagen , warum eine deterministische Sprache wichtig ist. Stell dir einen Satelliten

wichtig ist. Stell dir einen Satelliten vor. Du schießt ihn ins All. Er hat

vor. Du schießt ihn ins All. Er hat

eine endliche Menge an Speicher.

Mhm.

Und wenn man Heap-Allokationen hätte, bekäme man „Out of Memory“- Exceptions oder Null-Pointer-Exceptions in seinem Satelliten. Das will man nicht.

Nein.

Wir bewegen uns immer mehr in Richtung Robotik, Satelliten, maschinelles Lernen und all diese Dinge. Und da

möchte man, dass es so deterministisch wie möglich ist. Wenn du 2 GB Speicher hast, willst du genau wissen, dass die Anwendung niemals darüber hinausgeht.

Deshalb können wir, glaube ich, keine dynamischen Zuweisungen mehr verwenden.

Ich glaube, das ist der Grund, warum Leute vieles in Rust bauen, zumindest wenn wir von Satelliten sprechen. Im

Wesentlichen, weil ich erwarte, dass viele Fehler so früh wie möglich erkannt werden, damit sie nicht auftreten, wenn es tatsächlich im Weltraum läuft.

Ähm, Rust hat einen Standard mit einem sehr reduzierten Satz an Sprachfunktionen, um die Sprache deterministisch zu machen.

Mhm.

Aber es ist wirklich mühsam zu schreiben.

Mhm.

Zumindest war das meine Erfahrung.

Von Hand.

Ja.

Hast du damit experimentiert, Agenten Rust schreiben zu lassen?

Ja.

Wie war das?

Es war langsamer als bei den meisten anderen Sprachen, aber es hat irgendwie Spaß gemacht. Die Agenten sind also

Spaß gemacht. Die Agenten sind also ziemlich gut darin. Sie unterteilen den Code nicht so, wie ich es gerne hätte.

Und ich fand es schon immer sehr schwer , Rust später zu ändern.

Mhm.

Also, wenn man ein Stück Rust-Code hat , das funktioniert, fasse ich es lieber nicht mehr an.

Es ist fertig.

Ja.

Ja.

Ja. In anderen Sprachen ist es viel einfacher, mit dem Refactoring zu beginnen.

Mhm. Äh, aber das ist meine persönliche Erfahrung mit Rust. Ich

möchte niemanden davon abhalten, die Sprache auszuprobieren, denn sie ist wunderschön und hat viele Funktionen, die man sich von einer modernen Sprache wünscht, wie diskriminierte Unions und all diese Dinge. Aber der Borrow Checker ist an sich nur eine

Möglichkeit, Heap-Daten zu verwalten.

Und wenn man keinen Heap hätte, bräuchte man keinen Borrow Checker.

Stell dir also vor, du hast einen Datensatz und legst ihn im Speicher ab, und das Einzige, was du hast, ist der Startindex dieses Datensatzes. Und

dieser Datensatz wird immer da sein, weil zu Beginn deiner Anwendung alle Daten bereits im Speicher angelegt sind . Jetzt hast du den Startindex und nur

. Jetzt hast du den Startindex und nur noch Offsets für alle Felder in deinem Datensatz. Das ist rasend schnell.

Datensatz. Das ist rasend schnell.

Ja. Interessant. Wird diese neue Sprache nur eine Sprache sein, glaubst du? Werden wir konvergieren?

du? Werden wir konvergieren?

Ähm, meine Meinung dazu ist, dass es genau deshalb diese drei Ebenen gibt.

Ja. Ich denke, die resultierende Laufzeitumgebung und der resultierende Code werden identisch sein.

Okay.

Aber die Ebenen dazwischen werden mehr oder weniger Plug-and-Play sein.

Hm. Interessant.

Ich denke, es wird so weit gehen, dass jeder allein durch das Gespräch mit seinem Agenten seine eigene Sprache darüber definiert.

Mhm. Das Problem, das ich manchmal habe , zumindest wenn ich meine Agenten effektiver machen will, und das ist auch ein Problem zwischen Menschen, Teams und verschiedenen Hierarchien, ist das Sprechen derselben Sprache.

Wenn ich Komponente sage, was bedeutet das? Wenn ich von einem Agenten spreche

das? Wenn ich von einem Agenten spreche , ist das ein benutzerdefinierter Agent , ein lokaler Agent, ein Unteragent, ein Hauptagent? Ich weiß es nicht.

ein Hauptagent? Ich weiß es nicht.

Jede Art von anderen Agenten, die die Leute im Kopf haben. Dasselbe zu sagen war schon immer ein Problem. Wie

würden die Leute bei dieser neuen Arbeitsweise, bei der du erwähnst, dass jeder seine eigene Sprache und Interaktion definiert, diese gemeinsame Sprache überhaupt noch schaffen?

Ja. Das ist die Millionen-Dollar-Frage, glaube ich. Meine persönliche Sicht

glaube ich. Meine persönliche Sicht darauf ist, ähm wenn ich 20 Jahre zurückgehe und ein CRM-System bauen würde, gab es keine Diskussion

darüber, was ein Kunde ist, denn der Kunde ist eben dieses Schema.

Mhm.

Wie man zu diesem Schema gelangt, das ist schwierig. Und wie sich dieses

ist schwierig. Und wie sich dieses Schema entwickelt, das ist schwierig.

Aber das Jetzt, das ist die Definition eines Kunden. Der schwierigste Teil ist

eines Kunden. Der schwierigste Teil ist also, zu einer Definition zu kommen und von dort aus zu iterieren. Wenn ich die Frage richtig verstehe, wäre meine Annahme, dass wir viel einfacher

anfangen müssen als das, was wir jetzt tun.

Mhm.

Selbst wenn ein Kunde nur eine ID ist, wirst du feststellen, dass du sofort einen Konsens hast. Ja, natürlich

braucht ein Kunde eine ID. Und dann

fangen wir an zu iterieren.

Mhm.

Und Daten haben uns eine Menge Muster geliefert. Man kann ein Sternmodell

geliefert. Man kann ein Sternmodell haben, man kann einen Vertriebskunden, einen Marketingkunden haben. Man kann

all diese verschiedenen Dinge und Arten von Modellen haben, aber der Kern ist, dass die Vereinbarung kein fester Zeitpunkt ist, sondern die Übereinkunft über die Entwicklung dessen, was man zu bauen versucht, sein

sollte. Und weil Softwareentwicklung

sollte. Und weil Softwareentwicklung viel langsamer war, konzentrierten sich die Leute mehr auf das Jetzt als auf die Entwicklung. Das ist auch der Grund

die Entwicklung. Das ist auch der Grund , warum Agile meiner Meinung nach nicht mehr so agil ist, wie es sein sollte.

Wir haben schon mehrfach darüber gesprochen.

Ja.

Ich glaube, Agile wurde ein wenig vereinnahmt, und jetzt, mit Agenten, können wir zu dieser Idee zurückkehren: Okay, hier anfangen, schnell weiterentwickeln und es einfach machen.

Mhm. Sehr interessant. In unserem

gesamten Gespräch darüber, wie du eine Art agentenbasierte Entwicklung angehst, hatte ich nicht erwartet, dass das Scaffolding so ein entscheidender Faktor ist. Und mein Gedanke kommt vor

Faktor ist. Und mein Gedanke kommt vor allem daher, dass es zumindest in meiner Blase Leute gibt, die sagen: Ich habe schon eine Weile nicht mehr in den Code geschaut, oder? Ich bin effektiv, indem ich meinen Agenten alles erledigen lasse. Ich schaue mir den

erledigen lasse. Ich schaue mir den Code nicht an. Am Ende prüfe ich manchmal selbst, oder andere Leute prüfen meinen Code, den der Agent erstellt hat, oder ich lasse mehrere Agenten eine Art gegenseitige oder blinde Prüfung durchführen. Sie haben

eine Arbeitsweise gefunden und versuchen, ihr Verhalten so zu steuern, dass sie effektiv sind, ohne den Code anzusehen.

Ja.

Aber das ist nicht dein Ansatz.

Nein. Ich wüsste ehrlich gesagt auch nicht, worin da der Spaß bestehen sollte.

Mhm.

Es sei denn, man baut ein Produkt, das man verkaufen will und womit man Geld verdient, und man muss es so schnell wie möglich herausbringen–dann verstehe ich das. Aber wenn es rein für einen selbst ist, dann finde ich

...ich verstehe nicht, was daran Spaß

...ich verstehe nicht, was daran Spaß macht, den Agenten etwas tun zu lassen und dann einkaufen zu gehen oder ins Kino zu gehen, um dann zurückzukommen und mit dem zufrieden zu sein, was der Agent geliefert hat.

Vielleicht, wenn ich von mir selbst spreche, dann will ich das Ergebnis.

Mir wäre nicht unbedingt wichtig, wie man das Ergebnis erreicht und wie der Code aussieht oder ob er wartbar ist, aber ich wollte ganz spezifisch das Resultat dieses Ergebnisses.

Ja. Und wie passt das dann zu dem, was du vorhin sagtest, mit dem um...

Projekte nicht zu beenden?

Ja, manchmal erreiche ich dieses spezifische Ergebnis nicht. Manchmal

habe ich einen Gedanken, wie ich das lösen würde, und dann lasse ich die Agenten über Nacht darüber nachdenken . Und ich habe das Gefühl, dieses

. Und ich habe das Gefühl, dieses Verhalten wird auch dadurch stimuliert, dass ich wöchentliche Credits bekomme, und ich habe dieses FOMO-Gefühl: Wenn ich meine Credits nicht nutze, verschwende ich quasi das, wofür ich bezahle.

Mhm.

Deshalb möchte ich maximieren, was ich bekomme, besonders jetzt, weil ich glaube, dass Inferenz teurer werden könnte.

Mhm.

Aber dadurch habe ich dieses Verhalten: Lass mich einfach einen Agenten auf dieses Problem ansetzen und sehen, was dabei herauskommt. Und dann erkunde ich

dabei herauskommt. Und dann erkunde ich und schaue mir an, was da war, und manchmal erreiche ich das Ergebnis nicht, weil ich zumindest irgendeine Form von Lerneffekt habe oder mein Verhalten irgendwie orchestriert habe und etwas daraus mitnehme.

Mhm.

Das ist momentan meine Arbeitsweise.

Aber zum Beispiel, als ich einen Tag Innovationsbudget hatte, an dem wir einen Tag für irgendetwas aufwenden konnten, baute ich ein Gerüst, das Spiele erstellt, und ich hatte das bei Google gesehen. Ich war auf einer

Google gesehen. Ich war auf einer Konferenz und fragte: Werdet ihr das als Open Source veröffentlichen, weil ich es gerne mit irgendwem ausprobieren würde? Ich habe einen kleinen Bruder,

würde? Ich habe einen kleinen Bruder, der 16 Jahre jünger ist als ich. Ich

glaube, er würde es lieben, ein Spiel zu bauen.

Mhm.

Aber er weiß nicht, wie man programmiert. Ich denke, wenn ich ihm

programmiert. Ich denke, wenn ich ihm dieses Gerüst geben würde und er Spracherkennung nutzen könnte, würde er Spiele bauen. Aber sie haben es nicht als Open Source veröffentlicht.

Also dachte ich mir: Oh, dann baue ich es eben selbst. Und genau das habe ich getan. Am Ende war mein Ergebnis also,

getan. Am Ende war mein Ergebnis also, dass ich ein Gerüst habe. Mir ist

nicht unbedingt wichtig, oder ich bin auf einige Details eingegangen, was ich mir als Ergebnis für das Spiel wünsche, den Stil, vielleicht eine Template-Engine. Ich wollte

Template-Engine. Ich wollte Determinismus. Darauf habe ich meine

Determinismus. Darauf habe ich meine Zeit und Mühe wirklich konzentriert.

Wenn jemand ein Spiel mit einer bestimmten Funktionalität erstellt, möchte ich sicherstellen, dass das Ergebnis dieses Spiels, das mit meinem Gerüst erstellt wurde, dem nahe kommt, was der Benutzer erwartet. Und dann hat mein Bruder ein Spiel gebaut, das er wirklich vertieft hat, und dann hat er noch mehr Spiele gebaut, und ich habe

es meinem Partner und Leuten gegeben, die keine technischen Vorkenntnisse haben, und sie haben Spiele gebaut.

Aber ich habe mir den Code nicht wirklich angesehen. Das war das

wirklich angesehen. Das war das Ergebnis, das ich wollte.

Ja, aber das ist doch perfekt, oder? Ja

. Das ist perfekt. Denn die Absicht war nicht, zu lernen, wie man Spiele baut oder wie man eine Spiele-Engine entwickelt oder so etwas, sondern das Ziel war es, Leute glücklich zu machen .

Mhm.

Und das ist absolut in Ordnung. Aber

dann hast du dieses Ziel. Dieses Ziel

war es, ein Lächeln auf die Gesichter der Menschen zu zaubern, die du gerne lächeln siehst.

Ja.

Und das ist wunderschön. Und wenn eine zu 100%KI-codierte App das erreicht, dann nur zu, mach es.

Mhm.

Äh, aber es gibt es wird einen Unterschied geben zwischen dem, was du baust, und einem wunderschönen, handgefertigten Spiel, das von einem Team aus Experten entwickelt wurde.

Mhm.

Und auch wenn dieses wunderschöne, von Experten handgefertigte Spiel den Leuten vielleicht kein Lächeln ins Gesicht zaubert, weil sie sich denken: „Okay, ich habe 50 Euro dafür bezahlt, was soll das?“„Ähm die

Lerneffekte, die darin stecken, geben einem doch Lass mich das anders formulieren. Was wäre, wenn du dieses

formulieren. Was wäre, wenn du dieses Grundgerüst zusammen mit jemandem gebaut hättest, der 25 Jahre Game-Design-oder Spieleentwicklungs-Erfahrung hat? Was

Spieleentwicklungs-Erfahrung hat? Was hätte sich geändert?

Interessant. Ich glaube, wenn ich es mit jemandem mit diesem Erfahrungsschatz gebaut hätte, wäre ich gerne eine Ebene tiefer gegangen, denn ich habe das Gefühl, dass dort ein Großteil meiner Lerneffekte liegen würde. Sind die Entscheidungen, die

würde. Sind die Entscheidungen, die ich getroffen habe, also nur mein Agent und ich, die versuchen, so schnell wie möglich zum Ergebnis zu kommen? Sind

sie klug? Nehmen wir an, ich habe das Grundgerüst und möchte die Grafik komplett überarbeiten, denn mein Ergebnis bei bestimmten Spielen sieht zwar im Retro-Stil aus, aber sie wirken etwas zu verpixelt, oder die Grafik– ich habe andere Spiele gesehen, AAA-Titel, und ich weiß, wie das

aussieht und welches Gefühl das einem Nutzer vermitteln kann. Also würde ich eine Ebene tiefer gehen wollen. Ich

weiß nicht, ob ich das mit meinem Agenten tun könnte. Das könnten also Dinge sein, die ich frühzeitig einbringe und sicherstelle, dass sie in die Entscheidungen einfließen, die ich gemeinsam mit der Person treffe, mit der ich zusammenarbeite. Aber wenn ich das jetzt so laut ausspreche, weiß ich nicht, ob ich es überkomplizieren

würde, denn mir gefällt, dass ich so schnell wie möglich zum Ergebnis gekommen bin. Ich habe die Ergebnisse

gekommen bin. Ich habe die Ergebnisse geliefert. Ich habe eine Aktualisierung

geliefert. Ich habe eine Aktualisierung bei der Vorlagenerstellung im Grafikbereich vorgenommen. Ich bin dort

Grafikbereich vorgenommen. Ich bin dort auch steckengeblieben, also musste ich es neu machen, alles verwerfen, was ich getan hatte, und es dann noch einmal neu machen.

Mhm.

Und beim zweiten Mal hat es funktioniert.

Ja.

Ähm, aber ich würde diese Dinge vielleicht vorziehen.

Ja.

Ja.

Und im Grunde machst du dann ein Gerüst.

Mhm.

Du baust ein Gerüst für die Teile, die du für wichtig hältst.

Mhm.

Und mit diesem Gerüst gibst du deinem Agenten eine Priorisierung für die Dinge, die du brauchst. Also, das ist das ist schon immer Programmierung gewesen, oder? Wenn ich ein CRM-System

gewesen, oder? Wenn ich ein CRM-System bauen müsste, würde ich–in der Vergangenheit hätte man mit einigen Bildschirmen angefangen. Und man würde

Bildschirmen angefangen. Und man würde feststellen: Okay, meine Datenbank ist auch wichtig. Also, bei der nächsten

auch wichtig. Also, bei der nächsten Iteration–deshalb sagte ich immer, man muss eine Anwendung drei-oder viermal bauen. Beim nächsten Mal

viermal bauen. Beim nächsten Mal konzentrierst du dich mehr auf die Datenbank.

Mhm.

Und dann denkst du: Okay, aber diese Datenbank ist wirklich kompliziert zu handhaben. Also fängst du an, mehr an

handhaben. Also fängst du an, mehr an deiner Anwendungsschicht zu arbeiten.

Und dann plötzlich wird deine Anwendung mit jeder Iteration besser und besser. Und genau das Gleiche wird

und besser. Und genau das Gleiche wird mit KI-gestütztem Programmieren passieren, aber nur, wenn du dir die Zeit nimmst, einen Schritt zurückzutreten, Mhm.

wirklich zu erkennen, was du getan hast , vielleicht zu erkennen, was du anders machen oder worauf du dich mehr konzentrieren willst. Äh und und dann

konzentrieren willst. Äh und und dann wird die nächste Iteration wahrscheinlich besser sein.

Mhm.

Aber was ich beim KI-gestützten Programmieren bemerkt habe, ist, dass man an einem gewissen Punkt an eine Grenze stößt. Denn sie sind nicht gut

Grenze stößt. Denn sie sind nicht gut darin, ein altes Konzept einfach herauszureißen und komplett neu zu machen. Sie flicken es zusammen und

machen. Sie flicken es zusammen und machen es vielleicht zwei-oder dreimal in derselben Codebasis, und sie sind noch nicht gut darin, eine Anwendung zu entwickeln. Sie sind gut darin, Code zu

entwickeln. Sie sind gut darin, Code zu schreiben, aber nicht darin, eine Anwendung zu konstruieren.

Mhm.

Und deshalb ist es vielleicht ein interessantes Experiment, genau das Gleiche noch einmal zu machen, aber diesmal zu versuchen, ein Gerüst vorzugeben.

Mhm.

Erstelle einfach ein paar Ordner, lege ein paar Markdown-Dateien in diese Ordner und sage: Okay, ich möchte, dass du dies in diesem Ordner und jenes in jenem Ordner machst. Ich möchte,

dass die Abhängigkeiten ein bisschen so verlaufen. Ich möchte, dass du–

so verlaufen. Ich möchte, dass du– ich weiß nicht, ich kenne die Konzepte der Game-Engine nicht, aber vielleicht willst du Raylib verwenden und ein 2 D-Plattformspiel machen und all diese Dinge dort hineinlegen. Das ist der Assets-Ordner. So machst du das. So

Assets-Ordner. So machst du das. So

machst du das. Und und dann lass den Agenten es noch einmal versuchen. Und

ich denke, du wirst schneller zu einem ebenso guten Ergebnis kommen.

Mhm. Als du das erwähnt hast, dachte ich: Wo ist die Grenze? Wann investiere

ich die Mühe in das Grundgerüst und wann steuere ich einfach nur auf das Ergebnis zu?

Mhm.

Und dann dachte ich, vielleicht wenn ich lange und weit kommen will, oder?

Wenn ich also wirklich glaube, dass meine Zeit und Mühe tief in das Projekt fließen, das ich baue, dann investiere ich vielleicht wirklich die Zeit und Mühe, um ein solides Fundament zu haben. Und wenn ich einfach nur schnell ein Ergebnis will, dann ist es in Ordnung, sich den Code nicht anzusehen, nicht auf das Grundgerüst zu achten–vielleicht ist

es nur ein Experiment, oder? Vielleicht

ist es ein Proof of Concept, um zu sehen, ob ich überhaupt ein Gerüst für die Spielgenerierung bauen kann.

Mhm.

Und dann hält mich nichts davon ab, das wegzuwerfen und es noch einmal zu versuchen. Und dann zu schauen, wie

versuchen. Und dann zu schauen, wie weit ich komme und immer weiter zu iterieren. Dieser Gedankengang gefällt

iterieren. Dieser Gedankengang gefällt mir. Ich glaube, wir werfen nicht oft

mir. Ich glaube, wir werfen nicht oft genug weg, was wir gebaut haben. Alles,

was ich gebaut habe, ist irgendwo auf meinem GitHub oder irgendwo auf meinem Laptop. Es ist alles da.

Laptop. Es ist alles da.

Ja.

Außer wenn das, was ich versucht habe, nicht funktionierte, dann habe ich es weggeworfen.

Ja.

Ja.

Und genau das bieten einem jetzt die Agents. Code ist günstig.

Agents. Code ist günstig.

Mhm.

Also schnell iterieren, oft wegwerfen und einfach neu machen.

Mhm.

Ich habe sogar ein sehr cooles Muster bemerkt: Ich erstelle einfach drei Branches und lasse die Agents–oder drei Agents–in diesen drei Branches oder Worktrees arbeiten, wie auch immer . Und dann bitte ich einen vierten

. Und dann bitte ich einen vierten Agenten, ihre Ergebnisse zu vergleichen . Und führe nur die guten Teile

. Und führe nur die guten Teile zusammen.

Ja. Interessant. Breit ansetzen und dann alle Erkenntnisse daraus destillieren.

Ja.

Ja. Du erwähntest, dass das Grundgerüst ein wirklich gutes Unterscheidungsmerkmal war. Und wenn

Unterscheidungsmerkmal war. Und wenn man dieses Gerüst hat, läuft dann alles automatisch, oder was sind die Zutaten, die deinen agentenbasierten Workflow effektiv machen?

Oh, das Grundgerüst funktioniert unglaublich gut.

Mhm.

Ich muss zugeben, ich habe das Gerüst tiefer und weiter aufgebaut, als ich es anderen empfehlen würde. Wenn ich zum Beispiel eine Rust-Anwendung erstelle, generiere ich die Crates. Wenn ich eine

C#-Anwendung baue, generiere ich die C# -Projekte. Ich gebe den Projekten Namen

-Projekte. Ich gebe den Projekten Namen . Ich lege Markdown-Dateien in das

. Ich lege Markdown-Dateien in das Projekt, um die Grenzen zu erklären.

Ich zeichne normalerweise schnell eine Art Diagramm, in dem ich ihnen sage: „Okay, das ist die Funktionalität, die ich hier haben will. Das ist die Funktionalität, die ich dort haben will.“ Ich erstelle meistens auch die

will.“ Ich erstelle meistens auch die Ordnerstruktur und einige der Kerndateien, die ich dort erwarte.

Mhm.

Wie gesagt, bei einem Compiler schreibe ich die Lexer-Datei und sogar die Signatur des Lexers. Das bedeutet, ich habe mir Gedanken darüber gemacht, was ein Token für mich sein soll. Wenn ich

nicht angebe, was ein Token sein soll, wird der Agent einfach eine Aufzählung all meiner Tokentypen erstellen und vielleicht eine Art Position im Quellcode angeben. Aber wenn ich das

Quellcode angeben. Aber wenn ich das Token so vordefiniere, dass es genau das enthält, was ich möchte–also den Quellcode von hier bis hier in dieser Datei, von dieser Zeile bis zu dieser Zeile–, erhalte ich ein viel besseres Ergebnis, mit dem ich später weiterarbeiten kann.

Mhm.

Und der Agent arbeitet dann sehr gerne einfach mit dem, was ich ihm gegeben habe.

Ja. Hast du irgendwelche Open-Source-Projekte, die ich in den Shownotes teilen kann, damit die Leute sehen können, wie du das mit dem „ Scaffolding“ oder generell deine Herangehensweise gelöst hast?

Äh, ja. Aber da bin ich etwas vorsichtig, denn die Sprache, über die wir gerade sprachen, ist genau die, die ich gerade versuche zu entwickeln.

Verstehe.

Rein mit Agenten, und ich freue mich, wenn sich das jeder ansieht, aber es befindet sich noch in einer so experimentellen Phase, dass es wohl Tja

, Menschen tun sich schwer, äh, die erste Erfahrung, die sie mit etwas machen, wieder zu vergessen.

Mhm.

Und ich zögere ein wenig, dass Leute ein Projekt in einem so frühen Stadium sehen, äh, ohne eine Art Leitfaden dazu, wie es sich entwickeln wird oder was die Ideen dahinter sind. Vielleicht

sollte ich diesen Podcast verlinken.

Ja.

In der Readme-Datei.

Weil ich, wie gesagt, daran denke, die gleiche Sprache zu sprechen. Wenn du

„Scaffold“ sagst, habe ich zwar eine Vorstellung davon, was ein Gerüst bedeutet. Aber dann habe ich gehört,

bedeutet. Aber dann habe ich gehört, wie du die Tiefe dessen dargelegt hast, was Scaffolding für dich bedeutet, oder zumindest dein Ansatz dazu.

Deshalb wollte ich ein Beispiel sehen.

Ja. Ja.

Ich habe mit jemand anderem gesprochen, der tatsächlich auch darüber nachdenkt, wie die neue Art der Softwareentwicklung oder Softwareerstellung aussehen wird. Ich

werde euch beide vernetzen, denn ich glaube, ihr werdet ein spannendes Gespräch darüber haben.

Ja, das wäre sicher cool.

Ja.

Ich denke, das wäre cool. Ich glaube

auch, dass es Zeit für eine Ich will nicht „Revolution“ sagen, Mhm.

aber wenn wir Software demokratisieren, bedeutet das, dass wir mehr Menschen helfen können. Es bedeutet aber auch,

helfen können. Es bedeutet aber auch, dass wir Software bauen müssen, die Menschen hilft. Daher wäre ich sehr

Menschen hilft. Daher wäre ich sehr daran interessiert, eine Art Organisation oder Gemeinschaft zu gründen, in der wenn äh äh wenn Kommunen, Mhm.

Wenn zum Beispiel Software gebraucht wird, ist es für Leute, die ein paar Token übrig haben, sehr einfach, mit dem Aufbau der Dinge zu beginnen, die Gemeinden brauchen.

Mhm.

Und wir können Software entwickeln, um einige der Probleme zu lindern. Ich

weiß zum Beispiel, dass es schwierig ist, einen Rollstuhl zu bekommen, oder dass es sehr lange dauert. Vielleicht

kann jemand Software schreiben, um dabei zu helfen. Aber das erreichen wir nur, wenn wir diese Probleme klar und zentral erfassen, damit sich jeder etwas aussuchen kann, bei dem er sich wohlfühlt.

Mhm.

Und da Software derzeit so demokratisiert wird, kann einfach jeder loslegen. Wir brauchen auch eine Ebene

loslegen. Wir brauchen auch eine Ebene von Leuten, die anderen beibringen: „ Okay, aber du musst da einige Sicherheitsvorkehrungen einbauen.“„

Sicherheitsvorkehrungen einbauen.“„ Wenn du die KI nicht anweist, eine Sicherheitsprüfung durchzuführen, Mhm.

oder einen Penetrationstest oder ähnliches für deinen Code zu machen, wird sie das nicht von alleine tun.“

Mhm.

Wir müssen also Ingenieure mit Leuten zusammenbringen, die Software entwickeln wollen, um unsere Gemeinschaften voranzubringen. Und ich

Gemeinschaften voranzubringen. Und ich denke, darauf müssen wir uns als Branche konzentrieren. Wir müssen

Branche konzentrieren. Wir müssen anfangen, unsere Anstrengungen zu bündeln. Denn die alten Methoden, bei

bündeln. Denn die alten Methoden, bei denen man sagt: „Okay, wir sind die Experten. Wir sind die Einzigen, die

Experten. Wir sind die Einzigen, die das können.“ Das funktioniert

das können.“ Das funktioniert einfach nicht mehr.

Nein. Die die Hürden wurden gesenkt.

Die Eintrittsschwelle ist also plötzlich wirklich sehr niedrig.

Ja.

Man kann ziemlich schnell Fortschritte machen. Die Leute können mit jeder

machen. Die Leute können mit jeder Idee, die sie haben, auf Ergebnisse hinarbeiten.

Ja.

Aber ich habe das Gefühl, dass die Leute, die schon lange in der Branche sind, wissen, was richtig oder falsch ist, und die neue Generation hat diesen Geschmack oder das Bauchgefühl noch nicht wirklich.

Ja. Ja.

Und wenn man sich die rückläufigen Zahlen in den Ingenieurwissenschaften und den Software-Studiengängen an den Hochschulen ansieht, ist es unglaublich beängstigend, wie die Zukunft aussehen wird. Wir bilden unsere Junioren nicht

wird. Wir bilden unsere Junioren nicht mehr aus, weil wir ihnen einfach nur noch Agenten geben. Wir machen nicht einmal mehr vollständige PR-Zyklen, also Pull-Request-Zyklen, bei denen wir Kommentare und ähnliches abgeben, wo man ein ehrliches Gespräch über die

Qualität der Software führt. Wir

machen das alles nur noch über KI. Und

mein einziger Gedanke dabei ist, dass wir eine Generation darin ausbilden, ein Werkzeug zu benutzen, ihr aber nicht beibringen, wie man es eigentlich macht.

Mhm.

Und wenn also etwas passiert, wenn die Tokens sehr teuer werden und wir sie nicht mehr nutzen können, wenn aus irgendeinem Grund die KI verschwindet, ähm, dann bricht alles zusammen.

Mhm.

Und das ist ein beängstigender Gedanke .

Mhm. Glaubst du, dass das passieren wird? Ist das also eine Blase und wird

wird? Ist das also eine Blase und wird diese Blase platzen? Wird dann nichts mehr übrig sein?

Wenn ich ehrlich bin, sehe ich drei Dinge, die gerade passieren. Ich sehe

echte revolutionäre KI-Durchbrüche.

Ja, AlphaFold, ähm, diese Zellforschung, an der Google arbeitet, ähm, medizinische Fortschritte, Materialwissenschaften, all diese Dinge . Das ist umwerfend.

. Das ist umwerfend.

Wunderschön.

Ja. Das ist für mich wahre KI. Ähm,

Robotik, selbstfahrende Autos, das ist ...Ich habe mit meinen Kindern

...Ich habe mit meinen Kindern gesprochen und versucht ihnen zu erklären, wie es sich anfühlt, in so einer Welt zu leben, nachdem ich 47 Jahre lang nicht in so einer Welt gelebt habe.

Ja.

Und das einzige Wort, das mir einfiel, war Magie.

Mhm.

Aber dann gibt es die LLMs. Und LLMs sind wahnsinnig cool, aber sehr verschwenderisch, Mhm.

sehr energieineffizient. Unternehmen

geben eine Menge Geld aus. Und ich bin mir nicht sicher, ob sie uns halten werden, was alle versprechen. Das

fühlt sich also nach einem Hype und nach einer Blase an, auch wenn der Nutzen beim Programmieren extrem hoch ist. Ja. Unglaublich. Ja. Und dann ist

ist. Ja. Unglaublich. Ja. Und dann ist die letzte Ebene, denke ich, die...das

Machtgleichgewicht hat sich so verschoben, dass wenn man sich die größten Unternehmen mit dem meisten Geld ansieht, fast alle Tech-Unternehmen sind. Das ist

Tech-Unternehmen sind. Das ist beängstigend. Mhm. Besonders aus Sicht

beängstigend. Mhm. Besonders aus Sicht von Datenschutz und Sicherheit.

Nun, was ist der beängstigende Teil bei diesem letzten Punkt?

KI wurde immer als der große Gleichmacher verkauft. Und ich sehe

Gleichmacher verkauft. Und ich sehe noch keine Angleichung.

Mhm.

Und ich bin mir nicht sicher, ob es zu einer Angleichung kommen wird.

Es gibt also eine Zukunft, in der die Reichen reicher werden und keine Angleichung stattfindet.

Ja.

Mhm. Ja. Ja, ich weiß wirklich nicht, wohin das führen wird. Tatsächlich.

Ich habe ein sehr seltsames Gefühl, weil ich noch nie eine Art technologische Revolution in meinem Leben miterlebt habe. Ich glaube nicht, dass das viele Leute erlebt haben.

Vielleicht als das Internet aufkam, da war das eine Sache, aber da war ich nicht dabei. Dieses Gefühl, das ich

nicht dabei. Dieses Gefühl, das ich jetzt habe, ich weiß nicht, ob es mit dem Gefühl von damals vergleichbar ist . Denn die Branche entwickelt sich

. Denn die Branche entwickelt sich gerade so schnell. Wenn ich in den Urlaub fahre und auch nur zwei Wochen weg bin, gibt es vielleicht schon wieder etwas Neues, das ich komplett verpasst habe und das die Art und Weise , wie Software entwickelt wird, revolutioniert. Und genau damit setze

revolutioniert. Und genau damit setze ich meinen Beruf immer noch gleich.

Egal was ich tue, selbst wenn ich mich mehr auf die übergeordnete Ebene begebe und weniger operativ tätig bin, identifiziere ich mich immer noch stark mit der Rolle des Softwareentwicklers.

Ich weiß nicht einmal, ob ich diesem Titel damit gerecht werde, aber aus Sicht meiner Identität fühlt es sich einfach so an. Es ist schon seltsam, in einem Bereich zu arbeiten, in dem sich alles so unglaublich schnell bewegt, und zu sehen, wie andere über soziale Medien oder ihre eigenen

Informationskanäle bei jeder Neuerung auf dem Laufenden bleiben. Oder Leute,

die einfach ihren täglichen Job machen und sagen: „Das ist für mich nicht greifbar.“„Vielleicht ist es eine

greifbar.“„Vielleicht ist es eine Blase, vielleicht auch nicht“, und die einfach ihr Leben weiterleben. Es

ist momentan eine sehr interessante Kluft.

Ja. Aber für mich läuft es immer wieder auf das Lernen hinaus. Ähm, ich

denke als eines der ersten ChatGPTs rauskam, nicht ChatGPT 1, aber ich glaube zwei, äh vielleicht drei. Ähm,

ich habe mir ein Buch über maschinelles Lernen gekauft. Ich habe

meine eigenen neuronalen Netze gebaut.

Ich habe schnell gemerkt, dass meine neuronalen Netze nicht so gut sind wie die großen, also wurde mir klar, dass Skalierung tatsächlich wichtig ist, und all diese Erkenntnisse waren wirklich wertvoll. Ich sage nicht, dass

wirklich wertvoll. Ich sage nicht, dass ich ein großes Sprachmodell bauen kann , denn es geht längst nicht mehr nur um das neuronale Netz, das man baut.

Sondern es geht um alles, was drumherum passiert. Ähm, aber allein das

passiert. Ähm, aber allein das Erlernen der Grundlagen, das Verständnis dafür, was passiert, gibt einem eine so solide Basis, dass man nicht das Gefühl hat, etwas verpasst zu haben, wenn man zwei Wochen in den

Urlaub fährt. Ich glaube, wenn man

Urlaub fährt. Ich glaube, wenn man einen guten Urlaub macht, kommt man bereicherter zurück, als man gegangen ist.

Ja, ja. Ich meine, ich mache immer noch Urlaub. Ja. Ich Wir haben mit deinem

Urlaub. Ja. Ich Wir haben mit deinem Workflow für genetisches Engineering begonnen, und ich möchte sicherstellen , dass ich dem gerecht werde und das weiter vertiefe. Du erwähntest, dass

weiter vertiefe. Du erwähntest, dass Scaffolding zu den Dingen gehört, die einem einen wirklich großen Schub geben.

Ja.

Ich habe auch von diesem Konzept des Loop-Engineerings gehört. Und für

Loop-Engineerings gehört. Und für mich beinhaltet Loop-Engineering eine Art Vorwärts-und Rückwärtsdruck. Ich

habe das Gefühl, dass das Scaffolding wirklich den Vorwärtsdruck erzeugt.

Was sind also die Dinge, die vorhanden sein müssen, bevor man überhaupt mit dem Looping beginnt? Und wie sieht es mit Gegendruck aus, hast du da etwas eingerichtet? Hast du also

eingerichtet? Hast du also deterministische Pfade oder Tools, die dem Agenten helfen, innerhalb der vorgegebenen Grenzen oder des gesetzten Rahmens zu bleiben? Oder passiert das irgendwie automatisch?

Ähm ja, ich habe eine Menge dieser Tools. Aber ich entwerfe sie immer und

Tools. Aber ich entwerfe sie immer und immer wieder neu, jedes Mal, wenn ein neues Modell herauskommt.

Mhm.

Also, ähm Ich denke über diese Probleme immer nach, indem ich versuche , zu einer Art Prinzipienansatz zurückzukehren. Wissen aufzubauen,

zurückzukehren. Wissen aufzubauen, damit deine KI Entscheidungen treffen oder kommunizieren kann, bedeutet, dass du sie mit Informationen füttern musst . Denn dein Kontext setzt sich ständig

. Denn dein Kontext setzt sich ständig zurück. Aber du willst nicht, dass er

zurück. Aber du willst nicht, dass er zu groß wird, sonst fängt sie an zu halluzinieren, funktioniert nicht mehr gut und es ist zudem sehr teuer. Wie

ich also über diese Dinge nachdenke: Genau das ist ein soziales Netzwerk.

Mhm.

Also entwerfe ich mein Gerüst, mein System, im gleichen Stil wie den Aufbau eines sozialen Netzwerks. Zuerst suchst

du deine Verbindungen. Du findest die Informationsknoten, die wichtig sind.

Dann erhältst du ein paar Metadaten zu diesen Informationen, wie einen Einzeiler, einen Commit-Hash oder einen Ordner, in dem du mehr Informationen findest. Dann bewertest du einfach, wie

findest. Dann bewertest du einfach, wie gut die gefundenen Informationen zu dem passen, was du tun möchtest.

Vielleicht holst du den Menschen ins Boot. Ist das die Information, nach der

Boot. Ist das die Information, nach der du suchst? Ja? Das ist die Information,

du suchst? Ja? Das ist die Information, nach der ich suche. Danke, kleine KI.

Und dann geht sie immer tiefer, bis sie tatsächlich den Commit-Pfad findet, deinen Code durchgeht und herausfindet, was passiert. Ich lasse meine KIs also

was passiert. Ich lasse meine KIs also immer einen Commit oder Diff ansehen, bevor ich sie auf den gesamten Code loslasse.

Oh.

Ich habe festgestellt, dass die Betrachtung der Änderung zuerst eine sehr gute Methode ist, um den Kontext vorzubereiten oder, ich habe fast das Gefühl, es ist ein Aufwärmen Mhm.

für die eigentlichen Codedateien.

Interessant. Ich kannte das Konzept der progressiven Offenlegung, aber das hinterlässt wirklich Brotkrumen für die KI, damit sie sich entfalten und das richtige Stück Information finden kann. Ich habe das Gefühl, das geht

kann. Ich habe das Gefühl, das geht eine Ebene tiefer, weil du schon sagtest, bei einer großen Informationsmenge gibt es eine Art Neu-Ranking und dann schaust du dir sogar vor dem Start die Commits an.

Hast du das alles genau so in deinem System implementiert?

Ja.

Erst festlegen, dann eine Art schrittweise Offenlegung und Neugewichtung, bis man die richtigen Informationen findet.

Ja.

Interessant.

Ja. Und es ist verteilt.

Mhm.

Zum Beispiel, ähm, ich nenne es einen Recherche-Agenten, aber es ist ein wenig weniger als das. Aber er macht das mit URLs, Websites und all diesem Kram. Und dann, wie gesagt, hast du

Kram. Und dann, wie gesagt, hast du einen Einzeiler mit Informationen, und du kannst eine Ordnerstruktur, einen Pfad, einen Hash oder auch eine URL haben, um etwas tiefer zu graben und mehr Informationen zu finden. Es ist

also mehr wie, ja, es ist buchstäblich ein Netzwerk, ein Informationsgraph für diese schrittweise Offenlegung.

Aber du erstellst oder speicherst das am Ende nicht in einer Graphdatenbank?

Du baust den Graphen einfach organisch auf?

Ja.

Interessant.

Ja, und ich speichere es nicht in einer Graphdatenbank, weil ich möchte, dass es verteilt bleibt.

Ja.

Und deshalb mache ich das derzeit mit einer Kombination aus Markdown-Dateien für die Knoten und Kanten, ähm, mit einer vektorisierten Indexsuche und einer Stichwortsuche im Header des Markdowns.

Mhm.

im Frontmatter. Und es ist eine Kombination von Dingen, die zusammenwirken, und Pfaden, mit denen ich versuche, einen Weg zur Verwaltung all dieser Daten zu finden. Aber

momentan hält es stand. Ähm, und es ist tatsächlich ziemlich wertvoll, weil ich meinen Agenten auch strukturiert habe.

Der erste Agent, mit dem ich spreche, hat immer diese Idee eines offenen Modus. Er wird

niemals Code anfassen. Er wird niemals, ähm, meinen Rechner verändern.

Sondern er ist nur dazu da, dass ich mich mit dem Agenten unterhalte und er mir entweder etwas beibringt oder ich ihm.

Mhm.

Und das fließt zurück in diesen Graphen, in diese Informationen. So ist

es für die nächste Sitzung leicht abrufbar. Und dann kann er Unteragenten

abrufbar. Und dann kann er Unteragenten starten, um die eigentliche Arbeit zu erledigen.

Mhm.

Und ich habe festgestellt, dass dies eine gute Arbeitsweise ist, weil ich möchte, dass er mich so viel wie möglich fragt und mir das zurückgibt, bevor er tatsächlich mit der Arbeit beginnt.

Mhm. Heißt das auch, dass du nicht über mehrere Hauptagenten-Schleifen hinweg parallelisierst? Oder doch?

hinweg parallelisierst? Oder doch?

Doch, tue ich.

Das tust du.

Ja.

Also hast du immer noch die Arbeitsweise, dass der Agent, mit dem du sprichst, keinen Code ändert und nichts an deinem Dateisystem verändert . Das ist die Interaktion, und für die

. Das ist die Interaktion, und für die Arbeit startet er Unteragenten.

Ja.

Aber du parallelisierst das trotzdem und hast eine weitere Hauptagenten-Schleife mit demselben Verhalten.

Ja.

Interessant. Warum warum lässt du den Hauptagenten keine Dateien ändern?

Standardmäßig können sie das und sie sind dabei wirklich ehrgeizig und proaktiv, aber du hast bewusst gesagt: Tu das nicht.

Ja.

Warum ist das so?

Äh, weil ich möchte, dass er sich auf das konzentriert, worum ich ihn bitte.

Ich Also, was ich bemerkt habe, ist, ich bin in ein Projekt gegangen. Ich

habe auch eine Game-Engine gebaut und fragte ihn innerhalb dieses Projekts: „Hey, was hältst du von der Rede von John Cleese über die offenen und geschlossenen Modi der Kreativität?“

Und er fragte mich: „Soll ich das in deinem Projekt implementieren?“

Mhm.

Natürlich willst du das. Und das war so ein Aha-Moment, wow, er konzentriert sich nur auf eine einzige Sache.

Mhm.

Wie soll ich jemals eine gute Antwort von diesem Ding bekommen, wenn es nur darauf aus ist: Kann ich den Code für dich schreiben?

Ja, momentan.

Momentan, ja. Und deshalb habe ich ihn einfach gezwungen, das nie wieder zu tun.

Interessant.

Und stattdessen ein Gespräch zu führen, und nur wenn es So, ich habe dieses Bewertungssystem und ich nutze auch ein paar Modelle für die Bewertung, wie ein Gemini 4. Ich habe

immer ein Gemini 4 im Hintergrund für lokales Scoring laufen. Ähm, und nur wenn sich der Agent zu über 90%sicher ist, dass er weiß, was ich will, Mhm.

möchte ich, dass er mich fragt, ob er Sub-Agenten starten soll.

Verstehe. Ja.

Und wenn er dann Sub-Agenten startet, kann er die Aufgabe einfach erledigen.

Er er kann also für 12 Stunden laufen.

Das ist mir egal. Starte einfach

mehrere Agenten. Das ist mir egal. Aber

fang nicht an, bevor du dir nicht unglaublich sicher bist, dass du verstehst, was ich sage.

Mhm.

Und das das ist der Moment. Das ist der Moment, in dem er anfangen kann.

Interessant. Hast du dann auch angefangen, die Art der Vorarbeit, die du leistest, zusammen mit dieser Agenten-Schleife zu verlagern? Also,

wenn du eine Idee hast, kann das ein Teil eines Features sein, ein bestimmtes Interface, das du vertiefst, oder ein ganzes Feature-Set, das du ausarbeitest. Hat sich das geändert?

ausarbeitest. Hat sich das geändert?

Gehst du riesig vor? Gehst du klein vor ? Was sind so die Größenordnungen?

? Was sind so die Größenordnungen?

Ich gehe so riesig wie möglich vor.

Wirklich? Ja. Okay.

Weil Agenten, die ich gefunden habe, schlecht darin sind, Änderungen vorzunehmen, aber gut darin, es in einem Durchgang zu tun.

Mhm.

Es ist fast so, als wäre ihr Training ein Einmal-Training und kein iteratives Entwicklungstraining für deine Codebasis.

Das ist es, was ich bei den Benchmarks gesehen habe. Ja.

gesehen habe. Ja.

Ja.

Ich ich ich teile diese Folge, die ich mit Dex Orthy gemacht habe. Er ist der Typ, der den Begriff Context Engineering geprägt hat. Und er

erzählte mir von diesem Benchmark namens Slop Code Bench.

Ja.

Und der Slop Code Bench Benchmark testet genau das, was du testen willst.

Eine Änderung passiert, dann kommt eine neue Funktionalität hinzu, dann passiert eine weitere Änderung, oder etwas hat sich in der bereits gebauten Funktionalität geändert, also musst du vielleicht refactoren oder Dinge ändern, und das tun sie über einen Zeitraum hinweg. Und damals, als du mir

Zeitraum hinweg. Und damals, als du mir das mitgeteilt hast, war es so 6.0, glaube ich, oder sogar 5.6. Und es

waren 15%von 100%. Also, irgendwann

blieb es einfach stecken, die Änderungen gingen kaputt und plötzlich fing es an zu halluzinieren oder konnte den Kontext nicht wirklich verwalten. Es gab Fehler in diesem

verwalten. Es gab Fehler in diesem kontinuierlichen Prozess der Softwareentwicklung. Und ich habe das

Softwareentwicklung. Und ich habe das Gefühl, das deckt sich mit dem, was du kommuniziert hast, dass es darin einfach nicht gut ist und wirklich gut im One-Shot-Verfahren.

Ja.

Es war jedoch nicht das, was ich erwartet hatte. Ich hatte erwartet,

erwartet hatte. Ich hatte erwartet, dass es überschaubar ist, dass ich die Informationen auch verdauen kann, mir möglicherweise den Code ansehe, möglicherweise überprüfe, was da ist , um zu sehen, ob es meinen Erwartungen entspricht. Ich möchte, dass

entspricht. Ich möchte, dass Änderungen klein sind. Aber du machst das Gegenteil von dem, was ich erwartet habe. Also stellst du sicher, dass alle

habe. Also stellst du sicher, dass alle Erwartungen im Voraus erfüllt werden.

Du validierst das sogar. Du hast Gemma als lokales Modell erwähnt, um eine Art Vertrauensprozentsatz zu haben. Und

dann lässt du es einfach laufen.

Ja, aber da kommt mein Gerüst ins Spiel.

Ja.

Das meiste davon ist bereits als Gerüst vorhanden.

Interessant. Siehst du dir den Output an? Überprüfst du den Code?

an? Überprüfst du den Code?

Oh ja, und ich werfe ihn weg, wenn er mir nicht gefällt. Wenn ich ihn nicht verstehe, werfe ich ihn weg.

Okay. Wie sieht dann dieser Feedback-Zyklus aus? Also, nehmen wir

Feedback-Zyklus aus? Also, nehmen wir an, du machst die Vorarbeit. Da du

sagst, es ist besser bei Einmalaktionen , gehe ich davon aus, dass viel Zeit und Mühe hineinfließt, oder? Ja. Ein

ganzes Feature-Set erfordert viel Vorüberlegung. Ja. Also läuft es dann

Vorüberlegung. Ja. Also läuft es dann stundenlang.

Ja.

Und dann überprüfst du es. Wie

bringst du dieses Feedback zurück in die Agentschleife, wenn es nicht dem entspricht, was du erwartet hast? Oh,

wenn es äh ich arbeite immer in einem Worktree. Ja. Und ich werfe es einfach

Worktree. Ja. Und ich werfe es einfach weg, wenn ich es nicht verstehe. Ich

versuche gar nicht erst tiefer einzusteigen, denn ich weiß: Wenn ich es nicht verstehe, hat es das Grundgerüst, das ich vorgegeben habe, nicht eingehalten. Mhm. Und ich weiß,

nicht eingehalten. Mhm. Und ich weiß, dass es mich später beißen wird, wenn ich es einfach in meinen äh meinen Code merge. Mhm. Dass ich es nicht

Code merge. Mhm. Dass ich es nicht erkenne, das meine ich damit, wenn ich sage, ich verstehe es nicht. Ich meine,

ich könnte tief einsteigen und versuchen, es zu verstehen. Aber wenn

ich nicht sofort, wenn ich nicht in der Lage bin, den Code zu sehen und all die Dinge zu finden, von denen ich dachte, dass sie da sein sollten, werfe ich es einfach weg. Nochmal von vorne. Es ist

einfach weg. Nochmal von vorne. Es ist

also kein traditionelles Code-Review.

Du machst nur einen Scan, nach dem Motto: Erkenne ich das wieder und entspricht es meinen Erwartungen? Das

ist der erste Schritt. Mhm. Der erste

Schritt ist nur: Entspricht das meinen Erwartungen? Und das mache ich schon

Erwartungen? Und das mache ich schon viel früher als erst nach dem mehrstündigen Durchlauf, oder? Ja.

Nach einer Stunde oder nach zwei Stunden sage ich einfach: „Okay, Pause. Oh, okay. Und dann öffne ich

Pause. Oh, okay. Und dann öffne ich den Worktree in Z oder etwas anderem, sehe es mir an und sage: „Okay, das wird so nichts. „Und ich mache einfach einen Revert. Äh, ich

schließe den Agenten. Ich starte einen neuen Kontext. Und ich frage äh ich

neuen Kontext. Und ich frage äh ich sage ihm: „Okay, äh vorher ist dies und das schiefgelaufen. Äh wie können wir sicherstellen, dass das nicht wieder passiert? Mhm. Und so führen

wieder passiert? Mhm. Und so führen wir ein weiteres Gespräch. Deshalb ist

es ein offener Agent und nicht einer, der sich sofort auf den Code konzentriert. Wir führen ein Gespräch

konzentriert. Wir führen ein Gespräch . Ich versuche herauszufinden, was ich

. Ich versuche herauszufinden, was ich falsch gemacht habe, entweder im Code oder im Prompt. Und dann mache ich es einfach nochmal.

den Code. Wir führen ein Gespräch.

Ich versuche herauszufinden, was ich falsch gemacht habe, entweder im Grundgerüst oder in dem Gespräch mit diesem mehrschichtigen Informationsaufbau in dem Graphen, wo die Probleme liegen. Meistens liegt es

daran, dass äh sich einige Ideen widersprechen. Und dann muss ich das

widersprechen. Und dann muss ich das erst lösen und versuche es erneut, und meistens beim zweiten oder nur sehr selten beim dritten Mal klappt es dann.

Die Lösung liegt also wieder in der Interaktion.

Ja.

Man übernimmt nicht einfach das Verhalten, sondern baut etwas Deterministisches ein, oder ist das auch Teil des Prozesses?

Ja, ich versuche immer, von nicht-deterministisch zu deterministisch zu gelangen. Ich halte

LLMs für etwas Nicht-Deterministisches , das jedes Mal andere Antworten liefert, und ich versuche, es so weit wie möglich zu einem deterministischen Output zu drängen, bei dem ich immer die gleiche Antwort erhalte. Egal, ob

es darum geht, ein Skript zu erstellen, das genau das tut, was ich will, oder ob ich das Gerüst etwas stärker und sorgfältiger aufbauen muss. Ich

versuche, das in deterministisches Verhalten einzubetten.

Ein letzter Gedanke, den ich hatte, betrifft die Art und Weise, wie wir Code betrachten und überprüfen, speziell bei Pull Requests. Ich habe

gesehen, wie Leute innovativ sind und verschiedene Arten von Visualisierungen auf Basis von Codeänderungen erstellen .

Mhm.

Wenn wir also wieder dieses große Funktionsset haben, die Interaktion mit dem Haupt-Agenten läuft, man zufrieden ist, die Erwartungen erfüllt sind, die Unter-Agenten arbeiten und das Ende einer 12-Stunden-Schleife erreicht ist.

Wie schauen sich die Leute dann den Code an? Ich habe Beispiele gesehen,

Code an? Ich habe Beispiele gesehen, bei denen Leute „Code-Städte“ erschaffen, eine Art Gerüst oder Skyline, die zeigt, wo spezifischer Code in der Codebasis hinzugefügt wurde. Verschiedene Arten von

wurde. Verschiedene Arten von Visualisierungen für Schnittstellen und wo Komplexität entsteht. Und

obwohl man viele deterministische Skripte hat, die versuchen, den Code innerhalb einer bestimmten Architektur und innerhalb gewisser Konventionen zu halten. Ich habe das Gefühl, wir

halten. Ich habe das Gefühl, wir brauchen Innovation in der Art, wie wir Code betrachten, nachdem er ausgegeben wurde, denn Code ist billig, wie du erwähnt hast.

Ja.

Wie prüfen wir das, oder hast du dir dazu schon Gedanken gemacht?

Ja, ich habe mir dazu viele Gedanken gemacht. Das ist genau das Problem, das

gemacht. Das ist genau das Problem, das gerade passiert. Eines der Dinge, die

gerade passiert. Eines der Dinge, die ich immer häufiger sehe, ist, dass es keine Kommentare mehr in Pull Requests gibt.

Das ist für mich gut.

Ich möchte, dass Leute hitzige Diskussionen darüber führen, warum jemand kein Semikolon am Ende des Satzes gesetzt hat.

Ja.

Ich möchte, dass Teams ihre Grenzen finden, zusammenarbeiten und zueinander finden, denn genau das, was wir am Anfang des Podcasts sagten, ist: Warum reden die Leute nicht mehr miteinander?

Aber ich glaube, die Art und Weise, wie wir Code schreiben, wie wir unsere Agenten verwalten und wie wir zusammenarbeiten–dieser Teil der Zusammenarbeit geht verloren, und wir benutzen die große Menge an Code als Grund dafür. Und wenn eine große

Grund dafür. Und wenn eine große Menge an Code der Grund dafür ist, warum schreiben wir dann nicht weniger Code?

Mhm.

Also, man bittet den Agenten einfach, weniger Code zu schreiben, dann wird die Überprüfung viel einfacher. Man

hat also mehr Überprüfungsschritte.

Man versucht, den Agenten dazu zu zwingen, die Funktionen klein zu halten . Man macht all die Dinge, die man auch

. Man macht all die Dinge, die man auch in einem normalen iterativen Zyklus mit Menschen tun würde. Ich finde es beängstigend, wenn wir Agenten einfach eine sehr, sehr große Änderung vornehmen lassen, die wir danach nicht mehr validieren können.

Mhm.

Weil man die Fähigkeit verliert, aus dem zu lernen, was getan wurde.

Ich habe verschiedene Visualisierungen oder sogar Schnittstellen gesehen, die nicht Git sind, aber wenn man eine Interaktion mit seinem Tool hat, so wie du, dann wäre diese Interaktion auch im Pull Request vorhanden. So kann ich die gesamte Interaktion sehen. Und das

gefällt mir, weil die Art und Weise, wie du dein Verhalten erklärst, darin besteht, dass du viel Vorarbeit leistest.

Ja.

Wenn du also viel Aufwand in das Vordenken steckst, kannst du das verstärken, und da Code billig ist, möchte ich als Reviewer nicht den billigen Code sehen. Ich möchte mir den Vorab-Aufwand ansehen, den du betrieben hast. Ich habe das Gefühl,

betrieben hast. Ich habe das Gefühl, da steckt etwas drin, das ich mir ansehen und verstehen möchte. Und wenn

wir diesen Vorab-Aufwand dann deterministisch in die Ausgabe und das Ergebnis, den Code, überführen können, dann fühle ich mich zuversichtlich genug, nicht zwangsläufig in den Code schauen zu müssen oder ihn auf eine andere Weise zu betrachten.

Ja.

Zum Beispiel schauen, wo Komplexität hinzugefügt wurde, anstatt jedes Detail jeder Zeile spezifisch zu betrachten.

Ja.

Aber ich möchte das Vertrauensniveau erreichen, dass ich gar nicht mehr in den Code schauen muss. Und ich glaube, dass das möglich ist.

Ja. Das bringt also auch einen guten Punkt beim Testen auf. Und eines der Dinge, die Leute oft vergessen, ist, dass ein Unit-Test sehr leicht vortäuschbar ist.

Mhm.

Es gibt also eine weitere Ebene über dem Unit-Testen, die nennt sich Mutation-Testing. Mutation-Testing

Mutation-Testing. Mutation-Testing hingegen ist sehr rechenintensiv für den Computer. Ich habe ein paar P-Kerne

den Computer. Ich habe ein paar P-Kerne meiner CPU beschädigt, als ich Mutation-Testing für den Code durchführte, den ich schrieb. Und ich

denke, dass die Art und Weise, wie wir über das Testen denken, ein wenig tiefer gehen muss. Wir brauchen

statische Code-Analysetools, die bei dem von dir erstellten Grundgerüst ansetzen und prüfen, wie viel Prozent davon noch bestehen. Wir brauchen

Möglichkeiten, jeden Commit aufzuschlüsseln und zu sehen, wie er die Lösung vorangebracht hat. Und ich

glaube, das könnte eine sehr gute Art sein, das zu visualisieren. Denn es

geht nicht darum, wo man anfängt und wo man steht, sondern wie man dorthin gekommen ist.

Mhm.

Ich habe viele Fehler des Agents gesehen, bei denen er mir ein paar Iterationen später einfach sagte: „ Ja, aber ich habe es damals so gemacht, also weiß ich nicht, was du verlangst.

“ Und genau diese Teile müssen wir aus dem Prozess entfernen, denn für mich ist es genau derselbe Prozess, als würde ich in ein Team nur mit Junioren geworfen werden.

Mhm.

Wenn ich zu Junioren sage: „Okay, viel Spaß.“ Dann würde ich Code

viel Spaß.“ Dann würde ich Code bekommen.

Mhm.

Ich würde manchmal sogar großartigen Code bekommen, aber ich bekäme keine Anwendung.

Nein.

Was macht man also als Senior? Womit

fängst du an? Du fängst an, mit deinem PO zu kommunizieren, um die Produktspezifikationen absolut klar zu definieren. Und genau das mache ich in

definieren. Und genau das mache ich in der Konversation mit dieser KI. Und

dieses Diagramm, dieses Netzwerk macht das Produkt und die Produktvision mehr oder weniger sehr, sehr klar.

Mhm.

Ich erstelle ein Grundgerüst. Und

genau das würde ein Senior Engineer in einem Team tun. Ich entscheide über die Architektur. Das ist es, was ein

die Architektur. Das ist es, was ein Senior Engineer oder ein Architekt tun würde. Ich entwerfe, wie wir die

würde. Ich entwerfe, wie wir die Anwendung bereitstellen werden. Vorher

würde ich also sagen, dass wir das auf AWS bereitstellen oder dass es eine lokale Anwendung sein muss, oder man setzt einige Grenzen, wie man das angehen will. Man denkt vielleicht

angehen will. Man denkt vielleicht sogar ein bisschen darüber nach, welche Anwendungen man nutzen möchte, wenn es auf AWS bereitgestellt wird.

Möchtest du S3 nutzen, um deine Daten zu speichern? Möchtest du eine

zu speichern? Möchtest du eine Postgres-Datenbank verwenden? Möchtest

Postgres-Datenbank verwenden? Möchtest du SQLite verwenden? Wenn du SQLite verwenden willst, brauchst du physischen Speicherplatz, um die SQLite-Datenbank darauf abzulegen, oder ? Du musst also darüber nachdenken,

? Du musst also darüber nachdenken, wie du die Anwendung bereitstellen willst, wie sie laufen soll und wie die Leute damit interagieren sollen. Und

all das ist meiner Meinung nach etwas, das du nicht den Agent alleine entscheiden lassen solltest. Sich

dieser Entscheidungen im Voraus sehr bewusst zu sein, ist also die erste Phase des Grundgerüsts.

Mhm. Ich habe das Gefühl, ich muss noch so viel lernen. Einerseits ist das sehr spannend, andererseits aber auch sehr einschüchternd. Je mehr du sagst:

sehr einschüchternd. Je mehr du sagst: „Das ist die ganze Arbeit, die du vorab erledigen musst. Da denke ich mir : „Mensch, das sind Dinge, die in Projekten entweder für mich entschieden wurden oder über die ich nie wirklich nachgedacht habe. Ich habe

meine eigene Meinung, bin aber auch sehr neugierig. Und ich kann es kaum

sehr neugierig. Und ich kann es kaum erwarten, es auszuprobieren. Ich habe

das Gefühl, ich möchte jetzt mehr Dinge ausprobieren als vielleicht jemals zuvor. Neue Dinge. Weil ich auch

jemals zuvor. Neue Dinge. Weil ich auch das Gefühl habe, dass ich die Möglichkeit dazu bekommen habe.

Einfach ausprobieren, schauen, was hängen bleibt und was für meine eigene Arbeitsweise funktioniert. Und

auch daraus zu lernen.

Ja. Aber lass es uns tun.

Mhm.

Lass uns eine Community-Session oder etwas Ähnliches machen. Ein

Tagungszentrum mieten. Leute mit vielen Laptops zusammenbringen und wir fangen an, einige dieser Ideen auszuprobieren.

Und die Idee ist sowohl effizienter mit Agenten zu arbeiten, oder dass vielleicht jemand die Scaffolding-Technik nutzt, jemand anderes nicht, und dann sieht man, was dabei herauskommt, richtig?

Mhm.

Aber Leute zusammenzubringen und sie dazu zu bringen, darüber zu sprechen, ist meiner Meinung nach der erste Schritt. Wir isolieren uns alle immer

Schritt. Wir isolieren uns alle immer mehr in diesen Bubbles.

Mhm.

Und ich glaube, die einzige Möglichkeit, dem entgegenzuwirken, ist , zusammenzukommen, es gemeinsam zu tun , gemeinsam Fehler zu machen, zu lachen und zu lernen.

Absolut. Carlos, vielen Dank, dass du hier warst und das geteilt hast.

Ja, danke, dass ich wieder hier sein durfte.

Das war großartig. Das nächste Mal machen wir es nicht erst in drei Jahren , sondern in etwa einem Jahr.

Ja.

Ja, und vielleicht sind wir beim nächsten Mal in einer Post-Agenten-Situation, in der wir alle 10 Minuten auf unser Handy schauen müssen. Oh, da ist schon wieder eine

müssen. Oh, da ist schon wieder eine neue App.

Ja, genau. Ich denke, es wird eine gute Zukunft.

Vielen Dank.

Vielen Dank auch dir.