dev.to top (week)

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

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

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

117

259

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

280

219

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

320

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-Kumar2010

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

623

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

127

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

127

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

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

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!

Dev Opportunity Radar #21: $500K Y Combinator Funding, Bolt Builders Week, and AI Safety Research Residency

Hemapriya Kanagala — Fri, 16 Oct 2026 17:40:16 GMT

TL;DR

Welcome back to Dev Opportunity Radar!

This is a weekly series where I share opportunities, resources, communities, and interesting finds that I come across, with the goal of helping people discover things they might otherwise miss.

This week's edition features the MATS Residency for AI safety research, Bolt Builders Week, and applications for Y Combinator's Winter 2027 Batch. I'm also sharing roadmap.sh, a resource with interactive roadmaps and learning materials to help developers figure out what to learn next.

If you're new to the series, you can browse previous editions, search past opportunities, and explore Community Finds, Reader Updates, and Resources Worth Checking Out on the Dev Opportunity Radar website. I've also written a short post about why I built it. You'll find links to both at the end of this article.

If you've discovered something through the Radar, I'd love to hear about it. Whether you applied to an opportunity, joined a community, completed a program, or found a resource you hadn't seen before, I'd be happy to feature your experience in a future 💙 Reader Updates section, with your permission.

And if you've come across an opportunity, resource, community, program, or event that deserves more attention, feel free to share it in the comments.

If I feature one of your Community Finds in a future edition, I'll always make sure to credit you. If you discovered it, that recognition belongs to you.

⚡ Quick Scan

Opportunities

Opportunity	Organization	Type	Location / Format	Deadline
MATS Residency: AI Safety Research	MATS	Research Residency	Hybrid (London, Berkeley, Washington, DC)	October 31, 2026 (AoE)
Bolt Builders Week	Bolt	Build Event & Business Contest	Online	October 20, 2026 (Contest)
Y Combinator Winter 2027 Batch	Y Combinator	Startup Accelerator & Funding	In-person (San Francisco, USA)	November 2, 2026

Resource Highlight

Resource	Why Check It Out
roadmap.sh	Community-driven, interactive roadmaps and learning resources covering developer roles and technologies, along with best practices and questions to test your knowledge.

📝 A quick note: I spend a lot of time researching and verifying every opportunity before featuring it in Dev Opportunity Radar. However, deadlines, eligibility, program details, and application requirements can change after publication. Before applying, please visit the official program page, review the latest information, and confirm that you're eligible.

🔄 Still Open From Previous Editions

Before we get into this week's opportunities, here are a few from the two most recent editions that are still accepting applications.

As the Radar has grown, there are now quite a few opportunities spread across the different editions. I used to keep all the still-open opportunities here, but I don't think repeating a long list every week makes the editions easier to read.

So I keep this section to the two most recent editions as a quick reminder of opportunities you may have missed. Older opportunities are still available on the Dev Opportunity Radar website, where you can browse the full collection and use the filters to find something specific.

I've already covered the opportunities below in detail, so I won't repeat everything here. If any of them catch your attention, you can go back to the original edition for the full overview, eligibility details, and application links.

Opportunity	Organization	Type	Format	Deadline	Featured In
Pear Prime 2027	Pear	Early-Career Program	Hybrid	January 4, 2027	Edition #19
Hacktoberfest 2026	MLH × DEV	Open Source Event	Online + In-person	October 2026	Edition #19
PayPal AI Hackathon	PayPal	AI Hackathon	Online (Worldwide)	November 13, 2026	Edition #20
ARC Prize 2026	ARC Prize	AI Competition & Research	Online / Kaggle	November 2, 2026 (Papers: November 8)	Edition #20
Coinbase Strategy, Execution & Analytics Bounty Challenge	Coinbase	Bounty Challenge	Online (US and Canada, excluding Quebec)	October 18, 2026	Edition #20

📍 This Week's Opportunities

Here are a few opportunities I came across this week that I thought were worth sharing.

📌 MATS Residency: AI Safety Research

Who it's for: Researchers, academics, engineers, and professionals from AI, machine learning, policy, governance, and related fields who want to work on AI safety research.

What it's about:

The MATS Residency is a full-time research program focused on reducing catastrophic risks from advanced AI systems. Residents pursue their own research agendas over 6 to 24 months, with access to research advisors, computing resources, and the wider MATS research community.

The program has three tracks for different research goals:

Bridge: For experienced researchers transitioning into AI safety who want to develop a body of relevant research and receive career development and placement support.
Anchor: For researchers looking for a longer-term role to pursue an independent AI safety research agenda.
Incubation: For researchers exploring new research directions or developing AI safety research organizations.

Residents receive $155,000 to $285,000 per year (gross), depending on factors such as experience, circumstances, and office location, along with benefits and research computing resources. The program is based in London, Berkeley, and Washington, DC, with a hybrid arrangement requiring residents to work in person at one of the offices for at least a third of their residency.

The program is open to researchers from a range of backgrounds. Applicants are assessed on the quality and seriousness of their proposed work, with track-specific requirements applying. The residency is full-time, although certain academics on sabbatical may be considered for part-time participation.

Format: Full-time, hybrid research residency
Duration: 6–24 months, depending on track
Locations: London, Berkeley, or Washington, DC
Compensation: $155,000–$285,000 per year, gross, plus benefits
Application Window: August 25–October 31, 2026
Intake: Winter 2027

Residency overview | Track details | Apply

📌 Bolt Builders Week

Who it's for: Builders, founders, entrepreneurs, and anyone interested in creating or growing a business using Bolt.

What it's about:

Bolt Builders Week runs from October 17 to 24, 2026, and includes a free building weekend, live sessions, and a business-building contest.

During the building weekend on October 17 and 18, all Bolt users can access GLM 5.3 Flash through the model picker without changing their plan or redeeming a code. Usage is provided in six-hour blocks, with paid plans receiving five times the free allowance per block. Standard rate limits apply, and unused allowance does not carry over.

Live sessions run from October 20 to 23, covering topics such as SEO, customer onboarding and retention, design, and branding. The schedule also includes a Q&A with Bolt co-founders Eric Simons and Albert Pai.

The contest invites participants to build a business idea into a product or use Bolt to develop an existing business. Projects must be built primarily in Bolt, and submissions must include a publicly accessible live link and a Bolt project link. A demo video is optional.

The prizes are $10,000 for first place, $5,000 for second place, and $2,500 for third place. The first-place prize also includes a one-on-one mentoring session with Bolt co-founder and CEO Eric Simons. Entries are judged equally on use of Bolt, the idea, implementation and design, and potential impact.

Format: Online building weekend, live sessions, and contest
Dates: October 17–24, 2026
Deadline: October 20, 2026
Prizes: $10,000, $5,000, and $2,500
Eligibility: Contest entrants must be at least 18 and meet the official rules

Explore Bolt Builders Week

📌 Y Combinator Winter 2027 Batch

Who it's for: Founders who are building a startup or have an idea they want to develop into a business.

What it's about: Y Combinator (YC) is accepting applications for its Winter 2027 startup funding batch. The program runs from January to March 2027 and takes place in person in San Francisco.

YC invests $500,000 in each accepted company. During the three-month program, founders work with a dedicated YC partner, attend group sessions and meetups, and get support with developing their products and raising further investment.

Startups at different stages can apply, including those that are still at the idea stage. Applications are open to startups from anywhere in the world. However, founders should be prepared to work full-time on their company during the batch, which takes place in San Francisco.

If the upcoming batch doesn't fit your timeline, YC also accepts applications for future batches through its Early Decision option.

Format: In-person startup accelerator and funding program
Batch Dates: January to March 2027
Location: San Francisco, California, USA
Investment: $500,000 per accepted company
Application Deadline: November 2, 2026, at 8 PM PT

Decision Date: Applicants who apply by the deadline will receive a decision by December 11, 2026.

Apply to Y Combinator | Learn about Early Decision

📚 Resources Worth Checking Out

Not every useful find comes with an application deadline.

Here's one resource worth checking out this week.

roadmap.sh: Developer Roadmaps and Learning Resources

Who it's for: Developers who want to learn a new technology, prepare for a role, or figure out what skills to learn next.

What it's about: roadmap.sh is a community-driven platform with roadmaps, study plans, and learning resources for different developer roles and technologies.

The roadmaps are interactive, so you can click on individual topics to explore them and find resources to learn more. There are paths for frontend, backend, DevOps, cybersecurity, AI engineering, data science, cloud, and many other areas.

Beyond roadmaps, the platform also has best practices for topics like API security and code review, along with questions to test your knowledge of technologies such as JavaScript, React, and Node.js.

You can browse the roadmaps and use them to plan your learning. The project also accepts community contributions to its roadmaps.

Format: Online learning resource
Cost: Free to access the roadmaps and resources

Explore roadmap.sh

🌟 Community Finds

One of my favorite things about this series has been seeing people share opportunities, communities, and resources that others might not have discovered otherwise.

We've had some really wonderful community finds over the last few weeks, and I honestly can't thank everyone enough for taking the time to find these opportunities, look through them, and send them my way. I know that takes time, and I appreciate every person who thinks of the Radar when they come across something they feel others might find useful 💙

This week, we weren't able to include a community find, but that's completely okay. Hopefully we'll have more wonderful finds from the community as we keep going.

So if you come across an opportunity, fellowship, grant, hackathon, conference, community, resource, or anything else you think more people should know about, please do send it my way. I love seeing what you find, and it helps make this series better for everyone.

If I feature something you shared in a future edition, I'll always make sure to credit you. If you discovered it, that recognition belongs to you.

One small request: If you're sharing an opportunity, please avoid posting raw URLs directly in the comments. DEV sometimes filters them before I get a chance to see them.

A short description alongside the link makes it much easier for me to review and potentially feature it in a future edition.

💙 Reader Updates

I'm looking forward to this section gradually growing over time, and I'd still love to hear from you.

One of my favorite parts of writing Dev Opportunity Radar has been hearing from people who discovered something they otherwise might have missed.

If you discovered an opportunity through the radar, applied to something, joined a community, attended an event, or simply found a resource you hadn't seen before, I'd genuinely love to hear about it.

You don't need to have been accepted or have a big success story to share. Sometimes simply discovering the right opportunity at the right time is already a win.

If you'd like to share an update, feel free to leave a comment on this edition. With your permission, I may feature it in a future 💙 Reader Updates section and tag you so other readers can celebrate your journey too.

I hope this section gradually becomes a place where we can celebrate those stories together, one update at a time.

👋 Until Next Friday

Before I go, I just want to say thank you.

Every week, I spend time searching for opportunities, resources, and communities that I think deserve a little more attention. But one of my favorite parts of this series isn't the research. It's seeing what happens after an edition is published.

Seeing someone discover an opportunity, apply to a program, share a resource, suggest a Community Find, or come back to tell us what they learned reminds me why I started Dev Opportunity Radar in the first place.

The goal has always been simple:

Help people discover opportunities they otherwise might have missed.

Thanks to all of you, it feels like we're doing exactly that.

Whether you've been reading since the very first edition or this is your first time here, thank you for being part of the journey. Every comment, suggestion, and shared opportunity helps make this series better than I could build on my own.

If you ever come across an opportunity, resource, event, community, or anything else you think deserves more attention, I'd love for you to share it in the comments. And if Dev Opportunity Radar helped you discover something exciting, I'd love to hear that too.

Thank you for reading, for sharing, and for helping make this our radar, not just mine.

I'll be back next Friday with more opportunities, resources, and Community Finds.

Until then, take care, and I hope you discover something amazing this week 💙

🌐 Dev Opportunity Radar Website

If this is your first time discovering the series, you can explore every edition, browse opportunities by category, discover Community Finds, and catch up on Reader Updates on the Dev Opportunity Radar website.

👉 Website

I also wrote a short post about why I built the website and the journey behind it.

👉 Website Launch Post

Have You Ever Commented on the DEV Welcome Thread?

