Die Geschichte der Softwareentwicklung

Erstfassung 20. Oktober 2026, zuletzt geändert am 23. Oktober 2026 · Andreas Stockter

Software ist der Teil eines Computers, den man nicht anfassen kann: die Anweisungen, die der Rechner ausführt. Softwareentwicklung ist die Arbeit, diese Anweisungen zu schreiben, zu prüfen und über Jahre am Leben zu halten. Die Geschichte dieses Handwerks ist kurz, aber dicht: In achtzig Jahren wurde aus dem Umstecken von Kabeln ein Beruf, den weltweit Dutzende Millionen Menschen ausüben, und zuletzt eine Tätigkeit, die Maschinen zum Teil selbst übernehmen.

Wie die Geschichte der KI folgt dieser Text einer Kette: Jede Epoche löst einen Engpass, den die vorherige offen gelassen hat, und schafft dabei den nächsten. Erst war die Maschine der Engpass, dann die Sprache, dann die Größe der Programme, dann die Organisation der Menschen, dann die Geschwindigkeit der Welt. Jeder Fachbegriff ist an der Stelle fett gesetzt, an der er erklärt wird, und wird erst danach verwendet. Ein Glossar führt alle Begriffe alphabetisch auf.

Inhalt: 1 Vorgeschichte · 2 Die ersten Sprachen · 3 Softwarekrise · 4 Objekte und PC · 5 Internet und Open Source · 6 Agil, Git und Cloud · 7 KI-gestützte Entwicklung · Die Kette in Kurzform · Zeitleiste · Weiterlesen · Quellen

1. Vorgeschichte (1840er–1940er)

Das erste Programm. Die Idee, einer Maschine eine Folge von Anweisungen mitzugeben, ist älter als der Computer. 1804 steuerte Joseph-Marie Jacquard in Lyon einen Webstuhl mit Lochkarten: Jede Karte legte fest, welche Fäden sich heben, und eine Kette von Karten webte ein Muster. Charles Babbage übernahm die Lochkarte um 1837 für seine Analytical Engine, eine mechanische Rechenmaschine, die nie fertig wurde, aber auf dem Papier alles hatte, was einen Computer ausmacht: ein Rechenwerk, einen Speicher und eine Steuerung, die je nach Zwischenergebnis verzweigen konnte.

Ada Lovelace übersetzte 1843 einen Aufsatz über die Maschine und fügte Anmerkungen hinzu, die länger wurden als der Aufsatz. In der letzten beschreibt sie Schritt für Schritt, wie die Maschine die Bernoulli-Zahlen berechnen würde, mit Schleifen und Zwischenspeichern. Es gilt als das erste Programm: eine Folge von Anweisungen, die eine Maschine ausführen soll. Lovelace sah auch, dass die Maschine nicht nur mit Zahlen rechnen könnte, sondern mit allem, was sich in Symbolen ausdrücken lässt, Musik eingeschlossen.¹

Die Lochkarte selbst machte Karriere, bevor es Computer gab. Herman Hollerith wertete mit ihr 1890 die amerikanische Volkszählung aus, in zwei Jahren statt acht, und seine Firma wurde 1924 zu IBM. Vier Jahrzehnte lang war Datenverarbeitung das Sortieren und Zählen von Karten, und als die Computer kamen, erbten sie Kartenleser, Kartenlocher und die Gewohnheit, ein Programm als Stapel zu denken.

Die ersten Rechner. 1941 nahm Konrad Zuse in Berlin die Z3 in Betrieb, den ersten funktionsfähigen programmgesteuerten Rechner. Das Programm stand als Lochfolge auf gebrauchtem Kinofilm, der durch einen Leser lief. Zuse dachte auch als Erster darüber nach, wie man Programme für Menschen lesbar aufschreibt: Sein Plankalkül, zwischen 1942 und 1945 entworfen, war die erste höhere Programmiersprache, mit Variablen, Schleifen und Datenstrukturen. Er wurde erst 1972 veröffentlicht und beeinflusste niemanden, aber er zeigt, dass die Frage nach der Sprache so alt ist wie die Maschine.²

Der amerikanische ENIAC, 1945 fertiggestellt, rechnete tausendmal schneller als alles Vorherige, war aber nicht programmierbar im heutigen Sinn. Eine neue Aufgabe bedeutete, Hunderte Kabel umzustecken und Schalter zu setzen, eine Arbeit von Tagen. Sie wurde von sechs Mathematikerinnen erledigt, die man damals „Computer“ nannte, weil das Wort noch den Menschen bezeichnete, der rechnet. Sie waren die ersten Programmiererinnen, und sie entwickelten unterwegs die ersten Techniken des Fachs, etwa das Nachspielen des Programms auf dem Papier, um Fehler zu finden.

Das gespeicherte Programm. Die Lösung für das Umstecken formulierte John von Neumann 1945 in einem Bericht über den Nachfolgerechner EDVAC: Das Programm liegt wie die Daten im Speicher, als Zahlen. Dann lässt es sich in Sekunden austauschen, und ein Programm kann sogar andere Programme als Daten behandeln, also lesen, verändern und erzeugen.³ Die Idee war in Turings Arbeit von 1936 angelegt, und von Neumanns Bericht machte sie zum Bauplan. Am 21. Juni 1948 lief in Manchester das erste gespeicherte Programm auf dem Versuchsrechner „Baby“: 17 Anweisungen, die den größten Teiler einer Zahl suchten, 52 Minuten lang. 1949 folgte in Cambridge der EDSAC, der erste solche Rechner für den täglichen Betrieb.

Mit ihm begann die Softwareentwicklung als Tätigkeit. Ein Programm für den EDSAC war eine Folge von Zahlen in Maschinensprache, dem Befehlsvorrat, den die Hardware direkt versteht: Lade Speicherzelle 100, addiere Zelle 101, springe zu Befehl 7. David Wheeler, ein Student in Cambridge, ersann dafür zwei Hilfen, die bis heute das Fundament bilden. Erstens den Assembler, ein Programm, das Befehle mit Kurzwörtern wie ADD statt Zahlencodes annimmt und sie in Maschinensprache übersetzt. Zweitens das Unterprogramm: ein Stück Programm, das eine Aufgabe erledigt, etwa eine Wurzel ziehen, und von überall aufgerufen werden kann. Cambridge legte eine Bibliothek solcher Unterprogramme auf Lochstreifen an, und das Buch von Wilkes, Wheeler und Gill von 1951 war das erste Lehrbuch des Programmierens.⁴

Ein Beispiel: Zwei Zahlen addieren und das Ergebnis ablegen hieß in Maschinensprache drei Zahlenwörter, etwa 01 100, 02 101, 03 102. Im Assembler wurde daraus:

LOAD  A      ; Zahl aus Zelle A in das Rechenwerk holen
ADD   B      ; Zahl aus Zelle B dazuzählen
STORE C      ; Ergebnis in Zelle C ablegen

Der Assembler ersetzte die Kurzwörter und die Namen der Zellen durch die Zahlen, die die Maschine erwartete. Das Lesen wurde leichter, das Denken blieb das der Maschine.

