Stephan Schmidt — „Human, batteries-included toolset für AI Engineering“

Works in My Machine. Sehr gut. Es ist doch schön, wenn sich bestimmte Dinge einfach nicht ändern, so ne. Herzlich willkommen zu einer neuen Folge von HMZE Beyond Vibecoding, der Podcast, in dem wir den fundamentalen Chang in der Softwareentwicklung begleiten.

Ich bin Sebastian Heidemier zu Erpen, CTO bei Northo. Und ich bin Andre Neubauer, CTPO bei Trusted Shops. Schön, dass ihr wieder da seid. Unser heutiger Gast ist ein altbekannter, um 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? Na, weil uns ein Projekt von ihm ins Auge gesprungen ist, dass wir heute gemeinsam mit ihm besprechen wollen.

Es geht um Human, ein Toolset rund um wie sollte es anders sein, Agentic Engineering. Eine detaillierte Erklärung sparen wir uns hier an dieser Stelle und springen direkt rein in unsere Spezialfolge. Viel Spaß dabei. Herzlich willkommen zur Beyond Vibecoding 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 vorgeplenkel, also Stefan, stell dich doch mal vor und womit arbeitest du gerade sparen. Das könnt ihr euch in der ersten Episode sozusagen vom Beyond Vibe Coding von vor 10 Wochen anhören. Äh, heute gehen wir direkt aufs Eingemachte, aber genau bevor wir da einsteigen, erstmal herzlich willkommen, Stefan.

Schön, dass du wieder da bist. Ja, sehr gerne. Ey, wir sind ganz neugierig, denn du hast ja ähm vor kurzem, ich weiß gar nicht, wann ich das erste Mal mitgekriegt habe, wahrscheinlich letzte Woche dein neues Tool, würde ich mal sagen, ne, Human angefangen zu präsentieren und äh das ich hab es mir vorhin mal angeguckt oder auch gestern schon mal ein bisschen reingelesen. Klingt alles sehr, sehr spannend, aber es macht natürlich viel Sinn, wenn es äh mit den Worten des Creators vorgestellt wird.

Genau. Erklär doch mal kurz äh deine Gedanken dahinter und was was es kann, was du dir dabei gedacht hast. Ja, Rater, super Stichwort. Also, was habe ich mir dabei gedacht?

Ich habe äh es kommt aus einem gewissen nie aus einem gewissen Bedarf heraus ähm ein Tool, um mit dem Ziel letztlich Secure ähm Cloud Code nutzen zu können, nach Möglichkeit in einem Yolo Mode, weil man ja nicht dauernd ja sagen will oder weil man nicht dauernd irgendwie ja zu so langen Python Promps sagen will. Darf ich den ausführen? Ja, nein. Ja, weiß ich nicht.

Weil 20 Zeilen Python verstehe ich jetzt auch nicht so schnell. Ähm, da kommt es so ein bisschen her und ich habe mir die Tools angeguckt, die es da in dem Bereich gibt und war aber mit denen nicht ganz happy und habe dann somit angefangen ähm Human zu bauen, was im Prinzip ein anfängt als als Death Container äh einfaches Setup für den Death Container. Das heiß ich sag, mach human in und dann habe ich am Ende den Death Container. Jetzt hat man aber mit dem Death Container sehr viele Probleme.

Äh, das heißt z.B. Cloud Chrome geht nicht so richtig, Clps gehen nicht so richtig, alles von drinne nach draußen hapert immer. Äh, also habe ich gesagt, okay, dann muss man das irgendwie auch machen mit dem Proxy und der Firewall und dann geht's aber auch letztlich dann darum, z.B. äh um den Kontext zu managen, also wie komme ich an mein Gy ran, wie komme ich an mein 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 Context, Connectors äh und so weiter und so fort in und dann nur noch Cloud Code, was da drinnen läuft.

so ein Rails für AI Entwicklung, also alles better included. Ja, cool. Das ist tatsächlich auch wirklich sehr spannender Ansatz, weil genau das wünscht man sich ja immer, ne, wenn man irgendwie mit so einem Tool arbeitet, dass man wir nutzen Asana Notion, ne, dass man das alles connectet und dann auf das ganze Wissen zugreifen kann. Äh, genau.

Und ja, bei dir, also Death Container, ich nehme an, gewählt, insbesondere, du meintest ja auch Yolo Mode, um ähm äh Security zu gewährleisten, vermutlich, ne? Genau. Also, das einfach äh ein Dateizugriff limitiert ist auf das aktuelle Arbeitsverzeichnis und nicht auf andere Sachen und in Kombination dann eben mit einer Firewall ähm sprich SLPXY auch nur zu kontrollieren, auf welche Webseiten oder welche URLs äh Cloud Code aufzugreifen. Mhm.

Ich hatte es ja am Wochenende hätte ich ja am Wochenende angeschrieben und das auch für mich also so als Wochenendprojekt mal durchprobiert und war begeistert, weil äh hat er gerade schon so ein bisschen Vorgespräch gesagt, also ehrlich gesagt würde ich erwarten, dass das für jeder halbwegs Enterprise Grade Company so ein bisschen das die Fault setup halt irgendwie ist. Ähm äh ja, ich bin war ein bisschen, also als ich es gesehen habe, ich 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, vielleicht auch so für die äh geneigten Zuhörer. Wie würde man es denn ansonsten machen?

Na ja, man würde sich wahrscheinlich diverse MCPs installieren, äh braucht dann aber gegebenfalls Tokens. Dann muss man sich überlegen, kriegt die AI den Token oder nicht? Also ähm wenn wer schon mal einen Token in die AI kopiert hat, wird vielleicht feststellen, dass sie das in oder Cloud Code, dass sie das in den Memory äh gespeichert hat und dann drei Tage später äh sagt, ach ja, äh nee, funktioniert nicht, aber ich habe da noch einen Token, ich und Curl, ich kann doch jetzt einfach mal selber rumbasteln. Also ähm das die ist so richtiger was zu machen.

Äh ja und dann wenn sie irgendwo noch mal ein findet, den sie schon mal hatte, äh dann macht die ganz komische Sachen. Also das man müsste das kontrollieren in dem in dem Death Container. Das gibt Tools dafür, also one CLI z.B. will um äh sowas zu managen, aber es sind halt lauter verschiedene Tools und ich glaube, wenn ich als ähm die ich mir alle zusammensuchen muss, die ich konfigurieren muss äh was dann manchmal auch nicht ganz funktioniert oder nicht ganz reibungslos funktioniert ähm und was vielleicht auch noch geht, wenn ich jetzt sozusagen Freelancer Programmierer bin, aber in dem 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 in der ähm im Repo haben und so.

Also, es ist alles nichts halbes und nichts ganzes und vielleicht irgendwas, was was einfach funktioniert, weil mich geht's ja auch um diese Sachen gar nicht. Also ich will ja eigentlich nur, dass Cloud läuft äh 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. Und jetzt hast du über letzten weiß gar nicht Wochen die diesen Unterbau gebaut.

Auf der Seite steht das Secure Developer for AI AI empowered Engineering. Also kannst du magst du das Zielbild teilen? Also wenn es denn einen Zielbild schon gibt? Das Zielbild ist alles außer Cloud Code.

