Whiz-zarD

JSON hat einen geringeren Overhead gegenüber XML, was schon mal die Dateigröße reduziert und das ist der Vorteil von JSON. JSON verzichtet auch bewusst auf die Validierung, um leichtgewichtig zu bleiben, da es eben bei JavaScript seine Anwendung fand und JavaScript nun mal schwach typisiert ist.
Wer wirklich eine Validierung braucht, der sollte sich mal JSON-Schema anschauen.
Mit JSON-Schema kann man auch beliebig komplexe Datenmodelle validieren. Es gehört aber nicht zum Standard, sondern ist was eigenständiges. Es wird durch eine Community entwickelt und nicht durch ein Konsortium mehrerer Firmen (wie das W3C). Auch darf man nicht vergessen, dass JSON, als Datenaustauschformat, erst seit ca. 10 Jahren wirklich im Gespräch ist. Dadurch hat es also eher historische Gründe, warum XML verwendet wird, anstatt JSON. Früher, als man im Web noch Ajax als Technik benutzte, um Daten asyncron auf einer Webseite auszutauschen, hat man ja auch noch XML verwendet.

Don't feed the troll.

In Hamburg sagt man Tschüss...

Langzeitarbeitslose bekommen auch keine Umschulung geschenkt und sie als Spargelstecher loszuschicken löst auch keine Probleme, denn die werden diesen Job erst gar nicht antreten. Damit will man auch nur die Symptome bekämpfen und nicht die Ursache. Ich persönlich finde genau diesen Gedanken Asozial: Einfach treten, dann klappt es schon.
Langzeitarbeitslose haben oft eine starke Depression oder haben andere Erkrankungen. Aber ich schätze in deinem Mikrokosmos gibt es nur physische Erkränkungen. Es gibt inzwischen sogar Studien, dass Gefängnisinsassen zu einer nicht entdeckten ADHS-Störung neigen und daher auffällig und straffällig wurden. In einigen Gefängnissen wird deswegen auch daraufhin gezielt therapiert und es zeigt Erfolge. Anstatt auf die "faulen Arbeitslosen" zu treten, sollte man sich mal die Ursachen anschauen. Als Mechatroniker hatte ich auch meinen Lebensmut verloren, weil alles so Sinnlos erschien. Ich lebte damals noch bei meinen Eltern, weil ich mir z.B. keine eigene Wohnung leisten konnte, trotz 3,5 jähriger Ausbildung und mehrjähriger Berufserfahrung, dümpelte ich damals bei knapp 1.200 € Netto.

Wieder ist ein Ende der Diskussionsfähigkeit erreicht:
Mark Twain — 'Never argue with stupid people, they will drag you down to their level and then beat you with experience.'

Ich befürworte ein Ende des Threads. EOT

In Hamburg sagt man Tschüss...

Das ist das Ding mit "man kann nicht in die Köpfe der Leute gucken" und einfach über Leute zu urteilen find ich auch falsch. In welche Position sind wir denn bitte zu entscheiden wer verloren ist oder wer ne Chance kriegt.
Gab da so ne Zeit, wo Leute meinten sie wüssten genau das... naja ich will nicht so weit ausholen. Nur es bringt nichts zu behaupten wer "Asozial" ist und wer nicht. Ich konnte meinen alten Beruf in der Gastronomie auch nicht ausführen. Er hat mich psychisch fertig gemacht. IT wollte ich schon als kleines Mädchen immer machen, wurd mir nur schlecht geredet, habe ich dann halt mit 30 angefangen. Wege bilden sich auch gerne mal anders.
Wieso auch nicht?

Langzeitarbeitslose bekommen auch keine Umschulung geschenkt und sie als Spargelstecher loszuschicken löst auch keine Probleme, denn die werden diesen Job erst gar nicht antreten. Damit will man auch nur die Symptome bekämpfen und nicht die Ursache. Ich persönlich finde genau diesen Gedanken Asozial: Einfach treten, dann klappt es schon.
Langzeitarbeitslose haben oft eine starke Depression oder haben andere Erkrankungen. Aber ich schätze in deinem Mikrokosmos gibt es nur physische Erkränkungen. Es gibt inzwischen sogar Studien, dass Gefängnisinsassen zu einer nicht entdeckten ADHS-Störung neigen und daher auffällig und straffällig wurden. In einigen Gefängnissen wird deswegen auch daraufhin gezielt therapiert und es zeigt Erfolge. Anstatt auf die "faulen Arbeitslosen" zu treten, sollte man sich mal die Ursachen anschauen. Als Mechatroniker hatte ich auch meinen Lebensmut verloren, weil alles so Sinnlos erschien. Ich lebte damals noch bei meinen Eltern, weil ich mir z.B. keine eigene Wohnung leisten konnte, trotz 3,5 jähriger Ausbildung und mehrjähriger Berufserfahrung, dümpelte ich damals bei knapp 1.200 € Netto.

