I shipped a feature I can’t fully explain to my own team.
Something weird happened last week.
I’ve been working on another product alongside Murror — a side project we’re experimenting with, built almost entirely through AI. I’m not a developer. I can’t read most of the codebase. But I shipped a feature that three users have already told me feels “exactly right.”
And I cannot explain to my team how it works.
Not the user-facing part — I designed that. I know what it should do, why it matters, what emotion it should trigger. I wrote the spec as a conversation with an AI agent. The agent built it. I tested it. It worked. I shipped it.
But when our CTO asked me to walk through the implementation, I froze. I couldn’t explain the architecture. I didn’t know which database calls were happening or why the loading state worked the way it did. I just knew it felt right when I used it.
This is the part nobody talks about with AI-assisted building: the imposter syndrome isn’t about whether you can build things. You clearly can. The imposter syndrome is about whether you “deserve” to have built them.
Here’s what I’ve been sitting with:
When there’s no engineering handoff — when the person who understands the user’s emotional need is also the person shipping the code — something changes in the product. The translation layer disappears. Nobody is interpreting your intent through a Jira ticket.
But the cost is this disorienting feeling of owning something you can’t fully explain. I know what it does. I don’t know how it does it. And I’m learning to be okay with that.
Building Murror taught me that the best product decisions come from understanding your users deeply. Building this side project is teaching me that you don’t need to understand your own codebase deeply to build something people love. You just need to understand the problem.
Anyone else navigating this weird middle ground?
Replies
To me, AI agents feel like fellow colleagues. Especially now, after fully remote work, it often feels as if you’re just talking to a colleague who will implement the feature. So I honestly don’t see why anyone would feel they need to “deserve” anything here - you’re doing your job, and a “colleague” is doing theirs. In your case, it could just as well have been a freelancer, and that would instead be considered a compliment to your management skills.
Murror
@artk the freelancer analogy is actually really helpful. I hadn't thought about it that way, but you're right — nobody questions whether a project manager "deserves" credit for a feature built by their team. the remote work point hits too. when everything is async and text-based already, the line between "talking to a colleague" and "prompting an agent" gets surprisingly thin. thanks for the perspective shift.
this resonates but also makes me a little nervous, honestly. understanding the problem is the harder skill and I get why that's the real ownership. but the day it breaks in production at 2am, someone has to actually read that code, and if it's not you it's whoever's on call reading a stack trace for logic they've never seen either. I think the middle ground is knowing enough to ask the agent the right debugging questions even if you can't write the fix yourself
Murror
@omri_ben_shoham1 that 2am scenario is exactly what keeps me up honestly. you're right that the middle ground matters — I've been getting better at asking the agent diagnostic questions like "what could cause this to fail" or "walk me through the data flow here." it's not the same as reading the code yourself, but it's a different kind of literacy. learning to debug through conversation instead of through code. still early in figuring that out though.
the "deserve" framing is interesting because it's really a question about where credit lives. if the value was in knowing exactly what emotion the feature should trigger and recognizing when the output matched that, you did the hard part - most engineering teams have the reverse problem, perfect implementation of a spec nobody validated against a real user need. the not-knowing-the-database-calls part would worry me more the day you need to change the feature though, not the day it breaks. debugging with an agent that has the same blind spot you do is one thing, but iterating on something you can't reason about at all tends to get slower each round, not faster
Murror
@galdayan this reframe really stuck with me — "where credit lives." you're right that most teams have the reverse problem. I think that's what made the experience feel so disorienting. the iteration point is the one I need to sit with most though. right now each round still feels faster because the agent remembers context. but I can see how that could hit a wall the moment something fundamental needs to change and neither of us can reason about why.
@monatruong_murror that wall moment is the part I'd want a plan for before it happens rather than after. maybe worth periodically having the agent write a plain-language explainer of a chunk of the codebase, not because you need it day to day, but so there's a paper trail you can hand your CTO when something breaks and speed matters more than pride
Murror
@galdayan the paper trail idea is really smart. we actually haven't done this yet but I can see how it would solve the CTO walkthrough problem I mentioned — instead of me trying to explain architecture I don't fully understand, I could just point to a document the agent generated while the context was fresh. the "speed matters more than pride" framing is exactly the mindset shift I needed. going to try this on the side project first and see if the explainers hold up under real debugging pressure.
@monatruong_murror good luck with it - the real test is probably a debugging session at 2am when something's actually broken, not a calm demo. let me know if the explainer holds up under that kind of pressure, genuinely curious.
@monatruong_murror "a different kind of literacy" is a good way to put it. the diagnostic-question approach probably works fine for logic bugs, but Gal's point above about iteration is the one I'd actually worry about long term - debugging is a one-time cost, but not being able to reason about a feature every time you want to change it compounds. curious if you've hit that wall yet or if it's still early days for the side project.
Murror
@omri_ben_shoham1 still early days for the side project, so I haven't truly hit that wall yet. but I can feel it approaching. right now iteration is fast because the features are small and relatively independent. the moment something needs to touch multiple parts of the system at once — that's probably where not being able to reason about the whole architecture will start to compound, exactly like you're describing. I think the honest answer is I'm one major refactor away from finding out whether this approach scales or breaks.
@Mona Truong "debug through conversation instead of through code" is a good way to put it. the risk I keep running into with that approach is the agent can answer "walk me through the data flow" confidently and wrong at the same time - it'll narrate a plausible-sounding flow that isn't actually what the code does. have you caught it doing that, and if so what tipped you off that the explanation didn't match reality?
Murror
@omri_ben_shoham1 yes, caught it once so far. the agent described a flow where data went through a validation step before saving, and it sounded completely reasonable. what tipped me off was the UI — the error message I expected from that validation never appeared when I tested with bad input. turns out the agent had invented a validation layer that didn't exist. the thing that scares me is how confident the explanation was. I only caught it because I happened to test that exact edge case. if I'd just read the explanation and moved on, I would've believed it.
@Gal Dayan that's the practical fix I hadn't thought of - a plain-language explainer written before you need it costs almost nothing compared to writing one under pressure the day something breaks. curious if you'd trust that explainer at face value though, or would you always want to spot-check it against the actual code once, given the same agent could narrate its own architecture wrong the same way it narrates a data flow wrong.
@Mona Truong "diagnostic questions instead of reading code" is basically a new skill in its own right though, and probably a harder one to teach a team than code review ever was. do you know yet whether it transfers - like if someone gets good at asking "what could cause this to fail" on this feature, does that skill carry over to a totally different part of the codebase, or is it more tied to how well they know this specific feature's behavior?
Murror
@omri_ben_shoham1 honestly too early to say for sure. on the side project, I've only gone deep on two features so far. the "what could cause this to fail" question does seem to transfer — it's more of a thinking pattern than domain knowledge. but "walk me through the data flow" gets way less useful when you're asking about a part of the codebase neither you nor the agent has touched recently. I think the skill that actually transfers is knowing when the agent's answer feels too clean — that gut check for "this sounds right but probably isn't" is something you develop regardless of which feature you're looking at.
@Mona Truong the invented validation layer is a great example because it wasn't even lying, exactly, it was pattern-matching what a system like that usually looks like and presenting it as fact. now that you know that failure mode exists, has it changed how you operate day to day - do you spot-check every explanation the agent gives you, or only pull that thread when something feels off, like the gut check you mentioned? checking everything sounds exhausting but checking nothing is how you got here in the first place
Murror
@omri_ben_shoham1 you nailed the tension perfectly. I've landed somewhere in between — I don't spot-check everything because you're right, that defeats the point. but I've started developing a feel for when to pull the thread.
the biggest tell is when the agent's explanation is too neat. real systems have messy edges and the agent tends to smooth those over. so now when I get a walkthrough that sounds like a textbook, that's actually my signal to test the edge cases manually.
it's definitely not a solved problem. but I think this is just what building with AI looks like right now — you develop a new instinct for what to trust and what to verify, and that instinct gets better with each false positive you catch.
@mona_truong "one major refactor away from finding out" is such an honest place to be. the small-and-independent phase is genuinely the easy part, it's usually the first cross-cutting feature that forces you to actually understand your own architecture instead of just trusting it works. good luck when that day comes.