DEV Community: Tuan (Felix) Nguyen

Dấu or Die: Can LLMs put the accents back on Vietnamese?

Tuan (Felix) Nguyen — Sun, 11 Oct 2026 19:33:32 +0000

I built Dấu or Die, a Kaggle benchmark that removes the diacritics from Vietnamese sentences and asks LLMs to put them back. Each missing tone mark can change a word's meaning completely.

Benchmark: https://www.kaggle.com/benchmarks/tuanfelixnguyen/du-or-die-vietnamese-diacritic-restoration
Task & code: https://www.kaggle.com/benchmarks/tasks/tuanfelixnguyen/dau-or-die-vietnamese-diacritics

Why this task

Vietnamese has six tones plus vowel marks (ă, â, ê, ô, ơ, ư, đ). Millions of us still type without them ("không dấu"):

on phones without a Vietnamese keyboard,
in URLs, file names and usernames,
in old databases and SMS systems that only accept ASCII.

Remove the marks and many words collapse into the same string. ban could be bàn (table), bán (sell), bạn (friend) or bận (busy). Native speakers fix this from context without noticing. I wanted to know whether LLMs can do the same, or whether they just default to the most common word.

My favourite test sentence:

Cai ban nay ban bao nhieu tien vay ban?
→ Cái bàn này bán bao nhiêu tiền vậy bạn? ("How much is this table, friend?")

The same three letters appear three times, and each one must become a different word.

How the benchmark works

I wrote 37 sentences by hand, in 5 categories:

Category	What it tests
`everyday`	Plain daily sentences (the baseline)
`ambiguous`	Sentences built around colliding words (bàn/bán/bạn/bận, cười/cưới, ốm/ôm, thấy/thầy, cá/cà/cả…)
`idiom`	Proverbs. The words are fixed, so this needs cultural memory
`code_mixed`	Viet + English dev slang ("Em deploy code lên server rồi…"). English words must stay untouched
`proper_noun`	Places and people: Hà Nội, Đà Nẵng, Nguyễn Du, Truyện Kiều…

Then for each sentence:

The diacritics are stripped automatically with Unicode NFD normalisation, and đ is mapped to d.
The model is asked to restore the text and must return structured output {restored_text: str}.
Scoring is fully deterministic, with no LLM judge:
- Headline score: the share of sentences restored exactly. One wrong tone counts as wrong, because one wrong tone can change the meaning.
- Also reported: word-level accuracy per category.

Built with the kaggle-benchmarks library: one @kbench.task per sentence, aggregated by a parent task via .evaluate().

Models tested

I picked seven models from five different labs, mixing "fast/cheap" tiers with larger models. I wanted to see whether size or lab matters more for a low-resource-ish language task.

Rank	Model	Score (exact sentences)	Sentences right
1	Gemini 3.7 Flash	1.00	37 / 37
2	GLM-5	0.92	34 / 37
2	Gemini 2.5 Pro	0.92	34 / 37
4	GPT-5.4 mini	0.89	33 / 37
5	Claude Haiku 5.5	0.84	31 / 37
6	Qwen 3 Coder 480B	0.68	25 / 37
–	Gemma 4 26B (A4B)	run errored	–

I also added Gemma 4 26B, Google's open-weights model, but its run ended in an error before it produced a score. My scoring code assumes at least one sentence comes back in the requested structured format, so a model that fails that on every sample crashes the aggregation. I ran out of time to diagnose it before the deadline. That is a bug in my harness, not a verdict on Gemma.

Findings

1. A newer "Flash" model beat an older "Pro" model. Gemini 3.7 Flash restored every sentence, while Gemini 2.5 Pro missed 3. For this task, a newer generation mattered more than the bigger tier.

2. Being big doesn't help if the model is specialised for something else. Qwen 3 Coder has 480B parameters, by far the largest model here, yet it came last with 25/37. A model tuned for code seems to have lost some fine-grained, multilingual detail. Vietnamese tone marks are exactly that kind of detail.

3. The spread is wide even though the task looks trivial. Every native speaker restores these sentences without thinking. Yet the gap between the best and worst model is 12 sentences out of 37. One wrong tone counts as a wrong sentence, and that is how a reader experiences it too: "bán nhà" (sell the house) and "bàn nhà" (table house) are not "almost the same".

