← All speakers

Bio, Work & Ideas

Ara Khan

Conference affiliation: Cline · 2026

Ara Khan is an AI engineer at Cline, building and evaluating open-source coding agents and exploring how open-weight models can make sophisticated developer tools more affordable. His central challenge is making agents reliable across real software projects, different model providers, and the messy infrastructure surrounding both.

Khan, also known as Arafat, studied at the Indian Institute of Technology, Kharagpur, and worked at Shopify and Sourcegraph across backend development, infrastructure, developer-facing engineering, and AI-assisted programming. His independent projects include DataViz, a Go-based data-structure visualization tool; glot, a Go plotting library built on gnuplot; and slearn, an earlier supervised-machine-learning project in Ruby.

At Cline, he has pushed back on elaborate multi-agent hierarchies, indiscriminate retrieval over indexed codebases, and oversized system prompts. His critique of agent-building traps favors direct code search, clear instructions, and architectural complexity introduced only when it solves a demonstrated problem.

Four ideas shaping his work

  • Real-world coding-agent evaluation: Khan argues that leaderboard scores and subjective impressions both misrepresent agent quality. Effective tests require unfamiliar repositories, realistic setup, multistep debugging, executable checks, and safeguards against regressions. His analysis of flawed but necessary evaluations emphasizes that outcomes reflect the model, agent harness, task design, CPU and memory limits, timeouts, and isolated execution environments. He has described developing tasks from consented user workflows and using Terminal-Bench to investigate practical infrastructure failures and race conditions.
  • Hill climbing and recursive improvement: Khan treats failed execution traces as maps of fixable weaknesses in tools, prompts, model integration, and infrastructure. His guide to hill climbing describes raising one Terminal-Bench result from 47% to 57% through targeted changes. His work on recursive coding-agent optimization extends the loop: an agent modifies its harness, reruns evaluations, and iterates against measurable outcomes. He distinguishes useful engineering improvements from benchmark overfitting.
  • Open-weight inference economics: Khan evaluates self-hosting through workload-specific measurements of GPU memory, batching, throughput, caching, provider pricing, and service requirements. His analysis of model-serving costs argues that deployment decisions depend on actual traffic and infrastructure constraints, while a public post on open-weight deployment connects self-hosting with data autonomy and reduced provider dependence.
  • Human-supervised agent orchestration: Khan models agents as understandable state machines and favors CLI-first testing, clear repository instructions, dependable CI/CD, and isolated cloud execution. His framework for agent maturity proposes Kanban-style supervision of parallel tasks, with explicit transitions when agents need human input or review. He also warns that incompatible reasoning-trace formats across frontier-model APIs can quietly degrade performance and increase vendor lock-in.

For Khan, faster code generation only matters when paired with realistic evaluation, deliberate architecture, transparent operating costs, and human accountability for the result.

Read the topics behind these talks

2 conference talks

Key ideas

Scroll to read ↓

Build a useful agent by testing the idea quickly, making its execution understandable, coordinating concurrent work, and moving long-running tasks into shared cloud environments.

  • Should you run fifteen agents or read every line?
    0:29 ↗
  • Use a framework to test the idea
    3:00 ↗
  • Rule one: know which state the agent is in
    4:17 ↗
  • Rule two: every addition can make the agent worse
    5:55 ↗
  • Rule three: let other agents build and test yours
    7:19 ↗
  • Rule four: spend human attention on architecture
    8:45 ↗
  • Rule five: preserve each provider's API semantics
    9:47 ↗
  • Coordinate concurrent work through Kanban
    11:09 ↗
  • Move the environment off each user's machine
    13:11 ↗
  • Send a UX task, then let implementation and QA iterate
    14:26 ↗
  • Share the setup, but start with the minimum
    15:32 ↗
  • Planning still happens inside the task
    17:16 ↗

Key ideas

Scroll to read ↓

Similar benchmark scores can hide very different agents. Useful evaluation connects realistic tasks, isolated runs and failure traces to improvements that survive actual product use.

  • When the same score does not mean the same model
    1:42 ↗
  • Use external scores to decide what to investigate
    3:37 ↗
  • From intuition to tasks users actually perform
    6:24 ↗
  • Grade the repair, not just the answer
    8:55 ↗
  • Give every task a complete, isolated environment
    10:11 ↗
  • Run the isolated tasks concurrently
    11:59 ↗
  • Turn failed runs into a repair queue
    12:58 ↗
  • Resources and reasoning both change the outcome
    14:51 ↗
  • Improve the agent without fitting it to the test
    15:38 ↗
  • Keep the score and the product experience together
    16:58 ↗

References