Also du brauchst Tum und Cloud Code und dann kannst du dann kannst du letztlich Cloud Codes sicher laufen lassen in dem Environment, wo es den Kontext auf Kontextzugriff hat und so weiter und so weit. als was es braucht. Äh das ist sozusagen das Zielbild. ähm ist jetzt wenig inspired vielleicht, aber ist halt ultra pragmatisch als etwas, was ähm halt dann einfach funktioniert.

Es hat auch ein bisschen noch Prompting drin. Also es ist es hat auch Custom Prompts, an denen ich arbeite. ähm also soagen, also Code Review oder Ticket, weil die Idee war dann auch noch mal, wenn ich ähm sowieso Konnektoren habe an Chyra Linear Shortcut, dann kann ich auch Proms nehmen, die ähm sozusagen einen Plan nicht ein Lokal nur haben, sondern ein Ticket draus erzeugen oder sowas, was dann auch in Corporate Umfeld noch mal das Thema Audit und Traceability adressiert, was das ganze eben auch noch mal adressieren kann, also oder soll. Also ist vielleicht so schwierig zu fassen, also alles in einem Tool.

Ähm sonst braucht man nichts außer Plat. Ja, alles hinter einem Ja, stimmt. Tool. Ja, so eine Art Proxy im Endeffekt, ne?

Also so ein Layer und halt im Zweifelsfall auch Wegwerfumgebung. Es ist schon bisschen wie so ein Operating System. Also es ist natürlich ein Wort Wortspiel auch auf das, dass heute alles Operating System ist, wie wenn jemand sagt CTO Operating System äh wenn er sich drei To Listen macht, aber äh aber es ist schon auf einer gewissen Ebene, weil es hat eine Control Planee, 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. Ähm, also sozusagen bisschen eine Art Scheduler.

Ähm, die Konnektoren kann man sich auch im Prinzip ein bisschen wie wie ein Feilsystem vorstellen. Ähm, also es ist schon bisschen in die Richtung auch Operating System auf einer höheren Ebene mit Cloud Code sozusagen als äh als Executor ähm in kann. Ja, mich erinnert das tatsächlich von der Herangehensweise sehr an P, das ist ja mein Agent of Choice gerade, sorry. Und ähm da, also a gibt es halt auch ein Ökosystem, was viele dieser Dinge auch mitbringt, also eigene CLI für genau so Token Management, ne?

Dann du hast ja auch bestimmte Skills dabei, die ähm so ein so ein äh Workflow abbilden, ne? So ein typischen Development Workflow, also IDE Plan und dann Execute und Review und so. Genau. Das das gibt's da auch und ähm das äh also nutze ich tatsächlich auch sehr intensiv bei Pie.

Ähm und genau, also insofern würde ich Pai sozusagen ähm als äh fast größten Konkurrenten ansehen, weil da kann man natürlich auch so ein äh also Skills, Extensions und so packagen und dann als einen Bundle ausrollen. Also ich glaube, es gibt sogar speziell von Piso bestimmte Packages. Man kann sich da auch Extensions bilden, ne, bauen. Ähm, aber ähm das geht natürlich nicht, wenn man mit Cloud arbeitet, weil dann also zumindest äh es dann sehr teuer ist, weil man dann äh nur API Meted Cloud nutzen kann und äh genau dafür ist natürlich Human äh eine sehr sehr gute Alternative, wenn man das mit Cloud machen möchte.

Ja. Ähm, nee, aber also, also ganz genau, ich weiß jetzt nicht, ob ich das sagen sollte äh in in dem Podcast, aber ich weiß natürlich nicht, was ich tue. Also, ähm ich meine Herangehensweise ist schon ähm die letzten Monate auch zu sagen, wir sind wild im wilden Westen und wir wissen jetzt nicht, ist es besser äh ähm Kühe zu züchten, Gold zu graben, Schaufeln zu verkaufen oder ähm Schuhe herzustellen. Ganz genau weiß es aktuell keiner.

Und ähm ich will halt nur Cloud Code auf jeden Fall haben, weil ich davon, weil ich rein der persönlichen Meinung bin, äh dass Cloud Code mit Abstand das Beste aktuell ist, äh um Code zu entwickeln und Review zu machen und Bugs zu finden und alle diese Dinge. Ähm aber genau, wo es hingeht und wie sich diese Toolandschaft entwickelt und was wir am Ende brauchen werden, äh weiß ich natürlich auch nicht. Ähm aber ich will mit dabei sein, das auszuprobieren. Ja.

Ja, ich glaube, das geht so ein bisschen zurück auf das, was wir mit Markus irgendwann mal hatten. Musste einfach äh quasi ausprobieren, rumfummeln, weiß gar nicht, ich glaube, das hat er glaube, das hat er geoint. Ähm das, was ich mich das was äh das das was ich mich äh in dem Zusammenhang äh so ein bisschen frage ist, dass wir so auch gerade meines so Entwicklungsumgebung, ne? Also das wie wird sich das also ist das etwas, was was man perspektivisch halt eher zentral sehen würde?

Also als wir beide noch Software geschrieben haben, da war das halt irgendwie quasi hat das dem Entwickler gehört, ne? Das halt irgendwie die ID äh quasi das das war sehr individuell, da gab's halt irgendwie weiß nicht das Eclipslager, Jetbrains Lager und so weiter und so fort. Ich die Frage, die ich mir auch stelle, ist halt quasi inwiefern wird das halt stärker zentralisiert? Ja, also inwiefern wird das halt auch etwas, was die Firma halt einfach zur Verfügung stellt und dann musst du da drinne halt arbeiten.

Ja, also quasi wie Intelligj. Also die Frage ist, also war ja quasi ihr lange Zeit der Standard in vielen Unternehmen. Ähm am Anfang 2000er viel Diskussion im Java Bereich, Intellig Chain, Netbeans, Eclipse, was weiß und so weiter und so fort. Dann hat sich das aber ziemlich stark äh eingeschränkt auf Intellig.

Dann kam irgendwann äh VS Studio als kostenloses Tool. Ähm, aber ich glaube, dass wir neue Toolkategorien bekommen werden. Ich versuche mit Human eine Tool Kategorie zu schaffen. Ich weiß noch nicht genau, wie die aussieht, aber ähm ich glaube, wir kriegen neue Tools und ähm und auch die Unternehmen wollen dann halt letztlich am Ende ein Tool haben oder ein standardisiertes haben, was ein Noiner ist, ja, im Sinne von no one has been fired for buying IBM.

Ähm, das ist immer noch so, glaube ich, in Unternehmen und ähm wenn wir wenn wir gucken im Umbruch, sage ich mal, was ich so sehe mit den Firmen, mit denen ich arbeite und den Entwicklungen, die ich arbeite, ist das halt immer mehr Leute keine Idee und kein Curser mehr verwenden, sondern in Cloud Code CLI arbeiten äh und dort sagen, mach das und das und das und dann vielleicht noch den Review machen. Vielleicht haben sie Z Z Z Z ZDD offen, ZD offen oder irgendwelche Sachen. K auf Visual Studio offen, um ab und an mal reinzugucken. Äh, aber es gibt, ich sehe schon sehr starken äh äh Bewegung Richtung Cloud Code CLI oder Open Code CLI.

