Solange die Grenze noch offen ist

Von Yassine Bekri — 22. Mai 2026

Es gibt mittlerweile zwei Arten von Software-Teams.

Die erste Art hat bemerkt, dass etwas sehr Seltsames passiert ist, und hat ihr Leben darum herum neu organisiert.

Die zweite Art fragt immer noch, ob die seltsame Sache schon „produktionsreif“ ist.

Ich meine das nicht als Beleidigung. „Produktionsreif“ war früher eine echte Frage. Man hatte ein neues Framework, eine neue Datenbank, einen neuen Cloud-Dienst oder eine neue Frontend-Religion und fragte sich: Ist das stabil genug, um darauf zu vertrauen? Wird es das nächstes Jahr noch geben? Gibt es eine Dokumentation? Funktioniert es mit unserer Deployment-Pipeline? Hat irgendjemand mit einem Konferenzausweis den Begriff „Enterprise-Grade“ in dessen Nähe fallen lassen?

Das war nicht dumm. In der alten Welt war es teuer, schlechte Werkzeuge zu früh einzuführen. Man konnte Monate damit verlieren, auf etwas zu migrieren, das am Ende als GitHub-Archiv endete, dessen letzter Commit des Maintainers lautete: „Tut mir leid, Burnout“.

Aber Agentic Engineering ist nicht wirklich ein Werkzeug.

Es ähnelt eher einem neuen Organismus, der im Entwicklungsprozess aufgetaucht ist. Manchmal schreibt er Code. Manchmal schreibt er mit großem Selbstbewusstsein den falschen Code. Manchmal erklärt er eine alte Codebasis besser als der Senior Engineer, der sie gebaut hat – abgesehen von dem Teil, in dem er eine Funktion erfindet, die gar nicht existiert. Manchmal ist er ein Junior-Entwickler, manchmal ein Schwarm von Praktikanten, manchmal ein Compiler für Absichten, manchmal ein betrunkener Architekt mit perfekter Tippgeschwindigkeit.

Der Fehler liegt darin, entscheiden zu wollen, ob dieser Organismus im Abstrakten „gut“ ist.

Gut worin?

Gut darin, einen Senior Engineer zu ersetzen? Meistens nein.

Gut darin, eine halb ausformulierte Produktidee zu nehmen und sie in ein wartbares System zu verwandeln, während man Kaffee trinken geht? Ebenfalls nein, es sei denn, Ihr Kaffee enthält Ketamin und Sie träumen.

Gut darin, die Distanz zwischen Absicht und funktionierender Software zu verkürzen, wenn er von der richtigen Umgebung, dem richtigen Kontext, den richtigen Einschränkungen, Review-Schleifen und menschlichem Urteilsvermögen umgeben ist?

Ja.

Und dieses Ja ist groß genug, um die gesamte Branche darum herum neu zu organisieren.

I.

Die sichtbarste Kluft in der Softwarewelt verläuft derzeit nicht zwischen KI-Gläubigen und KI-Skeptikern. Das war die Debatte des letzten Jahres, und sie war schon damals langweilig.

Die Kluft verläuft zwischen Menschen, die emotional akzeptiert haben, dass sich der Workflow verändert hat, und Menschen, die nur intellektuell akzeptiert haben, dass Modelle nützlich sind.

Die zweite Gruppe wird Dinge sagen wie:

„Natürlich nutzen wir KI.“

Dann fragt man, was das bedeutet.

Sie nutzen gelegentlich Cursor. Jemand hat ChatGPT in einem anderen Tab geöffnet. Ein Entwickler hat einmal einen Unit-Test generiert. Der CTO hat eine Folie über KI-Produktivität. Es gibt ein Richtliniendokument, das erklärt, welche Daten nicht in welchen Chatbot kopiert werden dürfen. Eine Task Force evaluiert Copilot.

Das ist so, als würde man sagen, die eigene Armee habe die Luftfahrt eingeführt, weil ein Oberst einen Drachen besitzt.

Die erste Gruppe sieht anders aus. Ihre Arbeitsabläufe verändern sich wöchentlich. Sie betrachten das Modell nicht mehr als clevere Autovervollständigung. Sie denken in den Kategorien von Kontextoberflächen, Werkzeugberechtigungen, Speichergrenzen, Aufgabenzerlegung, Agenten-Rollen, Eval-Traces, Fehlermodi, Recovery-Schleifen und Harness-Design.