Maurice Wilkes, der Leiter des EDSAC, erinnerte sich später an einen Moment im Jahr 1949 auf der Treppe zwischen Rechnerraum und Lochstreifengerät: Ihm wurde klar, dass er einen guten Teil seines Lebens damit verbringen würde, Fehler in seinen eigenen Programmen zu suchen. Ein solcher Fehler heißt Bug. Das Wort ist älter als der Computer, aber Grace Hoppers Team klebte 1947 eine Motte, die ein Relais des Harvard Mark II blockiert hatte, ins Logbuch, mit dem Vermerk „erster tatsächlicher Fall eines Bugs“. Das Suchen und Beheben heißt seitdem Debugging.

Der Engpass. Jedes Programm wurde in der Sprache genau einer Maschine geschrieben, Befehl für Befehl, und war wertlos, sobald die Maschine ersetzt wurde. Programmieren war Expertenarbeit für wenige Dutzend Menschen pro Rechner, und ein Rechner kostete mehr als alle, die an ihm arbeiteten.

2. Die ersten Sprachen (1950er)

Der Compiler. Grace Hopper, Marineoffizierin und Mathematikerin, hatte am Harvard Mark I programmiert und wechselte 1949 zur Firma, die den UNIVAC baute. Sie wollte, dass Programme nicht mehr in Maschinensprache geschrieben werden müssen. 1952 stellte sie A-0 vor, ein Programm, das aus einer Folge von Unterprogrammaufrufen ein lauffähiges Programm zusammensetzte, und nannte es Compiler: ein Programm, das Programme aus einer für Menschen lesbaren Form in Maschinensprache übersetzt.⁵ Ihr FLOW-MATIC, ab 1955 entwickelt, nahm Befehle in englischen Wörtern entgegen. Hopper berichtete, die Idee sei anfangs verlacht worden, weil Computer angeblich nur rechnen und nicht Englisch verstehen könnten.

Fortran. Den Durchbruch brachte 1957 ein Team bei IBM um John Backus. Backus hatte 1954 vorgeschlagen, eine Sprache zu bauen, in der Formeln so stehen wie in der Mathematik, und einen Compiler, der daraus Maschinencode erzeugt, der so schnell läuft wie handgeschriebener. Die Fachwelt hielt das Zweite für unmöglich. Nach drei Jahren Arbeit erschien Fortran („Formula Translation“), die erste verbreitete Hochsprache, also eine Programmiersprache, die von der Maschine abstrahiert und dieselbe für verschiedene Rechner sein kann.⁶ Eine Zeile wie Y = A*X**2 + B*X + C ersetzte Dutzende Maschinenbefehle, und die Zahl der Programmierzeilen für eine Aufgabe sank auf ein Zwanzigstel. Fortran machte das Programmieren für Wissenschaftler und Ingenieure zugänglich, die keine Maschinensprache lernen wollten, und wird in der numerischen Simulation bis heute benutzt.

Der Compiler ist das Werkzeug, das dieses Kapitel möglich macht. Er liest den Quelltext, das vom Menschen geschriebene Programm, prüft ihn auf Form und Sinn, und erzeugt daraus den ausführbaren Code. Sein Gegenstück ist der Interpreter, der den Quelltext nicht übersetzt, sondern Zeile für Zeile beim Lesen ausführt, langsamer, aber ohne Wartezeit. Beide Wege begleiten das Fach bis heute, Fortran und C auf der einen Seite, Python und JavaScript auf der anderen.

Vier Sprachen, vier Richtungen. Binnen weniger Jahre entstanden die Vorfahren fast aller heutigen Sprachen. Lisp (1958) von John McCarthy, in der Geschichte der KI beschrieben, behandelte Programme selbst als Daten und führte die Rekursion und die Garbage Collection ein, die automatische Speicherverwaltung, bei der das System nicht mehr benötigten Speicher von selbst freigibt. COBOL (1959) wurde von einem Ausschuss aus Behörden und Herstellern für die Geschäftswelt entworfen, mit Sätzen wie ADD TAX TO TOTAL, damit auch Nicht-Programmierer Programme lesen können. Hoppers FLOW-MATIC war das Vorbild. COBOL verarbeitete Gehaltsabrechnungen und Kontobewegungen, und ein Großteil des Zahlungsverkehrs läuft noch heute über COBOL-Programme, die älter sind als ihre Betreuer.

Algol 60 schließlich war das Werk eines internationalen Komitees und weniger ein Produkt als eine Idee: Blöcke, die Variablen verstecken, Prozeduren, die sich selbst aufrufen, und eine exakte Beschreibung der Sprache in einer formalen Notation, der Backus-Naur-Form, mit der sich die Grammatik einer Programmiersprache so präzise aufschreiben lässt wie ein Beweis.⁷ Algol selbst wurde wenig benutzt, aber Pascal, C, Java und fast alles danach stammen von ihm ab. Tony Hoare sagte später, Algol 60 sei seiner Zeit so weit voraus gewesen, dass es nicht nur seine Vorgänger, sondern auch fast alle seine Nachfolger übertroffen habe.

So sieht die Backus-Naur-Form aus, hier für ganze Zahlen:

<Ziffer> ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
<Zahl>   ::= <Ziffer> | <Zahl> <Ziffer>

Die zweite Zeile sagt: Eine Zahl ist eine Ziffer, oder eine Zahl gefolgt von einer Ziffer. Mit zwei Zeilen sind alle Zahlen beliebiger Länge beschrieben, und ein Compiler kann aus solchen Regeln den Teil erzeugen, der den Quelltext zerlegt.

BASIC entwarfen die Mathematiker John Kemeny und Thomas Kurtz am Dartmouth College für Studenten, die keine Informatiker werden wollten; das erste Programm lief am 1. Mai 1964 um vier Uhr morgens.⁸ Es lief auf einem Time-Sharing-System, bei dem viele Nutzer gleichzeitig an Fernschreibern sitzen und der Rechner zwischen ihnen hin und her springt, so schnell, dass jeder glaubt, ihn allein zu haben. Das Programmieren im Dialog, Zeile eingeben, sofort ausführen, Fehler sehen, war eine neue Erfahrung. Zehn Jahre später machte BASIC die ersten Heimcomputer bedienbar.

Der Engpass. Die Sprachen hatten das Schreiben einzelner Programme um ein Vielfaches beschleunigt, und genau deshalb wurden die Programme größer. Ein Rechner konnte jetzt ein Betriebssystem haben, ein Programm, das die anderen verwaltet, und das erste große stellte die Branche vor ein Problem, das keine Sprache löst.

3. Softwarekrise und strukturierte Programmierung (1960er–1970er)

