I build AI and ML systems at Audi in Munich, on top of fourteen years spent running the infrastructure underneath them. Before this: DevOps and SRE at IABG, Infineon, Wipro and Thomson Reuters, and a long stretch of Linux administration before that.
GitHub LinkedIn krishnagove88@gmail.com
Fourteen years, six companies, and the code below ↓
Most of my career has been on the operations side: Linux across a few hundred nodes, CI/CD pipelines, Kubernetes, and the pager. The last few years I have been building AI systems instead, and the two turn out to be the same job. A RAG pipeline that works in a notebook and a service that survives a Tuesday afternoon are very different pieces of software.
So what I am useful for is the part after the demo. Where does this break, what does it cost, how will we know when it goes wrong, and what happens at 3am. At Audi that currently means AWS infrastructure, MLOps pipelines, and LLM automation that people other than me depend on.
I studied Business Analytics and Data Science at EU Business School in Munich alongside the work, and I was a top finalist in the AWS Agentic AI Hackathon.
Earlier: System Engineer at Tech Mahindra (2014 to 2015), Desktop Engineer at Zensar Technologies (2011 to 2013).
Side projects, all public. Each one runs with a single command, ships a test suite that runs in CI, and shows real output in its README. The READMEs also say where each design stops working, because that is usually the more useful half.
Ad decisioning inside a latency budget: targeting, pacing, frequency caps, budget. Answers in about a millisecond, and the README measures the point where that stops being true.
Node.js · TypeScript · PostgreSQL · Docker · 93 tests
An OAuth2 server: PKCE, refresh token rotation with reuse detection, RS256 with a published JWKS. Every security rule has a test that carries out the attack it stops.
Node.js · TypeScript · PostgreSQL · 144 tests
Feature flags with sticky percentage rollouts and attribute targeting, plus a React admin UI. Bucketing hashes the flag key with the user, so one unlucky user does not land in every experiment at once.
Node.js · TypeScript · React · PostgreSQL · 85 tests
Scores an LLM agent on how it behaved, not just what it answered: tool choice, forbidden tools, redundant steps, budget.
Python · Agent evaluation
Error budget, burn rate, and multi-window paging from the Google SRE workbook. Answers whether to wake someone, rather than what the availability number is.
Python · SRE
Right-sizes CPU and memory requests from real usage, and flags throttling and OOM risk before they find you.
Python · Kubernetes
The rest are on GitHub, including LLM observability, semantic caching, RAG, and prompt-injection work.
slo-error-budget, because it is the shortest thing to read. "We are at 99.9% availability" does not tell you whether to wake anyone up.
$ make demo 30-day error budget: { "slo": 0.999, "sli": 0.9995, "budget_consumed": 0.5, "budget_remaining": 0.5, "burn_rate": 0.5, "hours_to_exhaustion": 720.0, "healthy": true } spike burn rates short=30.0x long=15.0x -> alert: page
Half the budget is gone, so at this rate it lasts another 720 hours. Then a spike burns 30x over five minutes and 15x over the hour. Both windows are hot, so it pages. A five second blip would not, which is the entire point.
If you are working on production AI, platform engineering, or the unglamorous infrastructure that holds either of them up, I am happy to talk. The fastest way to reach me is krishnagove88@gmail.com, and I am on LinkedIn.