Ähm, also deswegen glaube ich so die IDE als äh ähm als als das Entwickler Tool ist, glaube ich, abgelöst. Es sei den jemand kommt mit ein ganz genialen neuen Idee. Will ich jetzt nicht in Abgede stellen oder so, aber und wir wissen nicht genau, welche Kategorien an neuen Tools es denn dann eigentlich geben wird. Ja.

Mhm. Ja, da bin ich da bin ich, da bin ich bei dir. Also, ich glaube das äh quasi das die Zeit, wo zumindestens der Codeil in der ID äh den Hauptspace eingenommen hat, das das denke ich ist auch vorbei. Es wird wahrscheinlich so würde ich jetzt auch Human verstehen, das ist eher so die Orchestrierung von vielem, ne?

Ist halt irgendwie alles unter also wie so eine Kommandozentrale. Ja, also wissen wir alle nicht, aber äh quasi ist ein ist ein möglicher Weg. Ist ein möglicher Weg. Ja, auf jeden Fall.

Und also vielleicht nur ganz kurz und dann darfst du gleich Andre und dass so ein Tooling benötigt wird, ist glaube ich auch klar, ne? Ich 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 ja gerne hättest. Und ähm so ähnliche äh sagen wir mal Automationen äh bauen sich meines nachher gerade verschiedene Leute. Also neulich auch ein Podcast gehört mit Mario Zechner, der baut sich auch noch mal um Pai rum äh so eine so eine Controlplane gerade.

Ähm von daher das ist glaube ich also äh Zweifels ohne ähm relevant. Die Frage ist, ne, ob das nachher auch alles von Enhropic kommt und äh oder ob es da noch mal extra Anbieter geben wird. Ja, sorry Andre, jetzt habe ich dich unterbrochen. Ich hatte nichts gar nichts, also hattest mich nicht unterbrochen.

Vielleicht bloß ein Gedanke, wenn du so ein bisschen so Roadmap Ich muss da trotzdem noch mal fragen vorhin, du meintest also auf dem OS Thema ähm so Ropemmap, was kann man denn noch erwarten? Also quasi in welche Breite willst du das noch bringen? Also wird das äh quasi wird das einen technischen Fokus quasi behalten oder willst du da man könnte noch einfach den Entwicklungsprozess halt hochgehen? Ähm weiß jetzt nicht inwiefern das halt irgendwie ein Benefit ist, das halt mit zu integrieren, aber hast du da irgendwelche Gedanken?

Ähm ja, es gibt jetzt schon ein Ediate Skill ähm wo ich mit rumprobiere, aber ich weiß jetzt nicht genau, wie weit es in Richtung Produkt geht oder ich weiß auch nicht genau, wo, also wo am Ende die Entwicklung anfängt oder also das weiß ich nicht. Ich kopiere das aus. In der Breite, eher in die Breite, weil ähm für mich ist natürlich das alles ein Experiment jetzt ähm wer mitmacht, ist gut. Also wer es nutzt und ausprobiert ist super.

Äh, aber es ist schon auch ein Experiment im Sinne von, na ja, ich kann halt eine Integration an dem halben Tag machen. Also jetzt eine Integration von Chyra äh oder sowas ist halt ein halber Tag AI Arbeit, also geht ziemlich schnell und dann hat's irgendwelche Edge Cases und dann geht das nicht das nicht. Bis es rund läuft ist halt ein halber Tag. So, wenn ich das jetzt vorhand irgendwann mal programmiert hätte, hätte ich vielleicht eine Woche gebraucht, um 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. Ähm, ich kann halt sagen, hier gibt's eine Bibliothek oder überlegt dir mal, wie wie könnte man das und das anbinden, dann machen wir dann paar Plan Itations. Ähm, und dann habe ich die Integration im Prinzip. Die Frage ist natürlich, wie wie weit geht es in die Breite?

Also wie wie wie viel ist da managebar? Also, wenn ich jetzt mal, ich hab 20 Integrations, ich habe 50 Features, ähm ist es noch managebar, ist es von mir manag, das weiß ich alles nicht. Deswegen ist es da auch so ein bisschen ähm 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 die Entwicklungsleistung gar nicht auf die Straße gebracht hat und die ist jetzt plötzlich da. Aber welche Einschränkungen bringt es dann dann sonst noch?

Oder gibt's überhaupt welche oder? Ja, für mich sehr sehr spannend. Ja, das glaube das ist ein quasi total faires äh Seitenexperiment. Da bin ich bin ich komplett bei dir.

Ähm ich hatte mich äh am Anfang, als ich das erste Mal ausprobiert äh äh habe äh gefragt oder so ein bisschen m das so zurückerinnert gefühlt äh an die äh Cloudzeiten äh 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, ne? man ja nie weggeschmissen, sondern immer quasi bloß quasi die nächste die nächste Ieration nächste Ieration und dann ist man ja dazu übergegangen, dass man einfach Environments wegschmeißt. Ich hätte den Eindruck gehabt, das könnte man ja hier genauso machen, ne? Das eigentlich deine Entwicklungsumgebung zum Wegschmeißen.

Du könntest eigentlich sagen, für jeden Feature Request, für jede für jedes für jedes Projekt einfach immer ein neues Environment. Hast du mal in die Richtung gedacht oder wirst du sagen konzeptionell eigentlich eher nicht? Konzeptionell eher ja. Ähm, es gibt ja auch andere Ansätze, also ich habe vorher sehr sehr viel mit anderen Ansätzen experimentiert.

Also z unter Linux gibt's ja z.B. so ein Tool, das heißt Bubble Rock Wrap. Ähm, da kann ich ein Binary verpacken äh in in in dieses Bubble Wap äh sozusagen in dieses Ding, was da was da knallt ähm dieses Packpapier ähm und äh kann den dann sagen, bitte nur die Dateien lesen oder die Dateien lesen oder oder also es gibt äh solche Ansätze äh Cloud Code einfach zuusagen in so eine Jail zu packen, Linux Jail oder auf dem Mac gibt's andere Jail Mechanismen. Ähm, dann habe ich natürlich trotzdem immer noch die Problematik, wie komm, wie funktioniert mein Rest meines Environments, also mit die Konnektoren und und und so weiter und so fort funktioniert dann Cloud Chrom und so.

Ähm, aber da sehe ich noch sehr viel mehr äh sozusagen dieses Wegwerfen. Also, ich starte das einmal mit so einem mit so einer Jail und dann mache ich was und dann beende ich es wieder und da kann ich es potenziell auch in C laufen lassen oder wie auch immer. Da will ich schon auch hin. Also, das ist schon so ein bisschen ähm ich weiß noch nicht genau, wo es dann hinläuft, aber irgendwie bisschen in die in die Richtung.

