Die Brücke der Enterprise-D: Die 80er-Jahre-Schrankwand des Weltraums

In den meisten Science-Fiction-Werken ist die Brücke eines Raumschiffs ein Ort der harten Funktionalität. Stahl, blanke Metallflächen, freiliegende Kabelbündel, Rohre an der Decke, blinkende Warnlampen und Sitze, die eher an Schleudersitze als an Möbel erinnern. Die Technik dominiert den Raum – und damit die Menschen, die darin arbeiten. Die Brücke der USS Enterprise-D aus Star Trek: The Next Generation (1987–1994) macht genau das Gegenteil. Sie ist keine Kommandozentrale im klassischen Sinne. Sie ist eine 80er-Jahre-Schrankwand im Weltraum.

Alles verschwindet hinter eleganten Fronten
Wer die Brücke der Enterprise-D betritt, sieht zuerst keine Technik. Man sieht eine großzügige, runde, fast wohnliche Fläche mit weichem Teppichboden in warmen Rottönen, beigefarbenen Wandverkleidungen und Holzimitat-Elementen. Die Konsolen sind nicht aufgeständert oder freiliegend, sondern in geschwungene, holzverkleidete Möbelelemente integriert. Die LCARS-Oberflächen (die charakteristischen bunten Touchscreens) wirken wie flache, elegante Einbaugeräte – vergleichbar mit einem hochwertigen HiFi-Turm oder einem flachen TV-Gerät, das in eine Schrankwand eingelassen wurde.
Was nicht ständig gebraucht wird, verschwindet. Stationen können deaktiviert oder ihre Funktionen auf andere Oberflächen verlagert werden. Der große Hauptschirm am vorderen Ende der Brücke ist kein technisches Monstrum, sondern wirkt wie ein riesiges Panoramafenster oder ein überdimensionaler Wohnzimmer-Fernseher. Die gesamte Technik – Sensoren, Waffensysteme, Navigation, Lebenserhaltung – ist hinter sauberen Verkleidungen, Paneelen und Möbelfronten versteckt. Genau wie bei einer klassischen deutschen Schrankwand der späten 80er: Hinter den Türen und Klappen verschwinden Fernseher, Videorekorder, Stereoanlage, Platten, Bücher und Alkohol. Was man nicht sieht, stört nicht. Der Raum bleibt aufgeräumt, wohnlich und repräsentativ.

Komfort zuerst – die Sitzgelegenheiten als Statement
Die Stühle auf der Brücke der Enterprise-D sind keine funktionalen Pilotensitze. Sie sind gepolsterte, fast loungeartige Sessel mit weicher Polsterung, Armlehnen und einer Form, die stundenlanges Sitzen ermöglicht. Der Captain’s Chair in der Mitte ist ein echtes Möbelstück: breit, bequem, mit integrierten Bedienelementen, die man fast nebenbei bedient. Man sitzt nicht „auf“ der Technik – man sitzt in einem Raum, der zum Verweilen einlädt.
Das ist der entscheidende Unterschied zu fast allen anderen Raumschiff-Brücken der Filmgeschichte. In der Nostromo (Alien), im Millennium Falcon oder auf den Brücken vieler Militärraumschiffe ist der Mensch dem Gerät untergeordnet. Man hockt in engen Sitzen, umgeben von blinkenden Schaltern und harten Kanten. Auf der Enterprise-D hingegen ist die Technik dem Menschen untergeordnet. Sie darf nicht stören, nicht ermüden, nicht einschüchtern. Sie soll dienen – und zwar komfortabel.

Kein Maschinenraum-Feeling
Andere Science-Fiction-Produktionen zelebrieren das industrielle, schmutzige, „echte“ Raumschiff: sichtbare Schweißnähte, tropfende Rohre, Kabel, die offen über die Decke laufen, Stahlblech überall. Die Brücke ist dort oft nur eine etwas aufgeräumtere Version des Maschinenraums. Die Enterprise-D verweigert dieses Klischee radikal. Es gibt auf ihrer Brücke keinen sichtbaren Stahl, keinen Dreck, keine hervorstechende Technik. Die Wände sind glatt, die Decken klar strukturiert, der Boden weich. Selbst die Beleuchtung ist indirekt und warm – kein kaltes Neon oder grelle Spotlights.
Das ist kein Zufall. Gene Roddenberry wollte mit The Next Generation eine optimistischere, humanere Zukunft zeigen. Die Brücke sollte kein Ort der Angst oder der reinen Kontrolle sein, sondern ein Ort der ruhigen, zivilisierten Entscheidungsfindung. Genau wie eine gute Schrankwand nicht nur Stauraum bietet, sondern auch den Raum strukturiert und ihm eine angenehme Atmosphäre verleiht.

Die Philosophie hinter dem Design
Die Enterprise-D-Brücke ist das architektonische Manifest einer Gesellschaft, die Technik nicht mehr als Selbstzweck begreift. Die Technik ist da – hochentwickelt, mächtig, allgegenwärtig –, aber sie ist unsichtbar gemacht. Sie stört nicht die menschliche Interaktion, sie behindert nicht die körperliche Bequemlichkeit und sie dominiert nicht die Ästhetik des Raums.
In einer Zeit, in der viele Science-Fiction-Werke auf „realistisches“ industrielles Design setzten (und damit oft nur die Ästhetik von Fabrikhallen und U-Booten ins All übertrugen), war die Enterprise-D ein radikaler Gegenentwurf: eine Brücke, die wie ein hochwertiges, durchdachtes Wohnzimmermöbel der späten 80er Jahre wirkt. Elegant, aufgeräumt, komfortabel – und mit der gesamten Technik perfekt hinter eleganten Fronten versteckt.
Das ist keine Schwäche. Das ist eine bewusste Designentscheidung mit philosophischer Tiefe. Die Enterprise-D sagt: In einer reifen Zivilisation muss man sich nicht mehr von blinkenden Maschinen und harten Oberflächen einschüchtern lassen. Die Technik hat ihren Platz – aber sie hat ihn hinter den Fronten einer gut gestalteten Schrankwand gefunden. Und genau dort, wo sie hingehört: im Dienst des Menschen, nicht umgekehrt.
Die Brücke der Enterprise-D ist nicht nur ein Raumschiff-Set. Sie ist ein utopisches Möbelstück – und vielleicht das schönste Argument dafür, dass eine bessere Zukunft auch schöner aussehen darf.

AI macht Fehler deutlich … AI ist doof?

Mich interessiert schon lange, welche Erfahrungen andere Menschen mit AI machen. Dabei geht es mir nicht nur um Entwickler, auch wenn die Geschichten aus der Softwareentwicklung für mich natürlich besonders spannend sind. Vielleicht gerade deshalb, weil ich selbst Entwickler bin. In letzter Zeit begegnen mir immer häufiger Beiträge von Entwicklern, die wieder mehr Abstand von AI nehmen wollen, weil sie angeblich langsamer geworden sind, die Code-Qualität leidet oder plötzlich überall Sicherheitslücken auftauchen.

Ich selbst habe in den letzten Jahren in vielen verschiedenen Firmen gearbeitet. Ich habe Projekte komplett alleine umgesetzt, kleine Teams geleitet, Aufgaben für Junior-Entwickler vorbereitet und Diskussionen mit anderen Senior-Entwicklern geführt. Dadurch habe ich sehr unterschiedliche Arbeitsweisen gesehen und vor allem gelernt, wie unterschiedlich Menschen mit Qualität, Verantwortung und Prozessen umgehen.

Ich versuche heute, AI so viel wie möglich und gleichzeitig sinnvoll einzusetzen. Wenn ich einen einzelnen CSS-Wert ändern muss, mache ich das selbst, weil es einfach schneller geht. Wenn ich aber ein riesiges Formular bauen muss, dessen Felder ohnehin schon feststehen, lasse ich die AI den Großteil generieren. Solcher Code ist selten komplex, aber zeitaufwendig. Das gleiche gilt für Twig-Templates, die Daten aus einem Formular in eine PDF übertragen. Das ist meist eine primitive 1:1-Abbildung, bei der die AI einfach schneller ist als ich. Auch PHP-Code lasse ich so weit wie möglich generieren, korrigiere aber kleine Dinge selbst oder gebe der AI gezielte Vorgaben, damit sie in die richtige Richtung arbeitet.

Trotzdem liest man immer häufiger, dass Entwickler AI wieder ablehnen. Oft kommt dann der Zusatz, man würde AI ja schon „seit ChatGPT angefangen hat“ nutzen. Das klingt erstmal nach Erfahrung, sagt aber eigentlich nichts aus. Die Qualität heutiger Modelle hat mit den ersten Versionen kaum noch etwas gemeinsam. Prompts sind einfacher geworden, der Output deutlich besser und viele Probleme von damals existieren heute schlicht nicht mehr. Die Aussage soll Kompetenz vermitteln, obwohl sie inhaltlich wenig Wert hat. Entwickler, die seit Jahren AI nutzen, erzeugen nicht automatisch besseren Output als jemand, der erst vor zwei Wochen angefangen hat.

Ein weiteres häufiges Argument ist, dass AI zwar schnell Code produziert, man sich den Code danach aber noch anschauen müsse. Für mich klingt das oft so, als hätten manche Entwickler früher einfach ihren eigenen Code geschrieben und ihn direkt als „fertig“ betrachtet, nur weil sie ihn selbst erzeugt haben. Sobald AI beteiligt ist, muss der Code plötzlich verstanden und geprüft werden — und das kostet Zeit. Persönlich kenne ich es eigentlich nur aus Projekten, an denen ich komplett alleine gearbeitet habe, dass ich meinen eigenen Code selbst überprüft habe. Meistens einfach deshalb, weil niemand anderes da war. Denn eigentlich ist man selbst nicht dafür geeignet, den eigenen Code abzunehmen.

Code-Reviews sind nichts Neues. Sie sollten immer stattfinden, egal ob der Code von einem anderen Entwickler oder von einer AI stammt. Wer Reviews jetzt plötzlich als zusätzliche Belastung wahrnimmt, hat vermutlich vorher schon keine vernünftigen Reviews gemacht. Für mich liegt genau dort das eigentliche Problem.

