Capstone · The AI-workflow writeup

Every developer now uses AI. The differentiator is no longer whether you use it but how well you supervise it — what you hand over, what you catch, and what you refuse. This writeup is where you make that judgment legible. It is graded as seriously as the code because, in the market you are entering, it is the more distinguishing signal.

Why this is an interview artifact

Interviewers in 2026 assume you can prompt a model. What they cannot tell from a repo is whether you understood what it produced or just pasted it. A specific, honest writeup — "here is a diff Claude gave me that had a retain cycle, here is how I caught it, here is what I changed" — proves comprehension in a way a clean commit history cannot. Vague AI writeups ("I used Claude to speed up development") signal the opposite. Treat this as a document you would hand to a hiring manager.

What to document — the three parts

1. What you delegated

List the components or tasks you handed to Claude Code, and why they were good candidates. Good delegation is not random — it is boilerplate, well-specified transformations, and areas with a clear contract. Be concrete:

"I delegated the URLSession API client and its Codable models — verbose, mechanical, and fully specified by the endpoint shapes. I delegated the SwiftData @Model migration scaffolding. I delegated the first draft of the settings screen's layout."

2. What you reviewed and rejected

This is the heart of it. Show at least two or three concrete cases where you sent AI output back, with the specific defect and your fix. Quote the problem. This is where the checkpoints in Projects 4–9 pay off — you have been trained to find exactly these:

"Claude's download manager stored progress in a plain dictionary written from concurrent delegate callbacks and slapped @unchecked Sendable on the class. That is a data race the annotation hides. I moved the state into an actor and dropped the annotation.

Claude's timeline repository returned an APIGatewayResponse<[Post]> from the protocol, leaking an AWS type into my domain and breaking backend-swappability. I changed the protocol to return [Post] and translated the response inside the concrete conformer.

Claude wrote a test that called the method but had no #expect — a green check that asserts nothing. I rewrote it to assert the actual post-condition."

Rejections are the strongest evidence of judgment. An honest writeup that says "the model was confidently wrong here and here is how I knew" beats one that claims the AI was flawless.

3. What you would configure differently

Reflect on your setup. What guardrail, hook, or review command would have caught your rejected diffs earlier? What would you change next time?

"A pre-commit hook flagging @unchecked Sendable and try! would have caught the download race before I did manually. A /swift-review rule that fails on any AWS import outside my boundary files would have caught the leak at review time. Next project I would write those on day one instead of relying on catching issues in review."

The bar for the writeup

• Specific, not generic. Name real diffs, real defects, real fixes. No "AI helped me code faster."
• Honest about failure. Include the cases where AI was wrong and where you were wrong to trust it initially. That candor is credibility.
• Shows the ladder. You are at Professional stage — demonstrate that you delegated broadly and reviewed ruthlessly, not one without the other.
• Readable by a hiring manager. A page or two of clear prose, not a chat log dump.

Checkpoint

Your writeup should:

• Cover all three parts: delegated, reviewed/rejected, would-configure-differently.
• Contain at least two or three concrete rejection cases with the defect named and the fix shown.
• Read as a professional document a hiring manager could skim and trust.
• Be honest, including where AI misled you and where you course-corrected.

Knowledge check

Q: Why is the "what I rejected" section the most important part of the writeup? Because rejecting bad AI output is the clearest evidence of engineering judgment — it proves you understood the code well enough to find defects a plausible-looking diff was hiding. Anyone can accept AI output; catching where it is wrong is the skill being assessed.

Q: What makes an AI-workflow writeup a strong interview artifact versus a weak one? Specificity and honesty. Naming real diffs, real defects, and real fixes — including where the model was confidently wrong — demonstrates comprehension and supervision. Generic claims like "AI sped me up" prove nothing, because they are true of everyone and show no judgment.