Blog: Latest Entries (15):


Tokenmaxxing: Kosten über Resultate

bbcode-image


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

bbcode-image


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

bbcode-image


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?

bbcode-image


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

bbcode-image


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?

bbcode-image


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 …

bbcode-image


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.

Vibe-Coding ist keine Demokratisierung

bbcode-image


In meiner LinkedIn-Bubble lese ich aktuell ständig von Menschen, die sich durch „Vibe-Coding“ in kürzester Zeit großartige Produkte gebaut haben – ganz ohne Programmierer.

Sie seien nun endlich selbst in der Lage, ihre Vorstellungen und Pläne in ein fertiges Produkt zu verwandeln. Kein Ticket schreiben. Kein Entwickler-Briefing. Kein Warten.

Das klingt nach Demokratisierung.
Ist es aber nicht.

Die Rolle des Programmierers war nie die, die man ihr gerade zuschreibt

Was mich an dieser Erzählung stört: Sie schiebt die Rolle des klassischen Programmierers in eine Höhe, die sie seit Jahren faktisch nicht mehr innehat.

Anfang der 2000er war Programmieren tatsächlich noch stark mit technischer Exzellenz verbunden. Man schrieb viel Code selbst, dachte intensiv über Strukturen und Speicher nach und arbeitete teilweise sogar noch direkt mit Pointern. Wer mit C oder gar Assembler gearbeitet hat, weiß, wie viel konzeptionelle und technische Denkleistung darin steckte. Damals bestand ein großer Teil der Arbeit darin, sich überhaupt zu überlegen, wie eine Idee technisch umsetzbar ist und wie sie sauber im Code abgebildet werden kann.

Ab etwa 2010 hat sich das grundlegend verändert. Frameworks und Libraries haben einen Großteil der Arbeit übernommen. Mit Maven, Composer oder npm zieht man sich heute nahezu alles ins Projekt, was man benötigt. Authentifizierung, UI-Komponenten, Datenbankzugriff oder komplette Backend-Strukturen lassen sich mit wenigen Befehlen integrieren. Die wirklich harte technische Komplexität ist in den meisten Anwendungsbereichen verschwunden oder zumindest stark abstrahiert worden.

Code schreiben ist heute keine Kunst mehr

Das meine ich nicht abwertend, sondern nüchtern. In den allermeisten modernen Softwareprojekten ist das eigentliche Schreiben von Code nicht mehr der kreative Kern der Arbeit. Es ist häufig Fleißarbeit.

Man hat den Plan im Kopf, kennt die Architektur und weiß genau, wie das System aufgebaut sein soll. Der schwierigste Teil – das Denken, Strukturieren und Entscheiden – ist bereits passiert. Danach folgt oft nur noch die relativ langwierige Überführung dieser Gedanken in Code. Natürlich geht das mit moderner Autovervollständigung deutlich schneller als früher. Trotzdem bleibt ein Gefühl: Man würde eigentlich gerne so schnell schreiben, wie man denken kann.

Genau hier setzt KI an. Sie tippt schneller. Aber sie ersetzt nicht das Denken.

Entwickler waren schon immer mehr als Code-Schreiber

Wer nie selbst programmiert hat, denkt oft, der Entwickler sei in erster Linie derjenige, der Code schreibt. In Wirklichkeit war das schon lange nicht mehr die entscheidende Rolle.

In vielen Teams sieht man das klassische Gefälle zwischen Senior und Junior. Der Senior entwickelt Konzepte, entscheidet über Architektur, priorisiert und entwirft Lösungen. Der Junior schreibt einen Großteil des Codes. Nicht, weil er die bessere Idee hatte, sondern weil das reine Runterschreiben von Code nicht die wertvollste Kompetenz im gesamten Prozess ist.

Wenn man es so betrachtet, ersetzt KI im Grunde genau diesen mechanischen Teil. Sie ist ein schnelleres Werkzeug, das die Umsetzung beschleunigt. Mehr nicht.

Demokratisierung? Nein.

Demokratisierung würde bedeuten, dass sich die Machtverhältnisse verschieben. Dass plötzlich Menschen Produkte entwickeln können, die es vorher nicht konnten.

Aber das stimmt so nicht.

