Developers are doing less coding than you think.

What happens when AI stops assisting and starts acting?

Agentic development is changing how software gets built. Instead of writing every line of code, developers increasingly define problems, set boundaries and guide AI systems that can execute and improve on their own.

In this article, Viktor Van Steenweghen shares how his role is evolving in practice. From running multiple AI agents in parallel to focusing more on orchestration than execution, his experience offers a clear view of where development is heading.

The biggest shift is not technical, it is mental.

Explore how the role is changing: https://lnkd.in/euhTJy7X

Ernst Weichselbaum starb am 27. Dezember 2024, zwei Tage nach Weihnachten. Er wurde 80 Jahre alt. Der österreichische Berater, Philosoph und Pionier zeitorientierter Arbeitssysteme hinterließ ein Werk, das fast niemand in der Softwareentwicklung gelesen hat. Er hinterließ zudem den OK-Punkt – ein Konzept, das mehr als sieben Jahrzehnte nach Taiichi Ohnos ersten Experimenten bei Toyota endlich den Weg in den Bereich gefunden hat, in dem es am dringendsten benötigt wird.

In diesem Artikel geht es um die Linie, die von Toyota City in den 1950er Jahren über Wien in den 1980er Jahren bis hin zum OK Point führt, wie wir ihn heute kennen: den täglichen Austausch zwischen Konzeptentwicklern und Umsetzern im Herzen der zeitorientierten Softwareentwicklung. Es geht auch darum, warum diese Linie 70 Jahre gebraucht hat, um uns zu erreichen, und warum es wichtig ist, dass wir anerkennen, auf wessen Schultern wir stehen.

Die Entdeckung in Toyota City

Taiichi Ohno wurde 1912 in Dalian an der mandschurischen Küste geboren. Er trat als junger Ingenieur bei Toyota Spinning and Weaving ein und wechselte 1943 zur Toyota Motor Company. In den folgenden drei Jahrzehnten entwickelte er – fast im Verborgenen – das, was später als „Toyota-Produktionssystem“ bekannt werden sollte: eine Reihe von Methoden, die so radikal waren, dass westliche Führungskräfte, die Toyotas Fabriken besichtigten, jahrelang mit dem Eindruck zurückkehrten, ihnen entginge etwas. Und das tat es auch.

Das, was ihnen fehlte, war einfach zu beschreiben, aber fast unmöglich zu verinnerlichen. Ohno hatte die grundlegende Annahme der industriellen Produktion auf den Kopf gestellt. Im Westen ging man davon aus, dass die Kapazität feststeht – man hat seine Maschinen, seine Arbeiter, seine Arbeitszeiten – und die Lieferzeit schwankt um diese herum. Steigt die Nachfrage, werden die Warteschlangen länger, die Kunden warten. Sinkt die Nachfrage, stehen die Maschinen still, werden Arbeiter entlassen. Die Kapazität ist die Konstante; die Zeit ist die Variable.

Ohno tat das Gegenteil. Er legte die Zeit fest und ließ die Kapazität schwanken. Er konzipierte Toyota so, dass die Produktion mit gleichmäßigen, zuverlässigen Lieferungen – der berühmten Taktzeit – auf die Kundennachfrage reagierte und sich die Kapazität des Systems selbst anpasste, um diesen Rhythmus aufrechtzuerhalten. Wo sich die Kapazität nicht anpassen ließ, gestaltete Ohno sie so, dass sie umgestaltet werden konnte. Multifunktionale Mitarbeiter. Schnellwechselwerkzeuge. Kleine Losgrößen. Pull statt Push. Das Ergebnis war in den 1970er Jahren ein Fertigungssystem, das Autos in einer Qualität und zu Kosten produzieren konnte, mit denen westliche Autohersteller nicht mithalten konnten, ohne die zugrunde liegende Philosophie zu kopieren. Die meisten von ihnen versuchten, nur die äußeren Merkmale zu kopieren – die Kanban-Karten, die Andon-Schnüre – und scheiterten.

Ohno hat die grundlegende Erkenntnis aller Zeitorientierung erkannt: Die Welt schwingt. Die Nachfrage schwingt. Die Jahreszeiten schwingen. Die Erde schwingt. Arbeitssysteme aufzubauen, die so tun, als wäre dies nicht der Fall, bedeutet, gegen die Physik zu arbeiten. Arbeitssysteme aufzubauen, die mit der Welt schwingen, bedeutet, mit ihr zu arbeiten.

Der Philosoph, der die Fackel trug

