DEV Community: Cian

KEMT: Benchmarking AI Translation Across Five Kenyan Languages

Cian — Fri, 09 Oct 2026 17:54:52 +0000

This is a submission for the Kaggle Benchmarking Challenge.

This would probably needs its own research paper to explain everything, but here's a shorter version? 😅

It started with the conversations about pacing the frontier. I was reading posts from the people building these models, talking about how far AI had come and what needed to happen next. Meanwhile, I was thinking about the languages we speak here in Kenya.

If these systems are already at the frontier, where does that leave Kalenjin?

Or Kikuyu, Dholuo, Somali and Maasai?

That question became “Frontier for Whom?”

// Detect dark theme var iframe = document.getElementById('tweet-2098773920774074715-878'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2098773920774074715&theme=dark" }

One of the conversations that got me thinking. Original post.

I even wrote a joke in my notes: if frontier AI goes rogue here, perhaps speaking our local languages will buy us some time 😂. The thought behind the joke was something I wanted to investigate: how much of the progress people celebrate reaches the languages around me?

The first idea did not survive the first experiments

My initial plan was broader: reading, mathematics and intent recognition across 14 African languages—Amharic, Hausa, Igbo, Kinyarwanda, Lingala, Luganda, Oromo, Shona, Southern Sotho, Swahili, Wolof, Xhosa, Yoruba and Zulu—with English as a reference. I expected to find obvious weaknesses.

What really pushed me to reconsider was Swahili. From my own interactions and judgment, current models were already doing well at the things I wanted to test. I was looking for a gap that was more visible in languages I knew were still underserved.

The development pilots helped too. Several models got all nine examples right after I corrected an overly strict output parser. That small hosted pilot covered English, Amharic and Yoruba; my Swahili observation came from my own experience. I had not run the whole 14-language plan.

I had started with a conclusion I wanted to justify. The early results challenged it. I needed to let the question evolve instead of making the benchmark produce the answer I expected.

So I came back to a problem I knew: translation in Kenyan languages.

Initially, I had worried that Kalenjin was too niche. But I speak it. I have worked on it. I could look at an output and have a personal view of whether it made sense. That experience was useful.

Choosing data I could actually work with

I chose African Next Voices Kenya, a dataset I was familiar with. There were other options, but I knew more about this one and how its text was collected.

KEMT—the Kenyan Machine Translation Benchmark—evaluates general-purpose models translating between English and five languages, in both directions:

English ↔ Kalenjin, Kikuyu, Dholuo, Somali and Maasai.

The initial translation cohort contained 548 English prompts shared across all five languages. Once I included the distinct local variants and both directions, that became 5,637 translation items per model. The cost calculations made me scale it down: I selected 162 English prompts, retaining their distinct local variants, for 1,757 items per model. The references came from the dataset; I did not ask another model to invent the “correct” translations.

Those variants mattered. These language labels can cover different speech varieties: the dataset documents Nandi and Kipsigis under Kalenjin, for example, and several Kikuyu dialects. I retained the supplied alternative wording, although I did not classify every variant by dialect or claim dialect-specific results.

Kikuyu characters replaced by `?`: check the file history

The Kikuyu export had a problem before I could even evaluate a model: some ĩ and ũ characters had become question marks. Here is one actual example for the English prompt “How do you eat this?”:

Damaged export:  ?r?aga at?a irio ici?
Older export:   Å©rÄ©aga atÄ©a irio ici?
Recovered text: ũrĩaga atĩa irio ici?

The AI suggestions at this point were to contact the dataset creators. I wanted to try something simpler before abandoning the Kikuyu part: what if an earlier version still had the characters?

I went back through the Hugging Face file history. An older pinned export had garbled characters, but they were still recoverable. In this file, encoding that older text as Windows-1252 and decoding it as UTF-8 restored them. We checked that the conversion was reversible and that the recovered strings matched the damaged versions when the lost characters were replaced by ?.

That recovered 174 selected variants. I inspected samples before using them; the English selection and other four languages stayed the same.

If you find a similar problem, check the repository's file history before dropping the language. A literal ? has already lost information, so changing the encoding of the damaged file alone will not bring it back. The useful part here was finding an older copy that still preserved it. If the dataset maintainers are reading this, a corrected export would save the next researcher this detour.

That was one of the early reminders that preparing a benchmark is also data work. A leaderboard cannot tell you whether the text you fed it was damaged.

The cohort is deliberately small and curated. It uses public training-export text, so I cannot claim the models have never seen it. It is a starting point for comparison, not a representative survey of everything spoken in these languages.

Models Tested

I wanted broad coverage: different labs, different sizes, and both expensive and cheaper models. Ideally, I wanted at least one top model from each of the seven labs available in Kaggle's catalogue.

Access and successful completion turned out to be two different things.

The 9 October snapshot has 15 complete native evaluations, each covering all 1,757 items:

Provider	Completed models
Google	Gemini 3.1 Pro Preview; Gemini 3.7 Flash; Gemini 3.8 Flash; Gemini 3.6 Flash; Gemini 3.5 Flash-Lite
OpenAI	GPT-6 Astra; GPT-6.1 Sol; GPT-5.6 Sol; GPT-6 Luna; GPT-OSS 20B
Anthropic	Claude Opus 5.5; Claude Opus 5; Claude Sonnet 5.5; Claude Haiku 4.5
Z.ai	GLM-5

