DEV Community: Giorgi Kobaidze

Engine Off: My 2026 Hackathon Run Is Over

Giorgi Kobaidze — Sun, 08 Nov 2026 18:41:00 +0000

There's a moment after a race when you turn the engine off and everything goes quiet. That's where I am with competitions this year.

Races --- 5
Wins  --- 2

Two Wins and a Dangerous Habit

I won 2 big dev challenges this year, and it got me so hyped that I couldn't stop entering more and more of them. Winning does that to you. You start refreshing the challenges page like crazy.

Then I found out I hadn't won my latest challenge. Did that slow me down? Not even a little. It made me want the next one even more.

The Idea That Never Showed Up

So I set my sights on the next one: the Presage SmartSpectra SDK Challenge.

I was fired up to get started, even though I had no idea what to build.

That's how it usually works. You never know which challenge is coming next, so you come up with an idea on the run. Metal Birds Watch literally started as a word association: Copilot, Pilot, Airplanes. Give me 2 or 3 days and something always clicks.

Back in May, during the Gemma 4 challenge, though, I had the opposite problem. I had so many ideas for the challenge that I couldn't pick one, and I ended up building an app for exactly that problem.

But This Time It's Different

It's been 4 or 5 days and I still have nothing. I've hit the ceiling.

I don't want to build something just for the sake of the challenge, because even if I won, it wouldn't feel special when I look back at my GitHub repositories. I want to build something I'm proud of, not something AI suggested. That's not how we roll here. If even I don't care about my creation, how do I expect that someone else will?

Effort Doesn't Guarantee a Win

There's another thing. After my recent losses, I realized that no matter how much energy and passion you put into a project, it doesn't guarantee a win.

For my last entry, I wrote every dataset by hand, and I finished the project with one eye patched up after a small surgery on my eyelid. It didn't matter.

You can drain yourself to the point where you can't think clearly the next day, and it still won't matter. Someone might come up with a better idea, build it better, or make a better video about it.

The judges only care about the end result, and rightfully so.

All In or Not at All

DEV challenges take a huge chunk of my free time, energy, and mental resources. If I commit to one, I have to go all in. There's no other option.

That was great in the first half of the year, when I was relatively fresh. Now it's a little different. It might be burnout, which I don't really pay attention to because I'm used to it. But I have so many other things going on right now that it's just harder to make time for challenges. I have a lot of personal projects to maintain and new articles and videos to create. I don't want to take any more time from them.

I've also noticed that people appreciate the things I create on my own even more, with no challenge attached, and I love that. I have so many cool ideas, and I need to ship them before someone else does.

Confessions of a Competition Junkie

I'm a competition junkie, though. I love the anticipation of the results and the huge spike of adrenaline and dopamine when I hear I just won. Oh god, I still remember winning those 2.

Let's recap the year real quick.

The Wins

Metal Birds Watch

Metal Birds Watch (GitHub Copilot CLI Challenge). A real-time aircraft tracker that watches the sky (using a public API) for you and notifies you when a plane flies over. It groups users into grid cells for caching, which was something that I came up with, and I'm still extremely proud of.

Check out the video:

NoteRunway

NoteRunway (Notion MCP Challenge). A cleanup crew for your Notion workspace. Seven tools hunt down duplicates, dead links, stale pages, and the API keys you swore you'd move later, and nothing destructive runs without your approval.

Check out the video:

The Losses

Sunday DEV Drive

Sunday DEV Drive (Weekend Challenge) a synthwave driving game where your DEV articles become neon billboards along an endless road. Enter a username and cruise past your own titles and quotes. I built it in a weekend with Three.js and no build tools, and the car is made from 46 boxes.

Check out the video:

NeuralHats

NeuralHats (Gemma 4 Challenge). Six AI personas, all running locally on Gemma 4, debate any topic using Edward de Bono's Six Thinking Hats. The Blue Hat decides when the debate is over, and a seventh model writes the final report.

Check out the video:

Georgian Language Benchmark

Georgian Language Benchmark (Kaggle Benchmarking Challenge). Eight OpenAI and Anthropic models against five Georgian language tasks I wrote by hand. They understand Georgian almost perfectly. Producing it correctly is a whole different story.

Sorry, I don't have a video for this one (yet).

So 2 wins out of 5. That isn't too bad. I also entered a couple of writing challenges, but I'm not counting those, because you don't really build something new for those.

I REALLY wanted to make it 3 wins this year, but as they say, you can't win them all. Sometimes you need to lose to adjust your approach and style.

Not Done Yet, Haven't Even Started

Am I done with challenges for good? Oh, no! I'm not going anywhere. I'm just getting started.

The moment I hear about a hackathon where I can build something really good, I'm in, guaranteed. And I'm going for that win with all I've got, down to the last ounce of energy. There's no other way for me to do things.

But for 2026, the engines are off, but only for hackathons.
Other than that, I'm going to be even more productive. I still have a few projects and articles to create.

And for those of you who follow me closely, you're in for a treat. I'm cooking up a few good things. Stay tuned.

Let's stay connected!

Scared to Publish Your First Technical Article? Don't Be. I'll Be There to Read It

Giorgi Kobaidze — Wed, 04 Nov 2026 17:11:22 +0000

⚡ In a hurry? Skip straight to the rules ⚡

Don't Make the Same Mistake I Did

I have plenty of regrets, and one of them is not starting to write my own content years ago. Better late than never, as they say, but still.

I want to make sure you don't make the same mistake. Every week I see more people joining this amazing community, and it reminds me how excited I was when I first signed up back in 2018. (If you're curious how I ended up here, I wrote about it in my previous article.)

Back then, I thought writing was only for seasoned veterans. I couldn't have been more wrong. I know plenty of engineers with years of experience who still can't write a single technical article. Not because they have nothing to say, but because they never tried.

Time to Take the Leap

Trust me, you don't need decades of experience. You're fine.

Your first article will probably feel tricky, awkward and hard. Speaking from experience, though, it gets so much easier after that. And your first one will always be special, no matter how good or bad it turns out. You might cringe at it in a year or two, but that's a special kind of cringe. It's proof of how far you've come a long way since then.

Not Sure What to Write About?

You don't need a groundbreaking idea. Some of the best first articles are simple:

A bug that took you way too long to fix, and what finally solved it
Something you learned this week that you wish you'd known earlier
How you got into programming
A small project you built, even if nobody uses it
A concept that finally clicked for you, explained the way you wish someone had explained it to you

And so many other ideas that you can think of.

If it was interesting to you, it'll be interesting to someone else.

✍️ The Rules

Alright, I'm going to be your first reader.

👉 Write your first article on DEV. Any topic, any length. Short is perfectly fine.
👉 Drop the link in the comments.
👉 Optional: tell me what finally made you hit "Publish".

I'll read EVERY SINGLE ONE OF THEM and give you honest, thorough feedback. I promise! 🤝 I always deliver whatever I promise.