Sie fragen nicht: „Kann KI coden?“

Sie fragen:

Was muss der Agent wissen?

Wie verhindern wir, dass er das Falsche weiß?

Welche Teile der Aufgabe sollten zerlegt werden, bevor das Modell sie sieht?

An welcher Stelle bringt das menschliche Review den größten Mehrwert?

Wann darf der Agent auf das Dateisystem zugreifen?

Was gilt als erledigt?

Was sollte zwischen den Durchläufen persistent gespeichert werden?

Wie verhindern wir, dass der clevere Hack von heute zur verfluchten Kathedrale von morgen wird?

Das sind keine philosophischen Fragen. Das sind technische Fragen. Genauer gesagt sind es die Fragen, die sich in der Softwareentwicklung stellen, wenn der Entwickler nicht mehr der einzige Verstand ist, der an der Arbeit beteiligt ist.

II.

Das Seltsame ist, dass kleinere, jüngere Teams das anscheinend schneller verstehen.

Die jungen Teams müssen weniger verlernen.

Das ist ungerecht, denn Senior Engineers wissen wirklich eine Menge. Sie wissen, warum Rewrites scheitern. Sie wissen, warum Demos lügen. Sie wissen, warum die Datenbank so ist, wie sie ist. Sie wissen, dass die einfache Anfrage des Kunden mit dem Abrechnungssystem interagieren wird, mit der Berechtigungsebene, mit der einen Tabelle, die niemand anfassen darf, und mit Frank, der das Unternehmen 2019 verlassen hat, dessen Meinungen aber immer noch in der Produktion laufen.

All das ist echtes Wissen.

Das Problem ist, dass echtes Wissen zu einer Immunantwort werden kann.

Ein neuer Workflow hält Einzug in die Organisation. Er sieht gefährlich aus, weil er gefährlich ist. Er produziert Code zu schnell. Er ignoriert implizite Konventionen. Er respektiert nicht die alten Traumata, die in der Architektur verankert sind. Er macht Junioren zu selbstsicher und Senioren zu genervt. Er schlägt vor, eine sorgfältig gepflegte interne Bibliothek durch zwölf Zeilen frischen Unsinn zu ersetzen. Die Organisation bildet Antikörper.

Die Antikörper liegen nicht falsch.

But manchmal ist der Erreger die Heilung.

Kleine Teams haben weniger Antikörper. Sie können sagen: „Das ist seltsam, aber es funktioniert in 30 % der Fälle. Können wir es bis morgen in 50 % der Fälle zum Laufen bringen?“ Sie müssen kein Governance-Meeting ansetzen, um zu definieren, was „Agent“ bedeutet. Sie können den Workflow ausprobieren, sehen, wo er bricht, und ihn neu aufbauen, noch bevor das große Unternehmen entschieden hat, ob Agentic Engineering unter Engineering, Produkt, IT, Innovation oder das neue AI Transformation Office fällt, dessen erste Amtshandlung immer darin besteht, einen SharePoint-Ordner anzulegen.

Das ist der Teil, der sich neu anfühlt.

Die meiste Zeit der Softwaregeschichte hatten die großen Player strukturelle Vorteile. Sie hatten die besten Entwickler, die beste Infrastruktur, den besten Vertrieb, die meisten Daten, die größten Kunden, die meiste Glaubwürdigkeit und die meisten Anwälte. Kleine Teams konnten zwar immer noch gewinnen, aber dafür brauchten sie meist entweder eine bahnbrechende Produktidee oder einen Markt, den die Etablierten ignorierten.

Heute kann ein kleines Team manchmal allein deshalb die Nase vorn haben, weil es bereit ist, seinen Entwicklungsprozess alle zehn Tage zu ändern.

Das sollte eigentlich nicht möglich sein. Und doch stehen wir genau hier.

III.

Es gäbe eine deprimierende Version dieses Beitrags, in der ich die nächsten 1.500 Wörter damit verbringe, Skeptiker davon zu überzeugen, dass Agentic Engineering real ist.