Ähnlich ist es beim Refactoring von altem AI-generiertem Code, der sich später als schlecht oder fehleranfällig herausstellt. Die Definition von gutem Code hat sich nicht plötzlich geändert. Warum fällt also erst jetzt auf, dass der Code problematisch ist? Hat ihn vorher niemand angesehen? Wahrscheinlich hätte ein ordentliches Review vieles verhindert. Dazu kommt, dass die Qualität heutiger AI-Modelle im Vergleich zu vor einem Jahr massiv gestiegen ist. Fehler, die man damals gemacht hat, kann man nicht der heutigen AI anlasten.

Besonders spannend finde ich die Diskussion rund um Sicherheitslücken und offene Datenbanken. Viele dieser Geschichten wirken auf mich weniger wie ein AI-Problem und mehr wie ein Problem von Menschen, die sich mit Entwicklung nicht ausreichend auskennen und den erzeugten Code nie überprüft haben. Wer die Grundlagen nicht versteht, liefert meist auch schlechte oder inkonsistente Prompts. Vielleicht wäre oft sogar ein einfacherer Prompt besser gewesen, weil moderne AI-Systeme standardmäßig eher versuchen, sichere Patterns zu verwenden. Keine AI schreibt absichtlich Code, der SQL-Injections erlaubt, wenn stattdessen Prepared Statements oder Framework-Lösungen möglich sind.

Ich würde sogar behaupten, dass viele dieser Leute auch ohne AI massive Sicherheitsprobleme gebaut hätten. Der Unterschied ist nur, dass AI jetzt sichtbar macht, wie schlecht manche Entwicklungsprozesse vorher schon waren. Ironischerweise hätte man viele dieser Sicherheitsprobleme sogar direkt wieder mit AI finden können, denn genau dafür eignet sie sich inzwischen ebenfalls erstaunlich gut.

Neulich habe ich außerdem wieder Diskussionen über angeblich enttäuschende Ergebnisse bei Anthropic gelesen. Dort wurde kritisiert, dass die gefundenen Sicherheitslücken alle auch von Menschen hätten entdeckt werden können. Das erinnert mich stark an Aussagen wie: „Diese Idee hätte ich auch haben können.“ Ja, vielleicht. Aber du hast sie eben nicht gehabt. Niemand behauptet, dass AI Dinge kann, die grundsätzlich außerhalb menschlicher Fähigkeiten liegen. Der Punkt ist doch vielmehr, dass die AI diese Sicherheitslücken tatsächlich gefunden hat — und zwar schnell. Zu behaupten, eine AI sei schlecht, weil sie etwas nicht kann, was ihr Hersteller nie versprochen hat, ist kein sinnvolles Argument.

Am Ende tut AI genau das, was sie soll. Mal besser, mal schlechter als ein Mensch. Aber fast immer deutlich schneller. Und meiner persönlichen Erfahrung nach oft auch qualitativ besser, zumindest bei vielen alltäglichen Aufgaben. Solange man vernünftige Code-Reviews macht, regelmäßig committet und sich den Output anschaut, ist AI eine enorme Hilfe.

Wer erwartet, dass man einen einzigen Prompt eingibt und danach perfekte, fehlerfreie Software entsteht, erwartet schlicht das Falsche. Und wer glaubt, Menschen würden weniger Fehler machen oder weniger halluzinieren als AI, der braucht vielleicht einfach mal wieder eine kleine Portion Realität.

Ticket oder Prompt? Wie sich kleine Aufgaben gerade neu erfinden

Es beginnt unspektakulär: eine kleine HTML-Seite, ein Suchfeld, das eine Tabelle filtert. Nichts, was man nicht schon dutzendfach gebaut hätte. Dann kommen noch ein paar zusätzliche Filter dazu, klassisch per Select umgesetzt, funktional, aber nicht besonders aufregend. Also mache ich das, was ich immer mache: Ich schreibe ein Ticket, halte die Anforderungen fest, schaue mir den bestehenden Code an und notiere mir die Schritte zur Umsetzung. Nebenbei fallen mir noch ein paar Verbesserungen ein, die ich direkt mit aufnehme.

Während ich das alles zusammentrage, passiert etwas Interessantes. Ich merke, dass ich gedanklich längst nicht mehr nur dokumentiere. Ich formuliere bereits eine Lösung. Eigentlich schreibe ich keinen klassischen Ticket-Text mehr, sondern etwas, das sich verdächtig wie ein Prompt anfühlt. Eine strukturierte Beschreibung dessen, was gebaut werden soll, inklusive Kontext, Details und Erwartungen.

Also drehe ich den Spieß einfach um und kippe alles in ein Tool wie Jira nicht nur als Ticket, sondern parallel als Prompt gedacht. Zwei Minuten später steht der Code. Funktionierend, nachvollziehbar, mit allem, was ich vorher noch mühselig selbst umgesetzt hätte. Eine kleine Anpassung fällt mir noch ein, also formuliere ich auch das direkt als Prompt und dokumentiere ihn gleich im Ticket.

Am Ende bleibt eine Frage hängen: Lohnt es sich überhaupt noch, erst ein Ticket zu schreiben und anschließend daraus einen Prompt zu machen? Oder ist der Prompt längst das eigentliche Artefakt geworden?

Ein guter Prompt enthält in der Regel alles, was auch in einem sauberen Ticket stehen würde. Kontext, Ziel, Anforderungen, vielleicht sogar schon Hinweise zur Umsetzung. Der Unterschied liegt weniger im Inhalt als in der Intention. Das Ticket war früher der Startpunkt der Entwicklung. Heute fühlt es sich oft schon wie ein halber Abschluss an. Sobald die Beschreibung gut genug ist, kann die Umsetzung fast unmittelbar folgen.

Das wirft zwangsläufig die nächste Frage auf: Ist ein Ticket einfach nur ein Prompt in anderer Form, oder ersetzt der Prompt das Ticket komplett? Für größere Vorhaben mag die Trennung weiterhin sinnvoll sein, allein schon wegen Abstimmung, Planung und Dokumentation. Aber bei kleinen Aufgaben kippt das Gleichgewicht spürbar. Hier wirkt es effizienter, direkt in Prompts zu denken und zu formulieren.

Interessant wird es, wenn man diesen Gedanken weiterführt. Wenn ein Prompt die Umsetzung in Minuten liefern kann, warum dann nicht den gesamten Ablauf darauf aufbauen? Ein Ticket wird als Entwurf geschrieben, im Refinement besprochen und freigegeben. Direkt danach übernimmt ein Agent die Umsetzung, ergänzt vielleicht sogar Unit Tests, committed den Code und erstellt einen Pull Request. Während das Meeting noch läuft, kann das Team im Grunde schon mit Review und Testing beginnen.

Plötzlich verschiebt sich die Dynamik im Team. Entwicklung wird kollaborativer, ohne zusätzlichen Zeitaufwand. Mehr Augen schauen auf das Ergebnis, ohne dass mehr Stunden investiert werden müssen. Die klassische Grenze zwischen Planung und Umsetzung verschwimmt, weil beides enger zusammenrückt.

Und genau hier liegt vielleicht der spannendste Effekt: Qualität entsteht nicht mehr nur durch sorgfältige Implementierung, sondern schon durch die Qualität der Beschreibung. Wenn das, was früher ein Ticket war, heute bereits ausführbar ist, dann entscheidet die Präzision im Denken und Formulieren über einen Großteil des Ergebnisses.

Vielleicht ist die eigentliche Veränderung also gar nicht, dass Prompts Tickets ersetzen. Sondern dass Tickets anfangen, sich wie Prompts zu verhalten.

AI und Security: Ein paar Gedanken zur aktuellen Entwicklung

In den letzten Wochen bin ich immer wieder über Diskussionen rund um neue KI-Modelle im Sicherheitskontext gestolpert, insbesondere über Systeme wie Anthropics „Mythos“. Spannend fand ich dabei vor allem, dass dieses Modell zunächst nur ausgewählten Herstellern zur Verfügung gestellt wurde, damit sie bestehende Sicherheitslücken schließen können, bevor die breite Öffentlichkeit Zugriff erhält. Allein diese Vorgehensweise zeigt schon, wie ernst das Thema genommen wird.

Auf den ersten Blick wirkt es beeindruckend, fast schon beängstigend: Eine KI, die innerhalb weniger Stunden eine umfangreiche Codebasis analysieren, Schwachstellen identifizieren und sogar funktionierende Exploits entwickeln kann. Das klingt nach einem Szenario, in dem plötzlich jedes Softwareprodukt akut gefährdet ist, sobald ein solches System frei verfügbar wird.

Viele Sicherheitslücken sind nämlich weder besonders tief versteckt noch außergewöhnlich komplex. Häufig wurden sie schlicht übersehen oder bewusst als akzeptables Risiko eingestuft. Genau solche Schwachstellen lassen sich aber bereits heute von bestehenden LLMs identifizieren, erklären und oft sogar mit passenden Proof-of-Concept-Skripten versehen. Der eigentliche Unterschied bei neueren Systemen wie Mythos liegt vermutlich eher in größeren Kontextfenstern und einer besseren Ausdauer bei langwierigen Analysen als in völlig neuen Fähigkeiten. Die Grundlage ist also längst vorhanden, was bedeutet, dass Software schon heute angreifbar ist und nicht erst durch die Veröffentlichung solcher Modelle.

In diesem Zusammenhang habe ich selbst ein kleines Experiment gemacht und ein internes Tool mit einer KI scannen lassen. Die gefundenen Sicherheitsprobleme waren sauber und nachvollziehbar identifiziert, allerdings nichts, was mir nicht bereits bekannt gewesen wäre. Ich hatte diese Schwachstellen vor einigen Jahren bewusst als unkritisch eingestuft, als das Tool entstanden ist. Interessant ist nun, dass sich solche Probleme heute in wenigen Minuten beheben lassen, wenn man die Unterstützung von KI nutzt. Das zeigt sehr deutlich, dass künstliche Intelligenz nicht nur eine potenzielle Bedrohung darstellt, sondern bereits jetzt ein äußerst hilfreiches Werkzeug im Sicherheitsbereich sein kann.