Die Person, die ein Produkt wirklich durchdenken und entwickeln kann, konnte das auch schon vorher. Programmieren zu lernen ist heute kein exklusives Privileg mehr. Die Tools sind seit Jahren zugänglich, die Komplexität in vielen Bereichen stark reduziert und die Einstiegshürden vergleichsweise niedrig. Wer in der Lage ist, ein Produkt sauber zu konzipieren, wäre auch ohne KI in der Lage gewesen, es selbst zu programmieren. Es hätte nur mehr Zeit gekostet.

KI spart Zeit. Sie verschiebt keine Kompetenz.

Der eigentliche Engpass war nie das Programmieren

Meine Mutter wird kein Produkt per Vibe-Coding entwickeln. Nicht, weil am Ende kein Code generiert würde. Sondern weil sie bereits an der grundlegenden Entwicklung und am Konzept scheitern würde.

Der eigentliche Engpass liegt nicht im Schreiben von Code, sondern in der Fähigkeit, Probleme sauber zu analysieren, Anforderungen zu strukturieren, Prioritäten zu setzen, Features sinnvoll zu designen und ein echtes Verständnis für Nutzer und deren Bedürfnisse zu entwickeln. Genau dort entsteht der Wert. Genau dort entscheidet sich, ob ein Produkt funktioniert oder nicht.

Diese Kompetenzen waren schon immer entscheidend – lange bevor KI existierte.

Wer sollte hier eigentlich stolz sein?

Deshalb mein Punkt: Wer jetzt stolz ist, per Vibe-Coding ein Produkt gebaut zu haben, sollte Programmierer nicht größer machen, als sie sind, und sich selbst nicht kleiner, als man eigentlich ist.

Die Kompetenz lag nie primär im Tippen von Code. Sie liegt im Denken, im Strukturieren und im echten Produktverständnis.

KI macht den Prozess schneller. Aber sie demokratisiert ihn nicht.

Die Macht verschiebt sich nicht.
Nur das Werkzeug wird schneller.

Und vielleicht ist genau das die eigentliche Wahrheit hinter dem ganzen Hype.

Schnelles Kopieren einer Firebird-2.5-Datenbank unter Linux

bbcode-image


Wer mit großen Firebird-2.5-Datenbanken arbeitet, kennt das Problem:
Ein klassisches Backup mit gbak kann extrem lange dauern. In meinem Fall benötigte ein gbak-Backup einer ca. 90-GB-Datenbank auf einem Surface-PC über 12 Stunden.

Mit nbackup lässt sich das gleiche Ziel jedoch in rund 20 Minuten erreichen.

Der verwendete Befehl


cd /usr/local/firebird/bin && \
./nbackup -user SYSDBA -password masterkey -L /firebird/data/testdb.fdb && \
cp /firebird/data/testdb.fdb /firebird/data/testdb_bkp_$(date +%Y%m%d).fdb && \
./nbackup -user SYSDBA -password masterkey -N /firebird/data/testdb.fdb && \
./nbackup -user SYSDBA -password masterkey -F /firebird/data/testdb_bkp_$(date +%Y%m%d).fdb


Was passiert hier genau?

nbackup -L (Lock)
Die Datenbank wird kurzzeitig in einen konsistenten Zustand versetzt.
Schreibzugriffe werden blockiert, laufende Leser dürfen weiterarbeiten.

cp
Die Datenbankdatei wird direkt auf Dateisystem-Ebene kopiert.
Das ist extrem schnell, da keine logische Analyse der Daten erfolgt.

nbackup -N (Normal)
Die Datenbank wird wieder freigegeben und arbeitet ganz normal weiter.

nbackup -F (Fixup)
Die Kopie wird „repariert“, sodass sie als eigenständige, saubere Datenbank genutzt werden kann.

Warum ist das schneller als gbak?

gbak arbeitet logisch:

- jede Tabelle,
- jeder Index,
- jeder Datensatz
wird gelesen, interpretiert und neu geschrieben.

Das ist sicher und portabel, aber bei großen Datenmengen sehr langsam.

nbackup dagegen arbeitet physisch:

- es wird praktisch eine konsistente Momentaufnahme der Datenbankdatei erstellt,
- ohne Daten zu interpretieren oder neu aufzubauen.

Das Ergebnis:
➡️ Minuten statt Stunden bei sehr großen Datenbanken.

Fazit

Für schnelle Sicherungen oder Klone großer Firebird-2.5-Datenbanken ist nbackup die deutlich bessere Wahl.
gbak bleibt sinnvoll für Migrationen oder Versionswechsel – aber für den Alltag spart nbackup enorm viel Zeit und Nerven.

