AI Skills with Matt Pocock

Es nervt, wie verdammt es ist, Bro.

Jeder hat eine Geschichte, in der er mich fertigmacht. Es hat einfach dieses

mich fertigmacht. Es hat einfach dieses seltsame emergente Verhalten, bei dem die Modelle anfangen, ein wenig über den Tellerrand hinauszuschauen und dir Ideen zuwerfen.

Ich denke, die Idee des Tracer-Bullets ist wie ein Tracer-Bullet, das eine Spur hinterlässt.

Ich habe einfach angefangen, diese Sätze in meinen Eingabeaufforderungen zu verwenden, als ich mit dem Agenten gesprochen habe, und mir ist aufgefallen, dass er mir diese Sätze zurückgesagt hat. Er sagte: „Okay,

zurückgesagt hat. Er sagte: „Okay, ich verwandle das in ein Tracer-Bullet.

“ Das nenne ich ein führendes Wort, bei dem du den Agenten nur mit einem einfachen Satz führst, den du wiederholst. Wie gehe ich vor und finde

wiederholst. Wie gehe ich vor und finde die wichtigen Grundlagen, zu denen ich zurückkehren kann?

Es ist wirklich schwierig, weil strategische Programmierung schon immer sehr schwer zu lernen war. Ich stelle

mir das Lernen strategischer Programmierung so vor, als hättest du ein riesiges Mischpult vor dir, mit vielen verschiedenen Reglern. Drehst du

ihn auf, hast du mehr Microservices.

Drehst du ihn runter, hast du einen Monolithen. Es ist ein bisschen so, als

Monolithen. Es ist ein bisschen so, als würdest du Musik mischen, aber erst nach neun Monaten hörst du, was falsch ist, bis die Fehler kommen und dich einholen.

Wie überzeugst du Stakeholder, die keine Techniker sind, davon, dass Investitionen in Software-Grundlagen wichtig sind? Du brauchst eine Art

wichtig sind? Du brauchst eine Art Metrik, um das herauszufinden. Ich

denke, der erste Schritt dazu war, dass ich den Grill meines Lebens bekam, als ich mit dem Skill „Grill Me“ einen ziemlich einfachen API-Endpunkt erstellte. Er stellte mir 35 Fragen.

erstellte. Er stellte mir 35 Fragen.

Ich mache keine Witze. Es war intensiv und nervig und er zwang mich, mehr nachzudenken. Der heutige Gast ist

nachzudenken. Der heutige Gast ist einer der Erfinder dieses beliebten Skills, Matt PCO. Matt ist ein Entwickler, der zum Ausbilder wurde und vor allem für seine TypeScript-Reihe und jetzt für seine KI-Skills und Lehrvideos bekannt ist. Heute berichten

wir über Matts ungewöhnlichen Weg in die Technologiebranche, nachdem er jahrelang als Sprachtrainer tätig war und seine eigene DIY-Coaching-Software entwickelt hat. Matts beliebter Skill

entwickelt hat. Matts beliebter Skill „Grill Me Wayfinder“ und warum diese Skills so weit verbreitet waren.

Er ließ sich von jahrzehntealten Programmierbüchern inspirieren, um mit KI und vielem mehr bessere Software zu entwickeln. Wenn Sie verstehen möchten

entwickeln. Wenn Sie verstehen möchten , welche grundlegenden Ansätze des Software-Engineerings bei der Arbeit mit KI-Agenten nach wie vor sehr nützlich sind, ist diese Folge genau das Richtige für Sie. Diese Folge wird präsentiert von Turbopuffer, Vector und Ftech Search, die auf Objektspeicher basieren. Das ist

Objektspeicher basieren. Das ist schnell, günstig und extrem skalierbar . Diese Folge wird präsentiert von

. Diese Folge wird präsentiert von Linear, und ich wollte Sie mit auf eine Zeitreise nehmen, um Sie daran zu erinnern, wie wir früher unsere Arbeit erledigt haben. Damals, als jede

erledigt haben. Damals, als jede Codezeile von einem Ingenieur wie Ihnen oder mir geschrieben wurde, bestand die Aufgabe eines Trackers darin, die Zusammenarbeit der Mitarbeiter auf dem Laufenden zu halten, ohne sie dabei auszubremsen. Linear wurde für

auszubremsen. Linear wurde für Schnelligkeit und geringe Reibung entwickelt, und das merkte man. In der

letztjährigen Umfrage von Pragmatic Engineer war Linear das beliebteste Tracker-Tool und Jura aufgrund seiner trägen Performance das am wenigsten beliebte. Die Daten der Zielgruppe von

beliebte. Die Daten der Zielgruppe von Pragmatic Engineer zeigten, wie Linear gegenüber bestehenden Tools an Boden gewann, insbesondere bei Start-ups und mittelständischen Unternehmen. Und

mittelständischen Unternehmen. Und seitdem ist Linear gewachsen. Linear

hat alles hinzugefügt, was größere Unternehmen benötigen, um Arbeit, Projekte, Initiativen, Roadmaps und Kundenanfragen zu verwalten. Und große

Unternehmen begannen, umzusteigen. Das

Gesundheitsunternehmen Oscar beispielsweise half dabei, 600 Ingenieure von Jira auf Lineer umzustellen. OpenAI begann mit 100

umzustellen. OpenAI begann mit 100 Arbeitsplätzen und migrierte alle 3.000 Mitarbeiter ohne jegliche Vorgaben. Coinbase, Cash App, Brex und

Vorgaben. Coinbase, Cash App, Brex und RAMP nutzen alle Linear. Viele von

ihnen sahen Linear als eine Möglichkeit, ein einziges Tool zu konsolidieren, das Planung und Entwicklung zusammenführt. Kommen wir

Entwicklung zusammenführt. Kommen wir nun zum heutigen Tag. Wenn man

KI-Agenten in einem Unternehmen hat, benötigen diese Agenten Kontext, um gut zu funktionieren. Sie benötigen

Zugriff auf Dinge wie Spezifikationen, Kundenanfragen und Historie. Oh, Moment

. Das alles gibt es bereits in Linear.

Als also Agenten auf den Markt kamen, wurde Linear zur idealen Kontextebene.

Heute haben 80%der linearen Unternehmensarbeitsplätze Agenten eingeführt. Sie können Agenten wie

eingeführt. Sie können Agenten wie Codeex, Cloud Code, Linear Agent oder Ihren eigenen Agenten verwenden.

Coinbase und RAM haben beide ihre eigenen internen Agenten entwickelt und beschreiben Linear als einen Ort, an den ihr Agent geht und den Kontext aufnimmt, bevor er mit der Arbeit beginnt. Sehen Sie sich unter

beginnt. Sehen Sie sich unter linear.app/pragmatic an, wie es

linear.app/pragmatic an, wie es funktioniert. app/pragmatic.

funktioniert. app/pragmatic.

Matt, es ist toll, dich im Podcast zu haben.

Schön, endlich hier zu sein. Ich bin

ein riesiger Fan. Ich habe mir so viele davon angesehen. Ich habe das Gefühl,

davon angesehen. Ich habe das Gefühl, das ist wie der winzige Schreibtisch eines Softwareentwicklers. Verstehst du

eines Softwareentwicklers. Verstehst du , was ich meine? Das ist eine große Sache. Ich bin also froh, hier zu sein.

Sache. Ich bin also froh, hier zu sein.

Und es ist auch toll, wieder Kontakt zu haben, denn vor etwa einem Jahr haben wir nach der Microsoft Build zu Mittag gegessen, was wirklich Spaß gemacht hat. Aber jetzt ist es an der Zeit,

hat. Aber jetzt ist es an der Zeit, hier anzufangen. Und in diesem

hier anzufangen. Und in diesem Zusammenhang wollte ich dich nach deinem Werdegang fragen. Im Gegensatz

zu vielen anderen in der Technologiebranche und in diesem Podcast hast du nicht angefangen, Informatik zu studieren, richtig? Auf

keinen Fall.

Bevor ich Entwicklerin wurde, war ich sechs Jahre lang Stimmtrainerin. Ich

war Gesangslehrerin und habe in London und bei X2 gearbeitet, wo ich auch zur Uni gegangen bin. Ich habe Akzente unterrichtet. Ich habe Gesang

unterrichtet. Ich habe Gesang unterrichtet. Ich habe Gesang

unterrichtet. Ich habe Gesang unterrichtet. Ich habe darin einen

unterrichtet. Ich habe darin einen Master gemacht. Ich habe lange Zeit

Master gemacht. Ich habe lange Zeit gedacht, dass das mein Beruf sein würde. Weißt du, ich hatte keine

würde. Weißt du, ich hatte keine Ahnung von Technik und habe mir darüber überhaupt keine Gedanken gemacht. Ich habe sozusagen meine

gemacht. Ich habe sozusagen meine eigene Website betrieben und so, aber ja, das habe ich lange Zeit gemacht und es hatte einen extrem wichtigen Einfluss auf mein Leben und ich denke auch auf meine Persönlichkeit. C

kannst du etwas tiefer darauf eingehen, woher die Stimme kommt und was du als Stimmtrainer machst? Wer sind die Leute

Stimmtrainer machst? Wer sind die Leute , die dich um Hilfe bitten und welche Art von Hilfe suchten?

Also, ich habe als Gesangslehrerin angefangen. Ich war in einer Band und

angefangen. Ich war in einer Band und so weiter an der Uni. Ich hatte ein bisschen Erfahrung im Singen und so habe ich meine eigene Firma an der Uni gegründet und mich in diesem Sinne engagiert. Es waren Leute dabei, die

engagiert. Es waren Leute dabei, die einfach besser singen wollten, die ihre Stimme für Chöre einsetzen wollten, die es einfach als Hobby machten. Es

war nichts wirklich Professionelles.

Dann habe ich einen Master darin gemacht und bin dann auf Schauspielschulen gegangen, um Leuten Shakespeare und so etwas beizubringen und Leute zu gewinnen, die öffentlich reden wollten. Ich habe ein paar große

reden wollten. Ich habe ein paar große Aufträge für Beratungsunternehmen gemacht, weißt du, wo ich ihnen beigebracht habe, wie man Reden hält und wie man besser spricht. Das war

verrückt, weißt du, und der Grund, warum ich damit aufgehört habe, war, dass ich gemerkt habe, dass man in London leben muss, um das auf einem anständigen Niveau zu machen. Ich

wollte nicht in London leben. Ich habe

es ungefähr zwei Jahre lang versucht.

Ich habe es einfach gehasst. Ich habe

es gehasst. Ich bin nicht in London aufgewachsen. Ich wollte zurück aufs

aufgewachsen. Ich wollte zurück aufs Land und dorthin, wo ich herkomme. Und

das habe ich getan. Und so habe ich gelernt, wie man Entwickler wird. Ich

habe mir das im Grunde genommen selbst beigebracht, um etwas zu haben, das ich aus der Ferne tun konnte. Im Grunde

genommen habe ich nach Berufen gesucht, die man außerhalb von London ausüben kann und die eine Karriere oder Perspektive oder Zukunft bieten.

Genau. Und ich habe mir selbst beigebracht, wie man Sachen baut, und zwar einfach grundlegende Sachen in JavaScript, weil ich daran interessiert war, meinen Unterricht für meine Schüler zu verbessern. Also habe ich tatsächlich eine Art kleine Karteikarten-Apps erstellt. Ich

Karteikarten-Apps erstellt. Ich arbeitete an meiner allerersten App, die ich je erstellte. Das war das Ambitionierteste, was ich je versucht habe. Es war wie ein

habe. Es war wie ein Web-Audio-Analysator. Damit konnte ich

Web-Audio-Analysator. Damit konnte ich das Spektrogramm deiner Stimme analysieren, um zu sehen, welche Resonanzfrequenzen auftraten und ob T1 und T2 richtig ausbalanciert waren und solche Dinge. Extrem tiefgreifend, lief

solche Dinge. Extrem tiefgreifend, lief schrecklich, aber tatsächlich machte es meinen Unterricht ein bisschen besser. Und so machte ich von Anfang an

besser. Und so machte ich von Anfang an ziemlich harte Sachen, die schrecklich waren. Und mir wurde klar, okay, ich

waren. Und mir wurde klar, okay, ich fing an, Stellenausschreibungen zu lesen und dachte, nun ja, ich könnte ein bisschen JavaScript, ein bisschen SAS, ein paar Kleinigkeiten machen. Und

ich stürzte mich einfach darauf. Ich

kündigte meinen Job, hatte ein paar Monate frei und bekam schließlich einen Job. Das war ungefähr 2017, als

einen Job. Das war ungefähr 2017, als es in Großbritannien noch ein bisschen einfacher war, einen Job zu bekommen als heute. Und von da an machte ich

als heute. Und von da an machte ich einfach weiter.

Ich schätze, in gewisser Weise hatten Sie auch Glück, denn das war der Höhepunkt. Das war eine Zeit, in der

Höhepunkt. Das war eine Zeit, in der die Nachfrage nach Ingenieuren so hoch war, dass die Leute mit ein paar Monaten Erfahrung Bootcamps machten, und ich denke, dass Leute mit dem Antrieb, der Motivation und dem Grips von vielen Stellen eine Chance bekamen, richtig?

Ja. Und weil ich diese Erfahrung im Umgang mit Menschen hatte, war das ein unglaublicher Vorteil, richtig? Ich

konnte tatsächlich in ein Vorstellungsgespräch gehen und wie eine vernünftige Person klingen, anstatt wie jemand, der direkt einen Abschluss in Informatik hat und vielleicht nicht über diese Fähigkeiten verfügt. Ich hatte also

Fähigkeiten verfügt. Ich hatte also diese bizarre Fähigkeit, anfangs gar kein oder nur sehr wenig technisches Wissen zu haben, aber die Fähigkeit, anderen technisches Wissen zu erklären. Im

Grunde genommen musste ich nur mein technisches Wissen ein wenig erweitern, und ich war sehr leidenschaftlich dabei , und das verbesserte sich ziemlich schnell. Und dann schien es irgendwie

schnell. Und dann schien es irgendwie eine unfaire Kombination zu sein, denn ich bin in verschiedenen Unternehmen sehr schnell aufgestiegen, und ich fühlte mich anders als die anderen Softwareentwickler, mit denen ich zusammengearbeitet habe. Ergibt das

zusammengearbeitet habe. Ergibt das Sinn? Und wie bist du dann die

Sinn? Und wie bist du dann die Karriereleiter hochgestiegen? Du hast

Karriereleiter hochgestiegen? Du hast beschlossen, dass du das machst. Du

hast es dir selbst beigebracht. Du bist

zu ein paar Vorstellungsgesprächen gegangen. Ich nehme an, es muss eine

gegangen. Ich nehme an, es muss eine kleine Firma gewesen sein, richtig?

Ja. Eine winzige Firma mit ein paar wirklich inspirierenden Softwareentwicklern, die dort arbeiten.

Im Grunde ein Typ, dessen Namen ich nicht nennen werde, weil er seine Anonymität schätzt, aber im Grunde ein Typ, der lange Zeit in Sandalen gelebt hat, der auf einem Kanalboot gelebt hat, also ein richtiger Hardcore-Typ mit langen Haaren. Es war

ungefähr zu der Zeit, als Microsoft GitHub gekauft hat. Ich erinnere mich, wie er fast in Tränen ausgebrochen ist .

Ja. Microsoft-Hasser.

Ja, absolut. Weißt du, ein Klassiker.

Ich erinnere mich, dass er mich als Erstes dazu gebracht hat, CentOS 6 auf meinem Windows-PC einzurichten.

Das ist eine ziemlich harte Linux-Distribution. Eine

Linux-Distribution. Eine richtig harte Linux-Distribution, denn darauf lief unsere Anwendung in der Cloud oder so, weißt du. Also, ein

wirklich lieber, wundervoller Typ und jemand, der mir direkt viel beigebracht hat. Und so geriet diese Firma in

hat. Und so geriet diese Firma in finanzielle Schwierigkeiten, weshalb ich ziemlich schnell zu einer Agentur wechseln musste und dort einen höheren Job bekam. Neun Monate später

Job bekam. Neun Monate später wechselte ich dann zu einer anderen Agentur und dann noch einer. Ich

hüpfte also einfach zwischen verschiedenen Agenturen hin und her und arbeitete dann im Bereich Open Source, was sozusagen der nächste Teil der Geschichte ist.

Und welchen Tech-Stack hast du damals bei den Agenturen verwendet?

Ja, es war Typescript, es war React.

Oh, gab es Typescript damals schon? Nun

, ich war schon ziemlich Hardcore-Fan bei Typescript, fast so wie in meinem zweiten Job. Ich glaube, ich habe

zweiten Job. Ich glaube, ich habe Präsentationen darüber gehalten, wie wichtig TypeScript ist. Wir arbeiteten

für einen Automobilhersteller und entwickelten ein Lernmanagementsystem, richtig? Du weißt schon, der

richtig? Du weißt schon, der klassische langweilige Agenturkram, richtig? Und das Frontend-Team war

richtig? Und das Frontend-Team war damals ziemlich klein und wir hatten ein Backend-Team in Portugal, richtig?

Also die klassische Frontend-Backend-Aufteilung. Das

Frontend-Backend-Aufteilung. Das Backend-Team war sehr leistungsorientiert, und als ich dazukam, war das Frontend-Team wirklich langsam. Wir hatten eine Menge Fehler.

langsam. Wir hatten eine Menge Fehler.

Das Backend-Team änderte ständig seine Verträge, ohne uns Bescheid zu geben, und wir dachten, wir bräuchten etwas, um uns besser zu vernetzen.

TypeScript schien uns die naheliegende Lösung zu sein, und als wir es dann auf den Markt brachten, wurde es immer schneller. Wir waren schneller als das

schneller. Wir waren schneller als das Backend-Team, und irgendwann haben sie uns Leute weggenommen, weil wir so schnell waren. Das war also meine

schnell waren. Das war also meine Geschichte mit TypeScript. Das ist

sozusagen meine Entstehungsgeschichte.

Wie bist du zu Open Source gekommen?

War es bei der Arbeit? War es nebenbei?

Ich habe nebenbei ständig mit Open Source herumgespielt und mich für verschiedene Dinge interessiert. Zu der

Zeit war ich auch bei Twitter. Ich habe

mir online Leute angeschaut und dachte, das ist jemand, den ich nachahmen möchte, jemand, den ich mir ansehen möchte. Und dann ist mir ein Typ

möchte. Und dann ist mir ein Typ aufgefallen, David Koshid, der State Machine-und TypeScript-Typ auf Twitter.

Ein sehr netter Typ, dem ich einen großen Teil meiner Karriere zu verdanken habe. Und ich habe an einem

verdanken habe. Und ich habe an einem Projekt gearbeitet. Ich glaube, das war

Projekt gearbeitet. Ich glaube, das war mein vierter Job, für das wir eine State Machine brauchten. Es war eine sehr komplexe Anwendung, bei der man mit jemandem per Videoanruf in Echtzeit durch ein Haus navigierte. Dabei kam

eine Art Mapport-Integration zum Einsatz. Viele Verknüpfungen mussten

Einsatz. Viele Verknüpfungen mussten über Netzwerkgrenzen hinweg erfolgen, viele komplizierte Zustände. Daher

verwendete ich damals eine Bibliothek namens XATE, XATE Version 4. Ich denke,

das war ein voller Erfolg. Daher fragte

ich mich: „Okay, wie kann ich das typsicherer machen?“ Also begann ich,

typsicherer machen?“ Also begann ich, ein paar Tools dafür zu entwickeln.

Ich hatte eine Art Fiddle und eine Art Befehlszeilenschnittstelle, die darauf aufbaute. Dadurch wurde David auf mich

