I shipped a feature I can't fully explain. It works better than anything I've spec'd.
Something strange happened last week while working on a side project we've been building alongside Murror.
I described what I wanted a feature to do — not how, just what. The AI built it. I tested it. It worked. Not just "worked" — it handled edge cases I hadn't even thought of.
Then came the uncomfortable part: I couldn't explain the implementation to someone if they asked.
At Murror, I've always been the person who writes the spec, reviews the logic, understands every decision. But on this other project, I'm operating completely differently. I describe intent. The AI interprets. I evaluate the outcome. The code in between? I trust it the way I trust a calculator — I don't need to see the long division.
This isn't a confession. It's a pattern I keep noticing. The people building the most interesting products right now aren't the ones who understand every line of code. They're the ones who understand the problem so deeply that they can tell whether a solution actually works — without needing to have written it.
Product sense is becoming the new technical skill.
The question that keeps me up: when the person who designs the experience can ship it directly — no handoff, no translation layer, no "that's not what I meant" — what happens to product quality?
In our case, it got better. Uncomfortably better.
Has anyone else found themselves building something they can't fully explain?
Replies
"product sense is becoming the new technical skill" is a fascinating idea. Do you think this trend will make deep technical expertise less valuable, or just shift where it's applied?
Yes - and I think you've named the real shift. The bottleneck moved from "can I build this" to "can I describe what good looks like." The new risk isn't implementation bugs - it's specification gaps. When the AI handles edge cases you didn't spec, sometimes it does it brilliantly. Sometimes it does it in a way you'd hate, and you only find out in prod. The skill that's becoming rare isn't writing code - it's being precise enough about outcomes that you can actually evaluate whether the thing you can't explain is doing the right thing.
I’ve definitely experienced this. The weird part isn’t that the AI wrote the code — it’s realizing your role shifts from builder to evaluator. The bottleneck becomes judgment, not implementation.
This matches a shift I keep hitting: the skill isn't writing the code, it's telling whether the result is right without having written it. The trap is that "I evaluated the outcome" quietly slides into "it looked plausible," and plausible is where AI work fails. What saves me is writing down one concrete thing the output has to pass before I see it, so judgment doesn't drift into vibes.
Murror
Reading all of these and honestly feeling seen.
@Nitesh Kumar I don't think deep technical expertise becomes less valuable — I think it splits. There will always be people who need to understand what's happening under the hood. But there's now a second path: people who are deeply technical about the problem, even if they can't read the solution. That's the shift I'm living.
@Gal Dayan "specification gaps" is the perfect framing. I've started thinking of my role less as a product manager and more as a quality auditor for intent. The spec IS the product now — the code is just the compilation step.
@Amard Sonal Yes — builder to evaluator. And the uncomfortable part is that evaluation is harder than building in some ways. When you wrote the code, you knew its limits. When you didn't, you have to discover them.
@Andrii Krugliak "so judgment doesn't drift into vibes" — I'm stealing that. We've started doing something similar: before we prompt, we write down what "done" looks like in concrete terms. It forces you to think before you build, which ironically is what good engineering always demanded.