Die größte Herausforderung – und gleichzeitig auch die größte Chance – sehe ich allerdings im Bereich der Legacy-Software. Über die Jahre sammelt sich bei vielen Entwicklern eine Vielzahl an Projekten, Tools, Systemen und Frameworks an, die irgendwann aus dem Fokus geraten sind, aber oft noch produktiv genutzt werden. Auch ich erkenne bei mir selbst viele Altlasten: alte Installationen, nicht aktualisierte Systeme, veraltete Plugins oder Frameworks, die irgendwo noch im Einsatz sind. Gerade bei solchen Konstrukten kann ein System wie Mythos zum dringend benötigten Weckruf werden.

Vielleicht ist es genau dieser „Arschtritt“, den viele gebraucht haben, um sich endlich wieder um ihre bestehenden Systeme zu kümmern. Statt sich auf dem Gedanken „Never change a running system“ auszuruhen, sollte man beginnen, genau diese Systeme regelmäßig zu überprüfen, zu aktualisieren oder zumindest besser abzusichern. Denn ein System, das heute noch läuft, könnte morgen bereits ein ernsthaftes Risiko darstellen.

Ich habe mir jedenfalls vorgenommen, meine eigenen Altlasten genauer unter die Lupe zu nehmen. Dazu gehört, alte Ubuntu-LTS-Versionen zu identifizieren und zu aktualisieren, genauso wie Container-Umgebungen konsequenter zu pflegen. Ein simples „docker compose pull“ sollte eigentlich viel öfter Teil der Routine sein, als es in der Praxis häufig der Fall ist. Stabilität ist wichtig, aber sie darf nicht auf Kosten der Sicherheit gehen.

Spannend bleibt auch die Frage, wie große Hersteller und Plattformen auf diese Entwicklung reagieren werden. Ob beispielsweise ältere Betriebssysteme noch einmal zusätzliche Sicherheitsupdates erhalten oder ob der Druck steigt, konsequent auf neuere Versionen zu wechseln, wird sich zeigen. Ebenso interessiert mich, wie Projekte im Legacy-Umfeld, etwa rund um ältere E-Commerce-Plattformen, mit dieser neuen Realität umgehen werden. Wenn die Sicherheitsprobleme im Fundament selbst liegen, stoßen Workarounds irgendwann an ihre Grenzen.

Am Ende steht eine grundlegende Frage im Raum: Wie werden Unternehmen und Entwickler künftig zwischen Bequemlichkeit, Kosten und Sicherheit abwägen? KI macht es einfacher denn je, Schwachstellen zu finden – auf beiden Seiten. Genau deshalb sollte man die aktuelle Entwicklung weniger als plötzliche Bedrohung verstehen, sondern vielmehr als längst überfällige Erinnerung daran, dass Sicherheit kein Zustand ist, sondern ein fortlaufender Prozess.

WordPress: Die Lösung für Probleme, die keine sind

Früher waren Websites erstaunlich schlicht. Ein paar HTML-Dateien, ein bisschen Inhalt, vielleicht ein Downloadbereich und eine Kontaktseite – mehr brauchte es oft nicht. Alles war statisch, direkt greifbar und leicht verständlich. Wenn es irgendwo ein Login-System gab, dann war das meist eine separate Anwendung, auf die einfach verlinkt wurde. Die Website selbst blieb davon unberührt. Das hatte natürlich seine Grenzen, aber es war vor allem eines: einfach.

Wer etwas ändern wollte, öffnete die entsprechenden Dateien und passte den Inhalt direkt an. Es gab keine Templates, keine Widgets, keine abstrahierten Systeme im Hintergrund. Auch Dinge wie suchmaschinenoptimierte URLs spielten kaum eine Rolle. Der Funktionsumfang war überschaubar, aber genau das machte den Umgang damit so effizient. Und wer ein bisschen technisches Verständnis mitbrachte, konnte sich in kurzer Zeit ein eigenes kleines System bauen, das genau diese Anforderungen erfüllte.

Mit der Zeit erkannten viele, dass sich solche Systeme abstrahieren lassen. Es entstanden Content-Management-Systeme, die die Pflege von Inhalten vereinfachen sollten. Doch während die ursprünglichen Websites im Kern oft genauso simpel blieben, entwickelten sich die CMS selbst in eine ganz andere Richtung. Sie wurden größer, komplexer und aufwendiger – nicht selten auch anfälliger.

Ein besonders prägnantes Beispiel dafür ist WordPress. Im Kern bringt es vergleichsweise wenig Funktionalität mit, wird aber durch Plugins zu einem gigantischen Baukasten erweitert. Das Versprechen ist verlockend: Jeder kann alles bauen, ohne wirklich verstehen zu müssen, was im Hintergrund passiert. Doch genau hier beginnt das eigentliche Problem. Aus kleinen Anforderungen werden plötzlich große Systeme, die mit unverhältnismäßigem Aufwand gelöst werden.

Ein einfaches Backup etwa wird zu einer komplexen Plugin-Lösung, obwohl ein kleines Shell-Skript mit zip und mysqldump das gleiche Problem in kürzester Zeit erledigen könnte. Übersetzungen werden über Plugins gelöst, die daran scheitern, dass sich Seiten in verschiedenen Sprachen strukturell leicht unterscheiden. Für Designanpassungen kommen umfangreiche Baukästen zum Einsatz, obwohl ein paar gezielte Änderungen im HTML ausreichen würden – mit dem Nebeneffekt, dass der erzeugte Code ein Vielfaches größer ist als nötig und häufig von unnötigen Abhängigkeiten wie jQuery durchzogen wird.

Natürlich hat dieses System auch seine Vorteile. Es ermöglicht Menschen ohne technischen Hintergrund, komplexe Aufgaben selbst zu erledigen. Ein Umzug der Website wird dann über ein Backup-Plugin abgewickelt – auch wenn das unter Umständen zwanzig Minuten dauert und zusätzliche Hürden mit sich bringt. Wenn etwa der benötigte FTP-Zugang nicht korrekt eingerichtet ist, beginnt schnell ein frustrierendes Hin und Her. Dabei zeigt sich oft, dass der manuelle Weg – Dateien kopieren, Datenbank exportieren und wieder importieren, Konfiguration anpassen – in wenigen Minuten erledigt ist und zuverlässig funktioniert.

Mit der wachsenden Anzahl an Plugins wächst auch die Angriffsfläche. Sicherheit wird zu einem zentralen Thema, und damit auch der Druck, ständig alles aktuell zu halten. Jedes Plugin, jedes Update wird zur potenziellen Fehlerquelle. Es entsteht eine gewisse Angst, etwas zu übersehen oder durch ein Update etwas zu zerstören. Gleichzeitig laufen viele Systeme auf veralteten Grundlagen, etwa älteren PHP-Versionen, weil die Sorge besteht, dass ein Upgrade bestehende Funktionen beeinträchtigen könnte. Dass sich solche Probleme meist beheben lassen oder Änderungen rückgängig gemacht werden können, gerät dabei oft in den Hintergrund.

Am Ende entsteht ein paradoxes Bild: Für kleine, eigentlich triviale Probleme werden große, komplexe Lösungen eingesetzt. Die Betreiber der Websites nehmen das als gegeben hin, ohne zu hinterfragen, ob der zugrunde liegende Bedarf diesen Aufwand überhaupt rechtfertigt. Für statische oder nur leicht dynamische Websites ist ein System wie WordPress häufig überdimensioniert. Es verbraucht Ressourcen und erzeugt Verwaltungsaufwand, obwohl ein leichtgewichtiges CMS oder sogar eine schlanke Eigenlösung mit überschaubarem Code völlig ausreichen würde.

Selbst die Verwendung einer Datenbank ist in vielen Fällen fragwürdig, wenn die Inhalte am Ende ohnehin aus einem Cache ausgeliefert werden. Eine einfache dateibasierte Lösung könnte hier genauso gut funktionieren – mit deutlich weniger Komplexität.

Trotz all dieser Punkte bleibt WordPress für viele die erste Wahl. Es hat sich als Standard etabliert, unabhängig davon, ob es für den jeweiligen Anwendungsfall wirklich geeignet ist. Die Folge sind höhere Kosten, mehr Wartungsaufwand und unnötige Komplexität. Und so bleibt am Ende oft der Eindruck, dass hier Lösungen für Probleme geschaffen werden, die in ihrer ursprünglichen Form nie besonders groß waren.

Andere Abteilungen sind nicht dumm

Ich habe über dieses Thema schon einmal geschrieben, damals vor allem im Kontext von Agenturkunden. Doch ein aktueller Anlass bringt mich dazu, es noch einmal aufzugreifen – diesmal mit Blick auf die Zusammenarbeit innerhalb derselben Firma. Genauer gesagt: auf das Verhältnis zwischen IT oder Entwicklung und allen anderen Abteilungen.

Was mich immer wieder stört, ist diese Haltung, die man leider nicht selten erlebt: Entwickler oder ganze IT-Teams verhalten sich, als wären sie die einzigen wirklich intelligenten Menschen im Unternehmen. Alles, was nicht direkt aus ihrer Welt stammt, wird schnell als unzureichend oder inkompetent abgestempelt. Anforderungen seien nicht detailliert genug, auf Rückfragen kämen keine sofortigen Antworten, sondern erst nach interner Abstimmung. Prozesse seien unklar, Entscheidungen nicht nachvollziehbar, und überhaupt – warum kennt sich die Leitung eigentlich nicht technisch bis ins letzte Detail aus?

Diese Kritikpunkte tauchen immer wieder auf. Doch die Art und Weise, wie sie vorgetragen werden, ist oft das eigentliche Problem. Dahinter steckt nicht selten eine übersteigerte Arroganz, die andere Mitarbeiter direkt oder indirekt abwertet. Es wird sich offen gewundert, wie ein Unternehmen mit solchen Leuten überhaupt funktionieren kann. Und nicht selten wird die Diskussion sogar persönlich.

Wer so denkt und handelt, hat meiner Meinung nach nicht nur ein zwischenmenschliches Problem, sondern auch ein grundlegendes Missverständnis davon, wie Arbeitswelt funktioniert. Ein IT-Leiter muss kein Top-Entwickler sein. Seine Aufgabe ist es, Verantwortung zu übernehmen, wirtschaftlich zu planen und Entscheidungen zu treffen. Dafür gibt es Entwickler im Team – genau wie es in anderen Abteilungen Experten gibt, die ganz andere Fähigkeiten mitbringen.