𝐓𝐡𝐞 𝐋𝐚𝐳𝐲 𝐆𝐢𝐫𝐥 — Fri, 16 Oct 2026 16:21:53 GMT

One of my favorite things about DEV.to is the Welcome Thread!

It’s such a lovely place to meet new people, welcome newcomers, and make someone feel like they belong here.

But I’m curious…

Have you ever commented on the DEV.to Welcome Thread?

If yes, do you remember your very first comment?

Here’s mine!

Comment on Welcome Thread - v379

𝐓𝐡𝐞 𝐋𝐚𝐳𝐲 𝐆𝐢𝐫𝐥 Jun 11

New here! 👋 Lazy girl reporting for duty . Came to dev.to for reading, exploring, and collecting knowledge without leaving my comfort zone! 📚☕✨

here
And Hema reply My Comment Thanks:D

From Automation to Autonomy: Designing Coordinated AI Systems

Aonica — Fri, 16 Oct 2026 14:18:57 GMT

Modern software architecture is moving beyond isolated automation.

Traditional automation executes predefined instructions. AI-enabled systems introduce analytical capabilities that can interpret information and support decisions as conditions change.

The engineering challenge is connecting these capabilities to reliable execution mechanisms.

A Conceptual Architecture

A coordinated intelligent system can be described through six stages:

Data → AI Analysis → Decision Logic → Execution → Monitoring → Feedback

Each stage has a separate responsibility.

Data provides information for evaluation.

AI analysis identifies patterns, anomalies, and relevant signals.

Decision logic determines whether an action is permitted under predefined conditions.

Execution components perform authorized operations.

Monitoring observes system behavior.

Feedback provides information for subsequent reassessment.

Separating these responsibilities helps engineers reason about system behavior and operational boundaries.

Why AI Alone Is Not Enough

An AI model can generate useful analytical outputs, but those outputs are not automatically reliable.

A production architecture must consider input validation, permissions, execution constraints, observability, and failure handling.

For example, an AI-generated recommendation should not necessarily trigger an irreversible operation without additional checks.

The architecture must distinguish between interpreting information and authorizing actions.

Connecting Blockchain and Automation

Blockchain infrastructure can provide verifiable records, while smart contracts can execute predefined rules.

These technologies may complement AI-based analysis when their responsibilities are clearly separated.

However, blockchain records do not establish whether an external data source was accurate, and smart contracts remain vulnerable to implementation errors.

Verification, testing, and governance are essential.

Aonica as an Architectural Example

Aonica is exploring the integration of artificial intelligence, blockchain infrastructure, smart contracts, and automation within an interconnected digital ecosystem.

Its conceptual direction involves connecting analytical capabilities with rule-based execution and feedback.

The objective is coordinated infrastructure rather than disconnected technological features.

Actual reliability depends on implementation, security controls, testing, and ongoing monitoring.

Designing for Responsible Autonomy

Autonomous behavior should operate within explicit boundaries.

Useful engineering considerations include access controls, validation, logging, anomaly monitoring, recovery procedures, and human approval for sensitive actions.

The goal is not to remove people from every workflow.

It is to design systems where automation and oversight reinforce each other.

Conclusion

The next generation of intelligent systems may be defined by coordination rather than automation alone.

AI provides analytical capabilities. Decision logic establishes boundaries. Execution components perform permitted actions. Monitoring and feedback support reassessment.

When these layers are designed to work together, digital infrastructure can become more adaptive while remaining accountable.

Aonica is exploring how this architectural direction can inform the development of interconnected intelligent ecosystems.

Aonica — Building the Foundations of Intelligent Digital Systems.

What Are Your Chances of Surviving Resident Evil Based on Your Tech Job?

xulingfeng — Fri, 16 Oct 2026 07:27:22 GMT

I recently watched the new Resident Evil movie. 🎬

Watching the main character stumble from one disaster into another was absurdly funny and a little heartbreaking. But what impressed me most was his professional commitment. He is a courier, and no matter what happens around him, he never forgets the job: the package must reach its destination.

I will avoid major spoilers here. You can join this discussion even if you have not seen the movie.

But I have to say this first: the main character deserves real credit for his work ethic. He is not a trained superhero. He is an ordinary courier who takes “deliver at all costs” to its absolute limit. That level of professional commitment is genuinely admirable.

So this thought experiment is not making fun of his decision. It uses his commitment as the starting condition:

You are just as dedicated to your profession as he is to delivering that package.

You cannot resign, call in sick, close the ticket, or simply refuse the mission. You still have to do your job and move forward. Your only advantage is the way your profession has trained you to think.

This is not a serious disaster survival guide. It is just a fun career question inspired by a horror movie. 😄

The city is failing. The ticket is still open.

Then I started wondering: what if I were in his place?

I have worked in QA for 15 years. If I carried all those testing habits into an extreme situation, what would my survival rate be?

My answer is: 50%. 🎲

Not because I can fight monsters. I cannot.

My advantage is that a QA engineer rarely trusts a happy path just because somebody says it should work.

QA Might Try to Stop the Story Before It Starts 🧪

Imagine receiving this task:

Deliver the only copy of a critical item into a city that is clearly falling apart. The environment is unknown. The recipient may be offline. There is no backup route.

My first questions would be:

Who created this requirement?
Is the recipient still online?
Why is there only one copy of the critical item?
Where is the backup?
What is the rollback plan?
Why are we continuing the happy path when production is already throwing alerts everywhere?

Without the “you must be as dedicated as the protagonist” rule, the movie might end in ten minutes. I would return the ticket with this comment:

Preconditions are incomplete. The recipient is unreachable. The production environment is unstable. Release blocked.

Unfortunately, our rules say I still have to continue.

This is where testing experience might help. One strange event can be random. Two might require investigation. But when the roads, people, communications, and infrastructure all fail at the same time, a senior QA should recognize a systemic failure.

The answer is not to keep following the original route. Pause that path. Isolate the risk. Find a safer alternative. Then continue the mission.

Why Testing Skills Might Improve My Odds

I would not casually bring a strangely behaving person into my only vehicle.

That would be the survival equivalent of connecting unvalidated, high-risk input directly to the only production environment that still works.

Before entering an unfamiliar building, I would also check:

Where is the exit?
Is there a second route?
Can the door be opened from the inside?
What happens if the power fails?
Is this plan dependent on a single point of failure?

I would not assume that something is permanently dead just because it fell over once. I would also avoid putting all hope into one sample, one laboratory, one vehicle, or one person.

Fifteen years in QA has taught me at least one thing:

Every critical process without a backup is just waiting for a sufficiently unlucky day.

That is why I give myself a 50% chance.

Testing experience might help me spot danger earlier, challenge bad assumptions, and stop a broken flow. But it cannot solve fitness, luck, limited resources, or unknown biological monsters.

Fifty-fifty is already my optimistic estimate.

QA Could Also Die From QA Habits 🐛

Of course, being a tester does not automatically make someone good at survival.

Our greatest risk is the need to reproduce a bug.

I might escape safely, then suddenly stop and think:

What exactly triggered that mutation? Distance? Time? Sound? Temperature?

Then I would go back to collect logs, record a better video, and attempt a second reproduction.

Or I might reach the exit, notice one unopened door, and say:

The main flow passed. I will test one last edge case before I leave.

At that moment, my survival probability drops from 50% to 5%. 🚨

The most dangerous sentence in QA: “One last edge case.”

What About Your Tech Job? 🧑‍💻

The same rule applies to you. You bring the same admirable professional commitment that the courier brings to his delivery. You cannot end the story by saying, “Not my ticket.” You must keep doing your job while using your professional skills to stay alive.

Every tech role has a possible survival advantage and a potentially fatal professional habit.

Frontend Engineer

They quickly notice that none of the exits provide useful status feedback and the city map violates every basic UX principle.

Unfortunately, they may spend valuable time complaining that the emergency door has no hover state.

Backend Engineer

They try to identify the source of the infection chain and shut down the upstream service.

They may also believe that restarting the core system will somehow fix everything.

DevOps / SRE

They check monitoring, capacity, failover, and backup regions. They would never trust a cure deployed as a single instance.

However, while every alarm in the city is firing, they might still be deciding whether this is a real incident or a broken alert rule.

Security Engineer

They trust nobody, no attachment, and no unknown device. Their isolation instincts may be the strongest of any profession.

They may also enter the most dangerous area just to prove the full impact of a vulnerability.

Data Engineer

They build a model from infection times, locations, and behavior patterns.

First, they must accept that half the data is missing, every source uses a different format, and there is no schema documentation.

Product Manager

They ask for the goal, target user, priority, and success metric before the outbreak begins.

Then, during the evacuation, they ask whether we can add multiplayer collaboration to the MVP.

AI / Agent Engineer

They send one agent to scout ahead and another agent to review the first agent's conclusion.

The biggest risk is that both agents confidently report “Task completed successfully” while the critical package is still sitting where it started.

Your Turn 🎯

Give yourself a survival probability based on your real profession.

You can use this format in the comments:

Role:
Years of experience:
Survival probability:
My biggest professional advantage:
The professional habit most likely to get me killed:
My first survival rule:

Here is mine:

Role: QA / Test Engineer
Years of experience: 15
Survival probability: 50%
My biggest professional advantage: I do not ignore repeated anomalies or trust a single happy path
The professional habit most likely to get me killed: Going back to reproduce the bug one more time
My first survival rule: When every monitor is alerting, pause the main flow, isolate the risk, and roll back

In the ideal ending, I survive the night, preserve the logs, reproduce every critical issue, and submit this bug report:

Severity: Critical
Reproduction rate: 100%
Impact: Entire city
Recommendation: Block the release immediately

The next morning, Umbrella management replies:

Status: Rejected
Reason: Known issue. No fix planned. Does not affect core business.

Known issue. No fix planned. Apparently production can continue.

Again, this is a silly thought experiment, not an actual survival guide. 😂

And every percentage comes with one final condition: do not run into a Tyrant, Nemesis, or any of the franchise's main characters. If you are a random civilian standing next to the protagonists, your survival rate is basically zero. 😂

Now it is your turn:

If you were dropped into Resident Evil and had to rely on your professional skills, what would your survival probability be—and why?

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

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

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:

The lease application had one box I could not fill

Elisa — Wed, 14 Oct 2026 21:37:26 GMT

The apartment was fine. Two rooms, a window over a parking lot, a radiator that knocked. The application was the part that stopped me. Name, phone, current address, employer, and then a box for a Social Security number, because the landlord ran every applicant through a tenant screening service and the service wanted one.

I had an ITIN. Nine digits, starting with 9, issued by the IRS so I could file a US tax return. It is not an SSN, and I had already learned that the hard way on a bank form that called it invalid. I did not want to type it into a box labeled SSN and hope. I also did not want to leave the box empty and look like I was hiding something.

What the box was actually asking

It took me a day to see that the box was standing in for a different question. The landlord did not care about the number. They cared about what the number unlocks in the screening report: a credit file, a payment history, a sign that rent would arrive.

I did not have that yet. I had the ITIN, and I had a US bank account that accepted it. I did not have a credit file, because a bank account by itself does not report to the bureaus. So even if the screening service had taken my number, the report would have come back thin. The honest answer to the box was "not yet," and I needed a way to say that without the form doing it for me.

What I brought instead

I emailed the property manager before submitting anything. I said I had an ITIN, not an SSN, that I was new to the US credit system, and asked what they accept from applicants in that position. The reply was short and more useful than the form: some screening services can run without an SSN, and some landlords look at other proof when the report is thin.

So I put together a folder, the same way I had for the ITIN itself:

The ITIN letter from the IRS, so the number was explained instead of guessed at.
Three months of statements from the US bank account, showing money arriving and staying.
A letter from my employer with my start date and pay.
My passport, as identity, shown in person rather than mailed.
A short note saying I did not have a US credit file yet and was starting one.

