DEV Community: Giorgi Kobaidze

Natural Languages Have Design Trade-offs Too: Georgian Is Dynamically Typed, English Is Statically Typed

Giorgi Kobaidze — Thu, 15 Oct 2026 19:22:46 +0000

How This Started
Feature #1: Articles (or the Lack of Them)
- The Upside
- The Downside
Feature #2: Gender
- English: He, She, and It
- Italian: Two Genders, Every Noun
- German: Three Genders
- Georgian: Zero Genders
- The Upside of Gender
- The Downside of Gender
- The Downside of Having No Gender
Complexity Doesn't Disappear, It Moves
Sounds Familiar, Developers?
- Articles vs. var
- Gender vs. Typing
Languages That Evolve (and Ones That Mostly Don't)
Every Language Is a Trade-Off
Tell Me About Your Language

How This Started

I've been doing a little research on how good AI models are with uncommon, niche languages. And Georgian, my native language, is my main test subject. Check out the article for more details:

Kaggle Benchmarking Challenge Submission

Giorgi Kobaidze

Oct 11

Georgian Language Benchmark: Two Biggest AI Labs Clash in a Language That Doesn't Play by Anyone's Rules

#devchallenge #kagglechallenge #ai #machinelearning

20 min read

While comparing outputs, I kept noticing that the hardest parts weren't vocabulary. They were structure: things Georgian simply doesn't encode that English requires, and the other way around.

And because I'm a developer, my brain immediately filed these under one label: language features. Some features make life easier, some make it harder, and almost all of them are trade-offs.

I'll compare English and Georgian, since those are the only two languages I know (for now, German is in progress). I love both of them, and both are beautiful in their own way. But they couldn't be more different. Georgian has its own alphabet, Mkhedruli, with 33 letters and no uppercase or lowercase in everyday writing. Yes, my native language is case-insensitive by design. We don't really need casing at all.

Let's look at two features.

Feature #1: Articles (or the Lack of Them)

English marks whether a noun is definite (a specific thing the listener already knows about) or indefinite (something new or non-specific). That's the whole job of the versus a/an.

I saw a bus leaving the station. The bus was a white MCI 102-DL3 with silver rims and a Greyhound badge on it.

Georgian has no articles at all. Structurally, the same sentence looks like this:

I saw bus leaving station. Bus was white 1999 MCI 102-DL3 with silver rims and Greyhound badge on it.

In actual Georgian:

დავინახე, როგორ გადიოდა ავტობუსი სადგურიდან. ავტობუსი იყო თეთრი MCI 102-DL3, ვერცხლისფერი დისკებით და Greyhound-ის ემბლემით.

No articles. None. Zero. Null. Undefined.
The listener figures out definiteness from context: what was mentioned before, word order, and the situation itself. The first "bus" is obviously new information, the second one is obviously the same bus.

That doesn't mean Georgian is helpless when it needs precision. It just reaches for other tools on demand:

Demonstratives like ეს (this) and ის (that) make something definite:

this/that bus

In casual speech, ერთი (one) often works like an indefinite article:

ერთი კაცი შემხვდა ("I met a (certain) man")

The Upside

It's simpler. Fewer words to say and write, and nothing to choose. You never have to stop and think about which article goes where, which is famously one of the hardest parts of English for people whose native languages don't have articles.

The Downside

It's not explicit, and implicit things occasionally become ambiguous. Rarely, but it happens. If someone tells you:

Take bus

Do they mean a bus, any bus, or the bus that's standing right in front of you? In real life, the speaker resolves it with intonation, a gesture, or by saying:

Take this bus

But that doesn't always happen.

And here's where it connects back to my AI research: when a model translates Georgian into English, it has to insert information that wasn't in the source. Every "a" and "the" in the output is a guess. Usually a good one, but still a guess.

Feature #2: Gender

From what I've observed, languages are absolutely obsessed with sorting things by gender. But there are actually two different things going on, and it's worth separating them:

Natural gender: pronouns reflect the actual gender of a person. That's English.
Grammatical gender: every noun belongs to a class, including spoons, tables, and the moon. That's Italian, German, and many others.

English: He, She, and It

English has he/him/his, she/her/hers, and it/its. That's as far as it goes, and it mostly follows reality: people get he or she, a table is "it". (Except ships, which are sometimes "she" for reasons sailors would have to explain.)

Italian: Two Genders, Every Noun

Italian has masculine and feminine, and every noun has to pick one. There are patterns (nouns ending in -o are usually masculine, -a usually feminine), and then the exceptions show up:

la mano (hand) is feminine, despite ending in -o
il problema (problem) is masculine, despite ending in -a
il sole (sun) is masculine, la luna (moon) is feminine

Logic behind it? Nobody knows. Well, at least I don't. You just memorize them.

German: Three Genders

Think that's complex? German has three: masculine (der), feminine (die), and neuter (das). Look at your dinner table:

der Löffel: the spoon is masculine
die Gabel: the fork is feminine
das Messer: the knife is neuter

Three pieces of cutlery, three genders. It gets better: das Mädchen (the girl) is neuter, because the diminutive suffix -chen always makes a word neuter. Grammar beats biology. And the sun and moon? die Sonne is feminine and der Mond is masculine, the exact opposite of Italian. If gender were logical, the two languages would at least agree on the sky.

I recently started learning German, and honestly, der/die/das is the hardest part for me. The standard advice is to never learn a noun without its article, and now I understand why.

Georgian: Zero Genders

When I was a kid and started learning other languages, this was the weirdest thing of all. Why on earth are words divided by gender? That was absolute nonsense to me. Because in Georgian, there's no gender. None. Zero. Not even for people.

The same pronoun covers he, she, and it: ის (he/she/it), მას (him/her/it, as an object), მისი (his/her/its). The only distinction Georgian makes is between people and things, with ვინ (who) versus რა (what). Which is natural. Nobody asks:

Who is that truck?

The Upside of Gender

It carries information.

My boss is really lovely, she told me I'm doing a great job during the meeting.

One pronoun, and you already know your boss is a woman.

It helps you track references. This is the advantage people rarely mention. In German:

Die Gabel liegt neben dem Löffel. Sie ist schmutzig.

Sie can only be the fork, because the fork is feminine and the spoon isn't. In English, the same sentence is ambiguous:

The fork is next to the spoon. It is dirty.

In Georgian, it's equally ambiguous. Grammatical gender works like a checksum: redundant information that helps the listener connect the right pronoun to the right noun.

The Downside of Gender

What if you don't know?

Tell your boss to give you some vacation days, he or she should be concerned that you're working so much.

Now you have to say both, and it gets clunky fast.

English's escape hatch is singular "they":

When a developer joins the meeting, ask them to show you where the repository is.

One developer, plural pronoun. My first instinct was that this is technically incorrect, but it turns out English speakers have been doing it since the 14th century, and writers like Shakespeare and Jane Austen used it. Even better: English has done this exact trick before. You was originally plural only; the singular was thou. Over time, "you" took over the singular too, and nobody today thinks "you are" is a grammar bug. Singular "they" is the same migration, still in progress.

The memorization tax. For people, gender carries meaning. For spoons and forks, it carries none, yet Italian and German learners still have to memorize it for every single noun.

The Downside of Having No Gender

Georgian's simplicity has a price too. If you want to express gender, you have to say it explicitly: man or woman, gentleman or lady. "My friend" (მეგობარი) tells you nothing about who that friend is.

And once again, this is a real problem for AI. Translating ის into English forces a choice between "he" and "she" that the original sentence never made. Machine translation systems have historically filled that gap with stereotypes: the doctor becomes "he", the nurse becomes "she". Those assumptions are never good.

Complexity Doesn't Disappear, It Moves

Before anyone concludes that Georgian is "easy mode", it isn't. Far from it, it's so complex, sometimes even native speakers struggle to speak or write grammatically correct, It just stores its complexity somewhere else, mostly in verbs.

A single Georgian verb can encode both the subject and the object. მიყვარხარ means "I love you". One word, three ideas. Verbs change form across groups of tenses, and even the case of the subject changes depending on the tense. Georgian dropped articles and gender, then poured all that saved effort into verbs that do an enormous amount of work.

There's a principle in software for exactly this: Tesler's law, or the law of conservation of complexity. Complexity can't be removed, only moved. Languages, it seems, follow it too.

Sounds Familiar, Developers?

All of this reminded me of programming languages, because they face the exact same trade-offs.

Articles vs. `var`

Georgian's missing articles map almost perfectly onto type inference in C#:

Bus bus = new Bus("MCI 102-DL3");   // explicit: "the bus"
var bus = new Bus("MCI 102-DL3");   // implied, but obvious from context
var next = dispatcher.Next();        // ...is that a Bus? A Route? "take bus"

The compiler always knows what next is. The human reading the code might not. That's why many teams have a style rule along the lines of "use var only when the type is obvious from the right-hand side". It's the Georgian rule exactly: implicit is great when the context makes it obvious, and when it doesn't, you say "this bus" or write the type out.

C# even went in the other direction with target-typed new, where the left side carries the information and the right side drops it:

Bus bus = new("MCI 102-DL3");

Same idea, different side of the sentence.

Gender vs. Typing

German grammatical gender behaves a lot like static typing. Every noun carries a tag, and everything around it (the article, the adjective endings) has to agree with that tag. It's ceremony, and sometimes it feels like noise, but mismatches get caught and references are easier to track.

Georgian pronouns are closer to dynamic typing. ის can hold anything: a person, a truck, an idea. Less ceremony, more flexibility, and meaning gets resolved at "runtime" from context.

C# won't let you mix types without saying so:

int distance = 5;
string label = "2";
var total = distance - label;
// error CS0019: Operator '-' cannot be applied to operands of type 'int' and 'string'

JavaScript will happily guess what you meant:

"5" - 2   // 3
"5" + 2   // "52"
[] + []   // ""

(To be precise, static vs. dynamic and strong vs. weak are two different axes. Python is dynamic but strongly typed: "5" + 2 raises a TypeError. JavaScript is dynamic and weakly typed, which is how you get "52".)

And the arbitrary part of German gender? Imagine a language that forces you to annotate every variable with a type, where the type names were assigned by rolling dice centuries ago, and nobody is allowed to refactor. That's der Löffel, die Gabel, and das Messer.

Languages That Evolve (and Ones That Mostly Don't)

Here's where natural languages and programming languages really differ.

Programming languages learn from each other constantly. C# is a great example. It added generics, then lambdas and LINQ (borrowed from the functional programming world), pattern matching inspired by F# and the ML family, records, and nullable reference types to fight what Tony Hoare called his "billion-dollar mistake". And it doesn't only borrow, it lends: async/await, introduced in C# 5, was later adopted by JavaScript, Python, Rust, and many others.

Natural languages mostly borrow words. English took beef, pork, and mutton from French after the Norman conquest, while the living animals stayed cow, pig, and sheep. Georgian borrowed კომპიუტერი (computer) and ტელეფონი (telephone) like nearly every other language on Earth. Sometimes a borrowed word wins so completely that people forget the original word in their own language ever existed.

The structure, on the other hand, usually stays put. Usually. Natural languages do refactor, just very slowly:

Old English had three grammatical genders, just like German. By the Middle English period, they were gone. English deprecated a feature that German still ships today.
Thou was deprecated, and you absorbed its job, which is exactly the precedent for singular "they".

The difference is the release process. There's no changelog and no migration guide, a breaking change takes a few centuries to roll out, and every speaker is a maintainer.

Every Language Is a Trade-Off

No matter what design you come up with, there will always be trade-offs. Articles buy precision and cost effort. Gender buys information and reference tracking, and costs memorization. Dropping both buys simplicity and costs explicitness, then the complexity sneaks back in through the verbs.

Every language is beautiful in its own right, and the same goes for programming languages. Learning a new one, spoken or compiled, is the best way to discover assumptions you didn't even know you had. Georgian taught me that a language can live perfectly well without "a/an/the" and "she/he". C# taught me why var needs a style guide. And German is currently teaching me how insanely hard it is.

As for AI: the places where languages disagree on what to encode are exactly the places where models have to guess. Which is precisely why I'm benchmarking them in Georgian.

Tell Me About Your Language

Now it's your turn. What languages do you speak, and how do they handle these features? Do they have articles? Grammatical gender? Is your native language "statically" or "dynamically" typed? Tell me in the comments. I'd love to see which languages follow the same patterns and which break all the rules.

Enjoyed this write-up? Let's stay connected!

I share more software engineering insights, projects, and experiments across these platforms:

Georgian Language Benchmark: Two Biggest AI Labs Clash in a Language That Doesn't Play by Anyone's Rules

Giorgi Kobaidze — Sun, 11 Oct 2026 19:40:43 +0000

This is a submission for the Kaggle Benchmarking Challenge

One Eye, Zero Excuses
What I Benchmarked
- Why Georgian?
- What I Built
- The Plan vs Reality
- The Five Tasks
- How It Runs on Kaggle
- Obstacles and Workarounds
Models Tested
Findings
- Level by Level
- Finding 1: Understanding Georgian Is Solved. Producing It Isn't.
- Finding 2: Numbers Are the Final Boss
- Finding 3: The Mistakes Are Very Georgian
- Finding 4: Georgian Costs More Tokens for Claude
- Finding 5: Cheap Can Be Smart
- Side Quest: The Uninvited Guest
- What It All Cost
- The Dashboard
- Limitations
- What's Next
My Benchmark
- Wrapping Up

One Eye, Zero Excuses

I really wanted to record a video for this one, just like I always do for my challenges. But yesterday I had a small surgery on my eyelid, and right now one of my eyes is swollen and patched up. Here's the current state:

Yep. I look like a pirate now. All I'm missing is a parrot and a cool nickname (suggestions are welcome in the comments).

But don't worry (if you were going to): I'm totally fine and my eyesight is still eagle-like from both eyes. It was just a small bug fix in the eyelid module. The eye itself is still in production and running smoothly.

That said, finishing a project with one-eye-patched-up is way harder than it sounds. Depth perception? Gone. Reading code? Awful. I don't believe in curses, but every time I join a challenge, something happens. If someone out there cursed me, please, just lift it. Give me a break! I just wanna work goddammit!

By the way shout out to my brother for chauffeuring me home from the hospital, because one-eye-patched-up driving felt like a really bad idea.

But a deadline is a deadline, and professionals deliver, no matter what. So I gave myself a little pep talk: "Dude, Michael Bisping became a UFC champion with basically one working eye. You can finish a coding project. No excuses, you're not lame." And so I did.

Let me tell you what I built.

What I Benchmarked

Why Georgian?

I benchmarked OpenAI's and Anthropic's models on how well they understand and produce Georgian. The whole process turned into a real adventure, but before we get to that, let me tell you why I picked this topic.

One of a Kind and Tough as Nails

Georgian is one of the oldest languages in the world. It has its own alphabet and doesn't belong to any of the major language families. It's totally unique. Phonetically, it sometimes kind of sounds like Italian, because both languages are obsessed with vowels, but that's where the similarity ends. And vowel obsession doesn't mean weak consonants. Quite the contrary: Georgian has consonants most people have never heard, stacked in clusters that make everyone struggle (try saying გვფრცქვნი, with eight consonants in a row; it basically means "you peel us", and yes, I know it sounds like nonsense, but technically that word exists). It's an incredibly rich language.

Grammatically, it's ridiculously tough. I take it for granted, because first, I'm Georgian, and second, I'm a language nerd (even when I'm learning other languages). I know Georgian grammar well, but even most Georgians don't know every detail of the Georgian grammar, and I know almost nobody who speaks it without a single mistake. Yes, it's that deep and complex.

Even I, a grammar nerd, had my dataset checked by a language specialist to make sure I got things right. And I was so happy when she came back with only 3 or 4 minor corrections.

Straight Out of a Fantasy Game ("შენ გგონია მომიგე? არა, ცდები!")

Georgian has a special charm of its own. The letters are round-shaped and beautiful, and it looks like an elvish script from some fantasy movie or game. And speaking of games, it was actually used in The Witcher 3's Hearts of Stone expansion. Remember the moment you defeat Gaunter O'Dimm? Somewhere in the middle of his short speech, he says:

"შენ გგონია მომიგე? არა, ცდები!"
("You think you've defeated me? No, you're wrong!")

Then he goes on in some other languages. The developers wanted him to speak some ancient, otherworldly tongue, so instead of some gibberish, they picked a few real languages that fit the vibe. Georgian was one of them.

Alright, enough flexing about how awesome my first language is. Let's get to the technical part.

What I Built

The Georgian Language Benchmark is a set of five tasks on Kaggle Benchmarks that test how well AI models handle Georgian: not just reading it, but actually producing it correctly. Every single dataset was written by hand by me, from scratch. No machine translation, no generated text.

It took some time and effort... by "some" I mean an ungodly amount of time and effort.

The Plan vs Reality

My original plan was, let's say, ambitious. Nine dimensions of Georgian (numbers, verbs, translation, chat-style Georgian written in Latin letters, proverbs, date and time, grammar judgment, even images), and all 41 models in Kaggle's catalog. I estimated a full run at around $345.

I was totally fine with that. The whole point was to build something comprehensive, not to save money. And let's be real: if I won, the prize money would totally make up for it.

But...

Then I found out how Kaggle's model credits actually work: you get $10 per day, for free, and that's it. You can't top it up with your own money. I literally went looking for the "add funds" button and it doesn't exist. (There's a research grant program, but not on a challenge deadline.)

Oh I was so frustrated and mad at myself for not researching Kaggle's rules properly. I had to dramatically change my approach.

So $10 a day it was. And that one constraint ended up shaping (or, to be more precise, re-shaping) almost every decision in this project:

41 models became 8. Two vendors, four levels, real pairs instead of a crowd.
9 dimensions became 5. Vision, proverbs, date and time and grammar judgment were cut. The chat-Georgian task (45 items) was built, then dropped too.
The datasets got trimmed to the items that actually separate models (more on that below). Nothing was thrown away: the full sets live in the repo's archive/ folder for anyone who wants to run them outside Kaggle.

On the flip side, the constraint made the benchmark better. Fewer, sharper items, and a fair fight instead of a crowded leaderboard.

The Five Tasks

Here's what the models had to face. Every example below is a real item from the benchmark.

1. Numbers: Counting in Twenties

Georgian counts in twenties. 99 is ოთხმოცდაცხრამეტი, literally "four twenties and nineteen". On top of that come ordinals, fractions, decimals and numbers all the way up to 10³⁹, in both directions: digits to words and words to digits.

Question	Expected
44th, in words	ორმოცდამეოთხე
თვრამეტი (18), its ordinal in digits	მე-18
1000000, in words	მილიონი

That middle one is sneakier than it looks. A Georgian ordinal in digits keeps its prefix in front (მე-18) when the word starts with მე-, and takes a suffix (21-ე) when it doesn't. Hold that thought, it comes back in the results.

158 questions, scored by exact match (with | separating alternative correct answers).

2. Verbs: Who Did What to Whom?

A single Georgian verb can carry a whole sentence: who does it, to whom, and when. მიყვარხარ means "I love you" (awww, by the way), all in one word. The task has three kinds of questions:

Who to whom: read a verb form and pick who acts on whom.
Form: build the right verb form for given persons and tense.
Preverb: pick the prefix that gives the right meaning in context.

id,kind,input,choices,expected
verbs-000,who_to_whom,მიყვარხარ,A) ის → შენ|B) მე → ის|C) შენ → მე|D) მე → შენ,D

