About 01/26 Shuvam Pandey Software engineer / systems, tooling, and verification

Search

Search work, writing, and fragments.

about

A little context behind the work.

I like software that is easy to use, hard to break, and still understandable after the first rush of shipping is over.

story

I study computer engineering, but most of my learning has come from projects that stopped being simple the moment someone else had to depend on them. I like that turn: when a neat idea becomes a tired student trying to find the right paper, a protocol mismatch that needs a replayable fixture, or a small kernel fix that has to survive people who know the subsystem better than I do.

The work I care about has to be clear at the surface and honest underneath. A tool should feel direct to the person using it, but the internals should leave a trail too: named failure modes, careful boundaries, and decisions that still make sense after the first rush of shipping is gone.

That is why upstream work matters to me. It removes some of the private mythology around a patch: the reasoning either survives public review, or it shows me exactly where it has to get sharper.

  • work I choose Product software, protocol tooling, and verification-heavy systems where correctness changes the result.
  • working style Start with the real use case, name the failure modes, and keep the implementation small enough to inspect.
  • looking for Developer infrastructure, product systems, and correctness-heavy software with real users and real constraints.

principles

  • Name the failure mode before decorating the solution.
  • If a system asks for trust, make the boundary inspectable.
  • Prefer small, reviewable changes over clever machinery.
  • Choose work that teaches judgment, not just speed.

What I want to work on

  • Systems where the engineering has to be solid because people actually rely on it.
  • Tools that get out of the way and make a hard workflow feel simple.
  • Environments that force me to understand the layers beneath the code I write.

recognition

Recognition belongs here only when it points back to the work: a real problem, a constrained build, and enough public evidence to inspect what happened.

selected recognition

HackForUHC / 2026

1st place at HackForUHC 2026.

As team CLAIM∅, we won 1st place at HackForUHC 2026, held June 18-19, 2026. Following the win, we were invited to participate and presented our solution at the 10th anniversary openIMIS Community Meeting in Kathmandu (June 23-25, 2026).

  • result 1st place, overall hackathon
  • team CLAIM∅
  • presentation 10th anniversary openIMIS Community Meeting, Kathmandu

selected recognition

JunctionX Kathmandu / 2026

JunctionX Kathmandu 2026 with Team Pikachu.

As team Pikachu, we worked on a constrained build around a local energy problem at JunctionX Kathmandu 2026. The result opened the next round of work in Finland, but what belongs here just as much is the support around it: the mentors, organizers, teammates, and KU community who made the work possible.

  • result Overall Winner + Hydropower & Sustainable Energy Track Winner
  • team Pikachu
  • next Golden Ticket to the global Junction stage in Finland

selected recognition

Google TMT Hackathon / 2026

1st place in the File Translation Tool Track with SANAD.

As team SPAN, a two-person team, we built SANAD for the Google TMT Hackathon 2026 under KU ILPRL's Google-supported Trilingual Machine Translation project. The product turns public-service documents into a reviewable translation workflow with protected-entity checks, scoped memory, risk flags, human review, and export-ready output.

  • result Winner, File Translation Tool Track
  • team SPAN, two-person team
  • scope English / Nepali / Tamang public-service document translation

upstream

I care about upstream work because it is one of the cleanest ways to test whether an idea survives outside my own repository. The contributions below are small on purpose: concrete enough to inspect, strict enough to review, and real enough to affect behavior that other people depend on.

selected contributions

Linux / Kernel / 2026

Linux kernel contributions across Bluetooth memory safety, DRM/PCI controller fixes, KUnit, and core library paths.

The work spans 13 commits verified in mainline Linux: Bluetooth memory-safety work, AMD XDNA debug BO sync, PowerVR userspace array stride handling, PCI/DWC/Meson teardown and error-path fixes, KUnit tooling fixes, cmdline next_arg() coverage, printf IPv6 tests, seq_buf export/KUnit coverage, and IIO DMA and PowerVR fixes tagged for stable. Related accepted upstream work includes an OpenVPN keepalive peer-lifetime fix and a FUSE/io-uring request-lifetime race report.

  • status 13 commits verified in mainline Linux; plus accepted OpenVPN and FUSE/io-uring upstream reports not counted as mainline commits here
  • scope Bluetooth memory safety / AMD XDNA debug BO sync / PowerVR userspace array stride handling / PCI controller teardown and error paths / OpenVPN peer lifetime / FUSE io_uring request lifetime / KUnit tooling / cmdline and seq_buf tests / printf IPv6 coverage / IIO DMA fix
  • through Maintainer-reviewed upstream workflow

also selected

Cilium Tetragon / eBPF / 2026

Kprobe return-path validation and schema clarification in Tetragon.

Merged in cilium/tetragon#4601, this series rejects unsupported returnArgAction values on kprobe return paths, adds regression coverage, and carries the clarified semantics through CRDs, docs, vendored schema copies, and examples. An earlier Helm template cleanup also merged in #4631.

  • status 2 merged pull requests in cilium/tetragon
  • scope Kprobe return-path validation / tracing-policy docs and CRDs / Helm packaging cleanup
  • evidence Regression coverage plus maintainer-reviewed upstream workflow

also selected

Pyrefly / Type checker / 2026

Stub descriptor semantics in Pyrefly.

Merged in facebook/pyrefly#3151, this fix makes stub and interface declarations use descriptor protocol lookup instead of exposing raw descriptor types. It closes #3045, adds regression coverage for inherited .pyi descriptors, and the mypy_primer run reported fewer real-world false positives.

  • status Merged into facebook/pyrefly
  • scope Descriptor protocol / .pyi stubs / type inference
  • evidence Regression test plus mypy_primer signal across real projects

also selected

Bitcoin Core / LLVM compiler-rt / 2026

TSAN and glibc fortify investigation for a Bitcoin Core timeout.

Investigated an intermittent Bitcoin Core TSAN timeout and traced the failing path to glibc fortify emitting __read_chk for TokenPipeEnd::TokenRead(), which did not go through TSAN's normal intercepted read path. The public issue thread records the diagnosis; a Bitcoin maintainer later linked the issue to an LLVM compiler-rt fix for fortified read/pread interceptors.

  • status Public upstream investigation; not counted as a merged LLVM code contribution
  • scope Bitcoin Core functional test timeout / glibc _FORTIFY_SOURCE / TSAN signal handling / compiler-rt interceptors
  • evidence Issue-thread diagnosis, maintainer follow-up, and merged LLVM PR addressing the same missing fortified read/pread interceptor path

also selected

Dify / Agentic workflow platform / 2026

OpenTelemetry decorator typing cleanup in Dify.

Merged in langgenius/dify#32163, this refactor tightens OpenTelemetry decorator typing in the API service while preserving runtime behavior. A separate prompt-template typing cleanup remains open and is not counted here.

  • status 1 merged pull request in langgenius/dify
  • scope Python typing / OpenTelemetry decorator ergonomics
  • evidence Merge commit verified reachable from langgenius/dify main