I am not claiming this works everywhere. Landlords and screening companies have their own rules, and the rules on deposits and screening differ by city and state. This is what I did for one apartment, with one manager who answered email.

The order I had skipped

What I had missed was the order. I treated the apartment as step one. It is closer to step three. ITIN Club is the free community that writes the year after the letter in one line: get the ITIN, open a US bank account that accepts it, start a credit file, let a score exist, then look at cards and the bigger applications that read your file. A lease is one of those.

The bank step is its own guide, and it is the page that made the folder possible: How to open a US bank account as a non-resident. The credit file is the step I am on now. How to check your US credit score as a non-resident is how I confirm whether anything is reporting yet, instead of finding out from the next application. The course that holds the whole sequence is Your first year with an ITIN.

If you are still before the number, the first page is How to get an ITIN as a foreigner. It also explains who can review a passport so the original does not have to go in the mail, which mattered to me because I needed that passport for the apartment viewing.

What I would tell myself a month earlier

Read the box as a question about history, not about a number. Ask the landlord before the form decides. Bring the paper that shows the history you do have. And start the credit file before the apartment search, not during it, because the file needs months that a lease application will not wait for.

None of this is tax, legal, or financial advice. It is what one rental form taught me about where I was in the order. The pages I used:

I got the apartment. The radiator still knocks.

How Do You Validate `unknown` in TypeScript Without a Schema Library? 🛡️

nyaomaru — Wed, 14 Oct 2026 15:35:25 GMT

Hoi hoi! 👋

I'm @nyaomaru, a frontend engineer who is obsessed with gamba. 😸🦐

Recently, I was thinking about a very common TypeScript problem.

Suppose some value comes from:

an API response
JSON.parse
local storage
a message payload
third-party code

What type should it have before we actually verify it?

Probably this

declare const input: unknown;

That part is easy.

The interesting question is what comes next.

How do we safely turn that unknown into something useful?

And do we really need a full schema library every time?

Let's look at it! 👀

Validate unknown in TypeScript Without a Schema Library | is-kit

Validate unknown TypeScript values with small composable type guards and safeParse, without adopting a schema-first validation workflow.

is-kit.dev

🧱 `unknown` Is Doing Its Job

Suppose we have

declare const input: unknown;

input.name;
// Error

TypeScript refuses to let us access name.

At first this can feel annoying.

But TypeScript is actually telling us something important

We have a value.

We do not know what it is yet.

That is exactly what an untrusted boundary value should mean.

An HTTP response does not become a User just because our application expects a User.

Neither does parsed JSON.

So I like to think of unknown like this

unknown is not missing type information.

It is an honest description of a value we have not verified yet.

The problem is not unknown.

The problem is how we establish trust.

😈 The Easy Escape: `as User`

There is a very short way out.

type User = {
  id: string;
  name: string;
};

declare const input: unknown;

const user = input as User;

user.name.toUpperCase();

TypeScript is happy.

Nice! 🎉

Except, nothing was actually checked.

This still works

const input = {
  id: "user-1",
  name: 123,
} as unknown;

const user = input as User;

user.name.toUpperCase();
// 💥 Runtime error

as User changes what the compiler believes.

It does not inspect the runtime value.
It does not add missing properties.
It does not turn 123 into a string.

So if runtime trust matters, a type assertion is not validation.

We need an actual runtime check.

🛡️ A Type Guard Connects Runtime and TypeScript

Let's start small.

With is-kit, we can build a guard like this

import { isString, oneOfValues, struct } from "is-kit";

const isUser = struct({
  id: isString,
  name: isString,
  role: oneOfValues("admin", "member"),
});

Now we can pass unknown directly to it

declare const input: unknown;

if (isUser(input)) {
  input.name.toUpperCase();

  // input:
  // Readonly<{
  //   id: string;
  //   name: string;
  //   role: "admin" | "member";
  // }>
}

This is the part I like.

The same check does two jobs

runtime
→ does this value actually match?

TypeScript
→ what is this value after the check succeeds?

There is no separate schema definition and no type assertion.

We just compose small runtime predicates.

🧩 The Shape Can Grow Naturally

Real payloads are usually a little more complicated.

Maybe a user has:

an optional profile
a nullable bio
a list of tags

We can keep composing guards

import {
  arrayOf,
  isString,
  nullable,
  oneOfValues,
  optionalKey,
  struct,
} from "is-kit";

const isProfile = struct({
  displayName: isString,
  bio: optionalKey(nullable(isString)),
});

const isUser = struct({
  id: isString,
  role: oneOfValues("admin", "member"),
  profile: optionalKey(isProfile),
  tags: arrayOf(isString),
});

Then

isUser({
  id: "user-1",
  role: "member",
  tags: ["typescript", "guards"],
});
// true

But

isUser({
  id: "user-1",
  role: "owner",
  tags: ["typescript"],
});
// false

Each piece is still just a guard.

That means we can test it independently, reuse it somewhere else, or compose it into something larger.

There is also an important difference here

optionalKey(...)

means

the property may be absent

while

nullable(...)

means

the value may be null

Those are different runtime contracts, so I prefer keeping them separate.

📦 What Does `safeParse` Add?

A direct guard is often enough.

if (isUser(input)) {
  renderUser(input);
}

But sometimes I want the validation result itself to move through the program.

For example

const result = safeParse(isUser, input);

if (!result.valid) {
  return { status: 400 as const };
}

return {
  status: 200 as const,
  user: result.value,
};

safeParse gives us a small tagged result

{
  valid: (true, value);
}

{
  valid: false;
}

So TypeScript can narrow it with a normal branch.

The important part is what safeParse does not do.

It does not:

clone the value
coerce the value
generate a new object
transform invalid data into valid data

On success, it returns the same value after the guard has accepted it.

So I think of the difference like this

guard
→ boolean + narrowing

safeParse
→ tagged result + validated value

Same runtime rule.

Different control-flow shape.

🧃 What About JSON?

This is one of the most common boundaries.

const value = JSON.parse(body);

The awkward part is that JSON.parse returns any.

So now the unsafe value can spread through the program before we validate it.

Instead, we can keep the boundary small

import { safeJsonParse } from "is-kit";

declare const body: string;

const result = safeJsonParse(body, isUser);

if (!result.valid) {
  return { status: 400 as const };
}

renderUser(result.value);

Conceptually, the flow is

JSON text
   ↓
decode
   ↓
unknown
   ↓
guard
   ↓
validated value

Invalid JSON and guard failures both produce

{
  valid: false;
}

And again, nothing is coerced just to make the value pass.

I like this because the unsafe part stays right at the decode boundary.

🚪 Should Extra Keys Be Allowed?

There is another small design choice that appears at object boundaries.

Suppose we expect

{
  username: string;
  password: string;
}

Should this also be accepted?

{
  username: "Neko",
  password: "secret",
  admin: true,
}

With struct, extra keys are allowed by default.

That is often useful for API responses because a server may add a new field without breaking an older client.

But sometimes we really want a closed object shape.

Then we can use

const isCredentials = struct(
  {
    username: isString,
    password: isString,
  },
  { exact: true },
);

Now

isCredentials({
  username: "Neko",
  password: "secret",
});
// true

while

isCredentials({
  username: "Neko",
  password: "secret",
  admin: true,
});
// false

The important part is not that one mode is always better.

It is that the boundary should express the contract we actually want.

🤔 So Do We Still Need Schema Libraries?

Yes.

Sometimes absolutely.

A type guard toolkit and a schema library overlap a little, but they are not trying to solve exactly the same problem.

For example, a schema library is probably the better choice when we need:

structured validation errors with field paths
multiple validation issues at once
coercion
default values
transformations
schema-generated types or external artifacts
deep integration with a form or API framework

Those are larger validation workflows.

is-kit asks a narrower question

Does this value satisfy this runtime predicate?

If yes, what can TypeScript safely narrow it to?

That narrower model is sometimes exactly what I want.

For example

Approach	Good fit
Inline `typeof` checks	One small local condition
Type guards	Reusable boolean validation and narrowing
Schema library	Rich validation, transformation, and schema workflows

So I don't think the question is

Type guards or schema libraries—which one wins?

The more useful question is

What is the smallest validation model that solves this boundary?

🎯 The Important Part

I started with a simple value

declare const input: unknown;

The tempting shortcut was

const user = input as User;

But that only changes TypeScript's belief.

It does not establish runtime trust.

A runtime guard gives us a much more useful flow

unknown
   ↓
runtime check
   ↓
narrowed value

And when we want a result-oriented API

unknown
   ↓
guard
   ↓
safeParse
   ↓
{ valid: true, value }
or
{ valid: false }

No hidden conversion.

No assertion pretending the check already happened.

Just small runtime rules that TypeScript can understand too. 😸

If you want to see the full guide, including JSON boundaries, exact objects, and custom domain refinements:

Validate unknown in TypeScript Without a Schema Library | is-kit

Validate unknown TypeScript values with small composable type guards and safeParse, without adopting a schema-first validation workflow.

is-kit.dev

And if you want to explore is-kit itself:

nyaomaru / is-kit

Build small guards. Compose them. A lightweight, zero-dependency toolkit for building reusable TypeScript type guards that compose, refine, and preserve natural narrowing. Runtime-safe 🛡️, composable 🧩, and ergonomic ✨.

is-kit

Build small guards. Compose them.

is-kit is a lightweight, zero-dependency toolkit for building reusable TypeScript type guards.

is-kit is not just a collection of isX helpers. Its main focus is composing small runtime checks into reusable guards while preserving useful TypeScript narrowing.

It helps you write small isFoo functions, compose them into richer runtime checks, refine properties on values you already know about, and keep TypeScript narrowing natural inside regular control flow. Use it at runtime boundaries when needed, without requiring a schema-first workflow.

Runtime-safe 🛡️, composable 🧩, and ergonomic ✨ without asking you to adopt a heavy schema workflow.

Build and reuse typed guards
Compose guards with and, or, not, oneOf
Use refineKey to narrow a child property while preserving its parent type
Validate object shapes and collections when that is useful
Parse or assert unknown values without a large schema framework

Best…

View on GitHub

If it looks useful, a ⭐ on GitHub is always very welcome!

Thanks for reading! 🙌

Your Browser Can Do WHAT?! 5 AI Features That Actually Work

Sylwia Laskowska — Wed, 14 Oct 2026 07:05:48 GMT

Are AI models running directly in the browser finally good enough to use in production? Let's find out! 😉

It's been a week since my talk at FrontKon in Prague. As I mentioned before, it was fantastic! I'm adding a few photos below, just to prove that I actually speak at conferences and don't just make these things up. 😀

My talk was titled "Your Browser Is a Compute Platform (And You're Using It for Forms)", and I showed how we can use WebAssembly and WebGPU to perform advanced computations directly in the browser. I was a little concerned to discover that, out of everyone in the audience, maybe three or four people had even heard of WebGPU! And that's a shame, because WebGPU can accelerate certain types of parallel computations by tens of times compared to CPU-based implementations.

But okay, at least the people at FrontKon know what WebGPU is now. 😁 And if you'd like a talk about this at your conference, feel free to reach out! Especially if your conference happens to take place in a particularly attractive tourist destination. 😀

Why I'm Revisiting Browser AI

After a conference, I traditionally prepare a blog post related to my talk. However, since I've already written about WebAssembly and WebGPU many times, today I'd like to approach the topic from a different angle. Namely, let's take a look at the current state of AI models running directly in the browser, which, of course, make extensive use of these technologies. 🙂

Browser-based AI models are a fascinating concept. No inference API calls. No network round trips to an AI backend. No worrying that your users will consume too many tokens, because you're not paying for them! But of course, local inference still takes time, and downloading the model in the first place can take a while.

Another advantage is that these models can work offline once they've been downloaded and cached by the browser, provided the application itself supports offline operation.

And that also brings a significant privacy benefit: inference happens directly on the user's device, so their data doesn't need to be sent to an external AI service.