One small request: write it yourself. Use AI to check your grammar if you like, but the voice and the story should be yours. That's what makes a first article worth reading.

Already a Writer? You're Invited Too

If you've been writing for a while, drop a link to your very first article in the comments, or share one piece of advice you wish someone had given you before you published it. Nothing calms first-time nerves like seeing that everyone started somewhere.

The Hall of Fame Is Waiting

A few weeks ago, I asked you to share the article you're most proud of, and it turned into the DEV Hall of Fame: 65 authors, 65 masterpieces. If you start now, your work could earn a spot when I put together the next volume.

Let's get the journey started! 🚀

Let's stay connected!

Doors I Walked Through to Reach DEV

Giorgi Kobaidze — Mon, 26 Oct 2026 16:46:19 +0000

Knock, Knock: The First Domino
The Numbers and a Plot Twist
How Did I End Up Here?
Door #1: Let Go for Being Too Good
Door #2: The Interview I Tried to Write in C++
Door #3: The Call
Door #4: The Community I Didn't Know I Needed
Door #5: The Register Button
The Door I'm Standing In Now

Knock, Knock: The First Domino

A few months ago, my DEV buddy @francistrdev invited me to join DEVengers. Of course, I accepted. It's a great team full of cool folks, they're all stars and it's a real honor to be among them.

The thing is, a team like this only stays alive if people keep showing up and writing. This is my first post under DEVengers, so I wanted it to be special: easy to read, but with some depth. Consider it the first domino. I'm knocking it over, and I fully expect the rest of the team to follow. (No pressure, folks.)

The Numbers and a Plot Twist

So here I am: thousands of followers, almost 50 articles, 2 hackathon wins, 6 Top 7 of the Week features, and that's only scratching the surface of what I've accomplished since I joined this amazing community.

You might think I've been creating content here for years. Nuh-uh. It's been just a year and a half since I started writing for real.

Here's the twist: I first heard about DEV back in 2017. Yes, some of you were probably still in high school. That was also around the time I started my professional software engineering career. A year later, in 2018, I registered.

So basically I bought the ticket in 2018 and boarded the train seven years later.

How Did I End Up Here?

To be honest, there's no funny story about how I discovered DEV. No viral post, no friend or colleague dragging me in.

So instead, I'm going to do what Ted Mosby did in How I Met Your Mother TV show. He sat his kids down to tell them how he met their mother, and ended up telling them his entire life story first.

So grab a seat, fellow devs. This is the story of how I met DEV, and all the doors I had to go through before I finally stepped through this one.

Don't worry, though. Unlike Ted, I promise it won't take nine seasons.

Door #1: Let Go for Being Too Good

Before I landed my first job as a junior software engineer, I worked in network and IT support while studying at university.

Yeah, that's the reality in my home country. You can't just focus on your studies and then glide smoothly into a job. Most students are broke as hell, and I definitely was one of them. Even with a job, I barely had enough money for public transport and food.

At first, the job was fine. It paid (a little), and it left me enough time for my studies. But the longer I stayed, the more I realized how much I hated it. I still performed like crazy, because that's just who I am. I don't know how to do things halfway, even things I can't stand.

And then I was let go. The reason? I was "overqualified", according to the CEO, or whatever he called himself.

Back then, I was angry and stressed. In hindsight, maybe he was right. And to be honest, I'm glad he did that, because that's what finally pushed me toward the software engineering job I'd been dreaming about. The last thing I wanted was to get stuck there.

Turns out, sometimes a door opens because someone kicks you out of another one.

Door #2: The Interview I Tried to Write in C++

A cold winter day. I'm sitting in a university building, not much warmer than the street outside, pretending to be a student. Well, technically I was a student, just not at that building of the university.

I was there because the building was close to the office where I had an interview and a coding assignment. And me being me, I showed up almost an hour early. It was freezing, and I didn't have the money to sit in a McDonald's, so the university building became my shelter. At least my brain wouldn't freeze. I was going to need it.

I was nervous as hell. Being a junior developer trying to break into the industry is brutal. You know you're not that good, and you're convinced everyone expects you to be great. It's nerve-wracking.

Then it was time. I walked into the office, and they pointed me to a desk where I'd spend the next hour and a half or so solving five coding problems.

In C#...

I didn't even know how to declare a property in C#. Then I saw something like this:

public int Total { get; set; }

I figured it had something to do with getters and setters. I knew getters and setters... but in C++, where you write them out explicitly. What on earth was this?!

"Alright, Giorgi, that's it. It's over. It's all over, there goes your hopes of becoming a developer" I thought.

I was close to giving up. Instead, I worked up the courage to interrupt my future co-workers, who were clearly busy with their own work:

"Umm... excuse me. I know this is C#, and I have some basic knowledge of it, but most of my classes were in C++. Can I possibly write the solutions in C++?"

You can't imagine my relief when they said the language didn't matter. Oh god.

I solved four of the five problems, clean. I couldn't get the fifth one running, but I explained my approach and they seemed fine with it.

I walked out of that office completely drained. I was sure they'd never call me back, and I was already looking at other companies.

Door #3: The Call

About a week later, my phone rang.

-"Hello?"
-"Hello. Is this Giorgi?"
-"Yes?"
-"You completed an assignment at our company. If you're still interested, we'd really like to talk to you. Could you come to our office?"

They wanted to meet me in person. That could only mean one thing: they were interested. If it were a rejection, they'd have just told me over the phone. I was so hyped.

I went in, we talked everything through, and they offered me a salary that was even lower than what I'd made at my previous job.

BUT WHO CARED?

I would've taken even less. A whole ocean of the industry was waiting behind that door, with SO MANY OPPORTUNITIES and I'd have walked through it. That's exactly what I needed - the opportunities.

I left the meeting and immediately called my mom. What I said to her is what I now call the turning point of my life:

"Hey Mom, your son is officially a software engineer. How cool is that?"

Door #4: The Community I Didn't Know I Needed

The first few months were extremely tough. My goal was to make software engineering part of who I was and to be good at everything. That stressed me out. Not the hard work itself, but the constant feeling that I wasn't as good as I wanted to be. I was decent, but I wanted to be much, much better, which is impossible with just a few months of experience. You can only do so much in that time.

I didn't really have friends to share that stress with, since I was fully dedicated to work (well I don't really have dozens of friends even now, but I don't really care to be honest), my only escape was a few hours of gaming on weekends.

The only developer community I knew back then was Stack Overflow, which, as you can imagine, is famously the friendliest place on the internet, especially for juniors... this is sarcasm, by the way.

I was looking for somewhere I could find people with the same struggles, read good technical articles, and feel like I wasn't the only one in this madness.

I can't recall exactly how I found DEV or which article brought me there, but I remember how fascinated I was. People discussed topics without trying to prove they were better than everyone else. No attitude. Just a welcoming place. I found so many interesting articles and great authors. It was like finding treasure. One Saturday, I spent the entire day at my laptop, reading article after article.

