01Unabhängiges KI-Coding-Agent-Setup

Ylli Kolgeci · Applikationsentwickler
Ich entwickle Webanwendungen, Automationen und KI-Workflows. Hier zeige ich ausgewählte Arbeiten von der Planung bis zum Test.
Case Study ansehen↗Ausgewählte Projekte
03 / 06
01Unabhängiges KI-Coding-Agent-Setup
02Dark Web · Recherche zu Datenlecks
03macOS-Dateibrowser
01↗Unabhängiges KI-Coding-Agent-Setup
Ein portables Pi-Setup mit GLM 5.2 als praxistaugliches Backup zu geschlossenen Coding-Agent-Anbietern.
August 2026
02↗Dark Web · Recherche zu Datenlecks
Mein Auftrag war, IntelliLab in irgendeiner Form im Dark Web zu finden, besonders Informationen, die dort nicht öffentlich sein sollten. Dafür durchsuchte ich Foren, Listen mit Leaks und Hinweise auf Datenpannen systematisch.
Oktober 2026
03↗macOS-Dateibrowser
Folder ist ein nativer Dateibrowser für macOS, entwickelt mit Swift. Ich übernahm die bestehende App bei v1.1.4 und arbeitete an Oberfläche, Dateiaktionen, Suche und Sortierung. Als in neuen Releases immer wieder Fehler gemeldet wurden, entwickelte ich einen wiederholbaren Testplan.
September 2026
04↗Trainingsprojekt · KI-Bestellchatbot
Ein getesteter KI-Bestellchatbot für die fiktive Pizzeria Pizza Bella. Er beantwortet Restaurantfragen, arbeitet mit Kundendaten und unterstützt Bestellungen, Änderungen und Stornierungen über einen n8n-Workflow.
August 2026Demnächst
Demnächst
Demnächst
Demnächst
Ein Bestellsystem als Embedded Chat
Ziel war es, einen zuverlässigen Chatbot für eine Pizzeria zu planen, zu entwickeln, zu testen und vorzustellen.
Wähle dein Betriebssystem und kopiere den passenden Installationsbefehl.
Pizza Bella ist fiktiv, die Situation aber realistisch: Restaurant-Mitarbeiter bearbeiten wiederkehrende Fragen und einfache Bestellaufgaben. Das Projekt wurde rund um diese Bedürfnisse und kontrollierte Bestellprozesse geplant.
Ziel: Routinefragen, Bestellungen und Bestellstatus unterstützen.
Daten: Menü, Kundendaten, Lieferadressen und Allergien kommen aus der Datenbank.
Sicherheit: nur Restaurantthemen; Bestellungen brauchen vollständige Angaben und eine klare Bestätigung.

Meine erste Workflow-Skizze war zu kompliziert. Lange Verbindungen und Loops machten sie langsam, unübersichtlich und weniger stabil. Am schwierigsten war der Agent mit seinen Tools und dem Systemprompt: Er sollte Kunden helfen können, durfte aber keine Kundendaten ausgeben, keine Restaurantinformationen erfinden und keine Bestellung ohne klare Bestätigung auslösen.
Erste Skizze: zu viele Verbindungen und Loops, langsam und instabil.
Agent: genug Freiheit zum Helfen, aber keine freien Antworten oder Datenlecks.
Architektur: mehrmals umgebaut, bis der Ablauf klarer und sicherer war.

Das Projekt hat mir gezeigt, warum aus einer guten Idee noch kein zuverlässiger Agent wird: Es braucht klare Anweisungen, verlässliche Daten und einen geschützten Ablauf.
Eindeutige Anweisungen: Der System Prompt legt Rolle, Prioritäten und Reihenfolge präzise fest.
Klarer Rahmen: Nur Restaurantthemen; bei fehlenden Informationen wird nachgefragt statt erfunden.
Schutz: Eine Bestellung wird nie ohne Bestätigung ausgelöst, und Kundendaten bleiben geschützt.
Verlässliche Daten: Antworten stützen sich auf aktuelle, strukturierte Quellen aus der Datenbank.

