Ich weiß: Der Titel ist provokant (dazu am Ende mehr), und Sie werden bei den ersten Sätzen vielleicht denken:

„Nicht schon wieder ein Artikel zum Thema KI!“

Aber darum geht es gar nicht – vertrauen Sie mir: Künstliche Intelligenz wird in diesem Beitrag nur am Rande behandelt, sie dient lediglich als Aufhänger. Denn tatsächlich geht es hier um etwas sehr viel Grundsätzlicheres.

Was bedeutet es, programmieren zu können?

In letzter Zeit hört man immer wieder den Satz:

„In Zukunft wird niemand mehr programmieren müssen. Das übernimmt dann alles die KI.“

Vielleicht haben auch Sie diesen Satz bereits ausgesprochen oder zumindest darüber nachgedacht – oder Sie haben sich gefragt, was er für Sie persönlich eigentlich bedeutet. Denn dieser Satz kann sehr unterschiedliche Reaktionen auslösen: Für manche klingt er wie ein Versprechen, für andere wie eine Bedrohung – und für wieder andere wie die Eintrittskarte in eine neue Welt. Aber unabhängig davon, wie man ihn bewertet, lohnt es sich, ihn genauer zu betrachten. Nicht nur unter dem Aspekt, ob er inhaltlich zutrifft, sondern vor allem auch mit Blick auf die Frage, was mit „Programmieren“ in diesem Zusammenhang überhaupt gemeint ist.

Denn genau hier liegt ein wesentlicher Knackpunkt. Wenn man unter „Programmieren“ das Schreiben von Code versteht (also Funktionen formulieren, Bedingungen ausdrücken, Datenstrukturen anlegen), dann gilt: Ja, diese Tätigkeit kann eine KI schon heute in weiten Teilen übernehmen. Und dieser Trend wird sich weiter verstärken. Wenn man jedoch unter „Programmieren“ versteht, Software zu entwickeln, also Probleme zu analysieren, zu strukturieren, zu modellieren und am Ende eine Lösung zu schaffen, die diesen Namen auch verdient, dann wird schnell klar: Das ist etwas ganz anderes. Und das lässt sich nicht ohne Weiteres automatisieren.

Genau darüber möchte ich heute schreiben. Nicht über den Hype oder über die Panik. Sondern über die Frage: Was bedeutet es eigentlich, programmieren zu können? Und wofür brauchen wir diese Fähigkeit?

Das große Missverständnis

Denn das Missverständnis beginnt bereits ganz am Anfang. Und wenn wir es nicht auflösen, dann treffen wir am Ende schlechte Entscheidungen – im Beruf, in der Ausbildung und in der persönlichen Orientierung. Es geht also um nichts weniger als die Frage: Was zeichnet gute Softwareentwicklung heute eigentlich aus? Und vor diesem Hintergrund ist der Satz

„Lern bloß nicht programmieren!“

vielleicht das Beste, was Sie heute lesen werden.

Ich hatte eingangs versprochen, dass es in diesem Text nur am Rand um KI gehen wird – und deshalb lassen wir sie jetzt auch erst einmal beiseite. Beginnen wir stattdessen mit dem Einstieg in die Welt der Softwareentwicklung. Wenn ich mit Menschen spreche, die überlegen, in diese Branche einzusteigen, dann fällt mir auf, dass fast alle mit der gleichen Frage beginnen:

„Welche Programmiersprache soll ich denn lernen?“

Und ich verstehe diese Frage. Sie wirkt konkret, sie vermittelt Orientierung und sie suggeriert, dass man weiß, was zu tun ist: Man wählt Python oder JavaScript oder Go oder eine andere Sprache, lernt die Grundlagen, macht ein paar Tutorials, schreibt ein erstes Projekt – und ist damit auf dem Weg zur Softwareentwicklerin oder zum Softwareentwickler. Tatsächlich gibt es dazu eine beeindruckende Vielzahl an Ressourcen: Bücher, Crashkurse, Bootcamps, YouTube-Serien, alles speziell für Einsteigerinnen und Einsteiger, alles technisch orientiert, und alles mit dem impliziten Versprechen:

„Wenn du erst einmal die Programmiersprache beherrschst, dann bist du ein Developer.“

Softwareentwicklung ist kein Selbstzweck

Aber genau hier beginnt das Problem. Denn was diese Angebote nicht vermitteln, ist, dass eine Programmiersprache lediglich ein Werkzeug ist – und zwar ein vergleichsweise kleines. Ich ziehe hierzu gerne die Analogie zum Schreiben: Natürlich muss man die Sprache beherrschen, in der man schreiben möchte. Man muss Grammatik und Rechtschreibung können. Man muss einen Satz zu Ende bringen können. Aber all das macht einen noch nicht zur Autorin oder zum Autor eines guten Buches. Oder eines klaren Berichts. Oder einer überzeugenden Analyse.

