# Secure AI Development Environments and Engineering Trends

**Podcast:** HMZE
**Published:** 2026-04-02

## Transcript

Works on my machines.
Sehr gut.
Es ist doch schön, wenn sich bestimmte Dinge einfach nicht ändern.
Herzlich willkommen zu einer neuen Folge von HMZE Beyond Vibecoding, der Podcast, in dem wir den fundamentalen Change in der Softwareentwicklung begleiten.
Ich bin Sebastian Heidemeyer zu Erben, CTO bei North.io.
Und ich bin André 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 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 soll das anders sein, Agenc 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 zehnten 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 Vorgeplänkel.
Also Stefan, stell dich doch mal vor, und womit arbeitest du gerade sparen?
Das könnt ihr euch in der ersten Episode sozusagen von Beyond Vibecoding von vor zehn Wochen anhören.
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.
Wir sind ganz neugierig, denn du hast ja vor kurzem, ich weiß gar nicht, wann ich es das erste Mal mitgekriegt habe, wahrscheinlich letzte Woche, dein neues Tool, würde ich mal sagen, ne, Human angefangen zu präsentieren.
Und das, ich habe 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 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.
Greater, super Stichwort.
Also was habe ich mir dabei gedacht?
Ich habe, es kommt aus einem gewissen Need, also einem gewissen Bedarf heraus, ein Tool, um 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 langen Python Prompts sagen will, darf ich denen ausführen, ja, nein, ja, weiß ich nicht, weil 20 Zeilen Python verstehe ich jetzt auch nicht so schnell.
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 hab dann somit angefangen, Human zu bauen, was im Prinzip anfängt als Dev-Container ein einfaches Setup für den Dev-Container.
Das heißt, ich sage, mach Human-Init und dann habe ich am Ende den Dev-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, hapert immer.
Also habe ich gesagt, okay, dann muss man das irgendwie auch machen mit einem Proxy und der Firewall.
Und dann geht es aber auch letztlich dann darum, zum Beispiel um 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.
Also 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 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 mal an, gewählt, insbesondere, meint es ja auch YOLO-Mode, um Security zu gewährleisten, vermutlich, ne?
Genau.
Also das ist einfach ein Dateizugriff limitiert ist auf das aktuelle Arbeitsverzeichnis und nicht auf andere Sachen.
Und in Kombination dann eben mit einer Firewall, sprich slash Proxy auch dazu zu kontrollieren, auf welche Webseiten oder URLs Cloud Code aufzupreffen.
Ich hatte es ja am Wochenende, ich hatte sich ja im Wochenende angeschrieben und das auch für mich, also so als Wochenendprojekt mal durchprobiert und war begeistert, weil hat er ja gerade schon so ein bisschen Vorgespräch gesagt.
Also ehrlich gesagt würde ich erwarten, dass das für jeder halbwegs Enterprise Great Company so ein bisschen das Default-Setup halt irgendwie ist.
Ich 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 geneigten Zuhörer, wie würde man es denn ansonsten machen?
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.
Also wenn wer schon mal einen 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, nee, funktioniert nicht, aber ich habe da noch einen Token, ich und Curl, ich kann doch jetzt einfach mal selber rumbasteln.
Also die AI ist so richtig eager, was zu machen, ja, und dann, wenn sie irgendwo nochmal einen Token findet, den sie schon mal hatte, dann macht die ganz komische Sachen.
Also man müsste das kontrollieren in dem Dev-Container.
Das gibt Tools dafür, also One-CLI zum Beispiel, um sowas zu managen.
Aber es sind halt lauter verschiedene Tools und ich glaube, wenn ich als, die ich mir alle zusammensuchen muss, die ich konfigurieren muss, was dann manchmal auch nicht ganz funktioniert oder nicht ganz reibungslos funktioniert.
Und 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 in der im Repo haben und so, also es ist alles nichts halbes und nichts Ganzes.
Und ich will einfach irgendwas, was einfach funktioniert.
Weil mich geht es ja auch um diese Sachen gar nicht.
Also, ich will ja eigentlich nur, dass Cloud 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.
Und jetzt hast du ja über die letzten Wochen diesen Unterbau gebaut.
Auf der Seite steht The Secure Developer OS for AI Empowered Engineering.
Also kannst du, magst du das Zielbild teilen?
Also, wenn es denn ein C-Build schon gibt?
Das Zielbild ist alles außer Cloud Code.
Also du brauchst Human und Cloud Code und dann kannst du, dann kannst du letztlich Cloud Codes sicher laufen lassen in einem Environment, wo es den Context auf Context Zugriff hat und so weiter und so fort.
Alles, alles was es braucht.
Das ist sozusagen das Zielbild.
Ist jetzt wenig inspired vielleicht, aber es ist halt ultra pragmatisch.
Als etwas, was halt dann einfach funktioniert.
Es hat auch ein bisschen noch Prompting drin.
Also es hat auch Custom Prompts, an denen ich arbeite.
Also sozusagen, also Code Review oder Ticket, weil die Idee war dann auch nochmal, wenn ich sowieso Connectoren habe an Gyra, Linear, Shortcut, dann kann ich auch Prompts nehmen, die sozusagen einen Plan nicht lokal nur haben, sondern einen Ticket draus erzeugen oder sowas, was dann auch im Corporate Umfeld nochmal das Thema Audit und Traceability adressiert, was das Ganze eben auch nochmal adressieren kann.
Also oder soll.
Also das ist vielleicht so, es ist schwierig zu fassen.
Also alles in einem Tool, sonst braucht man nichts.
Außer Cloud Code.
Ja, alles hinter einem, ja stimmt, Tool, ja, so eine Art Proxy im Endeffekt, ne?
Also so ein Layer und im Zweifelsfall auch Wegwerfumgebung.
Es ist schon ein bisschen wie so ein Operating System.
Also es 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 in Prompt automatisch zuweisen oder Tickets zuweisen.
Also sozusagen ein bisschen eine Art Scheduler.
Die Connectoren kann man sich auch im Prinzip ein bisschen wie ein File System vorstellen.
Also es ist schon ein bisschen in die Richtung auch Operating System auf einer höheren Ebene mit Cloud Code sozusagen als Executor kann.
Ja, mich erinnert das tatsächlich von der Herangehensweise sehr an Pi.
Das ist ja mein Agent of Choice gerade, sorry.
Und da, also A gibt es halt auch ein Ökosystem, was viele dieser Dinge auch mitbringt, also eigene CLIs für genauso Token Management.
Dann du hast ja auch bestimmte Skills dabei, die so ein Workflow abbilden, so einen typischen Development Workflow, also IDET Plan und dann Execute und Review und so.
Genau, das gibt es da auch und das nutze ich tatsächlich auch sehr intensiv bei Pi.
Und genau, also insofern würde ich Pi sozusagen als fast größeren Konkurrenten ansehen, weil da kann man natürlich auch so ein Skills, Extensions und so Packagen und dann als ein Bundle ausrollen.
Also ich glaube, es gibt sogar speziell von Pi so bestimmte Packages, man kann sich da auch Extensions bilden bauen.
Aber das geht natürlich nicht, wenn man mit Cloud arbeitet, weil dann, also zumindest ist dann sehr teuer ist, weil man dann nur API Mieter Cloud nutzen kann.
Und genau, dafür ist natürlich Human eine sehr, sehr gute Alternative, wenn man das mit Cloud machen möchte.
Nee, aber also ganz genau, ich weiß jetzt nicht, ob ich das sagen sollte in dem Podcast, aber ich weiß natürlich nicht, was ich tue.
Also, ich meine Herangehensweise 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, weil ich davon, weil ich rein der persönlichen Meinung bin, dass Cloud Code mit Abstand das Beste aktuell ist, um Code zu entwickeln und Review zu machen und Bugs zu finden und alle diese Dinge.
Aber genau, wo es 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.
Ja, ja, ich glaube, das geht so ein bisschen zurück auf das, was wir mit Markus irgendwann mal hatten.
Musste einfach quasi ausprobieren, rumfummeln, was kann ich glaube, das hat er, glaube ich, das hat er gekoint.
Das, was ich mich, das, was, das, was ich mich in dem Zusammenhang so ein bisschen frage, ist, dass wir so auch gerade meine so Entwicklungsumgebung.
Also, das, äh, wie wird sich das?
Also, ist das etwas, was many 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.
Dass halt irgendwie die IDI quasi das war sehr individuell, da gab es halt irgendwie, was nicht, das Eclipse-Lager, JetBrains-Lager, and so weiter und so forth.
Die Frage, die ich mir auch stelle, ist halt quasi inwiefern would this happen start centralisiert.
Also, inwiefern would this halt what the firm halt to verfügung stellt, and then musst du da drin halt arbeiten.
Ja, also quasi wie IntelliJ.
Also the frame is, also war ja quasi lange time the standard in fewer.
IntelliJ, NetBeans, Eclipse, and so on and so forth.
Dann hat sich das aber stark eingeschränkt in IntelliJ.
Dann kann man irgendwann VS Studio as a kostenloses Tool.
But I think that we have new tool-categorien.
Ich versuche mit Human a toolcategory to show.
But we create new tools.
Das ist immer noch so, glaube ich, in Unternehmen.
Und when we when we gucken in, im Umbruch, sage ich mal, was ich so sehe mit den Firmen, with which I aren ich arbeite und in the claim, which I aren't, ist, dass halt immer mehr, kein IDE and key cursor mehr verwenden, sondern in Cloud Code CLI arbeiten und dort sagen, mach das und das und das, and then viellect in a review machine, vielleicht haben sie ZTD often, ZAD often, or irgendwelche Sachen, vielleicht haben sie noch Visual Studio often, um ab und an mal reinzugucken.
Aber es gibt, ich sehe schon eine sehr starke Bewegung Richtung Cloud Code CLI oder Open Code CLI.
Also deswegen glaube ich, so die Idee als das Entwickler-Tool ist, glaube ich, abgelöst.
Es sei denn, jemand kommt mit einer ganz genialen neuen Idee.
Will ich jetzt nicht eine Abrede stellen oder so.
Aber wir wissen nicht genau, welche Kategorien an neuen Tools es denn dann eigentlich geben wird.
Ja.
Da bin ich, da bin ich, da bin ich bei dir.
Also ich glaube, dass quasi das die Zeit, wo zumindest der Code-Teil in der IDE, den Hauptspace eingenommen hat, 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.
Es ist halt irgendwie alles unter, also wie so eine Kommandozentrale.
Ja, also wissen wir alle nicht, aber quasi 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 André.
Und dass so ein Tooling benötigt wird, ist, glaube ich, auch klar.
Ich glaube, deine Intuition, Stefan, die kommt ja daher, dass du gerade dir selber so ein Tooling wünschst und quasi für dich das Tooling geschaffen hat, hast, was du ja gerne hättest.
Und so ähnliche Automationen bauen sich meines Erachtens nachher gerade verschiedene Leute.
Also neulich auch ein Podcast gehört mit Mario Zechner, der baut sich auch nochmal um Pi rum, so eine so eine Control Plane gerade.
Von daher, das ist, glaube ich, also zweifelsohne relevant.
Die Frage ist, ob das nachher auch alles von Enthropic kommt und oder ob es da nochmal extra Anbieter geben wird.
Sorry, André, jetzt habe ich dich unterbrochen.
Ich hatte nix, gar nichts, also hattest mich nicht unterbrochen.
Vielleicht bloß ein Gedanke, wenn du so ein bisschen so Roadmap, ich muss ja trotzdem nochmal fragen, vorhin meintest, also auf dem OS-Thema, so Roadmap, was kann man denn da noch erwarten?
Also quasi in welche Breite willst du denn 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.
Weiß ich jetzt nicht, inwiefern das halt irgendwie ein Benefit ist, das halt mit zu integrieren, aber hast du da irgendwelche Gedanken?
Ja, es gibt jetzt schon einen Ideate-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, also wo am Ende die Entwicklung anfängt oder das weiß ich nicht.
Ich probier das aus.
In der Breite eher in die Breite, weil für mich ist natürlich das alles ein Experiment.
Jetzt, wer mitmacht, ist 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 dem halben Tag machen.
Also jetzt eine Integration von Gyra oder sowas ist halt ein halber Tag AI-Arbeit.
Also geht es ziemlich schnell und dann hat es irgendwelche Edge Cases und dann geht das, nicht, das, nichts.
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.
Ich kann halt sagen, hier gibt es eine Bibliothek oder überlegt dir mal, wie könnte man das und das anbinden, dann machen wir da ein paar Plan Iterations und dann habe ich die Integration im Prinzip.
Die Frage ist natürlich, wie weit geht es in die Bright?
Also wie viel ist da managbar?
Also wenn ich jetzt, ne, ich habe 20 Integrations, 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 dann sonst noch?
Oder gibt es überhaupt welche?
Für mich sehr, sehr spannend.
Ja, das ist glaube ich, das ist ein quasi total faires Seitenexperiment.
Da bin ich, bin ich komplett bei dir.
Ich hatte mich am Anfang, als ich das erste Mal ausprobiert habe, gefragt, oder so ein bisschen zurückerinnert, geführt an die Cloud-Seiten, 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 hat es ja nie weggeschmissen, sondern immer quasi bloß quasi die nächste, die nächste Iteration, die nächste Iteration und dann ist man ja dazu übergegangen, dass man einfach Environments wegschmeißt.
Ich hatte den Eindruck gehabt, das könnte man ja hier genauso machen, dass eigentlich deine Entwicklungsumgebung zum Wegschmeißen.
Du könntest eigentlich sagen, für jeden Feature-Request, für jedes, für jedes Projekt einfach immer ein neues Environment.
Hast du mal in die Richtung gedacht oder würdest du sagen konzeptionell eigentlich eher nicht?
Konzeptionell eher ja.
Es gibt ja auch andere Ansätze.
Also, ich habe vorher sehr, sehr viel mit anderen Ansätzen experimentiert.
Also zum Beispiel unter Linux gibt es ja zum Beispiel so ein Tool, das heißt Bubble Rock 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 also es gibt solche Ansätze, Cloud Code einfach sozusagen in so eine Chale zu packen.
Linux, Jail oder auf dem Mac, gibt es andere Channel-Mechanismen.
Dann habe ich natürlich trotzdem immer noch die Problematik, wie kommt, wie funktioniert mein Rest meines Environments, also mit den 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 einem mit so einer Chale und dann mache ich was und dann beende ich es wieder.
Und da kann ich es potenziell auch in CI 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 ein bisschen in die Richtung, ja.
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 Co.
zum Beispiel einfach dann selbstständig von Ticket, also wenn es so gut ist, dass es von einem Ticket disidiated und Lücken findet oder aus einem Strategie-Tickets 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, was an den Kopf kommt.
Aber das verschiebt sich halt sehr viel.
Deswegen, ja, dieses Eins pro Feature und vielleicht hier zum Beispiel, da ist ein Ticket, mach das mal in Production, dann läuft die Umgebung, mach das und dann habe ich das Feature im Live-System oder so.
Ja.
Also zu dem, was du sagtest, ja.
Ich weiß bloß noch nicht genau wie.
Ja.
Bitte, Andre.
Ich hätte jetzt bloß nochmal gesagt, naja, ich finde das halt spannend.
Also, ich finde dieses, also quasi dieses, also diese, wie kann ich sagen, sagen Backmath-Mentalität, glaube ich, im Real Life finde ich es nicht spannend, aber halt ansonsten ist halt einfach immer vom Scratch, immer eine neue Umgebung, immer wieder, also das finde ich dadurch, dass es auch virtuell ist und erstmal nicht viel kostet, finde ich es eigentlich eher den erstreben, erstrebenswertigen, anstrebenswerteren Ansatz, weil es halt eben nicht ein mundgekloppertes Environment ist, sondern halt, du kannst es immer reproduzieren, es ist immer automatisiert, also es ist immer quasi kein manueller Aufwand.
Das, was ich vielleicht eine Frage dann doch noch, da muss ich mich nochmal dazwischen sneaken, Sebastian, sorry dafür.
Also der ganze Infrastrukturbereich, also quasi so das quasi Deployment, das hast du da, ist da ausgekauft, zumindest bis jetzt on Purpose?
Nee.
Also für meine Privatsachen, also für meine Webseite oder sowas, 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 ja 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 mich für meine kleinen Sachen, die ohne großes Risiko, sag ich mal, sind, weil keine, keine nicht mir anvertraute Kundendaten sind, die verloren gehen können oder so, macht ihr AI relativ viel von dem operationellen Betrieb auch schon, ohne dass ich da drauf gucken muss.
Also ja.
Ich fand das halt, also ich fand den Gedanken vor, was nicht schon längere Zeit her, ich fand den Gedanken irgendwie spannend, dass man diesen Entwicklungszyklus mit dem Produktzyklus halt irgendwie merged.
Das ist halt also quasi, dass du halt, und da passt jetzt halt Human ganz gut dazu, du hast halt im Endeffekt die ganze Chain, die ganzen Entwicklungsprozess bis in die Produktion rein und das wird halt auch ein sich selbst fütternde System.
Also 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önntest du halt irgendwie überlegen, okay, IDET, ne, ist halt irgendwie was, was könnte dem helfen, dann wird das durchgebaut, wird gebaut, okay, ist nicht besser, nochmal.
Und damit, also im Endeffekt würdest du damit so ein bisschen in die Richtung so, was nicht, heißt das Dark Factories?
Das ist es, ne?
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 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 ist auch so sein, meine Theorie, was ich auch mit meinen Kunden immer platziere, also ich Human ist auch integriert mit Amplitude zum einen oder mit Sentry zum anderen.
Also ich bin ja der Meinung, wenn ich jetzt, also zu sagen, hier baue mal ein Feature oder wir machen mal Planning zu dem Feature oder zu Ideation 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 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 DAI gesagt, hier sind tausend Tests, geh mal die Tests durch, analysiere die Test und findet Bugs basierend auf den Tests.
Und der AI hat halt zwei Bugs gefunden.
Also nicht in Human, sondern in einem anderen Produkt von mir.
Und das hätte ich jetzt nicht in dem Entwickler gegeben.
Ich hätte nicht gesagt, hier Entwickler, guck mal 1000 Bugs, 1000 Tests an.
Also ich finde es sehr, sehr spannend, Sachen zu machen mit der AI, die vorhin 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 ich benutze, die nicht nutzer, die Benutzungsdaten, mit in den Planungsprozess an der Stelle mit einfließen zu lassen.
Und vielleicht zum Deployment Code noch was.
Wir sehen ja, 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 es ein Sticky Header.
So when man is jetzt weiter denkt, ich versuche ja irgendwie auch immer weiter zu denken.
Ich habe irgendwie Philosophie studiert auch ein bisschen und ich versuche auch weiter zu denken oder größer zu denken und so, brauche ich AWS?
Also brauche ich nicht nur Bare Metal.
Also ich sag jetzt hier ist bare Metal, so, und jetzt baue mal die Application da drauf.
Und also die Frage ist, brauche ich halt Cloud auch noch?
Die nächsten fünf Jahre ja, aber wenn die AI halt super schnell was den Code generiert und Environment generiert and other things macht, ja, dann im Sinne of Wegwerf.
Das ist die Frage, brauche ich halt AWS oder was braucht ich denn dann noch an Tools oder Tooling außenrum?
Sehr, sehr viel von dem Tooling, was wir haben, was die DE betrifft, aber was auch AWS betrifft, ist halt human-centric.
Also jetzt nicht human-centric, sondern mensch-centrientriert.
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?
Und auch unsere Prozesse, Scrum, Dailies und alles hängt am Ende am Menschen.
Und die Frage ist eben für mich, when jetzt es alles AI is, also was ist denn wirklich eigentlich alles mensch zentriert in den letzten 20 Jahren und was fällt dann potenziell weg.
Kommt daher auch der Name?
Kommt daher der Name des Tools?
Ja, so ein bisschen.
Aber im Prinzip auch, also ein bisschen Wortspielen und ein bisschen auf ein bisschen Asimorph und so, also es ist schon, ja, wir werden sehen, wo es hingeht.
Ja.
Ich, also vieles von dem, was du sagst, resoniert total mit mir.
So verschiedene Punkte.
Also das eine, was wir auch in der letzten Episode mit Uli von MacBox 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 Wochenendexperiment oder so oder nebenbei gemacht.
In dem 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.
Gerade den Mentoring Club von Heroku wegmigriert.
Es gibt Tools wie Kulify und irgendwie noch sowas mit Docker im Namen, die mehr oder weniger, also eine ähnlich, ein ähnliches Automationslevel auf Bare Metal zur Verfügung stellen, wie das Heroku bietet.
Von daher, also fairerweise auch Versel, also wir sind von Heroku und Wurzel weg und haben insofern unseren Kostenfußabdruck wahrscheinlich durch 10 geteilt oder irgendwie sowas.
Und das ist mit AI, war das auch so eine Wochenendaktion halt.
Und tatsächlich in dem Falle auch, weil wir da noch keinen Live-Betrieb drauf hatten beim Aufsetzen erstmal, der Agent ist auf dem Server, konfiguriert fröhlich auf dem Server, liest Logfiles 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 Aussetzen war das ganz entspannt.
Und auch, und 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, hey, schau doch mal, was können wir denn machen, sozusagen, um die Nutzer noch besser abzuholen, beziehungsweise, wo sind die denn eigentlich und wo sind so die Heavy Users, was sind so Patterns, mega gut.
Da war auch eine Halluzination dabei, fairerweise.
Aber der Grundtenor der ganzen Analyse, wenn 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.
Und da ist, da kommt genau die Frage, ne?
Also, 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.
Also wo ist da dein Mensch noch nötig?
Wo ist der Mensch nötig?
Und eben, mit Human das Experiment, wo ist denn, also wo ist denn das Tool nötig?
Also, wir sehen ja eher so eine End-Tool-Isier oder eine General Tools.
Jeder baut sich was Eigenes.
Was du ja auch sagtest, ich habe mir auch sehr viele eigene Tools gebaut.
Für mein Newsletter, zum Beispiel, ich habe ein 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 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 es leicht warten, weil ja DAI das wartet.
Also ich erinnere mich nochmal, ange, was ich auf den Leuten immer wieder mal erzähle, ist, wir zwei haben mal ganz langer Zeit einen Ruby-Bug gefixt, weil der Ruby-Entwickler nicht mehr da war.
Und wir konnten aber bei denen nicht Ruby, aber haben es dann hingekriegt.
Und also, wie ist 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, ja?
Und welche Tools bleiben?
Bleibt Human, bleib's nicht, bleibt AWS.
Ich, ja, keine Ahnung.
Also auch vielleicht zu dem Thema, ich finde ja AI super für Terraform.
Also ich fand Terraform ja ein bisschen schwierig.
Ich finde es mit AI relativ easy.
Aber brauche ich halt Terraform, wenn ich einen neuen Server einrichte und dann auf den Server, also im kleinen Umfeld jetzt, ja, mal, aber in den Server mich einrichtet und sage, haben das Server.
Ja, und dann sagt er, ah 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, also auch das, ich meine, er könnte ja auch da ein Run-Book draus machen oder ein Ansible-Run-Book draus machen oder wie auch immer.
Aber ja, da geht es halt wieder darum, welche Tools brauche ich denn?
Oder also Ansible vielleicht ja, aber dann vielleicht kein Nicht Terraform, weil Cloud Code ein Ansible Run-Book schreiben kann, bedarfsorientiert.
Total.
Das ist super spannend, sehe ich genauso.
Also weiter gedacht, du hast ja schon gesagt, AWS die nächsten fünf Jahre auf jeden Fall safe so, ne?
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, weiß ich, Message-Ques oder was auch immer quasi intrinsisch bauen oder selber bauen.
Und es 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 Use Case so 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, ja.
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.
Ich meine, das schließt ja an Stefans Code wird verschwinden.
Weil das ist ja, Code ist ja auch eigentlich nur für Menschen da, wenn du es weiter denkst.
Genau, ich, also wir werden sehen, wohin das geht.
Ich sehe aktuell so zwei Strömungen.
Die einen sind so komplett Diolo und sagt, 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, Zechner und Co., die sagen, nee, nee, ich gucke mir schon den Code noch an, weil ich will den verstehen und ich will auch 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 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 quasi eher kein ID-Lookup macht, wenn ich irgendwo einfach nur einen Wehrwert oder eine Entität rausholen möchte aus der Datenbank, sondern irgendwie 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, achso, dann mache ich es ein bisschen unschärfer und dann, 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.
Und ich, also ich finde beide Perspektiven irgendwie nachvollziehbar.
Du bist eine Entwicklerperspektive, Sebastian, darf ich einfach reinkretschen.
Ja, klar, bitte.
Also der Engineering Manager hat ja das gleiche Problem.
Also ich gehe zu einem CD-Entwickler und sage, baue 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, oder ich glaube halt nicht gerade, dass man einen Code angucken sollte.
Vielleicht liege ich da falsch.
Es ist jetzt auch nicht meine Firma, also ich bin jetzt, ich habe jetzt keine große Softwarefirma oder so.
Ich riskiere nichts mit der Meinung.
Ich bin mal bei der festen Überzeugung, dass es einfach deutlich produktiver ist, wenn man nicht drauf guckt.
Ein Kunde hat mich letztens gefragt, Stefan, was sollten wir machen?
Ich höre immer in der Presse, sollten wir 70 oder 80 Prozent AI-generierten Code haben, dann sage ich, die Frage ist, wie komme ich auf 100%?
Nicht ob ich 70 oder 80 mache.
Und in dem Umfeld, wie gesagt, ich würde halt einfach immer gucken, also für mich ist so, ich habe halt einige Best Practices for AI und eine Backpack-Practice schon immer jetzt ein Ticket für einen Implementierungsplan zu bauen aus einem PM-Ticket und dann nachdem alles programmiert worden ist, dann nochmal zu 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 sie schon immer auch wieder Diskrepanzen.
Und dann sagt der ey, wie es so ist, oh, tut mir leid, habe ich übersehen, ja, richtig, hast du darauf hingewiesen und so weiter und so fort.
Aber unterm Strich korrigiert sie sich denn dann auch oder fragt mich, ja, habe ich nicht verstanden, was soll die denn eigentlich machen.
Oder Pro, ne?
Und das ist dann Bestandteil von einem Review-Skill, der automatisch vielleicht am Ende des Workflows so sogar vor dem Commit selber ausgeführt wird.
Also sehe ich, ne?
Trotzdem, wir haben letzte Woche ja mit Uli von Mapbox gesprochen und da ist auch dieses Thema Ownership without authorship wieder hochgekommen.
Und da bei denen ist es ganz klar, Claude schreibt den Code, aber du bist dafür verantwortlich.
Und es ist jetzt quasi an jedem Entwickler selber derzeit noch.
Die haben da auch, sagen wir mal, so 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, sehr viele Guardrails.
Before Dinge in Production kommen, müssen sie ja komplexe Buildpipelines und Testpipelines durchlaufen.
Nichtsdestotrotz muss da jeder Entwickler für sich selber entscheiden, halt, wie er oder sie das gewährleisten kann, die Qualität des Codes.
Und für dich heißt auch AI heißt nicht Responsible Engineering wegzuwerfen.
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 unresponsible nicht unresponsible.
Also ja, finde ich das unverantwortlich.
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 Engineers sich nicht geändert.
Bloß weil sie es probieren halt.
Genau.
Genau.
Und das ist halt, es geht bei jedem selbst zu entscheiden, was, wo, also, wie nimmt man die Verantwortung wahr?
Das ist genau dieser Freedom.
Sorry, André.
Ich würde sagen, es geht ja nicht ums Was, sondern nur ums V.
Und da führen wahrscheinlich viele Wege nach Rom.
Bin aber gespannt, wie sich quasi wirklich der, der, der, der, der, der Inner Loop, war, nee, eigentlich gar nicht der Inner Loop, eigentlich das gesamte, der gesamte Software Development Lifecycle.
Also quasi nach oben auch Richtung Produkt, aber dann halt auch Richtung Infrastruktur verändert.
Und ich habe heute gelernt, und das ist tatsächlich auf der These, muss ich 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.
Und das quasi das quasi rüttet schon auch an ein paar Modes, die es halt irgendwie, äh, die man eigentlich vorher nicht mehr gesehen hatte.
Ich sag mal, quasi häufig hast du eine Lambda-Function, versucht das mal irgendwo hinzumigrieren.
Das quasi, und das muss alles, muss alles vielleicht gar nicht mehr zukünftig sein.
Das ist eine sehr starke These.
Hier zuerst gehört.
Ich habe noch was zu dem Punkt vielleicht von Sebastian.
Eine meiner weiteren Thesen, ich habe so viele Thesen, aber eine weitere, vielleicht sollte ich irgendwie hier, weiß ich nicht, bin ich so bewandert, aber ich weiß nicht, wie viele Thesen Lutheran 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 habe das Konzept geklaut quasi und verändert ein bisschen von Ralf, der nennt es Semantic Anchors, macht das sehr viel auf LinkedIn und Webseite unter dem Stichwort Semantic Anchors, muss man sich auf jeden Fall angucken.
Die Idee ist, ich habe es ein bisschen vereinfacht, but I've been halt einfach 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 etwas, was ein bestimmtes Verhalten bei der AI triggered.
Zum Beispiel, meine Beispiele sind TDD is a trigger-word, Anti-Corruption Layer, Abstraction Layer, API or ABI, or it's a diverse trigger words that man as engineer had.
And these trigger words are so a bit like Rollenspielen of ADD Spells.
I can AI saga before you this feature boust, machine an abstraction layer.
Or before you do this to, or when you do this too, machine the TDD.
And so long and this has a lot of positive effect on the AI.
And vielleicht in Zukunft nicht mehr.
This is vielleicht irgendwann mal.
But actually, in the next five years, has the engineer a great forte given that with the AI bow, with them they then, good to the prototypenstadium comes, but I glau not in Production, not in scalierbarkeit, not in long fristige wartbarkeit.
Um Skalierbarkeit, long fristible wartbarkeit and other things to become a weighterbarkeit, also diese ganzen soften Requirements, braucht man diese Trigger-Words, braucht man diese Spells und dann kann man eben zu AI, während man die mit der AI arbeitet, stelle ich mir das immer so vor, dann kann ich den Abstraction Layer Spell sagen und dann macht die AI das Richtige.
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 Trigger-Words braucht, mit denen man das bei der AI das richtige Verhalten erzeugt.
Wir reden ja, wir reden ja jetzt ein Tag, nachdem Entropic mehr oder weniger quasi, weil keiner weiß, ob das halt quasi absichtlich oder unabsichtlich, aber egal, quasi die Frage.
Definitiv.
Unabsichtlich war das.
Die haben ja, die haben ja tatsächlich einzelne Leute auch angeschrieben und gesagt, du du den Code nicht weitergeben, auch wenn du ihn gesehen hast, 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.
Im Endeffekt Cloud Code geleakt.
Müsste man, kann man das nachvollziehen?
Also weil ich würde jetzt eher erwarten, also die These finde ich auch stark.
Ich würde aber erwarten, dass das nicht im LLM ist, sondern eigentlich eher im Environment halt irgendwie was triggert.
Wen meinst du?
Na, das müsste man doch eigentlich nachvollziehen können, was Stefan gerade gesagt hat.
Also gibt es da, wie hast du es genannt?
Semantic.
Trigger Words.
Semantic Anchors.
Rive-Fantasy Worlds.
Semantic Anchors.
Genau.
Semantic Anchors.
Müsste man doch klappt mal nachschauen in Cloud Code, ob das quasi dahingehend halt irgendeine Berücksichtigung gibt, oder?
Nee, ich glaube, das liegt halt im Modell.
Sicher.
Ja.
Also es sind auch, es geht auch sehr, sehr viel weiter als das.
Also bei Ralf, bei mir ist es ja, wie gesagt, bei Ralf geht es ja auch nochmal Triggerwords in anderen Bereichen.
Also wie schreibe ich gutes Deutsch, wie gibt es bestimmte Triggerwords, wie mache ich, also McKinsey hat einen ganzen Stapel Trigger-Words, wie sie arbeiten.
Es gibt von Gartner Trigger-Words, die ich kennen muss, um dann, wenn ich der Consultant bin, dann kenne ich die Gartner und McKinsey Trigger Words und dann erzeuge ich bestimmte Arten von Texten oder Folien in der AI.
Also ich kriege die EI dazu dann sozusagen wie McKinsey zu agieren, wenn ich die passenden Zaubersprüche da habe.
Vielleicht ein bisschen.
Achso, Sebastian.
Ja, ich wollte nur einen anderen Gedankengang noch, der jetzt gar nicht damit zu tun hatte.
Also fairerweise, um das Cloud Code-Ding nochmal abzuschließen, da ist natürlich, gibt es natürlich auch viel Spott und Theme.
Vibecoding, aller Code ist von der KI geschrieben.
Da gibt es auch ein Video von The Primogen, wo er 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, dass da hat jemand gesagt, hier, da funktioniert eine Source-Map nicht.
Und so ist dann die Source-Map von Cloud Code halt Open Sourced worden.
Was natürlich, ich sag mal, zum Thema, soll man sich das alles angucken oder nicht, aber fairerweise auch wenn er nicht auf.
Sebastian, ich kann noch nicht, mir fällt noch eine Klammer ein.
Und zwar jetzt vor kurzem hat er auch Cloud Code dieses kleine Tier in Claude Code.
Wie hießen die früher Tamagotchi gelauncht?
Wer auch immer, also ich habe den Tamagotchi, ich bin so alt.
Und da stellt sich natürlich jetzt auch die Frage, okay, Tamagotchi in Cloud Code, ist es jetzt der Zeitpunkt, wo ihm nichts mehr einfällt.
Also die haben ja super, super viel Released, also ich habe dann irgendwie jeden Tag 2,170, 2,171, jetzt sind wir, glaube ich, bei 2.1,89.
Wer in dem Podcast wird wahrscheinlich 2,1,90 sein.
Da stellt sich die Frage, wenn man jetzt Tamagotchis in Cloud Code reinbaut, die vielleicht einen Hintergrund haben oder wie auch immer.
Aber das ist eben die Klammer jetzt von Cloud Code.
Zu dem, was wir vorher diskutiert haben, wenn Erstellen von Features kein Limit mehr ist, welche Features baue ich denn alle in Human ein?
Also potenziell, wenn ich ein Tamagotchi einbaut, dann jumps ich.
Ja, exakt.
You jumped the shark, ja.
Neon Pro, genau.
Und den Gedanken, den ich aber eigentlich nochmal führen wollte, ist nochmal, also andere Perspektive auf Tools.
Weil was ich gerade wahrnehme, also ich auto mich jetzt mal, ich war nie in CLI-Fan, weil ich meine kognitiven, sagen wir mal, Kapazitäten immer gern für andere Themen genutzt habe, als mir irgendwelche Commands zu merken und so.
Ich habe das gerne, wenn ich mir das erschließen konnte und dann in einer UI irgendwie mich, also quasi einfach beim Sehen mich daran erinnern konnte.
Das ändert sich jetzt massiv, weil alle möglichen Applikationen, Tools, Plattformen auf einmal zugänglich, zugänglich werden, weil es halt jetzt eine CLI gibt, um damit zu interagieren.
Ich meine, das Gute ist, meine Cognitive Load erhöht sich dadurch jetzt nicht massiv, weil die KI macht es ja für mich.
Ich muss ja nur die KI-Trigger-Words wieder erkennen, damit es funktioniert und die Tools dann noch installieren.
Aber 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 auf der Quandozeile einfach sehr, sehr gut umgehen kann.
Das viel besser funktioniert natürlich, als irgendwie in einem Browser so, ne?
Was inzwischen aber fairerweise auch immer besser funktioniert.
Also Chrome Bridge oder wie das heißt, hier mein, wenn ich nicht weiterkomme mit an meiner App, dann sage ich hier, guck mal in meinem Browser.
Das geht nicht.
So, mach mal.
Und dann rödelst du zehn Minuten und dann geht es.
Gut, der an CLI bloß vielleicht da, was halt die AI kann mit einem CLI-Tool, ist, dass sie das mühelos mit einer mit Bash-Befehlen mit Pipes, mit For Loops und anderen Sachen integriert.
Also ich mache ein CLI-Tool, dann machst du einen For-Loop, dann macht es einen Sort, ein TR, dann macht sie ein JQ, um die JSON rauszufiltern und dann, also die AI ist sehr gut darin, ein CLI-Tool als Baustein in dem größeren Gesamtkunstwerk, sage ich mal, zu verwenden.
Ja, genau.
Ja, und das ist ja auch so ein bisschen der Startpunkt um Pi wiederum, ne?
Da sind wir wieder, also kann ja eigentlich per se nur vier Tools, glaube ich, irgendwie Verzeichnis scannen und Dateilen etc.
Und das ist das, was du in der Programmierung im Normalfall brauchst und machst einen Grab und dann findest du irgendwie, wo sich bestimmte Sachen wiederfinden, etc.
Und dann weicherst das an, um Zugriff auf Linia, Jira, was auch immer und dann kriegst du auch den Kontext angereichert.
Easy.
André, du wolltest mal.
Dann versuchen wir doch, dann versuchen wir doch mal so langsam eine Klammer drum zu kriegen.
Wir machen Special Edition, insofern, ich glaube, muss jetzt nicht sklavisch unendlich lang sein.
Aber Stefan, für dich quasi also zwei Fragen.
Wann baust du die Tamagotchis ein?
Erste Frage.
Zweite Frage, quasi, wie kann man dir, wie können wir dir helfen mit Human.
Also erstens, vielleicht brauche ich das halt, also ich brauche ja sowieso nichts mehr, man leider ganz klar.
Aber vielleicht mache ich es gleich morgen oder heute Abend im Hotelzimmer mal sehen.
Und 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.
Also 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 ein so aus.
Oder das sind das Feature fehlt, mir 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.
Sehr gerne.
Kann man contributen?
Ja, weiß ich nicht.
Im Prinzip ja.
Auch nochmal irgendwann nochmal 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 da jetzt eine Contribution aussehen?
Quasi, quasi, quasi lässt du da dein Agent halt einfach laufen oder also quasi, was ist der Mehrwert an der Stelle?
Weil es der Code selbst gar nicht mehr ist.
Es ist die Idee.
Es ist es die, was ist es?
Genau, aber auf jeden Fall danke, dass du die 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.
Ich bin dankbar vielen einzelnen.
Aufruf an unsere Zuhörer.
Probiert es aus.
Lass ein Like da.
GitHub Star, wenn es euch gefallen hat, genau und gib Feedback.
Genau.
Ich mache hier noch ein Easter Egg rein.
Quasi in der Hoffnung, im 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, um weiter sich weiterzuentwickeln.
Mal schauen, wie viel an dem Freitag dann vielleicht hier an GitHub Stars dazukommen, 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, äh, im Monat.
Insofern.
Letzter Freitag am Montag.
Ein bisschen Zeit.
Der letzte Freitag im Montag.
Genau.
Vielen Dank, Stefan.
Ich danke euch.
Vielen, vielen Dank.
Der HMZE Podcast ist ein gemeinsames Projekt von Sebastian Heidemeyer zu Erben und André Neubauer.
Infos zum Gast und Themen aus dem Podcast findest du in den Shownotes.
Diskutieren kannst du mit uns bei LinkedIn und für alles andere, zum Beispiel wen du gerne mal hier hören möchtest, kannst du gerne eine E-Mail an Podcast.hmze.tech schicken.
Vielen Dank für deine Zeit.
Wenn es dir gefallen hat, abonniere den Podcast.
Bis zum nächsten Folge.