Ich werde diesen Beitrag nicht schreiben.

Teils, weil andere ihn schon geschrieben haben. Teils, weil die Menschen, die ihn am dringendsten bräuchten, sich davon ohnehin nicht überzeugen ließen. Vor allem aber, weil es immer unklarer wird, warum man überhaupt Energie darauf verwenden sollte, das andere Lager zu überzeugen.

Das ist das wiederkehrende Muster bei technologischen Umbrüchen. Anfangs haben kluge Skeptiker oft recht mit ihren Mängeln. Die frühe Version ist wirklich hässlich. Sie scheitert wirklich auf peinliche Weise. Sie kann wirklich viele der Dinge nicht, die ihre Evangelisten versprechen. Aber die Evangelisten, die sie nutzen, kommen dadurch früher mit der nächsten Ebene von Problemen in Kontakt. Bis die Skeptiker die Diskussion über Version eins gewonnen haben, arbeiten die Praktiker bereits an Version vier, und das Argument ist zu einer historischen Nachstellung geworden.

Agentic Engineering hat viele reale Schwachstellen.

Agenten driften ab. Der Kontext verfällt. Modelle halluzinieren. Die Nutzung von Werkzeugen ist fehleranfällig. Lang laufende Aufgaben kollabieren in subtilen Unsinn. Generierter Code kann zu Architekturschulden mit besserer Grammatik werden. Das Modell kann den Wortlaut der Aufgabe befolgen, während es den Sinn so vollständig missachtet, dass man langsam versteht, warum die Menschen im Altertum an Trickster-Götter glaubten.

Alles wahr.

Aber auch irrelevant – es sei denn, man nutzt diese Fehler als Rohmaterial.

Die interessanten Leute sagen nicht „Agenten funktionieren“.

Sie sagen „Agenten scheitern auf spezifische Weise, und diese Wege erfordern spezifische Absicherungen“.

In diesem Satz liegt das ganze Geheimnis.

IV.

Seit etwa Dezember haben sich die Leute, die dies akzeptiert haben, wie eine lose kollektive Intelligenz in Bewegung gesetzt.

Keine Community im weichen HR-Sinne von „Menschen mit gemeinsamen Werten“. Eher wie ein dezentraler, Problemlösungs-Organismus mit einem schlechten Schlafrhythmus.

Irgendwo taucht ein Muster auf.

Karpathy benennt etwas, oder benennt es halb, oder macht eine Bemerkung, die alle dazu bringt, zu erkennen, dass sie das gleiche Konzept umkreist haben, ohne einen Begriff dafür zu haben.

Jemand postet ein Diagramm.

Jemand anderes postet ein Repository.

Eine dritte Person sagt, das Repo sei falsch, weil es das Gedächtnis ignoriert.

Eine vierte Person sagt, das Gedächtnis sei eine Falle und das eigentliche Problem sei die Kontext-Hygiene.

Eine fünfte Person prägt einen Begriff, der etwas schlechter ist als der vorherige, sich aber irgendwie durchsetzt.

Substack verarbeitet es.

Twitter komprimiert es in Slogans.

Ein kleines Labor implementiert es übers Wochenende.

Bis Dienstag ist es nicht mehr die vorderste Front. Es wird als Hintergrundwissen für das nächste Argument vorausgesetzt.

Das ist anstrengend, wenn man Stabilität will.

Es ist berauschend, wenn man es liebt, lebendig zu sein.

Inzwischen gibt es einen Rhythmus. Jede Woche scheint das Kollektiv einen Engpass durchzukauen und den nächsten freizulegen.

Zuerst ist das Problem das Prompting.

Dann ist das Problem, dass Prompting ein zu schwaches Konzept ist, also braucht man Workflows.

Dann ist das Problem, dass Workflows den Zustand verlieren, also braucht man ein Gedächtnis (Memory).

Dann ist das Problem, dass das Gedächtnis den Agenten vergiftet, also braucht man ein selektives Gedächtnis.

Dann ist das Problem, dass selektives Gedächtnis Urteilsvermögen erfordert, also braucht man Evals.

Then ist das Problem, dass Evals zu statisch sind, also braucht man Traces.