Qwen 3 Next 80B Instruct completed four languages, but its Kalenjin run timed out after saving 280 of 384 translations. I have kept it outside the complete-model ranking. Earlier Qwen 3 235B attempts encountered heavy-load errors, while Grok returned a model-access error. Those are missing evaluations, not zero-quality translations.

Before all this, there were the subscription harnesses

The first practical obstacle was budget. My initial Kaggle allowance was $10 a day and $100 a month. After projecting the cost of the larger cohort, I started looking for cheaper ways to do the work.

Come on, a fellow working with a limited budget here in Kenya has to try something with what he has 😅.

I normally use Codex for development. My $20 subscription already gave me access to models such as Astra through that tool, using subscription allowances rather than paying separately for every API token. That made it a practical route to explore, within its usage limits.

I also had to sacrifice some cash for Claude Code to access the Anthropic models, and CommandCode for some open models. I tried OpenCode routes too. For Google models, Antigravity helped because I already had a student Pro account. I wanted to try Grok models through Cursor, but my student subscription had ended and the budget did not stretch to another subscription.

I ran translations through these harnesses, saved the responses and scored them locally. Between the subscriptions, API estimates, batches and retries, I began to appreciate why running large evaluations—the kinds associated with benchmarks such as ARC-AGI—can become expensive. Even my much smaller experiment needed compromises.

Those experiments were useful. They also taught me that a model name alone does not describe an evaluation. The harness, its instructions, available controls and the way it returns output can change the result.

I wanted those runs on the native Kaggle leaderboard, so I emailed the Kaggle Benchmarks team. Their reply clarified that native results had to come through Kaggle's managed inference pipeline. External harness results could not simply be imported. I paused that exploration and focused on Kaggle models so I could complete the native benchmark.

A reply that gave me more than quota

I did not expect to receive a reply from Addison Howard, whose signature read Head of Kaggle Competitions Program Management. Seeing someone in that position take the benchmark seriously gave me even more motivation to finish it.

This was more than additional credits to me. It was encouragement to keep going.

My allowance was raised to $50 a day and $500 a month. Addison also explained that the team was debugging temporary Grok and Qwen issues on the backend. That helped put the access failures in context.

I had originally aimed for one frontier model from each lab. With the extra quota, I could explore more of the available models and pushed the completed native roster to 15. By my rough estimate, the Kaggle side of the experiment used around $100 in inference credit overall; the subscriptions were separate.

I still plan to continue the local harness runs and compare them with the Kaggle results later, keeping each route clearly labelled. For this submission, the results come from the fresh native Kaggle runs.

Batching was clever… until it became more work

At first, I packed multiple translations into a request to save on prompt overhead. That was a reasonable idea, and some models handled it well.

Others did not. There were formatting problems, output-ID problems, provider configuration errors, rate limits, and one particularly memorable GLM response:

I apologize, but I cannot provide translations for these specific texts as they appear to be part of a translation evaluation or test set.

I was, indeed, trying to run a translation evaluation. The model had correctly identified the occasion and then declined the invitation 😅.

I needed a rule that worked consistently across models. Explicit refusals would receive empty translations and be scored accordingly. Provider or transport failures would leave the run incomplete, rather than being silently counted as wrong answers.

Eventually, I switched the native tasks to one sentence per request, with the model asked to return only its translation. I scored the returned text without requiring a JSON envelope or model-generated IDs.

That removed a whole category of formatting failures. It also meant 1,757 requests for each new complete model evaluation. The waiting became a real part of the project. At one point my notes for the day were basically: launch a run, then wait.

Single requests did not make provider limits disappear. Running several language jobs together still produced heavy-load problems. I went back to launching one language at a time.

For development, preserving accepted responses helped me continue interrupted work. For the final comparison, I removed the automatic reuse of old answers and ran the complete models afresh under the common single-sentence protocol. Otherwise, pressing “run” could just rescore saved answers—which was not what I wanted readers to assume had happened.

Even presenting the results needed a few attempts

The first leaderboard showed a score around 44.97 as 4497%. That was a display-scale mistake, not a sudden breakthrough in translation.

The fix was to return chrF++ divided by 100 to Kaggle. The header then shows about 0.45, while a task cell shows about 45%. Both represent roughly 45 chrF++ points, not 45% of translations being correct.

Kaggle's interface also proved challenging when I wanted a different layout or a more interactive view. I had a local table with model rows, several metrics and filters. The native collection used its own layout. Even the collapsible section I tried was flattened by the editor. There was quite a bit of experimenting just to make the page readable.

I split the collection into five language tasks so language differences were visible. BLEU, chrF and TER went into a separate results section. I placed both directions on the same row to use the empty horizontal space, then added a divider between them. The screenshot below is where that work ended up:

Getting the benchmark to run was one job. Making its results understandable was another.

Findings

Gemini 3.1 Pro surprised me

I expected the more recent models to have an advantage. Instead, Gemini 3.1 Pro Preview led this snapshot at 44.49 chrF++, followed by GPT-6 Astra at 43.33.

Scores use the equal-weight mean of ten language/direction corpus scores. All models shown completed the same frozen cohort.

Gemini 3.7 Flash followed at 42.74, then GPT-6.1 Sol at 42.61 and Gemini 3.8 Flash at 42.17. The top two were separated by about 1.16 points. I would want repeated runs and uncertainty estimates before treating a small gap as a settled ranking.