50 items, multiple choice with letter answers or exact match.

3. Translation: Georgian to English

Twelve short paragraphs packed with idioms and tricky verbs, to be translated into English. For example, ხელი სთხოვა literally means "asked for (her) hand", but what it really means is "proposed".

Since there's more than one good translation, a judge model compares the meaning (not the wording) with my reference translation, on a 5-level scale:

4 = same meaning, nothing missing, wrong or added
3 = a small slip (a minor detail, tense or nuance), the main meaning intact
2 = partly right: one important part is wrong or missing
1 = only fragments right, the overall meaning is lost
0 = wrong, unrelated, or not English

One fun detail: Georgian has no grammatical gender, so the judge is told explicitly that "he", "she" or "they" are all fine when the Georgian text doesn't reveal it. The judge is always the same model, Gemini 3 Flash, which is not one of the models being tested.

4. Cloze: Fill the Gaps

Two short articles, one about the history of computers and one about the Roman Empire, with 25 gaps each. The model gets a list of 30 words in their dictionary form, including 5 that don't belong anywhere (like "television", "banana" or "airplane" in an article about Rome). It has to pick the right word for each gap and put it in the right grammatical form.

Example: ძველ [1] ... → დროში ("in old times")

50 gaps, scored one by one.

5. Correction: Fix It, Don't Break It

Paragraphs with planted grammar, spelling and punctuation errors. The model must fix them without touching anything that's already correct. Here's one sentence from a real item:

❌ მთელი ოჯახი მაგიდაზე დაჯდა და ერთად ვივახშმედ.
✅ მთელი ოჯახი მაგიდას შემოუსხდა და ერთად ვივახშმეთ.

Scoring is the part I'm most proud of. It counts word-level differences from the correct text before and after the model's edit:

# errors_before: how far the input is from the correct text
# errors_after:  how far the model's answer is from the correct text
score = max(0, (errors_before - errors_after) / errors_before)

Fix 3 of 4 errors and you get 0.75. But "fix" a correct word into a wrong one, and that's a new error, which pulls your score down. Rewriting the whole paragraph in your own style doesn't pay off either. Over-correction is punished, just like a strict teacher would do it.

17 paragraphs.

Writing It All by Hand

All of this data came out of my own head, one item at a time: 186 number rows, 115 verb items, 47 translation paragraphs, 51 correction paragraphs, 45 chat texts and two cloze articles. Then a language specialist reviewed everything, and I applied her corrections.

But with $10 a day (allowed by Kaggle), I couldn't afford to run all of it on eight models. So I trimmed it. For numbers and verbs, I used a probe model: I ran a cheap model over the full sets, kept every item it got wrong, and dropped part of the ones it found too easy. Big numbers stayed untouched. For translation, I kept the 12 paragraphs with the most Georgian-specific traps, I picked the correction paragraphs by hand, and the cloze texts stayed in full.

Task	Written	Kept
Numbers	186 rows	82 rows (158 questions)
Verbs	115	50
Translation	47	12
Cloze	2 texts	2 texts (50 gaps)
Correction	51	17

That means 287 scored items per model. And yes, it means the benchmark is hard on purpose. The absolute scores are lower than they'd be on an easy set, and the ranking is what matters.

How It Runs on Kaggle

Kaggle Benchmarks lets you write a task as plain Python with the kaggle-benchmarks library. Kaggle runs it on any model from its catalog and stores every call: the prompt, the answer, the tokens and the cost.

Every task in my benchmark has the same shape: a small item task that asks one question and scores it, and an outer task that runs it over the whole dataset and reports one score. Here's the numbers task, slightly simplified:

@kbench.task(name="glb-numbers-item", store_task=False)
def number_item(llm, qid, kind, form, text, expected) -> bool:
    got = normalize(ask(llm, PROMPTS[(kind, form)].format(text=text)))
    accepted = [normalize(e) for e in expected.split("|")]
    kbench.assertions.assert_in(got, accepted, expectation=f"{qid}: {text} -> {expected}")
    return got in accepted


@kbench.task(name="glb-numbers")
def numbers(llm) -> float:
    runs = number_item.evaluate(
        llm=[llm], evaluation_data=QUESTIONS, n_jobs=2, on_failure="continue"
    )
    correct = sum(1 for r in runs.completed_runs if r.result is True)
    return correct / len(QUESTIONS)


numbers.run(kbench.llm)

The data lives in a Kaggle dataset, and the whole workflow runs from the terminal with the Kaggle CLI:

scripts/push_data.sh "what changed"                  # upload data/ as a Kaggle dataset
scripts/push_task.sh glb-verbs tasks/glb_verbs.py    # push a task
kaggle b t run glb-verbs -m gpt-5.4-2026-03-05 --wait
kaggle b t download glb-verbs -m gpt-5.4-2026-03-05  # every answer, token and cost

Obstacles and Workarounds

This is where the adventure really started. Here's everything that tried to stop me, and how I got around it.

Obstacle 1: Kaggle Reserves the Worst Case

Before every single call, Kaggle reserves the maximum possible cost of that call: the model's maximum output length times its price. If that doesn't fit into your remaining quota, the call is refused, even if the real answer would cost a fraction of a cent:

max estimated cost of operation ($1.60195) exceeds your available quota
(based on max_output_tokens)

My first top-tier runs died exactly like this: many of the calls were refused, with plenty of real money still left in the quota.

Workaround: a generous but sane output limit, and only two calls in parallel:

# The longest answer seen in testing was 26,600 tokens.
OUTPUT_LIMIT = {"max_completion_tokens": 32000}
...
runs = number_item.evaluate(llm=[llm], evaluation_data=QUESTIONS, n_jobs=2, ...)

Obstacle 2: Failed Calls Look Like Wrong Answers

When a call fails (quota gone, API hiccup), the item just counts as wrong. So a run that ran out of money halfway would happily report a score of 0.3 and put it on the leaderboard as if the model were bad at Georgian. That's not a score, that's a lie.

Workaround: an error guard in every task. A few isolated failures (after 3 retries) count as wrong, but if more than 5% of the calls fail, the task stops and reports nothing:

errored = len(runs.errored_runs)
if errored > 0.05 * len(QUESTIONS):
    raise RuntimeError(f"{errored} of {len(QUESTIONS)} items failed with errors; no score reported.")

It paid off right away: when the worst-case reservation (Obstacle 1) killed my first top-tier runs, both stopped cleanly without a fake score.

Obstacle 3: Some Models Think by Default

Some models "think" before answering: they reason privately in hidden text, and you pay for every hidden token. One of my test runs wrote about 770,000 hidden tokens to answer 251 questions, most of which had one-word answers. GPT-5.5 wrote about 750 hidden tokens to answer a single multiple-choice question with one letter.

Worse, it wasn't fair: some of my models thought by default and some didn't. Comparing a thinking model with a non-thinking one says more about the setting than about the model.

Workaround: the same conditions for everyone. No thinking, every model answers directly:

llm.prompt(prompt, schema=Answer, reasoning="none", extra_api_params=OUTPUT_LIMIT)

Without thinking, a full run costs about 99% less. And every model plays by the same rules.

Obstacle 4: The Model That Won't Stop Thinking

When I got to the newest pair, GPT-6 Astra simply refused:

reasoning_effort does not support 'none' with this model.
Supported values are: 'low', 'medium', 'high', and 'xhigh'.

Workaround: the newest pair gets its own rule. Both Claude Opus 5 and GPT-6 Astra think at the lowest level ("low"), so they compete on equal terms with each other. They're marked ⚡ / LOW everywhere in the dashboard, so nobody compares them with the no-thinking models by accident:

LOW_THINKING = ("claude-opus-5", "gpt-6-astra")

def reasoning_for(llm) -> str:
    name = getattr(llm, "model", "") or ""
    return "low" if any(m in name for m in LOW_THINKING) else "none"

Obstacle 5: Every Push Runs the Task

Every time you push a new version of a task, Kaggle runs it once on its default model, Gemini 3.7 Flash, and that run is billed to your quota too. Each re-push of the full benchmark cost me between $0.45 and $1.00. By the end, these automatic runs had cost me almost $3, more than half of what the final comparison runs cost. Lesson learned: test locally, push rarely.

Obstacle 6: The Small Stuff

The dataset path moves. Kaggle mounts the dataset somewhere under /kaggle/input, but the exact path varies. So every task searches for its file:

  def data_file(name: str) -> Path:
      kaggle_input = Path("/kaggle/input")
      if kaggle_input.exists():
          return sorted(kaggle_input.rglob(name))[0]
      return Path(__file__).resolve().parent.parent / "data" / name

No automatic retries. Nested evaluations can't retry failed items, so every task retries API errors itself, 3 times with a 10-second pause.
Credentials expire. For local test runs, Kaggle's model proxy credentials expire every couple of hours. kaggle b auth -y refreshes them.
Look-alike characters. A hyphen and an en dash look the same but aren't, so answers are normalized before comparison (Unicode normalization, dash-like characters, extra spaces).

Models Tested

I put eight models from Anthropic and OpenAI through the benchmark, paired level by level, under identical conditions:

Level	Anthropic	OpenAI
Light	Claude Haiku 4.5	GPT-5.4 mini
Decent	Claude Sonnet 4.6	GPT-5.4
Top	Claude Opus 4.8	GPT-5.5
Newest ⚡	Claude Opus 5	GPT-6 Astra

⚡ The newest pair is a special case: as you saw in Obstacle 4, GPT-6 Astra simply refuses to stop thinking, so both models of that pair think at "low".

Here are the rules every model played by:

Rule	Why
No thinking	Every model answers directly. Mixing thinking and non-thinking models wouldn't be fair.
One marked exception	GPT-6 Astra can't switch thinking off, so the newest pair both think at "low". Marked ⚡ everywhere.
Comparable pairs	Each level pairs an Anthropic and an OpenAI model of the same class.
Same prompts, same code	English instructions, Georgian content, one task version for everyone.
A fixed judge	Translations are judged by Gemini 3 Flash, which isn't one of the tested models.
Partial credit where it's fair	Correction rewards every fixed error and penalizes every correct word broken.
Failures never look like scores	Above 5% failed calls, a task reports no score at all.

Findings

Drumroll, please. 🥁

Model	Numbers	Verbs	Translation	Cloze	Correction	Average	Cost
Claude Haiku 4.5	0.30	0.34	0.96	0.54	0.25	0.48	$0.10
GPT-5.4 mini	0.41	0.42	1.00	0.52	0.67	0.60	$0.05
Claude Sonnet 4.6	0.39	0.52	1.00	0.76	0.44	0.62	$0.29
GPT-5.4	0.46	0.54	1.00	0.88	0.66	0.71	$0.15
Claude Opus 4.8	0.54	0.68	1.00	0.84	0.68	0.75	$0.58
GPT-5.5	0.51	0.60	0.98	0.88	0.74	0.74	$0.30
Claude Opus 5 ⚡	0.65	0.84	1.00	0.86	0.77	0.82	$1.22
GPT-6 Astra ⚡	0.83	0.90	0.98	0.96	0.82	0.90	$1.73

Level by Level

Light: GPT-5.4 mini beats Claude Haiku 4.5, 0.60 vs 0.48, and costs half as much.
Decent: GPT-5.4 beats Claude Sonnet 4.6, 0.71 vs 0.62, again at about half the price.
Top: Claude Opus 4.8 edges out GPT-5.5, 0.75 vs 0.74. That's basically a tie.
Newest ⚡: GPT-6 Astra beats Claude Opus 5, 0.90 vs 0.82, the best score of the whole benchmark. It's ahead on four of the five tasks, with the biggest jump on numbers (0.83 vs 0.65).

Final tally: OpenAI wins 3 of the 4 levels, and Anthropic's only win, at the top level, is basically a tie.

One disclaimer: this is my dataset, my rules. Test other areas of Georgian and the results might shift a bit. That said, I tried to keep the tasks as broad and general as I could.

Finding 1: Understanding Georgian Is Solved. Producing It Isn't.

Look at the translation column: 0.96 to 1.00 for every model. Every one of them understands Georgian well enough to translate it into English almost perfectly.

Now look at the other four columns. The moment a model has to produce correct Georgian (build a number, form a verb, inflect a word, fix a sentence), the scores drop hard. Without thinking, even the best model (Claude Opus 4.8) gets almost half of the number questions wrong. Only GPT-6 Astra, with its small thinking budget, gets above 0.80.

Finding 2: Numbers Are the Final Boss

Numbers are the hardest task for 6 of the 8 models, and close to the bottom for the other two. And inside it, the gap is wild:

Question type	Range across models
Words → digits, cardinal	0.74 to 0.96
Words → digits, ordinal	0.04 to 0.92
Huge numbers, 10¹⁵ to 10³⁹	0.06 to 0.53

Reading a Georgian number into digits: fine. Writing its ordinal in digits: disaster. GPT-6 Astra is the big exception there with 0.92, while the next best model gets 0.62. Remember მე-18 from earlier? Most models wrote the suffix form instead, because that's the pattern they've seen more often. With მე-40000 (forty-thousandth), only 2 of the 8 models got it right.

Finding 3: The Mistakes Are Very Georgian

My favorite part of the whole project is reading the wrong answers. They're not random. They're what you'd get if you tried to speak Georgian with grammar borrowed from somewhere else:

"I fell in love with you." In Georgian, falling in love is an inversion verb: the one who loves is marked like an indirect object, so it's შემიყვარდი, literally "you became loved to me". Only GPT-6 Astra got it right. The others mostly built an ordinary transitive verb instead (შეგიყვარე).
"We sat." Georgian uses a different verb root for sitting when the subject is plural: "I sat" is ვიჯექი, but "we sat" is ვისხედით. I planted ვიჯექით (a mix of the two) in a correction paragraph. Not a single model fixed it.
"Who wrote it?" In დაგიწერია, the გ- marks "you" as the writer: "you have (apparently) written it". In the Georgian perfect, the markers flip. Only 2 of the 8 models got it right; the rest scattered across every other reading.
One million. It's simply მილიონი. Most models write ერთი მილიონი ("one million") instead.

Finding 4: Georgian Costs More Tokens for Claude

Same prompts, same Georgian text, very different token counts. Claude models used 2 to 2.6 times more input tokens than GPT models for exactly the same questions:

Task	Claude, input tokens per call	GPT, input tokens per call
Numbers	272	104
Verbs	310	130
Cloze	1,412	699
Correction	404	159

Part of that is each vendor's answer-format instructions, and part is how each tokenizer splits Georgian script. In practice it means a Georgian prompt costs a Claude user noticeably more than the price per token suggests.

Finding 5: Cheap Can Be Smart

Cost per correct answer, on the tasks scored right or wrong:

GPT-5.4 mini: 0.03 cents per correct answer. The bargain of the benchmark.
Claude Opus 5 ⚡: 0.55 cents per correct answer, about 17 times the price of GPT-5.4 mini.
GPT-6 Astra ⚡: 0.67 cents per correct answer. The best score, but about 21 times the price of GPT-5.4 mini per correct answer.

Side Quest: The Uninvited Guest

Remember Gemini 3.7 Flash, the model Kaggle runs automatically on every push? It's not part of my comparison, but it took the test every time I pushed, so I have its scores too. And it quietly scored around 0.89 on average, above every model in my table except GPT-6 Astra (0.90).

The catch: even with thinking set to "none", it kept writing about 480 output tokens per number question, while the models without thinking wrote about 16. So it seems to keep thinking a little no matter what you tell it. Which leads to a fun takeaway: for a language like Georgian, thinking seems to matter more than model size. The two best models in my table, GPT-6 Astra and Claude Opus 5, both think at "low" too.

What It All Cost

The whole project ran on Kaggle's free daily credits. Total spend across all the testing, probing and final runs:

	Cost
Final comparison runs	$4.63
Kaggle's automatic push runs	$2.88
Earlier runs and cost probes	$2.86
Local test runs	$3.46
Total	$13.84

Yes, the automatic push runs alone cost more than half as much as the actual benchmark. And spreading it over several days was the only way to stay under $10 a day.

The Dashboard

Tables are nice, but I wanted something you can actually explore. So all the results live on an interactive dashboard:

Overview: the level-by-level showdown, the task matrix and the key findings
Cost & tokens: what each model paid per task, the token gap, cost per correct answer and the full project spend
Tasks: numbers by question type, verbs by type, correction split into fixed / missed / broken, and every cloze gap for every model
Examples: real questions with every model's actual answer and an explanation of the mistake
Method: where the data comes from, how each task is scored, the conditions and the limits

It's a single static HTML page with no framework, no build step and no chart library, generated by a Python script straight from Kaggle's run files. So the dashboard and this article can never disagree.

👉 georgekobaidze.github.io/georgian-language-benchmarks

Limitations

Let's be honest about what this benchmark can and can't tell you:

Hard by design. The sets keep mostly items a model got wrong, so the absolute scores are lower than they'd be on an easy set. The ranking is the meaningful part.
Small sets. Some tasks have only 12 to 17 items, so a difference of a few points isn't significant.
One run per model. Re-runs of the same model differed by about ±0.03 per task.
The judge is a model. Translation scores depend on Gemini 3 Flash's judgment of meaning.
The token gap includes format overhead, not only the tokenizer.

What's Next

Bigger sets. The full, untrimmed datasets are already in the repo's archive/ folder, ready for a run without the daily cap.
More vendors. Google, xAI and the open models, once the budget allows.
Thinking vs no thinking. The Gemini side quest begs for a proper experiment: the same model with and without thinking, on the same items.
More Georgian. Native speakers are very welcome to contribute new items, corrections and alternative answers.

My Benchmark

📊 Dashboard: georgekobaidze.github.io/georgian-language-benchmarks
🏆 Benchmark on Kaggle: kaggle.com/benchmarks/georgekobaidze/georgian-language-benchmark (the leaderboard only shows the models that ran on the latest version of the tasks, where the newest pair ran with "low" thinking; all 8 models are on the dashboard)
💻 Code: github.com/georgekobaidze/georgian-language-benchmarks

Wrapping Up

I started this with patches on one eye, and ended it with a benchmark, a dashboard and a lot of respect for how hard my own language is. The models understand Georgian almost perfectly. Producing it correctly is a whole different story, and that's exactly the gap this benchmark measures.

And where the hell is my PhD? I've seen people (multiple of them) getting PhDs for exponentially less, and I'm not even kidding. I'm dead serious.

If you speak Georgian, go check the Examples tab and tell me which mistake made you laugh the most. And if you have a good pirate nickname for me, you know where the comments are.

If you don't speak Georgian and are planning to learn it, think twice and ask yourself if you're fully committed, because it can take a good 3 to 4 years (or more) of absolutely intense learning, and even then you'll be barely average. Reach out and let me know if you need any tips.

Enjoyed this write-up? Let's stay connected!

I share more software engineering insights, projects, and experiments across these platforms:

I Turned My GitHub Profile Into a Cyberpunk Console With a City Built From My Contributions

Giorgi Kobaidze — Thu, 01 Oct 2026 18:02:38 +0000

I just wanted a custom profile. I completely overcooked it.

Don't feel like reading? Fair. But you're going to miss a lot of interesting insights. Anyway, here's my profile link:

georgekobaidze (Giorgi Kobaidze) · GitHub

Software Engineer | Engineering Manager | Technical Writer |🏆2x Hackathon Winner | ☕Enjoyer - georgekobaidze

github.com

I Wanted a Simple Custom GitHub Profile. But Things Got Out of Hand Quickly
- 23:00. Fully Cooked.
- Random Doesn't Mean Bad
- Why Do I Keep Doing This to Myself?
The Contribution City
- The City That Represents Me
- The Moment It Clicked
The Cyberpunk Console
- Because Why Not?
Welcome to the Sandbox
- No JavaScript. No CSS. No Fun?
- The Loophole: An SVG Is Just an Image
- Okay, But the Sandbox Has Rules
One Console, 23 Images
- The Problem: Images Don't Hold Hands
- Slicing the Console
- The Tricks That Make It Seamless
Building the City
- From Grid to Skyline
- How Tall Is a Day?
- Lights On
- Green or Blue?
It Updates Itself Every Day
- A Robot on Daily Duty
- Talking to GitHub: One Query Instead of Twenty
- The All-Time Problem
- Talking to DEV
- When an API Has a Bad Day
- The README Edits Itself (Carefully)
- Secrets That Stay Secret
- Why 12:17?
Was It Worth It?
- The Damage Report
- So... Was It?
- Come Visit

I Wanted a Simple Custom GitHub Profile. But Things Got Out of Hand Quickly

23:00. Fully Cooked.

It was 23:00. I'd just got home after an extremely exhausting day, dropped into the chair in front of my laptop, and... just stared at the screen. No plan. No thoughts. Nothing... Blank.

I'm sure you know the feeling. The day cooks you so hard that your brain switches to screensaver mode, random thoughts start floating in and out on their own, like those bouncing DVD logos that never quite hit the corner.

Random Doesn't Mean Bad

Here's the funny part: that's exactly when my best ideas tend to show up. When the brain stops trying, it starts shuffling. And random doesn't always mean bad.

That night, somewhere between "I should go to sleep" and "I should really go to sleep," one of those floating thoughts really caught my attention. And, my goodness, it was so good that I got my energy back. Instantly. Like someone had plugged me straight into a wall socket.

"Are you kidding me? This is so cool! I'm building it right now. I don't care how tired I am."

That's what I told myself. Out loud. At 23:00... send help please.

Why Do I Keep Doing This to Myself?

Seriously, why? I'd been awake for about 16 hours by then, and my brain had been running the whole time like an engine in a 24-hour endurance race at Daytona or the Nürburgring. By the way, I love those race tracks.

Any reasonable person would have closed the laptop.

I clicked the VS Code icon instead, cracked my knuckles and got to work. Time to cook!🔥

The Contribution City

The City That Represents Me

I'd always wanted my contribution graph to be something more than a grid of green squares. Something original. The problem was that I never had a good enough idea.

And no, I didn't want to turn it into another Pac-Man, Snake or Tetris game. Don't get me wrong, those are creative and fun, I love them and I've seen many great implementations. But by now they're everywhere, overused.

I wanted something different. Something that actually says something about ME.

I love Cyberpunk 2077 and its atmosphere. Well, except maybe its launch day, when the cars were spawning inside each other and NPCs were T-posing out of nowhere in the middle of the street, but everything after that? Absolutely.

I love big cities with huge skyscrapers. I love being close to where things happen, where you can feel the pace and the pressure to keep up. I've never been an "I can't wait to retire and start a farm" kind of guy anyway.

Oh, and I love neon lights. A lot.

The Moment It Clicked

So there I was, sitting motionless and emotionless in front of the screen, when the picture just appeared in my head: my contribution graph, lifted into 3D. Every day a building. Quiet days as empty lots, busy days as skyscrapers. A whole city.

That was it. The contribution city was on its way.

The Cyberpunk Console

Because Why Not?

Then I thought: a city like that can't just sit there on a plain white README, next to a list of badges. It needs a proper home.

So I decided to go further and turn the whole profile into a cyberpunk console: neon glow, scanlines, a terminal that types out my name, and a frame that holds everything together.

Because why not?

Welcome to the Sandbox

No JavaScript. No CSS. No Fun?

First reality check: GitHub doesn't let you run anything in a README. <script> gets stripped. <style> gets stripped. Even inline style="" attributes get stripped.

I wanted a cyberpunk console. GitHub gave me Markdown and a handful of HTML tags.

The Loophole: An SVG Is Just an Image

But here's the thing. To GitHub, an SVG embedded with <img> is just an image. And inside an SVG, you're allowed to use CSS, including animations:

<svg xmlns="http://www.w3.org/2000/svg" width="300" height="60">
  <style>
    @keyframes blink { 50% { opacity: 0 } }
    .cursor { animation: blink 1s step-end infinite }
  </style>
  <text x="10" y="38" fill="#3fb950">$ whoami</text>
  <rect class="cursor" x="110" y="24" width="10" height="18" fill="#00d9ff"/>
</svg>

<img src="./assets/header.svg" width="100%">

That's the whole trick behind the typing animation, the glitching name and the blinking cursor. Every "UI" element on my profile is secretly a picture.

Okay, But the Sandbox Has Rules

Images get loaded in a locked-down mode, and that comes with a few catches:

No external resources. Not even Google Fonts. So the font is embedded inside every SVG, trimmed down to only the characters that image actually shows.
No hover, no clicks. An image is an image. Links only work on a whole image, which is why every project card and every link button is its own file.
Caching. GitHub caches images for a few minutes. I fixed a bug, refreshed, saw the bug. Fixed it again, refreshed, still the bug. Turns out I'd fixed it the first time.

One Console, 23 Images

The Problem: Images Don't Hold Hands

My first version had every section as its own neat little panel: a box for the header, a box for the about text, a box for the stats. Each one looked great on its own.

Together, they looked like a terminal that had been dropped on the floor. Separate pieces, with gaps between them.

I wanted one console. One continuous window you scroll through from top to bottom.

Slicing the Console

The fix: draw one big frame and cut it into horizontal slices.

Only the header draws the top edge and the title bar.
Only the footer draws the bottom edge.
Every slice in between draws just the two side rails, left and right.

Stack them on top of each other and the rails line up into one long window:

<p align="center">
<img src="./assets/header.svg" width="100%" align="top">
<img src="./assets/stats.svg" width="100%" align="top">
<img src="./assets/contribution-city.svg" width="100%" align="top">
<!-- ...more slices... -->
<img src="./assets/footer.svg" width="100%" align="top">
</p>

Project cards and link buttons are slices too, just narrower: half-width and fifth-width images that only draw the rail on their outer side. Count everything up and you get 23 images pretending to be one terminal.

The Tricks That Make It Seamless

Stacking images is easy. Making the seams invisible took a few tricks:

A 40 px grid. Every slice is a multiple of 40 pixels tall, so the faint background grid continues across the cuts instead of jumping.
Glow that overflows. The neon glow on the rails starts above each slice and ends below it, so it doesn't fade out at the edges like a broken fluorescent tube.
align="top". Browsers leave a small gap under images by default, the space reserved for letters like g and y that hang below the line. Aligning to the top removes it.

Building the City

From Grid to Skyline

The city isn't a new idea, it's the same contribution graph you already know. 53 columns of weeks, 7 rows of days. I just tilted it into an isometric view and gave every square some height.

Each building is only three shapes: a roof and two walls. The trick is the drawing order. Buildings are painted from back to front, so the ones closer to you naturally cover the ones behind them. No 3D engine needed, just the painter's algorithm and a sorted list.

How Tall Is a Day?

I know, what a weird question, right?

My first instinct was simple: height = number of contributions. That gave me one giant tower for my busiest day and a sea of flat slabs for everything else. Not a city. More like a huge parking lot with the Empire State Building right in the middle of it.

So the height uses a square root instead:

h = 8 + 110 \cdot \frac{c}{c _{m a x}}

In Python, that's:

height = 8 + 110 * math.sqrt(count / busiest_day)

It lifts the small days while keeping the busy days clearly on top:

Contributions	Linear	Square root
1	11 px	25 px
10	34 px	61 px
43 (my record)	118 px	118 px

Days with zero contributions don't get a building at all. They stay as empty lots. Some months of my city look like an abandoned district. And you know what? That's accurate.

Here's how the city compares to my actual GitHub activity graph:

The contribution city:

The default GitHub contribution graph:

Lights On

A skyline at night needs lights, so every building gets windows: some lit, some dark, and a few that flicker. Add twinkling stars, a moon, and a plane with blinking lights crossing the sky, and the city starts to feel alive.

The windows are placed randomly, but with a seeded random generator. Same data, same seed, same city, down to the last window. Why does that matter? Because otherwise the image would change every single day even with no new contributions, and my repo would get a pointless commit every morning.

Green or Blue?

GitHub's contribution graph is green, so my first city had green roofs. People instantly read it as "activity," and that's a big plus.

But the rest of my profile is neon blue. Next to everything else, the green city looked like it was pasted in from another website. So I rendered both versions side by side, looked at them for about three seconds, and blue won. I love the color blue.

Here are both variants. Which one do you like more?

It Updates Itself Every Day

A Robot on Daily Duty

A profile with stats that never change is just a screenshot with extra steps. So the whole thing runs on a schedule, on GitHub's servers, whether my laptop is on or not.

The pipeline is four steps, three of them small Python scripts:

fetch.py   → asks GitHub and DEV for fresh numbers, saves them as JSON
render.py  → reads the JSON, redraws every SVG
readme.py  → updates the parts of README.md that change
git commit → only if something actually changed

And the workflow that glues it together:

name: Update profile

on:
  schedule:
    - cron: "17 12 * * *"
      timezone: "America/New_York"
  workflow_dispatch:          # a "Run workflow" button for impatient people (me)

permissions:
  contents: write             # needed to push the refreshed files

jobs:
  update:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-python@v6
        with:
          python-version: "3.12"
      - run: pip install fonttools==4.62.1 brotli==1.2.0
      - run: python tools/profile/fetch.py
        env:
          PROFILE_TOKEN: ${{ secrets.PROFILE_TOKEN }}
          GITHUB_TOKEN: ${{ github.token }}
          DEV_API_KEY: ${{ secrets.DEV_API_KEY }}
      - run: python tools/profile/render.py
      - run: python tools/profile/readme.py
      - run: |
          git config user.name "github-actions[bot]"
          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
          git add tools/profile/data assets README.md
          git diff --cached --quiet || (git commit -m "Refresh profile stats" && git push)

That last line is the polite part: git diff --cached --quiet exits successfully when nothing changed, so the commit only happens when there's something new. No empty "update" commits polluting the history.

Talking to GitHub: One Query Instead of Twenty

GitHub has two APIs. The REST one would need a separate request for followers, pull requests, every repository, every repository's languages... I'd be paginating until next Tuesday.

The GraphQL API lets me ask for exactly what I need in one request:

query($login: String!) {
  user(login: $login) {
    createdAt
    followers { totalCount }
    pullRequests { totalCount }
    merged: pullRequests(states: MERGED) { totalCount }
    contributionsCollection { contributionYears }
    repositories(ownerAffiliations: OWNER, isFork: false, privacy: PUBLIC, first: 100) {
      nodes {
        name
        stargazerCount
        forkCount
        languages(first: 20) { edges { size node { name } } }
      }
    }
  }
}

From that single response I get the followers, PRs, member-since date, total stars and forks (summed across repos), per-project star counts for the cards, and the language bar (bytes of code per language, summed up).

Sending it is plain Python, no SDK needed:

def graphql(token, query, variables=None):
    res = http_json("https://api.github.com/graphql",
                    headers={"Authorization": f"bearer {token}"},
                    body={"query": query, "variables": variables or {}})
    if res.get("errors"):
        raise RuntimeError("GraphQL error: " + "; ".join(e["message"] for e in res["errors"]))
    return res["data"]

The All-Time Problem

Here's a GitHub quirk: contributionsCollection covers at most one year per request. Ask for more and it politely refuses.

So how do you get all-time contributions and a streak that doesn't break on January 1st? The first query returns contributionYears, the list of years I've been active. Then I build a second query on the fly, with one aliased field per year:

def years_query(years):
    parts = []
    for y in years:
        parts.append(f"""
    y{y}: contributionsCollection(from: "{y}-01-01T00:00:00Z", to: "{y}-12-31T23:59:59Z") {{
      totalCommitContributions
      contributionCalendar {{ totalContributions weeks {{ contributionDays {{ date contributionCount }} }} }}
    }}""")
    return "query($login: String!) {\n  user(login: $login) {" + "".join(parts) + "\n  }\n}"

y2016, y2017, ..., y2026: a decade of calendars in a single round trip. GraphQL aliases are criminally underrated.