Dann ist das Problem, dass Traces zeigen, wie der Agent etwas Wahnsinniges tut, also braucht man bessere Werkzeuggrenzen.

Dann ist das Problem, dass Werkzeuggrenzen ihn verlangsamen, also braucht man Berechtigungen.

Dann ist das Problem, dass Berechtigungen die Ontologie Ihrer Organisation codieren, die sich am Ende weniger als sauberer Baum, sondern eher als eine Schublade voller Kabelsalat herausstellt.

Auf jeder Stufe löst die „Lösung“ nicht das gesamte Feld. Sie kauft einem den Eintritt in den nächsten Raum.

So sieht Fortschritt aus, wenn niemand eine Landkarte hat.

V.

Das wird nicht ewig so bleiben.

Die aktuelle Phase hat eine etwas trügerische Offenheit. Es fühlt sich an, als könne jeder mit Geschmack, Neugier und genügend Bereitschaft, Dinge auszuprobieren, Schritt halten. Momentan stimmt das oft auch.

Aber Fachgebiete bleiben nicht ewig flüssig. Sie kristallisieren sich heraus.

Wir sehen bereits die ersten Anzeichen in der Terminologie.

Niemand weiß, wo Kontext-Engineering aufhört und Harness-Engineering beginnt. Niemand weiß, ob Agentic Engineering eine Untermenge des Software-Engineerings, ein Ersatz für das Software-Engineering oder einfach nur Software-Engineering ist, nachdem es einen leuchtenden Pilz gegessen hat. Niemand weiß, ob ein „Agent“ Autonomie, Werkzeugnutzung, Persistenz, Planung oder lediglich eine ausreichend ambitionierte README benötigt.

Dasselbe Wort bedeutet heute fünf verschiedene Dinge, je nachdem, ob es von einem Forscher, einem Gründer, einem Entwickler, einem Berater oder einer LinkedIn-Person verwendet wird, die zu nah an einem Ringlicht steht.

Das ist nervig. Es ist aber auch normal.

Ein Feld entdeckt zuerst Phänomene, erfindet dann Wörter, streitet sich dann um die Wörter, baut dann Institutionen um die Gewinner-Wörter auf und bringt Studenten schließlich eine vereinfachte Version bei, in der die Wörter schon immer offensichtlich gewesen zu sein scheinen.

Wir befinden uns irgendwo zwischen „Phänomene entdecken“ und „um Wörter streiten“.

Später wird sich dies in echte Spezialgebiete aufteilen. Es wird Menschen geben, deren gesamtes Handwerk die Kontext-Architektur ist. Andere werden sich auf die Evaluierung von Agenten spezialisieren. Andere auf Coding-Harnesses. Andere auf Schnittstellen für menschliche Reviews. Andere auf Tool-Umgebungen. Andere auf Compliance-Ebenen für regulierte Branchen. Wieder andere auf die Integration von Agenten in Altsysteme, was langweilig klingt, bis man merkt, dass die halbe Welt immer noch auf Software läuft, die UTF-8 als Gerücht behandelt.

Ab diesem Punkt wird die vorderste Front schwerer beiläufig zu erreichen sein. Man wird nicht mehr auf dem Laufenden bleiben können, indem man ein paar Beiträge liest und am Sonntag etwas herumschraubt. Die Probleme werden Tiefe, angesammelte Fehler, Benchmarks, Infrastruktur und wahrscheinlich ein paar deutsche Vergabeunterlagen erfordern.

Aber ganz so weit sind wir noch nicht.

Im Moment kann ein kleines Team noch mithalten.

Nicht mit den Foundation-Model-Laboren. Werden wir nicht größenwahnsinnig. Ein achtköpfiges Team in Düsseldorf trainiert kein neues Frontier-Modell in einem Keller vor, es sei denn, dieser Keller enthält das norwegische Stromnetz.

Aber in der Anwendungsebene, bei Harnesses, bei Workflows, in der praktischen Kunst, Modellfähigkeiten in fertige Software zu verwandeln, können kleine Teams absolut an der vordersten Front sein.

Manchmal können sie sogar voraus sein.

Das ist derzeit eine der erfreulichsten Tatsachen in der Softwarewelt.

VI.