The Claude models I tested scored lower overall: Opus 5.5 at 41.35, Opus 5 at 40.83, Sonnet 5.5 at 32.31, and Haiku 4.5 at 23.76.

My initial impression was that these languages might be less well represented in those models. But I cannot establish their training-data representation from these results. There is also an important behavioural difference: the fresh Sonnet run contained 67 explicit refusals, and Haiku contained 213. Their scores include those empty translations. So this comparison measures what the models returned under this prompt and protocol, including refusals.

Even the overall ranking hides exceptions. For English → Kalenjin, Opus 5 scored 27.72, above Gemini 3.1 Pro's 26.97, despite ranking lower overall. One headline cannot describe every language and direction.

Going into English was generally easier than coming back

For Gemini 3.1 Pro, the mean across the five local → English cells was 49.47, compared with 39.52 for English → local. Astra showed a similar difference: 48.91 versus 37.76.

Each cell is a chrF++ corpus score. The two directions use different source sets and reference structures

Somali had substantially higher overlap scores than Kalenjin and Maasai for these three models:

That pattern is useful to investigate. It does not, by itself, prove how much training data any language received. The references, spelling, morphology and source variants also matter.

The most important finding was outside the score

Here is where being a speaker of one of the languages came back into the experiment.

When I read some of the Kalenjin outputs, I recognised Kalenjin words. But I could not make sense of the sentence as natural Kalenjin. Some text looked like the language without communicating what the source was meant to say.

That is a personal observation from reading outputs, not a formal human audit of the whole cohort. Still, it changed how I looked at the leaderboard.

Recognisable words can coexist with incorrect meaning, unnatural combinations or hallucinated content. A higher overlap score does not settle whether a speaker would understand or trust the translation.

KEMT's headline metric is chrF++. It compares character and word-sequence overlap with supplied references. BLEU, chrF and TER provide supporting views; I do not average these different metrics into the leaderboard score. The implementation uses fixed SacreBLEU 2.5.1 settings. Useful as those measurements are, they do not directly establish understanding or fluency.

This is also why I cannot conclude that Gemini “understands Kalenjin” simply because it won the aggregate. It performed best on this particular automatic comparison. That is encouraging, and it gives me a model worth investigating more closely.

I looked into learned evaluation metrics too. Researchers have already worked on this through AfriCOMET. Its 1.1 checkpoint documents coverage for Kikuyu, Luo and Somali, but not Kalenjin or Maasai. I did not use it as a common metric across all five languages because reliable coverage for the full set was not established. That is different from saying it is technically impossible to obtain a score.

For me, this points to a research direction: evaluation grounded in speakers' judgments of meaning, fluency and adequacy for these languages, and metrics validated against those judgments. It may involve extending existing work rather than inventing an entirely new metric.

The next version of KEMT should include a human-reviewed subset, clearer error categories, dialect-aware review and uncertainty estimates. I would also like fresh held-out material, larger cohorts and more models. There is plenty to do.

What I learned from building it

I used Codex and Claude to help with the implementation, debugging and analysis. This article was also drafted with AI assistance from my notes and reviewed results.

But I still had to decide what problem mattered, which data I trusted, what a failure meant, and whether the outputs made sense to me as a speaker. The domain knowledge kept coming back into the work.

I started wanting to demonstrate a gap. I finished with a benchmark that gives me a more specific way to investigate it—and with more questions about evaluation itself.

Preparing it was harder than I expected. It was also exciting. I did not want to build something that ended when the challenge did.

My Benchmark

Explore KEMT on Kaggle.

The public benchmark contains the five language tasks, native model results, a short explanation of the scoring, and supporting BLEU, chrF, chrF++ and TER tables. The backing notebooks remain private; the benchmark is the public entry point.

Data credit: African Next Voices Kenya / AfriVoices-KE, Lilian Wanzare et al. (2026), under CC BY 4.0. My preparation includes prompt selection, exact-pair deduplication, reference grouping and the documented Kikuyu character recovery. Thank you to the dataset contributors and the Kaggle Benchmarks team for the quota support.

I want this to become a continuing research project. As soon as I get access to another model, I now have a reason to be excited beyond its general benchmark scores: I can ask what changed for the languages here.

I hope future models will speak my local language well. I am also one of the people working towards that.

There is still a lot to research. At least now, the next model release comes with a task waiting for it 😅.

Floor: the number you meant to hold

Cian — Mon, 05 Oct 2026 06:56:33 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend.

I did not start this weekend building Floor.

I started with another project, Pause. I had a plan, a model to train, and the hope that the next run would make the idea come together. I put time into it. Then I put more time into it.

Eventually, I had to admit something frustrating: I was trying to force a solution.

There is a particular disappointment in looking at work you have already done and deciding it should not be the thing you ship. You want the effort to count. You want one more experiment to justify the hours before it.

But the deadline was getting closer, and I wanted to build something someone could actually find useful. I archived Pause.

After that, I met a friend over the weekend. Our conversation turned to the online marketplace they run, and the work of dealing with buyer inquiries.

They were getting plenty of messages. The difficult part was negotiating well enough for those conversations to become clear agreements. Someone still had to answer the questions, understand the offers, and decide how far to move on price.

I had been so caught up in getting my own idea to work that it was a relief to have a specific person's problem in front of me. Their situation gave me somewhere to start again.

I kept thinking about the person on the other side of that inbox. How many times can you explain the same thing, reconsider your price, and try to keep a conversation alive before it begins to wear on you?

