I work across the stack: backend LLM pipelines, structured data processing, retrieval, evaluation, and the React or TypeScript interfaces people actually use.
My strongest work sits in the middle of that process: turning unclear inputs into reliable systems, shaping generation steps, testing outputs, and making the final experience understandable.
With a background in Visual Computing, I also bring experience in image generation, video workflows, computer vision, and design-sensitive product work.
ORIGO turns rough restaurant or small-business inputs into structured brand direction: menu ingestion, positioning, visual language, generated assets, and a guided interface for moving from intake to usable outputs.
JPArt is a commercial platform for managing, presenting, and selling artwork. My work focuses on reducing publishing friction through image staging, AI-assisted content preparation, external API integrations, and SEO-focused frontend updates.
Raw PDFs in, structured courses out — hybrid semantic chunking, learning-objective induction and lesson generation, hardened by a synthetic benchmark with 3,435 automated eval runs.
Our LLM pipeline generates a recipe built to your body and taste — with an AI-made photo — benchmarked blind against a conventional recipe-database baseline.
A serve-analysis pipeline that turns uploaded tennis videos into pose keypoints, phase labels, annotated playback, and coaching feedback for posture and movement errors.
A custom 2D physics engine turned into a game: rigid-body collisions, mass-spring bridges, Voronoi fracture, debug rendering, and destructible playgrounds.
Open to AI, LLM, GenAI, and AI-automation engineering roles with teams shipping real systems. Based in Austria, targeting Switzerland, Austria, and London. EU citizen.
Educational PDFs are unstructured walls of text. Turning them into courses means finding where topics actually begin and end, deciding what a learner should take away, and writing the material — work that doesn't scale by hand.
A four-stage pipeline behind a React + FastAPI app: pre-processing (Docling with PyMuPDF fallback, pdfminer heuristics) turns PDF bytes into structured paragraphs; hybrid semantic chunking combines heuristic pre-chunking with GPT-4 boundary prediction and merge/split post-processing; LO induction groups chunks into learning objectives with a dual-provider design — LLM grouping vs. a seeded k-means baseline — so the approaches can be compared head-to-head; generation writes lessons and quizzes per objective, with free-text answers graded against reference content.
Instead of eyeballing outputs: a synthetic benchmark generates multi-topic PDFs with known gold boundaries, then measures precision, recall and F1 across six controlled experiments (document length, chunk count, section variability, topic similarity, formatting noise, post-processing) — 3,435 automated runs over 139K+ pages.
A working meal-recommendation web app: enter your body stats and taste, get a recipe built to fit. Under the hood it doubles as a study — every user is silently assigned either our LLM pipeline or a conventional recipe-database baseline, and rates what they get blind. That comparison became a paper at the IntRS'23 workshop (Plangger, Rainer, Felfernig).
Biometrics (age, weight, height, gender, activity) feed a real nutrition engine — BMR via the Harris-Benedict equations, scaled to TDEE by activity factor (×1.2 to ×1.9), then split into macros (45% carbs / 35% fat / 20% protein). Those numbers, plus liked/disliked ingredients and meal type, become a structured prompt.
To find out whether an LLM actually helps, the app runs two recommenders behind one interface and assigns each user a random one (50/50 on page load), so ratings can be compared blind.
A conventional recommender: query a fixed database of thousands of existing recipes and return the closest match to the user's calories and ingredients. Reliable, but bounded by what already exists — and its stock photos rarely match the exact dish.
Our own pipeline builds a structured prompt from the user's nutrition targets and taste, has GPT compose a brand-new recipe around exactly those constraints, returns it as strict JSON (the model was primed on valid examples so parsing stays reliable), then paints a matching dish with DALL·E 3 — because an invented meal has no photo to borrow.
Users rated the meals they were served 0–5 across four axes, not knowing which recommender produced them. Our pipeline won every category:
Biggest gap was ingredients (+18%) — the LLM's freedom to build around exactly what a user likes, rather than match the closest thing in a database, is the whole thesis in one bar.
DALL·E images were slow and stylistically inconsistent, and the ingredient picker needed a lot of scrolling on mobile. The paper lays out the roadmap it opened: weekly meal plans with shopping lists, cook-from-your-fridge photo input, and a conversational ordering mode.
Tennis Pose Analysis is an AI coaching assistant for amateur players. A user uploads a serve video, the system extracts body keypoints frame by frame, separates the serve into biomechanical phases, checks posture and movement indicators, then returns annotated video, structured JSON, and text feedback.
The computer-vision stage combines YOLO person detection with AlphaPose 2D keypoint extraction. Those keypoints are stored as structured frame-level data, then passed into temporal phase detection for start, loading, acceleration, contact, and finish. Each phase can be evaluated against the body positions that matter for that moment of the serve.
The evaluation layer uses joint angles and body alignment rules to decide whether a technical indicator was satisfied. If the correct movement appears in at least one frame within a phase, that phase can pass. Failed checks become feedback codes, which are translated into coaching notes and highlighted in the annotated output video.
My main contribution was the Flask-based web service and cloud workflow: upload endpoints, AWS S3 storage, presigned file access, file listing, and orchestration around the analysis pipeline. I also contributed to the phase detection and keypoint-evaluation logic. The result is closer to a complete coaching workflow than a standalone notebook.
Dino Demolition is a playable shell around the engine work: rigid bodies, SAT collision checks, spring constraints, spline-following objects, runtime debug layers, and rendering experiments all running in the same PixiJS scene. The point was not only to make a game, but to expose the simulation controls while it is running.
The renderer and simulation tick are controlled separately. FPS handles how often the scene is drawn; TPS handles how often the physics updates. Both can be adjusted live up to 60, which made it possible to test stability, slow down behavior, and debug simulation timing without changing code.
Objects can follow custom Catmull-Rom spline paths. The debug view exposes the curve, control points, and sampled path, while runtime controls adjust object speed so movement can be tuned in the scene instead of hard-coded.
The hanging bridges are built from connected spring elements rather than static platforms. Spring stiffness is modifiable at runtime, so the same bridge can behave tighter, looser, or be reset while the simulation is running.
Game objects use custom hitboxes rather than relying on sprite bounds. The green debug layer shows how platforms, barrels, planets, and dinos are represented for collision, feeding the custom rigid-body system and SAT checks.
Scene hierarchy objects can render trails, making parent-child transforms, orbital motion, and motion-blur experiments visible. The trails helped inspect how transformed objects move through the world over time.
