Graded on what the database did
Logical reads are what a DBA tunes for on a shared server. In one batch, the two "obvious" join indexes made the query almost 4× more expensive than adding no indexes at all, while the execution plan looked better.
Senior Solutions Architect for enterprise software, cloud-native platforms, and RL environments for LLM post-training.
I've spent 20+ years delivering enterprise software end to end: Java and Oracle performance, Kubernetes and OpenShift, security and compliance. I work out what the customer actually needs, then build it in their stack. I now also build verifiable-reward RL environments that train coding agents on real database performance work.
Most RL environments for coding agents check whether the agent produced the right answer. Mine check something harder. The agent gets a slow SQL query, its own copy of the database and a shell, and has to tune the query.
It is scored on logical reads: how many database pages the query really touches. Not wall-clock time, which mostly measures the machine. Not how clean the execution plan looks, which is what the engine intends to do, not what it does.
The task sits where an environment is useful for training: frontier models succeed sometimes, but not reliably.
Scored on logical reads. Original query: 11,238 pages. Reference solution: 115 pages.
Logical reads are what a DBA tunes for on a shared server. In one batch, the two "obvious" join indexes made the query almost 4× more expensive than adding no indexes at all, while the execution plan looked better.
The reward is monotonic: every page saved raises the score, so a model gets a learning signal instead of a pass/fail cliff. Scores spread from 0.24 to 1.0, and the same submission always gets the same score.
Grading happens in a clean room on a fresh copy of the database, so shortcuts that lower the page count without tuning anything don't pay. Every rule the prompt states, the grader enforces.
Built on Prime Intellect's verifiers framework, running in a pinned, offline-capable Docker image. SQLite keeps the demo small and self-contained, but nothing in the approach is SQLite-specific. PostgreSQL and Oracle are next.
Contract and project work, remote from Austria with daily overlap with US Eastern Time. I start from the problem, then pick the technology.
Enterprise systems from requirements to production, primarily in Java/Spring and Java EE, with Go or Python where they fit. I also take technical leadership of the delivery.
Oracle, PL/SQL and SQL tuning. I've taken queries and programs from minutes to seconds, and migrated legacy Oracle Forms to modern web stacks.
Software built for Kubernetes and OpenShift, including a Red Hat-certified resilience-testing product. CI/CD on Jenkins and CircleCI, deployments on GCP.
Secure SDLC, code reviews and penetration testing, backed by six years as ISMS lead for the university management system developed at Graz University of Technology, and an MSc in security engineering.
Bug fixes, performance improvements and test coverage across major Java ecosystems. More on GitHub.
Need RL environments for database or performance engineering, an architect for a hard problem, or a slow database fixed? Email is the fastest way to reach me. I usually reply within a day.
Also open to full-time remote roles with US teams.