You ask AI to build a feature.
It writes the code. The tests pass. You click through the app.
Everything works.
Then someone asks:
“Why did you build it this way?”
And you open the AI chat again.
That’s a warning worth paying attention to.
Working code is only the beginning
Imagine AI builds your payment webhook.
A successful payment arrives. The customer gets access. Perfect.
But what happens when:
- The same event arrives twice?
- The database fails halfway through?
- Events arrive in a different order?
The happy path can work while important failure cases remain broken.
You need enough understanding to recognize the difference.
The cost appears later
Code you don’t understand becomes harder to change.
A small feature request turns into another prompt. That change breaks something else. You paste the error back into the chat.
Soon, you’re accepting fixes without knowing what they affect.
Every change becomes harder to judge.
AI can still help you debug. But you need a way to decide whether its answer makes sense.
Try these three checks before merging
1. Explain the logic
Describe what the code does in plain language.
Where does the data come from? What changes? What happens if a step fails?
If you get stuck, investigate that part.
2. Change one requirement
Suppose a customer now has two subscriptions instead of one.
Can you identify which parts need to change?
You don’t need to remember every line. You should understand where the behavior lives.
3. Test a failure
Try a duplicate request, an expired token, or a failed database write.
Check whether the result matches what you expected.
A passing demo shows that one path works. Failure tests help reveal what you missed.
Use AI to strengthen your understanding
After generating a feature, ask:
“Explain the assumptions in this code, identify likely failure cases, and show me how to verify them.”
Then check those answers against the code, documentation, and actual behavior.
Treat the explanation as something to investigate, too.
You don’t have to write every line yourself.
You do need enough understanding to maintain what you ship.
If your AI assistant disappeared tomorrow, could you maintain the code you shipped today?
Top comments (3)
The payment webhook example is a good one, because passing tests can hide some pretty serious consistency issues. Take a webhook handler that writes a payment record and then grants access to a subscription. If the process crashes between those two operations, a retry can leave the system in an inconsistent state unless the flow is designed around idempotency and recovery.
I’d go a step further than asking whether a developer can explain the code. Can they explain which invariants the system must preserve when requests are duplicated, events arrive out of order, or a transaction partially fails? That’s where understanding the implementation really matters. You can ask AI to describe the logic all day, but being able to trace the state transitions, identify the failure windows, and prove the behavior with integration tests is a different level of understanding. The real test isn’t whether you can explain what the code does on the happy path. It’s whether you know what guarantees it provides when the system starts failing.
The "change one requirement" check is the one I wish I'd done earlier. As a solo founder I leaned on AI hard for a parsing flow, and it worked fine until I needed to support a second resume format. That's when I realised I didn't know where the behaviour actually lived, so every fix became another prompt.
What helped me: before merging, I write two or three lines in the PR description saying what happens on failure. If I can't write them, I'm not ready to ship it. Your closing question is a good gut check too.
good