Denn genau das wird oft vergessen: Die Kompetenzen in anderen Bereichen sind nicht geringer, sie sind einfach anders gelagert. Marketing, Vertrieb, HR oder Controlling folgen eigenen Logiken, sprechen eigene Sprachen und lösen Probleme auf ihre Weise. Und ganz ehrlich: Jeder Entwickler, der behauptet, sämtliche Abläufe in der IT vollständig zu durchdringen, hat wahrscheinlich selbst schon die Hälfte vergessen oder nie im Detail verstanden.

Am Ende sitzen überall Fachkräfte. Menschen, die in ihrem Bereich deutlich mehr wissen als man selbst. Und wenn angeblich alle anderen so unfähig sind – wie kommt es dann, dass das Unternehmen erfolgreich genug ist, um sich teure Entwickler leisten zu können? Diese Frage sollte man sich ruhig öfter stellen.

Hinzu kommt, dass Entscheidungen im Unternehmen selten rein technisch getroffen werden. Es geht um Budgets, Risiken, Zeitpläne und strategische Überlegungen. Die „beste“ technische Lösung ist nicht immer die sinnvollste. Das zu verstehen, braucht Erfahrung – und oft auch den Blick über den eigenen Tellerrand hinaus.

Interessanterweise ändert sich die Perspektive häufig, je weiter man in seiner Karriere kommt. Mit wachsender Verantwortung wächst auch das Verständnis für die Komplexität von Entscheidungen und für die Fähigkeiten anderer. Dinge, die vorher unverständlich oder „dumm“ wirkten, ergeben plötzlich Sinn.

Als Entwickler ist man letztlich auch nur ein Teil des Ganzen. Man arbeitet mit den Informationen, die man bekommt, und bewegt sich innerhalb eines Systems, das von vielen anderen geprägt wird. Wer wirklich besser werden will, sollte anfangen, mit anderen Abteilungen zusammenzuarbeiten, ihre Denkweisen zu verstehen und ihre Sprache zu lernen.

Denn genau darin liegt der Schlüssel: Wenn jemand versucht, „IT zu sprechen“, klingt das für Entwickler oft unbeholfen. Aber das Gleiche gilt umgekehrt. Wer sich die Mühe macht, die Sprache anderer Disziplinen zu lernen, merkt schnell, wie viel Wissen und Intelligenz dort steckt.

Oder, um es mit einem Zitat aus der Serie Modern Family zu sagen: „Do you even know how smart I am in Spanish?“

Gedanken zu Kündigungen in Zeiten von KI

Über die letzten Jahre war ich mehrfach an Kündigungen beteiligt, und auch wenn jeder einzelne Fall unterschiedlich war, haben sich gewisse Muster immer wieder gezeigt. Es ging selten um fehlende Programmierfähigkeiten. Viel häufiger waren es mangelnde Erfahrung für die jeweilige Position, ein nicht passendes Mindset oder – gerade in schnelllebigen Agenturumfeldern – eine fehlende Stressresistenz. Was dabei jedoch nie gefehlt hat, waren Gespräche. Es wurde Feedback gegeben, Erwartungen wurden klar formuliert und Probleme offen angesprochen. Gleichzeitig war aber auch oft spürbar, dass gewisse Dinge nicht kurzfristig veränderbar sind. Mindset, Zuverlässigkeit oder Kommunikationsfähigkeit lassen sich nicht einfach „nachschulen“.

Trotzdem gab es immer eine gewisse Sicherheit im Hintergrund. Die meisten dieser Personen hatten zuvor gearbeitet und konnten grundsätzlich auf einem bestimmten Niveau bestehen. Wenn jemand beispielsweise als Senior eingestellt wurde, sich aber eher als Junior entpuppte, war eine Trennung zwar unangenehm, aber kein Drama. Der Markt war aufnahmefähig, insbesondere für Entwickler. Selbst Junior-Positionen waren oft verfügbar, und die Gewissheit, dass jemand wieder unterkommen würde, hat solche Entscheidungen erleichtert.

Vor Kurzem gab es wieder einen solchen Fall. Die Situation war relativ eindeutig. Es gab eine konsequente Weigerung, grundlegende Tools wie Confluence oder Jira zu nutzen. Commits ins Git-Repository erfolgten nur nach mehrfacher Aufforderung, oft mit der Begründung, dass der Code ja noch nicht fertig sei – obwohl genau darin der Sinn moderner Versionskontrolle liegt. Aufgaben dauerten um ein Vielfaches länger als erwartet, und gleichzeitig bestand eine klare Ablehnung gegenüber dem Einsatz von AI-Agents in der Entwicklung. Dazu kamen fehlende Soft Skills, teils grenzwertiges Verhalten gegenüber anderen Führungskräften und eine insgesamt mangelnde Zuverlässigkeit. Einsicht war nicht vorhanden.

Die Besonderheit in diesem Fall lag darin, dass die Person formal auf Abteilungsleiterebene agierte – weniger aus Qualifikation heraus, sondern weil zu einem bestimmten Zeitpunkt schlicht niemand anderes verfügbar war. Doch ein Titel ersetzt keine Erfahrung. Ein Junior-Entwickler wird nicht plötzlich zum CTO, nur weil es organisatorisch gerade passt.

Was mich jedoch wirklich überrascht hat, war die Reaktion auf die Kündigung. Die Aussage, man würde als Entwickler ohnehin sofort wieder einen Job finden, kam mit einer Selbstverständlichkeit, die ich so nicht mehr für realistisch halte. Noch irritierender war die Ergänzung, man könne ja sonst einfach ins Projektmanagement wechseln. Diese Haltung unterschätzt gleich zwei Dinge fundamental. Zum einen sind gute Projektmanager extrem selten, und ihre Arbeit ist alles andere als ein Ausweichplan. Zum anderen basiert erfolgreiches Projektmanagement genau auf den Fähigkeiten, die hier zuvor gefehlt haben: Kommunikation, Struktur, Verlässlichkeit und der souveräne Umgang mit Tools wie Jira.

Ich habe in meiner Laufbahn nur eine Handvoll wirklich herausragender Projektmanager erlebt, obwohl ich mit vielen gearbeitet habe. Diese Rolle erfordert ein tiefes Verständnis für Menschen, Prozesse und Prioritäten. Sie ist kein Auffangbecken für gescheiterte Entwicklerkarrieren.

Auch die Annahme, dass Entwickler grundsätzlich immer gefragt sind, beginnt zu bröckeln. Wer moderne Entwicklungstools ablehnt und stattdessen darauf beharrt, dass sich alles auch mit Word, Excel und einem geteilten Laufwerk lösen lässt, sendet klare Signale. Spätestens in Bewerbungsgesprächen, an denen erfahrene Entwickler beteiligt sind, fallen solche Haltungen schnell auf. Ebenso entwickelt man ein Gespür dafür, wie realistisch die Erwartungen eines Kandidaten sind. Wenn jemand davon ausgeht, dass jedes Ticket vollständig ausgearbeitet ist, umfassende Dokumentation vorliegt und gleichzeitig eine hundertprozentige Testabdeckung existiert, dann zeigt das weniger Professionalität als vielmehr eine fehlende Nähe zur Realität moderner Softwareentwicklung.

Interessanterweise ist Programmieren selbst nach wie vor selten das eigentliche Problem. Wenn jedoch eine vergleichsweise günstige Tool-Subscription die Produktivität eines Entwicklers um ein Vielfaches steigern könnte und dieser Mehrwert nicht genutzt wird, dann ist das ein deutliches Warnsignal. Genau hier setzt auch der Einfluss von KI an. Die aktuellen Entwicklungen verschieben die Anforderungen immer stärker in die Bereiche, in denen viele Entwickler traditionell Schwächen haben. Kommunikation wird wichtiger, Dokumentation unverzichtbar, und die Geschwindigkeit sowie Qualität in der Umsetzung steigen durch den Einsatz von KI-gestützten Werkzeugen erheblich. Gleichzeitig gewinnen das Verständnis für das jeweilige Unternehmen und seine Produkte sowie die Fähigkeit, sinnvolle Tests zu schreiben, weiter an Bedeutung.

Diese Entwicklung macht manche Profile schlicht untragbar für moderne Teams. Und auch wenn es hart klingt, hoffe ich in diesem konkreten Fall, dass nicht sofort wieder eine vergleichbare Position gefunden wird. Nicht aus Missgunst, sondern weil Entwicklung Zeit braucht. Wer noch nicht so weit ist, sollte die Chance bekommen, in einem passenden Umfeld zu wachsen. Unternehmen, die bewusst Junior-Entwickler einstellen und fördern, spielen dabei eine entscheidende Rolle. Nur so entsteht langfristig die Erfahrung, die später notwendig ist, um höhere Positionen nicht nur zu erreichen, sondern auch erfolgreich auszufüllen.

Tokenmaxxing: Kosten über Resultate

In den letzten Tagen bin ich auf einen interessanten Begriff gestoßen: Tokenmaxxing. Gelesen habe ich darüber in einem Artikel auf Golem, und die Grundidee hat mich sofort nachdenklich gemacht. Vereinfacht gesagt geht es dabei darum, möglichst viele Tokens bei der eigenen Arbeit mit KI-Tools zu generieren. Hohe Tokenzahlen bedeuten schließlich hohe Kosten – und in manchen Kreisen scheint genau das zunehmend mit Produktivität oder intensiver Nutzung von KI im Job gleichgesetzt zu werden.

Solche extremen Werte entstehen vor allem dann, wenn große Loops laufen gelassen werden oder riesige Kontexte wie komplette Codebasen in Prompts geschoben werden. Auch der parallele Einsatz vieler Agenten treibt den Tokenverbrauch schnell nach oben. Dabei dürfte es zwangsläufig zu Redundanzen kommen, weil mehrere Prozesse ähnliche Aufgaben bearbeiten oder sich gegenseitig überholen. Rein technisch ist das nachvollziehbar. Fragwürdig wird es jedoch, wenn daraus Leistungskennzahlen abgeleitet werden.

Denn ob jemand monatlich 150.000 Dollar an Tokenkosten verursacht, sagt zunächst einmal sehr wenig über seine tatsächliche Produktivität oder sein Können aus. Diese Denkweise erinnert stark an ein altes Paradigma aus der Softwareentwicklung: die Bewertung von Entwicklerleistung anhand geschriebener Codezeilen. Schon vor Jahrzehnten wurde erkannt, dass viele Zeilen Code keineswegs automatisch für Qualität stehen – häufig sogar für das Gegenteil. Guter Code ist optimiert, übersichtlich und wartbar. Und oft ist er gerade deshalb so gut, weil er so kurz wie möglich ist.

