Damn, das ist cringe: Der Australier Geoffrey Huntley hat die Programmier-KI Claude Code von Anthropic drei Monate in Dauerschleife laufen lassen, um eine eigene Programmiersprache im Stile der verbreiteten Umgangssprache der Generation Z zu entwerfen. Und warum? Nun, weil er es kann, wie er in einem Blogpost darlegt.

Tatsächlich habe ihn einfach die Möglichkeit gereizt, dass mithilfe generativer KI der Traum vom eigenen Compiler Gestalt annehmen kann, schreibt er. Das Ganze sei dann auch ein Lernexperiment gewesen. Der KI sei es dabei selbst überlassen worden, die Sprache jeweils weiter zu verbessern. Das Ergebnis hat er sogar auf einer eigenen Website zum Download bereitgestellt. Der Name der Programmiersprache: Cursed (auf deutsch: verflucht).

Der Compiler verfügt über zwei Modi. Er kann als Interpreter oder als Compiler eingesetzt werden und Binärdateien für macOS, Linux und Windows erstellen. Zudem gebe es halbfertige Erweiterungen für die Editoren VSCode, Emacs und Vim. Wer sich den Entstehungsprozess anschauen möchte, findet dazu entsprechende Videos bei YouTube.

Sprachlich darf man sich das so vorstellen, dass an die Stelle von bekannten Begriffen wie for oder case Wörter treten, die in der GenZ gerne benutzt werden, wie etwa bestie oder mood. Eine Roadmap zur Weiterentwicklung gebe es nicht, darüber soll die Community entscheiden.

Das kostete das Experiment

Der ursprüngliche Prompt lautete: „Hey, kannst du mir eine Programmiersprache wie Golang erstellen, bei der jedoch alle lexikalischen Schlüsselwörter ausgetauscht sind, sodass sie dem Slang der Generation Z entsprechen?“

Wer dem Beispiel von Huntley folgen möchte, sollte allerdings das nötige Kleingeld bereithalten. Der eigene Compiler koste einen etwa 5000 US-Dollar, schreibt er in einem Post auf X. Tatsächlich habe er mit 14.000 US-Dollar fast das Dreifache investieren müssen, da Cursed zunächst in C, dann in Rust und jetzt in Zig entwickelt wurde. Aber so gebe es jetzt eben auch drei Editionen des Compilers. Und am Ende sei das nur ein Vierzehntel des Gehalts eines Entwicklers in San Francisco, scherzt er.

(mki)

Die bisherigen Beiträge dieser Serie haben gezeigt, dass neuronale Netze aus einfachen Bausteinen bestehen. Erst die Kombination vieler dieser Bausteine in mehreren Schichten ermöglicht jedoch die Durchbrüche, die moderne KI-Systeme prägen. Genau hier setzt das Konzept „Deep Learning“ an: Es beschreibt maschinelles Lernen mit tiefen, also mehrschichtigen, neuronalen Netzen.

Deser Beitrag klärt, was „tief“ im Kontext neuronaler Netze bedeutet, warum zusätzliche Schichten die Leistungsfähigkeit erhöhen und welche typischen Architekturen in der Praxis verwendet werden.

Was „deep“ wirklich heißt

Von Deep Learning spricht man, wenn ein neuronales Netz mehrere verborgene Schichten enthält – in der Regel deutlich mehr als zwei oder drei. Jede Schicht abstrahiert die Ausgaben der vorherigen Schicht und ermöglicht so, komplexe Funktionen zu modellieren. Während einfache Netze vor allem lineare und leicht nichtlineare Zusammenhänge erfassen, können tiefe Netze hochdimensionale Strukturen und Muster erkennen.

Die Entwicklung hin zu tieferen Netzen wurde erst durch drei Faktoren möglich:

1. Stärkere Rechenleistung – insbesondere durch Grafikkarten (GPUs) und später spezialisierte Hardware wie TPUs.
2. Größere Datenmengen, die zum Training genutzt werden können.
3. Verbesserte Trainingsverfahren, darunter die Initialisierung von Gewichten, Regularisierungstechniken und optimierte Aktivierungsfunktionen.

Hierarchisches Lernen von Merkmalen

Ein Kernprinzip des Deep Learning ist die hierarchische Merkmalsextraktion. Jede Schicht eines tiefen Netzes lernt, auf einer höheren Abstraktionsebene zu arbeiten:

• Frühe Schichten erkennen einfache Strukturen, zum Beispiel Kanten in einem Bild.
• Mittlere Schichten kombinieren diese zu komplexeren Mustern, etwa Ecken oder Kurven.
• Späte Schichten identifizieren daraus ganze Objekte wie Gesichter, Autos oder Schriftzeichen.

Diese Hierarchiebildung entsteht automatisch aus den Trainingsdaten und macht Deep Learning besonders mächtig: Systeme können relevante Merkmale selbst entdecken, ohne dass Menschen sie mühsam vordefinieren müssen.

Typische Architekturen

Im Deep Learning haben sich verschiedene Architekturen etabliert, die für bestimmte Datenarten optimiert sind.

Convolutional Neural Networks (CNNs) sind spezialisiert auf Bild- und Videodaten. Sie verwenden Faltungsschichten („Convolutional Layers“), die lokale Bildbereiche analysieren und so translationinvariante Merkmale lernen. Ein CNN erkennt beispielsweise, dass ein Auge im Bild ein Auge bleibt, egal wo es sich befindet. CNNs sind der Standard in der Bildklassifikation und Objekterkennung.