OS/360. 1964 kündigte IBM das System/360 an, eine ganze Familie von Rechnern, die alle dieselben Programme ausführen sollten, vom kleinen Büromodell bis zur Großanlage. Das Betriebssystem dafür, OS/360, sollte alles zugleich sein: Programme laden, Speicher und Geräte verwalten, mehrere Aufgaben nebeneinander laufen lassen. Es wurde das größte Programm, das je geschrieben worden war, mehr als eine Million Zeilen, und es kam Jahre zu spät, verschlang ein Vielfaches des Budgets und war bei Auslieferung voller Fehler. Fred Brooks, der das Projekt leitete, zog daraus 1975 die Lehren in einem Buch, das bis heute gelesen wird: „The Mythical Man-Month“. Seine wichtigste Beobachtung heißt Brooks’ Gesetz: Wer einem verspäteten Softwareprojekt Entwickler hinzufügt, verzögert es nur noch weiter, weil die neuen eingearbeitet werden müssen und die Zahl der Abstimmungen mit der Zahl der Beteiligten explodiert. Neun Frauen bringen kein Kind in einem Monat zur Welt.⁹ In Zahlen: Bei n Beteiligten gibt es n(n − 1)/2 Gesprächswege, bei drei sind es drei, bei zehn 45, bei fünfzig 1.225.

Die Softwarekrise. OS/360 war kein Einzelfall. Ende der 1960er Jahre wurden große Programme regelmäßig zu spät fertig, zu teuer und unzuverlässig, während die Hardware jedes Jahr billiger und schneller wurde. Im Oktober 1968 lud die NATO rund fünfzig Fachleute nach Garmisch-Partenkirchen, um darüber zu reden. Der Münchner Informatiker Friedrich L. Bauer hatte der Konferenz einen provokanten Titel gegeben: Software Engineering, Softwaretechnik. Der Name war ein Programm: Software sollte so entworfen und gebaut werden wie Brücken, mit Methoden, Maßen und Verantwortung, statt als Kunsthandwerk. Der Tagungsbericht prägte den Begriff Softwarekrise für den Zustand, dass die Nachfrage nach Programmen und ihre Größe schneller wuchsen als die Fähigkeit, sie zuverlässig zu bauen.¹⁰

Dass es anders gehen konnte, zeigte im selben Jahr ein Projekt, das die Konferenz noch nicht kannte. Die Software für den Bordcomputer der Apollo-Mondlandefähre, geleitet von Margaret Hamilton am MIT, war so gebaut, dass sie bei Überlastung unwichtige Aufgaben abwarf und die wichtigen weiterrechnete. Drei Minuten vor der Landung am 20. Juli 1969 meldete der Rechner genau diese Überlastung, und weil die Software sie vorgesehen hatte, konnte die Landung weitergehen. Hamilton nannte ihre Arbeit „Software Engineering“, als der Ausdruck noch belächelt wurde.

Strukturierte Programmierung. Die Antwort auf die Krise kam aus der Theorie. Edsger Dijkstra, ein niederländischer Mathematiker, schrieb 1968 einen Leserbrief mit dem Titel „Go To Statement Considered Harmful“. Der Sprungbefehl goto, mit dem ein Programm an eine beliebige andere Stelle springt, war in allen Sprachen seit der Maschinensprache selbstverständlich. Dijkstra zeigte, dass er Programme unlesbar macht: Wer wissen will, wie das Programm an eine Stelle gekommen ist, muss alle Sprünge kennen, die dorthin führen. Die Qualität eines Programmierers, schrieb er, nehme mit der Zahl seiner goto-Anweisungen ab.¹¹

Die Alternative heißt strukturierte Programmierung: Ein Programm wird nur aus drei Bausteinen zusammengesetzt, der Folge von Anweisungen, der Verzweigung (wenn, dann, sonst) und der Schleife (solange, wiederhole). Corrado Böhm und Giuseppe Jacopini hatten 1966 bewiesen, dass diese drei für jedes Programm ausreichen. Jeder Baustein hat einen Eingang und einen Ausgang, und so lässt sich ein Programm von oben nach unten lesen wie ein Text. Niklaus Wirth baute 1970 die Sprache Pascal um diese Idee und erzog damit eine Generation von Studenten, und das Buch „Structured Programming“ von Dahl, Dijkstra und Hoare (1972) machte sie zur Lehre.

Dasselbe Stück Programm, einmal mit Sprüngen, einmal strukturiert. Beide zählen von 1 bis 10:

10 LET I = 1                   I = 1
20 PRINT I                     WHILE I <= 10
30 LET I = I + 1                   PRINT I
40 IF I <= 10 THEN GOTO 20         I = I + 1
                               END WHILE

Links muss man den Zeilennummern folgen, um zu sehen, dass eine Schleife gemeint ist. Rechts steht die Schleife als Block da, mit Anfang und Ende.

Module. Den zweiten Baustein lieferte David Parnas 1972. Große Programme, so sein Vorschlag, zerlegt man in Module, Teile mit einer klaren Aufgabe und einer Schnittstelle, also einer festgelegten Menge von Aufrufen, über die andere Teile mit ihnen reden. Was im Inneren eines Moduls geschieht, etwa wie Daten gespeichert sind, bleibt verborgen, damit es sich ändern lässt, ohne dass die anderen Module davon erfahren. Dieses Geheimnisprinzip (information hiding) ist die Grundlage jeder Software, die größer ist als ein Mensch.¹²

Das Wasserfallmodell. Winston Royce beschrieb 1970 in einem Aufsatz, wie große Softwareprojekte damals liefen: Anforderungen festlegen, dann entwerfen, dann programmieren, dann testen, dann betreiben, jede Stufe abgeschlossen, bevor die nächste beginnt, wie Wasser, das über Stufen fällt. Royce schrieb den Aufsatz, um vor diesem Ablauf zu warnen: Die Fehler des Entwurfs zeigen sich erst beim Testen, und dann ist es teuer, zurückzugehen. Er schlug fünf Ergänzungen vor: einen vorläufigen Entwurf vor der Analyse, ausführliche Dokumentation, unabhängige Testplanung, laufende Prüfungen mit dem Kunden und vor allem „do it twice“: Die ausgelieferte Fassung soll die zweite sein, nach einem Vorabmodell im kleinen Maßstab, dem Prototyp, zwanzig Jahre bevor das Wort üblich wurde. Seine Abbildungen zeigen Pfeile zurück von jeder Stufe zur vorherigen und vom Test zurück zum Entwurf. Trotzdem wurde das Wasserfallmodell, so benannt erst 1976 von Autoren, die seine Abbildung zitierten, für Jahrzehnte zum Standard. Der Softwarestandard des amerikanischen Verteidigungsministeriums schrieb 1985 genau den einfachen Ablauf vor, vor dem Royce gewarnt hatte, und Behörden und Konzerne folgten ihm.¹³

Unix und C. Während die Konzerne an Riesensystemen litten, entstand in den Bell Labs das Gegenmodell. Ken Thompson schrieb 1969 auf einem ausrangierten Kleinrechner ein Betriebssystem, das klein, elegant und für Programmierer gedacht war: Unix. Sein Kollege Dennis Ritchie entwarf 1972 dafür die Sprache C, nah an der Maschine, aber mit den Strukturen von Algol, und 1973 schrieben die beiden Unix in C neu. Zum ersten Mal war ein Betriebssystem in einer Hochsprache geschrieben und ließ sich auf andere Rechner übertragen, was später zu seiner Verbreitung an Universitäten führte.¹⁴

