Latest / Beyond Vibe Coding / #056 Human, batteries-included toolset für AI Engineering - mit Stephan Schmidt
Transcript
- Stephan: on my Machine. ⁓ Sebastian: Sehr gut. Es ist doch schön, wenn sich bestimmte Dinge einfach nicht ändern. Herzlich willkommen zur zehnten Beyond Vibe Coding Episode vom HMZE Podcast. Diesmal ein altbekannter Gast und zwar ist Stefan Schmidt wieder dabei in einer sozusagen Special Edition heute, denn er arbeitet derzeit an was neuem, sehr, sehr spannendem, was wir heute ein bisschen näher beleuchten wollen. Wir werden uns deswegen auch so ein bisschen das übliche Vorgeplänkel, also Stefan, stell dich doch mal vor und womit arbeitest du gerade sparen? Das könnt ihr euch in der Episode sozusagen vom Beyond Vibe Coding von vor zehn Wochen anhören. Heute gehen wir direkt aufs Eingemachte. genau, bevor wir da einsteigen, erstmal herzlich willkommen, Stefan. Schön, dass du wieder da bist. Stephan: Ja, sei gönn'e. Sebastian: wir sind ganz neugierig, denn du hast ja vor kurzem, ich weiß gar nicht, was ich das erste Mal mitgekriegt habe, wahrscheinlich letzte Woche dein neues Tool, würde ich mal sagen, human. angefangen zu präsentieren. Ich habe es mir vorhin mal angeguckt oder auch gestern schon mal bisschen reingelesen. Klingt alles sehr, sehr spannend, aber es macht natürlich viel Sinn, wenn es mit den Worten des Creators vorgestellt wird. Genau, erklär doch mal kurz deine Gedanken dahinter und was es kann, was du dir dabei gedacht hast. Stephan: Creator, super Stichwort. Also was habe ich mir dabei gedacht? Ich habe, es kommt aus einem gewissen Need, aus einem gewissen Bedarf heraus ein Tool, ⁓ mit dem Ziel letztlich secure Cloud Code nutzen zu können, nach Möglichkeit in einem YOLO Mode, weil man ja nicht dauernd Ja, Ja, Ja sagen will oder weil man nicht dauernd irgendwie Ja zu so lange in Python-Proms sagen will. Darf ich den ausführen? Ja, nein, ja, weiß ich nicht. Weil 20 Zeilen Python verstehe ich jetzt auch nicht so schnell. Da kommt es so bisschen her. Und ich habe mir die Tools angeguckt, es da in dem Bereich gibt und war aber mit denen nicht ganz happy und habe dann somit angefangen, human zu bauen, was im Prinzip anfängt als Def-Container, ein einfaches Setup für den Def-Container. Das heißt, sage, mach human in it und dann habe ich am Ende den Def-Container. Jetzt hat man aber mit dem Dev-Container sehr viele Probleme. Das heißt zum Beispiel Cloud Chrome geht nicht so richtig, MCPs gehen nicht so richtig, alles von drinnen nach draußen, harpert immer. Also habe ich gesagt, okay, dann muss man das irgendwie auch machen mit dem Proxy und der Firewall. Und dann geht es aber auch letztlich dann darum, zum Beispiel ⁓ den Kontext zu managen, also wie komme ich an meinen Gyro ran, wie komme ich an meinen Linear, Shortcut, Notion und so weiter ran. Und daraus hat sich dann etwas ergeben. zu sagen, okay, ich mache human in einer Art und Weise, dass es alles ist, was man braucht, also eine secure Umgebung, der Kontext, Connectors und so weiter und so fort. Und dann nur noch Cloud Code, was da drinnen läuft. So ein Rails für AI Entwicklung, also alles battery included. Sebastian: Ja cool, ist tatsächlich auch wirklich sehr spannender Ansatz, weil genau das wünscht man sich ja immer, wenn man irgendwie mit so Tool arbeitet, dass man benutzen, Asana, Notion, dass man das alles connectet und dann auf das ganze Wissen zugreifen kann. Genau und ja, bei dir also Dev-Container, ich nehme an gewählt insbesondere, man meint es ja auch YOLO Mode, ⁓ Security zu gewährleisten vermutlich. Stephan: Genau, also dass einfach Dateizugriff limitiert ist auf das aktuelle Arbeitsverzeichnis und nicht auf andere Sachen und in Kombination dann eben mit einer Firewall, sprich slash proxy, auch nur zu kontrollieren auf welche Webseiten oder URLs Cloud Code drauf... Sebastian: Mmh. André Neubauer: Ich hätte es ja am Wochenende angeschrieben und das auch für mich als Wochenendprojekt mal durchprobiert und war begeistert, hatte er ja gerade schon ein bisschen Vorgespräch gesagt, also ehrlich gesagt würde ich erwarten, dass das für jeder halbwegs Enterprise-grade-Company so bisschen das Default-Setup ist. Als ich es gesehen habe, gedacht, ja... Das müsste man, also so müsste es eigentlich sein und gleichzeitig habe ich es noch nirgendwo anders gesehen. Du hast gerade gesagt, du hast dir ein paar Sachen angeschaut, die nicht funktioniert haben, auch so für die geneigten Zuhörer. Wie würde man es dann ansonsten machen? Stephan: Naja, man würde sich wahrscheinlich diverse MCPs installieren, braucht dann aber gegebenenfalls Tokens, dann muss man sich überlegen, kriegt die AI den Token oder nicht. wenn wer schon mal den Token in die AI kopiert hat, wird vielleicht feststellen, dass er das in, oder Cloud Code, dass er das in den Memory gespeichert hat und dann drei Tage später sagt, ach ja, ne funktioniert nicht, aber ich hab da noch den Token, ich und Curl, ich kann doch jetzt einfach mal selber rum basteln. Also die AI ist so richtig eager, zu machen. Und wenn sie irgendwo noch mal einen Token findet, den sie schon mal hatte, dann macht die ganz komische Sachen. Also man müsste das kontrollieren in dem Def-Container. Es gibt Tools dafür, also One-CLI zum Beispiel, um sowas zu managen. Aber es sind halt lauter verschiedene Tools. ich glaube, die ich mir alle zusammen suchen muss, die ich konfigurieren muss, Was dann manchmal auch nicht ganz funktioniert oder nicht ganz reibungslos funktioniert. was vielleicht auch noch geht, wenn ich jetzt sozusagen Freelancer-Programmierer bin, aber in einem Corporate-Umfeld will man nicht irgendwie zu allen Entwicklern sagen, jetzt installiert euch mal bitte diese sieben Tools und konfiguriert die oder dann irgendwie eine config, aber ohne Tokens irgendwie im Repo haben und so. Also es ist halt das halbe und nix ganzes. Und ich will einfach irgendwas, was einfach funktioniert. Weil mich geht es ja auch ⁓ diese Sachen gar nicht. Also ich will ja eigentlich nur, dass Claude läuft, safe läuft und macht was es soll. Den Rest will ich ja gar nicht. Ich will mich ja nicht mit diesen Tools beschäftigen. André Neubauer: Übrigens hast du über die Wochen diesen Unterbau gebaut. Auf der Seite steht das Secure Developer OS for AI-Empowered Engineering. Kannst du, magst du das Zielbild teilen, wenn es denn ein Zielbild schon gibt? Stephan: Das Zielbild ist alles außer Cloud Code. Also du brauchst Human und Cloud Code und dann kannst du letztlich Cloud Code sicher laufen lassen in dem Environment, wo es den Kontext Zugriff hat und so weiter und alles was es braucht. Das ist sozusagen das Zielbild. Ist jetzt wenig inspired vielleicht, aber ist halt ultra pragmatisch als etwas, was halt dann einfach funktioniert. Es hat auch bisschen noch Prompting drin. Es hat auch Custom Prompts, denen ich arbeite. Also so dann, als Good Review oder Ticket. Weil die Idee war dann auch nochmal, wenn ich sowieso Connectoren habe an Chira Linear Shortcut, dann kann ich auch Prompts nehmen, die sozusagen einen Plan nicht lokal nur haben, sondern ein Ticket draus erzeugen oder so was, was dann auch im Corporate-Umfeld nochmal das Thema Audit und Traceability. adressiert, was es ganz eben auch nochmal adressieren kann. oder soll. Also, es ist vielleicht so schwierig zu fassen. Also, alles in einem Tool. Sonst brauchen wir nichts. Außer Plugboot. André Neubauer: Ja alles hinter einem er stimmt tool ja so eine art proxy im endeffekt also so ein layer und im zweifelsfall auch wegwerf umgebung. Stephan: Es ist schon ein bisschen wie ein Operating System. ist natürlich ein Wortspiel auch auf das, dass heute alles Operating System ist, wie wenn jemand sagt CTO Operating System, wenn er sich drei To-do-Listen macht. Aber es ist schon auf einer gewissen Ebene, weil es hat eine Control-Plane. Also das heißt, man sieht, welche Cloud-Instanzen laufen, ob die busy sind, nicht busy sind. Man kann denen prompt automatisch zuweisen oder Tickets zuweisen. Also sozusagen ein bisschen eine Art Scheduler. Die Konnektoren kann man sich auch Prinzip ein bisschen wie ein Filesystem vorstellen. Also es ist schon ein bisschen in die Richtung auch Operating System auf einer höheren Ebene mit Cloud Code sozusagen als Exekutor im KAN. Sebastian: Ja, mich erinnert das tatsächlich von der Herangehensweise sehr an Pi. Das ist ja mein Agent of Choice da, also A, gibt es halt auch ein Ökosystem, was viele dieser Dinge auch mitbringt, also eigene CLIs für genauso Tokenmanagement. Dann, du hast ja auch bestimmte Skills dabei, die so einen Workflow abbilden, so einen typischen Development Workflow, also Ideate Plan. dann execute und review und so genau das das gibt es da auch und das also nutze ich tatsächlich auch sehr intensiv bei pi und genau also insofern würde ich pay sozusagen als fast größten konkurrenten ansehen weil da kann man natürlich auch so also skills extensions und so packagen und dann als ein bundle ausrollen also ich glaube es gibt sogar speziell von so bestimmte packages man kann sich da auch extensions bilden bauen. das geht natürlich nicht, wenn man mit Cloud arbeitet, dann zumindest es dann sehr teuer ist, weil man dann nur API mietet, Cloud nutzen kann. Und genau, dafür ist natürlich Human eine sehr, gute Alternative, wenn man das mit Cloud machen möchte. Stephan: Also ganz genau, ich weiß jetzt nicht, ob ich das sagen sollte in dem Podcast, aber ich weiß natürlich nicht, was ich tue. meine Herangehensweise ist schon über die letzten Monate auch zu sagen, wir sind im Wilden Westen und wir wissen jetzt nicht, ist es besser, Kühe zu züchten, Gold zu graben, Schaufeln zu verkaufen oder Schuhe herzustellen. Ganz genau weiß es aktuell keiner. Und ich will halt nur Cloud Code auf jeden Fall haben, ich davon, weil ich rein der persönlichen Meinung bin, dass Cloud Code mit Abstand das Beste aktuell ist, ⁓ Code zu entwickeln und Review zu machen und Bugs zu finden und alle diese Dinge. Aber genau wo hingeht und wie sich diese Tool-Landschaft entwickelt und was wir am Ende brauchen werden, weiß ich natürlich auch nicht. Aber ich will mit dabei sein, das auszuprobieren. André Neubauer: Ja, ich glaube, das geht so ein bisschen zurück auf das, was wir mit Markus irgendwann mal hatten. musste er quasi ausprobieren, rumfummeln. Ich glaube, das hat er gecoint. Das, ich mich in dem Zusammenhang so bisschen frage, ist, dass wir so gerade meinen, ist so Entwicklungsumgebung. ist das etwas, was man perspektivisch eher zentral sehen würde? Sebastian: Ja. Stephan: Ja, kann ich mir vorstellen. André Neubauer: als wir beide noch Software geschrieben haben, da hat das dem Entwickler gehört. Das war sehr individuell, da gab es das Eclipse-Lager, JetBrains-Lager und so weiter und so fort. Die Frage, die ich mir auch stelle, inwiefern wird das stärker zentralisiert? Inwiefern wird das auch etwas, was die Firma einfach zur Verfügung stellt und dann musst du da drin arbeiten? Stephan: Ja, also quasi wie IntelliJ. Also die Frage ist, also war ja quasi lange Zeit der Standard in vielen Unternehmen. Am Anfang 2000er, viel Diskussion im Java-Bereich, IntelliJ, NetBeans, Eclipse, was weiß, und so weiter und so fort. Dann hat sich das aber ziemlich stark eingeschränkt auf IntelliJ. Dann kam irgendwann VHS Studio als kostenloses Tool. Aber ich glaube, dass wir Tool-Kategorien bekommen werden. Ich versuche mit human eine Kategorie zu schaffen. Ich weiß noch nicht genau, wie die aussieht, aber ich glaube, wir kriegen neue Tools und auch die Unternehmen wollen dann letztlich am Ende ein Tool haben oder ein standardisiertes haben, was ein No-Brain ist. Sinne von No one has been fired for buying IBM. Das ist immer noch so, glaube ich, in Unternehmen. Und wenn wir wenn wir gucken im Umbruch. sage ich mal, was ich so sehe mit den Firmen, mit denen ich arbeite und den Inflägen, ich arbeite, ist, dass halt immer mehr Leute keine IDE und kein Cursor mehr verwenden, sondern in Cloud Code CLI arbeiten und dort sagen, mach das und das und das und dann vielleicht noch den Review machen. Vielleicht haben sie ZDD offen, Z-Ed offen oder irgendwelche Sachen. haben sie noch Visual Studio offen, ⁓ ab und an mal reinzugucken. Aber es gibt, ich sehe schon eine sehr starken Bewegung Richtung Cloud Code CLI oder Open Code. CLE. Also deswegen glaube ich so die IDE als das Entwicklertool ist glaube ich abgelöst. Es sei denn, jemand kommt mit einer ganz genialen neuen Idee. Will ich jetzt nicht in Abrede stellen oder so. Aber wir wissen nicht genau, welche Kategorien an neuen Tools es denn dann eigentlich geben wird. André Neubauer: Ja da bin ich da bin ich da bin ich bei dir ich glaube das quasi das die zeit wo zumindestens der co teil in der ide den den hauptspace eingenommen hat das das denke ich ist auch vorbei es wird wahrscheinlich so würde ich jetzt auch human verstehen dass er so die orchestrierung von vielem das hat irgendwie alles und da also wie so eine kommandozentrale ja also wissen wir alle nicht aber quasi. Sebastian: Hm. André Neubauer: Das ist ein möglicher Weg. Sebastian: Ja, auf jeden Fall. also vielleicht nur ganz kurz und dann darfst du gleich André. Und dass so ein Tooling benötigt wird, ist, ich, auch klar. Ich glaube, deine Intuition, Stefan, die kommt ja daher, dass du gerade dir selber so ein Tooling wünscht und quasi für dich das Tooling geschaffen hat, hast, was du gerne hättest. Und so ähnliche Automationen bauen sich meines Erachtens nachher gerade verschiedene Leute. Neulich auch ein Podcast gehört mit der baut sich auch noch mal ⁓ PIE rum, eine Control Plane gerade. daher, das ist glaube ich zweifelsohne relevant. Die Frage ist, ob das nachher auch alles von Anthropic kommt oder ob es da noch mal extra Anbieter geben wird. Sorry Andre, jetzt habe ich dich unterbrochen. André Neubauer: Ich hatte nichts gar nichts also hat es mich nicht unterbrochen. Vielleicht nur ein gedanke wenn du so ein bisschen so roadmap ich muss trotzdem noch mal fragen vorhin meintest also auf dem os thema so roadmap was was kann man denn noch erwarten also quasi in welche breite willst du das noch bringen also wird das quasi wird das einen technischen fokus quasi behalten oder willst du da man könnte noch einfach den entwicklungsprozess halt hochgehen. Was ist ich inwiefern das halt irgendwie ein benefit ist das halt mit zu integrieren aber hast du da irgendwelche gedanken. Stephan: Ja, es gibt jetzt schon ein Idiate Skill, wo ich mit rumprobiere, aber ich weiß jetzt nicht genau, wie weit das in Richtung Produkt geht oder ich weiß auch nicht genau, wo am Ende die Entwicklung anfängt oder das weiß ich nicht. Ich probiere das aus. In der Breite eher, in die Breite, weil für mich ist natürlich das alles ein Experiment. Wer mitmacht, gut. Also wer es nutzt und ausprobiert, ist super. Aber es ist schon auch ein Experiment im Sinne von Naja, ich kann halt eine Integration an einem halben Tag machen. jetzt eine Integration von Chira oder sowas ist halt ein halber Tag AI-Arbeit. Also geht ziemlich schnell und dann hat es irgendwelche Edge-Cases und dann geht das nicht. Bis es rund läuft, ist halt ein halber Tag. So wenn ich das jetzt vorhand irgendwann mal programmiert hätte, ich vielleicht eine Woche gebraucht, ⁓ den Zustand zu erreichen mit Tests und so weiter. Das heißt, ich kann eben halt auch mit AI sehr viel schneller in die Breite gehen. Ich kann halt sagen, hier gibt es eine Bibliothek oder überlegt ihr mal, wie könnte man das und das anbinden? Dann machen wir da paar Plan iterations und dann habe ich die Integration im Prinzip. Die Frage ist natürlich, wie weit geht es in die Breite? Also wie viel ist da managbar? Also wenn ich jetzt 20 Integrations habe, ich habe 50 Features, ist es noch managbar? Ist es von mir managbar? Das weiß ich alles nicht. Deswegen ist es da auch so ein bisschen. Experiment, wie weit kann man eigentlich als Single-Entwickler vielleicht eben auch so ein Tool machen, was man vorher eben nicht konnte, weil man die Entwicklungsleistung gar nicht auf die Straße gebracht hat. Und die ist jetzt plötzlich da. Aber welche Einschränkungen bringt es dann sonst noch oder gibt es überhaupt welche? Für mich sehr spannend. André Neubauer: Hm. Das ist ein quasi total faires Seitenexperiment, bin ich komplett bei dir. Ich hatte mich am Anfang, als ich das erste Mal ausprobiert habe, gefragt, oder so bisschen zurückerinnert geführt an die Cloud-Zeiten. Sebastian: Mhm. André Neubauer: wo man halt also bevor das halt irgendwie bevor wir halt alle in die cloud gegangen sind war es ja mal so dass man halt immer ein system halt irgendwie aufwärts gepflegt hat man ist ja nie weggeschmissen sondern immer quasi bloß quasi die nächste die nächste generation nächste generation und dann ist man ja dazu übergegangen dass man einfach in weil man es weg schmeißt ich hatte den eindruck gehabt das könnte man ja hier genauso machen das eigentlich deine entwicklungsumgebung zum wegschmeißen du könntest eigentlich sagen für jeden Feature Request für jedes Projekt einfach immer ein neues Environment. Hast du mal in die Richtung gedacht oder wirst du sagen konzeptionell eigentlich eher nicht? Stephan: Konzeptionell eher ja. Es gibt ja auch andere Ansätze. Ich habe vorher sehr viel mit anderen Ansätzen experimentiert. Unter Linux gibt es ja so ein Tool, heißt Bubble Wrap. Da kann ich ein Binary verpacken in dieses Bubble Wrap sozusagen. Dieses Ding, was da knallt. Dieses Packpapier. Und kann denen dann sagen, bitte nur die Dateien lesen oder die Dateien lesen oder oder oder oder. Also es gibt... ⁓ Solche Ansätze Cloud Code einfach sozusagen in so eine Jail zu packen, Jail oder auf Mac gibt es andere Jail Mechanismen. Dann habe ich natürlich trotzdem immer noch die Problematik, wie funktioniert mein Rest meines Environments, also mit die Konnektoren und so weiter und so fort, funktioniert dann Cloud Chrome und so. Aber da sehe ich noch sehr viel mehr sozusagen dieses Wegwerfen. Also ich starte das einmal mit so einer Jail und Dann mach ich was und dann beende ich es wieder. Und dann kann ich es potenziell auch in C.I. laufen lassen oder wie auch immer. Da will ich schon auch hin. Also das ist schon so ein bisschen. Ich weiß noch nicht genau, wo es dann hinläuft, aber irgendwie bisschen in die Richtung. Am Ende vielleicht ja auch. Guck mal, Claude, hier sind die Tickets, hier ist die Production Umgebung. Mach mal. Ich weiß auch nicht, wenn Cloud Code zum Beispiel einfach dann selbstständig von Ticket, also wenn es so gut ist, dass es von einem Ticket desidiated und Lücken findet oder aus einer Strategie Ticket erstellt oder was weiß ich, die nach Production packt irgendwann und 24 Stunden am Tag Features produziert, sozusagen da weiß ich auch nicht, wo es hingeht. Also kann das dann am Ende noch jemand nutzen oder wird das unnutzbar oder muss ich dann wirklich mal sagen, nee. Ich will nur wirklich jedes zehnte Feature, was ich ja schon seit 20 Jahren propagiere, gute Features zu deployen und nicht jedes, einem in Kopf kommt. da verschiebt sich halt sehr viel. Deswegen ja dieses eins pro Feature und vielleicht hier zum Beispiel da ist ein Ticket, macht das mal in production, dann läuft die Umgebung, macht das und dann habe ich das Feature im Live System oder so. Also zu dem, was du sagtest, ja, ich weiß persönlich genau wie. Sebastian: Ja, bitte André. André Neubauer: Ich hätte jetzt nur noch mal gesagt ich finde das halt spannend also ich finde dieses also quasi dieses diese. Wegen der mentalität glaube im real life finde ich es nicht spannend aber halt ansonsten ist halt einfach immer from scratch immer eine neue umgebung immer wieder also das das finde ich. Dadurch, dass es auch virtuell ist und erstmal nicht viel kostet, finde ich es eigentlich eher den strebenswerten Ansatz, weil es eben nicht ein mundgeklöppertes Environment ist, sondern du kannst es immer reproduzieren, es ist immer automatisiert, es ist immer kein manueller Aufwand. Eine Frage dann doch noch, da muss ich mich nochmal dazwischen sneaken, Sebastian, sorry dafür. Der ganze Infrastrukturbereich, also quasi das Deployment, ist da ausgekaft. Sebastian: Alles gut. André Neubauer: zumindest bis jetzt on purpose. Stephan: Ja. Nö. Also für meine Privatsachen, also für meine Webseite oder so was, wo es nicht so viel geht oder irgendwelche, mein Privattool, das irgendwo läuft, für mein Coaching, weil eigentlich verdiene ich ja Geld mit CTO-Coaching und Leuten helfen bei AI-Transitionen, das ist ja meine eigentliche, da kommt irgendwie, irgendjemand muss ja auch bezahlen. Da macht auch die AI relativ viel vom Deployment, also vom CI einrichten, deployen, Probleme finden. sich System-D-Logs angucken, sagen, ja, da ist was falsch, fix ich und so. Also für meine kleinen Sachen, die ohne großes Risiko, sag ich mal, sind, weil keine mir anvertraute Kundendaten sind, die verloren gehen können oder so, macht ihr relativ viel von dem operationellen Betrieb auch schon, ohne dass ich da drauf gucken muss. ja. André Neubauer: Ich fand das halt also ich fand den Gedanken vor was nicht schon längere zeit her für den Gedanken irgendwie spannend dass man diesen Entwicklungzyklus mit dem Produktzyklus halt irgendwie möcht also halt also quasi dass du halt und da passt der Zeit human ganz gut dazu dass halt im Endeffekt die ganze chain die ganzen Entwicklungsprozess. bis in die Produktion rein und das wird halt auch ein sich selbst fütterndes System. Also wenn du da halt irgendwie ein Monitoring drauf hast, also auch ein fachliches Monitoring und dann halt irgendwie du siehst halt, da droppt halt irgendwie eine Conversion Rate oder die ist halt irgendwie nicht gut, dann kannst du halt irgendwie überlegen, ideate, Ist halt irgendwie, was könnte dem helfen? Dann wird das durchgebaut, wird gebaut. Okay, ist nicht besser? Nochmal. damit, also im Endeffekt würdest du damit so bisschen in die Richtung so, was nicht heißt das? Dark Factories? Das ist es, ne? Stephan: Mmh. André Neubauer: Also quasi, dass wirklich der Human im Endeffekt komplett draußen ist, eigentlich bauen. Und ich fand die Idee gut. Für mich ist aktuell noch immer dieses quasi Production Environment irgendwie, on purpose, ich weiß, isoliert. Aber eigentlich, wenn du das halt irgendwie enger zusammenbringst in den ganzen Entwicklungsprozess, gerade mit AI macht das für mich gerade, klar, ein bisschen vorwärtsgespult, ein bisschen mehr Security macht für mich irgendwie total Sinn. Stephan: Also, Human kann ja auch, das ist auch so meine Theorie, was ich auch mit meinen Kunden immer platziere. Human ist auch integriert mit Amplitude zum einen oder mit Sentry zum anderen. Also, ich bin der Meinung, wenn ich jetzt zu sagen, hier, baue mal ein Feature oder mach mal Planning zu dem Feature oder zu Ideation. Und hier ist halt Amplitude. Guck dir mal an, wie uns die Features funktionieren oder welche Features wie funktionieren. Oder guck hier in Sentry, welche Latenzen wir haben. und baut dann was mit dem Input. Ich finde es super generell, super spannend, Sachen zu machen, mit AI Sachen zu machen, die man vorher nicht machen konnte. Mein Beispiel ist so, ich habe irgendwann mal vor ein paar Wochen die AI gesagt, hier sind 1000 Tests, geh mal die Tests durch, analysier die Tests und find Bugs basierend auf den Tests. Und die AI hat halt zwei Bugs gefunden. Also nicht in human, sondern in einem anderen Produkt von mir. Und ... Das hätte ich jetzt nicht dem Entwickler gegeben. hätte nicht gesagt, Entwickler, guck mal 1000 Bugs, 1000 Tests an. Also ich finde es sehr, sehr spannend, Sachen zu machen mit der AI, vorher nicht nur schneller, also den Entwickler schneller zu machen, sondern Sachen zu machen, die vorher gar nicht möglich waren. Wie während der Feature-Entwicklung live in Sentry rein zu gucken oder in Amplitude rein zu gucken für das Planning und die Daten, die Benutzungsdaten mit in den Planungsprozess an der Stelle mit einfließen zu lassen. vielleicht zum Deployment Code noch was. Wir sehen dass die Open, ich weiß gar nicht, wo das alles hingeht. Aber wir sehen ja auch bei, zum Beispiel Tailwind, fast keiner macht ja jetzt, also nein, viele Leute machen jetzt keine CSS Frameworks mehr, weil ich einfach zur AI sagen kann, mach mir da bitte zwei Spalten und dann macht sie zwei Spalten oder macht da unten sticky header, dann macht sie sticky header. So, wenn man das jetzt weiterdenkt. Ich versuche ja irgendwie auch immer weiter zu denken. habe Philosophie studiert auch ein bisschen. André Neubauer: Ja. Stephan: und ich versuche, noch weiter zu denken oder größer zu denken und so, brauche ich AWS. Also brauche ich nicht nur bare Metal. Also ich sage jetzt hier ist bare Metal, so und jetzt baue mal die Applikation da drauf. also die Frage ist, brauche ich halt Cloud auch noch? die nächsten fünf Jahre ja, wenn die AI halt super schnell den Code generiert und Environment generiert und andere Sachen macht, Ja, im Sinne auch von wegwerf. Die Frage, brauche ich AWS oder was brauche ich denn noch an Tools oder Tooling außenrum? Sehr, viel von dem Tooling, was wir haben, was IDE betrifft. Aber was auch AWS betrifft, ist halt human centric. Also jetzt nicht human centric, sondern menschzentriert. Das heißt aus der Blickwinkel, wie kann ich den Job eines Menschen einfacher machen? Was braucht der Mensch, damit er Operation machen kann, damit er Software entwickeln kann? André Neubauer: Ja. Stephan: Und auch unsere Prozesse, Scrum, Dailies und alles hängt am Ende am Menschen. die Frage ist eben für mich, wenn jetzt es alles AI ist, was ist denn wirklich eigentlich alles menschenzentriert in den letzten 20 Jahren und was fällt dann potenziell weg? Sebastian: kommt daher auch der Name des Tools. Stephan: Hm? Äh... Ja, so ein bisschen. Aber im Prinzip auch ein bisschen Wortspielen und bisschen Assi-Mof und so. Also es ist schon... Ja, wenn es dir nicht gut geht. Sebastian: Ja, also vieles von dem, was du sagst, resoniert total mit mir. So verschiedene Punkte. Das eine, was wir auch in der letzten Episode mit Uli von Mapbox hatten, die haben, ich habe das jetzt genannt, kambrische Explosionen von internen Tools. So Sachen, die man früher einfach nicht gemacht hat, weil es einfach viel zu aufwendig gewesen wäre. Die sind jetzt halt einfach wirklich mal so ein Wochenendexperiment oder oder nebenbei gemacht, so in einem zweiten Fenster machst du halt irgendwie alle fünf Minuten, drückst du mal Enter oder beantwortest mal eine neue Frage oder stellst eine. Das ist definitiv ein Punkt, auch zum Thema Infrastruktur. haben gerade den Mentoring Club von Heroku wegmigriert, gibt Tools wie Coolify und irgendwie noch sowas mit Docker im Namen, die mehr oder weniger, also eine ähnliche, ähnliches Automationslevel auf Bare Metal zur Verfügung stellen, wie das Heroku bietet. Von daher und also fairerweise auch Versel, also wir sind von Heroku und Versel weg und haben insofern unseren Kostenfußabdruck wahrscheinlich durch zehn geteilt oder irgendwie sowas. Und das ist, das ist mit AI war das auch so eine Wochenendeaktion halt. Und tatsächlich in dem Falle auch, weil wir da noch kein Live André Neubauer: Well. Stephan: Ja. Sebastian: Betrieb drauf hatten beim Aufsetzen erstmal der Agent ist auf dem Server, konfiguriert fröhlich auf dem Server, liest Lockfiles auf dem Server und agiert da. Das machen wir jetzt nicht mehr. Jetzt ist das schon unsere Domäne und wir haben natürlich auch deterministische Automation jetzt für neue Deployments gebaut, aber initial beim Aufsetzen war das ganz entspannt und auch dann der nächste Schritt, gerade die Tage nebenbei so ein bisschen eine kleine Analyse von so User Journeys gemacht. Der Agent hat halt den ganzen Kontext, der kennt die Datenbanktabellen und mal zu sagen, schau doch mal, was können wir denn machen, sozusagen, ⁓ die Nutzer noch besser abzuholen, beziehungsweise wo sind die denn eigentlich und wo sind so die Heavy-Users, was sind so Patterns? Megagut, da war auch eine Halluzination dabei, fairerweise. Aber der Grundtenor der ganzen Analyse wir dann noch ein Jupyter Notebook bauen lassen und das selber nachvollzogen mit Queries und so. Der war einfach goldrichtig und da haben wir jetzt wieder gute Ansätze. da kommt genau die Frage, wenn du dann wiederum sagst, okay, du stoppst da nicht an der Stelle, sondern du guckst da nochmal drüber und sagst dann, okay, und jetzt mit dem machen wir weiter. wo ist da denn ein Mensch noch nötig? Stephan: Genau. Wo ist der Mensch nötig? eben mit mit mit human das Experiment. Wo ist denn also wo ist denn das Tool nötig? Also wir sehen ja eher so eine Enttoolisierung oder eine diese diese general Tools. Jeder baut sich was eigenes, was er auch sagt. Ich habe mir auch sehr viele eigene Tools gebaut. Für meinen Newsletter, haben sie Tio Newsletter. Da habe ich eben auch schon vor AI, aber mit AI jetzt noch viel mehr. Sebastian: Ja. Stephan: ein Tool gebaut, was mir dann die Markdown-Sachen konvertiert, Links checkt und alle möglichen Sachen macht. Die Frage ist, ist es jetzt so eine Explosion? Wollen die Leute das weiter warten? Muss ich es gar nicht warten? Lässt sich leicht warten, weil ja die AI das wartet. Also ich erinnere mich nochmal an, was ich auf den Leuten immer wieder mal erzähle, ist, wir zwei haben mal auf ganz langer Zeit einen Ruby-Bug gefixt, weil der Ruby-Entwickler nicht mehr da war. Und wir konnten aber bei den nicht Ruby, aber haben es dann hingekriegt. wie ist denn auch dieses Wartbarkeitsproblem? Es geht vielleicht weg oder kommt durch zu viele Tools? Also da weiß ich eben nicht. Ich finde es super spannend, aber ich weiß nicht genau, wo sich denn was hin entwickelt an der Stelle. Und welche Tools bleiben? Bleibt Human? Bleibt es nicht? Bleibt AWS? Ja, keine Ahnung. Also auch vielleicht zu dem Thema. Ich finde AI super für Terraform. Ich fand Terraform ein bisschen schwierig. Ich finde es AI relativ easy. Aber brauche ich Terraform, wenn ich einen neuen Server einrichte und dann auf den Server, also im kleinen Umfeld jetzt, aber in den Server mich einrichte und sage, harten der Server. Und dann sagt er, ich gucke mich mal ⁓ App Armor ist nicht da, SSH ist auf einem Standardport. Ich könnte diese 20 Sachen alle machen. Und dann sag ich ja, mach mal und dann macht er diese 20 Sachen und dann also auch das. Man könnte ja auch dann ein Runbook draus machen, ein Ansible Runbook draus machen oder wie auch immer. ja, da geht es halt wieder darum, welche Tools brauche ich denn oder also Ansible vielleicht ja, aber dann vielleicht kein Nicht Terraform, weil Claude Cotten Ansible Runbook schreiben kann, bedarfsorientiert. Sebastian: Total. Total, das ist super spannend, sehe ich genauso. Also weitergedacht, du hast ja schon gesagt, AWS ist nächsten fünf Jahre auf jeden Fall safe so, weil die Infrastruktur, die darunter steht, die kriegst du ja auch nicht so leicht repliziert. Aber für Sachen, die jetzt gebaut werden und dann vorsichtig wachsen, die können vielleicht auch auf bare Metal dann skalierbare Message-Cues oder was auch immer quasi intrinsisch bauen oder selber bauen. Und es ist genau wie du sagst, auch so ein Coolify. Brauchst es dann überhaupt noch oder habe ich dann einfach nur für meinen spezifischen Use-Case dediziertes Tooling, was einfach die KI selber wartet. Keine Ahnung, kommt irgendwie eine neue Version von irgendwas raus, was ich jetzt deployen will, stell fest, oh mein altes Tool bricht, fixe ich einfach den Fehler im Tool und dann geht es halt wieder so. Dann kann ich es deployen und es läuft 100 Prozent. André Neubauer: Die These dahinter, dass wir eigentlich die ganzen Abstraktionen, die wir für uns Menschen geschaffen haben, wieder jetzt abschaffen. Also alles, was sich so zumindest im Innerloop befindet, das ist schon eine starke These, muss ich ehrlich sagen. Sebastian: Ich meine, das schließt ja an an Stephans Code wird verschwinden. Das ist ja, Code ist ja auch eigentlich nur für Menschen da, wenn du das weiter denkst. Genau. Also wir werden sehen, wohin es geht. Ich sehe aktuell so zwei Strömungen. Die einen sind so komplett Diolo und Code gucke ich mir gar nicht mehr an. Ich mache so Meta-Reviews von den Changes. Und dann gibt es aber auch immer noch die Strömung. Mario Zechner und Co., die sagen, ich gucke mir schon. den Code noch an, weil ich will den verstehen und ich will auch sozusagen im Detail wissen, wie es funktioniert, was ich auch nachvollziehen kann, weil ich immer wieder feststelle an den Projekten, denen ich arbeite, dass ich nach drei Features feststelle, dass das Feature, was ich vor drei Features gebaut habe, gar nicht so gefixt ist, wie ich mir das vorgestellt habe, sondern, weiß ich eher keinen ID-Lookup macht, wenn ich einfach nur einen Wert oder eine Entität rausholen möchte aus der Datenbank, sondern irgendwie so einen Fallback-Mechanismus gebaut habe, weil ein bestimmter Fall nicht funktioniert hat, der aber nicht funktioniert hat, weil die Daten nicht korrekt waren. Das Tool hat dann aber gesagt, ach so, dann mache ich es ein bisschen unscherfer oder beziehungsweise die KI. Und dann funktioniert es schon. Also immer dieses, die faule KI in Anführungsstrichen, also sprich, ich gehe den einfachsten Weg. Also ich finde beide Perspektiven irgendwie nachvollziehbar. ja klar, bitte. Stephan: Aber es eine Entwicklerperspektive, Sebastian, darf ich da kurz rein grätschen. Das ist eine Entwicklerperspektive, der Engineering Manager hat das gleiche Problem. Also ich gehe zu einem Senior-Entwickler und sage, bau das Feature mal und dann baut er das und dann hat er es halt falsch gebaut. Also falsch im Sinne von nicht so wie ich das dachte. Nicht falsch in seinem Sinne oder falsch in dem absoluten Sinne, aber halt anders als ich dachte. Und jetzt macht es die AI. Also für mich ist dann immer die Frage, Sebastian: Ja, Ja, total. Stephan: Ich glaube nicht gerade, dass man einen Code angucken sollte. Vielleicht liege ich da falsch. Das ist jetzt auch nicht meine Firma. Ich habe jetzt keine große Softwarefirma. Ich riskiere nichts mit der Meinung. Ich bin bei der Festung überzeugt, dass es deutlich produktiver ist, wenn man nicht drauf guckt. Ein Kunde hat mich letztens gefragt, was sollten wir machen? Ich höre immer in der Presse, sollten wir 70 oder 80 % AI-generierten Code haben? Die Frage ist, wie komme ich auf 100 %? nicht ob ich 70 oder 80 mache. in dem Umfeld, wie gesagt, ich würde halt immer gucken, also für mich ist so, ich habe einige Best Practices für AI und eine Back Practice ist schon immer, jetzt ein Ticket für einen Implementierungsplan zu bauen aus einem PM-Ticket und dann nachdem alles programmiert worden ist, dann nochmal zur AI zu sagen, so und jetzt guck bitte nochmal dein Gitlog an und guck die zwei Tickets an und ist das, was du da gebaut hast, das, was da vorne gefordert worden ist oder nicht und warum nicht? Und dann gibt es immer auch wieder Diskrepanzen. Und dann sagt er, wie es jetzt so ist, tut mir leid, habe ich übersehen. Ja, richtig, hast du darauf hingewiesen und so weiter und so fort. Aber unterm Strich korrigiert sie sich dann auch oder fragt mich, habe ich nicht verstanden, was soll ich denn eigentlich machen? Sebastian: oder pro. Das ist ein Bestandteil von einem Review Skill, der automatisch vielleicht am Ende des Workflows sogar vor dem Commit selber ausgeführt wird. Also sehe ich, trotzdem, wir haben letzte Woche mit Uli von Medbox gesprochen und da ist auch dieses Thema Ownership without Authorship wieder hochgekommen und bei denen ist ganz klar, Claude schreibt den Code, aber du bist dafür verantwortlich. Also es ist jetzt quasi an jedem Entwickler selber derzeit noch. Die haben da auch, sagen wir mal, eine Mischung aus, die wollen schon, dass die Entwickler ganz viel AI nutzen. Auf der anderen Seite ist aber jeder Entwickler noch für das Feature, für den Code verantwortlich. Und die haben aber auch natürlich sehr, viele Guardrails. Bevor Dinge in Production kommen, müssen sie ja komplexe Bildpipelines und Testpipelines durchlaufen. Nichtsdestotrotz muss da jeder Entwickler für sich selber entscheiden, wie er oder sie das gewährleisten kann, die Qualität des Codes. Stephan: Also für mich heißt auch AI nicht, responsible engineering wegzuwerfen. Du bist trotzdem responsible engineer und wenn du vorher Code geschrieben hast, ungetestet in production gepusht, ich das unverantwortlich. Und wenn du heute das gleiche mit AI machst, ist es auch für mich unverantwortlich. Das heißt für mich haben die Maßstäbe an den engineers sich nicht geändert. Bloß weil sich das Tool ändert. Sebastian: Genau. André Neubauer: Ja. Sebastian: Ja. Genau 100. Genau. Und es ist halt an jedem selbst zu entscheiden, wo, also wie nimmt man die Verantwortung wahr? Das ist genau diese Frieden. Sorry, André. André Neubauer: Genau, das geht. Ich würde sagen, es geht ja nicht ums was, sondern nur ums wie. Da führen wahrscheinlich viele Wege nach Rom. Ich bin aber gespannt, wie sich der Inner Loop, eigentlich gar nicht der Inner Loop, eigentlich der gesamte Software Development Lifecycle, also quasi nach oben auch Richtung Produkt, aber dann auch Richtung Infrastruktur verändert. Und ich habe heute gelernt, und auf der These muss ich bisschen rumdenken, Wenn die ganzen Abstraktionen, die wir für uns geschaffen haben, damit wir das verkraften, diese ganze Komplexität, die braucht man tendenziell nicht. Und das rüttelt schon auch an ein paar Modes, die man vorher nicht mehr gesehen hatte. sag mal, häufig, ich weiß hast du eine Lambda-Function? Versuch das mal irgendwo hin zu migrieren. Und das muss alles muss alles vielleicht gar nicht mehr zukünftig sein. Das ist eine sehr starke These. Hier zuerst gehört. Punkt. Stephan: Ich habe noch was zu dem Punkt vielleicht von Sebastian. Eine meiner weiteren Thesen, ich habe so viele Thesen, eine weitere meine, vielleicht sollte ich irgendwie hier, wie weiß ich nicht, bin ich so bewandert, aber wie viele Thesen? an die 95 oder so. Ich habe keine 95 Thesen, aber ich habe noch eine These und zwar der Engineer, das geht ein bisschen zu dem, was Sebastian gerade gesagt hat, der Engineer wird gebraucht. weil er die passenden Trigger-Words hat. Also, ich hab das Konzept geklaut quasi und verändert ein bisschen. ist von Ralf, der nennt das Semantic Anchors. Macht auch sehr viel auf LinkedIn und der Webseite unter dem Stichwort Semantic Anchors. Muss man sich auf jeden Fall angucken. Die Idee ist, ich hab's ein bisschen vereinfacht, weil ich bin halt einfacher, nicht ganz so intellektuell vielleicht. Bei mir heißt es, ich nenne sie ja Trigger-Words. Und was ist ein Trigger-Word? Ein Trigger-Word ist Sebastian: Hm. Stephan: etwas was ein bestimmtes Verhalten bei der AI triggert. Beispiel meine Beispiele sind TDD ist ein Trigger-Word, Anti-Corruption-Layer, Abstraction-Layer, API oder ABI oder es gibt sogar diverseste Trigger-Words, die man als Engineer hat. Und diese Trigger-Words sind so ein bisschen wie aus Rollenspielen aus AD &D Spells. Man ist ein bisschen wie ein Spellcaster, man hat Geheimwissen. Ich hab diese Trigger-Words als Geheimwissen. Ich kann zur AI sagen, bevor du das Feature baust, mach mal ein Abstraction-Layer. Oder bevor du das tust, oder wenn du das tust, mach doch das Ganze mit TDD. das hat zurzeit noch sehr viel positiven Effekt auf die AI. Und vielleicht in Zukunft nicht mehr. Das geht vielleicht weg irgendwann mal. Aber aktuell, nächsten fünf Jahren, hat der Engineer einen großen Vorteil gegenüber Leuten, nur mit der AI was bauen, mit dem sie dann sehr gut zu einem Prototypenstadium kommen. Aber ich glaube nicht in Production, nicht in Skalierbarkeit, nicht in langfristige Wartbarkeit. ⁓ Skalierbarkeit, langfristige Wartbarkeit und andere Sachen zu bekommen, Erweiterbarkeit, also diese ganzen soften Requirements, braucht man diese Trigger Words, braucht man diese Spells und dann kann man eben zu AI, während man mit der AI arbeitet, stelle ich mir das einmal so vor, dann kann ich den Abstraction Layer Spell sagen und dann macht die AI das Richtige. Also das ist so bisschen noch zu dem, auch zu dem was du vorher sagtest, eben gucke ich den Code an oder nicht? Ich glaube nicht, dass man angucken muss, aber ich glaube, dass man diese Spells braucht, mit denen man diese Trigger Words braucht, mit denen man bei der AI das richtige Verhalten erzeugt. Sebastian: Ja, total. André Neubauer: Wir reden ja wir reden ja jetzt einen tag nachdem entropik mehr oder weniger quasi also keiner weiß ob das halt quasi absichtlich oder unabsichtlich aber egal quasi kloot kot ja ok. Sebastian: Ich wollte es gerade sagen. Definitiv unabsichtlich. Unabsichtlich war das. Die haben ja tatsächlich einzelne Leute auch angeschrieben und gesagt du du du den Code nicht weitergeben, auch wenn du ihn gesehen hast, wo sie wissen, dass sie Zugriff darauf hatten. Stephan: Würde ich aber auch machen, wenn ich es absichtlich machen würde. Sebastian: Okay. André Neubauer: Trotzdem der Punkt, im Endeffekt Cloud Code geleakt, kann man das nachvollziehen? Die These finde ich auch stark. Ich würde aber erwarten, dass das nicht im LLM ist, sondern eigentlich eher im Environment was triggert. Stephan: Aber ja, ich glaube auch, dass das Sebastian: Wie meinst du? André Neubauer: Das müsste man doch eigentlich nachvollziehen können was Stefan gerade gesagt hat also gibt es da wie er es genannt ist Semantik Semantik Enkers genau Semantik Enkers Müssen wir noch knapp mal nachschauen in Claude Cote ob das quasi dahingehend hat irgendeine Berücksichtigung gibt oder oder vielleicht sicher Ja Sebastian: Das sind Trigger-Words, Stephan: Semantic Anchors, Ralf nenne es Semantic Anchors und ich sag Trigger Words. Ich glaube, das liegt halt im Modell. Also, ja. Es geht auch sehr viel weiter als das. Bei mir ist es ja, wie gesagt, so klein. Bei Ralf geht es ja auch noch mal. Trigger-Words in anderen Bereichen. Wie schreibe ich gutes Deutsch? Gibt es bestimmte Trigger-Words? Wie mache ich ... McKinsey hat einen ganzen Stapel Trigger-Words, wie sie arbeiten. Es gibt von Gardner Trigger-Words, die ich kennen muss, ⁓ dann ... Wenn ich der Consultant bin, dann kenne ich die Gardner und McKinsey Trigger Words und dann erzeuge ich bestimmte Arten von Texten oder Folien in der AI. Also ich kriege die AI dazu dann, wie McKinsey zu agieren, wenn ich passende Taubersprüche habe. Sebastian: Ja, ich wollte nur einen anderen Gedanken machen, der jetzt gar nicht damit zu tun hatte. Also fairerweise, ⁓ das Claude-Coding nochmal abzuschließen, da gibt es natürlich auch viel Spott und Hämme. Vibecoding, aller Codes, von der KI geschrieben. Da auch ein Video von The Primogen War. André Neubauer: Vielleicht ein bisschen... Ach so, Sebastian. Sebastian: Kommentare in GitHub durchgeht, die halt dann auch von Cloud Code automatisch beantwortet werden. Und ich meine, so ist tatsächlich auch dieser Leak entstanden. Also sprich, da hat jemand gesagt, hier funktioniert eine Source Map nicht. Und so ist dann die Source Map von Cloud Code halt open source wurden, was natürlich, wir mal, zum Thema, soll man sich das alles angucken oder nicht, aber fairerweise auch, wenn da noch ein Mensch drauf... Ja, bitte. Stephan: Ich kann noch eine Klammer machen. Mir fällt doch eine Klammer ein. zwar jetzt, vor kurzem hat ja auch Claude Cote dieses... ... kleine Tier in Claude Cote, wie heiße die? Wie hießen die früher? Tamagotchi. Gelaunched. Und... wer auch immer... Also ich hatte Tamagotchi. Ich bin so alt. Und... Da stellt sich natürlich jetzt auch die Frage, okay... Sebastian: Hm. Stephan: Tamagotchi in Claude Coat ist es jetzt der Zeitpunkt, wo ihr nichts mehr einfällt. Also die haben ja super, super viel Release. Also ich habe dann irgendwie jeden Tag 2.1.70, 2.1.71. Jetzt sind wir glaube ich bei 2.1.89. Während dem Podcast wird wahrscheinlich 2.1.90 sein. Da stellt sich mir die Frage, wenn man jetzt Tamagotchi in Claude Coat reinbaut, die vielleicht einen Hintergrund haben oder wie auch immer. Aber das ist eben die Klammer jetzt von Claude Coat. Zu dem was wir vorher diskutiert haben, wenn das Erstellen von Features kein Limit mehr ist, welche Features baue ich denn alle in Human ein? Also potenziell wenn ich Tamagotchi einbaue dann Jump the Shark. Sebastian: Bist du vom Weg abgekommen? Ja, exakt. You jumped the shark. Ne, 100 pro, genau. Und den Gedanken, ich aber eigentlich nochmal führen wollte, ist nochmal, also andere Perspektive auf Tools. Weil was ich gerade wahrnehme, also ich oute mich jetzt mal, ich war nie ein CL-i-Fan, weil ich meine kognitiven Kapazitäten immer gern für andere Themen genutzt habe, als mir irgendwelche Commands zu merken und so. Ich hab das gerne, wenn ich mir das erschließen konnte dann in der UI irgendwie mit, also quasi einfach beim Sehen mich dran erinnern konnte. Das ändert sich jetzt massiv, alle möglichen Applikationen, Tools, Plattformen auf einmal zugänglich werden, weil es halt jetzt eine CLI gibt, ⁓ damit zu interagieren. Ich meine, das Gute ist, meine Cognitive Load erhöht sich dadurch jetzt nicht. massiv, weil die KI macht das ja für mich. Ich muss ja nur die KI Trigger Words wieder kennen, damit es funktioniert und die Tools dann noch installieren. Aber das finde ich auch gerade spannend. ist also jetzt fairerweise so ein Zwischending, weil am Ende CLI Tools sind ja auch Standard. Kann jeder Entwickler prinzipiell auch benutzen. Aber auch da haben wir eher so eine Proliferation, weil die KI eben mit dem CLI-Tool auf der Kommandanzelle einfach sehr, gut umgehen kann. Das viel besser funktioniert natürlich als irgendwie in einem Browser, was inzwischen aber fairerweise auch immer besser funktioniert. Chrome Bridge oder wie das heißt. Wenn ich nicht weiterkomme mit an meiner App, dann sage ich hier, guck mal in meinen Browser, das geht nicht. So, mach mal. Und dann rödelt es zehn Minuten und dann geht Stephan: Gute an CLI, was die AI kann mit einem CLI-Tool, ist, dass sie das Mühe los ⁓ Bash-Befehl, mit Pipes, mit For-Loops und anderen Sachen integriert. Also, ich mach ein CLI-Tool, dann macht es einen For-Loop, macht es einen Sorten-TA, dann macht es einen JQ, ⁓ die Chasing rauszufiltern. Also, die AI ist sehr gut darin, ⁓ als Baustein in dem größeren Gesamtkunstwerk, sag ich mal, ⁓ Sebastian: ein. Stephan: verwenden. Sebastian: Ja, genau. Ja, und das ist ja auch so ein bisschen der Startpunkt ⁓ Pi wiederum. Also kann ja eigentlich per se nur vier Tools, glaube ich, irgendwie verzeichnisscannen und Dateilesen etc. Und das ist das, du in der Programmierung normal verbrauchst. machst du ein Grab und dann findest du irgendwie, wo sich bestimmte Sachen wiederfinden etc. dann reichest du das an, ⁓ Zugriff auf Linja, Jira, was auch immer. Und dann kriegst du auch den Kontext angereichert. Easy. André, du wolltest noch was sagen. André Neubauer: Dann versuchen wir doch mal so langsam ne Klammer drum zu kriegen. Wir machen Special Edition insofern, ich muss jetzt nicht sklavisch unendlich lang sein. Aber Stefan, für dich quasi also zwei Fragen. Wann baust du die Tamagotchi ein? Erste Frage. Zweite Frage quasi, wie kann man dir, wie können wir dir helfen mit Jumeln? Stephan: Also erstens, vielleicht brauche ich das, also ich brauche ja sowieso nichts mehr, mein Leiter ist glott. Aber vielleicht mache ich es gleich morgen oder heute Abend im Hotelzimmer mal sehen. das ist das eine. Heißt dann aber nicht, dass mir nichts mehr einfällt. Wie kann jeder helfen? Ausprobieren, Feedback geben. Es hat halt eben auch viel mit Betriebssystemen und anderen Sachen zu tun. sprich läuft bei mir. heißt aber nicht, dass es bei anderen Leuten läuft. Also da gerne mir sagen, bei mir läuft es nicht, sieht so und so aus. Oder dass mir das Feature fehlt für mein Corporate, damit ich es einführen kann oder damit ich es vorschlagen könnte. Also da bin ich sehr dankbar für jeglichen Feedback. Sebastian: Wir André Neubauer: kann man contributen? Stephan: Öhm... Ja, weiß ich nicht. Im Prinzip ja. André Neubauer: auch noch mal irgendwann noch mal wahrscheinlich noch eine Folge wert quasi wie Open Source quasi in AI-Zeiten aussieht. Quasi würde mich auch brennend interessieren, wie man halt also wie würde dann jetzt eine Contribution aussehen? Quasi lässt du da deinen Agent halt einfach laufen oder also quasi was ist der Mehrwert an der Stelle, weil der Code selbst gar nicht mehr ist. Es ist die Idee, ist die was ist es? Genau, aber Auf jeden Fall danke, dass ihr Zeit genommen hast. Wir hatten ja am Anfang gesagt, ein mega interessantes Projekt. Ich gucke gerade auf die Seite, ich sehe 27 GitHub-Stars. Ich bin gespannt, wie sich das entwickelt. Vielen Dank. Stephan: Ich bedanke mich bei vielen Einzelnen. Sebastian: Aufruf an unsere Zuhörer. Probiert es aus. Lasst ein Like da. Gibt ab Star, wenn es euch gefallen hat. Genau und gebt Feedback. André Neubauer: Genau, ich mache hier noch einen Easter Egg rein. Quasi in der Hoffnung, mal am Endeffekt müssen wir auch ganz ehrlich sein, Sebastian schneidet bei uns ja immer. Also wenn wir richtig schnell sind, ist diese Folge live, bevor wir bei Trusted Shops den nächsten Self-Education Friday haben. Heißt, einen Tag, wo sich alle Leute quasi mit Themen beschäftigen können, ⁓ sich weiter zu entwickeln. Mal schauen, wie viel an dem Freitag dann vielleicht hier an GitHub-Stars dazukommen, weil Leute diesen Podcast gehört haben und denken, dass probiere ich mal aus. Sebastian: Challenge accepted. Das ist gerade von Folge 10 zu Folge 9 geworden. Morgen früh. André Neubauer: Self-Education Friday ist der letzte Freitag immer im Monat, insofern du hast noch bisschen Zeit. Der letzte Freitag im Montag. Stephan: Letztes Freitag am Montag. Sebastian: Alles klar. Vielen Dank, Stefan. Stephan: Ich danke euch. André Neubauer: Vielen, Dank. Sebastian: Herzlich willkommen zu einer neuen Folge von HMZE Beyond Vibe Coding, der Podcast, in dem wir den fundamentalen Change in der Softwareentwicklung begleiten. Ich bin Sebastian Heidemeyer zu erben, CTO bei NorthIO. André Neubauer: und ich bin Andre Neubauer, CTPO bei Trusted Jobs. Schön, dass ihr wieder da seid. Unser heutiger Gast ist ein altbekannter, ⁓ genau zu sein, der Gast aus der ersten Episode. Die, die es gehört haben, werden es wissen, wer es ist. Es ist Stefan Schmidt. Und warum ist Stefan da? Sebastian: weil uns ein Projekt von ihm ins Auge gesprungen ist, das wir heute gemeinsam mit ihm besprechen wollen. Es geht ⁓ Human, ein Toolset rund ⁓ wie sollte es anders sein, Agentsic Engineering. Eine detaillierte Erklärung sparen wir uns hier an dieser Stelle und springen direkt rein in unsere Spezialfolge. Viel Spaß dabei!