aufbaute. Dadurch wurde David auf mich aufmerksam und ich wurde Mitglied des Xate-Kernteams. Ich begann, mich zu Problemen zu äußern, Diskussionen über die Zukunft der Bibliothek zu führen. Dadurch kam ich mit

führen. Dadurch kam ich mit Entwicklern in Kontakt, die ich noch nie zuvor gesehen hatte: David und ein weiterer Typ namens Mattesh Bazinski, auf Twitter Anderish Rake genannt. Das

sind die talentiertesten Entwickler, die ich je gesehen habe. Das ist eine ganz andere Liga. Und schließlich

wollte David daraus eine Firma gründen . Er wollte stark auf State-Charts und

. Er wollte stark auf State-Charts und visuelle Programmierung als zukünftige Entwicklung setzen. Sie bekamen etwas

Entwicklung setzen. Sie bekamen etwas Geld und das war mein erster Job, bei dem ich im Grunde genommen mit amerikanischem Geld bezahlt wurde, und das war ein großer Schritt nach oben für mich.

Ja. Was, wie wir wissen, etwas ganz anderes ist, wenn ein europäisches oder lokales Unternehmen oder sogar ein britisches Unternehmen bezahlt. Denn ja

, ich habe auch einen Teil davon in der Triode-Natur der Vergütung von Softwareentwicklern behandelt, denn ja, US-amerikanische Unternehmen, insbesondere in Europa und auch in den USA, denken anders über Vergütung und generierten Wert, richtig?

Es hat mein Leben total verändert, weißt du, in Bezug auf die Art und Weise, wie ich über Geld und Flexibilität dachte, und es bedeutete, dass ich an etwas arbeitete, das mir am Herzen lag. Und ich begann, während

Herzen lag. Und ich begann, während ich dort war, mich ein wenig mehr dafür einzusetzen, denn natürlich ist das Unternehmen sehr klein. Ähm, ich

habe viel entwickelt, aber ich wollte mich auch dafür einsetzen, weil ich daran geglaubt habe, weißt du? Und ich

denke immer noch, dass Zustandsdiagramme für bestimmte Arten von Arbeit unglaublich primitiv sind.

Ich bin von meiner Überzeugung darüber ein wenig abgerückt, besonders im Zeitalter der KI, aber ich habe mich etwas mehr damit beschäftigt , und das hat mich bei ein paar Leuten bei Versel auf mich aufmerksam gemacht, denn zu dieser Zeit war Lee Robinson bei Versel der Typ, der dort für die

Entwicklerausbildung zuständig war.

Sie haben dieses unglaubliche Team, Delba Delba de Oliviera, ähm Lydia Halley, die beide jetzt bei Claw Code sind. Ja.

sind. Ja.

Ähm, Lee selbst und ich haben dort gearbeitet, ich habe dort einen Job unter Jared Palmer bekommen, sozusagen als ähm Ja.

Wow. Dieser Jared Palmer.

Dieser Jared Palmer. Ja. Ähm, der ist tatsächlich ein echt guter Kumpel, und er ist derjenige, der später zu ähm GitHub gewechselt hat. Er hat

Stack-Diffs oder Stack-PRs ins Leben gerufen oder geleitet, und jetzt ist er bei Cognition.

Ja. Er ging zu GitHub, veröffentlichte Stack-Diffs, verließ das Unternehmen, weigerte sich, näher darauf einzugehen , und arbeitet jetzt bei Cognition.

Genau.

Ja. Aber er ist auch eine Legende in der Branche. Ja.

der Branche. Ja.

Ja. Er ist ein toller Typ, und ich habe nicht lange unter ihm bei Versel gearbeitet. Ich war dort also nur etwa

gearbeitet. Ich war dort also nur etwa drei Monate. Von da an bekam ich einen

drei Monate. Von da an bekam ich einen witzigen Vertrag bei Versel, weil ich bereits diese Idee für TypeScript ins Spiel gebracht und über TypeScript nachgedacht hatte und darüber, vielleicht Lehrmaterial für TypeScript zu erstellen.

Als ich bei Stately, der Xate Company, war, verspürte ich dieses Bedürfnis, etwas zu unterrichten. Ich habe ja schon sechs Jahre lang unterrichtet. Zu

diesem Zeitpunkt hatte ich vier oder fünf Jahre lang nicht mehr unterrichtet, vielleicht sechs Jahre.

Und ich dachte, ich muss da wieder anfangen. Ich vermisse es, und ich

anfangen. Ich vermisse es, und ich liebe es, Dinge zu erschaffen. Ich

liebe es, Inhalte zu erstellen. Ich

liebe es, Menschen etwas beizubringen.

Und genau das habe ich dann angefangen.

Und ich habe angefangen, es für fortgeschrittene Programmierer zu tun.

Ich bin mit vielen verrückten Tipptricks in Berührung gekommen, mit einer Menge wirklich fortgeschrittenem TypeScript-Zeug, als ich versucht habe, XATE typsicher zu machen. Ein sehr,

sehr harter Job. Ich denke, ein fast unmöglicher Job. Also habe ich ein

unmöglicher Job. Also habe ich ein paar Tipps erstellt. Ich habe diese Zwei-Minuten-Tipps erstellt, sie auf Twitter gepostet, und sie kamen einfach so an, wie ich es noch nie zuvor gespürt hatte. Und mir wurde klar,

gespürt hatte. Und mir wurde klar, dass es hier einen Markt gibt. Und so

habe ich an einem Sonntag einfach 13 bis 15 dieser Zwei-Minuten-Tipps erstellt. Ich habe sie einfach über

erstellt. Ich habe sie einfach über die nächsten paar Wochen in die Warteschlange gestellt, und meine Follower-Zahl stieg von 4.000 auf 10.000 oder so. Man spürte einfach plötzlich, dass es riesiges Interesse daran gab, richtig?

Genau. Eine riesige Welle von etwas war , wissen Sie, eine Kombination aus meiner Art zu sprechen und dem Material , das ich lieferte, das auf eine Art und Weise klickte, wie ich es noch nie zuvor gespürt hatte. Und das ist in meiner Karriere wirklich nur zweimal passiert. Ich hatte also schon die Idee

passiert. Ich hatte also schon die Idee für einen Kurs im Kopf und wusste, dass ich das gut umsetzen konnte. Ich

wusste, dass ich einen richtig tollen Kurs machen konnte, wenn ich nur das richtige Publikum hätte und wenn es klickt. Also ging ich zu Versel. Ich

klickt. Also ging ich zu Versel. Ich

bekam dort zunächst einen Vertrag für nur 3 Tage die Woche für 3 Monate, was sehr ungewöhnlich ist. Wolltest du das oder war das so, dass Versel wahrscheinlich nur den Boden unter den Füßen testen wollte, um zu sehen, wie es sich entwickelt?

Ich wollte bei Versel sofort Vollzeit arbeiten.

Du wusstest, dass es noch diese andere Sache gibt. Also, lass mich ein

Sache gibt. Also, lass mich ein bisschen auf Nummer sicher gehen, wenn ich es richtig machen kann.

Versel war diese seltsame Absicherung für das, was ich wollte. Das ist

verrückt. Das

ist verrückt für mich.

Für die meisten Leute wäre das der Traumjob, oder?

Ich weiß. Es

ist mir ein bisschen peinlich, das zu sagen, weil es natürlich der Traumjob so vieler Leute ist, aber ich bin da mit dem Gedanken hingegangen: „Okay, ich brauche einen festen 9-to-5-Job für 3 Tage die Woche, während ich diese andere Sache ausprobiere.“ Aber

ich meine, nur um fair zu sein, ich denke, das ist vernünftig, oder? Wenn

wir zu diesem Zeitpunkt einfach mal zu dem Punkt zurückkehren, an dem du bist , du bist jetzt schon einen Großteil deiner Karriere als Stimmtrainer tätig , sagen wir mal sechs Jahre, und sagen wir mal, seit fünf Jahren entwickelst du Software. Du machst das gerne. Du

du Software. Du machst das gerne. Du

denkst, du bist gut darin. Du denkst,

du könntest vielleicht unterrichten, aber wer weiß, oder? Und an diesem Punkt denkst du dir: „Okay, lass mich das Risiko eingehen und mache diese Sache, die vielleicht klappt oder vielleicht auch nicht.“ Wenn du es aber schaffst, etwas Stabiles zu haben und es an Fahrt gewinnt, ist das etwas

anderes, oder? Viele Ingenieure haben

anderes, oder? Viele Ingenieure haben Ambitionen, Ideen, vor allem, weil man als Softwareentwickler aus der Ferne arbeiten kann, man kann seine Idee umsetzen und ein Unternehmen gründen, und sie denken sich: „Okay, soll ich einfach reinspringen? Soll ich meinen

einfach reinspringen? Soll ich meinen Job kündigen? Soll ich meinen Job

Job kündigen? Soll ich meinen Job nicht kündigen?“ Also, in gewisser

nicht kündigen?“ Also, in gewisser Weise ist es wohl dieses Modell, das einzigartig ist, und wenn man es schafft, es durchzuziehen. Ich meine,

es war das Bizarrste, weil sehr schnell klar wurde, dass ich im Grunde nicht bei Versell bleiben konnte. Wir waren

etwa zwei Monate nach meinem Arbeitsantritt bei Versell. Ich war

tatsächlich in einer sehr turbulenten Zeit dort, weil ich dabei war, als sie Turopac veröffentlichten. Ich habe

Turopac veröffentlichten. Ich habe tatsächlich einen Teil der Dokumentation geschrieben, die erste Dokumentation für Turboac, und habe einige aus dem Team kennengelernt, das ein viel schnelleres Build-System hatte. Richtig. Ja, es war im

hatte. Richtig. Ja, es war im Wesentlichen ein Build-System. Damals

versuchten sie, mit Webpack zu konkurrieren, woran sie arbeiteten, und ich war von Anfang an dabei, als sie die Dokumentation erstellten. Ich bin

nach San Francisco geflogen. Ich war

bei NextGComp dabei, als sie es ankündigten, wissen Sie, groß, wissen Sie, wissen Sie, eine wirklich lustige Erfahrung, und ich war mit allen dabei, als sie alles dafür vorbereiteten. Und

deswegen mache ich das, und schon denke ich mir im Hinterkopf, dass ich den Newsletter gelesen habe, und meine gesamte Zeit, die ich mit Skripten verbracht habe, steigt an. Ich verstehe

. Okay, hier gibt es etwas wirklich Großes. Und als ich einen

Großes. Und als ich einen Pre-Release-Verkauf machte, ging das einfach durch die Decke. Ich verdiente,

sagen wir mal, X bei Versel, und das war so etwas wie das 30-bis 40-fache oder so, weißt du, es ging sofort, und X bei Versel war bereits eine wirklich sehr gute Komposition.

Absolut. Ich bin sehr, sehr, sehr zufrieden damit. Aber ja, es war

zufrieden damit. Aber ja, es war einfach klar, dass ich keine andere Entscheidung treffen konnte. Ich habe

es geliebt, bei Vel zu arbeiten. Äh,

ich würde wahrscheinlich irgendwann zurückkehren, aber ich konnte einfach nicht bleiben. Also musste ich diese

nicht bleiben. Also musste ich diese Sache machen.

Und dann erzähl mir von TypeScript insgesamt. Du hattest also diese Idee,

insgesamt. Du hattest also diese Idee, äh, du hast angefangen, es zwei Tage die Woche zu entwickeln und am Wochenende weiterzumachen, und dann hast du diesen Pre-Release-Verkauf gemacht. Was ist das?

gemacht. Was ist das?

Ich versuche im Grunde genommen, nie am Wochenende zu arbeiten. Ich bin da extrem radikal. Ich weiß es einfach

extrem radikal. Ich weiß es einfach nicht. Ich glaube, das ist etwas, woran

nicht. Ich glaube, das ist etwas, woran ich meistens scheitere, weil ich ein ziemlich zwanghafter Mensch bin. Ich

versuche gerne, etwas zum Laufen zu bringen, aber ich gehöre nicht zu diesen Typen, die, wie war das noch mal ? Wie war das mit dem SF-Ding, wo die

? Wie war das mit dem SF-Ding, wo die Leute 9 bis 96 Tage durchhalten?

996, 996. Mir wird davon schlecht, weißt du

996. Mir wird davon schlecht, weißt du ? Ich hasse so etwas einfach. Ich

? Ich hasse so etwas einfach. Ich

versuche mit allem, was ich tue, einen Lebensstil aufzubauen und ein Leben zu führen, in dem ich die meiste Zeit mit meiner Familie verbringen kann. Das ist

mein Ziel. Und das soll ich mit all meinen Entscheidungen vorwegnehmen, die hoffentlich in diesem Licht mehr Sinn ergeben. Bei Total TypeScript habe ich

ergeben. Bei Total TypeScript habe ich mit einem Typen namens Joel Hooks zusammengearbeitet. Joel Hooks ist

zusammengearbeitet. Joel Hooks ist extrem witzig und hat mich extrem beeinflusst. Ich arbeite jetzt schon

beeinflusst. Ich arbeite jetzt schon seit Jahren mit ihm zusammen und er hat sich Egghhead ausgedacht. Er hat mit Keny Dods an seinen Kursen gearbeitet.

Ein äußerst erfolgreicher Kursentwickler im Hintergrund. Ich habe

ihn kontaktiert und gesagt: „Würdest du diesen Kurs erstellen wollen?“,

und er sagte: „Ja, auf jeden Fall.“

Und von da an ging es los. Während ich

bei Versell war, habe ich auch mit Joel zusammengearbeitet. Wir haben diese

zusammengearbeitet. Wir haben diese Vorabversion erstellt. Wie gesagt, es

Vorabversion erstellt. Wie gesagt, es wurde einfach immer spannender. Mir

wurde klar: „Okay, ich muss mich da voll und ganz reinhängen.“ Ich

glaube, es war Januar 2023 oder Februar 2023, und wir haben den vollständigen Kurs veröffentlicht. Ich weiß nicht,

Kurs veröffentlicht. Ich weiß nicht, ich muss mir die Diagramme von damals noch mal anschauen, aber der Betrag erreichte extrem schnell einen siebenstelligen Betrag. Und das ist ein

siebenstelligen Betrag. Und das ist ein Umsatz, den Joel und ich gemeinsam erzielt haben. Natürlich gibt es da

erzielt haben. Natürlich gibt es da auch Ausgaben, aber was den reinen Umsatz angeht, war es extrem aufregend.

Ja, aber der siebenstellige Betrag, also 1 Million Dollar, das ist ein unglaublicher Meilenstein, nicht wahr?

Das ist verrückt, und lebensverändernd.

Und mir wurde klar: Okay, ich kann morgens aufwachen und das Geld wird trotzdem reinkommen. Das ist etwas,

trotzdem reinkommen. Das ist etwas, wovon ich lange geträumt habe, als ich noch Gesangslehrerin war. Material zu

erstellen, das ich online verkaufen konnte. Das ist etwas, das ich schon

konnte. Das ist etwas, das ich schon lange anstrebte, eine Art von Arbeit mit viel Einfluss, bei der ich die Arbeit erledigen und mich dann zurückziehen und zu meiner Familie zurückkehren kann. Und in den

zurückkehren kann. Und in den nächsten Jahren arbeitete ich an Typcript, erweiterte den Kurs, verkaufte ein paar Zusatzkurse und ja, das war im Grunde genommen der Punkt, an dem TypeScript insgesamt entstand.

Und das war der Hauptteil meines Erfolgs in den letzten vier Jahren: TypeScript insgesamt und dessen Aufbau.

Ja, und die Total Size Group war sehr inspirierend, vor allem, dass du offen einen großen Meilenstein genannt hast, als der Gesamtumsatz von 2,5 Millionen US-Dollar erreicht wurde. Ich denke,

das gilt für viele Softwareentwickler.

Natürlich wissen wir, dass dies vor Umsatzbeteiligung gilt und dass auch Ausgaben anfallen. Aber es ist etwas,

Ausgaben anfallen. Aber es ist etwas, das ganz klar ein höheres Verdienstpotenzial bietet als viele großartige Jobs im Bereich Softwareentwicklung, nicht unbedingt alle, vor allem wenn wir uns die USA und einige der KI-Labore und so weiter ansehen, die wahrscheinlich eine

Ausnahme waren. Aber die Tatsache, dass

Ausnahme waren. Aber die Tatsache, dass es einen Markt und ein Geschäft gibt, das man daraus machen kann, ist meiner Meinung nach ein ehrliches Modell. So

nach dem Motto: „Hey, ich habe dieses Ding entwickelt, die Leute bezahlen dafür, weil sie etwas lernen wollen, und hoffentlich haben sie einen Mehrwert daraus, denn sonst würden sie eine Rückerstattung verlangen“, richtig?

Genau. Wir haben eine sehr erweiterte Rückerstattungsrichtlinie. Ich neige

Rückerstattungsrichtlinie. Ich neige auch nicht dazu, andere Formen von Geld zu akzeptieren. Ich mag es nicht

zu akzeptieren. Ich mag es nicht unbedingt, gesponserte Inhalte zu machen. Ich werde nicht sagen, dass ich

machen. Ich werde nicht sagen, dass ich es nie tun werde, aber ich habe eine GitHub-Sponsorenseite, aber ich versuche wirklich, sie zu löschen. Ich

habe lange versucht, sie zu löschen.

Mir gefällt die Idee, einfach jemand zu sein, der sagt: „Okay, das sind die Produkte, die ihr von mir kaufen könnt. So könnt ihr mich

könnt. So könnt ihr mich unterstützen.“ Und hoffentlich

unterstützen.“ Und hoffentlich bringt euch das den zehnfachen Ertrag, denn das ist eine sehr lukrative Branche, nicht wahr? Viele Leute haben Bildungsbudgets, die sie ausgeben können. Und wenn ihr einen Teil eures

können. Und wenn ihr einen Teil eures Bildungsbudgets für mich ausgeben wollt, ist das im Grunde mein Modell.

Und ein Großteil des Geldes, das viele Leute, die den Kurs belegen, bekommen, stammt aus den Bildungsbudgets der Leute. Das sind Unternehmen, die viel

Leute. Das sind Unternehmen, die viel Geld für Bildung ausgeben. Und das war ein Markt, in den Joel mich unbedingt drängen und den ich realisieren wollte . Wissen Sie, ich hatte keine Ahnung,

. Wissen Sie, ich hatte keine Ahnung, wie viel Geld in dieser Branche floss, vor allem zu dieser Zeit und ehrlich gesagt immer noch. Aber die Tatsache, dass dieser Meilenstein innerhalb weniger Jahre erreicht wurde, hat mein Leben verändert.

Das klingt nach einer fantastischen Geschichte und könnte ein märchenhaftes Ende haben, in dem man sein Leben lang Bildungsinhalte erstellt, die sehr gefragt sind. Aber

dann kam die KI.

Ja.

Und wie wir wissen, verändert sie unsere Arbeitsweise und die Art und Weise, wie wir Informationen finden, sehr. Ich zum Beispiel google nicht

sehr. Ich zum Beispiel google nicht mehr so viel. Ich arbeite tatsächlich mit KI-Agenten oder mache tiefgreifende Recherchen oder ähnliche Dinge. Ich

habe Geschichten über Pädagogen und Online-Pädagogen gehört, die sagen, dass ihre Einnahmen, Marktanteile und ihr Bekanntheitsgrad einfach zurückgehen, weil die Leute vielleicht keine Kurse oder Sitzungen mehr absolvieren wollen, wenn sie sich einfach an einen Bot wenden können.