Das will ich nicht sagen. Themen, wie z.B. "Spec Driven Development" und "Harness Engineering" haben in den letzten Wochen ganz schön Fahrt aufgenommen. Im Grunde steht und fällt vieles mit den Tokenpreisen. Klar, was Anthropics, OpenAI und Co. von sich geben, ist Marketing-Blabla, aber es passiert auch viel außerhalb oder großen Konzerne. Ob das auch alles so funktioniert, wie man es sich vorstellt, kann ich auch nicht sagen. Die Tests, die ich damit gemacht habe, sehen aber leider recht gut aus.

Die Frage ist, wie lange erfahrene noch gebraucht werden?
Ich mein, braucht man noch Kenntnisse über Assembler oder sogar Maschinensprache? Nein.
Wir trauen dem Compiler, dass er schon seine Aufgabe richtig macht.
Es ist ja auch schon heute so, dass hinterfragt wird, ob Entwickler überhaupt noch eine IDE benötigen. Ich denke, in Zukunft wird nur noch ein kleines Technik-Team benötigt, dass die Softwarearchitektur per Markdown (oder welches Format in Zukunft auch immer?) beschreibt und dann Fachanwender die Software beschreiben. Der Rest macht die KI. Ich kann mir sogar vorstellen, dass es in Zukunft viellecht sogar eine eigene, sehr kompakte Programmiersprache für LLMs geben wird, um Tokens zu sparen. Man sieht ja heute schon, dass es um Sprachfeatures sehr ruhig geworden ist, weil die KI braucht keinen syntaktischen Zucker.
In der IT selber (Administration, etc.) wird es wohl ähnlich aussehen. Da wird wohl auch noch viel mehr automatisiert werden, sodass man hier auch nur noch ein ein kleines Team benötigt, um den Grundrahmen zu beschreiben.
Das sind aber alles nur meine Vermutungen. Nichts davon muss stimmen. Ehrlich gesagt hoffe ich sogar, dass es nicht stimmen wird. Dafür liebe ich es einfach zu sehr, Problemlösungen zu finden. Wenn die KI das komplett übernehmen wird, dann werde ich wohl einen Job suchen.

Der Beitrag wurde doch editiert. Die 13 Punkte wurden nicht gutgeschrieben.
Aber ja, aktuell scheint in der Ausbildung echt der Wurm drinnen zu sein. Bei der Berufsschule in Hamburg hat man wohl auch verlernt, wie man richtig ausbildet und hat daher eine Initiative gestartet und wollen von den Firmen wissen, was und in welchem Umfang die Schule ausbilden soll, nachdem sich die Ausbilder über die Qualität der Schule beschwert haben.

Man könnte ja mal schreiben, was dir z.B. gefehlt hat, um überhaupt mal zu verstehen, was deine Intention war. Es kommt immer besser an, wenn man auch mal ein bisschen darüber redet und somit eine Gesprächsgrundlage schafft, anstatt nur damit zu prahlen, dass der Berufsschullehrer es verwendet. So wirkt es nur, als suchst du nur kostenlose Betatester.
Den Text verstehe ich nicht, aber dir ist schon klar, dass vor drei Monaten schon eine "Subnet Master"-App veröffentlicht wurde, die deiner Version verdammt ähnlich aussieht... (Und wahrscheinlich auch nur generiert wurde)
https://www.reddit.com/r/ccna/s/k2WBFi49Ei
Übrigens: In deinem Projekt steht "Subnetting Master" und nicht "Subnettmaster". Wie heißt es denn nun?

