I study how information behaves in code: in commits, in adoption curves, in systems that look chaotic until you measure them properly. Most of what's below started as a clean hypothesis. Some of it ended with the data winning instead of me. I think that's the more interesting outcome to publish.
difference-in-differences quasi-experimental git mining 638k commits
Does GitHub Copilot change how people commit, causally rather than just correlationally?
flowchart LR
A[GH Archive<br/>10 repos, 2018-2024] --> B[Commit extraction<br/>638,000+ commits]
B --> C[Feature engineering<br/>files / churn / inserts]
C --> D[Panel: repo x week<br/>fixed effects]
D --> E[Pre-trend F-test]
D --> F[DiD + event study]
D --> G[Commit-message DiD<br/>mechanism check]
E --> H[Result]
F --> H
G --> H
| Metric | Effect | p-value |
|---|---|---|
| Mean files/commit | −28% | < 0.01 |
| Mean insertions/commit | −37% | < 0.01 |
| Large-commit fraction | −2.4pp | < 0.01 |
| Fix-commit fraction | β = −0.030 | < 0.001 |
| Refactor-commit fraction | β = +0.007 | 0.006 |
| Pre-trend joint F-test | passes on all 4 headline features | n/a |
Effect concentrates in existing contributors, not newcomers: people write smaller, more atomic commits once an assistant is doing the typing. A commit-message DiD adds the mechanism check, with fix-commit share falling and refactor share rising post-adoption. HC3 robust SEs throughout; IEEEtran paper drafted, targeting MSR 2027.
Relation to prior work - Xu et al. 2025 (arXiv:2510.10165, Tilburg)
Xu et al. find Copilot adoption increases PR-level rework and review volume. Sekivara looks one level down, at the commit itself, and finds atomicity decreasing post-adoption. Together the two tell one story: more, smaller, more frequent commits. Sekivara supplies the commit-level mechanism underneath their PR-level result, and its clean pre-trend F-test and outlier-filtered control set are the methodological additions.
staggered-adoption DiD sun-abraham estimator bigquery 89 repos
Does adding a CODEOWNERS file causally change how fast pull requests get reviewed?
flowchart LR
A[GH Archive<br/>~21TB via BigQuery] --> B[89-repo panel<br/>staggered adoption]
B --> C[Sun-Abraham<br/>event-study DiD]
C --> D{Result by<br/>horizon}
D -->|0-18mo| E[Null on<br/>PR closing time]
D -->|23-24mo| F[Signal, flagged<br/>as confounded]
B --> G[CODEOWNERS coverage<br/>parsed at treatment date]
G --> H[Bimodal split:<br/>14 repos ≤10% / 8 repos ≥90%]
| Window | Finding | Confidence |
|---|---|---|
| 0-18 months | Null effect on PR closing time | Clean |
| 23-24 months | Two coefficients turn significant | Confounded: only 17/28 repos reach this horizon, no later-adopting comparison cohort at same horizon |
| Coverage split | 14 repos ≤10% coverage, 8 repos ≥90% | Low-coverage subset reproduces the null; high-coverage subset violates parallel trends, so coverage is a likely moderator |
Relation to prior work - Lulla, Kula & Treude 2025
A directly competing paper was found mid-analysis and incorporated rather than ignored. Their fixed RDD design structurally cannot observe the 18-24 month window Ikiru covers. The two studies are complementary in the horizons they can each speak to, not redundant.
shannon entropy leave-one-repo-out CV honest null result
Does Shannon entropy in commit histories predict upcoming software releases?
flowchart LR
A[Commit histories<br/>9 repos] --> B[Shannon entropy<br/>per commit window]
B --> C[Naive train/test split]
C --> D[72% accuracy]
B --> E[Leave-one-repo-out CV]
E --> F[AUC 0.47, chance level]
B --> G[Confound check]
G --> H[Commit volume vs entropy<br/>Spearman r = 0.817]
| Evaluation | Result | Interpretation |
|---|---|---|
| Naive split | 72% accuracy | Looked promising |
| LORO-CV | AUC 0.47 | Indistinguishable from chance |
| Confound test | Spearman r = 0.817, p = 0.007 | Entropy was re-detecting commit volume, not release prep |
Status: Published as a negative result with a documented confound, not a quiet repo nobody talks about. The methodology is the part worth reading.
fairness-aware ml demographic parity equal opportunity random forest
Does fixing bias in tabular ML cost accuracy, and do all mitigation strategies work equally well?
flowchart LR
A[Tabular dataset] --> B[Bias audit<br/>12 modules]
B --> C[Reweighting]
B --> D[Feature suppression]
B --> E[Post-processing]
C --> F[Fairness metrics]
D --> F
E --> F
F --> G[Random Forest<br/>accuracy check]
| Strategy | Demographic Parity Gap ↓ | Equal Opportunity TPR Gap ↓ | Accuracy |
|---|---|---|---|
| Reweighting | Best of 3 | Best of 3 | Stable |
| Post-processing | Middle | Middle | Stable |
| Feature suppression | Worst of 3 | Worst of 3 | Stable |
| Overall | 64.5% | 47.8% | Held stable throughout |
The sharper finding: naive feature suppression, the most intuitive fix, was the least effective of the three, underperforming reweighting on every fairness axis tested. Built with Dr. Chirag Joshi; pending arXiv endorsement.
Contributions to libraries with real production surface area, not toy patches.
- pandas - fixed a negative-slice indexer validation bug in core indexing logic using
slice.indices()(PR #66101), with regression tests. - PyDriller - corrected
Commit._stats()to respect theskip_whitespacesflag (PR #320); added aCommit.patchproperty exposing full unified diffs, closing a long-standing feature request (PR #321). - PyGithub - added a configurable
max_rate_limit_waitcap toGithubRetry, with a newRateLimitExceededExceedsMaxWaitexception, replacing unbounded rate-limit stalls (PR #3540).
go raft consensus deterministic simulation testing distributed systems
Can you make a distributed-consensus bug reproduce on demand?
flowchart LR
A[Raft nodes in Go<br/>leader election + log] --> B[Simulated scheduler<br/>deterministic delivery]
B --> C[Fault injection<br/>drop / delay / partition]
C --> D[Seeded runs<br/>replay any failure]
D --> E[6 passing tests incl.<br/>partition majority/minority]
| Phase | Scope | Status |
|---|---|---|
| 1 | Leader election, election safety checks, log accessors wired into RequestVote | Done |
| 2 | Scheduler-driven delivery, fault injection (drops, delays, partitions), lossy-network tests | Done |
| 3 | Full log replication: AppendEntries with consistency checks and commit advancement |
In progress |
Every test run is fully deterministic: same seed, same interleaving, same failure. No flaky distributed tests, no "works on my machine" for consensus bugs.
html sheetjs offline-first statistical filtering
Vocational trainee with the APR/SCADA team (June-July 2026). Two shipped tools:
- A fully offline, browser-based CSV/Excel trend-report converter (single HTML file + SheetJS) with a compound tag-editing UI: suffix-diff, character-strip, and per-position removal. Runs on air-gapped plant machines with zero install.
- An outlier-removal and feature-rejection pipeline for Pearson correlation analysis, combining IQR filtering with MAD-based modified z-scores and whole-graph auto-rejection (gap test + leverage test).
clip umap fastapi docker gcp
Can a machine read taste?
flowchart LR
A[25-round quiz<br/>image comparisons] --> B[CLIP ViT-B/32<br/>embeddings]
B --> C[Cosine similarity to<br/>16 aesthetic centroids]
B --> D[3D UMAP projection]
D --> E[kNN nearest-image<br/>retrieval]
A --> F[Upload & classify<br/>any photo]
| Engineering problem | Root cause | Fix |
|---|---|---|
| Docker image bloat | pip dependency-resolution bug | 9.2GB → 1.62GB |
| Session tracking silently broken | Browser secure-context restriction | Diagnosed via evidence, not guesswork |
| Slow classify response | Assumed memory issue | Actually e2-micro's documented 25% sustained CPU ceiling, measured directly |
| Repeated slow startup | UMAP re-fit on every restart | Cached fit to disk |
Free-tier GCP VM (964MB RAM) by choice: the constraint is what makes the engineering real. Free HTTPS, a real domain, zero ongoing cost. Full writeup in the repo's README.
- 🎓 Amazon ML Summer School 2026 - selected among the top ~3,000 of 134,000+ applicants (~2.2% selection rate)
- 🏆 Top 1,500 of 100,000+ participants - Google "The Big Code" competitive programming challenge