nbackup gibt es natürlich auch unter Windows!

Was wird in zwei Jahren sein?

bbcode-image


Was wird in zwei Jahren sein? Diese Frage beschäftigt mich in letzter Zeit immer häufiger. Es sind keine ausgearbeiteten Prognosen, sondern eher lose Überlegungen darüber, wie sich alles entwickeln könnte, wenn die aktuelle Dynamik anhält. Und falls es am Ende doch ganz anders kommt, dann lag ich eben daneben. Sollte sich jedoch herausstellen, dass ich mit meinen Einschätzungen richtig liege, werde ich vermutlich nicht widerstehen können, das mit einem gewissen Stolz zu erwähnen.

Wenn ich mir anschaue, mit welcher Geschwindigkeit ich in den letzten Tagen neue kleine Tools und Features in bestehende Legacy-Systeme eingebaut habe, wird mir deutlich, dass sich etwas Grundlegendes verändert hat. Aufgaben, die früher Planung, Abstimmung und viele Stunden konzentrierter Entwicklungsarbeit erfordert hätten, lassen sich heute oft in einem Bruchteil der Zeit umsetzen. Dieses Gefühl von Beschleunigung ist nicht mehr nur ein leises Hintergrundrauschen, sondern wird zunehmend zum dominanten Taktgeber im Arbeitsalltag.

Das Disruptive daran ist, dass diese Veränderung längst nicht mehr nur innerhalb der Softwareentwicklung zu spüren ist. Ich hatte zuletzt mehrere Anfragen dazu, wie sich etwa Plugins für Shop-Systeme mithilfe von KI entwickeln lassen. Gleichzeitig wächst das Unverständnis darüber, warum man noch mehrere Personentage bei einer Agentur einkaufen sollte, wenn sich vergleichbare Ergebnisse scheinbar in wenigen Stunden erzielen lassen. Diese Perspektive ist nachvollziehbar und wirft gleichzeitig spannende Fragen auf: Wie wird die Zusammenarbeit mit Agenturen künftig aussehen, wenn der eigentliche Code nicht mehr zwingend von ihnen stammt, sondern von einer KI generiert wird, die theoretisch von jedem bedient werden kann? Genau an diesem Punkt entscheidet sich, wie Agenturen in Zukunft ihren Wert definieren und ihr Geld verdienen werden.

Wird KI Jobs verändern? Daran besteht für mich kein Zweifel. Ich habe das Gefühl, mich gerade mitten im Epizentrum dieser Entwicklung zu befinden, weil die Softwareentwicklung vermutlich eines der ersten Berufsfelder ist, das die volle Härte, aber auch das enorme Potenzial dieser Technologie zu spüren bekommt. Einige Menschen werden ihren Job verlieren, wenn sie sich nicht anpassen, und selbst diejenigen, die sich weiterentwickeln, werden möglicherweise feststellen, dass künftig einfach weniger Entwickler benötigt werden.

Doch die Veränderungen gehen noch tiefer. Je besser KI wird, desto mehr verliert Software als Produkt an sich an Bedeutung. Ich ertappe mich immer häufiger dabei, dass ich nicht mehr gezielt nach Websites oder Tools suche, um kleine Aufgaben zu erledigen. Stattdessen lasse ich mir einfach eine kleine Web-App erstellen, die genau auf meinen Bedarf zugeschnitten ist. Wenn sich diese Entwicklung fortsetzt, könnte es sich irgendwann kaum noch lohnen, Standardsoftware zu kaufen, wenn man sie sich direkt individuell generieren lassen kann. Viele Anwendungen sind in ihrer Struktur einfacher, als sie auf den ersten Blick wirken, und genau hier spielt KI ihre Stärke aus.

Was also macht ein Entwickler in zwei Jahren? Ich vermute, dass sich die Rolle deutlich verschiebt. Entwickler werden stärker definieren, was Software leisten soll und wie Systeme miteinander interagieren müssen. Sie werden Code eher prüfen als selbst schreiben, Kontext zu bestehenden Legacy-Systemen dokumentieren und alte Strukturen so aufbereiten, dass KI effektiv damit arbeiten kann. Gleichzeitig werden sie Unternehmen dabei unterstützen, KI sinnvoll einzusetzen, Automatisierungen zu entwickeln und neue Arbeitsweisen zu etablieren. Das wichtigste Werkzeug eines Entwicklers wird dabei die KI selbst sein.