That gives me every single day since 2016 as {date: count}. From there:

Contributions this year and all time are sums of totalContributions.
The city gets the last 53 weeks, starting on a Sunday, exactly like GitHub's own graph.
The streaks are a simple walk through the days:

def streaks(days, today):
    longest = run = 0
    for d in sorted(d for d in days if d <= today):
        run = run + 1 if days[d] > 0 else 0
        longest = max(longest, run)

    current, d = 0, today
    if days.get(d, 0) == 0:          # no contributions yet today?
        d -= datetime.timedelta(days=1)   # then the streak can still end yesterday
    while days.get(d, 0) > 0:
        current += 1
        d -= datetime.timedelta(days=1)
    return current, longest

That little if matters more than it looks. The workflow runs at midday. Without it, my streak would reset to zero every day until I made my first commit of the day. Very motivating. But not in a good way.

Talking to DEV

The DEV numbers come from the Forem API. Articles, reactions and comments are public:

arts = dev_paged(f"https://dev.to/api/articles?username={USER}")
dev = {
    "articles":  len(arts),
    "reactions": sum(a["public_reactions_count"] for a in arts),
    "comments":  sum(a["comments_count"] for a in arts),
}

Views and followers are private, so they need an API key in the api-key header:

h = {"api-key": api_key, "Accept": "application/vnd.forem.api-v1+json"}
mine = dev_paged("https://dev.to/api/articles/me/published", h)
dev["views"] = sum(a["page_views_count"] for a in mine)
dev["followers"] = len(dev_paged("https://dev.to/api/followers/users", h))

dev_paged just keeps requesting page=1, 2, 3... until it gets an empty list back. The same response also gives me my five newest articles for the writing section.

When an API Has a Bad Day

APIs fail. Rate limits, timeouts, a random 502 at the worst possible moment. And a profile that suddenly shows "0 stars, 0 contributions" because GitHub hiccupped once is worse than no stats at all.

So fetch.py never starts from scratch. It loads yesterday's JSON first and only overwrites what it successfully fetched:

stats = load("stats.json", {})          # yesterday's numbers

try:
    stats.update(fetch_github(token, today))
except Exception as ex:
    warn(f"GitHub fetch failed, keeping previous stats: {ex}")

try:
    dev, latest = fetch_dev(api_key)
    ...
except Exception as ex:
    warn(f"DEV fetch failed, keeping previous values: {ex}")

If GitHub is down, the DEV numbers still update, and vice versa. If both fail, the script exits with an error and touches nothing. Worst case, my profile is one day old. It never goes blank.

Bonus: the JSON files are committed together with the images, so git log -p tools/profile/data/stats.json is a free history of my stats. I didn't plan that. I'll take it.

The README Edits Itself (Carefully)

Most of the README never changes. But the article links do, and so do the alt texts that describe the stats for screen readers. Rewriting the whole file from a template would wipe out anything I edit by hand, so readme.py only touches clearly marked zones:

<!-- writing:start -->
<a href="https://dev.to/..."><img src="./assets/writing/post-1.svg" ...></a>
...
<!-- writing:end -->

s, n = re.subn(r"<!-- writing:start -->.*?<!-- writing:end -->",
               lambda _: writing_block(articles), s, flags=re.S)
if n != 1:
    sys.exit("error: README needs exactly one writing block")

HTML comments are invisible on GitHub, so the markers cost nothing. And if someone (me) accidentally deletes one, the script fails loudly instead of quietly mangling the README.

Secrets That Stay Secret

The workflow needs two secrets: a GitHub token, so private contributions get counted, and the DEV API key. Neither is ever written in the repo. The workflow only references them by name:

PROFILE_TOKEN: ${{ secrets.PROFILE_TOKEN }}

The values live in Settings → Secrets and variables → Actions, encrypted. GitHub injects them at runtime and masks them as *** if they ever show up in the logs.

For the token I used a fine-grained personal access token instead of a classic one, because it can be read-only: Metadata and Contents, nothing else. If it ever leaked, the worst someone could do is read my code. Not push to it.

And both are optional. Without them, the workflow falls back to the built-in GITHUB_TOKEN and public data only.

Why 12:17?

:17 instead of :00, because everyone schedules their jobs on the full hour, and GitHub's runners get flooded at :00. Scheduled runs at the top of the hour often start late. A random-looking minute dodges the rush.

Was It Worth It?

The Damage Report

Let's count what my "simple custom profile" turned into:

23 SVG images pretending to be one terminal
a contribution city with one building for every day of the past year
three Python scripts and a GitHub Actions workflow
two APIs, two secrets and one very hardworking robot.

All of that, so a page most people will look at for about eight seconds says my name in neon.

So... Was It?

Absolutely.

It wasn't really about the profile. It was about that 23:00 feeling, when a random idea shows up and suddenly you're not tired anymore. The kind of project nobody asked for, with no deadline and no stakeholders, built just because it's fun.

And somewhere along the way I learned a bunch of things I'd never have touched otherwise: SVG animations, isometric drawing, font subsetting, GraphQL aliases, and how many layers of caching sit between "I fixed it" and "I can see that I fixed it."

Plus, the profile now maintains itself. Every day at 12:17 New York time, a robot wakes up, checks what I've been doing, and adds a new building to my city. Even on the days I don't feel like I'm building anything.

Visit the Profile

The city is live at:

georgekobaidze (Giorgi Kobaidze) · GitHub

Software Engineer | Engineering Manager | Technical Writer |🏆2x Hackathon Winner | ☕Enjoyer - georgekobaidze

github.com

And all the code behind it is in the same repo, under tools/profile. Feel free to look around, fork it, and build your own skyline. Just change the username first, unless you want my stats on your profile.

And if you build something cool with it, show me in the comments. I'd love to see what your city looks like.

Now if you'll excuse me, I have some quiet days to fill. My city has a few empty lots that need skyscrapers.

$ exit
connection to georgekobaidze closed. // EOF

Enjoyed this write-up? Let's stay connected!

I share more software engineering insights, projects, and experiments across these platforms:

Vim's Swan Song: Is It Time to :q!?

Giorgi Kobaidze — Fri, 25 Sep 2026 19:01:14 +0000

Hotel California
Hands Off the Mouse
Vim Was Never About Typing Speed
The Case for :q!
Plot Twist: The Terminal Strikes Back
The Last 10% Is Where Vim Lives
The Editor Might Leave, The Motions Won't
So... :q! or :w?

Hotel California

There's an old joke that the hardest part of learning Vim is figuring out how to leave it. The Stack Overflow question about exiting Vim is one of the most viewed questions on the site, and the answer has become a meme: :q!.

Hands Off the Mouse

For decades, Vim's pitch has been simple: keep your hands on the keyboard and do everything faster. No mouse, no menus, no reaching for arrow keys. Just you, the home row, and a text editor that feels like an extension of your fingers.

I've never been a Vim power user. But I've always been a big believer in treating the keyboard as an extension of your hands. Reaching for the mouse only takes a fraction of a second, but when you're deep in focus, that tiny interruption is enough to break your train of thought. So while I'm not a Vim enthusiast, I still think keyboard shortcuts are essential. Not for speed, but for focus.

Then AI showed up and started writing our code. So, the question is, do we still need Vim? Or maybe it's time to type :q! and walk away for good?

The answer is much more nuanced than a yes or no.

Vim Was Never About Typing Speed

Here's the thing most people get wrong about Vim: it was never really about typing speed. You can type just as fast in Notepad.

Alright, 🔥Hot take🔥, folks: does fast typing make you a better programmer?

My take? Absolutely not! Come on! Look, the typing is the easiest part of our job. The hard part is figuring out what to type, and no amount of words per minute is going to help you there. Average speed? You're golden. Trust me.

Vim's real superpower is that it gives you a language for editing. Instead of pressing keys to move a cursor around and delete characters one by one, you describe what you want to happen:

ci" means change inside quotes
dap means delete a paragraph
. means do that again

You're not pushing characters around, you're expressing intent, and the editor carries it out.

That matters because even before AI, most of our time wasn't spent writing new code. It was spent reading, navigating, and changing code that already existed. Keep that in mind, because it's about to become very important.

The Case for :q!

Let's be fair and give the "Vim is done" side its best shot, because it makes some good points.

The Learning Curve is Harder to Justify

Learning Vim means weeks of feeling slower than before. That investment made sense when you spent eight hours a day writing code by hand. If AI writes most of it now, the payoff shrinks.

AI-First Tools Aren't Built for Modes

The modern AI workflow revolves around chat panels, inline suggestions, diff views, and an "Accept" button. When your main interaction is describing what you want in plain English, switching between normal and insert mode can feel like friction rather than power.

The Next Generation May Never Need It

Developers starting out today might never write enough code by hand to build the muscle memory Vim demands. If your fingers spend the day writing prompts instead of for-loops, hjkl starts to look like a hobby.

These are pretty solid arguments. But they miss a plot twist.

Plot Twist: The Terminal Strikes Back

Here's the irony nobody predicted: the AI era sent developers back to the terminal.

Some of the most capable AI coding tools today, like Claude Code and GitHub Copilot CLI, live right there in the command line. When I built Metal Birds Watch for the GitHub Copilot CLI challenge, a big part of my back-and-forth with the AI happened in a terminal window, not a fancy IDE.

And the terminal was never really gone for developers anyway. SSH into a server, open a shell in a container, fix a config file in production at 2 AM, and there's a good chance Vim (or its ancestor, vi) is the only editor waiting for you, judging your skills.

So while AI was supposed to pull us further from the keyboard-driven world, it actually made the terminal feel modern again. And Vim has always been the terminal's native tongue.

Gosh... our industry is basically the Daytona 500: we just keep going in circles. The question is, are you Richard Petty, or the guy he just lapped... twice.

The Last 10% Is Where Vim Lives

This is the part that changes everything.

AI is fantastic at getting you 90% of the way there. But anyone who has shipped AI-generated code knows what the last 10% looks like: rename this variable, delete that redundant block, move this method up, fix the off-by-one error, swap these two arguments.

Those aren't typing tasks. They're editing tasks, small, precise, surgical changes in code you didn't write yourself.

Your job is quietly shifting from writing code to reviewing and shaping code. You read a diff, jump to the suspicious part, search for where something is used, change one thing, and move on. That's navigation and editing, which is exactly what Vim was designed for all along.

AI took the typing. It left the editing. And editing was always Vim's real job.

The Editor Might Leave, The Motions Won't

There's an important distinction here: Vim the program and Vim the way of editing are two different things.

Vim the program may well stay a niche choice. Plenty of developers will happily live in AI-first editors with chat panels and never open a raw terminal editor.

But Vim's motions have escaped the editor. They're in VS Code through an extension, in Rider and every other JetBrains IDE through IdeaVim, in Neovim with its huge modern ecosystem and even in your browser through extensions like Vimium. You can use the shiniest AI-powered editor available and still edit like a Vim user.

So... :q! or :w?

Is this Vim's swan song? I don't think so. I think we have to keep it as an option. Can't say it's absolutely essential, but it never was to be fair.

Vim the editor is optional, as it always has been. But Vim as a way of editing becomes more valuable, not less, when your job shifts from writing code to shaping it. The less you type, the more every edit counts.

If you already know Vim, keep it. Hold onto it. If you're new, don't learn it to type faster, AI has that covered. Learn the motions to edit faster, because that's the part of the job that isn't going anywhere.

So maybe it's not time for :q!. Maybe it's just time for :w save what works and keep going.

What about you? Still using Vim or Vim motions, or has AI made you drop them? Let's discuss.

Enjoyed this write-up? Let's stay connected!

I share more software engineering insights, projects, and experiments across these platforms:

Double Engine Failure: Back to the Hangar After Two Data Providers Changed Course

Giorgi Kobaidze — Thu, 24 Sep 2026 18:00:16 +0000

Two providers changed the rules, and my app went back to the hangar

Showtime on the Balcony (Gone Wrong)

"I like planes too. I wish I had an app that showed me the planes nearby and their details. That'd be so cool."

One of my buddy's buddy's buddies said this at a party, while we were out on the balcony getting some fresh air. Well, I was getting fresh air. He was smoking the whole time.

That was my moment to shine. He was describing, almost word for word, the app I'd won my first hackathon with. So I thought to myself: "It's showtime!"

"I have just the thing for ya"

I said with a slight smirk, pulled out my phone, typed metalbirdswatch.pilotronica.com into the browser... only to get this:

My smirk turned into a "what the hell is this bull shirt" face in about half a second. Obviously I wasn't going to show anyone my app in that state.

"Well... umm... yeah... some kind of problem, probably browser-related. I'll show you later."

It wasn't browser-related.

I knew that for sure. I figured CARTO, the service that draws my map, had changed something in their API or made it paid. Either way it'd be a quick fix, and that'd be it. Easy.

"I'll fix it tomorrow and send you the link so you can check it out"

I said.

Little did I know I was about to find out that the planes were gone too. Metal Birds Watch without the metal birds? Doesn't sound great, does it?

A Quick Layover

But let's not get ahead of ourselves. What's the point of explaining anything without proper storytelling? Storytelling on a technical write-up is like a good ragù on tagliatelle. Sure, you can eat the tagliatelle plain, but the sauce makes it so much better.

Otherwise I'd just drop a link to the release notes and call it a day. Easy, simple. But let's not do that.

Why This One Is Personal

By the way, this is me proudly holding a Boeing 737-800 model while recording the project video.

...and yes, the plane was more camera-friendly than I was.

I built Metal Birds Watch for the GitHub Copilot CLI Challenge on DEV. It was the first hackathon of my life, and I started it on hard mode: the competition was brutal, with over 400 participants.

But I won.

