Engineering with AI
Diese Seite beschäftigt sich nicht mit Trends, Frameworks oder Buzzwords, sondern mit Engineering im praktischen Sinn. Systeme werden geplant, gebaut, betrieben, debuggt und verantwortet. AI kann dabei unterstützen, übernimmt aber niemals die Führung.
Bevor EpicCodeMakers entstand und noch vor dem Studium wurden eigene Unity-Projekte umgesetzt. In dieser Phase ging es nicht um Sichtbarkeit oder Außenwirkung, sondern um funktionierende Grundlagen. Systeme mussten stabil laufen, nicht erklärt werden.
Eigene Charaktere, erste Kreaturen, einfache Gameplay-Systeme und Leveldesign bildeten die Basis. Komplexität verschwindet nicht, nur weil man sie ignoriert. Werkzeuge können beschleunigen, ersetzen aber kein technisches Verständnis.
Ein früher Fokus lag auf Horror- und Survival-Szenarien. Raumführung, Lichtsetzung und Performance in Echtzeit waren feste technische Randbedingungen. Entscheidungen mussten bewusst getroffen und getragen werden.
EpicCodeMakers entstand parallel zum Studium als Arbeitsraum, um reale Probleme zu lösen. In dieser Zeit entstand DayCare Assistant. Die Software war nicht perfekt, aber stabil, wartbar und funktional. Genau das war entscheidend.
Mit Futura Contour folgte ein Projekt mit deutlich höherer Komplexität. Mehrere Systeme, Zustände und Schnittstellen griffen ineinander. Unterstützende Automatisierung war sinnvoll, ersetzte jedoch kein Verständnis für Abhängigkeiten.
Viele Probleme ließen sich nicht automatisiert lösen. Sie mussten eingegrenzt, analysiert und systematisch behoben werden. Werkzeuge unterstützen beim Denken, Verantwortung bleibt jedoch immer beim Entwickler.
Engineering ersetzt kein Verständnis.
Werkzeuge verstärken es oder machen dessen Fehlen sichtbar.
Das größte laufende Projekt ist Dark Continent. Physik, Bewegung, Level-Logik, Gameplay-Skripte und Build-Prozesse greifen hier untrennbar ineinander. Jede Änderung wirkt sich unmittelbar auf andere Systeme aus.
Dieses Projekt existiert nicht als Showcase, sondern als langfristiger Belastungstest für tragfähige Architekturentscheidungen. Erst unter realer Last zeigt sich, ob Engineering funktioniert.
AI ist ein Werkzeug. Ein starkes Werkzeug. Aber nur dann, wenn man selbst weiß, wie man es einsetzt.
Wer mit AI lernen will und Verantwortung übernimmt, wird Fortschritte machen. Ohne eigenes Verständnis bleibt der Einsatz von AI auf kurzfristige Ergebnisse beschränkt. Langfristige Qualität entsteht durch durchdachte Entscheidungen.
AI Voice Agent
Dieses Projekt ist kein Produkt und kein Showcase. Es ist ein kompakter Proof of Concept, bewusst am Stück umgesetzt, um einen sauberen Engineering Workflow unter realen Bedingungen zu zeigen. AI unterstützt dabei, übernimmt aber nicht die Führung.
Bei kleinen Projekten ist ein Repository oft nicht nötig. Da reicht die Übersicht im Kopf, plus saubere Backups. Das ist schneller und verhindert Overhead. Ein Repo wird dann sinnvoll, wenn Struktur, Nachvollziehbarkeit und stabile Meilensteine wichtiger werden als maximale Geschwindigkeit.
Genau so wurde hier gearbeitet: lokal schnell iterieren, aber in GitHub nur klare, größere Pushes als stabile Schritte. Kein Commit-Spam, keine sinnlosen Mini-Pushes im Minutentakt. GitHub bleibt Historie und Struktur, nicht ein Chatlog.
Proof of Concept
Ich habe das Projekt bewusst als 3-Tage-Challenge geplant. Nicht um möglichst viel zu bauen, sondern um einen vollständigen Ablauf einmal sauber durchzuziehen und Entscheidungen, Fehler und Fixes nachvollziehbar zu halten. Wer keine Lust hat, sich durch technische Details oder Repository-Struktur zu arbeiten, kann einfach die Videos anschauen. Dort ist alles in Reihenfolge dokumentiert.
Day 1
Am ersten Tag ging es nur um das Fundament. Ein minimaler Free Mode, der stabil läuft. Voice Input über SpeechRecognition, Voice Output über Browser TTS, dazu ein einfacher Flow mit klaren Zuständen. Kein Backend, keine Provider Logik, keine Extras. Erst wenn dieser Loop zuverlässig funktioniert, lohnt es sich, die Komplexität zu erhöhen.
Day 2
Am zweiten Tag ging es nicht um mehr Features, sondern um den Schritt von „läuft lokal im Browser“ zu „läuft sauber über eine Schnittstelle“. Der Pro Mode wurde über eine API Route angebunden, sodass die Antwortgenerierung austauschbar bleibt und lokal laufen kann. Wichtig war mir dabei die Trennung: UI und Flow bleiben stabil, der Provider ist nur ein austauschbares Modul. Erst wenn diese Grenze steht, kann man später erweitern, ohne das System jedes Mal neu zu verknoten.
Day 3
Am dritten Tag ging es um den Abschluss als Gesamtsystem. Input und Output wurden in beiden Modi end to end verbunden, sodass der Ablauf nicht nur technisch vorhanden ist, sondern im Alltag testbar wird. Entscheidend war hier das Zusammenspiel: Voice rein, stabile Verarbeitung im Flow, Antwort zurück, Ausgabe im UI und als Sprache. Pro bleibt dabei sauber über die API getrennt, aber fühlt sich im Verhalten genauso geschlossen an wie Free.
Abschluss
Am Ende steht ein stabiler Ablauf: Spracheingabe, Flow und Sprachausgabe im UI funktionieren zuverlässig. Dieses Projekt zeigt, wie man von einem einfachen Prototypen zu einem funktionierenden System kommt, ohne sich in unnötiger Komplexität zu verlieren.