Für mich persönlich bedeutet das, dass ich aktuell vor allem in einem überschaubaren Zeithorizont plane. Die nächsten zwei Jahre erscheinen mir greifbar genug, um Entscheidungen über neue und bestehende Systeme sowie deren Weiterentwicklung und Pflege zu treffen. Ich gehe davon aus, dass KI in diesem Zeitraum ein Niveau erreicht, auf dem sich ein Großteil der benötigten Standardsoftware direkt generieren lässt. Sollte mir ein Legacy-System dann nicht mehr passen, könnte es realistischer werden, es einfach neu zu bauen, statt es mühsam weiterzuentwickeln.

Ich stelle mir Meetings vor, in denen Fachabteilungen und Entwickler gemeinsam Anforderungen formulieren, während im Hintergrund bereits neue Versionen der Software entstehen. Eine Art „Vibe-Coding“ im größeren Maßstab, bei dem Systeme kontinuierlich angepasst und neu zusammengesetzt werden. Mein persönlicher Vorteil liegt dabei weniger im eigentlichen Programmieren, sondern darin, dass ich die Firma, ihre Prozesse und ihre Sprache kenne. Diese Fähigkeit, Anforderungen klar und eindeutig zu formulieren, könnte wichtiger werden als jede einzelne Programmiersprache.

Am Ende bleibt dennoch eine große Unsicherheit. Es wird sich zeigen, ob diese Entwicklungen tatsächlich in der Geschwindigkeit eintreten, die heute möglich erscheint, und welche Auswirkungen sie auf Gesellschaft und Wirtschaft haben werden. Mein Eindruck ist, dass Deutschland auf viele dieser Veränderungen noch nicht ausreichend vorbereitet ist. Umso spannender wird es sein zu beobachten, wie sich Technologie, Arbeitswelt und Erwartungen in den kommenden Jahren gegenseitig beeinflussen und neu ausrichten.

Was verstehe ich unter einem Commitment?

bbcode-image


Der Begriff Commitment wird im Arbeitsalltag häufig verwendet, bleibt dabei aber oft unscharf. Für mich bedeutet ein Commitment deutlich mehr als ein loses „Ich kümmere mich darum“. Es ist eine bewusste Zusage und die Grundlage für professionelle Zusammenarbeit sowie für Vertrauen innerhalb eines Teams.

Ein Commitment beginnt damit, dass man klar kommuniziert, bis wann man sich um ein Thema gekümmert hat. Anschließend tut man alles dafür, diesen Zeitpunkt auch einzuhalten. Dabei geht es nicht darum, dass immer alles perfekt läuft. Entscheidend ist vielmehr, Verantwortung für die eigene Zusage zu übernehmen.

Es ist grundsätzlich kein Problem, wenn ein Commitment nicht eingehalten werden kann. Wichtig ist jedoch, dass die Gründe dafür nachvollziehbar sind und dass sie rechtzeitig und vollständig kommuniziert werden. Überraschungen kurz vor Ablauf oder gar erst auf Nachfrage untergraben Vertrauen und erschweren Zusammenarbeit unnötig.

Zu einem Commitment gehört für mich immer auch eine saubere und transparente Kommunikation. Dazu zählt, offen darzulegen, was konkret bereits umgesetzt wurde und welche Schritte unternommen wurden. Ebenso wichtig ist es, ehrlich zu benennen, welche Probleme aufgetreten sind und ob – und von wem – versucht wurde, Unterstützung zu bekommen. Gerade bei Schwierigkeiten ist es ein Zeichen von Professionalität, sich aktiv Hilfe zu suchen, statt Probleme still auszusitzen.

Wenn es Hindernisse gab, die sich nicht überwinden ließen, müssen auch diese klar benannt werden. Dabei geht es nicht um Rechtfertigung, sondern darum zu erklären, was genau nicht funktioniert hat und welche Auswirkungen das auf das Ergebnis oder den Zeitplan hat. Ebenso gehört zu guter Kommunikation die klare Aussage, ob ein Thema abgeschlossen ist oder wann realistisch mit einem Abschluss zu rechnen ist.