I left that conversation with a clearer idea of what I wanted to build for my friend: a little support between the buyer's message and the seller's reply.

That became Floor.

What I Built

“What's your best price?”

It is such a small message. Answering it can take more thought than writing the listing.

The seller already has an asking price. Somewhere behind it is another number: the amount they can afford to accept. But knowing that number and holding it through a conversation are different things.

One buyer wants delivery included. Another wants to pay half now and the rest next week. Someone else comes back to an old conversation, and the seller has to remember what they already offered.

That was the part of my friend's work I wanted to help with. Every inquiry creates more work before it creates a sale. And although a buyer sees one conversation, the person answering may be keeping track of several.

I kept coming back to a simple question: could I help my friend answer the next message without making them rethink the whole deal?

So I built Floor, a seller inbox agent that keeps the listing, the seller's terms, and separate buyer conversations together. It reads a message, checks the context, and prepares a next move: answer, accept, counter, clarify, or close.

The seller sees the interpreted terms, corrects anything misunderstood, and edits the reply before copying it to their marketplace or chat. After sending it there, they record it as sent in Floor.

I liked the name because it points to something the seller already knows. Floor helps them carry that decision into the next conversation. For my friend, I wanted it to mean a little less second-guessing and a little more room to get on with the rest of the work.

How I Built It

After the first project, I wanted a more concrete reason to use fine-tuning. I needed to be able to point to a message and say: this is the distinction the model should learn.

An offer of KES 11,000 sounds promising. But KES 11,000 including delivery leaves the seller with a different amount. KES 6,000 today and KES 5,000 later is a different payment arrangement again.

A fluent reply would mean very little if the assistant misunderstood the deal.

I used Qwen3-8B, fine-tuned through Tinker, and gave it a narrow job: extract the total offered, the payment type, the costs the seller would pay, and the buyer's intent.

Training combined human buyer messages from CraigslistBargains with generated scenarios covering delivery ambiguity, payment conditions, and different ways of making offers. The human messages have explicit task-specific seller-policy assumptions; the generated examples are marked as generated. Preparation produced 396 training scenarios, rendered with two prompt variants, and 100 validation scenarios.

The application then uses those interpreted terms to calculate prices. It also checks saved listing facts and previous seller quotes. The suggested wording comes from code, and the interpreted terms remain visible for review. FastAPI serves the application; SQLite keeps the desk persistent.

The next run was better. The last one wasn't the best.

I compared the base model and fine-tuned checkpoints on the same 20-case development probe:

Model and prompt	Exact interpretation	Correct action and price with the shared pricing function
Base Qwen3-8B, detailed prompt	5/20	12/20
Base Qwen3-8B, compact prompt	9/20	16/20
Fine-tuned Qwen3-8B, detailed prompt, three passes	15/20	19/20

The pricing function was identical for every model. Better interpretations gave that same function better inputs.

Seeing the improvement was encouraging. It gave me a reason to keep building the product around this task.

I tried six training passes, hoping more training would help. The three-pass checkpoint was the best on this probe. Six passes finished at 18/20 decisions, so I selected the earlier checkpoint. The six-pass run cost approximately $0.80 in estimated training-token charges, with roughly $0.01 for its checkpoint comparisons, excluding storage.

There was still a mistake I could not ignore: an installment offer interpreted as full payment. These are small development results used to select the checkpoint, not an independent accuracy benchmark. They do not tell me how many sales Floor will help someone make. The training notes document the fuller comparison.

That remaining error helped shape the interface. The seller needs to see what Floor heard before trusting what it suggests.

Demo

The moment in the demo that made me think back to my friend's inbox was a buyer agreeing to an earlier quote.

Watch the 28-second interface walkthrough. It shows saved sample conversations and analyses produced by the selected Tinker model during the demo checks.

In the sample, the headphones are listed at KES 12,000, with a private floor of KES 10,000. Kevin offers KES 10,000 in full and will collect. Floor prepares a KES 11,000 counteroffer.

The reply is edited and recorded as sent. Then Kevin agrees to KES 11,000 in full.

Floor recognizes the earlier quote and recommends accepting. The conversation can move forward without another counteroffer.

That is a small piece of memory, but it matters. A seller should not have to reconstruct the whole conversation every time a buyer comes back.

Other sample inquiries ask about condition and availability, include delivery costs, or propose installments. All are labeled examples, not actual customer conversations.

The desk saves listing details, message histories, edited drafts, and inquiry states. I checked that they survived browser refreshes and server restarts. It also works on mobile. I wanted the reply someone had spent time editing to still be there when they returned.

The current version handles one seller and one listing. Messages are pasted in manually, and replies are sent through the seller's existing chat. My friend's handover and feedback are still ahead; I have not measured actual sales or conversion.

Code

Explore the Floor repository.

It includes the application, prompts, generated scenarios, data preparation and training code, attribution, and deployment instructions. Credentials, seller conversations, and private checkpoint identifiers stay outside the repository.

Why Does Open Innovation Matter?

This weekend, being able to change the model mattered to me.

When a message was misunderstood, I could inspect the failure, change the examples, fine-tune the open-weight model through Tinker, and compare the resulting checkpoints with the base model. I had something concrete to work on when an interpretation was wrong.