However, as you can probably imagine, these are relatively small models. We're not going to run a massive frontier-scale model in a typical browser tab.

So the question is: how useful are these smaller models, really?

Some of you may remember that I experimented with browser-based AI models about a year ago. Back then, we were mostly laughing that they were a fun curiosity, but not much more than that.

But I've been following people from Hugging Face who work on Transformers.js on LinkedIn, and every now and then, their demos would appear in my feed. At first glance, some of them looked genuinely impressive. You know, practically spaceships running inside a browser. 😉

So before FrontKon, I decided to take another look at what they had to offer. And it turned out that after upgrading Transformers.js to version 4.3.1, which I used for these experiments, and trying some newer models, the results were genuinely impressive!

Of course, Transformers.js isn't the only option for running AI models in the browser. There are other libraries and runtimes, but I really like Transformers.js, and I think it's a pretty representative example of what this technology can achieve today.

At the same time, I don't work for Hugging Face, and nobody is paying me to sell you a spaceship in your browser. So I'll tell you what browser-based AI models can actually do today, what works well, and what still doesn't.

And even better, you can explore the code and try everything yourself!

GitHub: https://github.com/sylwia-lask/practical-browser-ai

Live demo: https://sylwia-lask.github.io/practical-browser-ai

If you like the project, please give it a star on GitHub. I'm collecting them! 😀

Can We Actually Use This in Production?

For these demos, I wanted to focus on practical applications. More specifically, I wanted to find out how we could use browser-based AI today, right now, in real production applications.

So is this technology worth paying attention to? In my opinion, absolutely!

But!

I probably wouldn't build a mission-critical system that depends entirely on these models working perfectly. 😉 Instead, I'd treat them as interesting, optional enhancements to existing application features, especially in areas like e-commerce, accessibility, and customer support.

The application itself is nothing particularly exotic, by the way. It's a regular React application written in TypeScript, using Web Workers to run model inference without blocking the main UI thread.

The models are loaded on demand, so you don't need to download all five of them just to open the application. The inference runs locally through Transformers.js, using WebGPU where supported and WebAssembly-based CPU execution where a fallback is available.

No AI backend involved!

Let's see what I managed to build. And at the end, I'll share my thoughts on the limitations of these models.

One more thing: these aren't browser-based AI agents yet. They're simply applications using local AI models for specific tasks. But give me a few more weeks, and you'll see agents running in the browser on my blog too!

1. Background Remover

One of the things I particularly appreciate about browser-based AI is that it's not limited to text generation. I love working with multimodal AI!

In this demo, a small model called RMBG-1.4, with approximately 44 million parameters, does a really impressive job of separating an object from its background. 🙂 The model itself is only about 170 MB to download in the configuration I'm using.

As you can see, we can then save the result as a transparent PNG, and it works surprisingly well!

I can easily imagine this as an additional feature on auction websites or e-commerce platforms.

Imagine someone trying to sell a product but only having a photo like my example. Instead of requiring them to use an external image-editing service, we could simply offer a background removal button directly in the application.

And the photo doesn't even need to leave their device. Pretty cool, isn't it?

One practical note: RMBG-1.4 comes with licensing conditions that should be checked before commercial deployment. So while the technical concept is very promising for e-commerce, you should always verify the model's license before shipping it.

2. Alt Text Generator

I've always felt that AI could become another useful layer of accessibility, if we use it properly.

This demo uses Florence-2-base-ft, a vision model with approximately 230 million parameters, to generate descriptions of images.

Imagine that you're uploading an image to DEV, for example. Instead of having to write an alt text description from scratch, you could use a model like this to generate a suggestion automatically. Especially when you really don't feel like describing what's in the picture!

Of course, the generated description should still be reviewed and edited by a human. Good alt text isn't just about identifying objects in an image. It also depends on the context and purpose of that image.

The model doesn't necessarily understand why you're using the picture, and it can occasionally miss or invent details. Still, as an accessibility assistant, I think this is a very promising approach.

There's also an option to provide additional context, but don't expect too much from it. In my implementation, the extra text is simply appended to the generated description rather than genuinely influencing what the model sees or understands. I'll explain why I wasn't satisfied with this approach later in the article.

For reference, the model download is roughly 350–450 MB, depending on the precision supported by the device.

3. Smart Ticket Creator

Oh, this one is my dream feature! I describe what's wrong in completely natural, messy language, and the model turns it into a structured ticket that I can send to support. 😀

The model I ended up using is Qwen2.5-0.5B-Instruct, a small language model with approximately 500 million parameters. In my configuration, its quantized weights require a download of around 786 MB, plus tokenizer files.

And I have to admit something. When I started implementing this feature, I thought it would be the easiest one! Seriously. How difficult could it be for a language model to turn a complaint into a structured ticket?

Well... Apparently, quite difficult! I spent much more time than expected trying different models and getting them to produce the output I actually needed.

The main challenge wasn't just understanding the complaint. It was producing a consistent, structured response with the correct fields, without inventing information or returning malformed JSON. Eventually, I got it working using a carefully designed prompt, output parsing, and schema validation with Zod.

The generated ticket is editable, so the user can review everything before copying or submitting it. And I think that's exactly the kind of approach that makes sense for production: let the AI do the boring initial work, but keep the human in control.

4. Semantic Search

Now, this is where small models really shine! For this demo, I implemented semantic search over a collection of support tickets.

Instead of looking for matching keywords, the application searches for tickets with a similar meaning. And, of course, I also included a traditional keyword search so you can compare the results yourself.

I'm using all-MiniLM-L6-v2, a small embedding model with approximately 22 million parameters. Depending on the backend, its model weights are only about 23 MB for the quantized CPU version or 90 MB for the WebGPU version.

And it works really well! The model is fast, and the results are genuinely useful.

Under the hood, it converts the tickets and the search query into numerical vectors, then compares them using cosine similarity. No generative LLM is needed here.

In fact, that's one of the most interesting lessons from these experiments: sometimes a small, specialized model is a much better choice than a general-purpose language model. This is particularly good news for applications where privacy matters and you don't want to send potentially sensitive information to an external server.

For a small collection of documents, this approach is definitely worth testing. Of course, for larger datasets you'd need to think about indexing, storage, and performance. In my demo, the embeddings are kept in memory, which is perfectly sufficient for the example. But the basic idea works surprisingly well.

5. Pause & Ask

Okay, this one might be a little less practical, but it's definitely fancy! 😀 And I think it also has interesting accessibility potential. For this demo, I'm using LFM2.5-VL-450M, a vision-language model with approximately 450 million parameters. The download is roughly 350–400 MB, depending on the configuration.

There are actually two features here. The first is live visual description. I turn on my webcam, and the model periodically describes what it sees. Yes, that's me:

But then it gets even better! I can pause the camera on a particular frame and ask the model questions about what it sees.

And here's the example showing that the model isn't exactly perfect. 😅 Although, well, I'm certainly flattered!

I wouldn't treat this as a reliable accessibility tool just yet, but as an experiment in local visual question answering, it's genuinely fascinating.

And that's all five demos!

So What's the Catch?

Now, as promised, let's talk about the disadvantages. Because, of course, there are quite a few!

WebGPU Support and Hardware Limitations

First of all, these models run as well as they do largely thanks to WebGPU. This API allows applications to use GPU computing capabilities directly in the browser, which can make a huge difference for machine learning inference.

The problem is that WebGPU availability and performance aren't the same on every device. Support has improved significantly across modern browsers, but availability still depends on the browser version, operating system, GPU, drivers, etc. And even if WebGPU is supported, that doesn't mean everyone has an equally powerful computer.

Mobile devices are a particularly interesting problem. Some mobile browsers and devices still lack usable WebGPU support for certain workloads. In those cases, some Transformers.js models can fall back to WebAssembly-based CPU inference, potentially using SIMD or multithreading depending on the environment and configuration.

Unfortunately, this can be significantly slower. On my phone, two of the examples from my demo didn't work at all because they timed out. And it's not like I'm using some ancient phone from a museum! It's a Samsung Galaxy S24 FE. Not the newest flagship anymore, but definitely not a dinosaur either.

So yes, WebGPU support is improving, and the models are getting better. But I want to talk about what we can actually use right now, not what might be possible in a few years.

Model Downloads Aren't Exactly Tiny

There's also another important limitation: the models themselves have to be downloaded. And while some are relatively small, others can require hundreds of megabytes. As you've seen, the models in my demo range from around 23 MB for the quantized semantic search model to nearly 800 MB for the Smart Ticket Creator. That's quite a lot if you're visiting a website on a mobile connection!

Fortunately, browsers can cache the downloaded model files, so subsequent visits usually don't require downloading everything again. But the first load still matters, and browser storage isn't guaranteed to keep those files forever.

That's another reason why I'd treat these features as optional enhancements rather than something every user must load before they can use the application.

Some Things Still Don't Work Well Enough

I also couldn't implement everything I originally wanted, even though some ideas seemed perfectly reasonable. For example, I tried adding text recognition from images. And despite experimenting with different models and configurations, I couldn't get results that were reliable enough for my demo. The approaches I tested didn't give me the quality I wanted, so I decided not to include that feature.

Another thing I wanted to improve was the contextual information in the alt text generator. Imagine uploading a photo of a dog and adding some additional context, such as: "This dog is available for adoption at a local animal shelter." Ideally, the model would take that information into account and generate a beautiful, context-aware description.

I tried using an additional local language model for this, hoping it could combine the visual description with the extra information. But no matter what I tried, the results were very unsatisfactory. So I ended up with the simpler approach I mentioned earlier, where the context is added separately rather than genuinely interpreted by the image-captioning model.

And that's another good example of why I wouldn't blindly trust these models in production.

What About Voice Recognition?

On the other hand, I've heard that small browser-based models can be surprisingly good at speech recognition. Transformers.js supports audio-related tasks too, so that's definitely another interesting area to explore.

I didn't test it this time, though. Mostly because I was building these demos in the evenings, and my family would have killed me if I'd spent hours talking to my computer. 😂 Maybe next time!

My Verdict: Is Browser AI Production-Ready?

So, to sum up: browser-based AI models are getting better, and I think it's already worth exploring how to use them in production applications.

Not necessarily as a replacement for every AI backend. And definitely not as a critical dependency without a fallback. But as optional features that improve the user experience? Absolutely.

What do you think? Have you already experimented with running AI models directly in the browser?

And if you enjoy reading my articles, feel free to follow me on LinkedIn too! 🙂

How I Feel about the Grace Hopper Celebration Getting Cancelled

Jess Lee — Tue, 13 Oct 2026 14:57:57 GMT

The Grace Hopper Celebration has been around since 1994, and for a lot of people, it's the event for women in tech. It's where students land their first internships, where people find mentors and peers who look like them, and where, for a few days, being a woman in a room full of technologists is the norm instead of the exception.

AnitaB.org has cancelled this year's Celebration, which was supposed to take place in Anaheim later this month. Their statement says registrations and sponsorships came in "significantly below" expectations, and the funds needed to put on the event just weren't there.

I was supposed to attend for the first time this year and host a panel on the evolution of nontraditional career paths into tech. I was really looking forward to that conversation.

A little over two years ago, I wrote about how I felt when Women Who Code shut down, and this news brings up a lot of the same feelings.

The sponsorship gap

Conferences like Grace Hopper run on company support, and that support shows up in two ways. The obvious one is sponsorship: booths, recruiting teams, and the dollars that make an event of this scale possible. The less obvious one is registrations. Between tickets, flights, and hotels, attending GHC adds up fast, and for a big chunk of attendees, it's their employer who has historically covered the cost. So when companies stop paying for their teams to attend, low registrations aren't a sign that people don't want to go. They're the same sponsorship gap, just showing up in a different line item.

When that support dries up on both fronts, even the most established event in the space can't happen.

When Women Who Code shut down, it felt like my fears of stagnancy and going backwards were being confirmed. I wish I could say things have turned around since then. Instead:

Company budgets for DEIB have continued to shrink, and "diversity" has become a word a lot of companies would rather not say out loud.
Sponsorship dollars for community events have dried up across the board.
The people these spaces serve are still tired. Being the only woman in the room hasn't gotten less exhausting just because it's gotten less fashionable to talk about.

Women Who Code and Grace Hopper were two of the biggest, most established institutions in this space. If the tech industry, which is by most measures still incredibly well-resourced, isn't investing in them, then smaller grassroots groups are in an even tougher spot.

What's next

One of my personal goals right now is to speak more, and news like this makes that feel more important than ever. If the big stages are disappearing, those of us who have a platform need to keep using it.

But you don't need a stage to make a difference. Look around at your team, your community, your classmates, and find the people who are undervalued and underrepresented. Mentor them, recommend them, amplify their work, and make sure they're heard in the rooms they're in. That kind of support doesn't need a sponsor.

Thanks for reading <3

AI Fatigue? Yea I know.

FrancisTRᴅᴇᴠ — Tue, 13 Oct 2026 14:57:34 GMT

I don't know how to start this off really haha. Though to be fair, everyone is talking about AI ranging from building projects with AI, news about AI, dev.to articles about AI, and so on.

Though the more I see articles talking about AI, the more I felt like it's no longer interesting anymore. There is so much articles that is related to AI (ignore the part where I posted about making a portfolio in relations to AI) to the point where I want something...different.

I remember having discussions with various people on dev.to where back then there use to be articles that were very interesting such as CSS Tips, Resources every developer should know, etc. I can tell it was interesting back then because I visit that time. How? (I just find articles before 2022). There were so much variety of articles to look into and it gives the reader a lot of choices.

Today, most of the time I see articles talking about:

Topics in MCP
An app someone use AI to build it
Tokens
Models
Machine Learning

This is based on my experience by simply looking at the front page. Don't get me wrong, MCP is important and so is someone building an app using AI in some sense and talking about their process. The problem is that almost everyone is doing it to the point where it's hard to find an article that stands out from the rest.

It also gets difficult for people, like me, to find articles that are easy to understand because in most cases, articles talking about AI tend to be complex.

Do I mention "AI" in my articles, yes. I talk about AI and I fit into this category. However, I try not to talk about AI most of the time and focus on other aspects. In other words, not making AI the main focus.

For instance, on my last article, I talked about the reasons of creating a portfolio in the age of AI. I mainly talk about how you can structure your portfolio and use AI as a tool. The main highlight is talking about making your portfolio in the age of AI and how it's still relevant in this market.

Before you ask, yes, it gave me fatigue even reading my own article on it. However, this is expected.

AI is unavoidable

If you are lucky enough, you can find an article that talks about anything not related to AI at all. However, there will always be some mention of AI whenever you read an article on dev.to or in any social media platform.

AI has becoming a discussion that seems unavoidable because AI plays a critical role whenever we are developing an app or how some companies using AI. AI is rapidly growing in a rate where it is hard to catch up for not only us developers, but for the general public as well. There are still some discussions about AI art and the legality of it to this day as it becomes much harder to distinguish.

It's everywhere. There is no escape from it and I don't know if it's even possible to escape from this fatigue. My fear is if we all know AI and if we remove AI from the equation from our lives, what do we truly know?

The question is never "how we differentiate topics between AI and non-AI?". we should all be asking: "What will we expect content to look like beyond AI?"

What's your Experience?

I would love to hear from you if you are experiencing this in the comments. If there is a solution to this, feel free to share this as well. Take care :D

Best Enterprise AI Gateways

Anthony Max — Tue, 13 Oct 2026 06:49:33 GMT

TL;DR

An enterprise AI gateway sits between your applications (and, increasingly, your agents and employees) and every model provider. It handles routing, failover, budgets, access control, guardrails and audit logs in one place, so you stop rebuilding them in every codebase.
Judge an enterprise AI gateway on five things: overhead under real load, governance depth, where it can be deployed, MCP support, and how much of your actual AI traffic it can see.
This guide compares the five leading enterprise AI gateways: Bifrost, Kong AI Gateway, Azure API Management, Portkey and LiteLLM.
Bifrost is the strongest all-round enterprise AI gateway for teams that want a dedicated, self-hostable gateway with MCP governance and, through Bifrost Edge, coverage of AI tools running on employee laptops. The other four each win in a narrower situation, covered below.
Two things changed this year and belong in any procurement conversation: Palo Alto Networks acquired Portkey, and LiteLLM had a PyPI supply chain incident in March.

A couple of years ago, a gateway conversation meant one thing: stop pasting provider keys into config files and get a single invoice. That's still part of the job. But platform teams now get harder questions. Which MCP servers can our agents reach? Who approved them? Why did one team's spend triple in a week? And what is the sales team pasting into the desktop chat app nobody configured?

An enterprise AI gateway is where those answers live, or at least where they should live. The catch is that the category has stretched. Some products are purpose-built LLM gateways, some are classic API gateways with AI policies added on top, and one just got bought by a security vendor. Picking between them on a feature checklist gets you a spreadsheet full of green ticks and no real answer.

Disclosure: Bifrost is built by Maxim AI, which also publishes this blog. Weigh the ranking with that in mind. Each section below says plainly where the alternatives are the better call.

What an enterprise AI gateway actually does

At its core, an AI gateway is a reverse proxy for model traffic. Your apps talk to one OpenAI-compatible endpoint, and the gateway translates, routes and retries across providers like OpenAI, Anthropic, AWS Bedrock and Google Vertex AI.

What turns an AI gateway into an enterprise AI gateway is everything around that proxy: identity (SSO and roles), budgets per team or customer, audit trails you can hand to a compliance officer, deployment inside your own network, and policy that applies the same way whether the caller is a service, an autonomous agent or a person. If you want the longer version of that argument, the LLM Gateway Buyer's Guide walks through the capability matrix in detail.

What to check before you shortlist an enterprise AI gateway

Overhead under load. Every request passes through the gateway, so its processing time is added to every model call. It's invisible on a single chat completion and very visible when an agent chains forty calls.
Governance depth. Per-team budgets, rate limits, role-based access and audit logs should be enforced at the infrastructure layer, not left to each app team's good intentions.
Where it runs. Regulated teams often need in-VPC, on-prem or air-gapped deployment. A gateway that only exists as a hosted service is a non-starter for them.
MCP. If agents call tools, the gateway needs to control which servers and tools they can reach, and with whose credentials.
Guardrails. PII redaction, secrets detection and prompt injection checks need to run before data reaches a model, with a clear choice between block, redact and log.
Coverage. A gateway only governs traffic that reaches it. Ask what happens to the AI tools people install themselves.

Enterprise AI gateways at a glance

If you only have a minute, this is the table to read. Bifrost is the go-to enterprise AI gateway because it covers model calls, MCP tool calls and agent traffic in one gateway, runs entirely inside your own infrastructure, and is the only one here that also reaches the AI tools running on employee laptops, through Bifrost Edge.

Capability	Bifrost (our pick)	Kong AI Gateway	Azure API Management	Portkey	LiteLLM
Form factor	Standalone gateway in Go, single binary	Plugins on Kong Gateway or Konnect	Policies on Azure API Management	Gateway plus hosted platform	Python SDK and proxy
Model coverage	10,000+ models, 25+ providers	Major hosted and self-hosted providers	Azure OpenAI plus other registered backends	1,600+ models	100+ providers
Failover and balancing	Weighted routing, retries, fallbacks, adaptive balancing and circuit breakers (Enterprise)	Load balancing and semantic routing	Backend load balancing	Retries, fallbacks, load balancing	Routing and fallbacks
Semantic caching	Yes (Redis, Qdrant, Weaviate, Pinecone)	Yes (plugin)	Yes (policies with Redis)	Select Enterprise plans	Yes (Qdrant, Valkey, Redis)
MCP governance	Native MCP gateway, tool filtering, per-user OAuth, Code Mode (up to 92.8% fewer input tokens)	AI MCP Proxy and OAuth2 plugins	MCP servers inside API Management	MCP Gateway	MCP gateway
Guardrails	Content safety, PII and secrets detection, plus AWS Bedrock Guardrails, Azure Content Safety, Google Model Armor, CrowdStrike AIDR and more (Enterprise)	Prompt guard plugins	Content safety policy	Built-in guardrails with PII detection	Integrations, some need a license
AI on laptops (desktop, browser, coding agents)	Yes, with Bifrost Edge	Routed traffic only	Routed traffic only	Routed traffic only	Routed traffic only
Our verdict	Best all-round enterprise choice	Best if Kong already runs your APIs	Best for Azure-only estates	Best managed option, especially for Palo Alto shops	Best for Python-first teams

The sections below take each gateway in turn, starting with the one we'd pick.

1. Bifrost

Bifrost is an open-source (Apache 2.0) enterprise AI gateway written in Go. It gives you one OpenAI-compatible interface to 10,000+ models across 25+ providers, and the drop-in setup means moving an existing app over is a single base URL change. It ships as one binary, so it runs on a VM, Kubernetes, private cloud or a fully disconnected network, and most teams are live the same day.

Speed is the headline. Bifrost's published benchmarks show about 11 microseconds of overhead at 5,000 requests per second on a single t3.xlarge, with a 100% success rate. In the head-to-head run on AWS EC2 (500 concurrent users, 60-second runs), Bifrost sustained 424 requests per second against 44.84 for LiteLLM, with a P99 latency of 1.68 seconds versus 90.72 seconds.

On the governance side, virtual keys carry budgets and rate limits that can be set per key, team, customer or model. In the Enterprise tier, governance runs off the identity provider you already use (Okta, Microsoft Entra, Keycloak, Zitadel, Auth0, Google Workspace or any OIDC provider), with SCIM 2.0 directory sync, fine-grained RBAC and data access control, and reusable access profiles so platform teams set the rules once. Routing combines weighted load balancing, retries with backoff and automatic fallbacks to another provider, and semantic caching serves stored answers to similar prompts, backed by Redis, Qdrant, Weaviate or Pinecone.

The MCP gateway is where it pulls ahead of most of this list. It governs which MCP servers and tools agents can use, with filtering at the client, request and virtual key level, and per-user OAuth so each person connects under their own account. Its Code Mode has the model write a short script to orchestrate tools instead of loading every tool definition into context, which cuts input token use by up to 92.8% across large tool sets. In a 508-tool run, Code Mode took the cost from $377 to $29 with a 100% task pass rate. The full numbers are in the MCP gateway cost and access control write-up.

Then there's Bifrost Edge, which the other gateways here simply don't have an answer for. Edge runs on macOS, Windows and Linux and routes traffic from desktop chat apps, browser AI, terminal coding agents and the MCP servers they connect to through your Bifrost gateway, after a one-time SSO sign-in. Only AI traffic is routed, and nothing else on the device is inspected. The same virtual keys, budgets and guardrails apply to tools nobody wired up on purpose, with content safety, PII and secrets detection on requests and responses, plus connections to AWS Bedrock Guardrails, Azure Content Safety, Google Model Armor, CrowdStrike AIDR, Check Point Guard and others. Admins can allow or block apps and MCP servers centrally, and a denial is enforced on the device, not just flagged in a dashboard. Rollout goes through the device management you already run: Jamf, Intune, Kandji, Omnissa Workspace ONE or JumpCloud.

For regulated teams, the enterprise tier adds clustering (a peer-to-peer cluster with no leader, so an outage one node sees is acted on by all of them), adaptive load balancing with circuit breakers, signed audit logs that can't be altered, secret management through AWS Secrets Manager, GCP Secret Manager or HashiCorp Vault, and in-VPC, on-prem or air-gapped deployment where no prompts or responses leave your infrastructure. Bifrost is SOC 2 Type II, ISO 27001, HIPAA and GDPR compliant, and multiple Fortune 500 companies run it in production across financial services, healthcare, technology, pharmaceuticals and defense.