Es liegt eine amüsante Demütigung darin, zuzusehen, wie ein großes Unternehmen mit professioneller Beleuchtung und einem Launch-Video ein Produkt ankündigt, das dem ähnelt, was unser kleines Team drei Monate zuvor mit Koffein und Verachtung für Schlaf gebaut hat.

Das sollte das kleine Team stolz machen.

Es sollte ihnen aber auch Angst machen.

Stolz, weil es bedeutet, dass wir in die richtige Richtung geschaut haben.

Besorgt, weil es bedeutet, dass das große Unternehmen jetzt auch dorthin schaut.

Die tröstliche Interpretation lautet: „Wir sind so gut wie die großen Player.“

Die treffendere Interpretation lautet: „Die vorderste Front ist noch so jung, dass die großen Akteure ihre strukturellen Vorteile noch nicht in Dominanz umgemünzt haben.“

Dieses Zeitfenster ist kostbar. Es ist auch vorübergehend.

Wenn es kein Drehbuch gibt, hat Erfahrung eine seltsame Wertkurve. Einige Erfahrungen helfen enorm. Geschmack hilft. Technische Disziplin hilft. Zu wissen, wie Systeme scheitern, hilft. Echte Software ausgeliefert zu haben, hilft. Narben zu haben hilft, vorausgesetzt, man fängt nicht an, das Narbengewebe anzubeten.

Aber manche Erfahrung schadet auch.

Der ältere Prozess besagt: Anforderungen definieren, Tickets zuweisen, schätzen, implementieren, reviewen, testen, deployen.

Der neue Prozess sagt eher: Absicht definieren, Kontext konstruieren, Exploration delegieren, Traces inspizieren, Werkzeuge einschränken, sich von Fehlern erholen, Erkenntnisse zurück in den Harness fließen lassen, dann vielleicht implementieren – außer dass die Implementierung die ganze Zeit über stattgefunden hat und die Grenze zwischen Design und Ausführung nun verdächtig verschwommen ist.

Wenn Ihre Identität auf der alten Abfolge aufbaut, sieht die neue aus wie Chaos.

Wenn Sie noch keine Identität haben, sieht es einfach aus wie ein ganz normaler Dienstag.

Deshalb sind junge Teams hier oft schneller. Nicht, weil Jugend magisch ist. Jugend bringt jede Menge Dummheit hervor. Aber wenn sich alles ändert, kann Dummheit plus schnelles Feedback Klugheit plus langsame Anpassung schlagen.

Das Ideal ist nicht Unerfahrenheit. Das Ideal ist Erfahrung ohne Verkalkung.

VII.

Dies bringt mich zu Mia.

Mia ist unser Agentic-Harness im Düsseldorf AI Lab. Wir haben sie in den letzten neun Monaten entwickelt. Wir haben sie gebaut, weil wir liefern mussten.

Wir bauten Software für deutsche Unternehmen und NGOs in Umgebungen, in denen die Einschränkungen nicht optional waren. Altsysteme. Rechtliche Anforderungen. Seltsame Kundenprozesse. Dokumente, die per E-Mail in Formaten eintreffen, die man zuletzt in der Bronzezeit gesehen hat. Menschen, die Automatisierung wollen, aber auch wissen wollen, was die Automatisierung getan hat, warum sie es getan hat, wo sie gescheitert ist und ob sie immer noch einem Menschen die Schuld geben können.

Aus diesem Druck heraus ist Mia entstanden.

Sie ist nicht „ein Agent“. Dieser Begriff ist mittlerweile zu überladen, um nützlich zu sein. Mia ähnelt eher einer Umgebung (Harness), um agentenbasierte Entwicklung weniger wie das Beschwören eines Dämons und mehr wie das Betreiben einer Maschinenwerkstatt zu gestalten.

Eine Werkstatt hat Werkbänke, Werkzeuge, Beschriftungen, Verfahren, Protokolle, Lehrlinge und jemanden, der weiß, wann er den Lehrling davon abhalten muss, die Tischkreissäge zu benutzen.

Die Umgebung ist wichtig, weil die reine Modellfähigkeit nicht ausreicht. Das war die zentrale Lehre der letzten Monate. Der Unterschied zwischen einer beeindruckenden Demo und einem nützlichen System ist im Abstrakten selten „das Modell muss klüger sein“. Oft ist das Modell klug genug, aber die Umgebung um es herum ist dumm.

