Du hast bestimmt schon einmal von prompt Engineering gehört,
aber viel wichtiger ist eigentlich das Kontext
Engineering. In dieser Folge tauchen wir tief
daran ein, wie man mit einer KI mit dem richtigen strukturierten
Kontext versorgt, um brauchbare Ergebnisse zu bekommen.
Wir erklären, warum gerade in der Softwareentwicklung ein
fokussierter Kontext super wichtig ist, wie man diesen
Kontext aufbaut und warum das traditionelle prompt Engineering
nach und nach an Relevanz verliert.
Außerdem gibt es ein paar Tipps gegen KI, Halluzinationen und
wie wir mit LN MS besser coden. Viel Spaß damit.
Es ist noch immer heiß und stehen noch immer die
Schweißperlen auf der Stirn, aber trotzdem gibt es eine
Nigelnagelneue Folge. Vom to do cast.
Dem Developer Podcast mit dem schwitzenden Malte Lantin und
dem. Mindestens genauso schwitzenden.
Robin Manuel Thiel ich hoffe, dass wir das.
Irgendwann mal in den Griff kriegen.
Ansonsten müssen wir uns mal ein klimatisiertes Podcast Studio
besorgen, denn unter Beleuchtung und Lichtern, die hier auf uns
scheinen und dicken Kopfhörern, die wir auch haben, ist es nicht
unbedingt erfrischender. Umso erfrischender sind
natürlich die. Kaffee, die wir von euch.
Ausbekommen haben ausgegeben bekommen, haben so das Gehirn
hat schon den ersten Ausfall gehabt heute hoffentlich nur am
Anfang, deswegen ganz, ganz lieben Dank, Wir haben Kaffee
ausgegeben, bekommen zweimal von Oliver und einmal von Nico.
Und da haben wir uns vielleicht die einen oder anderen Eiswürfel
reingelegt und. Uns damit über die Woche
gerettet. Ganz lieben Dank.
Vielen Dank dafür. Aber damit wollen wir mal ins
Thema der heutigen Folge einsteigen, nämlich context
Engineering und so wie wir die letzten Folgen immer und immer
wieder über das Wetter reden, reden wir auch in den letzten
Folgen immer und immer wieder über Themen rund um künstliche
Intelligenz in der Softwareentwicklung und dazu
gehört halt auch context Engineering, wie manche sagen,
als Evolution oder Weiterentwicklung von prompt
Engineering. Wie sieht das aus?
Aus deiner Sicht? Ist es wirklich eine
Weiterentwicklung des prompt engineerings?
Ja, ob jetzt. Weiterentwicklung, Ergänzung
oder Fokus weiß ich gar nicht so genau.
Es war ja schon immer so, dass der Kontext ein großer Teil von
meinem Gesamtprompt war. Also ich nehme eben eine
Anweisung, was ein Latch Language Model machen wollen
soll, habe ich ja schon immer Zusatzinformationen mitgegeben,
teilweise auch getippt und ich. Jetzt.
Stellt sich aber so ein bisschen raus, dass das der.
Wichtigste Teil zu. Werden scheint und dass diese
Modelle einfach besser darin werden zu verstehen, was ich von
ihnen will und das muss ich gar nicht mehr so klar irgendwie
strukturieren, sondern eben den richtigen Kontext, die richtigen
Informationen bereitzustellen, auch im richtigen Schritt.
Oft habe ich ja nicht nur eine einzelne Anfrage an so Modellen
krieg ich eine Antwort. Es haben heute so so.
Agentenbasierte Workflows, aber im richtigen Schritt von diesen
Workflows. Die richtigen Informationen dem
Modell. Bereitzustellen auch in der.
Richtigen Menge, sodass es dann plausibel die Aufgabe lösen
kann, die man ihm gibt. Das scheint gerade so der
wichtigste Teil zu werden, zumindest so vom ganz aktuellen
Stand, wo wo stehen wir heute in der Industrie und das nennt man
so ein bisschen Kontext Engineering, also den richtigen
Kontext dann zur richtigen Zeit in der richtigen Menge
Reinzugeben und das scheint zumindest.
Gerade so das Wichtigste zu. Sein und ich glaube deswegen
gerade so ein bisschen der Fokus drauf und.
Ob das jetzt Prom Engineering ersetzt, weiß ich nicht, aber
ich glaube, es rückt so ein bisschen in den Hintergrund, wie
wir den Promp bauen. Und es wird wichtiger, was wir
damit reingeben. Ja, ich glaube, es kommt ein
bisschen davon darauf an, welche Werkzeuge ich einsetze.
Ich glaube, wenn ich irgendwie so ein Bild oder
Musikgenerierungstool habe, dann bin ich häufig so in diesem
klassischen prompt Engineering, wo ich irgendwie eine Textbox,
irgendwie eine Anweisung schreibe, möglichst präzise, was
ich erreichen möchte. Aber wenn wir jetzt den Kontext
wechseln und so ein Multi Purpose Tool, irgendwie ein
Chat, GPT oder ähnliche verwenden oder halt ein Coding
Tool, da wird es immer wichtiger wirklich diesen Kontext zu bauen
und den kann ich entweder in meiner Chatbox bauen oder ich
kann Dateien anhängen oder das Tool was ich habe bietet noch
andere Möglichkeiten diesen Kontext möglichst gut und
präzise aufzubauen und darum soll es natürlich jetzt im
Folgenden im Detail gehen und wir schauen uns einfach mal an
wie sich das so ein bisschen auch.
In der Definition unterscheidet. Dabei kann der Kontext.
Natürlich eigentlich alles sein, was ich irgendwie dem Date
Language Model Mitgebe, als Information um.
Die Aufgabe. Die ich ihm mal gebe zu lösen,
das sind ganz viele Dinge, das ist wie du.
Gerade gesagt hast Day the. User prompt.
Also das, was ich in diese Textboxen mit Eintippe, das.
Ist aber auch so. Quasi.
Man nennt das System prompt. Also was der?
Anbieter von einem bestimmten Tool da mit reingeschrieben hat.
Ich glaube bei Getap Co peilt steht auch irgendwo drin.
Du bist ein hilfreicher Agent der beim Coden hilft und so
weiter also das ist ja oft dann was der der Tool Anbieter da mit
reinschreibt. Dann gibt es sowas wie.
Wie Long Term Memory. Also was hat das Tool?
Vielleicht in den ganzen Nutzungen, die ich schon mit ihm
habe. Über Informationen über mich
gesammelt. Dann sind das natürlich aber
auch Dinge. Wie?
Kurzzeitgedächtnis nennt man das
dann, also Short Term Memory, zum Beispiel.
Was, was ist die bestehende Chat?
Historie, die wir jetzt gerade. Hatten oder was ist vielleicht
eine Zusammenfassung von einem längeren Dokument, wo wir, wo
wir vor einer Minute in dem gleichen Thread drüber
gesprochen haben. Es kann natürlich auch.
Zusätzliche Informationen sein, die dann, bevor der prompt
abgeschickt wird, von dem. Tool, das hattest.
Du glaube ich gerade so ein bisschen gemeint noch mit
Reingesogen und im Hintergrund, ohne dass ich das als User
eigentlich sehe, da mit dran gehangen werden und das.
Wir reden natürlich also auch seit mehreren Folgen über.
Agenten, die selber Tools aufrufen.
Können. Wir hatten vor 2 Folgen in
diesem Vibe Coding Tool geht auch mal über sowas wie Kontext
7 gesprochen, was dann selber Dokumentation sich mit
reinziehen kann und zumindest diese Liste an Tools die LUT
Language Model auch bedienen könnte um dem Ergebnis näher zu
kommen, die wird auch mit Reingegeben und all das
definiert dann ja irgendwann den Kontext.
Also all das. Was das LUT Language Model
irgendwie an Information gebrauchen könnte.
Neben dem, was ich dann noch per Hand mit Reingetippt habe, formt
dann letzten Endes den Kontext, aus dem sich das Modell bedienen
kann. Das heißt, es hat dann alle
Informationen auf der aus der ganzen Welt aus dem gesamten
Internet, auf denen es trainiert wurde.
Plus das, was von. Mir eben als Kontext mit
Reingegeben wird und kann sich dann.
An die Lösung der Aufgabe machen.
Jedes dieser Sprachmodelle, die wir in unseren Tools einsetzen,
hat ja dann bestimmte. Bestimmte Kapazität an Kontext,
die es aufnehmen kann deswegen spricht man häufig auch von
einem Kontext window oder in anderem Kontext wird dann
einfach gesagt Token Limit, aber das ist ein bisschen abstrakter.
Ich finde eigentlich diesen Begriff des Kontextfensters
eigentlich gar nicht so verkehrt, das heißt, wieviel
Kontext kann ich eigentlich technisch in das sprachmodell
reingeben, wieviel Kontext sinnvoll ist und ob man das
immer komplett ausreizen sollte, da sprechen wir gleich noch mal
drüber, aber. Dabei, das findet man häufig
dann in der Dokumentation solcher Large Language Models,
also wie viele Tokens kann ich da reinwerfen als Kontext?
Und auch. Genauso wie der Kontext Window
Model abhängig ist, ist einfach. Durch die Art und.
Weise, wieso ein Model trainiert wurde.
Sind dann bestimmte Strukturen in bestimmten Prompts eben mehr
oder weniger erfolgreich? Es hat sich zum Beispiel bei den
openeye Modellen herausgestellt. Dass es sehr erfolgreich ist.
Einen prompt in einer bestimmten Reihenfolge aufzubauen, also
ganz am Anfang. Zu schreiben, was ist.
Das Ziel, was ich erreichen möchte.
Dann als zweites zu. Beschreiben, in welcher Art und
weise ich das Ergebnis aufbereitet haben möchte.
Man nennt das so ein bisschen return Format, also möchte ich
einen JSON zurückbekommen oder ein Diagramm oder eine.
Tabelle. Dann so ein paar, danach so ein
paar Warnungen, also so ein bisschen achte auf dies und
jenes und das und das habe ich schon probiert, das funktioniert
nicht, oder? Stelle aber sicher, dass du.
Folgendes auf jeden Fall machst und dann am Ende ebenso noch so
eine Liste mit Zusatzinformationen mit dem
Kontext, also Dinge die noch relevant sein könnten um um das
Ganze zu lösen, die. Aufgabe die, die gestellt.
Wurde und deswegen kann man auch, glaube ich, ganz klar
sagen, dass context Engineering eben so ein Sub Part vom vom
prompt Engineering ist und. Und es geht halt schon lange
nicht mehr darum, nur noch den Cleversten prompt zu schreiben,
sondern wirklich. Wir hatten ja schon vor ein
Paar. Wochen, ein paar Wochen schon
mal gesagt, immer wieder Kontext is King.
Also ganz klar zu kuratieren, wann welcher Kontext sinnvoll
ist. Ja, das liegt ja zum einen an
der Weiterentwicklung der Werkzeuge, über die wir dann am
Ende solche Sprachmodelle nutzen oder konsumieren.
Aber zum anderen liegt das natürlich auch daran, dass diese
Sprachmodelle einfach auch besser werden aus.
Schlecht beschriebenen Aufgaben das richtige Ergebnis
abzuleiten. Also ich kann teilweise wirklich
mit einem Halbsatz schon das richtige Ergebnis erzielen, wo
ich vielleicht noch vor ein, anderthalb Jahren wirklich einen
kompletten Absatz in einer bestimmten Syntax schreiben
musste, um wirklich zu einem guten Ergebnis zu kommen und von
daher ändert sich das auch und es geht gar nicht mehr so darum,
wirklich einen. Super guten prompt zu schreiben
und damit werden vielleicht auch diese prompt Engineering
classes, wie wir sie noch vor einiger Zeit hatten, ein
bisschen weniger relevant, sondern es geht vor allen Dingen
um den Kontext, also diesen Teil des Promptes, in dem ich halt
relevante Informationen zusammenstelle, die für die
Lösung des eigentlichen Problems entscheidend sind.
Und das ganze Thema hilft uns natürlich vor allem beim Coding.
Das ist ja immer noch ein developer Podcast hier
allgemein. Context Engineering ist erstmal
für. Ist überall da relevant?
Wo wir KI verwenden, also vielleicht einfach bei Chat GPT.
Aber gerade im Coding ist es oft erfolgsentscheidend, denn es
gibt eine Umfrage. Also Qdu hat eine.
Studie gemacht, die verlinken. Wir auch mal in den.
Shownotes die heißt 25 state of AI code.
Quality, Da haben Sie eine. Große Menge an.
Programmiererinnen und Programmierern befragt.
Wie sie generell zur Codequalität stehen, der den
eine KI ausspuckt und. Fast alle sind sich darüber
einig, dass es Produktivitäts und Effizienzgewinne gibt, aber
auch fast alle, nämlich hier 76%, also ein 3, also
dreiviertel der Befragten, haben sich aber auch darüber
beschwert, dass sie eigentlich dem KI Code nicht wirklich
vertrauen können und der Hauptgrund der der genannt
wurde, ist Halluzination gewesen, also Halluzination von
8. Apis, die es vielleicht gar
nicht gibt, oder Methoden Calls, die es vielleicht gar nicht gibt
oder die es vielleicht gar nicht in der Version von dem Tool oder
der Librader dieses Frameworks, was ich jetzt hier in meinem
Projekt anwende, gar nicht gibt. Und die Lösung für genau diese
Dinge ist unter anderem ein gut kuratierter Kontext.
Das hilft ja auch dabei wirklich.
Die Informationen darüber zu liefern, wie mein
Entwicklungsprojekt in Summe aussieht.
Häufig habe ich gerade in der Anfangszeit dieser KI Tools für
die Softwareentwicklung immer sehr lokal gearbeitet und da
fehlt natürlich dann entsprechend die Information
über die Gesamtstruktur oder welche internen Libraries AP is
ich dort nutze und da kommt natürlich auch viel der
Frustration her, nicht nur über Halluzinierte.
Ap is, sondern teilweise auch über Dinge, die ich vielleicht
auch in meinem Projekt schon mal gelöst habe.
Und dann wird nicht einfach die entsprechende Library Methode
aufgerufen, sondern das Ganze noch mal neu implementiert, weil
halt zu dem Zeitpunkt dann einfach das Bewusstsein nicht da
war, dass es bestimmte Informationen in dem Projekt
schon gibt, auf die ich einfach wieder zurückgreifen kann, was
natürlich auch so ein bisschen zu diesem Phänomen führt, was
manche dann auch bei diesen in Anführungsstrichen wipecoded
Applications beklagen, dass da ganz viel so immer wieder.
Geschriebener Code auftaucht, das heißt viel Duplikation und
andere Sachen, die ich eigentlich in der
professionellen Softwareentwicklung vermeiden
würde, indem ich halt klar strukturiere und
wiederverwendbaren Code nutze. Genau das ist der Punkt.
Also genau, es geht genau im Kontext Engineering darum, diese
Information, die du gerade genannt hast, irgendwie, also
zum richtigen Zeitpunkt, mich genau dann, wenn ich irgendwas
implementieren will, was es vielleicht schon gab, mit.
Dem Lutch Language Model Reingebe und das wird halt die
Aufgabe von in uns in diesem Fall jetzt den den den Coding
Tools sein, den Win den Win surfs Cursors geht ab Co Pilots
dieser Welt das. Die richtigen Dateien zur
Richtigen, zum richtigen Zeitpunkt zu finden und dem
lasch Englisch Model mitzugeben. Denn immer wenn wir diesen
Kontext kuratieren, dann müssen wir uns fragen, wenn wir, wenn
wir dem Model eine Aufgabe oder eine Frage stellen, woher soll
es das Wissen, also woher kann es das wissen, es ist ja nicht
auf unserem Code trainiert, es ist auf alle möglichen Code
trainiert, deswegen kann es programmieren.
Aber es kennt ja jetzt erstmal nicht unser Projekt.
Es ist ja nicht Teil des Trainings Sets und selbst wenn
es Teil des Trainings Sets gewesen ist, kann kann das
Modell das dann gar nicht so genau unterbrechen auf unser,
auf unser eigenes Projekt, das heißt, ich muss zum richtigen
Zeitpunkt, wenn du mich wenn du sagst Implementiere die oder
jene Funktion alle eigentlich alle relevanten Dateien finden,
das ist glaube ich die große Herausforderung finden und dann
in diesen Kontext mit mit Reinzupacken und das müssen halt
in unserem Fall irgendwann diese Tools machen und.
Es gibt aber noch ein paar andere Dinge, die wir halt schon
machen können. Und das ist ja, wie du gerade
schon gesagt hast, unser Projekt gut zu beschreiben.
Wir hatten in Folge 119 haben wir mal so ein Vibe Coding
Toolkit, so ein bisschen mit so einem Augenzwinkern beleuchtet,
aber auch ein paar relevante Sachen für uns rausziehen können
und da haben wir schon mal im Detail über sowas gesprochen,
wie dass wir zum Beispiel die Projektstruktur, also in welchem
Ordner findest du denn was? Welche Komponenten?
Wo findest du Tests? So findest du Dokumentation und
so weiter dass man das so einem Modell auch einfach immer schon
mal mitgeben kann, gerade in so einem agentenbasierten Workflow,
wo vielleicht im ersten Schritt relevante Dateien gesucht
werden, die dann in den Kontext gepackt werden und die dann alle
zusammen dem Model gegeben werden.
Oder sich eben Reinschreibe welche?
Libraries ich in welcher Version verwende und so weiter und
sofort, das kann ich ja alles schon mal in meinem Projekt
definieren und dem Model automatisch mitgeben.
Ja, und ich finde das ganz interessant, dass man wirklich
sich diese Strategien überlegen muss, weil ja der, ich sag mal,
naive Ansatz wäre jetzt, ich nehme einfach ein Sprachmodell
mit dem ausreichend großen Kontext window zum Beispiel so
ein aktuelles Germany pro Modell, was ein riesiges Kontext
window hat und schmeißt einfach mein komplettes Projekt da rein,
weil dann ist der ganze Kontext ja alles was mein.
Large language mal jetzt braucht, um beliebige Probleme
in diesem Projekt zu lösen sind ja jetzt ist ja jetzt vorhanden,
ich habe ja alles reingeworfen, aber wie man tatsächlich in der
Praxis sieht, bedeutet das nicht, dass das Sprachmodell
plötzlich ein vollständiges Verständnis des Projektes hat,
sondern es führt tatsächlich auch vielleicht zu negativen
Effekten, weil ich wirklich auch den Fokus verliere und genauso,
wenn ich dir jetzt sage. Du hast relativ wenig Zeit.
Du hast folgendes Problem zu lösen, hier ist die komplette
Codebase, dann funktioniert das wahrscheinlich weniger schlecht
als wenn ich sage ich kenne das Projekt.
Du hast folgendes Problem und schau dir mal diese Bereiche in
dem Projekt an, da ist alles drin was du wissen musst um
dieses Problem zu lösen. Wie hat Elon Musk letzte Woche
gesagt? Grog kann den ganzen Code
irgendwie lösen, der. Du kannst deine komplette Code
Datei da reinschmeißen. Also.
Solange deine komplette Codebase nur eine Datei ist, funktioniert
das vielleicht auch. Aber wir reden jetzt natürlich
hier über größere, komplexere Projekte und da zeigt die
Erfahrung, dass es nicht die Lösung ist, einfach möglichst
viel in den Kontext reinzuschmeißen.
Wo über diese Large Language Modelle halt einfach nicht gut
drin sind, sind Entscheidungen zu treffen und.
Und das ist ja eigentlich ein bisschen, das wird ja, glaube
ich, immer auch damit geworben, gerade bei Germany 25, da kannst
du deine gesamte Codebase theoretisch in das Modell in
einen Prom mit reinpacken, ist aber nicht sinnvoll, weil wir
haben auch gelernt, dass sich solche Modelle auch dann immer
wieder verwirren lassen und gerade wenn ich so eine
agentenbasierte Schleife irgendwie durchlaufe, dann hier
ganz klar der Tipp kontrolliert selber, was damit mit reinkommt.
Also selbst wenn ihr irgendwie selber Agenten baut, jetzt gar
nicht unbedingt im Coding benutzt, sondern irgendwie
selber mit irgendeinem Tool euch Agenten baut, dann.
Dann gibt es zum Beispiel so den ganz klassischen Fehler, dass
man sagt, ach guck mal, wenn hier irgendwas fehlschlägt,
irgendein Tool, Call, irgendeine API, irgendwas fehlschlägt, dann
nehme ich die Fehlermeldung davon und pack die einfach mit
in den Kontext rein und sag einfach dem Modell, guck mal,
jetzt hast du eine neue Information bekommen, Versuch
noch mal und dann kann es aber sein, dass.
Dass ich diese Schleife so oft durchlaufe, dass da 567
Fehlermeldungen im Coding teilweise zum Beispiel mit
gesamtem Stack Trace drin sind, das Ding quasi wirklich
vollgemüllt in Anführungszeichen wird und die Ergebnisse immer
schlechter werden und wir wirklich irgendwie sehen, dass
das, dass die Modelle crazy werden, also ganz klar.
Kuratiert diesen Kontext, wenn es einen erfolgreichen Tool Call
nach all den Fehlern gab, dann schmeißt die Fehlermeldungen
wieder raus. Bei den meisten Tools, also bei
Get Up Copile kann man es zum Beispiel, wenn man mit dem mit
dem Chat Modus auf der an der Seite arbeitet, auch wieder
einzelne Nachrichten aus der Vergangenheit löschen, man muss
ja Bewusstsein, dass die gesamte Chat Historie teil.
Oder irgendwie zumindest herangezogen wird, um die
Aufgabe zu lösen. Und da kann ich auch eben
relevante Sachen, die jetzt nicht mehr wichtig sind, weil
das Problem vielleicht gelöst wurde, da auch wieder mit
rausnehmen oder vielleicht einfach, wenn ich selber einen
Agenten baue, sagen, du kannst maximal 3 mal wieder verwenden
und wenn es dann erfolgreich war, schmeißt du die
Fehlermeldungen wieder raus und so weiter also ich glaube man
muss sich ja schon Bewusstsein, nur weil der Kontext so groß
werden kann. Heißt es nicht, dass er so groß
werden sollte, sondern dass es eigentlich nur dafür darf, wenn
wirklich alles, alles relevante so groß ist für die aktuelle
Aufgabe heißt aber nicht wie gesagt, dass man den auf jeden
Fall vollpacken sollte. Das Gute ist für uns aber
zumindest als Software Developer, dass das ein
bekanntes Problem ist. Das heißt viele der Tool
Hersteller, die Tools für die Softwareentwicklung anbieten.
Lösen dieses Problem teilweise schon für uns, indem sie
künstlich auch diesen Kontext beschränken.
Das heißt, nur weil ich in meinem Coding Tool der Wahl
jetzt Terminal 25 Pro auswähle, heißt es nicht, dass ich
wirklich diese 1000000 Tokens vollmüllen kann, sondern da
findet eine clevere Auswahl auch der entsprechenden Informationen
statt und es wird nicht einfach, nur weil es geht das komplette
Token window voll gemacht, sondern da gibt es natürlich
auch extrem viel Erfahrung auf der Seite dieser Tool Hersteller
und. Wieviel Kontext wirklich
sinnvoll ist, um ein Problem zu lösen, aber das entbindet uns
natürlich nicht davon, die Auswahl zu treffen oder diese
Auswahl mit zu beeinflussen, selbst wenn das Tool einiges im
Hintergrund macht, wie zum Beispiel dieses Token Window zu
beschränken, müssen wir natürlich da auch selber.
Bisschen Energie reinstecken und sagen Okay welche Informationen
gebe ich jetzt rein und mich da auch nicht vollständig darauf zu
verlassen, dass irgendwelche cleveren Suchalgorithmen dann
zum Beispiel in unserem Agenten immer die entsprechenden
richtigen Informationen finden. Und was immer hilft, wenn ich
weiß, was die richtige Information ist, dann gebe ich
das einfach mit rein. Also auch wenn der Agent
vielleicht selber in der Lage ist, die richtigen Dateien.
Zu suchen oder vielleicht zumindest versucht es sie zu
suchen und rauszufinden. Wenn ich weiß, du musst dir die
5 Dateien anschauen, auf jeden Fall um die Aufgabe erfolgreich
zu lösen, dann schmeiße ich die schon mal mit rein.
Ich kann in all diesen Tools einfach per Drag and Drop Code
Dateien mit in dieses Chat Fenster einfach reinziehen und
schon mal sagen Ey pass auf, ich gebe dir jetzt eine Aufgabe,
gerade wenn du so agentenbasiert vorgehst und diese Tools oder
diese Ordner werden auf jeden Fall relevant sein, also sich
gar nicht darauf verlassen, dass ich irgendwas rausfinde, sondern
wenn ich etwas weiß. Dann mitgeben.
Wir hatten das im Vibe Coding auch schon mal so ein bisschen
gesagt, Ich komme wieder auf diesen Kontext 7 MCP Server
zurück, wo das LM selber rausfinden kann, was ist denn
die richtige Library ID in dieser Datenbank an an aktuellem
an aktueller Dokumentation und wenn ich die richtige ID für
meinen React Version XY Framework herausgefunden habe,
dann gehe ich zu diesem Kontext 7 Server hin.
Wenn ich aber weiß, was die richtige ID ist für die Version
von diesem, von dieser Vibry, die ich verwende, dann sag ich
dem dem Model das direkt, dann schreibe ich das mit rein, wie
schon direkt in dem prompt, dass ich ihm quasi immer, je mehr
Arbeit ich ihm abnehmen kann durch Informationen, die ich
schon kenne. Desto besser wird auch das
Ergebnis werden. Dadurch kuratiere ich den
Kontext dann noch mal selber. Ja, die meisten agentenbasierten
Workflows können sich selber diesen Kontext kuratieren, indem
sie erst mal auf die Suche gehen nach den relevanten Dateien in
meinem in meinem Coding Projekt und erst dann das Large Language
Modell an der Code Generierung arbeiten lassen.
Aber wenn ich schon vorher Informationen weiß, dann gebe
ich die mit rein, denn je mehr ich selber quasi eigenständig
diesen Kontext dann kuratieren kann, desto besser wird auch das
Ergebnis werden. Und genauso macht es, obwohl ich
theoretisch dem Tool meinen kompletten Code geben kann,
immer noch Sinn. Die Struktur meines Codes zu
erklären. Einfach eine marktdown Datei,
die beschreibt, wie ist mein Projekt aufgebaut, wo befinden
sich welche Informationen, auch das hatten wir in der vorletzten
Folge im Detail besprochen, aber auch das ist ein Teil dieses
Kontext engineerings. Genau und genauso wie die Stufe
von meinem Projekt ist natürlich Struktur von der Aufgabe.
Sinnvoll also all das, was ich auch sonst vielleicht in ein
gutes Jira Ticket mit reinschreiben würde.
In gute issue Beschreibung mit reinschreiben würde also sowas
wie eine Definition of done, wann bist du fertig, wann kannst
du aufhören irgendwie Code zu generieren aber auch
Hintergrundinformationen sind nützlich, also was ist der
Business Value oder der User Impact von diesem Feature oder
diesem diesem Code change, warum machen wir das hier eigentlich?
Wie kannst du dein Ziel erreichen?
Also vielleicht auch eine kurortierte Liste an den
richtigen Tools oder schon mal so ein Implementation blueprint
oder schon mal ein bisschen pseudocode, den ich vielleicht
irgendwo geschrieben habe? Also alles was ich schon weiß
was dem Modell hilft in die richtige Richtung zu laufen, das
gehört da mit rein, wenn ich beschreibe was ist eigentlich
die Aufgabe die zu lösen ist und wann weißt du, dass die Aufgabe
korrekt gelöst ist? Und warum löst du überhaupt
diese Aufgabe? Und dazu kommen natürlich noch
Hilfe bei der Implementierung, irgendwie Dokumentationen,
Beispiele, vielleicht bekannte Fallstricke, also alles, was wir
vielleicht wissen, was in der Vergangenheit nicht funktioniert
hat. Um dieses Problem zu lösen.
All das kann am Ende dabei helfen, das Problem.
Am Ende richtig zu lösen und jetzt mag man sich fragen okay
jetzt sitze ich dort und muss das jedes Mal zusammenstellen in
mein prompt window reinschreiben und das ist genau der
Unterschied den wir am Anfang meinten, der zum klassischen
prompt Engineering besteht. Solche Dinge, die mache ich
nicht jedes Mal wenn ich mit meinem Coding Agenten rede oder
wenn ich im Chat unterwegs bin, sondern ich bereite das und.
Hoffentlich so vor, dass es wieder verwendbar ist und kann
dann immer wieder auf diese ganzen Informationen zugreifen.
Ja, dann lass uns doch jetzt mal anschauen.
Also wie baue ich denn jetzt mit Fokus auf Software Development,
wie baue ich denn jetzt so einen guten Kontext und wie kann ich
das vielleicht, wie du gerade gesagt hast, automatisieren
vorher erstmal, bevor man selber diesen Kontext kuratiert, also
die richtigen Dateien reinzieht, die richtigen Instruction
schreibt. Also es ist immer noch wichtig,
das Ziel gut zu beschreiben, also das, was man, glaube ich,
was wir eingangs mal irgendwie als User prompt bezeichnet
haben, das ist immer noch, wo wahrscheinlich auch ein Großteil
der Zeit mit reingeht, ganz klar zu sagen, was will ich
eigentlich, was ist deine Aufgabe, aber wenn ich das gut
gemacht habe, und das haben wir gerade ein bisschen gemerkt, es
ist fast noch wichtiger, jetzt hinzugehen und zu sagen, was
sind relevante Informationen, die es dazu gibt, was malte
gerade schon gesagt hat, ist wenn ich eben sowas wie eine
Struktur von meinem Projekt Anweisungen, wie baue ich das
Projekt, wie teste ich das das Projekt, wo finde ich eigentlich
was, welche Libraries wir verwenden, wenn ich das eh schon
habe, dann kann man in seinem Repository in den allermeisten
Fällen in den allermeisten KI Tools, die man verwendet so
Custom Instruction Files mit ablegen, das ist wenn ich Cloud
Code verwende ist das so eine Cloud Punkt Mark Down das ist
bei github Copy liegt das im Punkt github Ordner das sind das
Custom Instructions. Cursor nennt das Rules, Files
und so weiter und sofort und da kann ich eben Dinge ablegen, die
dann im Hintergrund von diesen Tools automatisch jedes Mal mit
in den Kontext geschrieben werden und das sind in der Regel
halt irgendwie markdown formatierte Dateien, die mir
generelle Informationen, allgemeine Informationen über
das vorliegende Projekt, also völlig unabhängig davon, was
jetzt gerade die Aufgabe ist, an der gearbeitet wird, die.
Diese Informationen kannst du immer gebrauchen.
Das sind einfach Dinge, die ich auch in mein Projekt mit
einchecken kann, die auch ein lebendiges Projekt sind.
Wenn irgendjemand eine Version updatet, dann wird auch kurz in
diese Datei reingegangen und das versions Update da da vermerkt,
wenn ich merke, dass mein Chatbot oder mein KI Agent immer
irgendwie einen häufigen Fehler macht, dann wird das damit
reingeschrieben um zu vermeiden, dass der nächste das nicht
macht. Das ist ein lebendiges Dokument,
das im Team bearbeitet wird. Was mir dann aber helfen kann,
eben jedes Mal projektrelevante Informationen von Tool, also von
Guitar, copil, Cursor und so weiter automatisch in diesen
Kontext mit reinpacken zu lassen, dass ich das nicht jedes
Mal irgendwo copy pasten muss oder mit reinpacken muss,
sondern dass die Dinger eben automatisch hinzugefügt werden.
Und dann hattest du ja gerade noch gesagt, ich kann häufig in
diesen Tools auch die Chat Historie kuratieren.
Ich kann bestimmte Dinge rausnehmen, die nicht so
relevant waren, um es wirklich präzise zu beschreiben und was
dann natürlich noch. Ganz wichtig dazu kommt, ist
meine Spezifikation. Im Idealfall habe ich die schon
seit vielen Jahren total präzise gemacht, mit irgendwie
Definition of done Success Cry Terrier, also im Rahmen meiner
klassischen Softwareentwicklung für menschliche Developer alles
so präzise wie möglich beschrieben, aber spätestens
jetzt wird es wichtig, im Rahmen dieses Kontext engineerings
diese Informationen dann auch präzise vorzulegen und die
liegen dann vielleicht nicht in meiner.
Im Repository, sondern die liegen dann.
Du hast es vorhin gesagt, zum Beispiel in einem JIRA Ticket
oder einem Gitarre issue und dort liegt dann wiederum ein
anderer Teil des Kontexts, der genau beschreibt, wo wir
hinwollen und diese Sachen, die brauchen wir natürlich nicht
komplett selber schreiben. Im Idealfall haben wir das
ohnehin im Team auch so ein bisschen aufgeteilt, wir haben
irgendwie den Teil den die Software Engineers machen, einen
anderen Teil, den vielleicht eher Produktmanager machen, aber
natürlich auch bei diesen. Teil, der das Ziel beschreibt.
Da kann ich natürlich wiederum auch auf die Hilfe von KI Tools
zurückgreifen, um das möglichst präzise zu machen und um
natürlich auch die manuelle Arbeit zu reduzieren.
Das in dieser Art und Weise zu beschreiben, wie wir es vorhin
am Beispiel von Opi hatten, wie die.
Quasi uns gesagt haben, wie man einen möglichst guten prompt für
die o 1 o 3 Modelle schreibt. Das kann man natürlich auch über
ein KI Tool sich entsprechend in diese Struktur bringen lassen
und das dann wiederum in so ein Spezifikationsdokument
übertragen. Genau, was Malta da gerade so
ein bisschen meint, ist KI zu benutzen, um Prompts für KI oder
bessere Prompts für ki zu schreiben.
Das ist ganz spannend, das kennen wir schon so ein bisschen
aus der Bildgenerierung. Also es ist ganz oft, wenn ich
irgendwie mir ein Bild generieren möchte, wo ich sage,
Hey, ein Foto von mir, wo ich vielleicht mit einem Hemd,
Krawatte und einem Anzug vor einem Bürogebäude stehe, weil
ich das vielleicht für meine Bewerbungsmappe brauche, dann
kann ich ganz oft diese Anforderung an Chatibity geben
und sagen, schreibt mir mal einen guten
Bildgenerierungsprompt dafür und das Ding geht dann los und
beschreibt mir 16 zu 9 folgende kameraaufnahme unscharfer
Hintergrund. In professionellem
Fotografiestyle bei der und der Tageszeit und so weiter also
bläht den prompt so ein bisschen auf mit relevanten Informationen
und die ich gar nicht gekommen wäre.
Ja, da sind dann auch so Informationen drin, die ich
vielleicht gar nicht geben könnte.
Zum Beispiel irgendwie eine Blende Brennweite, wenn es so um
Fotos geht. Und genau das kann ich natürlich
dann auch übertragen und auch zum Beschreiben von solchen
Software Spezifikationen in der KI gestützten
Softwareentwicklung nutzen. Genau.
Da wer sich das tiefer mal angucken möchte, da gibt es
gerade so ein Vorschuss, das heißt PR, PS, das steht für
Product Requirement Prompts, und das ist so ein bisschen
angelehnt an PR. Dies also Product Requirements
Definitions, die kennt man vielleicht schon.
Die beschreiben eigentlich so ein bisschen, was ein Produkt
machen muss oder auch ein einzelnes Feature und warum ein
Kunde das brauchen könnte. Die sind aber ganz klar so, dass
sie versuchen zu vermeiden, zu beschreiben, wie jetzt ein
bestimmtes Feature gebaut werden soll und diese Product
Requirement Prompts die. Die nehmen jetzt quasi so ein
klassisches PRD und quasi schießen einen KI Agenten mit
diesem PRD auf eure Codebasis los und versuchen dann so ein
bisschen so eine, ja die nennen das ein bisschen codebase
Intelligence da mit rein zu nehmen.
Das heißt sie schauen sich an okay das ist das Feature weil
was beschrieben wird aufgrund von dieser codebasis glaube ich
jetzt selber herauszufinden, was vielleicht relevante Dinge sind,
also relevante Dateien sind, die wir in den Kontext mit
reinziehen, vielleicht aber auch so ein so ein Runbook, also so
eine to do Liste. Die irgendwie abgearbeitet
werden muss. Das heißt, da versucht die KI
erstmal zu erkennen okay haben wir Tests in diesem Projekt Unit
Tests vielleicht aber auch irgendwie end to end ui Tests?
Wenn ja muss ich auf jeden Fall schon mal einen Eintrag Unit
test und einen Eintrag end to end ui Test schreiben mit in
diese Taskliste aufnehmen mit was für Technologien arbeiten
wir hier? Ah okay guck mal du hast alles
irgendwie scheinbar in Komponenten gekapselt also.
Zumindest in der vielleicht Komponenten, also schreibe wem
schon mal in die to do Liste wahrscheinlich neue Komponente
dafür bauen oder bestehende Komponente bearbeiten müssen und
so weiter das heißt da geht ein KI Agent mit diesem mit dieser
Product Definition los über eure Codebase und schreibt daraus
einen noch detaillierteren prompt und erst wenn das fertig
ist das. Dann wird das quasi als prompt
für den finalen Coding Agenten mit Reingegeben und wie weit er
gerade schon gesagt hat, das schreiben wir in der Regel nicht
mehr selber. Da gibt es jetzt quasi KI
geschützte Tools für die diesen promptheim halt irgendwie
schreiben. Also ki schreibt Prompts für
eine andere KI, das ist so ein bisschen Inception mäßig, wer
sich das mal angucken möchte, Product requirement Prompts
heißt das haben wir auch einen Link in der Beschreibung von der
Folge mit reingepackt. Das sind ja jetzt in Summe diese
ganzen Informationen, die relativ statisch reingehen.
Aber natürlich werden auch Informationen dynamisch
abgerufen. Das heißt, wenn jetzt mal ein
entsprechendes Llm bestimmte Informationen aus meinem Projekt
braucht, findet eine Suche über das Projekt statt, es kann eine
Internetsuche stattfinden, es können Tools zum Beispiel über
MCP Server, Wir hatten letztes Mal ja auch über diese context 7
gesprochen. Findet dann eine entsprechende
Suche hier statt und hier können dann halt über verschiedene
Tools hinweg dynamisch Informationen ergänzt werden.
Aber natürlich dieses rein dynamisch automatisierte ersetzt
jetzt nicht das statische, was wir vorhin beschrieben haben,
sondern es ergänzt es um zusätzliche Informationen, die
für die Lösung des Problems relevant sind und auch da können
wir natürlich das Ganze. Ki Tool in die entsprechende
Richtung dirigieren. Wir hatten vorhin gesagt, man
kann zum Beispiel auch hinterlegen, welche Werkzeuge
eingesetzt werden sollen oder welche zusätzlichen
Informationen abgerufen werden sollen und am Ende fließt das
dann mit in den Kontext und bietet damit entsprechende eine
entsprechende Information zur Lösung des Problems.
Ja, vor allem auch an der richtigen Stelle, weil alles,
was wir gerade besprochen haben, ist ja eher so so, das sind die
ganzen Infos und jetzt lieber Agent Lauf mal los.
Aber wir haben ja eben schon gemerkt, dass es meistens in
ganz, ganz vielen Schritten in so einer sogenannten Agent Loop
eigentlich abarbeitet wird. Oft geht der Agent als erster
Schritt, bevor überhaupt irgendeine Zeile Code schreibt,
hin und schaut sich das Projekt an und so weiter und sofort,
aber wir geben quasi einmal nur so Info mit und manchmal, wenn
wir so einen Human in The Loop Prozess haben, dann fragt er
auch noch mal nach, aber was jetzt diese dynamischen Tools
natürlich können, ist zum richtigen Schritt.
Oder an der richtigen Stelle noch weitere Informationen in
den Kontext mit Reinzugeben, ohne dass wir als User da
interagieren müssen. Und das geht zum Beispiel über
sowas wie Rack Retrievel Augmented Generation ist eine
Technologie, wo quasi haben wir auch schon mal eine eigene Folge
zu gemacht, wer das mal im Detail nachhören möchte, aber es
ist eine Technologie wo ich quasi eine Wissensdatenbank
durchsuchen kann, aber keinen genauen Texttreffer haben muss,
sondern auch irgendwas was semantisch zusammengehört mir
irgendwie rausziehen kann und das geht natürlich auch auf
einer Codebase, dass ich sagen kann okay für diesen Schritt
geht. Jetzt würde ich gerne mal
wissen, zeig mir alle coding Dateien wo es um dieses oder
jedes Thema geht an oder dass ich eben über MCP Server
arbeite, die nicht nur wie context 7 mir die Dokumentation
reinholen können, sondern die vielleicht auch wirklich mit der
Auswelt interagieren, indem sie eine API aufrufen, indem sie
vielleicht ein Weiteres eine E shue Beschreibung sich von
github runterladen, indem sie einen Pull request stellen,
indem sie vielleicht auch irgendwie einen Menschen
anpingen. Da sind ja der Fantasie ja keine
Grenzen gesetzt und da ist irgendwie spannend, dass wir
dann eben diesen Agenten die Möglichkeit geben.
Selber zu entscheiden, dynamisch weiteren Kontext nachzuladen,
der vielleicht auch nur für diesen einen Schritt interessant
ist und der vielleicht auch danach wieder aus dem Kontext
rausgeschmissen wird, sobald dieser dieser Schritt bearbeitet
wird. Man kennt das so ein bisschen
von diesen Deep Research Modellen, die im Prinzip auch
nichts anderes als ein Agenten Framework um ein KI Modell
drumherum sind, die gehen dann hin und lesen ganz ganz viele
online Quellen und packen dann aber nach dem Lesen nicht die
gesamte online Quelle in den Kontext, dann vielleicht nur
eine. Eine Zusammenfassung davon oder
die wichtigsten Punkte oder die Sachen, die jetzt verwendet
wurden und so weiter und schmeißen quasi dann nach dem
Lesen diese Quelle auch wieder raus.
Und genauso ist im Coding dann halt auch vielleicht wichtig.
Brauche ich vielleicht diesen einen Schritt einmal um das
Testing Framework rauszuholen, gucke ich mir einmal deine
package Punkt json an um zu wissen, was hast du denn für
Pakete installiert, danach brauche ich die aber vielleicht
nicht mehr im unbedingt Kontext und sich das dynamisch
reinzuholen über so Memory Funktionen die KI s haben über
RAG. Über MCP Server haben jetzt vor
allem auch schon mal eigene Folgen gemacht.
Das kann eben dann wichtig sein, im richtigen Schritt den
richtigen Kontext noch mal nachzuladen, passiert dann aber
wie gesagt, wenn man selber Agenten baut, muss man das
selber bauen, wenn man jetzt einfach nur Agenten benutzt, wie
zum Beispiel sowas wie wie ein Gitter co Piloten, dann machen
diese Tools das in der Regel für mich automatisch.
Und ich glaub, wir haben das jetzt versucht, so auf so einem
relativ abstrakten Level zu beschreiben, weil das natürlich
in jedem Werkzeug, dass ihr einsetzen bisschen
unterschiedlich ist. Die machen es alle natürlich
ähnlich, man lässt sich voneinander inspirieren.
Und viele nehmen einem natürlich diese Coding Werkzeuge auch ab.
Aber es ist ganz wichtig zu wissen, was bedeutet es
grundsätzlich einen guten Kontext bereitzustellen, dann
muss man sich natürlich ein bisschen mit der Dokumentation
des eigenen Tools beschäftigen, wie sieht denn jetzt so ein
Format aus, wo kann ich dort vielleicht so einen Kontext file
oder entsprechend solche Custom Instructions hinterlegen, wie
funktioniert das mit meinem Tool, wie kann ich dann am
besten auch meinem. Agenten sagen, dass bestimmte
Informationen dynamisch abgerufen werden können.
Welches ist vielleicht auch die richtige Herangehensweise für
ein bestimmtes Sprachmodell? Wir hatten ja vorhin darüber
gesprochen, jedes Sprachmodell funktioniert ein bisschen anders
und dann kann natürlich auch die Art und Weise, wie man diesen
Kontext zusammenstellt oder wie man vielleicht so eine Custom
Instruction formuliert, sich ein bisschen an.
An dem Sprachmodell orientieren, was ich vielleicht in meinem
Alltag am häufigsten einsetze. Was ich ganz spannend finde,
ist, man kann natürlich auch sprachmodelle so ein bisschen in
eine bestimmte Richtung bewegen, gerade wenn man so ein
günstigeres Modell hat. Wir sehen das bei einigen Tools,
wo dann vielleicht ein Basismodell nur zur Verfügung
steht, welches ich unlimitiert nutzen kann und bestimmte gute
Modelle wie irgendwie die. Die Cloudsonet 4 oder die Google
Germany Modelle kosten dann on top.
Da möchte ich vielleicht dieses Basismodell noch mit umso
besseren Informationen versorgen um halt die Qualität so ein
bisschen näher an diese. Teurere Modelle ranzubringen
also. Wie gesagt, das ist je nach
Werkzeug was ich einsetze ein bisschen unterschiedlich,
deswegen haben wir es da natürlich in dieser Folge so ein
bisschen abstrakt halten müssen. Wir packen euch noch mal ein
paar Links in die Show Notes, die das ganze Thema des Kontext
engineerings oder generell dieses.
Wie kann ich die richtigen Informationen an das
Sprachmodell in der Softwareentwicklung auch
zusammenstellen? Noch mal beschreiben, wenn ihr
ein bisschen tiefer in das Thema einsteigen möchtet und dann ist
natürlich der nächste Schritt für euch zu schauen, wie
funktioniert das in dem Tool eurer Wahl, da können wir euch
keine genauen Hinweise geben, sonst müssten wir eine Folge für
jedes Tool machen und ich glaube das ist an dieser Stelle nicht
so zielführend. Uns war auf jeden Fall wichtig,
die. Wichtigkeit die Relevanz von
diesem Kontext Engineering euch nahezulegen, also sozusagen,
wenn die KI nicht die Ergebnisse liefert.
Ihr wollt, vor allem wenn sie halluziniert, da liegt das in
bestimmt 90% der Fälle daran, dass sie selber nicht die
richtigen Informationen hatte und.
Idealerweise seid ihr selber dafür verantwortlich oder sind
wir alle dafür verantwortlich, diese richtigen Informationen
mit Reinzugeben? Ja, es gibt Technologien wie RAG
oder auch manche MCP. Server, über die das.
Ki Modell, das dann selber herausfinden kann, dynamisch
aber noch mal alles was ich schon weiß was relevant sein
könnte, gerade im Coding Dateien Ordner Library I ds.
Wenn ich die manuell mit Reingeben kann ist schon ganz
ganz viel geworden. Vielleicht lachen wir in 2
Jahren drüber und sagen, heute sind die Modelle so intelligent,
dass sie das eh alles automatisch hochpräzise ohne
Fehler zu machen rauszufinden. Stand heute aber nicht.
Stand heute ist context Engineering eigentlich so der
wichtigste Teil, wenn ich so einen Prom Bauer, dass ich
innehalte und mir Gedanken mache, was sind die
Informationen die ich dem Modell mit zur Verfügung stellen muss,
neben all dem, auf das es ja ohnehin schon trainiert wurde
und das zu kuratieren sich da auch vielleicht ein paar Minuten
Zeit zu nehmen, da kurz inne zu halten, auch gerade in so einem
Coding Tool und zu überlegen, ja was sind denn Dateien die ich
vielleicht einem Menschen wie malte das vorhin gesagt hat,
fand ich eigentlich cool, mitgeben würde sagen, Guck doch
mal da und da und da. Und das vielleicht schon mal mit
Reinzugeben hat eine sehr, sehr hohe Wahrscheinlichkeit, euch
noch bessere Ergebnisse zu liefern und das ist zumindest
was was malte und ich gerade viel auch miteinander
diskutieren, dass wir sagen, Hey okay, wie kann ich zu einem
Coding Agenten, der ganz offenbar viel Potenzial hat,
aber auch ganz offenbar manchmal noch ganz viel Quatsch macht und
einen Fehler macht, besser in die richtige Richtung lenken und
die Industrie scheint sich gerade zumindest ein bisschen
darauf eingeschlossen zu haben, dass je besser der Kontext ist,
desto besser sind die Ergebnisse und wir können das zumindest aus
unserer Erfahrung bestätigen. Freuen uns aber auch, wenn ihr
da vielleicht irgendwie Erfahrungen schon zugesammelt
habt und das mit uns und auch mit allen hier in der Community,
vielleicht sogar in den Kommentaren teilen wollt.
Ja, und wie wichtig auch so ein guter Kontext ist und auch die
Unterstützung durch uns menschliche Entwicklerinnen und
Entwickler sieht man auch in manchen Beispielen, die im
Internet kursieren, wo dann solche Coding Agenten sich
vielleicht auch in irgendwelchen Schleifen verfangen, weil die
entsprechenden Informationen fehlen oder vielleicht auch.
Verzweifeln, weil sie bestimmte Bugs gar nicht lösen können.
Weil zu viele Informationen sind, haben wir auch.
Dann konnte ich auch zu lang werden.
Ich pack da mal einen entsprechenden Link in die in
die Shownotes rein zu einem ganz spannenden Artikel, wo halt auch
wirklich so ein Gemini Pro basierendes sprachmodell sich
tatsächlich in so einer Schleife verfängt und am Ende wirklich an
den eigenen Fähigkeiten zweifelt und schon sagt, Ich muss mich
selber löschen, weil ich zu dumm bin dieses Problem zu lösen,
fand ich sehr amüsant. Lest euch das auf jeden Fall mal
durch, aber das. Zeigt halt, dass wir auch
gemeinsam mit diesen Tools arbeiten müssen und dass wir uns
nicht darauf verlassen können, dass wir einfach nur eine
Aufgabe da reingeben und dann wird das schon auf magische Art
und Weise passieren. Was mich persönlich
interessieren würde ist, ob ihr schon angefangen habt, eure
Projekte für diese KI gestützte Entwicklung vorzubereiten, um
halt solche wiederverwendbaren Informationen im Projekt
abzulegen und damit halt. Anderen und euch selber die
Möglichkeit zu geben, einfacher Context Engineering zu
betreiben. Ich würde dann mal auf Spotify
zumindest eine Umfrage an die Folge dranhängen, wo ihr dann
mal sagen könnt okay, wir machen das schon oder ich habe gerade
mal damit angefangen, würde mich auf jeden Fall interessieren.
Und wie immer gilt natürlich auch, wenn euch die Folge
gefallen hat, dann lasst uns gerne eine gute Bewertung da sei
es auf Spotify, auf Apple Podcast, wo auch immer ihr
Podcasts hört, wenn man da Sternchen oder Däumchen
hinterlassen kann. Dann freuen wir uns immer sehr
und sehr freuen wir uns natürlich auch immer, wenn ihr
uns einen Kaffee ausgeben möchtet.
Dazu findet ihr einen Link zu bei mir Coffee in den Shownotes,
da sind wir immer sehr gerührt und wir werden ein paar
Eiswürfel reinschmeißen und dann hilft es uns zumindest auch in
diesen heißen Tagen durch den Sommer.
Und natürlich würden wir uns auch freuen, wenn ihr nächste
Woche wieder dabei seid, wenn wir die nächste News folge des
to do developer Podcast aufnehmen.
Die nächste Themenfolge gibt es dann wie üblicherweise in 2
Wochen wieder. Bis dahin habt eine gute Zeit,
schreibt ganz viel Code, Kurt euren Kontext und bis bald.