Where to be careful: the enterprise depth (identity-based governance, clustering, adaptive load balancing, guardrail integrations, vault integrations and in-VPC deployment) sits in the paid Enterprise tier, not the open-source core. Edge requires the Enterprise gateway and is priced per endpoint, so budget for it separately, and it's still offered through early access, so pilot it on a subset of devices before a fleet-wide push.

Best for: Bifrost is built for enterprises running mission-critical AI workloads that require best-in-class performance, scalability, and reliability. It serves as a centralized AI gateway to route, govern, and secure all AI traffic across models and environments with ultra low latency. Bifrost unifies LLM gateway, MCP gateway, and Agents gateway capabilities into a single platform.

Designed for regulated industries and strict enterprise requirements, it supports air-gapped deployments, VPC isolation, and on-prem infrastructure. It provides full control over data, access, and execution, along with robust security, policy enforcement, and governance capabilities.

2. Kong AI Gateway

Kong AI Gateway is what happens when a mature API gateway learns about LLMs. If Kong already fronts your APIs, the pitch writes itself: same control plane, same plugin model, same team on call. The AI layer adds provider routing, token-based rate limiting, prompt guard plugins, semantic caching and semantic routing across models.

MCP arrived with Gateway 3.12 in October 2025. The AI MCP Proxy plugin can expose existing REST APIs as MCP tools or sit in front of an MCP server, with ACLs applied to both tool discovery and tool invocation, and a companion OAuth2 plugin handles authentication for MCP traffic.

The trade-offs are practical ones. Kong's docs list the MCP plugins as part of its AI Gateway Enterprise offering, and the OAuth2 plugin was still labelled tech preview there at the time of writing. And if Kong isn't already in your stack, standing up a full API gateway platform just for LLM traffic is a lot of machinery for the job.

Best for: organizations already standardized on Kong that want AI traffic on the control plane they already run.

3. Azure API Management

For Azure-first companies this is the path of least resistance. Microsoft's AI gateway capabilities aren't a separate product, they're a set of policies on top of API Management. A token limit policy enforces per-consumer quotas (and can count prompt tokens up front so oversized requests never reach the backend), a metrics policy sends token usage to Application Insights, and semantic caching runs on Azure Managed Redis or another RediSearch-compatible cache. LLM backends can be load balanced, and Entra ID handles authentication.

MCP support is real too. You can expose APIs as MCP servers and, per the June 2026 release notes, package them into products to control who gets what.

The costs are portability and tier. Capabilities vary by API Management service tier, everything is configured through policy XML, and the whole design assumes you live in Azure. Multi-cloud or on-prem estates will feel the friction.

Best for: Azure-centric enterprises with an existing API Management investment and security teams that already trust Entra and Azure Monitor.

4. Portkey (now Prisma AIRS AI Gateway)

Portkey made its name as the developer-friendly managed gateway: one API for 1,600+ models, retries, fallbacks, load balancing, guardrails with PII detection, budgets, RBAC and detailed logs. It added an MCP Gateway in January 2026, the core gateway is open source, and deployment options run from SaaS to private cloud, VPC and fully self-hosted. Enterprise plans bring SAML 2.0 SSO and audit logs.

The big news is ownership. Palo Alto Networks announced it would acquire Portkey and closed the deal on May 29, 2026, and the product now appears as the Prisma AIRS AI Gateway. For existing Palo Alto customers that's a neat consolidation, with the gateway sitting next to runtime security and identity tooling. For everyone else it's a fair moment to ask about roadmap and packaging, even though Palo Alto said existing and new Portkey customers will continue to be supported. One more detail: per Portkey's caching docs, semantic caching is limited to select Enterprise plans.

Best for: teams that want a managed, quick-to-adopt gateway, especially those already in the Palo Alto Networks ecosystem.

5. LiteLLM

LiteLLM is where a lot of teams start, for good reason. It's an MIT-licensed Python SDK plus a self-hosted proxy with 100+ providers, virtual keys, budgets, routing and fallbacks, guardrails and an MCP gateway. Semantic caching works with Qdrant, Valkey or Redis, though its docs recommend keeping it to single-shot prompts and away from multi-turn agent traffic. A paid enterprise license adds SCIM, audit logs and some guardrail integrations, and Admin UI SSO is free for up to five users.

Two things to weigh. First, performance: in Bifrost's published benchmarks (AWS EC2, 500 concurrent users, 60-second runs), LiteLLM sustained 44.84 requests per second with a P99 latency of 90.72 seconds, against 424 requests per second and 1.68 seconds for Bifrost. Second, supply chain hygiene. On March 24, 2026, versions 1.82.7 and 1.82.8 were published to PyPI carrying credential-stealing malware after attackers got hold of publishing credentials through a compromised CI/CD pipeline, as NetSPI's write-up describes. The bad versions were pulled. It wasn't a flaw in how the gateway works, and it could have hit any popular package. But a gateway holds every provider key you own, so pin versions and mirror packages internally whichever product you choose.

Best for: Python-heavy teams with moderate traffic that value ecosystem breadth and have the capacity to run and harden a self-hosted service.

Also worth a look

Cloudflare AI Gateway is a solid managed option for teams already on Cloudflare, with caching, rate limiting, dynamic routing, guardrails and DLP integration. It runs on Cloudflare's network, though, so it's not an option if you need self-hosted or in-VPC. OpenRouter suits individual developers and small teams who want broad model access under one bill better than it suits governance-heavy enterprise rollouts.

Enterprise controls and deployment compared

This second table covers what security reviews and procurement tend to ask about when they evaluate an enterprise AI gateway: identity, audit, where the gateway runs and how it's licensed. It's where Bifrost's open-source core with an enterprise tier on top makes the most difference for regulated buyers.

Control	Bifrost (our pick)	Kong AI Gateway	Azure API Management	Portkey	LiteLLM
SSO and roles	Okta, Entra, Keycloak, Zitadel, Auth0, Google Workspace or any OIDC provider, with SCIM 2.0, RBAC and data access control (Enterprise)	Kong's existing consumer and identity model	Entra ID with Azure RBAC	SAML 2.0 SSO and RBAC (Enterprise)	Admin UI SSO free for 5 users, license beyond; SCIM with license
Audit trail	Signed, tamper-proof audit logs with export to S3, GCS and BigQuery (Enterprise)	Kong logging plugins and Konnect analytics	Azure Monitor and Application Insights	Access rules and audit logs (Enterprise)	Audit logs with license
Where it runs	Single binary: self-hosted, in-VPC, on-prem, air-gapped, clustered	Self-hosted, hybrid or Konnect	Azure	SaaS, private cloud, VPC or self-hosted	Self-hosted (Docker, Kubernetes)
Licensing	Apache 2.0 core plus Enterprise tier (14-day free trial); Edge priced per endpoint	Open-source core, advanced AI plugins (including MCP) need a license	Azure service, capabilities vary by tier	Open-source gateway plus enterprise plans	MIT plus enterprise license key
Main trade-off	Depth sits in the paid tier; Edge needs Enterprise and is in early access	Needs Kong in place; MCP OAuth2 in tech preview	Azure-centric, policy XML	Roadmap now tied to Palo Alto	Python overhead and supply chain hygiene

Which AI Gateway Is Right for Your Team

For teams running enterprise AI workloads with multi-provider routing, agent workflows, regulated industry compliance, or high-throughput applications, the open-source Bifrost enterprise AI gateway addresses requirements that Python-based and lighter managed gateways tend to struggle with at scale. The 11 µs overhead, native MCP gateway, hierarchical virtual key governance, and support for air-gapped and VPC deployments make it the strongest production fit where those factors matter.

LiteLLM fits teams with Python-centric stacks and moderate traffic volumes that prioritize ecosystem familiarity. Kong AI Gateway fits organizations that have standardized on Kong for general API management. Azure API Management fits Azure-first estates where API Management is already approved, and Portkey fits teams that want a managed gateway, especially those already in the Palo Alto Networks ecosystem. Cloudflare AI Gateway and OpenRouter fit teams with simpler requirements: managed infrastructure, lighter governance needs, or early-stage workloads that have not yet encountered the scale at which a self-hosted, compiled-language gateway becomes necessary. Teams comparing options across this range will find the LLM Gateway Buyer's Guide a useful reference before finalizing a decision.

Frequently asked questions

What is an enterprise AI gateway?

It's a control layer between AI consumers (applications, agents and employees) and model providers. It routes and retries requests across models, enforces budgets and access rules, applies guardrails, and records everything for audit, usually through one OpenAI-compatible endpoint.

How is an enterprise AI gateway different from an API gateway?

A classic API gateway counts requests and checks auth. An AI gateway understands tokens, models and prompts: token-based budgets, failover across model vendors, semantic caching keyed on meaning, and per-model cost attribution. The line is blurrier than it used to be, since Kong and Azure API Management have added AI policies on top of their API gateways, while products like Bifrost treat those capabilities as native.

Should we self-host or use a managed enterprise AI gateway?

Self-hosting keeps prompts, keys and logs inside your own boundary and gives you control, in exchange for running the service. Managed options start faster but send traffic through a vendor's network. Regulated and high-volume teams usually end up self-hosted or in-VPC.

Do enterprise AI gateways support MCP?

All five now offer something. Bifrost has a native MCP gateway, Kong uses licensed plugins, Azure API Management exposes and packages MCP servers, Portkey has an MCP Gateway, and LiteLLM added one to its proxy. The differences are in authentication, tool-level access control and token cost, so test those rather than ticking a box.

How much latency does an enterprise AI gateway add?

It depends on the runtime and which features are switched on. Bifrost adds about 11 microseconds of overhead at 5,000 RPS on a single t3.xlarge, as shown in its published benchmarks. Against model latency measured in seconds, that's noise for a single call, but overhead compounds when agents chain many calls.

Can we move off LiteLLM without rewriting code?

Usually yes, since both expose OpenAI-compatible APIs. Bifrost ships drop-in adapters for the LiteLLM SDK, and teams on a LiteLLM proxy can migrate models, keys, teams and users across automatically. The LiteLLM migration guide covers the cutover.

Can an enterprise AI gateway govern employees using ChatGPT or Claude desktop apps?

Only if that traffic reaches it. Standard gateways cover what developers deliberately route through them. Bifrost Edge closes that gap by routing desktop, browser and coding-agent traffic through the gateway so existing policies apply.

Is Bifrost open source, and what does the Enterprise tier add?

The core is open source under Apache 2.0 and free to self-host. The Enterprise tier adds high availability, identity-based governance, guardrail integrations, signed audit logs, vault integrations and in-VPC or air-gapped deployment, with a free 14-day trial. Bifrost Edge requires the Enterprise gateway and is priced per endpoint.

Conclusion

The five gateways in this comparison cover different points on the tradeoff curve between operational simplicity and production depth. For teams where AI is a core infrastructure concern, Bifrost provides the performance baseline, governance model, and enterprise deployment options that production requirements demand. To see how Bifrost fits your infrastructure, book a demo with the Bifrost team.

Resources:

Bifrost GitHub: https://github.com/maximhq/bifrost
Bifrost Docs: https://docs.getbifrost.ai
Bifrost CLI: npx -y @maximhq/bifrost-cli

Thanks for reading this article! ❤️

I'd love to hear your thoughts on this mode in the comments!

💎 Check out the Bifrost repository ☆

Join the Hacktoberfest Open-Source AI Challenge: Side Hustle! $2,550 in Prizes Across 18 Winners.

Jem — Mon, 12 Oct 2026 19:01:08 GMT

Week 2 of our five Hacktoberfest DEV Challenges starts today! Running through October 18, the Hacktoberfest Open-Source AI Challenge: Week 2 gives you a full week to build.

This year's Hacktoberfest is all about building brand-new projects with open-source AI and open-weight models. Here's everything you need to know about Hacktoberfest 2026.

Missed Week 1: Touch Grass? No problem. Every challenge is a fresh start, so you're competing on the same footing as everyone else.