4. Cost buys very little at the top. Kaggle's score-vs-cost chart shows that GPT-5.4 mini reaches 0.89 for roughly $0.02 for the whole benchmark. GLM-5 gains only one more sentence (0.92) but costs over 10× more, around $0.3. Claude Haiku (≈$0.01) and Qwen Coder (<$0.01) are cheaper, but they lose accuracy quickly. For a production "add the accents back" feature, a small model is the sensible choice, with one condition: it has to be the right small model.

What surprised me

The benchmark found its own ambiguity. On my first development run, Gemini 3.7 Flash restored Sep bao hop online… as "Sếp báo họp online" ("the boss announced a meeting") instead of my reference "Sếp bảo họp online" ("the boss said to meet"). Both are correct Vietnamese. When I re-ran the same model at temperature 0 for the leaderboard, it chose "bảo" and scored a perfect 1.00.

Two lessons:

Removing diacritics sometimes destroys information that no amount of context can recover, so exact match is a slightly harsh metric. A future version should accept a set of valid answers per sentence.
Model outputs are not fully stable, even at temperature 0, and the wobble shows up exactly on the genuinely ambiguous items. A single leaderboard number hides that.

What I'd measure next

Fix the harness so format failures count as 0 instead of crashing, then re-run Gemma and other open-weights models
Multiple valid answers per sentence (bảo/báo), plus repeated runs to measure how stable each model is
Teencode / slang ("ko", "dc", "j z") mixed with missing accents
Longer paragraphs, where context can help more but errors also add up
Regional vocabulary (Northern vs Southern words)
The reverse direction: can a model detect a wrong diacritic that a typo introduced?

Credits

Solo entry by Tuan Nguyen. Built with kaggle-benchmarks. The sentences and the scoring are my own. Feel free to fork the task and add more Vietnamese sentences!

I Built StudyNest to Make Scattered Study Notes Easier to Review

Tuan (Felix) Nguyen — Mon, 05 Oct 2026 07:14:24 +0000

What I built

StudyNest turns scattered study notes into a small, usable study space. You can save notes in your browser, ask questions grounded in those notes, generate five practice questions with suggested answers, or get a short summary. A VI / EN switch changes both the interface and the language of the AI response.

I built it during the Hacktoberfest Weekend Challenge and tested it myself with a Python lesson. I asked, “Why does result equal 34?” StudyNest explained that append(10) changes [7, 8, 9] to [7, 8, 9, 10], and 7 + 8 + 9 + 10 = 34. That answer came from the note rather than from an unrelated explanation of Python.

I have not handed it to a friend yet, so I cannot claim feedback from someone else. For now, the real test is my own study workflow and yes, since I don't have any friends so I am still looking for a friend to give it to XDDD.

Why open AI matters here

StudyNest uses the open-weight openai/gpt-oss-20b model through Groq's API. I originally tried running a model locally, but the download was too large for the free space on my computer. Serving an open-weight model through Groq kept the project usable without that download. The model can be changed through configuration without changing the study workflow.

There is a tradeoff: notes stay in the browser until you request an AI feature, but then their content is sent to Groq for inference. The app says this clearly in the interface.

How it works

The front end is a single HTML file. A small Python HTTP server serves it and calls Groq through the official Python SDK. Notes are stored in browser localStorage. For each AI request, the server sends the notes as reference material and instructs the model to answer only from them or say when they do not contain the answer. The language switch is included in that request, so a note can be reviewed in Vietnamese or English.

The Groq key is read from a local config.py file or a deployment environment variable. config.py is ignored by Git; config_example.py shows the configuration format. The public demo also limits AI requests to 30 per hour to keep shared usage bounded.

Demo and source code

What I learned and what comes next

A useful AI project can be small: a clear input, a grounded response, and a way to check what the model says. The hardest practical constraint was making the app run on the computer I had. Next I want to add note export and an interactive quiz where learners answer before seeing the suggested answers.

Decision Lab: Making tradeoffs visible with Sanity

Tuan (Felix) Nguyen — Sun, 04 Oct 2026 15:50:27 +0000

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange.

What I Built