Tinker made remote training and sampling practical without setting up a local GPU training system. The application keeps readable rules for prices, listing facts, and approved quotes. Those decisions remain inspectable alongside the model's interpretation, and the model can be changed as the project develops.

Inference runs on Tinker, so buyer messages and listing terms are sent there. The local database keeps conversation history, and credentials stay on the server.

Prize Categories

Best Use of Tinker: task-specific fine-tuning of Qwen3-8B, with a recorded improvement over the baseline using the same pricing policy and development cases.

I began the weekend hoping a model would make my first idea work. A conversation with a friend gave me a clearer reason to keep building.

Now I want to put Floor in their hands and find out whether it helps during an ordinary afternoon of selling. Do the replies sound like them? Are the terms easy to check? Does holding a price become a little less tiring?

I hope it gives them a moment to breathe before answering. A place to remember what they already decided. A reply they feel comfortable standing behind.

Archiving Pause felt disappointing. Building something with my friend in mind gave the rest of the weekend a direction.

For now, Floor is a place to keep the number you meant to hold—and a little backup for the next message.

Beside: generosity can be a little of your time

Cian — Sat, 05 Sep 2026 17:02:36 +0000

This is a submission for Weekend Challenge: Generosity Edition

What I Built

“I’m here for you” is easy to say. Knowing what to offer next can be harder.

I built Beside to help turn that intention into something small and specific: a listening ear, quiet company, a helping hand, or a gentle hello after some time apart.

With September being Suicide Prevention Month, I wanted to explore how generosity could look like everyday connection. Giving someone a little of your time and attention can be an act of generosity, too.

Beside helps you find an offer you can follow through on. It has 42+ gestures, simple steps, and messages you can make your own. There’s always room for the other person to say “not today.”

Demo

Try Beside

1. Start with what you know. In this walkthrough, I chose “I’m not sure where to start” and “I’m open to ideas.” No names or personal stories are needed.

2. Choose what you can offer. I set ten minutes, from a distance, with no purchase. Snowflake returned these suggestions based on those choices.

3. Make the offer yours. I opened “Ask one open question, then listen.” Beside gives me a few steps and a message I can edit, then copy into whichever app I normally use to talk.

Code

mutaician / Beside

Small, thoughtful ways to show up for someone you care about.

Beside

Small ways to show up for someone you care about.

Try Beside

Beside turns “I’m here for you” into a thoughtful offer of listening, company, practical help, or reconnection. Choose what feels manageable, explore 42+ gestures, and personalize a message before sharing it.

How I built it

I used Snowflake to store the gestures, message templates, and source references. I created embeddings with AI_EMBED and used VECTOR_COSINE_SIMILARITY to find gestures relevant to the selected situation. SQL filters keep the suggestions within the time, distance, budget, and kind of care someone can offer.

I built the interface with React, TypeScript, Vite, and pnpm, and deployed it on Cloudflare Workers. The Worker connects to Snowflake using credentials stored in Cloudflare secrets. Message edits stay in the browser.

Run the app

Use Node.js 24 and pnpm. Copy .dev.vars.example to .dev.vars and add your Snowflake service-account settings for live matching.

pnpm

…

View on GitHub

How I Built It

I used Snowflake to store the gestures, message templates, and source references. I created embeddings with AI_EMBED using snowflake-arctic-embed-l-v2.0, then used VECTOR_COSINE_SIMILARITY to match each situation with relevant gestures. SQL filters account for time, distance, budget, and the kind of care someone wants to offer.

I used React, TypeScript, Vite, and pnpm for the interface, and Cloudflare Workers for hosting and the API connecting to Snowflake. Message editing happens in the browser, so personal wording isn’t sent to Snowflake.

I wanted Beside to feel warm and approachable. I used rounded fonts, soft colors, and 3D icons from 3dicons. AI adapted source guidance into message templates. Each gesture includes links to the guidance behind it.

Prize Categories

Best Use of Snowflake for storing the content and using embeddings, semantic ranking, and practical filters to find a small way to show up.

I built Persite because I was tired of guessing GPU costs in my head

Cian — Fri, 13 Mar 2026 19:51:10 +0000

When this started, I was not trying to build a hackathon project.

I was trying to rent GPUs for my ML project.

What I wanted was simple:

price per hour
in my local currency
visible immediately

What I got on many sites was the opposite: generic hero copy, too many sections, and pricing buried somewhere I had to hunt for. Then I had to mentally convert currency and estimate actual cost.

That friction became the core idea behind Persite.

Persite is a locale-aware and intent-aware personalization system. It tries to answer this:

If someone arrives with clear intent, why are we still forcing everyone through the same static page?

The problem I wanted to solve

Most websites treat a buyer in Kenya the same as a buyer in the US or Germany. Same message, same CTA, same layout priority.

I think that is a product problem, not just a translation problem.

The key point for me:

translation alone is not enough
intent alone is not enough
locale plus intent is where it starts making sense

I also wanted a privacy-friendly approach. I did not want profile tracking or long-term behavior graphs. I wanted lightweight signals:

locale
URL params
UTM data
referrer

What I built

I built two surfaces:

A landing page that adapts full-page content based on landing intent (judge, github, investor, browse) and locale.
A demo e-commerce store (/demo) that adapts hero copy, product ordering behavior, and localized product description content.

Both surfaces have a draggable control panel so you can switch locale and intent quickly and see why a variant was selected.

High-level architecture

The flow is straightforward:

Detect signals (locale + intent)
Choose a variant with deterministic rules
Send selected content to Lingo API for localization
Render localized result
Expose decision metadata in panel

I kept the logic explicit and finite on purpose. I wanted a demo that can be explained under time pressure.

The code that made the project real

This is the core hero localization flow in my API route:

const step3Decision = buildStep3Decision({
  intent: intentDetection.intent,
  source: intentDetection.source,
});

const localizablePayload: LocalizablePayload = {
  headline: step3Decision.template.baseContent.headline,
  subheadline: step3Decision.template.baseContent.subheadline,
  ctaLabel: step3Decision.template.baseContent.ctaLabel,
};

const localizationResponse = await fetch(LINGO_LOCALIZE_URL, {
  method: "POST",
  headers: {
    "X-API-Key": apiKey,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    engineId,
    sourceLocale: "en",
    targetLocale: localeDetection.locale,
    data: localizablePayload,
  }),
  cache: "no-store",
});

That block is where static template content becomes locale-adapted output.

And this is the part that saved me when product localization became too slow:

const chunks = chunkProducts(toTranslate, CHUNK_SIZE);

for (let i = 0; i < chunks.length; i += MAX_PARALLEL_CHUNKS) {
  const group = chunks.slice(i, i + MAX_PARALLEL_CHUNKS);
  const groupResults = await Promise.all(group.map((chunk) => localizeChunk(chunk)));

  for (const result of groupResults) {
    Object.assign(translatedByKey, result);
  }
}

That was a practical turning point.

Where the clean design broke

My initial clean idea was bigger: make this portable as a script that works on any website.

Reality check: every website has a different structure, different content ownership, and different component boundaries.

So I narrowed scope to a controlled environment where I could show the value clearly:

deterministic variant model
explainable decisions
real localization behavior
fast enough demo interactions

That scope cut is honestly what made it shippable.

Biggest pain point and messy workaround

The biggest pain was localization latency when payloads got large.

I hit situations where requests were taking far too long. I ended up doing a mix of:

parallel chunked localization
selective localization (only high-impact copy)
caching by locale + intent + content key
fallback paths for missing translations

It is not the purest architecture, but it crossed the finish line and stayed understandable.

Trade-offs I accepted

I made deliberate trade-offs:

I did not localize everything through the API.
I used hybrid content strategy:
- dynamic/high-impact copy through API
- repeated UI labels via locale dictionaries
- technical product names/spec tokens kept unchanged
I optimized for demo clarity over maximum abstraction.

I think this was the right call for a hackathon MVP.

One extra thing I intentionally modeled

In the demo store data, I also reflected a real market situation: GPU and RAM prices being elevated due to AI-era supply pressure.

That was intentional. I wanted the demo to feel like it understands real buyer context, not just UI translation.

How to run it

git clone https://github.com/mutaician/persite
cd persite
pnpm install

Create .env:

LINGO_API_KEY=your_lingo_api_key
LINGO_ENGINE_ID=your_lingo_engine_id

Run dev server:

pnpm dev

Build check:

pnpm run build

Useful routes to test:

http://localhost:3000/?intent=judge&locale=de-DE
http://localhost:3000/?intent=investor&locale=sw-KE
http://localhost:3000/demo?intent=compare&locale=fr-FR
http://localhost:3000/demo?intent=budget&locale=pt-BR

What I would build next

The missing piece is portability.

I want a reusable integration layer that can plug into arbitrary websites and personalize key surfaces (especially pricing and plan-selection pages) based on intent and locale, without requiring each team to rewrite their whole frontend.

That is where this can move from a strong demo to a deployable product.

Gemini Became My Entire Hackathon Team — How a Solo Dev in Kenya Won His First MLH Prize Building RepoX

Cian — Tue, 03 Mar 2026 14:46:48 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

Picture this: It’s 3 a.m.. My first-ever MLH hackathon. I’m staring at a blank screen, heart racing, knowing I’m completely outmatched by teams with years of experience.

Then I opened Google Antigravity — and everything changed.

I built RepoX: an interactive platform that turns any public GitHub repository into a living, breathing learning adventure.

No more getting lost in massive codebases. RepoX gives you:

A stunning D3.js force-directed graph that maps every file and its relationships like a neural network
Instant AI-powered explanations for any file (including “Explain Like I’m 5” mode that actually makes sense)
Smart personalized learning paths — the AI reads the entire repo and tells you the exact smartest order to explore it
Progress checklists and history so you never lose momentum

The crazy part? The app itself runs on Gemini. Every explanation and learning path is generated live by the Gemini API (securely routed through Cloudflare Workers).

And yes — this project won Best AI Application Built with Cloudflare at Hacks for Hackers 2026. My very first hackathon… and I took home a prize. I still can’t believe it.

Demo

Live app (paste any GitHub repo and watch the magic): https://main.repox.pages.dev

Full YouTube demo:

Devpost: https://devpost.com/software/repox

GitHub: https://github.com/mutaician/RepoX

What I Learned

This wasn’t just a hackathon project — it was my crash course in what happens when you stop coding alone and start coding with an AI teammate.

I went from zero D3.js experience to building a smooth, responsive graph that handles thousands of nodes. I learned secure API proxying on Cloudflare Workers under extreme time pressure. I mastered prompt engineering at a level I never thought possible — crafting system prompts so precise that Gemini would output perfectly formatted learning paths every single time.

