AI-DLC Interview Questions & Answers, by Role

Adding an AI coding assistant to Agile speeds up typing inside an unchanged process — it's still humans deciding what to build, sprint by sprint, with AI as a faster keyboard. AI-DLC restructures the process itself around three phases (Inception, Construction, Operations) where AI actively proposes requirements, architecture, and code, and the team's job shifts to validating and redirecting those proposals rather than authoring from a blank page. The distinction to make in an interview: Agile-plus-Copilot is velocity on the old model; AI-DLC is a different operating model.

Mob Elaboration is the structured session in the Inception phase where the whole team — not just a product owner — reviews and validates the AI's proposed requirements, questions, and units of work before anything moves to Construction. It exists because an AI agent working from an ambiguous or incomplete requirement will produce a confident, well-structured, and wrong implementation faster than a human would. Mob Elaboration is the checkpoint that catches a bad requirement before it becomes a bad architecture.

Process atrophy — teams that stop reflecting because the AI is generating so much, so fast, that oversight quietly becomes rubber-stamping. The methodology's human checkpoints (Mob Elaboration, Mob Construction, phase-gate sign-off) only work if people are still actively evaluating, not just approving. A strong answer names this risk unprompted, because it signals the candidate understands AI-DLC's discipline, not just its speed.

Not by lines of code shipped. Track whether context genuinely persists across sessions (are architectural decisions being re-litigated, or referenced?), whether the review cadence at Mob Elaboration and Mob Construction is substantive or ceremonial, and whether defect rates and rollback frequency are trending down as the team's fluency with the model increases. A programme that's "fast" but re-explaining the same architectural constraints every bolt hasn't actually adopted AI-DLC — it's adopted a faster autocomplete.

Context persistence — architectural decisions, requirements, and constraints being saved and carried forward across sessions rather than reset each time — is the mechanism that makes the three-phase model coherent instead of three disconnected AI conversations. Someone with real hands-on experience will describe specifically what artifacts get saved and where (plans, requirement documents, design decisions in the project repository) without prompting. If a candidate can only describe the phase names, that's a strong signal they've read about AI-DLC, not run it.

There's no defensible single number, and a candidate who gives one without qualification is guessing. What a strong answer describes instead is the sequence: agreeing the phase-gate artifacts before the first bolt, running the first Mob Elaboration deliberately slower than steady-state to build the review muscle, and treating the first two or three units of work as calibration rather than proof — the pilot's purpose is establishing whether the team's review discipline holds, not hitting a velocity number by a fixed date.

In a traditional Agile model, the architect typically sets direction upstream — reference architecture, architecture decision records — and reviews implementation after the fact, often once a sprint is already underway. In Mob Construction, the architect validates AI-proposed architecture and domain models live, before code exists, which moves the review from after-the-fact audit to a real-time gate. The skill that matters most shifts from writing the architecture document to reading a generated one critically, fast, and catching the plausible-but-wrong pattern before two teams have implemented it two different ways.

The same discipline that keeps consistency under any distributed model — a small set of binding constraints (integration patterns, data contracts, non-negotiable standards) that every team's AI agent is configured to respect, plus a shared, persisted context artifact that's the source of truth rather than each team's local session history. The risk under AI-DLC isn't that architecture drifts slower than usual — it's that it can drift within a single bolt if the constraint set isn't explicit and machine-readable, not just written in a wiki nobody's agent reads.

A team doing it well can show a specific instance where the AI's proposed architecture was rejected or substantially redirected — a domain boundary that didn't fit an existing bounded context, a dependency the AI proposed that violated a known constraint — with the reasoning recorded, not just the final approved version. A team that's rubber-stamping will only be able to produce approved diagrams; there's no evidence anyone pushed back.

The debt risk doesn't disappear — it moves, from slow accumulation you might catch in a quarterly review to fast accumulation that has to be caught inside the bolt it was created in. That means the review checklist needs the two or three debt patterns that matter most for the specific codebase made explicit and asked about directly at every Mob Construction session, rather than assumed as background diligence. What an interview is really testing is whether the candidate has that checklist, not whether they believe in principle that debt should be avoided.

