Teaching Our Merge Requests to Teach Back

Over the last few months, I’ve kept hearing the same question in different conversations: how do we keep growing humans in a world where agents can write most of the first draft? Junior folks want more context, and senior developers on one end of the stack want to actually learn from the work happening on the other.

At the same time, AI‑generated code is quietly becoming tomorrow’s training data. A lot of it lands in our repos as merge requests (or pull requests), where the changes get reviewed, merged, and eventually scraped into the next generation of models. That means AI is increasingly learning from AI.

That raises a bigger question for an agentic dev world: if tools are writing more of the code and even opening their own MRs, who’s training the juniors now? If the only thing they ever see is a wall of green diff lines, we shouldn’t be surprised when their judgment plateaus. All the messy trade‑offs, the awkward edge cases, the “we tried this and it blew up in staging” stories used to live in reviews, pairing sessions, and long comment threads; those are exactly the bits that don’t show up in an autocomplete box.

Instead of trying to solve that for the whole industry, I started smaller: with our merge requests.

Encoding mentorship into a Skill

On our team, we’d already been talking about how MR quality can either accelerate or stall learning. Rather than just reminding people to “write better descriptions” (everyone’s favorite vague guidance), I tried teaching our tools to nudge us in the right direction.

I created an educational-pr-description Skill and wired it into our MR flow with one extra job: after drafting the base description, it analyzes the diff against a short checklist — architectural decisions, non‑obvious framework conventions, performance or security trade‑offs, cross‑layer behavior. Instead of silently editing the MR, it proposes a Context & Patterns block back to the author: 1–4 bolded callouts, each with 2–3 sentences explaining the why behind a specific choice. Nothing goes in the MR until a human has accepted, edited, or deleted it, so we’re still exercising judgment while the tool does the first pass at spotting teachable moments.

The rule is simple: if there’s nothing to teach, say nothing. But when there is something interesting in the diff, the tool should help us surface it explicitly, without turning every MR into a novel.

What this looks like in a real MR

The first time I tried this was on a front‑end MR that added “show more” list item animations using CSS instead of JavaScript. CSS‑driven staggered animations on the compositor thread are powerful, but they’re not exactly a day‑one pattern for most developers.

The Skill came back with a Context & Patterns section along the lines of:

• Staggered animation via CSS animation-delay instead of JS logic, so the browser can handle it efficiently.
• Tracking animateFromIndex in state rather than a ref so the correct batch re‑renders and the animation actually attaches.
• Guarding the keyframes behind prefers-reduced-motion so users who request reduced motion don’t get a potentially uncomfortable effect.

None of this changes whether the code passes tests. But it radically changes how teachable the MR is. A reviewer now sees the intent behind the implementation. A newer teammate learns a concrete pattern, with just enough context to try it next time. And if you’re a backend developer wandering into a front‑end MR (or vice versa), you get a guided tour instead of a jump scare.

Why this matters in five years

Our edge as senior developers isn’t that we can output more lines of code than a model; it’s our experience, taste, and ability to steer messy systems under uncertainty. That edge is not a fixed asset. If we let our processes run unattended while agents handle more of the craft, we end up training the tools while letting our own muscles atrophy.

A lot of the code we ship today won’t just live in our repos; it will quietly end up in the training data for tomorrow’s models. That means models are increasingly learning from model‑generated code. It reminds me of the old days of copying cassette tapes from a copy instead of the master. The first copy sounds fine. The second is “good enough.” But a few generations in, the noise floor rises, the details blur, and the track is technically still there — it’s just a long way from the original performance.

If we’re not careful, we can end up in the same place with our tools: models training on model‑generated code, slowly drifting away from the hard‑won judgment and experience that made the originals good in the first place. Educational MR sections are one small way to push back on that trend. They force us to narrate our judgment instead of quietly outsourcing it to autocomplete. They keep the “master recording” — the intent, the trade‑offs, the constraints — attached to the work, so it doesn’t all blur into background noise.

A pattern you can steal

If you want to try something similar, you don’t need our exact setup. Start with:

• Add a Context & Patterns section to your MR template, right after Testing.
• Encourage authors to use it for 1–4 short callouts: “why this pattern,” “what we traded off,” “what might surprise future‑you.”
• If you have AI in the loop, teach it explicitly: analyze the diff for non‑obvious patterns, propose the section back to the author, and let them be the final editor of what actually ships.

It’s a small change, but it keeps a human voice in the repo. Every non‑trivial MR becomes more than a diff; it becomes a tiny lesson for the next person — whether that’s a junior developer, a senior from the other side of the stack, or whatever we end up calling our agents in a few years.

For folks who want to experiment with this directly, I’ve also published the installable educational-pr-description SKILL you can drop into your own setup.