Ai Coding Assistance wie Q Jules oder Co Pilot schreiben nicht
einfach nur Code, sondern mittlerweile übernehmen sie
komplexe Aufgaben, fixen Bugs oder Reviewen meine Pull
Requests. Damit werden sie immer mehr zu
echten Kolleginnen und Kollegen bei mir im Team.
In dieser Folge schauen wir uns an, wie Coding Agenten vor allem
die neuen Coding Agenten, den Entwickleralltag verändern, was
sie heute schon können und ob wir bald einfach nur noch mal KI
zuschauen, wie sie unseren Code schreibt.
Und damit ganz herzlich willkommen zu einer neuen Folge
vom To do Cast, dem Developer Podcast mit Malte Lantin.
Und Robin Manuel Thiel. Und heute sitzen wir tatsächlich
zusammen in deinem Wohnzimmer und versuchen mal, hier eine
gemeinsame Aufnahme und dementsprechend verzeiht es uns,
wenn es hier und da vielleicht an der Technik ein bisschen
hakt. Wir haben das Beste gegeben, wir
sitzen jetzt hier schon eine. Stunde zusammen und bauen alles
auf. Ich hoffe die Qualität ist
dementsprechend. Ganz gut.
Wir posten mal auf Social Media ein Foto von dem, was sehr
amateurhaftes Setup, was wir hier aufgebaut haben und der
malte hat die weite Reise nach München nicht gescheut und
deswegen, wer uns heute zuschaut und nicht nur zuhört, der sieht,
wir sitzen heute ausnahmsweise mal nebeneinander, Walter, ich
wusste gar nicht, dass du so gut riechst.
Als wenn wir uns das erste Mal treffen.
Aber vielleicht kommt der gute Geruch auch durch den Kaffee,
den Olaf uns heute ausgegeben hat.
Ich war hier bei dem lokalen Kaffee Shop des Vertrauens um
die Ecke und habe hier Kaffee für uns geholt.
Grüße gehen raus an die Coffee Twins.
Ja, herzlichen Dank. Diese Folge auch mal ruhig
hätten sponsern können. Genau, danke nicht nur an die
Coffee Twins, sondern vor allen Dingen an Olaf, der uns diese
Woche einen Kaffee ausgegeben. Hat dann seht ihr hier auf dich.
Olaf, Vielen Dank. Schauen wir, bevor wir in das
Thema der heutigen Folge gehen, einfach noch mal ganz kurz
zurück auf die letzte Folge, weil wir haben da auch
zahlreiche Rückmeldungen von euch bekommen.
Das Thema Network Attached Storage beziehungsweise
Homeserver hat euch durchaus angesprochen, wir haben war ein
bisschen unsicher, weil es natürlich kein reines developer
Thema ist, aber wir haben einige Rückmeldungen bekommen von euch,
dass ihr das Thema oder die Reise genauso auf euch genommen
habt wie Robin, Manuel und euch euren eigenen.
Naas aufgebaut habt und von einigen kam da die Empfehlung,
wenn man das technische Grundverständnis hat, auf jeden
Fall den Weg gehen. Es gibt einem die entsprechende
Ruhe, dass man seine Daten unter der Kontrolle hat, unter der
eigenen Kontrolle hat und von daher hoffen wir, dass vielen
von euch die Folge so gut gefallen hat wie denen, die uns
die Rückmeldung gegeben haben und ich denke mal, wenn du das
nächste Hardware Update machst, dann wirst du das auch hier im
Podcast teilen. Dann schauen wir mal, ob ich
noch die Kontrolle über meine Daten habe oder ob sie dann alle
weg sind. Aber genau, wenn es da
Neuigkeiten gibt, dann lassen wir euch das natürlich sehr
gerne wissen. Jetzt zeigen wir mal ein das
Thema der heutigen Folge und Malte, du hast da n provokanten
Take mitgebracht, auch so n bisschen aus den jüngsten
Entwicklungen. Erzähl mal was.
Was besprechen wir heute und wie kamst du drauf?
Ja, es kam so n bisschen über die Konferenzen, die jetzt in
den letzten Wochen liefen. Wir hatten ja die Google IO, wir
hatten die Microsoft Build und natürlich ging es da wieder
primär um das Thema KI, aber was ich da besonders fand ist
wirklich diese Veränderung davon, dass KI bisher uns als
Developer als. Assistentin Assistent
unterstützt hat zu einer Welt, wo sie autonom eigene Aufgaben
übernimmt. Und die Frage ist, damit ist
jetzt der KI Coding Agent der neue Junior Developer in unserem
Team, dem wir jetzt einfach Aufgaben übertragen können, die.
Komplett autark erledigt werden und nicht so, wie es jetzt
vielleicht in den letzten Jahren war.
In der Art und Weise, wie wir KI genutzt haben, dass wir als
Developer den Code geschrieben haben und KI uns dabei
unterstützt haben hat, sondern dass wir wirklich die Rollen
wechseln und jetzt die KI die Aufgabe bekommt, den Code
schreibt und wir letzten Endes. Die Instant sind die drüber
schaut die das Review macht, die sicherstellt, dass die Qualität
entsprechend stimmt und damit glaub ich schon ist das so n
bisschen ein Wechsel des Paradigmas der sich jetzt nach
und nach auch in der Realität vollzieht.
Ich glaub wir hatten da in der Folge zu Devin damals schon
drüber gesprochen, dass es. Diesen Wechsel gibt der sich
andeutet, aber damals war das noch sehr rudimentär.
Ich meine, wir erinnern uns an die Folge, wo wir über Devon
gesprochen haben, wo man noch irgendwie über Slack Aufgaben
verteilt hat, an Devon, was sich irgendwie so ein bisschen
seltsam anfühlte, und mittlerweile sind ja alle großen
Player in dem entsprechenden Bereich unterwegs und bauen dort
ihre autonomen Coaling Agenten. Ja, ich glaube.
Das ist ganz spannend, weil damals also diese das Erste das
erste Mal, als sie so Coding AI gesehen haben, war das
wahrscheinlich so im Rahmen von Guitar Co Pilot.
Mittlerweile sind ja noch sehr viel mehr Sachen dazu gekommen,
also A hat natürlich Guitar Co Pilot sehr viel mehr Konkurrenz
bekommen über Musik, Kaiser wie Windsurf und so weiter also da
gibt es verschiedene Geschmacksrichtungen und auch
die komplett autonomen Agenten die du gerade angesprochen hast
und die werden glaube ich gerade mehr und die sind ja glaube ich
gerade die die die die die spannend sind und da gibt es
von. Allen Playern auf dem Markt
mittlerweile irgendwas also Gitter bisher schon lange nicht
mehr alleine. Also wir sehen irgendwie allein
schon Amazon Q Developer, das glaube ich auch ein internes
Projekt ursprünglich gewesen, was du mittlerweile, wenn du auf
der RWS Plattform eben unterwegs bist auch nutzen kannst um dich
halt kurz zu schreiben, Aufgaben zuzuweisen.
Google hat mit Jules auch ein ähnliches Projekt, was jetzt
auch auf der Google IO letztens noch mal, zumindest da die
Erweiterung und Neuerung vorgestellt haben, Devin haben
wir schon angesprochen und. Was ich eigentlich spannend
finde, ist, dass so. Deswegen sagte ich vorhin, dass
das alles so aus dieser Co Pilot Ecke entstanden ist.
Die Frage ist, wieviel Co Pilot ist denn Co Pilot noch, weil
damals als Co Pilot rauskam, hieß es ja immer du bist im
Driver Seed und das Ding sitzt so n bisschen neben dir und
schaut dir zu und ich glaube wir sehen gerade so n bisschen so n
Rollentausch also sitze ich noch im Driver seed also ich habe auf
jeden Fall ja noch die letztendliche Kontrolle,
zumindest wenn ich die nicht ganz bewusst abgebe.
Man kann mittlerweile mit Co Pilot Agent Mode auch sagen ich
will Auto approve. Also ich will gar nicht mehr
gefragt werden. Also dann ist wirklich pure Vipe
Coding. Also ich will nicht mehr gefragt
werden, ob du irgendein Tool ausrufst.
Ich kann auch sagen, wenn ich dir die Codevorschläge, die du
mir machst nicht nach mindestens 60 Sekunden oder sowas bestätigt
habe, dann sieh das als ich habe akzeptiert und sowas an.
Und das ist schon die Frage, wie sehr also, wer ist denn hier im
Driver sieht und wer ist hier noch der Co Pilot?
Ja, aber das, was du gerade beschreibst, ist ja trotzdem
noch in der ide. Das heißt, du arbeitest da immer
noch iterativ in der IDE, das Tool, also der Agent läuft dann
zwar in einer gewissen Zeit alleine und löst die Aufgaben,
die du übergibst. Die Aufgaben können ja auch
komplex sein, wir hatten das in der Vergangenheit besprochen,
egal ob es jetzt irgendwie einen Co Pilot ist oder ob es einen
Win surf ist, wo ich dann eine Aufgabe übergebe, aber das Ganze
ist noch irgendwie. Mit mir gemeinsam und synchron.
Und manchmal hat man dann diese seltsamen Wartezeiten, das
heißt, ich geb dann ne Aufgabe an meinen Agenten, sitz dann
dabei und schau, weil ich weiß ja nicht, wie lang das dauert,
das heißt, ich hab auch nicht wirklich die Möglichkeit, dann
währenddessen was anderes zu machen, weil es kann sein, dass
danach irgendwie nach einer Minute ne Rückfrage kommt oder
es kann sein, dass das ganze irgendwie 15 Minuten läuft, weil
es ne komplexe Aufgabe ist. Und dann sitze ich da, schau
irgendwie wie da Daten reingestreamt werden und frag
mich, wie kann ich die Zeit sinnvoll nutzen und der.
Der Shift jetzt ist, dass ich tatsächlich diese Aufgaben
asynchron erledigen lassen kann und damit die KI zu einem echten
Teammitglied wird, der ich, dem ich komplexe Aufgaben übertragen
kann. Und das kommt vor allen Dingen
darüber, dass ich eine Integration sehe bei allen
diesen Tools, die ich jetzt gerade genannt habe, habe ich
mittlerweile eine Integration in github und andere Source Control
Systeme, in denen ich meine Aufgaben üblicherweise verwalte,
verwalte und ich meine, wenn du jetzt mal in deinen Alltag
schaust, dann. Du legst ja in der Regel die
Aufgaben, die du erledigen möchtest, nicht irgendwie in n
Textdokument auf deinen Desktop oder du überlegst dir die
spontan vielleicht so in diesem Vibe Coding, wie wir das in den
letzten 6 bis 12 Monaten gesehen haben, überlegt man sich so on
the go, was man als nächstes implementiert, aber im Alltag
der professionellen Softwareentwicklung gibt es ja
irgendwie Werkzeug, wo ich meine Anforderungen dokumentiere, wo
ich die Aufgaben beschreibe, die ich.
Als. Irgendwelche github issues oder
was das meinst. Du genau.
Und wie arbeiten wir klassischerweise, dass wir dann
sagen Okay jetzt Robin Manuel, das ist jetzt dein dein JIRA
Ticket, oder das ist dein issue, den Weise ich dir zu und dann
fängst du an, dir darüber Gedanken zu machen, wie du diese
Aufgabe löst, wie du sie implementierst.
Im Idealfall hat dann irgendjemand sich viele Gedanken
darüber gemacht, dass du nicht noch viele Rückfragen stellen
musst. Aber diese Rückfragen kannst du
ja stellen über so einen Dialog dort in diesen Tickets oder
Issues. Und dann fängst du an, die
Aufgabe zu übernehmen und das Ganze passiert ja nicht ad hoc.
Und wenn wir jetzt im professionellen Umfeld unterwegs
sind, wollen wir ja gar nicht, dass irgendwie eine Developer
tatsächlich sich ad hoc überlegt, was könnten die User
denn jetzt vielleicht als nächstes wollen und dann das
ganze Vibe Code coded, sondern wir haben tatsächlich
produktmanagerinnen Produktmanager, die sich
Gedanken darüber machen, was sind die Anforderungen, das
entsprechend planen, dokumentieren, eine Roadmap
schreiben und das Ganze dann über solche.
Tools abdecken und jetzt, und das ist glaube ich, eine
wesentliche Veränderung, die sich über das letzte halbe Jahr
ergeben hat. Jetzt kann ich halt einen Devin
oder einen Amazon Q oder einen Co Pilot diesen Github Issues
zum Beispiel zuweisen und die fangen dann an diese Aufgabe zu
erledigen, aber nicht auf deiner Developer Maschine in deiner
Idee, sondern die Bauen in ihrer eigenen Umgebung.
Das glaub ich der große Unterschied ne weil du gerade
sagtest das andere ist ja dass ich auf meiner Maschine immer
noch geblockt bin Ich kann nicht parallel was anderes machen ich
kann dem Ding zuschauen aber ich kann zumindest im gleichen
Projekt es sei denn ich Check mir halt irgendwie zweimal das
geht repository aus bla bla aber ne sind eigentlich nicht Ich
kann nicht meinen Laptop zuklappen in der Zeit oder das
Ding nachts arbeiten lassen oder das Ding 24 7 arbeiten lassen ne
also vielleicht schon aber Ich bin auf jeden Fall auf meiner
Maschine geblockt und das ist jetzt wirklich im Background
dass ich einfach sag Pass auf das ist ne Aufgabe.
Die Guan Tasking issue und was weiß ich das das könnte glaub
ich ne eine KI erledigen und dann kommt es wieder drauf an
wie immer. Wir haben ja schon in den
Podcast ganz oft über so Context is King bei KI gesprochen.
Je besser dieser Fehler dokumentiert ist desto besser
kann die KI den den den den lösen und das ist das gleiche
gilt ja für jeden Developer, also immer wenn ich mit
Entwicklerinnen und Entwicklern zusammenarbeite.
Dann ist ja auch völlig klar, je besser ich n Fehler dokumentiert
habe mit also gerade so gerade Issues in Github, da gibt es ja
wenn ich NN gutes großes Projekt hab hab ich ne Regel auch so
templates, dass ich sag OK was sind denn hier wenn ich n bug
hab steps for reprovolution also wie kann ich was genau muss ich
wo klicken damit dieser Fehler auftritt damit du den
nachvollziehen kannst was ist der Zustand der kommt was ist
der erwartete Zustand und so weiter und das sind natürlich
das ne Goldgrube eigentlich auch für diese KI Assistenten die die
das dann finden. Und auf auf Basis dieser Daten
arbeiten können. Ja, und letzten Endes, was dann
im Hintergrund technisch passiert ist, dass dann diese KI
Assistenten irgendwie ne virtuelle Umgebung in der Cloud
hochziehen. In diese virtuelle Umgebung
meinen Code auschecken, auf einem eigenen Feature Branch und
dann anfangen an der Aufgabe zu arbeiten.
Und nachdem diese Aufgabe erledigt wurde, vielleicht gibt
es zwischendurch Rückfragen, aber wenn diese Aufgabe erledigt
wurde, dann gibt es nen Pool request von diesem Feature
Brunch und den bekomme ich dann wiederum in meiner.
Umgebung github oder anderen und kann diese dann entsprechend als
developer reviewen. Kann dann Feedback geben, kann
dann auch Rückmeldung geben und sagen hier diese Codestelle
sollst du noch mal bearbeiten. Hier sehe ich ein Problem.
Ich habe weiterhin meine Tools Security Tools die drüber laufen
meine linking Tools die drüber laufen teilweise ki Tools die
das Ganze dann wiederum reviewen das ist so ein bisschen so KI
schreibt den Code KI Review den Code aber natürlich auch unsere
klassischen statischen Scanner laufen drüber und ich als
developer Review dann den Code geb Dir ein Feedback und mach
dann am. Am Ende auch den Merch, aber
dementsprechend fühlt es sich genauso an wie wenn ich dir halt
eine Aufgabe übertrage. Ich sage jetzt Robin, Manuel, du
arbeitest an dem github issue und dann kommst du irgendwann
mit dem PR zurück, vielleicht hast du im Vorfeld irgendwie
einen Entwurf angelegt, hast dann da nach und nach Code über
verschiedene Commits hinzugefügt und genau das kann ich halt
jetzt auch beobachten wieso ein KI Assistent das Macht und am
Ende kriege ich das fertige Ergebnis, was hoffentlich dann
die Anforderung erfüllt das Problem gelöst hat und
lauffähigen Code produziert. Und wie wir das auch in der
früheren Folge zu Devin schon mal besprochen hatten, können
diese KI Assistenten ja mittlerweile auch verstehen, wie
baue ich die Applikation, wie führe ich die Tests aus, wie
kann ich vielleicht sicherstellen, dass auch das UI
hochkommt, dass das Feature vielleicht grundsätzlich
funktioniert und über so Dinge wie Halt MCP Server kann ich
dann ja sogar. Tests ausführen und gucken OK,
funktioniert das Feature so wie ich mir das gedacht habe?
Weißt du, ob das Ding mir Rückfragen stellt?
Also nehmen wir an, ich bin jetzt in dieser github Welt und
ich hab jetzt n issue und ich weise da weise jetzt co Pilot
diesen issue zu. Ich sag jetzt das macht nicht
der malte sondern das Macht der Co Pilot weißt du ob das Ding
selber erkennt wenn es das also wenn es nicht selber nicht
weiterkommt oder weißt du ob es ob es dir sagen kann ey ich
glaub da hab ich nicht genug Informationen also antwortet das
dann in diesen issue oder markiert dich tag dich das oder
wie kriegst du das mit weil ich weiß dass Devin, hast du mit so
einem mit so einem Slackkanal verbunden, sodass dir das über
Slack irgendwie sagen kann. Ich, ich glaube du musst da mal
kurz drauf gucken, das lief ja auch live irgendwie durch, das
konntest du wirklich live zugucken bei diesem neuen Co
Pilot Ding was im Hintergrund läuft ist glaube ich so ich weiß
weiß ich weiß in den issue zu und dann kriege ich halt
irgendwann den Pull request gestellt.
Also auch so, egal ob jetzt ne Amazon Q, dass sich in Github
integriert oder nen github co Pilot.
Ich kriege dann über Kommentare in meinen Issues auch
entsprechend Feedback. Teilweise sehe ich dann auch in
dem Pull request Hey. Für folgende Dinge hätte ich aus
dem Internet n Package runterladen müssen müssen, hab
aber keinen Zugriff auf das Internet, weil das Netzwerk mich
geblockt hat. Bitte Konfigurier erst mal die
Firewall für die virtuelle Umgebung entsprechend um.
Damit ich das entsprechende Tool runterladen kann.
Wenn du das so möchtest. Also ich habe natürlich auch so
ein Feedback Loop und den Feedback Loop habe ich
einerseits so proaktiv von meiner Seite, das bedeutet ich
bekomme den Code, kann dann den Kommentieren und dann wird er
überarbeitet oder halt auch wenn das Tool nicht weiterkommt,
kriege ich natürlich dann auch entsprechend die Rückmeldung,
weil es wäre natürlich frustrierend, wenn ich irgendwie
dort Compute Zeit investiere und dann bekomme ich irgendwie nach
einer Stunde irgendwie das Feedback, hat alles nicht
funktioniert, ich habe mittendrin aufgehört und jetzt
müssen wir bitte. Du noch mal neu anfangen, weil
du musst noch mal dann sag. Es mir bitte einmal hier was ich
guck, ich mein das passiert bei einem das das kann dir ja aber
auch bei einem Teammitglied passieren, ne dass du sagst ey
du hast mir hier diese Aufgabe zugewiesen und am Ende hab ich
aber gemerkt, dass der, dass du vielleicht den letzten Coach
dann gar nicht committed oder gar nicht gepusht hast.
Und dann hat natürlich auch jemand irgendwie Zeit verloren
in deinem Team. Ohne dass dass also, dass man
Aufgabe hätte, gar nicht lösen können, weil du vielleicht auch
irgendwie Informationen nicht mitgegeben hast.
Ja, ich glaub die das Szenario ist für mich eher so wie die
Kolleginnen und Kollegen, die teilweise sehr lange an
irgendeiner Aufgabe arbeiten, vielleicht irgendwo nicht mehr
weiterkommen, das dann aber nicht sofort kommunizieren,
genau dann nicht nachfragen und kommen dann irgendwann nach 2
Wochen zurück am Ende des Prints und sagen hat nicht ganz
geklappt, Requirements waren unvollständig oder ich hatte
einen technischen Blocker. Das müssen wir in den nächsten
Sprint noch mal mitnehmen und genau das sollte natürlich nicht
passieren. Genauso wie wir von menschlichen
Kolleginnen und Kollegen erwarten, dass sobald sie nicht
weiterkommen, wenn sie Rückfragen haben, sie anfangen
zu kommunizieren, erwarten wir natürlich jetzt das Gleiche von
diesen KI Agenten, auch weil wir sonst natürlich dann.
Analog zu den Personalkosten in der Vergangenheit dann auch
entsprechend Kosten haben. Weil natürlich ist das Ganze
nicht umsonst diese ganze Computerzeit, die da investiert
wird, die Zugriffe auf die KI Modelle sind alles
kostenpflichtig und dementsprechend ist natürlich
wichtig, dass ich da auch das Ganze führen kann, aber was für
mich jetzt irgendwie auch spannend ist, es zu sehen, dass
gerade das, was auch beim Menschen vielleicht immer so ein
bisschen. Stiefmütterlich behandelt wurde
nämlich das Schreiben von guten Anforderungen.
Jetzt noch wichtiger wird, weil bei Menschen war es manchmal so,
man hat irgendwie das sehr rudimentär beschrieben, dann hat
man aber irgendwie stundenlang Meetings zusammengesessen und am
Ende hat es keiner gemerkt, dass ich schlecht dokumentiert hatte,
weil in dem Meeting hat sich das dann geklärt, aber mit einer KI
irgendwelche langen Meetings haben und viele Rückfragen ist
teilweise nicht möglich oder einfach nur nervig und
dementsprechend ist es natürlich wichtig.
In meinen Anforderungen, die ich ja dokumentiere.
In meinem Jura Ticket oder in meinem Get issue dann wirklich
präzise zu sein. Ne was möchte ich erreichen, was
sind die Anforderungen die erfüllt werden müssen, wie kann
ich das auch validieren, dass es nachher funktioniert, so wie
erwartet, damit dann das was die KI umsetzt auch getestet werden
kann und ich dann natürlich auf funktionierenden Code
zurückkomme. Ist schon verrückt.
Also ich glaube, wir hatten das von vor ein paar Folgen schon
mal gesagt, dass irgendwie, dass KI uns jetzt dazu verleitet,
endlich unseren Code zu dokumentieren, unsere
Anforderungen zu dokumentieren. Es gibt auch schon diese.
Diese Motions von so so specdriven Vibe Coding so n
bisschen, dass du halt sagst, ich setz mich erstmal hin,
wirklich vielleicht ein 2 Stunden und schreibe runter, was
meine Anforderung ist oder vielleicht was meine ganze
Applikation ist, die ich bauen will und dann geht irgendein
Agent irgendeine KI hin und baut das und das funktioniert halt,
weil ich das nicht nur in meinem Kopf habe, diesen Gedanken,
sondern weil ich mich wirklich hingesetzt habe, den
Runtergeschrieben ne gute ne gute.
Spezifikation geschrieben hab. Vielleicht haben wir da auch
schon mal drüber gesprochen, vielleicht ist das auch die
Rolle von uns als developer mal irgendwann in der nahen Zukunft,
dass wir viel viel mehr so Spezifikationen schreiben,
Architekturentscheidungen treffen, das Ganze in Diagrammen
vielleicht ausdrücken, Abläufe beschreiben und wirklich dieses
reine Runtertippen vom Code, dass das gar nicht mehr unsere
Aufgabe ist. Während hat man auch eine
interessante Überlappung dann zwischen den Aufgaben, die man
üblicherweise so als Produktmanager hat, in den
Aufgaben, die man als Developer hat, weil man ja in der
Vergangenheit irgendwie davon ausgegangen ist.
Produktmanager spezifizieren, was ist so die das Business
Requirement, wo will ich hin und welche Aufgabe soll mit dem
Ergebnis gelöst werden und dann das Development Team macht sich
Gedanken darüber die technische Architektur zu designen, wie
implementieren wir das ganze und jetzt muss ich das natürlich.
Vorab dokumentieren, das heißt, da gibt es dann schon vielleicht
ne engere Zusammenarbeit, bevor ich überhaupt so einem KI
Agenten ne Aufgabe geben kann, muss ich mir Gedanken darüber
machen, was ist grundsätzlich so die Architektur meiner Software,
weil abseits dieser Prototypen, die ich vielleicht mal schnell
irgendwie von so einer KI runterschreiben lasse, muss ich
natürlich im professionellen Kontext sichergehen, dass ich
irgendwie ne Software baue, die irgendwie.
Die Architekturstandards berücksichtigt die ich
unternehmen habe, die genau die Wartbar ist.
Und das muss natürlich dann vorab passieren, weil ich möchte
natürlich nicht irgendwie so einen KI Agenten loslaufen
lassen und am Ende sagen, ja, übrigens, ich hätte gern, dass
du ein anderes Framework verwendest und wir haben ganz
anderen Architektur, Pattern und jetzt fang noch mal neu an und
überarbeite das, sondern das sollte natürlich vorab klar
sein, das heißt, ich muss dann auch entsprechend das
dokumentieren, es gibt da in den unterschiedlichen Tools die
Möglichkeiten solche Custom prompts zu hinterlegen, wo dann
halt solche. Technologischen Informationen
hinterlegt sind. Welche Technologien setze ich
ein, welche Architektur etc. Damit natürlich mein KI Agent
das entsprechend umsetzen kann und damit kann ich natürlich,
und da kommen wir so ein bisschen zu den Vorteilen und
Risiken dieser neuen Technologiewelle der KI, da
komme ich natürlich an einem Punkt, wo ich dann gerade bei so
Routineaufgaben mein Development Team entlasten kann, ich kann
so. Kleine.
Fixes oder entlasten was? Entlasten hab ich.
Gesagt, ich hab's verstanden, wo ich die Notiz aufgaben kann.
Ich meine bei der Party entlasten.
Nee, tatsächlich haben wir häufig häufig das Risiko, dass
wir einen extrem langen Backlog von Sachen haben, die wir
eigentlich schon immer mal machen wollten.
Es können kleine Fixes sein, irgendwie user Feedback, wir
haben häufig die Herausforderung, dass wir ganz
viel Rückmeldung kriegen von irgendwie usern, hey, ich hätte
noch dieses kleine Feature, das ist aber vielleicht nur für ganz
wenig Kunden relevant und dementsprechend befindet sich
das irgendwo ganz unten auf meinem Backlog oder irgendwelche
Bugfixes. X ist und statt da jetzt mein
Development Team zu beschäftigen, kann ich solche
kleineren Aufgaben, die auch vom Scope sehr überschaubar sind,
weil sie sich nur auf einen bestimmten Bereich meiner
Software beziehen, dann sehr gut einfach asynchron durch solche
KI Agenten. Finde ich spannend.
Du hast gerade gesagt, anstatt mein developer Team zu
beschäftigen, ich würde vielleicht schon sagen,
vielleicht wird KI teil deines Developer Teams und das ist
einfach auch einfach so Teil der vielleicht im Moment noch Armee
von Junior Developer, die du vielleicht irgendwie hast, dass
er, ich weiß es halt einfach jemanden zu, von dem ich weiß.
Dass er oder s. In dem Fall ja wahrscheinlich
oder vielleicht auch sie das erledigen kann und mit s mein
ich halt ne KI, also vielleicht ich ne wie ich halt auch sonst
issues den Leuten zuweise, von denen ich glaube, dass sie es
lösen können und die die Zeit haben und die Skills und so
weiter gibt es halt jetzt einfach ne bestimmte Kategorie
von von Aufgaben, die ich einfach sag, das weiß ich dann
einfach dieser KI zu und das finde ich ist auch so n bisschen
diese Power, also einer dieser ganz klaren Vorteile die ich
sehe, bevor wir gleich mal über die über die Nachteile und die
Risiken davon aussprechen. Weil gerade so Junior Developer,
hatten wir schon mal angesprochen ist ist glaub ich n
großes Fragezeichen in in der Industrie, aber der Vorteil ist
ja eigentlich, dass Art, also ne was ja völlig auf der Hand liegt
ist, dass das dass die Dinger unendlich skalieren.
Ich kann da an 10 issues gleichzeitig arbeiten und auch
die KI arbeiten lassen, bedeutet halt auch jeder hat ja auf
einmal n Team zur Verfügung wenn ich mir überlege also ich hab
mich mit vielen Developerern die sagen ganz ehrlich aber.
Am besten oder am einfachsten und am liebsten würde ich
alleine arbeiten, weil da muss ich mich mit keinem abstimmen.
Dann dann passiert es am besten und das hat natürlich Grenzen
und Limits und ich glaube, wenn du richtig gut in dem Projekt
oder irgendwas egal was ist, warum willst du dieser eine
Skill der der dich anlockt mehr zu erreichen als du selber
könntest dich selber zu zu skalieren.
Ist die Fähigkeit in dem Team zu arbeiten und ich glaube, keiner
liebt es in dem Team Software zu schreiben.
Aber jeder der das schon mal gemacht hat, kennt auch
irgendwann die Magie, dass an verschiedenen Baustellen
gleichzeitig gearbeitet wird, gearbeitet wird und am Ende
kommt das alles zusammen und dann funktioniert es doch
irgendwie und jetzt hat jeder ja eigentlich die Möglichkeit
dieses Team. Sich aufzubauen und gerade so
nimm, nimm irgendwie so Open Source Projekte die von so einem
einzelnen kleinen Maintainer irgendwie maintained werden, die
dann irgendwann so groß werden, dass es haben wir auch schon mal
drüber gesprochen, so dass es eigentlich irre ist, dass es an
einer Person irgendwie hängt und dann natürlich auch sich so n so
n Backlog an Issues füllt und wie du gerade sagst, hat
eigentlich ja jeder gerade die Möglichkeit.
So ein Mini Team sich aufzubauen.
Und ich glaube, meine Aufgabe ist es dann als Developer zu
entscheiden, was sind die Aufgaben, an denen ich arbeite
oder an denen ich arbeiten möchte und was sind die
Aufgaben, die ich delegieren kann, weil sie.
Vielleicht auch von der Komplexität oder vom Scope dafür
geeignet sind, dass KI sie zum heutigen Entwicklungsstand schon
gut erledigen kann. Die Technologie entwickelt sich
natürlich weiter, aber man muss natürlich auch immer schauen,
was kann die Technologie heute auch schon zuverlässig, weil
wenn ich am Ende noch super viel nacharbeiten muss, dann habe ich
vielleicht genauso viel Zeit investiert wie vorher, aber ich
glaube, man kann dann auch letzten Endes auch schneller
Funktionalitäten umsetzen, weil man diese ganzen kleinen
Aufgaben abgeben kann, die größeren Aufgaben habe ich mehr
Zeit, mich darauf zu konzentrieren und kann dann.
Dann wirklich auch entsprechend Dinge abarbeiten und damit auch
die Qualität. Feature Umfang meiner Software
erhöhen. Man muss natürlich dann auch
immer so ein bisschen die Kosten im Auge behalten, weil wir
hatten ja gerade schon gesagt, das Ganze ist nicht kostenfrei
und das verleitet natürlich dazu ganz viel irgendwie abzugeben
und dann auch in solchen asynchronen Flows weiß man gar
nicht, wie viele KI abfragen passieren, dann letzten Endes,
das heißt, das ist auch so leicht.
Unpredictable ne, manche der Kosten sind halt vorausschaubar
manche der Anbieter haben so ein Flat Price und so pro Aufgabe
die ich übergebe wird berechnet, bei anderen ist es wirklich nach
Tokens oder nach Compute Zeit und dann wird es natürlich
extrem schwer da auch ein Forecast zu machen, aber das ist
glaube ich dann eine Fähigkeit die man nach und nach irgendwie
so ein bisschen Gefühl entwickeln muss wie das Ganze
funktioniert. Bei einem Menschen auch.
Er weiß da auch nicht immer, wie lange man dafür braucht, und
manchmal sagt er. Oder glaubst du auch selber, das
ist ne Sache, die habe ich in einer Stunde erledigt und
irgendwann sitzt sitzt du da 2 Tage dran, also ich hätte nie
gedacht, dass das so lange dauert, aber klar muss man das
natürlich irgendwo limitieren können, ich kann nicht da
irgendwie, wenn ich jetzt vor 2 Wochen der KI ne Aufgabe gegeben
habe und die ist halt seit 2 Wochen 24 7 dran und in irgend
so einer Endlosschleife gefangen und verbrennt da meine Credits,
das muss man natürlich irgendwie deckeln können oder man muss
irgendwie sagen, dass auch wenn du das nicht innerhalb von einer
halben Stunde lösen kannst, dann.
Schreib mir bitte noch mal oder dann gucke ich da mal drauf, ob
du in die völlig falsche Richtung rennst und ob du kurz
davor bist. Ich glaube so Mechanismen die
werden jetzt auch dann als nächstes kommen, das ist
wirklich ja wieso ein wieso ein richtiger Teammate irgendwie.
Ja, und ich glaube, das wird jetzt tatsächlich so ein
bisschen unlockt dadurch, dass wir diese Integration haben in
die Werkzeuge, die wir traditionell jetzt schon seit
vielen Jahren nutzen. Vorher war es so ein bisschen an
meine Idee gebunden, aber jetzt läuft es im Hintergrund, aber
das Ganze kommt natürlich nicht ohne Risiken, wir haben gerade
schon über das Thema so Kostenkontrolle gesprochen.
Wochen, aber natürlich auch so. Qualitätskontrolle wieviel
Vertrauen setzt man in den Anbieter, der mir diesen KI
Assistenten verkauft oder anbietet, weil häufig werden die
Sachen ja dann nicht inhouse entwickelt, sondern das sind
irgendwelche großen Player wo ich das dann entsprechend als
Abo oder Pay as you go dazukaufe das heißt ich muss dann auch
darauf vertrauen, dass die mit der entsprechenden Qualität
arbeiten, dass die vertrauenswürdig sind.
Und das Ganze bringt dann natürlich Herausforderungen mit
sich, die ich aber auch vorher in der Zusammenarbeit natürlich
mit menschlichen Teams hatten. Wir haben auch in der
Vergangenheit mal so ein bisschen Richtung, irgendwie
macht es Sinn, vielleicht auch Dinge über solche Fiverr
Freelancer Out zu sourcen, da hat man natürlich die gleiche
Herausforderung, kann ich dieser Person vertrauen, wird diese
Person das in Time mit der richtigen Qualität erledigen
und. Und genauso sieht es natürlich
jetzt bei diesen KI Agenten. Auch aus einer Security
Perspektive ist ja auch n völlig neuer Angriffsvektor, also ist
es wahrscheinlich deutlich schwieriger nen Menschen zu
beeinflussen sich jetzt irgendwie gegen mich zu wenden
als ne KI, die vielleicht sogar wirklich glaubt, dass sie das
richtige tut, wenn sie mir ne ne library die vielleicht ne
bekannte Sicherheitslücke hat, irgendwie unterjubelt oder
einfach weil sie darauf trainiert wurde, oder?
Das ist ja völlig intransparent für mich, ich weiß ja gar nicht
genau warum diese KIS weltsche Entscheidung trifft und wer da
vielleicht. Das Training Set versucht hat zu
beeinflussen, irgendwie die dem prompt Versuch zu injekten
vielleicht macht macht jemand bei mir in meinem Open source
repository nen issue auf. Schreib in das issue rein
irgendwie so ignor all previous instructions und blabla also
versucht der KI irgendwie ne Anweisung zu geben die mir
vielleicht durchrutscht. Also das ist ja also zumindest
müssen wir wissen, dass es n neuer Angriffsvektor und so n
neuer Sicherheitsvektor wird. Ja, gerade so in Kombination mit
diesen MCP Themen, über die wir letztes Mal gesprochen haben.
Genau das, was du erwähnt hast, war diese Woche in einem
Blogspot ne, da hat jemand gesagt, Hey, ich hab es
geschafft über einen issue in einem Open Source Repository n
prompt injection zu machen, weil dann entsprechend über den MCP
Server der Agent diesen issue sich gezogen hat und dann über
den gleichen MCP Server dann. Vertrauliche Informationen in
ein anderes Repo geschrieben hat und damit konnten dann
Informationen extrahiert werden, das heißt, über solche Themen
muss man sich Gedanken machen. Kann ich diesen Anbietern
vertrauen, welche Angriffsvektoren gibt es da
entsprechend, aber das gleiche war natürlich auch in der
Vergangenheit der Fall, wenn ich irgendwie neue Leute in mein
Team geholt habe, man braucht immer eine gewisse Zeit, um das
Vertrauen zu entwickeln, dass die Person die richtige Qualität
liefert et cetera und genau so sieht das jetzt aus.
Aber es kommen natürlich noch auch andere Herausforderungen
ins Spiel, die jetzt vielleicht in der Vergangenheit noch nicht
so relevant waren. Und ein Thema, das hatten wir ja
gerade schon angesprochen, wie baue ich in Zukunft wissen auf,
gerade bei den Kolleginnen und Kollegen, die noch nicht so viel
Erfahrung haben, Stichwort Junior Developer, wenn ich jetzt
alle diese Aufgaben, an denen man gut lernen kann, irgendwie
an der KI weg delegiere, und wir hatten in der Vergangenheit ja
darüber gesprochen, ja, wenn ich das ganze jetzt irgendwie in der
Idee mache, lese ich immer noch mit und schaue, wie die KI das
macht. Macht und kann damit mein Wissen
aufbauen. Wenn ich das jetzt in diesem
asynchronen Prozess habe. Das heißt, ich kriege am Ende
immer nur das Endergebnis, wird das natürlich für mich als
jemand mit wenig Erfahrung super schwer, das Endergebnis zu
beurteilen, zu reviewen und sicherzustellen, das heißt, das
müssen eigentlich erfahrene Kolleginnen Kollegen machen.
Und welche Aufgabe habe ich dann als Junior, die es mir hilft,
noch zu wachsen und zu lernen? Und ich glaube, da müssen wir
uns dann natürlich auch neue Wege überlegen, weil am Ende
brauchen wir den Nachwuchs, wir brauchen neue Leute, die ins
Team kommen, neue Ideen liefern und dann nachher auch die
Aufgaben später übernehmen, falls mal jemand das Unternehmen
verlässt. Also die Frage, die Frage, wie
wird man Senior, hatten wir ja schon mal in einer eigenen
Folge, aber ich glaube diese Frage, die sich gerade allen
stellt ist, brauchen wir noch Junior Developer?
Ich würd wahnsinnig gerne mal mit dir ne Frage drüber machen,
wie man wie man Junior Developer gut anleitet.
Wie schafft man es also was mach ich mit den Junior Developer in
meinem Team, wofür kann ich sie sehr gut gebrauchen und wie wie
schaff ich es, dass ich denen also dass ich die so in meine
Prozesse einbinde, dass sie möglichst schnell wachsen, den
Code verstehen. Lernen können und dann auch
super schnell eben senioriger werden, wenn wenn das spannend
ist für euch, weil ich hab da n paar Gedanken zu und malte du
bestimmt auch, lass uns das gerne mal in den Kommentaren
wissen ob das ne Folge ist, die euch die euch interessiert, weil
ich glaub das haben wir immer mehr und die Frage die sich halt
in dieser KI Richtung stellt ist ja einfach, müssen wir denn
überhaupt noch Junior Developer heiern wenn wir jetzt diese
Armee aus KI Agenten haben die eigentlich diese Aufgaben die
wir früher Junior Developer gegeben haben übernehmen kann?
Ja, ich glaub das ist n wichtiges Thema und auch die
Frage ist, wie verändern sich die Aufgaben, weil die Frage ist
ja irgendwie, was macht die KI, was machst du als Developer und
auch für die Leute die neu im Team sind ist auch die Frage,
wie lernen sie, ich glaub da müssen wir noch mal dediziert
drüber sprechen, aber auch jenseits dieser Learning
Perspektive finde ich das ne sehr spannende Herausforderung
irgendwie wer ist verantwortlich für was?
Das heißt, Wer ist für den Code verantwortlich?
Wer stellt sicher, dass die Qualität stimmt und auch, wie
entwickle ich die Fähigkeiten zu entscheiden, welche Aufgaben man
besser selber macht, welche die KI machen kann?
Gerade ich arbeite viel mit sehr großen Unternehmen zusammen bei
solchen Großen, vielleicht auch über viele Jahre oder Jahrzehnte
gewachsenen Applikationen, wo viele der Dinge, an denen die
Developer heute arbeiten, sich stand heute noch nicht durch
eine KI vollautomatisieren lassen, dann aber dennoch.
Bei jedem einzelnen Fall zu entscheiden, OK, das ist
vielleicht ne Aufgabe, weil es vielleicht n kleinerer fix, die
geb ich einfach mal ab um mich dann wiederum auf die größeren
Sachen zu konzentrieren. Ja, und die Frage ist halt,
früher hab ich das Halt an Junior abgegeben und jetzt geb
ich das an der an der an der KI ab.
Was mach ich damit ich glaub das ich glaub das das wird ne ne
sehr sehr spannende Entwicklung auch womit wir uns als Industrie
beschäftigen müssen weil wenn wir keine Juniors feiern dann
haben wir also wer wer macht das denn dann in in 20 Jahren nur
noch die KI maybe und wenn nicht.
Ist glaub wichtig, also dieses ganze Junior Thema.
Wie gesagt machen wir mal ne eigene Folge zu um das
abschließen. Eine Sache ist mir aber noch
irgendwie wichtig, die hier mal stehen zu lassen, das ist ich
glaube wir haben Junior Developer noch nie für ihre
Skills geheiert also ich glaub wer sich jetzt die Frage stellt
OK wenn jetzt die KI das übernehmen kann brauch ich dann
noch noch Junior Developer du higherst eigentlich juniorige
Leute nicht wegen ihrer Skills sondern auch wegen der Energie
die sie mit in n Team bringen wegen der.
Wegen wegen der Frische, die sie vielleicht noch noch im Kopf
haben, weil sie vielleicht simple Fragen stellen, die du
aber lange nicht nicht mehr gehört hast, mit denen du lange
nicht mehr gerechnet hast. Die Dinge in Frage stellen, die
für alle im Team aber völlig klar waren und so weiter und ich
glaube, der Grund, warum du Julien Developer hast, noch viel
aus einer kulturellen Perspektive für dein Team, weil
es einfach auch erfrischend ist, neue und junge Leute im Team zu
haben und nicht wegen ihrer Skills, weil selbst wenn die KI
jetzt die Skills übernehmen kann.
Haben wir, glaube ich, June Developer noch nie wegen ihrer
Skills geheiert. Das ist mir nur noch mal wichtig
hier stehen zu lassen. Wenn ich diese Frage in den Raum
stelle, die eben so ein bisschen provokant gemeint war, brauchen
wir die überhaupt noch? Das ist glaube ich mein Take
dazu. Ich glaube, gerade auch wenn wir
jetzt in die Zukunft schauen, ist es ganz interessant, einfach
auch zu sehen, wie sich die Art der Softwareentwicklung jetzt
durch diese asynchronen Agenten noch mal in einer neuen Welle
verändert. Wir hatten gerade darüber
gesprochen, es. Entwickeln wir bald nur noch
über JIRA Tickets und github issues und gar nicht mehr
wirklich im Code, weil den Code schreibt jemand anders und wir
machen uns viel mehr Gedanken über die Themen.
So Architekturanforderung tatsächlich wirklich in der
Fachlichkeit. Das heißt nicht, dass wir kein
technisches Wissen mehr brauchen und dass wir nicht mehr wissen
müssen, wie Software entwickelt wird und wie Code aussieht, weil
wir müssen es ja am Ende immer noch in gewisser Art und Weise
reviewen wir müssen sicherstellen.
Aber ich glaub der gibt es n gewissen Shift, dass wir auch
als Developer noch stärker in dieser Requirements Engineering
Phase arbeiten als in der Vergangenheit.
Und der zweite Shift ist glaub ich.
In die letzte Phase hin. Wir hatten vor, Ach, ich weiß
gar nicht vor, ich glaub anderthalb 2 Jahren mal über das
Thema Pull request Reviews gesprochen und wie man gute PR
Reviews macht und ich glaub da geht auch wieder mehr Fokus hin,
weil wir natürlich am Ende sicherstellen müssen, dass das
Ergebnis stimmt. Wir werden so, so, so
technischen Product Managern eigentlich.
Also wir werden sehr viel, ich glaub wir brauchen auf jeden
Fall noch noch noch viel wissen, weil wir eigentlich für den für
das Review von Code changes. Sehr viel mehr wissen braucht,
als um den Code Change selber zu machen.
Also eigentlich ne so traditionell, wenn wir da sind
wir wieder bei diesem Junior Senior Ding reviewen ja die
erfahren auch an dem Team meistens zumindest haben die das
oft das letzte Wort, also macht auch Sinn manchmal Juniors zu
reviewen wie gesagt machen wir vielleicht mal ne eigene Folge
zu, aber eigentlich muss brauchen wir ja sogar noch mehr
Erfahrung um diese Code changes dann bewerten zu können die so
ne KI macht. Also ich glaub das wissen.
Das wandert erstmal nicht ab, aber halt diese Tipparbeit.
Also ich werde eigentlich richtig, ich stimme dir
eigentlich da komplett zu sehr viel mehr Requirements
Engineering wo alle im Team meistens immer wissen, ah da
könnten wir ein bisschen besser werden und dann halt diesen
diesen Review Prozess und dann bespricht man vielleicht in
einem Team gemeinsam, was jetzt der beste Lösungsansatz ist,
lässt den aber von jemand anderem in dem Pro von AKI Bauen
und Review das nachher. Aber es hängt natürlich auch
immer vom Projekt selber ab. Wir haben halt so viele große,
über viele Jahre gewachsene Applikationen, wo vielleicht
jetzt auf absehbare Zeit sich erst mal gar nicht so viel
ändert in der Art und Weise, wie ich es entwickel, das heißt, ich
als Developer schreibe immer noch den Code, ich krieg
vielleicht n bisschen KI Unterstützung, aber glaube ich,
ich glaube bei neuen Applikationen, die wir jetzt neu
auf dem aktuellen Technologie Stack entwickeln, den dann auch
so eine KI gut beherrscht. Habe ich immer mehr Szenarien,
wo ich dann auch Aufgaben, inkrementelle Aufgaben,
Weiterentwicklung, Bug Fixes sehr gut an solche Agenten
abgeben kann und von daher ist es glaube ich auch so ein so
eine Veränderung, die im Laufe der Zeit sehr graduell läuft und
auch wenn jetzt man sich diese Konferenzen anschaut und dann
irgendwie denkt, wow. Wir vermitteln jetzt den
Eindruck, wir brauchen irgendwie in paar Monaten brauchen wir
keine Developer mehr. Das stimmt nicht und das merken
jetzt auch viele Unternehmen, dass wir einfach noch viel zu
viele Applikationen haben, wo wir die Menschen brauchen, die
die Erfahrung haben, die das Wissen haben, um diese
Applikation weiter zu pflegen, weil nicht alles ist auf einem
aktuellen Technologiespeck auf der grünen Wiese gebaut.
Ja, ich glaube gerade. Ja, also was was Spannendes für
diese. Ich glaub in dieser greenfield
Welt, da sehen wir eh so nen Shift, diese diese
Wegwerfsoftware die man einfach so für einen ich bau jetzt
wirklich ne Software für diesen genau einen Use Case, die lass
ich uns von der KI bauen, dann nutze diesen Use Case einmal und
entweder nutze das nur ich oder ich schmeiß die danach sogar weg
ich glaub da sind wir auf jeden Fall auch jetzt schon aber so
Legacy migrationen oder sehr sehr große gewachsene sehr
komplexe Projekte. Da gibt es ja schon so die
ersten Entwicklungen, gerade für diese Code Migration irgendwie
weg von COBOL oder Java X auf Java y updaten und sowas für die
Updates. Ja aber glaub ich für die Arbeit
da da drin brauchen wir auf jeden Fall noch developer aber
man sieht egal was man ist, man ist ja immer an dem Punkt, dass
man sagt brauchen wir noch developer, also war einfach
einfach nur weil die KI das noch nicht kann, aber das ist ja die
schlechteste KI die. Die wir jetzt also die KI
Variante, die wir jetzt haben, ist ja die Schlechteste, die
wir, die wir die nächsten 5 Jahre haben werden, die wird ja
nur noch besser. Ich glaube, die Unterscheidung
ist halt zwischen Developer und coder, weil ich glaube, Code
schreiben kann die KI mittlerweile sehr gut, aber
developer ist halt mehr. Wir haben ja gerade schon drüber
gesprochen, Architektur, softair Design, Requirements
Engineering. Da muss man immer noch diesen
Gesamtüberblick haben, den die KI zumindest heute nicht hat.
Und ich glaube, da ist n Unterschied zwischen Coder und
developer und vielleicht Dinge, die man jetzt schon in den
letzten 10 Jahren an irgendwelche Coder ausgelagert
hat, wo man gesagt hat, da ist vielleicht ist ne einfache
Aufgabe, kann jeder erledigen, ich hab einfach nur keine Zeit
dazu, die kann man jetzt halt auch durch ne KI.
Erledigen lassen und ich glaube, es ist wirklich so weit, dass
wir realisieren müssen, das ist jetzt jenseits der Phase, wo wir
einfach nur ein bisschen mit KI rumspielen, sondern es ist
Realität und früher oder später wird jeder und jede von uns die
Anforderung haben, solche KI Agenten zu orchestrieren, das
heißt, wir werden irgendwann wird irgendjemand zu uns kommen,
oder wir machen es einfach von von uns aus und und sagen, Hey,
du hast jetzt dieses Tool. Guck mal, welche Aufgaben du
delegieren kannst, damit du halt mehr Zeit für andere Dinge hast.
Also produktiver wirst genau, also lacht uns aus.
Aber Mark Hour words hier, ich glaube also das werden Teil, das
werden Kollegen werden, also das werden diese diese diese Gruppe
an KI Agenten, das werden halbwegs ernstzunehmende
vollwertige Kollegen in unserem Developer Team werden und das
wird der Alltag sein, dass man bestimmte Aufgaben an die
abgibt. Und das mag jetzt noch irgendwie
weit weg wirken, aber wir sehen halt gerade diese ersten
Auswirkungen daran und das wird ja wie gesagt nur noch besser
und ich bin felsenfest davon überzeugt, dass das irgendwann
absolut developer Alltag wird zu entscheiden, ah nee, das geb ich
ab. Ja, und ich fand ne Diskussion,
die ich online gesehen hatte ganz gut.
Da müssen wir jetzt nicht zu tief drauf eingehen, aber ich
fand es ne sehr schöne Analogie, weil ja immer die Angst besteht,
fällt unser Job weg und ich glaube wenn man sagt OK Musik
spielen, professionell Musik spielen.
Das kann man lernen und das kann vielleicht eine KI kann jetzt
professionell Coach schreiben, aber am Ende, wenn man ein
Orchester hat, braucht man immer noch gute Dirigentinnen und
Dirigenten, die dafür sorgen, dass diese Profis, die in ihrem
Bereich vielleicht super gut sind.
Gut zusammenspielen dass sie das richtige Spielen an der
richtigen Stelle in den richtigen Geschwindigkeiten.
Die Instrumente benutzen. Genau, und wir vielleicht dann
am Ende die Dirigenten und Dirigenten sind, die Halt dann
dieses Orchester dann irgendwie orchestrieren, und das ist
natürlich auch eine extrem wichtige Aufgabe und damit
steigt vielleicht sogar die Verantwortung, weil du hast da
nicht die Verantwortung für ein kleines Feature, sondern du hast
dann die Verantwortung für einen ganzen Park von Funktionalitäten
und Bugs, die gefixt werden und du musst das dann entsprechend.
Überwachen und sicherstellen, dass am Ende die Qualität
stimmt. Find ich n schönes Fazit.
Was glaubt ihr denn, ist das was?
Also stimmt ihr uns zu und geht es in der Zukunft eigentlich gar
nicht mehr darum, ob wir mit KI Agenten arbeiten, sondern eher
wie wir mit ihnen zusammenarbeiten sollen oder
würdet Ihr n KI Assistenten trauen, der einfach im
Hintergrund n vielleicht auch gut dokumentiertendes issue
abarbeitet? Lasst mich das gern mal wissen
und lasst uns das gern mal wissen und schreibt.
Schreibt da gern mal was in die Kommentare oder schreibt uns
doch irgendwie ne e Mail, wenn ihr das nicht öffentlich machen
wollt, findet ihr in der Beschreibung von jeder Folge
auch ne e Mail Adresse, da können wir auch gerne privat
diskutieren, wenn ihr keine Lust habt n Kommentar zu schreiben
aber malte und ich glaub ich wir reden auch viel mit Leuten die
so n bisschen in diesem AI Hype Train ganz vorne sitzen und uns
würde mal interessieren. Wie ihr das seht, die ja auch
jeden Tag in Softwareprojekten unterwegs sind und die da, die
das vielleicht auch aus einer Perspektive sehen, wo wo nicht
jedes github Cope halt feature sofort aktiviert wird und sofort
genutzt wird und wo auch natürlich viel, viel Skepsis
herrscht, da würden wir uns freuen, wenn ihr mit uns
bisschen diskutieren würdet. Und wenn euch die Folge gefallen
hat, lasst uns gerne positives Feedback da auf Apple Podcast
oder Spotify und ihr habt natürlich jederzeit die
Möglichkeit uns einen Kaffee auszugeben.
Nutzt dafür den Link zu bei mir Coffee, den ihr in den Shownotes
findet. Ansonsten, ich hoffe euch hat
diese etwas andere, wahrscheinlich auch mehr
gesprächige Folge gefallen. Wie gesagt, hier ein bisschen
anderes Setup. Das nächste Mal dann
wahrscheinlich wieder im gewohnten Remote Format.
Ich glaube nicht, dass der Malte jetzt alle 2 Wochen nach München
reist oder ich alle 2 Wochen nach Essen Reise, soweit sind
wir noch nicht, aber ihr habt schon gehört, den To do
Developer Podcast, den gibt es alle 2 Wochen erscheint jeden
zweiten Montag eine neue Folge, seid also auch beim nächsten Mal
wieder mit dabei und ja gebt uns Feedback, gebt uns Sterne, wir
freuen uns über Kaffee und ansonsten hören wir uns in 2
Wochen wieder. Bis dahin.
Bei viel Code. Ciao ciao.