The Disappearing Middle of Software Work

Software work used to have a clear center of gravity: writing the code.

A team would spend weeks debating architecture, days in pull reviews, hours debugging. The middle—implementation—absorbed most of the time, attention, and craft. It was the work.

That middle is collapsing.

AI agents now produce working code from goals, context, and tasks. They operate independently. They don't need pair programming, they need clear instructions. The IDE is becoming a code viewer, not a code writer.

Linear founder Karri Saarinen recently articulated this shift: when the middle disappears, value migrates to the ends—defining intent upfront and verifying outcomes after.

This reframes what "product work" actually means.

What the Middle Used to Do

The middle wasn't just typing. It was the forcing function for clarity. An engineer reading an ambiguous spec would walk over to the PM's desk and ask: "What do you actually mean by this?" That conversation—the clarification loop—happened because implementation was hard and slow.

When implementation is instant, that loop disappears. Nobody walks over to ask clarifying questions when shipping a prototype takes four minutes.

The result: teams build faster but define worse. Speed without intent produces the Vibe Coding Hangover.

The Two Ends

With the middle automated, the work concentrates at two points:

Both ends require something the middle used to provide for free: precision. When engineers translated specs into code, they were forced to resolve ambiguity. Remove that step, and ambiguity goes straight to production.

The Front: Clarity of Intent

"Design is not about artifacts or tools. It is about forming and shaping clarity of the intent through ideas, exploration, research, and discussion." — Karri Saarinen

This is the hardest shift for product teams. The bottleneck is no longer "how do we build this?" but "what exactly should we build?"

A traditional spec might say: "Add a checkout flow." That was enough when a human engineer would ask twenty clarifying questions during implementation. An agent won't ask. It will execute literally against whatever you give it.

This is the problem the Intent Layer addresses—not by drawing pixels (that's Figma), but by structuring the software's behavior and purpose into machine-readable specs before agents touch the code.

Structure Serves Both Sides

Karri makes a point that often gets overlooked: structure in tools reduces ambiguity for humans and agents equally.

Linear provides task structure—assignee, status, cycle. But task structure isn't enough for an agent to write correct code. It needs domain structure: user flows, data requirements, edge cases, success criteria.

These are complementary layers:

• Task structure answers: Who is doing what, and when?
• Domain structure answers: What does "done" mean, precisely?

Without domain structure, agents hallucinate the details. With it, they execute against a contract.

The Back: Pressure on Verification

When the middle produced code slowly and under supervision, review was manageable. A team might ship a feature a week. A senior engineer could eyeball the diff.

Now agents produce large volumes of output with minimal supervision. The review surface explodes. You can't eyeball your way through ten features generated in a day.

This is where structured intent serves a second purpose: acceptance criteria. You're not just reviewing raw code—you're verifying it against documented intent. The spec defines what success looks like, which closes the loop between the front and back ends.

Without that loop, you're left with the worst outcome: fast code that nobody can evaluate.

The Organizational Question

This might be the most important dimension. Defining intent clearly is not a solo activity. It's not one PM writing better specs in a vacuum.

"This might not be an individual task, but an organizational one: how can you create these conditions for the whole product team." — Karri Saarinen

Scaling intent means every team member—PM, designer, engineer—operates from a shared source of truth for what gets built and why. Not a shared Notion doc that drifts. A structured, versioned, machine-readable system that agents and humans both consume.

That's the infrastructure gap we're building Pathmode to fill.

The middle of software work was the craft for a long time. As it disappears, what remains is the work at the ends: forming the right intent upfront, and verifying the outcome actually meets it.

The teams that master both ends will build the best products. The teams that only master speed will build the most code.