"That's exactly what I need in my life", I thought.

Door #5: The Register Button

I didn't feel worthy of registering, let alone writing a comment, and an article was completely out of the question. I thought that was something only seasoned masters did.

I was so wrong.

Finally, sometime in 2018, I registered, thinking I might join a discussion or two. I'd occasionally send articles to my coworkers, and they loved them too. That's when DEV became my go-to place for reading whenever I had some free time.

Back then, I set myself a long-term goal: to become one of the best writers on this platform. Maybe in ten years or so.

The Door I'm Standing In Now

I can't call myself one of the best here. The competition is way too strong. But I think my 21-year-old self would be proud. I finally learned to write about my personal projects, tech analysis, AI, career, everything, and to inspire others to grind more, build more, and show their work to the world.

Truth be told, I'm doing all this for that young fella who was almost too anxious to ask if he could solve the problems in C++ instead of C#, and too broke to sit in a McDonald's to warm up on a freezing winter day.

And boy, am I just getting started.

And that, fellow devs, is how I met the DEV Community.

Let's stay connected!

The DEVengers Have Unfinished Business

They were scattered across the world, their names whispered only in legend, until the day the darkness returned and the DEVengers answered.

I Earned a Seat at GitHub Universe. It'll Stay Empty, and That's Not Fair

Giorgi Kobaidze — Sun, 25 Oct 2026 06:44:20 +0000

Why Am I Writing This?

I'm writing this to show how unfair the world we live in can be, sometimes ridiculously so.

This isn't the first time I've faced unfairness. It's happened more times than I can count, and by now I'm mostly numb to it. I don't really feel sad or angry anymore. I just keep going.

So this write-up isn't really for me. It's for people who are just starting out, or who aren't used to doing everything they possibly can, and even more, and still not getting what they deserve. I've seen so many people give up on their careers, their job searches, and their dreams because of moments like this. I was lucky to be resilient and stubborn enough not to let them break me.

The Best Prize I'll Never Use

Back in March, I won the biggest competition of my life, a challenge held by GitHub. I built Metal Birds Watch, an app I'm absolutely proud of. It's in maintenance mode right now, but it'll be back soon.

GitHub Copilot CLI Challenge Submission

Giorgi Kobaidze

Feb 13

Metal Birds Watch: Copilot CLI Helped Me Watch Planes Without Looking Up

#devchallenge #githubchallenge #cli #githubcopilot

11 min read

I still don't know how I finished it. I was in severe pain the entire time. My neck, shoulder, and arm were absolutely killing me, and I could barely sit up straight. It was literal hell. But I pushed through and shipped it anyway.

So you can imagine how it felt to hear I'd won. And the prizes were amazing.

One of them was a one-year GitHub Copilot Pro+ subscription. I already had one, so GitHub offered me a very generous voucher for their shop instead. I asked them to donate that money to charity. It's the biggest charitable contribution I'd ever made, and I'm really proud of it.

The other prize was a ticket to GitHub Universe, the one I was looking forward to most.

Everything was going great.

The Reason I Had Zero Control Over

That lasted until a month or two ago, when I found out I wouldn't be able to attend. The reason is absolutely ridiculous. Sometimes I catch myself laughing hysterically at the sheer level of this utter BS. But the world is a weird place right now. A very, very weird place.

I won't go into the exact reasons, but remember this: where you are in the world matters, especially at this point in history. It can affect your career, your life, everything. Don't be naive about it. No matter how successful you are, how good you are, or whether you do literally everything right, external factors don't give a damn.

A Precious Ticket Gone to Waste

One more thing I'm really annoyed about: the ticket is going to waste, and nobody can use it. I reached out to GitHub twice to ask whether I could transfer it to someone else, but I haven't heard back. I get it, they have a massive conference to run, so they're too busy to respond my emails, but still, I would've loved to give it to someone and make their day. It is what it is. I'm still infinitely grateful to GitHub for what they have done, I love you folks!

So What Now?

Nothing, really. Like I said, it's bad, but I've been through much worse, and I can handle this. I have way too much on my plate anyway, so I don't even have time to dwell on it.

For me, knowing I gave it everything I had, and more, is enough. Regretting that you didn't give it your all would feel far worse than this nonsense.

This write-up is mainly for people who give up the moment something doesn't go their way. Be stubborn. Focus on what you can control. Play the long game. You might lose a round, but that doesn't mean you've lost the match.

That's what I've always done, and it played out pretty well for me. So I'm just going to keep doing it. I might get things the hard way, but one way or another, I'll get them. I've lost rounds before. I've never lost the match.

The seat stays empty this year. It won't stay empty forever. I promise you that.

Let's stay connected!

Promise Delivered: Welcome to the DEV Hall of Fame (65 Authors, 65 Masterpieces)

Giorgi Kobaidze — Sun, 18 Oct 2026 10:55:38 +0000

Status: Promise delivered ✅

The Doors Are Open

A little over a month ago, I published this:

Community members share hidden gem posts

Giorgi Kobaidze

Sep 10

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

#discuss #community #showdev #writing

118

265

2 min read

The deal was simple. You pick the one article you're most proud of, not the one with the most reactions, the one you love the most. I read it and give you my honest feedback.

I expected maybe 15 or 20 replies. The thread ended up with over 250 comments.

Was it tough? Absolutely. There were evenings when my eyes desperately asked me to stop. But I read every single one.

That post had a second promise hidden at the very end: "Let's build a hall of fame of DEV's best work!"

So here it is.

Every article below was chosen by the person who wrote it. Not by an algorithm, not by a reactions count, not by me. By the author.

📌 A quick note: A few of you shared articles hosted outside DEV. I read them, but I haven't included them here. This hall only features articles published on DEV, because I can't vouch for external links, and I don't want to send readers somewhere I can't verify is safe.

Visitor Stats 📊

Before the tour starts, a few numbers:

65 authors, 65 masterpieces.
600+ minutes of listed reading time. That's over 10 hours, and in reality it was much more, because listed reading time is a polite lie.
The longest read: 68 minutes. It took me closer to 100.
The shortest read: 1 minute.
The oldest exhibit: published in March 2020.
The most reactions: 623.
Zero reactions: 8 articles had none when I collected them. Zero! That's exactly why this hall exists.

How to Tour the Hall

The exhibits are grouped into wings by theme, so you can head straight to whatever interests you most. Each exhibit has the article itself, why the author picked it (when they told me), and my take.

🚪 The Welcome Desk: where every visitor should start
🏛️ Stories From the Trenches: careers, first steps, and the people behind the code
💡 The "Finally, It Clicked" Gallery: fundamentals explained the way they should be
⚙️ The Engine Room: systems, internals, and seriously deep dives
🤖 The AI Lab: building with AI, and finding out where it breaks
🧠 The Philosophy Floor: thinking about AI, engineering, and the craft itself
🔧 The Builder's Garage: real tools solving real problems

