A little about me.
I like understanding how systems work, especially when they stop behaving as expected.
I started with getting applications into service
My engineering career began in enterprise application delivery and infrastructure operations. I worked on environment preparation, deployment validation, release support, and troubleshooting. That work taught me to follow an application beyond its own process: the host it runs on, the network it uses, the configuration it expects, and the services it depends on.
I continued that work at SAP in Hungary, helping prepare production environments and bring applications into service. In 2018 I moved into a dedicated reliability and DevOps role. Over 13+ years, my work has grown from getting systems ready to run to taking responsibility for how they behave over time.
The work I do now
My current work at SAP SuccessFactors centres on end-to-end ownership of an operational analytics and reporting platform. I am responsible for reliability, automation, lifecycle management, modernization, and day-to-day technical decisions. The work continues after a change is delivered: I stay responsible for how the platform behaves over time.
I am also a technical escalation resource for difficult production investigations, following problems across application and infrastructure layers with other engineers. I enjoy the part where the symptoms do not yet form a clear explanation and we have to work out what to inspect next.
I have built investigation tooling for my team and designed a containerized Jenkins operating model using configuration as code and Git-backed job definitions. Earlier work included designing and building separate production health-validation tooling. That was a distinct project; my current operating responsibility is the broader analytics platform.
Owning a system makes the details matter. A useful investigation tool needs context, not just more output. A configuration needs to explain how to reconstruct an environment. Automation needs a failure path that another engineer can understand. Those are practical concerns in my work, rather than separate interests I pursue only on paper.
Learning a different workload
My independent AI work starts with running models locally. I use NVIDIA hardware and Apple Silicon, llama.cpp, Open WebUI, and local model APIs. My experiments also include Jan, model management, OpenCode and other coding agents, and MCP-compatible integrations. I configure runtimes and connect models to tools so I can learn how the pieces behave together.
I’m now extending that work toward more deliberate serving and reliability experiments. My production experience helps me frame the questions; learning the inference workload still requires hands-on work of its own. I'm also developing my understanding of Python, NumPy, PyTorch, and the fundamentals of model inference alongside the systems work.
I also work on independent trading-system software and strategy research. I treat the integration and operational questions separately from the research question of whether a candidate deserves further evaluation. I’m interested in what those projects teach me about data, orchestration, reproducibility, and controlling external actions.
What keeps me interested
I like following a problem across layers until I can explain it. Sometimes that means investigating a production failure. Sometimes it means rebuilding a piece of automation or finding out why a local model integration does not behave as expected. I want the result to be something another engineer can inspect, maintain, and question.
Senior reliability and platform engineering remain the centre of my professional work. AI infrastructure is a developing specialization that I’m building through experiments and integration work.