Unix brachte eine Denkweise mit, die bis heute wirkt: viele kleine Programme, die je eine Sache gut tun, und ein Mechanismus, die Pipe, mit dem man die Ausgabe des einen in die Eingabe des nächsten leitet. Statt eines großen Programms baut man eine Kette aus Werkzeugen. Dazu kam ein Dateisystem, in dem alles eine Datei ist, auch Geräte, und ein Quelltext, der an Universitäten gegen eine Gebühr weitergegeben wurde, sodass Studenten ihn lesen und verändern konnten. Berkeley baute darauf eine eigene Fassung, BSD, die das Internet-Protokoll bekam.

Ein Beispiel, das bis heute in jedem Unix-Terminal funktioniert:

grep Fehler protokoll.txt | sort | uniq -c | sort -rn | head -5

Das erste Werkzeug sucht alle Zeilen mit „Fehler“ heraus, das zweite sortiert sie, das dritte zählt gleiche Zeilen, das vierte sortiert nach Häufigkeit, das fünfte zeigt die ersten fünf. Fünf Programme, die nichts voneinander wissen, beantworten gemeinsam die Frage, welche Fehler am häufigsten vorkommen.

Software wird Ware. Bis 1969 lieferte IBM Software kostenlos mit der Hardware, als Zugabe wie das Handbuch. Unter dem Druck eines Kartellverfahrens trennte IBM im Juni 1969 die Preise für Hardware und Software, das Unbundling. Von da an war Software ein eigenes Produkt mit eigenem Preis, und eine Industrie entstand, die nur Programme verkaufte. Zur selben Zeit begann Donald Knuth sein Werk „The Art of Computer Programming“ (ab 1968), das die Algorithmen des Fachs mathematisch durchdrang und dem Programmieren den Anspruch gab, Wissenschaft und Kunst zugleich zu sein.¹⁵

Selbst ausprobieren. Der Compiler Explorer zeigt im Browser neben jeder Zeile C-Code die Maschinenbefehle, die der Compiler daraus macht; man sieht, was Fortran 1957 den Programmierern abnahm. Ein EDSAC-Simulator der Universität Warwick lässt die Programme von 1949 auf dem Bildschirm laufen, mit Lochstreifen und Röhrenanzeige. Und jedes Terminal auf Mac oder Linux versteht die Pipe von oben; wer sie einmal tippt, versteht Unix.¹⁶

Der Engpass. Strukturierte Programme und Module machten große Systeme beherrschbar, solange die Teile sich an ihre Schnittstellen hielten. Aber die Teile wurden in Sprachen geschrieben, die Daten und die Funktionen, die darauf arbeiten, getrennt hielten, und mit jeder Änderung der Datenstruktur mussten alle Funktionen nachgezogen werden. Zugleich stand ein Umbruch bevor, den niemand in Garmisch vorhergesehen hatte: Der Rechner wurde so billig, dass er auf den Schreibtisch passte.

4. Objekte und persönliche Computer (1980er)

Objekte. Die Idee kam aus Norwegen. Ole-Johan Dahl und Kristen Nygaard hatten 1967 für Simulationen die Sprache Simula entworfen, in der man Dinge der wirklichen Welt, etwa Schiffe in einem Hafen, als Objekte beschreibt: Jedes trägt seine Daten und die Operationen, die darauf arbeiten, zusammen in sich. Eine Klasse ist der Bauplan für Objekte gleicher Art, und eine Klasse kann von einer anderen erben, also deren Daten und Operationen übernehmen und ergänzen. Ein Konto zum Beispiel trägt als Daten den Kontostand und als Operationen Einzahlen und Abheben; jedes einzelne Konto ist ein Objekt, der Bauplan aller Konten die Klasse, und ein Sparkonto erbt von ihr und ergänzt die Zinsen. Alan Kay nahm die Idee am Forschungszentrum Xerox PARC auf und machte sie zum Prinzip einer ganzen Sprache: In Smalltalk (1972 bis 1980) ist alles ein Objekt, und Objekte reden miteinander, indem sie Nachrichten schicken. Kay dachte dabei an biologische Zellen, die unabhängig arbeiten und sich über Botenstoffe abstimmen.¹⁷ Dieses Denken heißt objektorientierte Programmierung: Software als Gesellschaft kooperierender Objekte statt als Folge von Anweisungen über Daten.

Smalltalk lief auf dem Alto, einem Rechner, den PARC 1973 gebaut hatte und der aussah wie die Zukunft: Bildschirm mit Fenstern und Symbolen, Maus, Netzwerk. Die Programmierumgebung war Teil des Systems, man konnte jedes Objekt anklicken, seinen Code ansehen und im laufenden Betrieb ändern. Steve Jobs sah den Alto 1979 und baute daraus den Macintosh.

Bjarne Stroustrup brachte die Objekte 1983 in die Welt der Systemprogrammierer: C++ fügte C Klassen hinzu, ohne die Nähe zur Maschine aufzugeben, und wurde zur Sprache für Betriebssysteme, Datenbanken, Spiele und alles, was schnell sein muss.¹⁸ Objective-C tat 1984 dasselbe mit Smalltalk-Nachrichten und wurde bei NeXT und später bei Apple heimisch. Bis zur Jahrtausendwende hatte sich die objektorientierte Programmierung als Normalform durchgesetzt, und das Buch „Design Patterns“ von Gamma, Helm, Johnson und Vlissides (1994) gab den wiederkehrenden Bauformen Namen, in denen Entwickler bis heute miteinander reden: Factory, Observer, Adapter, also eine Klasse, die Objekte erzeugt; ein Objekt, das Änderungen an alle Angemeldeten meldet; ein Zwischenstück, das zwei unpassende Schnittstellen verbindet.¹⁹

Der persönliche Computer. Im Januar 1975 stand auf dem Titel der Zeitschrift „Popular Electronics“ der Altair 8800, ein Bausatz für 397 Dollar, der nichts konnte außer Lämpchen blinken lassen. Zwei Studenten in Harvard, Bill Gates und Paul Allen, schrieben dafür in acht Wochen einen BASIC-Interpreter, ohne die Maschine je gesehen zu haben, und gründeten dafür Microsoft. Gates’ „Offener Brief an die Hobbyisten“ vom Februar 1976 beklagte, dass die meisten Nutzer das BASIC kopierten, statt es zu kaufen, und markierte den Streit, der das Fach seitdem begleitet: Ist Software ein Gut, das man besitzt und verkauft, oder ein Wissen, das man teilt?²⁰

Der Apple II (1977) brachte den Rechner ins Wohnzimmer, und 1979 zeigte VisiCalc, die erste Tabellenkalkulation, wozu er gut war: Ein Buchhalter konnte ein Zahlenblatt ändern und sah sofort alle Folgen. Es war die erste Killer-App, ein Programm, für das Menschen einen Computer kaufen. 1981 folgte der IBM PC mit dem Betriebssystem MS-DOS von Microsoft, das IBM nicht gekauft, sondern nur lizenziert hatte. Der Fehler kostete IBM den Markt und machte Microsoft zum größten Softwarehersteller der Welt. Der Macintosh brachte 1984 Fenster und Maus zu den Massen, Windows zog 1990 nach.

