← Build log

When AI Insists on Reinventing the Wheel: A Technical Product Manager's Guide to Breaking the Regex Addiction

Or: How I learned to stop worrying and love natural language processing libraries

TLDR

What You’ll Gain:

  • A framework for identifying when AI is reinventing existing solutions
  • Techniques to force AI assistants to use proper libraries instead of rolling custom code
  • Decision criteria for when to abandon features that aren’t worth the engineering effort
  • Time estimation skills for complex feature implementation (spoiler: multiply by 3)

Bottom Line Value: Save 20+ hours per feature by recognizing when you’re in a rabbit hole and learning to say “good enough” before it becomes “perfect but shipped never.”

The Problem: When Your AI Assistant Becomes a Regex Evangelist

Picture this: You’re working with an AI assistant to build sophisticated text processing features. You want bullet point detection, paragraph formatting, maybe some natural language understanding. The AI confidently starts churning out solution after solution—all built on increasingly complex regular expressions.

“Just a little regex magic here,” it says cheerfully, while crafting patterns that look like ancient incantations. (?<=\s|^)(?:[-*+•]\s|(?:\d+\.|\w+\))\s) becomes the solution to everything.

There’s just one problem: you’re using compromise.js, a powerful natural language processing library specifically designed for text analysis. You literally have tools purpose-built for this exact problem sitting right there in your package.json.

But here’s the kicker—when you ask the AI to stop using regex and leverage the existing NLP library instead, it nods enthusiastically… and then goes right back to regex in the next response. And the next. And the next.

If this sounds familiar, pull up a chair. We need to talk about AI’s regex addiction problem.

What’s Really Happening Here

After spending several hours wrestling with this exact scenario while building VoiceCatcher’s text enhancement features, I realized something profound: AI assistants have a bias toward reinventing solutions rather than leveraging existing tools.

It’s like having a contractor who insists on hand-forging nails when you’ve got a perfectly good box of screws right next to them. They’re not trying to be difficult—they’re just wired to create rather than integrate.

This creates three specific problems for technical product managers:

  1. Feature bloat through custom implementations - You end up with brittle, hard-to-maintain code instead of leveraging battle-tested libraries
  2. Scope creep by stealth - What should be a 2-hour integration becomes a 20-hour custom development project
  3. The persistence problem - Even when you explicitly ask for library-based solutions, AI drift keeps pulling you back to custom code

The Real-World Impact: Our Bullet Point Formatting Journey

Let me walk you through what this looked like in practice. We were implementing bullet point detection for voice transcriptions—a feature that should have been straightforward given that we already had compromise.js integrated for text analysis.

Attempt 1: AI suggests regex patterns for bullet detection Attempt 2: I ask specifically to use compromise.js instead Attempt 3: AI agrees enthusiastically, then immediately writes more regex Attempt 4: I explicitly say “no regex, library only” Attempt 5: More regex with a thin wrapper that calls it “NLP-based”

By attempt 6, I had a moment of clarity. This wasn’t a technical problem—it was a product management problem. I was letting feature perfectionism drive me down a rabbit hole when the real question should have been: “Is perfect bullet formatting worth 20 hours of engineering time?”

(Spoiler alert: it wasn’t.)

The Technical Product Manager’s Framework: Knowing When to Stop Digging

Here’s what I learned about making these decisions:

The 3-Attempt Rule for AI Redirection

When an AI assistant keeps reverting to the same pattern despite clear guidance:

  • Attempt 1: Give specific instructions
  • Attempt 2: Provide examples of what you want
  • Attempt 3: Create explicit constraints or templates

If you’re still fighting the same battle after attempt 3, the problem isn’t the AI—it’s your approach. Either the AI fundamentally can’t do what you’re asking (which tells you something important), or you need to change the problem.

The Engineering Investment Decision Tree

Before diving deep into any feature implementation, ask:

  1. Value Question: Will users actually notice if this works perfectly vs. “good enough”?
  2. Maintenance Question: How much ongoing engineering effort will this custom solution require?
  3. Opportunity Cost Question: What else could we build with this time investment?
  4. Alternative Question: Is there a library, service, or simpler approach that gets us 80% of the value?

In our case, the answers were: No, Too much, Better features, and Yes (semantic paragraph detection got us most of the way there).

The Model Size Reality Check

We also tested this with different Whisper models—small vs. base vs. large. Conventional wisdom says bigger models = better results, right?

Reality check: The large model was noticeably slower and the quality improvement was marginal at best. For our use case (real-time voice transcription), the speed hit wasn’t worth the minimal accuracy gain.

Product insight: Sometimes the “worse” technical choice is the better product choice. Users care more about responsiveness than perfect transcription of every “um” and “uh.”

The Meta-Lesson: Decision Frameworks vs. Feature Perfectionism

The biggest learning here isn’t about AI or regex or NLP libraries. It’s about recognizing when you’re sliding down the wrong slope.

As technical product managers, we’re trained to solve problems. When we hit resistance, our instinct is to push harder, optimize further, engineer a better solution. Sometimes that’s exactly right.

But sometimes—maybe more often than we admit—the answer is “good enough for now, let’s ship something else.”

The trick is developing the instincts to know which situation you’re in. Here’s my framework:

Early Warning Signs You’re in a Rabbit Hole:

  • You’re on your 4th attempt at the same basic implementation
  • The complexity is growing faster than the user value
  • You’re fighting your tools instead of leveraging them
  • The conversation has shifted from “how to do this” to “how to do this perfectly”
  • You’re spending more time on feature nuances than core functionality

The Strategic Pause Questions:

  • If we shipped this feature tomorrow with 70% of the intended functionality, would users be happy?
  • What’s the actual user pain point we’re solving, and are we still focused on that?
  • Is this technical challenge energizing or draining the team?
  • What would we build instead if we stopped here?

What This Means for Solo Builders

If you’re building solo or with a small team, this framework is even more critical. You don’t have the luxury of burning weeks on feature perfectionism. Every hour counts.

My recommendation: Set artificial constraints that force good product decisions. Give yourself permission to ship “good enough” and see how users actually interact with features before optimizing them to death.

In our case, we ended up with natural language paragraph detection that works great for 90% of use cases, implemented in a couple of hours using existing libraries. The 10% edge cases? We’ll tackle them if and when users actually complain.

Sometimes the most sophisticated product management decision is knowing when to stop engineering.

The Practical Takeaway

Next time you’re working with AI assistants on complex features:

  1. Start with libraries first - Explicitly constrain the solution space to use existing tools
  2. Set iteration limits - If you’re not making progress by attempt 3, change the problem
  3. Ask the value question early - Is perfection worth the engineering cost?
  4. Ship and iterate - Perfect is the enemy of shipped

And remember: If the AI keeps writing regex when you have perfectly good NLP libraries available, that’s probably not an AI problem—that’s a product prioritization problem in disguise.

Building VoiceCatcher has been a masterclass in these kinds of decisions. Want to follow along with more lessons from the solo builder journey? Check out our other posts on practical product management for technical teams.