Code Review: Was ein Profi an deinem AI-Prototyp als Erstes prüft

Du hast deinen Prototyp an einen Entwickler übergeben. Er öffnet den Code und ist erstmal still. Dann scrollt er, klickt, scrollt weiter. Nach einer Stunde kommt das Feedback: „Der Prototyp ist gut. Aber hier müssen wir einiges ändern.”

Was hat er gesehen? Was prüft ein Profi als Erstes wenn er AI-generierten Code übernimmt? Und warum? In diesem Artikel erkläre ich die 8 Checkpoints eines professionellen Code Reviews — so, dass du als Nicht-Techniker verstehst was passiert und warum es wichtig ist.

Warum ein Code Review der erste Schritt ist

Bevor ein Entwickler eine Zeile Code schreibt, liest er deinen Code. Das ist kein Misstrauen — es ist Professionalität. Ein Chirurg schaut sich die Röntgenbilder an bevor er operiert. Ein Entwickler schaut sich den Code an bevor er baut.

Was der Code Review liefert: - Verständnis der bestehenden Architektur - Identifikation von Risiken und Schwachstellen - Realistische Aufwandsschätzung - Entscheidung: Übernehmen, verbessern oder neu bauen?

Bei AI-generiertem Code ist der Review besonders wichtig, weil AI Tools Code erzeugen der funktioniert, aber oft technische Schulden mitbringt die nicht sofort sichtbar sind.

Checkpoint 1: Projektstruktur

Was der Entwickler prüft: Wie ist der Code organisiert? Gibt es eine klare Ordnerstruktur oder liegt alles in einem Haufen?

Was AI Tools oft machen: Alle Dateien in wenige große Ordner packen. Komponenten mit 500+ Zeilen die eigentlich 5 kleinere Komponenten sein sollten. Keine Trennung zwischen UI-Logik und Business-Logik.

Was der Profi will sehen: - Klare Ordner für Seiten, Komponenten, Utilities - Kleine Dateien die jeweils eine Aufgabe haben - Konsistente Namensgebung

Warum das wichtig ist: Eine gute Struktur bedeutet: Der Entwickler findet schnell was er sucht. Eine schlechte Struktur bedeutet: Jede Änderung ist wie eine Schatzsuche. Gute Struktur spart über die Projektlaufzeit Dutzende Stunden.

Checkpoint 2: Sicherheit

Was der Entwickler prüft: Kann jemand Unbefugtes auf Daten zugreifen?

Die 5 Sicherheits-Fragen: 1. Ist Row Level Security in Supabase aktiviert? 2. Liegt der Service Role Key nur auf dem Server (nicht im Frontend)? 3. Werden Nutzereingaben validiert? 4. Gibt es SQL-Injection- oder XSS-Schwachstellen? 5. Sind Passwort-Anforderungen gesetzt?

Was AI Tools oft vergessen: RLS-Policies sind das häufigste Problem. Die AI erstellt Tabellen, vergisst aber die Zugriffsregeln. Das bedeutet: Jeder eingeloggte Nutzer kann theoretisch die Daten aller anderen Nutzer lesen.

Warum das wichtig ist: Sicherheitslücken sind nicht „irgendwann” ein Problem. Sie sind sofort ein Problem — ab dem ersten Nutzer der echte Daten eingibt. Ein Profi schließt diese Lücken als Erstes.

Checkpoint 3: Datenbankstruktur

Was der Entwickler prüft: Wie sind die Tabellen aufgebaut? Gibt es Beziehungen zwischen Tabellen? Gibt es Indizes?

Was AI Tools oft machen: - Alles in eine große Tabelle packen statt sauber aufzuteilen - Keine Foreign Keys (Beziehungen zwischen Tabellen) - Keine Indizes (Datenbankabfragen werden langsam bei mehr Daten) - Redundante Daten (gleiche Information an mehreren Stellen)

Was der Profi will sehen: - Normalisierte Struktur (jede Information nur einmal gespeichert) - Foreign Keys für Beziehungen (Auftrag → Kunde → Mitarbeiter) - Indizes auf Spalten die häufig gesucht werden - Sinnvolle Datentypen (nicht alles als Text speichern)

