End of year one at university. Working at an NLP company.
Building local-first tools where language models do structured work —
desktop apps that actually run, store, and process something useful.
The pattern I keep coming back to: messy input → structured AI processing → persistent, useful output. Not a chatbot wrapper, not a demo — tools that actually transform and organize things. Local storage, real UI, structured LLM calls.
First-year student. Up to date tools. Real outputs.
Not polished demos. Not tutorial projects. Real tools I built because they needed to exist — each one a version of a question I was trying to answer by building.
Support teams still read every message manually and decide what to do with it. It's the kind of work that drains people fast and doesn't really need a human at the front. So I built a console that takes incoming messages, classifies them with an LLM, assigns urgency, calculates SLA deadlines, and creates structured tickets directly in HubSpot — with a rule-based fallback when the model isn't confident. Local-first, real CRM connected, not a demo.
The first project where I felt the shape of real internal tooling. AI handles the routine, humans only see the edge cases. That ratio is what good automation looks like.
Job alerts come in scattered across email, the actual description is buried in snippets, and researching each one by hand takes forever. I built a local-first pipeline that pulls Gmail alerts via OAuth, extracts structured leads with heuristics plus an AI fallback for messy formats, optionally finds the original posting on the open web, and runs analysis for skills, fit, and source quality. Everything stored locally in SQLite with a Saved / Applied / Ignored decision dashboard.
Built it while actively job-searching. The friction was immediate and personal — which is exactly when you build the best tools.
Every time I opened an unfamiliar codebase I wasted time just figuring out what it was. So I built a desktop app that imports any local project folder, scans it with sensible ignore rules, sends a capped snapshot to the Claude API, and stores a structured explanation in a personal SQLite library. Built local-first so nothing leaves your machine except the API call itself — and I had to learn how to keep LLM inputs properly bounded for the system to stay reliable.
The project where I got serious about Rust and the constraints of working with LLMs. Token caps and validated outputs aren't a detail — they're the whole game.
These aren't research topics. They're the questions that keep surfacing — when I build, when I read, when I watch a system fail in a deeply human way.
Studying Menschzentrierte Informatik & Psychologie at Universität Duisburg-Essen. Currently working at an NLP company — building tools in the LLM space alongside the degree. Working with Tauri, Rust, React, Python, and LLM APIs across projects, and actively looking for a Werkstudentenstelle in LLM systems, automation, workflow tooling, or applied NLP.
I'm interested in research collaborations, student roles in AI workflows and automation, and conversations with people building things that take humans seriously.
zaraselim04@gmail.com