Ja. Ähm am Ende vielleicht ja auch äh guck mal äh Claud, hier sind die Tickets, hier ist die Production Umgebung. Ähm äh mach mal äh ich weiß auch nicht, wenn wenn Cloud Code z.B. einfach dann selbständig von Ticket, also wenn es so gut ist, dass es von dem Ticket des ideiated und und und Lücken findet oder aus dem Strategie Tickets erstellt oder was weiß ich w die nach Production packt irgendwann und 24 Stunden am Tag Features produziert, ähm sozusagen da weiß ich auch nicht, wo es hingeht.

Also, kann das dann am Ende noch jemand nutzen oder äh wird das unnutzbar oder also muss ich dann wirklich mal sagen, nee, ich will nur wirklich jedes zehnte Feature, was ich ja schon seit 20 Jahren propagier, ähm gute Features zu deployen und nicht jedes, was in den Kopf kommt, aber ähm das da das verschiebt sich halt sehr viel. Deswegen ja dieses 1 pro Feature und vielleicht hier z.B. da ist ein Ticket, macht das mal in Production, dann läuft die Umgebung, macht es und dann habe ich das Feature im Liveystem oder so. Ähm ja.

Also zu dem, was du sagtest, ja, ich weiß noch nicht genau wie. Mm. Mhm. Ja, bitte Andre.

Ich hätte jetzt bloß noch mal gesagt, na, ich finde das halt spannend. Also ich finde dieses, also quasi dieses, also diese kan ich sagen, sagen Backmelf Mentalität, glaube im 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 äh das finde ich dadurch, dass es auch virtuell ist und erstmal nicht viel kostet, finde ich es eigentlich eher den erstrebenensstrebenswertigen anstrebenswerteren Ansatz, weil es halt eben nicht ein mundgeklöppetes Environment ist, sondern halt du kannst es immer reproduzieren, es ist immer automatisiert. Also ist immer äh quasi kein manueller Aufwand. Das was ich vielleicht eine Frage dann doch noch, da muss ich mich noch mal dazwischen sneaken.

Sebastian, sorry dafür. äh der ganze Infrastrukturbereich, also quasi so das quasi Deployment, das hast du da ist da ausgecarft, zumindestens bis jetzt on on purpose. Äh, nee, also äh für meine Privatsachen ähm also für meine Webseite oder sowas, wo es nicht so viel geht oder irgendwelche mein Privatool, das irgendwo läuft für mein Coaching, weil eigentlich verdiene ja Geld mit CTO Coaching und Leuten helfen bei AI Transitionen, das ja meine eigentliche, da kommt irgendwie irgendjemand muss ich auch bezahlen. Ähm, da macht auch die AI relativ viel vom Deployment, also vom CI einrichten, deployen, Probleme finden, sich System Delogs angucken, äh sagen, ja, da ist was falsch, fix ich und so.

Also für mich, für meine kleinen Sachen, die ohne großes Risiko, sage ich mal, sind, weil keine keine nicht mir anvertraute Kundendaten sind, die verloren gehen können oder so, ähm macht ihr ja relativ viel von dem operationellen Betrieb auch schon, ohne dass ich da drauf gucken muss. Ähm, also ja, ich fand das halt, also ich fand den Gedanken vor, weiß nicht, schon längere Zeit her, ähm fand den Gedanken irgendwie spannend, dass man diesen äh Entwicklungszyklus mit dem Produktzyklus halt irgendwie mercht, ne? Halt, also quasi, dass du halt und da passt jetzt halt Human ganz gut dazu, du hast halt im Endeffekt die ganze Chain, ne, die ganzen Entwicklungsprozess bis in die Produktion rein und das wird halt auch ein ein sich selbst fütterndes System, ne? Also wenn wenn du da halt irgendwie ein Monitoring drauf hast, also auch ein fachliches Monitoring und dann halt irgendwie du siehst halt weiß ich nicht da droppt halt irgendwie eine Conversion Rate oder die ist halt irgendwie nicht gut, dann könnst du halt irgendwie überlegen, okay, ne, ist halt irgendwie was könnte dem helfen, dann wird das durchgebaut, wird gebaut, okay, ist nicht besser noch mal, ne?

Und damit d also im Endeffekt würdest du damit so ein bisschen in die Richtung so weiß nicht, heißt das Dark Factories, das ist es, ne? Ähm, also quasi, dass wirklich der Human im Endeffekt komplett draußen ist. ähm eigentlich bauen und ich fand die Idee gut. Für mich ist aktuell noch immer so dieses quasi Production Environment irgendwie das also on purpose, ich weiß halt 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ärts gespult, ein bisschen mehr Security macht für mich irgendwie total Sinn.

Also Human kann ja auch das auch sozusagen meine Theorie, was ich auch mit meinen Kunden immer platziere. Also Human ist auch integriert mit Amplitude äh zum einen oder mit Centry zum anderen. Also ich bin hal der Meinung, wenn ich jetzt also zu sagen hier bau mal ein Feature oder wir machen mal Planning zu dem Feature oder zu Idiation und hier ist halt Amplitude, guck dir mal an, wie unsere Features funktionieren oder welche Features wie funktionieren oder guck hier in Century, welche was weiß ich, welche Latenzen wir haben. Äh und äh und bau dann was mit dem Input.

Äh, ich find's super generell super spannend Sachen zu machen, äh mit AI Sachen zu machen, die man vorher nicht machen konnte. Mein Beispiel ist so, äh ich habe irgendwann mal vor paar Wochen ähm die AI gesagt, hier sind 1000 Tests, geh mal die Test durch, analysiere die Tests und find Bugs basieren auf die Tests. Und der II hat halt zwei Bugs gefunden. Ähm also nicht in Human, sondern in dem anderen Produkt von mir.

Und ähm das hätte ich jetzt nicht dem Entwickler gegeben. Ich hätte nicht gesagt, hier Entwickler, guck mal 1000 Bugs, 1000 Tests an. Also ich finde sehr sehr spannend Sachen zu machen mit der AI, die 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 Century reinzugucken oder in Amplitude reinzugucken für das Planning und die Daten, die nicht Benutzer, die nicht nutzer die Benutzungsdaten äh mit in den Planungsprozess an der Stelle mit einfließen zu lassen. Und vielleicht zum Deployment Coach noch was, wir sehen ja, dass die Open, ich weiß gar nicht, wo das alles hingeht.

Ähm, aber wir sehen ja auch bei äh z.B. 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 ein Sticky Header, dann macht sie ein Sticky Header. So, wenn man das jetzt weiterdenkt, ich versuche ja irgendwie auch immer weiter zu denken. Ich habe irgendwie ähm ja, Philosophie studiert auch ein bisschen und ich versuche auch weiter zu denken oder größer zu denken und so.

äh ist brauche ich AWS, also brauche ich nicht nur Beal, also ich sage jetzt hier ist Beetal äh so und jetzt bau mal die Applikation da drauf. Und also die Frage ist, brauche ich halt Cloud auch noch alle die nächsten 5 Jahre? Ja, aber ähm aber wenn die wenn die AI halt super schnell was den Code generiert und Environment generiert und andere Sachen macht, äh ja, dann im Sinne auch von wegwarf. Ähm, ist die Frage, brauche ich halt AWS oder was brauche ich denn dann noch an Tools oder Tooling außenrum?

