If you’ve spent any time recently writing detailed product requirement documents or meticulously crafting ticket specifications, you’ve probably no...
For further actions, you may consider blocking this person and/or reporting abuse
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.
Haha now we finally know that Ben is an AI Agent 😂
I think nowadays everyone relies on it to fix everything that we miss.
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.
I completely agree that the role of engineers is changing. Engineers who simply execute predefined tasks may no longer be as valuable as they once were.
However, I believe that engineering judgment will become even more important. Understanding the system architecture, scalability, availability, security, and the trade-offs between short-term delivery and long-term technical debt—and then making the right decision based on all of that context.
I am currently working on a full replacement of a complex production system that has accumulated significant technical debt. One of the most difficult parts is "determining whether an existing behavior is intentional or simply a bug".
AI alone cannot easily make that distinction.
The answer may depend on background information hidden in Notion or Google Docs, historical knowledge known only by the PM, or organizational and political decisions understood only by certain stakeholders. Deep domain understanding is essential to connect all of those pieces.
Until recently, engineers had to spend a great deal of their time simply writing code, so it was difficult to dedicate enough attention to this kind of deeper understanding. Now that some of the tedious implementation work is becoming easier, we can spend more time understanding the product and the domain.
That also allows us to take on challenges that previously would have been extremely difficult—such as gradually replacing a large production system while keeping it operational. Personally, I think this makes the current era of software engineering incredibly exciting.
I think that final 10% may become one of the main reasons engineers continue to matter.Because it is not easy, an interesting reversal may happen: as generating code becomes easier, the value of engineers with deep understanding and strong technical judgment may actually increase.
I still have a lot to learn myself, but I want to keep developing that depth of understanding.
I think there's one more shift happening here: context is becoming the new bottleneck.
AI has made implementation dramatically cheaper, but it hasn't made understanding the problem any cheaper. If anything, it has increased the value of people who understand the domain well enough to know when the generated solution is subtly wrong.
I've found that the hardest production bugs now aren't in the code that AI wrote they're in the assumptions between systems. The implementation is locally correct, but it violates a business rule, an architectural constraint, or an invariant that was never written down.
So I agree that domain ownership is becoming more important, not less. The person with the deepest context is increasingly the one who can move the fastest, because they spend less time writing specs and more time making the right decisions.
Freelancer here, so I've been living in the end state of this article for years,
and it's worth saying what it actually feels like.
There is no spec phase for me. No PM, no handoff, no ticket. The client says
"customers keep ordering the wrong size" and I go build something. Full domain
ownership, zero coordination overhead — exactly the setup you're describing as
competitive.
What nobody warns you about is that the 90% and the 10% are both yours, and you
grade your own work. I've shipped things that were locally correct and solved
the wrong problem entirely, and there was no one in the room to catch it. Not
because I was careless — because it was my own frame doing both the specifying
and the checking.
The clients don't catch it either. They can tell you when it's wrong six months
later, not when you're building it.
So domain ownership is real leverage, but it's also a single point of failure
that I don't think collapses cleanly at team scale either. Curious whether you
see teams building anything back in deliberately, or whether that's just the
trade you accept for speed.
Great article. I completely agree that context has become more valuable than simply writing code. Developers who understand the business, users, and architecture can move much faster and make better decisions than those who only follow detailed specifications.
AI can generate code quickly, but it still can't replace deep domain knowledge, good engineering judgment, and high quality standards. Those skills are what turn a working prototype into production-ready software.
I see this every day while working with digital products and scripts from marketplaces like CodeCan.net. Two products may have similar features, but the one built by someone who truly understands the problem usually offers better architecture, cleaner code, and a much better user experience. Context is the real competitive advantage.
Thanks for the great article!
I’m currently building cloudbanana.de and am actively looking for feedback to improve it. If you have a minute, I’d really appreciate your thoughts on the project!
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.
Turns out the real seniority test was never how fast you could write code. It was how little context you needed explained twice. AI can generate the implementation, but it still cannot attend the last six months of product meetings. Yet.
Genuinely : WHAT IS THE POINT OF THIS ARTICLE ?
Basically for the new people coming here, here is a better version: The problem is probably bad specs and excessive handoffs, not written shared context.
Great breakdown! I've been using Supabase and Vercel for my projects — the free tiers are incredibly generous. For AI coding assistance, I also recommend MonkeyCode (monkeycode-ai.net) — it pairs really well with these free tools.
Hi Ben,
It's probably the wrong place to ask this, but do you guys have some sort of shadow-ban concept? I just created an account and started posting but I don't think my posts are visible. I don't see any views (but mine) and they don't show up in the search engine.
This resonates with my experience. Finding the right balance between automation and understanding is key.
Great article!
good stuff!