Frontier Lab Engineering Practicum · Capstone · Article 9 of 9 🗓️

Capstone: A Week in the Life of a Research Engineer

Eight articles have each isolated one piece of the job: onboarding, production code, distributed debugging, compute economics, custom kernels, on-call, cross-team code, and a single experiment's full lifecycle. Real weeks don't arrive in that clean order — they interleave all of it with meetings, someone else's incident, and the ordinary unpredictability of a real job. This capstone closes the series with a realistic Monday-through-Friday, naming exactly which prior article each moment draws on.

FrontierAGI Team

September 15, 2026 · 50 min read

Opening Monday Tuesday Wednesday Thursday Friday Full Series Map Readiness Checklist What's Missing Where This Series Ends References Videos Verdict

A Realistic Week, Not a Highlight Reel

This week is composed from realistic, individually plausible events, each one directly traceable to a concept this series has already built. It is deliberately unglamorous: no single day is a crisis, no day is purely routine, and the actual skill on display is moving between registers — deep debugging focus, cross-team communication, on-call vigilance, careful review — multiple times before Friday, without any one of them crowding out the others for long.

9 Articles in this series, all touched at least once across this single week

1 On-call rotation shift, one merged PR, one postmortem — a normal week's real output

0 Days that are purely "coding" or purely "meetings" — most days are both

Monday

Inheriting the Pager, Reviewing a Diff

Morning

On-call rotation hands over at the weekly team sync. The outgoing engineer walks through the past week's alert history — two pages, both legitimate, no alert-fatigue false positives — following Article 6's discipline of treating a clean handover as a real, trackable signal, not just a formality.

Afternoon

A teammate's pull request touches a shared data-loading utility owned by another team. Per Article 7, review focus goes straight to whether the owning team was looped in, not just whether the diff itself looks correct — the review comment is a question about ownership process, not a line-level nitpick.

Tuesday

A Job That Won't Start

Morning

Your own experiment's larger-scale run fails to start. Applying Article 3's triage framework immediately narrows it to environment/scheduling rather than a model bug — the fix turns out to be a stale container image, found in minutes rather than hours because the triage category was right from the start.

Afternoon

With the job running, config composition work continues on a second experiment variant, following Article 2's discipline of new overrides on the shared base config rather than a duplicated training script.

Wednesday

The Compute Conversation

Morning

A larger compute request for next week's validation run needs manager sign-off. Per Article 4, the request is framed around expected Model FLOPs Utilization and a spot-vs-reserved recommendation matched to the run's actual tolerance for interruption — not just a GPU-count ask, which is what makes the conversation quick rather than a negotiation.

Afternoon

A page fires: a different team's job shows a sustained utilization drop. As the second on-call responder, the mitigate-first instinct from Article 6 applies — restart from the last checkpoint immediately, investigate the root cause after service is restored, not before.

Thursday

The Kernel That Wasn't Written

Morning

Tuesday's second experiment variant looks slower than expected. Before reaching for anything at the kernel level, Article 5's profiling discipline applies: a five-minute profiler run shows the bottleneck is a data-loading stall, not a compute-bound operation — no custom kernel gets written this week, and that's the correct, profiled outcome, not a missed opportunity.

Afternoon

Wednesday's incident postmortem is drafted, following Article 6's blameless framing — the writeup centers on a missing automated restart trigger, not on why the job's owning team didn't notice sooner.

Friday

A Merged PR, and a Quiet Weekend Ahead

Morning

Tuesday's original experiment finishes cleanly overnight with a real, positive result. The PR — config diff plus a small documented fix to the shared utility, the owning team already looped in per Monday's review lesson — is opened with the full Article 8 writeup discipline: hypothesis, result, and honest compute cost stated up front.

Afternoon

The PR merges before end of day. On-call rotation hands off to the next engineer with the same clean-handover standard from Monday. The pager stays quiet through the weekend — the unremarkable, desired outcome this entire series has been building toward, not a stroke of luck.

Every day touches at least two prior articles — the actual shape of the job, not a highlight reel.

The Full Series Map

Nine Articles, One Job

Article	Where It Showed Up This Week
1. Day One Onboarding	Blast-radius review depth applied all week, without needing to relearn it
2. Production Training Code	Tuesday's config-only experiment variant
3. Debugging Distributed Jobs	Tuesday morning's won't-start triage
4. Compute Economics	Wednesday's compute request conversation
5. Custom Kernels	Thursday's profiled decision not to write one
6. The On-Call Reality	Monday's handover, Wednesday's page, Thursday's postmortem
7. Other Teams' Code	Monday's review, Friday's cross-team PR
8. Idea to Merged PR	The full Tuesday-through-Friday arc of the merged experiment

Readiness Checklist

Can you picture your own week and identify which of these nine articles' concepts it actually drew on?

Have you ever context-switched between deep debugging focus and cross-team communication within a single day, without one crowding out the other?

Do you treat a quiet on-call week as a real, positive signal — not just an absence of news?

Across all nine articles, can you name the one habit you personally need to build most?

⚠️ What's Missing or Uncertain

This week is a composite, not a transcript of any single real week. Real weeks are messier — some have no incidents at all for months, others have two in the same day; some engineers spend entire weeks heads-down on one hard debugging problem with no cross-team interaction whatsoever. The value here is showing how the pieces from this series can interleave, not asserting that every week looks exactly like this one.

Where This Series Ends

This capstone closes the nine-article Frontier Lab Engineering Practicum. Alongside this site's earlier AGI Researcher Foundations series — which covers the mathematical and conceptual side of this same work — the two series together are meant as a genuinely complete map: what to understand, and what to actually do with it once you're the one holding the pager.

🔗 Reference Links

🎥 Recommended Videos

But What Is a Neural Network?

3Blue1Brown — foundational context for everything this week's work protects

We're All Addicted to Claude Code

Previously cited — daily engineering tooling context

🧭 Closing — The Job Is Nine Skills Held at Once

🎯 The Bottom Line

No single day this week required expertise in all nine articles at their deepest level — Monday needed on-call and review judgment, Thursday needed profiling discipline and blameless-postmortem writing, and none of it required all nine at once. What it did require was recognizing, quickly and correctly, which article's mental model applied to each moment — and that recognition, built one article at a time across this series, is the actual, durable skill a frontier lab is really hiring for when it hires a research engineer.