Sehr, 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. Ja, das heißt äh 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 und auch unsere Prozesse, Scrum, Dailys und und alles hängt am Ende am am Menschen und äh und die Frage ist eben für mich, wenn jetzt es alles AI ist, also was ist denn wirklich eigentlich alles menschentriert in den letzten 20 Jahren und was fällt dann potenziell weg?

Kommt daher auch der Name, kommt daher der Name des Tools? Äh äh ja, so ein bisschen äh aber im Prinzip auch, also ein bisschen Wortspiel und ein bisschen auch ein bisschen Assimov und so. Also es ist schon äh ja, wir werden sehen, wo es hingeht. Ja.

Ähm ich, also ähm vieles von dem, was du sagst, resoniert total mit mir. Ähm so verschiedene Punkte, ne? Also das eine äh was wir auch in der letzten Episode mit mit äh Ulli von Mapbox hatten, die haben eine, ich habe das jetzt genannt, kambrische Explosion 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 ähm Wochenendexperiment oder so oder nebenbei gemacht, so ne.

in dem zweiten Fenster machst du halt irgendwie alle 5 Minuten, drückst du mal Enter oder beantwortest mal eine neue Frage oder stellst eine. Ähm, das ist definitiv ein Punkt, ne, auch zum zum Thema Infrastruktur. Ähm gerade den Mentorrain Club ähm von Heroku migriert. Ähm, gibt Tools wie ähm äh Coolify und irgendwie noch sowas mit Docker im Namen.

Äh, die mehr oder weniger also eine ähnlichen ähnliches Automationslevel auf Beetal zur Verfügung stellen, wie das Heroko bietet, ne? Ähm, von daher und also fairerweise auch Versell, also das sind von Heroko und Versel weg und haben insofern unseren äh Kostenfußabdruck ähm wahrscheinlich durch 10 geteilt oder irgendwie sowas, ne? Ähm und das ist das ist mit mit AI war das auch so so eine Wochenendaktion halt, ne? Und tatsächlich in dem Falle auch, weil wir da noch keinen Live Betrieb drauf hatten beim Aufsetzen erstmal ähm der Agent ist auf dem Server, konfiguriert fröhlich auf dem Server, liest äh Logfiles auf dem Server und agiert er.

Das machen wir jetzt nicht mehr, ne? Jetzt ähm äh ist ist das schon unsere Domäne und wir haben natürlich auch deterministische Automationen jetzt für neue Deployments gebaut, ne? Aber initial beim Aufsetzen war das ähm ganz entspannt und auch und dann der nächste Schritt, ne? Ähm gerade die Tage nebenbei so ein bisschen eine kleine Analyse von so User Journeys äh gemacht.

Der Agent hat halt den ganzen Kontext, ne, der kennt die Datenbanktabellen und äh mal zu sagen: "Hey, schau doch mal, was können wir denn äh machen sozusagen, um die Nutzer noch besser abzuholen, bzw. wo wo sind die denn eigentlich und wo sind so die Heavy Users? Was sind so Patterns? ähm mega gut.

Da war auch eine Halluzination dabei, fairerweise. Äh, aber äh der Grund Tenor der ganzen Analyse äh wir dann noch ein Jupiter Notebook bauen lassen und das selber nachvollzogen mit äh Queries und so, der war einfach Gold richtig. Und da haben wir jetzt äh wieder gute Ansätze und das ist da kommt genau die Frage, ne? Also, wenn du dann wiederum äh sagst, okay, du stoppst da nicht an der Stelle, sondern du guckst dann noch mal drüber und sagst dann: "Okay, und jetzt mit dem machen wir weiter." Äh, ne, also äh ja, wo wo ist da der Mensch noch nötig?

Wo wo ist der Mensch nötig? Und eben sagen mit mit äh mit Human das Experiment, wo ist denn also wo ist denn das Tool nötig? Also wir sehen ja eher so eine End eine Endtoolisierung oder eine eine diese General Tools. Jeder baut sich was eigenes, was du auch sagtest.

Ich habe mir auch sehr viele eigene Tools gebaut für mein Newsletter. CTO Newsletter, da habe ich eben auch schon vor AI, aber mit AI jetzt noch viel mehr ein Tool gebaut, was mir dann die Markdown Sachen konvertiert, Links checkt und und alle möglichen Sachen macht. Ähm, 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 noch mal Andre, was ich auch Leuten immer wieder mal erzähle, ist wir zwei haben mal vor ganz langer Zeit äh einen Ruby Bug gefixt, äh weil der Rubientwickler nicht mehr da war und äh und wir konnen aber bei den nicht Rubi, aber haben es dann hingekriegt. Ähm und äh also wie sind auch dieses Wartbarkeitsproblem äh geht vielleicht weg oder kommt durch zu viele Tools. Also da weiß ich eben nicht, ich find's super spannend, aber ich weiß nicht genau, wo sich denn was hinentwickelt an der Stelle.

Ja. Und welche Tools bleiben? Bleibt Tumin, bleibt's nicht, bleibt AWS? Ich ja, keine Ahnung.

Also auch vielleicht zu dem Thema Z. Ich finde ja äh AI ist super für Terraform. Also ich fand Terraform ja ein bisschen schwierig. Find es mit AI relativ easy.

Ähm aber brauche ich halt Terraform, wenn ich neuen Server einrichte und dann auf den Server, also im kleinen Umfeld jetzt ja mal äh aber in den Server mich einrichte und sag äh Harden the Server. Ja. Und dann sagt er ja, ich gucke mich mal um. Irgendwie App Armor ist nicht da.

SSH ist auf einem Standardport. Ich könnte diese 20 Sachen alle machen und dann sage ich: "Ja, mach mal." Und dann macht er diese 20 Sachen und dann äh also auch das äh meine könnt auch ein Runbook draus machen und Enle Runbook draus machen oder wie auch immer, aber äh ja, da geht's halt wieder darum, welche Tools brauche ich denn oder äh also Ensibil vielleicht ja, aber dann vielleicht kein nicht Terraform, weil Cloud Coden en Runbook schreiben kann bedarfsorientiert und total das ist super spannend sehe ich genauso, ne? Also die weiter gedacht, ne? Äh, du hast ja schon gesagt, aber ist die nächsten 5 Jahre auf jeden Fall safe, so ne, weil die Infrastruktur, die darunter steht, die kriegst ja auch nicht so leicht äh äh repliziert, aber für Sachen, die jetzt gebaut werden und dann vorsichtig wachsen, die können vielleicht auch auf Bettal dann skalierbare, weiß ich Message oder was auch immer quasi intrinsisch bauen oder selber bauen, ne?

Und ist genau wie du sagst irgendwie auch so ein Coolify brauchst du es dann überhaupt noch oder habe ich dann einfach nur für meinen spezifischen Uscase so dediziertes Tooling äh was einfach die KI selber äh wartet, ne? In keine Ahnung kommt irgendwie eine neue Version von irgendwas raus, was ich jetzt deployen will. Stellt fest, oh, mein altes Tool bricht, na ja, fixe ich einfach den Fehler im Tool und dann geht's halt wieder so, dann kann ich es deployen und und es läuft 100%. Ja.

