Engineering Kiosk Episode #53 Cloud / NoCode/ AI / ChatGPT ersetzen unsere Jobs?

#53 Cloud / NoCode/ AI / ChatGPT ersetzen unsere Jobs?

Diese Episode in deiner Podcast-App hören...

Shownotes / Worum geht's?

Werden Software-Engineers sich selbst durch neue Entwicklungen arbeitslos machen?

Jedes Jahr wird eine neue Sau durchs Dorf (aka Internet) getrieben. Wenn das passiert, heißt es wieder "X wird unsere Jobs ersetzen". Doch ist das wirklich so? In dieser Episode schauen wir uns drei dieser Thesen an, die wir in den letzten Jahren gehört haben:

1. "Die Cloud wird die Jobs von System-Administratoren ersetzen"

2. "No-Code / Low-Code tools werden den Jobs des Software-Entwicklers ersetzen"

3. "AI / ChatGPT wird unsere Jobs ersetzen"

und besprechen, wie denn die Realität aussieht, ob die Thesen wahr sind bzw. wahr werden oder ob doch alles beim alten bleibt.

Bonus: Warum Wolfgang ein Fan von Holz-Clogs ist und was Plasmaschneider in der Schmiede zu suchen haben.

Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners

 

Sprungmarken

(00:00:00) Intro

(00:00:54) Ein volles Jahr Engineering Kiosk: Start der Staffel 2

(00:02:44) Heutiges Thema: 3 Thesen über die Zukunft des Job als Software-Entwickler

(00:04:12) These "Die Cloud wird die Jobs von System-Administratoren ersetzen"

(00:20:08) These "No-Code / Low-Code tools werden den Jobs des Software-Entwicklers ersetzen"

(00:40:11) These "AI / ChatGPT wird unsere Jobs ersetzen"