Warum das wichtig ist: Die Datenbankstruktur bestimmt wie schnell deine App bei 100, 500 oder 1.000 Nutzern noch läuft. Eine schlecht strukturierte Datenbank wird bei Wachstum zum Flaschenhals.

Checkpoint 4: Authentication und Autorisierung

Was der Entwickler prüft: Funktioniert der Login sicher? Können Nutzer nur das tun was sie tun dürfen?

Der Unterschied (wichtig!): - Authentication = Wer bist du? (Login) - Autorisierung = Was darfst du? (Rechte)

Was AI Tools oft machen: Authentication funktioniert. Autorisierung fehlt. Jeder eingeloggte Nutzer kann alles — Admin-Funktionen, Daten anderer Nutzer, Einstellungen.

Was der Profi prüft: - Sind Sessions richtig konfiguriert? - Laufen Sessions nach Inaktivität ab? - Gibt es Nutzerrollen (Admin, User, Viewer)? - Sind Admin-Seiten vor normalen Nutzern geschützt? - Funktioniert Passwort-Reset sicher?

Warum das wichtig ist: Unsichere Authentication ist laut OWASP der häufigste Angriffsvektor. Ein Login der funktioniert ist nicht automatisch ein Login der sicher ist. Mehr dazu: Was AI Tools nicht lösen.

Checkpoint 5: Fehlerbehandlung

Was der Entwickler prüft: Was passiert wenn etwas schiefgeht?

Was AI Tools oft machen: Nichts. Wenn ein API-Call fehlschlägt, passiert im besten Fall nichts Sichtbares. Im schlechtesten Fall crasht die App und zeigt eine weiße Seite oder einen technischen Fehlercode.

Was der Profi will sehen: - Freundliche Fehlermeldungen für den Nutzer („Etwas ist schiefgegangen. Bitte versuche es erneut.”) - Technische Fehler werden geloggt (aber nicht dem Nutzer gezeigt) - Netzwerk-Fehler werden abgefangen (was wenn das Internet kurz weg ist?) - Loading-States (der Nutzer sieht dass etwas passiert)

Warum das wichtig ist: Nutzer verzeihen Fehler — wenn sie verstehen was passiert. Eine freundliche Fehlermeldung mit „Versuche es erneut” hält Nutzer. Eine weiße Seite verliert sie.

Checkpoint 6: Performance

Was der Entwickler prüft: Wie schnell lädt die App? Was passiert bei mehr Daten?

Typische Performance-Probleme bei AI-Prototypen: - Alle Daten werden auf einmal geladen (keine Pagination) - Bilder sind unkomprimiert (5 MB pro Bild statt 200 KB) - Keine Lazy Loading (alles wird geladen, auch was der Nutzer nicht sieht) - Datenbank-Abfragen ohne Indizes - Unnötige API-Calls (die gleichen Daten werden mehrfach geladen)

Was der Profi misst: - Ladezeit der Startseite (unter 3 Sekunden?) - Größe der übertragenen Daten - Anzahl der API-Calls pro Seitenaufruf - Verhalten bei 100+ Datensätzen in einer Tabelle

Warum das wichtig ist: Google-Studien zeigen dass 53% der mobilen Nutzer eine Seite verlassen die länger als 3 Sekunden lädt. Performance ist kein Luxus — es ist eine Notwendigkeit.

Checkpoint 7: Code-Duplikation

Was der Entwickler prüft: Wird der gleiche Code an mehreren Stellen wiederholt?

Was AI Tools systematisch machen: Die AI kennt den Kontext des aktuellen Prompts, aber nicht den gesamten Code. Wenn du die gleiche Funktion auf zwei verschiedenen Seiten brauchst, erstellt die AI sie zweimal. Und wenn du einen Bug fixst, fixst du ihn nur einmal — die Kopie bleibt kaputt.

Was der Profi tut: - Wiederholten Code in wiederverwendbare Funktionen auslagern - Gemeinsame Komponenten erstellen (Button, Modal, Formular) - Eine einzige Quelle der Wahrheit für jede Logik

Warum das wichtig ist: Duplikation ist die häufigste Ursache für inkonsistentes Verhalten. Wenn eine Berechnung an drei Stellen im Code steht und du eine davon änderst, sind die anderen zwei plötzlich falsch.