Ein weiterer wichtiger Aspekt ist die Reflexion. Treten Probleme auf, sollte man prüfen, ob sich daraus Verbesserungen für die eigenen Workflows oder für die bestehende Infrastruktur ableiten lassen. Ebenso relevant ist die Frage, ob man plant, diese Verbesserungen auch tatsächlich umzusetzen. Ein Commitment endet nicht zwangsläufig mit dem Ergebnis, sondern oft erst mit den daraus gezogenen Lehren.

Kommunikation ist dabei mindestens genauso wichtig wie die Umsetzung selbst. Eine gute Lösung, über die niemand Bescheid weiß oder deren Status unklar ist, bringt in der Praxis oft wenig. Umsetzung ohne Kommunikation führt fast zwangsläufig zu Missverständnissen, Doppelarbeit oder falschen Erwartungen.

Dabei darf man niemals davon ausgehen, dass die andere Seite ja hätte nachfragen müssen. Diese Annahme erzeugt unnötige Arbeit und verschiebt Verantwortung in die falsche Richtung. Die Pflicht zur Statuskommunikation liegt immer bei der Person, die das Commitment abgegeben hat – also beim aktiven Part.

Commitments sind deshalb kein formales Beiwerk, sondern eine absolute Voraussetzung für professionelle Arbeit. Ohne verlässliche Zusagen und transparente Kommunikation funktionieren weder Planung noch Zusammenarbeit, insbesondere nicht in Teams mit mehreren Abhängigkeiten.

Gleichzeitig ist es wichtig, Commitments nicht als Maßstab für den persönlichen Wert zu missverstehen. Wenn jemand es nicht schafft, Commitments zuverlässig einzuhalten, heißt das nicht automatisch, dass diese Person ein schlechter Entwickler oder eine schlechte Fachkraft ist. Es kann jedoch ein Hinweis darauf sein, dass Rollen mit hoher Verantwortung – etwa auf Senior-Level, in der Teamleitung oder in Führungspositionen – vielleicht nicht oder noch nicht der richtige nächste Schritt sind.

Commitment bedeutet am Ende klare Zusagen zu machen, aktiv zu kommunizieren, Verantwortung für Probleme und Verzögerungen zu übernehmen und aus Fehlern zu lernen. Wer das ernst nimmt, verbessert nicht nur die eigene Arbeit, sondern auch die Zusammenarbeit im gesamten Team.

Zwei Arten von Entwicklern

bbcode-image


In meiner Zeit als Entwickler und generell in Softwareprojekten habe ich immer wieder zwei sehr unterschiedliche Typen von Softwareentwicklern kennengelernt. Der Unterschied liegt weniger im Können oder im Wissen, sondern vor allem in der Herangehensweise bei der Lösungsfindung. Beide Gruppen können zu sehr guten Ergebnissen kommen, aber sie arbeiten auf völlig unterschiedliche Weise.

Ich selbst gehörte immer zu den Entwicklern, die sich zunächst lange Gedanken machen. Bevor die ersten Zeilen Code entstehen, steht bei mir meist eine Phase der Analyse und Konzeption. Ich überlege mir mögliche Architekturen, entwerfe Strukturen und versuche, das Problem möglichst umfassend zu verstehen. Erst wenn sich ein klares Bild ergibt, beginne ich mit der eigentlichen Implementierung. Das hat den Vorteil, dass viele Entscheidungen bereits getroffen sind, bevor sie im Code sichtbar werden.

Diese Vorgehensweise hat allerdings eine kleine Schwäche, zumindest aus Sicht vieler Kunden. Sie sehen gerne möglichst früh etwas Greifbares. Wenn über längere Zeit nichts Sichtbares entsteht, werden sie schnell unruhig. Sobald die eigentliche Entwicklung beginnt, geht es zwar oft sehr schnell voran und die Begeisterung ist groß, aber die Phase davor muss man häufig mit kleinen sichtbaren Fortschritten überbrücken, damit Vertrauen und Geduld erhalten bleiben.

Andere Entwickler haben dieses Problem kaum. Sie steigen direkt mit dem Code ein und lassen das Konzept während der Arbeit entstehen. Ideen werden unmittelbar ausprobiert, Ansätze getestet und bei Bedarf auch wieder verworfen. Für sie ist es selbstverständlich, Code neu zu schreiben oder ganze Teile zu ersetzen, wenn sich während der Entwicklung bessere Lösungen ergeben. Dabei entsteht oft ein Flow, in dem man Schritt für Schritt weiterkommt und sich die Lösung organisch entwickelt.

