Ich kann programmieren!

Wir müssen lernen, dass Programmieren ungleich Programmieren ist

Bei der Diskussion anlässlich der Formulierung des Lehrplans 21 vor 10 bis 15 Jahren, ob Informatik obligatorisch in die Volksschule gehöre (Biblionetz:a00436) , erlebte ich Gegenwind auch von unerwarteter Seite: Informatikerinnen und Informatiker äusserten die Sorge, dass bald alle sagen würden "Ich kann programmieren!", weil sie in der Schule Informatikunterricht hatten. Das sei verheerend, denn dadurch würde die Bedeutung einer "echten" Informatikausbildung geschmälert.

Mit der aktuellen Entwicklung, dass generative Machine-Learning-Systeme immer besser Software schreiben können, nimmt derzeit die Zahl der Menschen zu, die auf LinkedIn laut ausrufen: "Ich kann programmieren!".

Ein Versuch der Klärung zur Beruhigung der Gemüter auf beiden Seiten.

Beim Schreiben ist allen klar, dass ein Unterschied besteht zwischen dem, was Kinder machen, wenn sie in der Schule schreiben lernen und dem, was erfolgreiche Autorinnen und Autoren machen, wenn sie ein Buch schreiben. Da kommt niemand auf die Idee zu kritisieren: "Wenn ihr den Kindern sagt, dass sie jetzt schreiben gelernt haben, dann vermittelt dies ein völlig falsches Bild, was schreiben wirklich ist.!" Beim Programmieren ist dies vielen nicht klar.

Ich habe versucht, diesen Unterschied in eine verständliche Grafik zu packen und bin aktuell nach vielen Entwürfen und einigen Diskussionen bei zwei Versionen angelangt, die mir aber noch nicht gut genug scheinen. Bei beiden spielt einerseits mit, dass der Begriff Programmieren nicht präzis definiert ist und wir eventuell zwischen Programmieren und Software entwickeln unterscheiden müssen:

• Softare entwickeln: Aus einem Verständnis für die zu lösende Aufgabe und den verfügbaren technischen Möglichkeiten ein Architektur planen und umsetzen, welche die Aufgabe effektiv, effizient und zuverlässig und sicher löst.
• Programmieren: Einen Ablauf in lauffähigen Code umsetzen.

Zum anderen gibt es auch Unterschiede, was programmiert wird und welchen Ansprüchen das Programmierte genügen muss. Diesen Unterschied habe ich versucht in dieser Grafik auszudrücken:

Die zweite Grafik visualisiert unterschiedliche Arten von "Schreiben":

Welche der beiden Grafiken transportiert die Botschaft besser?

Warum blogge ich überhaupt darüber? Man könnte mir vorwerfen, dass ich als ausgebildeter Informatiker einen Statusverlust befürchte, wenn jetzt dankt GMLS das Herstellen von Software einfacher geworden ist. Ich hoffe, dass das nicht mein heimlicher Treiber ist, auf diese Problematik hinzuweisen. Ich freue mich, dass mehr Menschen durch GMLS ihre Möglichkeiten erweitern können, sich digital auszudrücken und/oder in digitalen Strukturen zu denken. Programmieren kann dazu führen, dass man sich vermehrt Gedanken über Strukturen und Abläufe im digitalen Raum macht. Es sind mehrere berufliche Fragen, die mich beschäftigen:

• Brauchen wir künftig noch ausgebildete Informatiker:innen? ist eine wichtige bildungspolitische Frage, die mich beruflich beschäftigt. Insofern ist es wichtig zu beobachten, wo die Potenziale und Grenzen von GMLS im Bereich der Software-Entwicklung sind.
• Müssen wir uns vor schlecht programmierten Systemen fürchten? ist die grössere Frage, die mich umtreibt. So wie wir in der Schweiz und in der EU für gewisse Berufe eine Ausbildung verlangen (z.B. Elektriker:innen) oder bei gewissen Produkten ein gewisses Sicherheitslevel mit einem Prüfsiegel auf dem Produkt belegt werden muss (und chinesische Direktimporte das Siegel teilweise nicht oder nur gefälscht haben), so müssen wir bei gewisser Software auch sicher sein können, dass sie gewisse Sicherheitsstandards genügt. Das gilt nicht nur für selbstfahrende Autos, sondern auch für Lernsoftware und andere Programme, mit denen Kindern und Jugendliche zu tun haben (oder gar zu tun haben müssen).

Und ja, ich kann nicht ausschliessen, dass GMLS in kurzer Zeit wirklich fast alleine robuste Software entwickeln können. Derzeit können sie das meines Erachtens noch nicht.

P.S.: Myke Naef hat mich auf Simon Willison aufmerksam gemacht, der zwischen *vibe coding (Biblionetz:w03702) und vibe engineering unterscheidet.