Warum erscheinen eigentlich fast alle Coding Agents wie Cloud
Code Germany, CLI oder jetzt auch ganz neu die Cursor CLI als
Kommandozeilentools anstatt via Plugin in den Editor integriert
zu werden? Was sind die Vorteile von
Kommandozeilentools was sind die Nachteile und coden wir bald nur
noch über Agents im Terminal? Darum geht es in dieser Folge.
Und damit herzlich Willkommen zu Folge 127 des To do Developer
Podcasts mit Robin Manuel Thiel und mir malte Lantin Robin
Manuel arbeitet als Cloud Architekt und AI Berater bei
Microsoft. Ich bin Solutions Engineer bei
github, den Podcast machen wir privat und geben hier natürlich
unsere ganz persönliche Meinung wieder.
Heute sprechen wir natürlich mal wieder über KI, aber das Ganze
so ein bisschen auf der meta. Dieser Ebene, wir reden nämlich
über das Tooling. Wir haben uns nämlich beide
gefragt, woran liegt es eigentlich, dass mittlerweile
wieder mehr auf der Kommandozeile gearbeitet wird,
wenn es um die Softwareentwicklung geht, und
das sind nicht nur die cool Kids, die dann irgendwie wieder
Vi als primäre Idee ausgepackt haben, sondern es liegt vor
allen Dingen daran, dass wir immer mehr KI Werkzeuge auch auf
dem Terminal haben. Aber bevor wir hier in das Thema
einsteigen, haben wir hier noch ein Thema, was wir kurz
ankündigen wollten. Und zwar sind die Organisatoren
der Community Konferenz Iterate Ruhe auf uns zugekommen und weil
wir natürlich große Fans von Community Konferenzen sind,
haben wir gedacht, wir erwähnen diese Konferenz einfach mal im
Podcast und empfehlen euch dorthin zu gehen.
Und zwar findet die Konferenz am 26 und 27.
September in Essen statt. Daher auch der Bezug, ich wohne
in Essen, ich hatte es vielleicht schon erwähnt und von
daher auch ein bisschen Lokalpatriotismus dabei und ich
freue mich natürlich, wenn die developer Community zu uns nach
Essen kommt und dementsprechend können wir das Ganze empfehlen.
Viele namhafte Speaker aus der Community dabei wie gesagt, also
keine kommerzielle Konferenz, die da.
Organisiert wird, um Geld zu verdienen, sondern allein von
der Community, um Wissen zu vermitteln.
Und da sind wir natürlich große Fans.
Dementsprechend gibt es einen Link bei uns in den Shownotes
und über diesen Link gibt es auch einen 10% Discount auf die
Tickets. Das bedeutet, wenn ihr euch über
unseren Link anmeldet. Könnt ihr das Ganze auch ein
bisschen günstiger haben? Und ganz wichtig an dieser
Stelle auch noch mal. Also das ist eine Community
Konferenz, das ist ja auch keine bezahlte Werbung, wir haben kein
Geld hierfür bekommen, wir sind nur beide, haben wir unseren
Konferenz und Speaker und eventulist Background sowohl
Malta als auch ich und deswegen freuen wir uns immer, wenn wir
so Community getriebene Konferenzen unterstützen können.
Vielleicht sieht man es sich ja vor Ort.
Wunderbar. Und damit lass uns ins Thema
einsteigen. Ich hatte es gerade schon so ein
bisschen. Eingeleitet und diejenigen, die
uns regelmäßig zuhören, werden es auch in den letzten News
folgen. Gehört haben immer mehr KI Tools
kommen auf die Kommandozeile zuletzt.
Auch die Germany CLI und Cursor Cloud ist schon länger da und
wir haben uns gefragt, warum ist das eigentlich so, weil wir und
glaube ich auch viele andere Developer ja eigentlich mehr
Zeit in der Entwicklungsumgebung in der Idee verbringen.
Ja, kommt vor allem ja nicht auch auf die Kommandozeile,
sondern erstmal nur auf die Kommandozeile, also Cloud Code
und jetzt vor allem auch Germany CLI.
Die kriege ich jetzt erstmal ja nur in meiner Kommandozeile.
Cursor ist jetzt diesen diesen Schritt gegangen, den ich immer
noch so ein bisschen seltsam finde, die ja zuerst ein IDE
gebaut haben und jetzt auf die Kommandozeile gehen, sich so ein
bisschen irgendwie diesem Trend anzupassen, und das ist ja
eigentlich erstmal komisch, weil ich würde sagen, die
Kommandozeile ist zwar schon fester Bestandteil von so einem
developer Alltag, aber ja nicht unbedingt der Ort, wo wir ganz
viel Code schreiben oder vor allem auch irgendwie dann Code
Changes, reviewen und so weiter. Und deswegen schauen wir uns
heute mal so ein bisschen an. Warum ist das eigentlich so und
was sind so ein bisschen die vor und Nachteile bzw warum machen
die Hersteller von diesen Ziel i Tools das und werden da heute
mal so ein bisschen diskutieren und sind natürlich auch am Ende
sehr auf eure Meinung gespannt, ob ihr da vielleicht noch
Ergänzungen oder ganz andere Ideen habt.
Und was wir im Rahmen der Vorbereitung auch gesehen haben,
dass natürlich dadurch, dass das immer weiter anwächst, es jetzt
natürlich auch spezialisierte Benchmarks und Seiten gibt, die
sich nur mit diesen. Terminal basierenden KI Agenten
beschäftigen, und zwar zum Beispiel Terminal Bench und die
Benchmarken diese Agenten gegeneinander.
Und die haben tatsächlich letztens in einem Artikel
gesagt, sie gehen davon aus, dass 95%, also fast alle lm
Interaktionen in der Zukunft über den Terminal läuft und ich
glaube gerade für Developer ist das heute noch.
Sehr weit weg also, zumindest so in meinem Umfeld arbeiten die
meisten halt mit einer ide Integration, egal ob es jetzt
irgendwie eine der KI native id es sind oder die klassischen ID
es von diversen Herstellern, egal ob es jetzt irgendwie jet
Brains ist oder Visual Studio, wo sie dann halt über eine
Extension die KI Tools verwenden und dementsprechend ein
grafisches User Interface nutzen und nicht den Terminal Terminal.
Ist natürlich irgendwie immer dabei, aber.
Aber nicht der Terminal als primäres Interface zu diesem
Large Language Model. Ja, dazu muss man natürlich auch
sagen, dass die Welt da nicht so ganz schwarz weiß ist.
Also irgendwie so Cloud Code und Germany CLI sind zum Beispiel
auch in manche id s, also zum Beispiel im Visual Studio Code
über eine Extension integriert und können dann da zum Beispiel
sehen, welche Dateien gerade offen sind und welche
Codestellen markiert sind. Das ist ja wahrscheinlich so
einer der Sachen, die ich ja normalerweise, wenn ich im
Terminal arbeite, nicht unbedingt machen kann.
Aber da kommen wir dann auch schon so ein bisschen zu diesem
ersten Punkt, also wahrscheinlich einer der Gründe,
warum ganz, ganz viele gerade ihre Tools erstmal als CLI Tools
und auf der Kommandozeile anbieten.
Das ist wahrscheinlich so ein bisschen so diese
Editorunabhängigkeit, also klar, Visual Studio Code ist ein
wahrscheinlich der weit verbreitetste Editor, wenn ich
mir so die letzte Stack Overflow Server angucke, dann stimmt das
auch noch, aber. Die ja die Kommandozeile ist
jetzt erstmal so die einzige garantierte Umgebung für jeden
Entwickler und jede Entwicklerin.
Nicht jeder verwendet vs Code oder Intelli J, aber jeder hat
irgendwo ein Terminal und die meisten von diesen id s können
natürlich auch irgendwo in der ID dann ein Terminal aufmachen
und wenn ich dann eben mein mein cooles Agent Tool dann darin
anbiete, dann habe. Habe ich halt keinen mehr Login
in irgendein in irgendein schon bestehendes Tool oder muss so
wie Cursor und Windsurf das gemacht haben, vielleicht ein
bestehendes Open Source Tool klonen, die haben ja Virtual
Studio Code genommen und das quasi geklont und dann da ihre
eigene Integration eingebaut und so habe ich natürlich so ein
bisschen so eine Unabhängigkeit vom Editor.
Es ist natürlich gerade erstmal vorrangig, ist ein Vorteil für
die Hersteller, von diesen Tools können also quasi viel viel
schneller wie. An alle Umgebungen neue Features
chippen und ich glaube gerade um dieses schneller, also um
Geschwindigkeit geht es gerade ganz massiv in diesem KI Markt.
Also ich würde sagen Ah, also ein bisschen Faulheit ist ein
ist ein hartes Wort, aber natürlich auch irgendwie so eine
Editorunabhängigkeit für die Hersteller beim Bauen, aber
natürlich auch für uns. Es gibt ja auch ganz viele Leute
die sagen keine Ahnung ich bin Full Stack Developer, ich muss
in Android Studio eine Android App bauen und dann in Visual
Studio ein net Backend dafür oder so.
Wenn ich dann eben so ein bisschen hin und her springe,
habe ich, habe ich halt diese Unabhängigkeit von der ide.
Ja, ich glaube, das ist ganz wichtig, auch aus der User
Sicht, dass du tatsächlich das gleiche Tool, den gleichen KI
Agenten hast, egal wo du gerade arbeitest.
Das heißt, du musst nicht darauf warten, dass dein
Lieblingshersteller dann jetzt auch noch vielleicht eine
weitere Idee unterstützt, die du vielleicht ganz cool findest.
In deinem Alltag verwendest, sondern du hast halt parallel
irgendwie den Terminal und die. Ide offen, aber ich fand es ganz
interessant, dass du als erstes Argument tatsächlich diese
Editor Unabhängigkeit genannt hattest.
Ich hätte jetzt gedacht, das erste Argument ist, dass es
einfach cooler aussieht, den Terminal auch zu haben als
irgendwie eine GUI und man dementsprechend mehr Credibility
als Developer noch behält, auch wenn jemand anders den Code
schreibt, aber das ist wohl nicht der primäre Vorteil.
Ja, die Wahrheit ist natürlich auch so.
Ein CLI Tool ist einfacher zu bauen, es ist trotzdem noch
komplex, aber man kann es natürlich auch einfach als.
Cool vermarkten und auch so ein bisschen so diese coole
Developer. Die nutzen dann halt irgendwie
die Kommandozeile und die ist ja eh schon seit ein paar Jahren so
ein bisschen auch so ein bisschen aus so einem Hype Train
wieder mehr Kommandozeile zu benutzen.
Es gibt Leute, die schwören darauf einfach git Befehle
einfach nur im Terminal runter zu hämmern anstatt irgendwie ein
grafisches Tool dafür zu verwenden.
Es gibt auch also die Kommandozeile hat sich auch
weiterentwickelt. Es gibt auch mittlerweile
wirklich coole Tools, die mir das arbeiten da noch mal
deutlich leichter machen. Ich muss lange nicht mehr
irgendwie den kompletten Dateipfad da per Hand eintippen,
Auto complete und sowas gibt es da mittlerweile auch, also klar,
ich glaube es ist so ein bisschen diesen Coolness Faktor,
ich glaube es ist aber auch so ein bisschen so eine Abgrenzung
von dem, was schon da ist. Wenn jetzt irgendwie, ich
glaube, das hat ja alles so ein bisschen angefangen mit Guitar
Co Pilot in Visual Studio Code und jetzt ist.
Gitap Co Pilot auch in so ein paar anderen id s.
Das ist so ein bisschen dieser konträre Ansatz dazu.
Aber alles was ich jetzt neu baue, also wenn ich jetzt in
Google bin, wenn ich jetzt ein dann droppic bin und ich bringe
so einen eigenen Coding Agent raus, dann wenn ich den genauso
bauen würde wie gitap Co Pilot, dann müsste ich den halt auch
immer direkt an Gitap Co Pilot messen oder ich habe natürlich
die Sorge, dass ich vielleicht nie genauso gut in Visual Studio
Code, was ja auch so ein bisschen von Microsoft
kontrolliert wird, das. Mich rein integrieren kann ice
git up co. Peile, wenn ich einfach da sage,
ich mache mich da komplett von unabhängig und gehe einfach auf
die Kommandozeile, da habe ich da erstmal eine komplett neue
Landschaft, die so noch gar nicht so mit Ai Coding Agenten
verseucht ist, sondern kann mich da irgendwie noch mal neu
ausprobieren und vielleicht auch neue Sachen machen und binde
mich natürlich komplett unabhängig von diesem Editor und
habe natürlich das, was du auch gerade gesagt hast.
Dass ich vielleicht meinen Agenten irgendwie einmal
konfiguriere und den dann einfach überall hin mitbringe.
Also anstatt alle ID is, die man verwendet, einzeln zu
konfigurieren, da gibt es durch das eine Feature da nicht das
andere gibt es, da gibt es da dann doch, kann ich halt meinen
Agenten auf der Cii ein einziges Mal konfigurieren und auch
personalisieren und den dann überall hin mitnehmen.
Ja, weil ansonsten brauche ich wirklich ein Tool, was in allen
meinen id ES präsent ist und auch die gleichen
Konfigurationsdateien dann verwendet und.
Und hier ist es per Definition so, weil ich letzten Endes auf
der Kommandozeile bin und die Idee macht vielleicht einfach
nur das Projekt dann auch zusätzlich auf als User
Interface für den Menschen und die KI, die braucht gar kein
User Interface, sondern kann direkt auf den Dateien arbeiten
und das machen wir uns ja auch in vielen anderen.
Zusammenhängen zu nutze, gerade wenn wir automatisieren,
arbeiten wir eigentlich immer mit CLI Tools.
Das heißt, wir schreiben Skripte, egal ob es jetzt
irgendwie cicd Pipelines sind oder halt auch andere Dinge, die
wir im Rahmen von Git automatisieren.
Und hier können wir natürlich über CLI Tools auch unsere KI
Agenten in diese Workflows reinhängen und als Teil dieser
Automatisierung. Ich dann betrachten, das ist
jetzt noch nicht Mainstream. Aber ich glaube, in die Richtung
wird es gehen, dass man dann in seinen Skripten, die man ohnehin
schon hat, dann Ai Schritte einbaut und kann dann zum
Beispiel über vielleicht seine Cii Kommandos, die man in seinem
CI Workflow hat, dann irgendwo noch einen Step Reinbauen, der
für mich vielleicht noch mal ein Code Review macht, ein Finales
und dann von der aus der KI Perspektive noch mal das Okay
gibt, damit meine CI co. Komplett durchlaufen kann.
Das ist ein super starkes Argument, dass ich das eben
irgendwie meine Automationen mit einbauen kann.
Da haben wir ja vor ein paar Folgen auch schon mal über
Automatisierungen gesprochen und jetzt einfach, wenn ich sowas
einfach im Rahmen von einem Git hook zum Beispiel irgendwie ein
KI Review einbetten kann oder wo auch immer in meiner cicd
Pipeline kann ich natürlich diesen Agenten aufrufen jetzt,
und das kann ich natürlich nicht, wenn der irgendwo in der
ID e eingebaut ist. Dann ist ja vielleicht im
Zweifel auf dem Bildrechner diese idi gar nicht installiert,
oder? Ich kann vielleicht so ohnehin
nicht von außen drauf zugreifen. Also ich glaube so diese die
Möglichkeit mehr mit dem Kommandozeilentool, das schnell
in meine Workflows einzubauen, das ist schon ziemlich stark,
man muss dazu aber sagen, so ein bisschen als Gegenargument würde
ich dann schon auch kritisch nachfragen sagen, ist das so,
weil die meisten dieser dieser Coding Agenten, die ja auf der
Kommandozeile laufen sind nicht wie klassische
Kommandozeilentools. Ein Kommando geben mir dann eine
Ausgabe und sind dann fertig und sagen mir vielleicht sogar, ob
es geklappt hat oder nicht. Über den Error Code, sondern die
sind ja alle irgendwie interaktiv, das heißt, ich habe
gesagt, die bauen ja eigentlich alle sowas, wieso eine jet gbt
Oberfläche nach im Terminal und ich weiß nicht ob man die
vielleicht auch irgendwie über einen Flag beim Starten noch so
konfigurieren kann, dass sie sagen, bitte gib mir wirklich
nur eine Antwort und dann beende hier diesen diesen Task und
diesen Thread auch wieder, aber sonst warten die ja teilweise
auf mein Feedback und ich. Also so ganz so einfach die
einzubinden finde ich jetzt glaube ich nicht.
Aber die Möglichkeit habe ich natürlich generell schon, wenn
ich ein Kommandozeilentool habe. Ja, und ich glaube, es ist ganz
wichtig, auch zu sehen, dass gerade diese CLI Tools aktuell
noch für das autonome Softwareentwickeln durch
Agenten, also das Vibe Coding, wie wir es in den vergangenen
Folgen besprochen haben, gedacht sind.
Das heißt, ich gebe einen Auftrag, der Agent übernimmt
diesen Auftrag, erledigt den Auftrag und gibt mir ein
Ergebnis zum. Zurück, das heißt, es ist nicht
dieses klassische. Ich arbeite mit KI Hand in Hand,
also das ist per Programming, wo ich eine Code compleation habe
oder wo ich einfach Fragen stellen kann oder bestimmte
Codestellen Review, also dafür ist es zumindest heute bei den
Tools die am Markt sind eigentlich nicht gedacht und
steht damit natürlich mehr im Wettbewerb, auch zu diesen
entsprechenden Modi in. Geht ab Co Pilot mit dem Agent
Mode oder auch in Cursor, wenn wir da mit dem Agenten arbeiten.
Ja genau, die haben ja gar nicht den Anspruch, sich so tief in
eine IDE zu integrieren. Es geht da nämlich genau nicht
um Code Auto vervollständigung, während ich tippe oder sowas,
sondern die Idee ist ja eigentlich wirklich, dass ich
einem Cloud Code oder einem Germany ci eine Aufgabe gebe und
dann mehr oder weniger im Hintergrund dieser Agent
versucht an dieser Aufgabe zu arbeiten und mich ja versucht so
wenig wie möglich zu stören und. Wohingegen ich habe bei so einer
Editor Integration ja eigentlich bei so an so vielen Schritten
wie irgendwie sinnvoll ist, immer mal wieder diese Ai Hilfe
oder irgendwas haben möchte. Und ich glaube auch so diese
beiden Sachen. Ich mache das Terminal auf, ich
gebe dir eine Aufgabe der Rödel da jetzt wahrscheinlich mehrere
Minuten dran, ich kann in der Zeit irgendwas anderes machen,
vielleicht auch irgendwie in meiner ide sollte ich auch ein
bisschen gucken, dass da keine, dass da keine Konflikte kommen.
Es gibt ja auch noch mal so ein bisschen wie du gerade richtig
sagst, dieses Mindset, das einfach eine andere Art und
Weise ist, sondern ich gebe da wirklich eine Aufgabe rein und
das Ding soll dann so lange irgendwie an der Aufgabe rödeln,
bis es fertig ist. Wir hatten ja auch ein bisschen
recherchiert, was andere so als pro und contra Argumente sehen.
Und da sind auch so ein paar Sachen dabei, die zumindest ich
nicht so ganz nachvollziehen konnte, wie zum Beispiel, wenn
ich eine Cii habe, dann kann ich auch mehrere Turnals parallel
aufmachen und dann mehrere Aufgaben vergeben.
Wie gut das dann funktioniert und in wie viele Konflikte ich
dann laufe, wenn ich mehrere Agenten auf der gleichen
Codebase arbeiten lasse, ist es glaube ich, dahingestellt.
Und das zweite, was ich nicht so ganz nachvollziehen konnte, war
das Argument ja, auf der Kommandozeile ist man natürlich
auch unabhängig, ich bin nicht abhängig von einem bestimmten
Vendor, einer bestimmten Idee, aber letzten Endes sind ja die
meisten dieser Tools auch durch einen dieser Modelventoren
entwickelt worden, um mich. An deren Modell zu binden.
Es gibt Open Source Tools, bei denen ich beliebige Modelle
nutzen kann, aber wenn ich jetzt speziell zum Beispiel über Cloud
Code und Germany spreche, dann habe ich natürlich die Modelle
von dem Hersteller und da bin ich ja dann tatsächlich eher
Login im Vergleich zu einem Co Pilot oder einem Cursor oder
einem Win Surf, wo ich aus einer großen Palette von Modellen
wählen kann und nicht mich darauf verlassen muss, dass auch
wirklich dieser Modellhersteller auch in Zukunft.
Ganz weit vorne sein wird. Ja, guter Punkt.
Wieso einen einen Tod muss ich ja irgendwie sterben und klar
bin ich halt unabhängig von der IDE, aber abhängig von vom Model
war spannend können wir gleich noch mal kurz drüber sprechen,
dass ja eigentlich jetzt neben diesen ganzen Open Source
Varianten auch Cursor so ein bisschen diesen Ansatz gibt mit
der Cursor CLI, die sind ja eigentlich eher dadurch groß
geworden, dass sie. Ja, einen eigenen Editor gebaut
haben oder mehr oder weniger einen VS Code Clone gebaut
haben, aber der Erfolg von Cursor kommt eigentlich daher,
dass die haben ja keine eigenen Modelle, sondern dass sie gesagt
haben, wir können eine sehr sehr gute User Experience bauen, das
heißt, warum Cursor überhaupt erst mal so erfolgreich ist ist,
weil sie ja die Idee von einem github Co Pilot genommen haben
und eine bessere UX eigentlich drumherum gebaut haben, dass
noch besser oder noch tiefer in die IDE zumindest anfangs
irgendwie integriert haben und. Und dass die jetzt auch sagen,
wir gehen auf die Kommandozeile, zeigt ja eigentlich nur, dass
entweder dieser Trend der Konsistenz, also die gleiche
Experience, die gleiche Qualität in alle Editoren zu bringen,
dass entweder das Halt so ein bisschen der Treiber dafür war,
weil bei denen sind es ja auf jeden Fall nicht die einzelnen
Modelle. Den Login habe ich aber
natürlich genau wie du gerade richtig sagst, bei den anderen
Tools schon und ich muss auch sagen, selbst wenn ich die
gleiche. Den gleichen Coding Agenten wie
jetzt irgendwie zum Beispiel Github Copilot in verschiedenen
id s hab da muss man ja auch irgendwie so fair sein zu sagen
ja, aber der ist ja ganz klar auch im Visual Studio Code am
tiefsten ausgeprägt, also der ist ja, der hat ja zum Beispiel
in Ex Code nicht mal einen Bruchteil der Features die er
irgendwie in eine Visual Studio Familie hat.
Ich glaube Intelli j ist halbwegs gleich auf, aber nur
weil es nur weil es github Copilot in ganz vielen Editoren
gibt, heißt es ja nicht, dass die Experience da gleich ist.
Und das hätte ich aber so einem Terminal Tool auf jeden Fall.
Da habe ich auf jeden Fall die gleiche Experience, die gleiche
Qualität in allen Editoren, weil ich gar nicht im Editor bin,
sondern weil ich ja in der Shell laufe.
Hat auch den Vorteil, dass ich natürlich mein Shell Environment
mitbringe, also dass die automatisch meine
Umgebungsvariablen geladen werden und irgendwelche config
Dateien und sowas, aber ich bin halt gar nicht im Editor drin
und muss mich dann halt auch gar nicht abhängig von den Sachen
machen, die ich irgendwie in diesen Einzel Editor integrieren
lassen kann und habe dann halt auch nicht die Frustration.
Dass irgendwas, wie es Code vielleicht mega gut mit Koop
funktioniert und dann aber in Intelli J das Feature noch nicht
da ist und so. Also da kann ich schon mal
verstehen, warum man auf die Kommandozeile gehen will, um in
andere Editoren reinzukommen und diesen Pain sich gar nicht gibt.
Dann irgendwie noch eine Extension zu bauen.
Wobei ja tatsächlich es nicht so ist, dass es dann die gleiche
Experience über alle. Id is dann ist für dich, wenn du
es im Terminal nutzt, weil es ja von den CLI Tool Herstellern
teilweise dann doch noch Extensions insbesondere für vs
Code gibt und ich dann natürlich wenn ich jetzt einen Cloud Code
einsetze, vielleicht noch besser in Kombination mit vs Code
arbeiten kann als vielleicht mit Ex Code, weil es für Ex Code
dann keine direkte Integration gibt, aber.
Also ich glaube, da muss man halt wirklich schauen, wo sind
da für einen selber auch die vor und Nachteile arbeite ich in
verschiedenen id ES was ist auch das Tool was für mich
entsprechend sich Kostentechnisch am besten
anbietet, wir kommen gleich noch mal ein bisschen zu den
Nachteilen, vielleicht auch von diesen ci tools, aber ich glaube
da muss man tatsächlich für sein eigenes Setup auch mal gucken
was funktioniert da auch am besten.
Ja, das war ganz spannend zu sehen, dass dann irgendwie diese
ganzen Terminal First Tools, ich glaube so Cloud Code war so der
Erste, dass die dann ja schon irgendwie gemerkt haben, ich
glaube so ganz so cool ist das dann doch nicht und so ein paar
Sachen gehen uns dann schon verloren und dann ja wieder
Extensions für wir es Code gebaut haben um zum Beispiel
einfach so Sachen machen zu können wie ich kann, dann im
Terminal das Terminal sieht dann oder der Agent der im Terminal
arbeitet sieht dann welche Datei ich gerade offen habe oder
welche Codestelle ich gerade markiert habe.
Sowas geht natürlich nur wenn ich eine Brücke wieder.
Zur idi schlage also so diverse Vorteile hat das wahrscheinlich
schon, wenn ich entweder eine grafische Oberfläche habe, gut
die wird so ein bisschen versuchen, der Seal I
nachzubauen, aber vor allem auch eine richtige Integration in die
idi habe und dann finde ich diesen Weg spannend zu gehen,
dass ganz viele von diesen Herstellern erst so ein Seal I
Tool rausbringen, wie gesagt, vielleicht weil es auch
einfacher zu bauen ist und sich dann aber doch wieder irgendwo
hinten raus in die ID IS integrieren, weil.
Weil es gibt ja einfach auch ein paar Features, die kann ich auf
der Kommandozeile gar nicht abbilden.
Es gibt den VS Code und in Cursor auch dieses so ein
halbversion Tracking, also eine KI, macht ihnen einen Vorschlag
von einer Codeänderung. Ich sehe diesen Vorschlag dann
schon auch wirklich wie in so einer div.
Ansicht in der Entwicklungsumgebung, sie ist
aber noch nicht wirklich auf die Festplatte geschrieben.
Das heißt, ich habe so einen, so einen Zwischenzustand natürlich
so lange mit der KI an was arbeiten kann, bis ich sage, Jo,
das passt jetzt, dann akzeptiere ich diese Änderungen und dann
sind sie wirklich irgendwie festgeschrieben.
Ich kann aber trotzdem schon vorher diese Änderungen mal
kompilieren und mal ausführen, weil sie dann für diesen einen
Moment dann doch irgendwie wieder akzeptiert werden, also
diesen Zwischenzustand, den kann ich natürlich nur herstellen,
wenn ich auch eine Editor drumherum baue, der das
unterstützt. In der Kommandozeile gibt es
sowas nicht, also dieses. So ein bisschen so so User
Experience Feature bleiben da ja auf jeden Fall auf der Strecke
und das ist dann doch irgendwie spannend zu sehen, dass dieser
Weg halt wieder zurückgeht. Ja, ich glaube insbesondere.
Und ich hatte ja vorhin auch schon gesagt, so, die Idee ist
ja für den Menschen gebaut und insbesondere wenn ich dann auch
als Mensch. Heute immer noch ganz viel
selber Software entwickle und auch in meinem Projekt
navigieren muss. Und wie gesagt, vielleicht die
Codevorschläge Reviewen möchte schauen möchte sind das die
Dinge die ich wirklich auch erreichen möchte, dann ist
natürlich eine Idee ganz klar überlegen.
Ich kann auf der Kommandozeile da irgendwie versuchen drumherum
zu bauen und es gibt so Dinge wie Otto Git das dann
automatisch nach. Einer ki agentenänderung ein Git
commit gemacht wird und ich kann dann ein div.
Tool verwenden um zu schauen zwischen den Commits.
Was hat sich da verändert um auch zu sagen Okay die Änderung
möchte ich nicht, dann gehe ich halt noch mal einen Schritt
zurück aber das Ganze ist natürlich bei weitem nicht so
komfortabel wie ich es im grafischen Code Editor habe und
ich glaube da ist ein ganz wichtiger Punkt, dass sich halt
diese CI Tools tatsächlich an dieses agentengestützte
Softwareentwicklung. Thema richten und in der IDE
natürlich ganz stark der Mensch im Vordergrund steht.
Und ich glaube, wir können auch nicht immer sagen okay, wir
arbeiten jetzt nur noch mit Agenten, weil das ist so The
Latest and Greatest, sondern wir verwenden halt immer noch eine
Code compleition. Wir haben immer noch
irgendwelche Fragen wo wir etwas recherchieren müssen, wo es
einfacher ist ein einfaches Chat Interface zu haben und da sind
natürlich die Tools, die irgendwie verschiedene Modi mir
bieten und vor allen Dingen halt auch.
Weiterhin die seit Jahrzehnten aufgebaute Unterstützung,
Unterstützung für menschliche Developer weiterhin bieten klar
im Vorteil. Diese ganze User Experiency, die
kommen natürlich nicht ran. Also gerade schon gesagt, aktive
Cursorposition, offene Dateien. Aber auch so was ist mein
aktueller git Status. Den sehe ich dann halt einfach
in der ID. Klar kann ich den kann mit der
Agent den auch über einen Command abfeuern und
unterfragen, aber ich sehe ihn halt irgendwie deutlich in der
ID. Ich kann über Drag and Drop
arbeiten, ich habe irgendwie eine Datei auf, ich ziehe die
einfach zack in meinen Agenten rein, weil ich weiß, dass die
vielleicht irgendwo relevant ist.
Ich kann mit irgendwelchen Shortcuts mit Tasten arbeiten,
ich habe vielleicht eine Integration in meinen Linter, in
meinen Debugger, der kann irgendwie Informationen da
reingeben, ich habe. Diese ganzen Integrationen, die
ja schon gebaut sind, die für einen Menschen da sind, wie du
gerade gesagt hast, die bringe ich halt mit rein.
Und natürlich kann das Terminal mit so einer UX nicht mithalten
oder zumindest nicht ohne noch so eine Menge zusätzlichen Glue
hier und da zu verwenden und sich dann noch irgendwelche
andere Tools zu bauen. Und es gibt ja auch tatsächlich
in zum Beispiel Terminal Visis, da kannst du dir eine
Codeänderung im Terminal anzeigen lassen, da kriegst du
so ein klassisches Git mäßiges Diff.
Aber du kannst auch sagen, öffne mir jetzt dieses Diff mal in vs
Code und. Und zeige mir das mal irgendwie
so an, wie ich es gewohnt bin. Ist wahrscheinlich so ein
bisschen Geschmackssache, aber ich habe persönlich meinen
Agenten im Moment noch lieber im Editor, auch weil ich selber
glaube, dass wir noch gar nicht so weit sind, dass wir Aufgaben
wirklich komplett autonom an so einen Agenten abgeben und habe
dann so ein bisschen auch das Gefühl, ich habe, ich habe ein
bisschen weniger Kontext switching, wenn ich dann wieder
vom Editor raus Switche in mein Terminal gehe.
Klar, du kannst das Terminal auch irgendwie in die IDE
einbinden. Aber das ist ja einfach nicht
der bessere Ort, um eine Unterhaltung zu führen, anstatt
wenn ich irgendwelche Chat bubbles vielleicht irgendwo
habe. Und das ist aber ich merke, ich
merke das auch wenn ich mich mit anderen Developern unterhalte,
eine recht persönliche Sache von mir.
Es gibt Leute, die schwören auf die Kommandozeile, aber für mich
ist das so, ich bin gerne irgendwie in einem Kontext, ich
arbeite auch gerne in so einem Zen Modus wo ich nicht 15
verschiedene Fenster offen habe und da hilft es mir so ein
bisschen wenn das in die ide. Integriert ist.
Ja, und tatsächlich sind ja in der Realität, gerade wenn wir in
die Industrie reingehen, auch einige Anwendungen einfach so
groß, dass so ein KI Tool, was auf der Kommandozeile läuft,
vielleicht gar nicht ohne weiteres genau so eine
Änderungsgruppen kann. Wo muss ich eigentlich
reingucken, in welchen Dateien muss ich jetzt arbeiten?
Das mag bei kleineren Projekten schon sehr gut funktionieren,
aber tatsächlich, wenn man sich anschaut mit wieviel Millionen
wirklich Zahlencode manche der größten Projekte die.
Ausgestattet wird an denen teilweise wirklich hunderte
Developer parallel arbeiten. Dann stellt sich natürlich die
Frage, kommt man da ohnehin nicht an einer Idee vorbei, weil
man auch selber als Mensch. Scopen muss, man muss
entscheiden okay folgende Änderungen beziehen sich auf
folgendes Subprojekt auf folgende Dateien und da kann ich
natürlich viel einfacher in einer Idee, in der ich mich
ohnehin den ganzen Tag bewege, dann auch meinem KI Agenten,
meinem KI Tool der Wahl, dann entsprechend den Kontext geben.
Das heißt ich kann viel einfacher als Mensch helfen,
diesen Kontext zu bauen und muss mich nicht auf die Logik
verlassen, die dann irgendwie einen Tool Hersteller
implementiert hat, weil wenn ich so ein CI Tool habe.
Habe kann ich auch mal auf eine oder die eine oder andere Datei
direkt verweisen, aber ich bin natürlich extrem eingeschränkt
und muss mich ganz oft darauf verlassen, dass das Tool einfach
die richtigen Codestellen findet, auf die sich mein Wunsch
bezieht. Man kann natürlich nur, du
kannst auch so diesen Tools ja verschiedene Ordner erwähnen
oder so. Dieses ganze Kontext Engineering
so ein bisschen selber machen, meistens irgendwie so Hashtag
oder ADD irgendwie schreibst, dann wird auch direkt so ein
Filepicker irgendwie reingebracht, aber natürlich.
Ist das was anderes, als irgendwie mal eben so ein
Ordner, so ein Ordner per Drag and Drop oder den Scope
irgendwie durch durch ein bisschen klicken zu definieren?
Ja, ich glaube am Ende läuft es gar nicht so unbedingt auf
Features, sondern wirklich auf die User Experience raus.
Wir haben tatsächlich User Experience ist dann glaube ich
ein ganz wichtiger Punkt, weil der User ist ja letzten Endes
ein Mensch, ist ein Developer wie du und ich und wir wollen
vielleicht auch mit einem Werkzeug arbeiten, was speziell
für Menschen gebaut wurde und nicht für Automatisierung oder
für die. Oder KI.
Und am Ende läuft es glaube ich, dann darauf hinaus, dass man
beides gemeinsam nutzt, also Dinge, die auf dem Terminal
laufen, mit Dingen, die in die Idee integriert sind, am besten
in die Idee, die ich ohnehin schon seit vielen Jahren
verwende, weil Menschen sind natürlich auch gewohnheitstiere,
und wir wollen halt am liebsten in dem Tool arbeiten, in dem wir
uns gut auskennen, das merkt man auch schon allein, wenn man
sagt, Okay. Folgendes KI Tool gibt es jetzt
nur in Editor A. Du kannst ja halt einfach Editor
B nehmen, da gibt es glaube ich durchaus große Widerstände dort
auch so einen Wechsel zu machen und im Idealfall hat man dann
natürlich so eine Editor unabhängige CI die ich dann
kombinieren kann mit der Idee der Wahl über ein entsprechendes
Plugin, ja. Das ist ein guter Punkt, gerade
in so Enterprise Umgebung kann ich ja nicht einfach morgen
einen neuen Editor installieren und aus meinem ganzen Team
ausrollen. Habe vielleicht auch meine
ganzen Workflows schon auf diesen einen Editor oder diese
eine. Entwicklungsumgebung angepasst.
Deswegen glaube ich auch. Ich glaube, dass wir in Zukunft
viel mehr so hybride Ansätze sehen.
Also ich habe eh das Gefühl, die Industrie tendiert so zu diesen
hybriden Modellen, also irgendwelche Unternehmen führen
ihre fügen ihre ide Integration zu, also zur CI hinzu oder zu
der Kern von diesem Agent, der läuft dann eben in der CI zum
Beispiel haben wir eben schon besprochen, diese vs Code
Integration von Germany oder die Editor Plugins von Cloud Code
und so ein bisschen und die werden.
Machen dann hoffentlich so das Beste aus beiden Welten und ich
muss mir auch fragen, so wenn ich jetzt irgendwie cursor bin,
die waren ja sehr erfolgreich damit, dass sie dann irgendwie
diese IDE gebaut haben, aber vor allem haben die auch, obwohl sie
die gleichen Modelle wie viele andere nutzen, für viele
Entwicklerinnen und Entwickler zumindest gefühlt auch die
besseren Ergebnisse geliefert und das liegt natürlich so ein
bisschen daran, dass die vielleicht einen anderen System
prompt geschrieben haben, dass die vielleicht das Context
Engineering ein bisschen geschickter machen als andere,
wenn die jetzt auch auf die Kommandozeile gehen, dann.
Heißt es ja, dass die vielleicht auch erkannt haben, es ist ja
nicht das Kerngeschäft von Cursor, eine Idi zu bauen, und
das ist ja auch nicht das, was ich machen will, ich will ja
nicht 15 verschiedene Editoren bauen, das kann ja auch nicht
die Lösung sein irgendwie, dass jetzt jeder mit seiner komplett
eigenen Idi oder sogar mit seinem eigenen Klon von Visual
Studio Code irgendwie daherkommt, sondern ich will ja
am Ende auch irgendwo mein Tool darein integrieren, wo meine
User sind und. Und keiner will der Cursor, weil
die Idi so geil ist. Das ist ja einfach nur ein
abgespecktes vs Code. Die haben zwar eine sehr, sehr
gute UX gebaut und das noch irgendwie diese Codevorschläge
ein bisschen besser integriert, aber Cursor ist ja so beliebt,
weil der Agent so gut ist. Und sollte sich die Cursor CLI
durchsetzen, kann sich Cursor in Zukunft sparen, die idi zu
pflegen, das ist ja vielleicht auch eine Idee, weil sonst
hängen die ja immer 123 Releases hinter vs Code her und sowas und
das. Vielleicht gewinnt Cursor
dadurch auch, weil sie, auch weil sie jetzt natürlich keine
eigenen Modelle haben, der Erfolg von Cursor keine.
Sie haben ja eigentlich daher, dass die Integration so viel
besser und smoothser war und nicht, weil sie irgendwie coole
Modelle oder sowas haben wie Germany oder Clunt also ich
glaube, dass es ein ganz geschickter Ansatz ist und dass
wir, das glaube ich, auch noch mehr sehen werden, aber ich
glaube, dass wir am Ende so Hybrid werden und sagen, der
Kern von meinem Agenten, der ist dann vielleicht super portabel.
Betriebssystem unabhängig läuft überall läuft in der
Automatisierung, läuft aber auch auf deinem Rechner, läuft aber
auch in irgendwelchen remote Umgebungen, weil der eben Cii
basiert ist. Integrieren werden die sich aber
trotzdem wahrscheinlich immer mehr in die ID IS die schon da
sind um eben genau diese Brücke von dieser noch fehlenden User
Experience in die Zukunft mal zu schlagen.
Also ich kann mir sehr gut vorstellen, dass wir das mehr
sehen werden und dass wir das auch vielleicht von von
bestehenden Agenten sehen werden, die sich dann in noch
mehr Tools integrieren. Oder noch verfügbarer werden,
indem sie dann irgendwie auf der Idi erscheinen, auf der CLI
erscheinen. Ich denke mal zusammenfassend
können wir sagen, dass natürlich diese CLI Tools viele stärken
haben. Du hast sie gerade am Ende noch
mal genannt, sie sind plattformunabhängig, sie sind
idi unabhängig und haben dementsprechend viele stärken.
Wir hatten über Automatisierung gesprochen, wir hatten über
Einfachheit und Startup Zeiten gesprochen, also ganz viele
Vorteile, aber am Ende gehen die id es nicht weg, die id, es
werden immer noch gebraucht für uns als Mensch.
Menschliche Developer zur Integration von anderen KI Tools
in unseren developer Workflow, das heißt nach hinten raus,
werden wir wahrscheinlich eine Kombination von beiden
verwenden, wie du es gerade gesagt hattest.
Und ich denke mal, das ist auch für uns am Ende als Menschen die
bequemste Option, weil es ist einfach zugänglich.
Aber trotzdem habe ich diese mächtigen Tools, die ich auch
automatisieren kann und man muss halt schauen, mit welchen
Einschränkungen lebe ich heute, wo wir vielleicht noch nicht in.
Dieser Welt angekommen sind, wo alle Hersteller beides anbieten,
weil wir haben es ja ganz am Anfang gesagt, die einen
Hersteller kommen von der Kommandozeile und bewegen sich
Richtung ide und die anderen kommen aus der IDE und bewegen
sich Richtung Kommandozeile und ich denke mal, wenn wir jetzt
glaube ich in einem Jahr noch mal über das Thema sprechen,
haben wir wieder eine ganz andere Landschaft, wo vielleicht
ein Großteil der Hersteller in beiden Welten unterwegs ist.
Ich. Bin.
Ich bin sehr, sehr, sehr gespannt, was sich durchsetzt,
ob es so das eine Model gibt, was wirklich sehr viel besser
ist als die anderen, das kann ich mir fast noch nicht so ganz
vorstellen, weil die ja alle auf sehr ähnlichen Daten irgendwie
trainieren, oder ob es irgendwann so den einen Agenten
gibt, der irgendwie komplett modelunabhängig ist und der sich
irgendwie durchsetzt. Wir werden es hier im Podcast
auf jeden Fall weiter verfolgen, mich interessiert aber
wahnsinnig, was ihr dir jetzt hier alle zuhört, was?
Was ihr dazu denkt? Weil ich weiß, dass die
Developer Community da super zweigeteilt.
Es gibt Leute, die lieben ihr Terminal und es gibt Leute, die
möchten am liebsten niemand ihre ID verlassen und deswegen machen
wir unter dieser Folge mal eine kleine Umfrage.
Wo fühlt ihr euch wohler, sagt ihr, Ich finde das eigentlich
cool, dass die Agenten jetzt im Terminal irgendwie sind und ich
finde das auch gut, dass das irgendwie im Hintergrund läuft,
dann könnt ihr darauf verbannen oder dass es eh die die
Umgebung, in der ich mich am allerwohlsten fühle oder am
liebsten arbeite und. Oder sagt ihr, ihr habt lieber
eigentlich eine so tiefe Integration in eurer Ide wie
möglich? Wir machen mal so eine IDE oder
Terminal Umfrage und wenn irgendwas davon nicht passt,
dann lasst es auch gerne einen Kommentar nochmal irgendwie
unten drunter da wenn ihr das nochmal ein bisschen
ausformulieren wollt und dann können wir gerne auch in der
nächsten Folge mal ein bisschen einsammeln, was ihr als unsere
Community so ein bisschen dazu denkt, weil ich einfach weiß und
das Gefühl habe, dass die developer Community da sehr
zweigeteilt ist. Und ihr habt ja meine Meinung
und maltes Meinung heute so ein bisschen gehört und jetzt
interessiert uns natürlich wie ihr dazu.
Eingestellt seid. Und wir sind nicht nur an eurem
Feedback zu diesem Thema interessiert, sondern wie immer,
wenn euch die Folge gefallen hat, lasst uns auch gerne eine
positive Bewertung da entweder auf Apple Podcast oder Spotify,
das hilft uns immer sehr, um auch in den entsprechenden
Charts von neuen Hörerinnen und Hörern gefunden zu werden.
Und wir freuen uns natürlich auch immer sehr, wenn ihr Lust
habt, uns einen Kaffee auszugeben oder wenn ihr zu
eurem eigenen Kaffee die passende Nerd Tasse mit Podcast
Branding haben wollt. Für beides schaut doch gern mal
in der Beschreibung vom Podcast vorbei.
Da findet ihr Links zu unserem Shop und zu bei mir Coffee.
Und wie immer hören wir uns schon nächste Woche wieder.
Der to do Developer Podcast erscheint jeden Montag
abwechselnd mit einer Themenfolge wie dieser und einer
News Folge im Wechsel. Also bis nächsten Montag.
Macht's gut, habt eine gute Zeit, schreibt ganz viel Code,
habt eine gute Woche und wir hören uns bald wieder.
Bis dahin.