Decision Lab is a small workspace for choices that have no obvious winner. Instead of asking one question and returning a confident answer, it lets people describe the options, name the criteria that matter, assign scores, and then move the importance sliders to see whether their conclusion survives a change in priorities.

The demo compares two project ideas: AI Study Planner and Portfolio Website. The published Sanity content gives the former a higher learning score and the latter a much faster path to completion. With the initial weights, Portfolio Website leads 78% to 73%. The interesting part is the what-if interaction: the answer can change when the user changes what matters most.

Demo

Live app: Decision Lab

The published What should I build next? decision is the Sanity-backed example in the sidebar. The screenshots below follow the built-in Where should I work next? example, which uses three options to show more of the comparison interface.

Overview: the current front runner and the three available paths.

At a glance: option scores and the sliders used to test different priorities.

Side by side: each option is scored against the same criteria.

The rest of the breakdown, with weights that can be adjusted without editing published content.

No login is needed to view the published decision. The app's New decision flow creates a local browser draft; published content is edited in Sanity Studio.

Code

Repository: Decision Lab source

The frontend is React, TypeScript, and Vite. Sanity Studio and the content schemas live in the same repository. The frontend queries published documents from the public Sanity dataset with GROQ. No API token is shipped to the browser.

My Build Process

I built this with Codex as an iterative coding partner. We started with a narrow scope: one decision, several options, criteria with weights, and a side-by-side comparison. This avoided a generic dashboard full of unrelated features and made the structured content central to the experience.

The first pass used a local example so the interface and scoring could be tested before the Sanity project existed. Then I created a Sanity project, connected the Studio schema, added the frontend origin to CORS, and entered a real decision. The content model has a decision document containing criteria and options; each option has a score and optional reasoning for each criterion. The app calculates:

fit = sum(score * criterion weight) / (5 * sum(criterion weight)) * 100

The first real publish revealed a useful failure: the document had options but no scores yet. The API returned null for the score arrays. I updated the query layer to normalize missing arrays, changed the interface to ask for scores instead of inventing a winner, and added Studio validation requiring scores. That was more valuable than a happy-path screenshot: it made the app honest about incomplete content.

We also caught a small CSS specificity issue during visual review. The initial letters in the comparison table's colored option marks were pushed away from the center by a generic table-header rule. A narrower rule fixed the alignment. Testing with real Sanity content and a human looking at the page found both issues.

The app deliberately keeps importance sliders as temporary what-if controls. Moving them recalculates the ranking instantly without changing the published decision. This separates the shared source data from an individual visitor's exploration.

How I Used Sanity

Sanity holds the decision question, context, category, criteria, option summaries, colors, scores, and evidence notes as structured content. Studio is the editing interface; the frontend queries the published dataset and renders the same data in both the overview and comparison views. Editing and republishing a decision in Studio changes what visitors see without rebuilding the frontend.

Sanity Project ID: f2yoycw9

Dataset: production (public)

What I Would Improve Next

The current frontend reads published Sanity content while its quick-create flow saves drafts locally. A future version could use Sanity's App SDK for authenticated editing and keep drafts in Content Lake. I would also add a richer way to link scores to criteria, so content editors do not have to type the exact criterion name.

Balan Coffee & Roastery — A Slow-Drip Vietnamese Coffee Landing Page

Tuan (Felix) Nguyen — Sun, 16 Aug 2026 20:41:25 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing

What I Built

I created Balan Coffee & Roastery, a polished landing page for a fictional Vietnamese comfort café in Saigon.

The concept is inspired by the quiet comfort of slow phin coffee, butter toast, and small sweet treats. Rather than treating coffee as a quick purchase, I wanted the site to feel like a calm daily ritual: slow, warm, familiar, and personal.

Visitors can explore the menu, learn the café story, find visiting information, and interact with a small pixel-art coffee brewing experience.

Highlights:

Responsive editorial-style coffee shop landing page
Vietnamese coffee-inspired menu, story, ritual, and visit sections
Clear navigation and accessible interactive controls
Consistent number and price typography throughout the site
A lightweight interactive mini-game: Pixel Phin Brew
- Dose beans into the phin
- Grind the beans
- Bloom the coffee
- Let the phin drip
- Serve the finished cup
Built without heavy UI, game, or animation libraries

Demo

Live demo: Balan Coffee & Roastery