Wie haben Sie die Auswirkungen von KI auf die Branche, das Lernen der Menschen und auch auf Ihr Unternehmen und Sie als Lehrer erlebt?

Es ist kompliziert, weil KI die Spielregeln verändert hat, richtig?

Sie hat verändert, wie wichtig Wissen ist und insbesondere welche Arten von Wissen wichtig sind. Wenn ich meine Kurse gebe, denke ich mir daher, dass es zwei Ebenen gibt. Ich bringe dir die Syntax bei, ich bringe dir das Was bei, aber es gibt auch das Warum dahinter.

Und es ist sehr schwer, das Warum zu vermitteln, ohne das Was anzusprechen, wenn das Sinn ergibt. Die Art von Medium ist also: Ich werde dir diese Syntax beibringen, und vielleicht entwickelst du daraus Wissen, richtig?

Ich bringe dir Wissen bei, aber ich versuche auch, dir Weisheit beizubringen. Wissen ist jetzt sehr

beizubringen. Wissen ist jetzt sehr günstig zu erwerben, richtig? Sehr,

sehr günstig. Du kannst es einfach nachschlagen, weißt du? Du kannst dir eine Lehrfähigkeit aneignen, die dir einfach das Wissen beibringen kann, das du brauchst. Aber die Weisheit ist

du brauchst. Aber die Weisheit ist nicht einfacher zu erlernen geworden, richtig? Das ist immer noch aktuell,

richtig? Das ist immer noch aktuell, man wird immer noch auf die gleichen Probleme stoßen, auf die man gestoßen ist, wenn man vorher nicht über dieses Wissen verfügte, selbst mit KI. Was

meine Einnahmen aus dem gesamten Zeitaufwand für Skripte angeht, so sind diese natürlich zurückgegangen, weil ich denke, dass die Leute nicht mehr so sehr an diesem Material interessiert sind. Und ich denke, dass

interessiert sind. Und ich denke, dass Leute, die dieses Material unterrichten , es schwierig finden werden, weil dieses Wissen wirklich sehr schwer zu erlangen ist. Der einzige Weg, wie ich

erlangen ist. Der einzige Weg, wie ich überleben konnte, war nicht unbedingt, aber ich habe lange gebraucht, um herauszufinden, wo ich im KI-Bereich sein wollte, weil ich kein Forscher von OpenAI bin. Ich habe nicht die

OpenAI bin. Ich habe nicht die Qualifikationen, um wirklich über diese Dinge zu sprechen, vor allem nicht 2020, Ende 2023. Ich habe

angefangen, mich damit zu beschäftigen und habe zunächst Kurse darüber erstellt, wie man KI in Anwendungen einbindet. Ich dachte mir: Okay, ich

einbindet. Ich dachte mir: Okay, ich entwickle schon lange Frontend-Anwendungen. Es macht Sinn,

Frontend-Anwendungen. Es macht Sinn, dass KI die Dinge ein wenig verändert.

Aber mir wurde langsam klar, dass das die falsche Wette war. Ich habe nicht die erwarteten Ergebnisse gesehen und das Material gefiel mir nicht. Es war

gut und ich bin stolz darauf, aber ich dachte nicht, dass ich mehr davon machen wollte. Letztes Jahr im Dezember

machen wollte. Letztes Jahr im Dezember , ein Datum, das viele Leute nennen, ...Oh ja, wir kennen die Winterpause,

...Oh ja, wir kennen die Winterpause, in der alle mit KI zurückkamen.

Ja, genau. Die Peter-Pause, richtig?

Die Peter-Pause.

Die Open-Claw-Pause, als Opus 4.5 herauskam. Die Leute hatten viel

herauskam. Die Leute hatten viel Freizeit und stürzten sich einfach darauf. Dann wurde ihnen klar: Wow,

darauf. Dann wurde ihnen klar: Wow, okay, es passiert wirklich was. Das ist

mir auch passiert. Und mir wurde klar: Okay, die KI ist jetzt gut genug, dass man Aufgaben an sie delegieren kann.

Man kann tatsächlich Strukturen um die Agenten herum aufbauen, und die Agenten können sich um das Wissen, die Syntax und die taktischen Dinge kümmern. Ja.

Und man kann sich um die strategischen Dinge kümmern, das langfristige Denken . Das

. Das nutze ich sehr oft. Ich weiß, dass du John Amster in diesem Podcast hattest.

Ich wollte mich wirklich mit ihm unterhalten. Er hat einen großen

unterhalten. Er hat einen großen Einfluss auf mich. Er spricht über den Unterschied zwischen taktischer und strategischer Programmierung. Meiner

strategischer Programmierung. Meiner Meinung nach hat die KI die taktische Programmierung weitgehend aufgefressen, und es liegt an uns, uns um die Strategie zu kümmern. Mir wurde klar, dass ich auf der strategischen Ebene einen Kurs erstellen kann. Ich habe mir damals Ralph-Schleifen angesehen.

Jeffrey Huntley hat dieses wirklich coole Zeug entwickelt, bei dem man den Agenten in eine Schleife einbeziehen und ihn dazu bringen kann, diese Ziele zu verfolgen. Ich dachte mir, okay,

zu verfolgen. Ich dachte mir, okay, hier gibt es definitiv Material. Ich

muss nur eine Struktur finden, in die ich es einfügen und organisieren kann, wie ich damit herumexperimentiere. Ich

erinnere mich, dass es die Ralph-Schleifen gab. Du hast auch ein

Ralph-Schleifen gab. Du hast auch ein Video gemacht, das auf YouTube sehr beliebt wurde und überall zugänglich ist. Darin hast du im Grunde gesagt:

ist. Darin hast du im Grunde gesagt: „Okay, so habe ich eine Ralph-Schleife erstellt. Ich habe ein

Ralph-Schleife erstellt. Ich habe ein Projekt mit vielen To-dos.“ Und du hast einen tollen Job gemacht. Wir

werden das Video unten in den Shownotes verlinken. Darin sagtest du: „Okay,

verlinken. Darin sagtest du: „Okay, so würden wir normalerweise versuchen, Agenten zum Arbeiten zu bringen. Wir

erstellen im Voraus einen Plan und implementieren dann jeden Schritt, wie bei der herkömmlichen Top-Down-Planung .“ Und du sagst, das Problem sei,

.“ Und du sagst, das Problem sei, dass während der Implementierung oder sogar bei der Implementierung der Agenten erkannt wird: „Moment mal, ich muss noch mehr tun.“ Und wie ändert man den Plan? Und dann kommt die RAL-Schleife ins Spiel, in der du die Strukturen angegeben hast, die du damals verwendet hast. Es gab so etwas wie eine MD-Datei. Sie behält sie bei,

fügt hinzu, was dort war, und frisst sie gewissermaßen auf, aber sie fügt immer mehr hinzu. Und das war tatsächlich ein ziemlicher Augenöffner für mich, was die Art und Weise betrifft, wie man über diese Agenten nachdenkt. Tatsächlich waren

Agenten nachdenkt. Tatsächlich waren die paar Jahre, in denen ich versucht habe, Agenten in Anwendungen zu integrieren, sehr nützlich. Denn wenn

man versucht, eine App zu entwickeln, die einen Agenten enthält, denkt man immer an den Datenfluss. Man überlegt,

wie die Daten hineinkommen, in welcher Form sie sein werden, welche Priorität sie haben werden und ob man sie in die Systemeingabeaufforderung oder die Benutzereingabeaufforderung einfügt.

Man arbeitet auf einer niedrigeren Ebene, als man es normalerweise mit den Harnesses tun würde. Als ich dann anfing, mit den Harnesses zu arbeiten, fühlte es sich einfach sehr vertraut an. Ich muss nur wissen, wo der Status

an. Ich muss nur wissen, wo der Status abgelegt wird. Wie übergebe ich den

abgelegt wird. Wie übergebe ich den Status an die Agenten? Welche Form wird das haben? Wie komprimiere oder lösche

das haben? Wie komprimiere oder lösche ich es? Das war ja noch in den

ich es? Das war ja noch in den Anfängen des CL-Codes. Cloud war zu diesem Zeitpunkt seit fünf, sechs Monaten auf dem Markt.

Und es fühlte sich einfach sehr natürlich an. Und von da an war ich

natürlich an. Und von da an war ich einfach besessen von diesen, ich denke, wir würden sie heute Schleifen nennen, aber eigentlich sind es nur Prozesse.

Sie sind verschiedene Möglichkeiten, Agenten aneinanderzureihen. Das ist so

Agenten aneinanderzureihen. Das ist so ähnlich wie das Diagramm, richtig?

Wenn man Pfeile von einem Objekt zum anderen zeichnen kann, kann man das als Schleife bezeichnen, besonders wenn es einen Port gibt, der zurückgeht, oder man kann es einen Workflow oder einen Fluss oder was auch immer nennen, richtig?

Ich würde es eine endliche Zustandsmaschine nennen. Wissen Sie,

Zustandsmaschine nennen. Wissen Sie, ich fand, es fühlte sich sehr ähnlich an wie das, woran ich in XATE gearbeitet habe, das prozessbasiert ist , zustandsbasiert und manchmal auch ereignisbasiert, wo man unten einen Agenten hat, der oben ein Ereignis zurückruft. Und damit habe ich

zurückruft. Und damit habe ich angefangen, nur um richtig gute Ergebnisse zu sehen. Und ich habe diese Experimente durchgeführt, bei denen ich versucht habe, meinen Prozess zu erweitern und eine Funktion zu entwickeln. Ich habe ein paar Apps, an

entwickeln. Ich habe ein paar Apps, an denen ich arbeite, um das, was ich mache, zu erweitern, wie zum Beispiel einen benutzerdefinierten Video-Editor.

Ich habe eine riesige Sache, eine riesige Codebasis, auch ein paar Open-Source-Projekte, und ich habe nur diese kleinen Schleifen und Pipelines erstellt, und manchmal habe ich sie einfach verworfen und zum Standard-Setup zurückgekehrt, und mir ist einfach ein riesiger Unterschied

aufgefallen. Ich dachte mir: „Wow,

aufgefallen. Ich dachte mir: „Wow, okay, das, was ich hier mache, bereitet mich wirklich auf den Erfolg vor“, und ich begann darüber nachzudenken: „Wie kann ich das am besten verbreiten? Wie kann ich das besser mit

verbreiten? Wie kann ich das besser mit anderen Menschen teilen?“ Und da bin ich auf Skills als Verbreitungsmechanismus für dieses Zeug gekommen.

Das sind die Skills für KI-Bots-Harnesses, in denen man sie normalerweise definieren kann, und jetzt kann man sie, sobald man sie installiert hat, mit einem Slash-Befehl aufrufen.

Skills sind eigentlich nur ein Ordner mit Markdown-Dateien, die sich irgendwo auf deinem Computer befinden können, und die Agenten können sie entweder selbst aufrufen. Also Modell-Skills

selbst aufrufen. Also Modell-Skills aufrufen, oder man kann Skills haben, von denen der Agent nichts weiß, die man aber selbst aufrufen kann. Benutzer

rufen also Fähigkeiten auf, und ich sah, wie diese Fähigkeiten überall auftauchten wie Superkräfte und Claw-Code-Plugins, die man installieren kann. Ich denke auch an GStack. Mir

kann. Ich denke auch an GStack. Mir

wurde klar: Okay, vielleicht kann ich das, was ich habe, diesen Prozess als eine Reihe von Fähigkeiten verbreiten und sehen, was die Leute davon halten.

Und zunächst habe ich es einfach hochgeladen und mich um andere Dinge gekümmert. Ich habe an einem Kurs

gekümmert. Ich habe an einem Kurs gearbeitet und als ich mich wieder einloggte, stellte ich fest: Oh, er hat mehr Sterne als alles andere, was ich je gemacht habe. Ich habe noch nicht einmal wirklich darüber gesprochen.

Wissen Sie, er lag einfach nur da.

Durch Mundpropaganda, schätze ich. Ich

habe ein wenig Dokumentation geschrieben, aber wirklich nicht viel, und die Informationen sind bereits explodiert. Also dachte ich: Okay,

explodiert. Also dachte ich: Okay, vielleicht sollte ich noch ein bisschen mehr Arbeit da reinstecken. Vielleicht

sollte ich darüber sprechen. Und ich

habe einen Vortrag gehalten, ich glaube , bei unserem letzten Treffen, das war im April bei AI Engineer London. Der

Vortrag trug den Titel: Software Fundamentals still matter. Und dieser

Vortrag hat mittlerweile, glaube ich, 1,2 Millionen Aufrufe oder so. Und ich

habe das Skillset erwähnt. Das

Skillset hat mittlerweile 230.000 Sterne. Damit ist es das am

Sterne. Damit ist es das am zweithäufigsten mit Sternen bewertete Skills-Repository der Welt. Ich glaube,

es liegt irgendwo zwischen Platz 20 und 25 der am häufigsten mit Sternen bewerteten Repositories aller Zeiten.

Wow. Sie wissen, was ich meine? Was ist

da los? Es gibt also offensichtlich einen großen Bedarf danach. Das war

also das zweite Mal in meiner Karriere, genau wie damals, als ich die kleinen Typescript-Videos veröffentlicht habe, bei denen ich das Gefühl hatte: „Wow , hier kommt eine Dynamik ins Spiel. Da

tut sich was.“ Und deshalb hatte ich das Gefühl, dass ich mich da noch mehr anstrengen musste.

Wie haben Sie die Skills geschrieben?

Versucht das, Ihren Workflow zu erfassen, Ihr Verständnis dafür, was mit Agenten funktioniert? Nicht nur im Moment, sondern natürlich denken Sie auch über den Status nach, Sie denken darüber nach, wie Sie KI in Anwendungen integrieren, was wiederum nicht so sehr an Fahrt aufgenommen hat,

aber Sie haben gelernt. Ist das also Matts Workflow, Matts Art und Weise, wie er das macht, was für mich funktioniert?

Ja, so ist es. Ich versuche, mir zunächst einmal vorzustellen, dass die Leute diese Fähigkeiten nutzen und daran herumbasteln werden. Wie erstelle

ich also die einfachsten Fähigkeiten, die die Leute ganz einfach überprüfen können? Ich versuche zu überlegen,

können? Ich versuche zu überlegen, wie ich die Wahrscheinlichkeit maximieren kann, dass die Leute diese Fähigkeiten erlernen und bei der Arbeit einsetzen? Zum Beispiel die

Arbeit einsetzen? Zum Beispiel die Fähigkeit „Grill me“, die am beliebtesten ist.

Ich weiß nicht, ob du sie schon benutzt hast, aber ich benutze sie auch. Okay.

Nun, es ist nervig, wie verdammt es mich gegrillt hat. Ich habe es einfach gefragt. Ich

hat. Ich habe es einfach gefragt. Ich

dachte mir, ich würde gerne einen API-Endpunkt bereitstellen, der demjenigen, der über das authentifizierte Token verfügt, mitteilen kann, dass ich über eine grundlegende Authentifizierung verfüge . Ist diese E-Mail-Adresse ein Abonnent

. Ist diese E-Mail-Adresse ein Abonnent meiner E-Mail-Liste oder nicht? Weil

ich es mit einem der Events verbinden möchte, die ich mache, um Priorität für zahlende Abonnenten zu erhalten.

Und das ist doch ganz einfach, oder?

Und dann fängt das Grill-Me-Ding an, mich wirklich zu grübeln, so nach dem Motto: Okay, wie sieht es mit der Authentifizierung aus? Willst du den

Authentifizierung aus? Willst du den Inhaber-Token oder willst du ihn in JSON, was nicht so sicher ist usw.?

Okay, nun, das ist eine Entscheidung, die [] wir treffen müssen, und dann gehen wir alle diese Entscheidungen durch, und es geht wirklich auf niedriger Ebene weiter, einschließlich : „Okay, wie setzen wir Ratenbegrenzungen durch?“ Wenn es um

Ratenbegrenzungen durch?“ Wenn es um Ratenbegrenzungen geht, willst du das genau dann tun, wenn du beispielsweise tausend pro Tag bekommst, und nicht [] eine weitere zulassen, was mehr Komplexität bedeutet. Und mir ist

Komplexität bedeutet. Und mir ist gerade aufgefallen, dass es lange her ist, dass ich so eine tiefgreifende Designdiskussion mit einem Team oder einem Entwicklungsteam geführt habe.

Normalerweise hat man so etwas, wenn jemand über tiefgreifendes Fachwissen verfügt. Ich fand es einerseits

verfügt. Ich fand es einerseits genervt von den Aussagen „Das ist doch einfach“ und „Nein, mach dir darüber keine Sorgen“. Andererseits

war ich auch beeindruckt, dass dieses Ding, diese KI, dieses LM mithilfe einer Reihe von Eingabeaufforderungen all das tun kann.

Ich meine, jeder hat eine Geschichte, in der er mich fertigmacht. Ich höre

so viele davon auf Konferenzen. Die

Leute sagen: „Du hast diese ganz, ganz einfache Fähigkeit.“ Im Grunde genommen sagst du dem Agenten nur, er soll dich unerbittlich zu dem Thema interviewen. Das ist eine sehr kleine

interviewen. Das ist eine sehr kleine Fähigkeit. Sie hat einfach dieses

Fähigkeit. Sie hat einfach dieses seltsame emergente Verhalten, bei dem die Modelle anfangen, ein wenig über den Tellerrand hinauszuschauen und dir Ideen zuwerfen. Ich glaube, ich habe

Ideen zuwerfen. Ich glaube, ich habe das ursprünglich von einem gewissen Tariq, der mit Claw Code arbeitet. Er

sagt im Grunde, dass man den Agenten bitten soll, einen zu interviewen, dann sieht man bessere Ergebnisse. Also habe

ich das in eine kleine Fähigkeit umgewandelt und mir wurde klar: Wow, okay, das ist einfach zehnmal besser als alles, was ich je benutzt habe. Und

diese Grill-Me-Fähigkeit war die erste , die mich ein wenig an die Diskussionen erinnerte, die ich bei meinem ersten Job mit dem Typen in den Sandalen geführt habe. Dieser sehr

leitende Ingenieur im Raum brachte mich wirklich dazu, über alles nachzudenken , was ich getan hatte. Es war für mich das Vertrauteste, tatsächlich mit jemandem wie Anderist Rake bei Xate zusammenzuarbeiten. Es fühlte sich

zusammenzuarbeiten. Es fühlte sich einfach an, als würde mir ein wirklich hochqualifizierter Entwickler diese guten Fragen stellen. Und ich dachte: Wow, okay. Und dann fing ich an, das zu

Wow, okay. Und dann fing ich an, das zu nehmen und zu überlegen: Wie kann ich diesen Agenten für grundlegendere Software-Sachen ausnutzen? Wie kann ich

Software-Sachen ausnutzen? Wie kann ich dafür sorgen, dass er sich mehr wie ein richtiger Entwickler anfühlt, ein echter Senior? Wie kitzle ich den

echter Senior? Wie kitzle ich den richtigen latenten Raum, damit sich sein Verhalten ändert und ich auf interessante Weise herausgefordert werde? Denn wenn Sie das können, wenn

werde? Denn wenn Sie das können, wenn Sie die Qualität der Unterhaltung mit dem Agenten steigern können, dann steigern Sie auch die Qualität der Ergebnisse. Was mir an der

Ergebnisse. Was mir an der Grill-Meme-Fähigkeit gefallen hat, ist , dass sie mich dazu zwingt, Entscheidungen zu treffen, von denen ich weiß, welche ich treffen muss, wenn ich darüber nachdenke. Aber es

ist meine Entscheidung. Anders als wenn ich dem Agenten sage, dass ich den Befehl/go ausführe, z. B. „Build