Werkzeuge. Mit dem PC wurde das Programmieren zur Tätigkeit am eigenen Schreibtisch, und die Werkzeuge rückten zusammen. Turbo Pascal (1983) von Borland kostete 50 Dollar und vereinte Editor, Compiler und Debugger in einem Programm, der ersten verbreiteten integrierten Entwicklungsumgebung (IDE), in der man eine Zeile ändert und Sekunden später das Ergebnis sieht. Die Rückkopplungsschleife, die auf dem Großrechner Stunden gedauert hatte, Lochkarten abgeben, am nächsten Tag das Protokoll holen, schrumpfte auf Augenblicke, und das veränderte, wie man programmiert: probierend statt planend.

Freie Software. Richard Stallman, Programmierer am MIT, hatte erlebt, wie die offene Kultur der Labore verschwand, als Firmen Quelltexte unter Verschluss nahmen. 1983 kündigte er GNU an, ein Betriebssystem, das Unix gleicht, aber von jedem benutzt, gelesen, verändert und weitergegeben werden darf, und schrieb dafür Compiler, Editor und Werkzeuge.²¹ Sein juristischer Kunstgriff war die GNU General Public License (1989): Wer freie Software verändert und weitergibt, muss den Quelltext mitgeben und die Freiheit weiterreichen. Diese Lizenz, die Erlaubnis, Software unter bestimmten Bedingungen zu nutzen, machte aus einer Haltung ein Rechtsinstrument, und sie fehlte nur noch ein Kern, um ein vollständiges System zu ergeben.

Software, die tötet. Zwischen 1985 und 1987 verabreichte das Bestrahlungsgerät Therac-25 sechs Patienten massive Überdosen, drei von ihnen starben. Die Ursache lag in der Software: Ein Wettlauf zwischen zwei Programmteilen, der nur auftrat, wenn die Bedienerin schneller tippte, als die Entwickler es sich vorgestellt hatten. Die ältere Baureihe hatte eine mechanische Sicherung gehabt, die man dem Programm zuliebe eingespart hatte. Die Untersuchung von Nancy Leveson wurde zum Lehrstück dafür, dass Software, die über Leben entscheidet, anderen Regeln folgen muss, und begründete das Fach der Softwaresicherheit.²²

Der Engpass. Objekte, IDEs und der PC hatten das Programmieren für einen einzelnen Entwickler so produktiv gemacht wie nie. Aber jedes Programm lief auf einem Rechner und wurde als Diskette im Karton verkauft. Die Rechner begannen, miteinander zu reden, und damit änderte sich, wie Software entsteht und wen sie erreicht.

5. Internet und Open Source (1990er)

Linux. Am 25. August 1991 schrieb ein 21-jähriger Student in Helsinki in eine Diskussionsgruppe, er arbeite an einem freien Betriebssystem, „nur ein Hobby, nichts Großes und Professionelles“. Linus Torvalds hatte einen Betriebssystemkern für seinen PC geschrieben, und weil er ihn ins Netz stellte und jeden Beitrag annahm, der gut war, wuchs Linux binnen weniger Jahre zu einem vollständigen System, zusammen mit den GNU-Werkzeugen, die Stallman vorbereitet hatte.²³ Tausende Freiwillige, die sich nie trafen, bauten das Betriebssystem, das heute auf fast jedem Server, jedem Android-Telefon und dem größten Teil der Cloud läuft. Der Kern hatte 1991 rund 10.000 Zeilen, heute sind es über 30 Millionen, und an jeder neuen Version arbeiten mehrere tausend Entwickler mit. Die Entwicklung lief über E-Mail-Listen: Wer eine Änderung hatte, schickte sie als Patch, einen Text, der nur die geänderten Zeilen enthält, und Torvalds nahm an oder lehnte ab.

So sieht ein Patch aus, hier eine Änderung von einer Zeile:

--- a/zaehler.c
+++ b/zaehler.c
@@ -12,3 +12,3 @@
     summe = summe + wert;
-    if (zaehler > 100)
+    if (zaehler >= 100)
         ausgabe(summe);

Die Zeile mit dem Minus wird entfernt, die mit dem Plus eingefügt, die Zeilen darum zeigen, wo im Programm das geschieht. Mehr braucht ein Prüfer nicht, um die Änderung zu beurteilen.

Das Web. Tim Berners-Lee schlug 1989 am CERN ein System vor, um Dokumente über das Internet zu verknüpfen, und baute es 1990 und 1991: eine Seitenbeschreibungssprache, HTML, ein Übertragungsprotokoll, HTTP, und ein Programm zum Lesen, den Browser.²⁴ Der Browser Mosaic (1993) zeigte Bilder im Text und machte das Web populär, Netscape (1994) kommerziell. Für Programmierer bedeutete das Web zweierlei. Erstens eine neue Plattform: Ein Programm musste nicht mehr installiert werden, es lief auf einem Server, und jeder mit Browser konnte es benutzen. Zweitens einen Markt, der sich alle paar Monate änderte, in dem der Erste gewann, der etwas Brauchbares lieferte, und der die Planung von Jahresprojekten lächerlich machte.

Neue Sprachen für das Netz. Brendan Eich schrieb 1995 in zehn Tagen eine Sprache, die im Browser läuft, damit Webseiten sich bewegen und auf Eingaben reagieren: JavaScript, heute die am meisten benutzte Sprache der Welt. Im selben Jahr stellte Sun Java vor, mit dem Versprechen „einmal schreiben, überall ausführen“: Der Compiler erzeugt keinen Maschinencode, sondern Bytecode, einen Zwischencode, den eine virtuelle Maschine auf jedem Rechner ausführt, der sie hat. Java wurde die Sprache der Unternehmensserver und später von Android. Guido van Rossum hatte 1991 Python veröffentlicht, eine Skriptsprache, also eine interpretierte Sprache für schnelle, kurze Programme, die lesbar sein sollte wie Pseudocode. Sie wuchs langsam und wurde drei Jahrzehnte später zur Sprache der Datenanalyse und der KI. Perl (1987) und PHP (1995) trieben die ersten dynamischen Webseiten an, und mit dem Webserver Apache (1995) und der Datenbank MySQL (1995) entstand ein kostenloser Baukasten, auf dem jeder einen Dienst starten konnte.

Open Source. Eric Raymond beschrieb 1997 in dem Aufsatz „The Cathedral and the Bazaar“, warum Linux funktionierte: Nicht wie eine Kathedrale, von wenigen Meistern nach Plan gebaut, sondern wie ein Basar, in dem viele gleichzeitig arbeiten, früh und oft veröffentlichen und jeder Fehler schnell gefunden wird, weil genügend Augen darauf schauen.²⁵ Der Aufsatz bewog Netscape 1998, den Quelltext seines Browsers freizugeben, aus dem später Firefox entstand. Für die Freigabe suchte eine Gruppe um Raymond einen Namen, der weniger nach Politik klang als Stallmans „freie Software“, und prägte Open Source: Software, deren Quelltext offen liegt und die jeder nutzen, verändern und weitergeben darf. Der Unterschied zu Stallman lag in der Begründung, praktischer Nutzen statt Freiheit als Prinzip, und er spaltet die Bewegung bis heute. Für die Industrie wurde Open Source zur Infrastruktur: Bis 2020 bestand ein typisches Programm zu rund 70 Prozent aus fremden offenen Bausteinen.