Source code: GitHub repository

Journey

I wanted to create something that felt more like a coffee ritual than a typical restaurant landing page.

The visual direction uses warm cream tones, deep coffee browns, generous spacing, subtle texture, and an editorial layout inspired by a slow morning at a Saigon café. I paid attention to small details such as consistent tabular numerals for prices and opening hours, responsive layouts, visible interaction states, and reduced-motion support.

The feature I enjoyed building most was Pixel Phin Brew. I wanted the interaction to be understandable instead of just decorative, so each button clearly explains the next brewing action. Every correct step updates the pixel scene, progress indicator, and feedback message until the final cup is served.

The project was built with React, TypeScript, Vinext/Vite, and custom CSS. I kept the implementation lightweight and avoided adding large dependencies for animation or the game.

Assets and Credits

The Manhattan Café illustration assets retain the original creator watermark visible in the source files. The interface design, responsive layout, styling, interactions, and Pixel Phin Brew game were created for this submission.

Operation Turing — A Caesar Cipher Codebreaking Game

Tuan (Felix) Nguyen — Sat, 20 Jun 2026 15:18:54 +0000

This is a submission for the June Solstice Game Jam

What I Built

Operation Turing is a Caesar cipher decoding game set in WWII Bletchley Park. You're a codebreaker racing the clock — 60 seconds to decode 5 intercepted enemy messages by finding the correct cipher shift before time runs out.

The game ties directly into the Best Ode to Alan Turing prize category: Turing's most famous achievement was breaking the Enigma cipher during WWII, so the entire core mechanic — sliding through shift values to reveal a hidden message — is a small, playable echo of the codebreaking work he pioneered. The game closes with one of his quotes after each run.

Mechanically it's intentionally simple: a slider from 0–25, real-time decode feedback, a hint system that costs points, and a 60-second timer across 5 rounds. I wanted something polished and complete rather than ambitious and half-finished, given the jam's tight turnaround.

This is actually my first game jam, so I kept things small on purpose — wanted to make sure I had something working end-to-end rather than something ambitious but broken XD.

▶ Play Operation Turing

Video Demo

Code

AIVIETNAM-AIO-felixdoit / operation-turing

🔐 Operation Turing

A Caesar cipher decoding game built for the DEV.to June Solstice Game Jam 2026, honoring Alan Turing and the codebreakers of Bletchley Park.

▶ Play the game

About

WWII, 1942. Enemy messages are flooding in. You're a codebreaker at Bletchley Park, racing against the clock to decode intercepted Caesar cipher transmissions before time runs out.

This game is an ode to Alan Turing — the man who broke the Enigma cipher and laid the foundations of modern computer science. The mechanic itself (finding the right shift to reveal a hidden message) is a small, playable echo of the codebreaking work Turing pioneered.

Built for the jam's Best Ode to Alan Turing bonus prize category.

How to play

Click Start mission
Drag the shift slider (0–25) until the decoded text below turns into readable English
Click Submit decode to lock in your answer
Decode all 5 messages…

View on GitHub

How I Built It

The whole game is vanilla HTML/CSS/JavaScript — no frameworks, no build step, no dependencies. I wanted it to be trivially embeddable and playable directly in the browser for judging.

A few technical notes:

Caesar cipher logic: a single caesar(text, shift) function handles both encoding and decoding — decoding a message is just encoding it with the inverse shift (26 - shift), so I didn't need separate encrypt/decrypt implementations.
Real-time decode preview: as you drag the shift slider, the decoded text updates live and turns green the instant it matches the target phrase, so you get immediate feedback without needing to "submit" to check your guess.
Scoring: each correct decode is worth 20 points, or 10 if you used a hint on that round — so hints don't subtract from your score directly, they just halve what you would've earned for that round.
Polish pass: added small CSS keyframe animations (fade-in on load/new round, a shake on wrong submissions, a green flash on correct ones) to make the feedback loop feel more responsive.
Deployment: static site on GitHub Pages — push to main, zero config.

Prize Category

Submitting for Best Ode to Alan Turing. The game's entire premise — decoding intercepted WWII-era cipher messages under time pressure — is a direct nod to Turing's work breaking Enigma at Bletchley Park. The ending screen also surfaces one of his quotes as a small tribute.