Most importantly, I learned that one determined developer + the right Gemini workflow can outpace entire traditional teams. The confidence this gave me is something no tutorial could ever provide.

Google Gemini Feedback

Gemini wasn’t a tool. It was my co-founder, my senior dev, my QA tester, and my creative director — all in one.

I used Antigravity (Google’s agentic IDE) the entire time:

Gemini 3 Pro handled the heavy lifting — autonomously designing the learning-path algorithm, reasoning through complex repo analysis, and even suggesting UI tweaks that made the graph feel alive.
Gemini 3 Flash was my speed demon — instantly generating UI components, ELI5 explanations, and quick fixes while I kept momentum.
Gemini 2.5 was the reliable fallback when context got too big on massive repos.

What blew me away:
The agentic flow was unreal. I’d describe a feature once, and Antigravity would plan, code, debug, and iterate — often better than I would have done myself. The personalized learning paths Gemini 3.1 created were scarily good — logical, educational, and genuinely helpful.

Where it got messy (keeping it real):
Larger repos sometimes overwhelmed the context window and the agent would start hallucinating relationships or going off on wild creative tangents. I had to get surgical with my prompts and occasionally switch models. Response formatting could be inconsistent (markdown breaking in weird places), and yes, the token costs added up during heavy 3.1 sessions.

But here’s the truth: Without this exact multi-model + Antigravity setup, RepoX would still be a half-finished idea on my laptop. Gemini didn’t just help me finish — it helped me win my first hackathon.

From a nervous solo dev in Kenya to MLH prize winner in 48 hours. That’s the power of Google Gemini.

Thanks for reading my story — can’t wait to see what we build next. 🚀

I Built an AI That Can See Your Arduino and Write the Code For It

Cian — Fri, 27 Feb 2026 17:49:51 +0000

There is a specific frustration anyone who has worked with Arduino knows well.

You have a breadboard in front of you. Components are wired up. You open a chat window, describe your setup in text — "I have an LED on pin 8 with a 220 ohm resistor" — copy the code the AI gives you, paste it into the Arduino IDE, hit upload, and watch the LED do nothing. You go back to the chat window. You describe what happened. You get a revised version. You copy it again.

You do this five times before realizing the AI gave you code for pin 9 because you told it pin 8 and it added a one-line comment that said "change this to match your wiring" which you missed.

Every AI coding assistant has this problem: they are blind to your physical setup.

ArduinoVision is my attempt to fix that.

The Idea

The concept is simple enough to state in one sentence: an AI agent that can see your breadboard through a camera, write the correct Arduino code based on what it actually observes, and upload it directly to your board.

No copy-paste. No IDE switching. No describing your wiring in text. You connect the components. The AI handles everything else.

I built this for the Vision Possible: Agent Protocol hackathon by WeMakeDevs, and the core of it runs on the VisionAgents SDK by Stream.

What VisionAgents Makes Possible

Before I get into the build, I want to explain why this project needed VisionAgents specifically — because that is not an obvious answer.

The challenge with building a hardware coding agent is that it needs three things happening simultaneously and tightly integrated: it needs to see video (your camera), hear audio (your voice), reason about both together (the LLM), and take external actions (compile, upload). Wiring all of that together manually — WebRTC for the camera feed, a separate STT service, a separate LLM call, a separate TTS for the response — is a significant amount of infrastructure before you write a single line of the actual agent logic.

VisionAgents collapses all of that into a few lines of Python.

The relevant part of the agent setup looks like this:

from vision_agents.core import Agent, AgentLauncher, User, Runner
from vision_agents.plugins import getstream, openai

llm = openai.Realtime(model="gpt-realtime", voice="cedar", fps=1)

agent = Agent(
    edge=getstream.Edge(),
    agent_user=User(name="ArduinoVision", id="arduino-vision-agent"),
    instructions=SYSTEM_PROMPT,
    llm=llm,
)

That is the entire transport and LLM setup. getstream.Edge() handles the WebRTC infrastructure — video/audio in and out, connection management, reconnection logic. openai.Realtime() handles speech-to-speech natively — no separate STT or TTS services, no intermediate text conversion, just audio in and audio out with video frames attached. Stream's edge network keeps the latency under 30ms, which matters when someone is physically holding a component in front of the camera.

The fps=1 setting deserves a note. I initially had it at fps=3 and the audio quality was noticeably degraded — cutting out, pitch shifts mid-sentence. Dropping to one frame per second freed up the audio pipeline entirely. For identifying breadboard wiring, one frame per second is more than sufficient.

Registering Arduino Tools

The agent's practical capability comes from tool registration. VisionAgents uses @llm.register_function() to make Python functions callable by the model during conversation:

@llm.register_function(
    description="List all connected Arduino boards. Returns port, board name, and FQBN. ALWAYS call this first to find the port needed for upload."
)
async def list_boards() -> dict:
    boards = list_arduino_boards()
    if boards:
        return {
            "found": True,
            "boards": boards,
            "message": f"Found {len(boards)} board(s). Use the 'port' for upload operations."
        }
    return {"found": False, "boards": [], "message": "No Arduino boards detected."}

I registered six tools in total: list_boards, write_code, compile_code, upload_code, serial_monitor, and deploy_code (which chains the previous three). Each one wraps a call to arduino-cli on the system.