Treating the AI's first proposal as a first draft to polish rather than a hypothesis to interrogate. A confident, well-structured, syntactically clean architecture proposal reads like a senior engineer's work, which makes it easy to under-scrutinize. Architects who do this well keep asking "what did the AI not have visibility into" as a standing question — that's usually where a proposal breaks: an existing integration, an unwritten convention, a constraint that lived in someone's head and never made it into the context.

Judgment, not authorship. The Product Owner's role shifts from drafting requirements line by line to validating that the AI's proposed requirements reflect actual business intent, catching the gaps an AI can't see (organizational politics, unstated constraints, competing stakeholder priorities), and making the prioritization calls the AI has no authority to make. The work gets harder to fake, not easier — a Product Owner who was hiding behind vague requirements has nowhere to hide when the AI asks direct, specific clarifying questions.

The criteria don't change — business value, data readiness, and technical complexity still matter — but the tempo does. Because Construction moves faster once Inception is validated, a poorly scoped use case now wastes less time in guesswork and more time in actual, wrong-direction build. That raises the cost of choosing badly, which raises the value of a structured, weighted prioritization pass before a use case ever enters Inception.

A validated context artifact at the end of Inception — the AI's requirements, assumptions, and open questions, reviewed and confirmed by the team in Mob Elaboration — before Construction begins. This is new relative to a typical Agile backlog item: it's a formal checkpoint, not a ticket description, and it's the record that everything downstream (architecture, code, tests) traces back to.

Whether they can articulate business intent precisely enough that an AI's clarifying question sounds like a reasonable follow-up rather than exposing a gap they hadn't thought through. A Product Owner used to writing vague acceptance criteria and letting a human developer fill the ambiguity in conversation will struggle in Mob Elaboration, where the AI asks direct questions in front of the whole team, in the room, in real time — there's no quiet side conversation to patch the gap afterward.

By tracking at two deliberately different cadences instead of forcing bolts into a sprint-shaped reporting box: bolts for team-level execution rhythm, and a slower cycle — weekly or fortnightly — for portfolio-level status, budget burn, and stakeholder reporting. Reporting programme status at bolt frequency creates noise; forcing bolt-level work into sprint-length planning boxes creates artificial waiting. A PMO that's adapted well can describe both cadences and explain why they're different.

The cost of getting Inception wrong on a low-priority initiative goes up — it now consumes less calendar time to discover the mistake, but the same amount of scarce senior review capacity, since Mob Elaboration needs the real team in the room, not a document sign-off. That raises the value of a structured, weighted prioritization pass before a use case is allowed to consume that Mob Elaboration capacity at all.

Resist collapsing it into one number — velocity or bolts-completed alone will overstate health if review is quietly becoming ceremonial. Report against a small set instead: whether context is genuinely persisting (a proxy for whether Construction is compounding or restarting), review substantiveness at Mob Elaboration and Mob Construction, and the defect and rollback trend. A maturity benchmark against defined stages, not a single self-reported score, is what lets a sponsor compare across teams honestly.

Correct the framing early and specifically: AI-DLC changes what governance looks at, not just its speed. The audit trail moves from meeting notes to persisted repository artifacts; sign-off shifts from a backlog ticket to a validated context artifact at the end of Inception. A stakeholder who hasn't been told this will assume the old governance model still applies and be caught off guard when it doesn't map cleanly.

Not "did the pilot go faster" but "did the pilot's review discipline hold under real deadline pressure, and is there evidence for that beyond the team's own report." A pilot that looked fast because Mob Elaboration and Mob Construction were treated as optional under time pressure isn't evidence AI-DLC works — it's evidence the team can skip the checkpoints that make it work. That's exactly the gap a formal adoption readiness assessment is built to catch before it scales.

It changes the confidence behind the estimate, not the underlying financial logic. Because Inception validates requirements and scope before Construction begins, the cost side of the business case is grounded in a reviewed context artifact rather than a rough sizing done before anyone looked closely at the problem. The stronger business cases show a range — a P50/P80/P90-style estimate — rather than a single confident number, because AI-DLC's speed doesn't eliminate estimation uncertainty, it just means you find out you were wrong faster.

A cost estimate that doesn't distinguish Construction-phase savings — real, and typically the headline number — from Operations-phase cost, which is frequently underestimated because it gets the least documentation attention in most AI-DLC material. A credible business case states its assumptions about ongoing model usage cost, review labor, and infrastructure explicitly, not just the build-time acceleration.