Grab a coffee. It's a big building.

🚪 The Welcome Desk

FrancisTRDev

FrancisTRᴅᴇᴠ

Mar 20

Get Started on Dev.to! A Beginner's Guide to Engage with the Community! 💡

#discuss #community #beginners #howtodevto

301

229

7 min read

Why they picked it: It made it onto DEV's official community resources page and earned a badge for it.

My take: If I'd had something like this when I first joined DEV, I'd have been a lot more active from day one. It's the perfect first stop for anyone new here, which is exactly why it's the first stop of this tour.

🏛️ Stories From the Trenches

Earl Grey

May 19

A Builder in Paris: Do Devs Dream of Électrique Chats?

#buildinpublic #ai #hackathon #learning

7 min read

Why they picked it: Written after walking away from the computer on vacation and realizing there was an idea worth coming back to.

My take: I loved this one from the first few sentences, because it mentions rainy, cold days, and those are my favorite. That's when I feel most alive. It also reminded me of my own work-to-travel switch: a few hours before a flight, I recorded a 20-minute video, only to find out it had no sound at all. Sometimes the best thing you can do for your work is step away from it.

Hadil Ben Abdallah

Dec 25 '25

Coding Without Pressure: How Slowing Down Helped Me Learn Faster

#webdev #productivity #programming #codenewbie

325

3 min read

Why they picked it: So many people related to it, and it got over 13K views in less than 3 days.

My take: It's brief, but it's packed with painfully relatable stuff. As a junior engineer, I tried to learn everything by heart, because I thought that's how real developers worked. Then reality punched me in the face. Just consuming information is pretending to progress. Real progress comes when you're in motion, with 10 bugs to fix and zero clue how, and you still have to figure it out.

Ali Navidi

Nov 21 '24

A Letter to Jobseekers: Don't Give Up!

#mentalhealth #programming #motivation #career

2 min read

My take: Relatable for pretty much everyone in a field that can be way too tough and unforgiving. I've had my own share of rock bottom, which back then felt like the end of my career. Looking back, I'd never have achieved half of what I have without it. Learning to turn bad situations to your advantage is a superpower.

alptekin I.

Jan 23 '25

Dreams & Cheers

#devchallenge #newyearchallenge #career

4 min read

Why they picked it: It's kind of his first post, and it's about dreams that are still waiting to be fulfilled.

My take: The key quote: "I feel I do not belong there, but it is too late..." You don't know what's behind the door until you step inside. I admire anyone with the courage to stick around where they "don't belong", only to find out it's their natural habitat.

Cesar Aguirre

WeCoded 2026: Echoes of Experience 💜

Cesar Aguirre

Mar 23

The Most Painful Career Lesson My Best Job Taught Me

#devchallenge #wecoded #dei #career

3 min read

My take: I love that someone picked an article titled "The Most Painful Career Lesson My Best Job Taught Me" as their favorite. It shows you're not trying to forget bad experiences, you embrace them. Not everyone can do that. The more experience you gain, the more you realize there's no such thing as a bad experience in a career. Bad ones teach you far more than good ones.

The Lazy Girl

𝐓𝐡𝐞 𝐋𝐚𝐳𝐲 𝐆𝐢𝐫𝐥

Aug 9

The Code That Started It All !

#discuss #programming #beginners #community

2 min read

My take: What a story! Everyone's story of how they started programming is special, but some are more special than others. As a fellow gamer, engineer, and introvert, I related to a lot of it. For the record, my own first software code was in C++, 20 years ago, in Borland C++. I was 11. Simpler times.

Dhruv Jani

Readers debate underrated tech stacks

Dhruv Jani

Sep 1

The Stack Nobody Picks Might Be the One That Picks You

#discuss #csharp #devjournal #career

5 min read

My take: As a .NET developer with C# as my primary language for 10 years, this one hit home. Would I pick a different stack if I could go back? Absolutely NOT! Web apps, desktop apps, games, mobile apps, back-end services, you name it. Learn one language, and you can build almost anything. And as long as there are enough jobs out there, you only need one.

Puneet Kumar

Comments suggest adding social logins

Puneet Kumar Mishra

Aug 6

I Built the Product. Made It Open Source. Deployed It Cheaply. Then... 7 Users Signed Up.

#discuss #buildinpublic #opensource #indiehack

2 min read

My take: I totally understand the frustration. No matter how great your project is, without backing or marketing it rarely takes off right away. That's not a reason to give up, it's learning material: get to know your audience, understand the demand, and try again. Every failure is a lesson in disguise.

Sameer Qaiser

Sep 11

If-Else Statements: When I Finally Got It

#python #beginners #programming

1 min read

Why they picked it: It's his very first article, and he almost didn't publish it.

My take: If-else is the cornerstone of pretty much every programming language, so it definitely deserves an article of its own. And the fact that you almost didn't publish it makes me even happier that you did.

💡 The "Finally, It Clicked" Gallery

GrahamTheDev

Jul 30 '21

101 Digital Accessibility (a11y) tips and tricks

#webdev #html #a11y #beginners

626

68 min read

Why they picked it: He threatened to give me a quiz afterwards. 😜

My take: Coming from a back-end background, my accessibility strategy used to be trusting that whoever writes the frontend knows what they're doing. Turns out that's not a strategy, it's a prayer. What I appreciate most is that this isn't a compliance checklist, every point explains who it actually helps and why. It's listed at 68 minutes. It took me closer to 100. Worth every one of them.

Gaurang

Mar 15 '20

Do you really understand interfaces?

#java #oop #beginners #codenewbie

8 min read

Why they picked it: His first published piece, written entirely from scratch before the age of AI, with over a month of fine-tuning and a self-made cover.

My take: Interfaces are a huge deal in .NET, so this one was right up my alley. A class doesn't inherit from an interface, it implements it, and that difference is gigantic. Months into my first job, I still didn't get why we needed interfaces at all. Every tutorial said "loose coupling is good." Sure, but WHY? This article answers exactly that. And the "Badass Prince" badge analogy cracked me up. One of the best in the whole thread. 🔥

Tejas Shinkar

Jul 28

AWS VPC From Scratch: Building Your Own Private Network Inside AWS

#aws #cloud #devops #networking

21 min read

Why they picked it: He gave up on the topic the first time, then went back and learned networking fundamentals from scratch just to understand why any of it worked.

My take: One of the most useful and practical articles I've read in a while. As someone who uses AWS frequently, it's easy to forget the details over time, and this is a great refresher on how VPCs, subnets, security groups, and NACLs fit together. The analogies make it all stick.

Lawrence Cooke

Jul 30 '23

SQL Common Table Expressions and Window functions

#sql #mysql #database #datascience

7 min read

Why they picked it: His first real dip into tech writing, and he spent the time digging into the database to make sure everything he wrote was fact.