Auch dieses Vorgehen hat jedoch seine eigene Dynamik in der Zusammenarbeit mit Kunden. Zwar gibt es sehr früh etwas zu sehen, doch danach kann es Phasen geben, in denen sich aus Kundensicht scheinbar wenig bewegt. Vieles passiert im Hintergrund: Refactoring, neue Ansätze, verworfene Ideen und erneute Versuche. Für Außenstehende wirkt es dann manchmal so, als würde der Fortschritt langsamer werden, obwohl intern intensiv gearbeitet wird.

Wenn man sich heutige Diskussionen über Begriffe wie Vibe Coding und Context Engineering anschaut, erkennt man erstaunlich viele Parallelen zu diesen beiden klassischen Arbeitsweisen. Beim Context Engineering wird zunächst der Kontext aufgebaut, strukturiert und vorbereitet, bevor er an eine KI übergeben wird. Das erinnert stark an die Entwickler, die zuerst ein Konzept ausarbeiten und erst später mit der eigentlichen Umsetzung beginnen.

Beim Vibe Coding hingegen entsteht der Kontext während der Arbeit mit der KI. Man probiert Dinge aus, passt Prompts an, verwirft Ergebnisse und tastet sich iterativ an eine Lösung heran. Genau wie beim Entwickler, der direkt mit dem Coden beginnt und das Konzept währenddessen wachsen lässt.

Was nun besser oder schlechter ist, lässt sich kaum eindeutig beantworten. Viel hängt von persönlichen Vorlieben ab, aber auch davon, welche Informationen zu Beginn vorhanden sind und welche Erwartungen der Kunde hat. Manche Projekte profitieren von einer klaren Konzeptphase, andere von einem experimentelleren Ansatz.

Interessant ist vor allem, dass die aktuellen KI-Diskussionen im Kern keine völlig neuen Arbeitsweisen hervorbringen. Sie greifen vielmehr bekannte Konzepte der Softwareentwicklung auf und machen sie sichtbarer. Die Werkzeuge ändern sich, doch die grundlegenden Denkweisen bleiben erstaunlich konstant. KI verstärkt diese Unterschiede lediglich und räumt gleichzeitig viele Nebengeräusche aus dem Weg, die sie früher überlagert haben.

KI hat mich abgehängt. So richtig doll.

bbcode-image


Ich habe das Gefühl, dass ich den Anschluss verliere. Und das ausgerechnet bei KI – einem Thema, mit dem ich mich eigentlich gut auskenne.

Vor zwei Jahren war die Welt noch überschaubar. ChatGPT, Stable Diffusion und eine Handvoll weiterer Tools – das war machbar. Man konnte sich reinarbeiten, Dinge ausprobieren, ein Gefühl dafür entwickeln. Heute? Heute gibt es eine schier unendliche Anzahl an mächtigen KI-Tools, Modellen, Frameworks, Agenten und Plattformen.

Ich habe eine Liste mit KI-Modellen und Anwendungen, die ich mir „mal anschauen“ will. Und das sind wohlgemerkt nur die bekanntesten. Wenn ich mir jedes neue Tool, jeden Agenten oder jedes Modell wirklich ansehen wollte, wäre ich damit den ganzen Tag beschäftigt. Und selbst das Anschauen ist ja nur die halbe Miete – richtig anwenden, verstehen, integrieren, produktiv nutzen… das kostet nochmal deutlich mehr Zeit.

Ein gutes Beispiel ist n8n. Ich habe es schon mal benutzt, weiß also, was möglich ist – und genau deshalb hätte ich gern viel mehr Zeit, mich da wirklich reinzufuchsen. Oder Suno: die Idee, das durch ein Open-Source-Modell zu ersetzen, klingt großartig. HeartMula liegt bei mir seit Wochen auf der „Will ich mir ansehen“-Liste. Seit Wochen.

Bei KI-Agenten für die Entwicklung habe ich irgendwann einfach aufgegeben. Ich nutze inzwischen JetBrains Junie – pragmatisch. Das Tool baut mir aus einer kurzen Beschreibung in zwei Minuten eine XML für einen Report, für die ich sonst 30 Minuten zusammenkopieren müsste. Okay, fairerweise: Das Haupt-Query bastle ich immer noch selbst. Aber das tue ich auch ohne KI. Und genau das ist der Punkt.