Im Grunde geht es um eine Haltung zur Problemlösung. Wer sich Zeit nimmt, nachzudenken und eine durchdachte Lösung zu entwickeln, erreicht sein Ziel meist mit weniger Aufwand – und eben auch mit weniger Tokens. Wer hingegen versucht, jedes Problem mit möglichst viel generiertem Output zu erschlagen, verliert schnell den Überblick. Hohe Tokenzahlen zeigen dann vor allem eines: dass KI intensiv genutzt wird. Sie zeigen jedoch nicht, ob sie sinnvoll eingesetzt wird. Im Gegenteil, bei sehr großen Mengen könnte man sogar vermuten, dass die Kontrolle über den Entwicklungsprozess teilweise verloren gegangen ist.

Hinzu kommt eine Nachhaltigkeitsperspektive, die man nicht ignorieren sollte. Unnötig Geld und Energie zu verbrennen, kann kaum ein sinnvolles Ziel sein – weder für Einzelpersonen noch für Unternehmen, die langfristig denken wollen. Gleichzeitig ist schwer einzuschätzen, wie verbreitet dieses Tokenmaxxing tatsächlich ist. Vielleicht handelt es sich nur um einzelne Extremfälle oder sogar um eine Form von Trolling. Ohne die konkreten Anwendungsfälle zu kennen, lässt sich auch nicht beurteilen, ob der hohe Verbrauch in bestimmten Szenarien gerechtfertigt oder sogar wirtschaftlich sinnvoll ist.

Für den normalen Entwickler sollte das Ziel jedenfalls ein anderes sein. Es geht darum, mit möglichst geringem Aufwand maximale Ergebnisse zu erzielen. Effizienz bedeutet nicht, möglichst viele Ressourcen zu verbrauchen, sondern sie klug einzusetzen. Firmen, die glauben, allein aus Tokenzahlen etwas Positives über Leistung oder Fortschritt ablesen zu können, wirken dabei fast ein wenig wie Relikte aus einer anderen Zeit. Modernität zeigt sich nicht darin, neue Kennzahlen einzuführen, sondern darin, die richtigen Fragen zu stellen.

OpenCode mit Ollama.. einfach!

Ich geh einfach mal davon aus, dass Ollama in der einen oder anderen Variante schon läuft. Dabei ist es egal ob es nativ auf einem Rechner läuft oder in einem Docker-Container.
Als Model nutzen wir Qwen3:8b. Wir starten das Model in Ollama via

ollama run qwen3:8b

darin ändern wir num_ctx und speichern es unter neuen Namen ab. Das ist EXTREM wichtig, weil sonst die Agentic Tools (z.B. schreiben von Dateien) nicht funktionieren werden.. ich habe es probiert.

/set parameter num_ctx 16384
/save qwen3:8b-16k
/bye

Nun installieren wir OpenCode (Linux):

curl -fsSL https://opencode.ai/install | bash

Und legen die Config (~/.config/opencode/config.json) an:

{
"$schema": "https://opencode.ai/config.json",
"provider": {
"ollama": {
"npm": "@ai-sdk/openai-compatible",
"options": {
"baseURL": "http://your_ollama_server:11434/v1"
},
"models": {
"qwen3:8b-16k": {
"tools": true
}
}
}
}
}

Nun kann man OpenCode mit opencode starten und das Model per /models auswählen und loslegen.

gemma:latest funktioniert auch, wenn man die num_ctx Anpassung vornimmt.

KI kann unsere Standards nicht einhalten

Manchmal macht es tatsächlich Spaß, mit anderen Menschen über KI in der Softwareentwicklung zu diskutieren. Besonders dann, wenn man auf Positionen trifft, die unterschiedlicher kaum sein könnten. Auf der einen Seite stehen diejenigen, die mit KI experimentieren, ihre Möglichkeiten austesten und versuchen, sie sinnvoll in den Entwicklungsalltag zu integrieren. Auf der anderen Seite gibt es immer noch viele, die jede Nutzung von KI kategorisch ablehnen. Für sie ist das Thema im Grunde bereits entschieden: KI taugt nichts, produziert keinen brauchbaren Code und spart am Ende ohnehin keine Zeit.

Interessanterweise gehen viele dieser Meinungen mit einer gewissen Verweigerungshaltung einher. Häufig hört man, dass es sich gar nicht lohne, KI überhaupt auszuprobieren. Allein das Testen sei bereits Zeitverschwendung, schließlich gebe es genügend Argumente, die angeblich belegen würden, dass KI ohnehin nichts taugt. Besonders oft fällt in diesem Zusammenhang das Argument, dass der durch KI erzeugte Code ja überprüft werden müsse. Dieser zusätzliche Review-Aufwand würde den möglichen Zeitgewinn direkt wieder zunichtemachen.

Dabei wird implizit eine bemerkenswerte Annahme getroffen: dass menschliche Entwickler offenbar keinen Code produzieren, der überprüft werden muss. Als wären Code Reviews nur deshalb erfunden worden, weil es jetzt KI gibt. In dieser Logik wäre der Code von Menschen grundsätzlich korrekt, während nur KI fehlerhaften Code erzeugt. Die Realität in der Softwareentwicklung sieht allerdings deutlich anders aus. Code Reviews existieren nicht, weil irgendjemand in der Vergangenheit KI vorhergesehen hat, sondern weil jede Quelle von Code potenziell fehleranfällig ist. Ganz egal, ob dieser Code von einer Maschine oder einem Menschen stammt.

Meine eigenen Erfahrungen zeigen ziemlich klar, dass Menschen sehr viele Fehler machen. Das ist völlig normal und gehört zum Entwicklungsprozess dazu. Jeder Entwickler hat schon schlechten Code geschrieben, oft ohne es in dem Moment zu merken. Im Vergleich dazu schneidet eine KI erstaunlich häufig ziemlich gut ab. Der entscheidende Unterschied liegt dabei weniger in der Fehlerfreiheit als in der Geschwindigkeit. Wenn ein Mensch einen Fehler macht, kann es Stunden dauern, bis er entdeckt und korrigiert wird. Mit KI laufen diese Iterationen oft innerhalb weniger Minuten ab. Fehler entstehen auf beiden Seiten, aber die Geschwindigkeit, mit der man sie finden und beheben kann, verändert sich drastisch.

Ein weiteres häufiges Argument lautet, dass der Review von KI-Code besonders aufwendig sei, weil bestehende Konzepte und Teamstandards nicht eingehalten würden. Die KI kenne diese Regeln schließlich nicht. Interessanterweise wird dabei selten erwähnt, dass neue Entwickler diese Standards ebenfalls nicht automatisch kennen. Niemand beginnt einen neuen Job und weiß intuitiv, welche internen Regeln in einem Team gelten. Auch Menschen müssen diese erst lernen, meistens anhand von Dokumentationen oder durch Gespräche mit Kollegen.

Genau dieselben Informationen könnte man einer KI ebenfalls geben. Tatsächlich liest eine KI ein solches Dokument sogar deutlich schneller als ein Mensch. Sollte es allerdings gar keine dokumentierten Standards geben, liegt das Problem vermutlich an einer ganz anderen Stelle. In vielen Teams existieren diese Regeln nämlich nur in den Köpfen einzelner Entwickler. Sobald jemand Neues hinzukommt, beginnt das mühsame Entschlüsseln dieser impliziten Erwartungen. Dass eine KI daran scheitert, zeigt dann weniger eine Schwäche der KI als eine Schwäche der vorhandenen Prozesse.

Oft wird auch argumentiert, dass eine KI gar nicht wissen könne, welche zusätzlichen Informationen in Meetings oder Calls besprochen wurden. Aber dieses Problem betrifft jeden, der an einem Meeting nicht teilgenommen hat. Wenn Informationen nicht festgehalten werden, kann niemand darauf zugreifen. Wer daraus ableitet, dass nur KI dadurch ein schlechter Entwickler wäre, müsste konsequenterweise auch jedem Kollegen, der einmal einen Termin verpasst hat, dieselbe Unfähigkeit unterstellen. In der Praxis wäre es ohnehin sinnvoller, solche Meetings zu dokumentieren oder direkt automatisch zusammenfassen zu lassen.

Ein besonders unterhaltsamer Teil dieser Diskussionen dreht sich um Coding-Standards und Code Style. Ich habe im Laufe meiner Karriere an genügend Code-Style-Meetings teilgenommen, um eine gewisse Skepsis gegenüber deren tatsächlichem Nutzen entwickelt zu haben. Häufig werden solche Meetings von jemandem initiiert, dessen persönliches ästhetisches Empfinden durch den Code anderer Entwickler beleidigt wurde. Diese Person erklärt dann zunächst ausführlich, wie wichtig ein einheitlicher Coding Style für jedes Team sei.

Darauf folgt meist eine Liste dramatischer Szenarien darüber, was alles passieren könnte, wenn man sich nicht darum kümmert. Der Code wäre angeblich schon nach wenigen Monaten völlig unlesbar. Danach werden Beispiele präsentiert, wie man Dinge „richtig“ macht. Ich habe tatsächlich einmal erlebt, dass ernsthaft gefordert wurde, die Einrückung im Code von vier auf drei Spaces zu ändern, weil dies angeblich deutlich besser lesbar sei. Nicht zwei, nicht vier – exakt drei.

Unternehmen lieben solche Initiativen, weil sie den Eindruck vermitteln, dass damit automatisch die Codequalität steigt und Fehler drastisch reduziert werden. Am Ende schreibt jemand ein Dokument mit den neuen Regeln. Dieses Dokument wird anschließend kaum noch gelesen, während es von seinem ursprünglichen Autor gelegentlich weiter gepflegt wird. In Code Reviews fallen Verstöße selten auf, weil auch der Reviewer das Dokument nie wirklich studiert hat. Manchmal gibt es dann irgendwann einen automatischen Reformat, und der Code landet wieder beim Standardstil der verwendeten IDE.