Genauso verhält es sich mit dem Programmieren: Sie beherrschen die Syntax, Sie wissen, was Schleifen sind, Sie können Bedingungen formulieren. Vielleicht haben Sie sogar schon kleinere Projekte umgesetzt – eine Notiz-App, einen Taschenrechner, eine einfache Webseite. Und trotzdem fühlen Sie sich unsicher. Sie wissen nicht, wie Sie größere Probleme angehen sollen. Sie sind überfordert, wenn Ihnen jemand ein echtes fachliches Anliegen beschreibt. Sie haben das Gefühl, dass Ihnen etwas fehlt – und können nicht genau sagen, was es ist.

Dieses Gefühl ist berechtigt. Denn was Ihnen fehlt, ist nicht das Programmieren – sondern das, was davor kommt.

Programmieren lernen in 21 Tagen

Damit kommen wir zu einem Punkt, der mir persönlich sehr wichtig ist, weil ich ihn für problematisch halte: In den letzten Jahren sind zahlreiche Bootcamps und Schnellkurse entstanden, die versprechen, aus Ihnen in drei Monaten eine Fullstack-Entwicklerin oder einen Data Scientist zu machen, oder in zwölf Wochen einen KI-Engineer. Auf dem Papier klingt das attraktiv. Sie investieren einige Wochen oder Monate, absolvieren eine intensive Ausbildung, und anschließend (so das Versprechen) sind Sie bereit für den Arbeitsmarkt.

Und ja: Technisch gesehen ist das nicht völlig falsch. Sie werden nach drei Monaten vermutlich in der Lage sein, einfache Webanwendungen zu bauen. Sie werden eine Sprache beherrschen, vielleicht zwei. Sie werden Tools bedienen können. Sie wissen, wie man mit Git arbeitet, wie man die Kommandozeile benutzt, wie man eine React-App aufsetzt.

Aber was Sie in dieser Zeit nicht lernen, ist das, was den Unterschied macht zwischen jemandem, der Code schreibt, und jemandem, der Software entwickelt. Sie lernen nicht, wie man mit Kundinnen und Stakeholdern spricht. Sie lernen nicht, wie man Anforderungen hinterfragt. Sie lernen nicht, wie man ein Problem so abstrahiert, dass es im Code wiedererkennbar wird. Sie lernen nicht, wie man modelliert. Und Sie lernen auch nicht, wie man mit Komplexität umgeht, mit Widersprüchen, mit Veränderungen.

Genau das ist der Punkt, der mich stört: Diese Ausbildungsprogramme erzeugen oft eine verzerrte Vorstellung davon, was Softwareentwicklung eigentlich ist. Sie verkaufen das Werkzeug und tun so, als sei man damit bereits Handwerker. Aber niemand wird Chirurgin, weil sie ein Skalpell halten kann. Und niemand wird Komponist, weil er eine Noten-App bedienen kann. Und in der Softwareentwicklung ist das nicht anders.

Ganz wichtig: Es geht mir hier nicht darum, pauschal gegen alle Bootcamps oder Schulungsprogramme zu argumentieren. Es gibt sicherlich auch Formate, die bemüht sind, Substanz zu vermitteln, den Beruf differenziert zu erklären und die Teilnehmerinnen und Teilnehmer nicht bloß durch eine Technologieschleife zu treiben. Aber: Es gibt eben auch viele Programme, bei denen das nicht der Fall ist – und bei denen man (zumindest mit etwas Erfahrung) deutlich merkt, dass es in erster Linie darum geht, mit der Hoffnung von Menschen, die vielleicht einen Neuanfang suchen, Geld zu verdienen. Und ich finde, genau das muss man benennen dürfen.

Code schreiben ist nur die Spitze des Eisbergs

Wenn Sie Software entwickeln wollen, dann müssen Sie verstehen, dass der wichtigste Teil Ihrer Arbeit unsichtbar ist. Er passiert vor dem Code. Vor dem Editor. Vor dem ersten Commit. Er beginnt mit einem Problem – und mit einem Menschen, der dieses Problem hat. Oder mit einer Organisation, einer Abteilung, einem Prozess. Ihre erste Aufgabe ist, zuzuhören. Nicht zu kommentieren oder eine Lösung vorzuschlagen. Sondern wirklich zuzuhören. Zu verstehen, worum es geht. Was dahinter liegt. Welche Perspektiven es gibt. Welche Abhängigkeiten. Welche Zwänge. Welche Wünsche.