Recurrent Neural Networks (RNNs) wurden entwickelt, um Sequenzen wie Text, Sprache oder Zeitreihen zu verarbeiten. Sie besitzen Rückkopplungen, durch die Informationen aus früheren Schritten in spätere einfließen. Damit können sie Zusammenhänge über mehrere Zeitschritte hinweg modellieren. Varianten wie LSTMs (Long Short-Term Memory) und GRUs (Gated Recurrent Units) beheben typische Probleme wie das Vergessen relevanter Informationen.

Autoencoder sind Netze, die Eingaben komprimieren und anschließend wieder rekonstruieren. Sie lernen dabei implizit eine verdichtete Repräsentation der Daten und werden etwa für Anomalieerkennung oder zur Vorverarbeitung genutzt. Erweiterte Varianten wie Variational Autoencoders (VAE) erlauben auch generative Anwendungen.

Diese Architekturen bilden die Grundlage vieler moderner KI-Anwendungen. Sie sind jedoch noch nicht der Endpunkt: In den letzten Jahren haben Transformer klassische RNNs in vielen Bereichen abgelöst, insbesondere in der Sprachverarbeitung. Darum wird es in einer späteren Folge dieser Serie gehen.

Herausforderungen des Deep Learning

Tiefe Netze sind leistungsfähig, bringen aber neue Herausforderungen mit sich:

• Großer Datenhunger: Ohne ausreichend Trainingsdaten tendieren tiefe Modelle zum Überfitting.
• Rechenintensiv: Training und Inferenz erfordern spezialisierte Hardware und hohe Energieaufwände.
• Schwer erklärbar: Mit wachsender Tiefe nimmt die Nachvollziehbarkeit weiter ab, was für viele Anwendungsbereiche problematisch ist.

Trotzdem hat sich Deep Learning als Schlüsseltechnologie für die meisten aktuellen KI-Durchbrüche etabliert.

Ausblick

Die nächste Folge widmet sich den Transformern – der Architektur, die Large Language Models und viele andere moderne Systeme ermöglicht. Sie erläutert, warum klassische RNNs an ihre Grenzen stießen und wie Self-Attention die Verarbeitung von Sprache revolutionierte.

(rme)

Sprintziele gehören zu den stärksten Werkzeugen im Scrum-Framework. In dieser Folge diskutieren Dominique Winter und Oliver Winter, wie es Teams gelingt, Sprintziele so zu etablieren, dass sie Orientierung geben, Wirkung entfalten und Vertrauen schaffen. Ein Sprintziel ist schließlich mehr als eine Pflichtübung im Sprint Planning. Richtig eingesetzt, schafft es Klarheit über das „Warum“ der nächsten Iteration und verbindet die tägliche Arbeit mit der Produktvision.

Schwierigkeiten mit Sprintzielen

Vielen Teams fällt die Nutzung von Sprintzielen jedoch schwer. Häufig gibt es gar kein Ziel oder es bleibt auf der Ebene von Aufgabenlisten stecken. Statt echter Wirkung wird dann nur Output gemessen. Die Folge: wenig Fokus, kaum Begeisterung bei Stakeholdern und sinkendes Vertrauen in den Wert von Sprintzielen.

Gute Sprintziele: Outcome-orientiert und im Alltag präsent

Doch gerade hier liegt der Hebel. Ein gut formuliertes Sprintziel richtet die Arbeit am Outcome aus. Es beantwortet die Frage, welchen Mehrwert das Team in den kommenden zwei Wochen schaffen will, und gibt damit eine klare Orientierung für Entscheidungen im Sprint. Statt einer Sammlung von Backlog-Items entsteht ein gemeinsamer Fokus. Im Daily oder im Review lässt sich damit jederzeit prüfen, ob die Arbeit noch auf das eigentliche Ziel einzahlt.

Dominique Winter und Oliver Winter machen aber auch deutlich, dass Sprintziele eben nicht im stillen Kämmerlein entstehen sollten. Entscheidend ist die gemeinsame Gestaltung mit den Developern. Wer das Ziel aktiv mitformuliert, wird es auch eher als eigenes Commitment ansehen. So entsteht nicht nur mehr Akzeptanz, sondern auch die Bereitschaft, externe Einflüsse auszuhalten und das Ziel zu verteidigen. Product Owner bringen dabei den strategischen Rahmen ein – etwa Vision, Roadmap oder Product Goal – und öffnen einen Raum, in dem das Team das nächste sinnvolle Ziel bestimmen kann.

Ein gutes Sprintziel ist aber auch sichtbar und im Alltag präsent: in Dailys, in Gesprächen mit Stakeholdern und sogar in der spontanen Antwort auf die Frage „Woran arbeitet ihr gerade?“. Nur so werden sie zu einem lebendigen Orientierungspunkt statt zu einem Protokolleintrag. Wenn ein Team das gemeinsam vereinbarte Sprintziel erreicht, gilt es, diesen Erfolg sichtbar zu feiern; nicht die Anzahl der erledigten Backlog-Items, sondern den erzielten Mehrwert. Gerade im Sprint Review eröffnet das die Chance, Stakeholder zu begeistern und ihnen zu zeigen, warum sich die investierte Arbeit gelohnt hat. So wird das Konzept Sprintziele gestärkt und gewinnt wieder Vertrauen.

Zusammengefasst helfen Sprintziele Teams dabei, sich auf das Wesentliche zu konzentrieren, Entscheidungen leichter zu treffen und Stakeholder einzubeziehen. Wer sie konsequent auf Outcome ausrichtet, gemeinsam gestaltet und sichtbar macht, etabliert ein Instrument, das weit mehr ist als eine Formalität. Es ist ein Kompass, der Produktteams eine gemeinsame, wertvolle Richtung gibt.

Die aktuelle Ausgabe des Podcasts steht auch im Blog der Produktwerker bereit: „So etablierst du Sprintziele, die wirklich helfen„.

(mai)