Ich habe in solchen Situationen oft gefragt, warum man bei PHP nicht einfach sagt, dass man sich an PSR-12 halten soll. Eine kurze Nachricht im Chat würde ausreichen, und jeder wüsste sofort, woran er ist. Die Reaktionen zeigen dann meist recht schnell, dass es selten wirklich um Verbesserungen ging. Häufig stehen persönliche Vorlieben oder ein gewisses Bedürfnis nach Einfluss im Mittelpunkt.

Genau hier liegt übrigens eine der Stärken von KI. Man gibt ihr einen etablierten öffentlichen Coding-Standard und lässt zusätzlich eine Pipeline laufen, die diesen Stil automatisch überprüft und erzwingt. Die KI kann sich problemlos daran halten oder bestehenden Code entsprechend anpassen. Sobald die Regeln klar formuliert sind, funktioniert das erstaunlich zuverlässig.

Grundsätzlich gilt: Wenn Prozesse sauber dokumentiert sind, kann eine KI hervorragend damit arbeiten. Wenn stattdessen viele Dinge nur im Kopf einzelner Entwickler existieren, dann deckt eine KI lediglich bereits vorhandene strukturelle Probleme auf. In gewisser Weise verhält sich die Einführung von KI sehr ähnlich wie das Onboarding eines neuen Junior Developers. Wenn ein Team daran scheitert, einer KI die notwendigen Informationen bereitzustellen, hätte es vermutlich auch große Schwierigkeiten gehabt, einen neuen Entwickler sinnvoll einzuarbeiten.

Natürlich kostet die Nutzung von KI Zeit. Man muss Prompts formulieren, Ergebnisse prüfen und manchmal nachjustieren. Aber genau diese Aufwände entstehen auch bei menschlicher Zusammenarbeit. Oft sogar in größerem Umfang. Gleichzeitig bringt KI einen enormen Geschwindigkeitsvorteil mit sich. Code entsteht in Sekunden oder Minuten statt in Stunden. Dieser Code ist nicht immer perfekt, aber perfekt war Code früher auch nicht.

Am Ende wirken viele der vorgebrachten Argumente weniger wie fundierte Kritik und mehr wie Ausreden. Dahinter steckt oft die Hoffnung, dass sich das Thema irgendwie von selbst erledigt, wenn man lange genug abwartet. Stattdessen wäre es wahrscheinlich sinnvoller, sich aktiv damit auseinanderzusetzen und die Entwicklung mitzugestalten. Denn wenn es berechtigte Bedenken gibt, dann lassen sie sich nur lösen, wenn man beginnt, mit der Technologie zu arbeiten – nicht, wenn man sie ignoriert.

Das kann ICH alles besser! – Wenn Selbstüberschätzung zum Unternehmensrisiko wird

Es gibt Kollegen, die misstrauen grundsätzlich allem, was sie nicht selbst gemacht haben. Dabei spielt es keine Rolle, ob eine Lösung von anderen Teammitgliedern stammt oder extern eingekauft wurde. Was nicht aus der eigenen Feder kommt, wird kritisch beäugt, vorschnell abgewertet oder direkt als mangelhaft abgestempelt. Besonders häufig zeigt sich dieses Verhalten im technischen Umfeld, wenn es um Software oder Hardware geht. Programme werden als fehlerhaft und unoptimiert bezeichnet, ohne dass sie jemals ernsthaft getestet oder analysiert wurden. Geräte gelten als unzuverlässig oder schlecht verarbeitet, weil einmal etwas nicht reibungslos lief. Aus einer einzelnen Beobachtung wird ein grundsätzliches Problem konstruiert.

Statt sich strukturiert mit möglichen Ursachen auseinanderzusetzen oder nüchtern nach Alternativen zu suchen, beginnt dann das große Herumbasteln. Es wird geschraubt, getauscht, umkonfiguriert und optimiert, um vermeintliche Unzulänglichkeiten zu beheben, die in dieser Form oft gar nicht existieren. Ein besonders anschauliches Beispiel war ein Mini-PC, der beim Kopieren sehr großer Dateien nicht den erhofften Datendurchsatz erreichte. Dabei wurde mehrfach erklärt, dass solche Szenarien im normalen Office-Alltag praktisch nicht vorkommen und sich bislang kein einziger Nutzer über die Performance beschwert hatte. Dennoch wurde aus diesem Einzelfall kurzerhand geschlossen, dass die gesamte Baureihe fehlerhaft sei und alle Geräte bald ausfallen würden.

Was folgte, war eine regelrechte Optimierungsodyssee. Die Wärmeleitpaste wurde ersetzt, weil es vermeintlich bessere Varianten gäbe. Mehrere zusätzliche SSDs wurden angeschafft und getestet, obwohl die eingebaute OEM-SSD für typische Büroaufgaben vollkommen ausreichend dimensioniert war. Die WLAN-Karte wurde ausgebaut, da sie als potenzielle Stabilitätsursache vermutet wurde. Das Kühlkonzept wurde als grundsätzlich schlecht durchdacht bezeichnet, Teile davon wurden mit Werkzeug entfernt und später provisorisch wieder eingebaut. Selbst nach weiteren Anpassungen und erneutem Austausch der Wärmeleitpaste blieb das Ziel, bessere Benchmarkergebnisse zu erzielen, insbesondere in synthetischen Tests wie Cinebench, die für einen Office-PC keinerlei Relevanz im Alltag haben. Am Ende zeigte das Gerät tatsächlich Probleme, doch nach so vielen Eingriffen war kaum noch nachvollziehbar, wodurch sie verursacht wurden. Ein Austausch gegen eine bewährte Alternative wie eine HP Z2 G1a wurde kategorisch abgelehnt, da der ursprüngliche Einzelfall inzwischen als Beweis für die generelle Untauglichkeit von Mini-PCs interpretiert wurde.

Ein ähnliches Muster zeigte sich bei einer Legacy-Software. Die Datenbank sei falsch aufgebaut, die Anbindung schlecht umgesetzt, alles voller Fehler. Den Entwicklern wurde unterstellt, sie hätten keine Ahnung und seien nicht in der Lage, bestehende Probleme zu beheben. Die gesamte Konfiguration wurde als unprofessionell dargestellt. Also wurde eine eigene Konfiguration entwickelt, vieles neu aufgesetzt und umgebaut. Doch nach umfangreichen Tests zeigte sich, dass die vorgenommenen Änderungen keinerlei messbare Verbesserung brachten. Die ursprüngliche Lösung funktionierte genauso gut oder schlecht wie zuvor.

Grundsätzlich ist es positiv, wenn Probleme angegangen und Lösungen gesucht werden. Doch nicht jedes kleine Symptom rechtfertigt es, ein gesamtes Produkt oder eine komplette Lösung als grundsätzlich fehlerhaft zu brandmarken. Wenn außer einer einzelnen Person niemand Probleme wahrnimmt, spricht vieles dafür, dass es sich nicht um ein systemisches, sondern um ein situatives Thema handelt. Ein sehr hochbezahlter Entwickler sollte seine Zeit nicht damit verbringen, verschiedene Wärmeleitpasten durchzutesten, um für einen Office-Rechner marginal bessere Benchmarks zu erzielen. Investierte Arbeitszeit muss in einem sinnvollen Verhältnis zum Nutzen stehen. Ressourcen sollten dort eingesetzt werden, wo sie echten Mehrwert schaffen, und nicht zur Absicherung theoretischer Grenzfälle, die im realen Betrieb nie auftreten.

Die Folgen eines solchen Verhaltens sind gravierend. Schuld wird reflexartig bei anderen gesucht, externe Partner werden unnötig unter Druck gesetzt, um Notfälle zu verhindern, die mit hoher Wahrscheinlichkeit nie eintreten werden. Es wird Geld verbrannt, ohne dass ein messbarer Impact entsteht. Gleichzeitig wird die Arbeit anderer abgewertet, obwohl sie nach bestem Wissen und Gewissen und auf Basis sauberer Tests durchgeführt wurde. Wenn ständig behauptet wird, alles ließe sich besser machen, ohne dass sich diese Behauptung jemals belegen lässt, verliert Kritik an Glaubwürdigkeit. Am Ende weiß niemand mehr, ob Einwände berechtigt sind oder lediglich Ausdruck persönlicher Selbstüberschätzung.

Besonders problematisch wird dieses Verhalten in Führungspositionen. Wer grundsätzlich niemandem im Team vertraut, wird jede Arbeit hinterfragen und kleinreden. Statt Verantwortung zu delegieren, wird alles an sich gezogen, häufig mit dem Ergebnis, dass schlechtere Lösungen entstehen, als es mit etablierten Produkten oder externem Know-how der Fall gewesen wäre. Hinzu kommen unnötige Ausgaben, weil bewährte Lösungen aus Prinzip abgelehnt werden, obwohl sie anderswo seit Jahren stabil funktionieren. Führung bedeutet jedoch, Vertrauen zu schenken, Kompetenzen zu bündeln und die Stärken anderer anzuerkennen, nicht alles selbst besser wissen zu wollen.

Am Ende bleibt eine einfache Erkenntnis: Man kann nicht alles besser. Kollegen und externe Partner arbeiten in der Regel nach bestem Wissen und Gewissen. Ohne konkreten Anlass ihre Arbeit grundsätzlich infrage zu stellen, ist nicht nur unfair, sondern auch ineffizient. Wer behauptet, alles besser zu können, muss dies auch nachweislich belegen. Wenn jedoch trotz großer Worte keine besseren Ergebnisse entstehen, sollte man eher an der eigenen Selbstwahrnehmung arbeiten als an der Hardware. Und wer dauerhaft Misstrauen sät, unnötige Kosten verursacht und etablierte Lösungen aus Prinzip ablehnt, sollte keine Führungsverantwortung tragen, denn eine solche Haltung führt selten zu besseren Ergebnissen – aber fast immer zu einem zerrütteten Team.

Sind lokale große Server tot?

Ich sitze gerade in einer Umgebung, die sinnbildlich für ein ganz bestimmtes IT-Zeitalter steht. In einem kleinen Labor werkeln drei ziemlich große ESXi-Hosts von VMware, flankiert von mindestens ebenso vielen NAS-Systemen von QNAP. In diesen Racks steckt unglaublich viel Geld. Viel Blech, viel RAM, viele SAS-SSDs, redundante Netzteile, dedizierte RAID-Controller – alles, was man sich vor ein paar Jahren unter „Enterprise“ vorgestellt hat.