Ohno war ein Praktiker. Er war zudem, allen Berichten zufolge, ein schwieriger Mensch – direkt, unverblümt und intolerant gegenüber der ausweichenden Sprache, die den Großteil des Managementdenkens umgibt. Er verfasste drei Bücher, von denen eines ins Englische übersetzt wurde. Er starb 1990, nachdem er miterlebt hatte, wie das Toyota-Produktionssystem weltberühmt und fast überall missverstanden wurde.

Etwa zur gleichen Zeit, als westliche Berater damit beschäftigt waren, TPS in „Lean Manufacturing“ umzuwandeln – eine freundliche, vermarktbare, etwas entschärfte Version von Ohno’s Werk –, war in Österreich ein Denker ganz anderer Art am Werk. Ernst Weichselbaum war ein Berater, der Jahrzehnte in produzierenden Unternehmen verbracht hatte, wo er mit den von Ohno entwickelten Systemen arbeitete, dabei aber andere Fragen zu ihnen stellte. Weichselbaum war ein Philosoph im älteren Sinne des Wortes: jemand, der versuchte, die Prinzipien hinter der Praxis zu verstehen, und nicht jemand, der diese Praktiken in Schulungen verpacken wollte.

Weichselbaums einzigartiger Beitrag, auf den wir bei TOSD täglich zurückgreifen, war der „OK-Punkt“. In seiner ursprünglichen Formulierung befand sich der OK-Punkt an der Schnittstelle zwischen Kunde und Lieferant. Es war der Moment der Einigung – konkret, bezeugt, oft physisch –, in dem ein Projekt von der Konzeptphase, in der die Anforderungen noch verhandelbar waren, in die Umsetzungsphase überging, in der dies nicht mehr der Fall war. Vor dem OK-Punkt konnten beide Seiten noch darüber sprechen, wie die Arbeit aussehen sollte. Danach verlagerte sich das Gespräch darauf, ob die Arbeit wie vereinbart ausgeführt wurde. Der OK-Punkt war der Moment, in dem Transparenz unvermeidlich wurde: nicht, weil jemand sie erzwang, sondern weil das Überschreiten dieses Punktes beide Parteien an dieselbe gemeinsame Definition von „fertig“ band.

Weichselbaum erkannte, was Ohno erkannt hatte – dass der Wert der Zeitorientierung nicht in der Geschwindigkeit liegt, sondern in der Disziplin, die die Zeitorientierung schafft. Doch er dehnte Ohnos Erkenntnis nach innen aus, vom Fließband hin zum Gesprächsgeschehen. Der OK-Punkt ist eine zeitliche Struktur, die in einer Beziehung zwischen zwei Parteien existiert. Das ist auch der Grund, warum sich Zeitorientierung anders anfühlt als Lean: Lean versucht, Verschwendung zu beseitigen, Zeitorientierung versucht, Rhythmus zu gestalten.

Weichselbaum widmete seine Karriere der Einführung von Zeitorientierung in Unternehmen, die noch nie von Toyota gehört hatten. Er arbeitete mit produzierenden Unternehmen zusammen, aber auch mit Organisationen im Bereich der Wissensarbeit. Er verfasste nur wenige Schriften. Das meiste, was wir über sein Denken wissen, stammt von den Menschen, die er beeinflusst hat – darunter Niels Pflaeging, der den kürzlich erschienenen Band „What would Ernst Weichselbaum do?“ herausgegeben hat und der mehr als jeder andere dafür gesorgt hat, dass Weichselbaums Name nicht in derselben Anonymität verschwindet, die so viele von Ohno’s tatsächlichen Mitarbeitern umgab.

Die 70-jährige Lücke

Hier ist die Frage, die uns beschäftigt hat, während wir TOSD aus diesem Erbe aufgebaut haben: Warum hat es 70 Jahre gedauert, bis die Zeitorientierung die Softwareentwicklung erreicht hat?

Die ehrliche Antwort lautet: Die Softwareentwicklung hat sich dagegen gewehrt. Sie hat sich aus Gründen gewehrt, die bei nüchterner Betrachtung wenig schmeichelhaft sind. Der erste und am weitesten verbreitete Grund war die Überzeugung, dass Software Kunst sei. Durch diese Einordnung in den Kunstkontext fühlte sich jeder Versuch, der Entwicklung eine zeitliche Struktur zu geben, wie ein Verstoß gegen die kreative Integrität an. Außerdem entband sie die Branche bequemerweise von der Disziplin, die andere Bereiche des Ingenieurwesens längst akzeptiert hatten. Die kapazitätsorientierte Herangehensweise mit ihren langen Planungshorizonten und ihrer Toleranz gegenüber Terminüberschreitungen passte perfekt zu einer Praxis, die im Kunstkontext verortet war. Die zeitorientierte Herangehensweise tat dies nicht.

