AI Prompts for Writing Regex

Picture this: you're a backend developer, you ask an AI for a regex to extract phone numbers, you test it on five examples, they all pass, and you ship it. Two weeks later, support tickets reveal it's been silently missing every number with an extension, every international format, and every number with parentheses. The regex wasn't wrong on your test cases — it was wrong on reality, and your test cases were a tiny, tidy subset of reality. This is the trap with AI prompts for writing regex, and this case study shows how to avoid it.

The Problem a Developer Faced

Tom, a backend developer at a logistics company, needed to extract tracking numbers from a flood of customer emails. Tracking numbers came in several carrier formats, sometimes with spaces, sometimes with hyphens, sometimes embedded in a sentence. He asked an AI for a regex, tested it against a handful of emails he had open, and deployed it into the email-parsing pipeline.

It worked on his samples. In production, it captured maybe 60% of the tracking numbers. The other 40% used formats his handful of test emails happened not to contain. Because the pipeline didn't flag misses — it just silently found nothing — nobody realized how much was slipping through until a customer complained about a package the system claimed it had never seen.

The Wrong Approach

Here's the prompt Tom used:

Write a regex to extract tracking numbers from text.
Here's an example: "Your tracking number is 1Z999AA10123456784"

The AI dutifully wrote a pattern that matched that exact shape — a UPS-style number. It had no way to know about the FedEx and USPS formats also flowing through, because Tom only gave it one example. The prompt asked the model to generalize from a single data point, and it generalized narrowly, exactly as you'd expect.

⚠️ Common mistake: Giving the AI one or two examples and expecting a regex that handles all real-world variations. A regex is only as good as the range of inputs it was designed against. One example produces a pattern that matches that one example's shape and quietly ignores everything else. You have to show the model the variety you actually expect.

Tom spent an afternoon confused about why production results didn't match his testing before realizing his "tests" had never included the formats that were failing.

The Correct Prompt

Tom rebuilt the request to expose the model to the real range and to make it think about failure:

Write a regex to extract shipping tracking numbers from
email text. The numbers appear in these formats:
- UPS: 1Z999AA10123456784 (18 chars, starts 1Z)
- FedEx: 12 or 15 digits, sometimes spaced in groups
- USPS: 20-22 digits, sometimes with spaces
They may be surrounded by text, have trailing punctuation,
or use spaces/hyphens as separators.

Requirements:
- Match all three formats
- Provide 10 test cases: valid numbers of each type, plus
  tricky non-matches (order numbers, phone numbers) that
  should NOT match
- Explain what each part of the regex does
- Note any format you're NOT confident about

What this does: It gives the model the real variety of inputs, demands test cases including things that should not match, and asks the model to flag its own uncertainty — turning a blind pattern into a tested, documented one.

The result matched over 95% of real tracking numbers, and the explicit non-match tests caught a bug where the first draft accidentally matched long order numbers too.

⚡ Pro tip: Always ask for test cases that should NOT match, not just ones that should. False positives are as damaging as false negatives — a regex that matches phone numbers when you want tracking numbers is quietly polluting your data. Negative test cases are where these bugs surface before they reach production.

Results and What Changed

The rebuilt regex lifted capture from 60% to over 95%, and — just as important — the misses were now visible. Tom added a step that logged any email where no tracking number was found, so the remaining 5% surfaced as a reviewable list instead of silent gaps. Within a week he'd spotted two more rare formats and added them.

The broader change was to the team's process. They stopped treating regex as write-once and started treating it as something you test against a representative sample and monitor in production. Every regex now ships with its test cases saved alongside it, so when a new format appears, updating the pattern and re-running the tests takes minutes instead of triggering a fresh round of guesswork.

⚡ Pro tip: Save a regex together with its test cases as a single unit. When the pattern eventually needs to change — and it will — the tests let you modify it confidently instead of fearing you've broken an old case. A regex without tests is a liability; a regex with tests is maintainable.

How to Apply This to Your Situation

The specific problem was tracking numbers, but the approach generalizes to any regex task.

A data analyst cleaning messy CSVs should give the AI the actual messy values — the ones with inconsistent formatting — not the clean ideal, because the whole point is handling the mess.

A security engineer writing input-validation regex should focus hardest on the non-match cases, since a validation regex that's too permissive is a vulnerability. Ask specifically: "what malicious inputs might slip past this?"

A log-parsing engineer should paste real log lines, including the malformed ones, and ask the regex to handle or explicitly skip them. Real logs are far messier than any documentation suggests.

Here's a reusable regex prompt skeleton:

Write a regex to [task]. Real inputs vary like this:
[paste 5-8 real, varied examples including edge cases]
Requirements:
- Provide 10+ test cases: valid matches AND things that
  must NOT match
- Explain each component of the pattern
- Flag any input variation you're unsure about
- Note the regex flavor (PCRE, JavaScript, Python)

What this does: The varied real examples plus mandatory negative tests plus the regex-flavor note close the three gaps — narrow input range, false positives, and dialect mismatches — that break most generated regex.

⚡ Pro tip: Always specify the regex flavor. JavaScript, Python, PCRE, and Go regex differ in lookbehind support, named groups, and escaping. A pattern that works in one can throw an error in another, and the model defaults to whichever flavor it happens to guess.

Next Steps

Take your next regex task and, before prompting, collect five to eight real, varied examples — including the awkward ones. That input variety is what separates a regex that works in the demo from one that works in production. Then demand negative test cases and monitor for misses.

The developers who write regex they can trust aren't regex wizards; they've built a habit of testing against real variety and saving patterns with their tests. PromptABCD is where that habit lives — store your regex prompt skeleton, keep your validated patterns with their test cases attached, and reuse them the moment a similar parsing task appears. Tom keeps his tagged by format type, and says having the negative-test-case requirement built into his template is what finally made his regex reliable. A regex tested against reality beats one tested against five tidy examples every single time.

There's a broader lesson here about how to prompt for anything pattern-based, not just regex. Any time you ask a model to generalize a rule from examples — a validation function, a parser, a data transformation — the quality of the output is capped by the variety of examples you provide. Give it clean, similar examples and it learns a narrow rule. Give it the full messy range, including the cases that break the obvious approach, and it learns a rule that survives reality. Regex just makes this especially visible because the failures are so binary: a pattern either matches or it doesn't, with no partial credit.

⚡ Pro tip: When a regex feels too complex to trust, ask the model to break it into a commented, multi-line version using the extended/verbose flag (x flag in most flavors). A regex you can read line by line is a regex you can maintain; a dense one-liner is a regex you'll be afraid to touch six months from now.

Think about the roles that live and die by this. A compliance analyst validating account numbers can't afford false positives, so their prompts lean hardest on negative test cases. A content engineer extracting data from scraped HTML faces enormous input variety, so their prompts lean on pasting real, messy samples. A backend developer parsing log formats needs the regex-flavor note most, because their code runs in a specific language whose regex dialect has its own quirks. Same skeleton, different emphasis depending on which failure mode would hurt you most. Knowing your dominant failure mode is what turns a generic prompt into a sharp one. Once you can name your dominant failure mode, the rest of the prompt writes itself, and your regex stops being a source of quiet production surprises. A pattern you trust is worth building carefully, because you only build it once but you rely on it every day it runs in production.