This module installs the senior engineer's operating system for AI: routing every task by its verification cost, holding the line between disposable and production code, and running personal verification defaults you decided in daylight — the difference between generating code fast and shipping it correct.
Sana, a senior backend engineer, has one review left before she can log off.
Her coding assistant hands her a tidy 200-line diff: a retry wrapper around billing-service's calls to the payment provider, exactly what the ticket asked for. Exponential backoff, a clean decorator, tests that pass.
It reads beautifully. Her cursor hovers over the merge button.
except requests.RequestException, wrapping a block whose real failure — she'd noted that morning — comes out of resp.raise_for_status().
If raise_for_status doesn't throw a RequestException, this wrapper retries nothing and swallows the very error it was written to catch.
The docs confirm the gap. The diff was almost right — the most expensive kind of wrong.
She fixes three lines, adds the edge-case test the AI skipped, and merges.
The speed was real — the assistant wrote in seconds what would have cost her an hour. But the value landed only because she read the one line she was tempted to trust. That gap, between code generated and code shipped-correct, is the whole job now.
You already know how to prompt, how to verify, what a trust tier is, and why "the AI wrote it" has no professional standing — that was the Common Core. This module is where the general discipline meets your actual job. The market context is unusual: US software-developer postings rose roughly 15% since February 2025 while overall postings fell 7%, and 71% of that increase is senior roles (Indeed Hiring Lab, July 2026).
Employers are not hiring people who can generate code — 90% of developers already use AI daily, a median of about two hours a day (DORA 2025). They are hiring people who can convert that speed into shipped, correct, maintainable systems. The same DORA report shows why that is rare: individual output is up sharply (+21% task throughput, +98% PRs merged) while organizational delivery performance stayed flat. Somebody is absorbing all that generated speed, and it isn't the customer.
This module gives you the senior engineer's operating system for AI: where it pays and where it burns, the disposable-versus-production boundary, assist-not-delegate planning, what AI-enabled interviews actually score, and the personal verification defaults that make everything downstream of you trustworthy.
The scarce skill in 2026 is not generating code with AI — it is converting AI's individual speed into team-level delivery. DORA measured the gap: +98% PRs merged per individual, flat organizational performance. Closing that gap in your own work is what this entire track trains.
The survey data is consistent enough to treat as an engineering input rather than an opinion. Stack Overflow's 2025 survey and the Pragmatic Engineer's 2025 survey converge on the same high-win zones, and the same frustration: 66% of developers report spending more time than expected debugging AI-generated code — "almost right, but not quite" is the single most-cited complaint. The senior move is not to use AI more or less, but to route tasks deliberately.
These tasks have a shape AI handles well — bounded scope, verifiable output, low blast radius:
The burn zone is not "tasks AI is bad at" — it is "tasks where verification cost exceeds generation savings." That framing predicts new cases the survey data doesn't cover: AI may write a plausible Kafka rebalancing config in seconds, but if verifying it takes you a day of reading, the trade lost.
Generic maps are a starting point; your leverage is specific. Run this exercise once, honestly, against a real week:
Column 1: every distinct task type you did last week (from calendar,
git log, ticket history — not memory).
Column 2: hours spent.
Column 3: verification cost if AI drafted it — LOW (compiler/test/read
in minutes), MEDIUM (needs careful read + targeted tests),
HIGH (needs expertise you'd have to build, or reality you
can't simulate).
Column 4: current AI usage — none / assist / delegate-and-review.
The gold is in the mismatches. High hours + LOW verification cost + no AI usage is money on the table (typically: test writing, migration boilerplate, log spelunking, doc updates). AI usage on HIGH-verification tasks is where your future incidents are queued. Most senior engineers who do this audit find two or three hours a week of LOW-verification work still being done by hand — that is your adoption backlog, and it costs nothing in risk to claim it.
Coinbase's AI mandate is the cleanest public articulation of the rule this section teaches. Engineers were given one week to onboard onto Copilot and Cursor — AI use is mandatory, not optional — and roughly a third or more of shipped code is AI-generated. But every line carries mandatory human review, and the CEO's phrasing draws the boundary exactly: "no vibe coding in financial systems." Both halves matter. Vibe coding — conversational, spec-free, accept-and-run generation — is not banned. It is banned in financial systems. The skill is knowing which side of the line you're standing on before you start typing.
Disposable code is Tier 1 in the Common Core trust framework: raw material whose value is what it teaches you, not what it ships.
For disposable code, verification effort beyond "did it answer my question?" is waste. Generate fast, extract the learning, delete the code. The discipline is the deleting: label the branch spike/, never merge it, and write down what you learned somewhere the code isn't.
Production code is anything that will run when you're not watching: merged code, cron jobs, migrations, infrastructure config, anything a teammate might build on. Production code gets the full Common Core treatment — read every line, verify dependencies exist and behave as used, run edge cases, review the AI's tests hardest — plus mandatory human review under your name.
The dangerous moment is the silent crossing: the spike that worked so well someone says "can we just ship this?" The Common Core named this the T1→T3 transition, and it is where AI incidents are born. The senior engineer's rule: crossing the boundary re-tiers the artifact, and re-tiering means the production checklist runs from scratch — the spike's apparent success is evidence about feasibility, not correctness.
A prototype that survives contact with a demo has proven exactly one thing: the happy path exists. Every property production cares about — error handling, idempotency, concurrency, security, observability — is precisely what vibe coding skips. Promote the learning, rewrite the code.
Make the boundary mechanical, not moral. Naming conventions (spike/, throwaway/), a repo-level rule that spike branches can't open PRs against main, and a PR-template checkbox — "contains AI-generated code: what I verified / what I'm unsure of" — survive deadline pressure. Personal discipline doesn't.
Planning is where the 69% resistance lives, and the resistance encodes something true: a plan is a commitment made under context the model doesn't have — team capacity, political constraints, the client's actual tolerance for risk, which "two-day task" burned you for two weeks last quarter. Delegating the plan delegates the accountability, and accountability is non-delegable. But refusing AI entirely forfeits real leverage. The pattern that works is assist-not-delegate: AI does structured expansion and compression; you do judgment, sequencing, and ownership.
You own an epic: "Add usage-based billing to the API platform." Instead of asking AI to plan it, use AI to stress your plan:
I'm decomposing an epic for a system I know well. My draft tickets:
1. Add usage_events table + write path from the API gateway
2. Aggregation job (hourly rollups)
3. Pricing engine (tier lookup, proration)
4. Invoice generation + PDF
5. Customer-facing usage dashboard endpoint
For each ticket: (a) list dependencies on other tickets I haven't
made explicit, (b) name one risk that would surface only in
production, (c) flag anything that is really two tickets.
Then list what's MISSING from the decomposition entirely —
especially migration, backfill, feature-flag, and rollback work.
Do not re-plan the epic. Critique mine.
Note the shape: the plan is yours; the model's job is finding holes ("what's missing" reliably surfaces backfill jobs, dual-write periods, and rate-limit interactions that human drafts omit). Estimates stay yours entirely — the model has never watched your team ship. In Copilot Chat this runs against your open workspace for grounding; in Claude Code or Cursor, run it in the repo so the critique can cite actual files. On a $0 path, Copilot Free's chat allowance covers planning conversations comfortably — they're low-volume, high-value.
The other planning-adjacent win is compression: standup notes, sprint summaries, and stakeholder updates generated from real activity rather than memory:
gh pr list --author @me --state merged --limit 20 --json title,mergedAt,url
git log --author="$(git config user.name)" --since="1 week ago" --oneline
Feed the output to any assistant with "draft a five-bullet stakeholder update; audience is non-technical; flag anything that looks like a slipped commitment." Then apply the Common Core commitment scan — every sentence that promises or characterizes gets rewritten by you. Ten minutes becomes two, and the update is grounded in what actually merged instead of what you remember.
In assist-not-delegate, the human artifact is the input, not the output. You bring the draft plan, the real git log, the actual constraint list — AI expands, attacks, or compresses it. If you're staring at a blank prompt asking AI to plan for you, you've inverted the pattern.
The interview format has already flipped at the top of the market, and Indian product companies and GCCs are copying it. Meta's AI-enabled coding round has been standard for E4–E7 since October 2025; Google adopted a similar format in 2026; HackerRank ships AI-assisted assessment modes (already common in Indian pipelines); Karat's NextGen format followed in December 2025. The Common Core covered why these interviews exist. Here is what they measure, because it is exactly this module's content under time pressure:
Practice format, not just skills: one hour, a HackerRank-style AI-assisted problem or any medium-complexity ticket in a sandbox repo, your usual assistant, and a recording or a partner. Score yourself afterward on routing decisions, defects caught versus shipped, and whether your narration would have told an interviewer why you accepted what you accepted. The UC-51 lab in this track is a full rehearsal with a rubric.
In an AI-enabled interview, catching one planted defect in AI output out loud is worth more than finishing five minutes faster. The formats exist because generation is no longer a signal — judgment under time pressure is the entire test.
The Common Core gave you the trust-tier framework and the read-run-test discipline. Applied to a working senior engineer's week, the framework becomes a set of standing defaults — decided once, in daylight, so you're not renegotiating with yourself at 6 p.m. against a deadline:
| Situation | Default tier | Standing rule |
|---|---|---|
| Spike, throwaway script, learning exploration | T1 | Run it, extract the lesson, delete. spike/ branch, never merges |
| Utility code with tests, internal tooling | T2 | Read the diff, verify every unfamiliar API against docs, run the tests plus one edge case of mine |
| Anything that merges to a shipped service | T3 | Full read-run-test; AI-generated tests reviewed hardest; provenance disclosed in the PR |
| Auth, payments, migrations with data loss potential, crypto, secrets handling | T4 | AI as sounding board only; I write the code; a second human reviews regardless |
Two defaults deserve emphasis because they fail most often in practice:
Verification governs what comes out of the model. Working engineers — especially at Indian services companies on client codebases — need an equally rigid default for what goes in. Many client contracts prohibit sending code to external LLM APIs, and India's DPDP Act 2023 attaches real liability to personal data in logs and fixtures. Run this tree before every paste, until it's reflex:
1. Does the content contain customer/personal data (emails, IDs,
tokens, real records in logs or fixtures)?
→ YES: redact first, or stop. DPDP Act 2023 applies to personal
data; stack traces and log lines are common leak vectors.
2. Is this a client codebase under NDA/contract?
→ YES: only client-sanctioned tools (e.g., Copilot Business with
the no-training flag, or Bedrock/Azure OpenAI inside the
client's own cloud tenancy). No sanctioned tool? Share shape,
not substance: sanitized signatures, invented identifiers,
a minimal reproduction you wrote fresh.
3. Does it reveal proprietary architecture or secrets (internal
hostnames, keys, schema names under NDA)?
→ YES: strip or generalize before pasting.
4. Otherwise → paste, with the minimum context that gets a good answer.
A local-model fallback (Ollama with a coding-tuned model) is a legitimate branch for restricted environments — usable for comprehension and boilerplate, though below frontier quality for agentic work. The point of the tree is not paranoia; it is that "can I paste this?" must be answered before the deadline pressure arrives, like every other default in this module.
Your first 15 minutes on Monday: the next AI diff you're tempted to accept on sight, pick the single line you understand least and verify it against real docs before anything else — that is exactly where Sana's retry wrapper hid its defect, and it is the highest-yield fifteen seconds in the review.
Check yourself: A prototype you vibe-coded to compare two queue designs works so well in the demo that your tech lead asks, "can we just ship this?" What has the prototype actually proven, and what does saying yes commit you to?
git log, not memory). Identify: two LOW-verification tasks you still do by hand, and one place you're currently using AI on a HIGH-verification task. Write the standing rule you'll adopt for each.This module's companion playbooks cover the weekly-workflow audit and personal AI operating agreement, the disposable-vs-production boundary with team-policy variants, assist-not-delegate planning and status distillation, restricted-environment and "can I paste this?" data-hygiene patterns, and AI-enabled interview preparation. Do this at work this week → pb-40 Epic Decomposition: Vague Epic to Sequenced, Estimable Tickets (assist-not-delegate against a real epic you own), pb-41 Status Distillation: Git Activity to Standups, Sprint Summaries, and Stakeholder Updates (the ten-minutes-to-two win from your actual git log), and pb-42 AI-Enabled Interview Readiness: Practice the AI-Assisted Coding Round (rehearse the format this module describes). The associated lab is a timed AI-assisted interview rehearsal scored against a judgment rubric — the same format Meta-style rounds use.