this“, und er dann loslegt und dies und jenes tut und alle Entscheidungen oder die wichtigsten Entscheidungen trifft. Was mir an Grill Me gefällt,

trifft. Was mir an Grill Me gefällt, ist, dass ich die Entscheidung treffe, aber dass es mich manchmal auch an Dinge erinnert, über die ich nicht so viel nachgedacht habe, oder dass ich ein wenig recherchieren sollte. Es

fragt mich zum Beispiel, welche Authentifizierung ich verwenden möchte : einen Bearer-Token oder über Post oder sogar über Get? Und dann denke ich mir: „Moment mal“, ich schlage nach, was die Unterschiede sind, oder bitte eine andere Sitzung, mich darüber aufzuklären. Es macht mich

darüber aufzuklären. Es macht mich also zu einem besseren Profi und ich glaube, wenn man mit KI arbeitet, ist alles in Ordnung, solange wir lernen.

Solange wir aufhören zu lernen und das Lernen an dieses Ding auslagern, wird es vielleicht noch Monate oder Jahre später Probleme geben. Zu

100%. Es gibt zwei Dinge, die meiner Meinung nach jeder an Agenten unterschätzt: Es gibt eine Kommunikationslücke zwischen einem und dem Agenten. Da gibt es eine Barriere.

dem Agenten. Da gibt es eine Barriere.

Man hat das Gefühl, dass der Agent, weil er kein Mensch ist und man die eigene Wertehierarchie versteht, diese einfach übernehmen wird. Man hat das Gefühl, man solle dem Modell einfach vertrauen. Vor allem bei den

vertrauen. Vor allem bei den Top-Modellen gilt: Man solle dem Modell einfach vertrauen. Aber der Agent, egal

einfach vertrauen. Aber der Agent, egal wie gut oder intelligent das Modell ist , selbst Mythos, kann deine Gedanken nicht lesen. Er kann deine Gedanken

nicht lesen. Er kann deine Gedanken nicht lesen. Also muss es einen Prozess

nicht lesen. Also muss es einen Prozess geben, um dem Agenten deine Werte zu vermitteln. Denn oft, wenn du ein Ziel

vermitteln. Denn oft, wenn du ein Ziel erreichst und einfach sagst: „Okay, spamme mich einfach mit etwas Code zu, gib mir etwas Schnickschnack“, wird der Agent etwas produzieren, das überhaupt nicht mit dir übereinstimmt , weil er nicht versteht, was du für wichtig hältst. „Grill me“ geht es

wichtig hältst. „Grill me“ geht es also nicht nur um Implementierungsdetails, sondern auch darum, klarzustellen: „Okay, mach dies, das ist im Rahmen, das ist nicht im Rahmen, das ist meiner Meinung nach wichtig.“ Der Agent lernt dich also

wichtig.“ Der Agent lernt dich also kennen.

Matt hat gerade die Grill me-Fähigkeit beschrieben. Als ich diese Fähigkeit

beschrieben. Als ich diese Fähigkeit verwendet habe, um einen API-Endpunkt zu entwerfen, waren die ersten Fragen, die gestellt wurden, was der Endpunkt tun durfte und was nicht, und für wen er es tun durfte. In meinem Fall hatte ich eine ziemlich gute Vorstellung davon, was ich wollte, aber es ist im Allgemeinen keine gute Idee, einen

Agenten die Authentifizierung und Autorisierung improvisieren zu lassen, wie sie es oft tun würden. Das bringt

uns zu unserem Saisonsponsor, Work OS.

Wie autorisiert man KI-Agenten? Das

Problem ist, wie Sie den Umfang des Agenten steuern möchten. Der knifflige

Teil besteht darin, dass Berechtigungen statisch sind, die Aufgabe des Agenten jedoch dynamisch ist. Teams müssen

sich also zwischen zwei schlechten Optionen entscheiden. Entweder Sie

Optionen entscheiden. Entweder Sie lesen die Eingabeaufforderung, genehmigen dann jeden Toolaufruf und- aufruf manuell, lesen die Eingabeaufforderung erneut, genehmigen sie dann erneut manuell, bis Sie schließlich aufhören, die Eingabeaufforderung zu lesen, oder Sie arbeiten einfach im Yolo-Modus, lassen

es laufen und hoffen, dass das, was der Agent tut, nicht irreversibel ist. Aber

es gibt einen besseren Weg. Work hat

gerade die absichtsbasierte Zugriffskontrolle Airlock für Agenten eingeführt. Sie schreiben die Regeln

eingeführt. Sie schreiben die Regeln in einfachem Englisch. Lesen Sie

beispielsweise Repositories und Kommentare zu PRs. Alles, was die Abrechnung des Autors betrifft, muss genehmigt werden. Pushen Sie niemals an

genehmigt werden. Pushen Sie niemals an die Hauptaufgabe. Jeder Aufruf, den der

die Hauptaufgabe. Jeder Aufruf, den der Agent tätigt, wird anhand seiner Aufgabe beurteilt und zugelassen, abgelehnt oder an einen Menschen weitergeleitet. Jedes Urteil wird von

weitergeleitet. Jedes Urteil wird von Airlock protokolliert. Das Besondere an

Airlock protokolliert. Das Besondere an Airlock ist, dass es keine vorab festgelegten Bereiche und keine Regeln gibt, die zugewiesen werden müssen.

Die Aufgabe selbst definiert, was der Agent tun kann. Work Airlock ist bereits im Early Access verfügbar.

Fordern Sie es unter work.com/airlock

an. Ich möchte auch unseren präsentierenden Sponsor Turbo Buffer erwähnen. Matt und ich diskutieren

erwähnen. Matt und ich diskutieren eine grundlegende Frage. Wie bringt man Agenten dazu, sich an das Wichtige zu erinnern? Hier ist eine Idee. Was wäre

erinnern? Hier ist eine Idee. Was wäre

, wenn man den Agenten einfach seinen gesamten Verlauf durchsuchen lässt, anstatt ein komplexes Speichersystem aufzubauen? Das klingt nach viel zu

aufzubauen? Das klingt nach viel zu hohem Aufwand, ist es aber mit Turbobuffer nicht. Dank der nativen

Turbobuffer nicht. Dank der nativen Objektspeicherarchitektur von Turbopuffer sind die Grenzkosten für die Transkription von Quellsitzungen so gut wie nicht vorhanden, sodass es sich wirtschaftlich macht, den gesamten Chatverlauf zu indizieren. Und da

Turbobuffer-Namespaces praktisch unbegrenzt skalierbar sind, können Sie für jeden Agenten einen dedizierten Suchindex erstellen. Hier ist ein gutes

Suchindex erstellen. Hier ist ein gutes Beispiel dafür. Entire, ein weiterer

Beispiel dafür. Entire, ein weiterer Sponsor des Podcasts, indiziert Hunderte Millionen von Transkripten von Agentensitzungen für die Suche und lässt den codierenden Agenten dann abrufen, was er benötigt, um sich daran zu erinnern, wie und warum eine technische Entscheidung getroffen wurde . entire zeigte, dass ihr Agent genauer

. entire zeigte, dass ihr Agent genauer war, weniger Token verwendete und weniger Zeit zum Finden von Speichern benötigte, wenn er Turbo Buffer anstelle von Git History und einer CLI verwendete. Der Speicher von Agenten

verwendete. Der Speicher von Agenten ist ein komplexer und sich weiterentwickelnder Anwendungsfall.

Aber vielleicht gibt es hier eine bittere Lektion. Vielleicht ist die

bittere Lektion. Vielleicht ist die beste Lösung die einfache. Durchsuchen

Sie einfach jedes Transkript. Mit

Turbopuffer ist das tatsächlich möglich. Wenn Sie das Problem des

möglich. Wenn Sie das Problem des Agentenspeichers lösen möchten, wenden Sie sich bitte an das Turboper-Team unter turbopuffer.com/pagmatic. Und welche

turbopuffer.com/pagmatic. Und welche

anderen Fähigkeiten haben Sie entwickelt? Von da an dachte ich: „

entwickelt? Von da an dachte ich: „ Okay, wie kann ich dieses Gespräch nehmen und in Code umwandeln?“ Und

ich hatte sofort Angst, weil ich mit Modellen gearbeitet hatte, kurz bevor sie gut waren und vor dem Dezemberwinter, als die Dinge richtig gut wurden. Und so spürte ich die

gut wurden. Und so spürte ich die Einschränkungen meiner bisherigen Arbeit. Ich wusste zum Beispiel, dass

Arbeit. Ich wusste zum Beispiel, dass die Leistung des Agenten umso schlechter wird, je mehr Kontext man ihm gibt. Ich weiß, dass Dex Horthy in

ihm gibt. Ich weiß, dass Dex Horthy in diesem Podcast zu Gast war. Ja. Und Dex

beeinflusst mich wirklich sehr, besonders seine Idee der Smart Zone und der Dumb Zone.

Smart Zone und Dumb Zone. Ja.

Ja. Die Idee dahinter ist nur, damit du dir den Podcast nicht komplett anhören musst, obwohl du es solltest. Im Grunde

genommen gilt: Je mehr Kontext du dem Agenten gibst, desto mehr schreit jedes Token nach Aufmerksamkeit. Und je mehr Stimmen du in diesen Raum bringst, desto schwieriger wird es, die wichtigen zu hören. Und so verliert das Modell die Verbindungen zwischen den Dingen und macht deswegen Fehler.

Und du kannst dir das als einen langsamen Verfall vorstellen. Aber es

gibt einen Teil des Kontextfensters, in dem es besser und in dem es schlechter ist. Und so hast du die Smart Zone, die

ist. Und so hast du die Smart Zone, die derzeit etwa die ersten 150.000 Token von Frontier-Modellen eines Fensters von 1 Million Token umfasst.

Ja. Von jedem Token-Fenster jeder Größe. Die Größe des

Größe. Die Größe des Kontextfensters spielt keine Rolle. Es

dreht sich alles um die reine Menge an Token, die reine Menge an Aufmerksamkeitsbeziehungen, und dann nimmt der Rest langsam immer mehr ab.

Und so begann ich darüber nachzudenken , wie ich Arbeit, die größer als 150.000 Token ist, was ja nicht sehr umfangreich ist, auf mehrere Kontextfenster und Sitzungen aufteilen kann. Und das hat mich viele Versuche

kann. Und das hat mich viele Versuche und viel Herumexperimentieren mit verschiedenen Ansätzen gekostet. Die

Ralph-Schleifen waren eine Version davon. Ralph-Schleifen wurden

davon. Ralph-Schleifen wurden entwickelt, um die Smart Zone optimal zu nutzen, da sie der Ralph-Schleife im Wesentlichen nur ein Ziel vorgeben und sagen: „Mach die kleinstmögliche Änderung, die uns diesem Ziel näher bringt, und lösche dann deinen Kontext und beginne von vorne.“

Genau. Und du fängst technisch gesehen nicht bei Null an, da du die Codebasis hast, richtig? Es gibt ein bisschen

hast, richtig? Es gibt ein bisschen Status, der im Dateisystem und in der Umgebung gespeichert ist, aber im Wesentlichen nicht im Modell. Das ist

also die Idee. Also begann ich darüber nachzudenken, wie ich diese Idee der Ralph-Schleife aufgreifen und ein wenig stabiler machen und in Fähigkeiten umwandeln kann? Und mir wurde klar,

umwandeln kann? Und mir wurde klar, dass ich zwei verschiedene Arten von Dokumenten benötigte. Man benötigt

Dokumenten benötigte. Man benötigt ein Dokument für das Ziel, das Zieldokument. Früher

Zieldokument. Früher nannte ich das ein Produktanforderungsdokument oder jetzt nenne ich es eine Spezifikation.

Das ist die Spezifikation, die festlegt , wann man das Ende erreicht hat. Dann

muss man diese Spezifikation in einzelne Tickets aufteilen, ein Ticket pro Sitzung. Ich habe eine sehr

pro Sitzung. Ich habe eine sehr einfache Möglichkeit, einfach Spezifikationen und dann Tickets zu erstellen. Man nimmt also diese

erstellen. Man nimmt also diese Grillsitzung, die man hatte, und macht daraus eine Spezifikation. Diese

Spezifikation kann sich auf beispielsweise 30 bis 40 Tickets beziehen. Man kann wirklich riesige

beziehen. Man kann wirklich riesige Arbeitspakete haben, die alle in diese Spezifikation eingebunden sind. Das ist

die Hauptidee. Man grillt einfach. Man

wandelt dieses Grillen in eine Spezifikation um. Und dann lässt man

Spezifikation um. Und dann lässt man einfach eine Art Implementierungsschleife über diese Tickets laufen, bis man ein großes Arbeitspaket hat. Bekommt man nach dem

Arbeitspaket hat. Bekommt man nach dem Grillen auch Benutzereingaben oder während dieses Prozesses, oder das hängt davon ab.

Ich habe das hauptsächlich so konzipiert, dass der Benutzer es so ausführen kann, dass er sich nicht an der Tastatur befindet, da es diese Idee der Tag-und Nachtschicht gibt. Haben Sie davon

Nachtschicht gibt. Haben Sie davon gehört?

Nein. Nein. Nein.

Es ist großartig. Im Grunde genommen besteht die optimale Art, mit Agenten zu arbeiten, darin, die Planung während der Tagschicht vorzunehmen und die Agenten dann während der Nachtschicht arbeiten zu lassen, richtig? Und hoffentlich wachen Sie

richtig? Und hoffentlich wachen Sie morgens auf und haben einen schönen, sauberen Code, den Sie sich ansehen können. Und genau dafür habe ich

können. Und genau dafür habe ich versucht, meinen Prozess zu optimieren, denn ich hatte es wirklich satt, dass ich immer noch zwischen Terminals und Kontexten hin-und herwechsele und einfach nur „bumm, bumm, bumm, bumm, bumm“ mache. Was ich wollte und was

bumm“ mache. Was ich wollte und was ich optimieren möchte, ist, einfach einen Großteil der Planung zu erledigen und den Agenten dann ein paar Stunden arbeiten zu lassen. Und dann

kann ich mich anderen Aufgaben widmen, in angemessenen Zeitblöcken, 15 Minuten lang an einer Sache arbeiten, Dinge planen und dann den Code überprüfen und das tun. Das habe ich also die ganze Zeit optimiert, als ich Ralph Loops gemacht habe. Das war die große Erkenntnis im Dezember: Diese Jungs sind gut genug, um Aufgaben an

sie zu delegieren, sodass ich sie AFK laufen lassen kann. Und dann gibt es noch eine andere Fähigkeit, die etwas ambitionierter ist: die Wayfinder-Fähigkeit. Können wir

Wayfinder-Fähigkeit. Können wir darüber sprechen? Auf jeden Fall.

darüber sprechen? Auf jeden Fall.

Genauso wie ich festgestellt habe, dass die Implementierung auf mehrere Sitzungen aufgeteilt werden muss.

Manchmal grillt man etwas und stößt an seine Grenzen. Man grillt etwas, man baut mir einen Stripe-Klon oder so etwas, richtig? Da stößt man an seine

etwas, richtig? Da stößt man an seine Grenzen. Das kann man unmöglich mit

Grenzen. Das kann man unmöglich mit 150.000 Token planen. Also habe ich mir überlegt, wie ich das aufteilen kann, damit ich unendlich lange Grill-Sitzungen durchführen kann. Wie

teile ich Grill-Sitzungen auf, damit es so funktioniert? Und so kam ich wieder

so funktioniert? Und so kam ich wieder auf diese Idee. Ich denke im Wesentlichen über den Informationsfluss nach: Was braucht er, um in einer Grill-Sitzung gut zu funktionieren? Wahrscheinlich muss es

funktionieren? Wahrscheinlich muss es genau verstehen, was der Zweck dieser Verhör-Session ist, aber es muss auch verstehen, was bisher entschieden wurde . Es muss verstehen, welche anderen

. Es muss verstehen, welche anderen Verhör-Sessions in diesem Moment stattfinden könnten. Und ich hatte

stattfinden könnten. Und ich hatte diese Idee mit einer Karte. Die Karte

wäre eine Art Mittelpunkt für alles, was für alle Entscheidungen benötigt wird, die man trifft. Und wenn man eine Karte hat, merkt man, okay, es gibt bestimmte Dinge, die ich tun kann, während ich versuche, meinen Weg zu einem Ziel zu finden, es gibt bestimmte Dinge, von denen ich weiß, dass ich sie entscheiden muss, bestimmte Punkte,

die so etwas wie Meilensteine auf der Karte sind. Und es gibt einen Nebel des

Karte sind. Und es gibt einen Nebel des Krieges. Und diese schöne Metapher hat

Krieges. Und diese schöne Metapher hat mich durch die Entwicklung des restlichen Skills geführt, richtig?

Denn man hat seine Karte, man hat seinen Nebel des Krieges, man weiß ungefähr, wo man hin will, und jedes Mal, wenn man eine Verhör-Session hat, werden mehr Punkte auf der Karte sichtbar. Und so findet man mehr und

sichtbar. Und so findet man mehr und mehr heraus, wo man hin will. Das ist

also eine Art gerichteter zyklischer Graph, bei dem man so lange läuft, bis man sein endgültiges Ziel erreicht.

Man hat also die Karte und für jede einzelne Sitzung gibt es Tickets auf dieser Karte. Und mir wurde klar: Okay,

dieser Karte. Und mir wurde klar: Okay, Grillen ist gut, aber was ist, wenn man einen Prototyp erstellen muss? Was ist,

wenn man recherchieren muss? Was ist,

wenn man eine beliebige Aufgabe erledigen muss, wie zum Beispiel die Bereitstellung von Infrastruktur oder Ähnlichem? Nun, das sind verschiedene

Ähnlichem? Nun, das sind verschiedene Arten von Tickets auf der Karte. Und

Wayfinder führt einen im Grunde genommen nur durch diesen Prozess. Ich

hatte Karten, die 50, 100 Tickets oder so hatten, bis ich endlich mein Ziel erreichte. Ich habe es tatsächlich

erreichte. Ich habe es tatsächlich auch für die Kursplanung verwendet, also für nicht-technische Dinge, was wirklich großartig ist. Ich habe es verwendet, um ein Gartenbüro in meinem Garten zu bauen. Richtig. Es ist, es ist, weißt du, viele dieser Fähigkeiten, von denen wir sagen: „ Okay, die sind großartig für das

Ingenieurwesen.“ Dann wird einem klar

Ingenieurwesen.“ Dann wird einem klar : „Okay, Ingenieurwesen ist nur eine Disziplin…“ Was machen wir hier?

Wir diskutieren nur über etwas. Wir

tun Dinge im echten Leben, wie zum Beispiel das Surfen auf Webseiten und so. Man merkt, wie leicht sich das auf

so. Man merkt, wie leicht sich das auf andere Bereiche übertragen lässt.

Vielleicht können wir das später noch einmal kurz ansprechen. Ich denke

darüber nach, wie übertragbar dieses Thema auf andere Disziplinen und Lebensbereiche ist. Wayfinder war da

Lebensbereiche ist. Wayfinder war da großartig.

Aber wenn wir über eine interessante Sache in Bezug auf Ingenieurwesen und Softwareentwicklung nachdenken: Hill Wayne hat im Podcast Ingenieure interviewt, die er für echte Ingenieure hält: Chemieingenieure, Maschinenbauingenieure, Bauingenieure.

Er wollte herausfinden, ob Softwareentwicklung echtes Ingenieurwesen ist. Und am Ende stellte

Ingenieurwesen ist. Und am Ende stellte er fest, dass dies wahrscheinlich der Fall ist. Er sagte jedoch, dass sich