Es hat den falschen Kontext.

Es hat zu viel Kontext.

Es hat keine Möglichkeit zu prüfen, ob es erfolgreich war.

Es hat Werkzeuge, aber keine Disziplin.

Es hat ein Gedächtnis, aber keinen Geschmack.

Es hat Autonomie, aber keine Aufsicht durch Erwachsene.

Es hat eine Aufgabe, aber nicht die eigentliche Aufgabe, weil die eigentliche Aufgabe im Kopf eines Gründers lebt, der sagte „mach es einfach sauber und enterprise-ready“ und dann in einem Meeting verschwand.

Mia ist unser Versuch, diese Aufsicht aufzubauen, ohne die Geschwindigkeit zu opfern, die das Ganze überhaupt erst wertvoll gemacht hat.

Es hat uns geholfen, Software schneller zu bauen und auszuliefern. Es hat uns geholfen, den üblichen Fehlermodus zu vermeiden, bei dem agentenbasiertes Coden für die ersten 80 % funktioniert und uns dann mit einer glitzernden Ruine zurücklässt. Es hat uns geholfen, beim OMR-Festival in Hamburg Anerkennung unter den führenden KI-nativen Entwicklern in Deutschland zu finden. Es hat uns geholfen, Systeme für NGOs und Unternehmen zu bauen, die mehr als einen schicken Prototyp brauchten.

And nun werden wir es als Open Source veröffentlichen.

VIII.

Aus geschäftlicher Sicht fühlt sich das irgendwo zwischen großzügig und dumm an.

Es gibt ein klassisches Startup-Sprichwort, das besagt: Gib niemals dein Geheimrezept preis.

Das ist ein guter Rat, wenn man eine Saucenfirma ist.

Aber ich bin mir weniger sicher, ob das gilt, wenn die Küche in einem fahrenden Zug steht, sich die Zutaten jede Woche ändern und die Hälfte der Köche gerade neue Formen des Feuers entdeckt.

Die naive Version der Open-Source-Veröffentlichung von Mia lautet:

„Wir verschenken unser goldenes Ei.“

Das ist nah dran, aber falsch.

Ein goldenes Ei ist ein statischer Vermögenswert. Man schützt ihn, denn sobald jemand anderes ihn hat, ist der eigene Vorteil weg. Aber in einem sich schnell entwickelnden technischen Bereich ist das Artefakt nur ein Teil des Vorteils. Der tiefere Vorteil ist die Fähigkeit, weiterhin Artefakte an der vordersten Front zu produzieren.

Bessere Analogie:

Wir veröffentlichen eine Karte von einer Expedition, während sich der Kontinent noch selbst neu formiert.

Das kann immer noch gefährlich sein. Karten haben einen Wert. Menschen können sie nutzen. Konkurrenten können von ihnen lernen. Irgendein Berater kann unsere Ideen in eine Präsentation packen, drei Sechsecke hinzufügen und mehr verlangen als wir. Das ist der natürliche Kreislauf des Lebens, nur mit schlechteren Schriftarten.

Aber die Alternative ist schlimmer.

Wenn jedes ernsthafte Team seinen Harness versteckt, bewegen wir uns alle langsamer. Jeder entdeckt die gleichen langweiligen Fehler neu. Jeder lernt unabhängig voneinander, dass zu viel Kontext schlecht ist, dass Agenten eingeschränkte Werkzeuge brauchen, dass Gedächtnis nicht automatisch Weisheit bedeutet, dass lange Aufgaben Kontrollpunkte benötigen, dass „erledigt“ nach Möglichkeit maschinell überprüfbar und andernfalls von Menschen überprüfbar sein muss.

Das ist keine edle Geheimhaltung. Das ist doppeltes Leiden.

In einem langsamen Bereich summiert sich die Geheimhaltung.

In einem schnellen Bereich summiert sich das gemeinsame Lernen.

Der Grund für die Open-Source-Veröffentlichung von Mia ist nicht, dass wir das Agentic Engineering gelöst haben. Das haben wir nicht. Niemand hat das. Der Grund ist, dass wir genügend lokale Probleme gelöst haben, um unsere Fehler und Muster für andere nützlich zu machen, und wir möchten sehen, was passiert, wenn ernsthaftere Teams darauf aufbauen, anstatt bei Null anzufangen.