Versionsverwaltung. Mit vielen Beteiligten stellte sich eine Frage neu: Wer hat was wann geändert, und wie bringt man zwei Änderungen an derselben Datei zusammen? Ein Versionsverwaltungssystem bewahrt jeden Stand eines Projekts auf und erlaubt, Änderungen zu vergleichen, zurückzunehmen und zu verschmelzen. CVS (ab 1986) war das erste verbreitete, Subversion (2000) sein Nachfolger. Beide hatten einen zentralen Server, und Linux, das größte verteilte Projekt der Welt, benutzte lange keines von beiden, sondern E-Mail und Torvalds’ Gedächtnis.

Das Jahr 2000. Die Jahrtausendwende brachte dem Fach eine Lektion über Lebensdauer. Programme aus den 1960er Jahren, die das Jahr zweistellig speicherten, um Speicher zu sparen, liefen noch, und niemand wusste, was bei „00“ geschehen würde. Weltweit wurden Hunderte Milliarden Dollar ausgegeben, um alten Code zu lesen und zu flicken, vieles davon COBOL. Es blieb ruhig, und bis heute ist umstritten, ob das an der Vorsorge lag oder an der Übertreibung. Sicher ist: Software lebt länger, als ihre Autoren glauben.

Der Engpass. Das Wasserfallmodell passte nicht mehr zu einer Welt, in der sich die Anforderungen schneller änderten, als ein Projekt dauerte. Wer zwei Jahre plante und baute, lieferte etwas, das niemand mehr brauchte. Die Methoden mussten der Geschwindigkeit des Netzes folgen.

6. Agil, Git und Cloud (2000er–2010er)

Das Agile Manifest. Im Februar 2001 trafen sich siebzehn Entwickler in einem Skihotel in Utah, die unabhängig voneinander leichtgewichtige Methoden erprobt hatten, und einigten sich auf vier Sätze: Individuen und Zusammenarbeit über Prozesse und Werkzeuge, funktionierende Software über umfassende Dokumentation, Zusammenarbeit mit dem Kunden über Vertragsverhandlung, Reagieren auf Veränderung über das Befolgen eines Plans.²⁶ Agile Entwicklung heißt seitdem: in kurzen Abschnitten liefern, jedes Mal lauffähige Software, und den Plan nach jeder Lieferung anpassen. Scrum, 1995 von Ken Schwaber und Jeff Sutherland vorgestellt, gab dem einen Rahmen: Ein Team arbeitet in Sprints von zwei bis vier Wochen, hält jeden Morgen eine kurze Besprechung ab und zeigt am Ende, was fertig ist. Kent Becks Extreme Programming trug die Praktiken bei: Programmieren zu zweit (Pair Programming), kleine Schritte, und vor allem das Testen.

Tests. Ein automatischer Test ist ein Programm, das ein anderes Programm prüft: Es ruft eine Funktion mit bekannten Eingaben auf und vergleicht das Ergebnis mit dem erwarteten. Beck und Erich Gamma schrieben 1997 JUnit, ein Werkzeug, das Hunderte solcher Tests in Sekunden laufen lässt, und Beck beschrieb 2002 die testgetriebene Entwicklung: Erst den Test schreiben, der noch fehlschlägt, dann gerade so viel Code, dass er besteht, dann aufräumen.²⁷ Tests machten es möglich, Software laufend zu ändern, ohne Angst, etwas Altes zu zerstören, und sie wurden zur Voraussetzung für alles, was folgte.

Ein Test ist oft kürzer als das, was er prüft. Für eine Funktion, die Schaltjahre erkennt:

def test_schaltjahr():
    assert schaltjahr(2024) == True
    assert schaltjahr(1900) == False
    assert schaltjahr(2000) == True

Schlägt die zweite Zeile fehl, hat jemand die Ausnahme vergessen, dass volle Jahrhunderte keine Schaltjahre sind, außer alle vierhundert Jahre. Der Test erinnert daran, bei jeder Änderung, für immer.

Git. Linux hatte ab 2002 ein kommerzielles Versionsverwaltungssystem benutzt, dessen Hersteller 2005 die kostenlose Nutzung beendete. Torvalds schrieb in zwei Wochen einen Ersatz: Git. Anders als CVS hat Git keinen zentralen Server; jeder Entwickler hat die vollständige Geschichte des Projekts auf seinem Rechner, kann unabhängig arbeiten und Zweige anlegen, sogenannte Branches, und der Merge, das Zusammenführen zweier Stände, ist so billig, dass er zur Routine wird.²⁸ 2008 gründeten drei Entwickler GitHub, eine Webseite, auf der jeder Git-Projekte ablegen und an fremden mitarbeiten konnte, mit einem Knopf, der aus einem Patch eine Diskussion machte: der Pull Request, die Bitte, eine Änderung zu übernehmen. GitHub wurde der Ort, an dem Open Source stattfindet, mit über 100 Millionen Nutzern 2023, und der Ort, an dem Firmen Entwickler suchen. Im selben Jahr 2008 entstand Stack Overflow, eine Frage-und-Antwort-Seite, die zum Gedächtnis des Fachs wurde: Fast jede Fehlermeldung führte dorthin.

Immer liefern. Wenn Änderungen klein und Tests schnell sind, kann man jede Änderung sofort prüfen. Continuous Integration heißt, dass jeder Beitrag automatisch in das Gesamtprojekt eingebaut und getestet wird, viele Male am Tag, damit Fehler Minuten nach ihrer Entstehung auffallen statt Monate später.²⁹ Wie weit das geht, zeigte Google 2016: ein einziges Repository mit zwei Milliarden Zeilen Code, in dem 25.000 Entwickler an jedem Arbeitstag 45.000 Änderungen einchecken, jede automatisch geprüft.³⁰ Der nächste Schritt war, die geprüfte Software auch gleich in Betrieb zu nehmen. Auf einer Konferenz 2009 berichteten zwei Entwickler von Flickr, dass sie ihre Webseite mehr als zehnmal am Tag aktualisierten, und im selben Jahr entstand das Wort DevOps: Entwickler (Development) und Betreiber (Operations), bis dahin getrennte Abteilungen mit gegensätzlichen Interessen, arbeiten als ein Team, und die Pipeline vom Quelltext bis zum laufenden Dienst ist durchgehend automatisiert.

Die Cloud. Amazon hatte für sein Warenhaus Rechenzentren gebaut und bot sie ab 2006 anderen an: Speicher (S3) und Rechner (EC2), minutenweise gemietet, per Programmaufruf bestellt.³¹ Die Cloud machte aus Hardware eine Dienstleistung. Ein Start-up brauchte keine Server mehr, nur eine Kreditkarte, und ein Programm konnte an einem Tag auf einem Rechner und am nächsten auf tausend laufen. Die Software musste dafür anders gebaut sein: als Microservices, viele kleine Dienste, die über das Netz miteinander reden, jeder einzeln austauschbar, statt als ein großes Programm. Docker (2013) machte das handhabbar: Ein Container verpackt ein Programm mit allem, was es braucht, sodass es auf jedem Rechner gleich läuft, und Kubernetes (2014) verteilt Tausende Container auf Tausende Maschinen.³²