Und ja, damals war das beeindruckend. Viele Windows-VMs, sauber getrennt, alles hochverfügbar, alles virtualisiert. Das war State of the Art.

Nur kam dann die Ryzen- und Epyc-Zeit.

Hier steht inzwischen als Testsystem ein unscheinbarer Mini-PC, eine Leihgabe eines Software-Anbieters. Ein kleiner Kasten mit Ryzen-CPU, 96 GB DDR5-RAM und schnellen NVMe-SSDs. Nichts davon klingt nach Rechenzentrum. Aber egal, wie viele CPUs, wie viel RAM oder wie viele SAS-SSDs ich einer VM auf den großen Hosts zuweise – an die gefühlte und messbare Performance dieses kleinen Ryzen-Systems kommt keine davon heran. Nicht, weil die VM schlecht konfiguriert wäre, sondern weil der Unterbau limitiert. Alte CPUs von 2017 oder 2019, Storage-Anbindungen, die nie wirklich auf NVMe-Niveau waren, gewachsene Strukturen, die auf maximale Konsolidierung statt auf maximale Performance ausgelegt sind.

Cloud war übrigens auch mal ein Thema. Noch bevor ich dazu gestoßen bin, wurden die Pläne wieder beerdigt. Zu teuer, zu komplex, zu viele offene Fragen. Also blieb alles on-prem – aber eben in einem Denkmuster, das stark in den 2010ern verwurzelt ist.

Dicke ESXi-Server mit einem Zoo aus Windows-VMs waren lange total in. Jede Anwendung bekam ihren eigenen Windows Server. Eine MongoDB hier, eine Firebird-Datenbank dort, noch ein Applikationsserver daneben. Alles sauber getrennt, alles ordentlich lizenziert, alles virtuell – aber auch alles schwerfällig. Heute frage ich mich ernsthaft, warum eine MongoDB oder eine Firebird-Datenbank zwingend auf einem eigenen Windows-Server laufen muss, wenn sie sich technisch problemlos in getrennten Docker-Containern auf einem schlanken Linux-Host betreiben ließe. Containerisierung ist kein Hype mehr, sondern Alltag. Docker-Setups sind reproduzierbar, leichtgewichtig und in vielen Fällen performanter als klassische VM-Monolithen.

Stattdessen werden weiter große Server gekauft. Schwer, teuer, beeindruckend auf dem Datenblatt – aber mit erstaunlich langsamen CPUs. Die „neueste“ CPU-Generation hier stammt von 2019, der Rest von 2017. In rechenintensiven OCR-Anwendungen würde vermutlich schon ein mittelmäßiger AMD EPYC 4005 die teuren Xeons deutlich abhängen. Und wenn man dann noch an eine kleine GPU wie die NVIDIA A2 mit 16 GB VRAM denkt, wird klar, wie viel Potenzial hier brachliegt – nicht aus Mangel an Budget, sondern aus Mangel an Paradigmenwechsel.

Refurbished-Hardware spart auf dem Papier Geld, und ich bin grundsätzlich ein Freund davon. Aber man landet schnell an einem Punkt, an dem günstige, moderne Systeme die objektiv bessere Wahl gewesen wären. Gerade bei den heutigen Speicherpreisen relativiert sich vieles. Server-Hardware ist teuer, keine Frage. Doch wenn man Systeme mit fest verbautem, aber schnellem Speicher betrachtet, wird es plötzlich interessant. Und ein Server ohne NVMe-SSDs fühlt sich inzwischen schlicht nicht mehr zeitgemäß an.

Für mich sind die Zeiten der riesigen, alles-konsolidierenden Server weitgehend vorbei. Ich würde lieber mehrere kompakte Workstation-Systeme wie den HP Z2 G1a ins Rack stellen, jeweils mit 128 GB schnellem RAM und NVMe-Storage, dazu sauber angebundener Blockspeicher von den NAS-Systemen. Anwendungen granular verteilen, Dienste klar trennen, auf schlanke Lösungen wie Docker setzen, wo immer es geht. Ein Fileserver muss nicht zwangsläufig eine Windows-VM sein, wenn das NAS selbst diese Aufgabe solide übernehmen kann. Warum also noch Maschinen mit 3 TB RAM und vier CPUs betreiben, die im Kern nur Windows-VMs vorhalten und bei denen ausgerechnet an der schnellen Massenspeicheranbindung gespart wurde?

Vielleicht sind große lokale Server nicht tot. Aber ihr bisheriger Einsatzzweck gehört zunehmend hinterfragt. Die Frage ist nicht mehr, wie viel wir auf einen Host packen können, sondern wie wir mit möglichst wenig Overhead möglichst viel reale Leistung bekommen. Weniger Ballast, mehr Fokus. Weniger Nostalgie für alte Architekturprinzipien, mehr Mut zu schlanken, modernen Setups.

Manchmal ist der kleine, unscheinbare Mini-PC im Rack die deutlich ehrlichere Antwort als das nächste tonnenschwere „Enterprise“-Monster.

PDFs sind keine Digitalisierung

Wir leben in einer Zeit, in der „alles digital“ sein soll. Papier gilt als Relikt vergangener Tage, und in vielen Unternehmen ist das erklärte Ziel, möglichst keine physischen Dokumente mehr zu produzieren. Gleichzeitig zeigt der Alltag, dass Papier noch erstaunlich oft zum Einsatz kommt. Doch selbst dort, wo Ordner verschwinden und Scanner surren, bedeutet das noch lange nicht, dass echte Digitalisierung stattfindet.

Denn wer seine Zettelwirtschaft einfach einscannt und als PDF ablegt, hat im Kern nur das Medium gewechselt. Der Prozess dahinter bleibt derselbe. Eine digitale Mitarbeiterakte ist eben nicht einfach ein Netzlaufwerk mit hunderten von eingescannten Dokumenten. Ein Produktkatalog, der als PDF verschickt oder auf die Website gestellt wird, ist kein digitaler Vertriebskanal, sondern lediglich ein gedrucktes Dokument in neuem Gewand. Das Ergebnis wirkt moderner, doch die Strukturen bleiben analog gedacht.

Wer durch kleine und mittelständische Unternehmen in Deutschland geht, gewinnt oft den Eindruck, dass die gesamte Organisation auf vier Grundpfeilern ruht: Windows, Word, Excel und Outlook. Diese Werkzeuge sind allgegenwärtig und zweifellos nützlich. Doch sie ersetzen keine durchdachten Systeme. Spezialisierte Lösungen wie PIM-, CRM- oder Warenwirtschaftssysteme sind deutlich seltener im Einsatz, als man es in einer angeblich digitalisierten Wirtschaft erwarten würde. Je größer und internationaler ein Unternehmen ist, desto eher findet man solche spezialisierten Softwarelösungen. Gerade kleinere Firmen hingegen begnügen sich häufig damit, Papier in Dateien zu verwandeln, ohne ihre Prozesse grundlegend zu hinterfragen oder anzupassen.

Besonders irritierend ist in diesem Zusammenhang, wie hartnäckig sich alte Denkweisen halten. Dass der Begriff „Fax“ im Jahr 2026 immer noch selbstverständlich fällt, wirkt fast surreal. Warum sollte man eine PDF-Datei faxen, wenn sie sich per E-Mail in Sekunden verschicken lässt? Solche Fragen zeigen, dass es oft nicht an der Technik fehlt, sondern am Verständnis für digitale Möglichkeiten und an der Bereitschaft, Gewohnheiten zu verändern.

Ein zentrales Problem ist dabei das mangelnde Bewusstsein für den Wert strukturierter Daten. Ein gescanntes Dokument ist im Grunde nur ein Bild. Es lässt sich nicht sinnvoll auswerten, automatisiert verarbeiten oder zuverlässig analysieren. Echte Digitalisierung bedeutet, Informationen so zu erfassen, dass sie durchsuchbar, verknüpfbar und auswertbar sind. Reports, Analysen und Auswertungen sollten nicht davon abhängen, dass ein Mitarbeiter stundenlang Daten manuell zusammensucht und in Excel-Tabellen kopiert. Moderne Systeme erledigen solche Aufgaben automatisiert und schaffen damit Freiräume für wertschöpfende Tätigkeiten.

Wer als Entwickler in ein solches Umfeld kommt, stellt schnell fest, dass die Rolle weit über das reine Programmieren hinausgeht. Man wird zum Berater, manchmal sogar zum Übersetzer zwischen alter und neuer Welt. Es geht nicht nur darum, Software einzuführen, sondern Mindsets zu verändern und Versäumnisse der letzten fünfzehn Jahre aufzuholen. Das ist oft ein kultureller Prozess, kein technischer.

Und nein, ein Unternehmen ist nicht automatisch modern, nur weil seine Excel-Datei in der Cloud liegt oder über OneDrive synchronisiert wird. Die Speicherung ändert nichts an der grundlegenden Logik, nach der gearbeitet wird. Digitalisierung bedeutet nicht, analoge Prozesse zu konservieren und ihnen einen digitalen Anstrich zu geben. Sie bedeutet, Prozesse neu zu denken, Daten strukturiert nutzbar zu machen und Technologie als strategisches Werkzeug zu verstehen. PDFs sind dabei höchstens ein Zwischenschritt – aber ganz sicher nicht das Ziel.

KI ohne messbaren Impact – oder nur falsch eingeführt?

In den letzten Monaten war immer wieder zu lesen, dass Unternehmen trotz verfügbarer KI-Werkzeuge keine echte Steigerung ihrer Produktivität messen konnten. Führungskräfte berichten davon, dass man viel ausprobiert habe, Lizenzen eingekauft wurden und dennoch am Ende keine klaren Zahlen vorlägen, die einen Durchbruch belegen. Auffällig ist jedoch, dass selten darüber gesprochen wird, wie genau KI eingeführt wurde, welche Bereiche betroffen waren und welche Erwartungen man eigentlich an den Einsatz geknüpft hat.

KI ist kein Werkzeug wie Outlook, das man einfach jedem Mitarbeitenden zur Verfügung stellt, in der Hoffnung, es werde sich schon von selbst sinnvoll integrieren. Wer Unternehmen beobachtet, die gleichzeitig KI- und Cloud-Initiativen starten, erkennt schnell ein wiederkehrendes Muster. Technologie wird bereitgestellt, doch Prozesse, Verantwortlichkeiten und Denkweisen bleiben unverändert. Die Enttäuschung folgt dann meist planbar.