Dann folgt der nächste Schritt: Strukturieren. Sie müssen beginnen, das Gehörte in Gedankenmodelle zu überführen. Was sind Begriffe, die immer wieder vorkommen? Was sind Zustände, was sind Übergänge, was sind Regeln? Was sind relevante Zusammenhänge – und welche sind es nicht? Und dann: Reduktion. Sie müssen entscheiden, was wirklich zählt. Sie müssen abstrahieren, verdichten, weglassen. Sie müssen aus der unendlichen Vielfalt der Realität ein Modell bauen, das gerade gut genug ist, um das Problem zu lösen – aber nicht mehr.

Und erst danach kommt das, was viele für den eigentlichen Job halten: der Code. Aber zu diesem Zeitpunkt wissen Sie längst, was Sie ausdrücken wollen. Sie haben die Struktur, Sie haben die Begriffe, Sie kennen die Regeln. Der Code ist dann nur noch das Werkzeug – nicht mehr das Denken.

Ich erinnere mich noch gut an eine Aussage eines Professors während meines Studiums. Sinngemäß sagte er:

„Das eigentliche Programmieren – das Schreiben von Code – sind nur die letzten zehn Prozent der Softwareentwicklung.“

Ich war damals irritiert. Ich dachte:

„Was soll ich denn mit den anderen 90 Prozent der Zeit anfangen?“

Heute, mit 25 Jahren mehr Erfahrung, weiß ich genau, was er damals meinte: Es ist die Zeit, die man braucht, um zu verstehen, worum es wirklich geht. Um herauszufinden, welches Problem gelöst werden soll. Um Klarheit zu schaffen, Prioritäten zu setzen, Strukturen zu entwerfen. Natürlich ist Code wichtig – keine Frage. Aber er ist eben nur der letzte Schritt. Und wenn man die neunzig Prozent davor nicht beherrscht, wird auch der Code nicht gut. Selbst dann nicht, wenn er formal korrekt ist – weil er wahrscheinlich am eigentlichen Problem vorbeigeht.

Software bildet nicht ab, was der Kunde braucht

An genau diesem Punkt kommt die KI ins Spiel. Viele Menschen machen sich derzeit Sorgen, dass ihre Fähigkeiten bald nicht mehr gebraucht werden. Dass ihr Job ersetzt wird. Dass das, was sie mit Mühe und Leidenschaft gelernt haben, plötzlich wertlos ist. Und ja: Wenn man seine Rolle so versteht, dass man Code schreibt, Anforderungen umsetzt, Dinge nach Anleitung erledigt – dann ist diese Sorge nicht unbegründet.

Denn genau diese Art von Arbeit kann eine KI heute schon gut simulieren. Sie kann Code generieren, Testfälle schreiben, Schnittstellen definieren. Sie kann sogar ganze UI-Komponenten bauen, vorausgesetzt, man beschreibt präzise, was sie tun sollen. Aber genau das ist das Problem: Sie weiß nicht, ob das, was sie umsetzt, auch sinnvoll ist. Sie hat kein Urteilsvermögen, kein Verständnis für fachliche Zusammenhänge. Keine Intuition für Ambivalenz. Keine Empathie für Unsicherheit.

Alberto Brandolini hat es einmal sehr treffend formuliert:

„The biggest problem in software development is that software is not intended to match what the customer wanted, but what the developer thought the customer wanted.“

Sinngemäß übersetzt: Software bildet nicht das ab, was der Kunde braucht, sondern das, was Entwicklerinnen und Entwickler glauben, verstanden zu haben. Dieses Missverständnis ist der Kern. Gute Software entsteht nicht dadurch, dass jemand schnell Code schreibt, sondern dadurch, dass jemand richtig versteht, was gebraucht wird, und dieses Verstehen mit Technik verbindet. Genau das ist der Teil, den KI nicht leisten kann. Zumindest nicht in absehbarer Zeit.

Sie kann Vorschläge machen, ja. Sie kann Bekanntes wiederholen. Aber sie kann nicht in einem Gespräch zwischen Fachbereich und Entwicklungsteam heraushören, was zwischen den Zeilen gesagt wurde. Sie kann keine fehlenden Fragen stellen. Keine impliziten Annahmen entlarven. Keine Missverständnisse auflösen. Dafür braucht es Menschen.

Die Relevanz von Sprache

Wenn Sie gute Software bauen wollen – langlebige, robuste, fachlich saubere Systeme –, dann müssen Sie Sprache ernst nehmen. Und damit ist nicht die Programmiersprache gemeint, sondern die natürliche Sprache. Denn Sprache ist das Medium, durch das wir Komplexität greifbar machen. Sie ist die Brücke zwischen dem, was Menschen sagen, und dem, was Maschinen tun.

