🚨 I hovered over Approve. The AI PR looked senior - clean names, DI wired, six green unit tests. Then one characterization check printed what finance would have found weeks later: an External customer with EMP-SAVE got a ₹15 employee discount instead of ₹0. Another path showed a total of ₹93.50 when the correct total was ₹110.00. Green tests. Wrong money. Almost merged.
That is the Future of Development story in one click. AI can write the PR. Seniors still own the spec.
TL;DR
AI is already drafting refactors, tests, and PR descriptions faster than most teams type. The bottleneck is not code volume - it is trust. Seniors still own the spec (money rules, EMP- quirks, rounding modes), characterization before the model touches behavior, review gates that reject happy-path-only suites, and incident ownership when wrong ₹ ships. This article is about that career shift - not another Copilot tip sheet.
🙋 Honesty first - what this is / isn't
This is: a career / role piece under Future of Development - how AI and the industry change what seniors still own when models draft the PR.
This is not: an AI tooling tutorial (that lives under AI for Developers) and not a .NET version upgrade guide (that's Modern .NET).
I will reuse live numbers from two DotNet Wisdom demos I already published. I will not retell every line of those articles - I will use them as proof that "pretty PR + green bar" is not enough.
Let's be honest: when I first let AI "clean up" a legacy Orders API, I almost approved on structure alone. Learn from my mistakes.
What changed in the job
Five years ago, "senior" often meant I wrote more of the hard code. Today models draft naming, DI, test scaffolding, and half the PR body before lunch.
What did not change:
- Finance still cares whether External +
EMP-is ₹0 or ₹15. - EU tax still cares about
MidpointRounding.ToEvenvsAwayFromZero. - Production still pages a human when money drifts.
So the job shifted. Typing speed is no longer the scarce skill. Judgment under uncertainty is. The senior who owns the spec can safely let AI write a large share of the PR. The senior who skips the spec becomes a fast path for wrong behavior with a green CI badge.
📌 Trust is the bottleneck - not autocomplete.
What seniors still own
| Own (non-negotiable) | Delegate (with gates) |
|---|---|
| Spec - money rules, EMP-, rounding, auth quirks, silent no-ops - written before code | Draft PR body, renames, DI wiring, dump duplication |
| Characterization - pin current / contract behavior with tests before AI refactors | Boilerplate happy-path tests (never the oracle for quirks) |
| Review gates - refuse merge on wrong-oracle or mock-theater suites | Structural refactors after characterization exists |
| Incident ownership - postmortem when ₹ leaks; fix the process, not only the line | Docs / comments (still review for accuracy) |
🎯 Own the outcome. Delegate the draft. That is the role shift.
I wrote about both failure modes in depth:
- AI Refactored My .NET API. It Broke the Business Rules - cleaner code, broken EMP- / EU rounding / shipped no-ops.
- AI Wrote My Unit Tests. They All Passed. The Bug Still Shipped - six green tests, wrong total, Stryker ~15.79% vs ~90.91%.
Those are the receipts. This FoD piece is the career framing on top.
A practical "spec before code" playbook
When I am about to ask AI to implement, refactor, or write tests, I run this sequence myself. Steal it.
1. Write the Spec Card (one page)
Before any prompt:
- Name the quirk in business language (
EMP-only for Internal; External → discount ₹0). - Put the live number on the card (External +
EMP-SAVEon ₹100 subtotal → ₹0, not ₹15). - Note edge modes (EU tax on midpoint →
ToEven). - Note silent behaviors (Shipped + remove-line = no-op, not error).
If it is not on the Spec Card, the model will "simplify" it.
2. Characterization first
Pin the current (or contracted) behavior with tests before the model edits production code. Red against a known-bad implementation is success - it means your specs have teeth.
3. Prompt with constraints, not vibes
"Preserve behavior" alone is not enough. I now paste non-negotiable quirks with numbers into the prompt and say: do not delete or merge branches that look redundant if finance / auth depends on them.
4. Let AI draft the PR
Naming, DI, structure, scaffolding - yes. Treat the output like a junior PR: useful, fast, never merge-ready on style alone.
5. Run the gates
- Regression / characterization suite (not only AI happy paths).
- Scary negatives: External +
EMP-, midpoint edges. - For money / auth paths: mutation testing. In the unit-tests demo, the weak AI-style slice scored ~15.79%; solid characterization on the correct calculator scored ~90.91%.
6. Senior owns merge
Approve only when the Spec Card numbers still hold. Eyes love pretty names. Tests love boring numbers like ₹0 vs ₹15 and ₹93.50 vs ₹110.00.
✅ No characterization = no AI refactor. That rule alone has saved me from more than one "clean" PR.
Live numbers (proof, not decoration)
Reuse these when you argue for senior ownership in your team:
| Scenario | Wrong (AI / buggy path) | Correct (owned spec) |
|---|---|---|
External + EMP-SAVE on ₹100 |
discount ₹15 | discount ₹0 |
| Same order, IN region total | ₹93.50 | ₹110.00 |
| Stryker on weak AI-style tests | ~15.79% | - |
| Stryker on solid characterization | - | ~90.91% |
📌 Live number AI can't fake: External customer + EMP-SAVE → ₹0, not ₹15. Green bars that assert the wrong total protect the bug.
Senior ownership checklist
Copy the full stealable version from the pack: toolkit/Senior-Spec-Ownership-Checklist.md. Quick version:
- Spec Card exists with money / auth quirks and example numbers.
- Characterization suite green on legacy (or contracted) behavior before AI edits.
- Prompt lists non-negotiable quirks - not only "preserve behavior."
- Review rejects happy-path-only and mock
Times.Oncetheater as merge evidence. - Scary negatives are asserted (External + EMP-, EU midpoint).
- Wrong-oracle smell check: expected totals not copied from buggy output.
- For money paths, glance at mutation score / survivors.
- Spot-check one console path with real ₹ before Approve.
- Incident playbook names a human owner if finance finds drift later.
- Mentoring: juniors learn to write Spec Cards, not only to paste prompts.
🙋 FAQ (career-focused)
Q: Does AI replace senior engineers?
A: It replaces a lot of drafting. It does not replace owning the spec, the gates, or the incident. Teams that confuse those will ship wrong money faster.
Q: Should mid-levels still learn deep .NET guts?
A: Yes. Spec ownership requires knowing why ToEven vs AwayFromZero matters. AI will not feel the finance Slack thread for you.
Q: Is "senior" now mostly review?
A: Review plus spec authoring plus gate design. If you only rubber-stamp green PRs, you are not doing senior work - you are doing ceremony.
Q: Can I ban AI on money paths?
A: You can require characterization + human merge on money / auth. Banning the draft is optional. Banning unchecked merge is not.
Q: What do I tell my manager about "velocity"?
A: Velocity without trust is inventory of bugs. Measure merge quality on quirk suites and incident rate - not lines AI generated.
Q: Where do the EMP- / Stryker numbers come from?
A: Live demos on DotNet Wisdom - AI refactor broke business rules and AI unit tests passed, bug shipped.
Your turn
🎯 What do you still refuse to delegate when AI drafts the PR - Spec Cards, characterization, merge gates, or incident ownership?
Drop it in the comments. I am collecting career stories for Part 2 of this Future of Development thread.
Soft CTA - steal the checklist
Use the checklist in this article pack: toolkit/Senior-Spec-Ownership-Checklist.md (and the one-page toolkit/Spec-Card-Template.md if you want a blank Spec Card).
More career + industry pieces: dotnetwisdom.com · pillar: Future of Development.
Comments