Fall ist. Er sagte jedoch, dass sich Softwareentwicklung von allen anderen Ingenieurberufen stark durch die Materialien unterscheidet, mit denen wir überall arbeiten. Maschinenbau,

Bauingenieurwesen und sogar Chemieingenieurwesen–all das sind Materialien, die eine Grenze haben. Man

weiß nicht genau, wie sie beschaffen sind. Sie wissen, dass es so sein wird,

sind. Sie wissen, dass es so sein wird, dass es ungefähr so viel Last usw.

aufnehmen kann. Aber bei Software ist das Material Software, das heißt, es funktioniert einfach wie ein Programm.

Ich meine, lassen wir mal das Nichtdeterministische weg, was uns vielleicht mehr in Richtung Technik bringt, aber Software, ein Code, den man tausendmal ausführt, macht tausendmal dasselbe, während das in anderen Bereichen nicht der Fall ist.

Und er sagte, dass er einen großen Unterschied sieht. Aber jetzt haben wir

Unterschied sieht. Aber jetzt haben wir bei LLMs vielleicht so etwas, bei dem man es tausendmal ausführt und es diese Varianz aufweist, die die meisten technischen Bereiche haben. Wer weiß

also, ob das, was mit LLMs funktioniert , auch in anderen technischen Bereichen nützlich sein wird, wo es diese Varianz bereits gab, oder ob wir Ansätze aus anderen technischen Berufen übernehmen können, die vielleicht gut mit diesem Material namens KI funktionieren.

Ich stimme voll und ganz zu. Ich finde

es interessant, dass Softwareentwicklung und der Grund, warum Agenten damit gut umgehen können , darin bestehen, dass alle Eingaben und Ausgaben komplett textbasiert sind.

Die Eingaben, also die Dokumentationen, die Anweisungen für den Agenten, was er tun soll, sind allesamt textbasiert, und die Ausgabe, die aus weiterem Code besteht, ist Test-Suites, Typprüfungen , Ergebnis-Lint-Tests und all das Zeug ist textbasiert. Womit Agenten wirklich

ist textbasiert. Womit Agenten wirklich zu kämpfen haben, ist alles, was nicht-extbasiert ist. Aber man sieht

nicht-extbasiert ist. Aber man sieht diese tollen Demos von Leuten, die beim ersten Mal eine perfekte Benutzeroberfläche auf Anhieb hinbekommen. Was aber, wenn man in

hinbekommen. Was aber, wenn man in dieser Benutzeroberfläche ein Interaktionsproblem hat? Was, wenn man

Interaktionsproblem hat? Was, wenn man mit der Maus über etwas fährt und die Animation nicht richtig aussieht? Wie

soll man das dann an den Agenten weitergeben? Man kann es ja als Video

weitergeben? Man kann es ja als Video aufnehmen, und es hält dann bei bestimmten Frames an. Aber in puncto Optik ist es noch nicht so gut. Alles,

was nicht-extbasiert ist, ist für den Agenten also einfach nur Müll. Er kann

damit einfach nicht umgehen. Ich denke

also, dass in solchen Berufen, wenn man sich umdrehen kann, ich nehme an, sie führen Simulationen durch, richtig?

Ich vermute, sie arbeiten mit einer Art ...Ich weiß nicht, ob Sie einen

...Ich weiß nicht, ob Sie einen Computer haben, der mit Architekturdiagrammen arbeiten kann.

Ich bin sicher, Sie haben so etwas in der Art, oder? Eine Simulation. Wenn

Sie das textbasiert gestalten können, wenn Sie die Interaktionen, die Sie in Ihrem täglichen Leben haben, in Text umwandeln können, was ohnehin meistens der Fall ist, dann werden die Agenten eine ziemlich gute Arbeit leisten. Das

ist etwas, was ich derzeit versuche: Alle Dienste, die ich nutze, zu nehmen und sie in Agenten einzubinden, richtig ? Sie den Agenten zur Verfügung zu

? Sie den Agenten zur Verfügung zu stellen. Aber ja, je

stellen. Aber ja, je agentenfreundlicher wir unsere Arbeit gestalten können, desto bessere Ergebnisse werden wir erzielen. Zurück

zur KI als Ganzes und was sich geändert hat. Es hat sich so vieles

geändert hat. Es hat sich so vieles geändert. Eine Sache, die bei KI immer

geändert. Eine Sache, die bei KI immer wieder auftaucht, insbesondere bei Forschern und Mitarbeitern von KI-Unternehmen, ist: „Keine KI-Vorkenntnisse; man sollte alles, was man bisher wusste, hinter sich lassen, denn das hier ist anders. Man muss bei Null anfangen. Die Ansätze

Null anfangen. Die Ansätze funktionieren möglicherweise nicht.

Nehmen wir einfach an, dass sie nicht funktionieren, und entwickeln neue Ansätze.“ Sie waren vor der KI

Ansätze.“ Sie waren vor der KI Entwickler und haben sich sehr für die Entwicklung hochwertiger, großartiger Software interessiert. Wie sehr hat

Software interessiert. Wie sehr hat sich Ihrer Meinung nach durch KI alles verändert, auch die Grundlagen? Das

habe ich mir auch gedacht. Ich dachte,

KI hat alles verändert. Ich schütte

das Kind nicht mit dem Bade aus, oder?

Ich denke, wir müssen einfach alles aus einem neuen Blickwinkel betrachten.

Ich habe damit angefangen, weil ich mir vor allem die so genannte spezifikationsgesteuerte Entwicklung angeschaut habe. Ich habe da gemischte

angeschaut habe. Ich habe da gemischte Gefühle. Ich finde, es ist ein

Gefühle. Ich finde, es ist ein seltsamer Begriff, der zu viel umfasst.

Ich dachte mir: „Okay, vielleicht ist Englisch die angesagte neue Programmiersprache.“ Das

Programmiersprache.“ Das ging dann viral, als es unter „ Gefällt mir“ gepostet wurde.

Genau so, als könnte ich einfach eine Spezifikation schreiben, die dann dauerhaft gilt. Sie wäre etwas, das

dauerhaft gilt. Sie wäre etwas, das ich bearbeiten kann und den Agenten einfach dazu bringen könnte, sie nach und nach zu ändern. Als ich damit experimentierte, probierte ich es oft aus und bekam einfach schlechtere Ergebnisse, als wenn ich es von Hand codiert hätte. Und es wurde auch nicht

codiert hätte. Und es wurde auch nicht besser. Mir fiel auf, dass der Code

besser. Mir fiel auf, dass der Code jedes Mal schlechter wurde, wenn ich diese Schleife ausführte, um die Spezifikation zu ändern und die Änderung des Codes zu sehen. Man darf

sich den Code natürlich nicht ansehen, aber ich sah ihn mir an und er war Schrott. Und ich dachte mir: Wie soll

Schrott. Und ich dachte mir: Wie soll der Agent hier gute Leistungen erbringen? Wie soll das funktionieren?

erbringen? Wie soll das funktionieren?

Denn die Feedbackschleifen sind für den Agenten so wichtig. Wenn man eine schlechte Testreihe hat, erhält der Agent schlechte Signale davon, genau wie ein Mensch. Und ich dachte mir: Wie kann ich die Testreihe verbessern? Wie

sorge ich dafür, dass dieses Setup nicht jedes Mal Müll ausspuckt? Und

ich schlug einfach ein Buch auf, das bei mir im Regal stand und das, glaube ich, noch in Plastik eingewickelt war, als ich es das erste Mal herausnahm. Es

hieß „The Pragmatic Programmer“.

Alle hatten mir gesagt, ich solle es lesen. Alle sagten: „Das ist das

lesen. Alle sagten: „Das ist das beste Buch überhaupt. Man muss es einfach lesen.“ Und ich kaufte es,

einfach lesen.“ Und ich kaufte es, aber aus irgendeinem Grund habe ich es nicht gelesen. Ich schlug es auf und es

nicht gelesen. Ich schlug es auf und es enthielt ein ganzes Kapitel, einen ganzen Abschnitt über Software-Entropie. Und

Software-Entropie. Und Software-Entropie ist das Konzept, dass Dinge in einen ungeordneteren Zustand übergehen. Das ist wahrscheinlicher,

übergehen. Das ist wahrscheinlicher, als dass sie in einen geordneten Zustand übergehen. Und mir wurde klar:

Zustand übergehen. Und mir wurde klar: Software-Entropie ist unvermeidlich.

Was ich hier sehe, ist, dass Agenten Software-Entropie in einem höheren Tempo produzieren als je zuvor. Und ich

begann, mich tiefer in dieses Buch zu vertiefen. Und bei fast jeder Zeile,

vertiefen. Und bei fast jeder Zeile, die ich las, dachte ich: Wow, das fühlt sich an, als wäre es für die heutige Zeit geschrieben worden. Man

sollte sich das Buch unbedingt noch einmal genauer anschauen. Diese Ideen,

wie man seinen Scheinwerfern nicht davonläuft, immer innerhalb seiner Feedbackschleifen arbeitet, Programmierung durch Zufall, Traceabits , so viele clevere Ideen. Und mir wurde klar, dass dieses Buch schon seit 25 Jahren auf dem Markt ist, richtig? Das

war wahrscheinlich früher in den Agenten. Vielleicht sollte ich nur

Agenten. Vielleicht sollte ich nur einige dieser Konzepte erwähnen, insbesondere die wirklich pathetischen, wie zum Beispiel die Tracer-Kugeln, bei denen es darum geht, dass man immer sehr schnell Feedback zu seiner Arbeit erhalten sollte. Ich denke, die Idee

erhalten sollte. Ich denke, die Idee der Tracer-Kugel ist richtig. Man

hinterlässt sozusagen eine Tracer-Kugel, die eine Spur hinterlässt, und implementiert einen Pfad, der wie ein wichtiger Teil einer Software funktioniert, anstatt beispielsweise eine Datenbankschicht und die Anwendungsschicht und, ich weiß nicht, welche Schicht auch immer zu erstellen, sondern alle drei zu erstellen und sie dann

zusammenzuführen. Man erstellt einfach

zusammenzuführen. Man erstellt einfach nur einen Teil von jeder Schicht, aber sie sollten zusammenarbeiten. Das war

das Problem, das ich bei Agenten sah: Sie ließen sie eine Software erstellen , sogar mit Ralph-Schleifen, und sie erstellten die gesamte Datenbank und dann die gesamte Anwendungsschicht darüber. Dann erstellten sie die

darüber. Dann erstellten sie die gesamte React-Komponentenbibliothek.

Erst am Ende fingen sie an, die Dinge tatsächlich zusammenzufügen und Feedback zu erhalten, was sie taten.

Und es war verrückt, weil Dinge in der Datenbank sich auf das auswirken, was man im Frontend anzeigt. Man weiß nur dann wirklich, ob etwas Sinn ergibt, wenn man sieht, wie es diese Integrationsschichten durchläuft. Ein

Integrationsschichten durchläuft. Ein weiteres Konzept sind vertikale Schnitte. Anstelle dieser horizontalen

Schnitte. Anstelle dieser horizontalen Schnitte über diese verschiedenen bereitstellbaren Einheiten hinweg hat man einen vertikalen Schnitt, bei dem der Agent sofort Feedback zu seiner Aktion erhält und darauf aufbauen kann . Ich habe also angefangen, diese

. Ich habe also angefangen, diese Sätze in meinen Eingabeaufforderungen zu verwenden, wenn ich mit dem Agenten sprach, und mir ist aufgefallen, dass er mir diese Sätze zurücksagte. Er

wiederholte sie mir. Es sagte: „Okay, ich verwandle das in ein Trace-Bullet, weil das hier ein Trace-Bullet ist. Ich

mache das.“ Es verwendete die Wörter , die ich in seinen eigenen Argumentationsspuren verwendete. Das

Argumentationsspuren verwendete. Das ist also das, was ich ein Leitwort nenne, ein Lightvert, sagen wir mal, das ist eine Art ausgefallener literarischer Begriff, bei dem man den Agenten nur mit einer einfachen Phrase führt, die man ein paar Mal in der Fertigkeit oder der Eingabeaufforderung wiederholt, um sein Verhalten zu

ändern. Traceabits war also

ändern. Traceabits war also fantastisch. Und ich fing einfach an,

fantastisch. Und ich fing einfach an, mich in verschiedene Bücher zu vertiefen, alle Bücher, die ich finden konnte, um zu versuchen, sie nach Leitwörtern zu durchforsten. Ein

weiteres war John Asterouts Buch „ Philosophie des Softwaredesigns“, in dem ich tonnenweise großartiges Zeug wie „Deep Modules“ gefunden habe, was für mich ein riesiges Thema ist.

Es ist interessant zu überlegen, ob diese Agenten offensichtlich mit diesen Büchern trainiert wurden, die es immer noch als Druckversion gibt, und natürlich gibt es Argumente dafür, was sie mit diesen Büchern machen und was nicht. Aber wenn es sich um ihre

was nicht. Aber wenn es sich um ihre Trainingsdaten handelt und die Agenten, während sie trainiert werden, all diese verschiedenen Konzepte miteinander verbinden, wie können diese Leitwörter diese Konzepte aufrufen? Ich frage mich, ob das ein

aufrufen? Ich frage mich, ob das ein großer Unterschied zu einem Thema ist, in dem man mit einem Fachmann spricht und als Amateur versucht zu beschreiben , was man möchte, und ein Fachmann sagt ein Wort, das dies bewirkt, und ein Kollege versteht es. Und das ist Fachjargon, richtig? Und Fachjargon ist

Fachjargon, richtig? Und Fachjargon ist einerseits nicht sehr einladend, wenn man in ein Unternehmen eintritt und es dort Fachjargon gibt, aber wir verwenden ihn einfach, weil er die Dinge schneller und einfacher macht und es weniger Missverständnisse gibt.

Diese Idee hat mich definitiv dazu gebracht, denn es gibt diese Leitwörter natürlich bereits in den Agenten, richtig? Wie z. B.

Agenten, richtig? Wie z. B.

Ablaufverfolgungspunkte und so weiter.

Wie beschreibe ich meine Anwendung? Wie

beschreibe ich meinen Code? Wie bringe

ich den Agenten dazu, denn die Agenten sind einfach schrecklich wortreich, richtig? Vor allem Opus 5 ist aus

richtig? Vor allem Opus 5 ist aus irgendeinem Grund ein Modell, das die Leute dafür lieben, dass es zu wortreich ist. Und das ist es wirklich.

wortreich ist. Und das ist es wirklich.

Und ich dachte mir, wie kann ich es weniger wortreich machen? Wie können

wir anfangen, eine gemeinsame Sprache zwischen mir und dem Agenten zu sprechen? Wieder diese

sprechen? Wieder diese Kommunikationsbarriere. Und das führte

Kommunikationsbarriere. Und das führte mich zu DDD, Domain Driven, Domain Different Design. Eric Evans ist ein unglaubliches Buch, in dem er über allgegenwärtige Sprache spricht. Eine

Sprache, die sehr tief im Inneren des Agenten verankert ist. Er versteht sie sehr gut. Ich begann mit dem Gedanken

sehr gut. Ich begann mit dem Gedanken zu spielen, Grill Mate vielleicht ein wenig zu verändern, weil Grill Me eine sehr einfache Fähigkeit ist. Aber was

wäre, wenn wir, während wir über die Anwendung nachdenken, die wir erstellen wollen, auch eine Domänensprache erstellen würden? Was wäre, wenn wir

erstellen würden? Was wäre, wenn wir uns auch für die richtigen Begriffe entscheiden würden? Und das wurde zu

entscheiden würden? Und das wurde zu einer Fähigkeit namens Grill With Docs , die einen furchtbaren Namen hat, aber im Grunde diese Domänensprache erstellt, während man arbeitet. Und

wenn man den Agenten dazu bringt, die Domänensprache zu verwenden, ist der Unterschied wie Tag und Nacht, weil man plötzlich dieselbe Sprache spricht.

Sie können die Dinge, die Sie ändern möchten, mit viel weniger Worten beschreiben. Ich habe zum Beispiel an

beschreiben. Ich habe zum Beispiel an dieser App gearbeitet. Es gibt diese komplizierte Interaktion, bei der es Geisterlektionen und echte Lektionen gibt. Und was passiert, wenn Sie eine

gibt. Und was passiert, wenn Sie eine Geisterlektion, die sich in einem Geisterabschnitt innerhalb eines Geisterkurses befindet, in eine echte Lektion verwandeln? Das bedeutet, dass

Lektion verwandeln? Das bedeutet, dass der Geisterabschnitt real werden muss.

Der Geisterkurs muss real werden. Wie

erklären Sie das? Nun, das ist die Materialisierungskaskade, richtig?

Und Sie haben sich diese Begriffe mit dem Agenten ausgedacht, richtig?

Der Agent ist tatsächlich sehr gut darin, sich diese Begriffe auszudenken.

Daher verfüge ich über Fähigkeiten zur Domänenmodellierung. Wir sprechen

zur Domänenmodellierung. Wir sprechen über Fachjargon, aber eigentlich ist es die Domänensprache. Und wenn Sie das integrieren können, und zwar nicht nur in Ihre Sprechweise über die App, sondern auch in den App-Code selbst, dann haben Sie einen Eintopf am Laufen.

Das ist sehr, sehr spannend und bedeutet, dass der Agent viel einfacher in Ihrer Codebasis navigieren kann. Er

kann die Funktionen finden, die diese spezifische Domänenterminologie erwähnen, und das mit nur einem einfachen GP. Das ist einfach

einfachen GP. Das ist einfach großartig. Das ist also etwas, das ich

großartig. Das ist also etwas, das ich wirklich in jeden Teil meines Setups integriert habe, nämlich DDD. Aber das

ist so interessant, denn bei dem Versuch, diese Agenten effizienter arbeiten zu lassen oder Workflows zu erstellen, die einfach dazu führen, dass man bessere Software mit weniger Fehlern produzieren kann, und diese Dinge, reist man in der Zeit zurück und findet dieses Buch, das jetzt,

glaube ich, 20, 30, 40 Jahre alt ist.

Und man reist immer noch zurück und findet Perlen von uns. Ich bin sicher, irgendwann wirst du zum Mythical Man Month kommen.

Ja, das habe ich schon. Absolut. Das

ist jetzt mehr als 50 Jahre her, und man versucht, die richtigen Worte zu finden, um die Dinge zu beschreiben, was sehr interessant ist. Denn als ich mit Kent darüber sprach, wie sie früher mit Ward Cunningham programmierten, als sie das Konzept der eigentlich nur Domänen-Entwurfsmuster

entwickelten, hatten sie Aaris dabei und sie suchten nach dem richtigen Wort mit der richtigen Bedeutung, und sie hatten es auf ihrem Schreibtisch. Im

Moment fühlt es sich so an, als würden wir zu den Grundlagen zurückkehren, zu dem Wie, das sich die Leute gefragt haben, und hin und wieder schreiben die Leute es in Büchern auf, und es verbreitet sich sozusagen als Weisheit. Und jetzt sind wir wieder da,

Weisheit. Und jetzt sind wir wieder da, wo wir angefangen haben, nämlich wo wir versuchen, den Weisheitsteil zu vermitteln. Das ist verrückt, oder?

vermitteln. Das ist verrückt, oder?

Weil sich KI so sehr von Menschen unterscheidet, muss man sie optimieren.

Stellen Sie sich im Grunde einen Menschen vor, der jeden Morgen aufwacht und sich nicht erinnern kann, wer er ist, richtig? Der Typ von Momento,

ist, richtig? Der Typ von Momento, wissen Sie? Das ist Momento-gesteuerte

