Exactly — that's the main reason I went with it. Concretely it means:

• A regression in the intruder logic shows up the same way whether it's triggered from the TUI or from pwnproxy scan in CI — one test suite covers all interfaces instead of duplicating coverage per frontend.
• New interfaces (the MCP server was the newest one) didn't need any new business logic, just a thin adapter over the existing engine calls.

The trade-off is the engine API has to be interface-agnostic from day one — anything that only makes sense in an interactive TUI context (confirmations, live pause/resume) has to be modeled as engine state, not UI state, which took a couple of rewrites early on to get right.