The natural gate points shift to align with the phase boundaries — funding a full Construction phase should follow a validated context artifact from Inception, not a rough proposal. This is a stronger gate than most traditional stage-gate models offer, because what's being reviewed is a specific, team-validated requirement set rather than a slide-deck estimate. A finance stakeholder who understands this asks to see that artifact before releasing the next funding tranche, not just a status update.

"What did we assume the AI could do that we haven't actually validated yet." A team that has run Mob Elaboration and Mob Construction on comparable work has real cycle-time and defect data to anchor the case; a team extrapolating from a vendor's marketing claim or a proof-of-concept demo is presenting a hope, not an estimate.

Neither cleanly. AI-DLC is a lifecycle model — Inception, Construction, Operations — not a set of ceremonies, so it doesn't prescribe standups or retros the way Scrum does. In practice, most adopting teams keep their existing cadence as the outer rhythm and run Mob Elaboration and Mob Construction as structured working sessions inside that cadence, typically replacing or absorbing backlog refinement and parts of sprint planning. A candidate who says "AI-DLC replaces Scrum" is oversimplifying; one who can describe exactly which ceremonies get replaced, which get repurposed, and which stay untouched is showing real facilitation experience.

Facilitate the same discipline they'd bring to any structured working session, aimed at a different failure mode. In Mob Elaboration, that means keeping the team from rubber-stamping the AI's proposed requirements — surfacing quiet disagreement, making sure the quietest voice in the room actually reviews the proposal rather than nodding along. In Mob Construction, it means watching for scope creep in what the AI proposes to build and keeping the session anchored to the validated requirement, not chasing an interesting tangent the AI introduces. The job is unchanged in kind — protect the team's thinking time — but the content being facilitated is AI output instead of a colleague's proposal, which changes the social dynamics of pushback.

Poorly, if left unexamined. Story points were calibrated against human effort and uncertainty; once AI absorbs a meaningful share of implementation, velocity trends can shift for reasons that have nothing to do with team capability, and a coach who keeps reporting velocity unchanged is reporting a number that no longer means what the organization thinks it means. The stronger answer: re-baseline estimation around review and validation effort — the work that's still human — rather than trying to force the old story-point model to keep describing a changed job.

The dependency-mapping discipline doesn't change, but the tolerance for stale dependency information shrinks. If one team's Construction phase compresses from days to hours, a dependency board updated at PI planning and left alone for a quarter will be wrong faster than it used to be. An RTE should expect to increase the cadence of cross-team sync specifically around Construction-phase handoffs, and treat the persisted context artifacts from Inception as the source of truth for interface contracts between teams, not the PI board.

Name the specific fear rather than arguing against a vague one. Most resistance to AI-DLC isn't about the AI — it's about status (does my judgment still matter if the AI proposes the architecture?) and pace (can I actually review this carefully at the speed Construction now moves?). A coach who addresses those two questions directly — showing where human judgment is still the binding constraint, and building review capacity into the cadence rather than assuming the team will absorb the new pace for free — gets further than one who treats resistance as a change-management problem to be pushed through.

The artifacts produced at each phase gate — the validated requirements from Mob Elaboration, the architecture and design decisions confirmed in Mob Construction, and the deployment records from Operations — form the trail, and they persist in the project repository rather than in meeting notes or chat threads. A governance-literate answer names where that trail lives and who is accountable for reviewing it, not just that a trail "exists."

Yes, and the honest answer says so directly. Higher-velocity AI-generated code, dependencies, and infrastructure-as-code templates require continuous automated scanning — static analysis, software composition analysis, secrets detection, and infrastructure scanning — because manual line-by-line review cannot keep pace with agent-generated pull request volume. A candidate who claims AI-DLC has no security implications hasn't thought about it seriously; a strong answer names the specific control categories that need to scale.

The same dimensions used to evaluate any AI-enabled vendor — statement-of-work and contract quality, delivery capability, governance and performance track record, knowledge transfer plan, and exit readiness — with one addition specific to AI-DLC: ask them to show, not describe, a Mob Elaboration or Mob Construction session artifact from a prior engagement. Vendors who've only read the AI-DLC methodology paper won't have one.

