Architect today for a loosely defined future

WHAT THIS TESTS The interviewer wants the balance between evolvability and YAGNI. A loosely defined vision invites two failures: rigid architecture that cannot bend, or speculative over-engineering that builds for imagined futures at real present cost. Good answers show you design for change along the right axes only.

A GOOD ANSWER COVERS Start by naming where change is likely. For integrating with any AI service, the volatile axis is the provider: models, APIs, and capabilities will churn. Isolate that volatility behind a stable, provider-agnostic interface using a ports-and-adapters style, with an anti-corruption layer translating each vendor's quirks into your domain terms. Keep decisions reversible: prefer configuration over hard-coding, keep modules loosely coupled so a swap is local, and defer irreversible commitments until you must make them. Use fitness functions, automated checks, to protect properties that must endure, like latency budgets or the rule that no vendor SDK leaks into core domain code. Crucially, build only the first concrete adapter now; the abstraction is justified by one real implementation plus a credible second, not by a hypothetical ten.

COMMON WRONG ANSWERS Building a sprawling plugin framework for providers that do not exist yet. Equally, hard-coding a single vendor so deeply that any change is a rewrite. Both ignore the cost of being wrong about the future.

LIKELY FOLLOW-UPS How do you avoid speculative generality while staying flexible? What is an anti-corruption layer? How do fitness functions enforce evolvability over time?

ONE CONCRETE EXAMPLE You define an AIProvider interface with generate and embed methods in your domain language, implement an adapter for the one provider you use today, and route all calls through it. When a second provider appears next year, you add one adapter behind the same interface, no core changes. You did not prebuild a marketplace of plugins; you isolated the one axis that truly varies.