If you’ve spent any time recently writing detailed product requirement documents or meticulously crafting ticket specifications, you’ve probably noticed a frustrating paradox:
Thoroughly specifying an issue is often 90% of the work required to solve it.
By the time you’ve gathered the context, mapped out the edge cases, accounted for user flows, and detailed the expected behavior precisely enough for someone else to execute without friction, you’ve already done the heavy mental lifting. Translating that comprehensive spec into code is increasingly becoming the easy part.
This dynamic is quietly reshaping how software gets built, how teams collaborate, and what it actually means to be a competitive developer today.
The Death of the Developer-as-Cog
Back in the day, software development often operated on an assembly-line model. A Product Manager wrote a detailed spec, handed it off to an engineering lead, who broke it down into sub-tickets, which were then handed off to developers.
The developer’s job was essentially to act as a cog in the machine: take the ticket, write the code according to spec, and move it to QA.
To be clear, this model was never ideal. It created silos, bred disinterest, and led to bloated communication loops. But it technically worked.
Today, operating that way isn't just inefficient—it’s non-competitive. When the friction between ideation and execution drops, the overhead of the traditional handoff becomes the main bottleneck. The games of telephone between product definition and code delivery slow teams down to a crawl while faster, context-rich teams lap them.
The Friction of the "Spec Phase"
If writing a complete spec takes 90% of the cognitive effort, having a constant handoff between "the person who thinks of the task" and "the person who implements the task" creates massive drag.
This is why domain ownership has become table stakes.
When developers truly own a domain—meaning they deeply understand the problem space, the user, the underlying system architecture, and the business goals—they bypass the awkward, high-overhead "spec phase." They don't need a 10-page PRD to build the next feature because they already hold the context in their head. They can move fluidly from one problem to the next, making real-time trade-offs and inline product decisions without waiting for a spec to be baked.
Redefining the Lines Between Dev and PM
This shift doesn't mean Product Managers disappear, but it does mean the boundaries of the roles are becoming far more fluid:
- The Developer as PM: In many areas, the developer is the product manager. Because they hold domain context, they identify what needs to be built next, spec it in their mind as they go, and ship it.
- The PM as Builder: In other workflows, a PM might leverage low-code tools, scripts, or AI models to take a feature 90% of the way to completion—building a functional prototype, shaping the data flow, or laying out the initial structure. The developer then steps in to handle the remaining 10%.
Why is that last 10% so critical? Because even simple features require deep technical introspection: architecture alignment, performance at scale, edge-case hardening, security, and long-term maintainability.
The Moving Goalpost of "Competitive Software"
It’s tempting to look at current trends and assume that as models and tools improve, that final 10% will simply vanish—that software will eventually build and maintain itself at the press of a button.
That view misses how software markets operate.
As raw code generation becomes cheaper and faster, the baseline for what constitutes "competitive software" continuously moves up. Features that used to take three months now take three days, which means customer expectations rise accordingly. The line of what makes a product stand out shifts to higher levels of polish, deeper integrations, tighter performance, and better user experience.
The last 10% doesn't disappear; it just becomes more nuanced.
The Bottom Line: Problem Context and Quality Standards
We are moving away from an era where value is measured by syntax output or the ability to execute against rigid, pre-packaged specifications.
The real leverage in modern software engineering comes down to two things:
- Problem Context Management: Your ability to internalize the user's needs, the business goals, and the system architecture so you can make high-judgment decisions on the fly without waiting for a spec.
- Quality Thresholds: Your ability to look at a 90%-complete solution—whether produced by an AI, a teammate, or a PM—and know exactly what it needs to cross the finish line to be production-ready, scalable, and resilient.
Tools will continue to evolve, and the mechanics of writing code will keep changing. But the engineers who cultivate deep domain context and maintain uncompromising standards for quality won't just stay competitive—they’ll be the ones setting the pace.
Top comments (7)
Either way, good stuff :)
😅
I always use some amount of AI to flesh out and/or edit any longer posts these days—but I think I have a decent process and it's definitely written by me for all intents and purposes. I've always loved the emdash—so that's an issue with my writing these days no matter what.
That fair. Thought I want to do this since it's funny the more I think about this. This may either open a can or worms or everyone is chill about it lol.
The "spec is 90% of the work" framing hits home. I have been thinking about this from the collaboration-matching angle. When you find the right person to work with, the spec overhead shrinks because shared context already exists. The problem is that context about how someone actually works (their quality thresholds, communication style, problem domains they own deeply) rarely travels beyond the team that built it. This is exactly what I was trying to solve with Opportunity Skill. Making the context your agent accumulates about you discoverable by other agents, so the 90% transfer happens before the first message, not after ten standups.
The spec-phase handoff was doing two jobs, and domain ownership only removes one of them. One job was coordination overhead: the drag of moving context from the head that has it to the head that does not. That one is pure friction and worth deleting. The other was involuntary. The handoff forced the frame out of one head and onto a surface where someone who did not share it could catch a wrong assumption before it shipped. That was not friction, it was a free audit of the 90%, and it happened to be bundled with the drag.
Keep the context in one head and you lose both. The wrong-problem and wrong-assumption mistakes, the ones that live in the 90%, are exactly the ones a single owner is structurally blind to, because it is their own frame doing the specifying and the checking. Which flips the last-10% point in a useful way. You are right that the 10% stays hard, but it stays hard and visible: you can test scale, you can scan for the security hole. The 90% is the part that goes dark under ownership, because the only reader it ever had was the handoff you just removed. The teams that stay fast and stay good will be the ones who notice the spec phase was two things, and keep the audit on purpose after automating the drag away.
"Context" here 100% meaning traditional uses of the term — not in the AI sense.
The domain-ownership shift rings true, and the sharpest open question here is what the spec handoff was quietly buying you: an independent audit of your own assumptions. Collapse the roles and you keep the speed, but you lose the second person who used to catch the assumption you could not see from inside the problem.
The fix is not to add the reviewer back, that is just the handoff returning. It is to move the audit from a stage into the system: the assumptions a spec used to state in prose become executable, contracts and invariants and checks that fail the moment reality diverges from what you assumed. Then it runs continuously and for free instead of once at a handoff, and one context-rich owner can move fast without flying blind. That matters more as the model writes more of the 90 percent, not less, because a model will confidently build on a wrong assumption and never raise its hand. The last 10 percent you point at is partly this: not just polish, but the checks that let one person own the whole loop and still get told when they were wrong.