Skip to content

Squeezed From Both Sides

The PM can build what you build, and AI can automate the parts they can't. Your current work sits in the overlap zone where both pressures converge. This is the hardest squeeze to name because it comes from two directions at once.

What convergent pressure actually looks like

Most engineers experiencing this squeeze feel it as a vague anxiety about relevance before they can name the specific mechanism. The feeling is right. The diagnosis is just incomplete.

From the side, product managers now ship working prototypes using AI tools like Cursor, Bolt, and Lovable. They already had the user context, the business rationale, and the product vision. AI gave them hands. A PM with good product sense and AI tools is, functionally, a strong engineer wrapped inside someone who already knows what the product should do.

From below, AI tools are automating the structured, spec-driven implementation work that used to require a human engineer. The boilerplate, the CRUD endpoints, the ticket-shaped features. Nearly 70% of routine programming tasks have already seen the effects of automation, and the percentage keeps climbing.

Each pressure alone is manageable. The convergent version is different. When the PM builds a working demo over a weekend and AI handles the tickets that fill your backlog, the spec-to-code pipeline that defined your role is becoming something either side of the old handoff can handle on their own.

Why the overlap zone is the most exposed position

Engineers in other squeeze positions have one clear direction to move. If the side pressure is dominant, you build systems depth. If the floor is rising, you shift toward judgment-heavy work. But when both pressures converge, the natural question becomes: where do I go?

The answer is up. The ceiling above both pressures consists of four specific areas that prototypes and automation cannot touch:

  • Architecture at scale. The PM's prototype was never designed to handle ten thousand concurrent users, a database that grows by a gigabyte a day, or a retry storm that cascades across three services. You know what breaks under load because you've watched it break.
  • Production weather. The 2 AM page, the cascading failure, the moment you choose between restarting the service and rolling back the deploy. That judgment forms under real pressure and cannot be simulated.
  • Second-order consequences. Every technical choice has downstream effects that surface months later. The library that locks you into a migration path. The data model that makes a future feature impossible. Prototypes don't live long enough to encounter these.
  • The second mind. When someone shows you working code, you catch the failure modes the builder couldn't see alone. That adversarial review reflex requires a different brain looking at the same problem. Solo builders, whether PMs or AI agents, cannot disagree with themselves.

If none of these describe your current work, that's the signal. The overlap zone is telling you exactly what to build next.

The honest audit

Pull up your last ten completed tickets. For each one, ask two questions. Could a PM with Cursor have shipped this? Could an AI coding agent have handled it without your judgment?

If the answer to both is "probably" for more than half your tickets, the convergent pressure is already compressing your role. That's not a verdict. It's a measurement. And measurements are useful precisely because they tell you where to invest.

The tickets where both answers are "no" reveal where your real value sits today. The gap between the demo and the production system, the question nobody was assigned to ask, the failure mode that only surfaces under real traffic. That's the work to protect and expand.

What to do when the pressure is convergent

Do not try to outrun the PM on implementation speed. That race is over. AI tools equalized it. Competing on velocity against someone who already has the product context and now has the coding tools is a losing position.

Instead, move toward the work that requires disagreement and depth. Be the person who walks into the room after the demo works and asks: what happens when this hits real users? Where does this break at scale? What does this quietly prevent us from doing in a year?

Concretely: volunteer for the migration nobody wants. Take the on-call rotation. Trace a production incident backward to the design decision that caused it. Spend a full week only evaluating, not building, and notice how uncomfortable that feels. The discomfort reveals the gap between your builder identity and the judgment-heavy role that's actually harder to replace.

The convergent squeeze is the hardest to sit in, but it's also the clearest signal. When both sides of the old handoff can do what you do, the only durable move is to do what neither of them can.