This week, we'll select one overall winner and a winner in each of our 17 partner categories. See all five challenges and current partner categories on the HF26 DEV Challenge Hub.

Let's get to it!

This week's theme: Side Hustle

Build something with open-weight models or open-source AI that someone would actually pay for.

That can mean running an open-weight model, building on an open-source agent harness or framework, running inference locally, or all three. Whatever you pick, the open pieces should be what makes your project work.

Think small, specific, and useful. The best builds here solve a real problem for a real person, whether that's a freelancer, a small business owner, a niche hobby community, or your friend who keeps complaining about the same tedious task. A few ideas to get you going:

An invoice and receipt sorter for freelancers that runs locally, so client data never leaves their laptop
A listing writer for Etsy or eBay sellers that turns a few product photos into a polished description
A menu translator for a local restaurant that handles their specific dishes better than a generic tool

In your post, tell us why open innovation matters for what you built. Does running your own model keep costs low enough that the business actually works? Keep your customers' data private? Let you fine-tune for a niche that a general-purpose API handles poorly? Avoid getting locked into someone else's pricing? Tell us where your open-based approach worked better than a closed one.

Bonus points if you land your first user. Get it in front of someone, let them use it, and tell us how it went. Did they pay? Would they? What did they ask for next?

Side Hustle Submission Template

Prize Categories

Alongside our overall winner, we have 17 prize categories for projects that use a specific partner's technology. You don't need to use any of these to win the overall prize, but if you've been curious about any of this tech, this is a great excuse to give one a try. Full descriptions are on the hub.

Featured categories:

Partner categories:

Pro Tip: Partner category winners come from a smaller pool of submissions, so your odds are meaningfully higher.

Note: One project can enter every category it genuinely uses, but you can only win once per challenge, and we'll aim to celebrate as many different builders as possible across the month.

Free credits: several partners are giving participants credits and promo codes, including Tinker, Render, and Backboard. Claim yours at hacktoberfest.com/my.

A huge thank you to our partners for making these prizes possible!

Judging Criteria

This is DEV, so your write-up matters most.

Writing Quality (weighted most heavily): Is the post clear and engaging? Does it explain what you built, who it's for, and why open innovation matters?
Relevance to the Prompt and Theme: Is open-source AI or open-weight models at the core of the project? Is it something someone would actually pay for?
Creativity: Is it an original idea, or a fresh take on a familiar problem?
Technical Execution: Does it work, and is it well built?
Use of Partner Technology (optional): If you're entering a partner category, does the project use that technology in a meaningful way?

Show your work. We'd love to see how you built it. Save your agent session with DevRelay and embed it in your post, or link to it. It's optional, but it helps the judges understand your process.

Prizes

Overall winner (1): $250 USD, a DEV++ membership, and an exclusive DEV badge
Featured category winners (6): $200 USD and an exclusive DEV badge each
Partner category winners (11): $100 USD and an exclusive DEV badge each

All participants with a valid submission will receive a completion badge.

How To Participate

Publish a post on DEV using the submission template below. Tell us what you built and who would pay for it, show us a demo, and explain why open innovation matters for what you built. If you landed your first user, tell us about it!

Side Hustle Submission Template

Please review our judging criteria, rules, guidelines, and FAQ page before submitting so you understand our participation guidelines and official contest rules, such as eligibility requirements.

Need Help?

New to Hacktoberfest this year? Start with Everything You Need To Know About Hacktoberfest 2026.
Come hang out and ask questions in the MLH Discord.
The challenge page has resources from our partners to help you get started.

Important Dates

October 12: Hacktoberfest Open-Source AI Challenge: Week 2 begins!
October 18: Submissions due at 11:59 PM PDT
Week of October 19: Winners announced

Looking Ahead

Week 3 launches Monday, October 19 with a brand-new theme. Be sure to register so you don't miss the announcement.

Questions about the challenge? Drop them in the comments below.

Happy Hacktoberfest, and good luck!

5 Best AI Gateways

Hadil Ben Abdallah — Mon, 12 Oct 2026 09:05:21 GMT

Choosing between the best AI gateways is not just about getting a way to call an LLM.

In real deployments, teams face more than one model vendor. Models can change over time. Traffic is not steady. Token prices keep going up. Agent style workflows can get hard to manage. A gateway lets engineers manage these moving parts in one spot, instead of writing provider-specific code across the app.

Still, not every gateway is meant for the same job. Some tools focus on a smooth developer setup and quick onboarding. Others aim for wide provider support and more control over choices. A few run close to the edge. Others are built for large scale production use, where throughput and enterprise needs matter.

This write-up compares five AI gateways: Bifrost, Cloudflare AI Gateway, Vercel AI Gateway, LiteLLM, and OpenRouter.

We will cover what counts for live use. That includes speed, provider access, reliability, routing, logs and tracing, cost limits, deployment options, and how simple it is to hook the gateway into your code.

TL;DR

AI gateways are an important part of the modern AI stack, but the best AI gateway for your application depends on where you host it and what you need from the gateway.

Below is a short review of five gateways:

Bifrost: Built for real production use. It is open source. It handles routing and failover. It also brings governance and observability. It includes MCP and agent features too. You can deploy it for teams that want enterprise setups.
Cloudflare AI Gateway: This one runs on Cloudflare’s edge. It supports routing across providers. It adds analytics, caching, and retry logic. It also ties into the rest of Cloudflare’s platform.
Vercel AI Gateway: This is a managed choice. The focus is on easy setup. It targets teams building with modern web tools and AI SDKs. The goal is quick integration.
LiteLLM: It is open source and written in Python. It covers many model providers. It offers an OpenAI-style interface. That helps if you want one client style while you switch between providers.
OpenRouter: This is a hosted API gateway. It routes models for you. It lets developers use a wide set of models and providers. You access them through one API.

In the end, the gap between these tools is control. Some help you reach many models fast. Others give you more control over how requests route, how the system runs, how it stays reliable, and how you can see what is happening in production.

What Is an AI Gateway (And Why Does It Matter in Production)?

An AI gateway is a layer that could be added between your app and the AI models or providers it uses.

Instead of connecting your application separately to OpenAI, Anthropic, Google, AWS, and other providers, an AI gateway can give your application a unified interface for sending requests and managing what happens around those requests.

Depending on the platform, an AI gateway can provide:

Unified APIs that reduce provider-specific integration work
Model routing across different providers and models
Automatic retries and failover when a provider has an issue
Observability for requests, latency, errors, tokens, and usage
Caching to reduce repeated model calls and costs
Rate limits and budgets for controlling AI usage
Access controls for teams, applications, or users
MCP and agent support for more complex AI workflows

This matters more as your AI app gets bigger.

A prototype might call one model directly from a single application. A production system can end up depending on several models, multiple providers, different environments, and thousands of requests per minute.

Without a centralized gateway, provider configuration and reliability logic can spread across the application codebase. Changing models, handling provider failures, tracking costs, or introducing usage policies can then require changes in several places.

A gateway gives your engineering team a clear place to manage these issues. Your app code can stay focused on the product.

How We Evaluated These AI Gateways

This comparison is about where AI gateways land in real work settings. It is not only about the feature list on a sales page.

The main criteria are:

Performance and scalability
Model and provider coverage
Routing and failover
Observability and cost control
Ease of integration
Deployment and infrastructure flexibility
Open-source availability and enterprise capabilities

Quick Comparison: The 5 Best AI Gateways

This comparison of the best AI gateways highlights the differences in deployment, provider access, performance, and pricing. Use it to narrow down the options that best fit your production requirements.

AI Gateway	Runtime / Model	Open Source	Key Strength	Pricing Model	Best For
Bifrost	Go	✓ Apache 2.0 core	Performance, routing, reliability, governance	Free self-hosted; Enterprise custom	High-traffic production AI
Cloudflare AI Gateway	Cloudflare Edge	✗	Edge integration, analytics, caching	Free core; usage-based Cloudflare costs	Cloudflare-based applications
Vercel AI Gateway	Managed	✗	Developer experience, routing, web integration	Free tier; paid plans	Vercel and frontend-heavy teams
LiteLLM	Python	✓	Provider coverage and flexibility	Free self-hosted; managed options	Multi-provider and Python teams
OpenRouter	Managed	✗	Large model catalog and unified API	Usage-based	Developers needing broad model access

It gets easier to tell them apart when you compare real production flow. Look at how each gateway manages live traffic. Also check how it handles provider setup. Finally, review what they do around AI request routing and supporting infrastructure.

1. Bifrost (by Maxim AI)

Bifrost is an open-source AI gateway and control plane built for production AI infrastructure. It gives engineering and platform teams a single interface for routing requests across models and providers while handling reliability, governance, observability, and cost controls from the same layer.

Bifrost is designed for environments where the gateway itself becomes an important part of the production request path. It supports 10,000+ models across 25+ providers, and provides an OpenAI-compatible API, so existing applications can connect by changing the API base URL.

It also goes beyond traditional LLM routing. Bifrost can govern LLM requests, MCP tool calls, and AI agent traffic through the same gateway, with enterprise capabilities for identity, access control, security, and deployment inside the customer's own infrastructure.

Production Performance and Reliability

An AI gateway adds another layer to every request, so its own performance can have a direct effect on the application using it.

Bifrost is built in Go with the request path optimized for low overhead. Its architecture keeps configuration in memory, pools and warms memory at startup, and maintains provider connections so requests do not repeatedly pay connection or database costs.

In a benchmark on AWS EC2 with 500 concurrent users over 60-second runs (benchmark results), Bifrost delivered:

424 requests/second versus 44.84 requests/second for LiteLLM
804 ms P50 latency versus 38.65 seconds
1.68 seconds P99 latency versus 90.72 seconds
120 MB memory usage versus 372 MB
100% success rate versus 88.78%

Actual performance depends on infrastructure, workload, provider latency, and configuration, so it is worth testing with your own traffic.

For larger production deployments, Bifrost Enterprise adds cluster mode, adaptive load balancing, circuit breakers, automatic failover, and zero-downtime deployments.

Routing, Governance, and AI Traffic Control

Bifrost provides a unified gateway for model and provider routing, with support for weighted load balancing, retries, and automatic fallback.

Teams can route requests across different models and providers while keeping application integrations behind a single API. Governance controls can then be applied to that traffic without requiring each application team to implement the same rules independently.

Core capabilities include:

Routing across 10,000+ models and 25+ providers
Weighted load balancing and provider failover
Budgets and rate limits through virtual keys
Semantic caching for repeated requests
Prometheus metrics and OpenTelemetry tracing
Integrations with platforms such as Datadog, Kafka, BigQuery, Pub/Sub, and Splunk

Bifrost also supports MCP Gateway capabilities, allowing models and agents to discover and call tools through the same infrastructure. Tool filtering, authentication, agent mode, and MCP server functionality extend the gateway beyond conventional model routing.

For large tool environments, MCP Code Mode lets the model orchestrate tools through sandboxed code instead of carrying every tool definition inside the prompt. Code Mode cuts input tokens by up to 92.8% across large tool sets.

Deployment and Enterprise Control

Bifrost is designed for organizations that need control over where their AI infrastructure runs and where their data stays.

The gateway can run as a single binary across environments including:

Virtual machines
Kubernetes
Private cloud
VPC infrastructure
On-premises environments
Air-gapped networks

The open-source core is licensed under Apache 2.0, while Bifrost Enterprise adds capabilities such as identity-based governance, fine-grained access control, guardrails, signed audit logs, secret management, and high-availability infrastructure.

Bifrost also includes Bifrost Edge, which extends gateway control to employee devices.

Pricing

Bifrost's open-source version is free forever for self-hosted use under the Apache 2.0 license.

Bifrost Enterprise uses custom pricing and includes a 14-day free trial.

Best for