Man könnte ja mal schreiben, was dir z.B. gefehlt hat, um überhaupt mal zu verstehen, was deine Intention war. Es kommt immer besser an, wenn man auch mal ein bisschen darüber redet und somit eine Gesprächsgrundlage schafft, anstatt nur damit zu prahlen, dass der Berufsschullehrer es verwendet. So wirkt es nur, als suchst du nur kostenlose Betatester.
Den Text verstehe ich nicht, aber dir ist schon klar, dass vor drei Monaten schon eine "Subnet Master"-App veröffentlicht wurde, die deiner Version verdammt ähnlich aussieht... (Und wahrscheinlich auch nur generiert wurde)
https://www.reddit.com/r/ccna/s/k2WBFi49Ei
Übrigens: In deinem Projekt steht "Subnetting Master" und nicht "Subnettmaster". Wie heißt es denn nun?

Sollen wir unsere Verbesserungsvorschläge direkt in die große Miesmuschel geben oder willst du sie lieber selbst kopieren?
Sorry, die Hitze macht mich etwas grumpy.

Wenn man Scrum falsch umsetzt, dann kommt halt murcS raus. ;)
Das scheint bei euch ja der Fall zu sein. Scrum hat nicht das Ziel, dem Entwicklern Scheuklappen aufzusetzen, sondern sich mit den Kunden, in einem Dialog, auszutauschen. Das Team ist dabei interdisziplinär. Der PO soll dabei auch nicht entscheiden, wie etwas umgesetzt werden soll. Dafür ist das Team zuständig. Der PO soll nur die Prioritäten anhand des sog. business value vorgeben. Also was bringt dem Unternehmen am meisten? Er entscheidet also das was, und nicht das wie.
Allerdings scheitert Scrum in den meisten Firmen, weil Scrum verlangt, dass man die Kontrolle den Teams gibt, aber gerade Manager werden dann gerne zum PO ernannt und die wollen natürlich die Kontrolle nicht abgeben und fangen dann mit Micromanagement an. Daily Meetings werden dann zu PO Status Meetings. Dazu sind sie aber nicht gedacht. Sie dienen für das Team, ihre tägliche Arbeit abzustimmen, wobei ich mich auch immer gefragt habe wozu? Ein Team kann sich auch auf kurzen Dienstwegen abstimmen. Ein Meeting ist dazu überhaupt nicht notwendig. Auch sind die Teams meist nicht interdisziplinär, sondern sind dann von anderen Teams abhängig und dadurch entsteht ein Wasserfall. Die Teams sind dann keine Scrum-Teams, sondern nur Komponenten-Teams, die Komponenten am Fließband produzieren, ohne zu wissen, für wen sie was produzieren und ob sie überhaupt das richtige produzieren.
Das Video zeigt sehr gut das Problem: Why "Scrum" Isn't Making Your Organization Agile: Harmful Misconceptions About Product Owner Role
Auch sind die Videos von Allen Holub sehr aufschlussreich (Er ist ein Scrum-Hasser): War is Peace, Freedom is Slavery, Ignorance is Strength, Scrum is Agile
Auf Papier arbeiten wir auch nach Scrum, aber Scrum ist bei uns aus den gleichen Gründen gescheitert. Die Teams arbeiten inzwischen immer mehr nach Kanban. Wir haben auch keine interdisziplinären Teams, aber wir stimmen uns untereinander mit den anderen Teams ab, was wir brauchen und sie planen es dann bei sich ein. Die Sprints sind nahezu aufgelöst. Wir haben zwar noch Sprints, aber ob in zwei Wochen die Aufgaben fertig werden, oder in China fällt ein Sack Reis um. Das interessiert eh keinen, da wir eh nur alle drei Monate ein Release veröffentlichen. Das hat wieder eine ganze Menge Ruhe ins Unternehmen gebracht.

Das deckt sich auch mit den Studien, die es dazu auch inzwischen gibt. Die Planungsphase rückt viel mehr in den Vordergrund und da sehe ich auch die größte Problematik, denn die Spezifikation war schon immer das größte Problem in der Softwareentwicklung. Man konnte so viel spezifizieren, wie man wollte, sobald es in die Entwicklung geht, geht die Spezifikation und Programmcode auseinander. Es ist manchmal auch schwierig, die Dinge unmissverständlich in Worte zu packen, damit kein Interpretationsspielraum übrig bleibt. Dafür ist die Sprache zu vielfältig. Deswegen beschränken sich Programmiersprachen auch nur auf wenige Worte, damit es eindeutig ist. Außerdem wurden die Anforderungen auch zu gerne "über den Zaun geworfen". Es heißt dann oft: "Der Kunde will ... Mach das mal fertig!". Das ist dann quasi vorbei. Jetzt muss man sich hinsetzen und genau planen, was der Kunde eigentlich wirklich will. Das viel erhoffte Vibe Coding funktioniert meiner Meinung auch nicht. Ab einem gewissen Punkt kommt da überwiegend Müll raus.