Und ganz egoistisch gesagt: Der schnellste Weg, die nächsten Probleme zu finden, besteht darin, mehr Menschen mit die aktuelle Lösung kollidieren zu lassen.

IX.

Die Zukunft der Software ist undefiniert.

Normalerweise bedeutet dieser Satz nichts. Er gehört auf die Eröffnungsfolie einer Keynote von jemandem mit einem Headset-Mikrofon und ohne eigene Commits.

Hier meine ich es wörtlich.

Wir wissen nicht, was die Grundeinheit der Softwarearbeit sein wird.

Vielleicht bleibt es das Ticket. Vielleicht wird es die Spezifikation. Vielleicht wird es der Trace. Vielleicht wird es der Harness-Durchlauf. Vielleicht ist das wichtige Artefakt nicht mehr der Code-Diff, sondern die strukturierte Absicht, die den Code-Diff generiert hat, plus die Evaluierung, die beweist, dass er das getan hat, was der Mensch wollte.

Wir wissen nicht, was aus dem Entwickler wird.

Vielleicht schreibt ein Entwickler immer noch hauptsächlich Code. Vielleicht wird ein Entwickler zu einem Systemdesigner, der die Arbeit von Modellen verwaltet. Vielleicht ähneln die besten Entwickler eher Redakteuren, Reviewern, Architekten und Werkzeugmachern. Vielleicht werden Junioren mächtiger, aber auch gefährlicher. Vielleicht werden Senioren wertvoller, wenn sie ihr Urteilsvermögen in Workflows kodieren können, und weniger wertvoll, wenn sie sich nur noch daran erinnern können, wie die Dinge früher gemacht wurden.

Wir wissen nicht, was aus Softwareunternehmen wird.

Vielleicht produzieren dieselben Unternehmen mit weniger Leuten mehr Output. Vielleicht werden winzige Teams beängstigend leistungsfähig. Vielleicht verlagert sich der Engpass von der Implementierung auf Geschmack, Vertrieb, Vertrauen, Domänenzugang und die Bereitschaft, die Verantwortung für das zu übernehmen, was die Agenten getan haben. Vielleicht verbringt die gesamte Branche fünf Jahre damit, herauszufinden, dass das Schreiben von Code nie der schwierige Teil war, und weitere fünf Jahre damit, darüber zu streiten, wer das zuerst gesagt hat.

Wir wissen es nicht.

Das ist der Punkt.

Es gibt kein festgeschriebenes Drehbuch. Es gibt nur Live-Experimente.

Einige davon finden in den großen Laboren statt. Einige in großen Unternehmen mit ernsthaften Einschränkungen und ernsthaften Kunden. Und einige finden in kleinen Räumen mit jungen Teams statt, die eigentlich kein Recht haben, mitzuhalten – außer dass die neue Welt vorübergehend vergessen hat, ihre Zeugnisse zu kontrollieren.

Dies ist ein seltener Moment.

Die Einstiegshürde ist auf so etwas wie Denkkraft, Geschmack, Durchhaltevermögen und die Bereitschaft gesunken, den eigenen Workflow zu sprengen, bevor es jemand anderes tut.

Es wird nicht so offen bleiben.

Im Moment ist die Sache noch lebendig.

Deshalb öffnen wir Mia.

Weil wir mehr Teams im lebendigen Teil des Problems haben wollen.

Weil der nächste Engpass interessanter ist als der aktuelle Burggraben.

Weil die Zukunft der Software schneller von Leuten entdeckt wird, die Notizen vergleichen, als von Leuten, die Screenshots hüten.

Weil, wenn ein kleines Labor in Düsseldorf aus neun Monaten Kollision mit der Realität etwas Nützliches bauen kann, vielleicht ein anderes Team es nehmen, zerlegen, verbessern und uns den nächsten Raum zeigen kann.

Und weil es im Moment immer noch mehr Spaß macht, durch die Tür zu gehen, als mit den Leuten zu streiten, die darauf beharren, dass es eine Wand ist.