Checkpoint 8: Abhängigkeiten

Was der Entwickler prüft: Welche externen Bibliotheken nutzt die App? Sind sie aktuell und sicher?

Was AI Tools oft machen: Für jedes kleine Problem eine neue Bibliothek installieren. Nach 50 Prompts hat die App 80+ Abhängigkeiten — manche davon veraltet, manche mit bekannten Sicherheitslücken, manche die das Gleiche tun.

Was der Profi tut: - Unnötige Abhängigkeiten entfernen - Veraltete Bibliotheken aktualisieren - Bekannte Sicherheitslücken schließen - Alternativen prüfen (braucht man eine 200-KB-Bibliothek für eine Funktion die 5 Zeilen Code braucht?)

Warum das wichtig ist: Jede Abhängigkeit ist ein potenzielles Sicherheitsrisiko und ein Wartungsaufwand. Weniger Abhängigkeiten = weniger Angriffsfläche und einfachere Updates.

Was nach dem Code Review passiert

Der Entwickler erstellt typischerweise einen Bericht mit drei Kategorien:

Rot (Sofort beheben): - Sicherheitslücken (RLS fehlt, Keys exponiert) - Datenverlust-Risiken (kein Backup, kaputte Speicherlogik) - Kritische Bugs die Nutzer betreffen

Gelb (Vor Go-Live beheben): - Performance-Probleme - Fehlende Fehlerbehandlung - Code-Duplikation in kritischen Bereichen - Fehlende Autorisierung

Grün (Kann warten): - Code-Qualität verbessern - Abhängigkeiten aufräumen - Projektstruktur optimieren - Tests schreiben

Basierend auf diesem Bericht erstellt der Entwickler den Projektplan und das Angebot.

FAQ: Häufig gestellte Fragen

Muss ich beim Code Review dabei sein?

Nein. Der Code Review ist eine technische Aufgabe. Du bekommst danach eine verständliche Zusammenfassung. Ein guter Entwickler erklärt dir die Ergebnisse so, dass du sie verstehst — ohne Fachchinesisch.

Was wenn der Code Review zeigt dass alles schlecht ist?

Das ist normal bei AI-generiertem Code. Es bedeutet nicht, dass dein Prototyp wertlos ist — im Gegenteil. Der Prototyp hat bewiesen was funktioniert. Der Code Review zeigt was verbessert werden muss. Das ist der ganze Zweck.

Wie lange dauert ein Code Review?

Für einen typischen AI-Prototyp: 4–8 Stunden. Bei komplexeren Projekten: 1–2 Tage. Die meisten Entwickler bieten den initialen Review als Teil des Angebotsprozesses an — kostenlos oder gegen eine geringe Pauschale.

Kann ich den Code Review selbst machen?

Die technischen Checkpoints: Nein (es sei denn du bist Entwickler). Aber die Sicherheits-Basics kannst du selbst prüfen — RLS, API-Keys, HTTPS. Das ist besser als nichts und zeigt dem Entwickler dass du dich kümmerst.

Entscheidet der Code Review ob neu gebaut oder verbessert wird?

Ja — er ist die Basis für diese Entscheidung. Wenn die Grundstruktur solide ist: verbessern (günstiger, schneller). Wenn die Architektur fundamental falsch ist: neu bauen mit den Erkenntnissen aus dem Prototyp (sauberer, langfristig günstiger). Ein guter Entwickler empfiehlt immer den wirtschaftlichsten Weg.

Fazit: Der Code Review ist die Brücke zwischen Prototyp und Produkt

Ein Code Review ist keine Kritik an deiner Arbeit. Es ist der professionelle erste Schritt auf dem Weg vom Prototyp zum Produkt. Der Entwickler versteht was du gebaut hast, identifiziert was verbessert werden muss und erstellt einen Plan für die Professionalisierung.

Je besser du die Übergabe vorbereitet hast, desto schneller und günstiger wird dieser Prozess. Und das Ergebnis: Ein klarer Fahrplan von „funktionierender Prototyp” zu „production-ready Produkt.”

Willst du wissen was in deinem AI-Prototyp steckt — und was noch fehlt? Wir machen einen professionellen Code Review und sagen dir ehrlich was der nächste Schritt kostet.

Jetzt Code Review anfragen