My take: I love how the query is built step by step, verifying each CTE on its own before putting everything together. That's exactly how complex reporting queries should be approached. The recursive CTE for filling in missing dates is a neat trick, and the named WINDOW clause doesn't get mentioned nearly enough.

Suprie

Sep 11

Idempotency: Protecting User Intent Beyond the Buy Button

#mobile #idempotency #ios

3 min read

My take: I really like the framing of idempotency as protecting the user's intent, and the point that it's an end-to-end contract, not just a back-end concern. As a back-end engineer, I can tell you it's one of the most overlooked concepts out there.

Abhishek Kumar Dutta

Jun 30

Why Your Call Stack Is Silently Freezing Your UI

#javascript #softwareengineering #technicalleadership #frontendarchitecture

7 min read

Why they picked it: His first article.

My take: The first one always remains special. I feel the same way about my own first article. A great start, and a topic every developer runs into sooner or later.

Caleb Weeks

Oct 20 '21

Haskell Quicksort in JavaScript

#haskell #javascript #functional

3 min read

Why they picked it: His first DEV post, and still his most read one by far.

My take: A fun read, and a clever use of the algorithm as a vehicle for explaining Haskell syntax rather than the other way round. Coming from C#, the same shape falls out of LINQ almost unchanged.

CitronBrick

Jun 13 '22

ES5 Class based React Components

#react #ie11 #tutorial

2 min read

Why they picked it: It's still the only article of its kind on the web that they could find.

My take: This brought back memories of the days when supporting IE11 was part of everyday work. It's also a great look at what's happening under the hood of React class components, something most of us never think about now that ES6 classes and hooks handle it for us.

Shwetha

Aug 6

Fixing your site's metadata: a practical checklist

#webdev #seo #metadata

6 min read

My take: This is so important to keep in mind. I've been there too, and it's painful to watch the preview of your project doing funny things on different websites and apps. A very practical guide.

DevOps Daily

Aug 28

Practice Linux, Docker and kubectl in Your Browser, No VM Required

#linux #docker #kubernetes #beginners

5 min read

My take: I love the idea of learning Linux, Docker, and Kubernetes in order, with each stage building on the previous one. The observation that get is basically ls and describe is a verbose cat makes kubectl feel much less intimidating. And removing the setup hassle is a big deal, that's where many beginners give up before typing their first command.

EffessDev

Aug 28

ESP-IDF Bluetooth LE (BLE) Beginner Tutorial

#tutorial #iot #esp32 #education

9 min read

Why they picked it: It took the longest to write. They also asked whether I really meant I'd read every single one, because they'd never do that. "Too risky." Well... 😄

My take: Solid tutorial. You build the program up piece by piece instead of dropping a finished file on the reader, and the short asides on macros and error codes fit naturally without derailing the flow. The UUID section is the highlight. The one thing I'd add is what happens after the phone disconnects, since that's usually where a first BLE project stops behaving as expected.

Dylan Scott Mickelson

Sep 12

Creating Adaptive Flutter Screens and Widgets

#flutter #dart #opensource #uidesign

5 min read

My take: A nice package and a clear tutorial. I like that it adapts the composition, not just the size: a list on mobile, a grid on tablet, and side navigation on desktop. The explicit width override for testing exact breakpoints is a really thoughtful touch.

4thwithme

Aug 30

A/B testing: the stat-sig problem

#statistics #abtesting #datascience #career

14 min read

My take: A great breakdown. A/B testing looks simple right up until the statistics enter the room, and this one tackles exactly that part.

⚙️ The Engine Room

UnitBuilds

Self-healing OS running in CPU L3 cache

UnitBuilds for UnitBuilds CC

Jun 28

V.E.L.O.C.I.T.Y.-OS: Kimi K2.7 and the 'Safe-Room Security' Illusion (Part 1)

#showdev #coding #compilers #security

4 min read

Why they picked it: It's where his two longest-running projects, an IDE and a single address space OS, all started.

My take: A bare-metal, self-healing OS is a really creative goal. As a teenager, I always wanted to build my own operating system, then reality hit. The most interesting part is Kimi optimizing for correctness against the spec, a great illustration of how much the unstated context matters with these models. One thing worth flagging: in edge cases, that self-correction loop could get expensive, since it works a lot like the agentic loops that keep cycling until they verify the goal.

Omar Afifi

Sep 9

My Phone Broke, and Gemini Fixed It

#android #gemini #googleai #debugging

8 min read

Why they picked it: After an all-nighter, an accidental ADB command triggered an undocumented debug overlay that survived reboots. Instead of factory resetting, he reverse-engineered the phone's UI bytecode with Gemini.

My take: Seriously impressive, both in storytelling and in technical explanation. From the first lines, I had to know what was causing that stubborn red text. It reminded me of my own all-nighters spent hunting one silly problem. Our job is tough, but it's so rewarding. And a massive "W" for Gemini!

Yash Kumar Saini

Three silent bugs caught by loopback testing

Yash Kumar Saini

Jul 13

Adding WebRTC to py-libp2p: Two Runtimes, Three Specs, and One Unforgiving Private Slot

#libp2p #webrtc #python #networking

19 min read

Why they picked it: He shipped a core feature into an open-source project, working closely with the core team, the maintainers, and a mentor.

My take: Deep enough that I had to research a few concepts to follow it properly. Trio, SCTP framing, and the whole certhash mechanism were new territory for me, and it was worth the detour. I also appreciated the honesty about scope, saying plainly that this advances the issue without closing it. Preserving the trade-offs as they actually came up in review is what makes it worth the effort.

Gagandeep Singh Ahuja

Jul 4

Building SaarDB, Part 1: Write-Ahead Log (WAL)

#computerscience #database #go #tutorial

12 min read

Why they picked it: He was always curious about database internals, so he started building his own.

My take: Each problem motivates the next piece: volatility, write ordering, record framing, partial writes, corruption, fsync. It makes the design feel inevitable rather than arbitrary, which is hard to pull off in a storage-engine write-up. The write-order section is almost word for word the cache-aside rule, durable store first, cache second. Nice to see the same argument show up a layer down.

Mike Talbot

Mike Talbot ⭐

Jun 19 '20

A SOLID framework - Inversion of Control Pt 1

#showdev #javascript #react #tutorial

17 min read

Why they picked it: He's built the entire architecture of multiple projects on this model, because it lets teams (and AI agents) work in parallel. As a bonus, it includes a game, fully playable inside the article.

My take: When someone says "inversion of control" to a C# developer, nine times out of ten they mean constructor injection and a container. What this article inverts is something bigger: who decides what happens next. I also appreciated that it doesn't force Liskov to fit, admitting one principle is a stretch made me trust the rest more. Nice game too! 🎮

Peter Vivo

April Fools Challenge Submission ☕️🤡

Peter Vivo

Apr 12

M||D||JS = MorDorJS