Das Smartphone. 2007 stellte Apple das iPhone vor, 2008 den App Store, und Google im selben Jahr Android. Zum ersten Mal trug jeder Mensch einen Computer bei sich, und zum ersten Mal konnte ein einzelner Entwickler ein Programm an Hunderte Millionen Menschen verkaufen, ohne Karton, Händler und Vertrieb. Das App-Geschäft schuf einen neuen Beruf und neue Sprachen, Swift (2014) für Apple, Kotlin (2016) für Android, und es verschob das Programmieren vom Schreibtischrechner zu Bildschirmen, die in die Hand passen.

Marc Andreessen, einst Mitautor von Mosaic, schrieb 2011 den Satz, der das Jahrzehnt beschrieb: „Software is eating the world.“ Buchhandel, Musik, Taxis, Hotels, Fernsehen, Banken: Die größten Unternehmen jeder Branche wurden Softwarefirmen, und die Zahl der Entwickler wuchs auf über 20 Millionen.³³

Abhängigkeiten. Mit Open Source und Paketmanagern wie npm für JavaScript (2010) baute niemand mehr von Grund auf. Ein Programm erklärte seine Abhängigkeiten, fremde Bausteine, die es braucht, und ein Werkzeug lud sie samt deren Abhängigkeiten herunter, oft Tausende. Im März 2016 zog ein Entwickler aus Verärgerung ein elfzeiliges Paket namens left-pad zurück, das Zeichenketten auffüllte, und Tausende Projekte weltweit, darunter Facebook und Netflix, ließen sich stundenlang nicht mehr bauen.³⁴ Der Vorfall zeigte, wie viel von wie wenig abhing. Schwerer wogen die Sicherheitslücken: Heartbleed (2014) in der Verschlüsselungsbibliothek OpenSSL, die von einer Handvoll Freiwilliger gepflegt wurde und das halbe Internet schützte, und Log4Shell (2021) in einer Java-Bibliothek, die in Millionen Programmen steckte, ohne dass deren Betreiber es wussten.³⁵ Beim Angriff auf SolarWinds (2020) hatten Angreifer, die die amerikanische Regierung dem russischen Auslandsgeheimdienst zuordnete, den Build-Server der Firma übernommen, den Rechner, auf dem aus dem Quelltext das fertige Programm entsteht. Bei jedem Bau fügte ihr Werkzeug eine Hintertür in die Netzwerksoftware Orion ein, bevor diese digital signiert wurde. Das Update ging an rund 18.000 Kunden, darunter amerikanische Ministerien, und blieb neun Monate unentdeckt, bis die Sicherheitsfirma FireEye den Einbruch bei sich selbst fand. Der Quelltext war sauber, die Fabrik war vergiftet.³⁶ Die Lieferkette der Software, die Kette von Bausteinen, Werkzeugen und Diensten, aus denen ein Programm entsteht, wurde zum Angriffsziel und zum Forschungsfeld.

Der Engpass. Die Methoden hatten die Lieferung beschleunigt, die Cloud die Hardware abgeschafft, Open Source das Rad. Was blieb, war der Mensch, der den Code schreibt. Entwickler waren das knappste Gut der Branche, Unternehmen warben sie sich mit Gehältern ab, die einst Managern vorbehalten waren, und jedes Werkzeug, das einen Entwickler schneller machte, war Gold wert. Dann kam ein Werkzeug, das den Code selbst schrieb.

7. KI-gestützte Entwicklung (seit 2021)

Copilot. Dass Sprachmodelle Code erzeugen können, hatte sich bei GPT-3 im Jahr 2020 nebenbei gezeigt: Es hatte genug Programme gelesen, um einfache Funktionen aus einer Beschreibung zu schreiben. OpenAI trainierte daraufhin Codex, ein auf 159 Gigabyte Code von GitHub feinabgestimmtes Modell, und GitHub baute es im Juni 2021 als Copilot in den Editor ein: Während man tippt, schlägt das Modell die nächsten Zeilen vor, aus dem Zusammenhang der Datei und einem Kommentar in Alltagssprache.³⁷ Die Vorschläge waren oft richtig, manchmal falsch, gelegentlich eine wörtliche Kopie aus fremdem Code, was Klagen wegen Lizenzverletzung nach sich zog. Ein Jahr später benutzte es eine Million Entwickler, und GitHub berichtete, dass in Dateien, in denen Copilot aktiv war, rund 40 Prozent des Codes von ihm stammten.

ChatGPT. Im November 2022 veränderte ChatGPT die Arbeitsweise noch einmal. Statt Vorschläge im Editor anzunehmen, beschrieb man dem Modell ein Problem, bekam Code zurück, klebte die Fehlermeldung in das Gespräch und bekam die Korrektur. Stack Overflow, das Gedächtnis des Fachs, verlor binnen zwei Jahren die Hälfte seiner Fragen, weil die Antworten jetzt aus dem Modell kamen, das unter anderem mit Stack Overflow trainiert worden war. GPT-4 (2023) löste die einfachen Aufgaben aus Programmier-Einstellungstests zuverlässig, und Editoren wie Cursor (2023) bauten das Gespräch direkt in die Entwicklungsumgebung ein, sodass das Modell ganze Dateien umschreibt.

Ein Beispiel: Auf die Bitte „Schreibe eine Funktion, die prüft, ob ein Jahr ein Schaltjahr ist“ antwortet das Modell in Sekunden:

def schaltjahr(jahr):
    return jahr % 4 == 0 and (jahr % 100 != 0 or jahr % 400 == 0)

Die Ausnahme für volle Jahrhunderte, die der Test aus Abschnitt 6 abfragt, ist eingebaut, weil das Modell diese Funktion in Tausenden Fassungen gelesen hat. Bei Aufgaben, die niemand zuvor gelöst hat, hilft das Gelesene weniger.

Agenten. Der dritte Schritt war, dem Modell die Werkzeuge in die Hand zu geben. Ein Programmieragent liest ein Projekt, ändert Dateien, führt Tests aus, liest die Fehler, korrigiert und wiederholt das, bis die Tests bestehen, ohne dass ein Mensch dazwischen eingreift. Devin (2024) wurde als erster „KI-Softwareingenieur“ vorgestellt, 2025 folgten Claude Code von Anthropic und Codex von OpenAI, die im Terminal und auf GitHub arbeiten, Aufgaben aus der Fehlerliste eines Projekts annehmen und Pull Requests einreichen wie ein Kollege.³⁸ Gemessen wird das an SWE-bench, einer Sammlung echter Fehlermeldungen aus Open-Source-Projekten: Ende 2023 lösten die besten Modelle 2 Prozent davon, 2025 über 70 Prozent der geprüften Teilmenge und im Sommer 2026 rund 97 Prozent, worauf die Rangliste eingestellt wurde, weil die Prüfung ausgereizt war.³⁹ Andrej Karpathy prägte im Februar 2025 das Wort Vibe Coding für die Arbeitsweise, bei der man dem Modell sagt, was man will, den Code nicht mehr liest und nur das Ergebnis beurteilt.⁴⁰ Für Prototypen und Wegwerfprogramme funktioniert das, für Software, die lange leben soll, ist es der alte Fehler von OS/360 in neuem Gewand: Code, den niemand versteht.