Ja. Na, 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 zumindestens im Innerloop befindet, das ist schon eine starke These, muss ich ehrlich sagen. Da ähm ich meine, das schließt ja an Stefans Code wird verschwinden, so ne, das also, weil das ist ja Code ist ja auch eigentlich nur für Menschen da, ne?

Wenn du es weiterdingkst. Ähm genau. Ich, also wir werden sehen, wohin es geht, ne? So, ich sehe aktuell so zwei Strömung, ne?

Die einen sind so komplett Diolo und sag Code gucke ich mir gar nicht mehr an. Ich mache so Meta äh Reviews von den Changes, ne? Und dann gibt's aber auch immer noch die Strömung Mario Zechner und Co, die sagen: "Nee, nee, ich gucke mir schon den Code noch an, weil ich will den verstehen und ich will auch äh da da sozusagen im Detail wissen, wie es funktioniert." was ich auch nachvollziehen kann, weil ich immer wieder feststelle an den Projekten, an denen ich arbeite, dass ich ähm nach drei Features feststelle, dass das Feature, was ich vor drei Features gebaut habe, gar nicht ähm so gefixt ist, wie ich mir das vorgestellt habe, sondern äh quasi er kein ID Lookup macht, na, wenn ich irgend irgendein äh einfach nur ein äh Werwert oder eine Entität rausholen möchte aus der Datenbank, sondern irgendwie so eine so ein Fallback Mechanismus gebaut hat, weil ein bestimmter Fall nicht funktioniert hat, der aber nicht funktioniert hat, weil die Daten nicht korrekt waren und das Tool hat dann aber gesagt, ach so, dann mache ich es ein bisschen unschärfer und dann oder bzw. die KI, ne, und dann dann funktioniert schon, ne?

Also immer dieses die faule KI in Anführungsstrichen, also äh sprich ich gehe den einfachsten Weg, ne? Und ich also ich finde beide beide ähm äh äh Perspektiven irgendwie nachvollziehbar. Ähm Entwicklerperspektive, Sebastian reinkretschen, das ist Perspektive, weil weil welcher also der Engineering Manager hat das gleiche Problem. Also ich ich gehe zu dem Sentwickler und sag, bau das Feature mal.

Und dann baut er das und dann hat das 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's die AI. Ähm, also für mich ist dann immer die Frage äh oder also ich glaube halt nicht gerade, dass man Code angucken sollte.

Vielleicht liege ich da falsch. Äh, ist jetzt auch nicht meine Firma. Also ich bin jetzt ich habe jetzt keine große Softwarefirma oder so. Ich riskiere nichts mit der groß mit der mit der Meinung.

Ich bin mal festen Überzeugung, dass es einmal äh deutlich produktiver ist, wenn man nicht drauf guckt. Kunde hat mich letztens gefragt, Stefan, was sollten wir machen? Ich höre mir in der Presse, sollten wir 70 oder 80% AI generierten Code haben, dann sage ich äh, die Frage ist, wie komme ich auf 100%? ähm nicht, ob ich 70 oder 80 mache und also für und in dem Umfeld, wie gesagt, ich würde halt einmer gucken, also für mich ist so, ich habe einige Best Practices für AI und eine Back Practice ist schon immer äh jetzt ein Ticket für einen Implementierungsplan zu bauen aus einem PM-ticket und dann nachdem alles programmiert worden ist, dann noch mal zu AI zu sagen so und jetzt guck bitte noch mal dein Gitlock 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 da dann gibt sie schon immer auch wieder Diskrepanzen und dann sagt sagt e wie es so ist. Oh, tut mir leid, habe ich übersehen. Ja, richtig, hast drauf hingewiesen und so weiter und so fort. Aber ähm unterm Strich äh korrigiert sie sich denn dann auch oder fragt mich, ja, habe ich nicht verstanden, was soll ich denn eigentlich machen?

Ähm 100 Pro, ne? Und das ist dann Bestandteil von dem Review Skill, der der automatisch vielleicht am Ende des Workflows sogar vorm Commit selber ausgeführt wird. Äh, also sehe ich, ne? ähm trotzdem ähm bei wir haben letzte Woche ja mit mit Uli von Mcbox gesprochen und da ist auch dieses Thema Ownership without Authorship wieder hochgekommen und da bei denen ist ganz klar ähm Claud schreibt den Code, aber du bist dafür verantwortlich, ne?

Und die, also es ist jetzt quasi an jedem Entwickler selber derzeit noch. die haben da auch ähm sagen wir mal so eine Mischung aus äh ähm die wollen schon, dass die Entwickler ganz viel AI nutzen. Auf der anderen Seite ist aber jeder Entwickler noch für den äh für das Feature, für den Code verantwortlich. Und äh haben aber auch natürlich sehr, sehr viele Guardra.

Bevor Dinge in Production kommen, müssen sie ja komplexe äh Buildpipelines und Testpipelines durchlaufen. Ähm nichtsdestotrotz muss da jeder Entwickler für sich selber entscheiden halt, wie wie er oder sie das gewährleisten kann, ne? Die die Qualität des Codes, ne? Und äh ja, also für mich heißt auch AI heißt nicht äh Responsible Engineering wegzuwerfen.

Also also du bist trotzdem responsible Engineer und wenn du halt vorher irgendwie also wenn du vorher Code geschrieben hast ungetestet in Production gepusht, fand ich das unresp nicht unrantwortlich und wenn du heute das gleiche mit AI machst, ist es auch für mich unverantwortlich. Also das heißt für mich haben diese Maßstäbe an den Engineer sich nicht geändert. Ähm bloß 100% genau und es ist halt an jedem selbst entscheiden, was wo also wie nimmt man die Verantwortung wahr, ne? Das ist genau dieser Freedom.

Sorry Andre. Ich würde sagen, es geht ja nicht ums was, sondern nur ums wie. Ähm und dafüren wahrscheinlich viele Wege nach Rom. Ja, bin aber gespannt, wie sich äh quasi wirklich der der der Innerloop war, nee, eigentlich gar nicht der Innerloop, eigentlich das gesamte der gesamte Software Life Cycle, also quasi nach oben auch Richtung Produkt, aber dann halt auch Richtung Infrastruktur ähm verändert.

Und ich habe heute gelernt und das ist tatsächlich auf der These muss ein bisschen rumdenken, eigentlich die ganzen Abstraktionen, die wir halt irgendwie für uns geschaffen haben, damit wir das irgendwie halt irgendwie verkraften, diese ganze Komplexität. Die braucht man tendenziell nicht, ne? Und das äh quasi das äh quasi rüttet schon auch an ein paar Modes, die es halt irgendwie äh die man die man eigentlich vorher nicht mehr gesehen hatte, ne? Ich sag mal quasi häufig äh nicht heiß ein Lambda Function, ne?

Versuch das mal irgendwohin zu migrieren. Ja, das äh quasi und das muss alles äh muss alles vielleicht gar nicht mehr zukünftig sein. Das ist eine sehr starke These. Hier zuerst gehört.

Punkt noch. Ich habe noch was zu dem Punkt vielleicht von ja von von Sebastian. Ein eine meiner weiteren Thesen. Ich habe so viele Thesen, aber eine weitere vielleicht sollte ich irgendwie hier weiß ich nicht bin nicht so bewandert dabei.