Dass ich mir flux.2-klein überhaupt angesehen habe, war gefühlt schon eine Leistung. Es hat sich gelohnt – auch wenn ich ehrlich gesagt nicht mehr sicher sagen kann, ob das besser ist als z-image-turbo. Ich glaube, wir sind an einem Punkt angekommen, an dem diese Unterschiede kaum noch wirklich greifbar sind.

Viele behaupten, die Entwicklung von KI hätte sich verlangsamt. Ich merke davon nichts. Ganz im Gegenteil: Ich komme nicht hinterher. Es kommen immer noch schneller neue Dinge heraus, als ich sie mir anschauen kann. Und selbst wenn ich es schaffe, mir etwas anzusehen, fehlt oft die Zeit, es wirklich sauber in den Alltag zu integrieren.

Eigentlich müsste ich mir bei der Arbeit einen ganzen Tag pro Woche freihalten – nur für KI. Nicht zum Spielen, sondern um sinnvoll Dinge zu evaluieren, zu testen und anzuwenden. Denn man könnte so viele Prozesse in der Firma massiv verbessern oder beschleunigen. Man kommt nur einfach nicht dazu.

2D-Images zu 3D-Meshes und dann drucken? Habe ich eine Zeit lang gemacht. Vielleicht im Sommer wieder. Die Sprünge, die es zuletzt bei BambuLab MakerWorld gab, waren schon enorm. Ich will gar nicht wissen, wie gut das inzwischen ist. Eigentlich könnte ich alles noch mal neu und besser machen.

Manchmal frage ich mich, ob „KI-Berater“ inzwischen ein anerkannter Job ist. Denn das zu werden wäre sicher spannend. Oder man holt sich einfach jemanden, der genau das übernimmt: sich mit all dem neuen Zeug auseinanderzusetzen, während man selbst die Alltagsaufgaben erledigt – oft noch ganz ohne KI.

Ich war nie ein großer Freund davon, aber inzwischen kopiere ich E-Mails mit Fragen zu OneDrive oder Datenschutz direkt in ChatGPT, überfliege die Antwort einmal kurz und schicke sie unverändert weiter. Ich bin im Grunde nur noch die Qualitätskontrolle für KI-Resultate. Und irgendwie… finde ich das auch echt gut.

Ich habe sogar eine Python-Webanwendung geschrieben – beziehungsweise von Junie schreiben lassen. Ich kann Python gut lesen, habe aber selbst nur sehr selten damit gearbeitet. Trotzdem: super Ergebnis.

All das zeigt mir wieder, wie schnell sich gerade alles verändert. Und wie schwer es selbst für mich ist, Schritt zu halten – obwohl ich mich mit solchen Themen wirklich gut auskenne und KI auch gut anwenden kann. Ich frage mich, wann diese Erkenntnis in der Breite der Gesellschaft ankommt. Wann die meisten merken, dass sie in einer Welt leben, die zunehmend von KI-Agenten dominiert wird. Dass sie die Kontrolle eigentlich schon längst verloren haben – und im Grunde nur noch akzeptieren können, wie es ist.

Und während ich das schreibe, wird mir klar: All diese Gedanken waren eben noch eine lose Liste aus kurzen Sätzen in Notepad++. Und jetzt sind sie – dank ChatGPT – ein richtiger Text.

Warum wir auch im Zeitalter von AI immer noch Frameworks brauchen

bbcode-image


In den letzten Wochen habe ich mir aus Neugier per Vibe-Coding eine kleine Chat-Anwendung gebaut. Nichts Großes, nichts Kompliziertes – ein simples PHP-Backend, komplett ohne Framework. Kein Symfony, kein Slim, einfach pures PHP.

Und ganz ehrlich: Es läuft erstaunlich gut.

Für diese kleine Anwendung wäre Symfony völlig überdimensioniert gewesen. Zu schwer, zu viel Ballast. Slim hingegen hätte durchaus gepasst, aber am Ende habe ich mich bewusst dagegen entschieden. Es ging auch ohne Framework problemlos. Genau an diesem Punkt stellt sich fast automatisch eine Frage, die aktuell viele umtreibt: Brauchen wir überhaupt noch Frameworks, wenn AI uns beim Programmieren so stark unterstützt?

Die kurze Antwort lautet: Ja. Die längere Antwort ist etwas differenzierter.

