In Teil 1 dieser Reihe ging es um strukturelle Fehler: fehlende Fremdschlüssel, falsche Indizes, Soft Deletes die keine sind. Am Ende stand ein Versprechen: Transaktionen. Ein Thema das in der Theorie einfach klingt und in der Praxis erschreckend oft falsch eingesetzt wird — oder gar nicht.
(mehr …)Kategorie: eproi pur
eproi pur – das ist „unsere“ Kategorie in der wir ganz speziell beleuchten was uns in/um/mit eproi bewegt. Dabei sowohl technisches aus unseren Projekten aber mitunter auch tagesaktuelle IT-Themen.
-
KI erzeugt Code. Programmieren kann sie nicht.
„Wir brauchen keinen Entwickler mehr, dafür haben wir jetzt KI.“ Dieser Satz fällt gerade in vielen Unternehmen. Manche sagen ihn laut in Meetings. Andere denken ihn still beim nächsten Budgetgespräch. Und ein paar haben bereits entsprechend gehandelt: Entwickler entlassen, Stellen nicht neu besetzt, Projekte an Tools übergeben die Prompts in Code verwandeln.
Das ist ein Fehler. Nicht weil KI nutzlos wäre. Sondern weil der Unterschied zwischen „Code erzeugen“ und „programmieren“ größer ist als er auf den ersten Blick aussieht.
1. Was KI wirklich macht — und was nicht
Eine KI beantwortet die Frage die ihr gestellt wird. Schreibt man „Erstell mir eine PHP-Funktion die Nutzereingaben validiert“, bekommt man eine PHP-Funktion die Nutzereingaben validiert. Das ist beeindruckend. Das ist auch nützlich. Aber es ist nicht dasselbe wie Programmieren. Unklar bleibt bei diesem Prompt auch, ob es die richtigen, zielführenden Validierungen sind. Und ob im Rahmen des Projekts vielleicht noch weitere Validierungen notwendig sein würden; oder zumindest hilfreich.
Das liegt vor allem an einem Punkt: Die KI kennt nur den Kontext den man ihr explizit gibt — und der ist fast immer unvollständig. Nicht weil man es nicht besser wüsste, sondern weil beim ersten Prompt niemand daran denkt alles zu nennen: Serverumgebung, bestehende Architektur, Abhängigkeiten, Einsatzzweck, Sicherheitsanforderungen. Die KI baut sich diesen Kontext nicht selbst zusammen. Sie baut die Funktion für das was im Prompt steht und ignoriert alles was fehlt. Dabei greift sie auf clevere Algorithmen und Wahrscheinlichkeiten zurück. Daher passt das Ergebnis dann meist in abstrakten, generellen Anforderungem, aber nicht immer für die konkrete Situation.
Programmieren bedeutet: Architekturentscheidungen treffen. Wissen welcher Ansatz in drei Jahren noch wartbar ist. Verstehen wie ein Server unter Last reagiert. Einschätzen welche Datenstruktur für diesen konkreten Anwendungsfall passt und welche nicht. Sicherheitsimplikationen durchdenken bevor jemand den Code anfasst. Und sicherlich auch die Edge Cases mit im Blick haben, die der Wahrscheinlichkeit nach nicht so relevant sind, aber wenn sie auftreten, furchtbar wirken können.
All das steckt nicht im Prompt. All das ist das Handwerk hinter dem Code.
2. Das Validierungsproblem — wer prüft ob der Code richtig ist?
Eine Funktion die aus einem gegebenen Prompt entsteht, ist nicht zwingend eine vollständige integrative Lösung. Der entscheidende Test ist nicht „liefert sie das erwartete Ergebnis bei normaler Nutzung“ sondern: Was passiert wenn jemand sie falsch nutzt? Was passiert bei einer leeren Eingabe, einem unerwarteten Datentyp, einem Angreifer der gezielt nach Schwachstellen sucht? Und wie wirkt die Funktion im Zusammenspiel mit der gesamten Anwendung?
Diese Fragen beantworten zu können setzt voraus zu verstehen was die Funktion im Inneren macht. Wer das nicht weiß, weiß auch nicht wo sie bricht. Und KI-generierter Code bricht — nicht öfter als von Menschen geschriebener Code, aber genauso. Der Unterschied ist: Bei menschlichem Code weiß der Entwickler warum. Bei KI-Code weiß niemand es mehr.
Das ist kein Argument gegen KI als Werkzeug. Es ist ein Argument gegen KI ohne Review.
3. Das Skalierungsproblem — Snippet ist nicht Architektur
Ein CSS-Snippet per KI generieren: unkritisch. Eine Hilfsfunktion zum Formatieren eines Datums: unkritisch. Einen Login-Flow, eine Zahlungsschnittstelle, eine Rechteverwaltung per KI bauen und dann so deployen: fahrlässig.
Der Unterschied liegt nicht in der Komplexität einzelner Codeblöcke. Er liegt darin wie viele Annahmen in eine Architektur eingeflossen sind, wie viele davon sicherheitsrelevant sind, und wie viele davon ein Nicht-Programmierer weder stellen noch beantworten kann. KI kennt diese Annahmen nicht. Sie beantwortet die Frage die ihr gestellt wird nicht die Fragen die man „vergessen“ hat zu stellen.
4. Das Kontextproblem — KI hat kein Projektgedächtnis
Große Softwareprojekte entstehen nicht an einem Tag. Sie wachsen über Wochen und Monate, mit Entscheidungen die aufeinander aufbauen, mit Architekturen die sich entwickeln, mit Kontext der sich anhäuft. Und manchmal auch mit Kehrtwenden, wenn sich herausstellt, dass der Ansatz nicht trägt oder sich die Rahmenbedingungen zwischenzeitlich geändert haben.
KI hat davon nichts. Jede neue Session startet bei null. Wer täglich mit KI an einer komplexen Codebase arbeitet verbringt einen erheblichen Teil der Zeit damit die KI erst wieder in den Stand zu versetzen der nötig ist um sinnvollen Anschlusscode zu erzeugen: Hier ist die bestehende Struktur. Hier ist die bisherige Logik. Hier sind die Constraints die wir uns letzte Woche überlegt haben.
Das ist kein theoretisches Problem; es ist ein täglicher Overhead der den versprochenen Geschwindigkeitsvorteil in vielen Projekten schlicht aufzehrt. KI beschleunigt isolierte Aufgaben. Komplexe, gewachsene Systeme sind das Gegenteil davon. Dazu kommt: KI arbeitet nicht deterministisch. Und nur weil ich ihr heute wieder alles rein gebe, was wir gestern erarbeitet haben, muss im Anschluss nicht dasselbe rauskommen, was gestern rausgekommen ist.
5. Die fatale Unternehmensentscheidung
Viele Unternehmen entlassen gerade Entwickler oft genug auch erfahrene Senior Developers. Die Begründung: KI übernimmt das. Was dabei übersehen wird: Genau diese Entwickler wären die einzigen die KI-generierten Code seriös reviewen könnten.
Wer einen Junior fragt ob der Code sicher ist, bekommt „ja“; weil er es nicht beurteilen kann. Wer eine KI fragt ob ihr eigener Code sicher ist, bekommt ebenfalls „ja“. Was fehlt ist der erfahrene Blick der weiß was er suchen muss, der Edge Cases kennt, der Sicherheitslücken erkennt bevor sie ausgenutzt werden.
Die Quittung für diese Entscheidungen kommt. Nicht heute. Aber in zwei, drei Jahren wenn Systeme die heute mit KI gebaut werden unter Last versagen, Daten verloren gehen oder Sicherheitslücken auftauchen die niemand mehr im Team schließen kann.
Funfact übrigens: Auch das Entlassen aller Junior-Developer ist fahrlässig. Wer soll denn in einigen Jahren, wenn die „alten Hasen“ weg sind, die Architektur und den Code weiterverfolgen, wenn niemand mehr gelernt hat, wie „Senior Dev“ eigentlich geht!?
Fazit — KI als Werkzeug, nicht als Ersatz
KI ist ein leistungsfähiges Werkzeug für klar umgrenzte, überschaubare Aufgaben. Boilerplate-Code. Erste Entwürfe. Recherche. Erklärungen. Das alles ist genuiner Mehrwert.
Was KI nicht ist: ein Ersatz für Architekturdenken, Sicherheitskompetenz, Projekterfahrung und Reviewkompetenz. Wer das verwechselt baut schnell und baut auf Sand.
Der sinnvolle Einsatz von KI in der Softwareentwicklung setzt genau das Wissen voraus das angeblich überflüssig geworden ist: zu verstehen was hinter dem Code steckt.
KI sinnvoll in deine Software integrieren
KI-Unterstützung entfaltet ihren Mehrwert wenn sie von Entwicklern eingesetzt wird die den Output verstehen, prüfen und verantworten können. Wie das konkret aussieht und wie ich KI in bestehende PHP- und Laravel-Systeme integriere findest du auf unserer Seite zur KI-Integration.
-
SQL Performance und Datenintegrität
Die 5 Fehler die ich immer wieder sehe
Die Datenbank ist das Fundament jeder Anwendung. Das Frontend lässt sich neu bauen, Business-Logik refactoren, ein Framework austauschen — aber eine schlecht strukturierte oder langsame Datenbankschicht zieht die gesamte Anwendung nach unten. Und das meist schleichend: Nicht mit einem Knall, sondern mit Abfragen die nach und nach langsamer werden, mit Daten die irgendwann nicht mehr stimmen, mit einem System das unter Last in die Knie geht.
Trotzdem bekommt die Datenbank in vielen Projekten die wenigste Aufmerksamkeit. Sie läuft, also ist sie gut. Bis sie es nicht mehr ist.
In der Praxis sehe ich immer wieder dieselben Muster: Egal ob Neuprojekt oder gewachsenes System. Hier sind die fünf die mir am häufigsten begegnen.
(mehr …)Die 5 Fehler die ich immer wieder sehe
Die Datenbank ist das Fundament jeder Anwendung. Das Frontend lässt sich neu bauen, Business-Logik refactoren, ein Framework austauschen — aber eine schlecht strukturierte oder langsame Datenbankschicht zieht die gesamte Anwendung nach unten. Und das meist schleichend: Nicht mit einem Knall, sondern mit Abfragen die nach und nach langsamer werden, mit Daten die irgendwann nicht mehr stimmen, mit einem System das unter Last in die Knie geht.
Trotzdem bekommt die Datenbank in vielen Projekten die wenigste Aufmerksamkeit. Sie läuft, also ist sie gut. Bis sie es nicht mehr ist.
In der Praxis sehe ich immer wieder dieselben Muster: Egal ob Neuprojekt oder gewachsenes System. Hier sind die fünf die mir am häufigsten begegnen.
(mehr …) -
PHP-Dateien ohne PHP — warum das eine stille Performance-Falle ist
Bei der Analyse einer älteren WordPress-Installation fiel mir kürzlich etwas auf, das auf den ersten Blick harmlos wirkt: Dateien mit der Endung .php — die aber kein einziges Byte PHP enthalten. Stattdessen: XML-Strukturen, SVG-Markup, statische Inhalte. Alles prima, nur eben nicht PHP.
Klingt nach Kleinigkeit. Ist es nicht.
(mehr …)Bei der Analyse einer älteren WordPress-Installation fiel mir kürzlich etwas auf, das auf den ersten Blick harmlos wirkt: Dateien mit der Endung .php — die aber kein einziges Byte PHP enthalten. Stattdessen: XML-Strukturen, SVG-Markup, statische Inhalte. Alles prima, nur eben nicht PHP.
Klingt nach Kleinigkeit. Ist es nicht.
(mehr …) -
Laravel 12 auf 13 — warum wir migriert haben, obwohl wir nicht mussten
Manchmal merkt man beim Arbeiten an einem neuen Projekt was einem an einem älteren fehlt. Genau das ist passiert: Bei neueren Laravel-Projekten haben wir direkt mit Version 13 gestartet und dabei Features entdeckt, die wir rückwirkend auch in unserem eigenen Produkt haben wollten.
Allen voran: native Suche in verschlüsselten Datenbankspalten. Ein Feature das für datenschutzsensible Anwendungen konkret relevant ist — und das in Laravel 13 sauber im Standard mitkommt, ohne eigene Konstrukte drumherum.
Dazu kam eine pragmatische Entscheidung: Lieber jetzt migrieren, bevor weitere Features dazukommen. Je mehr ein System wächst, desto mehr gibt es beim nächsten Mal zu testen und anzupassen. Wer das kennt, kennt auch den Moment wo man sich denkt: hätte ich das früher gemacht.
Das Projekt hatte über die Zeit einige eigene Klassenkonstrukte und Besonderheiten im Front- und Backend angesammelt. Dinge, für die Laravel zwar die Basis gelegt hatte, die wir aber selbständig weiterentwickelt hatten. Entsprechend stand zu Beginn gefühlt eine sehr lange Checkliste im Raum.
Am Ende zeigte sich: Es ging schneller als erwartet. Der Grund dafür hat weniger mit der Laravel-Version zu tun als mit dem Zustand des Projekts davor.
(mehr …)Manchmal merkt man beim Arbeiten an einem neuen Projekt was einem an einem älteren fehlt. Genau das ist passiert: Bei neueren Laravel-Projekten haben wir direkt mit Version 13 gestartet und dabei Features entdeckt, die wir rückwirkend auch in unserem eigenen Produkt haben wollten.
Allen voran: native Suche in verschlüsselten Datenbankspalten. Ein Feature das für datenschutzsensible Anwendungen konkret relevant ist — und das in Laravel 13 sauber im Standard mitkommt, ohne eigene Konstrukte drumherum.
Dazu kam eine pragmatische Entscheidung: Lieber jetzt migrieren, bevor weitere Features dazukommen. Je mehr ein System wächst, desto mehr gibt es beim nächsten Mal zu testen und anzupassen. Wer das kennt, kennt auch den Moment wo man sich denkt: hätte ich das früher gemacht.
Das Projekt hatte über die Zeit einige eigene Klassenkonstrukte und Besonderheiten im Front- und Backend angesammelt. Dinge, für die Laravel zwar die Basis gelegt hatte, die wir aber selbständig weiterentwickelt hatten. Entsprechend stand zu Beginn gefühlt eine sehr lange Checkliste im Raum.
Am Ende zeigte sich: Es ging schneller als erwartet. Der Grund dafür hat weniger mit der Laravel-Version zu tun als mit dem Zustand des Projekts davor.
(mehr …) -
Primärschlüssel: Warum Auto-Increment IDs UUIDs in den meisten Projekten schlagen
Die harmlos wirkende Anforderung
Es fing mit einer simplen Aufgabe an: Eine AJAX-Abfrage sollte idempotent werden. Konkret bedeutete das — egal wie oft der Request gefeuert wird, das Ergebnis bleibt stabil und vorhersehbar. Kein Flackern, keine Race Conditions, keine doppelten Einträge die sich gegenseitig überholen.
Die klassische Lösung: ORDER BY id. Fertig. Nächstes Problem.
Nur dass es diesmal kein nächstes Problem gab. Zumindest nicht sofort.
(mehr …) -
Neuer Service: Ein Pageconverter
Nach unserer Event‑Ressourcenplattform Ende letzten Jahres folgt nun das nächste Produkt aus dem eproi‑Ökosystem: PageConvertPage.
(mehr …)
Mit diesem Tool lassen sich Webseiteninhalte direkt in den gewünschten Pagebuilder übersetzen – schnell, zuverlässig und mit weitaus geringerer manueller Nacharbeit als bisher. -
WordPress gehackt: Befallene Installation bereinigen — ein Praxisfall
Eine WordPress‑Installation, die gestern noch normal lief, ist plötzlich komplett tot – weder Frontend noch Backend reagieren. Nach der ersten Wiederherstellung zeigt sich schnell, dass das Backend zwar wieder erreichbar ist, das Frontend jedoch weiterhin ausfällt. Ein Blick per FTP bringt die eigentliche Ursache ans Licht: Die Seite ist kompromittiert. Die Art der Infektion sorgt für massive Systemlast, selbstreparierende Core‑Dateien und ein Root‑Verzeichnis, das sich nicht mehr bereinigen lässt. Besonders heikel: Das Ganze läuft auf einem klassischen Webspace ohne SSH‑Zugriff, also ohne jede Möglichkeit, tiefer in das System einzugreifen.
Parallel dazu berichtet Golem über aufgekaufte WordPress‑Plugins, die gezielt mit Backdoors versehen wurden. Cloudflare wiederum bewirbt sein neues EmDash‑System als robustere Alternative. Doch was bedeutet das alles in der Praxis – und was lässt sich aus dieser Melange wirklich lernen?
(mehr …) -
WordPress Plugins: Warum schlechte Auswahl deine Installation ruiniert
-
WordPress Performance: Warum zu viele Plugins deine Seite ausbremsen
WordPress erfreut sich seit Jahren großer Beliebtheit – trotz oder vielleicht gerade wegen seines Alters. Heute wird damit fast alles gebaut: vom persönlichen Blog über Vereinsseiten bis hin zu ausgewachsenen Shopsystemen. Ursprünglich war WordPress aber eine reine Blogsoftware. Viele WordPress‑Seiten werden langsam, weil zu viele Plugins geladen werden – oft ohne dass Betreiber es merken. Oft entstehen Performance‑Probleme dabei nicht durch ein einzelnes Plugin, sondern durch Plugin‑Konflikte – besonders wenn mehrere Erweiterungen dieselben Hooks nutzen.
(mehr …)
Aber viele kennen es: Etliches ist eben nur mit zusätzlichen Plugins möglich.
Und genau da beginnt das Problem: Nur weil man kann, heißt das nicht, dass man sollte.
