AS

Software Engineer / UCLA Computer Science

Aansh
Singh.

Pragmatic, systems-minded | AI Engineering, Developer Tools & Distributed Systems | UCLA CS

Explore My Work Resume PDFGitHubLinkedIn
01 / Selected workSummer 2026

CodeGraph

Repository intelligence for AI-assisted software engineering.

What if an AI agent could understand a codebase before touching it?

Understanding unfamiliar code means finding the relevant files, tracing their relationships, and choosing what an agent needs to see.

CodeGraph connects repository structure, source inspection, and natural-language analysis so an agent can retrieve focused context.

From repository structure to focused context

  1. 01

    Files

    Repository-scoped source

  2. 02

    Functions

    Tree-sitter parsing

  3. 03

    Calls & dependencies

    Neo4j relationships

  4. 04

    Focused context

    Graph + vector retrieval

  5. 05

    Agent

    LangGraph ReAct

Files define functions. Calls connect them. Graph reasoning and vector search retrieve focused context for the agent.

Reported LLM context / per query

≈737Kto≈18K

tokens per query

LLM context reduction
97.5%

Supplied résumé result · supported-source tokens compared with tool-returned context.

Repository-scoped analysis

Structure, dependency, and architecture queries stay within the selected repository.

Source retrieval

Inspect source on demand through the application’s source lookup endpoint and code drawer.

Graph reasoning

Trace callers and dependencies, and explore architectural communities with Neo4j and Leiden clustering.

Vector search

Use OpenAI embeddings and Neo4j vector indexes to find semantically related functions.

7 repository-scoped tools

A Claude-powered LangGraph ReAct agent uses tools for structure, dependencies, blast radius, external calls, semantic search, and architecture analysis.

Built withReact / TypeScript · Python / FastAPI · Tree-sitter · Neo4j · LangGraph

Explore CodeGraph
02 / Selected workSummer 2026

TaskForge

Distributed task execution built around correctness, reliability, and concurrency.

What happens when thousands of tasks compete for the same workers?

TaskForge coordinates durable task admission, concurrent Go workers, retries, and crash recovery through PostgreSQL.

Coordination before execution

  1. 01

    Queue

    Durable tasks, ordered by priority

  2. 02

    Atomic claim

    FOR UPDATE SKIP LOCKED

  3. 03

    Workers

    Concurrent Go processes

  4. 04

    Leases & heartbeats

    Ownership and process liveness

  5. 05

    Completion / retry

    Persist results or schedule backoff

Alternative path / Retryable failure → backoff → due promotion → queue, within the attempt budget.

Workers skip locked tasks instead of competing for the same claim. Renewable leases guard ownership; heartbeats report liveness. Due retries return to the queue through the scheduler.

When a lease expires, the scheduler abandons the stale attempt and requeues eligible work within its attempt budget.

Conceptual coordination flow; worker symbols illustrate concurrency, not a benchmark configuration.

Atomic ownership

A PostgreSQL transaction locks a candidate, assigns ownership, and records its attempt before execution starts.

Priority scheduling

Workers claim due queued tasks by descending priority, then creation time and ID. Execution happens outside the claim transaction.

Retries & recovery

Retryable failures use exponential backoff. Guarded renewals and completion writes prevent stale owners from updating the task.

Operational visibility

Prometheus metrics and Grafana dashboards track throughput, latency, retries, lease recovery, and system health.

Measured under defined workloads

E1 / No-op workload

validated task executions
60,000

12 trials × 5,000 no-op tasks, across 1 / 4 / 8 / 16 workers. Persisted task and attempt counts reconciled with Prometheus.

E1 / No-op workload

tasks/sec median
≈1,284

Four workers: the highest tested median for this no-op workload (1,284.015 tasks/sec). Three independently reset blocks.

E2 / Synthetic waits

parallel efficiency
99%

Synthetic 50ms waits, scaling from 1 to 16 workers. 12 trials and 12,000 tasks; 15.84× measured speedup at 16 workers.

Recorded environment: Apple M4 Pro · 12 logical CPUs · 24 GiB RAM · local Docker.

These are controlled local results. Throughput and efficiency depend on the workload and resources; they are not production capacity guarantees.

Built withGo · PostgreSQL · Docker Compose · Prometheus · Grafana

Explore TaskForge

03 / About & journey

Curiosity, put to work.

I’m Aansh, a computer science student at UCLA. My work spans developer tooling, reliable backend systems, and underwater robotics. I enjoy connecting the details of implementation to a clear, useful experience.

Bachelor of Science in Computer Science
University of California, Los Angeles
Expected graduation · June 2029

  1. Sept 2025–Present

    Bruin Underwater Robotics · UCLA

    Software Engineer

    Developing perception models and integrating onboard computing for autonomous underwater robotics.

  2. May 2024–Sept 2025

    D-Tech

    Software Engineering Team Lead Intern

    Led five interns designing Flippper, translating requirements into workflows, interfaces, and prototypes.

  3. May 2024–Jan 2025

    CompuChild

    Instructor

    Taught Python and Scratch through hands-on projects and helped students debug code and devices.

04 / Contact

Let’s build something useful.

Have a project or an idea to discuss? Get in touch.