Build1 distinct publisher3 min readUpdated
A developer rebuilding a name lettering tool planned to classify user input with an LLM, then enumerated the cases and found nine deterministic branches waiting.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
A developer rebuilding a small name tattoo tool reached for an LLM call to classify user input, then shipped a plain function with eight checks and a default branch instead, in a post published on dev.to [1][4][7]. The useful detail is the order of operations: he wrote down the cases he actually cared about before he wrote the prompt, and after that there was nothing left for a model to do [5][6].
The tool takes a line of text and shows a set of lettering styles, and at first every input got the same treatment [2]. The inputs are not the same shape: a single short first name, two initials with periods, two names joined by a plus sign, a name followed by a date, a hyphenated name, a two-word phrase [3]. Serving identical recommendations across that range started to feel wrong [2].
Because the product already used AI elsewhere, another model call was the path of least resistance [4]. What killed it was the case list. The author needed to distinguish initials, initials plus date, name plus date, two names, hyphenated names, multi-word text, and short, medium and long single names [6]. That is nine categories, not arbitrary human language [5][6]. The function that replaced the model call trims the string and falls through ordered guards: initials-with-date, name-with-date, initials, name pair, then a hyphen check, then a whitespace-split check, then length under six characters, then length under ten, then long [7]. Eight conditionals plus the fallback return produce exactly nine outcomes, one per enumerated case [16]. Note the ordering: the two compound date cases are tested before the bare initials and name-pair checks, so a compound input cannot be swallowed by the rule for its own components [17]. The medium band is four characters wide, from six to nine [18].
The scope discipline matters as much as the rules. The classifier does not decide which style is correct; it decides which directions appear first, and the remaining styles stay visible [9]. That is what keeps the branch count low, because a reordering function can be wrong without being harmful.
The stated payoff is unglamorous and checkable: no inference cost, no network latency, identical output for identical input, reproducible edge cases, a visible reason for every recommendation, and product changes that are code edits rather than prompt edits followed by hoping the model reads them the same way [10]. The author's conclusion is that the problem was not fuzzy enough to justify a model [11]. AI stays in the workflow where the request is genuinely open-ended, for custom compositions with flowers, symbols and flourishes, while the lightweight preview remains deterministic [12].
Two things to watch. The real implementation already carries extra checks around dates and separators beyond the simplified version shown [8], and that is where rule sets grow: every new separator, locale or date format is another guard, and the honest test is whether the branch count stays near nine. Second, the published recommendation map covers only four of the nine classes [15][19], so the ordering logic is less finished than the classifier. The transferable part is the screening question the author now applies before adding a model: not whether AI could handle the task, but whether the input space contains enough uncertainty to need it [13].
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
A post titled "I Almost Used AI to Classify User Input. Simple Rules Worked Better" was published on dev.to, written in the first person by a developer rebuilding a small name tattoo tool.
In the tool, the user enters some text; at first the author treated every input the same way (text to a set of lettering styles), which works for simple names, but showing the exact same recommendations for very different inputs "started to feel wrong".
The example inputs listed are: a single first name (Emma), initials with periods (A.M.), two names joined by a plus sign (Jack + Mia), a name followed by a date (Amelia and 1998-11-14 separated by a middle dot), a hyphenated name (Anna-Marie), and a two-word phrase (Forever Dad).
The author's first thought was to classify the input with an LLM, and because AI was already used elsewhere in the product, sending the text through another model call "would have been easy enough".
After listing the cases he actually cared about, the author realised the classification problem was tiny and that he did not need to understand arbitrary human language.
The cases enumerated were: initials; initials plus date; name plus date; two names; hyphenated names; multi-word text; short single names; medium single names; long single names.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One self-reported build log with a simplified code excerpt
The strongest evidence is the published classifier excerpt and the case enumeration, which are internally consistent and let the branch count and length bands be checked directly. Everything else is the author's own account: the production predicates for dates and separators are not shown, the LLM alternative was never built or measured, and there is no accuracy, latency or cost data. Single publisher, no independent corroboration.
One self-disclosed deployment in the author's own tool
The only adoption signal is the author stating the pattern ships in his Name Tattoo Generator, with the deterministic preview first and AI later. There are no user counts, traffic, revenue or third-party implementations, so adoption is real but minimal and entirely self-reported.
Modestly overstated: the model path was never tested
The post is unusually hedged for its genre — it scopes the classifier to ordering, keeps other styles visible, admits the excerpt is simplified and says presets do not matter — which keeps the gap small. It is positive rather than zero because the comparative headline conclusion that simple rules worked better rests on a model call the author never made and never measured, and because the generalized decision heuristic is offered on the strength of one small, low-ambiguity feature.
Author promotes his own product inside the argument
The piece is written by the builder of the product it cites and names the Name Tattoo Generator as the deployment, giving the author a direct promotional interest in the narrative being read as sound engineering. The contrarian less-AI framing is also well-suited to developer-platform engagement. Offsetting this, the technical content is checkable and the post concedes limitations, and no vendor, sponsorship or third-party funding is disclosed anywhere in the source.
Low-moderate: verifiable code, single unverified narrator
Confidence in what the post says it did is fair, because the code excerpt and case list are self-consistent and the derived counts follow from them. Confidence in the broader conclusion is low: one publisher, one self-interested narrator, no measurements, no independent replication, and no data on how the rules behave on inputs outside the six examples given.
build
Allow-list the closed set, block-list the open one: 193 thin geo pages, one gate1 distinct publisher
build
A GAN beauty filter is a device budget allocation, not a feature toggle1 distinct publisher
build
Your inference bill is an architecture defect: declare the task before you call the model1 distinct publisher
build
The NestJS default path puts the query inside the business rule, and nothing fails when it moves1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 14, 2026