Der Beitrag wurde doch editiert. Die 13 Punkte wurden nicht gutgeschrieben.
Aber ja, aktuell scheint in der Ausbildung echt der Wurm drinnen zu sein. Bei der Berufsschule in Hamburg hat man wohl auch verlernt, wie man richtig ausbildet und hat daher eine Initiative gestartet und wollen von den Firmen wissen, was und in welchem Umfang die Schule ausbilden soll, nachdem sich die Ausbilder über die Qualität der Schule beschwert haben.

Nur zur Einordnung: Der Rahmenlehrplan ist der Plan der Berufsschule. Der Ausbildungsrahmenplan ist der Plan des Betriebes. ;)
Im Grunde ist es genau so. In der Anlage der Ausbildungsordnung stehen ja die zu vermittelnden Fertigkeiten, Kenntnisse und Fähigkeiten und zu jedem dieser Punkte schreibst du dann auf, wann und was vermittelt wird. Das Bundesinstitut für Berufsbildung hat dazu ein Muster veröffentlicht: https://www.bibb.de/dienst/berufesuche/de/index_berufesuche.php/practice_examples/checklisten_und_muster/AG_FI_Kap_2.1.5_Muster_Betr_Aplan.pdf

Es gibt keine wissenschaftliche Studie, die belegt, dass der Dark Mode schonender für die Augen sei. Ich denke, dass man hier nur von einem Gefühl sprechen kann.
Ich persönlich finde aber auch den Dark Mode nicht so anstrengend. Das hat folgende Gründe:
Ich bin stark kurzsichtig. (Stark) Kurzsichtige sehen die Mouches volantes stärker. Durch den Dark Mode fallen sie daher nicht so stark auf.
Außerdem sind meine Augen hell (bzw. grün). Helle Augen filtern Licht weniger als dunkle Augen. Daher kommt mir der Light Mode auch vor, als würde mich ein Flutlicht anstrahlen. Auch im Sommer habe ich damit stark zu kämpfen. Einmal bin ich in eine allgemeine Verkehrskontrolle geraten und musste einen Drogentest machen, weil meine Pupillen so klein waren, dass sie dachten, ich hätte Drogen genommen.
Ich kenne aber auch genug Leute, die den Light Mode bevorzugen.

Es gibt keine wissenschaftliche Studie, die belegt, dass der Dark Mode schonender für die Augen sei. Ich denke, dass man hier nur von einem Gefühl sprechen kann.
Ich persönlich finde aber auch den Dark Mode nicht so anstrengend. Das hat folgende Gründe:
Ich bin stark kurzsichtig. (Stark) Kurzsichtige sehen die Mouches volantes stärker. Durch den Dark Mode fallen sie daher nicht so stark auf.
Außerdem sind meine Augen hell (bzw. grün). Helle Augen filtern Licht weniger als dunkle Augen. Daher kommt mir der Light Mode auch vor, als würde mich ein Flutlicht anstrahlen. Auch im Sommer habe ich damit stark zu kämpfen. Einmal bin ich in eine allgemeine Verkehrskontrolle geraten und musste einen Drogentest machen, weil meine Pupillen so klein waren, dass sie dachten, ich hätte Drogen genommen.
Ich kenne aber auch genug Leute, die den Light Mode bevorzugen.

Stimmt.
Aber was bringt es, wenn beide sich immer den schwarzen Peter zuspielen und sich nichts ändert?

Azubis und vor allem Umschüler, müssen darüber wachen, wenn Lücken entstehen und sich hörbar beschweren.
Eigeninitiative als Lückenfüller zu fordern ist nicht sinnvoll. Aber wenn die Betroffenen Mängel nicht ansprechen, sind Beschwerden nach der Prüfung einfach zu spät.