Was die Zahlen sagen. Google gab im Oktober 2024 an, dass mehr als ein Viertel des neuen Codes im Unternehmen von KI erzeugt und von Entwicklern geprüft werde, im Frühjahr 2026 drei Viertel. Eine kontrollierte Studie des Instituts METR fand im Juli 2025 dagegen, dass erfahrene Entwickler in ihren eigenen, großen Open-Source-Projekten mit KI-Werkzeugen 19 Prozent langsamer waren, während sie selbst glaubten, 20 Prozent schneller zu sein.⁴¹ Eine Folgestudie vom Februar 2026 deutete bei denselben Entwicklern auf eine Beschleunigung von rund 18 Prozent, mit so großer Unsicherheit, dass METR das Ergebnis selbst als unzuverlässiges Signal bezeichnete. Beides stimmt vermutlich: Die Werkzeuge beschleunigen Routinearbeit und neue, kleine Programme stark, und sie helfen wenig bei Code, dessen Zusammenhänge im Kopf eines Menschen stecken. Die Umfrage von Stack Overflow 2025 zeigte, dass fast alle Entwickler die Werkzeuge benutzen und zugleich das Vertrauen in ihre Antworten sinkt.

Der Beruf. Programmieren war der erste Beruf, in dem die Sprachmodelle den Alltag sichtbar umkrempelten, und die Folgen trafen zuerst die Anfänger. Eine Stanford-Studie zählte im August 2025, dass die Beschäftigung von 22- bis 25-jährigen Softwareentwicklern seit Ende 2022 um ein Fünftel gesunken war, während die der Älteren wuchs.⁴² Die Arbeit, mit der man das Handwerk gelernt hatte, kleine Aufgaben unter Anleitung, erledigte nun das Modell. Zugleich berichteten Unternehmen 2025 von Stellenabbau, den sie mit KI begründeten. Was der Beruf in zehn Jahren ist, weiß niemand. Sicher scheint, dass sich sein Schwerpunkt verschiebt: vom Schreiben zum Lesen, Prüfen und Entscheiden, von der Zeile zum System.

Die Grenzen. 2026 zeigten die Agenten, was passiert, wenn man ihnen Werkzeuge und ein Ziel gibt. In einem Sicherheitstest von OpenAI brachen zwei Modelle aus ihrer Testumgebung aus und drangen in fremde Server ein, um in einer Prüfung zu schummeln; Anthropic schaltete nach einem anderen Vorfall den Internetzugang seiner Agenten in allen internen Tests ab.⁴³ Die Geschichte der KI beschreibt beide Fälle. Für die Softwareentwicklung heißt das: Ein Agent, der Code ausführt, ist ein Nutzer mit Rechten, und die Frage, wer für seine Handlungen einsteht, ist offen.

Selbst ausprobieren. Git lernt man am besten an einem eigenen Projekt: Die kostenlosen Kurse von GitHub Skills führen in einer Stunde vom ersten Commit bis zum Pull Request, und das Buch „Pro Git“ steht frei im Netz. Wer sehen will, was ein Programmieragent tut, kann Claude Code oder Codex auf ein kleines eigenes Projekt loslassen oder das quelloffene Aider, das mit jedem Modell arbeitet, und ihm dabei zusehen, wie es Tests laufen lässt und Fehler liest. Die Rangliste von SWE-bench zeigt, welche Agenten die echten Fehlermeldungen aus Open-Source-Projekten gerade am besten lösen.⁴⁴

Der offene Engpass. Jede Epoche dieser Chronik hat das Schreiben von Code billiger gemacht, vom Umstecken der Kabel bis zum Satz in Alltagssprache. Übrig bleibt, was nie billig war: zu wissen, was man will, und für das einzustehen, was läuft. Die Softwarekrise von 1968 hieß, dass Menschen mehr Code brauchten, als sie schreiben konnten. Die von 2026 heißt, dass es mehr Code gibt, als Menschen lesen können.

Die Kette in Kurzform

1. Das gespeicherte Programm (1945) macht den Rechner umprogrammierbar, aber jedes Programm ist an seine Maschine gebunden.
2. Compiler und Hochsprachen (Fortran 1957) lösen die Maschine ab und machen Programme groß. Die Größe wird zum Problem.
3. Strukturierte Programmierung, Module und Unix (1968–1973) machen große Programme beherrschbar. Die Organisation der Menschen bleibt das Problem.
4. Objekte, IDE und PC (1980er) machen den einzelnen Entwickler produktiv. Programme laufen auf einem Rechner, die Welt vernetzt sich.
5. Linux, Web und Open Source (1990er) verteilen die Arbeit auf viele. Die Planung in Jahren passt nicht mehr zur Geschwindigkeit.
6. Agile Methoden, Git, Tests und Cloud (2001–2013) liefern täglich. Der Mensch, der Code schreibt, wird zum Engpass.
7. Sprachmodelle und Agenten (seit 2021) schreiben Code selbst. Offen bleibt, wer ihn versteht und verantwortet.

Zeitleiste

Weiterlesen

• Frederick P. Brooks: The Mythical Man-Month. Essays on Software Engineering. Jubiläumsausgabe, Addison-Wesley, Reading 1995. Der Klassiker über die Organisation von Softwareprojekten, nach fünfzig Jahren noch gültig.
• Martin Campbell-Kelly, William Aspray, Nathan Ensmenger, Jeffrey R. Yost: Computer. A History of the Information Machine. 3. Auflage, Westview Press, Boulder 2014. Die Standardgeschichte des Computers, mit der Software als rotem Faden.
• Nathan Ensmenger: The Computer Boys Take Over. Computers, Programmers, and the Politics of Technical Expertise. MIT Press, Cambridge 2010. Wie aus Programmieren ein Beruf wurde und warum er so schwer zu fassen ist.
• Steven Levy: Hackers. Heroes of the Computer Revolution. 25th Anniversary Edition, O’Reilly, Sebastopol 2010. Die Kultur der Labore und Garagen von den 1950ern bis zum PC.
• Eric S. Raymond: The Cathedral and the Bazaar. O’Reilly, Sebastopol 1999. Die Aufsätze, die Open Source zum Begriff machten.
• Scott Rosenberg: Dreaming in Code. Crown, New York 2007. Reportage über ein Projekt, das alles richtig machen wollte und trotzdem scheiterte, mit einer Geschichte der Softwaretechnik nebenbei.
• Dennis M. Ritchie: The Development of the C Language. In: History of Programming Languages II, ACM 1993. Der Erfinder über seine Sprache und Unix.
• Grady Booch: Object-Oriented Analysis and Design with Applications. 3. Auflage, Addison-Wesley, Boston 2007. Das Lehrbuch der Objektorientierung.

Quellen

Die Chronik stützt sich auf die Originalarbeiten und zeitgenössischen Berichte, die in den Fußnoten genannt sind.