Problem shape
The first version of my Luau error analyzer started as a clipboard habit. I would paste stack traces from Roblox Studio into a scratch file, scan for the same three clues, then message the same explanation to a teammate. After doing that enough times, the repetition became louder than the errors themselves.
The errors were not random. They were patterned. A missing method on a table had one shape. A nil access inside a deeply nested module had another. A race between character spawn and UI mount had a third. Once I accepted that most of the pain came from recurring patterns, a deterministic tool became the obvious next step.
Why rules, not AI
I like language models, but this was not a language-model problem. I needed outputs that were stable between runs, easy to test, and explainable to junior developers. If the same input produced two slightly different suggestions on two different days, trust would disappear fast.
Regex and rule tables gave me what I wanted: fixed behavior, explicit intent, and cheap local execution. No network, no token budgets, no prompt drift. Most importantly, a failed match is easier to reason about than a plausible but incorrect narrative.
Architecture
The analyzer runs as a small pipeline: normalize input, extract frames, classify the error family, then apply ordered rules with confidence tags. The early stages only reshape text. The later stages produce developer guidance.
type Rule = {
id: string;
pattern: RegExp;
explain: (m: RegExpMatchArray) => string;
next: string[];
};
const rules: Rule[] = [
{
id: "nil-index",
pattern: /attempt to index nil with '([w_]+)'/i,
explain: ([, key]) => "Value is nil before '" + key + "'. Check initialization order.",
next: ["verify module return", "guard optional values", "inspect call site"],
},
];The ordering matters more than it seems. I rank rules from specific to broad, then stop on the first strong match. This avoids generic advice masking a more precise diagnosis. For ambiguous inputs, the tool returns a short list of candidate causes rather than pretending certainty.
Trade-offs
Rule systems age. New engine behaviors and community patterns eventually outgrow the initial rule set. I accepted that early and designed for maintenance: each rule has fixtures, expected explanations, and a short rationale comment in the source.
Coverage is the second trade-off. AI can improvise around unfamiliar phrasing; rules cannot. The practical fix was to treat unknown errors as first-class output. "No confident match" is a healthy response when the tool cannot justify itself.
Debugging philosophy
Good debugging tools should lower panic. When an error appears during playtest, people do not need a lecture. They need a calm first move. I bias every message toward immediate action: where to look first, what to log, and what assumption to challenge.
In a noisy moment, the first useful hint is better than a perfect explanation five minutes later.
That principle changed the wording of the output more than the matching logic. Fewer abstract descriptions, more operational steps.
Lessons
Building this reminded me that determinism is a feature, not a compromise. The tool is small, boring, and local. It is also predictable, debuggable, and easy to extend after a long week when my brain is tired.
I still keep AI around for exploratory work. But for recurring production errors in a Roblox workflow, a transparent rule engine has been the better teammate.