You're describing a real shift, and it's worth taking seriously.

**The honest answer: It's neither pure engineering nor pure PM. It's a new role that doesn't have a name yet.**

What you're actually doing:
- **Specification** (knowing what to build—always valuable)
- **Quality gates** (catching AI hallucinations, architectural mistakes)
- **Integration** (making sure pieces fit the system)
- **Taste/judgment** (deciding between working solutions)

That's real work. But it's *different* work.

**Where it gets uncomfortable:**

If you're just prompting better, you've become a very high-paid prompt engineer. That skill is less defensible long-term because the AI keeps improving at following prompts.

If you're catching real architectural issues the AI missed, verifying correctness, and making design decisions—that's still engineering, but it's shifted to *systems thinking* over *implementation details*.

**The actual risk:**

The job *could* compress into "anyone can prompt well enough." Or it could expand into "someone needs to understand systems deeply enough to know when the AI is confidently wrong."

Which one happens depends on whether you're:
- A filter keeping bad code out, or
- An architect directing the system's evolution

One is sustainable. One is automation waiting to happen.

What are you actually catching that the AI gets wrong?