Weiß nicht wie viel Thesen Luther an die war 95 oder so. Ich habe keine 95 Thesen, aber ich habe noch eine These Engineer äh das geht ein bisschen dem was Sebastian gerade gesagt hat. Der Engineer ähm wird gebraucht, weil er die passenden Trigger Words hat. Also äh ich habe das Konzept geklaut quasi und verändert ein bisschen von Ralf, der äh nennt es Sementic Anch, macht auch sehr viel auf LinkedIn und Webseite unter dem Stichwort Cementic Anchers.

muss man sich auf jeden Fall angucken. Äh die Idee ist, ich habe es ein bisschen vereinfacht, weil ich bin halt einfach und nicht ganz so äh intellektuell vielleicht. Bei mir heißt es, ich nenne sie ja Trigger Words. Und was ist ein Trigger Word?

Ein Trigger Word ist etwas, was ein bestimmtes Verhalten bei der AI triggert. Z.B. Meine Beispiel sind TDD ist ein Triggerw anticorruction Layer, Abstraction Layer, ähm ähm API oder ABI äh oder oder es gibt sogar diverseste Triggerwords, die man als Engineer hat und diese Triggerwords sind so ein bisschen wie aus Rollenspielen, aus AD&D Spells. Also man ist so ein bisschen so wie ein Spellcaster, man hat Geheimwissen.

Also ich habe sozusagen 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 und äh solange und das hat zurzeit noch sehr viel positiven Effekt auf die AI und vielleicht in Zukunft nicht mehr. Das geht vielleicht weg irgendwann mal. Äh, aber aktuell nächsten 5 Jahre hat der Engineer einen großen Vorteil gegenüber Leuten, die äh nur mit der AI was bauen, mit dem sie dann sehr sehr gut zu einem Prototypenstad kommen, aber ich glaube nicht in Production, nicht in Skalierbarkeit, nicht in langfristige Wartbarkeit, um Skalierbarkeit, langfristige Wartbarkeit und andere Sachen zu bekommen, Erweiterbarkeit, also diese ganzen soften ähm äh Requirements ähm braucht man diese Triggerws, braucht man diese Spells und dann kann man eben zu AI, während man die mit der AI arbeitet, stelle ich mir das ein so vor, dann kann ich den ähm Abstraction Layer Spell sagen und dann macht ihr das richtige.

Ähm also das ist so ein 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 Triggerws braucht, mit dem man das bei der A das richtige Verhalten erzeugt. Ja, wir reden ja wir reden ja jetzt einen Tag, nachdem äh Entropic, ich wollte es gerade sagen, mehr oder weniger ähäh quasi, also keiner weiß, ne, ob das halt quasi absichtlich oder unabsichtlich, aber egal.

Er hat er hat quasi definitiv unabsichtlich unabsichtlich war das. Die haben ja die haben ja tatsächlich einzelne Leute äh auch angeschrieben und gesagt, du du du den Code nicht weitergeben, auch wenn du ihn gesehen hast, äh wo sie wissen, dass sie Zugriff drauf hatten. Würde ich aber auch machen, wenn ich es absichtlich machen würde. Ja, okay.

Trotzdem der Punkt, ne? Seit im Endeffekt Clode Code geliegt. Äh müss man kann man das nachvollziehen? Also, weil ich würde jetzt eher ab erwarten, also der die These finde ich auch stark.

Ich würde aber erwarten, dass das nicht im LM ist, sondern eigentlich eher im Environment halt irgendwie was äh triggert. Wie wie meinst du? Na, das müsste man doch eigentlich nachvollziehen können, was Stefan gerade gesagt hat. Also gibt's da äh wie es genannt?

Semantic Triggerwsantic Semantic Ankers. Genau. Semantic Ankers. Ähm, müss man doch gpp mal nachschauen äh in Cloud Code ähm ob das äh quasi dahingehend halt irgendeine Berücksichtigung gibt oder ne?

Ich glaube, das liegt halt im Modell sicher. Also ja, also es sind auch es geht auch sehr sehr viel weiter als das. Also bei Ralf, bei mir ist ja wie gesagt mir so klein. Bei Ralf geht's ja auch noch mal Triggerws in anderen Bereichen.

Also wie schreibe ich gutes Deutsch, wie gibt's bestimmte Triggerws, wie mache ich also McKinzie hat ein ganzen Stapel Triggerwords, wie sie arbeiten. Es gibt von Gartner Trigger Words, äh die ich kennen muss, um dann wenn ich wenn ich der Consultant bin, dann kenne ich die Gartner und McKinsey Trigger Words und dann erzeuge ich bestimmte Arten von Texten oder Folien äh in der AI. Also, ich kriege die Erde dazu dann äh die zu sagen, wie wie McKinzie zu agieren, wenn ich die passenden Zaubersprüche da hab. Ähm vielleicht ein bisschen Ach so, Sebastian.

Ja, ich woll wollte nur einen anderen Gedankengang noch, der jetzt gar nicht damit zu tun hatte. Also fairerweise äh um das äh Cloud Code Ding noch mal ähm abzuschließen, da ist natürlich gibt's natürlich auch viel Sport und Theme, ne? Vibe Coding Aer Codes von der KI geschrieben. Gibt's auch ein Video von The Prim Gen, wo er ähm äh Kommentare in GitHub durchgeht äh die halt dann auch von Cloud Code automatisch äh beantwortet werden.

Und ich meine, so ist tatsächlich auch dieser League entstanden. Also spricht, dass da hat jemand gesagt, hier da funktioniert eine Source Map nicht und so ist dann die Source Map von Cloud Code halt äh open sourced worden, was äh natürlich ähm sagen wir mal zum Thema soll man sich das alles angucken oder nicht, aber fairerweise auch wenn kann mir fällt Klammer ein und zwar äh jetzt vor kurzem hat auch Cloud Code dieses äh kleine Tier in Clud Code, wie heiße wie hießen die früher? Tamagoi gelauncht. Wer auch immer, also ich hatte den Tamagoci.

Ähm ich bin so alt und da stellt sich natürlich jetzt auch die Frage, okay, Tamagoci in Cloud Code äh ist es jetzt der Zeitpunkt, wo ihr nichts mehr einfällt? Also, äh die haben ja super super viel Release, also ich habe dann irgendwie jeden Tag äh äh 2170, 2171, jetzt sind wir glaube ich bei 2189. Äh, wer in dem Podcast wird wahrscheinlich 2190 sein. Ähm, da stellt sich mir die Frage, wenn man jetzt Tamagochcis äh in Cloud Code reinbaut, die vielleicht einen Hintergrund haben oder wie auch immer.

Ähm, aber das ist eben die Klammer jetzt von Cloud Code zu dem, was wir vorher diskutiert haben. Äh, wenn erstellen von Features kein Limit mehr ist, ähm welche Features baue ich denn alle in Human ein? Also potenziell, wenn ich Tamagoi einbaut, dann äh bist du vom Weg abgekommen. Ja, exakt.

