TL;DR:
With AI-assisted coding, everything moves so fast that the biggest skill now is knowing when to think before you code.
Always start by asking the AI: “What are the existing solutions? What are the tradeoffs?”
Then you decide. Then you build.
Skip this step and you’ll reinvent the wheel — beautifully — like I did.
I spent 2 hours building a Chrome extension with AI.
It worked perfectly. Every edge case handled. Tests passing. The dopamine hits were real.
Then I asked one question that changed everything:
“Wait... has nobody else already solved Gmail thread detection?”
Spoiler: yes. There’s a maintained SDK (InboxSDK) that does exactly that.
The AI never mentioned it. Not once. In 2 hours of pair programming.
The Setup
I needed a Chrome extension to auto-click Gainsight buttons in Gmail — a simple automation to save our CS team some time.
I fired up Claude Code:
“Build me a Chrome extension that clicks Gainsight buttons in Gmail threads.”
Claude: “Sure! Let’s use DOM manipulation to detect Gmail views and find the buttons...”
And we’re off.
The Vibe Coding Flow
Here’s the thing about AI-assisted coding in 2025: it feels so empowering it should almost be regulated like steroids.
The barrier to entry is basically zero.
You describe what you want, the AI writes it, you test it, it breaks, you describe the bug, it fixes it. Rinse and repeat.
Within 2 hours, I had:
- Gmail URL detection with regex (
#inbox/thread-id
vs#sent/thread-id
vs#search/query/thread-id
) - MutationObserver detecting DOM changes when Gmail loads content
- Button state detection (
state-default
,state-loading
,state-logged
) - Retry logic for race conditions with third-party extensions
- A full Chrome extension that actually worked
I was in the zone. That pure flow state where problems → solutions → more problems → more solutions.
The Problem with Flow
Flow is dangerous when you’re going in the wrong direction.
I was so focused on solving each bug that I never stopped to ask the bigger question:
“Is this even the right approach?”
We spent minutes debugging Gmail’s search URLs, regex mismatches, and MutationObserver loops. Each fix felt smart. Each bug, a dopamine hit.
But every “win” moved me deeper into the wrong path.
The Moment of Clarity
After an hour of AI-assisted debugging, the extension worked flawlessly. But ... Until when ?
I finally closed VS Code, looked up from my screen, and thought:
“Wait… is it really possible that nobody has figured out Gmail integration before?”
That’s when I re-opened Claude Code and asked explicitly:
“Okay, but is there an existing library for Gmail extensions?”
Claude: “Oh yeah, there’s InboxSDK. It’s actively maintained by Streak, handles all the Gmail view detection. The team that built this extension probably should’ve used it.”
Bro. The “team” was YOU.
It felt like a scene straight out of Memento.
The thing is brilliant at writing code, but can't figure out what it did 5 minutes ago. Disorienting contrast.
Back to our point: the problem wasn’t Claude Code — it was how I was using it. Not guiding it enough.
The AI Has Blinders On
Claude Code is the smartest developer I’ve ever worked with.
It can debug race conditions, write complex regex, optimize DOM performance — all in seconds.
But it has tunnel vision.
It solves exactly what you ask, perfectly.
What it won’t do is stop and ask:
“Hey, should we research if this problem has already been solved?”
Unless you explicitly tell it to.
It’s like pair programming with a racehorse wearing blinders: incredible speed and focus in one direction, zero peripheral vision.
What Went Wrong (and What to Do Instead)
My mistake wasn’t technical — the code worked.
It was strategic: I reinvented Gmail thread processing from scratch when a mature SDK already existed.
AI will happily build whatever you ask for.
It won’t say:
“Hold on — maybe this isn’t worth building.”
Because it doesn’t know your context. It just executes.
The real skill now isn’t avoiding mistakes — mistakes are cheap.
It’s building a methodology that reduces throwaway code.
Here’s what I should have done instead:
Step 1: Research phase (15 min)
Me: "What are the main approaches for Gmail Chrome extensions?"
AI: "You can use InboxSDK, Gmail API, or raw DOM manipulation..."
Me: "What are the tradeoffs?"
AI: "InboxSDK is maintained, handles edge cases, but adds dependency..."
Step 2: Decision (you, not the AI)
“Use InboxSDK for production stability.”
Step 3: Implementation (1 hour)
InboxSDK.load(2, 'APP_ID').then(sdk => {
sdk.Conversations.registerThreadViewHandler(threadView => {
// You’re in a thread, do your thing
});
});
Done.
If you don’t tell the AI to research first, it will just start coding — perfectly.
And you won’t realize you’re reinventing the wheel until it’s too late.
The Broader Pattern
This isn’t just Chrome extensions.
How many people are using AI to build:
- Custom auth systems (when Auth0 exists)
- Form validators (when Zod exists)
- State managers (when Zustand exists)
- UI kits (when shadcn/ui exists)
The AI will build all of it — flawlessly — without ever suggesting you might not need to.
AI makes you feel competent even when you’re making strategic mistakes.
The code runs, tests pass... but is it maintainable? Future-proof? Or just cool throwaway code?
The Takeaway
The barrier to building is lower than ever.
But the importance of knowing what’s worth building has never been higher.
Think before you start. (It’s surprising how often that advice applies in life.)
Ask about existing solutions.
Let the AI present options.
Then you decide what to build.
💡 AI builds fast. You decide what’s worth building.
Questions for You
- Have you built something with AI only to discover you shouldn’t have?
- How do you balance “just start coding” vs. research?
- Am I just a noob who should’ve known about InboxSDK?
Drop your experiences below — curious how others are navigating this.
Top comments (0)