Wenn man Scrum falsch umsetzt, dann kommt halt murcS raus. ;)
Das scheint bei euch ja der Fall zu sein. Scrum hat nicht das Ziel, dem Entwicklern Scheuklappen aufzusetzen, sondern sich mit den Kunden, in einem Dialog, auszutauschen. Das Team ist dabei interdisziplinär. Der PO soll dabei auch nicht entscheiden, wie etwas umgesetzt werden soll. Dafür ist das Team zuständig. Der PO soll nur die Prioritäten anhand des sog. business value vorgeben. Also was bringt dem Unternehmen am meisten? Er entscheidet also das was, und nicht das wie.
Allerdings scheitert Scrum in den meisten Firmen, weil Scrum verlangt, dass man die Kontrolle den Teams gibt, aber gerade Manager werden dann gerne zum PO ernannt und die wollen natürlich die Kontrolle nicht abgeben und fangen dann mit Micromanagement an. Daily Meetings werden dann zu PO Status Meetings. Dazu sind sie aber nicht gedacht. Sie dienen für das Team, ihre tägliche Arbeit abzustimmen, wobei ich mich auch immer gefragt habe wozu? Ein Team kann sich auch auf kurzen Dienstwegen abstimmen. Ein Meeting ist dazu überhaupt nicht notwendig. Auch sind die Teams meist nicht interdisziplinär, sondern sind dann von anderen Teams abhängig und dadurch entsteht ein Wasserfall. Die Teams sind dann keine Scrum-Teams, sondern nur Komponenten-Teams, die Komponenten am Fließband produzieren, ohne zu wissen, für wen sie was produzieren und ob sie überhaupt das richtige produzieren.
Das Video zeigt sehr gut das Problem: Why "Scrum" Isn't Making Your Organization Agile: Harmful Misconceptions About Product Owner Role
Auch sind die Videos von Allen Holub sehr aufschlussreich (Er ist ein Scrum-Hasser): War is Peace, Freedom is Slavery, Ignorance is Strength, Scrum is Agile
Auf Papier arbeiten wir auch nach Scrum, aber Scrum ist bei uns aus den gleichen Gründen gescheitert. Die Teams arbeiten inzwischen immer mehr nach Kanban. Wir haben auch keine interdisziplinären Teams, aber wir stimmen uns untereinander mit den anderen Teams ab, was wir brauchen und sie planen es dann bei sich ein. Die Sprints sind nahezu aufgelöst. Wir haben zwar noch Sprints, aber ob in zwei Wochen die Aufgaben fertig werden, oder in China fällt ein Sack Reis um. Das interessiert eh keinen, da wir eh nur alle drei Monate ein Release veröffentlichen. Das hat wieder eine ganze Menge Ruhe ins Unternehmen gebracht.

Keine Ahnung, wo man da wirklich anfangen soll, weil das Video doch sehr viele Mängel aufweist und Studenten und Juniors in eine falsche Richtung führt.
Erstmal ist JSON nicht die Sprache, mit der moderne Systeme kommunizieren. Es ist lediglich nur eine Sprache. JSON ist nur wegen seiner relativen Kompaktheit und Lesbarkeit so verbreitet. Früher war XML sehr verbreitet (Stichwort wäre z.B. AJAX). JSON ist aber auch nur Text und daher von der Datenmenge recht groß. Bei einer UTF-8-Kodierung kann im schlimmsten Fall ein Zeichen 4 Bytes groß sein. Auch ist das Parsen von JSON nicht die schnellste Variante und je nach Anwendungsfall auch nicht optimal. Daher gibt es auch ganz andere Formate, wie z.B. Googles Protobuf, was ein komprimiertes Binärformat ist und einfach dekomprimiert als Datenblock in den Speicher gelegt werden kann, ohne dass man es Zeichen für Zeichen parsen muss. In einer Android-App, die ich mal mitentwickelt habe, haben wir uns für Protobuf entscheiden, anstatt für JSON, weil Protobuf performanter war und den Akku schonte. Das kann man momentan auch gut bei den ganzen KI-Apps sehen, wie der Akku aufgrund von JSON streaming leergelutscht wird. ChatGPT braucht z.B. mehr Akkuleistung, als Netflix.
Auch finde ich den Microservice-Teil sehr problematisch. Das suggiert, als würde man heute nur noch Microservices entwickeln. Das ist aber falsch und sehr gefährlich. In den allermeisten Fällen sind Microservices wie mit Kanonen auf Spatzen schießen, da Microservices im Vergleich zu einem Monolithen, sehr viele komplexe Problematiken aufweist, die man mit einem Monolithen eben nicht hat (z.B. Orchestrieung? Was tun beim Ausfall einzelner Services? Verteilte Transaktionen? Health-Check? etc.)
Alles in einem frage ich mich auch, wer die Zielgruppe sein soll? Für Anfänger und Juniors sind da viel zu viele Fachbegriffe drinnen, die auch nicht richtig eingeordnet werden. Warum wird überhaupt JSON erwähnt und warum der Schwung Richtung Microservices?