(01:01:41) Zusammenfassung (Too long; didn't read)

Hosts

Feedback (gerne auch als Voice Message)

 

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Wolfi Gassler (00:00:04 - 00:00:58) Teilen

Wer nicht mit der Zeit geht, geht mit der Zeit. Aber was ist, wenn die Zeit uns ersetzt? Und damit willkommen zu einer neuen Episode vom Engineering Kiosk, in der wir uns fragen, ob unsere Arbeit bald noch benötigt wird. Oder übernehmen die Cloud, NoCodeTools und die künstliche Intelligenz unsere Jobs? Wir versuchen uns der Antwort über die Vergangenheit zu nähern. Denn es ist nicht das erste Mal, dass unsere Jobs durch Technologie ersetzt werden sollen. Aber sind die Szenarien dann überhaupt vergleichbar? Oder muss man jetzt automatisch zum Data Scientist werden, um nicht den Anschluss zu verlieren? Finde das heraus! Ah, und übrigens, wenn Themen wie GitHubs neue künstliche Intelligenz namens Copilot zu modern sind, keine Sorge, wir reden in dieser Episode auch über alte Schmiedekunst, Schuster und Bohrmaschinen. Andi, ist dir bewusst, die wievielte Episode wir gerade machen? Was ist die Nummer?

Andy Grunwald (00:00:58 - 00:01:06) Teilen

Ich glaube, das müsste Episode 53 sein. Jetzt ist die Frage, Programmierer fangen bei Null an zu zählen.

Wolfi Gassler (00:01:06 - 00:01:35) Teilen

Ja, das hat die Luise, eine Hörerin, schon auf Twitter bekrittelt, dass wir die nicht mitzählen, aber das ist die Null. Die zählen wir ausmaßweise mal nicht mit, obwohl wir Informatiker sind. Und zwar haben wir die 53. Episode, was bedeutet, wir haben jetzt Ein Jahr Engineering Kiosk hinter uns, 52 Episoden und damit sind wir jetzt in der ersten Episode der quasi zweiten Staffel. Wenn man in TV-Serien Jargon sprechen würde, sind wir jetzt in der zweiten Staffel nach einem Jahr Engineering Kiosk. Geht's weiter.

Andy Grunwald (00:01:35 - 00:01:39) Teilen

Warum ist unser Jahr verschoben? Warum ist unser Jahr nicht eins zu eins das Kalenderjahr?

Wolfi Gassler (00:01:39 - 00:01:52) Teilen

Ja, weil wir auch später angefangen haben. Das ist so wie mit dem Fiskaljahr bei den ganzen Firmen. Wir machen einfach unser eigenes Jahr. Wir haben unseren Engineering Kiosk hier, der startet irgendwo so in der zweiten Januar, damit es alle verstehen.

Andy Grunwald (00:01:52 - 00:02:20) Teilen

Moment, wo habe ich den Rechenfehler? Der 3. Januar war das Datum unserer ersten Episode, was Kalenderwoche 1 ist im Jahr 2022. Wir sind jetzt bei Episode 53, sind aber schon in Woche zwei im Jahr 23. Wo ist der Rechenfehler jetzt hier? Wieso ist die Episode 53 in der zweiten Kalenderwoche des Folgejahres?

Wolfi Gassler (00:02:20 - 00:02:37) Teilen

Das sind Details, die interessieren doch niemanden. Wir lassen das ... Ein Professor von mir hat immer gesagt, it's left to the audience as a homework. Wir machen das jetzt auch so mit unseren Hörerinnen. Falls ihr wisst, wo dieser Rechenfehler ist, bitte sagt uns Bescheid.

Andy Grunwald (00:02:37 - 00:02:40) Teilen

Das ist der klassische Off-By-One-Error, oder, bei Programmierern?

Wolfi Gassler (00:02:40 - 00:03:00) Teilen

Und dabei haben wir eine Episode 0 auch noch. Es wird wirklich kompliziert. Okay, aber wir haben auf jeden Fall den Anlass genommen, von der zweiten Staffel, von dem Start in die zweite Staffel, mal ein bisschen in die Zukunft zu blicken und vielleicht auch in die Vergangenheit. Und zwar wollen wir uns mit drei Thesen besprechen, die man ganz oft, gerade in jüngster Zeit, hört.

Andy Grunwald (00:03:00 - 00:03:12) Teilen

Welche drei Thesen sind das? Bitcoin steigt über 50.000 Dollar, Elon Musk bleibt CEO von Twitter und VW schafft es wieder an die Spitze von der deutschen Automobilindustrie oder?

Wolfi Gassler (00:03:12 - 00:03:59) Teilen

Die Automobilindustrie ist sowieso tot, aber das ist wieder ein anderes Thema. Das erkläre dir mal, wenn du dein erstes Lastenfahrrad dann fährst. Aber wir zoomen noch mehr raus und zwar wollen wir uns beschäftigen eigentlich mit den drei Thesen oder Aussagen, die man ganz oft in unserer Industrie hört, einer etwas älteren. Und zwar die Cloud wird alle Admin-Jobs vernichten und ersetzen. Dann was wir so im letzten Jahr, Anfang des Jahres ganz oft gehört haben, ist diese ganze No-Code-Tool-Welle. Die No-Code-Tools oder Low-Code-Tools, die werden unseren Job ersetzen. Es braucht keine Entwickler mehr. Und jetzt ganz, ganz jung, die letzte große These oder Message, die man ganz oft gelesen hat, Chat-GPT wird unseren Job ersetzen. Es braucht also in Zukunft keine Admins und keine Developer mehr.

Andy Grunwald (00:03:59 - 00:04:11) Teilen

Ja gut, da wird halt wieder eine Sau durchs Dorf getrieben, wie jedes Jahr. Und ich habe das Gefühl, 2023 wird das nicht besser, weil irgendwie kommt mir das so vor, wir brauchen jedes Jahr irgendeine Sau, die durchs Internet getrieben wird.

Wolfi Gassler (00:04:12 - 00:04:24) Teilen

Bleiben wir mal bei der ersten Sau, die armen Schweine übrigens, dass die Cloud unsere Admin-Jobs vernichtet. Andi, da bist ja du daheim in dieser Cloud und in dieser DevOps-Szene.

Andy Grunwald (00:04:24 - 00:04:27) Teilen

Wann kam die These das erste Mal auf? Wann hast du das erste Mal gehört?

Wolfi Gassler (00:04:27 - 00:04:50) Teilen

Ja, das wird schon eher so 2016, 2017. 18 zu gewesen sein, aber ich habe es auch kürzlich wieder gehört, gerade von einem Kollegen, vielleicht vor einem guten Jahr, der in einem größeren Konzern arbeitet, der hat auch gemeint, also wenn das alles funktioniert, was uns da jetzt so präsentiert worden sind, dann werden wir keine Admins mehr haben bald. Die haben glaube ich immer noch Admins, wenn mich nicht alles täuscht.

Andy Grunwald (00:04:50 - 00:05:06) Teilen

Du stellst es jetzt so dar, als ist das voll alt und gar nicht mehr aktuell, aber ich habe eher das Gefühl, dass die Hyperscaler, also Google, Microsoft und Amazon, AWS, Entschuldigung, Amazon und AWS sind ja zwei verschiedene Firmen, Amazon ist das Retailgeschäft, AWS ist der Cloud Provider.

Wolfi Gassler (00:05:06 - 00:05:09) Teilen

Das eine macht die kohle das andere den verlust ja.

Andy Grunwald (00:05:09 - 00:05:41) Teilen

Dass deren marketing maschinerie einfach noch immer unglaublich gut läuft weil ich habe nämlich das gefühl dass die these die cloud wird unsere admin jobs ersetzen immer sich noch sehr sehr hartnäckig hält in den ganzen köpfen der CEOs vielleicht neue CTOs, Vielleicht wird das alles jetzt grad ein bisschen anders verpackt mit Serverless und allem drum und dran, aber ich hab das Gefühl, so wie du das darstellst, das ist ja alter Hut von, das ist ja alter Kram von gestern. Ich hab das Gefühl, das ist noch top aktuell.

Wolfi Gassler (00:05:41 - 00:05:47) Teilen

Ja, glaubst du, dass die DSE dann irgendwann wahr wird? Dass durch Cloud keine Admins mehr benötigt werden?

Andy Grunwald (00:05:47 - 00:06:30) Teilen

Ich glaube einfach, dass das, dass die These einfach nur unglaublich gute Sales-Taktik ist, weil du triffst halt genau den Nerv von der Geschäftsführung. Kosten einsparen, weil Systemadministrator und die IT, das ist ja immer ein Problem, ja? Du hast ja ganz viele teure Fachkräfte da und immer wenn du was von denen möchtest, sagen die, geht nicht, dauert viel zu lange, möchtest du nicht bezahlen. Das bedeutet, die, die Grundeinstimmung von den meisten IT-Lern- und Admins gegenüber irgendwelchen Fragen und Anforderungen der Geschäftsführung ist ja erstmal tendenziell negativ. Und jetzt stell dir vor, jetzt kommt dann der Heilsbringer, ja, in einem Anzug, Amazon, um die Ecke und sagt, hör mal, pass mal auf, du gibst mir einfach vier Millionen im Jahr und dafür kannst du deine ganze Admin-Abteilung löschen, löschen.

Wolfi Gassler (00:06:30 - 00:06:35) Teilen

Du kannst die Admin-Abteilung löschen, Vom Balance-Sheet zumindest löschen.

Andy Grunwald (00:06:35 - 00:06:44) Teilen

Vom Balance-Sheet? Und du brauchst keine Admin mehr, keine Admins mehr, weil das ist ja alles Self-Service, Serverless und wir machen das für dich.

Wolfi Gassler (00:06:44 - 00:06:46) Teilen

Hast du das schon mal erlebt in der Realität?

Andy Grunwald (00:06:46 - 00:06:48) Teilen

Ach, um Gottes Willen, Hammer.

Wolfi Gassler (00:06:48 - 00:07:05) Teilen

Aber vielleicht anders gefragt, hast du es mal erlebt, dass die Cloud bei dem Admin-Team schlussendlich Einsparungen ermöglicht hat, also rein auf der Personalseite? Oder noch konkreter, glaubst du, wenn du ein Team hast von zehn Admins und du gehst in die Cloud, dass du dann weniger als zehn Leute benötigst?

Andy Grunwald (00:07:06 - 00:08:16) Teilen

Wenn wir mal die genaue Anzahl von Admins ausblenden, du hast ein jetziges Team von einer Größe und du gehst dann in die Cloud? Nein, ich denke nicht, dass du Einsperrungen machst. Ich denke, dass sich der Job dieser Admins einfach nur 100 Prozent ändert. Und zwar weg von On-Premise, weg von Hardwarebestellung, weg von ich wracke jetzt irgendwie Server oder neue Festplatten, hin zu ich konfiguriere mehr, kümmere mich möglichst mehr um die Essentials, um Security, um Key-Rotation, Zugriffsrechte und allem drum und dran also irgendjemand muss den kram ja auch maintain und ich frage mich halt wie diese pre-sales leute von den großen hyperscalern wenn die in so ein gespräch gehen mit einem mit einer geschäftsführung und die haben dann mal pech und da sitzt ein technisch versierter abteilungsleiter oder technisch versierte abteilungsleiterin oder irgendjemand halt davon von deine ahnung hat, der von Tuten und Blasen halt mal irgendwie Ahnung hat, ja, und dann halt mal so eine Frage stellt, ja, aber gut, aber wer macht denn dann jetzt hier die Zugriffsberechtigung und was sagen die denn diese Pre-Sales-Leute dann da? Also das ist doch eigentlich ein Totschlagargument, oder? Sagen die dann, du brauchst weniger Admins oder das können jetzt alles die Entwickler?

Wolfi Gassler (00:08:16 - 00:08:20) Teilen

Damals war die Sales-Bitch eigentlich so, dass die Entwickler dann das alles selber können.

Andy Grunwald (00:08:20 - 00:08:23) Teilen

Der Sales Bitch oder die Sales Bitch?

Wolfi Gassler (00:08:23 - 00:09:32) Teilen

Ja liegt wahrscheinlich nahe beieinander, aber hat sich zumindest dann immer herausgestellt, dass das eher falsch war und dass man eben die richtigen Leute trotzdem noch braucht. Aber du hast vollkommen recht, ich glaube auch das Jobprofil ändert sich sehr stark, weil du machst einfach weniger auf den tieferen Ebenen, Netzwerkebenen und so weiter. Aber es braucht immer noch die Leute, die sich um das Ganze kümmern. Also was ich mir eher vorstellen könnte, ist, dass man sich ein Team einsparen kann, das sich vielleicht um gewisse Softwareaspekte gekümmert hat. Also diese Admins, die dann vielleicht Software verwalten und, wie wir in der letzten Episode gesehen haben, irgendwie ein RabbitMQ am Laufen hält. Wenn man da vielleicht dann auf die eine oder andere Infrastructure as a Service, SQS oder sowas aufbaut, könnte mir vorstellen, dass man da unter Umständen vielleicht irgendwo einsparen kann. Aber am Ende müssen dann auch die Developers vielleicht mehr machen und dann haben die weniger Zeit für andere Dinge. Also ob man dann unterm Strich viel weniger Personal braucht, das wage ich auch zu bezweifeln. Also ich glaube, diese These hat sich, glaube ich, mittlerweile erledigt. Das ist vielleicht noch in großen Konzernen ein Thema, aber ich glaube, dass man da wirklich viel Personal einsparen kann. Ich hoffe mal, dass sich diese These eigentlich erledigt hat.

Andy Grunwald (00:09:32 - 00:09:37) Teilen

Also du redest jetzt wirklich von Leuten, die dann jetzt einen Message-Q-Broker installieren oder was?

Wolfi Gassler (00:09:37 - 00:09:48) Teilen

Und am Laufen halten. Ja, also die, die die Sachen machen, die vielleicht ein Managed Service dann erledigen würde. Aber eben, ob das am Ende so viel Personal ausmacht, ist eine andere Sache.

Andy Grunwald (00:09:48 - 00:10:10) Teilen

Ja, aber viele Sachen nimmt der Managed Service ja gar nicht ab. Der Managed Service nimmt dir ab, dass du das Ding neu startest, aber um Backups musst du dich selbst kümmern, um Zugriffsberechtigung musst du dich selbst kümmern, um Monitoring musst du dich selbst kümmern, ja? Also das bedeutet, die Installation und das Lustige ist ja, je nachdem wie du es betreibst, klar, wenn du einen Managed Service nimmst, dann musst du es nicht installieren, du musst es nicht neu starten.

Wolfi Gassler (00:10:10 - 00:10:13) Teilen

Und nicht updaten. Updaten ist mal schon eine große Sache.

Andy Grunwald (00:10:14 - 00:10:18) Teilen

Das stimmt nur halbwegs, weil ... Sag.

Wolfi Gassler (00:10:18 - 00:10:24) Teilen

Mal, weiß dein Arbeitgeber, dass du da so über Hosted Services rentest?

Andy Grunwald (00:10:24 - 00:10:57) Teilen

Nein, ich rente nicht über Hosted Services, ich rente auch nicht über Managed Service, ich sag nur, ich frag nur nach konkreten Beispielen. Weil Updates, ja du hast ein Maintenance Window und ja gegebenenfalls musst du das Update nicht planen und selbst ausführen, das stimmt schon, aber der Punkt ist bei vielen Managed Services ist dein Service während des Updates auch nicht verfügbar. Das bedeutet das Heavy Lifting eigentlich, dass du während des Formel 1 Rennens die die Reifen austauscht, das ist ja immer noch da und das ist ja meist kleinseitig und nicht serverseitig.

Wolfi Gassler (00:10:57 - 00:11:17) Teilen

Aber du hast vielleicht einen Partner wenigstens an der Hand, der dir da auch beisteht und vielleicht Unterstützung gibt. Also du machst schon eine gewisse Auslagerung, wo du sonst vielleicht einen Spezialisten bräuchtest, einen mehr, wenn du ganz viele Services hast. Aber im Endeffekt eben, ob dir bei einem 10-Mann-Team da jetzt zwei Personen einspart, kann ich mir fast nicht vorstellen.

Andy Grunwald (00:11:17 - 00:12:39) Teilen

Also finanziell ist halt ne ganz andere Liga, weil auf deiner Bilanz schreibst du es anders ab, als wenn du jetzt eigene Kosten als Server kaufst und so weiter, wirklich hier Asset aufbaust oder wirklich nur monatlich irgendwelche Server mietest, das ist natürlich was ganz anderes, das stimmt schon. Aber im Endeffekt hast du da schon recht. Der Job deiner Systemadministratoren, oder wie es neudeutsch heißt, System Engineers, oder Site Reliability Engineers, oder DevOps, oder der nächste Titel, der bald durchs Internet getrieben wird, der ändert sich. Und da muss man sich natürlich auch fragen, wollen die das? Weil ich hatte mal einen Kollegen, der hatte sehr viel Expertise im Netzwerkbereich. Und speziell in der Switch-Konfiguration, in dem Switch-Aufbau und Firewalls und whatnot. Und dann auch mit Kabel ziehen und ... Was weiß der Geier nicht, ja? Also wirklich so Co-Location-On-Premise-Data-Center. Und dann kam die Meldung, okay, wir arbeiten daran, unsere On-Premise-Data-Center zu schließen, und wir gehen mehr und mehr in die Cloud. Und da hat er für sich entschieden, hör mal du, pass mal auf, das ist nicht meine Welt, ich möchte das nicht. Und dann hat die Person gekündigt. Und die Person ist dann zu einem Co-Location-Betreiber gegangen. Also wirklich on-premise, jemand, der eine kleine Firma, die kleine Datacenter für andere Firmen managt. Und da hat die Person dann weiter Switch-Konfiguration, Kabel ziehen und Firewalls und so weiter gemacht. Klar, all so was macht man natürlich auch in der Cloud, nur auf einem anderen Level halt.

Wolfi Gassler (00:12:39 - 00:13:43) Teilen

Was man sich natürlich schon fragen könnte, ist, wenn jetzt diese ganzen Admins nach einem Cloud-Move zum Beispiel einen anderen Job haben, dass sie sich mehr um Security kümmern, um Benutzermanagement und so weiter. Das müssten sie ja auch, wenn man jetzt On-Prem oder eigene Lösungen betreibt, machen. Das heißt, die Frage ist halt, wenn ich jetzt ein Team von zehn Leuten habe, könnte ich den ganzen Workload mit meinen zehn Leuten auch in Zukunft noch Herr werden, wenn ich mir auch um die ganzen Security-Sachen kümmern müsste. Also vielleicht müsste ich in der Zukunft mein Team aufstocken, damit ich dasselbe noch machen könnte. Und wenn ich jetzt vielleicht auf Cloud umsteige, gewisse Software-as-a-Service verwende, dann kann ich vielleicht die Teamgröße halten. Also von dem Aspekt könnte man dann vielleicht sagen, okay, meine Leute konzentrieren sich auf die essentiellen Sachen wie Security oder andere Themen oder den Betrieb von der Software. Aber wenn ich dann die Server und so weiter auch noch selber machen müsste oder manche Services betreiben müsste, updaten müsste, dann müsste vielleicht aufstocken. Also von der Warte her könnt ihr mir schon vorstellen, dass es Einsparungspotenzial gibt.

Andy Grunwald (00:13:43 - 00:15:11) Teilen

Ich glaube du vernachlässigt einen wichtigen Punkt und zwar redest du jetzt gerade nur über die Einsparung von Mannstärken und eigentlich um die Verschiebung von Geld, nämlich von dem kaufen von servants in die tasche von einem cloud provider und ich glaube die originale these dass die cloud unsere admin jobs ersetzen wird ich glaube die wurde widerlegt das ist korrekt der punkt ist aber du reduzierst ja die time to market und die die kapazitäten und die die, die Fähigkeiten von den Admins, die vorher Server gerackt haben und allem drum und dran, die gehen halt jetzt unter anderem in den Bau von Plattformen, um die Entwickler und andere Mitarbeiter und Data Scientists mehr zu enablen. Das bedeutet, sie kommen schneller zu ihrem Ziel, wo sie vorher einfach nur ein Ticket im Jira gemacht haben und dann die ganze Zeit gesagt haben, ja, pass mal auf, ich bin geblockt, weil das Admin-Team mir noch nicht eine DNS-Zone eingerichtet hat oder was weiß der Geier nicht. Also da ist ja schon ein Improvement, der Punkt ist aber auch, die ursprüngliche These, dass die Cloud unsere Adminjobs ersetzen wird, ist glaube ich inzwischen widerlegt, beziehungsweise für die Leute, die noch nicht auf den Zweig gekommen sind und jetzt bald in die Cloud migrieren, schöne Grüße an den deutschen Mittelstand. Die werden es halt noch lernen. Also ich mich aber auch frage in der ganzen Hinsicht, okay, wenn sich jetzt das ganze Wissen vom Servermanagement und Serverkaufen und so weiter alles auf die Hyperscaler konsolidiert, ob das nicht eine Gefahr für alle anderen Firmen sind. Aber das ist dann ...

Wolfi Gassler (00:15:11 - 00:16:18) Teilen

Das ist ja auch immer eine Argumentation, die gerne gebracht wird, gegen Cloud natürlich. Und ich möchte jetzt gar nicht sagen, dass Cloud die einzige wahre Lösung ist und wir haben ja auch in Episode 43 viel darüber gesprochen, wo wir über Cloud versus On-Premise gesprochen haben, dass Cloud auch durchaus wesentlich teurer sein kann und dass es auch finanziell Sinn macht, unter Umständen On-Prem zu machen und selbst Hardware zu kaufen. Aber bezüglich des Wissens, das abfließt, ist halt meine Meinung immer noch, erstens gibt es ganz viele lokale, kleinere Cloud-Anbieter, die immer mehr den großen auch Konkurrenz machen. Hetzner, ich würde jetzt sagen, ist jetzt nicht mehr klein in Deutschland, ist, glaube ich, eine der größten in Europa. Aber es gibt schon kleinere natürlich auch. Es gibt die Co-Locations, die auch viele viel anbieten, dass die Hardware für dich zum Beispiel kaufen, dass du die mieten kannst, die für dich racken. also da gibt schon auch viele möglichkeiten es gibt kleinere firmen die netzwerke aufbauen in firmen in firmen hast du immer noch diese ganzen netzwerke switches du wirst immer in einem büro das ganze haben also das wird sich nicht komplett auflösen auch mit mit 5g nicht ist das.

Andy Grunwald (00:16:18 - 00:16:47) Teilen

So im remote setup also ich habe jetzt hier kein switch ich habe eine fritz box hier am start, Ja, und remote first und allem drum und dran. Die neuste Stackoverflow-Entwicklerumfrage hat nämlich eigentlich gezeigt, dass doch schon in der Regel 50 Prozent der Teilnehmer dieser Umfrage halt remote arbeiten. Also jetzt ist die Frage, wie wird sich das weiterentwickeln? Ich will nicht sagen, dass wir keine Büros mehr haben, um Gottes willen. Ist noch alles sinnvoll.

Wolfi Gassler (00:16:47 - 00:17:52) Teilen

Aber eben das ist, das ist alles hybrid. Du hast, du hast dann trotzdem noch ein Büro. Du hast auch die ganzen Telekommunikationsanbieter, die lokalen, auch wenn du jetzt 5G hast, du hast ja dann Dot-Router. Du brauchst Leute, die die ganzen Masten verkabeln, die Dot-Routing machen. Also dass dir dieses Wissen abfließt und nur mehr im Silicon Valley im Google Headquarters sitzt, an das glaube ich einfach nicht, weil du brauchst es lokal noch und sogar wenn das so ist, wenn du das Wissen lokal nicht mehr brauchst, dann ist die Frage, warum kannst du nicht abwandern? Also ich denke mir auch, ich persönlich vermisse jetzt keinen Schuster in meiner Umgebung, der mir meine Plastiktonschuhe eh nicht reparieren kann. Und ich weine jetzt auch nicht den alten Holzschuhen nach, auch wenn sie cool sind natürlich und irgendwie stylische Glocks zu haben. Macht auch viel her, aber das ist halt dann irgendeine spezielle Nische. Aber im Alltag brauche ich jetzt keinen Schuster mehr. Und wenn sich das zeigt, dass das nicht mehr benötigt wird, dann finde ich es auch okay, dass das Wissen in irgendeiner Form abfließt, weil Assembler-Programmierer findest du auch eher weniger, obwohl Assembler durchaus noch vielleicht irgendwo Sinn macht.

Andy Grunwald (00:17:52 - 00:18:19) Teilen

Jetzt, wo ich ein bisschen gerade drüber nachdenke, höre ich mich an, wie gerade die Mittelstandslobby in der deutschen Politik so nach dem Motto, wir müssen aufpassen, dass das ganze Fachwissen nicht abwandert. Auf der anderen Seite bin ich halt eher dafür, okay, der Wettbewerb ist halt einfach ziemlich gut, ja, Amazon und Google und Microsoft, die machen ja die ganze Sache ziemlich gut, ansonsten hätten sie ja nicht so einen Erfolg, deswegen sage ich, sei denen gegönnt und ja gut, dann, wie Stromberg schon sagte, wer nicht mit der Zeit geht, geht mit der Zeit.

Wolfi Gassler (00:18:19 - 00:18:49) Teilen

Ne. Und weil du gerade den Mittelstand erwähnst, ganz viel ist natürlich auch produzierendes Gewerbe, muss man auch dazu sagen. Und da hast du einfach lokale Hardware, da brauchst du noch Verkabelung dort. Also dass mal in Zukunft alle Maschinen mit 5G funktionieren oder 10G dann vielleicht, kann schon sein, aber es wird schon eine Zeit brauchen. Also aktuell bist du einfach noch gerade im produzierenden Gewerbe, willst du vielleicht die Datenbank nahe an deiner Maschine sitzen haben und nicht irgendwo in der Cloud, wo noch fünf Stationen dazwischen sind, die sterben können.

Andy Grunwald (00:18:49 - 00:19:40) Teilen

Summa summarum wird die Cloud unsere Admin-Jobs ersetzen? Die Antwort ist nein. Die Admin-Jobs, die klassischen Admin-Jobs werden sich ändern bzw. der Fachbereich wird sich ändern. Vielleicht nicht für jeden Systemadministrator, Aber für die Leute, die bisher eigene Server gereckt haben und dann die Infrastruktur bald in der Cloud maintainen, für die wird sich das täglich Brot ein bisschen ändern, weil auch der Fokus ein anderer liegt. Und zwar auf Hochverfügbarkeit und allem drum und dran. Es gibt natürlich immer noch Spezialanwendungsfälle. Ich habe da jetzt gerade so High-Performance-Computing im Sinn. Da gibt es auch in der Cloud spezielle Bereiche für, aber für Leute, die dieses auf hochprofessionellem Level betreiben, ich denke gerade so an Wetterkalkulationen und Co., weiß ich jetzt nicht, inwieweit diese in die Cloud verschoben werden. Würde mich aber auch mal interessieren.

Wolfi Gassler (00:19:40 - 00:19:51) Teilen

Passiert glaube ich immer mehr, auch mit den ganzen GPUs und so weiter, kann ich mir vorstellen, dass das auch immer mehr in die Cloud wandert, weil es einfach doch echt teuer ist, selber einen super Computer zu hosten.

Andy Grunwald (00:19:51 - 00:20:00) Teilen

Also falls jemand von euch einen Blick in die Wetterkalkulation hat, meldet euch doch mal bei uns. Ich hätte da mal Lust drauf, mal das ein oder andere Käffchen zu trinken.

Wolfi Gassler (00:20:01 - 00:20:08) Teilen

Und wir sind auch gerade in der Überlegungsphase, vielleicht mal auch Leute zu interviewen in naher Zukunft. Also die Wetterbranche, meldet euch.

Andy Grunwald (00:20:08 - 00:20:24) Teilen

Von der zweiten These, die du mir hier vorgesetzt hast, habe ich gar keine Ahnung. Und zwar geht es irgendwie um No-Code und Low-Code-Tools. Und die These ist, No-Code-Tools werden unsere Jobs entsetzen. Und mit unseren meinst du dann den von Softwareentwicklern?

Wolfi Gassler (00:20:25 - 00:20:32) Teilen

Primär würde ich mal sagen von Entwicklern. Hast du die These schon mal gehört oder irgendwie, wie die so aufgekommen sind in den letzten, ich würde mal sagen, zwei Jahren?

Andy Grunwald (00:20:32 - 00:21:04) Teilen

Ja, 100 Prozent. Also die ist halt wieder diese Sau, die dann, ja, die Cloud-These wurde 2016, 2017, 2018 durchs Dorf getragen. Ich würde mal sagen, die No-Code-Geschichte habe ich das erste Mal. Ja, auch 2018, 2019, 2020 irgendwie so in dem Spektrum mal gehört. Und ich muss zugeben, ich hab seitdem, glaub ich, noch kein richtiges No-Code-Tool oder Low-Code-Tool wirklich eingesetzt. Oder, schau mal, was ist das genau? Ist IFTTT No-Code- oder Low-Code-Tool? Also, if this, then that?

Wolfi Gassler (00:21:04 - 00:21:16) Teilen

Im weitesten Sinne wahrscheinlich schon, ja. Könnte man schon so sehen. Ich glaube, du hast sehr wohl schon No-Code, Low-Code-Tools eingesetzt, weil du hast sicher schon mal Airtable oder so in irgendeiner Form benutzt zumindestens.

Andy Grunwald (00:21:16 - 00:21:19) Teilen

Ich habe Google Forms genutzt. Ist das auch ein Low-Code-Tool?

Wolfi Gassler (00:21:19 - 00:21:34) Teilen

Könnte man auch so sehen, klar. Gehört auch dazu. Also das ist ja auch die Frage, was ist eigentlich No-Code, Low-Code? Das ist halt wieder so ein Buzzword, was so entstanden ist in letzter Zeit. Und es erinnert mich sehr stark an die vierte Generation der Programmiersprachen. Sagt dir das was?

Andy Grunwald (00:21:35 - 00:21:39) Teilen

Nee, aber wenn ich dich so reden höre, frage ich mich, bei welcher Generation sind wir gerade?

Wolfi Gassler (00:21:39 - 00:21:55) Teilen

Bei der dritten. Hä? Also ich bin ja alt genug, dass ich das, ja ich bin nicht ganz so alt, aber ich habe so am Rande noch miterlebt das Ganze oder eigentlich wie ich ganz jung war, habe ich das schon so miterlebt. Ich weiß nicht, sagt dir FileMaker zufällig was?

Andy Grunwald (00:21:55 - 00:21:56) Teilen

Ist das ein Dateibrowser?

Wolfi Gassler (00:21:57 - 00:23:20) Teilen

Okay, du bist also wirklich zu jung. Das kommt so aus den 80er, 90er Jahren, würde ich sagen. Da war das noch recht in. Und das ist ein Vertreter von dieser vierten Generation der Programmiersprachen. Und zwar waren die damals eigentlich so der Standard, wenn es um schnelle Programmierung gegangen ist. Das war meistens so eine integrierte Datenbank mit einer UI. Und man hat dann schon recht gut mit Clicky Bunty Sachen zusammen klicken können, Formulare, die dann aus der Datenbank Sachen auslesen, eingeben können. Man hat dann natürlich auch dazu programmieren können, Programmiersprachen. Klassischer Vertreter war Gupta oder Centura, hat es später geheißen. Ich glaube, mittlerweile heißt es wieder Gupta. Wurde mal so hin und her verkauft. Ist garantiert in deinem Mittelstand sehr weit verbreitet, immer noch. Progress wäre so eine andere Variante. Habe ich gerade kürzlich wieder gehört, dass das wo eingesetzt wird. Also das sind so Packages, die einfach die Entwicklung vereinfachen, würde ich mal sagen, die alle so dir liefern. Du hast eine Oberfläche, da ist eine Datenbank integriert, du kannst das zusammenklicken und dann kannst du eine Anwendung für den Mittelstand bauen, um da irgendwie den Ablauf zu realisieren oder eine Verwaltung, ein ERP-System. So klassische Tabellenanwendungen und heutzutage muss man ja sagen, das meiste basiert halt auch auf Tabellen, ganz klar. Man könnte sogar noch weiter zurückgehen, das kennst du wahrscheinlich garantiert nicht, Hypercard.

Andy Grunwald (00:23:20 - 00:23:21) Teilen

Hört sich an wie ein Skilift.

Wolfi Gassler (00:23:22 - 00:23:59) Teilen

Das habe ich selber auch nicht mehr miterlebt. FileMaker-Applikationen habe ich noch miterlebt. Mein erster Firmenpartner, mit dem ich meine erste Firma gegründet habe, der hat noch FileMaker programmiert und hat teilweise auch FileMaker-Sachen an Kunden verkauft. Und der hat auch noch HyperCard programmiert, das habe ich aber selber nicht mehr erlebt. Das war so ein erstes Apple-Ding, wo alles in Karten realisiert war. Das heißt, jeder Eintrag war so eine Karte und du hast so wie in einem Kartei-Kartensystem dann diese Karten gehabt. was auch wieder eine Datenbank am Ende war und du hast so Logiken drüber programmieren können und war scheinbar im Firmenbereich auch durchaus üblich, da die ersten Softwareprogramme mit HyperCard zu entwickeln, um so Abläufe abzubilden und Daten zu speichern.

Andy Grunwald (00:23:59 - 00:24:23) Teilen

Du redest jetzt von wahren, wahren, wahren, also nicht vom wahren Einsatz, sondern von der Historie, dass die Dinger anscheinend nicht mehr aktuell sind, aber jetzt frage ich mich gerade, wir sind jetzt gerade hier im War of Talent und Shortage an Programmierern und so weiter und so fort. Warum gibt's die Dinger nicht mehr? Oder gibt's die Dinger noch? Warum kenn ich die nicht und warum werden darauf noch nicht neue Startups gebaut?

Wolfi Gassler (00:24:24 - 00:26:08) Teilen

Also die gibt's teilweise schon noch. Und gerade im Mittelstandbereich, alte Software gibt's da sicher noch viel. Wie weit die jetzt ... Also die existieren noch alle, die Firmen. Wie aktiv die jetzt noch sind, kann ich schwer einschätzen, ehrlich gesagt. Und vielleicht noch zur Erklärung, warum vierte Generation, wenn jetzt die dritte Generation Java, Python und so weiter ist. Das war auch so ein bisschen so ein Marketing-Gag, dass man gesagt hat, okay, die Programmiersprachen, die klassischen sind dritte Generation und mit der vierten Generation heben wir das jetzt auf ein neues Level und die Programmierung wird in Zukunft so aussehen, dass man eben diese integrierten Systeme hat, wo die Datenbank schon dabei ist, wo alles integriert ist, viel einfacher entwickelt werden kann, die Oberflächen und alles schon out of the box kommt. Und wenn man sich das so anhört, das klingt genau so wie Low-Code und No-Code-Tools. Und wenn man Airtable anschaut, das ist eine große Tabelle, in die man viele Sachen reinpacken kann, Bilder, komplexere Datentypen, aber alles basiert auf dieser Tabelle, die dann verknüpfe, verschnittstellen mit anderen Tools. Dann erinnert mich das sehr an HyperCard von Apple, das irgendwann in den 70ern oder so entwickelt wurde, weil da war halt alles eine Karte und da wir ein Bild reinhängen können, viele Felder und das ist eigentlich dasselbe wie R-Table am Ende. Der einzige Unterschied ist jetzt vielleicht mit No-Code, Low-Code, dass viel mehr in die Richtung Schnittstellen geht. Das heißt, ich kann diese Tools verknüpfen mit externen Tools, mit anderen Tools. Ich habe meine R-Table als Datenbank und dann habe ich für die Oberfläche wieder irgendeinen Formular-Generator oder so und verknüpfe das über APIs. Hingegen früher wie FileMaker war das halt ein Tool von derselben Firma, was die Datenbank geliefert hat, den Report-Generator, den UI-Generator, die Forms. Das war alles in einem System.

Andy Grunwald (00:26:08 - 00:26:22) Teilen

Also möchtest du mir sagen, Macromedia, Dreamweaver und Microsoft Frontpage waren also vor seiner Zeit? Waren das auch schon No-Code, Low-Code-Tools? Weil da konnte ich ja auch einfach HTML-Webseiten drag-and-drop ziehen und allem drum und dran.

Wolfi Gassler (00:26:23 - 00:26:58) Teilen

Ja, das war halt dann schon für die Web-Generation. Und das vielleicht auch noch der Unterschied. Üblicherweise No-Code, Low-Code-Tools sind jetzt im Web und nicht mehr am Desktop, am Computer wie früher der FileMaker zum Beispiel. Aber die ganzen Web-Designer, die hatten ja keine Datenbank. Also die 4GL oder vierte Generation Tools, die hatten immer eigentlich eine Datenbank dabei. Also das war schon so für das Business-Umfeld gedacht, um wirklich so klassische Workflows abzubilden. wo es auch immer um die Datenspeicherung geht. Und die Low-Code-Tools haben das ja jetzt meistens auch. Da gibt es immer eine Komponente, wo du die Daten speicherst.

Andy Grunwald (00:26:58 - 00:28:11) Teilen

Jetzt komme ich aus dem Infrastrukturbereich und denke mir immer so, okay, immer wenn du von APIs redest, dann denke ich immer an Diagrammen mit irgendwelchen Boxen und irgendwelchen Pfeilen. Und immer wenn ich ein Diagramm mit ganz vielen Pfeilen sehe, sagt mein mentales Modell, da spricht eine Applikation mit einer anderen Applikation. Und jeder Pfeil ist dann ein API-Request, eine Verbindung, was weiß ich nicht. Und auf Basis der Anzahl der Feilspitzen, umso höher die ist, umso mehr Probleme haben wir. Weil jede Verbindung zusammenbrechen kann und Co. Meine Frage ist jetzt eigentlich, wenn du sagst, okay, früher gab's dann Gupta, Progress, FileMaker, HyperCard und Visual Fox Pro und was weiß ich nicht. Und das kam alles aus einer Hand. Und jetzt sagst du, der Unterschied ist, dass das damals eine Desktop-Applikation war und jetzt das alles im Web ist und dass man jetzt viel mehr über APIs quatscht. War das dann früher nicht alles besser in der Hinsicht, weil dann alles aus einer Hand kam und die sich genau um diese Reliability-Themen, dass die Verbindung zwischen einer Datenbank und einem Formular und Co. ja stabil war, weil die haben sich ja drum gekümmert und jetzt hast du irgendeinen Web-Tool, was dann sich mit einem anderen Web-Tool unterhält und da kennen die Programmierer sich wahrscheinlich noch gar nicht und das kann alles kaputt gehen?

Wolfi Gassler (00:28:11 - 00:31:14) Teilen

Ja, besser ist die Frage, wie du besser definierst. Es war auf jeden Fall einfacher, ganz klar. Aber du hattest natürlich den Nachteil, dass du einen Lock-in-Effekt hattest, weil wenn du einen Filemaker aufgesetzt hast, war alles in Filemaker. Und du konntest jetzt nicht irgendwie was anderes anschließen. Und wenn da jetzt eine hippe andere Firma gekommen ist und gesagt hat, wir haben jetzt aber einen viel besseren Formgenerator, der mit AI irgendwie automatisch deine Felder vorfüllt, dann hast du den nicht verwenden können, weil du halt nur in dem Filemaker-System arbeiten hast können. Und jetzt über die Schnittstellen hast du halt den Vorteil, dass du unabhängige Systeme miteinander vereinen kannst und nicht mehr abhängig voneinander bist. Und dadurch natürlich viel, viel flexibler arbeiten kannst, viel schneller umsteigen kannst, dass du mal die Oberfläche austauschst, dass du ein System dranhängst, was deine Data Science Tasks macht, was irgendwelche Modelle berechnet auf deinen Daten, was vielleicht irgendwie getriggert wird über Webhooks, dass irgendwelche Notifications ausgesendet werden. auf Handys, auf irgendwelche Apps, die vielleicht mit dem Originalsystem gar nichts zu tun haben. Also da hast du einfach viel mehr Möglichkeiten und kannst dadurch viel schneller Dinge realisieren, indem du die unterschiedlichen Komponenten zusammenhängst, weil du einfach viel modularer arbeiten kannst und viele verschiedene Module hast, die alle möglichst offen sind und miteinander kommunizieren können. Und diese Schnittstellen hat es in der Vergangenheit eben nicht gegeben, weil alles closed war und keiner eigentlich die Daten überhaupt freiwillig nach außen gegeben hat. Und meine Lieblingsgeschichte dazu ist über Motorola. Und zwar war das gar nicht so lange her, vor ein paar Jahren noch, wie wir eine neue Leitstelle bekommen haben, die Feuerwehr, Rettung und so weiter koordiniert, Bergrettung. Und die hatten ein Funksystem von Motorola. Und Motorola hat keine Schnittstellen angebunden, dass die das in ihr VoIP-System integrieren haben können. Also wenn die am Arbeitsplatz sitzen mit Kopfhörer und Mikrofon, dass die über dieses Funksystem interagieren können. Und was die dann am Ende gemacht haben ist, die haben eine Software geschrieben, die Mausklicks simuliert und die irgendwo auf einem Rechner in der Ecke mit der Maus dann auf diesen Sprechbutton gedrückt haben in dem Software-Client von Motorola. und die haben das dann einfach über die Audioschleife von dem Computer durchgeschliffen und so haben die realisiert, dass die auch auf einem entfernten Arbeitsplatz einfach mit diesem Funksystem sprechen konnten. Also da hat es keine Schnittstellen gegeben, auch wenn du wirklich viel Geld in die Hand nimmst und bei Motorola so ein professionelles System kaufst, was für Blaulichtorganisationen designt ist, hatten die keine Schnittstellen und haben über so schlimme Workarounds, dass die mit simulierten Mausklicks in der Oberfläche arbeiten haben müssen. Und das ist heutzutage einfach anders. Wenn du moderne Software anschaust im Web, aber auch sonst, du hast immer eine Schnittstelle. Du kannst auf die Daten zugreifen, du kannst mit anderen Systemen interagieren. Und ich glaube, da ist der große Unterschied zur Vergangenheit. Und da kommen jetzt die Low-Code, No-Code-Tools ins Spiel, die einfach probieren, möglichst modular miteinander zusammenzuarbeiten und dass du eben nicht mehr in diesen Lock-in-Effekt läufst.

Andy Grunwald (00:31:14 - 00:32:44) Teilen

Ich meine mal gelesen zu haben, damals als Jeff Bezos mit AWS gestartet ist, beziehungsweise als die ganze Sache aufgebaut wurde, gab es mal so eine Art interne Regel. Immer wenn ein neuer Service gestartet wird, soll der API first sein. Das bedeutet, man startet erst mit einer API, sodass andere Teams dann zugreifen können. Beispiel. Jeder AWS-Service hat wohl irgendwie so eine Art Schnittstelle zum Access-Management. Aber auch zum Object Storage, also zu S3, weil du kannst ja fast den Output aus jedem AWS-Tool irgendwie in den Object Storage S3 pumpen. Und das erinnert mich grad so ein bisschen daran, dass sich das vielleicht die ganze Industrie so gewendet hat, dass alles irgendwie API-first ist. Es gibt ja auch schon so Trends wie Micro-Frontends und Headless-Shop-Systeme und was weiß der Geier nicht. Und das erinnert mich halt irgendwie dann, okay, durch dieses Mantra, API first, sind halt vielleicht diese No-Code-Tools hochgekommen, weil es eigentlich ja nur eine UI auf irgendeiner API ist. So, und wenn ich den Gedanken jetzt weiterspinne, klar, ich als Softwareentwickler, irgendjemand muss ja diese APIs schreiben. Aber was heißt das denn, wenn jetzt einfach mal so 50, 60, 100 No-Code-Tools auf dem Markt sind? Kann dann der Abteilungsleiter und der CTO und der CEO oder sich da selbst zusammen klicken und ein neues Startup bauen? Brauchen die dann keine Programmierer mehr? Also er setzt No-Code. Kommen wir zurück zur These. Wirklich unser Job?

Wolfi Gassler (00:32:44 - 00:34:43) Teilen

Also, ihr habt noch keinen Developer getroffen, der wirklich extrem auf No-Code-Tools setzt. Vielleicht, um irgendwie eine Kleinigkeit mal zusammenzubauen. Aber ihr habt keinen getroffen, der voll überzeugt ist davon, weil es vielleicht auch ein Problem ist von Entwicklern, die suchen natürlich immer diese Sachen, die nicht funktionieren. Und dann sind die nie ausreichend genug. Was man sehr wohl sieht, ist, dass es viele Businessleute gibt, die ein Startup gründen, die komplett ohne technisches Wissen diese Dinge zusammen klicken mit diesen No-Code-Tools. Und das hat sich sicher geändert, dass eben auch Businessleute oder auch andere Leute mit weniger technischem Verständnis Sachen umsetzen können. Einfache Sachen umsetzen können, sogar ein Startup vielleicht, weil du bekommst die Authentifizierung, du bekommst die Datenbank mit Airtable zum Beispiel, du bekommst einen Formgenerator und kannst dir da schon recht gut Sachen zusammenklicken, die funktionieren, weil ehrlich gesagt, die meisten Programme lösen ja einen simplen Workflow, wo du eine Datenbank wieder hast, ein Formular und du zeigst dir Daten in irgendeiner Form an. Und das können sich dann Leute schon zusammenklicken. Ob das jetzt die Developer ersetzt, auch da glaube ich, dass früher oder später dann irgendwelche Developer wieder gebraucht werden, vor allem wenn es komplexer wird, wenn du Glue-Code brauchst, wenn du die Sachen verstehen willst, wenn du skalieren willst. Ab da brauchst du dann normalerweise technische Leute. Aber der Einstieg ist natürlich vielleicht leichter. Ich glaube aber nicht, dass deswegen jetzt groß Jobs ersetzt werden, sondern vielleicht Ideen einfach schneller realisiert werden und auch manche Dinge für Developer vereinfacht werden. weil die kleine Tools zusammenbauen können. Aber ich sehe jetzt eigentlich noch nicht irgendwo den Trend, dass die Entwickler nicht mehr benötigt werden, sondern sie werden vielleicht später benötigt oder in der Vergangenheit ist vielleicht eine Idee gar nicht realisiert worden, weil die Tools nicht zur Verfügung standen und die Entwickler eben auch nicht und jetzt können irgendwelche fiendigen Businessleute vielleicht die erste Idee schon mal selber zusammenklicken und den Case überprüfen, ob der überhaupt funktioniert. Also für so Startups und kleine Tools kann ich mir das sehr gut vorstellen.

Andy Grunwald (00:34:44 - 00:35:29) Teilen

Aber kennst du denn komplexe Logiken, die damit wirklich abgedeckt wurden? Oder reden wir hier wirklich nur über Grundlisten, also create, read, update, delete und mit einer anderen View obendrauf? Weil das wäre der Standardcase. Ich hab das Gefühl, die meisten Programmierer machen halt einfach Grundlisten und man hat eine Eingabemaske, man speichert was in der Datenbank und dann wird das halt irgendwie dargestellt. Das ist so ungefähr, weiß ich nicht, 80, 90 Prozent der Anwendung gefühlt. Und ist dafür jetzt no code gut oder oder kann man da wirklich knallharte business logik mit berechnungen logging authentication permission sondern also kann ich damit ohne problemen marktplatz wo sich dann leute gegeneinander überbieten und zu bauen.

Wolfi Gassler (00:35:30 - 00:35:55) Teilen

Also ich glaube, du kannst schon sehr viel bauen, aber du brauchst natürlich schon dann irgendwo dieses technische Verständnis, auch wie man so Dinge zusammenbaut. Vor allem, wenn es dann um mehr Logik geht, dann wird es schon schwieriger. Und ab da, klar, wir müssen dann schon irgendwelche Leute mit dem technischen Background, mit dem technischen Verständnis übernehmen, um das einfach zu skalieren und dann auf den, und dann eine Ebene höher zu bringen, auf den Next Level sozusagen.

Andy Grunwald (00:35:56 - 00:36:07) Teilen

Ja gut, aber dafür brauchst du ja keine Programmiererkenntnis, sondern das können ja wirklich Leute auch mit strukturiertem Denken, also Leute, die sich für Technik interessieren und so weiter, also dafür brauchst du ja jetzt kein Software Engineering.

Wolfi Gassler (00:36:08 - 00:37:55) Teilen

Also ich glaube schon, dass sich mehr Nicht-Techniker-Sachen zusammen klicken können und vielleicht selber lösen können. Und das sind ja eigentlich, wenn wir uns ehrlich sind, auch die langweiligen Themen, die Entwickler sowieso nicht machen wollen. Also ich kenne jetzt wenige Entwickler, die sagen, yeah, das 20. Login-Formular, das ich jetzt programmieren darf. Endlich wieder mal ein cooles Projekt oder das 20. Listing von irgendwelchen Daten. Also das sind ja nicht die spannenden Themen, die auf die Entwickler wirklich Lust haben. Und ich glaube, diese langweiligen Themen kann man ganz gut wegoptimieren durch No-Code-Tools, zumindest am Anfang. Wie gesagt, sobald man größer wird, ist das nicht mehr möglich. Das ist halt so, wie wenn man ein Shop-System einsetzt. Für die meisten Anwendungsfälle wird so ein simples Shop-System ausreichen, eines von der Stange. Aber wenn du natürlich ein großes Unternehmen bist und dann irgendwie 1000 Mitarbeiter hast und irgendeine spezielle Shop-Lösung brauchst, dann musst du natürlich irgendwo customizen, dann brauchst du Entwickler, die das App ändern. Aber für 80% der Anwendungsfälle funktioniert wahrscheinlich ein Shopify oder ein ganz simples Shop-System und erfüllt alle Anforderungen. Und so sehe ich das halt bei NoCodeTools auch. Und was schon cool ist, es gibt mittlerweile auch sehr viel Open Source NoCode-Tools. Also NoCodeDB ist zum Beispiel ein sehr großes und sehr leistungsstarkes Tool. Das kann man sich selber aufsetzen, mit Docker, kann einfach mal rumspielen. Und wenn man so kleines Projekt hat, kann ich mir gut vorstellen, dass Entwickler das auch gerne verwenden, weil man da einfach viel schneller ist. Oder Base Row wäre so eine Alternative auch, die ist nicht so leistungsstark, aber ermöglicht auch einiges. Und da kann man eigentlich recht schnell Dinge umsetzen und die erleichtern eben auch einem Entwickler dann vielleicht diese nervigen, lästigen, wiederholenden Tasks, die man eigentlich sowieso nicht machen will. Aber dass der Job ersetzt wird, kann ich mir eigentlich kaum vorstellen.

Andy Grunwald (00:37:55 - 00:38:12) Teilen

Wenn ich dir so zuhöre, dann hört sich das so an, okay, ich kann jetzt mit den NoCore-Tools ein neues Startup, das nächste unicorn innerhalb von von fünf minuten bauen aber so ist es ja nicht wirklich oder also ich meine man man muss sich da schon hinsetzen und ein paar tage investieren und natürlich aber.

Wolfi Gassler (00:38:12 - 00:38:44) Teilen

Es können auch nicht entwickler das ist wieder große unterschied man muss schon die tage investieren aber es können auch leute die weniger technisches verständnis haben können das jetzt schon machen ja Aber ob die früher das Geld aufgebracht hätten, um den Entwickler zu zahlen, ist halt eine andere Sache. Also ich glaube, es ermöglicht mehr, volkswirtschaftlich sozusagen. Aber ob jetzt dadurch weniger Entwickler gebraucht werden, glaube ich eben eher weniger. Sondern jeder will heutzutage Sachen umsetzen und das wird leichter. Früher hat man Entwickler dazu gebraucht, aber jetzt wird einfach mehr umgesetzt.

Andy Grunwald (00:38:45 - 00:39:31) Teilen

Gut, wenn ich jetzt so als Over-Engineering-Software-Engineer daran denke, denke ich an, kann das skalieren? Also mit skalieren meine ich mit Traffic und so weiter, weil dann legt man sich ja eigentlich komplett auf die Schultern von den verschiedenen NoCore-Tools. Was ist, wenn ich diesen einen Use-Case habe, der sich nicht dadurch abdecken lässt, der dann eigentlich meine Unique-Selling-Proposition gegenüber meiner Konkurrenz ist? Ich glaube, wenn man über solche Themen Gedanken macht, dann hat man schon seinen Anwendungsfall evaluiert und dann sollte man vielleicht auch Kapital und Zeit da investieren. Vielleicht ist das, also ist das richtig, verstehe ich das gut, dass das zur schnellen Prototyp-Evaluierung eine sinnvolle Alternative ist, anstatt einfach mal ein Programmierteam irgendwie anzuheuern?

Wolfi Gassler (00:39:31 - 00:39:58) Teilen

Genau, ich glaube, genau dafür ist es da. Und du lässt dir auch nicht ein eigenes Shop-System programmieren, wenn du mal irgendwas testweise verkaufen willst. Oder früher, wenn man irgendein Forum gebraucht hat zum Beispiel, dann hat man auch fertige Software verwendet und hat sich nicht selber ein Forum programmiert. Also man hat ja früher schon Open-Source-Software eingesetzt zum Beispiel, um Dinge nicht immer wieder selbst neu machen zu müssen. Und das ist halt jetzt ein Schritt weiter, dass das vielleicht auch nicht Techniker machen können und einfach die Bedienung einfacher wird.

Andy Grunwald (00:39:59 - 00:40:07) Teilen

Auf der einen Seite habe ich schon Bock, das jetzt auszuprobieren, auf der anderen Seite ist es halt nicht so spannend, als wenn ich das jetzt programmieren würde. Von daher, naja.

Wolfi Gassler (00:40:07 - 00:40:09) Teilen

Dafür wirst du fertig.

Andy Grunwald (00:40:09 - 00:40:45) Teilen

Ach, das will doch keiner, das will doch keiner, das weiß doch. Kommen wir zur dritten These und die ist, glaube ich, top aktuell. Und zwar geht's da um ein Thema, womit ich mich irgendwie nicht so viel identifizieren kann, muss ich zugeben. Und zwar geht's um künstliche Intelligenz, Artificial Intelligence und ganz speziell Chat-GPT von OpenAI. Und wie wir die Tage auch schon mal in einer vorherigen Podcast-Folge erwähnt hatten, um Prompt Engineering und all diese Themen. Und die These ist, AI, Chat-GPT wird unsere Jobs ersetzen.

Wolfi Gassler (00:40:46 - 00:40:50) Teilen

Vielleicht eine Frage vorab, Andi, wie oft verwendest du AI am Tag?

Andy Grunwald (00:40:50 - 00:41:13) Teilen

Stell die Frage anders. Wie oft nutze ich AI bewusst? Ah, nein, nein, nein, nein, nein. Das ist jetzt eine superinteressante Frage, weil AI ist ja wieder so ein scheiß Passwort, weil jeder macht ja AI, aber unten drunter ist es mit hoher Wahrscheinlichkeit ganz stumpfe und stupide Statistik. So. Also, ich will sagen, nur weil da AI draufsteht, bin ich sehr skeptisch, ob AI drin ist.

Wolfi Gassler (00:41:13 - 00:41:35) Teilen

Ja, AI ist natürlich ein extremes Passwort und Marketing-Term und wir können es Machine Learning nennen und Statistik ist in gewisser Weise auch Machine Learning, fällt zumindest teilweise darunter, wenn man jetzt irgendwie eine Regression oder sowas berechnet. Aber schätze mal, wie viele Tools glaubst du, dass in irgendeiner Form so Machine Learning eingebaut haben, die du jeden Tag verwendest?

Andy Grunwald (00:41:36 - 00:42:06) Teilen

Schwierige Frage, schwierige Frage. Also wo, glaube ich, schon was unten drunter steckt, ist bei einem meiner Lieblings-Services DeepL. Das nutze ich sehr viel, um Texte zu übersetzen. Ich glaube, da ist schon sehr viel drin. Ich denke, dass dieser ganze Hype und Buzzword viel mehr zu Werbezwecken genutzt wird, als dass wirklich da unten drunter was drin steckt. deswegen schwierig zu beantworten weiß ich nicht also bewusst nutze ich glaube ich nicht so viel und drunter glaube ich mehr als ich mir eingestehen möchte.

Wolfi Gassler (00:42:06 - 00:42:52) Teilen

Also ich glaube Maschinenleitung ist schon sehr verbreitet mittlerweile wie tief das natürlich jetzt geht und wie intelligent das ganze ist und wie viel eben du sagst es ist nur ganz simple Statistik oder vielleicht sogar nur fünf Statements und dann sprechen schon manche von AI und wenn die Waschmaschine AI drin hat und es sind Fünf If-Statements. Früher hat es Fuzzy Logic geheißen bei den Waschmaschinen zumindest, was im Endeffekt, glaube ich, auch nur fünf If-Statements irgendwo drin waren. Also es ist natürlich schwer, immer reinzublicken, was da im Hintergrund abläuft, aber ich glaube, es wird immer mehr der Standardfall, dass in irgendeiner Form irgendwo wenigstens was maschinell Gelerntes vielleicht irgendwo drunter steckt oder vielleicht auch am Weg irgendwo beteiligt war. Jetzt bewusst oder unbewusst ist nochmal eine andere Sache.

Andy Grunwald (00:42:53 - 00:43:39) Teilen

Das führt mich wieder zu einer ähnlichen Frage, wie wir bei der ersten These hatten. Wird Cloud jetzt die ganzen Systemadministratoren abschaffen? Und verlieren wir grad das Wissen von diesem Serverracken und so weiter und so fort? AI und KI und Chat-GPT und OpenAI und whatnot ist ja grad wieder so ein Hype-Thema, ja? Und da gehen ja superviele Leute in den Markt und wollen das lernen und so weiter und so fort. Ist ja alles super und find ich ja auch klasse, dass das Wissen mehr verteilt wird. Aber wie viele Leute weltweit kennen sich mit diesem Thema gut aus also wie viele leute können wirklich mal sagen wie chat gpt und das modell darunter und ich glaube das ist gpt 3 oder sowas wie mal gehört also wie viele leute verstehen was da vor sich geht.

Wolfi Gassler (00:43:39 - 00:43:46) Teilen

Aber das ist ja immer die die die frage verstehst du wie deine bohrmaschine im inneren funktioniert wie ein elektromotor funktioniert von der bohrmaschine.

Andy Grunwald (00:43:46 - 00:44:19) Teilen

Ja, aber wenn ich so Meldungen lese, dass innerhalb von Google irgendeine KI ist, die ein Bewusstsein entwickelt und irgendeinen Anwalt angeheuert hat. Sorry, aber so machen wir eine Bohrmaschine halt auch nicht, ne? Also, die entwickelt sich ja nicht weiter. Ich hab davon ja keine Ahnung von AI und KI. Ich find's interessant, aber ich find's nicht so interessant, als dass ich mich mit Deep Learning und moralen Netzwerken tief beschäftige. Aber ich weiß auf jeden Fall, dass meine Netzwerkmaschine, meine Bohrmaschine, kein neurales Netzwerk hat, sondern mir einfach ein scheiß Loch in die Wand bohrt.

Wolfi Gassler (00:44:19 - 00:45:53) Teilen

Aber vielleicht ist sie auch schon mittlerweile irgendwo entwickelt worden mit Daten, die man gesammelt hat, wo man vielleicht dann irgendwas rausgelesen hat. Also am Weg der Entwicklung kann das durchaus schon irgendwo mit reingeflossen sein. Aber was ich eigentlich damit sagen will, ist, dass man natürlich nicht alles verstehen muss bis ins Tiefste, nur um es zu verwenden. Und das hast du ja richtig gesagt, nur weil du DeepL verwendest und deine Texte übersetzen lässt, musst du nicht verstehen, was im Hintergrund passiert. Und das sieht man halt jetzt eigentlich überall, dass das schon überall in irgendeiner Form verwendet wird oder zumindest als Marketing-Term promoted wird, dass AI drinsteckt. Aber nehmen wir mal an, es stimmt in irgendeiner Form, dass Machine Learning irgendwo drinsteckt. dann sieht man halt auch, dass das zu einem Standard-Tool wird, was einfach mittlerweile dazugehört. Und das ist halt wichtig, dass man da den Zug nicht verpasst. Man muss halt einfach damit lernen, umzugehen und das zu verwenden, zu integrieren. Das wird halt einfach ein Standard-Tool werden, so wie die Bohrmaschine auch. Früher hat man vielleicht Löcher noch manuell gebohrt, aber heute würde niemand mehr auf die Idee kommen, Loch manuell zu bohren oder die Wäsche manuell zu waschen. Nicht mal die hartgesottenen Fans der manuellen Arbeit, die vielleicht noch das Geschirr manuell spülen. Auch die verwenden üblicherweise Waschmaschinen und ich glaube, so wird es halt mit Machine Learning in Zukunft auch sein. Es wird überall drin sein und es wird vieles erleichtern, aber wir müssen uns daran gewöhnen, dass das einfach Teil von dem Workflow wird und vielleicht auch wir gar nicht alles verstehen, wie wir die Bohrmaschine halt auch nicht verstehen, den Elektromotor.

Andy Grunwald (00:45:54 - 00:46:45) Teilen

Meines Erachtens nach hinkt ein Vergleich mit der Bohrmaschine ein bisschen so nach dem Motto, ich verstehe nicht wie eine Bohrmaschine intern funktioniert. Ich lehne mich mal weit aus dem Fenster und sage, es gibt mehr Menschen auf der Welt, die die Funktionsweise einer Bohrmaschine intern verstehen, als Chat-GPT, AI, neurale Netzwerke und so weiter und so fort. Ja und wenn wir jetzt mal an die gesellschaftlichen Effekte davon denken, dass wir eine Handvoll Leuten haben weltweit, die das verstehen, und echt viele Leute, die das Innenleben einer Bohrmaschine verstehen, dann würde ich fast sagen, fühle ich mich mit dem Verständnis einer Bohrmaschine deutlich wohler, als die Zukunft der Welt mit KI und AI und was weiß ich nicht in die Hände von einer Handvoll von Leuten zu geben, die sich dann mit dem Innenleben von neuralen Netzwerken und Chat-GPT und keine Ahnung was.

Wolfi Gassler (00:46:45 - 00:47:31) Teilen

Aber das ist dasselbe mit jeder technologischen Entwicklung. Du hattest auch in der Vergangenheit wenig Leute, die sich mit Solarpanels auskennen und das war wahrscheinlich eine Handvoll, die das Ganze verstanden hat und heutzutage kennt sich jeder Elektriker damit aus und es ist Standard geworden, dass das einfach jeder verwendet und sich viel mehr Leute damit auskennen. Also klar dauert es eine Zeit und ich würde mal nicht sagen, dass es eine Handvoll Data Scientists sind, weil es gibt schon viele Data Scientists und es wird immer wichtiger in Zukunft und so werden halt in Zukunft es auch immer mehr Leute verstehen müssen, weil es immer mehr verwendet wird und immer mehr Standard wird. Aber das heißt ja nicht, dass ich dann jeder User damit auseinandersetzen muss und ich als User das verstehen muss, wie das zustande kommt, wie DeepL meine Texte übersetzt oder wie der Copilot mir hilft, meinen Code zu schreiben.

Andy Grunwald (00:47:32 - 00:48:02) Teilen

Ja, vielleicht hast du da einen Punkt. Ich denke immer noch, dass AI und KI marketingtechnisch sehr sexy unterbreitet werden, sich aber niemals oder sehr wenig Leute mit der tiefen Mathematik und Statistik und so auseinandersetzen wollen. Und vielleicht sehe ich deswegen die ganze Sache ein bisschen skeptisch, aber ich nutze sie vielleicht jeden Tag. Kommen wir zur These, wie ist es denn jetzt? Muss ich mir Sorgen um meinen Job machen, dass AI mich bald arbeitslos macht?

Wolfi Gassler (00:48:03 - 00:50:28) Teilen

Es ist ja ganz witzig, weil in der Vergangenheit hat man sich eigentlich überlegt, dass eher so diese dummen Arbeiten ersetzt werden durch Roboter, durch mehr Intelligenz, keine Ahnung, die Müllabfuhr oder irgendwelche Paketauslieferer, LKW-Fahrer. Aber da merkt man jetzt schon, dass wir eigentlich relativ weit entfernt sind noch. Und dass eigentlich ganz andere Sachen jetzt ersetzt werden, dass eher die Knowledge Worker ersetzt werden, eben die Entwickler, die Designer. Mittlerweile kannst du dir Sachen automatisch designen lassen. Simple Apps verbessern dir deine Fotos oder schneiden Videos zusammen, die du dann auf TikTok hochladen kannst und so weiter, wo du früher wirklich Spezialisten gebraucht hast, die dir ein Video zusammenschneiden. Also es geht eigentlich vielmehr jetzt in diese Richtung, dass die klassischen Knowledge Worker Arbeiten ersetzt werden. Aber auch da wieder, aktuell zumindestens, sind es eher diese Arbeiten, die unbeliebt waren. Also ein Kollege von mir ist Cutter und der hat mir mal erzählt, für so TV-Sendungen, wie viele Kurzclips er machen muss für die Bewerbung von dieser Fernsehsendung. Also dieses Magazin kommt morgen um 20 Uhr, dann gibt es einen anderen Clip, dieses Magazin kommt heute um 20 Uhr und so weiter. Und der macht 20 solche Clips nur für die Bewerbung von dem eigentlichen Programm. Und die macht er natürlich alle händisch, die schneidet er zusammen und so weiter. Und dann kommt irgendjemand und sagt, wir verlegen jetzt die Sendung auf 21 Uhr. Dann kann er sich hinsetzen und diese ganzen 20 Clips wieder manuell ändern, überall die Zeit durch ändern und das nennt sich dann Videoschnitt, aber im Prinzip ist es dumme Arbeit. Und diese Dinge, glaube ich, kann der Computer in Zukunft wesentlich schneller und besser und einfacher erledigen. Die kreative Arbeit wird aber trotzdem noch schwierig werden. Und das ist ja das eigentlich, was jetzt irgendein Videoschnitt-Mensch wahrscheinlich viel lieber macht, da kreative Arbeiten, anstatt nur dumm irgendwelche Zeiten auszubessern. Oder der Programmierer, der eben das zwanzigste Login-Formular macht. Also ich glaube, diese Tasks werden sehr schnell ersetzt werden. Wie weit dann unser Job in Gefahr ist, auf lange Sicht, Es ist eine gute Frage, weil wir uns halt auch die Zukunft nicht so gut vorstellen können. Und wir denken halt immer, was ist in den letzten 20 Jahren passiert, es wird halt in der Geschwindigkeit weitergehen. Aber was halt die Vergangenheit auch zeigt, ist, dass das eigentlich exponentiell schnell wächst, die Technologie, und wir uns das gar nicht vorstellen können, was in den nächsten 20 Jahren passiert, weil die Geschwindigkeit einfach so stark steigt.

Andy Grunwald (00:50:29 - 00:50:39) Teilen

Aber jetzt ist es ja so, du redest von kreativer Arbeit, Videoschnitt, Audioschnitt und so weiter und so fort, aber wie sieht es denn in der Generierung von Blogartikeln aus, ja? Zeotexte, Marketing?

Wolfi Gassler (00:50:40 - 00:50:43) Teilen

Ja, das ist ja auch nichts, was jemand gerne macht, würde ich mal sagen.

Andy Grunwald (00:50:43 - 00:50:57) Teilen

Auch weiß ich jetzt nicht, aber wenn ich jetzt Copywriter bin, das ist mein Job und hoffentlich haben alle Copywriter natürlich Spaß an ihrem Job und machen das nicht nur, um die Miete zu zahlen. Also ich hoffe doch mal, dass Leute schon sehr gerne schöne Texte schreiben und daran Spaß haben.

Wolfi Gassler (00:50:57 - 00:51:13) Teilen

Aber die schreiben eben schöne Texte und keine SEO-Texte. Die wollen kreative, schöne Texte schreiben und weniger den hundertsten SEO-Artikel, glaube ich mal. Ich kenne die Leute jetzt keine persönlich, aber ich glaube mal, dass das Dumme eher weniger Spaß macht, das Repetitive.

Andy Grunwald (00:51:14 - 00:51:41) Teilen

Oder oder jetzt hier ist mal so ein so ein so ein manuskript für so einen film ja ich habe die tage gelesen irgendjemand hat auf chat gpt so ein komplettes manuskript für so einen film geballert so also ich als filmproduzent werde doch wohl spaß haben mir die ganze storyline auszudenken und so weiter und so fort und wenn ich dann so lese okay chat gpt macht da 95 98 prozent meiner arbeit dann ist die frage ok ersetzt, AI vielleicht nicht die Softwareentwicklung, aber ersetzt AI solche Jobs?

Wolfi Gassler (00:51:41 - 00:52:28) Teilen

Kann durchaus sein. Ich glaube, dass es aktuell immer noch ein Tool ist. Und diese Leute, die das Business gut verstehen, wie das funktioniert, die wenden dann dieses Tool an, um sich selber das Leben einfacher zu machen und lassen sich da helfen. Zumindest die Leute, die schlau sind, meiner Meinung nach, um eben den Zug nicht zu verpassen. Aber dass die Person komplett ersetzt wird, auf lange Sicht ja, vielleicht. Aber auf mittlere Sicht sehe ich das jetzt noch nicht so, dass das von heute auf morgen irgendwie eine Maschine erledigt, auch weil ich einen Ansprechpartner will, der mir als Gesamtpackage das dann überliefert. Bei einem Elektriker geht es ja auch nicht darum, nur dieses Kabel zu verlegen, sondern der versteht das Problem, der findet die beste Lösung, setzt es dann alles um und nimmt mir diesen gesamten Task eigentlich ab.

Andy Grunwald (00:52:29 - 00:53:15) Teilen

Jetzt ist es ja so dass ei auf basis von vorhandenen daten lernen muss also also dieser prozess muss ja irgendwie lernen okay das gibt es und dann kann man drei existierende informationen zusammenschmeißen und hat man eine vierte neue information und ich glaube so funktioniert auch so ein tool wie github copilot oder wo ich dann eingebe hey schreiben mal bitte irgendwie die, Funktion, um die Wurzel von irgendwas zu ziehen. So, und dann gibt er mir den Quellcode raus. Das geht ja schon sehr hart in unsere Richtung von ersetzt die Softwareentwicklung, weil da können Leute eingeben, schreibt mir mal bitte einen Sortieralgorithmus, der mir eine Liste von Zahlen, die aus einer REST-API kommen, sortiert oder sowas. Also das geht ja schon sehr weit.

Wolfi Gassler (00:53:15 - 00:56:25) Teilen

Also es ist schon sehr impressive, was da schon möglich ist. Vor allem JettGPD macht da wirklich einen super Job und schreibt dir noch die Tests dazu und so weiter. Also das ist schon sehr cool und funktioniert eigentlich auch sehr gut. Ich sehe da aber schon auch noch Schwachstellen, die sicher in Zukunft auch behoben werden, aber aktuell ist es schon noch so, du musst den Code lesen können, du musst die Fehler finden können, du musst verstehen, was da passiert. Und mir ist das gerade kürzlich selbst passiert bei Copilot, der meiner Meinung nach sehr, sehr gut ist. Dieses GitHub-Produkt, was dir in die IDE integriert ist und dir einfach beim Programmieren hilft. Also da gibst du nicht nur an, ich will jetzt da eine Wurzelberechnung, sondern der macht dir einfach Autocompletion, Vervollständigungen. Der schreibt dir auch Kommentare, wenn du willst. Das heißt, du Du gehst über eine Funktion, die du geschrieben hast, hin und er schlägt dir anhand deiner Funktion, die du geschrieben hast, Kommentare vor, um diese Funktion zu kommentieren und die Eingabe Parameter und so weiter. Also das ist wirklich sehr coole Hilfe. Also ich verwende die super gern und die hilft mir auch viel. Aber ich habe das gerade kürzlich selbst erlebt. Ich habe da was Auto vervollständigen lassen und so weiter. Es war in Vue mit HTML. Und dann am Ende habe ich einen Error bekommen von irgendeiner Variable, die von mir war, und er findet diese Variable nicht. Und ich habe mir gedacht, warum ist da jetzt ein Fehler? Der ist ganz woanders im Code, in einer anderen Datei sogar. Und warum kommt da jetzt dieser Fehler, dass diese Variable nicht gefunden wird? Und dann habe ich nochmal natürlich, so wie man es als guter Debugger macht, man führt den Code einfach nochmal aus, um zu schauen, ob es nicht vielleicht doch schon funktioniert, ohne was zu ändern. Dann funktioniert es immer noch nicht, dann führt man es nochmal aus, ein drittes Mal, um ganz sicher zu gehen, dass es immer noch nicht funktioniert. Und dann sieht man die Fehlermeldung und dann habe ich glaube ich wirklich ein paar Minuten herumgesucht, bis ich draufgekommen bin, dass Copilot mir da irgendwo diese Variable eingebaut hat automatisch. die ich in einer anderen Datei verwendet habe, aber von mir kreiert war. Also es war eindeutig, der Variablen-Namen war von mir, aber ist mir einfach nicht aufgefallen. Das heißt, es kann dir natürlich auch wieder neue Probleme reinwerfen und dann musst du schon den Code verstehen und Debug-Messages lesen können und die Erfahrung haben, wo ist das Problem, wie finde ich dieses Problem. Also es bleibt alles noch bestehen, aber es macht einfach mein Leben viel viel einfacher. Ich muss nicht mehr aufs Stack-Overflow gehen, ich muss nicht mehr nachschauen. Wie heißt denn jetzt irgendwann eine Funktion? Vor allem, wenn man viele Programmiersprachen wechselt, ist man immer verwirrt, wie heißt jetzt die Funktion nochmal? Vor allem, wenn die Autocompletion nicht so gut ist wie in JavaScript oder so, vor allem in nicht typisierte Sprachen, ist es auch nochmal ein ganz anderer Punkt, wenn man da automatisiert sinnvolle Autocompletion-Vervollständigung bekommt oder ganze Teile zum Beispiel, ganze Funktionen und man die bewerten kann. Aber das Wichtige ist, man muss sie bewerten. Ist es das Richtige? Macht es das Richtige? Ist es eine saubere Lösung? Aber das muss ich bei Stack Overflow auch, weil da eben 20 Lösungen dann kommen. Da muss ich eine auswählen. Das muss ich bei Copilot eigentlich auch noch immer. Und da sehe ich jetzt unseren Job eigentlich noch nicht in Gefahr, weil man eben dieses ganze Zusatzwissen braucht. Noch, muss man dazu sagen. Weil eben die Technologie steigt exponentiell an und es kann schneller gehen, als man denkt. Aber aktuell sehe ich das schon noch, dass man unser Wissen braucht und unsere Erfahrung braucht. Aber es wird in Zukunft vielleicht weniger.

Andy Grunwald (00:56:25 - 00:56:33) Teilen

Jetzt ist es ja so, dass JetGPT und so weiter und so fort ja nicht immer die richtige Antwort rausspuckt. Ich habe ja die Tage auch irgendwo gelesen, dass Stack Overflow jetzt die Antwort von JetGPT verboten hat.

Wolfi Gassler (00:56:34 - 00:57:25) Teilen

Klar, es spuckt dir irgendwas aus, das kann auch kompletter Bullshit sein, aber es klingt so gut, weil es so toll geschrieben ist, dass man fast glaubt, dass es stimmt. Das ist so wie, dass man immer glaubt, dass es stimmt, wenn was in einem Buch steht oder im Fernsehen kommt. Also ich hoffe, dass mittlerweile das durchgedrungen ist, nicht alles, was im Fernsehen kommt, stimmt. Das ältere Publikum ist da schon oft der Meinung. Und ich höre diese Argumentation in meiner Familie auch immer wieder. Ja, aber das war im Fernsehen. Und so seht ihr es halt bei JettGPT auch. Nur weil das ausgespuckt wird, heißt das noch lange nicht, dass es richtig ist. Und man muss lernen, damit umzugehen und das zu überprüfen und halt auch wissen, wie man Quellen analysiert, wie man die prüft, ob die richtig sind. Das war ja bei SEO-Artikeln dasselbe. Es kommt schon so viel Bullshit über SEO-Artikel daher und man hat eigentlich keine Ahnung, ob das noch irgendwie ein sinnvolles Review ist oder nur gekauft ist und ein Produkt beworben wird.

Andy Grunwald (00:57:26 - 00:57:48) Teilen

Wenn du sagst, okay, die Entwicklung von neuen Technologien ist exponentiell, und du sagst, jetzt, AI wird unseren Job als Softwareentwickler nicht ersetzen, von welchem Zeithorizont reden wir da? So nach dem Motto, sagst du, okay, die nächsten zehn Jahre müssen wir uns da keine Gedanken machen, aber in zehn, 15 Jahren könnte das sein, dass wir so weit sind, dass das schon sehr sophisticated ist und an unser Fleisch geht?

Wolfi Gassler (00:57:48 - 00:57:52) Teilen

Ja, wie immer, man sagt, Vorhersagen sind schwierig, vor allem, wenn sie die Zukunft betreffen.

Andy Grunwald (00:57:53 - 00:57:55) Teilen

Schön.

Wolfi Gassler (00:57:56 - 00:59:05) Teilen

Und ich traue mir da wirklich nichts zu sagen, weil wenn man sich überlegt, was ist zwischen 1950 und 1970 passiert in 20 Jahren und was ist zwischen 1970 und 1990 passiert technologisch, das sind einfach Welten. Es sind beides 20 Jahre, aber das sind einfach Welten dazwischen. Und insofern ist es extrem schwierig jetzt zu sagen, was passiert in zehn Jahren. Aber ich sehe das gleich wie mit den anderen Punkten, wenn wir zurückgehen auf die Admins und Cloud. Die Profile ändern sich. Und vielleicht wird man weniger die dummen Tasks erledigen und die dummen Sachen. Und man wird sich vielleicht auf die schwierigeren Probleme lösen. Man braucht ein gutes Verständnis, Erfahrung, die Grundlagen, die man verstehen muss, um dann diese Probleme zu lösen. Den Überblick, den braucht man. Aber es wird sich wahrscheinlich das Jobprofil ändern. Und wahrscheinlich, hoffentlich, werde ich in Zukunft als Entwickler nicht mehr das 20. Mal das Login-Formular programmieren. sondern Co-Pilot wird mir das einfach komplett ausprogrammieren, wenn ich sage, okay, ihr habt ein View, programmieren wir mal ein Skeleton für ein Login-Formular oder für ein Listing oder sowas. Und dann kann ich mir auf die wichtigen Tasks konzentrieren oder auf das Big Picture.

Andy Grunwald (00:59:05 - 00:59:53) Teilen

Ich habe mich mit den ganzen Details von AI und so weiter und so fort noch gar nicht auseinandergesetzt und irgendwie denke ich mir, okay, verpasse ich da einen Hype. Auf der anderen Seite muss man natürlich auch immer explizit sagen, mit welchen themen man sich wirklich beschäftigt und mit welchen man nicht und ich habe für mich auf jeden fall diese ganze ai thema irgendwie mal nach hinten geschoben ich bin ich bin sehr gerne ein nutzer wie ich ja schon sagte von von dbl und ich habe auch schon jet jet gpt mal gebeten mal einen song zu schreiben im team vom rammstein oder ähnliches da kommt halt schon schon was lustiges bei raus, Muss man ja auch sagen. Aber ja, ich würd's halt auch gern unten drunter mal verstehen. Ich würd halt gern mal, dass jemand mal neurale Netzwerke vor Dummies oder so schreibt. Oder Chat-GPT oder GPT-3 vor Dummies. Oder GitHub-Copilot-Explained oder so was. Einfach mal so, ohne ein ganzes Mathe-Studium abschließen zu müssen.

Wolfi Gassler (00:59:54 - 01:00:08) Teilen

Ist natürlich schwierig. Ich glaube, an das müssen wir uns gewöhnen, dass wir eben nicht alles verstehen mehr. Und das haben wir in ganz vielen anderen Bereichen auch. Und die wenigsten wissen wahrscheinlich noch, wie man gut Wäsche manuell im Fluss wäscht, dass sie sauber wird.

Andy Grunwald (01:00:08 - 01:00:19) Teilen

Aber auf der anderen Seite überlege ich gerade, bin ich gerade der alte Opa, der auf der Couch sitzt, so die die Faust hebt und sagt mäh mäh mäh mäh mäh? Weiß ich jetzt gerade auch nicht. Na ja, schauen wir mal.

Wolfi Gassler (01:00:19 - 01:00:56) Teilen

Ihr habt noch eine gute Geschichte, die mir meine Schwester gerade erzählt hat, die in einer Schmiede arbeitet. Und die arbeitet mit einem Plasmaschneider. Die kann so große Metallplatten ausschneiden. Die designt das am Computer und das wird dann ausgeschnitten. Ganz, ganz easy. Und sie hat gesagt, alle anderen Schmieden und alte Schmiede, die verteufeln natürlich dieses Zeug. Das ist alles dieses neumodische Zeug. Das ist nicht mehr die alte Schmiedekunst. Da wird was ausgeschnitten mit einem Plasmaschneider. Und das ist ja alles nur Müll. Aber man kann natürlich andere Sachen damit machen und kreative Sachen machen und man kann sich vielleicht auf die kreativen Teile konzentrieren und das Metall wird dann am Ende geschnitten.

Andy Grunwald (01:00:56 - 01:01:17) Teilen

Aber das ist auch mal eine interessante Frage, wird die alte Schmiedekunst dann mehr wertgeschätzt? Weil es einfacher wird, mit solchen Tools wie dem Plasmaschneider, dass es dann, ich sag mal, jeder kann, was ja positiv ist, aber wird dann das alte traditionelle Handwerk dann von Die-Hard-Fans, weiß ich nicht, nicht mehr wertgeschätzt und steigt das dann vielleicht auch im Preis?

Wolfi Gassler (01:01:17 - 01:01:38) Teilen

Das glaube ich schon. Es wird eine Nische werden. Und wenn du was Handgemachtes haben willst, dann gehst du zu einem alten klassischen Schmied. Aber wenn du ein riesen Tor willst, mit acht mal drei Meter, mit einem Muster ausgeschnitten, dann schau mir das an, wie das ein klassischer Schmied mit der Handsäge oder keine Ahnung, mit was man das macht, mit einem Handbohrer, die er ausschneidet.

Andy Grunwald (01:01:39 - 01:02:03) Teilen

Also man merkt, du bist ein Schmied bis auf keinen Fall. Genau. Okay, drei Thesen. Die Cloud wird unsere Admin-Jobs ersetzen. No-Code-Tools wird unsere Jobs ersetzen. Und AI und Chat-GPT wird unsere Jobs ersetzen. So, wie ich das rausgehört hab, ist das too long, didn't read von dieser Podcast-Episode. Nein, nein, nein. Alles gerade nicht so der Fall. Ist das richtig?

Wolfi Gassler (01:02:03 - 01:02:10) Teilen

Genau, aber wir müssen uns, glaube ich, mit den Dingen beschäftigen, um nicht auf der Strecke zu bleiben und für die Zukunft gerüstet zu sein.

Andy Grunwald (01:02:10 - 01:02:20) Teilen

Das bedeutet wohl auch, ich muss mich auch mal der AI-Thematik hingeben. Und ich muss zugeben, ich hab GitHub Copilot noch nicht ausprobiert, kam ich noch nicht zu, muss ich mal tun.

Wolfi Gassler (01:02:20 - 01:02:32) Teilen

Also auch da wieder, wir werden nicht bezahlt von GitHub. Ist ja leider kostenpflichtig. Man kann's ausprobieren, glaub, zwei Monate kostenlos. Aber ich bin wirklich sehr überzeugt, und es spart mir sehr viel Zeit.

Andy Grunwald (01:02:32 - 01:02:36) Teilen

Werbung wird in diesem Podcast transparent und gekennzeichnet.

Wolfi Gassler (01:02:36 - 01:02:39) Teilen

Also in dem Fall war es keine bezahlte Werbung, es war nur Werbung.

Andy Grunwald (01:02:39 - 01:02:47) Teilen

Lasst uns doch mal wissen, wie ihr über diese drei Thesen, die Cloud, Low-Code und No-Code und AI, wie ihr darüber denkt.

Wolfi Gassler (01:02:47 - 01:02:50) Teilen

Und ob wir in drei Jahren noch einen Job haben als Entwickler.

Andy Grunwald (01:02:50 - 01:02:53) Teilen

Ja, wenn nicht, dann würde ich sagen, können wir den Podcast ja einstellen, wa?

Wolfi Gassler (01:02:53 - 01:02:55) Teilen

Das macht dann die AI.

Andy Grunwald (01:02:55 - 01:02:57) Teilen

Die AI hört dann unseren Podcast, meinst du?

Wolfi Gassler (01:02:57 - 01:02:58) Teilen

Die kreiert und hört den Podcast.

Andy Grunwald (01:03:00 - 01:03:01) Teilen

Ja gut, man kann sich auch selbst beschäftigen.

Wolfi Gassler (01:03:02 - 01:03:03) Teilen

Genau.

Andy Grunwald (01:03:03 - 01:03:09) Teilen

Ein bisschen Gedankenfutter für den heutigen Tag. Und bis dahin würde ich sagen, viel Spaß und bis bald. Ciao.