ai4se researcher · software engineer

I build AI that earns developer trust.

Researcher at JetBrains Research and MSc student at TU Delft. I work across large language models, developer tooling, and human-AI interaction.

Portrait of Roham Koohestani
RK · Den Haag, NL
// scroll to trace the history ↓

// now · the through line

Three questions drive the work.

One thread runs through everything I have built: how do we make AI assistance in software engineering something a developer can rely on, and prove that it is.

question 01

What do developers need?

The empirical side. What makes a developer trust or reject an AI suggestion, and when does model confidence matter at all.

question 02

What can we guarantee?

The formal side. What assurances hold for systems that are stochastic by design, from single models to multi-agent pipelines.

question 03

Does it ship?

The impact side. Validation inside real IDEs at production scale, not on toy benchmarks.

// 2025 · jetbrains research

Research at production scale.

As a research intern at JetBrains, I asked a direct question: can a model's confidence tell a developer when to trust its code. The answer was not simple. Post-hoc calibration sharpens the signal, but a model's confidence is not the same thing as a developer's acceptance.

0 real-world IDE interactions analyzed, across 750,000+ devices and three languages
acceptance model confidence calibrated perfect uncalibrated

Calibration reduces overconfidence, yet acceptance depends on human factors beyond correctness. Developers preferred color-coded reliability cues over raw probabilities.

// 2025 · a bet placed early

When agents multiplied, I asked what breaks first.

My answer was safety. AgentGuard, my first single-author paper, argued for verifying agents at runtime rather than trusting them by default. It builds a probabilistic model of an agent's behavior from its execution traces and checks quantitative properties against it. That question grew into a research line: an automated abstraction mechanism (TriCEGAR) and a formal theory of what an agent can be once you constrain its memory.

plan collect fix verify

Dynamic Probabilistic Assurance: the question shifts from "will it fail?" to "what is the probability of failure within these constraints?"

// 2025 · the long one

If the ruler is wrong, every measurement is.

A review of 273 benchmarks for AI in software engineering, a semantic search tool to navigate them (BenchScout), and a protocol for repairing the ones the field still relies on (BenchFrame). When we rebuilt HumanEval with correct solutions and real edge cases, the leaderboard collapsed.

−31% average pass@1 drop across models once the benchmark is repaired
pass@1 (CodeQwen1.5-7B)
original 87.2%
repaired 11.0%

One example: a top performer, CodeQwen1.5-7B, fell 76 points on the repaired benchmark, a signature of leakage rather than capability.

// 2024 · learning the craft

Where the research habit formed.

I joined the AISE Lab under Prof. Maliheh Izadi and started where curiosity pointed: hyperdimensional computing as a lightweight way to model how developers behave inside an IDE. Two early papers, a lot of freedom. My first paper, on making automatically generated unit tests understandable, landed at ICSE 2025. The idea was simple: a test only helps if a person can read it.

// generated by a search-based tool
void test0() { ... }

// after UTGen: named for what it verifies
void testEqualsWithDifferentMinDamageValues() {
  // given / when / then, in plain terms
  Weapon sword = new Weapon("sword", 12);
  ...
}

In a controlled study, developers fixed up to 33% more bugs and spent up to 20% less time with the enhanced tests.

// 2023 · the groundwork

A degree, and a question about memory.

A BSc in Computer Science and Engineering at TU Delft (2023–2026), with a mathematics minor at the University of Amsterdam for the theory I kept reaching for. My bachelor thesis asked whether you can tell if a code model was trained on a given file. You often can, and the signal survives even after the code is refactored. The trick was to perturb code along its syntax tree instead of its raw tokens, so the calibration samples stay valid.

AST-guided perturbation: provenance survives refactoring. Published at FSE Companion 2026.

// 2022 · where it started

Structure out of noise.

It began at Syntho, first as a high-school intern and then as a software engineer, working on synthetic data and fairness. Designing methods to generate data that is useful without being harmful is where building and researching stopped being two separate activities for me. Everything after this is a variation on the same instinct: understand a system well enough to make it better.

// away from the screen

The rest of it.

I sing and play music, I train and dance bachata, and I cook. I move between three languages depending on the room. The through line is the same as the work: I like understanding how something functions well enough to improve it.

musicgymbachatacooking فارسیenglishnederlands

// contact

Let us build something.

If you work on language models for code, developer-AI interaction, or agentic systems, I would like to hear from you.