Keine Ahnung, wo man da wirklich anfangen soll, weil das Video doch sehr viele Mängel aufweist und Studenten und Juniors in eine falsche Richtung führt.
Erstmal ist JSON nicht die Sprache, mit der moderne Systeme kommunizieren. Es ist lediglich nur eine Sprache. JSON ist nur wegen seiner relativen Kompaktheit und Lesbarkeit so verbreitet. Früher war XML sehr verbreitet (Stichwort wäre z.B. AJAX). JSON ist aber auch nur Text und daher von der Datenmenge recht groß. Bei einer UTF-8-Kodierung kann im schlimmsten Fall ein Zeichen 4 Bytes groß sein. Auch ist das Parsen von JSON nicht die schnellste Variante und je nach Anwendungsfall auch nicht optimal. Daher gibt es auch ganz andere Formate, wie z.B. Googles Protobuf, was ein komprimiertes Binärformat ist und einfach dekomprimiert als Datenblock in den Speicher gelegt werden kann, ohne dass man es Zeichen für Zeichen parsen muss. In einer Android-App, die ich mal mitentwickelt habe, haben wir uns für Protobuf entscheiden, anstatt für JSON, weil Protobuf performanter war und den Akku schonte. Das kann man momentan auch gut bei den ganzen KI-Apps sehen, wie der Akku aufgrund von JSON streaming leergelutscht wird. ChatGPT braucht z.B. mehr Akkuleistung, als Netflix.
Auch finde ich den Microservice-Teil sehr problematisch. Das suggiert, als würde man heute nur noch Microservices entwickeln. Das ist aber falsch und sehr gefährlich. In den allermeisten Fällen sind Microservices wie mit Kanonen auf Spatzen schießen, da Microservices im Vergleich zu einem Monolithen, sehr viele komplexe Problematiken aufweist, die man mit einem Monolithen eben nicht hat (z.B. Orchestrieung? Was tun beim Ausfall einzelner Services? Verteilte Transaktionen? Health-Check? etc.)
Alles in einem frage ich mich auch, wer die Zielgruppe sein soll? Für Anfänger und Juniors sind da viel zu viele Fachbegriffe drinnen, die auch nicht richtig eingeordnet werden. Warum wird überhaupt JSON erwähnt und warum der Schwung Richtung Microservices?

Mein Verständnis von KI-Skills
ist idealerweise eine fundierte Ausbildung -- etwa im Bereich Data Science oder Machine Learning -- sowie die Fähigkeit, sowohl mit klassischen ML-Verfahren als auch mit künstlichen neuronalen Netzen eigenständig Modelle zu entwickeln. Dazu gehört ebenso, diese Systeme für konkrete Anwendungsfälle zu optimieren, kritisch zu evaluieren und nachhaltig in bestehende Prozesse zu integrieren.
Was häufig als KI-Skills bezeichnet wird
ist die Nutzung eines vorgefertigten Systems, welches -- nicht selten von externen Anbietern -- über eine einfache Eingabemaske oder Schnittstelle bereitgestellt wird. Manche fühlen sich bereits dann als Experten, wenn sie glauben, Anfragen besonders geschickt formulieren zu können (Prompting). Eine andere Variante besteht darin, fertige Modelle herunterzuladen und einzubinden, ohne deren Funktionsweise wirklich zu verstehen. Dies in der Hoffnung, dass bei der Integration in Geschäftsprozesse und Entwicklungsprozessen schon nichts schiefgehen wird.
Nach meiner Einschätzung lässt sich dieses oberflächliche Niveau an Kompetenz innerhalb weniger Tage erreichen. Es spricht nichts dagegen, solche Werkzeuge in Ausbildung und Studium einzusetzen. Mit echter fachlicher Kompetenz oder nachhaltigem Skill-Aufbau hat das aus meiner Sicht jedoch nur begrenzt zu tun. Die Wahrscheinlichkeit ist recht hoch, dass die Person am Ende weder eigene Fähigkeiten hat, noch diese Systeme sinnvoll einsetzen kann. Die Leute, deren Mehrwert nur daraus besteht von ChatGPT und Co. zu copy&pasten, sind die ersten, für die es später keinen Platz mehr geben wird.