wissen Sie? Das ist Momento-gesteuerte Entwicklung, richtig? Wir versuchen,

Entwicklung, richtig? Wir versuchen, unsere Codebasen für Neueinsteiger zu optimieren. Wir versuchen also, die

optimieren. Wir versuchen also, die gesündeste Codebasis zu haben, die wir je hatten, denn wenn ein Mensch mit einer schlechten Codebasis umgehen kann , entwickelt er einfach ein Gedächtnis . Er schlägt einfach immer wieder

. Er schlägt einfach immer wieder seinen Kopf gegen die Wand, bis er es geschafft hat. Aber ein Agent kann das

geschafft hat. Aber ein Agent kann das nicht. Er fängt bei jeder einzelnen

nicht. Er fängt bei jeder einzelnen Sitzung von vorne an. Daher muss man seine Codebasis für diese Person optimieren. Das führt einen auf

optimieren. Das führt einen auf wirklich interessante Wege. Und es

stellt sich heraus, dass die Software-Grundlagen besagen, dass wir das die ganze Zeit versucht haben, richtig? Ich bin ganz wie Eric Evans.

richtig? Ich bin ganz wie Eric Evans.

Ich bin ganz wie Software-Grundlagen.

Wir ändern die Regeln ein wenig, aber vielleicht betonen wir nur Regeln, von denen wir wussten, dass wir sie befolgen sollten, es aber vielleicht nicht getan haben. Und das finde ich wirklich faszinierend und es macht auf jeden Fall viel Spaß. Okay, ich denke, es ist leicht, diesem Gedankengang zu

folgen, warum Grundlagen wichtig sind.

Aber welche Grundlagen? Und wenn ich ein Ingenieur bin, insbesondere jemand, der bisher nur mit konzentriertem Coden gearbeitet hat, wie gehe ich dann vor, um die wichtigen Grundlagen zu finden und mich wieder darauf zu konzentrieren ? Was hat sich für Sie bewährt? Das

? Was hat sich für Sie bewährt? Das

ist eine wirklich schwere Frage, nicht wahr? Sie ist deswegen so schwer zu

wahr? Sie ist deswegen so schwer zu erlernen, weil strategische Programmierung schon immer sehr schwer war. Der Grund dafür ist, dass die

war. Der Grund dafür ist, dass die Feedbackschleife sehr lang ist. Man

findet oft Leute, die nach sechs Monaten ihren Job kündigen und ihre strategischen Fehler nie einholen.

Vielleicht dauert es neun Monate, bis sich ein strategischer Fehler bei einem bemerkbar macht. Ich stelle mir

bemerkbar macht. Ich stelle mir strategisches Lernen und strategische Programmierung so vor, als hätte man ein riesiges Mischpult vor sich, mit vielen verschiedenen Schiebereglern.

Einer dieser Schieberegler ist beispielsweise die Anzahl der bereitstellbaren Einheiten. Erhöhen

bereitstellbaren Einheiten. Erhöhen Sie die Anzahl, erhalten Sie mehr Microservices. Verringern Sie die

Microservices. Verringern Sie die Anzahl, erhalten Sie einen Monolithen.

Wie trifft man diese Entscheidung? Wo

platziert man diesen Schieberegler?

Weil es so ähnlich ist wie beim Mastering von etwas, beim Abmischen von Musik, aber man merkt erst nach neun Monaten, was falsch ist, richtig? Bis

die Fehler kommen und einen einholen.

Ich denke, das Einzige, was diese Feedbackschleife beschleunigen kann, ist, schneller zu werden. Dank KI kann man jetzt schneller werden, richtig?

Und so werden sich Ihre strategischen Fehler schneller einholen. Sie werden

sich schneller einholen, weil die KI einfach so viel Code produzieren kann.

Sie müssen sich also darüber im Klaren sein, dass Ihr Code die Umgebung ist, in der der Agent agiert, und Sie sollten immer darüber nachdenken, diese Umgebung zu verbessern und darüber, wie Sie es besser machen können. Und das erfordert natürlich

können. Und das erfordert natürlich ein wenig taktisches Wissen, richtig?

Sie müssen verstehen, was Code ist, wie er zusammenpasst, welche Speicherbeschränkungen es gibt und all diese Dinge. Aber um besser in der

diese Dinge. Aber um besser in der strategischen Programmierung zu werden, müssen Sie einfach immer auf dieser Ebene denken. Und ich würde sagen,

Ebene denken. Und ich würde sagen, dass Sie auch diese Bücher lesen sollten, denn allein die Sprache zu haben, um das zu erklären, und den Unterschied zwischen der Anwendung strategischer Techniken zu verstehen und nicht, ist das Ganze. Ich meine,

bis zu PreAI, also für leitende Entwickler oder leitende Ingenieure, angestellte Ingenieure, waren das die Leute, bei denen man oft keinen leitenden Ingenieur mit weniger als fünf Jahren Erfahrung sah, weil man das normalerweise braucht, selbst in einem schnelllebigen Umfeld. Man

braucht so viel Zeit, um Feedback zu erhalten, Fehler zu machen und seine eigenen Fehler zu machen. Und wenn

Leute dann angestellte Ingenieure wurden, oft mit mehr als 10 Jahren Erfahrung, hatten manche schon früher solche Leute, aber oft hatten sie nur einen Totenkopf an sich und es passierte, dass jemand ein Projekt startete, sie nahmen einfach eine Änderung vor, ohne zu wissen, warum, und sie dachten sich: „Vertrau mir,

damit vermeiden wir Katastrophen und Produktion oder Bereitschaftsdienste oder oder oder was auch immer.“ Aber

all das entstand durch gelebte Erfahrung. Jetzt beschleunigt KI die

Erfahrung. Jetzt beschleunigt KI die Dinge. Sie erleichtert auch die

Dinge. Sie erleichtert auch die Behebung von Fehlern. Ich frage mich, wie sich das ändern könnte. Ich kann

mir vorstellen, dass es die Erfahrung einfach beschleunigen könnte. In einem

Jahr können manche Leute oder Teams mehr Projekte ausliefern als in vier Jahren. Das entspricht in etwa der

Jahren. Das entspricht in etwa der Anzahl der Projekte, die sie in den letzten drei oder vier Jahren abgeschlossen haben. Man sammelt also

abgeschlossen haben. Man sammelt also viel mehr Erfahrung. Ich frage mich jedoch, ob die Fehler, die man macht, nicht manchmal so schwerwiegend sind, weil man sie schnell beheben kann. Und

ich frage mich, ob das Lernen nicht so stark ausgeprägt ist. Wie bei einigen dieser Kampfnarben oder Kriegsgeschichten handelt es sich um wirklich schlimme Ausfälle. Wir haben

viel Geld verloren, weil uns die Wirksamkeit eines Elements fehlte.

Jetzt weißt du natürlich, was die Wirksamkeit eines Elements bedeutet.

Das ist kein einfaches Konzept, aber es ist wichtig, wenn du dadurch Schaden erlitten hast. Wenn du jetzt ein

erlitten hast. Wenn du jetzt ein Unternehmen bist und den nächsten Junior-Entwickler ausbilden möchtest, weil dieses strategische Programmierwissen jetzt so wertvoll ist , weil du es mit viel mehr Hebelwirkung einsetzen kannst, würdest du dann

wirklich jemanden ohne dieses Wissen einstellen? Warum solltest du das tun?

einstellen? Warum solltest du das tun?

Wie ich schon sagte, ich habe neulich ein Interview mit Onkel Bob geführt und seine Empfehlung war: Okay, stell einfach jemanden ein und behandle ihn eine Zeit lang wie einen Agenten.

Delegiere einfach Aufgaben an ihn.

Halte ihn eine Weile in dieser taktischen Denkweise, bis seine Fehler auftauchen. Aber das ist eine riesige

auftauchen. Aber das ist eine riesige Geldverschwendung für die Leute, oder?

So wie bei der Softwareentwicklung, wenn die taktischen Dinge in vielen Ländern unter den Mindestlohn gefallen sind. Ich weiß nicht, ob das die

sind. Ich weiß nicht, ob das die Antwort ist. Ich weiß nur, dass die

Antwort ist. Ich weiß nur, dass die strategischen Dinge, das Verständnis des Codes, das Verständnis der langfristigen Perspektive, wertvoller geworden sind als je zuvor, oder? Denn

man kann einfach so viel daraus ziehen.

Ich habe sie nach interessanten Dingen gefragt, die sie gerne von dir wissen würden, und das hängt stark damit zusammen. Diese Person fragt, wie man

zusammen. Diese Person fragt, wie man Stakeholder, die nicht aus dem Bereich der Entwicklung stammen, davon überzeugt, dass Investitionen in Softwaregrundlagen wichtig sind, auch wenn sie auf dem Papier die Geschwindigkeit und Produktivität verringern könnten. Ich denke, die

verringern könnten. Ich denke, die Frage hier ist, ob manche Leute sagen: „Schau mal, wir wollen die Grundlagen richtig machen, was bedeutet, dass wir es etwas langsamer angehen wollen, über ihre Entscheidungen nachdenken und uns vielleicht auch weiterbilden, anstatt es einfach aufzugeben.“ Ich

meine, man hätte die gleiche Frage auch vor 10 Jahren stellen können, und sie wäre immer noch relevant gewesen.

Verstehst du, was ich meine?

Abgesehen davon, dass wir die fünf wichtigsten Elemente genannt hätten, nach denen wir gefragt hätten, wie man die technische Tiefe ausreizt. Genau,

und es ist doch dasselbe, oder?

Wir haben die gleiche Diskussion geführt, was für mich sehr befriedigend ist, denn man braucht ja eine Art von Messgröße, um das herauszufinden. Und es ist etwas

herauszufinden. Und es ist etwas einfacher, das herauszufinden, weil man mit Agenten schneller vorankommt. Der

erste Schritt dazu ist, in seinem Unternehmen Transparenz über jeden einzelnen Agenten zu schaffen, darüber , was er tut und wie hoch seine Erfolgs -und Misserfolgsrate ist. Das hatten

wir bei Entwicklern noch nie. Das ist

für Entwickler irgendwie invasiv.

Ja. Aber für Agenten ist es eigentlich okay. Ist doch

okay. Ist doch okay, oder? Wir bezahlen ja für diesen

okay, oder? Wir bezahlen ja für diesen Service, oder? Wir müssen verstehen,

Service, oder? Wir müssen verstehen, wie gut wir ihn optimieren. Der erste

Schritt dazu ist, eine Art Überwachungs-und Kontrollsystem für Ihren Agenten und die gesamte Organisation zu schaffen, um herauszufinden, was funktioniert und was nicht. Und Sie brauchen

was nicht. Und Sie brauchen wahrscheinlich jemanden, dessen Job es ist oder zu dessen Job es gehört, sich diese Daten anzusehen und herauszufinden, was wir tun. Vielleicht

haben einige Repositorys in Ihrer Organisation bessere Erfolgsraten als andere. Und so nehmen Sie die Lektionen

andere. Und so nehmen Sie die Lektionen , die sich darin befinden, und geben sie weiter. Ich denke auch, dass die

sie weiter. Ich denke auch, dass die meisten Organisationen sich auf gemeinsame Fähigkeiten stützen sollten. Sie brauchen einen gemeinsamen

sollten. Sie brauchen einen gemeinsamen Software-Workflow-Prozess, damit jeder dazu beitragen kann. Damit Sie mit Dingen experimentieren können. Sie

können Dinge AB-Tests unterziehen. Sie

können ein Team eine Aufgabe erledigen lassen und ein anderes Team eine andere Aufgabe, und dann fragen Sie sie im Nachhinein. Alle, die in einer

Nachhinein. Alle, die in einer Organisation mit Agenten arbeiten, brauchen diese experimentelle Denkweise . Man muss sich überlegen, wie man aus

. Man muss sich überlegen, wie man aus den ausgegebenen Token mehr herausholen kann. Der erste Schritt dazu ist die

kann. Der erste Schritt dazu ist die Beobachtbarkeit.

Ja. Ich frage mich auch, ob es eine menschliche Feedbackschleife gibt. Ich

meine, man muss einfach mit seinen Kollegen sprechen. Wir haben Rituale,

Kollegen sprechen. Wir haben Rituale, Teambesprechungen, unternehmensweite Meetings aus einem bestimmten Grund.

Wir teilen zum Beispiel mit: „Das hat bei mir funktioniert, hier hat es nicht funktioniert, das lerne ich daraus.“

Am Ende sind wir dafür verantwortlich, die Regeln aufzustellen, zu entscheiden , wie und wo wir sie anwenden, wo nicht . Und wo wir sagen: „Nein, das

. Und wo wir sagen: „Nein, das müssen Menschen zu 100%übernehmen.

Wir beziehen nicht einmal KI mit ein“ , was, wie gesagt, überall anders sein wird.

Und es ist nicht nur so, dass man bei vielen dieser Dinge jetzt keine menschlichen Instanzen mehr einbeziehen muss. Man muss nicht wirklich viel Zeit

muss. Man muss nicht wirklich viel Zeit delegieren, um eine bessere Codebasis aufzubauen. Ich habe Schleifen, die im

aufzubauen. Ich habe Schleifen, die im Grunde jeden Morgen meine Fähigkeit zur Verbesserung der Codebasisarchitektur ausführen und mir einen Vorschlag für etwas geben, das ich an der Codebasis verbessern könnte . Und dann kann ich einfach auf einen

. Und dann kann ich einfach auf einen Button drücken. Ich kann sagen: „

Button drücken. Ich kann sagen: „ Okay, wandle das in Tickets um und lass uns das ausliefern.“ Das ist ziemlich einfach zu bewerkstelligen und lässt sich leicht mit anderen Arbeiten zusammenführen. Ich weiß nicht, ob

zusammenführen. Ich weiß nicht, ob man etwa 20%seiner Zeit damit verbringen sollte, sich auf die Fabrik zu konzentrieren, die die Software erstellt, und auch auf die Software selbst. Ich denke, das ist eine enorme

selbst. Ich denke, das ist eine enorme Investition in die zukünftige Leistungsfähigkeit, nicht nur in die Leistungsfähigkeit bei der Arbeit, sondern auch in die Leistungsfähigkeit und das Verständnis Ihres Teams sowie in die Verbesserung dieser Fähigkeiten . Aber natürlich brauchst du

. Aber natürlich brauchst du Ergebnisse und du musst diese Arbeit möglicherweise eine Weile verstecken, bevor du sie tatsächlich enthüllst.

Das ist, was wir die ganze Zeit gut gemacht haben, und das hängt von deiner Umgebung ab, aber ja, und niemand wird sauer auf dich sein, wenn du zurückkommst und sagst: „Oh, übrigens, Leute, das habe ich auch gemacht.“

gemacht.“ Ja, genau.

Ähm, ich wollte dich fragen, wie du Tools speziell einsetzt. Erstens:

Coding Agents, lokal oder in der Cloud.

Und du hast kürzlich einen ziemlich provokanten Tweet gepostet, den ich dich zitiere. Ich verlasse mein lokales

dich zitiere. Ich verlasse mein lokales Entwicklungs-Setup. Das ergibt für

Entwicklungs-Setup. Das ergibt für mich überhaupt keinen Sinn.

Viele Leute fragen mich, wie du deine Fähigkeiten kollaborativ einbringst.

Wie führst du eine gemeinsame Diskussionsrunde durch? Und die Antwort

Diskussionsrunde durch? Und die Antwort darauf ist, dass du mehr brauchst als nur dein Terminal und dich selbst, richtig? Wir befinden uns jetzt in

richtig? Wir befinden uns jetzt in einer Phase, in der jeder Entwickler etwa 100 Terminals zur Verfügung hat.

Und das klingt verrückt. Es fühlt

sich an, als bräuchte man diese 100 Terminals für das gesamte Unternehmen.

Man muss in der Lage sein, in einem gemeinsam genutzten Bereich zusammenzuarbeiten. Man muss jemanden

zusammenzuarbeiten. Man muss jemanden fragen können, jemanden zu seiner Gesprächsrunde hinzufügen und sagen können: „Okay, mach das.“ Daher

ist es für mich sehr sinnvoll, viele dieser Interaktionen an dem Ort zu haben, an dem man bereits arbeitet, in Slack, Discord, Teams oder Linear. Und

das ist wirklich der Grund, warum ich das Thema erweitern möchte. Ich

arbeite nicht unbedingt in einem Team, aber ich weiß, wie wertvoll das ist.

Und ich habe versucht, das in meine Abläufe zu integrieren. Hier im Zug chatte ich in Discord mit meiner inneren Gruppe, entwickle Dinge für meinen Kurs oder behebe Fehler, auf die die Studenten stoßen. Daher sehe ich jetzt weniger Wert darin, Dinge nur lokal zu erledigen, wenn ich dieses

Setup habe, auf das ich Änderungen portieren und den Entwicklungsserver verfolgen kann. Und ich weiß nicht, es

verfolgen kann. Und ich weiß nicht, es fühlt sich für mich einfach viel sinnvoller an, als einen sehr, sehr teuren Laptop zu haben, der so etwas kann. Es fühlt sich wie verschwendete

kann. Es fühlt sich wie verschwendete Rechenzeit an. Und vor allem, weil ich

Rechenzeit an. Und vor allem, weil ich auf dieser Remote-Box Zeitpläne einrichten kann. Ich weiß, dass die

einrichten kann. Ich weiß, dass die Box immer eingeschaltet sein wird. Ich

habe zum Beispiel ein morgendliches Standup mit meinem Agenten, bei dem ich sie bekomme. Sie plant meinen Tag für

sie bekomme. Sie plant meinen Tag für mich und sie versteht alle meine Discord-Chats und so weiter. Ja, diese

Remote-Lösung fühlt sich für mich einfach viel sinnvoller an. Und das

Einzige, was ich jetzt lokal mache, ist das Debuggen von Problemen mit dem Remote-Bot. Ja, ich frage mich, ob es

Remote-Bot. Ja, ich frage mich, ob es eine Frage ist, wie einfach es ist, einige ziemlich komplizierte lokale Setups in der Cloud zu replizieren, aber sobald das möglich wird, ist es wahrscheinlich eine Frage des Wann, nicht des Ob.

Ja. Und wenn überhaupt, dann haben die Leute ein ähnliches Problem mit lokalen Setups, mit tausend Git-Worktrees, die ihre Festplatte zuspammen, und fragen sich: „Wie erstelle ich einen Worktree, der fünf Docker-Container ausführen muss, um mein lokales Dev-Setup zu erhalten?“

Nun, das ist in der Cloud oft etwas einfacher, da man die benötigten Ressourcen einfach bei Bedarf bereitstellen kann.

Übrigens sehen wir, dass Unternehmen wie RAMP, Stripe und Uber über Plattformteams verfügen, die es schaffen, das gesamte Setup lokaler Entwickler in die Cloud auf einem Cloud-Rechner zu stellen, den man dann über Slack oder eine Website aufrufen kann. Sie sehen, dass die Leute diese

kann. Sie sehen, dass die Leute diese Agenten viel häufiger verwenden, außer für Frontend-Arbeiten, bei denen man immer noch diese Feedbackschleife haben möchte. Es gibt

ein paar Ausnahmen, bei denen man wirklich ein lokales Dev-Setup haben möchte, um Latenzen oder Ähnliches zu vermeiden. Aber sie sehen auch, dass

vermeiden. Aber sie sehen auch, dass etwa 70 bis 80%der Entwickler freiwillig auf die Cloud umsteigen.

Ja. Ich meine, ich denke, man kann einfach durchtunneln und einfach den ausführenden Dev-Server abrufen, und man lässt diesen dann einfach auf dem lokalen Rechner erscheinen. Wie