Dank AI ist es heute extrem einfach geworden, kleine Anwendungen schnell zusammenzubauen. Boilerplate-Code, Routing, einfache Logik oder sogar kleinere Sicherheitsmechanismen lassen sich in kürzester Zeit generieren. Für kleine Tools, Prototypen oder Experimente funktioniert das hervorragend. Dadurch entsteht schnell der Eindruck, dass Frameworks vielleicht gar nicht mehr notwendig sind.

Dieser Eindruck hält allerdings meist nur so lange, bis eine Anwendung wächst oder länger gepflegt werden soll.

Frameworks bringen vor allem einen entscheidenden Vorteil mit: Sie bestehen aus Code, der von sehr vielen Menschen genutzt, gelesen und getestet wird. Fehler fallen dadurch schneller auf und werden behoben. Auch wenn AI guten Code generieren kann, erreicht individuell erzeugter Code diesen Reifegrad nicht automatisch. Getesteter, vielfach eingesetzter Code bleibt langfristig stabiler.

Ein weiterer wichtiger Punkt ist Sicherheit. In etablierten Frameworks sind viele Sicherheitsmechanismen bereits sauber integriert. Dinge wie CSRF-Schutz, Input-Validierung, sichere Standardkonfigurationen oder Authentifizierungsmechanismen sind dort kein nachträglicher Gedanke, sondern fester Bestandteil. Ohne Framework muss man jedes Mal selbst überprüfen, ob wirklich alles korrekt umgesetzt wurde und ob man nicht irgendwo eine Lücke übersehen hat. Genau diese Wiederholungsarbeit nehmen einem Frameworks ab.

Auch beim Thema Unterstützung zeigen sich klare Vorteile. Wenn die AI einmal nicht weiterkommt oder eine Lösung nicht sauber funktioniert, ist man mit einem bekannten Framework deutlich besser aufgestellt. Dokumentationen, Blogposts, Stack Overflow, GitHub-Issues – für gängige Frameworks findet man fast immer Hilfe. Bei individuell zusammengeschustertem Code sieht das oft anders aus.

Interessanterweise lassen sich Anwendungen mit einem bekannten Framework oft sogar schneller anpassen – selbst ganz ohne AI. Die klaren Strukturen, Konventionen und Best Practices sorgen dafür, dass Änderungen nachvollziehbar und sauber umgesetzt werden können, ohne jedes Mal neu denken zu müssen.

Bei CMS-artigen Anwendungen gehe ich inzwischen allerdings einen etwas anderen Weg. Hier neige ich dazu, mir mithilfe von AI ein sehr schlankes und schnelles Mini-CMS zu bauen, das exakt auf den jeweiligen Anwendungsfall zugeschnitten ist. Ziel ist dabei immer, dass es so einfach zu bedienen ist, dass ich Inhalte notfalls komplett ohne Programmieraufwand per Hand pflegen kann.

Auf klassische Backends verzichte ich dabei fast immer. Entweder ist das System so simpel, dass ein normaler Editor völlig ausreicht, oder ich nutze direkt einen AI-Agenten, um Inhalte einzupflegen. Ein komplexes Admin-Interface ist in vielen Fällen schlicht nicht mehr notwendig.

Am Ende bleibt ein recht klares Fazit. Ja, wir brauchen auch weiterhin Frameworks. Allerdings dürfen und sollten sie schlanker, technischer und fokussierter werden. Viele klassische WYSIWYG-Editoren lassen sich heute problemlos durch AI-Agenten ersetzen, die Inhalte schneller und konsistenter erstellen. Und Template-Sprachen wie Twig sind nach wie vor hervorragend geeignet, um Content strukturiert zu erstellen und zu pflegen – egal ob per Hand oder mit Unterstützung durch AI. Sie sind klarer, wartbarer und oft angenehmer als reines PHP oder Plain HTML, ohne dass man dafür etwas völlig Neues erfinden muss.

AI verändert massiv, wie wir entwickeln. Sie nimmt uns Arbeit ab und beschleunigt Prozesse. Aber sie ersetzt nicht alles, was sich über Jahre bewährt hat. Frameworks gehören weiterhin dazu – nur eben in einer moderneren, schlankeren Form.

Wenn du willst, passe ich den Stil noch weiter an, mache den Text provokanter, kürzer für Social Media oder technischer für eine Entwicklerplattform.

Older posts:

Möchtest Du AdSense-Werbung erlauben und mir damit helfen die laufenden Kosten des Blogs tragen zu können?