Distilling 1

2026/04/17

BUILDinfraazureterraformlearning

In ML, knowledge distillation is when a small model learns from a larger model’s outputs instead of from raw data. The student doesn’t need to retrace the teacher’s entire training process. It just studies what the teacher produces and extracts the patterns.

You can do the same thing with colleagues.

This is the first post in a series I’m calling 蒸馏同事 (zhēngliù tóngshì, “distilling colleagues”). The idea: pick someone on your team, read their commit history methodically, and extract their expertise into your own understanding. Not pair programming, not asking questions. Just reading their PRs like a student model reading teacher logits.

蒸馏模型，蒸馏同事. Distill models, distill colleagues.

The subject: Jie Li

Jie Li (jieli8_microsoft) joined our team on March 26, 2026. In three weeks he shipped 37 PRs across 4 repos (mango: 30, yolo: 5, HPC: 1, msi-101: 1). His velocity curve alone tells a story: 8 PRs in the remaining days of March, then 29 in the first 15 days of April. That’s roughly 2 PRs per day by week 3.

But velocity isn’t what makes his history interesting. The sequence is.

Four phases of ramp

Reading his PRs chronologically, you can see four distinct phases. Each one teaches you something different.

Week 1 (Mar 26–31): Onboarding quick wins

Condor onboarding, fixing devbox/Brix defaults, adding a meridian_playground FastAPI demo. Classic new-hire pattern. He’s touching things that are easy to verify, building context on the codebase, and shipping small wins that prove the dev loop works. Nothing surprising here, but the FastAPI playground is interesting. He’s not just reading docs. He’s building a toy to poke at the system.

What you distill: When onboarding to infra, build a playground first. Don’t start with the production Terraform. Start with a FastAPI app that calls the thing you’re trying to understand.

Week 2 (Apr 1–6): Observability and dev containers

ddtrace instrumentation, DEVEX-807 msi-devbox and msi-dev-container image CI, pinning yazi. He’s shifted from “understand the app” to “understand the developer experience.” The ddtrace work means he’s thinking about how you see what the platform is doing, not just how you build it.

What you distill: Observability before features. If you can’t see what’s happening, you can’t debug what you build next. Also, dev container work this early means he’s investing in his own iteration speed, which pays compound interest on everything after.

Week 3 (Apr 7–12): Meridian database infra

PostgreSQL provisioning, private endpoints, read replicas, HA, RBAC setup and cleanup. This is the real infra phase. He’s building the Meridian platform’s database layer in Terraform, and the PR sequence shows a very specific pattern: provision the base resource, then layer on networking (private endpoints), then layer on reliability (replicas, HA), then layer on access control (RBAC).

What you distill: The layering order matters. You don’t try to do “complete PostgreSQL with HA and RBAC” in one PR. You build the resource, make it reachable, make it reliable, then lock it down. Each layer validates the previous one. If your private endpoint is wrong, you find out before you’ve also tangled RBAC into the same Terraform state.

Week 4 (Apr 13–15): The Service Bus saga

This is where it gets really educational.

Jie Li opened 7 PRs in a single day trying to get Azure Service Bus working with cross-tenant access, Key Vault integration, and AAD authentication. Seven sequential fix PRs. Each one addresses a specific failure from the previous attempt.

Reading them in order is like watching someone navigate a minefield, and every step reveals where a mine is:

  1. Initial Service Bus + Key Vault + AAD setup
  2. Fix: Azure provider registration (the Microsoft.ServiceBus resource provider wasn’t registered in the subscription)
  3. Fix: Premium SKU required for private endpoints (Basic/Standard don’t support them, and the error message from Azure is… not great)
  4. Fix: capacity must be explicitly set for Premium (defaults to 0, which is invalid, but Terraform doesn’t catch it at plan time)
  5. Fix: private endpoint approval flow (auto-approval doesn’t work cross-tenant, needs manual approval or a different private_dns_zone_group setup)
  6. Fix: cross-tenant service principal permissions
  7. Fix: final provider quirk cleanup

What you distill: This is the most valuable part of the entire 37-PR history. No Azure documentation page will teach you this sequence. Docs tell you what the settings are. Jie Li’s PRs tell you what order you’ll hit the walls in. The Premium SKU gotcha, the capacity default, the cross-tenant PE approval flow. These are the things you only learn by doing it, or by reading someone else’s commits who did.

Why this works

Reading commit history is underrated as a learning tool. A PR diff tells you:

That last point is the key. Individual PRs are useful. PR sequences are where the real knowledge lives. Jie Li’s Service Bus saga is 7 PRs that, individually, look like small Terraform fixes. Read together, they’re a complete tutorial on provisioning Azure Service Bus with private networking and cross-tenant identity.

You can’t get this from Stack Overflow. You can’t get it from Microsoft’s docs. You get it from reading what your colleague actually had to do, in order, with all the false starts visible.

The series going forward

I’ll keep doing this. Pick a colleague, read their recent work, write up what I distilled. It’s good for me (I learn their domain), it’s good for the team (knowledge gets shared), and it’s a nice forcing function to actually read PRs carefully instead of just approving them.

蒸馏同事. Next one TBD.