unterscheidet sich das davon, ihn lokal zu haben?

Okay.

Ich weiß es nicht. Ich glaube, ich habe damit noch nicht experimentiert, aber damals habe ich darüber gesprochen und gesagt: „Oh, vielleicht ist das Frontend eine gute Ausnahme.“ Das war die unmittelbare

Ausnahme.“ Das war die unmittelbare Antwort, die ich bekam, und für mich leuchtet sie ein.

Ich möchte dich bezüglich der Planung und den Anforderungen fragen. Du bist

ein großer Verfechter von Gil Me und der Planung im Voraus oder davon, den Plan zu erstellen und dann den Agenten arbeiten zu lassen. Aber hier ist der advocatus diaboli. Agenten sind so

advocatus diaboli. Agenten sind so schnell bei der Implementierung. Man

könnte sogar mehrere, wenige Agenten haben, die unterschiedliche Architekturen implementieren. Wie sieht

Architekturen implementieren. Wie sieht es mit dem Ansatz aus, dass sie schnell bei der Implementierung sind? Daher

muss ich möglicherweise nicht so viel im Voraus planen. Ich kann einfach den Kurs korrigieren, während ich arbeite.

Es hängt davon ab, welche Art von Arbeit du machst, richtig? Weil ich

glaube, dass man Grill Me nicht für alles verwenden sollte. Im Wesentlichen

benötigt man Grill Me für Arbeiten, bei denen die tatsächliche Ausführung sehr umfangreich ist und es schwer ist, sie rückgängig zu machen. Wenn man

denkt, okay, dieses Feature, vielleicht ist es eine ganz neue Seite, vielleicht ist es ein großes Feature, dieser Code , dann denkt man, wenn der Agent es falsch macht, dann wird der falsche Code in seinem Kontextfenster sein und alles beeinflussen, was danach kommt.

Und tatsächlich wird es aufwendig, zurückzugehen und das Zeug nachträglich zu bearbeiten und die Ausrichtung nachträglich vorzunehmen.

In diesen Fällen ist es sinnvoll, zuerst die Ausrichtung vorzunehmen, um alle kniffligen Fragen zu beantworten, wie z. B. dein JSON-Cookie oder was

wie z. B. dein JSON-Cookie oder was auch immer, dein Authentifizierungstoken, und es dann zu tun. Aber in einigen Fällen, wie bei

tun. Aber in einigen Fällen, wie bei einfachen Fehlerbehebungen oder einfach nur, um diese Schaltfläche drei Pixel nach links zu verschieben, ist es offensichtlich, dass man vorher keine Ausrichtung vornehmen muss. Man kann

die Sache sehen, wenn es sich nur um eine Änderung von fünf Zeilen oder so handelt. Man kann sie nachträglich

handelt. Man kann sie nachträglich ausrichten. Und deswegen denke ich mir

ausrichten. Und deswegen denke ich mir das so: Wo immer du kannst, solltest du so weit wie möglich nach rechts verschieben. Und tatsächlich gibt es

verschieben. Und tatsächlich gibt es bestimmte Funktionen, die ich in meinem Video-Editor habe. Ich habe eine

Video-Editor habe. Ich habe eine Schaltfläche, mit der ich Feedback senden kann. Und ich verwende diese

senden kann. Und ich verwende diese Funktion oft für sehr einfache Aufgaben, bei denen ich das Feedback sende. Es wird in ein GitHub-Issue

sende. Es wird in ein GitHub-Issue übernommen. Das wird sofort von einem

übernommen. Das wird sofort von einem Implementierungsagenten übernommen und sofort bearbeitet. Dann kommt ein

sofort bearbeitet. Dann kommt ein Code-Review-Agent und überprüft den Code. Am Ende sehe ich dann, dass das

Code. Am Ende sehe ich dann, dass das Problem behoben wird, und kann meine Ausrichtung vornehmen. Und das hat

Ausrichtung vornehmen. Und das hat wirklich gut funktioniert bei Dingen, die sehr einfach zu spezifizieren sind, Dinge, die ich nicht im Detail besprechen muss. Das sind also die

besprechen muss. Das sind also die Möglichkeiten, die man hat. Ist es

eine so kleine Sache, dass ich sie im Nachhinein anpassen kann? Dann verwende

nicht „Grill me“. Passt es in eine einzelne Sitzung? Dann verwende „

einzelne Sitzung? Dann verwende „ Grill me“. Umfasst es mehrere

Grill me“. Umfasst es mehrere Sitzungen? Muss ich das gesamte Ding

Sitzungen? Muss ich das gesamte Ding ausrichten, dann verwende ich „ Wayfinder“. Interessant, denn das

Wayfinder“. Interessant, denn das unterscheidet sich nicht so sehr von dem, was einige Technologieunternehmen vor Jahren getan haben, nämlich im PRD , dem Produktreferenzdokument. Wenn es

etwas Triviales ist, dann baue es einfach. Wenn es das Team benötigt,

einfach. Wenn es das Team benötigt, also auf Teamebene, dann schreibe ein PRD, schicke es an das Team, setze es vielleicht in CC bei einigen anderen Teams, aber das ist kein Hindernis.

Wenn es etwas Größeres ist, dann ist es ein Hindernis, denn wir müssen auf Feedback warten. Im Grunde genommen

Feedback warten. Im Grunde genommen würden wir sagen: Wenn es sich um ein Ein-Monats-Projekt handelt, dann sollten wir zwei Tage damit verbringen, es zu planen. Es ist nicht schlecht, ein oder zwei Tage damit zu verbringen, es zu planen, weil wir so Zeit sparen.

Aber wenn es ein Ein-Tages-Projekt ist, dann vergiss es. Wenn es ein Ein-Jahres-Projekt ist, was machen wir dann? Sollte es kleiner sein? Auf

dann? Sollte es kleiner sein? Auf

jeden Fall. Ich möchte anmerken, dass es ein wenig Kritik von außerhalb gibt , wenn du das sagst, nämlich: „ Klingt das nicht nach Wasserfallmodell, was wir hier machen?“ Wenn ich über Wayfinder spreche und wenn ich irgendeine Art von Spezifikation

erstelle, erstelle ich im Vorfeld intensiv Prototypen. Das kommt immer

intensiv Prototypen. Das kommt immer wieder vor. Es ist, als ob wir in die

wieder vor. Es ist, als ob wir in die 70 er-Jahre zurückgehen. Aber Agenten

geben einem die Möglichkeit, einfach nur Mist zu produzieren, richtig? Und

manchmal kann man das zu seinem Vorteil nutzen, denn ein Prototyp hilft einem, ein Gefühl dafür zu bekommen, wie es aussehen soll. Man kann drei oder vier

aussehen soll. Man kann drei oder vier verschiedene Versionen erstellen und einfach die beste auswählen, sie iterieren und einfach immer weiter produzieren. Das kann ein wirklich

produzieren. Das kann ein wirklich leistungsstarkes Setup sein, das wir vorher nicht hatten, richtig?

Prototypen zu erstellen war immer teuer . Jetzt ist es so günstig wie noch nie

. Jetzt ist es so günstig wie noch nie . Und das ist für mich ein

. Und das ist für mich ein wesentlicher Bestandteil des Schreibens von Spezifikationen: die tatsächliche Erstellung dieser Prototypen.

Ja. Aber auch, was die Kritik am Wasserfallmodell betrifft, denke ich, dass Grady Buch mir das auch gesagt haben könnte: Vergesst nicht, wir sollten das Wasserfallmodell nicht kritisieren, weil zum Beispiel viele große Technologieunternehmen wie Amazon, Microsoft, Google, Meta und

andere eine Art Mini-Wasserfallmodell anwenden. Vor der Einführung der KI

anwenden. Vor der Einführung der KI haben sie ein Mini-Wasserfallmodell angewendet, nach dem Motto: Lasst uns einen Plan erstellen, uns darauf einigen, ihn entwickeln und ausliefern.

Und das alles dauert etwa zwei Wochen, ein Monat, zwei Monate oder drei Monate . Drei Monate sind schon extrem. Aber

. Drei Monate sind schon extrem. Aber

Crady Buch sagte, dass dies nie das Problem beim Wasserfallmodell war. Das

Problem beim Wasserfallmodell war, dass die Planung buchstäblich ein Jahr dauerte, also ein Jahr, und dann die Umsetzung drei Jahre. Und als es vier Jahre später fertig war, war es nicht das, was wir wollten. Und das war das Problem. Er sagte, das Problem sei

Problem. Er sagte, das Problem sei nicht, dass es sich bei einem Wasserfallmodell um ein ein-oder zweimonatiges oder einwöchiges Projekt handele. Das Problem war immer, dass

handele. Das Problem war immer, dass wir hier über Jahre sprechen und er sagte, dass die Branche seit Jahrzehnten keine Wasserfälle mehr gesehen hat. Und deshalb verwenden wir

gesehen hat. Und deshalb verwenden wir hier diesen Begriff, der ein bisschen so ist, als würden wir Wasserfälle kritisieren oder viele davon wurden in diesem Zusammenhang kritisiert. Das ist

eigentlich nicht unbedingt etwas Schlechtes. Verstehen Sie, was ich

Schlechtes. Verstehen Sie, was ich meine?

Eine Vogelscheuche, auf die wir einprügeln oder so etwas.

Ja. Es ist eine Piñata, die nicht mehr existiert. Sie mag in einigen

existiert. Sie mag in einigen verrückten Unternehmensprojekten existieren, von denen niemand in regulierten Branchen etwas weiß. Aber

ich habe das Gefühl, dass sie selbst dort wahrscheinlich aus der Mode gekommen ist.

Ja. Ich denke, es ist, als würden wir auf eine Piñata einschlagen. Ich denke

, es ist tatsächlich nützlich, sie dort oben zu haben. Sie ist wie ein nützlicher Geist oder eine nützliche Warnung, nicht wahr? Denn was am besten zum künstlichen Aufbau passt, ist Agilität, nicht wahr? Da die

Arbeitskosten so stark gesunken sind, können wir sehr, sehr schnell Änderungen vornehmen. Ich weiß nicht,

Änderungen vornehmen. Ich weiß nicht, ob das für mich die richtige Metapher ist. Ich habe also nichts dagegen,

ist. Ich habe also nichts dagegen, Waterfall zu hassen, auch wenn es niemand mehr wirklich macht.

Nun, eine andere Sache, die einfach aus der Mode gekommen ist. Wir haben es nicht gehasst, ist die testgetriebene Entwicklung, TDD. Wie stehst du dazu,

Entwicklung, TDD. Wie stehst du dazu, sie für die Agenda zu verwenden? Nun,

als ich mit Ken Beck gesprochen habe, haben wir darüber gesprochen, dass dies aus vielen Gründen eine großartige Lösung sein könnte, aber ich sehe immer noch nicht, dass die Leute es wirklich nutzen. Ich sehe,

dass Leute Tests schreiben. Die Agenten

schreiben auch gerne nachträglich Tests, so arbeiten die meisten Leute, aber ich glaube, du bist ein Verfechter von TDD, richtig?

Ja. Ich habe also eine TDD-Fähigkeit, die ich empfehlen würde, und das ist ziemlich aktuell, weil ich darüber nachgedacht habe, aber noch nicht wirklich darüber gepostet habe. TDD

optimiert für einen sehr kleinen Arbeitsspeicher, richtig? Sie schreiben

Arbeitsspeicher, richtig? Sie schreiben einen Test, der fehlschlagen soll. Das

bedeutet, dass der Test fehlschlägt, selbst wenn Sie abgelenkt werden, einen Kaffee trinken oder einen langen Spaziergang machen. Wenn Sie

Spaziergang machen. Wenn Sie zurückkommen, wird der Test immer noch fehlschlagen. So werden Sie daran

fehlschlagen. So werden Sie daran erinnert, an welcher Stelle der Implementierung Sie sich befinden, und zum nächsten Schritt geführt. Agenten

benötigen das nicht. Das Tolle an Agenten ist, dass sie ein viel größeres Arbeitsgedächtnis als Menschen haben. Sie können

Menschen haben. Sie können tatsächlich viel mehr im Kopf behalten als Menschen derzeit, was sehr nützlich ist. Aber sie haben kein

nützlich ist. Aber sie haben kein unendliches Arbeitsgedächtnis, und TDD zielt meiner Meinung nach auf das falsche Problem ab. Was Agenten aber wirklich brauchen, sind Feedbackschleifen. Sie müssen sehen,

Feedbackschleifen. Sie müssen sehen, was sie tun und wie dies mit der Umgebung des Codes interagiert. Sie

müssen es ständig überprüfen, und ein Agent, der dies tut, muss zuerst den Fehler erstellen. Außerdem ist es für einen Agenten sehr schwer, das zu umgehen. Sie zwingen den Agenten also

umgehen. Sie zwingen den Agenten also nicht nur dazu, seine eigenen Feedbackschleifen aufzubauen, sondern der Agent liefert Ihnen auch den Beweis , dass die Sache tatsächlich funktioniert. Und selbst wenn ich TDD

funktioniert. Und selbst wenn ich TDD nicht direkt verwende, wo er, wissen Sie, zuerst den fehlgeschlagenen Test schreibt, ihn dann behebt und dann umgestaltet, sage ich oft: „Liefern Sie den Beweis, dass Ihre Änderung das tut, was sie tun soll.“ Geben Sie mir

einen TDD-Beweis, richtig? Dass sie

ohne diese Änderung fehlschlagen würde. Und das war wirklich gut, um im

würde. Und das war wirklich gut, um im Wesentlichen die Feedbackschleifen zu verbessern, denn ein weiterer Fehler bei TDD, den Agenten machen, ist, dass sie oft einfach nur Misttests schreiben . Sie schreiben oft nur besonders

. Sie schreiben oft nur besonders toologische Tests, bei denen der Test nur die Implementierung selbst bestätigt. Es ist einfach wie ein

bestätigt. Es ist einfach wie ein Duplikat davon. Wissen Sie, er schreibt

Duplikat davon. Wissen Sie, er schreibt eine Konstante und sagt dann, dass diese Konstante diesen Wert haben soll.

Ich meine, welchen Sinn hat dieser Test ? Er bestätigt nur die Implementierung

? Er bestätigt nur die Implementierung . Also, ja, ich habe eine gemischte

. Also, ja, ich habe eine gemischte Beziehung zu TDD. Ich empfehle es trotzdem, einfach, weil es einem viel mehr Vertrauen in das gibt, was man aus menschlicher Sicht entwickelt. Aber ja,

ich fange an, die Gegenargumente zu verstehen. Reden wir

verstehen. Reden wir über technische Tiefe. Jared

Freriedman von Y Cominator hat einen Tweet geschrieben, den ich zitiere.

Früher war technische Tiefe etwas, mit dem man einfach leben musste, wenn man eine ausreichend große Codebasis hatte . Das ist nicht mehr so. Und darauf

. Das ist nicht mehr so. Und darauf

hast du geantwortet: „Ja, jetzt kann man damit sogar in einer winzigen Codebasis leben.“

Codebasis leben.“ Das ist gut. Ich habe es tatsächlich laut vorgelesen. Du hast den Sinn

laut vorgelesen. Du hast den Sinn dieser Aussage wirklich gut wiedergegeben. Ja, es ist einfach für

wiedergegeben. Ja, es ist einfach für Agenten, Unsinn zu produzieren, nicht wahr? Anders als selbst wirklich

wahr? Anders als selbst wirklich intelligente, mächtige Agenten, weil sie nicht strategisch denken können, konzentrieren sie sich nur auf das, was sie gerade tun. Es ist sehr einfach für sie, technische Schulden zu produzieren. Was sind technische

produzieren. Was sind technische Schulden? Technische Schulden sind

Schulden? Technische Schulden sind alles, was es im Laufe der Zeit schwieriger macht, Änderungen an der Codebasis vorzunehmen. Eine gute

Codebasis vorzunehmen. Eine gute Codebasis ist eine, die sich leicht ändern lässt. Eine, an der man leicht

ändern lässt. Eine, an der man leicht Änderungen vornehmen kann, die nicht zu kaskadierenden Fehlern führen, richtig? Eine Codebasis mit einer

richtig? Eine Codebasis mit einer soliden Testabdeckung und einer guten Testsuite ist also eine Codebasis, die sich leicht ändern lässt.

Ja.

Aber es ist so einfach für Agenten, eine Codebasis mit der Zeit einfach zu verschlechtern.

Ja. Und das ist ein wirklich schwieriges Problem, und man braucht eine strategische Denkweise, um darüber nachzudenken, denn ich habe festgestellt, dass eine Sache wirklich gut funktioniert: die automatisierte Überprüfung. Man hat also einen

Überprüfung. Man hat also einen Implementierungsagenten, der die Sache erledigt, und dann hat man einen weiteren automatisierten Überprüfungsagenten, der sozusagen die Codierungsstandards durchsetzt und nach diesen tortologischen Tests sucht, die die Qualität der Testsuite mit der Zeit verbessern. Aber woher weiß man

Zeit verbessern. Aber woher weiß man dann, ob der automatisierte Überprüfungsagent gute Arbeit leistet ? Selbst in winzigen Codebasen, selbst

? Selbst in winzigen Codebasen, selbst bei Änderungen von nur einer Zeile, kann der Agent Mist produzieren. Ich

denke, das ist einfach etwas, mit dem wir leben müssen, und etwas, gegen das wir ständig kämpfen müssen.

Es ist auch nicht unbedingt etwas Schlechtes. Wir bringen eine Menge

Schlechtes. Wir bringen eine Menge Mehrwert ein, wenn man versteht, wie guter Code aussieht, wenn man erkennt, was Techup ist.

Und das ist auch ein Problem, das wir schon immer hatten. Verstehst du, was ich meine? Es ist

ich meine? Es ist nicht verschwunden. Es ist

nicht verschwunden. Es ist nicht verschwunden. Ich habe einfach

nicht verschwunden. Ich habe einfach das Gefühl, dass wir immer noch die gleichen Gespräche führen, die wir seit 20 Jahren führen. Es gibt nur diesen neuen Elefanten im Raum. Ich

möchte dich gerne fragen, wie es ist, in Großbritannien und in Bezug auf KI zu leben. Diese Frage kam auch von

zu leben. Diese Frage kam auch von einem der Leser, da du jetzt in Großbritannien und nicht mehr in London lebst, aber jetzt über KI aufklärst. Macht es die Dinge für

aufklärst. Macht es die Dinge für dich einfacher oder schwieriger, dass du weiter weg vom Silicon Valley und den Hauptsitzen der Labore bist?

Ich versuche wirklich nur, meinen eigenen Weg zu gehen. Ich habe schon ziemlich früh erkannt, dass ich die Zukunft nicht vorhersagen kann, richtig ? Weil ich so weit weg von allem bin.

? Weil ich so weit weg von allem bin.

Ich bin nur jemand, der vor Ort mit diesen Dingen arbeitet. Ich kann nicht wissen, was auf mich zukommt, richtig?

Ich weiß nicht, ob sich das Modell verbessern wird. Ich habe keinen

verbessern wird. Ich habe keinen privilegierten Zugriff auf die Dinge.

Deshalb versuche ich mich einfach auf das zu konzentrieren, was gerade funktioniert. Und deswegen ist mein

funktioniert. Und deswegen ist mein Handlungsspielraum ein wenig eingeschränkt. Das bedeutet, ich kann

eingeschränkt. Das bedeutet, ich kann einfach nur versuchen, meine Sachen zum Laufen zu bringen. Und es überrascht mich schon ein wenig, dass es so gut funktioniert, wie es funktioniert, denn ich habe nicht diesen privilegierten Zugriff. Ich versuche nur, diesen einen