#showdev #devchallenge #418challenge #javascript

10 min read

Why they picked it: It's the mordor-project and MordorJS, a file format and a one-dimensional programming language.

My take: Congratulations, sir, this thing broke my mind. In a good way, though. I've never seen anything like it.

Sylwia Laskowska

Practical WebGPU and WebAssembly performance

Sylwia Laskowska

Apr 16

Most Apps Are Slower Than They Need to Be — Here’s Why (Live Demo🛸)

#javascript #react #webassembly #webgpu

130

5 min read

Why they picked it: If not her best one, then definitely her most "groundbreaking" one.

My take: A great demo, and a fun one to play with. Going from around 40K particles on Canvas 2D to over 500K on WebGPU shows the difference between optimizing a path and choosing a better one. Coming from the back end, the idea of moving real load from the server to the client was the most interesting part for me. It also reminded me how far Blazor WebAssembly has come in bringing C# into the browser.

Elanat Framework

Sep 11

Great News for the Rust Community: A New Server-Driven UI Technology in Rust

#news #rust #actix #webformscore

7 min read

Why they picked it: It shows the power of WebForms Core, and they challenge you to write an equivalent of the example yourself.

My take: The Actix example is easy to follow end to end, and I like that the HTML stays plain HTML. I'm curious whether a more typed builder API is on the roadmap, since string criteria let a typo compile and only show up at runtime. I'd also love to see an example with validation or permission-based UI, because that's where this model seems strongest.

Dimitrios Desyllas

Jun 16 '23

How to make a batch process that emails big CSV (~1-2 Mbytes) from complex unoptimized queries using laravel.

#howto #php #laravel

2 min read

Why they picked it: It points in the direction he wants to follow professionally.

My take: A solid approach. Sending a link instead of an attachment and writing the file row by row is the right way to handle this. One thing worth knowing: on MySQL, PDO buffers the whole result set by default, so you'll want to turn that off or the memory savings won't materialize.

Harsh Sengar

Sep 15

Why Your D365 F&O Automation Breaks: The Hidden Logic Behind TargetId and RootId

#dynamics365 #webdev #testing #automation

4 min read

Why they picked it: His first and only article, shared to inspire others.

My take: A great first post. This is exactly the kind of hard-won, practical knowledge that's tough to find in official docs, and the detail that Post validates stale IDs while Save doesn't is really interesting. Niche topics like D365 F&O need more writers like this. Keep writing, don't stop at one!

Ashley Childress

Summer Bug Smash: Smash Stories 🐛🛹

Ashley Childress

Jul 23

Jerry Ran Out of Numbers But Drank All the Punch

#devchallenge #bugsmash #devrel #java

9 min read

Why they picked it: One of her favorites, and she was "pretty sure" I'd appreciate this particular brand of nonsense.

My take: She was right, I did. A legacy Java service that runs out of IDs and blocks testing for weeks could have been a dry postmortem, but told as the story of Jerry, the weird uncle left alone with the punch, it's a blast. It's proof that a great bug story is half the bug and half the storytelling.

Krishna Tangudu

Sep 7

Moving Data Is Easier Than Moving Knowledge

#ai #snowflake #sap #agents

4 min read

My take: Great title, and so true. Migrations rarely fail because the data didn't move. They fail because the business logic, the ownership, and the "why" behind it got lost along the way.

Ekong Ikpe

May 24

Gnoke POC: Proof of concept

#discuss #architecture #microservices #systemdesign

2 min read

Why they picked it: His humble story, the best-compressed version of discovering who he's been. After writing it, it felt like reading a post written by someone else.

My take: I love the philosophy behind this. "Deploying 14 microservices to save a note" made me laugh, because it's painfully accurate. Complexity often looks smart from a distance, but simplicity is what survives. Good architecture starts with decomposition, not with tools.

🤖 The AI Lab

Elsie Rainee

Context matters more than raw speed

Elsie Rainee

Sep 2

I Tried Pair Programming With Three Different AI Tools For a Month

#discuss #productivity #ai #tools

8 min read

Why they picked it: A month-long comparison of Cursor, GitHub Copilot, and Claude Code on real tasks like debugging, refactoring, and multi-file changes, not toy prompts.

My take: The idea that AI shifts engineering work rather than removing it is spot on. Reviewing diffs, checking assumptions, and breaking tasks into smaller pieces have become core skills. And step 7, asking the AI to challenge its own solution, is such a simple habit, yet it catches a lot.

Dev Stack Hub

Dev Stack Hub for Dev Stack Community

Sep 2

I Let AI Design Tools Build My Portfolio Site — Clients Noticed

#discuss #ai #design #productivity

9 min read

Why they picked it: They tried different AI design tools to build their portfolio and shared what worked, what didn't, and how it changed the way clients saw their work.

My take: Extremely useful for someone like me, a back-end engineer who still doesn't have a portfolio website, partly because I want it to be so good that I never start. The title made me think clients disliked the AI-made work. Glad it turned out the other way around. And this quote is an absolute gem: "Fast generation is useful. Blind acceptance isn't."

Amit Chandra

Jul 23

I built a local-first personal AI gateway that connects 32 messaging platforms to 13 LLM providers — NeuralCleave

#showdev #python #ai #opensource

9 min read

Why they picked it: A personal AI assistant powered by the models you choose, connected to your messaging platforms, running locally to protect your privacy.

My take: A really nice concept, and I like the idea a lot. Local-first with your privacy intact is the part that sold me. Well done! 👏

Henk van Hoek

Sep 12

How I Built an Agentless Self-Hosting Orchestrator with 100+ Tested Stacks & 100% Local AI

#selfhosted #devops #docker #opensource

5 min read

Why they picked it: He's proud of what he achieved in a year and a half of developing Njord-Deploy.

My take: A great project. The "Air Traffic Control" approach stood out most to me. Forcing the model through a deterministic schema and linter loop instead of trusting raw YAML is a smart way to tame hallucinations, especially with smaller local models.

Carlo Gino Catapang

Sep 13

Add AI search to existing application

#ai #webdev #react #postgres

12 min read

Why they picked it: It marks his return to writing.

My take: Welcome back! This is one of the clearest explanations of semantic search I've read. "The AI part ends when you get the numbers back" demystifies the whole thing. As a back-end developer, I also appreciated the practical decisions: not blocking creation on the embedding call, treating embeddings as derived data, and keeping keyword search instead of replacing it.

Domenico Tenace

Domenico Tenace for Playful Programming

Jun 5

Google AI Studio: The Playground Every Developer Should Know About 🎮

#ai #programming #google #learngoogleaistudio

6 min read

Why they picked it: It didn't get much praise, but it shows how much his writing has matured, and it's about a subject that's very special to him.

My take: Testing prompts in AI Studio before hardcoding them is such an underrated habit, and the side-by-side model comparison saves a lot of guesswork when choosing between Pro and Flash. Good call highlighting that free-tier prompts may be used for training, too. Every developer should know that before using it with real data.