Not "is it working" — "what's our evidence that human oversight is still substantive at each gate, and who signs off on that judgment." Speed without a credible answer to that question is the definition of a governance blind spot, and a candidate who reflexively leads with velocity metrics instead of oversight evidence is telling you something about their priorities.

A bug-fix request should not silently become a refactor of adjacent modules — that's the specific failure mode a well-run programme guards against by scoping an agent's file-edit permissions to the unit of work actually under review, and requiring a separate, explicit approval step before it touches anything outside that boundary. This discipline is sometimes referred to in AI-DLC practitioner circles as reining in agent overreach; whatever it's called locally, a candidate should be able to name the enforcement mechanism, not just the principle.

A Verification Gate is a mandatory human approval checkpoint within a Bolt at which the AI cannot proceed without explicit sign-off — the mechanism, not the metaphor, behind "human in the loop." AWS's own documentation puts this at 10 to 26 gates per Bolt depending on complexity, which is a useful number to press a candidate on directly: someone who's actually configured gates in a real programme will have an opinion about where in that range their work sits and why; someone who hasn't will be surprised the number is that high, because most AI-DLC descriptions gloss over how granular the checkpointing actually is.

Less line-by-line authorship, more architectural review and specification precision. In Mob Construction, the developer's job is to evaluate the AI's proposed domain model, code, and tests against the validated requirements from Inception — catching where the AI's proposal drifts from an unstated convention, an existing integration pattern, or a dependency the AI doesn't have visibility into. The skill that matters most shifts from typing speed to judgment speed.

By treating context as a first-class artifact, not a chat history. That means committing plans, requirements, and design decisions to files in the project repository at defined checkpoints, so a new session starts by reading that saved state rather than re-deriving it from scratch or, worse, from the AI's own unverified assumptions. This is the practical answer to the abstract phrase "persistent context" that shows up in every AI-DLC description.

Explicitly bounding what an AI agent is authorized to change, so a request to fix a bug doesn't silently expand into a refactor of adjacent modules. A concrete control: scoping an agent's file-edit permissions to the specific unit of work under review, and requiring a separate, explicit approval step before it touches anything outside that boundary. A candidate who can only define the idea abstractly, without naming an enforcement mechanism, hasn't implemented it.

By checking whether they trace back to the validated requirements from Inception and the domain model from Construction — not by checking whether they pass. An AI agent can write tests that pass against its own, possibly wrong, implementation, because the same agent that writes the code often writes the tests. The verification discipline AI-DLC assumes is closer to continuous, requirement-traced review than to a green checkmark in CI.

Fast, structured skepticism — reading a plausible, well-formatted AI proposal and correctly identifying the one assumption it got wrong, inside a live Mob Construction session, without slowing the room down. This is a different skill from writing code well, and different from reviewing a colleague's pull request at leisure; it's closer to the pace and posture of live code review under time pressure, and most engineers new to AI-DLC underestimate how much practice it takes.

Ask the candidate to describe a specific Mob Elaboration or Mob Construction session that went badly — not a success story. Someone with real experience will have a concrete failure to describe: a requirement the team approved too fast, an architecture proposal that looked right and wasn't. Someone reciting the methodology paper will pivot to generic benefits language because they have no incident to draw on.

Ask directly: "When would you not recommend AI-DLC for a project?" A candidate who understands the methodology's actual constraints — small, well-understood maintenance work where the phase-gate overhead exceeds the benefit; teams without the discipline to run substantive review sessions rather than rubber-stamp them — will answer without hesitation. Unconditional enthusiasm for any methodology is itself a red flag.

Inability to name what breaks when a phase gate is skipped. AI-DLC's three phases and their associated review rituals exist specifically to catch failure modes — a bad requirement propagating into a bad architecture, an architecture proposal shipping without team validation. A senior candidate should be able to describe the failure each gate prevents, from direct experience or close observation, not just recite the gate's name.

Treat the bare skill listing as neutral, not a signal, and ask one specific follow-up in the first phone screen: "Which phase did you spend the most time in, and what was the hardest part of that phase specifically." A candidate with real experience will answer with texture — a phase, a difficulty, a reason — inside a few seconds. A candidate who pauses to reconstruct an answer from the methodology's structure, rather than recall it, is a signal worth weighting.