Zugriff. Ich versuche nur, diesen einen Ansatz zum Funktionieren zu bringen.

Ich denke also, ja, du hast wahrscheinlich recht. Ich könnte das

wahrscheinlich recht. Ich könnte das wahrscheinlich auch machen, wenn ich in San Francisco leben würde, aber dann müsste ich in San Francisco leben. Das

möchte ich nicht. Das ist schrecklich.

Ich habe hier eine tolle Situation.

Meine Eltern wohnen gleich um die Ecke.

Wissen Sie, mein Sohn wächst auf dem Land auf. Es ist, wie es ist. Und ja,

Land auf. Es ist, wie es ist. Und ja,

jetzt sind Sie im Herzen ein Pädagoge.

Wie haben Sie die Veränderungen im Geschäft des Lehrens oder der Ausbildung von Softwareentwicklern wahrgenommen und auch die Art und Weise , wie die Menschen lernen möchten?

Wenn Sie irgendwelche Trends aus der Zeit davor beobachtet haben, als Online-Kurse und Lernen per Video viel beliebter wurden, im Gegensatz zu vor, sagen wir, zehn Jahren, als es vielleicht Tutorials und davor Bücher gab. Natürlich gibt es die immer noch,

gab. Natürlich gibt es die immer noch, aber die Vorlieben waren einfach anders .

Ja, es war während der COVID-Zeit, als Video-Tutorials so richtig durchgestartet sind. Ich denke, die

durchgestartet sind. Ich denke, die Menschen wollten eine viel umfassendere Lernerfahrung, und ich war sozusagen nach dieser Welle, nehme ich an. Ich

denke, die Art und Weise, wie die Menschen lernen, hat sich nicht so sehr verändert, oder? Und ihre Wünsche

verändert, oder? Und ihre Wünsche nach bestimmten Arten von Materialien haben sich nicht geändert. Ich finde

die Idee sehr sexy, dass ein Agent einfach vorbeikommt und dir alles beibringt. Und das funktioniert in

beibringt. Und das funktioniert in manchen Kontexten auch, aber eigentlich willst du doch eine Kuration, oder? Du

möchtest, dass ein Mensch kommt und den Informationsfluss versteht. Ich

stelle mir Informationen immer wie eine Art Graph vor, oder? Eine Information

hängt von einer anderen Information ab , die wiederum von einer anderen Information abhängt. Und

Information abhängt. Und diese Grafik in einen linearen Pfad umzuwandeln, ist für mich meine Aufgabe.

Ich versuche nur, dir den Algorithmus von Dystra anhand des Graphen beizubringen, damit du ihn auf möglichst sinnvolle Weise lernen kannst. Und diese Art der Kuration ist

kannst. Und diese Art der Kuration ist einfach nicht strategisch, oder? Das

ist nichts, was KI besonders gut kann.

Ich habe also offensichtlich diese große Wende von Typescript vollzogen, von taktischen Dingen auf diese strategische Ebene, und das funktioniert für mich ganz gut. Ich

kann wirklich nicht für andere Leute sprechen, die diese Arbeit machen, und ich weiß, dass viele andere nicht so erfolgreich sind. Ähm, ich denke, das

erfolgreich sind. Ähm, ich denke, das zeigt, dass Makler die Spielregeln hinsichtlich der Werte und Prioritäten der Leute gerade geändert haben. Die

Branche hat sich in sieben Monaten schneller verändert als je zuvor. Das

ist ein gewaltiger Wandel. Das bedeutet

nicht, dass wir unsere Arbeitspraktiken über Bord werfen müssen, aber wir müssen uns auf etwas anderes konzentrieren. Ich habe das Gefühl,

konzentrieren. Ich habe das Gefühl, dass ich damit ganz gut klargekommen bin. Andere hingegen nicht, weil sie

bin. Andere hingegen nicht, weil sie sich auf andere Dinge konzentrieren.

Ich frage mich, ob das in deinem Fall auch mit TypeScript insgesamt zu tun hat. Schon vorher hast du den Leuten

hat. Schon vorher hast du den Leuten geholfen, dieses damals sehr beliebte Tool zu nutzen. TypeScript gewann

Marktanteile. Es gab Migrationen von Java zu TypeScript, von Python zu TypeScript und so weiter. und

Entwickler wollten richtig gut werden, viele von ihnen oder die Top 10%oder Top 20%–wie auch immer man es nennen mag–wollten richtig, richtig gut mit TypeScript werden und suchten nach effizienten Wegen, dies zu tun. Nun ist

KI da und verändert die Art und Weise, wie wir als Softwareentwickler arbeiten , und ich denke, dass es besonders wertvoll ist, Software zu entwickeln.

Aber es stellt sich die Frage „Wie nutze ich diese Tools effizienter?“,

was im Moment dringlicher ist als „ Wie schreibe ich TypeScript effizient?

“, insbesondere in Bezug auf den Agenten. Ich frage mich, ob Sie ein

Agenten. Ich frage mich, ob Sie ein wenig davon hatten, von der Sprachausgabe, die Sie außerhalb Londons nicht machen konnten, zu etwas zu wechseln, das Sie außerhalb Londons machen konnten, nämlich dem Unterrichten. Sie haben sich einfach

Unterrichten. Sie haben sich einfach darauf konzentriert, einen anderen Bereich zu unterrichten, der im Moment wieder so viele Menschen beschäftigt.

Ich denke, ich hatte im Grunde genommen einfach Glück, dass ich das Richtige zur richtigen Zeit gewählt habe. Es

wäre für mich sehr einfach gewesen, in die KI zu wechseln, und es hat tatsächlich einiges an Überzeugungsarbeit gebraucht. Wie vor

Überzeugungsarbeit gebraucht. Wie vor ein paar Jahren war es Joel, mein Geschäftspartner, der mich dazu drängte, es tatsächlich zu versuchen.

Es ist wirklich ziemlich gut und man kann es für alle möglichen Dinge verwenden. Und es dauerte etwa drei

verwenden. Und es dauerte etwa drei Monate, in denen ich es tatsächlich versuchte und immer wieder scheiterte, bis mir klar wurde: Okay, das ist großartig. Ich schätze mich einfach

großartig. Ich schätze mich einfach sehr glücklich, dass ich zur richtigen Zeit am richtigen Ort gelandet bin. Und

ich versuche, es nicht zu erzählen.

Ich versuche, nicht zu denken: Gut gemacht, Matt. Du warst so clever, den

gemacht, Matt. Du warst so clever, den richtigen Schritt zur richtigen Zeit zu machen. Denn ich hätte auch einige

machen. Denn ich hätte auch einige Fehler machen und mich leicht in einer anderen Domäne wiederfinden können.

Und ich meine, das ist keine schlechte Sache. Ich würde einfach wieder

Sache. Ich würde einfach wieder Ingenieur werden. Das ist es, was ich

Ingenieur werden. Das ist es, was ich auch liebe.

Sich in die Lage zu versetzen, als man noch ein Anfänger in der Branche war.

Heute, für Leute, die in der Branche neu anfangen, für Berufseinsteiger, für Junioren, was würden Sie ihnen in taktischer Hinsicht empfehlen? Sie

sollten wissen: „Ich möchte diese Erfahrung sammeln. Ich möchte dieses

Erfahrung sammeln. Ich möchte dieses Urteilsvermögen, diesen Geschmack und diese Grundlagen entwickeln.“ Sie

müssen Wiederholungen machen. Wenn Sie

sich in dieser Situation befänden, wie würden Sie dann vorgehen? Ich möchte

ein Entwickler sein, ein Softwareentwickler mit all diesen KI-Tools und so weiter. Das ist jetzt verwirrend, weil es jetzt eine Mischung aus Folgendem gibt: Nutze ich diese KI-Tools nur, um Dinge für mich zu erledigen? Beherrsche ich die

erledigen? Beherrsche ich die Grundlagen, was langsam ist, und so weiter.

Ja, ich meine, ich würde jetzt gerne ein Junior sein. Ich wäre gerne in der genauen Position, in der ich 2014 war, als ich diese Tools für meine Studenten entwickelt habe, richtig?

Neulich wurde ich tatsächlich richtig nostalgisch deswegen. Ich dachte, ich

nostalgisch deswegen. Ich dachte, ich würde gerne zurückgehen und Gesangsunterricht geben, denn allein die Möglichkeit, eine Lektion abzuschließen und dann dem Agenten zu sagen: „Okay, dieses Tool hat auf diese Weise nicht ganz funktioniert.

Ich könnte es vielleicht ein wenig modifizieren und dann sehen, ob es funktioniert.“ Ich denke einfach, das

funktioniert.“ Ich denke einfach, das Richtige ist, diese Agenten so oft wie möglich zu verwenden, denn so arbeiten die Leute heutzutage. Und ich denke, das Wertvolle an meinen Fähigkeiten ist, dass man ständig mit den Veränderungen in Kontakt ist. Grill

mich nicht nur, sondern man führt eine Diskussion mit einem leitenden Entwickler, richtig? Das ist

Entwickler, richtig? Das ist vorteilhaft für den Entwickler, aber auch für dich, denn es bringt dich dazu, über diese tieferen Ideen nachzudenken. Und der absolute Mist,

nachzudenken. Und der absolute Mist, den ich mit meinem Spektrogramm-Analyse-Tool produziert habe, wäre so viel besser gewesen, wenn ich einen Agenten gehabt hätte, mit dem ich arbeiten konnte. Es lief

wie am Schnürchen, weißt du, die Leistung war absolut schrecklich. Wenn

ich hätte sagen können: „Okay, diese Bildrate ist auf 10 Bilder pro Sekunde gesunken.“ Wie behebe ich das

Sekunde gesunken.“ Wie behebe ich das ? Es hätte die sechs verschachtelten

? Es hätte die sechs verschachtelten For-Schleifen gesehen und gesagt: „ Okay, vielleicht solltest du dort etwas anders machen.“ Ich denke, es gab

anders machen.“ Ich denke, es gab noch nie eine bessere Zeit, um an diesem Zeug zu arbeiten. Solange du

dich nicht nur für den Code interessierst, den du produzierst, sondern auch für den Prozess der Codeerstellung, gab es noch nie einen besseren Zeitpunkt, um eine Art Nabelschau-Programmierer zu sein. Denk

einfach ständig über deine eigenen Prozesse nach und sei introspektiv.

Es klingt also so, als ob du, wenn du motiviert bist, im Vergleich zu früher wirklich schnell lernen kannst.

Absolut. Es geht nur darum, neugierig und anpassungsfähig zu sein. Und die

Leute, die ich sehe, die in dieser neuen Umgebung aufblühen, sind die gleichen Leute, die vor 10 Jahren aufgeblüht sind, weil sie einfach an dieser Arbeit interessiert sind, daran interessiert sind, bessere Software zu entwickeln, an ihren eigenen Prozessen und daran, bessere Software zu

entwickeln. Ich möchte dich über

entwickeln. Ich möchte dich über Gartenarbeit fragen. Äh, eine

Gartenarbeit fragen. Äh, eine Softwareentwicklerin auf X Lauren hat gepostet, ich zitiere sie mal. Jedes

Team braucht einen Gärtner. Jemand,

der ruhig den Strom an PRs beobachtet, der in euren Code einfließt, die Gerüche und die Fusseln bemerkt, die wie Efeu durch euren sorgfältig gepflegten Garten kriechen. Eine ruhige

Hand, die das Unkraut jätet, das sonst den Garten überwuchern würde. Und

worauf du geantwortet hast: Ich würde sagen, das Einzige, was euer Team braucht, sind Gärtner.

Ihr braucht wahrscheinlich auch noch ein paar andere Leute.

Ja. Ja. Aber, aber, aber genauer gesagt , möchte ich dich zu diesem Konzept des Gärtnerns befragen. Mir gefällt

wirklich sehr, wie Lauren beschrieben hat, wie das Unkraut den Garten überwuchert und wie man es rausbekommt .

Ich glaube, ich habe vor einiger Zeit einen Tweet gepostet, dass wir–das war, als ich über Ralph und die Agenten nachgedacht habe, die sich sozusagen immer wieder mit den Dingen befassen. Wir sind im Grunde nur Ralphs

befassen. Wir sind im Grunde nur Ralphs Plattformteam, richtig? Das sind wir

Plattformteam, richtig? Das sind wir jetzt. Und wir sind das Plattformteam

jetzt. Und wir sind das Plattformteam unserer Agenten. Wir versuchen, die

unserer Agenten. Wir versuchen, die Umgebung zu schaffen, in der sie erfolgreich sein können. Genau so

sollte man darüber denken. Wieder

einmal ist es strategisch und diese Gärtner-Metapher ist schön, denn, wissen Sie, es ist sehr einfach für den Garten, sich selbst zu entropieisieren, richtig? Unkraut zu

entropieisieren, richtig? Unkraut zu sammeln und all das zu tun. Daher ist

es eine wesentliche Fähigkeit, diese Dinge zu verstehen und zu diagnostizieren, bevor sie zu einem Problem in Ihrem eigenen Code werden, und das könnte die wichtigste Fähigkeit sein, richtig? Solange Sie

Arbeit für Agenten in die Warteschlange stellen können, solange Sie diese Schleifen erstellen können, jetzt, wo wir diese Prozesse sehen, bei denen Agenten den Code auf der Grundlage von Fehlerberichten und Feedbacks verbessern, fühlt sich das für mich nach wirklich cooler Arbeit und auch edler, interessanter Arbeit an .

Wir haben über einige großartige herausragende Softwareentwickler gesprochen, von denen Sie gelernt haben und von denen Sie sich heute inspirieren ließen. Welche

inspirieren ließen. Welche Fähigkeiten, Erfahrungen und Ansätze machen Ihrer Meinung nach einen großartigen Softwareentwickler aus?

Ich gebe Ihnen ein Beispiel: LZ Grahaml , der bei Versel am AI SDK arbeitet.

Ich habe mich neulich mit ihm unterhalten und er baut eine ganze Softwarefabrik für seine äußerst beliebte Open-Source-Bibliothek auf, die eine Menge Probleme hat. Wir

sprechen wieder über Klempnerarbeiten.

Wir sprechen über Gartenarbeit. Wir

denken über die Prozesse der Softwareentwicklung nach. Und ich denke

Softwareentwicklung nach. Und ich denke , wenn ich es mit einem Wort ausdrücken müsste, wäre es Selbstbeobachtung. Es wäre die

Selbstbeobachtung. Es wäre die Betrachtung von sich selbst und die Fähigkeit, das, was man tut, in etwas zu verwandeln, mit dem die KI arbeiten kann. Im Wesentlichen versucht man,

kann. Im Wesentlichen versucht man, seinen Prozess in Worte zu fassen. Und

genau das habe ich mit den Fähigkeiten gemacht. Das habe ich auch mit den

gemacht. Das habe ich auch mit den Automatisierungen versucht, die ich erstellt habe. Ich schaue mir einfach

erstellt habe. Ich schaue mir einfach an, was ich tue, und überlege, wie ich es besser machen könnte. Und wie

könnte ich das in dieses seltsame Tier einbetten, das ich vor mir habe. Wie

kann ich es so umsetzen, wie ich es möchte? Diese Einstellung war wirklich

möchte? Diese Einstellung war wirklich sehr hilfreich für mich. Das ist etwas , das ich an Lars und allen Menschen, mit denen ich zusammenarbeite, schätze , wenn sie sich an Agenten wenden.

Und zum Abschluss: Welches Buch oder welche Bücher würden Sie empfehlen?

Ich würde „Pragmatic Programmer“ nennen, „Philosophy of Software Design“ von John Asterau, und ich würde sagen, die ersten drei Kapitel von DDD, das Buch von Eric Evans, „ Theus Language One“. Insbesondere

dieses Buch ist wirklich gut für die allgegenwärtigen Sprachkonzepte, die Domänenmodellierung und die eigentliche Kodierung in Code. Ich bin

kein so großer Fan davon, aber diese drei sind die wichtigsten.

Großartig. Mathe. Nun, danke. Das war

wirklich interessant und hat viel Spaß gemacht.

Schön, endlich im Podcast zu sein. Ja.

Lerne den berühmten Typen höchstpersönlich kennen. Es ist toll.

höchstpersönlich kennen. Es ist toll.

Wir haben uns natürlich schon einmal getroffen, aber es ist toll, hier zu sein. Es war so schön, mit Matt

sein. Es war so schön, mit Matt zusammenzusitzen, und ich muss sagen, dass ich durch das Wissen, dass er Stimmtrainer und Schauspieler ist, verstehe, wie flüssig er spricht und wie angenehm es ist, ihm zuzuhören.

Der wahrscheinlich amüsanteste Teil dieses Gesprächs war, wie Matt bei seiner Suche nach besseren Möglichkeiten für die Arbeit mit KI nicht die modernen Ansätze fand, die ihm wirklich nützlich waren.

Stattdessen griff er auf klassische Bücher über Softwareentwicklung zurück: „The pragmatic Programmer“ , „A Philosophy of Software Design“ und „Domain Driven Design“. Es ist

schon ironisch, dass die Best Practices , die vor über 20 Jahren dokumentiert wurden, wie z. B. taktische und

strategische Programmierung in diesem Buch, nicht nur immer noch funktionieren, sondern beim Schreiben von Code mit KI-Agenten sogar noch wichtiger werden. Ein damit

wichtiger werden. Ein damit zusammenhängender Punkt, den ich hervorheben möchte, ist die Bedeutung von einleitenden Wörtern in der Arbeit mit KI. Als Matt anfing, Begriffe wie

mit KI. Als Matt anfing, Begriffe wie Leuchtspurgeschoss oder vertikale Schnitte zu verwenden, folgte das Modell seinen Ideen bei der Planung besser. Und wenn man darüber nachdenkt

besser. Und wenn man darüber nachdenkt , macht das Sinn, denn Literatur über Softwareentwicklung ist Teil der LLM-Ausbildung. Diese Begriffe sind

LLM-Ausbildung. Diese Begriffe sind also auch Teil der Priors des Modells.

Ebenso interessant ist, dass die Verwendung der richtigen Wörter zur Beschreibung eines Problems kein neues Konzept ist. Als ich beispielsweise Ken

Konzept ist. Als ich beispielsweise Ken Beck im Podcast hatte, erzählte er, dass er und Ward Cunningham vor 30 oder 35 Jahren eine Doktorarbeit auf dem Schreibtisch hatten und diese nutzten, um die besten Wörter für das zu beschreibende Problem zu finden. Das

war ein weiterer Moment, in dem sich der Kreis schloss und zeigte, wie wichtig Wörter tatsächlich sind.

Abschließend möchte ich Matts Hinweis darauf schätzen, dass man eine saubere Codebasis anstreben sollte. Nicht nur,

weil es für Menschen einfacher ist, sich zurechtzufinden, obwohl ich denke, dass man das auch aus diesem Grund tun sollte, sondern auch, weil Agenten kein Langzeitgedächtnis haben und sich Ihre Codebasis bei jedem neuen Durchlauf zum ersten Mal ansehen. Und es ist viel einfacher, sich in einer gut strukturierten Codebasis

zurechtzufinden als in einer, die wirklich unübersichtlich ist. In den

Shownotes unten finden Sie ein Interview mit John Auster How, dem Autor von „Philadelphia Software Design“, einem Buch, das ich wirklich liebe, sowie verwandten Deep Dives für KI-Engineering und Kontext-Engineering.

Wenn euch die Folge gefallen hat, dann abonniert den Podcast doch bitte. Eine

Bewertung ist immer gern gesehen.

Vielen Dank und bis zum nächsten Mal.