Prince Panchani

Unannotated tools silently bypass approval gates

Prince Panchani

Aug 30

I gave an AI agent a production rollback button — then spent the hackathon trying to trick it into pressing it

#wemakedevs #truefoundry #qodo #ai

17 min read

My take: Impressive work, and one of the most honest hackathon write-ups I've read. The idea that the approval gate protects a path, not a tool, is a great insight. And "a safety property you haven't attacked is a safety property you don't have" is a line every team building AI agents should remember.

Dani Shemesh

Sep 14

Designing agentic development workflows: what a workflow is, and what it is made of

#ai #agents #workflows #automation

16 min read

Why they picked it: They're new here, and it's the start of their series on designing agentic development workflows.

My take: A great start to the series. The point that everyone uses the same AI agent differently really resonates, and I loved the idea that workflow phases should come from your existing process, not from the tool.

Orvi Das

Aug 5

Tool Use in LLMs: What It Actually Means for Production Systems

#llmfunctioncalling #tooluse #aiagents #honeycomb

7 min read

Why they picked it: It's their personal favorite.

My take: Getting an LLM to call a tool is the easy part. The real work is everything around it: validation, reliability, and designing systems that recover when the model gets things wrong. The Honeycomb story makes it practical and relatable.

Marco

Summer Bug Smash: Smash Stories 🐛🛹

Marco

Aug 20

I wrote a test for prompt injection. It passed while the attack worked.

#devchallenge #bugsmash #security #ai

5 min read

Why they picked it: The experiment changed the way he thinks about testing, not just about prompt injection.

My take: The name-as-claim framing is the part worth keeping. A test that exercises real code but asserts the wrong property is worse than a missing one, because its name is what people read when deciding the area is already covered. Mutation testing tools like mutmut or cosmic-ray could turn that manual "revert the defense and see" check into a standing one.

Amritpal Singh

Sep 15

My RAG system's refusal threshold was having no effect. I only found out because I measured it.

#java #ai #rag #testing

6 min read

My take: Measuring before adding features is the part most people skip, and it's the only reason this bug was found at all. The title says it best.

Forrester Terry

Sep 15

26 Ways to Use Coding Agents for Non-Coding Tasks

#ai #agents #productivity #operations

14 min read

Why they picked it: He hopes it gives people ideas for using AI agents outside the standard coding and reporting.

My take: A fantastic list, and I love that the post itself is example number one! I use AI for cover images and illustrations all the time, considering I have zero talent in drawing. The Spotify listening history analysis is a brilliant idea, I really have to try it.

🧠 The Philosophy Floor

xulingfeng

Jun 3

Our CTO Guaranteed His $2.8B AI Gateway Was Safe. I Quietly Kept a Different Record. For 8 Months.

#discuss #ai #programming #career

8 min read

Why they picked it: Their personal favorite from an older series. They didn't dumb down the villain, yet it didn't get much engagement. It's also the first appearance of character P, the protagonist of their ongoing Thirty-Six Stratagems series.

My take: I started reading this outside during a few idle minutes and couldn't wait to finish it. It felt like reading an extremely good book. I knew things would go badly the moment the room applauded Drew, because all anyone had seen was a demo running on test data he prepared himself. Sometimes people look at how things appear instead of how they actually are.

Self-Correcting Systems

Jun 28

The Art of the Misconception

#discuss #ai #agents #devjournal

19 min read

Why they picked it: It didn't get much interaction, but it's the one that matters most to him.

My take: Thought-provoking. "A receipt is not an outcome" really stuck with me. Control can't depend on understanding every line of code forever, it has to come from clear boundaries: what a system can touch, who can change the checks, and where it must stop. I also appreciated that he turns the same skepticism on his own ideas.

Tariq Davis

Sep 7

Two Ways People Go With AI. Both Are Traps.

#ai #writing #mentalhealth #productivity

8 min read

Why they picked it: His best work so far, and a vulnerable one, written to bring awareness to AI from a less common perspective.

My take: So different from everything else I've read on this topic, almost a spiritual point of view. Being an extremist doesn't work in pretty much anything, and AI is no exception. It's a tool, a powerful one. Most people pick one side and disregard the other, and that mindset stops you from taking the best of both.

Paulo Henrique

Paulo H. Alkmin

Jul 21

Generative AI is a gacha game with no pity system

#ai #programming #design

6 min read

Why they picked it: He doesn't know why it got so few views.

My take: Neither do I, it absolutely deserves more. The metaphor does real work instead of just sitting in the title, and "retries are only cheap on the invoice" is the line that'll stick with me. Everyone argues about price per generation, nobody counts the human judgment on top, which is the one thing you can't parallelize.

Sergiy Yevtushenko

Jul 22

Software's Second Free Lunch

#softwareengineering #architecture #softwaredesign #programming

6 min read

My take: The parallel with Herb Sutter's "The Free Lunch Is Over" is spot on. Adding more people, or more AI agents, doesn't help much if the work itself is tightly coupled.

Marco Sbragi

Sep 6

Is History Repeating Itself? From the PC Era to the AI Era: A Developer’s Take on the Hype and Healthy Skepticism

#discuss #ai #softwareengineering #career

6 min read

Why they picked it: It landed him in the top 7 of the week, a snapshot of everything he's witnessed, from the PC era to AI.

My take: One of the best articles I've read here in a while. Engineers aren't going anywhere: the job changes, but you can't build on non-deterministic output and rely on it completely. Saying engineering is just producing characters is like saying an F1 driver just turns a wheel and presses pedals. And speaking of F1, my favorite sport, the analogy of F1 engineers and trucks in medieval streets made complete sense.

Michael Krupnyak

Sep 23

Experimental RecurseWright: Engineering on Moving Ground, and Other Pretty Problems with Stability

#discuss #ai #architecture #recursewright

65 min read

My take: What a thoughtful read. The capybara story was my favorite part. "Where is the rule?" is such a simple question, yet it captures a mistake many of us make: treating a real observation as proof of a conclusion it doesn't actually support.

Sal Parvez

Sal Parvez | ML Systems RI

Sep 14

MVE: The Balance in MVP

#startup #ai #architecture #systemdesign

4 min read

Why they picked it: MVP means two things, Most Valuable Player and Minimum Viable Product, and they pull apart. The piece names the balance: MVE, Minimum Viable Expense.

My take: The ring-shank nail is the best part: cut it and you keep both the rafter and the sheet, pull it and you keep one. The point lands before the paragraph even ends.

🔧 The Builder's Garage

nyaomaru

Real-world scale for type safety

nyaomaru

Aug 12

is-kit Reached 50 Stars ⭐ Here’s How We Use It in Production

#typescript #opensource #webdev #frontend

7 min read

Why they picked it: It shows how their open-source library is used in a real production system serving over 100,000 users.

