How do you work with AI tools?

Asked in nearly every 2026 interview. It is not a question about which tools you’ve tried — it’s about whether you’ve thought about where you keep judgement and how your review practice changed.

What they’re actually testing

Both extremes lose. Dismissing the tools reads as incurious; delegating judgement reads as dangerous.

The structure of a good answer

Where I lean on it heavily:

• Boilerplate and scaffolding — a new service skeleton, a test harness, migration files.
• Unfamiliar API surfaces — faster than reading a whole doc site to find the three calls I need.
• Test generation, especially edge cases I’d have missed. It’s good at enumerating what could go wrong.
• Rewriting between forms — a shell script into Python, a callback API into async.
• Explaining unfamiliar code when joining a codebase.
• Review pre-pass: “what’s wrong with this diff” before I ask a colleague.

Where I keep control:

• Architecture and data modelling. These decisions are expensive to reverse and depend on context the model doesn’t have — team, roadmap, existing systems.
• Anything security-sensitive. Auth, crypto, permissions. I read those lines with more suspicion than my own.
• Debugging real production problems. The model doesn’t know our system. It confidently proposes plausible causes, which is the worst possible failure mode when you’re under time pressure.
• Performance work. It optimises what looks slow, not what profiling proves is slow.

What changed in how I work:

• I write tests first more often. When a model generates the implementation, the tests are the specification, and having them first means I’m reviewing against something rather than eyeballing.
• Smaller diffs. It’s easy to generate 400 lines that look right. I keep changes reviewable, because I have to actually review them.
• I read more code than I write, so review skill matters more than it used to.
• I ask for the approach before the code. If the plan is wrong, the code being clean doesn’t help.

The honest failure story

Have one ready — it’s the part that makes the rest credible.

Something like: a generated function looked correct and passed its tests, but used a library API in a way that was subtly wrong under concurrency — it worked in tests because tests were single-threaded. Caught in review by someone who knew that library well. The lesson: generated code fails in ways that look like working code, so “the tests pass” is a weaker signal than it used to be.

That’s a better answer than a story about it producing obvious nonsense, because obvious nonsense isn’t the real risk.

Practical points that signal experience

• Context is the bottleneck, not the model. Time spent giving it the right files and constraints pays back more than a better prompt.
• Project-level conventions — a CLAUDE.md, .cursorrules or equivalent — stop it re-litigating style decisions in every session.
• Licensing and provenance matter for generated code in a commercial product.
• Never paste secrets or customer data into a tool without checking the data policy and retention terms.
• Agentic tools raise the stakes. Something that edits files and runs commands needs a scoped working directory and review before commit, not after.

Interview angle

• “How do you use AI in your work?” — name where you lean on it (boilerplate, unfamiliar APIs, test generation, first-pass review) and where you don’t (architecture, security, production debugging, performance), then say what changed in your practice: tests first, smaller diffs, more reviewing than writing.
• “Has it made you faster?” — on some things substantially, on others not at all. It compresses the mechanical parts; it doesn’t compress understanding the problem, and the review burden grew. Claiming a blanket multiplier is not credible.
• “What are the risks?” — code that fails in ways resembling working code, so passing tests is weaker evidence than before. Plus confidently wrong debugging suggestions, licensing questions, and data leaving your boundary.
• “How do you review AI-generated code?” — the same as any code, with extra suspicion in security-sensitive areas and around concurrency, where errors look correct. Small diffs, and ask for the approach before the implementation.
• “Do you worry it will replace engineers?” — the mechanical parts of the job compressed; the judgement parts didn’t. Deciding what to build, how it should be structured, and what an acceptable trade-off is — those are still the work, and there’s more code to review than before.