Deshalb ist etwa Domain-Driven Design (DDD) ein so wertvoller Ansatz. DDD stellt die gemeinsame Sprache zwischen Entwicklungsteam und Fachabteilung ins Zentrum. Es geht nicht um Technologien, Frameworks oder Tools – sondern um Begriffe, Bedeutungen, Modelle. Sie entwickeln gemeinsam ein tiefes Verständnis dafür, wie die Welt der Anwenderinnen und Anwender funktioniert. Welche Konzepte es gibt, welche Regeln gelten, was typisch ist – und was nicht.

Aus diesem gemeinsamen Verständnis entsteht das Modell der Software. Keine Tabellen. Keine Klassen. Keine Funktionen. Sondern ein fachliches Modell, das Sie in einem letzten Schritt in Code übersetzen.

Wenn Sie wissen möchten, wie man solche Modelle haltbar macht – wie man Systeme so aufbaut, dass die Fachlichkeit sichtbar bleibt, dass Entscheidungen nachvollziehbar sind, dass die Sprache erhalten bleibt –, dann lohnt sich ein Blick auf Domain-Driven Design und auch auf Event-Sourcing. Es sind zwei Ansätze, die wir sehr intensiv verfolgen – und zu denen wir bereits zahlreiche Videos und auch Artikel veröffentlicht haben.

Weniger Code, mehr Software

Zum Schluss möchte ich kurz schildern, wie sich mein eigenes Verständnis von Softwareentwicklung im Laufe der Zeit verändert hat. Als ich anfing, wollte ich möglichst viel Code schreiben. Ich wollte effizient sein, clever, schnell. Ich wollte neue Frameworks ausprobieren, neue Patterns anwenden, spannende Architekturen bauen. Und ganz ehrlich: Ich dachte lange, dass das der eigentliche Job sei.

Aber mit den Jahren habe ich gemerkt: Die spannendsten und wichtigsten Aspekte meiner Arbeit haben gar nichts mit Code zu tun. Es sind die Gespräche, die Diskussionen, die Versuche, etwas wirklich zu verstehen. Die Momente, in denen jemand sagt:

„Ach das ist gemeint!“

Und plötzlich wird etwas klar. Oder die Momente, in denen ich erkenne, dass eine Anforderung gar keine Lösung ist, sondern ein Workaround für ein ganz anderes, tieferliegendes Problem.

Heute schreibe ich deutlich weniger Code als früher – aber ich entwickle mehr Software. Weil ich mich auf das konzentriere, was zwischen den Menschen passiert: auf Sprache, auf Verstehen, auf Struktur. Und ich bin überzeugt: Genau das ist es, was Entwicklerinnen und Entwickler unersetzlich macht. Nicht, dass sie JavaScript oder Go oder TypeScript beherrschen. Sondern, dass sie Menschen verstehen können – und aus einem Problem eine Lösung entwickeln, die nicht nur funktioniert, sondern langfristig trägt.

Was man eigentlich lernen sollte

Also: Lernen Sie bloß nicht programmieren – wenn Sie glauben, dass das genügt. Wenn Sie glauben, dass Sie durch das Erlernen einer Programmiersprache zur Entwicklerin oder zum Entwickler werden, dann begehen Sie denselben Denkfehler wie viele andere vor Ihnen. Lernen Sie stattdessen, zu verstehen. Lernen Sie zuzuhören. Lernen Sie zu abstrahieren. Lernen Sie, ein Problem in ein Modell zu überführen – und daraus ein System zu entwickeln. Und dann, ganz zum Schluss, lernen Sie, wie Sie das in Code ausdrücken.

Dann brauchen Sie keine Bootcamp-Versprechen – und auch keine Angst vor der KI. Denn dann sind Sie kein Coder. Dann sind Sie Softwareentwicklerin oder Softwareentwickler. Und die werden auch in Zukunft gebraucht – vielleicht mehr denn je.

Vielleicht haben Sie sich beim Lesen dieses Beitrags gefragt, warum ich ihn so provokant betitelt habe: „Lern bloß nicht programmieren!“

Und ja – der Titel ist bewusst zugespitzt. Er soll irritieren. Vielleicht auch kurz aufregen. Aber er verfolgt einen klaren Zweck: Ich wollte Ihre Aufmerksamkeit auf genau jenes Missverständnis lenken, das ich im Text herausgearbeitet habe. Denn viel zu viele Menschen glauben, dass das Lernen einer Programmiersprache gleichbedeutend damit sei, Softwareentwicklerin oder Softwareentwickler zu sein. Und mit diesem Beitrag wollte ich einen Kontrapunkt setzen – und zeigen, worauf es wirklich ankommt: Auf das Verstehen. Auf die Fähigkeit, Komplexität zu erfassen, Sprache ernst zu nehmen, Modelle zu entwickeln. Und erst dann – ganz am Ende – kommt der Code.

In diesem Sinne: Lernen Sie programmieren. Aber lernen Sie es als Werkzeug – nicht als Ziel.

(rme)