My take: A really interesting and fun project. Keep it maintained! And congrats on blowing past 50 stars, it was already at 77 when I read it. ⭐

CanWeShip

Sep 12

USPS can charge you $50 after the package ships. I built a free checker to catch it before you buy the label

#showdev #node #webdev #api

4 min read

Why they picked it: Their first ShowDEV, half research rabbit hole, half build story.

My take: I had no idea USPS could charge a fee weeks after delivery, and the fact that the official documents contradict each other makes a tool like this even more valuable. I really like the decision to keep AI out of the actual verdicts. When money is on the line, a traceable answer beats a confident guess every time.

Tanay Dwivedi

Jun 20

I developed an App that can k!ll you.

#webdev #javascript #opensource #web

2 min read

Why they picked it: He learned many new concepts while building it.

My take: The scariest title in the entire hall. My first reaction was "what the hell?" 😄 Don't worry, there's nothing disturbing inside, just a fun idea.

Son Hoang

Sep 15

We Planted 180 Bugs in Copies of Real Open-Source Backends. Fix Your First One in About 20 Minutes

#showdev #career #backend #programming

15 min read

Why they picked it: "It ain't much, but it's honest work."

My take: It's much more than that. Navigating someone else's codebase and hunting down a bug from a vague report is the real skill gap for many developers starting a new job, and LeetCode doesn't train that at all.

Cédric Hervet

Hidden business rules break routing projects

Cédric Hervet, Ph.D.

Sep 15

Why the hard part of route optimization is the modeling, not the algorithm

#api #computerscience #algorithms #software

7 min read

Why they picked it: His very first post here, about something he's watched fail quietly for ten years: everyone benchmarks the algorithm, but most failed projects die in modeling, not solving.

My take: The three-layer split generalizes well beyond routing. "The rule nobody wrote down" is the same failure mode in any rules-driven system. A cookbook that maps named business rules to primitive compositions would probably close more of the gap than adding more primitives, and it would be a lot cheaper to ship.

Panagis Tzivras

Sep 17

The Answer You Didn't Want: Fiskardo Evacuation Routing

#opensource #gis #kefalonia #opendata

4 min read

Why they picked it: His evacuation-routing model confidently gave him an answer that was "geographically adventurous", and the model wasn't the only problem.

My take: What stuck with me is that he published the number while openly admitting one round is still unsolved. That's rare, and it makes the rest of the post far more believable than a clean ending would have. I'd love to see the actual SQL around the SRID mismatch, though.

Mārtiņš Veiss

Sep 14

The one you reported is gone. This one is still up.

#security #github #malware #opensource

4 min read

Why they picked it: It serves as a warning to the community.

My take: A great investigation and an important warning. Using a clean, legitimate interpreter to run a payload disguised as cert.txt is a clever and scary technique. With so many people installing AI skills and tools by name these days, always verify the publisher first.

TheBitForge

Read it here: From Idea to Launch: How Developers Can Build Successful Startups

My take: What a gigantic post! It's packed with practical lessons, and I really liked how honest it is about the mistakes along the way. The point that the code is often the easiest part of building a startup is something every developer-founder needs to hear. Validation, pricing, and talking to customers are where most of us struggle.

🎩Giorgi Kobaidze (yes, that's me)

GitHub Copilot CLI Challenge Submission

Giorgi Kobaidze

Feb 13

Metal Birds Watch: Copilot CLI Helped Me Watch Planes Without Looking Up

#devchallenge #githubchallenge #cli #githubcopilot

11 min read

Why I picked it: I built Metal Birds Watch for the GitHub Copilot CLI challenge, and it's still my biggest win. It made me dig deeper than any project before it, not just the code, but the maths and the geographic coordinate work behind it. It was an enormous amount of effort, and I was in bad shape for most of it. I'm still not sure how I got it finished, which is probably why I'm so attached to it.

What I Learned From Reading All of This

People pick their firsts. A surprising number of you chose your very first article. Not your most polished one, not your most popular one, your first. The one you almost didn't publish. I get it, I feel the same way about mine.

Reactions don't measure value. Eight of these articles had zero reactions when I collected them, and several of you said yours "didn't get much interaction." Some of those were among the best things I read all month. The algorithm rewards timing, audience, and luck. It doesn't reward effort, and it doesn't reward what matters to the author.

AI is everywhere, but the best AI posts are about where it breaks. Rollback buttons, prompt injection tests that pass while the attack works, RAG thresholds that do nothing. The most valuable writing wasn't "look what AI can do", it was "here's what happened when I tested it properly."

The range of this community is absurd. Operating systems, ESP32 boards, databases built from scratch, evacuation routing on a Greek island, and a Christmas-themed legacy Java horror story. All in one thread.

The Doors Will Open Again

Thank you to every single one of you who shared your work. Reading it was tough, but it was one of the most rewarding things I've done on DEV.

Now it's your turn. Pick at least one exhibit from this hall that you haven't read yet, and leave the author a comment. It takes two minutes and it might make someone's week.

And if you missed the first round, stay tuned, maybe there's a Vol. 2 coming. 🎩

Let's stay connected!

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.

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.

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:

DEV Community: Giorgi Kobaidze

Engine Off: My 2026 Hackathon Run Is Over

Two Wins and a Dangerous Habit

The Idea That Never Showed Up

But This Time It's Different

Effort Doesn't Guarantee a Win

All In or Not at All

Confessions of a Competition Junkie

The Wins

Metal Birds Watch

NoteRunway

The Losses

Sunday DEV Drive

NeuralHats

Georgian Language Benchmark

Not Done Yet, Haven't Even Started

Scared to Publish Your First Technical Article? Don't Be. I'll Be There to Read It

Don't Make the Same Mistake I Did

Time to Take the Leap

Not Sure What to Write About?

✍️ The Rules

Already a Writer? You're Invited Too

The Hall of Fame Is Waiting

Doors I Walked Through to Reach DEV

Table of Contents

Knock, Knock: The First Domino

The Numbers and a Plot Twist

How Did I End Up Here?

Door #1: Let Go for Being Too Good

Door #2: The Interview I Tried to Write in C++

Door #3: The Call

Door #4: The Community I Didn't Know I Needed

Door #5: The Register Button

The Door I'm Standing In Now

The DEVengers Have Unfinished Business

I Earned a Seat at GitHub Universe. It'll Stay Empty, and That's Not Fair

Why Am I Writing This?

The Best Prize I'll Never Use

The Reason I Had Zero Control Over

A Precious Ticket Gone to Waste

So What Now?

Promise Delivered: Welcome to the DEV Hall of Fame (65 Authors, 65 Masterpieces)

The Doors Are Open

Visitor Stats 📊

How to Tour the Hall

🚪 The Welcome Desk

🏛️ Stories From the Trenches

💡 The "Finally, It Clicked" Gallery

⚙️ The Engine Room

🤖 The AI Lab

🧠 The Philosophy Floor