AI-assisted development and AI-DLC

Verified 2026-08. This is now a standard interview topic, and one vacancy names specific tools. The strong answer is about how the process changes, not which IDE you prefer.

The tool landscape

Names an interviewer may drop, and what distinguishes each:

The axis that matters is not vendor but how much structure the tool imposes. Kiro is spec-first: you agree requirements and a plan before code. Antigravity is agent-first: several agents work in parallel and you review artefacts. Claude Code sits between, with an explicit plan step and hooks for deterministic enforcement. Which suits you depends on the work — spec-first pays off on well-defined features, agent-first on broad parallel changes.

AI-DLC

AWS’s open-source AI-Driven Development Lifecycle: a methodology, not a tool, that restructures delivery around AI agents doing the drafting and humans validating.

Three phases:

“Bolts” replace sprints. A bolt is a work cycle measured in hours or days, not weeks: the AI proposes a plan, the team validates it, the agent executes, the results are reviewed. The premise is that when drafting collapses from days to minutes, a two-week sprint boundary is the wrong unit of planning.

The load-bearing principle is human validation at each step, not “AI writes the code”. The bottleneck moves from typing to reviewing, and the methodology is explicit that the human decision points are where quality is preserved.

Treat it as one named answer to “how does AI change your process”, not as the only one. Being able to name it and explain the bolt concept is worth more than adopting it wholesale.

What actually changes in the process

Specification becomes the expensive part. When implementation is cheap, ambiguity in requirements is what costs you. Spec-driven workflows exist because “make the API faster” produces something; “reduce p99 on this endpoint below 200ms without changing the response schema” produces the right thing.

Review is the bottleneck. A team can generate far more code than it can carefully review, and unreviewed generated code is the largest new risk. Practices that help: smaller changes, agents that explain their reasoning, and automated gates that do not depend on a human noticing.

Deterministic enforcement matters more. Formatters, linters, type checkers, tests and pre-commit hooks stop being hygiene and become the mechanism that keeps generated code in bounds. Anything you would be unhappy for an agent to skip belongs in a hook or a CI gate, not in a prompt. See ../backend/26_code_quality/04_pre_commit_and_review.md.

Tests become more valuable, and their design more so. A strong suite is what lets you accept a large generated change. But tests written by the same agent that wrote the code can encode the same misunderstanding — so specify behaviour independently, and review test assertions with more care than implementation.

Context is the constraint. Agents work well on codebases that are navigable: clear module boundaries, consistent conventions, a project-level instructions file, and documentation of the non-obvious decisions. The practices that make a codebase good for humans make it good for agents, which is a convenient alignment.

Where it does not help

Worth saying out loud, because uncritical enthusiasm reads as inexperience:

• Novel algorithmic work with no prior art
• Decisions requiring organisational context the agent cannot see
• Anything where the cost of a subtle error is high and detection is hard — concurrency, financial calculation, security boundaries, clinical logic
• Very large refactors without a strong test suite, where nothing verifies the change

The senior framing: AI shifts the distribution of engineering effort from writing toward specifying, reviewing and verifying. Judgement about what to build and whether it is right is more valuable, not less.

Interview angle

• “How do you use AI tools in your workflow?” - be specific about where they earn their place: scaffolding, test generation from a spec, navigating an unfamiliar codebase, mechanical refactors across many files. Then name where you do not use them, which is what separates a considered answer from an enthusiastic one.
• “What is AI-DLC?” - AWS’s AI-driven development lifecycle: Inception, Construction, Operations, executed in “bolts” of hours or days rather than sprints, with AI drafting and humans validating at each step. The point is the validation gates, not the generation.
• “What is the biggest risk with AI-generated code?” - review capacity. Teams can produce more than they can carefully review, and plausible-looking wrong code passes a skim. The mitigations are smaller changes, deterministic automated gates, and independently specified tests.
• “How do you keep quality up?” - move enforcement into hooks and CI where it cannot be skipped: formatting, linting, type checking, tests, dependency scanning. A prompt asking for good practice is a request; a hook is a guarantee.
• “Has it changed how you architect systems?” - clearer boundaries and consistent conventions matter more, because they are what makes a codebase navigable by an agent. It also lowers the cost of writing the adapter layers and tests that good architecture asks for, which makes the disciplined option cheaper than it used to be.
• “Which tool would you pick?” - answer by the structure you want: spec-first when requirements need pinning down before code, agent-first for broad parallel changes, terminal-based agents for work in large existing repositories. Naming a vendor without a reason is the weaker answer.