You jump the Shark. Ja, 100 Pro. Genau. Äh und den Gedanken, den ich aber eigentlich noch mal führen wollte, ist noch mal also andere Perspektive auf Tools.

Ähm weil was ich gerade wahrnehme, also ich aute mich jetzt mal, ich war nie ein CLI Fan, weil ich ähm meine äh kognitiven, sagen wir mal, Kapazitäten immer gern für andere Themen genutzt habe, als mir irgendwelche äh Commands zu merken und so, ne? Ich habe das gerne, wenn ich mir das erschließen konnte und dann in der UI irgendwie mit also quasi einfach beim sehen mich dran erinnern konnte, ne? Äh, das ändert sich jetzt massiv, ne, weil ähm alle möglichen Applikationen, Tools, Plattformen auf einmal zugängig zugängig werden, weil es halt jetzt eine CLI gibt äh um damit zu interagieren, ne? Ich meine, das Gute ist, meine Cognitive Load äh erhöht sich dadurch jetzt nicht massiv, weil die KI macht es ja für mich, ne?

Ich muss ja nur die KI Trigger Words wieder kennen, damit es äh funktioniert und die Tools dann noch installieren, ne? Aber äh das finde ich auch gerade spannend. Das ist also jetzt fairerweise so ein Zwischending, weil am Ende CLI Tools sind ja also auch Standard, kann jeder Entwickler prinzipiell auch benutzen, ne? Aber die auch da haben wir eher so eine Proliferation, weil die KI eben mit dem CLI Tool äh auf der Kommandozelle einfach sehr sehr gut umgehen kann.

Das viel besser funktioniert natürlich als irgendwie in dem Browser, so ne, was inzwischen aber fairerweise auch immer besser funktioniert. Also Chrome äh äh Bridge oder wie das heißt hier mein mein wenn ich nicht weiterkomme mit an meiner App, dann sage ich hier guck mal in mein Browser, das geht nicht so mach und dann rödelst 10 Minuten und dann geht's. Gut auch gut CLI bloß vielleicht da zu das was halt die AI kann mit dem CLI Tool ist, dass sie das mühelos mit einer mit Bashbe Befehlen mit Pipes mit Vorloops und anderen Sachen integriert. Also ich macht ein C Tool, dann macht sie ein Vorloop, dann macht s ein Sorten TR, dann macht sie JQ, um die Jason rauszufiltern und dann also äh die AI ist sehr gut darin, ein CLI Tool als Baustein ähm in dem größeren Gesamtkunstwerk äh sage ich mal äh zu verwenden.

Ja, genau. Ja. Ja. Und das ist ja auch so bisschen der Startpunkt umpai wiederum, ne?

Sind wieder, also kann ja eigentlich per se nur vier Tools, glaube ich, ne? irgendwie äh Verzeichnis scannen und Datei lesen etc., ne? Und ähm das ist das, was du in der Programmierung im Normal ver brauchst und machst du ein Grab und dann findest du irgendwie, wo sich bestimmte Sachen wiederfinden etc. und dann reicherst das an, um Zugriff auf Linia, Gira, was auch immer und dann kriegst du auch den Kontext angereichert.

Easy, ne? Andre, du wolltest dann versuchen wir doch dann versuchen wir doch mal so langsam eine Klammer drum zu kriegen. Wir machen Special Edition, insofern, glaube muss jetzt nicht skisch unendlich lang sein, aber Stefan, für dich war quasi also zwei Fragen. Wann baust du die Tamagocchis ein?

Erste Frage. Äh zweite Frage äh quasi wie wie kann man dir wie können wir dir helfen mit Human? Ähm, also erstens vielleicht brauche ich das, also ich brau ja sowieso nichts mehr als Cloud, aber ähm vielleicht mache ich es gleich morgen äh oder heute Abend im Hotelzimmer. Äh mal sehen.

Und das ist das eine. Äh heißt dann aber nicht, dass mir nichts mehr einfällt. Wie kann jeder helfen, ausprobieren, ähm Feedback geben. Äh es hat halt eben auch viel mit Betriebssystem und anderen Sachen zu tun.

Also sprich äh läuft bei mir äh heißt aber nicht, dass es bei anderen Leuten läuft. Also da garne mir sagen, ähm bei mir läuft's nicht, sieht so und so aus. Äh oder das das Feature fehlt mir für mein Corporate äh damit ich es einführen kann oder damit ich es vorschlagen könnte. Also da bin ich sehr dankbar für jeglichen ähm Feedback.

Sehr gerne. Kann man contributen? Äh ja, weiß ich nicht. Im Prinzip ja auch noch mal irgend irgendwann noch mal wahrscheinlich noch eine Folge wert quasi wie Open Source quasi in AI Zeiten aussieht.

Äh quasi würde mich auch brennend interessieren, wie man halt also wie würde dann jetzt eine Contribution aussehen? Äh quasi quasi quasi lässt du da dein Agent halt einfach laufen oder also quasi was ist der Mehrwert an der Stelle? Ähm weil es der Code selbst gar nicht mehr ist. Ähm ist es die Idee?

Ist es die Was ist es? Ähm, genau. Aber ähm äh auf jeden Fall danke, dass ihr Zeit genommen hast. Ich wir hten ja am Anfang gesagt, ein mega interessantes Projekt.

Ähm ich gucke gerade auf die Seite, ich sehe 27 Gitub Stars. Ich bin gespannt ähm wie sich das äh entwickelt. Vielen Dank. Ich bin Dank bei vielen einzelnen Aufruf an unsere Zuhörer, ne?

Probiert's aus. Lasst ein Like da, Gitups da, wenn es euch gefallen hat. Genau. Und gebt Feedback, ne?

Genau, ich mache hier noch ein Easterck rein quasi in der Hoffnung. Mal im Endeffekt müssen wir auch ganz ehrlich sein. Sebastian schneidet bei uns ja immer. Also wenn wenn wir richtig schnell sind, ist diese Folge live, bevor wir bei Trusted Jobs den nächsten Selfeducation Friday haben.

Heißt einen Tag, wo sich alle Leute quasi mit Themen beschäftigen können, um weiter sich weiter zu entwickeln. Mal schauen, wie viel an dem Freitag dann vielleicht hier an Gitupstars dazu kommen, weil Leute diesen Podcast gehört haben und denken, das probiere ich mal aus. Challenge accepted. Das ist gerade von Folge 10 zu Folge 9 geworden.

Morgen früh. Self Education Friday ist der letzte Freitag immer am Montag äh im Monat. Äh insofern ein bisschen Zeit. Ja, letzte der letzte Freitag im Montag.

Genau, genau. Vielen Dank, Stefan. Ich danke euch. Ja, vielen, vielen Dank.

Der HMZde Podcast ist ein gemeinsames Projekt von Sebastian Heidemier zu Erpen und Andre Neubauer. Infos zum Gast und Themen aus dem Podcast findest du in den Showotes. Diskutieren kannst du mit uns bei LinkedIn und für alles andere, z.B. wen du gerne mal hier hören möchtest, kannst du gerne eine E-Mail an podcast@hamzde.

Vielen Dank für deine Zeit. Wenn es dir gefallen hat, abonniere den Podcast.