Bifrost is built for businesses that require high-level performance, scalability, and reliability ability that are crucial to AI deployment. Its primary function is to act as a gateway through which all AI traffic goes through the system in a guided and secure manner. Bifrost combines its LLM, MCP, and Agents gateways into a single platform. It covers industries subject to regulations and strict business needs, including air-gapped deployment, VPC isolation, and on premises infrastructure. It offers complete control over data, access, and execution, as well as huge security capabilities.

Explore Bifrost

2. Cloudflare AI Gateway

Cloudflare AI Gateway provides a centralized layer for managing AI requests across different model providers while keeping those requests within the Cloudflare ecosystem. It is designed for teams that want more control over AI traffic without building a separate gateway layer from scratch.

The gateway works as a proxy between applications and AI providers, giving teams a consistent endpoint for sending requests while adding capabilities such as caching, rate limiting, retries, logging, and analytics. This can make it easier to monitor AI usage and manage production traffic as applications scale.

Pricing

Cloudflare AI Gateway has a free gateway layer, while the underlying AI provider usage and other Cloudflare services can incur their own costs. Pricing therefore depends largely on the Cloudflare products being used and the volume of AI traffic generated.

Best for

Cloudflare AI Gateway is best for teams already using Cloudflare infrastructure that want centralized AI traffic management, observability, caching, and control without introducing a separate AI gateway stack.

Explore Cloudflare AI Gateway

3. Vercel AI Gateway

Vercel AI Gateway is built for teams that are developing AI-powered web applications and want a simple way to connect their applications to multiple model providers.

The gateway provides a unified interface for model access while handling infrastructure concerns such as provider routing, failover, and model selection. This can reduce the amount of provider-specific logic developers need to maintain inside their applications.

Its biggest appeal is the developer experience. Teams already building with Vercel, Next.js, and the AI SDK can adopt an AI gateway without introducing a large amount of additional infrastructure to their stack.

Pricing

Vercel AI Gateway offers a free way to get started, with additional Vercel plans and usage-related costs depending on the deployment and services a team uses. BYOK configurations can also use provider pricing directly without additional token markup from Vercel.

Best for

Vercel AI Gateway is best for frontend and full-stack teams building AI applications with Vercel that prioritize developer experience, fast integration, and straightforward access to multiple AI models.

Explore Vercel AI Gateway

4. LiteLLM

LiteLLM is one of the most widely used open-source AI gateways for teams that want a common interface across different model providers. Built around Python, it provides an OpenAI-compatible API that lets applications connect to hundreds of models and providers without implementing separate integrations for each one.

Its biggest advantage is flexibility. LiteLLM supports a broad range of providers and gives developers tools for model routing, fallbacks, load balancing, retries, spend tracking, rate limits, and observability. That makes it useful for teams experimenting with different models or building applications that need to switch providers without rewriting their application logic.

LiteLLM can be deployed as a self-hosted proxy, making it attractive to engineering teams that want control over their AI infrastructure. It also offers managed cloud options for teams that do not want to operate the gateway themselves.

Pricing

LiteLLM's open-source gateway can be self-hosted for free, with infrastructure and model-provider costs remaining the main expenses. Managed and cloud offerings have separate pricing based on the services and usage involved.

Best for

LiteLLM is best for developers and engineering teams that need broad model and provider coverage, flexible routing, and an open-source AI gateway they can customize and self-host.

Explore LiteLLM

5. OpenRouter

OpenRouter takes a different approach to the AI gateway problem by providing a unified API for accessing a large catalog of AI models from different providers. Developers can use one API and switch between models without building separate integrations for every provider.

This makes OpenRouter useful when model choice is a major part of the development workflow. Teams can compare models, experiment with different providers, and route requests through a common interface while keeping the application integration relatively simple.

OpenRouter also provides features such as model routing, provider selection, usage tracking, and fallbacks, depending on the configuration and models being used. For developers who want fast access to a broad model ecosystem without operating their own gateway infrastructure, that simplicity can be a major advantage.

Pricing

OpenRouter generally charges based on model usage, with pricing determined by the underlying models and providers. Some models may also be available at no cost, while paid models follow their respective usage rates.

Best for

OpenRouter is best for developers and AI teams that want a single API for accessing and experimenting with a large selection of models without managing multiple provider integrations themselves.

Explore OpenRouter

How to Choose the Right AI Gateway

Choosing an AI gateway is not about looking for the one that offers the most features. It's about understanding your application's needs as it develops.

Here’s what to consider:

How many models and vendors do I need to work with?

If your application relies on different providers, look for broad provider coverage, a uniform API, and consistent behavior across models. A gateway that simplifies switching providers can save significant engineering time as your application grows.

How critical are speed and dependability?

For customer-facing AI applications, gateway overhead and provider failures can directly affect the user experience. Look for fast request processing, automatic retries, availability-aware routing, and high availability. Bifrost is worth evaluating when low latency, throughput, and production reliability are priorities.

Do I want an open-source or a hosted solution?

An open-source gateway gives your team more control over deployment, customization, and infrastructure, but your team is responsible for operating it. A hosted gateway reduces maintenance and can simplify onboarding. Choose based on your team's infrastructure capabilities, security requirements, and need for operational control.

How do I keep track of AI costs?

As AI usage grows across applications and teams, costs can become harder to track. Look for budgets, rate limits, usage reports, and analytics that help you understand spending by model, provider, application, or team. Bifrost is worth considering when centralized cost controls and usage visibility are important.

Where will the gateway be implemented?

Consider your deployment requirements before choosing a gateway. A hosted service may suit teams that want minimal infrastructure work, while organizations with strict data-control requirements may need a private-cloud, VPC, on-premises, or air-gapped deployment. Bifrost supports these deployment models, making it a relevant option for enterprises that need greater control over their AI infrastructure.

A gateway that works perfectly for an early-stage application may not be the right choice once traffic, model usage, and operational requirements increase. Evaluating those constraints early makes the decision easier.

Frequently Asked Questions

What is an AI gateway used for?

→ An AI gateway provides a centralized layer between an application and the AI models or providers it uses. When evaluating the best AI gateways, look for capabilities such as model routing, authentication, retries, monitoring, rate limiting, and cost management.

This becomes more valuable as an application grows and starts using multiple models or providers. A centralized layer can keep provider-specific logic out of individual applications and give engineering teams a consistent way to manage AI traffic.

What is the difference between an AI gateway and an API gateway?

→ An API gateway is designed to manage traffic between applications and backend services, handling concerns such as authentication, routing, rate limiting, and request policies.

An AI gateway applies similar principles to AI workloads, but adds capabilities specific to model traffic. These can include model selection, provider routing, token and usage tracking, AI-specific fallbacks, prompt-related controls, and support for different model providers.

Should I use an open-source or managed AI gateway?

→ The right choice depends on how much infrastructure control your team needs and how much operational work it wants to take on.

Open-source gateways can provide greater control over deployment, configuration, customization, and data handling. They can be a good fit for teams with strong infrastructure capabilities or strict security requirements.

Managed gateways reduce the operational burden because the provider handles much of the underlying infrastructure. They can be attractive to teams that want to integrate multiple AI providers quickly without maintaining another production service.

Can an AI gateway reduce AI costs?

→ An AI gateway can help reduce and control AI spending, but it does not automatically make model usage cheaper.

Cost savings can come from capabilities such as model routing, caching, rate limits, budgets, and usage tracking. For example, an application can route simpler requests to lower-cost models, cache repeated requests, or enforce spending limits for individual teams or applications.

The actual savings depend on how the gateway is configured and how AI traffic is managed.

Do I need an AI gateway if my application only uses one AI provider?

→ Not necessarily. A small application using one provider may not need the additional infrastructure or operational layer.

An AI gateway can still be useful when the application needs centralized observability, rate limiting, cost controls, security policies, or a clean way to introduce additional models later. The decision should be based on the operational requirements of the application rather than simply the number of providers being used.

Final Thoughts

AI gateways are a core part of the architecture of production AI applications. As the number of models, providers, agents, and AI tools a team uses increases, managing each integration separately gets harder.

The five platforms in this guide address that challenge in different ways, but Bifrost is my top pick for production and enterprise AI workloads. Its combination of performance, reliability, routing, governance, and flexible deployment makes it a strong option for teams that need control over their AI infrastructure.

Bifrost unifies LLM gateway, MCP gateway, and agent capabilities in one platform. It also supports self-hosted, VPC, on-premises, and air-gapped deployments, which makes it a strong fit for enterprises with demanding security, governance, and infrastructure requirements.

The other gateways have clear use cases, too. Cloudflare AI Gateway is a natural fit for teams already using Cloudflare. Vercel AI Gateway suits teams building with Vercel and Next.js. LiteLLM is a flexible option for Python teams that want an open-source gateway, while OpenRouter is useful for developers who want broad model access through one API.

When comparing the best AI gateways, consider performance, reliability, model access, observability, cost controls, security, and deployment requirements. For teams running mission-critical AI workloads, Bifrost stands out as the leading choice in this comparison because it combines these production needs with enterprise governance and infrastructure flexibility.

For a simple application, a lightweight managed solution will do. For a larger AI platform that handles heavy production traffic, model routing, agent workflows, and enterprise policies, the gateway becomes an essential part of the architecture.

Choose the AI gateway based on the problems you need to solve. If production performance, reliability, governance, and deployment control are your priorities, Bifrost is the first option I'd evaluate.

Teams evaluating AI gateways can request a Bifrost demo or review the open-source repository.

Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah

Hadil Ben Abdallah

Software Engineer • Technical Writer (300K+ readers & 25K+ followers) • Trusted by 20+ startups and tech companies worldwide I turn brands into websites people 💙 to use

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 GMT

This is a submission for the Kaggle Benchmarking Challenge

One Eye, Zero Excuses

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

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

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

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

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

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

Let me tell you what I built.

What I Benchmarked

Why Georgian?

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

One of a Kind and Tough as Nails

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

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

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

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

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

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

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

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

What I Built

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

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

The Plan vs Reality

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

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

But...

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

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

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

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

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

The Five Tasks

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

1. Numbers: Counting in Twenties

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

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

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

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

2. Verbs: Who Did What to Whom?

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

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

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

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

3. Translation: Georgian to English

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

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

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

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

4. Cloze: Fill the Gaps

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

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

50 gaps, scored one by one.

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

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

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

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

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

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

17 paragraphs.

Writing It All by Hand

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

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

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

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

How It Runs on Kaggle

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

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

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


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


numbers.run(kbench.llm)

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

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

Obstacles and Workarounds

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

Obstacle 1: Kaggle Reserves the Worst Case

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

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

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

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

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

Obstacle 2: Failed Calls Look Like Wrong Answers

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

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

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

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

Obstacle 3: Some Models Think by Default

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

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

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

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

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

Obstacle 4: The Model That Won't Stop Thinking

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

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

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

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

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

Obstacle 5: Every Push Runs the Task

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

Obstacle 6: The Small Stuff

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

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

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

Models Tested

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

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

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

Here are the rules every model played by:

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

Findings

Drumroll, please. 🥁

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

Level by Level

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

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

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

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

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

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

Finding 2: Numbers Are the Final Boss

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

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

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

Finding 3: The Mistakes Are Very Georgian

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

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

Finding 4: Georgian Costs More Tokens for Claude

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

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

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

Finding 5: Cheap Can Be Smart

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

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

Side Quest: The Uninvited Guest

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

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

What It All Cost

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

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

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

The Dashboard

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

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

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

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

Limitations

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

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

What's Next

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

My Benchmark

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

Wrapping Up

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

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

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

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

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

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

dev.to top (week)

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

🔧 The Builder's Garage

🎩Giorgi Kobaidze (yes, that's me)

What I Learned From Reading All of This

The Doors Will Open Again

Dev Opportunity Radar #21: $500K Y Combinator Funding, Bolt Builders Week, and AI Safety Research Residency

Table of Contents

⚡ Quick Scan

Opportunities

Resource Highlight

🔄 Still Open From Previous Editions