Advait Pandey

Point of view

I like debugging systems when the failure is real but the cause is not obvious. That has meant chasing stuck Kubernetes deletions, flaky tests, and slow C++ paths until the logs or profiles finally explain what happened.

I have also been working lower in the AI stack: simulating transformer hardware and adding compiler support for running models on AMD GPUs. I enjoy the part where an idea has to survive a benchmark, a trace, or a failing test.

Currently

Right now I am turning a memory-reclamation theory into controlled experiments and building Obelisk around an explicit boundary between coordination and execution.

Languages: Go, C++, C, Python, C#, TypeScript, SQL, Bash, Verilog

Infrastructure: Kubernetes, OpenShift, Advanced Cluster Management, Docker, Kubebuilder, controller-runtime, Linux

AI systems: Transformer inference, attention and KV-cache modeling, accelerator simulation, MLIR, IREE, AMD ROCm

Systems: Distributed systems, reconciliation loops, finalizers, owner references, fault injection, Raft, HTTP, DNS, TCP

Tooling: Prometheus, perf, flame graphs, REST, PostgreSQL, SQL Server, Git, GitHub Actions

Case files

Red Hat · Project Glasswing [NDA]

The state transition nobody recorded

flagship

A deletion request is only the beginning. Controllers, finalizers, ownership, and garbage collection still have to agree on what “gone” means.

01delete requested
02controller observes
03finalizer blocks
04owner chain inspected
05cleanup verified

Evidence inspected

Controller logs and resource-state transitions
Finalizers and owner references
Garbage-collection behavior
Deletion sequencing across asynchronous cleanup

Intervention

Traced the recurring edge case through the complete deletion sequence, fixed the failure path, and made teardown state easier to inspect.

Root-cause investigation time−15%

Selected work

May 2026 – Aug 2026 · 4 mos

Flaky validation−45%

Red Hat

Software Engineer Intern

Flagship contributionProject Glasswing [NDA]

Project Glasswing [NDA] · OpenShift multicluster lifecycle management, AI orchestration, validation, and failure recovery.

GoPythonBashKubernetesOpenShiftACM

Dec 2025 – Aug 2026 · 9 mos

Microbenchmark+8%

Charter Communications

Software Engineer Intern

Internal tooling for the case-management platform used across support operations.

JavaReactRESTSQL ServerC++Raft

All work

Selected projects

01Collaborative infrastructure · In development

Obelisk

An in-development workspace for teams using AI agents on real engineering work. Obelisk keeps the request, proposed change, approval, execution result, and audit history together so people do not have to pass credentials or critical context through chat.

How can a team work quickly with AI agents without losing review, accountability, or control?

collaborative systemsAI agentsapproval workflowssecure executionauditability

02AI systems · Transformer inference

Transformer Accelerator Simulator

A cycle-accurate CPU and accelerator simulator for GPT-style forward passes, including systolic-array matrix multiplication, attention execution, SRAM/HBM transfers, and configurable tiling. Roofline and trace-driven analysis exposed the shift from compute-bound to memory-bound execution beyond 2K-token sequences.

At what context length does moving transformer state cost more than computing on it?

HBM traffic at 8K: 3.2× reduction
Throughput at 8K: 1.8×
A100 estimate error: ≤12%

PythonC++computer architecturetransformer inferenceFlashAttention-2

03AI compilers · Open source

Multi-Backend Transformer Compiler

An upstream MLIR lowering path for BERT-class transformer execution on AMD ROCm through IREE. The work fused LayerNorm–Dropout–Residual Add sequences, added cross-backend numerical validation, and extended end-to-end CI while collaborating with four maintainers across 12 pull requests.

How much transformer overhead can disappear when the compiler sees across operator boundaries?