AI-Allowed Live Coding: A New Rulebook, Not a Cheat Code

A format that didn't exist a few years ago, and doesn't have settled rules yet

Every other topic in this roadmap assumes a fairly stable, well-understood round with known evaluation criteria. AI-allowed live coding is the exception: it emerged directly in response to AI coding assistants becoming good enough that banning them outright started to feel like testing a skill nobody uses on the job anymore, and different companies have converged on genuinely different rules. Some explicitly permit AI tools for certain rounds and ban them for others (Stripe's own published process, for instance, varies tool policy round by round). Some — OpenAI among them, unsurprisingly — treat competent AI-tool use as an expected, evaluated skill rather than a permitted exception. The one thing you can rely on: you cannot assume the policy, you have to ask. Confirm explicitly, before the round starts, whether AI tools are allowed, required, or banned, and if allowed, whether that's unrestricted or scoped to specific tools or use cases. Walking in with the wrong assumption in either direction — using a banned tool, or awkwardly avoiding an available one — is an unforced error this format specifically creates room for.

What's actually being scored is not "can you use the tool"

The naive fear about this format is that it's testing prompt-writing instead of engineering — in practice, well-run versions of this round score almost the opposite: your judgment about when to lean on the assistant, when to override or ignore its suggestion, and how well you can verify, explain, and defend code you didn't type character-by-character yourself. A candidate who accepts every suggestion without reading it carefully, or who can't explain why a particular AI-generated line does what it does, fails this round regardless of whether the resulting code happens to work. A candidate who uses the assistant efficiently for boilerplate, catches a subtly wrong suggestion, and can explain every line of the final result — including the parts they didn't type — passes it. The skill under test is closer to code review under time pressure, applied continuously to your own generated output, than to "coding," full stop.

Everything else in this roadmap is the actual prerequisite here

This is the reason the topic sits as a capstone rather than standing alone: verifying an AI suggestion instead of blindly accepting it draws directly on Debugging Methodology's hypothesize-and-check discipline — treat a suggestion as a hypothesis about correct behavior, not a fact, and confirm it the same way you'd confirm any other hypothesis, with a test or a reproduction, before moving on. Catching a subtly wrong suggestion in code you're reading for the first time is exactly the skill built in Reading Code Like a Reviewer — the same severity-first triage (correctness and side effects before style) applies whether the code in front of you came from a human PR or a completion you just accepted. And explaining, out loud, why a generated block of code does what it does — as it's being generated, not after — is Working Under Observation's continuous-narration habit, applied to a collaborator that happens to be a model instead of a person.

Concrete habits that read well in this format

• Narrate your prompt and your reasoning for it, not just the code that comes back — "I'll ask it to scaffold the endpoint handler since that's boilerplate, but I want to write the validation logic myself since that's the part I actually want to reason through carefully" makes your judgment visible instead of leaving the interviewer to guess why you delegated one part and not another.
• Read every suggestion before accepting it, at a pace visibly slower than your typing pace — accepting a multi-line completion within a second of it appearing reads as not having actually read it, regardless of whether it happens to be correct.
• Verify non-trivial suggestions the same way you'd verify your own code — run it, test the edge case you'd be suspicious of, don't take "it looks right" as sufficient for anything beyond genuinely trivial boilerplate.
• Correct it out loud when it's wrong, rather than silently fixing it and hoping the interviewer didn't notice the model's mistake — "that's not quite right, it's not handling the empty-list case, let me fix that" turns a model error into a moment that demonstrates your review skill, which is a net positive outcome from an ostensibly bad suggestion.
• Be honest about your own reliance on it if asked directly, in the same spirit as the take-home defense round — "I use it heavily for boilerplate and I'm comfortable defending everything it produces because I review it as I go" is a stronger answer than either pretending not to use such tools or being defensive about using them.

The trap in the other direction: refusing to use it well

Because "am I supposed to look independently capable" anxiety is common, some candidates under-use an explicitly permitted assistant, avoiding it even for genuine boilerplate to "prove" they can do it manually — in a round that explicitly allows the tool, this usually reads as not understanding the format, not as a display of strength. If the policy is "AI allowed," efficient, judicious use of it is the expected baseline, not a red flag; the signal you're being measured on is the judgment and verification layered on top of that use, not whether you touched the tool at all.

Where this roadmap ends and judgment begins

There's no fixed rulebook for this format yet, and won't be for a while — company policies will keep shifting as the tools and the market's comfort with them evolve. What's durable is everything this format draws on: read what you're given (whether it's an unfamiliar codebase or a model's suggestion) before trusting it, verify before you move on, narrate your reasoning continuously, and manage the clock deliberately. Those are this entire roadmap's actual throughline — AI-allowed live coding just happens to be the format that currently asks for all of them at once, applied to a collaborator none of the older interview formats had to account for.