Der finale Workflow verbindet den eingebetteten Chat, einen KI-Agenten und die benötigten Services in n8n. Jede Anfrage folgt einem klaren Weg vom ersten System-Check bis zur finalen Antwort, mit Guardrails, die die Antworten fokussieren und interne Informationen schützen.
Start: Ein Datenbank-Check bestätigt, dass das System bereit ist, bevor der Agent antwortet.
Agent: DeepSeek, Memory und PostgreSQL-Tools rufen Produkte, Kundendaten und Bestellinformationen ab.
Guardrails: Allergien, Bestätigungen und Antwortprüfungen schützen Kunden- und interne Daten.
Ergebnis: ein klarer, sicherer Weg von der Anfrage zur Antwort statt freier Antworten.

Klare Datenquellen und kleine, fokussierte Tools machten die Antworten zuverlässig. Wiederkehrende Fragen wurden konsistent behandelt, wiederkehrende Kunden erkannt und Bestellentwürfe aus echten Datenbankeinträgen gebaut.
Wiederkehrende Restaurantfragen konsistent aus der Datenbank beantwortet.
Wiederkehrende Kunden erkannt; Bestellentwürfe aus echten Daten gebaut.
Allergie-Prüfung zuverlässig als Teil des Bestell-Flows.
Systemstatus: bereit
Anfangs neigte der Agent zu freien Antworten und die erste Skizze war instabil. Am schwierigsten war die Balance zwischen Hilfsbereitschaft und Kontrolle: Kundendaten brauchten explizite, durchgesetzte Regeln, Sonderfälle wie Allergien und Stornierungen brauchten extra Sorgfalt, und Guardrails mussten schützen, ohne im Weg zu stehen.
Balance: genug Freiheit zum Helfen, genug Kontrolle für Sicherheit.
Kundendaten-Schutz brauchte explizite, durchgesetzte Regeln.
Sonderfälle wie Allergien, fehlende Daten und Stornierungen brauchten extra Sorgfalt.
Die erste Skizze war instabil; Bestellungen ohne Bestätigung mussten blockiert werden.
Nächster Durchlauf
Der Prototyp wurde mit normalen Anfragen, Sonderfällen und strukturierten Szenarien getestet. Wenn Informationen fehlten, sollte der Chatbot nachfragen, statt eine Antwort zu erfinden.
Restaurantwissen: Menü, Preise, Zutaten, Verfügbarkeit und Ernährungsanforderungen wurden mit der Datenbank geprüft.
Bestellungen & Sicherheit: Fehlende Daten, Kundenidentifikation, Allergien, Änderungen und Stornierungen wurden getestet.
Wiederholbare Prüfung: 100 Szenarien mit 10 Personas bestanden die zusätzliche Auswertung.

Der fertige Prototyp wurde dokumentiert und als transparentes Portfolio-Projekt vorgestellt. Er zeigt, was der Agent kann und wo bewusst Grenzen bleiben.
Dokumentiert: Architektur, Tools, Datenbank-Check, Allergie-Flow, E-Mail-Flow und Guardrails.
Ergebnis: ein getesteter Prototyp für Restaurantfragen, Bestellentwürfe, Änderungen und Stornierungen.
Umfang: Finale Live-Bestellungen und E-Mails wurden während der Chat-Tests bewusst nicht ausgelöst.

Ein leistungsfähiges Modell reicht nicht. Zuverlässige Agenten brauchen klare Datenquellen, fokussierte Tools, eindeutige Bestätigungen und Guardrails.
Klare Anweisungen, verlässliche Daten und wiederholtes Testing machten die Idee zum kontrollierten Prototyp.
Die Arbeit wird ehrlich als getesteter Prototyp vorgestellt, nicht als Live-Produkt.
Finale Live-Bestellungen und E-Mails wurden im Chat bewusst nicht ausgelöst.