What makes this work well in practice is that the model chains these calls naturally based on the conversation. The user says "make the LED blink." The model calls list_boards to find the port, calls write_code to save the sketch, then deploy_code to compile and upload. The user did not ask it to do those steps in that order — the model inferred the sequence from context and tool descriptions.

The Event System

One thing I found genuinely useful during development was the event subscription API. Every tool call emits a ToolStartEvent and ToolEndEvent:

@agent.events.subscribe
async def on_tool_start(event: ToolStartEvent):
    logger.info(f"TOOL START: {event.tool_name}")
    logger.info(f"Args: {json.dumps(event.arguments, indent=2)}")

@agent.events.subscribe
async def on_tool_end(event: ToolEndEvent):
    if event.success:
        logger.info(f"TOOL END: {event.tool_name} ({event.execution_time_ms:.0f}ms)")
    else:
        logger.error(f"TOOL FAILED: {event.tool_name} - {event.error}")

When you are building a hardware-in-the-loop agent where failures are physical (LED does not blink, board does not respond), having a structured log of every tool call with arguments and timing is essential. It is also how I caught that the model was calling deploy_code before the port permissions were correctly set — the error message was clear in the log instantly.

What I Learned Building This

Real-time video AI has a different failure mode than text AI. With text AI, wrong output is obvious — you read it and fix the prompt. With video AI, wrong output means the board does not respond and you are staring at a stationary LED trying to figure out if the model misidentified the pin, or the code is wrong, or the upload failed, or the LED is wired backwards. Good observability (the event system) is not optional.

Tool descriptions are more important than I expected. The model's behaviour changed significantly based on how I phrased the tool descriptions. "Detect connected Arduino boards" caused the model to call it inconsistently. "List all connected Arduino boards. ALWAYS call this first to find the port needed for upload." made it call the tool reliably every time, in the right order.

Hardware-in-the-loop iteration is slow. Software agents can iterate in milliseconds. Hardware agents have a four-second compile-upload cycle. This changes how you design the system — you want the model to be confident before it acts, not to try-and-retry. Good visual grounding (making sure the agent can clearly see the wiring before generating code) matters more than in pure software contexts.

What It Is Not (Yet)

ArduinoVision is a hackathon prototype. Its scope right now is: AVR boards (Uno, Nano), basic GPIO (digital pins, LEDs, buttons), one board connected at a time. It does not handle I2C sensors, servo control, ESP32/ESP8266, or multi-board setups. These are natural extensions but they are not in this version.

The interface also relies on the VisionAgents demo UI at demo.visionagents.ai rather than a custom frontend. For a prototype this is fine — building a custom WebRTC client is significant work that would have added nothing to the core idea.

The Bigger Picture

The thing that strikes me about this project is how little code it took to get something genuinely useful working. The Arduino tooling (list boards, write, compile, upload) is maybe 300 lines of Python. The agent setup is another 150. The entire relevant surface area is small.

What VisionAgents provides is the hard part: real-time video transport, speech-to-speech latency that feels natural, and a clean function calling interface that the model uses reliably. Without that infrastructure being pre-built, this project would have been two weeks of WebRTC work before a single Arduino command got called.

There is a real category of applications that becomes possible when AI agents can see physical environments and take actions based on what they observe. Hardware debugging is one. Lab automation is another. Physical quality control. Teaching environments where a student shows their circuit and gets immediate, accurate feedback.

ArduinoVision is a small example of what that category looks like when the infrastructure is available.

Try It

The code is on GitHub: github.com/mutaician/arduino-vision

You need a Stream account (free tier works), an OpenAI API key, Python 3.12, and arduino-cli. The README has full setup instructions. If you are on Windows, there are notes on forwarding the USB serial port to WSL.

Built for the Vision Possible: Agent Protocol hackathon by WeMakeDevs. Powered by VisionAgents SDK by Stream.

DEV Community: Cian

KEMT: Benchmarking AI Translation Across Five Kenyan Languages

The first idea did not survive the first experiments

Choosing data I could actually work with

Kikuyu characters replaced by ?: check the file history

Models Tested

Before all this, there were the subscription harnesses

A reply that gave me more than quota

Batching was clever… until it became more work

Even presenting the results needed a few attempts

Findings

Gemini 3.1 Pro surprised me

Going into English was generally easier than coming back

The most important finding was outside the score

What I learned from building it

My Benchmark

Floor: the number you meant to hold

What I Built

How I Built It

The next run was better. The last one wasn't the best.

Demo

Code

Why Does Open Innovation Matter?

Prize Categories

Beside: generosity can be a little of your time

What I Built

Demo

Code

mutaician / Beside

Small, thoughtful ways to show up for someone you care about.

Beside

How I built it

Run the app

How I Built It

Prize Categories

I built Persite because I was tired of guessing GPU costs in my head

The problem I wanted to solve

What I built

High-level architecture

The code that made the project real

Where the clean design broke

Biggest pain point and messy workaround

Trade-offs I accepted

One extra thing I intentionally modeled

How to run it

What I would build next

Links

Gemini Became My Entire Hackathon Team — How a Solo Dev in Kenya Won His First MLH Prize Building RepoX

What I Built with Google Gemini

Demo

What I Learned

Google Gemini Feedback

I Built an AI That Can See Your Arduino and Write the Code For It

The Idea

What VisionAgents Makes Possible

Registering Arduino Tools

The Event System

What I Learned Building This

What It Is Not (Yet)

The Bigger Picture

Try It

Kikuyu characters replaced by `?`: check the file history