Bots Before the Boom.

If you were online in the early 2000s, you probably remember SmarterChild. It lived in your AIM or MSN Messenger buddy list and you could just... talk to it. Ask it for the weather. Get movie times. Check sports scores. Millions of people chatted with it every day, and plenty had no idea they weren't talking to a person.

No GPT. No BERT. No neural network of any kind. SmarterChild ran on pattern matching: regular expressions and decision trees that routed your input to the right handler and returned something that felt, against all reasonable expectations, pretty smart.

How a Regex Can Feel Like Understanding.

It's easier than you'd think. The main challenge is mapping all the routes a conversation could take. Testing with friends is the most useful thing you can do at this stage. You define an intent and write a pattern that matches the ways people tend to phrase it. Weather, for instance, might be triggered by something as direct as "what's the weather in Dallas" or as roundabout as "what do you think about conditions in Chicago right now." Input matches, you extract what you need, look up the data, return the answer. To the user, the bot understood them.

SmarterChild covered a wide taxonomy of intents:

• Weather and news
• Sports scores
• Movie times and entertainment
• Dictionary lookups and stock quotes
• Horoscopes and more

The breadth made it feel general. The patterns made it accurate within each domain. And because users were typing short questions into a chat window, inputs naturally stayed easy to match. The interface shaped the language, which shaped the whole experience.

ELIZA worked the same way back in 1966. Joseph Weizenbaum's program simulated a therapist by reflecting user statements back as questions using pattern substitution. A pattern like I feel (.*) returned "Why do you feel \1?" Users found it so convincing that Weizenbaum was genuinely unsettled by their trust in it. The pattern just needs to match well enough that the person keeps going.

AIML Took It Further.

ALICE, built by Richard Wallace in the late 90s, extended this into a full framework. AIML (Artificial Intelligence Markup Language) was an XML format for writing pattern-response pairs with support for:

• Variables and conditionals
• Context carried across turns
• Recursive and referential responses

You could write a bot that remembered your name, changed behavior based on context, and handled follow-up questions by referencing what was just said. ALICE won the Loebner Prize (a Turing Test competition) three times.

Three times. With XML and regex.

The designers of those bots understood what their users would say, built patterns to catch it, and wrote responses that felt natural. A product design skill as much as a technical one.

What I Brought to My Own Bots.

At a 24-hour hackathon in 2017, my team shipped two projects using Azure Bot Framework and Node.js. Both received recognition:

• An AI-powered dining reservation chatbot. LUIS handled intent recognition by classifying the user's input against trained examples. It would grab the intent, trigger the right flow, then respond. I layered custom regex on top for edge cases LUIS consistently missed.
• A customer-facing web interface paired with a backend system that could deduce potential walk-up capacity from real-time data.

What made both work was knowing the surface area. A dining bot has a small, clear set of intents:

• Make a reservation
• Check availability
• Cancel a booking
• Find the menu
• Ask about hours or directions

Anything outside those is out of scope. The bot says so cleanly and redirects. Defining that boundary is half the design work.

The other half is fallback. When no pattern matches, a response like "I can help you book a table, check our hours, or find the menu. What would you like?" acknowledges the miss and steers back toward the happy path. SmarterChild did this well. Its graceful "I'm not sure I got that, try asking me about [topics]" kept the conversation moving.

The surface area, the fallback, and a clear scope matter more than the model underneath.

What Carried Over to the LLM Era.

When I started working with LLM APIs, the fundamental design work felt identical. You still:

• Define the intent surface
• Manage conversation state
• Write the fallback behavior
• Decide what the bot will and won't answer

The regex era built that discipline in by necessity. With LLMs you can skip it, which is why a lot of AI features feel unfocused. SmarterChild was opinionated about what it was for. That focus is what made it feel smart.

Regex also still has a real place today. If a user types "cancel" or hits a known keyword, there is no reason to send that to a model and spend tokens on it. A simple pattern match handles it instantly. In a world where token costs add up fast, knowing when to route around the LLM is just good engineering.

I try to carry that into everything I build now. Define the domain. Write the fallback. Set the scope before you write a line.