Der zweite Grund war, dass die frühe Agile-Bewegung um das Jahr 2001 herum die eine Hälfte von Ohno’s Erkenntnis aufgriff und die andere Hälfte verwarf. Das Agile Manifest und die Methoden, die sich darum herum entwickelten – Scrum, dann Kanban, dann die Skalierungs-Frameworks – übernahmen den „Small-Batch“-Ansatz aus Lean und nannten ihn „Iteration“. Aber sie behielten die Kapazitätsorientierung als zugrunde liegenden Rahmen bei. Ein Scrum-Team hat eine feste Kapazität, ausgedrückt in Story-Points, von der angenommen wird, dass sie stabil ist. Sprints kommen und gehen; was schwankt, ist das, was in sie hineinpasst. Das ist die Wand, die mit einer anderen Farbe gestrichen wurde. Ohno hätte darin keine Zeitorientierung erkannt.

Der dritte Grund war soziologischer Natur. Zeitorientierung führt zu einer Dezentralisierung der Macht. Sie lässt sich nicht mit der dichten Schicht von Vermittlerrollen – Product Owner, Scrum Master, Agile Coaches, Projektmanager, Architekten im Titel – vereinbaren, die sich in den letzten zwei Jahrzehnten rund um die Softwareentwicklung gebildet hat. Eine ganze Branche hat sich um die Aufrechterhaltung dieser Rollen herum organisiert. Zeitorientierung bedeutet unter anderem das Verschwinden dieser Branche. Wie zu erwarten war, hat die Branche diese Entwicklung nicht gerade begeistert aufgenommen.

Der vierte und vielleicht entscheidende Grund war, dass KI die Rechnung verändert hat. Bevor KI-Assistenten ins Spiel kamen, war der Aufwand beim Tippen von Code so groß, dass die Kapazitätsorientierung vorgeben konnte, das richtige Modell zu sein. Sobald die KI den Aufwand für das Tippen auf nahezu null senkte, verlagerte sich der Engpass. Er verlagerte sich zum Denken – zur Präzision dessen, was gebaut wird, bevor es gebaut wird. Ein Bereich, in dem der Engpass die Präzision ist, ist ein Bereich, der einen OK-Punkt benötigt. Die Software hatte schließlich keinen Ort mehr, an dem sie sich verstecken konnte.

Die Übertragung auf TOSD

Im White Paper Nr. 26 beschreiben wir den „OK-Punkt“ in der Softwareentwicklung. Die Übertragung von Weichselbaums „Kunde-Lieferant-Nahtstelle“ ist nicht metaphorisch gemeint: Die Struktur ist dieselbe, nur die Parteien sind andere. In TOSD ist der „OK-Punkt“ die Nahtstelle zwischen Konzeption und Realisierung. Der Konzeptionist übernimmt die Rolle der konzeptionellen Seite; der Realisierer übernimmt die Rolle der realisierenden Seite. Der Handschlag ist ein tägliches Ritual, kein vertragliches, aber der zugrunde liegende Mechanismus – es wird eine Einigung erzielt, die Einigung wird bezeugt, die Arbeit überschreitet eine Schwelle – entspricht dem, was Weichselbaum beschrieben hat.

Wir haben auch den von Ohno entdeckten Rhythmus fast unverändert übernommen. Tägliche Portionen sind die Kadenz des Fließbandes in der Softwareentwicklung. Die Zeitbox der Realisierung (ein, zwei oder drei Tage) ist die kleine Charge. Das TTEO-Prinzip – „Talk To Each Other“ (Miteinander reden) – ist die Andon-Schnur, an der jederzeit gezogen wird, wenn etwas nicht stimmt. Das Zellstruktur-Design ist in vielerlei Hinsicht die Philosophie der vielseitig qualifizierten Arbeitskräfte, angewandt auf eine gesamte Organisation. Das sind keine Zufälle. Es sind die strukturellen Grundsätze jedes zeitorientierten Arbeitssystems, übertragen auf einen Bereich, den Ohno nie gesehen hat und den Weichselbaum sich erst zu erahnen begann.

Warum die Tradition wichtig ist

Es wäre einfach und verlockend, TOSD als etwas Neues darzustellen. Aus marketingtechnischer Sicht ist es das auch. Aus intellektueller Sicht ist es jedoch der jüngste Ausdruck eines 70-jährigen Projekts. Ich halte diese Unterscheidung aus mindestens drei Gründen für wichtig.