Nicht jeder Arbeitsbereich profitiert in gleichem Maße von KI. Wer täglich viele E-Mails schreibt, braucht oft keine komplexen Prompts, wenn das Formulieren des Prompts am Ende genauso lange dauert wie die Nachricht selbst. Zudem wiederholen sich Formulierungen häufig, sodass der Mehrwert begrenzt ist. Ganz anders sieht es in der Softwareentwicklung aus. Dort entstehen Prototypen nicht mehr erst nach zwei Tagen intensiver Arbeit, sondern entwickeln sich bereits während der Konzeptionsphase. Neue Features lassen sich schneller implementieren, wodurch deutlich mehr Zeit für Tests, Qualitätssicherung und echte Verbesserung bleibt. Der Effekt ist hier nicht nur eine Beschleunigung, sondern auch eine qualitative Verschiebung der Arbeit.

Entscheidend ist jedoch nicht allein das Werkzeug, sondern das Verständnis für seinen Einsatz. KI sinnvoll zu nutzen bedeutet nicht, fünf Standard-Prompts zu kennen und diese minimal anzupassen. Jede Aufgabe ist anders, jede Fragestellung hat ihren eigenen Kontext. Wer glaubt, zwei Entwickler könnten sich intensiv einarbeiten und anschließend zwanzig weiteren Kolleginnen und Kollegen in einer kurzen Schulung ein paar Prompts an die Hand geben, damit das gesamte Team „KI-enabled“ ist, unterschätzt die Tiefe des Themas. KI ist weniger eine Frage der Bedienung als eine Frage des Mindsets.

Gerade im klassischen Büroalltag zeigt sich diese Problematik besonders deutlich. KI verhält sich hier ähnlich wie Cloud-Technologie. Man kann nicht einfach OneDrive bereitstellen, einen Link mit der Überschrift „So funktioniert OneDrive“ verschicken und erwarten, dass plötzlich alle Prozesse cloudbasiert, effizient und strukturiert ablaufen. Technologie entfaltet ihren Nutzen nur dann, wenn Menschen verstehen, wie sie bestehende Arbeitsweisen anpassen müssen, um von den Vorteilen zu profitieren. Es geht darum, Arbeitsprozesse neu zu denken, statt alte Muster digital zu kopieren.

Warum bleibt der messbare Impact also häufig aus? Oft werden lediglich Werkzeuge bereitgestellt, ohne begleitende Strukturveränderung. Man verlässt sich darauf, dass Mitarbeitende schon selbst herausfinden werden, wie man KI sinnvoll einsetzt, ohne ihnen dafür Zeit oder Raum zum Experimentieren zu geben. Führungskräfte, die selbst wenig Berührungspunkte mit der Technologie haben, können zudem schwer beurteilen, ob sie richtig oder oberflächlich genutzt wird. Hinzu kommt, dass Produktivität in vielen Bereichen schon vor der Einführung von KI schwer messbar war. Backoffice-Abteilungen oder interne Softwareentwicklung generieren keinen unmittelbar sichtbaren Umsatz. Wer hier erwartet, einen Monat nach Einführung direkt messbare Gewinnsteigerungen zu sehen, setzt falsche Maßstäbe.

Eine ernsthafte Einführung von KI bedeutet deshalb, jeden Arbeitsplatz und jeden Prozess einzeln zu betrachten. Es geht darum zu analysieren, wo echte Hebel liegen, wie Verbesserungen bewertet werden können und welche Kennzahlen überhaupt sinnvoll sind. In vielen Bereichen führt KI bereits heute zu enormen Produktivitätssteigerungen oder zumindest zu einer Verschiebung von Tätigkeiten, sodass die Qualität der Ergebnisse deutlich steigt. Nicht jede Verbesserung zeigt sich sofort in Umsatzkennzahlen, manche äußert sich in geringerer Fehlerquote, höherer Innovationsgeschwindigkeit oder zufriedeneren Mitarbeitenden.

Wer behauptet, KI bringe keinen messbaren Impact, sollte sich daher zunächst selbstkritische Fragen stellen. Liegt es vielleicht am Aufgabenbereich, in dem der Nutzen naturgemäß geringer ist? Wurden Mitarbeitende wirklich geschult, eingebunden und befähigt, oder hat man ihnen lediglich ein neues Tool vor die Nase gesetzt? Und misst man womöglich falsch, weil man davon ausgeht, dass sich Verbesserung ausschließlich in kurzfristigen finanziellen Kennzahlen zeigen muss?

Einfach zu sagen, KI bringe nichts und man müsse sich deshalb nicht weiter damit beschäftigen, ist eine bequeme Haltung. Langfristig jedoch werden jene Unternehmen vorne liegen, die nicht nur Werkzeuge einführen, sondern Denkweisen verändern. Wer heute aus Frust oder Ungeduld aussteigt, könnte morgen feststellen, dass andere im selben Marktumfeld sehr wohl gelernt haben, das Potenzial zu heben. Dann war es nicht die Technologie, die keinen Impact hatte, sondern die eigene Ignoranz gegenüber dem notwendigen Wandel.

„Wenn du doch länger brauchst, sag bitte dann Bescheid …

Diesen Satz habe ich in Projekten schon oft gehört. Und jedes Mal schwingt darin dasselbe mit: Unsicherheit. Unsicherheit darüber, wie lange etwas wirklich dauert, was es am Ende kosten wird und wer eigentlich das Risiko trägt.

Ich mochte Projektarbeit zu Festpreisen schon immer lieber als Time & Material. Und seit ich wieder in der internen Softwareentwicklung arbeite und regelmäßig mit Agenturen und externen Anbietern zu tun habe, fühle ich mich darin nur noch mehr bestätigt.

Ich brauche keine hochkomplexen Kalkulationen, um das Risiko eines Projekts zu bewerten. Ein Festpreis zwingt automatisch dazu, sich früh Gedanken zu machen: Was ist wirklich Teil des Projekts, was nicht, und wo liegen die Unsicherheiten? Gerade auf Kundenseite ist das ein enormer Vorteil. Freigaben zu bekommen ist viel einfacher, wenn nicht ständig die Frage im Raum steht, was passiert, wenn das Projekt fast fertig ist, aber doch noch mehr Geld benötigt wird – und ob es sich dann überhaupt noch lohnt, weiterzumachen.

Auch in der Rolle des Anbieters ziehe ich Festpreise klar vor. Ich weiß von Anfang an, was ich verdienen werde und wie lange ein Projekt maximal dauern darf. Dadurch lasse ich mich nicht auf Endlosprojekte ein, bei denen zwar kontinuierlich Geld fließt, aber kein Ende in Sicht ist. Nachverhandlungen entfallen ebenfalls, weil der finanzielle Rahmen klar ist und sich daran nichts mehr ändert.

Diese Klarheit hat einen wichtigen Nebeneffekt: Ich muss selbst sauber planen. Eigene Unzulänglichkeiten lassen sich nicht einfach auf den Kunden abwälzen, indem man sagt, dass alles eben länger dauert und deshalb mehr kostet. Gleichzeitig nimmt ein Festpreis dem Kunden sehr viel Unsicherheit. Selbst wenn etwas nicht ideal läuft, steigen die Kosten nicht plötzlich. Diese Sicherheit ist Kunden auch Geld wert. Viele zahlen lieber etwas mehr, als später intern erneut Prozesse durchlaufen zu müssen, um zusätzliches Budget freizugeben.

Natürlich hat Time & Material seine Berechtigung. In der Praxis verleitet dieses Modell jedoch schnell zu problematischem Verhalten. Häufig wird nicht ausreichend geplant oder spezifiziert, weil Vorleistungen nicht bezahlt werden und man möglichst schnell abrechenbare Stunden generieren möchte. Neue Anforderungen werden gerne noch in laufende Projekte aufgenommen, weil sie vielleicht noch ins geplante Budget passen könnten. In der Realität tun sie das nie. Beim Festpreis ist hingegen klar, dass zusätzliche Anforderungen extra kosten – und vor allem auch, wie viel genau.

Time & Material ermöglicht außerdem Preis-Dumping, weil kein Risiko eingepreist werden muss. Beim Festpreis werden sowohl der Initialaufwand als auch ein Puffer berücksichtigt. Bei Time & Material wird dagegen oft gehofft, diesen Initialaufwand über die Laufzeit des Projekts zu kompensieren. Wenn alles länger dauert, ist das erst einmal egal, denn der Kunde zahlt weiter – zumindest so lange, bis er sich weigert oder das Ganze juristisch eskaliert.

Ein weiterer Punkt, der mir beim Festpreis wichtig ist, betrifft die eigene Freiheit in der Zeitplanung. Dem Kunden ist es egal, wie lange ich tatsächlich brauche oder wann ich arbeite. Ich liefere ein Feature, keine Arbeitszeit. Natürlich kann auch ein Festpreisprojekt grob zeitlich eingeordnet werden, und das ist oft sinnvoll, damit der Kunde weiß, wann er womit rechnen kann. Der entscheidende Unterschied ist jedoch, dass der Druck nur auf der Auslieferung liegt und nicht darauf, möglichst wenig Zeit zu bezahlen.

Sollte etwas deutlich schneller gehen als gedacht, kann man immer noch einen Rabatt gewähren. Das freut den Kunden und stärkt die Beziehung. Die Kontrolle bleibt dabei trotzdem beim Anbieter, und der Kunde kann keinen Druck aufbauen in der Hoffnung, durch Verzögerungen weniger zahlen zu müssen.

Mein persönliches Fazit – gerade auch mit Blick auf neue Arbeitsweisen und KI – ist daher recht klar: Es geht um den Wert eines Features, nicht um die Zeit, die seine Umsetzung gebraucht hat. Wenn jemand eine sehr gute Idee hat und dadurch extrem schnell liefert, ist das oft mehr wert als eine Lösung, die länger braucht. Eigentlich sollte dann auch genau diese Leistung besser bezahlt werden.

Lass dir Schnelligkeit und Qualität bezahlen, nicht die Tatsache, dass du besonders lange an einem Feature arbeitest. Gib dem Kunden die Kontrolle über das Projekt zurück. Denn je geringer das Risiko ist, desto entspannter – und am Ende auch besser – arbeiten alle Beteiligten.