While building it I had every obstacle in the world, including back, neck and arm pain from shoveling my driveway for hours non-stop. (Pro tip: don't shovel an entire driveway in one go right before a hackathon.)

I could barely sit up straight while writing the whole thing. My back was killing me.

So yeah, as you can imagine, this app is pretty special to me. It's my baby.

Engine #1: The Map That Said No

The morning after the party. I poured a cup of dark coffee, sat down at my desk, put on some music (RHCP, as usual), and got to work. Time to fix this thing.

the first job was to figure out why on earth the map looked like that.

It turned out CARTO had changed its policy around 28 August 2026. Their free basemaps now require an API key, and requests without one get tiles with "API KEY REQUIRED" stamped diagonally across them.

I didn't have a CARTO account, so they had no email address to warn me, and I'm sure plenty of other users were in the same position. Their best way to tell us was to cover our maps with the message. Fair enough.

A Quick Patch on the Tarmac

This was the easy part. I requested a free key, which allows 5 million tile requests per month, and added it to the tile URL. My map URLs live in CSS custom properties, one per theme:

/* variables.css, before */
--map-tiles: 'https://{s}.basemaps.cartocdn.com/dark_all/{z}/{x}/{y}.png';

/* after */
--map-tiles: 'https://{s}.basemaps.cartocdn.com/dark_all/{z}/{x}/{y}.png?key=YOUR_KEY';

That was the whole change: not a single line of JavaScript. The map reads its tile URL from CSS on startup and again on every theme switch, so both picked up the key automatically:

const tileUrl = getComputedStyle(document.documentElement)
  .getPropertyValue('--map-tiles')
  .trim()
  .replace(/['"]/g, '');

tileLayer = L.tileLayer(tileUrl, { /* ... */ }).addTo(map);

Past me, thank you for that architecture decision.

Pre-Flight Checklist

There were a few details to think through, though.

1. Should the key be committed to a public repo? My first instinct was "never commit keys." But a map tile key can't be secret: the browser sends it with every tile request, and anyone can see it in DevTools. What protects it is a domain restriction set in CARTO's dashboard, so the key only works on my production domain. Committing it was fine.

2. A CSP trap. CARTO's current docs show the apex domain, basemaps.cartocdn.com. My Content Security Policy only allows https://*.basemaps.cartocdn.com, and that wildcard doesn't match the apex domain. If I'd copied the URL from the docs, the tiles would have been silently blocked by my own CSP. Keeping the {s}. subdomain form avoided a second outage in the same fix.

3. The domain restriction backfired locally. Because the key only works on production, every tile on localhost returned 403, and my local map went completely grey. I later added a small helper that swaps the key on localhost for a personal development key stored in the browser, or removes it entirely:

function getTileUrl() {
  const url = getComputedStyle(document.documentElement)
    .getPropertyValue('--map-tiles').trim().replace(/['"]/g, '');

  if (!isLocalhost) return url; // production: unchanged

  const devKey = localStorage.getItem('carto-dev-key');
  return devKey
    ? url.replace(/key=[^&]+/, `key=${devKey}`) // your own dev key
    : url.replace(/[?&]key=[^&]+/, '');         // no key: watermark, but it works
}

My development key lives in my browser, not in a file, so it can never be committed by accident.

I added the key, tested it, and everything was back to normal. I was so happy to see my favorite app, my baby, running smoothly again.

Time to deploy.

Engine #2: Where Did All the Birds Go?

I ran the pipeline, and it deployed. Alright, let me check production.

OK, whoa whoa whoa whoa. What do you mean, Failed to fetch plane data: API error: 503 Service Unavailable?

The map was clean, and it was also completely empty. No planes. The status indicator said OFFLINE, and an error toast showed up every 20 seconds or so like clockwork: the frontend asked for planes, waited about 10 seconds, got a 503, then tried again.

The Instrument That Lied

The backend logs were very clear about the problem:

Authentication failed - check OpenSky credentials

Makes sense. My flight data comes from OpenSky Network, and the backend authenticates with OAuth client credentials before fetching aircraft. Maybe the credentials had expired, or been revoked.

So I rotated them. It didn't help.

So I rotated them again. It didn't help either.

Two credential rotations and several hours later, I finally looked closely at the code that produced the message:

tokenRefreshPromise = (async () => {
  try {
    return await getAccessToken();
  } catch (error) {
    console.error('Failed to get OAuth token:', error.message);
    throw new Error('Authentication failed - check OpenSky credentials');
  }
  // ...
})();

Can you see it? Every failure became "Authentication failed": network timeouts, DNS errors, HTTP errors, and genuine credential problems. The code swallowed the real error and replaced it with a confident, specific and completely wrong diagnosis.

The error message had been lying to me all along, and I'd written it myself. That hurt.

Opening Up the Engine

Enough guessing. If the error message wasn't going to tell me the truth, I'd make the error tell me itself.

Step 1: log everything. Instead of trusting my own summary, I logged every detail of the raw error: its code, syscall, address, port, and most importantly its cause. That's how you tell a DNS failure from a TCP failure, a TLS failure or an actual HTTP error:

console.error('OpenSky auth error details:', {
  name: error.name,
  code: error.code,
  cause: error.cause && {
    name: error.cause.name,
    code: error.cause.code,
    message: error.cause.message
  }
});

I deployed, waited, and the logs finally told the truth. It wasn't an authentication failure at all. It was a TCP connect timeout to OpenSky's auth server. My backend never got as far as sending the credentials I'd rotated twice, because it couldn't even open a connection.

Step 2: be patient. A timeout? Maybe OpenSky's server was just slow to respond from Railway's network. So I increased the auth request timeout to 30 seconds:

signal: AbortSignal.timeout(30000)

I deployed, waited, and got exactly the same error, still after 10 seconds.

Wait, what? I'd just set it to 30.

Step 3: find out where the 10 seconds came from. Node's fetch is built on undici, and undici has its own separate 10-second limit for opening a TCP connection. That limit applies before any request timeout you set yourself. So my 30-second timeout never got a chance to run; undici gave up first.

To change it, you pass fetch a custom undici Agent:

const { Agent } = require('undici');

const authDispatcher = new Agent({
  connect: { timeout: 30000 } // give the TCP handshake 30s instead of 10s
});

await fetch(OPENSKY_AUTH_URL, {
  // ...
  dispatcher: authDispatcher,
  signal: AbortSignal.timeout(30000)
});

My theory was that the TCP handshake from Railway to OpenSky was just slow and would get there eventually if I gave it enough time.

I deployed, waited, and waited some more.

Reader, it did not get there eventually. I gave it 30 seconds. I could have given it 30 minutes. A connection that isn't slow but ignored will never complete, however long you wait.

Silence on the Frequency

This was the turning point, so it's worth a short technical detour.

When you try to connect to a server, there are roughly two ways it can go wrong:

Connection refused: the server's machine answers and says "nobody's listening on that port". It's fast and polite.
Connection timeout: nothing answers at all. Your packets leave, and nothing comes back.

A timeout on a server that's otherwise up and working for everyone else usually means one thing: something is dropping your packets on purpose, typically a firewall. And the only unusual thing about my backend's packets was where they came from: a cloud provider's IP range.

Tower, Do You Copy?

So I asked OpenSky directly:

Do you block hosting and cloud provider IP ranges?
"Yes."

Can a specific address be allowlisted?
"No."

What's the recommended approach for hosted apps?
They're considering a paid option to handle the requests coming from cloud providers.

So that was that. The blocking is deliberate, exceptions aren't possible, and a paid option might come someday. There's currently no supported way to use OpenSky from a hosted backend.

That's a bummer. Real bummer. I really liked OpenSky's service.

To be fair to OpenSky, I get it. They run a free, community-driven service, and they're being flooded by automated traffic from cloud servers.

Back to the Hangar

So it was time to land the plane. I fixed one engine mid-air, but I couldn't do it for the second one. So I had to land and go back into the hangar.

Adding an API key is easy, especially a public one. Researching and integrating a new flight data provider is not something you do in a few minutes, or even a few hours.

So I put the app into maintenance mode. It'll take a while to find the right provider, but hey, great things take time.

Ten Seconds of Doubt

That was my first idea, and it's a trap. The backend takes about 10 seconds to return that 503. A banner that appears after the failed request leaves users staring at an empty map for 10 seconds first. That's exactly when they decide the app is broken, or that there just aren't any planes overhead.

So the maintenance page is unconditional. It appears immediately and doesn't wait for anything to fail. One flag controls it:

MAINTENANCE: {
  ACTIVE: true,                  // Set to false once the new data provider is live
  ID: 'opensky-2026-09',
  SINCE: '2026-09-20',           // Used for the "day N" counter
  ISSUE_URL: 'https://github.com/georgekobaidze/metal-birds-watch/issues/98'
}

When it's on, the map doesn't load, the browser doesn't ask for your location, and polling never starts:

function startPolling() {
  // Skip polling during maintenance - the backend can't reach the data provider,
  // so every request would time out and show an error toast
  if (CONFIG.MAINTENANCE.ACTIVE) {
    return;
  }
  // ...
}

No more doomed requests, no more error toasts every 20 seconds, and no more "is it me?"

Speaking Fluent Aviation

Since this is an aviation app, the maintenance page talks like one:

A NOTAM-style notice. A NOTAM ("Notice to Air Missions") is how pilots are told about closures and outages. The notice sits over a full-screen photo of a plane being repaired in a hangar.
A radio call: "All stations, all stations: Metal Birds Watch is out of service for unscheduled maintenance until further notice."
A counter: "Grounded since 20 Sep 2026 · day N", updated automatically.
Ask the Tower: a small panel that answers the questions people actually have, such as Is it something on my end? ("Negative."), Is my logbook safe? ("Affirmative. It lives in your own browser.") and When will it be fixed?

There's no AI in the Tower, which felt right given the circumstances. It's a list of pre-written questions and answers with a typing indicator for effect:

logbook: {
  question: 'Is my logbook safe?',
  answer: 'Affirmative. Your logbook lives in your own browser, not on our servers, so the ' +
    'outage can\'t touch it. Open it anytime with the 📖 button up top.',
  followUps: ['stillWorks']
}

Looking for a New Engine

Replacing the data provider is tracked in issue #98.

The good news is that my OpenSky code is already an isolated adapter. It converts OpenSky's response into my own data format, and nothing above it knows where the data comes from. A new provider is one new service file behind the same interface. The routes, the cache and the entire frontend stay the same.

Reading the Black Box

If I had to summarize the flight recorder:

Silent failures are the worst failures. An HTTP 200 containing a watermark and a 503 nobody was watching both went unnoticed for about three weeks. I found out at a party, from a phone, while trying to show off. Some basic monitoring would have found them for me.
Your error messages are part of your debugging tools. A misleading one costs hours. Mine cost two credential rotations and an afternoon.
A timeout and a refusal tell you different things. A refusal means nobody is listening. A timeout, when the server works for everyone else, usually means someone chose not to answer you.
Free services can change their rules at any time. That's not a complaint. They don't owe anyone anything. But design for it: isolate your providers behind adapters, and have a plan for the day one disappears.
When you can't fix it right away, say so clearly and immediately. An honest maintenance page is better than an empty map that makes people think the app is broken.

Final Approach

As for my buddy's buddy's buddy: I still owe him that link. It's coming, I promise, with planes on it.

Until then, Metal Birds Watch is in the hangar, the mechanics are at work, and the new engine is on order.

We promise we'll be flying again together soon. 🛫

Follow the progress in issue #98, or read the v1.0.2 release notes.

Enjoyed this write-up? Let's stay connected!

I share more software engineering insights, projects, and experiments across these platforms:

Real Talk: You Don't Miss Engineering. You Miss Typing

Giorgi Kobaidze — Mon, 21 Sep 2026 20:36:39 +0000

A Sci-Fi Scenario Come True

As a kid, when I watched sci-fi movies about computers with human-like thinking, I was completely sure they'd never exist. That was in the early 2000s. Now we live alongside them. Engineering isn't ending. It's starting.

Nostalgia Isn't an Argument

Lately I keep seeing engineers declare that "real engineering is gone," that "they're done with this s...," that "it's all AI now," and that they miss typing every line themselves. I understand the feeling, but I think it confuses nostalgia with how engineering and science work in general.

The Most Dynamic Era to Be an Engineer

I feel bad for engineers who can't see that this is one of the best times, if not the best time, to be an engineer. Look around: things change almost overnight. For most of human history, life changed slowly, with generations living in roughly the same world as their parents, grandparents, or great-grandparents. We're living through one of the most dynamic eras ever.

Sure, I still have a soft spot for '80s vibes, even though I wasn't even born yet. But there's no need to invent a problem and suffer over it when there are so many things to catch up with.

Just ask yourself how many things you don't know that you want to know.

We've Been Here Before

Tech and science don't give a damn about the good ol' days. It's always been like this.

When Grace Hopper built early compilers, skeptics doubted "automatic programming" was serious work. When FORTRAN arrived, programmers doubted compiled code could match hand-written assembly.

High-level languages, frameworks, and package managers all triggered the same fear, and each time the industry grew. AI is the next rung on the same ladder.

The Hard Part Was Never the Typing

Never. You spend exponentially more time thinking about the problem than typing the code that expresses your thoughts.

The real program is the understanding in the engineers' heads, not the source code. AI can generate thousands of lines, but someone still has to hold the theory of why the system works the way it does.

The Bottleneck Moves

Speeding up one step only helps as much as that step mattered. Make code generation instant, and the constraints shift to requirements, design, review, and debugging. Generating code is getting cheap; verifying it is not. That judgment is engineering.

Cheaper Software Means More Software

Every time software got cheaper to build, we built far more of it. Lower costs unlock problems that were never worth solving before.

Coding Was Never the Point

What matters is who does the engineering: you, the AI, or both of you together. My bet is on the engineers who choose both and keep the thinking for themselves.

So please, just stop dwelling on things that are inevitable and focus on the real problems, and the real opportunities will show up.

Just don't vibe code, please! That's not engineering and nobody can change my mind about that.

I hope this little note helps a bit.

Enjoyed this brief note? Let's stay connected!

I share more software engineering insights, projects, and experiments across these platforms:

Clean Code Is Not the Same as Clear Code: Comments Were Never the Problem

Giorgi Kobaidze — Mon, 21 Sep 2026 18:07:10 +0000

A Line That Does Nothing... Except Keep Production Alive
Some Code Can't Explain Itself
The Code Knows What. Only You Know Why
"Just Put It in the Commit Message"
So What's the Worst That Can Happen?
How Not to Write Comments
Clean Gets You Halfway

A Line That Does Nothing... Except Keep Production Alive

Somewhere along the way, our industry decided that writing a comment means you've failed as an engineer and need to "git good" (don't try that in the terminal, it's not a git command). If your code needs explaining, the logic goes, your code isn't good enough.

I won't lie, I really like the idea. I'd love every codebase to be so clean that you open a file, read it once, and think "yep, got it." Everything logical, everything obvious.

But...

I'd also love roads so well designed they don't need signs. But even the most beautifully engineered mountain road has a "sharp bend ahead" sign, and not because the engineers failed. It's there because you can't see the bend until you're already in it.

So here's the quick reality check: not every function can explain what it's doing. Not now, not tomorrow, not ever. There will always be code that:

Was never written with structure in mind, so nobody understands it.
Is written just beautifully, but solves a problem so complex that you still need five hours staring at one function to follow it.
Is simple, clean, and perfectly readable, yet does something for a reason that isn't visible anywhere in the code.

Some Code Can't Explain Itself

Here's a perfectly clean piece of C#:

public static partial class FlightNumbers
{
    [GeneratedRegex(@"^([A-Z]{2}|[A-Z]\d|\d[A-Z])(\d{1,4})([A-Z]?)$")]
    private static partial Regex FlightNumber();

    public static bool IsValid(string input) =>
        FlightNumber().IsMatch(input.Replace(" ", "").ToUpperInvariant());
}

Good names. Modern, source-generated regex. Nothing to refactor, nothing to rename.

Now, quick quiz. Which of these are valid?

FlightNumbers.IsValid("BA123");
FlightNumbers.IsValid("U21234");
FlightNumbers.IsValid("9W5A");
FlightNumbers.IsValid("99123");

Unless you're an aviation nerd like me, or someone who reads regex fluently (if you do, my goodness, more power to you), you have no idea what this method is actually checking.

Sure, you can look it up. Sure, you can read the documentation. And sure, there must be unit tests that describe exactly what's valid and what isn't. Right?!

Well, yes, on paper, however "on paper" and "actually" can be like the burger in the ad and the burger in the box.

Sometimes there's no documentation. Sometimes there are no unit tests. Sometimes there's just you, the regex, and a growing sense of dread.

But even when the docs and tests exist, why should you have to derail your train of thought, open three tabs, and go on a scavenger hunt, when a single comment could be sitting right there on top of the code, waiting for you?

Let me show you. Then tell me this isn't infinitely better:

// IATA flight number, e.g. "BA123", "U21234", "9W5A".
// Airline code is 2 chars: two letters, or a letter-digit mix (U2 = easyJet).
// Then a 1-4 digit flight number and an optional operational suffix letter.
// Uppercase only, no spaces: normalize input before matching.
[GeneratedRegex(@"^([A-Z]{2}|[A-Z]\d|\d[A-Z])(\d{1,4})([A-Z]?)$")]
private static partial Regex FlightNumber();

Plus, you also learn things the code could never tell you.

The Code Knows What. Only You Know Why

The regex was a translation problem: the code was correct, it just spoke a language most humans don't. But there's a second kind of comment, and it's arguably even more valuable, because it covers something the code can't express in any language.

private const int MaxConcurrentRequests = 47;

Clean. Named. A constant, not a magic number buried in a loop. Textbook.

And yet every developer who sees it has the same thought: why 47? It's not a round number. It's not a power of two. It looks like someone's lucky number, or a typo, or the result of a very long night. The provider's documentation says the limit is 50, so surely this is just a mistake.

So somebody changes it to 50. And a few weeks later, under real traffic, the provider starts rejecting requests at random, and nobody can reproduce it.

Here's what was missing:

// 47, not 50. The provider documents 50 requests per second, but their
// limiter measures bursts over a 1.2s window, so retries at 50 trip it.
// Recheck if they publish new limits.
private const int MaxConcurrentRequests = 47;

This is the part of the code that lives only in the head of whoever wrote it. The code records the decision. The comment records the reasoning. Lose the reasoning, and the decision looks like a bug.

So, in practice, a good comment does one of four jobs:

1. Translates

Dense code like a regex, a bit trick, or a math formula, where the what isn't obvious even when the code is perfect.

2. Explains

The reason behind a choice that looks wrong, arbitrary, or unnecessary.

3. Warns

What breaks if you change this, and how badly.

4. Records

A decision with an expiry date. What was tried, what didn't work, and when it's worth revisiting.

If a comment doesn't do one of those four jobs, it probably shouldn't exist. But if it does, deleting it for the sake of "clean code" isn't cleaning.

By the way, these are extremely simple examples, in practice, you'll come across much more complex scenarios.

"Just Put It in the Commit Message"

At this point, someone in the back raises their hand: the reasoning belongs in git history. Write a good commit message, keep the source clean. That's what version control is for.

Again, on paper, it sounds disciplined. But in practice, go run git log on any file that's older than a year. I'll wait.

...
a91f3c2  apply editorconfig
7d2e8b1  fix
3c4f9a0  fix again
e81b7d4  PR feedback
b02c6f5  final fix
f5a1e93  final fix (actually)
...

Somewhere in there is the reason MaxConcurrentRequests is 47. Good luck. Let me know when you find it.

And what if you don't? You're just going to sit and blame everything and everyone? Or just be pragmatic and write a short comment that'll solve problems for other developers and future you? Maybe if past you hadn't been so dogmatic you'd have been exponentially happier now? Have you thought about that?

And by the way even if your team writes beautiful commit messages, the approach still breaks down for a few boring, practical reasons.

Nobody runs `git blame` on code that looks fine

This is the big one. You don't go looking for a reason when you don't know there is one. A constant set to 47 looks like a typo, not like a mystery worth investigating. A comment interrupts you before you make the mistake. Git history only answers questions you already thought to ask.

Blame decays

One reformat, one rename, one file split, one squash merge, and the line now points to a commit titled "apply editorconfig." The original reason is still in there somewhere, buried under years of unrelated changes. Finding it is no longer a lookup. It's archaeology. Archaeology takes time and effort.

People leave

Sometimes the real documentation isn't the commit history at all. It's Bill. Bill knows why it's 47. Bill also left for a new company two years ago and won't pick up the phone, because he knows you're going to bother him with those questions.

Commit messages are great at explaining a change: what was different about this commit and why. They're terrible at explaining a current state, because the current state is the sum of dozens of changes, and nobody is going to reconstruct it by reading them in order.

The comment is the only place that describes the code as it is right now, right where you're looking at it.

So What's the Worst That Can Happen?

Let's flip the question. Say you write a comment. What's the worst-case scenario?

The most common argument I hear is this:

"if you change the code, you have to change the comment too."

And... so what?

Seriously. How hard is it? The comment is right there. Not in a wiki, not in a Confluence page nobody has opened since 2021, not in a separate repository. It's one line above the code you're already editing. If you can change 47 to 50, you can change the sentence directly on top of it. You're literally looking at it.

The argument assumes there's some rule that a change should touch only the code and leave everything around it untouched. There isn't. When you change a method's behavior, you update its tests. When you rename a parameter, you update its callers. Updating the comment that describes the thing you just changed is the same kind of work. It's not overhead. It's the job.

This is part of a bigger pattern: taking a good guideline and following it so strictly that it starts hurting the code it was supposed to help.

Take DRY. That's a topic for another episode of this series, but ask yourself honestly: does strictly following DRY always make your code better?

Nuh-uh.

Sometimes two pieces of code look similar, so someone extracts a shared function to avoid the "duplication." Then the two use cases drift apart a little, so the function grows a parameter. Then another. Then a couple of flags. And six months later you're reading this:

ProcessOrder(order, true, false, null, customer, true, 3, "legacy", false, skipValidation: true);

Congratulations, the code is DRY. The only downside is that nobody knows what it does. Not even future you, by the way.

Don't tell me you haven't seen, or better yet, written a function/method like this. I have, when I was junior/mid-level developer. And it made my life miserable.

Sometimes it's perfectly fine to repeat a few lines in two places, because keeping each piece readable on its own matters more than eliminating every repeated pattern. Duplication isn't automatically bad, and abstraction isn't automatically good. Everything is a tradeoff, and knowing which side to pick is exactly the kind of instinct that separates a good developer from someone following a checklist.

Comments work the same way. "Never write comments" and "comment everything" are both checklists. The right answer is to write the comment when it carries something the code can't, and to keep it updated the same way you keep everything else updated: because it's right there.

How Not to Write Comments

Now, before anyone runs off and starts commenting every line: none of this is permission to narrate your code. Bad comments are real, and they're a big part of why comments got a bad reputation in the first place. Here's the hall of shame.

The echo

// Increment the retry count
retryCount++;

The XML doc that says absolutely nothing

/// <summary>
/// Gets the user
/// </summary>
/// <param name="id">The id.</param>
/// <returns>The user</returns>
public User GetUser(int id)

Six lines of ceremony and zero information. Every .NET codebase has thousands of these, usually generated by a tool to make a warning go away. If you're going to write a doc comment, tell me something the signature doesn't.

The liar

// Retry up to 3 times
private const int MaxRetries = 5;

The eternal "temporary" fix.

// TODO: temporary workaround, remove later

Later when? Remove it how? Under what conditions? This comment was written in 2019 and it will outlive us all. If something is temporary, say what it's waiting for: a ticket, a version, a date.

The graveyard

// var result = await _legacyService.CalculateAsync(order);
// if (result.IsValid) { ... }
// var result2 = await _newService.CalculateAsync(order);

Commented-out code tells the reader nothing except that someone was scared to delete it. Delete it. If you ever need it again, you won't.

The novel

A thirty-line method with a three-paragraph comment on top explaining how it works. Sometimes that's necessary. Often it's a sign the code should be rewritten, and the comment is compensating. Try the refactor first. Then comment whatever complexity is left.

Clean Gets You Halfway

Clean code is a great goal. Good names, small methods, clear structure: keep doing all of it. But clean code answers one question, what does this do?, and a real codebase keeps asking more. Why is it like this? What happens if I change it? Is this weird thing a bug or a scar?

Those answers don't live in the syntax. They live in the head of whoever wrote the code, and heads are terrible storage. They change jobs, they go on vacation, and they forget things by Tuesday.

So here's the rule I actually follow, and it fits in one sentence:

If I had to stop and think before writing a line, I write down what I thought.

If the line was obvious, I leave it alone. No echoes, no ceremony, no dragons. But if there was a moment where I went "hmm, careful here," that moment goes into a comment, because the next reader is going to have the exact same "hmm," just without the answer.

Clean code tells the reader what you did. A good comment tells them what you knew. You need both.

Enjoyed this write-up? Let's stay connected!

I share more software engineering insights, projects, and experiments across these platforms:

Vibe Coding Isn't the Problem. Calling It Engineering Is

Giorgi Kobaidze — Sun, 13 Sep 2026 07:06:59 +0000

Let's Address the Elephant in the Room Again

Vibe coding has always been a weird topic to talk about. Lately it's gotten even weirder.

Say "vibe coding is a creative process, but it's not engineering" and people get defensive immediately, calling you a gatekeeper and all those interesting terms.

So I decided to write this brief article to answer those opinions in a short and precise manner, without too much sugarcoating or dancing around.

Engineering is Part of Creation

There's a real difference between the two. Creation is much broader term. engineering is part of the creation process. It's also part of maintenance, debugging, refactoring, and most of what engineers actually spend their days doing.

So the question worth asking is: during the creation process, who does the engineering? You? Your coding agent? Both of you?

Definitions Matter Here, Critically

Vibe Coding

You write a prompt and hand it to the AI. You don't edit the code and you don't review it. You might not know the first thing about programming and still ship something.

AI-Assisting

AI-generated, human-reviewed. The AI writes all of it, you read all of it. THIS IS NOT VIBE CODING, it takes enough skill to tell good code from bad.

AI-assisted

You and the AI write the code together, and you're the one driving. AI gives you speed, a second opinion, and the edge cases you'd have missed. ALSO NOT VIBE CODING.

Where This is Going

The trend is toward more semantics and more abstraction. It's been that way since assembly. Vibe coding is the next step on that line, and it will keep taking over more of the work. Maybe one day the job is 95% writing prompts, and to be honest, I'll welcome it, that makes my life easier too.

But the question right now is whether we're ready to build financial systems, health apps, and anything else touching sensitive data without analyzing the code.

We're not. Doing it anyway to prove your point will cause absolute chaos.

The line I'd draw:

Building something for yourself, for fun? Vibe code all of it. It's genuinely a good time.

Building something real, something that processes people's personal data, handles money, and turns a profit and vibe coding it from start to finish? That tells me one of three things:

You're not willing to spend two to four weeks learning the absolute basics of coding, security, and best practices.
You don't care about the quality of your own product, and ultimately other people's personal data and security.
You're not curious about how any of it works under the hood. And if you're calling yourself an engineer, you should be eager to understand the mechanics of software engineering and coding.

All three happen constantly now, and that's the sad part.

What I Actually Do?

I've been a software engineer for ten years. Even so, when I need to build something in a language I'm not fluent in, I still spend a day or two on the language reference, the docs, the basic mechanics, enough that I can understand what the AI produces.

Then I review everything it generates and ask so many follow-up questions that I probably spend more tokens interrogating the code than creating the project.

Every strong engineer I know works this way. We use AI extensively, every single day. We also take everything it gives us with a grain of salt.

So what's stopping you from doing the same?

We'll get to the point where you can let go of the steering wheel. We're not there yet. Keep holding the wheel to make sure you don't go off the road.

Enjoyed this write-up? Let's stay connected!

I share more software engineering insights, projects, and experiments across these platforms:

Show Me the Article You're Most Proud Of And I'll Read Every Single One of Them

Giorgi Kobaidze — Thu, 10 Sep 2026 19:30:37 +0000

I Write More Than I Read

I used to read a lot on DEV. Then I started writing my own articles, and somewhere along the way I stopped reading nearly as much as I used to.

I want to fix that. There are so many good writers on here that it's genuinely overwhelming, and I'd rather be reading them than not.

The Rules

Doesn't matter if you're a veteran tech writer or you published your first post last week.

👉 Pick one article you're most proud of. Just one. It doesn't have to be the community favorite or the one with the most reactions, pick the one you love the most.
👉 Drop the link in the comments.
👉 Optional: tell me why it's special to you. One paragraph is plenty.

I'll read it and give you my honest feedback. I promise! 🤝

Why Bother

Maybe your favorite post never got the attention you thought it deserved. Maybe it got plenty, and you'd just like an excuse to share it again.

Either way, it's sitting in your archive and nobody's read it in months. This is a chance to put it back in front of people.

And it works both ways, read what other people drop in the comments. That's the whole point.

Showcase your work, appreciate everyone else's.

Let's build a hall of fame of DEV's best work! 🌟

Let's stay connected!

I share more software engineering insights, projects, and experiments across these platforms:

The Same Day, 180 Times: How Does the Unglamorous Machinery of Locking In Actually Work?

Giorgi Kobaidze — Sun, 06 Sep 2026 17:36:04 +0000

"Inspiration is for amateurs, the rest of us just show up and get to work."

— Chuck Close

This Wasn't Supposed to Be the Next Article
What Locking In Actually Means
- The Longer You Practice Consistency, The More Consistent You Get
- The Rule of 100: The Compounding Effect of Life
- Vacations Happen Roughly Once Every Six Months
It's Day One of 180. So What Do You Do?
- Just Plan Things
- Sharpen Your Tools
Now That You're Well Into The Camp Everything Matters
- The System Is the Point
- Same Hours, Every Day
- Clock Out Twice
- Put Your Phone Away
- The Body Is Part of the System
- Day Five Is Usually When It Turns
- Checkpoints Get You Through the Gap
- Recharge on Purpose
How to Deal With Bad Days
Commit to More Than One Thing, Just Not at Once
My Suggestion to You
- Congratulations
- Start Slow
- Lonesome Is a State of Mind
- By The Way

This Wasn't Supposed to Be the Next Article

It's 6:00 AM on a Sunday. I haven't had coffee yet, and I thought about fixing that before I started. I didn't. The longer I do this, the more I think the pre-coffee excuse is just a licence to do something badly and call it circumstance.

I hadn't planned to write this one either. My last piece on this topic A New Personal Best: What Six Months of Locking In Can Do got more engagement than I ever expected, which included praise and a handful of healthy critiques. I had a stack of technical articles queued up behind it. They can wait.

The questions were mostly the same question, asked different ways. That article was a list of outcomes: two hackathon wins, a new role, a charity donation, thirteen articles. What people wanted was the part I left out:

What the days actually looked like.

So that's what this is. The routine, written down as it ran. Roughly the same day, 180 times. It is far less interesting than the results made it look. But if you're anything like me, you love to hear about the process even more than the results.

Let's just get it done.

What Locking In Actually Means

Locking in sounds dramatic, and it isn't. I don't lock myself up in a room for six months and I don't go up a mountain to think about nothing but work while meditating for 12 hours a day. That stuff ain't for me.

Quite the contrary.

These are the stretches when I'm most active socially and most active on my own projects at the same time.

Strip the phrase down and it's ordinary: sustained, hyperfocus on a goal and on the process that gets you to it. The only unusual part is how long I hold it. Six months. Quite a stretch, huh?

There are reasons it has to run that long.

The Longer You Practice Consistency, The More Consistent You Get

That sounds obvious. The interesting part is why it happens.

Your brain has that weird and useful feature to handle almost anything you hand it repeatedly. That includes things you actively disliked at the start: training, sitting with a hard problem, running errands, even organizing your desk. Do them often enough and they stop costing what they used to. Some of them start pulling at you instead.

The mechanism isn't mysterious. Repetition makes a thing part of your baseline, and the baseline is what your brain treats as normal. Once something is in there, skipping it doesn't feel like a day off. It feels like a day with something missing from it.

Here's roughly how that went for me:

One week: A good start and nothing more. Nothing is in the system yet.
One month: It's getting easier. You still have to decide to do it.
Three months: A habit. You notice when you skip it. It's significant.
Six months: Part of you. Skipping it costs more than doing it, and your brain actively protests.

Two things amplify all of this when there's a reward waiting at the end: motivation and anticipation.
They aren't the same force and confusing them is why people stall around month two.

Motivation starts you. It's whatever you're after: a skill, money, connections, a promotion, recognition, or everything together.

Anticipation carries you. Same reward, different job. Motivation is spent the moment you begin, anticipation is what you run on for the six months after that.

The Rule of 100: The Compounding Effect of Life

I borrowed this from Jesse Itzler, an American entrepreneur, who's also one of my favorite authors.

The rule of 100 basically means the following:

If you spend 100 hours a year on any discipline, about 17 minutes a day, you'll end up better than 95% of the world's population at that discipline.

Pick any discipline you want: coding, playing basketball, playing guitar, boxing, riding a bike. It doesn't really matter which one.

If you practice it for 17 minutes a day, within a year you'll be more skilled than most people in the world. This doesn't mean you'll become a boxing champion, an NBA player, or a professional software engineer. But you'll be pretty decent.

Now imagine what you can achieve if you do something for hours a day. You can reach a professional level in a few years if you stay consistent. But keep in mind: consistency isn't measured in time alone. The hours only count if you put real effort into them.

This is called the compounding effect of life.

Vacations Happen Roughly Once Every Six Months

On average, people take a big vacation about once every six months, and I'm no different. When I take one, I always travel somewhere to clear my head. Traveling after six months of locking in is one of the most rewarding feelings there is. You know you got through that "six-month camp," you have results you're proud of, and now you're out in your favorite countries and cities. Oh gosh, there's nothing like it.

If a trip falls inside a lock-in period, I try not to step away from the work completely. Even without my laptop, I'll research things on my phone on a plane or a train, where there's plenty of time anyway.

It's Day One of 180. So What Do You Do?

Just Plan Things

Nothing dramatic. There's no starting gun. Day one is for preparation.

I spend it on prerequisites: a rough map of what I'm doing over the next six months, and roughly when. It's the dullest day of the entire stretch and skipping it is the most expensive mistake on offer.

Here's the thing about that map: it's wrong. Some things slip, others land early. Even the most disciplined person alive doesn't hit the schedule they drew on day one, and I never have either.

That's fine, because the dates were never the point.

You're not trying to predict when you'll reach the goal, or even its sub-goals. You're deciding what you'll do every single day, repeatedly to get closer to it. Plan the input, not the outcome. Input is something that you actually control, so make it precise. If you say: "I'm going to spend 4 hours a day on this project", mean it! Making claims you don't follow through on will cost you trust in your own word. And there's nothing worse than not trusting yourself. If you can't count on yourself, how can anyone (your team, your boss, your friends, your loved ones) count on you?

So spend day one planning. If you're building something, decide which features come first, then break the work down until you're left with pieces small enough to estimate honestly. Usually there's more than one thing running at once - a project, articles, open source, competitions, whatever else you've signed up for. Deciding roughly when you'll do what is what stops those from collapsing into each other.

The worse alternative is working on whatever you feel like that evening. And whatever you feel like, six months out, adds up to nothing. That'll just waste your time. Don't do that to yourself.

Sharpen Your Tools

Take a look around your workspace. Yes, right now. What does it look like? Messy or organized?

If it's organized, congratulations, that box is already ticked.

If it's messy, start there. Discipline isn't just saying "I'm going to review three pull requests today."

A few weeks ago, when I started my current six-month lock-in period, do you know what the very first thing I did was?
I washed my car. Then I cleaned my laptops and my keyboard. Sounds weird, right? It does, but it also works for me like a charm.

Real discipline is the kind that's embedded in your whole system, your life, not just your projects. The broader it is, the more sustainable it is and the more it carries into everything else you do.

If your car is full of garbage, soda cans and old receipts and your living room has last month's pizza boxes and empty bottles scattered around it, there's a good chance you're not consistent in your repositories either. Best practices, timely reviews, pruning dead branches and stale pull requests, all of it tends to be sloppy for the same reason. Not because you don't know better, but because discipline isn't a thing you switch on when the editor opens, or not even when your eyes open in the morning.

So start with the basics. You'll be surprised how much it changes your attitude toward the actual work. You'll feel proud of yourself, and you'll trust yourself more.

Once that's done, get specific. For example, if you're building a new app, make sure:

Every tool installed, configured, and updated
Every dependency installed and resolving cleanly
The latest version of your framework. You don't want to start on an old one unless there's a specific reason for it
A repository that's ready on day one: README, license, .gitignore, branch naming, branch protection
Formatting and linting rules committed, so you're not arguing with your editor in week three
CI running green on an empty commit, before there's anything to break
Secrets and environment variables sorted, documented, and out of source control
Somewhere to track work: a board, issues, whatever you'll actually open (I usually use GitHub projects)

And many other things.

Every item on that list is a small piece of friction you're removing now, while setting things up is still interesting, so that it can't stop you later. Because it will be day 56 at eleven at night, you'll have forty minutes and no energy, and the difference between doing something and doing nothing will come down to whether the build runs on the first try. Clear the obstacles while you're still enthusiastic.

Now That You're Well Into The Camp Everything Matters

The System Is the Point

When I'm in the middle of a camp like this, which I am right now, the only thing that matters is following the system. Not feeling good about it. Not being perfect at it. Following it.

You will not be perfect. Some days are slow, others are faster. Some days you'll do half of what you planned, and some days you'll do none of it. That's fine. A system you follow 80% of the time for six months will beat a system you follow perfectly for nine days and then abandon. The goal isn't a clean record. It's that the thing keeps running while you're tired, bored, annoyed, or unconvinced.

One rule that's worth more than the rest: never miss twice. One missed day is noise. Two missed days is the new pattern - a very very bad bad pattern.

Same Hours, Every Day

Wake up at the same time. Go to sleep at the same time. Work in the same windows. It sounds joyless and it's the single highest-leverage thing on this list, because a fixed schedule means you stop spending willpower on when. The decision is already made, so all you have to do is show up.

Find out how long you can actually concentrate before the quality drops, not how long you can sit at a desk, how long you can genuinely hold a problem in your head. For most people it's shorter than they'd like to admit. Build your blocks around that real number instead of the one you wish you had and then work on stretching it. Attention is trainable, and it pays out in everything else you do.

Protect the first block of the day for the hardest thing. Whatever gets your best hours is what actually gets done. And once you've gotten over with that hard part, the rest of the day is almost like coasting.

Clock Out Twice

Draw a hard line between your day job and your personal work. Not a soft one, a hard one, with a time on it. I know, it's much harder than it sounds, I'm speaking from experience, but it's not impossible. It'll actually make way more productive on both sides of the fence.

You also need a marker for done. Decide in advance what finishing looks like today, and when you hit it, stop. Being unable to stop is not discipline, it's the thing that ends six-month runs early.

Do one thing in a given time. Only one.

I've watched people brag about working on four or five things at once, and I used to be one of them. Here's what I eventually understood: doing five things simultaneously mostly means screwing up all five things simultaneously, because none of them get the quality they need.

There's a real cost to task switching, too. Every jump between contexts leaves part of your attention stuck on the last thing, and you pay that tax on every single switch. It doesn't feel like a cost, which is exactly what makes it expensive. Ten context switches an hour and you're already exhausted without getting any quality work done.

Put Your Phone Away

It goes without saying that you should stay the hell away from social media. I mean it, put the phone down.

I don't think most people have honestly reckoned with what those stupid reels do to their ability to sit with a hard problem. You train your attention with whatever you feed it, and if you feed it seven-second clips all evening, then sit down to debug something that needs forty uninterrupted minutes, you're going to find the machinery doesn't work anymore. It isn't that you've lost the ability. It's that you've spent months practicing the exact opposite "skill".

The fix is boring and it's mechanical: get the apps off the phone, or just don't touch the phone unless you absolutely need to. Willpower is not a strategy here, and you're not competing only against your own laziness. You're competing against companies who have spent billions figuring out how to win this specific fight.

Think about how much pointless content you consume per day and how much great content you could've actually produce if you had used that time productively.

I'm not saying cut it out entirely. I still watch videos to keep up with things I like during breaks and over lunch. But there's a line and it isn't blurry. When I sit back down, the phone is done for the next block.

The Body Is Part of the System

For me this was never only about the hours at the desk. The rest of your life either supports the goal or quietly undermines it.

Think like a professional athlete.

Sleep properly. You'll be tired at the end of every day and that's normal, but tired and under-slept aren't the same thing. Sleep is where the recovery actually happens and it's the first thing people sacrifice when they're behind. It's also the worst possible thing to sacrifice, because everything you're trying to do runs on the organ that sleep repairs - your brain.

I used to stay up all night or two nights in a row, writing code, but it'd take 2 full days to recover after from that hardcore session, which isn't productive.

Eat like it matters. It affects your thinking more than you'd expect. Junk food, sugar, fat, carbs don't just make you slower physically, they make the afternoons foggy, and foggy afternoons are where your six months quietly leak away.

And obviously, stay away from alcohol and cigs. Not only because they'll cost you a productive evening, but because they'll cost you the brain and the body that your own life depends on. Well, unless you want to destroy both, your brain and body, for some reason.

Move most days, preferrably every day. It doesn't have to be hard or complicated. Walking outside, or an hour on a treadmill, is enough. It's fine to do the bare minimum if being athlete-level fit isn't your goal. It pays back in ways that aren't obvious. Better sleep, steadier energy, fewer bad afternoons, and a real confidence boost that comes from doing a moderately unpleasant thing that most people skip.

None of this is optimization for its own sake. It's maintenance on the machine that has to run for 180 days.

Day Five Is Usually When It Turns

Here's the part nobody warns you about.

Day one is great. You're excited, the plan is fresh, you have all the energy in the world.

Day two, slightly less.

By day five you absolutely hate it.

That's not a sign you picked the wrong goal. The goal is fine. That's just what motivation does, it's a starting force, and it wears off.

The problem is that this happens before discipline has had time to develop, so for a couple of weeks you're in a gap with no motivation left and no habit yet to carry you. That gap is where almost everyone quits. I've quit there myself a few times.

Checkpoints Get You Through the Gap

The technique that worked for me was scheduled checkpoints. Every two weeks, on a Monday, I'd stop and look at what's actually happened.

Two things make it work. First, you look at the record instead of the feeling. The feeling on day twelve is "I'm getting nowhere." The record says you shipped four things, wrote 2 articles and the record is right. That's why it's worth keeping a rough log as you go, a checkpoint with no data is just a mood.

Second, judge yourself on what you did, not on what it produced. Results arrive on their own schedule and mostly late. Whether you did the work is knowable today.

Then treat the checkpoint as a small restart: readjust the plan, cut what isn't working, remind yourself what the end goal actually is, and go again. You keep doing that until the day you notice you don't need the checkpoints anymore, because the thing has become who you are. Now you're a disciplined guy or a girl.

That's when it stops being hard.

Recharge on Purpose

You have to let the system cool down every once in a while. Pick a day, let's say once every two weeks, or once a week if you need it, where you deliberately move slowly or do nothing at all. I mean the personal work, obviously. I'm not telling you to take the day off from your job.

Spend that day on something you genuinely enjoy. This matters more than it sounds. If you don't feel like playing video games, don't play them just for the sake of "taking a break." If you don't feel like going out and socializing, don't go out because someone told you that's what fun looks like. It's fine to decline a casual invitation, the real friends will understand.

One warning, though: make sure that day doesn't quietly turn into three. That's a new pattern forming, and it needs to be spotted and terminated early. One day restores your momentum. Three days end it.

How to Deal With Bad Days

We've talked a lot about discipline and how it answers almost everything. But some days are just awful. Everyone gets them. Some stretches, most days are awful.

I had one recently.

Back in March I won the GitHub Copilot CLI challenge, came first out of more than 400 participants with this project: Metal Birds Watch

It's still the biggest thing I've ever won, and it's special to me for a second reason: I used it to make a significant donation to charity.

One of the prizes was a ticket to GitHub Universe in San Francisco this October. I've been looking forward to it all year.

I just found out I'm not going to be able to go. The reason is completely outside my control.

It sucks, right?

It absolutely does. It especially sucks when you've done everything right and the thing standing in the way isn't yours to fix. That win was one of the high points of my life. This is one of the sharpest disappointments of it.

But that's life. It's unfair, there's nothing new about that, and if I sit here and dwell on it the only thing I'll actually change is my own state of mind - for the absolute worse.

So here's what happened on the evening I found out: I opened my editor and worked my a$$ off on one of my personal projects. Not heroically, not particularly well. I just did the block that was on the schedule.

That's the whole argument for the system, and it's why this section isn't a detour from the rest of the article. On a good day, discipline is a nice-to-have, you'd have done the work anyway, because you wanted to. On a day like that one, it's the only thing standing between you and a week you don't get back. The routine doesn't ask how your news went. It just says it's eight o'clock.

Something didn't work out for you? Fine. Try again, or try something else. Life is unfair sometimes, and it's also full of opportunities you haven't looked at yet. But don't wait until you feel better before you start moving again. Moving again is what makes you feel better.

Commit to More Than One Thing, Just Not at Once

If you want to give the whole six months to a single thing because of its size or importance, go for it. But it helps to have somewhere else to put your attention when you're sick of staring at the same problem for the fourth day running and it's better if that somewhere is fundamentally different from the main work.

Right now I've got the biggest personal project I've ever attempted. Realistically it's five or six months just to reach a basic, shippable version (or so I hope). Alongside it I'm still writing articles, recording videos, and entering challenges. And last but definitely not least, I've started learning German on my own, no teacher, no class, nobody. My argument is that I'm a software engineer and I know a thing or two about learning languages, I'm hoping to have the basics in about a year. So far I'm loving it.

That sounds like it contradicts what I said earlier about doing one thing at a time. It doesn't, and the distinction is worth being precise about: multiple commitments, never simultaneous ones. Nothing on that list ever shares an hour with anything else on it. They share a week. That's the difference between variety and multitasking, and it's the whole game.

So allocate days, not attention.

A lock-in period can also contain smaller lock-in periods inside it. You block off a week or two for something specific, finish it, and return to whatever you were doing before.

Say you're deep in your main project and DEV Community posts a challenge you can't turn down. You pause the main work, lock in on the challenge for a couple of weeks, then lock back into the primary thing. It works like a function call stack, the last thing you pushed is the first thing that gets finished and then you unwind back down to where you were. LIFO.

The catch is the same one you'd recognize in code. A stack only works if the frames actually return. Push something new on top every time a shinier thing appears and never pop any of it, and you don't have a system, you have a leak. Six months later there's nothing finished at the bottom of it.

My Suggestion to You

Congratulations

If you've made it this far and you've read the whole thing, congratulations. This article turned out much longer than I anticipated, and reading it end to end in one sitting says something real about your attention span. That's not a throwaway compliment either, the ability to stay with something long after it stops being novel is the best predictor I know of whether you'll finish a six-month run or abandon it in week three.

Start Slow

If you've never done anything like this, don't start at six months. Start at one, with something specific you want finished by the end of it. Then raise it to three. What you're really practicing is patience, attention, and the ability to finish what you started, those are real skills, and they can be trained like any other. Pull off three months and six is absolutely within reach. At that point it's just a decision.

Lonesome Is a State of Mind

This is actually a song by Djo - great song by the way. But the statement itself is also very true. Especially when it comes to this topic.

Do it quietly. Tell nobody, or tell only the people closest to you. Two reasons for that. First, announcing a plan hands you a hit of almost the same satisfaction you'd get from actually doing the thing, you collect the congratulations up front, and the drive that was supposed to carry you leaks out through your own mouth.

Second, very few people are going to come with you on a commitment this long. Be ready for that. If you're not a lone wolf type of person like I am, someone genuinely comfortable doing things alone, then you need to either find at least one person willing to run the same stretch alongside you, or get comfortable with the quiet.

And finally, this isn't an F1 sprint race. It's the 24 Hours of Daytona, not an F1 sprint race. Nobody wins it in the first hour. You win it by still being on track when most of the field isn't.

By The Way

This is also a song name this one's by Red Hot Chili Peppers. But it also fits the context.

Speaking of F1. As I was writing this I realized I'd missed the race at Monza, Italy. Got so carried away that it went straight past me. It's fine, I'll watch the highlights.

Let's get to that checkered flag!🏁

Enjoyed this deep dive? Let's stay connected!

I share more software engineering insights, projects, and experiments across these platforms:

Backend Engineer (Me) Ships a Browser Game With One Unintentional System Requirement: My Monitor

Giorgi Kobaidze — Sun, 09 Aug 2026 19:42:53 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

Prefer Watching Instead?

If reading isn't your thing, no worries, I've got you covered. You can watch the video below:

Introduction: In What Universe Did I Think This Was a Good Idea?
The Game
The Game Loop
The Game Physics
It Worked on My Machine Goddammit
Understanding the Root Cause
The Fix: Delta Time
But There's a Catch: Not Everything Is Fixed With × dt
- Pattern 1: Linear operations
- Pattern 2: Exponential decay
- Pattern 3: Lerp smoothing
Summary: The Three Patterns
One More Thing: Re-tune Your Constants
Pull Request
The Takeaway

Introduction: In What Universe Did I Think This Was a Good Idea?

It was a nice, calm day. Everything was going smoothly, I was just minding my own business.

Out of nowhere, a notification from @jess popped up. And I see this:

Good morning! Good afternoon! Good Evening!

Welcome to our first DEV Weekend Challenge, a short focused challenge designed to fit into your weekend. Since submission window is tight, we've set the timing to ensure that no matter where you are in the world, you'll have the majority of your Saturday and Sunday to participate.

Let's get started!

I don't know what's exactly wrong with me, but whenever I see a word "challenge", something clicks in my brain and it starts a multi-thousand thread process to think of an idea until the idea isn't generated. This time was no different. But in some ways, it really was quite different.

Let me explain why. So here's my thinking process:

OK I just have the weekend. 2 days tops, that's it. Well, sometimes just planning can take way more than that.
I'm a full-stack engineer with extensive back-end background, so back-end is my primary comfort zone.
Building something fun and flashy would be great, like a... browser game? Hell yeah!!! ... well, except, I ain't no game developer and I have never ever written a browser game.

...

So I decided to build... drum rolls ... A BROWSER GAME!

If you're not a technical person, a back-end developer building a browser game is an NFL player playing tennis.

You already know this isn't gonna end well, don't ya?

The Game

You're probably wondering what kind of game I created. It's basically a driving simulator (well... kinda) - a synthwave 3D driving game where your DEV community articles appear as neon billboards along the endless highway. It fetches articles, stats, and things like that using the DEV Community by the username.

If you'd like to give it a try before continuing, here are the relevant links:

Demo
Submission article
GitHub Repo

The Game Loop

Sunday DEV Drive is a browser game built on top of Three.js - a JavaScript library that handles 3D rendering in the browser. The game runs entirely client-side: no server, no backend, no build step. Just HTML, JavaScript, and your DEV Community articles fetched from a public API.

The game is built around a game loop: a function that runs over and over, many times per second. On each iteration it does the same three things:

Read inputs - is the player pressing the accelerator? Turning left?
Update the world - move the car, adjust the camera, apply physics
Draw the frame - render everything to the screen

In the browser, the standard tool for this is requestAnimationFrame. You give it a function, and the browser calls that function right before it repaints the screen — as fast as the display allows:

function animate() {
  requestAnimationFrame(animate); // "call me again next frame"

  updatePhysics();
  updateCamera();
  renderScene();
}

animate(); // start the loop

Think of it like a flipbook. Each call to animate() draws one page. The faster the pages flip, the smoother the motion looks. On a 60Hz monitor, the browser flips 60 pages per second. On a 165Hz monitor, 165 pages per second.

The Game Physics

The car's movement is simple Newtonian-ish math applied every frame, nothing exotic, just the kind of physics you vaguely remember from high school:

Throttle → adds to the car's speed (acceleration)
Speed → moves the car's position
Steering → rotates the car's angle
Friction → slowly reduces speed when no input is held
Camera → smoothly follows the car from behind

Simple stuff. Which is exactly why the bug hiding inside it was so easy to overlook.

It Worked on My Machine Goddammit

I tested the game. Multiple times. Zero issues. The car moved naturally. Steering felt great. Acceleration was progressive. The brakes had a nice bite to them.

Everything felt perfect.

Well, until I tested it on another computer. Ladies and gentlemen, I need your attention, please: I don't care how certain you are that your code works:

ALWAYS TEST IT ON ANOTHER COMPUTER.

I decided to flex a little and show the game to my mom and brother. So I sent them the links.

"Hey, check this out. I made a game."

A few minutes later, they texted me back:

"The visuals are really good, but the car is barely moving. Is this by design?"
"Umm... whaddaya mean "barely moving?" I just tested it and it's fine. Are you sure you're pressing the gas?"

So I started troubleshooting.

And troubleshooting.

And troubleshooting some more.

Nothing made sense.

The controls were working. The game was running. There were no obvious errors. Yet somehow, on their machines, my beautifully engineered car had apparently decided to become a mobility scooter.

I had no idea what was going on.

So I did what any developer would do in this situation:

I Googled
I asked AI
I stared at the code
I sketched things out
I questioned my architectural decisions.

...

I questioned my life choices.

And then it just clicked.

I had used the monitor's refresh rate as part of my movement calculations.

Yep.

My physics weren't actually frame-rate independent.

My monitor was running at 165 Hz. Their monitor was running at 120 Hz.

That's a 45 Hz difference.

45 frames per second was enough to turn my perfectly drivable car into a perfectly drivable car, but in slow motion.

The game wasn't broken on my machine. My monitor was secretly a system dependency.

I had messed up... And badly.

And now it was time to fix it.

Understanding the Root Cause

My animate loop looked like this:

function animate() {
  requestAnimationFrame(animate);

  carState.speed += acceleration;
  car.position.x += Math.sin(carState.angle) * carState.speed;
  car.position.z -= Math.cos(carState.angle) * carState.speed;
}

requestAnimationFrame calls your function once per display refresh. On my 165Hz monitor, that's 165 times per second. On a 120Hz monitor, 120 times.

The problem: every physics value was per-frame, not per-second.

Look at what actually happens across different hardware:

Frame Rate	Updates/sec	Effective speed/sec
165 fps (my machine)	165	`0.42 × 165 = 69.3` ✅ feels right
120 fps	120	`0.42 × 120 = 50.4` 🙂 73% of intended
60 fps	60	`0.42 × 60 = 25.2` 😐 36% of intended
30 fps	30	`0.42 × 30 = 12.6` 😩 18% of intended

I had unknowingly tuned the entire game for 165fps. Everyone else was experiencing a completely different game.

The Fix: Delta Time

The solution is to measure the actual time elapsed between frames and use it to scale all physics updates. This is called delta time.

const clock = new THREE.Clock();

function animate() {
  requestAnimationFrame(animate);

  const delta = clock.getDelta(); // real seconds since last frame
  const dt = delta * 60;         // normalized: 1.0 at 60fps baseline

  // Now multiply everything by dt
  carState.speed += acceleration * dt;
  car.position.x += Math.sin(carState.angle) * carState.speed * dt;
  car.position.z -= Math.cos(carState.angle) * carState.speed * dt;
}

clock.getDelta() returns the real elapsed time in seconds. At 60fps that's ~0.0167s.
At 165fps it's ~0.006s.
At 30fps it's ~0.033s.

I multiply by 60 to normalize: dt = delta * 60. This means:

At 165fps → dt ≈ 0.36 (smaller steps per frame, same per second)
At 60fps → dt ≈ 1.0 (baseline)
At 30fps → dt ≈ 2.0 (larger steps per frame, same per second)

Now the same distance is covered per second regardless of hardware:

Frame Rate	`dt` per frame	Movement per frame	Movement per second
165 fps	`≈ 0.36`	`speed × 0.36`	`speed × 60` ✅
60 fps	`≈ 1.0`	`speed × 1.0`	`speed × 60` ✅
30 fps	`≈ 2.0`	`speed × 2.0`	`speed × 60` ✅

But There's a Catch: Not Everything Is Fixed With `× dt`

Simple * dt fixes linear operations. But a real game has more than just linear math. In this fix alone, there were three distinct patterns, each requiring a different approach.

Pattern 1: Linear operations

The straightforward one. Any additive rate just gets multiplied by dt:

// ❌ Frame-rate dependent
carState.speed += CAR.acceleration * throttle;
carState.speed -= CAR.brakeForce * brake;
car.position.x += Math.sin(carState.angle) * carState.speed;
carState.angle += carState.steer * carState.speed * CAR.turnSpeed;

// ✅ Frame-rate independent
carState.speed += CAR.acceleration * throttle * dt;
carState.speed -= CAR.brakeForce * brake * dt;
car.position.x += Math.sin(carState.angle) * carState.speed * dt;
carState.angle += carState.steer * carState.speed * CAR.turnSpeed * dt;

If you're adding or subtracting a value per frame, multiply it by dt. Done.

Pattern 2: Exponential decay:

Math.pow(factor, dt)

This one is less obvious. When driving off-road, the car slows down using a multiplier applied each frame:

// ❌ Frame-rate dependent
carState.speed *= 0.97; // 3% drag per frame

At 165fps this applies 3% drag 165 times per second. At 30fps, only 30 times. The off-road drag behaves completely differently depending on hardware.

The naive fix: carState.speed *= 0.97 * dt is wrong.
You can't linearly scale a multiplier. At dt = 2 you'd get 0.97 * 2 = 1.94, which would accelerate the car instead of slowing it down.

The correct fix uses exponentiation:

// ✅ Frame-rate independent
carState.speed *= Math.pow(0.97, dt);

Why does this work? Repeated multiplication is exponential decay. Consider what happens over one second:

At 60fps (dt = 1, 60 frames):

speed after 1s = speed × 0.97^60

At 30fps (dt = 2, 30 frames):

speed after 1s = speed × (0.97^2)^30 = speed × 0.97^60 ✅ identical

Math.pow(factor, dt) correctly scales the decay exponent rather than the multiplier itself. The result over any given real-world time is always the same.

The same pattern applies to smooth steering interpolation, instead of a fixed lerp coefficient, it uses the same exponential trick:

// ❌ Frame-rate dependent
carState.steer += (steerDir - carState.steer) * 0.1;

// ✅ Frame-rate independent
carState.steer += (steerDir - carState.steer) * (1 - Math.pow(0.9, dt));

Pattern 3: Lerp smoothing

1 - Math.pow(1 - alpha, dt)

The trickiest one. The camera smoothly follows the car using lerp:

// ❌ Frame-rate dependent
camera.position.lerp(targetPos, 0.08);

lerp(target, alpha) moves alpha percent of the remaining distance each frame. At 165fps the camera takes 165 small steps per second - buttery smooth. At 30fps it takes 30 steps - sluggish, visibly lagging.

Again, alpha * dt is the wrong fix. At dt = 2 you'd get alpha = 0.16, which changes the feel, and at high enough values it would overshoot the target entirely.

The correct formula:

// ✅ Frame-rate independent
camera.position.lerp(targetPos, 1 - Math.pow(1 - 0.2, dt));

Here's the intuition. After n lerp steps at factor alpha, the remaining distance is:

remaining = (1 - alpha)^n

To make this time-independent, you want the same remaining distance after n frames at dt=1 as after n/2 frames at dt=2. The solution is to raise (1 - alpha) to the power of dt:

adjusted_alpha = 1 - (1 - alpha)^dt

Plugging in the numbers:

At dt = 1.0 (60fps baseline): 1 - 0.8^1.0 = 0.200 - original feel ✅
At dt = 0.36 (165fps): 1 - 0.8^0.36 ≈ 0.083 - smaller steps, same tracking speed ✅
At dt = 2.0 (30fps): 1 - 0.8^2.0 = 0.360 - larger steps, same tracking speed ✅

The camera now follows the car at the same real-world speed on any display.

Summary: The Three Patterns

Situation	Frame-rate dependent	Frame-rate independent
Add/subtract per frame	`value += rate`	`value += rate * dt`
Multiply per frame (decay)	`value *= factor`	`value *= Math.pow(factor, dt)`
Lerp toward target	`lerp(target, alpha)`	`lerp(target, 1 - Math.pow(1-alpha, dt))`

One More Thing: Re-tune Your Constants

After making physics frame-rate independent at a 60fps baseline, my original constants felt wrong, they were implicitly tuned for 165fps. I had to re-tune them for dt = 1:

// Before (accidentally tuned for 165fps)
maxSpeed:     0.42,
acceleration: 0.0006,
brakeForce:   0.0015,
friction:     0.00005,

// After (tuned for dt = 1 baseline at 60fps)
maxSpeed:     1.155,
acceleration: 0.004538,
brakeForce:   0.011344,
friction:     0.000378,

If you're migrating an existing game, expect to spend time re-tuning. The physics will now be consistent across hardware, but the feel may shift from what you were used to on your own monitor.

Pull Request

Check out the pull request for this bug fix:

Click Here to Check Out the Pull Request

The Takeaway

If you're building a game or animation loop with requestAnimationFrame, assume nothing about frame rate. Your players are on everything from 30fps integrated graphics to 240Hz gaming monitors.

The fix isn't too complicated, but it's also not just "multiply everything by dt." Linear operations, exponential decay, and lerp smoothing each need their own treatment. Get all three right and your game will feel identical whether it runs on a decade-old laptop or a high-refresh gaming rig.

My car now drives the same on every machine. And I learned far more about frame-rate-independent math than I expected from what looked like a simple bug.

Enjoyed this deep dive? Let's stay connected!

I share more software engineering insights, projects, and experiments across these platforms:

Everyone Can Drive. Not Everyone Can Drive Well. Same Goes for AI-Assisted Coding

Giorgi Kobaidze — Fri, 07 Aug 2026 22:01:11 +0000

Overview
AI Didn't Remove the Skill, It Relocated the Skill
Vibe Coding Is Easy. Doing It Well Isn't
Everyone Can Drive. Not Everyone Can Drive Well.
The same thing happens with AI
It's Not Just About Prompting

Overview

Lately, I've been writing a lot of technical-heavy articles and I noticed my articles got less popular.

Well, what did I expect, technical articles can be a little... boooooring.

So this time, let's take a different route. A lighter, more easy-going article, something less about complex concepts and more about sharing ideas, stories and perspectives.

Time to win some readers' hearts back... But if you're a bad driver, you might hate me after that.

AI Didn't Remove the Skill, It Relocated the Skill

I've heard people say that you don't need any skills to use AI to write code.
❌ Errrrr... Wrong.

Stick around. I'll explain it with a car-driving analogy.

Vibe Coding Is Easy. Doing It Well Isn't

Even if you're vibe coding, which is probably the most abstract way of creating software, you still need skills.

Just a different kind of skills.

You need to know how to use your tokens effectively so you can ship products faster, safer, with better quality, and without setting your wallet on fire.

That's what I call "hypermiling your tokens".

There are actual techniques for using your tokens intelligently rather than just throwing more of them at the problem. And those techniques are harder to master than you might think. Not because they're particularly complicated to understand, but because mastering them takes a ridiculous amount of experimentation.

You try different approaches.

Different prompts.

Different models.

Different levels of context.

Different tasks.

You screw things up (inevitable).

You spend way too many tokens on something that should've taken half as many (also inevitable).

You ask the model to fix something it didn't even break (probably with some attitude as well).

Then you ask it to fix the fix (recursion anyone?).

Then you realize the original code was fine (but your top-notch model has already inhaled your entire token budget).

Congratulations. You just spent 200,000 tokens going in a circle.

But, don't get discouraged, because you also started finding that sweet spot where you're getting the most output for the least amount of waste.

And that's a skill. Anything that's earned through trial and failure, is a skill. Simple as that.

Everyone Can Drive. Not Everyone Can Drive Well.

Who would you call a good, skilled driver?

A skilled driver is someone who knows the rules and follows them, while also trying to be as efficient as possible.

They don't overspeed.

They park accurately, between the lines.

They can drive inside a lane consistently.

They use just enough fuel to get where they're going.

They're predictable on the road.

They care about the car.

They care about other drivers.

They don't floor the gas pedal from every single traffic light like they're in a drag race.

And they don't slam on the brakes like they're playing Forza with a keyboard.

A trully good driver knows how to be both safe and efficient. And they might even have no idea how engines or transmissions work and still be great drivers. I mean I'm not a mechanic, I've been driving for about 7 years now and I've never gotten a ticket, or maybe once, but that was unintentional and once I realized I'd crossed the wrong line, it was already late.

And I've seen too many car mechanics who drive like they're gonna spawn again like an NPC after they crash.

Now imagine the opposite.

You go 30 km/h over the speed limit.

Cut people off.

Floor the accelerator the millisecond the light turns green.

Brake so hard your passengers start reconsidering their life choices.

Meanwhile, you're wearing out the car, burning fuel, and spending six times more money than you need to, while also being a danger to everyone around you.

You're not a skilled driver. You're just driving recklessly.

In fact, you probably have no idea what good driving actually is. What being a car operator actually is. What it actually means to be a human element in the equation.

And that's an important distinction.

The same thing happens with AI

Luckily, in vibe coding, being reckless with AI is considerably safer because, thankfully, your Claude session isn't going to rear-end a bus.

The worst thing you're probably going to hit is your own token budget. But being reckless with tokens doesn't mean you're skilled.

Everyone can be reckless. Whether you're driving or coding.

The skill is knowing how to find that sweet spot between speed, quality, cost, and safety, and staying close to it while you're working.

And that sweet spot isn't the same for every situation. Sometimes you need a huge amount of context, sometimes you don't.

Sometimes a massive reasoning model is exactly what you need. Sometimes you're asking it to rename a variable and you've basically brought a semi-truck to the grocery store, not to deliver goods, but to buy them... for the day.

Sometimes you should let the AI explore the problem.

Sometimes you should give it very strict boundaries.

Sometimes you should ask it to implement something.

Sometimes you should stop and think about the architecture yourself first.

And sometimes the best prompt you can write is:

"Don't change anything. Just tell me what's wrong."

That's where the real skill starts showing up.

It's Not Just About Prompting

I think this is where a lot of people misunderstand AI-assisted development.

They reduce the skill to:

"Can you write a good prompt?" - That's actually only one small part of it. You need to know how to scope a problem, how much context the model actually needs, when to split a task into smaller pieces.

You need to recognize when the model is going down the wrong path and understand the output well enough to know whether it's actually good.

And there's another skill: knowing when to stop. This is probably one of the most underrated parts of AI-assisted development (and driving too, some people just can't recognize huge red stop signs sometimes).

More tokens don't automatically mean better software.

More iterations don't automatically mean better software.

More context doesn't automatically mean better answers.

Sometimes you're already 95% of the way there, and another twenty prompts are going to make things worse.

You start optimizing things that don't matter or introduce abstractions nobody asked for.

You refactor perfectly functional code because the model suddenly decided that your entire architecture needs to be "more scalable."

You don't necessarily need to be the person manually turning every screw anymore. Not every driver should be a car mechanic or a mechanical engineer.

You need to know which screws to turn, when to turn them, how hard to turn them, and when to stop touching things before you break something.

And the better you become at working with AI, the less you'll think about "getting AI to write code" and the more you'll think about orchestrating a system that produces good software efficiently.

Similarly to driving, you don't need to build the engine to drive the car. But you still need to know the rules of the road, you need to understand what the pedals do.

You need to recognize when something sounds wrong. You need to know when to slow down and definitely need to know that flooring the accelerator doesn't make you a better driver (it actually makes you look like a terrible driver).

The same applies to AI coding. Throwing more tokens at a problem isn't a skill nor is having the biggest context window or using the most powerful model for everything.

Being able to consistently get the result you need with the least unnecessary wastem, while keeping quality and safety high, is.

And the more time you spend operating around that sweet spot, the better you become at recognizing it.

And that's why:

"AI can write the code for me"

doesn't mean:

"I don't need skills anymore."

The skill just moved.

So yeah.

Be efficient.

Drive safe.

Hypermile.

Enjoyed this deep dive? Let's stay connected!

I share more software engineering insights, projects, and experiments across these platforms:

DEV Community: Giorgi Kobaidze

Natural Languages Have Design Trade-offs Too: Georgian Is Dynamically Typed, English Is Statically Typed

Table of Contents

How This Started

Georgian Language Benchmark: Two Biggest AI Labs Clash in a Language That Doesn't Play by Anyone's Rules

Feature #1: Articles (or the Lack of Them)

The Upside

The Downside

Feature #2: Gender

English: He, She, and It

Italian: Two Genders, Every Noun

German: Three Genders

Georgian: Zero Genders

The Upside of Gender

The Downside of Gender

The Downside of Having No Gender

Complexity Doesn't Disappear, It Moves

Sounds Familiar, Developers?

Articles vs. var

Gender vs. Typing

Languages That Evolve (and Ones That Mostly Don't)

Every Language Is a Trade-Off

Tell Me About Your Language

Georgian Language Benchmark: Two Biggest AI Labs Clash in a Language That Doesn't Play by Anyone's Rules

Table of Contents

One Eye, Zero Excuses

What I Benchmarked

Why Georgian?

One of a Kind and Tough as Nails

Straight Out of a Fantasy Game ("შენ გგონია მომიგე? არა, ცდები!")

What I Built

The Plan vs Reality

The Five Tasks

1. Numbers: Counting in Twenties

2. Verbs: Who Did What to Whom?

3. Translation: Georgian to English

4. Cloze: Fill the Gaps

5. Correction: Fix It, Don't Break It

Writing It All by Hand

How It Runs on Kaggle

Obstacles and Workarounds

Obstacle 1: Kaggle Reserves the Worst Case

Obstacle 2: Failed Calls Look Like Wrong Answers

Obstacle 3: Some Models Think by Default

Obstacle 4: The Model That Won't Stop Thinking

Obstacle 5: Every Push Runs the Task

Obstacle 6: The Small Stuff

Models Tested

Findings

Level by Level

Finding 1: Understanding Georgian Is Solved. Producing It Isn't.

Finding 2: Numbers Are the Final Boss

Finding 3: The Mistakes Are Very Georgian

Finding 4: Georgian Costs More Tokens for Claude

Finding 5: Cheap Can Be Smart

Side Quest: The Uninvited Guest

What It All Cost

The Dashboard

Limitations

What's Next

My Benchmark

Wrapping Up

I Turned My GitHub Profile Into a Cyberpunk Console With a City Built From My Contributions

georgekobaidze (Giorgi Kobaidze) · GitHub

Table of Contents

I Wanted a Simple Custom GitHub Profile. But Things Got Out of Hand Quickly

23:00. Fully Cooked.

Random Doesn't Mean Bad

Why Do I Keep Doing This to Myself?

The Contribution City

The City That Represents Me

The Moment It Clicked

The Cyberpunk Console

Because Why Not?

Welcome to the Sandbox

No JavaScript. No CSS. No Fun?

The Loophole: An SVG Is Just an Image

Okay, But the Sandbox Has Rules

One Console, 23 Images

The Problem: Images Don't Hold Hands

Articles vs. `var`