Erstens verschafft die Tradition jedem, der TOSD anwendet, Zugang zur umfassenderen Fachliteratur. Wenn Sie sich damit schwertun, wie die Kapazität in Ihrer Organisation schwanken sollte, müssen Sie die Antwort nicht von Grund auf neu erfinden – Ohno hat diese Frage bereits ausführlich für einen Bereich beantwortet, der schwieriger ist als der Ihre. Wenn Sie sich damit schwertun, wie sich der „OK-Punkt“ in der Praxis anfühlt, können Sie Weichselbaum lesen und seine ursprüngliche Formulierung nachschlagen. Die Menschen von diesem Erbe abzuschneiden, indem man so tut, als sei TOSD im Oktober 2025 erfunden worden, würde die Praxis verarmen lassen.

Zweitens schützt die Herkunft vor der häufigsten Fehlerquelle neuer Methoden, nämlich der stillschweigenden Wiedereinführung alter Annahmen. Die Zeitorientierung wurde sieben Jahrzehnte lang kontinuierlich abgelehnt, neu interpretiert und wieder vereinnahmt. Die Kenntnis der Geschichte hilft Ihnen, die Muster zu erkennen, wenn sie bei TOSD auftreten. Und das werden sie.

Drittens, und das ist das Wichtigste: Diese Tradition mahnt uns zur Demut. Ohno starb, bevor er erleben konnte, dass seine Arbeit richtig verstanden wurde. Weichselbaum starb, bevor er erleben konnte, dass seine Arbeit in Software Einzug hielt. Das Mindeste, was wir tun können, um diese Linie um ein weiteres Segment zu verlängern, ist, die Menschen zu nennen, deren Erkenntnisse wir in die Praxis umsetzen. Das Whitepaper Nr. 26 ist Weichselbaum gewidmet. Das Whitepaper Nr. 27 ist Ohno gewidmet. Jeder, der TOSD nutzt, hält – ob er es weiß oder nicht – diese Linie ebenfalls am Leben.

Wir hoffen, dass zukünftige Praktiker sie weiter ausbauen werden. Ich hoffe, dass jemand im Jahr 2050 auf unsere heutige Darstellung zurückblicken und sie als primitiv empfinden wird – nicht, weil sie falsch war, sondern weil sieben Jahrzehnte weiterer Arbeit sie so erscheinen lassen. So funktionieren schließlich Traditionen.

Erfahren Sie mehr über TOSD: https://timeoriented.dev

Unser Büro ist ausgezeichnet!

Unser Büro wurde vom Callwey Verlag als einer der „Best Workspaces 2026“ ausgezeichnet und in das gleichnamige Jahrbuch aufgenommen. Damit gehört unser Pradtke HQ jetzt auch offiziell zu den herausragenden Arbeitsorten des Jahres 2026. Für uns ist diese Auszeichnung weit mehr als ein Designpreis. Sie bestätigt unsere Überzeugung, dass Räume nicht Kulisse sind, sondern ein integraler Bestandteil organisationaler Wirksamkeit. Arbeitsräume prägen Verhalten, Zusammenarbeit und Kultur.

Unser Büro sieht nicht nur gut aus, sondern fühlt sich auch so an: Es gibt uns viel Raum für kollegiale Kommunikation, konstruktive Konzentration, für unsere Kunden und für Kulinarik. Denn alle, die im Büro sind, begegnen sich jeden Tag bei einem gemeinsamen Mittagstisch, zu dem wir uns selbst einladen.

Software development is about solving challenges together. The B2Run Karlsruhe offered a different kind of challenge: a 5.5 km running course through Karlsruhe.

Runners from IT-Choice Software GmbH, medavis GmbH, and synava came together as one synava group team. All with different roles, different expertise and experience. 

The 5.5 km course wasn’t about finishing times. It was about collaboration, mutual support, and the energy that comes from working toward a shared goal.

Moments like these remind us that strong teams are built not only through projects, but through shared experiences.

One of the highlights: after the run, there was plenty of time to connect, celebrate together, and enjoy the great atmosphere at the team tent - all with perfect weather ☀️ and lots of positive energy.

For us, events like these matter. They create connections across teams, strengthen relationships, and remind us that behind every successful software solution is a group of people who enjoy achieving great things together.

Wir freuen uns riesig, auch in diesem Jahr wieder beim HerHackathon in Mannheim dabei zu sein – als Sponsor und erneut mit einer Challenge für die Teilnehmerinnen.

Was erwartet Euch? 48 Stunden voller Möglichkeiten! Zeigt uns, was in Euch steckt und nutzt die Chance, Eure Kreativität und Euer Können unter Beweis zu stellen. Gleichzeitig habt Ihr die Gelegenheit, mit Tech-Talenten aus ganz Europa zu netzwerken und vielleicht sogar Freundschaften zu schließen. 🦸‍♀️

Na, Lust bekommen mitzumachen? Dann bewerbt Euch bis zum 3. Juni HIER, die Teilnahme ist kostenlos.