Forem: Giorgi Kobaidze

The Final 1% of Every GitHub Project: Sealing It Properly

Giorgi Kobaidze — Sat, 11 Apr 2026 15:55:53 +0000

Introduction
What Does It Mean to "Seal" a Project?
The Release Checklist
- README
- The "About" Section
- Branch Hygiene
- Release Tags
- Branch and Tag Rulesets
- New Release and Release Notes
- Move All Tasks to Done
- Choose a License for Your Project
- CI/CD Status & Pipeline Health
- Versioned Builds & Artifacts
- Optional: Write an Article or Record a Demo Video
Here's the Full Checklist to Copy and Use
Finish as Strong as You Start

Introduction

You're sitting at your desk excited, sleep-deprived, but still genuinely happy.

After weeks, maybe even months of grinding, you're finally ready to show your project to the world, or your team.

This is the moment you've been waiting for.
Time to publish, share, and feel proud of what you've built.

But hold on

You might not be done just yet.

There's that final 1% you need to take care of before even thinking about wrapping things up - the part where you truly seal your project.

Because "done" usually just means the code works.

❓ But is it versioned?
❓ Can someone else understand it?
❓ Is it safe to deploy?
❓ Can your future self come back to it without pain?

That last 1% isn't about writing more code.
It's about making your project ready for the real world.

And that's exactly what most developers overlook.

What Does It Mean to "Seal" a Project?

Well, that's what I call it, but it's not really about the repository as a whole. It's about every single version of your product.

Every time you release something, you're not just shipping code, you're shipping a complete unit. A version that should stand on its own: deployable, tested, and fully functional.

But that's only the baseline.

A properly "sealed" version is also:

Well-documented
Clearly versioned
Properly packaged
Easy to understand and use
Presented in a way that others (or your future self) can trust

You need a well-defined checklist to go through before you can call it done. Let's go through them one by one.

The Release Checklist

This isn't a definitive list, it's my personal approach. You might find it helpful, but everyone has their own way of properly wrapping up a project or repository.

README

Duh, right?

It might sound obvious, but you'd be surprised how many repositories either don't have a README at all, or have one that barely says anything useful.

Your README should be the main entry point to your project.
If someone can't understand, set up, or use your project from it without any hassle, it's not good enough.

A solid README should answer the basic questions:

❓ What is this project?
❓ Why does it exist?
❓ How do I run it?
❓ How do I use it?

And many more important questions.

I'll write a separate article on how to craft an effective README that's actually useful, because it deserves that level of attention.

But for now, just remember this:
README is never optional, it's one of the most essential parts of your project.

The "About" Section

The About section is one of the most important parts of a repository. It provides a quick, high-level overview of the project and makes it easier for others to immediately understand what it is about.

It can include a short description of the repository, a demo or live link, and other quick-access resources like documentation or a website. It also surfaces key repository metadata such as stars, forks, and watchers, giving instant context about the project's popularity and activity.

In addition, the About section allows you to enable or disable different repository features and visibility components, helping you control what information is highlighted on the repo page.

One of its most powerful features is tags (topics). Tags improve searchability and discovery by helping your repository appear in relevant searches and topic-based browsing. They also communicate the tech stack and domain of your project at a glance.

Used properly, the About section becomes a compact "control panel" for your repository's identity, visibility, and discoverability.

Branch Hygiene

When writing code, you usually end up creating a number of temporary branches like feature, bugfix, documentation, refactor, and so on.

Some developers stay disciplined and clean them up right after they're merged into permanent branches like main, develop, or release. Others, however, leave them behind, where they slowly accumulate in the repository without any real purpose.

That doesn't leave a great impression for someone exploring your project or considering a contribution. It's a bit like walking into someone's house and seeing empty soda cans, pizza boxes, and empty, expired snack wrappers scattered all over the living room and kitchen, you immediately feel that things aren't being maintained properly.

More importantly, it creates internal confusion over time. You'll eventually find yourself asking: "Do we still need this branch? Why is it still here?" In many cases, it's just forgotten, not intentionally kept.

Keeping your branch list clean is a small habit, but it improves clarity, reduces cognitive load, and makes repository maintenance much easier in the long run.

So once development work is finished and merged, make it a habit to remove temporary branches and keep only the long-lived ones like main, develop, and release (not limited to these three, there can be more).

A clean repository isn't just about code, it's about discipline and clarity.

Release Tags

Release tags are one of the most important but often overlooked parts of properly sealing a project.

A tag marks a specific point in your repository's history as a meaningful version, such as v1.0.1, v1.2.3, or v2.0.0. Unlike branches, tags are immutable - they permanently point to a specific commit. This makes them ideal for representing official releases.

Without tags, it becomes harder to track what version was deployed, compare changes between releases, or reliably roll back if something breaks. With proper version tagging, every release becomes a clear and reproducible snapshot of your project.

Most teams follow semantic versioning (MAJOR.MINOR.PATCH), which communicates the nature of changes:

MAJOR: breaking changes
MINOR: new features, backward compatible
PATCH: bug fixes

In my own workflow, I sometimes take this a step further. Alongside a release tag like 1.0.1, I also create a corresponding branch such as release/1.0.1. I treat it as an immutable reference point that mirrors the tagged commit.

This is my personal approach, and it's not the only way to handle releases. Many developers or teams rely solely on tags, while others use release branches for stabilization, CI/CD workflows, or long-term maintenance.

Tags are often sufficient on their own, but in certain workflows, combining them with release branches can add flexibility and clarity.

In short, a release tag gives you a stable reference. How you structure around it depends on your workflow and team preferences.

Branch and Tag Rulesets

GitHub provides rulesets (under repository settings → rules) that let you define and enforce policies for both branches and tags. This is an important but often overlooked part of properly "sealing" a project.

Rulesets allow you to control what is allowed and what is restricted in your repository. For branches, you can enforce things like requiring pull requests before merging, requiring status checks to pass, blocking force pushes, and restricting direct commits to important branches like main, develop, or release/*.

For tags, rulesets are just as important. You can control who is allowed to create or modify tags, enforce naming patterns (such as semantic versioning like v1.2.3), and prevent accidental or unauthorized releases from being created.

Together, branch and tag rulesets help ensure that your repository follows a predictable and safe workflow. They prevent accidental changes to critical branches and protect release integrity by making sure that versions are created in a controlled and consistent way.

In practice, I use these rulesets to enforce discipline around my workflow. For example, I restrict direct pushes to main, require pull request reviews, and ensure that release tags follow a strict versioning format. This helps keep the repository clean, predictable, and production-ready.

That said, rulesets are flexible and highly team-dependent. Different projects will have different levels of strictness depending on their size, deployment strategy, and collaboration model.

At a high level, rulesets are what turn a repository from "just code" into a controlled system with enforced structure and reliability. I'll discuss more about the best practices of rulesets in a separate article.

New Release and Release Notes

A project version is not truly complete until it has been published as an official release.

In GitHub terms, this means creating a release tied to a specific tag, marking a stable and meaningful snapshot of your codebase. However, the release itself is only half of the story.

A release is not complete until it is accompanied by proper release notes that describe what has changed since the previous version.

Release notes are not a "nice to have", they are critical. They are the primary way for users, consumers, contributors, and dependent teams/developers to understand what has changed, why it changed, and how it might affect them.

Good release notes typically include:

New features added
Bug fixes
Breaking changes
Internal improvements or refactors
Migration notes or required actions

That said, not everything from this list might be applicable to every release.

Without this context, even a well-versioned release becomes difficult to use safely. People are left guessing what changed, which increases the risk of integration issues and misunderstandings.

A well-written release note also improves collaboration. It acts as a communication layer between development and usage, ensuring that changes are transparent and traceable.

Here is a simple example of the v1.0.0 release notes for the Metal Birds Watch project:

Move All Tasks to Done

One often overlooked part of properly finishing a project is cleaning up your task tracking system, especially in GitHub Projects.

Before considering a version truly complete, all relevant tasks should be either completed, closed, or moved to a final "Done" state. This ensures that the project board accurately reflects the actual state of the work.

Leaving tasks in "In Progress" or "To Do" after a release creates confusion. It becomes unclear whether something was forgotten, postponed, or simply not tracked properly. Over time, this reduces trust in the project's planning and documentation.

A clean project board has a psychological impact as well. It gives a clear sense of closure and helps both contributors and maintainers understand that a release cycle has been fully completed.

In addition, GitHub Projects can act as a historical record of work. Keeping it clean and properly closed makes it easier to review past development cycles and understand what was delivered in each release.

So before you consider a version fully "sealed", make sure the work is not only merged, but also properly reflected in your project board. Everything should either be done, closed, or intentionally moved forward into the next iteration.

Choose a License for Your Project

One of the most commonly overlooked parts of finishing a project is adding a proper license.

A license defines how others are allowed to use your code, whether they can modify it, distribute it, use it commercially, or build on top of it. Without a license, your project is technically "all rights reserved" by default, meaning others don't actually have legal permission to use it in most contexts.

This is especially important if your repository is public. People may be interested in learning from your work, contributing to it, or using it as a dependency. Without a clear license, you're creating uncertainty around what is and isn't allowed.

Choosing a license doesn't need to be complicated. Many projects use standard options like MIT, Apache 2.0, or GPL, depending on how permissive or restrictive they want to be. The key is not which license you choose, but that you choose one deliberately.

Adding a license is a small step, but it completes an essential part of the project's "contract" with its users.

A project without a license is unfinished in a different way, it may work technically, but it's not fully ready for real-world use.

CI/CD Status & Pipeline Health

A project is not truly "done" if your CI/CD pipeline is broken or unreliable.

Before considering a release complete, you should always ensure that your automation pipelines are in a healthy state. This includes making sure that builds run successfully, tests pass consistently, and deployment workflows behave as expected.

CI/CD is often the first thing that silently breaks over time. A small change in dependencies, configuration, or environment setup can easily lead to failing pipelines, even if the application itself seems fine locally.

That's why pipeline health is part of the final 1% of sealing a project. It ensures that your code is not only working on your machine, but is also reliably validated and deployable in an automated environment.

A properly sealed project should have:

✅ Green build status on all required branches
✅ Passing unit and integration tests
✅ Stable and repeatable workflows
✅ No failing or outdated GitHub Actions (or equivalent pipelines)

If your pipeline is broken, your release is not really safe, no matter how good the code looks.

Versioned Builds & Artifacts

Another critical part of properly finishing a project is ensuring that your builds and artifacts are versioned and reproducible.

A release should not just exist in source code, it should exist as a concrete, identifiable output that can be built, stored, and retrieved at any time.

Versioned builds ensure that every release corresponds exactly to a specific state of your codebase. Whether it's a compiled binary, a Docker image, a NuGet package, or any other artifact, it should always be traceable back to a specific tag or commit.

Without this, deployments become unreliable. You may end up in situations where:

You cannot reproduce an older version of the application
Different environments produce different outputs
Rolling back becomes difficult or impossible

A properly sealed project ensures that:

Every release is tied to a versioned artifact
Artifacts are stored in a consistent registry or repository
Builds are reproducible from source at any time
Tags, versions, and artifacts are aligned

In mature systems, this is often automated through CI/CD pipelines, where every tag or release automatically produces a versioned build artifact.

In short, if you cannot rebuild and retrieve a specific version of your project, then the release is not truly complete, it is only partially sealed.

Optional: Write an Article or Record a Demo Video

This step is optional and rightfully so. Not everyone needs to go this far, because a well-written README and proper release notes usually cover the essentials.

However, if you want to truly showcase your work in a more complete and impactful way, consider going beyond the repository itself.

Writing an article about your project allows you to explain the motivation, design decisions, challenges, and solutions in a structured and human-readable format. It gives context that code alone often cannot communicate.

Taking it a step further, recording a short demo video can be even more powerful. It lets people see your project in action, understand its behavior instantly, and get a feel for the user experience without needing to set anything up. This is often the fastest way to communicate value.

This combination, an article or a demo, also helps you improve your communication and presentation skills, which are just as important as technical ability.

Because no matter how good your application is, if it's not presented properly, it might never get the attention it deserves.

Here's the Full Checklist to Copy and Use

✅ README
✅ The "About" Section
✅ Branch Hygiene
✅ Release Tags
✅ Branch and Tag Rulesets
✅ New Release and Release Notes
✅ Move All Tasks to Done
✅ Choose a License for Your Project
✅ CI/CD Status & Pipeline Health
✅ Versioned Builds & Artifacts
✅ Optional: Write an Article or Record a Demo Video

Finish as Strong as You Start

Sometimes we're so desperate to finish a project that we rush through the final steps and end up missing important details. When that happens, keep in mind to slow down, take a deep breath, and remind ourselves that finishing well is just as important as starting well.

Think of a brand-new car missing a taillight or a side mirror - it still works, but it's not complete, and it's not safe, and it looks ugly. Unfinished or rushed projects feel the same: something important is missing.

If you've already committed to doing something, take the extra time to do it properly. Be a strong finisher. Be someone who completes things with care and intention.

365 Days of Building in Public, Perfectly Reflected By My Badges

Giorgi Kobaidze — Thu, 02 Apr 2026 21:24:26 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

Introduction
365
Your DEV Badges Are Trying to Tell Your Story. Listen to Them
One Year Club
- "Hey Mom, Your Son Is a Software Engineer"
- And That's When I Discovered DEV Community
Two & Three Year Club
- Fast forward to 2020
- Boom: The Pandemic Hits. And It Hits Real Bad
- I Had to Carve Time Out of Thin Air
- If You're Expecting a Happy Ending, You Won't Find It Here
Four, Five, Six & Seven Year Club
- I Refuse to Catch a Break, Ever
- Then I Finally Started to Feel Comfortable... I Absolutely Hated It
Writing Debut
Community Wellness Streak
Top 7
- I'm All In on AI, But We Need to Talk About Vibe Coding
- 20 Rules for Becoming THAT Manager (From a Principal Engineer's Perspective)
- Can AI Generate Binary Directly? Is It Feasible? Does It Make Sense?
C#
Eight Year Club
GitHub Copilot CLI Challenge Winner
DEV Weekend Challenge Completion
Still Not Convinced?!
Time to Play the Game

Introduction

I keep all my articles tucked away in a private repository on GitHub. It's not just storage, it's more like an archive of how I think, how I grow, and sometimes, how I struggle.

Over time, it naturally shaped itself into a few categories:

Analysis
Career
Technical
Challenges
Specials

You could argue this belongs in the "Challenges" category. And you wouldn't be wrong. But I chose "Specials" instead. Because this isn't just another challenge. It's something different... something that stays with you.

The moment @jess announced this challenge and I read the description, it actually made me smile, because right away I knew exactly what I would write. I have zero ideas for the Frontend Art challenge, my creativity sometimes isn't performing at its best.

Since that frontend challenge is out of the question, well, here I am, offering the textual representation of the intense signals firing in my brain. This article won't be technical at all (which is by design), more like an easy-going, reflective piece to read while you're chilling in your favorite chair, in your room, garden, or porch, sipping your coffee, tea, or whatever your favorite beverage is.

Right now, I don't have an internet connection and for the first time, I'm actually grateful. No notifications, no tabs, no distractions. Just the quiet hum of my thoughts, letting me focus on writing this.

Strap in. We're about to take a little journey through my brain, neuron by neuron. And make sure you read it all the way to the end, because I'm about to play a game with you that might just change your entire life.

365

The timing of this challenge couldn't have been better.

Why?

Because it's March 2026 (at the moment of writing this article), which means I published my first article a year ago. And this anniversary fits perfectly with the spirit of the challenge.

This past year has been spectacularly amazing. There's so much to reflect on that I don't even know where to start, and I definitely can't recall everything in one go. Of course, I won't try to fit it all into this article, that would turn it into a small book.

But being brief isn't easy either. Anyone familiar with my writing knows I'm really terrible at keeping things short. I like providing as many details as possible, whether technical or non-technical. Definitely something I need to work on.

Your DEV Badges Are Trying to Tell Your Story. Listen to Them

I don't want this to be a generic storytelling of my journey, I'll save that for when I write a proper, comprehensive lookback.

Instead, I want to show how my badges on DEV Community can actually tell my story. And honestly, it's surprising how accurate they are, I can't believe I hadn't noticed it before.

If you take a close look at them, they form a perfect timeline of what you've been doing on this amazing platform. They give you a ton of context about your values, your focus, and your performance.

These aren't just random badges, icons hanging on your profile. They're trying to tell your story. They have purpose. They are your path. Your signature.

Let me show you, using my example.

One Year Club

"Hey Mom, Your Son Is a Software Engineer"

I know I should reflect on the past year, but to see the full picture, I need to go much further back than that.

I've known DEV since 2017, when I first started coding professionally as a junior developer. Good times... man, I was so happy. I even remember stepping out of my final interview and calling my mom right away. I was like, "Hey Mom, your son is officially a software engineer! How cool is that?!"

That very moment didn't just define my career, it defined my life. I had never felt that proud of myself before.

Back then, in my country, getting a job as a junior software engineer was almost impossible, everybody wanted seniors. And when you somehow did land a junior role, eager to learn as much as possible, they expected you to handle senior developer tasks as quickly as possible, with little to no guidance.

Sure, reaching that level is the goal for every junior developer, but when it comes paired with immense pressure, things can get tricky, sometimes really tricky.

I remember being trapped in a vicious cycle, wanting to excel at work while also trying to learn as many things as possible in every direction. I ended up stressing myself out even more than the work did, and there were times I even questioned if I was good enough. Impostor syndrome is one hell of a thing.

And That's When I Discovered DEV Community

A few months after I started working, I came across a really interesting article on DEV Community. I was at home, writing code, when it just popped up and it completely blew my mind. I wish I had saved it.

Back then, I wasn't trying to get involved in any kind of community. I'd just occasionally stumble upon articles on the platform, and whenever a title caught my eye, I'd read it.

One day in 2018, I decided to join DEV Community. I was already reading most of the articles there and wanted to give something back, even if it was just my presence, or a few comments here and there.

Back then, I didn't think I was worthy of writing articles. I believed it was only for the most experienced, veteran, superstar developers, how wrong I was. I wish I had started writing from the moment I registered.

So you, yeah, you, reading this, if you're hesitating about whether to start writing, just start. Do it NOW! You'll thank me in a few months. Mark my words.

Two & Three Year Club

Fast forward to 2020

Even though there are so many stories from that fast-forward period, I want to move quickly to the more recent years. I'll save the tales of all the things I faced back then for another time, there will be other opportunities to share them.

I stayed pretty passive for a few years. Then, sometime in 2020, I started leaving comments on other people's articles, and that alone already made me feel like part of the community. It felt really good.

I'm not trying to make excuses, but in my defense, that period was extremely tough. I had been selected to continue my PhD research at SDSU (San Diego State University). Everything was set — and then...

Boom: The Pandemic Hits. And It Hits Real Bad

Everything shut down instantly. Flights were canceled, programs postponed, the whole world shifted to remote, including universities. So my plans of continuing my PhD just went out the window.

That was something I had wanted since I was a teenager. And just like that, for reasons completely out of my control, that perfect opportunity was gone overnight.

I'm not the type of person who gives up easily, so when they offered continuing it remotely from my country, I said, "hell yeah, I'm in! Count me in!"

But there was a small catch: I was working full-time during the day, and then getting into my research in the evening, when it was still morning for my co-researchers in California.

So my schedule basically looked like this:

So I basically only had a few hours to work on my research - late at night, when my brain was completely exhausted and there was barely any energy left for creativity. Sometimes I'd stay up until 3 AM or even later, barely getting any sleep.

The next day, I'd be so drained that I'd fall asleep right after the meeting, I just couldn't keep my head up anymore. That kind of inconsistency destroys your productivity, and I was feeling miserable.

But no matter how I felt, I just don't give up. I'm not trying to sound cool, it's just who I am. I don't trust my own brain or body when they tell me I'm tired or exhausted or I can't do it anymore. I convince myself they're just being lazy, that I can push even further.

Even if I dropped unconscious in the street after a few sleepless nights, I'd still try to work on my PhD. That's just how I'm wired.

Is it a good trait?
That's debatable. Probably not.

I Had to Carve Time Out of Thin Air

I was trying everything to find extra time. I didn't even have a car back then, and I was losing way too much time commuting. So I decided to spend most of my savings to get one (which I still have, by the way, I'm way too loyal).

But that wasn't all. I also changed jobs and joined a company that would let me work from home. That alone saved me around 2–3 hours a day, and at that time, it felt like the best decision ever.

I started there as a senior software engineer, which is even tougher than starting out as a junior, because the expectations are there from day one. Literally. You're expected to do senior-level work, and you're expected to do it well.

If You're Expecting a Happy Ending, You Won't Find It Here

That stretch lasted for about two years. Eventually, I was finally able to move to the right time zone and continue working on my PhD properly.

But

The timing, and the circumstances couldn't have been worse.

The university was still partially closed. COVID was still very much a thing. We didn't meet often as a research team.

Because of my schedule over those two years, my co-researchers were already far ahead. Some of them were even thinking about moving on to other programs. The group was slowly coming to an end.

And on top of everything, it was decided that I had only a few months to finish my research. Not more.

If you've ever worked on a PhD, you know that finishing your first research in such a short time is nearly impossible. Yes, I had those two years before that...

But did I really?

This whole pandemic situation really messed up my PhD plans. I still managed to get some work done, but I wasn't happy with my progress.

That entire experience completely broke me. I just can't handle losing or not succeeding, I have to win. Doesn't matter if it's my PhD or playing with my cat. Sorry, Ruby.

I'm honestly jealous of people who can lose and just say, "yeah, whatever." I wish I could do that. And I do understand that failure is necessary for growth, sometimes even more than success.

But still... it leaves scar tissues.

Four, Five, Six & Seven Year Club

I Refuse to Catch a Break, Ever

So I became a principal engineer, which was multiple levels harder than what I'd been doing as a senior software engineer.

Granted, I no longer had to work on my PhD, since the program had ended. But transition periods are never easy, they demand your full focus - I had to level up both my technical and management skills to become a solid principal engineer. Because even if you're a technical genius, if you can't manage people, your products, your services, and your communication properly, you simply can't be a strong principal engineer. You really need to be good at... pretty much everything. You're the bridge between multiple different teams and people: technical, product, leadership, and more.

So it's not just about being good at each of those areas, but also figuring out how to manage communication between all those levels and roles.

Yeah... it's a little tricky, to say the least.

I once published an article: 20 Rules for Becoming THAT Manager (From a Principal Engineer’s Perspective). A reader left a comment that really stuck with me:

"After more than 35 years of engineering management, the only comment I need to make is: You have arrived early my friend. You expressed most of what needs to be said, and extremely more eloquently than I could ever wish to do. Brilliant! I just wish everybody, regardless of the profession would read this slowly and thoughtfully. It would make the world a better place. Thanks for taking the time. I can't say that I enjoyed reading anything on the subject more - ever."

That comment absolutely made my day, especially coming from such an experienced veteran. But the truth is, I had to be an early bird. My career accelerated incredibly fast, or rather, I forced it to, because I desperately needed to get my life on track and fast, because there's no time to waste. Out of curiosity, I asked ChatGPT about the average ages for different levels of software engineers, and here is what it told me:

Typical path:

Junior → Mid: early–mid 20s
Senior: late 20s–early 30s
Staff: early–mid 30s
Principal: late 30s → mid 40s (most common)

I had just turned 27 when I became a principal engineer. Now, at 30, I feel like it had to happen that quickly, because you are never truly ready for anything until you actually try it. My philosophy has always been this: don't worry if a challenge sounds hard. As long as it sounds even a tiny bit reasonable, jump in and figure things out as you go. Otherwise, you will spend your entire life just getting ready. That mindset has always worked for me. Almost every challenge I've tackled has turned out to be much easier than I expected. I'm sure it would have worked with my PhD, too, if it weren't for COVID and all the chaos it brought to the world.

Then I Finally Started to Feel Comfortable... I Absolutely Hated It

This madness continued until about 2024. Once I noticed I was starting to feel comfortable in my new position, with more free time and mental capacity after work, the thought of writing articles snuck back into my mind. I had a few ideas, but I lacked the courage to start. That lingering trauma of not achieving my PhD was still echoing in my brain (and to be honest, it still does, but it's much more manageable now).

For some reason, I need to be in constant motion to feel alive. I have to direct my thoughts toward something productive, it doesn't matter whether that means tackling a new project, drafting an article, washing my car, organizing my workspace, or getting a workout in.

I spent a lot of time sketching out drafts only to abandon them, convinced they weren't good enough. I threw away five or six different articles. Even though I already had a huge experience, I still couldn't shake the feeling that public writing just wasn't for me...

Until March 8th, 2025.

Writing Debut

It hit me while I was having my morning coffee, which is a brief period of the day when I can step back and reflect. I was overthinking the idea of blogging when I suddenly remembered my own "doer" mindset. A wave of frustration washed over me as I realized I was betraying my own rules. What kind of leader am I if I abandon my own principles?! I actually said out loud, "What the hell is wrong with you, man? Is that all you got?!"

That verbal reality check was all I needed. I gave myself a few days to commit to a topic and force it onto the page. That was how Understanding Your Audience as a Software Engineer came to life. While the article itself isn't a masterpiece, it remains special to me. It marks the precise starting point of my writing addiction.

I had no idea how the community would react to my first article, but I was genuinely surprised by how well it was received. And you know how it goes: when you realize you're actually decent at something and it's also a lot of fun, you can't stop. You just want to do it over and over again. That's exactly what happened to me. I just carried on.

Community Wellness Streak

Writing is great, but if you really want to contribute to your community at the highest level, you have to read other people's work and engage in the comments. Over time, I've developed a few rules I always follow whenever I leave a comment:

1. Always write a high-quality comment

Be professional. This is your image as a community member and creator. Nobody likes to see an unprofessional or even slightly offensive comment on their posts. You won't make any friends by being arrogant.

2. Be a decent human being

Express appreciation for other people's work. They took the time to deliver a product to you, whether it's an article, a project, or anything else. Show them that you appreciate that effort.

3. Include as many details as possible

Be comprehensive about your ideas. A comment doesn't have to be just a few words. I've seen comments that are better than many articles. Write thought-provoking, interesting ideas and show your thinking process.

4. If you disagree, explain your point of view clearly

Never offend or ridicule an author, even if you think a blog post is total nonsense. An offensive or mocking comment says a lot more about the commenter than it does about the author.

5. Don't be a hater. It will just eat you from the inside

If someone else's post gathers way more engagement than yours, even if yours is 10 times longer and 20 times more complex, don't feel like you were treated unfairly. I usually write large, technical posts (some might even be a 20-minute read), and it's entirely natural that they won't get as many likes because not everyone is interested in that level of detail. I've seen two-paragraph posts reach incredible engagement because they are highly relatable and draw people in easily. Writing those kinds of articles is a real talent, and it's not easy at all. I myself am not great at it. Check out this very article, it's a monster, and it might not even get 10 likes. But that's okay with me because I write to share my knowledge and experience, not to chase and collect likes.

6. Never rush to press the "submit" button

Read your comment again to make sure none of the previous five rules are broken.

Sometimes, I get so absorbed in writing my own articles that I completely forget to check out what other people are publishing and leave comments. To fix this, I use any spare minutes I have to read at least one article a day. Whether you are writing or engaging with others, consistency is always the key. That's how I managed to reach the "8 Week Community Wellness Streak" badge, and I'm going for the "16 week" one next.

Top 7

Now, let's talk about the articles that were especially successful, the ones that made it onto the weekly top 7 list. I never imagined I would hit that milestone even once, let alone three times.

I'm All In on AI, But We Need to Talk About Vibe Coding

Giorgi Kobaidze

Jun 24 '25

I'm All In on AI, But We Need to Talk About Vibe Coding

#ai #vibecoding #machinelearning #coding

126

Comments 64

16 min read

This particular article took off faster than I could have imagined. It went so viral that I actually came across it in the Google feed on my phone.

Let me tell you, sitting there looking at my own article on my homepage... that was a genuinely proud moment.

I had been thinking about that idea for ages before I finally brought it to life and published it. I literally spent a solid three months just thinking and planning. It even led to a podcast invitation, after which I wrote a reflective article where I mentioned something like this:

...this was the result of nearly three months of thinking, writing, grinding, editing, and second-guessing. I kind of knew what Axl Rose must've felt like when releasing "November Rain" after working on it for nearly a decade. (Okay, I'm joking, I'm nowhere near Axl's level in any way. It's just a bad analogy. But as a rock fan, I had to make it.)...

That article definitely felt like I had created something special, and that was the moment I got totally addicted to writing, forever. As I mentioned, it even landed me a guest spot on a podcast, which was an incredibly cool experience.

20 Rules for Becoming THAT Manager (From a Principal Engineer's Perspective)

Giorgi Kobaidze

Jul 19 '25

20 Rules for Becoming THAT Manager (From a Principal Engineer’s Perspective)

#management #softskills #leadership #career

Comments 15

10 min read

About a month later, I wrote "20 Rules for Becoming THAT Manager (From a Principal Engineer's Perspective)".

It's funny because, unlike the vibe coding article, I wrote this one completely spontaneously. I was sitting in my car in a parking lot with time to kill, realized my laptop was in the backseat, and just started typing. That actually worked out perfectly because it allowed me to write purely from my raw experience as both an engineer and a development lead.

That article was special. I wanted to create a set of notes for myself and for others on what it takes to be a good manager. I've seen all kinds of leaders in my career: the good, the great, the bad, and the absolute worst as well. Through it all, I gathered enough data to know exactly the kind of leader I want to be.

Being a leader is vastly harder than most people think. Some take it for granted, while others overthink it entirely. The whole magic is in finding the fine balance between the two.

By the way, I'm currently working on another article focused on leadership, and it's shaping up to be a good one. Stay tuned.

Can AI Generate Binary Directly? Is It Feasible? Does It Make Sense?

Giorgi Kobaidze

Mar 8

Can AI Generate Binary Directly? Is It Feasible? Does It Make Sense?

#discuss #ai #compilers #programming

Comments 14

11 min read

A few weeks ago, I wrote about the concept of AI generating binary code directly, a topic that, for whatever reason, suddenly became the internet's favorite subject to debate.

I noticed that most of the takes out there weren't very precise and were missing a few key points, so I decided to jump in and give my two cents. To my surprise, that piece also made it into the weekly top 7. Hitting that milestone three times in just under a year is a result I'm incredibly proud of.

`C#`

I'll admit, sometimes my articles can get intensely technical. Sometimes, they only resonate with specialists in that exact niche. But I love writing them. I'm a software engineer and I always have to scratch that itch to dive deep into the code, especially with .NET and C#.

I've built things across a bunch of languages like JavaScript, Python, Java, TypeScript, even C and C++, but C# is still my baby.

Getting that badge for the most popular C# article was an incredible feeling. Now? The goal is to collect a few more language badges to sit right next to it.

Eight Year Club

And amidst all of this, I just completed my 8th year on dev.to.

Sometimes a career in software can feel a bit dull and repetitive, but when you actually stop to reflect on the road so far, you realize how much you've been through. Honestly, you kind of question how on earth you remained sane.

Especially for a guy like me who doesn't look back too often, it's almost shocking how much you can learn just by checking your rearview mirror. But one thing is for sure: I ain't going anywhere anytime soon. I'm going to be right here with this community until the day I retire, and I never plan on retiring.

GitHub Copilot CLI Challenge Winner

This right here is my biggest achievement on the platform, and easily one of the proudest moments of my entire career.

I never actually thought I'd win my first real dev competition. Sure, I did some algorithmic challenges back in the day when I was still a junior developer, but those aren't real hackathons, they're mostly for the younger crowd, not a 30-year-old millennial.

Taking first place in my debut, especially in a massive challenge with over 400 people, was surreal. But the absolute best part? I won it by building Metal Birds Watch. It was an idea I had been keeping in my head for years, and this hackathon gave me the perfect excuse to finally bring it to life. I still catch myself smiling whenever I think about seeing my name sitting there at number one.

The Making of Metal Birds Watch:

If you'd like to know the story behind this idea and project, check out the following article:

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

Comments 17

11 min read

DEV Weekend Challenge Completion

I took on this challenge because I love spontaneous, short-term challenges. They allow me to test my speed and give me the intense drive to build something from start to finish in record time.

I wanted to create a project that would make people smile and feel a deep sense of pride in what they've created. The goal was to take their articles and turn them into something interactive, motivate the self-doubters to finally hit 'publish,' and even draw new people into the community. I was aiming for something totally unique... something actually fun.

That's how Sunday DEV Drive was born - a browser game.

You might be thinking: a browser game built by a backend engineer? But it turned out much better than I ever expected.

DEV Weekend Challenge: Community

Giorgi Kobaidze

Mar 1

Sunday DEV Drive: A Synthwave Driving Experience Through Your DEV Community Articles

#showdev #devchallenge #weekendchallenge

Comments 23

10 min read

Well, I didn't win this challenge because you can't win every competition, however you can learn from each one. That said, the feedback I received was so incredibly amazing that it felt like winning a championship all on its own. Plus, the badge is absolutely gorgeous.

Still Not Convinced?!

All of the things starting from writing my first article, happened within the span of a single year. If I can do all of this, so can you and you can achieve much more if you push harder than I did.

It's not about becoming famous, earning more money, or chasing status. It's about proving to yourself that you are capable of doing it all, and actually having fun in the process.

Whenever people doubt their skills or career choices, I always tell them the same thing: "If you lack confidence, build evidence." Once you start taking action: coding, writing, recording, that output becomes all the evidence you need. Just try it and see yourself how your life changes.

But I have a feeling you might still need a little more convincing. So, let's play a little game.

Time to Play the Game

Don't worry, I'm not Triple H, so I'm not going to jump out and hit you with a sledgehammer. But depending on how you play, the result of this game might feel like it.

The Game

Imagine it is the year [current year + 10].
Take a moment to really immerse yourself in that future.
You still haven't started building your personal projects or writing technical articles. You realize how much time you've lost and how much you could have accomplished in that decade.

You are frustrated and annoyed at yourself for never taking that first step. You feel like you failed... you spent your prime years idle, and now nobody will ever know what could have been if you had just tried. You would give ANYTHING to start over, knowing exactly how much better you would do. But you can't go back in time. Sad, isn't it?

...

Now, end your immersion. You are back in the present. You have just been gifted those 10 years back. Congratulations! You are the first person in the universe to be handed a decade of extra time to start over.

So... are you really going to waste that chance again?

Start NOW! Your journey begins right NOW!

NoteRunway: Because Your Notion Workspace Deserves an Elite Crew

Giorgi Kobaidze — Sun, 29 Mar 2026 20:54:06 +0000

This is a submission for the Notion MCP Challenge

What I Built
- Explanatory Video
- Introduction
- The Backstory
- The 7 Tools
Show us the code
How I Used Notion MCP
- The Architecture
- Why MCP and Not Just the API?
- Destructive Tool Safety
The Tech Behind It
- Multi-Provider AI (BYOK)
- The Archive System
Wrapping Up

What I Built

Explanatory Video

Introduction

NoteRunway: an AI-powered workspace management tool that helps Notion power users clean up, audit, and command their workspace through a single interface.

Think of it as a flight control tower for your Notion workspace. It scans for problems you didn't know you had, visualizes connections you couldn't see, and lets you talk to your workspace in plain English.

🔗 Live Demo → noterunway.pilotronica.com

The Backstory

I'm a Notion addict. Not the "I use it for grocery lists" kind, rather the "I have 400+ pages, nested databases inside databases, and a set of half-written ideas from 2 AM" kind.

It all started in 2020, when I decided it was time to bring more order into my life. My notes were scattered everywhere, there was some structure, but not nearly enough. I needed something more powerful... something more organized.

Then I discovered Notion and instantly knew it was exactly what I'd been looking for all along and didn't know existed.

You know how it goes, at first, you're fully motivated. Everything's clean, structured, flawless. You're convinced this time you'll manage your notes perfectly.

But sooner or later, every power user ends up in the same place: orphaned pages from long-forgotten projects, duplicate notes written three times because the first two vanished into the void, and dead links leading to pages you archived months ago.

And somewhere in that chaos, there's probably a note with an API key you definitely didn't mean to paste and leave it forever. Have you ever pasted an API key or secret thinking "I'm gonna move it somewhere more secure later"? And that "later" doesn't really come, does it?

I needed a tool that could see the bigger picture, something that could scan everything, something that'd surface what's broken, and help me fix it without blindly deleting content or forcing me to manually comb through bajillion pages.

When the Notion MCP Challenge dropped, it clicked right away. I could build that tool, and give something back to the Notion community while I'm at it.

The 7 Tools

NoteRunway packs 7 workspace management tools, split between pure scanners and AI-powered analyzers.

Think of it as a crew of seven tools at your disposal, everything you need to keep your Notion workspace in top shape. Each one has a specific role: some scan your workspace to surface hidden issues, others go deeper to analyze patterns and give you smarter insights.

Together, they cut through the clutter, highlight what actually needs attention, and help you clean things up without the risk of losing something important. No guesswork, no endless manual checks, just a clear view of your workspace and the tools to keep it running smoothly.

📊 Workspace Health Dashboard

Your workspace at a glance. Total pages, top-level pages, recently edited, empty pages, and link density (how well-connected your workspace actually is).

It's the "oh wow, I have how many empty pages?" moment.

🔍 Duplicate Detection

This is where the AI earns its keep. NoteRunway fetches up to 100 pages with their content snippets, sends them to the LLM with a specialized system prompt, and gets back semantic duplicate groups with similarity scores.

Not just "same title" duplicates, it catches pages with different names but overlapping content. The AI picks a recommended "keep" version (⭐), and you choose which ones to archive.

🗑️ Garbage Collector

Rule-based detection across three categories:

Orphaned — parent page was deleted, child is floating in limbo
Empty — zero content blocks (you created it and... forgot)
Stale — untouched for 90+ days (configurable)

Dry-run mode is on by default. You review everything before anything moves.

🔗 Dead Link Detector

Finds @mentions pointing to pages that no longer exist. Every broken mention is tracked back to its source page, so you know exactly where to fix it.

🔐 Sensitive Data Finder

Two-phase security scanner:

Phase 1 (Regex): Scans all pages against 13 patterns: API keys (OpenAI, Anthropic, Stripe, AWS, GitHub), PEM keys, JWTs, database URLs, passwords, credit cards. Findings are always partially redacted, never exposing full values.

Phase 2 (AI Deep Scan): Optionally sends page text to the LLM to catch natural-language secrets that regex misses. Things like "the password is hunter2" or "login: admin/secret123".

🕸️ Dependency Graph

An interactive force-directed graph of your entire workspace. Pages are nodes (colored by depth), connections are edges (solid for parent-child, dashed for @mentions). Orphaned pages glow red.

You can hover, click, collapse branches, and zoom around. It's surprisingly therapeutic to see your workspace as a living network.

💬 Semantic Ask (Agentic Chat)

A natural language interface to your workspace, powered by an agentic AI loop.

Type something like "Find all pages about authentication and summarize them" or "Archive everything in the old-project folder." The AI breaks it into tool calls (search, read, analyze), feeds results back into its context, and proposes structured actions for your approval.

It supports 5 action types: archive, create, rename, append, and update, all with a human-in-the-loop confirmation step. No action executes without your explicit "yes."

Just a heads-up: be cautious with destructive actions. Avoid updating or archiving critical data.

This project is still in beta, and I don't want you to risk losing important information. As you know, AI isn't deterministic, and unexpected outcomes can happen.

Show us the code

Here's the repository:

georgekobaidze / noterunway

NoteRunway

AI-Powered Notion Workspace Management

Clean, organize, and command your Notion workspace with AI. Powered by the Notion MCP.

🔗 Live Demo → noterunway.pilotronica.com

Overview

NoteRunway is a browser-based tool that helps Notion power users clean up, audit, and manage their workspace using a combination of deterministic scans and AI-powered intelligence via the Notion MCP.

It connects to your Notion workspace through OAuth, runs server-side analysis via Next.js API routes, and provides a cyberpunk-themed UI for reviewing findings and approving actions.

Core Principles

Principle	Description
Zero Lock-in	Your data stays in Notion. NoteRunway never stores workspace content.
Human-in-the-Loop	No destructive action runs without explicit user approval.
Privacy First	AI keys stored only in your browser (BYOK). Sent per-request to NoteRunway APIs and never persisted server-side.

…

View on GitHub

How I Used Notion MCP

This is the core of the whole project. NoteRunway uses the Notion MCP Server as the execution layer for all workspace interactions in the Semantic Ask feature.

The Architecture

Browser → Next.js API (SSE) → Vercel AI SDK → MCP Client → notion-mcp-server (stdio) → Notion API

Here's the flow:

User sends a message in the Ask interface
Vercel AI SDK processes it with streamText() and the selected LLM
When the AI decides it needs workspace data, it calls tools: search_pages, get_page, get_page_content, run_analysis
These tools route through MCPClient, which communicates with the Notion MCP server over stdio (JSON-RPC 2.0)
The MCP server translates tool calls into Notion API requests and returns structured results
Results feed back into the AI's context for the next reasoning step (up to 10 steps)
When the AI wants to make changes, it calls propose_actions, which streams proposed actions to the UI for human approval
Only after the user confirms does the action execute via MCP

Why MCP and Not Just the API?

I use both. Here's the split:

NotionClient (direct SDK) for bulk reads, workspace scans, pagination-heavy operations. It's faster for fetching 400 pages than routing through MCP.
MCPClient (MCP server) for all writes like creating, archiving, renaming, updating pages. MCP provides a sandboxed execution layer with tool-level safety.

This hybrid approach gives me the speed of direct API access with the safety of MCP's tool calling protocol.

Destructive Tool Safety

Any tool that modifies workspace data (patch, post-page, delete, move) requires an approved: true flag. The AI can propose actions, but nothing destructive runs without the user clicking "Execute."

The Tech Behind It

Layer	Technology	Why
Framework	Next.js 16 (App Router)	Full-stack React with API routes
AI SDK	Vercel AI SDK 6	Unified streaming + tool calling across 4 providers
MCP	@notionhq/notion-mcp-server	Notion workspace access via Model Context Protocol
Visualization	React Flow 11	Force-directed graph for the dependency viewer
Validation	Zod 4	Runtime schema validation for all API inputs/outputs
Styling	Tailwind CSS 4 + shadcn/ui	Cyberpunk aesthetic with accessible components

Multi-Provider AI (BYOK)

NoteRunway supports 4 AI providers with 13 models: OpenAI (GPT-5.4, GPT-5 Mini), Anthropic (Claude Opus 4.6, Haiku 4.5), xAI (Grok 4, Grok 3), and Google (Gemini 2.5 Pro/Flash).

Your API key stays in your browser's localStorage. It's sent per-request in an HTTP header, used once to create a provider instance, and discarded. NoteRunway's server never stores, logs, or persists your key.

The Archive System

Every destructive action creates an audit trail:

NoteRunway Archive/
├── Duplicates/
│   └── [Audit Stub] Original Title
├── Garbage Collection/
│   └── [Audit Stub] Stale Page Name
└── Semantic Ask/
    └── [Audit Stub] Archived via Chat

Each audit stub contains a callout with the archive date, reason, and a faithful copy of the original content. The original page is soft-archived to Notion's trash (recoverable for 30 days).

Nothing is ever truly deleted without a paper trail.

Wrapping Up

NoteRunway started as a personal itch, a messy workspace and a dev challenge deadline. It turned into something I'm going to use every week.

Building with the Notion MCP was a revelation. The ability to give an AI structured access to a workspace, with tool-level control over what it can read and write, opens up workflows that feel like magic. Ask a question, get an answer sourced from your actual pages. Propose a cleanup, review it, execute it. All in one flow.

If you're a Notion power user drowning in pages, give it a spin: noterunway.pilotronica.com

And if you find an API key you forgot about in a meeting note... you're welcome. 😄

Built with ☕ and too many late nights by Giorgi Kobaidze

Can AI Generate Binary Directly? Is It Feasible? Does It Make Sense?

Giorgi Kobaidze — Sun, 08 Mar 2026 20:33:41 +0000

Introduction
From Prompt to Binary Code
- Is It Even Feasible?
- Is It Worth It?
- Things That Almost Everyone Gets Wrong
- So What Are the Actual Problems with This Approach?
- Generalized Prompt Repetition Formula
- Example
- How Can AI Be Helpful for Modern Compilers?
Summary

Introduction

Exciting, futuristic ideas tend to gain traction quickly. Whether they are realistic or not often matters less at first. After all, no one can truly prove an idea will work until someone actually attempts it. The concept alone can still be exciting enough to capture everyone's attention.

However, that initial excitement often fades once people begin to analyze the complexities, trade-offs, and potential downsides. In many cases the idea ultimately proves to be feasible, but the path toward making it practical and usable can lead in directions no one initially anticipated.

From Prompt to Binary Code

In this article, I want to explore the idea of generating binary directly from a prompt, without first producing human-readable source code.

In other words, the goal would be to bypass the traditional steps in the compilation pipeline that normally transform human-written code into a final executable binary.

The process can be visualized like this:

Prompt → AI → Binary

This approach eliminates many of the intermediate components typically involved in producing an executable:

No source code required
No compilation or interpretation needed
No intermediate representation, such as IL in C#

On paper, this sounds appealing: so many steps are skipped, product creation could be faster and more streamlined, and AI could generate binary directly without worrying about programming languages or their specifications.

It sounds like a logical next step, right?

Well... not quite. This is far from the most practical approach, at least for the near, or even distant future.

Let's break down why this idea is problematic, but before we do, let's quickly address one of the more controversial questions.

Is It Even Feasible?

Many people quickly dismiss this idea because they assume AI simply cannot generate binary directly. That's understandable, AI can only learn from the data that exists, and there's very little information about writing software directly in binary. After all, humans don't and can't do it (well unless your idea of fun is debugging a bajillion bits at 2 AM).

However, that doesn't mean it's impossible (I mean training AI models, not debugging binary). Technically, it is feasible. You could take existing source code, there's no shortage of it, compile it to produce binary, and then create a source code <-> binary code dataset to train AI models.

As you might imagine, though, this would require astronomical amounts of data and computational resources, making it extremely expensive. Which brings us to the next question.

Is It Worth It?

This question requires a deeper analysis on multiple levels. Let's examine each point one by one.

What's the Point of Source Code, Anyway?

To explore this question, I'll refer back to my very first article on this platform and link an important section for this context.

Giorgi Kobaidze

Mar 25 '25

Understanding Your Audience as a Software Engineer

#discuss #softwareengineering #programming #productivity

Comments

7 min read

If you don't feel like reading another article, here's a brief summary of the key points from that section:

Software code isn't primarily for computers, it's for humans. Computers don't "understand" programming languages directly, they require translation into machine code via compilers, interpreters, or virtual machines. Programming languages are designed to be human-readable so developers can write, read, and maintain code effectively. Clear, structured, and well-documented code prevents confusion, reduces bugs, and avoids long-term technical debt. Writing with future maintainers (including yourself) in mind ensures smoother collaboration and easier maintenance as projects grow.

The main point is this: you don't write source code primarily for computers, otherwise, you'd be writing it in binary yourself. Source code exists for a very good reason: to be understandable by humans. It acts as an interface for developers to communicate with machines, giving them instructions and rules in a readable form. That's why we have coding best practices, naming conventions, design patterns, and so on. Compilers or CPUs don't care about any of that, it's all for us.

When You Take Away the Interface, the System Becomes Unusable

As I mentioned, source code is the only ergonomic and sensible interface that developers currently understand and can use reliably. Nobody can read or write raw binary code directly. Think of source code like the steering wheel, gear selector, and pedals of a car, the binary code under the hood is the engine's "magic". Technically, you might try to operate the car without a steering wheel, but is it ergonomic or even feasible? Absolutely not!

If we remove source code from the equation, the entire deterministic process goes out the window. From that point onward, there's no way to generate code while ensuring the resulting binary is exactly correct. We'll explore this in more detail later in the article.

This brings us to a common issue I've seen in many articles on this topic. They're not exactly wrong, but they often argue against the idea using points that are irrelevant in the context of what we've just discussed. Let's take a closer look at those arguments.

Things That Almost Everyone Gets Wrong

In almost every article on this topic, authors point out a few issues with the idea of generating binary directly. Technically, their points are correct, but they often miss the core problem. Some of the common criticisms include:

Source Control Will Become Pointless

Let's start with this one, as it's a somewhat controversial claim. The statement is partially correct, but not entirely.

Technically, you can still store binaries in source control, manage releases, tags, versions, and all the other standard repository references. You can even switch between different versions, so many core features of source control would remain usable.

However, one thing that would no longer be possible is code review - the very feature that makes source code so valuable in the first place. That said, using this as an argument against the entire idea feels a bit off, and here's why:

Code Review Will Become Impossible

Absolutely, there's no doubt about it. Pull requests would just be an opaque sequence of binary data, providing no context at all. Sure, you might still see a bunch of "LGTM" comments, but on a serious note, without a tangible interface to review, what would there even be to review? This makes the argument largely irrelevant in the context of evaluating direct binary generation.

Security Auditing Will Become Impossible

Of course, without human-readable source code, there would be no way to audit it for vulnerabilities, let alone fix any issues. This limitation is another obvious downside.

Libraries and Shared Source Code Will Become Pointless

Yeah, again, just like everything else that relies on proper source code. Without source code, there are no best practices, naming conventions, project structure, modularity, or shared packages... basically none of the tools and patterns developers rely on. While this argument is technically correct, it's not really relevant in the context of evaluating direct binary generation.

In this scenario, the only interface would be the prompt. Could natural English become a new unified programming language? That's a fascinating question, but it's a topic for another article. For now, let's stay focused.

So What Are the Actual Problems with This Approach?

There are quite a few challenges with this approach, and I hope I don't turn this into another 20-minute read (which, annoyingly, almost always happens to me).

Determinism Goes Out the Window

When you write code in C#, it goes through several steps before becoming actual machine code:

Compilation with Roslyn: the compiler parses your source code, performing lexical, syntax, and semantic analysis, along with some basic optimizations. It doesn't produce native code directly, instead, it emits CIL (Common Intermediate Language) instructions and metadata tables describing types, attributes, generics, and other information. All of this is packaged into a .NET assembly (a .dll or .exe) using the Portable Executable (PE) format.
Execution under the CLR: when the program runs in the Common Language Runtime (CLR), methods are compiled by the JIT compiler (Just-In-Time compiler):
- A method is called for the first time
- JIT reads the IL instructions and metadata
- Performs runtime-aware optimizations such as inlining, escape analysis, and CPU-specific vectorizations
- Finally generates native machine code (x64, ARM, etc.) and caches it for future calls

In short, the pipeline looks like this:

C# -> Roslyn -> IL + metadata (assembly) -> CLR JIT/AOT -> Native machine code

This process is complex, but its key advantage is determinism: given the same input, the compiler will produce the exact same IL every time, and the JIT will produce logically equivalent native code. While runtime factors like tiered compilation (Tier 0 vs Tier 1) might produce different native code across runs, the logical behavior remains consistent.

When you delegate this task to AI, however, determinism disappears. Not only can unpredictable issues arise, but the entire process becomes abstracted and uncertain, introducing significant risk.

No More Partial Changes

Every time you want to make a change, like adding a small feature, the machine code would likely have to be regenerated from scratch. This is because machine code is a low-level representation with no modular structure, comments, or abstractions, so an AI can't easily patch just one part of it.

Each new "build" could differ slightly from the last, increasing the risk that a previously working program might break completely with just a minor change. While in theory, binary patching is possible, it's extremely complex and error-prone.

Without source code as an interface, you'd be forced to rely entirely on the AI model to fix issues, since the prompt would be your only way to interact with the system. You might end up imploring your AI model to fix a bug that needs to go to production today, but instead it just adds more and more bugs. A minor update could turn into a chaotic conversation with your AI: "No, not that part... the other part... wait, why is it doing this again?" - a scenario that's both unpredictable and, frankly, a little scary.

Waste of Precious Tokens

Even today, when AI-assisted coding has become more common and models are well-trained, generating code is still expensive and consumes a lot of tokens. Now imagine AI generating binary code from scratch every time you need even the smallest feature. The whole project would have to be regenerated, wasting a huge number of tokens and it's unlikely to get it right on the first, second, or even fiftieth attempt.
That's a multiplied token disaster.

Generalized Prompt Repetition Formula

When each change might have a different number of failed attempts, the total number of prompts needed can be expressed as:

Repetitions = Σᵢ₌₁ⁿ (Failed_Attemptsᵢ + 1)

Where:

n = total number of changes required
Failed_Attemptsᵢ = number of failed attempts for the i-th change
+1 accounts for the successful attempt of each change

Example

Suppose you need 3 changes, and the failed attempts per change are:

Change 1 → 2 failed attempts
Change 2 → 0 failed attempts
Change 3 → 5 failed attempts

Then:

Repetitions = (2 + 1) + (0 + 1) + (5 + 1) = 3 + 1 + 6 = 10

You would need 10 total prompts to get all changes successfully applied.

And that's a very optimistic example, by the way. The n variable can even be infinite, meaning, you'll never get your project to the desired state.

Possible solution?

One approach could be to divide your product into small, deployable components (yes, we're talking microservices). Instead of regenerating the entire project from scratch, you'd regenerate only the specific part of the system that needs updating. For example, updating a notification service is far easier than rebuilding an entire banking system.

However, this solution undermines the original idea. You'd end up managing a huge number of microservices, which, if you've ever worked on large systems, you know can be far more painful to maintain than a single monolith. In other words, this "fix" may solve one problem but introduces many others.

Performance Issues

As I mentioned earlier, modern compilers are extremely sophisticated. Entire teams focus solely on making compilers as accurate, optimized, and fast as possible. Today's compilers can generate machine code in milliseconds, and they do so deterministically.

For example, the Roslyn compiler (which I mentioned earlier) supports incremental analysis, meaning it can run continuously as you type. Instead of recompiling everything, it only updates the syntax tree and dependent symbols. While this feature is mostly used in IDEs, it's a major performance booster.

Roslyn also leverages heavy caching and immutable data structures, so previously computed semantic information can be reused. On top of that, it supports parallel compilation, allowing multiple files to be processed simultaneously across CPU cores.

We could talk about Roslyn all day, but that's a completely different topic. The main point here is: when you bypass these sophisticated compilers, all these performance advantages disappear. You're left with just the AI, which works non-deterministically and can waste massive amounts of time, resources, and performance.

There Are Many Different Platforms (Architectures)

Every platform requires its own specific binaries. For example, a binary built for x86 won't run on ARM. Compilers handle this automatically, they know exactly what to generate.

With AI generating binaries directly, you'd need to produce separate versions for each architecture. Remember our earlier formula for prompt repetitions, which accounted for failed attempts per change? Now we have another variable: the number of architectures.

If you previously calculated:

Repetitions = Σᵢ₌₁ⁿ (Failed_Attemptsᵢ + 1)

We now need to multiply by the number of architectures (let's call it A):

Repetitions = Σᵢ₌₁ⁿ ((Failed_Attemptsᵢ + 1) * A)

Where:

n = total number of changes
Failed_Attemptsᵢ = failed attempts for the i-th change
A = number of target architectures
+1 accounts for the successful attempt of each change

For complex projects, this can quickly explode. Multiply by 3–5 or more architectures, and remember that each attempt might fail multiple times. Suddenly, a small change could require hundreds or even thousands of AI prompts, burning through tokens and time at an alarming rate.

Are you still excited about this idea?

How Can AI Be Helpful for Modern Compilers?

AI should never be the main driver of compilation, because developers rely on compilers to be reliable, predictable, deterministic, and fast. AI simply can't guarantee any of that as the primary engine.

However, AI shines as an assistant. It can provide refactoring suggestions, performance improvements, or code optimizations, effectively taking some of the load off the compiler and helping developers write better code.

A realistic workflow could look like this:

Source code -> Roslyn -> AI assistant -> Suggestions

Here, the AI doesn't replace the compiler, it analyzes the intermediate structures that Roslyn generates (syntax trees, semantic models, metadata) and provides actionable insights back to the developer. Think of it as a co-pilot rather than the engine: it makes your work smoother without risking determinism or performance. But even this is just an abstract concept.

Summary

This whole "AI generates binaries directly" idea sounds sci-fi and Cyberpunky, which is undeniably fun. But reality doesn't care about coolness, it cares about whether the idea actually solves a problem. In this case, it clearly doesn't. In fact, it introduces a mountain of new problems: non-determinism, wasted tokens, impossible debugging, and insane complexity across multiple architectures.

Maybe one day in the far future, people will rely on prompts instead of source code, and developers won't even touch the code anymore. But even then, the core problem remains: without understandable source code and deterministic compilation, maintaining, debugging, and collaborating on software becomes almost impossible. The interface is gone, and with it, control is gone.

At the end of the day, AI can be amazing for coding, but let's leave the heavy lifting of compilation to our compilers. The AI's real value is as a smart assistant, not the engine that drives everything.

Sunday DEV Drive: A Synthwave Driving Experience Through Your DEV Community Articles

Giorgi Kobaidze — Sun, 01 Mar 2026 20:32:00 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

Let's Start from the Very Beginning

I love weekends. Not because I want to escape coding, quite the opposite. As a full-time principal engineer, my weekdays belong to meetings, architecture decisions, reviews, and production responsibilities. Evenings are short. Energy is limited. But weekends? Weekends are different. Weekends are pure.

They're the only time I can dedicate an entire day to building something just for the joy of it. Writing. Experimenting. Creating.

Recently, I started participating in DEV challenges and it's been one of the best decisions I've made in a long time. There's something powerful about building in public. Shipping something playful and sharing it with your community.

This challenge, in particular, just felt right - the weekend challenge.

To the Community I Call Home

The DEV community has been my home since 2017, since the very beginning of my professional software engineering journey.

More often than not, I found comfort here when things weren't going well. Especially in those early years. When imposter syndrome was loud. When mistakes felt heavier. When growth felt slow.

Reading other developers' stories helped. Seeing their struggles. Their wins. Their lessons. It all reminded me that we're all just figuring it out.

Now, years later, I wanted to give something back.

I wanted to build something that would:

Make fellow members smile.
Help them feel proud of their work.
Turn their articles into something interactive.
Encourage passive members to write.
Maybe even inspire non-members to join.

Something actually different... something actually fun...

What I Built

So I Built Sunday DEV Drive

Sunday DEV Drive is a game, but not in the traditional sense.

There are no bosses to defeat, no side quests, no objectives, no timers.

It's intentionally different.

It's a browser-based synthwave driving game where your DEV Community articles become neon billboards along an endless procedural road. You type in a username, and within seconds you're cruising through a retro-futuristic cityscape with your article titles, cover images, and actual quotes from your writing towering above the highway.

And as you drive, billboards around the city display articles - yours or someone else's, pulled dynamically using the DEV API.

Imagine cruising through a digital city and suddenly seeing your own words glowing above you.

Or discovering another developer's article while driving past a virtual skyline.

It's not about winning, it's about reflecting, it's all about feeling proud and transforming written content into a spatial experience.

It Works in Three Modes

Your articles: Enter any DEV username. The game fetches their posts via the DEV API, extracts real quotes from article bodies, and renders them onto billboard textures in real-time.
Motivational mode: If a user has an account but no articles yet, every billboard becomes an encouraging message with "Click here to start writing!" - each one linking directly to dev.to/new.
Test drive: No DEV account? No problem. Take a demo spin and let the game convince you to join the community, every billboard becomes an invitation.

Every billboard is clickable. See a post you want to read? Click it, and it opens in a new tab.

Beyond billboards, green road signs display your profile stats as you drive: total articles, lifetime reactions, reading time, your top post, favorite tags, and the date you joined DEV.

But wait, there's more.

You can even switch to first-person mode and drive straight from the cabin for full immersion.

The Idea Behind It

We usually consume articles passively, scrolling on a feed. But what if your writing became part of a world? What if your thoughts lived on digital billboards? What if discovering developers felt like exploring a city instead of browsing a list?

Sunday DEV Drive turns articles into scenery. It makes community content feel tangible.

More Than Just a Game

At its core, this project is a thank-you letter.

To the platform.
To the writers.
To the readers.
To the beginners who are still doubting themselves.

If you've ever published even one article, you deserve to see it shining in neon.

If you've been thinking about writing, maybe this is your sign. WHAT ARE YOU WAITING FOR? START NOW. A year from now, you'll wish you'd started today. Regret is avoidable by taking action.

Welcome to Sunday DEV Drive! 🚗✨

Demo

Try it yourself: 🔗 sundaydevdrive.pilotronica.com

Try it with your own DEV username, or just hit "Take a test drive" to jump right in.

GAME CONTROLLER SUPPORT INCLUDED
Plug in a controller and enjoy the experience.

Code

The entire codebase is public, dive into the repository and take a look:

georgekobaidze / sunday-dev-drive

A synthwave driving experience through your DEV Community articles

Sunday DEV Drive

A synthwave driving experience through your DEV Community articles

Live Demo • Features • Controls • How It Works

Live Demo

🔗 sundaydevdrive.pilotronica.com

About

Enter your DEV Community username, hit Start Driving, and cruise through a neon-lit synthwave world where your articles appear as roadside billboards. Each billboard shows a title, cover image, and a snippet from the article body. Click any to open the full post.

Built for the DEV Weekend Challenge: Build for Your Community.

Features

Your Articles as Billboards

Roadside and overhead signs generated from your real DEV posts, complete with cover images, snippets, and reaction counts.

Stat Signs Along the Road

Green road signs display your profile stats: total articles, reactions, reading time, top post, favorite tags, and join date.

Keyboard & gamepad support

Drive with arrow keys or plug in a controller. Full analog steering, throttle, and a right-stick orbit…

View on GitHub

Don't judge the JavaScript too harshly, I come from the land of APIs and databases - I'm a back-end developer through and through.

How I Built It

The Stack

Three.js (r170) - 3D rendering, loaded via ES module import maps from CDN
Vanilla JavaScript - 12 ES modules, zero build step, zero bundler, zero npm dependencies
Canvas API - Every billboard and road sign texture is drawn programmatically
DEV API - Public endpoints, no API key, no backend

No React. No Vite. No webpack. Open index.html with any static file server and drive.

The Architecture

The entire project is 12 ES modules with a clean dependency graph and zero circular imports:

scene.js ← road.js ← buildings.js
                    ← car.js ← camera.js
                              ← input.js
         ← billboards.js ← stats.js ← api.js
main.js imports everything

Each module owns its domain: road.js generates the path, car.js builds the car, billboards.js handles the article-to-texture pipeline. The main.js entry point wires them together and runs the animation loop.

Procedural Road Generation: Stochastic Steering

The road is infinitely generated as you drive. There's no predefined track, it grows segment by segment using a stochastic steering algorithm:

export function growPath(count) {
  for (let i = 0; i < count; i++) {
    if (--pathTurnCountdown <= 0) {
      pathTurnRate      = (Math.random() - 0.5) * 0.042;
      pathTurnCountdown = 4 + Math.floor(Math.random() * 6);
    }
    pathHead.angle += pathTurnRate;
    pathData.push({ pos: pathHead.pos.clone(), angle: pathHead.angle });
    pathHead.pos = new THREE.Vector3(
      pathHead.pos.x + Math.sin(pathHead.angle) * SEGMENT_LEN,
      0,
      pathHead.pos.z - Math.cos(pathHead.angle) * SEGMENT_LEN
    );
  }
}

Every few segments, a new random turn rate and duration are chosen. Because the turn rate accumulates over multiple segments rather than being applied instantly, the road produces smooth, organic curves, gentle sweeps, not jarring zigzags. Randomizing both the magnitude (0.042 range) and the duration (4–10 segments) creates surprising variation from very simple math.

The road surface itself is a ribbon mesh: a sliding window of 200 segments rebuilt from raw BufferGeometry. For each segment, perpendicular edge points are computed using the path angle:

const rx = Math.cos(pd.angle);
const rz = Math.sin(pd.angle);
const lx = pd.pos.x - rx * ROAD_WIDTH / 2;  // Left edge
const hx = pd.pos.x + rx * ROAD_WIDTH / 2;  // Right edge

The ribbon follows the car. When you've driven far enough, the mesh is rebuilt centered around your position. The road is always beneath you, and always extends into the horizon.

Canvas-Rendered Billboard Textures

This is where the DEV API meets the Canvas API. Every billboard texture is a 512×768 canvas (roadside) or 1024×512 canvas (overhead), painted section by section:

Header bar - neon-bordered strip with author and reaction count
Cover image - letterboxed from the article's cover_image URL, loaded asynchronously
Snippet - an actual quote extracted from the article body
Footer - reading time and tag display

The tricky part: cover images load after the texture is already applied to the 3D mesh. Three.js handles this beautifully with tex.needsUpdate = true:

if (article.cover_image) {
  const img = new window.Image();
  img.crossOrigin = 'anonymous';
  img.onload = () => {
    drawImageLetterbox(img, cx, cy, cw, ch);
    tex.needsUpdate = true;  // GPU re-uploads on next frame
  };
  img.src = article.cover_image;
}

For articles without cover images, the cover area becomes a playful "404 / cover_image: null / (the author was too busy)" message, complete with a retro grid background. In motivational mode, it reads "Click here to start writing!" instead.

Snippet Extraction: Turning Markdown Into Billboard Quotes

Simply showing article titles on billboards wouldn't be enough. I wanted actual quotes from people's writing. But the DEV API returns raw Markdown, not clean prose. The extraction pipeline strips away code blocks, images, links, and headers, then picks paragraphs in a sweet spot - long enough to be meaningful, short enough to fit a billboard.

The 60-400 character filter is crucial. Too short and you get orphaned sentences. Too long and the text overflows the billboard canvas. The result: clean, readable quotes that actually represent what someone wrote.

Car Physics: The Struggle Effect When Both Pedals Are Pressed

The driving model is simple but has one detail I'm proud of. When a player presses both throttle and brake simultaneously (a common thing with gamepads), instead of canceling out, the car settles into a "struggle" state, which is basically low speed, high engine strain:

if (throttle > 0 && brake > 0) {
  const struggle = CAR.maxSpeed * 0.08;
  carState.speed += (struggle - carState.speed) * 0.04;
}

The speed converges to 8% of max through lerp smoothing. It simulates the feeling of fighting the brakes, the car doesn't stop, doesn't accelerate, just vibrates with restrained energy. It's a small detail but it makes the physics feel alive.

Acceleration also uses diminishing returns, the faster you're going, the harder it is to go faster:

const speedRatio = carState.speed / CAR.maxSpeed;
const effectiveAccel = CAR.acceleration * throttle * (1 - speedRatio * 0.85);

This single line replaces what would otherwise be a complex drag model. At zero speed, you get 100% acceleration. At top speed, you get 15%. The curve in between is completely smooth.

The 25-Article Shuffle

The DEV API has a quirk: the list endpoint returns titles and metadata, but not the full article body. To get actual text for snippet extraction, you need a separate request per article. For a user with hundreds of posts, that's hundreds of requests - too slow and too aggressive.

And I'm not planning to brutally overload our favorite creators' platform. I'll be easy on it. So Jess, Ben, Peter, if you're reading this, don't worry, I got you.😄

The solution: shuffle the full article list and deep-fetch only 25 random articles. The rest get their description field as a fallback snippet:

const shuffled = [...list].sort(() => Math.random() - 0.5);
const toFetch = shuffled.slice(0, 25);
for (const art of toFetch) {
  const r = await fetch(`https://dev.to/api/articles/${art.id}`);
  if (r.status === 429) { art._snippets = [art.description || '']; continue; }
  const full = await r.json();
  art._snippets = extractSnippets(full.body_markdown || '');
  await new Promise(res => setTimeout(res, 350));
}

Each request has a 350ms delay to respect rate limits. If the API returns 429 (Too Many Requests), it gracefully falls back to the description instead of failing. The player never notices, they just see billboards with quotes. Whether those quotes came from a full article parse or a description fallback is invisible.

Billboard Click Detection via Raycasting

Clicking a 3D billboard to open an article isn't trivial in a 3D scene. The solution is Three.js raycasting, converting a 2D mouse position into a 3D ray, then testing intersection against billboard geometry.

Each billboard stores its article URL in userData. The raycast checks both front and back panels, so billboards work no matter which direction you're looking at them from. The orbit.active guard prevents accidental clicks during camera rotation.

Building a Car from 46 Boxes

When I was a kid, I'd grab random little wooden scraps nobody seemed to need (or at least I thought nobody needed), hammer them together into a rough car shape, and nail four bottle caps on as wheels. Perfect toy car. Good times.

Who would've thought that, more than 20 years later, the same "stack-and-nail" approach would actually come in handy... in code.

There are no 3D models in this project. Every part of the car like body, cabin, hood, trunk, wheels, rims, windows, dashboard, headlights, tail/brake/reverse lights, steering wheel, interior screens, is built entirely from BoxGeometry and CylinderGeometry primitives, carefully stacked and positioned by hand.

And boy did I spend a lot of time on that! Totally worth it.

Lower body → Mid body → Hood → Trunk → Cabin
→ 4× Wheels (cylinder + torus rim)
→ 4× Windows (transparent glass material)
→ Dashboard with neon trim + dual screens
→ Steering wheel (torus + cylinder spokes)
→ Headlights (emissive mesh + PointLight)
→ Tail/brake/reverse lights

The steering wheel actually rotates when you turn:

const sw = car.userData.steeringWheel;
if (sw) sw.rotation.z = -carState.steer * 0.5;

Visible only in interior camera mode, but it's there. These kinds of details don't matter until they do.

So Much More to Talk About

This project was a blast to build. Every component of the game required a ton of thought, and I learned so much along the way. What I've shared here are just the most exciting parts, there are plenty of other fascinating details. If I included everything, I'd probably end up writing a book. Maybe that's a story for another day.

What I Learned This Weekend

Building a 3D game with zero dependencies and zero build tools in a weekend taught me a few things:

The Canvas API is absurdly powerful for textures. Every billboard, every road sign, the sun, the skyline, all drawn with fillRect, fillText, and drawImage. No texture files needed.
ES modules are production-ready. Import maps + CDN + type="module" gives you a complete module system with zero tooling. Twelve modules, clean dependency graph, no bundler.
Simple physics beat complex physics. A one-line diminishing-returns formula (1 - speedRatio * 0.85) gives more "feel" than a proper friction simulation would. Games aren't simulations, they're about how things feel.
The DEV API is a goldmine. Public, no auth, generous rate limits, full Markdown body access. Building for the community with the community's own API felt right.

This project was built in a weekend with coffee, a gamepad, and a deep appreciation for the DEV Community. Every article you've written deserves to be a neon billboard on an endless synthwave highway.

Now it's your turn. Take your car for a spin, share your journey in the comments, grab screenshots and show it off to your friends, colleagues... anyone! I'd love to hear everyone's reaction. Let's show everyone that we're by far the best community.

Could Vibe Coding Be the Missing Communication Link Between PMs and Developers?

Giorgi Kobaidze — Tue, 17 Feb 2026 17:08:33 +0000

Introduction
Building a Product Is a Team Sport
- No Developer Is Perfect And That's Okay
- No Project Manager Is Perfect And That's Okay Too
- Even PMs and Clients Can Misalign
- Common Language
Mental Models & Misalignment
- Cognitive Science Tells Us Something Important
- Visualization Changes the Equation
Can Vibe Coding Be the Answer?
- Yes, Absolutely
- Potential Issues
Things To Keep In Mind
- Make Sure Your Company Allows It
- Do the Research Yourself or Consult Your Technical Team
- AI Models Do Exactly What You Tell Them, So Be Specific
Conclusion

Introduction

It's been a long time since I wrote about vibe coding, and for good reason - it's not a topic I like to talk about. As a seasoned software engineer, I'm all for AI-assisted coding, but vibe coding? That's still a hard no from me.

If you want to understand why I feel this way, check out this article:

Giorgi Kobaidze

Jun 24 '25

I'm All In on AI, But We Need to Talk About Vibe Coding

#ai #vibecoding #machinelearning #coding

126

Comments 64

16 min read

And here's where the good old 'however' comes in.

However, today we're going to play a little "😈's 🥑".
After crunching and grinding through the data, my brain finally figured out exactly where vibe coding can actually be useful. Yes, you heard me right, I just mentioned "vibe coding" and "useful" in the same sentence. Who'd have thought?

Spoiler alert: it's not what you think. It's not the traditional, hype-driven version of vibe coding. If you're a software engineer hoping for an excuse to drop everything and dive headfirst into the vibe coding world, sorry, this isn't that place.

In my world, there's no such thing as a developer without coding skills, no matter how hard the influencers who've never written a single line of production code try to sound cool by telling everyone that "Software engineers won't be needed in a month."
They've been saying that for at least three years.

Instead, we're going to explore vibe coding from a different angle, with an open mind. I'm not the type of person who's hostile toward an idea just because it's unfamiliar. That's why I've been thinking about this topic for a long time.

Building a Product Is a Team Sport

No Developer Is Perfect And That's Okay

If you're a software engineer, chances are you've worked in a team with people in very different roles.

The single most important factor in successful teamwork is Communication.

You could assemble the world's best developers in one team, but if they can't communicate effectively, they won't achieve much. Just like in sports, talent alone isn't enough, teamwork and clear communication are what make the real difference.

But there's a problem that often gets overlooked.

A developer might be brilliant at designing systems, writing maintainable, optimized code, and thinking through architecture, basically, everything you'd want technically. Sounds perfect, right? But that doesn't automatically make them a strong communicator when explaining what they're doing.

Even more challenging is understanding exactly what's needed from the business side. For many developers, translating business requirements into technical implementation, or the other way around, can be far harder than just writing code. And there are multiple reasons for this, which we'll explore soon.

Yes, we all know developers should be good communicators, but that's just "shoulda, coulda, woulda". It doesn't always happen. Sometimes a developer is so good at solving problems that you overlook the fact they're not the most talkative or expressive. Sure, they'll ask questions, understand the context, and gather the requirements. But once they feel they understand, they often assume everything's fine and dive into designing the solution, and sometimes, they get something wrong because of those assumptions.

Then there's another category of developers, usually beginners, who worry that asking "too many" questions will make them look unqualified for the job (been there myself and it's miserable until you realize that's not how it works.)

Either way, the result is the same: they end up doing things the wrong way, which is far from ideal.

No Project Manager Is Perfect And That's Okay Too

Project managers usually aren't deeply familiar with the technical side of the product. Sure, there are PMs who understand what's going on at a high level, but they're typically either former software engineers who, for some reason, have had enough of writing code and moved toward the client-facing side, or people who are genuinely curious about how everything works under the hood.

However, those cases aren't that common. Let look at the Venn diagram:

And this diagram isn't just about PMs and developers. The same idea applies to almost any job, technical or non-technical. There are hundreds of roles where the overlap of "excellent at communication" and "excellent at the core skill" creates the mythical, superhuman type.

As a project manager, communication is your superpower. Your primary job is to understand exactly what your client wants and gather the right information from them. Then comes the next step: translating that information clearly to your developers.

And that's when things can get really tricky.

As mentioned, you won't always have developers who understand the product language the same way you do. You might use different terms or conceptualize things differently, and for developers, your terms could have completely different meanings.

Let's look at an example. A simple term - "Real-Time".

PM says: "We need real-time updates."

What the PM might mean is when users refresh, they see fresh data. The numbers feel current. No obvious delay.

What the developer hears? WebSockets, persistent connections, complex state management, scaling challenges.

Now engineering effort multiplies... exponentially.
All because "real-time" meant different things.

This might sound like a funny or even nonsensical example, because surely you'd think it would get clarified, right? But to be honest, I've heard much worse horror stories than this.

Even PMs and Clients Can Misalign

Especially when PMs are working on highly technical products and their clients are also technical. I can only imagine how challenging it must be to listen, gather information you don't fully understand and then translate it clearly to your developers. You're the only bridge between these two overly complex technical worlds, and doing it flawlessly is no small task. That must be a lonely place to be.

Common Language

Developers usually think system-first, while product people think product-first. There's nothing outrageous about this, that's exactly why different roles exist in a company.

But these different mindsets can create gaps in language, perception, and understanding, which sometimes lead to problems. Think of it like Lego pieces: they can be used to build many different things. One person might build a horse🐴, while another builds a bear🐻. Neither is wrong, but the client only wants one of them.

Mental Models & Misalignment

Cognitive Science Tells Us Something Important

It tells us that words don't carry meaning, they trigger mental models.

When you say "dashboard", you're not transmitting an image. You're just activating one. That image is built from your own experiences, your past projects, your preferences, your assumptions. I do the same. And even if we both nod in agreement, we might be visualizing completely different products. That's why teams who've worked together for a long time make hard things look easy.

Their words trigger similar mental models.
The interpretation gap is tiny.
And when you remove that gap, you've already solved half the problem.

That's the hidden danger of language in product development.
It feels precise. It feels shared. But it's interpretive.

Our brains have to decode words, attach context, fill in gaps, and construct internal pictures. That process is fast but it's also personal. Which means two intelligent, competent professionals can agree on the same sentence and still walk away with different realities in mind.

Visualization Changes the Equation

The human brain processes visuals dramatically faster than text. Images don't need to be translated. They don't require semantic negotiation. They're concrete. Immediate. Shared.

When we're both looking at the same interface, the same layout, the same interaction flow, the interpretation layer completely goes out of the window. The mental models collapse into a single reference point. We're no longer debating what something means. We're directly looking at that thing.

So why do we keep trying to align through paragraphs?

If visualization is the fastest path to alignment... then what happens when creating that visualization becomes effortless?

Can Vibe Coding Be the Answer?

Yes, Absolutely

However, not to create the product itself, but to create a visual representation of the product, or a major new feature that's difficult to model clearly in your head.

What I'm trying to say is this: vibe coding can give project managers something close to a superpower, the ability to communicate with near-perfect clarity. Instead of relying solely on words, they can create a working prototype. A tangible blueprint. Something engineers can look at, explore, question and then use as a foundation to build the real system.

As mentioned earlier, misalignments sometimes even happen because clients and product teams visualize ideas differently. This approach can solve that problem as well, and arguably, that's even more important.

Project managers can use this "blueprint" to validate requirements with precision, walking clients through quick demos and confirming alignment before a single line of production code is written.

Potential Issues

But let's address the potential issues with this approach:

1. Not Everyone Builds Visually Tangible Products

What about teams that aren’t building something visually tangible? Teams developing internal libraries or purely technical tools, for example.

In those cases, this approach might not even be necessary. The conversations are already deeply technical and everyone involved likely shares a similar mental model. The language gap is smaller and alignment happens through architecture diagrams, interfaces, and code, not UI prototypes. In cases like that, often the developers from different teams have direct communication with each other for steamlining the whole process.

2. What About Mockup Tools?

Conceptually, this isn't a particulary new idea, tools for creating mockups have existed for a long time.

Absolutely. But those tools are quite limited: they can only do so much, and often your requirements are far more complex than what they support. That's why many companies and project managers skip this practice, it doesn't always deliver enough value to justify the time, and if used incorrectly, it can create more problems than it solves.

With vibe coding, however, you can generate much more advanced, customized visuals that tell the full story. You don't need to learn complex software, it's much faster, and the result communicates your idea clearly to both clients and developers.

3. Speaking of Speed, It Still Takes More Time Than Just Talking Verbally

Even though vibe coding is faster and more precise than traditional mockup tools, It still takes more time than just explaining the concept verbally to developers. Sure.

But... does it?👀

I've seen developers and product people go back and forth tweaking a simple feature for months, only to get it wrong repeatedly.

Think of it like racing: inexperienced drivers think that going "all in", way too hot into a corner will make them faster, but fast in doesn't always mean fast out. Sometimes the opposite is true. Experienced drivers know that to maximize speed on the next straight, you often need to slow down on entry: slow in, fast out.

The same principle applies here: it's better to invest a little extra time upfront, creating clear visuals and alignment, than to deal with endless issues down the line.

Things To Keep In Mind

Make Sure Your Company Allows It

Every company has policies around sharing confidential information. Sometimes, a project, or even a single feature, can be sensitive enough that you're not allowed to mock it up using an external AI model. Typically, this isn't an issue if the company provides its own internal AI model, which keeps all data in-house.

Do the Research Yourself or Consult Your Technical Team

Yes, vibe coding is essentially telling an AI agent what to create, in plain English. But you still need a proper setup, which usually involves a small amount of configuration to get everything running. Consulting with your developers can make this even easier, they can have you up and running in just a few minutes.

AI Models Do Exactly What You Tell Them, So Be Specific

Make sure your instructions are precise. AI models often assume you want a fully functional system, complete with databases, caching, external requests, scaling, security - everything that comes with real software, because most people use vibe coding to actually build software (this is not recommended by me).

If all you need is a dummy or mockup to use as a demo, you have to tell the AI that explicitly. Doing so makes the model's job exponentially easier, produces more flexible results, and uses far fewer tokens.

Examples:

Simple Visual Mockup

Prompt:
"Create a simple mockup of a project management dashboard for a web app. Include task lists, progress bars, and a calendar view. This is just a visual demo, do not include actual databases, APIs, or backend logic."

Feature Prototype

Prompt:
"Generate a prototype for a feature where users can create, edit, and delete items. The prototype should show screens and buttons, but it does not need to connect to a database or have real functionality."

Internal Tool Demo

Prompt:
"Produce a mockup for an internal reporting tool. Include charts, filters, and tables. Only visual elements are required, do not add real data fetching, authentication, or backend services."

Mobile App Example

Prompt:
"Create a visual prototype of a mobile to-do app with three screens: task list, task details, and task creation. This is just a demo, no actual storage, API calls, or notifications are required."

Interactive Demo with Dummy Data

Prompt:
"Build a mockup for a CRM dashboard with dummy data. Include client cards, search filters and activity logs. This is only a prototype for demonstration purposes, skip real functionality like databases, caching, or external requests."

Conclusion

As a developer, I'm not a fan of vibe coding, it's definitely not coding (nor "vibe"), and the name is kind of silly if you ask me. But that doesn't mean it's useless. In software development, everything is a tool. There are no inherently good or bad tools, only good and bad ways to use them.

Vibe coding can be a superpower for project managers, product managers, product owners, and others with limited technical knowledge. It's right there for you to use, with almost no learning curve. That's where I see the real value.

If you're a product person, try suggesting this to your team: practice it, create a demo, and show the value in a tangible way.

If you're a technical person struggling to understand requirements, invite your product people to try this approach. Make it a fun, knowledge-sharing session where you vibe code a dummy or mock application that looks like the real deal. The opportunities here are endless.

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

Giorgi Kobaidze — Fri, 13 Feb 2026 20:01:12 +0000

This is a submission for the GitHub Copilot CLI Challenge

Demo
What I Built
- The Idea
- So, What Does It Do?
- Turns Out, It Wasn't That Simple
- The Solution
- A Few Words About the Tech Stack
My Experience with GitHub Copilot CLI
- So Here's the Conclusion:
- And One Last Thing
Credits
Useful Links

Demo

In this video, I not only present the demo, but also walk through the core purpose and motivation behind the project. I dive into the architecture and design decisions in detail, explaining how everything fits together and why certain approaches were chosen.

You can check out the video chapters if you'd like to jump to a specific part, but I highly recommend watching the full video to get the complete picture and fully understand how everything connects.

What I Built

The Idea

I love airplanes, traveling, airports, the sound of engines, everything related to aviation. For a long time, I've wanted to build something connected to that world. I just needed the right excuse.

Then this challenge appeared. This was my though process:

Okay, this challenge looks fun. I need to use Copilot CLI.
Alright, but what do I build? It has to be authentic. Cool. Creative and actually useful...

Copilot CLI...
Copilot...
Pilot...
Airplanes...

And suddenly it clicked.

That was the moment Metal Birds Watch was born.

What started as a word association turned into a real-time aircraft tracking app that notifies you when planes fly over you. Sometimes ideas don't come from complex brainstorming sessions, sometimes they come from connecting a few dots and letting your curiosity do the rest.

This challenge didn't just give me a prompt, it gave me the push I needed to finally build something I'd been thinking about for years. And I'm insanely proud of how it turned out.

So, What Does It Do?

As a regular aircraft nerd, I instinctively look up at the sky every time I hear an engine overhead. I try to guess the make and model, the airline, maybe even where it took off from or where it's heading. It's like a little game (I'm not the best at it though, my brother and mom absolutely destroy me at this game, they make me look like I've never seen a plane in my life).

But there's one problem.

I can't just stand outside all day watching planes. Most of the time I'm working - coding, building things, solving problems. I'm a busy guy, too busy.

Sure, there are plenty of websites where you can track airplanes from all around the world in real time. But that still requires actively watching a screen. And again... I'm way too busy for that.

So I decided to build something that would "watch the sky" for me.

I use quotation marks because it doesn't literally watch the sky, it taps into real-time public flight data and detects when aircraft enter my area. When that happens, it sends me a notification. And if I miss it, the plane is still logged in my browser so I can check later and see what flew over my head.

Instead of me watching planes, the app watches them for me. Hence the name Metal Birds Watch.

Try it out yourself using the following link: https://metalbirdswatch.pilotronica.com/

Turns Out, It Wasn't That Simple

The whole concept sounds pretty straightforward right?

Fetch plane data periodically → filter by your area → trigger a notification. Easy!

Well, nuh-uh! The architecture and implementation turned out to be way more complex than the idea itself.

When you rely on a third-party public service, there are always limitations and rightfully so. Free APIs need rate limits. Without them, they'd be abused and become unusable for everyone.

The API I used for this challenge is no exception. It has strict request limits, and I have to respect the limits. If I exceed them, my app runs out of credits and simply stops working.

Usually when you're constrained by request limits or data quotas, the obvious solution is caching. Smart caching reduces the number of calls you make to the API provider. Great!

But then comes the real question:

How do you cache this kind of data?

There are tens of thousands of aircraft in the sky at any given moment, scattered across the globe. I needed to keep a fine balance between caching too aggressively (which could overload my storage and keep irrelevant data) and not caching enough (which would burn through API credits in minutes).

And that's where things started to get interesting.

On top of that, I made a deliberate decision to keep the system simple.

No persistent storage.

And more importantly, no sensitive data stored anywhere.

This is a privacy-first application. That means I don't store the user's location, IP address, or any personally identifiable information, not in a database, not in logs, not even in cache and any readable storage. Nor should it be retrievable via any endpoint.

By now, you can probably tell there are already quite a few moving parts in this system.

And we haven't even started talking about the actual solution yet.

The Solution

A Note Before You Dive In

Disclaimer: This is one way to solve this problem, not the only way. There are many strategies and approaches you could take, and I'd love to hear your ideas or suggestions. Here's how I tackled it:

Caching by "Grid Cells"

I decided to cache plane data based on what I call grid cells - basically, areas where multiple airplanes might be present. Instead of tracking every user individually, I group users by coordinates, rounding them to the nearest grid cell.

Each grid cell is roughly 0.2° latitude × 0.2° longitude, about 22 km × 22 km. That's 484 km².

For reference, San Francisco is 121 km², so each grid cell is about four times larger.

Users are grouped by rounding their coordinates to nearest 0.2°

Example:

User A at (48.856, 2.352) → grid cell 48.8_2.4 (cache key)

User B at (48.772, 2.421) → same grid cell 48.8_2.4 (same cache key)

Both users can get plane data for the area without storing their exact locations anywhere.

As you can see, User B falls within the same grid cell initialized by User A, so both users share the same cache entry 48.8_2.4. Any user in this area will use the same entry.

Detection Radius

After the plane data is retrieved, each user only sees aircraft within a 12 km detection radius centered on their location. This filtering happens on the client side to minimize backend resource usage and keep the system flexible.

But there's an important edge case

If a user is near the edge of a grid cell, they might miss planes flying just outside the grid. Corner users could see only a quarter of the surrounding sky. See the diagram below for a better visualization:

The green planes (Plane A and Plane C) are cached and fall within the detection radii of their respective users so notifications will be triggered. ✅

The yellow plane (Plane B) is inside the grid cell, so it's cached as well. Users will see it on the page, but no notification will be sent until it enters one of the detection circles. ❌

The white planes (Plane E, Plane D, and Plane F), however, are outside the grid cell and therefore won't be cached, nor will they be shown on the map, even though Plane D is technically within the detection radius of User C. ❌

Now, this is a significant drawback, because it means some users might not receive fully accurate information about nearby planes.

And this is exactly where the Bounding Box strategy saves the day.

Bounding Box

Fetching a slightly larger rectangle ensures everyone gets the full "all-around" view.

The backend actually fetches a 50 km × 50 km rectangle around the grid cell center, slightly larger than the grid itself, to ensure full coverage of the area.

See the diagram below for a clearer view:

As you can see, Plane D has just turned green, which means User C will now receive a notification about it.

Keep in mind: the bounding box serves a completely different purpose than the grid cell. If a new user appears within the bounding box but outside the existing grid cell, a new grid cell and consequently a new bounding box will be created for them. The bounding box's only job is to ensure that no planes are missed near the edges.

Looking at the diagram, you can see that the bounding box doesn't need to be this large, which is fine for now. In future versions of the app, users will be able to adjust their detection radius and making it bigger (or smaller).

Smart Polling

Clients don't poll the server at fixed intervals. Instead, the server tells each client when to request new data, based on cache freshness. This approach:

Reduces unnecessary polling
Saves bandwidth

Haversine Distance for Accuracy

To calculate the exact distance between a plane and a user, I use the Haversine formula, which measures distance on a sphere. This ensures accurate notifications, even for users near the edge of a grid cell.

This setup allows my app to provide real-time, privacy-first plane tracking, efficiently handling thousands of planes and users simultaneously.

Math Reference

Constants

KM_PER_DEGREE_LAT = 111 km (constant everywhere)
KM_PER_DEGREE_LON = 111 × cos(latitude) km (varies by latitude)

Why Longitude Varies

Earth is a sphere. Longitude lines converge at poles.

At equator (0°):    1° longitude = 111 km
At Paris (48.8°):   1° longitude = 111 × cos(48.8°) = 73 km
At Oslo (60°):      1° longitude = 111 × cos(60°) = 55.5 km
At poles (90°):     1° longitude = 0 km

Converting km to Degrees

Δlat = distance_km / 111
Δlon = distance_km / (111 × cos(latitude))

Bounding Box Calculation

Given center (φ, λ) and radius r km:

lat_min = φ - (r / 111)
lat_max = φ + (r / 111)
lon_min = λ - (r / (111 × cos(φ)))
lon_max = λ + (r / (111 × cos(φ)))

Example: 25km around Paris (48.8°, 2.4°)

Δlat = 25 / 111 = 0.225°
Δlon = 25 / (111 × cos(48.8°)) = 25 / 73 = 0.342°

lat_min = 48.8 - 0.225 = 48.575
lat_max = 48.8 + 0.225 = 49.025
lon_min = 2.4 - 0.342 = 2.058
lon_max = 2.4 + 0.342 = 2.742

Grid Rounding

grid_lat = round(lat / 0.2) × 0.2
grid_lon = round(lon / 0.2) × 0.2
cache_key = "{grid_lat}_{grid_lon}"

Example:

User location: (48.8712, 2.3891)

grid_lat = round(48.8712 / 0.2) × 0.2 = round(244.356) × 0.2 = 244 × 0.2 = 48.8
grid_lon = round(2.3891 / 0.2) × 0.2 = round(11.9455) × 0.2 = 12 × 0.2 = 2.4

cache_key = "48.8_2.4"

A Few Words About the Tech Stack

Even though I'm most proficient in .NET, I wanted to make this challenge more interesting by building it on something different, for a few reasons:

I wanted to learn a technology I had less experience with.
I'd get to interact more with Copilot CLI and explore its capabilities.
I needed a stack that's popular and widely used, making it easier for others to contribute in the future.

That's how I landed on Node.js. It's completely different from .NET, but that's exactly the point! I wanted to step outside my comfort zone, explore a relatively unexplored area, and see how it felt. Spoiler: it felt just right!

For the front-end, I kept things simple with plain HTML, CSS, and JavaScript. In the future, I plan to upgrade it with something more advanced, but for this challenge, simplicity was key.

My Experience with GitHub Copilot CLI

I'm a huge fan of the CLI tools in general. To me, it's the single most efficient and authentic tool a software engineer can use. After all, every GUI tool is built on top of it. I often find myself struggling to understand GUI tools, which might make me look a bit weird to developers who can't live without their shiny interfaces, but I guess I'll never be able to understand that point of view.

As amazing as Copilot is, it always lacked one feature I had been waiting for - the CLI tool. Now that it's finally here, there's no way I'm not going to use it.

This was actually my first time using Copilot in CLI mode, and I was instantly amazed at how good of a communicator it is. The variety of model options is fantastic too, and I really appreciate the token system, each model consumes a specific number of tokens, allowing you to choose based on the complexity of your task.

Copilot CLI didn't just help me create beautiful visuals and make the front-end fully responsive, it also helped me refine all the ideas I had sketched out before even starting to code. It improved my calculations to handle edge cases I hadn't considered, like normalizing longitude values.

Here's how the conversation went like:

Me: Can you explain the purpose of this normalization function?
Copilot CLI:
This function ensures longitude values stay within the valid range of -180° to +180°.
Why it's needed:
- Longitude wraps around the Earth (180° and -180° are the same line - the International Date Line)
- If a user pans the map far right, Leaflet might report longitude as 370° instead of 10°
- API calls and distance calculations need standard -180 to 180 range
How it works:
1. lon % 360 - Wraps values into -360 to 360 range
2. If > 180 → subtract 360 (e.g., 270° → -90°)
3. If < -180 → add 360 (e.g., -270° → 90°)

Example: User pans to longitude 540° → 540 % 360 = 180 → returns 180° ✓

This is one of the highlights and a perfect example of how Copilot CLI can save you from overlooking subtle details. It really feels like having a fellow engineer by your side, pointing out mistakes, suggesting better alternatives, and even helping you implement them.

Additionally, it was incredibly easy and convenient to create issues on my GitHub project board directly from the CLI. Based on the strategy and implementation details I provided, Copilot generated a neatly organized list of tasks for me. I didn't have to create them manually, which is a process that can be repetitive and time-consuming.

So, Here's the Conclusion

Would I be able to create this project only by myself? - Yes, absolutely.
Would I be able to create the same exact project only by myself in less than 2 weeks? - Probably not - the Copilot CLI really boosted my performance.

I didn't encounter any issues or bugs while using Copilot CLI, which is impressive for a brand-new tool, especially since you'd normally expect at least some minor hiccups.

Overall, I'm absolutely satisfied with Copilot CLI and I think it'll always have room in my toolbox from now on.

And One Last Thing

This app has great potential. I've already planned many features that will be added in the future, and I'd love to see contributions from other software engineers as well.

Check out the high-level roadmap in the screenshot on the website:

Building this app wasn't just a coding challenge, it was a way to bring a piece of my passion for aviation into reality. Every line of code, every architecture decision, and every optimization I made was about connecting people to the thrill of watching planes even if they're stuck at a desk or on the go.

It's amazing how technology can bridge the gap between curiosity and reality. With just a few carefully crafted algorithms, users can feel the sky above them, catch glimpses of planes flying overhead, and experience the small joys I've loved for years.

This project reminded me that the best ideas aren't just about what you create, they're about the feeling they leave behind. For me, it's that little spark of excitement when a plane passes by, and now, thanks to this app, I can share that spark with anyone, anywhere. Working on this app reminded me that nothing makes me feel more alive than building and creating things that I'm passionate about.

Credits

Special thanks to the following projects and services that made this application possible:

OpenSky Network API - An incredible public service providing real-time aviation data that powers this application ✈️

Leaflet - For delivering lightweight and powerful interactive maps

OpenStreetMap - For providing the open-source map data and tiles

Useful Links

GitHub Repository

Demo

Video Explanation

The Real Cost of Loving What You Do: The Uncomfortable Truth About Developer Burnout

Giorgi Kobaidze — Sun, 18 Jan 2026 15:48:39 +0000

Introduction
The Complexity We Underestimate About Burnout
- It Takes Experience and Time to Handle It
- Why Most Burnout Advice Misses the Point
- No One's Coming to Fix You
Why I Can't Stop Reading About Navy SEALs
The Darkest Days of My Burnout
- Bit Off More Than I Could Chew
- Multitasking, A.K.A: Screwing Up Multiple Things at Once
- Trapped in a Vicious Cycle
- Escaping the Cycle
- Checking Your Rearview Mirror is Important
- The Main Reasons in My Personal Case
- Wait, What About Working too Hard or Too Much?
Then What's The Main Cause of Burnout?
- Reflect Honestly on These Factors
And This Is Where the Navy SEALs Reference Comes Into Play
- How Does This Relate to Our Field?
- Discipline, Discipline, Discipline!
Why Burnout Hits Software Engineers Differently
The Method That Keeps Me Running and Avoids Burnout
Summary and Exercise for You
- The Summary
- The Excercise

Introduction

I usually write code-heavy articles filled with snippets and concepts meant for a very specific crowd, the "chosen ones".

This one is different.

It's still about software engineering, but instead of code, it's a "let's talk about it" kind of article. Even if you're not a software engineer, this will likely feel familiar. Burnout exists in every career. No matter what you do at a professional level, the work is demanding and harsh.

You're constantly operating near your limits, juggling multiple responsibilities, trying to do everything as well as you can, because performance is expected, on top of that, you have high standards for yourself. And sometimes, even that isn't enough, leaving you feeling like you need to push even harder, you don't trust your perception of your limits, you think that there's much more to give.

If this sounds familiar, keep reading. You may find perspectives you haven't considered before, ones that could help break the friction loop that causes your burnout.

I'll share the time when my burnout reached its absolute peak, and at the end of the article, I'll give you a small exercise you can try, one that might just help you break free from burnout.

The Complexity We Underestimate About Burnout

It Takes Experience and Time to Handle It

I'm no different, I've struggled with the same condition for a while in the past and sometimes it still stops by to say hello. But now, with experience, I can handle it more calmly and easily. It's never actually easy, and it can still jab me in the face, but understanding what causes it and why it hits so hard makes it more manageable. It might still hurt, but at least it won't knock me down.

Why Most Burnout Advice Misses the Point

I've read plenty of articles regarding this topic, but very few really delivered a message I could relate to. Most felt like they were written to make me feel better about myself, a temporary shelter where I could justify not working on my skills or personal projects because I was burned out. Sure, sometimes we need a little comfort and a reminder that we're still awesome, but in the long run, that doesn't actually help, does it?

No One's Coming to Fix You

When I spend my own time reading about mindset, discipline, or work ethic, I'm looking for long-term benefit. The best way to get that is by being honest with yourself, figuring out what's really holding you back from becoming a better software engineer, leader, or professional in your career. I'm not interested in fake "you're awesome!", "you're a winner!" "you can do anything!" type of nonsense. I'm looking for something, that'll point out where I'm an absolute loser at. So I can address it.

In today's world, very few people will be that brutally honest with you. The ones who do, are the people who truly care. But nobody can study you full-time, so it's up to you to do the work: reflect on your career, run experiments, and debug your own system. Identify your flaws, confront them, and use that insight to grow.

Why I Can't Stop Reading About Navy SEALs

Before we dive into burnout itself, let's set the stage. This topic is complex and touches on many different areas, so establishing a clear reference point will help explain the core concept more effectively.

If I were to recommend a book to someone trying to improve their life or start a new career with the right mindset, I'd advise staying away from the commonly hyped titles that everyone talks about but rarely deliver real value. The reason is simple: they teach the techniques, but they don't tell the story, and without the story, it just doesn't stick.

Instead, look for books written about real stories. Storytelling is one of the most underrated tools in almost everything. A good story captures attention, draws you in, and makes you want to learn more. That's why I recommend reading books that share real experiences, you'll gain lessons you can actually apply.

As a software engineer, you wouldn't expect me to relate to Navy SEALs in any way. Does it sound strange? Absolutely. But reading their stories has been incredibly valuable, it actually helped me uncover why I was constantly feeling burned out.

Navy SEALs are an elite special operations force. The name "SEAL" comes from Sea, Air, and Land, meaning they are trained to be excellent in any environment imaginable. They are basically the toughest humans on the planet, which is why their selection and training process is brutally demanding, almost impossible to pass.

What's most fascinating is that the training isn't designed to lead to comfort or ease afterward. In fact, the challenges they face in real-life missions are far tougher and exponentially more dangerous than anything in training.

It's hard for the regular, common people to understand this, because the common mindset always seeks comfort and convenience. SEALs think differently, they embrace the struggle completely. I remember one of them saying something like:

"Those moments when everything feels heavy, quiet, and painful, that's where self-respect is built."

And the more I think about it, the more I'm convinced how true it is.

You're probably wondering what all of this has to do with burnout, especially in software engineering. Stick with me, we'll uncover it all.

The Darkest Days of My Burnout

As I mentioned in the previous section, sharing knowledge or giving advice without proper storytelling is pretty dull. It's like eating a burger without sauce, sure, it fills you up, but the experience is nothing alike. The richer the experience, the more unforgettable it becomes and the more it can positively affect you. With that in mind, I'll share as much as I can about what the best (or worst) version of burnout has meant personally for me.

Bit Off More Than I Could Chew

This was a long time ago, when I was still a beginner software engineer. I decided to learn multiple completely different things at once while staying extremely productive at work, because I wanted to reach the senior level as fast as possible and keep up with seasoned developers, some of them with five times more experience than me.

Not only that, I wanted to be self-sufficient right away, meaning I decided to learn every part of the software engineering at the same time.

Back then, I didn't have much experience and didn't really know the most effective ways to work or learn. I bought a bunch of video courses and tried to go through them all in parallel to "save time" - BIG MISTAKE.

Multitasking, A.K.A: Screwing Up Multiple Things at Once

Let's be honest here, who ever learned anything in tech just by watching someone else do it? Nobody. I'm no exception.

Back then, I hadn't realized that a 30-hour video course doesn't mean you'll master the topic in 30 hours. You need to multiply that time by at least 15 just to grasp the basics, the foundation on which you can build real knowledge and experience. Unless you write code yourself, you don't really know anything, all you're doing is memorizing, and memorization alone never works.

Trapped in a Vicious Cycle

I was miserable. My plan was failing and I felt completely unlike the person I was when I started. I watched the tutorials and did exactly the same as they did, sometimes not even that. I made no progress, life felt boring, and I definitely couldn't keep up with the seniors around me.

I forced myself to work overtime, going home at 10 PM or later, and then spent almost the entire night/morning watching tutorials or building meaningless, goalless apps. I had no discipline, I was doing everything without a plan or real commitment.

Sometimes, out of boredom, I'd stop a tutorial halfway through and play video games late into the night to "unwind". But it didn't even feel fun, I was just pretending to have fun. Then I'd wake up after three hours of sleep and drag myself to work, clueless about how I was supposed to function. Somehow, I still did, probably coffee? I don't really know.

I was completely stuck in a vicious circle that looked something like this:

That almost broke me.

I was visibly overwhelmed, not enjoying life, and making no real progress. The worst part was that I wasn't even trying to change anything, I was too stubbornly persistent to step back and rethink what I was doing.

Escaping the Cycle

This peak period of burnout and stress lasted about 3 to 4 months. Luckily, at some point, I decided to reflect on the road I had traveled so far and realized that all the struggle, sleepless nights, and mental and physical strain hadn't brought any real progress whatsoever. Quite the opposite, in fact.

It was alarming. I knew I had to change my approach because continuing like that wasn't doing me any favors. Burnout can easily turn into depression, and we all know that's a place you don't want to be at. Looking back, admittedly, I was there without even realizing.

Checking Your Rearview Mirror is Important

I'm a true believer of always moving and looking forward, but occasionally you need to check your rearview mirror to make sure there's no danger behind you. I know people who say, "Never look back, doesn't matter if it's bad or good" - WRONG!

Ignoring the past means missing out on valuable lessons, especially when you view them with a fresh, current perspective.

I don't play chess, but I've watched professional players, both the winner and the loser review their moves immediately after the game. It doesn't matter where past actions got you, reflecting on them is still incredibly valuable. It teaches you what to do better in the future.

If I hadn't taken the time to evaluate my progress and the road I'd traveled so far, I'd have stayed stuck in that burnout loop much longer, causing even more damage to myself and my career.

The Main Reasons in My Personal Case

In hindsight, the main reasons I burned out were:

Lack of specific goals: I was doing everything just for the sake of doing it.
Lack of commitment: I wasn't motivated or excited to tackle tasks consistently.
Nonexistent discipline: I worked based on how I felt each day, with zero consistency.
Chasing quick dopamine hits: when coding or learning got boring, I'd switch to social media or video games. Even then, I wasn't truly enjoying myself, I was just pretending.
Making excuses for slow progress: I never questioned my approach and always found lame reasons for lack of results.
Fear of leaving my comfort zone: this actually translates to "fear of achieving a much better life and career".
False expectations: before I started working as a software engineer, I imagined it would be a nonstop process of exciting problems and constant feature development. The reality is different: at some point, you get stuck in a routine, and it can feel dull.

Wait, What About Working too Hard or Too Much?

Some of you might be wondering why "working too hard" or "working too much" isn't on my burnout list. Let's dive into that.

To be honest, what I was doing back then was far from true "hard work." As I mentioned earlier, I had no real discipline, and my bursts of intense work weren't consistent. Working hard for two or three hours a day while coasting the rest of the time doesn't make you a hardworking person. In my case, burnout had nothing to do with overworking.

As for working too much, it would be a lie to say I wasn't putting in long hours, sometimes I'd go to bed at 3 or 4 AM, or even later. But what's the point of working that much if it doesn't actually lead to anything? It's just convincing yourself that you're being productive.

Those long sessions contributed to my burnout, but not in the way you might think. It wasn't that I was putting in massive effort every minute and wearing myself down over time, it was that I was spending hours boring myself by accomplishing almost nothing. I was like a car idling with the engine on: burning fuel, going nowhere, and slowly getting rusty in the process.

When I said I didn't relate to most articles on this topic, this is what I meant. Most of them suggest things like "take it easy," "limit your coding time," or "do something else instead." For me, that NEVER, EVER worked.

Burnout isn't about how hard or how much you work, or about what other activities you do besides coding or learning. I've tried plenty of things like walking, running, working out, even meditating, but none of that gets rid of burnout on its own. Sure, they can help a little, but unless you identify the main, core reason behind it, burnout will always find a way back, no matter how many distractions or hobbies you add.

Then What's The Main Cause of Burnout?

There's no single cause, or set of causes for burnout. It can depend on many different factors, including your personality. But the bottom line is this:

If you genuinely enjoy what you do, burnout is unlikely to happen, no matter how much or how hard you work in a day. There's a huge difference between feeling tired and being burned out, and it's critical to recognize that distinction.

Have you ever felt tired but still completely happy? I have, and it's absolutely amazing. I remember working on projects so exciting that I'd skip sleep, sometimes going almost three nights without rest, let alone sleep, just because I just didn't want to stop coding. I was so exhausted that my eyes would close on their own, and I was barely holding on with a huge coffee mug by my side.

But I didn't care for a second. I coded not because of deadlines, and not because I couldn't do it later, I coded because I was in my flow state, which was way too precious to break.

Was I tired? Absolutely!
Was I Burned out or stressed? Not at all!

In fact, I felt incredible, because I was doing something meaningful and absorbing an enormous amount of knowledge that I knew would pay off massively in the future.

That's one of the many reasons why I keep coding and writing articles even when I don't have to - I'm addicted to that rewarding feeling of creating something new, whether it's a software or an article.

So before you label yourself as a burned-out developer, ask yourself: are you just tired, the kind of tired that goes away after a good night's sleep? To find out, try getting a solid 8 hours of sleep for 2-3 days and observe your mood and motivation. If you feel significantly better afterward, congratulations! You're not burned out, you're just tired. You just need a proper system and a good sleep schedule, and you'll be back on track.

⚠️ However, if you:

Feel stressed out all the time
Struggle to even tackle the simplest tasks at work, like adding a button, implementing a basic CRUD operation, or reviewing a simple code change properly
Feel sleepy during the day but can't fall asleep at night
Don't know what to chase or focus on when you wake up
Experience severe anxiety even during a short, easy 15-minute call
No longer feel excited about new features or enhancements
Lack discipline and just do things arbitrarily
Only do activities because they're labeled as "fun", without actually enjoying them
Feel like you're just coasting, working only for your paycheck (and even that doesn't make you properly happy)
Struggle with peak-level impostor syndrome

Then it's likely that you're dealing with real burnout, not just tiredness. And you need to start addressing it as soon as you can.

Reflect Honestly on These Factors

When it comes to developer burnout, it's important to reflect on your own habits, mindset, and approach to work and learning. Consider the following factors:

Impostor Syndrome

Feeling like you need to be as skilled as developers with years of experience immediately is a common trap. Comparing yourself to others can create unnecessary pressure and stress.

Lack of Experience

Mastery takes time. No matter how hard you try, it's unrealistic to expect instant expertise. Understanding this helps set more reasonable expectations.

Wrong Direction

Not developing the right skills or learning in an inefficient way can lead to frustration and slow progress. Focus on learning methods that actually help you grow.

Overly Self-Critical

Perfectionism is a silent burnout driver. Everyone needs to accept that mistakes and failures are part of learning. It's okay to fail, you can't be perfect all the time.

Unreasonable Ambition

Ambition is important, but spreading yourself too thin across multiple programming languages, frameworks, or domains can backfire. Trying to master backend, frontend, mobile, desktop, and game development simultaneously is unrealistic for beginners, and even seasoned developers struggle with that. Focus on one area to specialize in, while maintaining a general understanding of other areas - that's actually where I made a huge mistake.

Lack of Goals or Discipline

Having no clear goal or system for growth can be isolating in software engineering. Regardless of how well you're doing at work, personal projects, learning, certifications, research, blogging, or tutorials give your career purpose. To make progress:

Plan your day and allocate time for meaningful work outside of your job.
Be mindful of time spent on low-value activities, such as endless scrolling on social media, and replace part of it with growth-oriented activities. Avoid rotting your brain.
Recognize that "relaxing" isn't always restorative if it doesn't align with your personal goals. Sometimes burnout comes from passive downtime that doesn't feel productive.

Remember the car analogy? Standing still, engine working, but still slowly getting rusty. The only thing that car needs to start moving forward is to shift into drive. For you, finding your "D" gear means identifying the part of your system that actually gets you moving toward meaningful progress, whether it's a disciplined daily routine, a focused learning plan, or a personal project that excites you. Once you engage it, you start moving again, and the rust of stagnation begins to wear off.

The key is to experiment, reflect, and build your own system. Burnout often comes from a mismatch between your ambitions, your approach to work, and the way you spend your time. Being honest with yourself about these factors is the first step toward breaking the cycle.

The bottom line is this: break the loop. You need to do something different, anything. Even the wildest idea can work. For example, if you're a back-end engineer, try a front-end project: learn the basics, pick up the prerequisites, and dive in. Don't get stuck in tutorial hell, it only amplifies stress.

Or start writing tech blogs. Sure, they won't be perfect right off the bat...

BUT THAT'S EXACTLY THE POINT!

The excitement of creating something from scratch is massively underrated. It's like entering a whole new world where everything is fresh and exciting.

That feeling of discomfort and inconvenience? It's actually one of the best feelings you can experience. Convenience is boring, really boring. Living on autopilot is dull, and it slowly but absolutely surely rots your brain. Breaking out of routine and doing something new is how you reconnect with the joy of learning and building again.

And This Is Where the Navy SEALs Reference Comes Into Play

I'm not saying you should go through the "Hell Week" on a San Diego beach, carrying boats and logs in freezing water without sleep for five days, like real Navy SEALs do in training that shapes their future (I'd love to try though).

But let's think about it for a second. Any SEAL can end that excruciating ordeal at any time by simply saying, "I quit" and the instructors will gladly lead them off the beach to a warm shower.

BUT

Here's a particularly interesting part from one of the books I read a few years ago:

"Which can lead to a lifetime of regret" is the key part here. Even though I had already overcome burnout by the time I read this book, it still offered incredibly valuable lessons. Burnout is closely related to stress, but stress rarely comes from working too much. More often, it comes from feeling like you're not achieving anything or losing control of your career. Regret comes from realizing you've been going about it the wrong way all along.

Yes, you're in the "warm shower," which is supposed to feel comfortable and safe, but deep down, it doesn't truly make you feel accomplished. Think about it. In hindsight, you'd rather have traded that comfort for a real achievement, but that chance is gone. All you're left with is the warm shower - a fleeting dopamine hit that ultimately gives you absolutely nothing.

If you had stayed on the beach, continued grinding through discomfort, inconvenience, and pain, even knowing that more challenges awaited, you'd have been growing toward your ultimate goal. Navy SEALs don't train to earn warm showers, they endure the impossible because they want to become elite, doing things most people can't. The discomfort itself is part of the goal.

How Does This Relate to Our Field?

Yes, it's a completely different game, but most of us sign up to become engineers or tech leads because we genuinely love what we do and believe we can handle the toughness that comes with it. This profession was never meant to be easy.

Just like a Navy SEAL must stay in shape mentally, physically, and psychologically at all times, tech professionals must constantly learn new skills, practice them, and stay alert to avoid falling behind. In many ways, it's closer to being a professional athlete than to a regular 9–5 job. If you stop training, you just start going backwards right away.

I personally chose this profession because it isn't something just anyone can do. Not because it's impossible to learn, but because it demands a very specific mindset to stay relevant and competitive over time. Skill alone isn't enough, discipline, curiosity, and consistency are non-negotiable.

If you truly live and breathe what you do on a daily basis, burnout becomes unlikely. In fact, the opposite happens. Burnout often starts the moment you stop doing that, when learning slows down, growth stalls, and you feel the pressure of standing still while everyone else keeps moving forward.

Discipline, Discipline, Discipline!

I've mentioned discipline many times throughout this article and for a very good reason. One thing Navy SEALs are exceptional at, and something without which it's literally impossible to become one, is discipline.

I believe discipline is one of the most underrated skills anyone can have, especially in a field like software engineering. Reading books about Navy SEALs made me painfully aware of just how undisciplined I had been in comparison. That contrast was eye-opening.

What I quickly realized is this: an unclear mind and an unstructured life are among the biggest contributors to stress and burnout. Chaos isn't just external, it lives in your daily habits, your routines, and the way you make decisions.

Discipline removes that chaos. When you're disciplined, you do the work regardless of whether you feel like doing it or not. You don't negotiate with your mood, your motivation, or your temporary emotions. You simply execute.

And that's exactly why discipline isn't restrictive, it's liberating. It frees your mind from constant decision-making, reduces mental noise, and gives you forward momentum even on the days when motivation is nowhere to be found.

Discipline builds self-respect, because it proves to you that you do what you said you would and you'll have more trust in yourself in the future.

If you want to test your level of discipline, ask yourself this:
Can you stay productive every single day and follow predefined patterns that keep you consistent, or are you productive only when you're forced to be?

For example if you wake up at 6:00 AM on weekdays because you have no choice, but sleep until 9:00 AM on weekends and waste the day binge-watching shows or doom-scrolling reels, that's not discipline.

Discipline doesn't turn off when your calendar is empty or someone's not watching.

Most Navy SEALs keep their routines long after they retire, often for the rest of their lives. No one is yelling at them anymore. No one is forcing them to wake up early, train, or stay sharp. They do it because comfort makes them weak and structure keeps them dangerous and useful in the best possible sense. They've trained their minds to reject convenience because they've learned a hard truth: comfort feels good short-term, but it destroys you long-term. Discipline, on the other hand, is uncomfortable, but it's the only thing that keeps you useful, relevant, and mentally sharp.

Being decisive and a doer is one of the strongest traits you can develop to keep burnout away. Overthinking can lead to disaster, in a silent way. Learn to respect the idea of "good enough".

If your knowledge is good enough to start a new project, pursue a certification, apply for a new job, or even pivot to a new career, just stop hesitating. Start, and start NOW! Put the gear lever into D. The light has been green for a long time, it's been waiting for you to move 🟢.

Real action is what breaks vicious cycles. Not planning. Not thinking. Not consuming more content. Action. And once you break through that cycle, you prove to yourself that burnout and stress aren't permanent states, they're symptoms of stagnation.

All you need is traction.
Once you have that, acceleration becomes inevitable.

Why Burnout Hits Software Engineers Differently

As I mentioned at the beginning of this article, burnout exists in every profession. But burnout in software engineering is particularly brutal. Not because we're special or entitled, but because the tech world is unforgiving in ways most fields aren't.

The pace is relentless. The uncertainty is constant. Technologies change, expectations shift, and the definition of "good enough" keeps moving forward. It's a career that constantly makes you question your skills, your decisions, and sometimes even your choice of profession.

That persistent doubt is what makes burnout in software engineering so severe.

Here's a short list of things that often overwhelm software engineers and tech leaders:

Balancing being generalist vs. specialist: should you focus deeply on one area or spread yourself across multiple domains? Finding the right balance is stressful and often feels impossible.
Design decisions and self-doubt: even when you make the most optimal design choices, you constantly question yourself: could it have been better? What if I missed something?
The endless sea of frameworks and tools: new programming languages, libraries, and frameworks appear constantly. Just keeping up with the pace, especially in fast-moving ecosystems like for example JavaScript is exhausting.
Choice paralysis for learning: you want to stay relevant, but picking what to learn next can feel impossible. It has to be useful, interesting, and applicable in real projects, otherwise it's wasted effort.
Fear of getting rusty: at work, you only use a limited set of skills. Even the most exciting projects can leave you in a routine for months or years. Without coding outside work, other skills atrophy, and anxiety about becoming irrelevant builds.
AI and automation fears: while AI can boost productivity, many engineers worry it will replace them. This uncertainty only amplifies stress and burnout.
Changing industry trends: the tech boom of the 2010s made job security feel abundant. Today, layoffs, slowdowns, and shifts caused partially by AI have made the future feel unstable, adding more pressure for every engineer.

Yes, it's tough. Yes, it's real. And yes, it's stressful and worrying. I'm on the same page. But how we position ourselves in the market is entirely up to us. We have every tool we need to become exceptional professionals.

From my experience, stress and burnout don't help you, not even a little. They don't push you forward, they freeze you in place for weeks, months, or even years. And that's exactly what you don't want as a tech professional.

The Method That Keeps Me Running and Avoids Burnout

My best technique for avoiding stress is embracing the privilege of being in a field that demands nothing less than your absolute best, just like Navy SEALs. They spend their entire careers training, mastering new skills, and taking on missions most minds can barely imagine. But they see it as a privilege, not a burden.

The same applies to doctors, pilots, professional athletes, CEOs, and other high-stakes professions. These roles are tough, full of responsibility, and often stressful, but when you rise to the challenge, they're also deeply rewarding. Stress becomes a signal of growth, not a trap.

Who needs a boring job anyway?

Summary and Exercise for You

The Summary

Burnout is a tricky topic. It's more about psychological exhaustion than physical fatigue, and surprisingly, it's often caused by not using your full potential, not by overworking.

Finding the most effective ways for using your potential is like driving an F1 car at its limit through a corner. When approaching the corner, you need to slow down by pressing the brake pedal just hard enough not to lock up the tire in the process. Go in too hot and you'll miss the corner. When exiting the corner you need to apply just the right amount of throttle and steering lock not to spin the rear tires, lose the grip and spin around, causing losing a significant amount of time.

Developer burnout is much the same. Spin your tires in the wrong way - mismanage your energy, progress, or focus and friction builds up, smoke rises, and you stall. The solution? Be methodical. Balance your pace, check your progress, and manage your energy carefully. That's how you win the race and your career.

And the foundation of all this? Discipline. Everything else like skills, growth, success builds on top of it. Everything!

The Excercise

I'm not going to give you strict step-by-step rules, because everyone's personality and situation is different. Instead, here's a high-level framework, you can customize it to what works best for you.

If you're suffering from burnout, try the following for the next full month:

Map your vicious cycle: pick a day to sit down and identify where you're stuck. Physically draw the cycle that stresses you out.
Find the weakest point: where can the cycle be broken? For example, if you're not doing personal projects but have time, start there. Pick an idea, it doesn't need to be groundbreaking. Even something simple, like a todo app, works.
Commit fully, take it seriously: attach yourself to your idea, project, certification, or blog. Think about it often, the more you engage, the easier and more exciting it becomes.
Avoid quick dopamine hits: please stay off social media, reels, and other brain-rotting distractions. Instead, focus on the long-term satisfaction of completing your project and the impact it can have.
Use AI wisely: tools are helpful, but you're the operator. Find a balance between using it too much and not using it at all.
Stick to a strict morning routine: wake up early and follow the routine every day, even on weekends or holidays.
Be mindful of your time: plan, track, and manage it carefully.
Document your progress: keep a log of what you do daily.
Commit daily: make GitHub commits or other measurable actions to track consistency.
Whenever you have to do something, do it now: don't procrastinate. Bugs, refactoring, learning, or tests, do it now. There's no better moment than the present.

After a month, compare how you feel now to how you felt at the start. Don't worry if your project isn't finished, that's not the goal. The goal is consistency, reflection, and growth.

If you love the process, keep going, it will do wonders for you. If you hate it, first check honestly: were you consistent, or did you slack off? Either way, you'll gain clarity on what you need to improve to reduce stress and burnout.

Remember: you're in a privileged position, don't waste it!

.NET 10: The Performance Beast That's Redefining Modern Application Development

Giorgi Kobaidze — Sun, 14 Dec 2025 13:47:37 +0000

Introduction
- Microsoft's Boldest .NET Release Yet
- What This Article Covers and Who Should Read It?
- .NET Support Policy
- Playground Repository
C# 14: Language Features
- Extension Members
- Null Conditional Assignment
- Field Access in Auto Properties
- Simple Lambda Parameters With Modifiers
- User-Defined Compound Assignment Operators
- Partial Events and Constructors
- Unbound Generic Types in nameof
.NET 10 New Features
- File-Based Apps
- Validation in Minimal APIs
- MCP for .NET Developers
- Security Improvements
- Aspire 13
- Performance
Other Changes
- Visual Studio 2026
- Github Copilot App Modernization
Summary
- What We Covered
- Migration Recommendations
- Final Thoughts

Introduction

Microsoft's Boldest .NET Release Yet

After years of relentless innovation Microsoft drops .NET 10 in November 2025 with a clear message: performance, developer productivity, AI, and cloud-native excellence are no longer competing priorities they're table stakes.

.NET 10 isn't just an incremental update. It represents a fundamental shift in how we think about building applications in an AI-first, cloud-native world. With major performance improvements in critical paths, C# 14's game-changing language features, and ASP.NET Core's radical simplification of web development, this release challenges everything we thought we knew about the limits of managed runtime performance.

What This Article Covers and Who Should Read It?

This article is for:

.NET developers who are unsure about upgrading to the latest version
Non-.NET developers who are hesitant about adopting .NET

Whether you're a:

Backend developer drowning in latency requirements and looking for legitimate performance gains
Frontend developer who's fed up with endless JavaScript churn and tangled toolchains, Blazor and MAUI offer a cleaner, unified, C#-powered alternative that actually lets you focus on building, not babysitting frameworks
Architect evaluating whether .NET 10's LTS stability combined with cutting-edge features makes it the right choice for new projects
Engineering manager / Tech Lead making platform decisions that will impact the next 3-5 years while balancing delivery pressure, team productivity, and long-term maintainability
Full-stack engineer tired of maintaining separate frontend and backend codebases
DevOps engineer optimizing container costs and deployment pipelines

You'll find concrete, actionable insights backed by benchmarks, code examples, and real-world migration experiences.

Disclaimer: This is a large article with a lot of information and reasonable depth. However it still doesn't cover everything introduced recently, doing that would require a 900-page book (or more).

The goal here is to highlight the most interesting and useful additions from my perspective, share my opinions and trade-offs, and provide demo examples that make each topic easier to understand.

As a principal software engineer myself, I'll need to work with this framework at some point, so this article also serves as structured notes for my future self - a way to quickly regain context and insights without relearning everything from scratch.

.NET Support Policy

Here's the best part: .NET 10 is a Long Term Support (LTS) release, supported for three full years until November 2028. Unlike .NET 9 (STS) which only receives 18 months of support, .NET 10 combines cutting-edge features with enterprise-grade stability.

Check out the .NET lifecycle table for the currently supported versions:

Version	Original Release Date	Release Type	End of Support
.NET 10	November 11, 2025	LTS	November 14, 2028
.NET 9	November 12, 2024	STS	November 10, 2026
.NET 8	November 14, 2023	LTS	November 10, 2026

.NET follows a predictable release cadence where even-numbered versions receive Long Term Support (LTS). This makes .NET 10 the perfect storm for adoption: you get bleeding-edge features wrapped in enterprise-grade support commitments. Unlike .NET 9 which forces you to choose between cutting-edge capabilities and long-term stability, .NET 10 delivers both. This is the sweet spot: groundbreaking performance improvements with the long-term commitment that production systems demand. Sounds like a great deal doesn't it?

Playground Repository

Some of the code examples in this article comes from real, runnable code in my repository. Rather than trust code snippets and demos, you can clone the repository, run the code on your own hardware, and see how it all plays out for yourself.

Also, feel free to fork the repository add your own code and create pull requests to contribute.

georgekobaidze / dotnet10-playground

.NET 10 & C# 14 Playground

A lightweight playground repository for experimenting with and testing new features introduced in .NET 10 and C# 14.

Use it to explore language changes, try out APIs, and validate ideas in isolation without production constraints.

View on GitHub

If you'd like to follow along, start by downloading and installing .NET 10 from the following link: https://dotnet.microsoft.com/en-us/download/dotnet/10.0

To generate a repository with a structure similar to mine, it's much easier to use the CLI than to manually create files and folders through a GUI. You can follow the instructions I outlined in one of my previous articles:

Giorgi Kobaidze

May 15 '25

Kickstarting a .NET Solution from Scratch with the CLI

#dotnet #cli #softwareengineering #terminal

Comments

6 min read

Now that the groundwork is laid, let's dive in.

C# 14: Language Features

Extension Members

This is an interesting new feature that could reshape how we write extension methods. And on top of that, we now also have things like:

Extension properties
Extension operators

The best way to describe the purpose of extension methods is that they "enable you to "add" methods to existing types without creating a derived type, recompiling, or modifying the original type." This definition comes straight from Microsoft's official documentation.

The most interesting part is that this feature isn't just more syntactic sugar, it's something new to C#, with real potential to simplify code and make it more elegant and readable. And, of course, it's completely optional, whether you choose to use it is entirely up to you.

Syntax

Instead of the traditional way (static class + this keyword in method parameter), C# 14 allows a cleaner extension(...) { ... } block inside a static class.

Inside this block, you define extension methods, properties, or even operators, and the "receiver" type (the type you're extending) is declared just once.

Example

Let's implement examples for each type of extension member so we can explore their full potential and see exactly how they behave.

I'm going to use the ConsolePlayground project for this task from my repository.

The "Point"

Let's make our example about a Point, because, well, what's the point without a point, right? Get it?😏 OK, I see myself out.

Ever taken a math class? Then you probably remember that a point has two coordinates: X and Y. (Sure, it can have more, but we're just trying to make up an example alright? We're not trying to launch a Mars rover here. Not yet, anyway.)

This definition opens the door pretty wide for modeling a point mathematically and turning all that into code. Don't worry, we're not going full "mad scientist" here. We'll just add a few properties, methods, and operators for demo purposes.

Let's define the following members:

Extension properties: Magnitude and IsAtOrigin

Static extension properties: Origin and UnitX

Instance Extension Methods: Translate and DistanceTo

Static Extension Method: FromPolar

Extension Operators (Binary): + and *

Extension operator (Unary): -

Let's create the Point.cs file, which will contain a record for Point.

public record Point(double X, double Y);

And a separate file for the extensions: PointExtensions.cs

public static class PointExtensions
{
    extension (Point point)
    {
        // Instance Extension Properties
        public double Magnitude => Math.Sqrt(point.X * point.X + point.Y * point.Y);
        public bool IsAtOrigin => point.X == 0 && point.Y == 0;

        // Static Extension Properties
        public static Point Origin => new(0, 0);
        public static Point UnitX => new(1, 0);

        // Instance Extension Methods
        public Point Translate(double dx, double dy) => new(point.X + dx, point.Y + dy);
        public double DistanceTo(Point other)
        {
            double dx = point.X - other.X;
            double dy = point.Y - other.Y;
            return Math.Sqrt(dx * dx + dy * dy);
        }

        // Static Extension Method
        public static Point FromPolar(double radius, double angleRadians)
        {
            return new Point(
                radius * Math.Cos(angleRadians),
                radius * Math.Sin(angleRadians)
            );
        }

        // Extension Operators (Binary)
        public static Point operator +(Point left, Point right) =>
            new(left.X + right.X, left.Y + right.Y);

        public static Point operator *(Point p, double scalar) =>
            new(p.X * scalar, p.Y * scalar);

        // Extension Operator (Unary)
        public static Point operator -(Point p) =>
            new(-p.X, -p.Y);
    }
}

This shows how each extension member works. It's all very straightforward. The only truly new piece of syntax here is extension(...) { ... }, and even that feels pretty intuitive.

Now, to make things even clearer, let's open Program.cs and see how we can actually use these extension members.

Console.WriteLine("=== C# 14 Extension Members Demo ===\n");

// Static Extension Properties
Console.WriteLine("1. Static Extension Properties:");
Console.WriteLine($"   Point.Origin = {Point.Origin}");
Console.WriteLine($"   Point.UnitX = {Point.UnitX}");

// Static Extension Method
Console.WriteLine("\n2. Static Extension Method:");
var polar = Point.FromPolar(5, Math.PI / 4);
Console.WriteLine($"   Point.FromPolar(5, π/4) = {polar}");

// Instance Extension Properties
Console.WriteLine("\n3. Instance Extension Properties:");
var point1 = new Point(3, 4);
Console.WriteLine($"   point1 = {point1}");
Console.WriteLine($"   point1.Magnitude = {point1.Magnitude}");
Console.WriteLine($"   point1.IsAtOrigin = {point1.IsAtOrigin}");

// Instance Extension Methods
Console.WriteLine("\n4. Instance Extension Methods:");
var point2 = new Point(-2, 3);
var translated = point1.Translate(1, 1);
Console.WriteLine($"   point1.Translate(1, 1) = {translated}");

var distance = point1.DistanceTo(point2);
Console.WriteLine($"   point1.DistanceTo(point2) = {distance:F2}");

// Extension Operators
Console.WriteLine("\n5. Extension Operators:");
var sum = point1 + point2;
Console.WriteLine($"   {point1} + {point2} = {sum}");

var product = point1 * 2;
Console.WriteLine($"   {point1} * 2 = {product}");

var negated = -point1;
Console.WriteLine($"   -{point1} = {negated}");

// Combined Usage
Console.WriteLine("\n6. Combined Usage:");
var complexExpression = Point.Origin + Point.UnitX * 2;
Console.WriteLine($"   Origin + UnitX*2 = {complexExpression}");

Console.WriteLine("\n=== Demo Complete ===");

It'll output the following result:

I'm sold!

Null Conditional Assignment

If you've been writing C# for a while, you're probably familiar with the null-conditional operator (?.) and the null-coalescing operator (??). These have been lifesavers for avoiding NullReferenceException and writing cleaner null-handling code. But there's always been one annoying gap: you couldn't use ?. on the left side of an assignment.

Consider this common scenario: you have a nested object, and you only want to assign a value to a property if the parent object isn't null. Before C# 14, you had to write something like this:

if (person?.Address != null)
{
    person.Address.City = "Seattle";
}

Or the slightly more verbose version:

if (person is not null && person.Address is not null)
{
    person.Address.City = "Seattle";
}

It works, but it's clunky. You're essentially checking for null twice, once in your condition and once implicitly when you access the property.

C# 14 fixes this with null-conditional assignment. You can now write:

person?.Address?.City = "Seattle";

That's it. One line. If person is null, nothing happens. If person.Address is null, nothing happens. Only if both are non-null does the assignment occur. No exception, no ceremony, just clean, readable code.

Why Is This Important?

Reduced boilerplate: You no longer need verbose null checks scattered throughout your code just to safely assign values.
Consistency: The ?. operator already works for method calls and property access. Now it works for assignments too, making the language more consistent and predictable.
Fewer bugs: Every time you write an if statement, there's a chance you'll get it wrong. Maybe you forget to check one level of nesting, or you accidentally use || instead of &&. Null-conditional assignment eliminates these opportunities for mistakes.
Better readability: Code intent is immediately clear. When someone reads person?.Address?.City = "Seattle", they instantly understand: "assign this value only if the path is valid."

Demo Example

Let's see this in action. I'll use the ConsolePlayground project to demonstrate a practical scenario.

Imagine we're building a user profile system where users can optionally have address information:

public record Address
{
    public string? Street { get; set; }
    public string? City { get; set; }
    public string? Country { get; set; }
}

public record Person
{
    public string Name { get; set; } = string.Empty;
    public Address? Address { get; set; }
}

Now let's write some code that updates the address information using null-conditional assignment:

Console.WriteLine("=== C# 14 Null Conditional Assignment Demo ===\n");

// Scenario 1: Person with an address
var personWithAddress = new Person
{
    Name = "Alice",
    Address = new Address { Street = "123 Main St", City = "Portland" }
};

Console.WriteLine("Before update:");
Console.WriteLine($"  {personWithAddress.Name}'s city: {personWithAddress.Address?.City}");

// Using null-conditional assignment
personWithAddress?.Address?.City = "Seattle";

Console.WriteLine("After update:");
Console.WriteLine($"  {personWithAddress.Name}'s city: {personWithAddress.Address?.City}");

// Scenario 2: Person without an address
var personWithoutAddress = new Person { Name = "Bob" };

Console.WriteLine($"\n{personWithoutAddress.Name} has no address.");
Console.WriteLine("Attempting to set city using null-conditional assignment...");

// This safely does nothing because Address is null
personWithoutAddress?.Address?.City = "New York";

Console.WriteLine($"  City after attempted assignment: {personWithoutAddress.Address?.City ?? "(no address)"}");

// Scenario 3: Null person reference
Person? nullPerson = null;

Console.WriteLine("\nAttempting to set city on a null person reference...");

// This safely does nothing because nullPerson is null
nullPerson?.Address?.City = "Chicago";

Console.WriteLine("  No exception thrown! Assignment was safely skipped.");

Console.WriteLine("\n=== Demo Complete ===");

Running this code produces the following output:

=== C# 14 Null Conditional Assignment Demo ===

Before update:
  Alice's city: Portland
After update:
  Alice's city: Seattle

Bob has no address.
Attempting to set city using null-conditional assignment...
  City after attempted assignment: (no address)

Attempting to set city on a null person reference...
  No exception thrown! Assignment was safely skipped.

=== Demo Complete ===

As you can see, the null-conditional assignment gracefully handles all three scenarios:

When the full path exists, the assignment works as expected
When part of the path is null, the assignment is simply skipped
When the root object is null, no exception is thrown

The Old Way vs. The New Way

Here's a side-by-side comparison to really drive home how much cleaner this is:

Before C# 14:

if (order != null && order.Customer != null && order.Customer.Preferences != null)
{
    order.Customer.Preferences.NotificationsEnabled = true;
}

C# 14:

order?.Customer?.Preferences?.NotificationsEnabled = true;

The improvement speaks for itself. Less code, fewer chances for bugs, and the intent is crystal clear.

This might seem like a small change, but it's exactly the kind of quality-of-life improvement that makes a language more enjoyable to use day-to-day. It's one less thing to think about, one less pattern to remember, and one less source of potential bugs.

Field Access in Auto Properties

Auto-properties have been one of C#'s most beloved features since their introduction. They let you write public string Name { get; set; } instead of manually declaring a backing field and wiring up the getter and setter. Clean, simple, elegant.

But here's the problem: the moment you need to add any logic to your property, like validation, transformation, or lazy initialization, you lose the auto-property syntax entirely. You have to fall back to the old-school approach:

private string _name = string.Empty;

public string Name
{
    get => _name;
    set
    {
        if (string.IsNullOrWhiteSpace(value))
            throw new ArgumentException("Name cannot be empty");

        _name = value;
    }
}

Suddenly you're back to declaring backing fields, picking naming conventions (_name, m_name, name), and dealing with extra boilerplate. For a single property it's fine, but when you have a dozen properties (or hundreds of properties) that all need validation, your class becomes a wall of repetitive code.

C# 14 introduces the field keyword, which gives you direct access to the compiler-generated backing field within your property accessors. Now you can write:

public string Name
{
    get;
    set
    {
        if (string.IsNullOrWhiteSpace(value))
            throw new ArgumentException("Name cannot be empty");

        field = value;
    }
}

No explicit backing field declaration needed. The compiler creates one for you, and you access it using the contextual keyword field. You get the best of both worlds: the conciseness of auto-properties with the flexibility of custom logic.

Why Is This Important?

Less boilerplate: You don't need to declare backing fields manually anymore. The compiler handles it, and you just reference field when you need it.
Cleaner code: Your classes stay focused on what matters, the logic, rather than being cluttered with field declarations and naming conventions.
Consistency: No more debates about _name vs m_name vs name. The backing field is anonymous and accessed uniformly via field.
Gradual enhancement: You can start with a simple auto-property and add logic later without restructuring your code. Just add the accessor body and use field.
Works with both get and set: You can use field in either accessor, or both, depending on your needs.

Demo Example

Let's build a practical example. Imagine we're creating a Product class for an e-commerce system with properties that need validation and transformation:

public class Product
{
    // Simple validation: price must be non-negative
    public decimal Price
    {
        get;
        set
        {
            if (value < 0)
                throw new ArgumentOutOfRangeException(nameof(value), "Price cannot be negative");

            field = value;
        }
    }

    // Transformation: automatically trim and capitalize the name
    public string Name
    {
        get;
        set
        {
            if (string.IsNullOrWhiteSpace(value))
                throw new ArgumentException("Product name cannot be empty", nameof(value));

            field = value.Trim();
        }
    }

    // Lazy initialization with field access in getter
    public string Slug
    {
        get => field ??= GenerateSlug(Name);
        set;
    }

    // Stock quantity with change tracking
    public int StockQuantity
    {
        get;
        set
        {
            if (value < 0)
                throw new ArgumentOutOfRangeException(nameof(value), "Stock cannot be negative");

            int oldValue = field;
            field = value;

            if (oldValue != value)
                Console.WriteLine($"Stock changed from {oldValue} to {value}");
        }
    }

    private static string GenerateSlug(string name) =>
        name.ToLowerInvariant().Replace(" ", "-");
}

Now let's test this class:

Console.WriteLine("=== C# 14 Field Keyword Demo ===\n");

var productItem = new Product();

// Test Name with trimming
Console.WriteLine("1. Setting product name with extra whitespace:");
productItem.Name = "   Wireless Headphones   ";
Console.WriteLine($"   Stored name: \"{productItem.Name}\"");

// Test Price validation
Console.WriteLine("\n2. Setting valid price:");
productItem.Price = 99.99m;
Console.WriteLine($"   Price: {productItem.Price:C}");

Console.WriteLine("\n3. Attempting to set negative price:");
try
{
    productItem.Price = -10m;
}
catch (ArgumentOutOfRangeException ex)
{
    Console.WriteLine($"   Caught exception: {ex.Message}");
}

// Test lazy slug generation
Console.WriteLine("\n4. Accessing slug (lazy initialization):");
Console.WriteLine($"   Slug: {productItem.Slug}");

// Test stock quantity with change tracking
Console.WriteLine("\n5. Updating stock quantity:");
productItem.StockQuantity = 100;
productItem.StockQuantity = 95;
productItem.StockQuantity = 95;  // No change, no message

Console.WriteLine("\n=== Demo Complete ===");

Running this produces:

=== C# 14 Field Keyword Demo ===

1. Setting product name with extra whitespace:
   Stored name: "Wireless Headphones"

2. Setting valid price:
   Price: $99.99

3. Attempting to set negative price:
   Caught exception: Price cannot be negative (Parameter 'value')

4. Accessing slug (lazy initialization):
   Slug: wireless-headphones

5. Updating stock quantity:
Stock changed from 0 to 100
Stock changed from 100 to 95

=== Demo Complete ===

The Old Way vs. The New Way

Let's compare a class with multiple validated properties:

Before C# 14:

public class User
{
    private string _email = string.Empty;
    private int _age;
    private string _username = string.Empty;

    public string Email
    {
        get => _email;
        set
        {
            if (!value.Contains('@'))
                throw new ArgumentException("Invalid email");

            _email = value.ToLowerInvariant();
        }
    }

    public int Age
    {
        get => _age;
        set
        {
            if (value < 0 || value > 150)
                throw new ArgumentOutOfRangeException(nameof(value));

            _age = value;
        }
    }

    public string Username
    {
        get => _username;
        set
        {
            if (value.Length < 3)
                throw new ArgumentException("Username too short");

            _username = value.Trim();
        }
    }
}

C# 14:

public class User
{
    public string Email
    {
        get;
        set
        {
            if (!value.Contains('@'))
                throw new ArgumentException("Invalid email");

            field = value.ToLowerInvariant();
        }
    }

    public int Age
    {
        get;
        set
        {
            if (value < 0 || value > 150)
                throw new ArgumentOutOfRangeException(nameof(value));

            field = value;
        }
    }

    public string Username
    {
        get;
        set
        {
            if (value.Length < 3)
                throw new ArgumentException("Username too short");

            field = value.Trim();
        }
    }
}

The C# 14 version eliminates all the backing field declarations at the top of the class. It's cleaner, more focused, and the relationship between each property and its validation logic is immediately clear.

Why Did This Take So Long?

If you've been following C# development, you might know that this feature has been on the wishlist for years. Developers have been asking for it since auto-properties were first introduced. So why did it take until C# 14?

The answer is simple but important: BREAKING CHANGES.

The word field is not a reserved keyword in C#. It's a perfectly valid identifier. That means there's existing code out there that looks like this:

public class SomeClass
{
    private int field;  // A variable literally named "field"

    public int Value
    {
        get => field;
        set => field = value;
    }
}

If Microsoft had simply made field a full keyword, this code would break. Every project using field as a variable name would suddenly fail to compile. That's millions of lines of code across the ecosystem potentially affected.

The .NET team had to be extremely careful here. They needed to introduce the feature without breaking existing codebases. The solution? Make field a contextual keyword, meaning it only has special meaning in a specific context, inside property accessors where there's no local variable or parameter named field.

What if you have an existing member named field? If your class already has a field literally named field and you want to access it inside a property accessor (where the keyword takes precedence), you have two options:

Use the this keyword: this.field
Use the @ escape: @field

Both of these explicitly tell the compiler "I mean my variable, not the backing field keyword."

public class Example
{
    private int field = 42;  // Your own field named 'field'

    public int Value
    {
        get;
        set
        {
            Console.WriteLine(this.field);  // Refers to the class member (42)
            Console.WriteLine(@field);      // Also refers to the class member (42)
            field = value;                  // Refers to the backing field keyword
        }
    }
}

This careful approach means your existing code continues to work exactly as before. The new feature is purely additive, and when naming conflicts arise, you have clear escape hatches to disambiguate.

This is a great example of how language design isn't just about adding cool features. It's about doing so responsibly, respecting the vast ecosystem of existing code, and maintaining the trust that developers have placed in backward compatibility.

Important Notes

The field keyword is contextual, it only has special meaning inside property accessors. If you have an existing field named field in your code, it will still work, but you might want to rename it for clarity to avoid confusion.
You can use field with property initializers: public string Name { get; set => field = value.Trim(); } = "Default";
This feature works with init accessors too, not just set.

This is one of those features that might seem minor at first glance, but once you start using it, you'll wonder how you ever lived without it. It removes friction from a very common pattern and makes C# properties even more powerful.

Simple Lambda Parameters With Modifiers

Lambda expressions in C# support type inference, so you can write x => x * 2 instead of (int x) => x * 2. But there's been one annoying exception: the moment you add a parameter modifier, you lose the concise syntax.

Before C# 14, if you wanted to use ref, out, in, or params in a lambda, you had to explicitly specify the type:

// Without modifier - type is inferred
Func<int, int> square = x => x * x;

// With modifier - forced to specify type
RefAction<int> doubleIt = (ref int x) => x *= 2;

C# 14 removes this limitation. You can now use modifiers without specifying the type:

RefAction<int> doubleIt = (ref x) => x *= 2;

Supported Modifiers

All parameter modifiers work with implicit typing: ref, out, in, ref readonly, scoped, and params.

The Old Way vs. The New Way

Before C# 14:

ProcessData((ref int x, ref int y) => (x, y) = (y, x));

TryParseAll(items, (string s, out int result) => int.TryParse(s, out result));

Calculate((in Vector3 v) => v.Length());

C# 14:

ProcessData((ref x, ref y) => (x, y) = (y, x));

TryParseAll(items, (s, out result) => int.TryParse(s, out result));

Calculate((in v) => v.Length());

The improvement is especially valuable in high-performance code where ref, in, and Span<T> are common. Instead of cluttering your lambdas with type annotations that the compiler can already infer, you just add the modifier you need and move on.

User-Defined Compound Assignment Operators

In C#, when you write x += 5, the compiler translates it to x = x + 5. This works fine for most cases, but there's a problem: what if you want += to behave differently than +?

This matters for performance-sensitive types. Consider a StringBuilder-like type or a collection. When you write list = list + item, you're creating a new object and reassigning. But list += item could modify the existing object in place, which is far more efficient.

Before C# 14, you couldn't express this distinction. Compound assignment always expanded to the binary operator plus assignment.

C# 14 lets you define compound assignment operators separately. The += operator can now:

Return void instead of the type
Take the first parameter by ref, allowing in-place modification

Demo Example

Let's create a custom 2D vector type to demonstrate this feature:

Console.WriteLine("=== C# 14 User-Defined Compound Assignment Operators Demo ===\n");

var v1 = new Vec2D(3, 4);
var v2 = new Vec2D(1, 2);

Console.WriteLine($"v1 = {v1}");
Console.WriteLine($"v2 = {v2}");

// Using + operator (creates new instance)
Console.WriteLine("\nUsing + operator (creates new instance):");
var v3 = v1 + v2;
Console.WriteLine($"v3 = v1 + v2 = {v3}");
Console.WriteLine($"v1 is still: {v1} (unchanged)");

// Using += operator (modifies in place)
Console.WriteLine("\nUsing += operator (modifies in place):");
Console.WriteLine($"Before: v1 = {v1}");
v1 += v2;
Console.WriteLine($"After v1 += v2: v1 = {v1} (modified!)");

Console.WriteLine("\n=== Demo Complete ===");

// Custom 2D vector struct
public struct Vec2D
{
    public double X { get; set; }
    public double Y { get; set; }

    public Vec2D(double x, double y)
    {
        X = x;
        Y = y;
    }

    // Regular + operator - creates new instance
    public static Vec2D operator +(Vec2D a, Vec2D b)
        => new Vec2D(a.X + b.X, a.Y + b.Y);

    // C# 14: Compound assignment operator - modifies in place
    public static void operator +=(ref Vec2D a, Vec2D b)
    {
        a.X += b.X;
        a.Y += b.Y;
    }

    public override string ToString() => $"({X}, {Y})";
}

Output:

=== C# 14 User-Defined Compound Assignment Operators Demo ===

v1 = (3, 4)
v2 = (1, 2)

Using + operator (creates new instance):
v3 = v1 + v2 = (4, 6)
v1 is still: (3, 4) (unchanged)

Using += operator (modifies in place):
Before: v1 = (3, 4)
After v1 += v2: v1 = (4, 6) (modified!)

=== Demo Complete ===

Why Is This Important?

Performance: Avoid unnecessary allocations by modifying objects in place instead of creating new ones.
Semantic clarity: + means "combine and create new", while += means "append to existing". Now your code can reflect that distinction.
Mutable collections: Types like List<T> or custom buffers can now have += mean "add to this collection" rather than "create a new collection with this item added".

The Old Way vs. The New Way

Before C# 14:

// Both operations did the same thing - create new instance
var result = v1 + v2;     // Creates new instance
v1 = v1 + v2;             // What += expanded to - also creates new instance

C# 14:

var result = v1 + v2;  // Creates new instance
v1 += v2;              // Modifies v1 in place (if custom += is defined)

This feature is particularly useful for numeric types, buffers, builders, and any scenario where in-place mutation is more efficient than creating new instances. It's a niche but powerful addition for library authors and performance-critical code.

Partial Events and Constructors

The partial keyword has been in C# for a long time, allowing you to split a class across multiple files. More recently, C# added partial methods and partial properties. C# 14 completes the picture by adding partial events and partial constructors.

This is especially useful for source generators. A generator can declare a partial constructor or event, and you provide the implementation in your own code. It keeps generated code separate from hand-written code while allowing them to work together seamlessly.

Partial Constructors

// File: MyClass.Generated.cs (from source generator)
public partial class MyClass
{
    public partial MyClass(string name);  // Declaration
}

// File: MyClass.cs (your code)
public partial class MyClass
{
    public partial MyClass(string name)  // Implementation
    {
        Name = name;
        Initialize();
    }
}

Partial Events

// File: MyComponent.Generated.cs
public partial class MyComponent
{
    public partial event EventHandler? StatusChanged;  // Declaration
}

// File: MyComponent.cs
public partial class MyComponent
{
    public partial event EventHandler? StatusChanged
    {
        add => _statusChanged += value;
        remove => _statusChanged -= value;
    }

    private EventHandler? _statusChanged;
}

Why Is This Important?

Source generator friendly: Generators can declare the shape of constructors and events, while you control the implementation details.
Clean separation: Keep auto-generated code in separate files without merge conflicts or manual edits to generated files.
Consistency: The partial keyword now works uniformly across all member types: methods, properties, events, and constructors.

This feature is primarily aimed at source generator authors and scenarios where code is split across generated and hand-written files. If you're not using source generators, you might not need this often, but it's a welcome addition that rounds out the partial member story in C#.

Unbound Generic Types in nameof

The nameof operator returns the name of a type or member as a string. When used with generic types, it only returns the base name, ignoring type arguments:

nameof(List<int>)    // Returns "List", not "List<int>"
nameof(List<string>) // Also returns "List"

The problem? Before C# 14, you had to provide type arguments even though they're completely ignored. This forces you to make an arbitrary choice that has no effect on the result.

C# 14 lets you skip the unnecessary type arguments:

// Before C# 14 - must provide type arguments (even though they're ignored)
var name = nameof(List<int>);              // "List"
var name2 = nameof(Dictionary<int, int>);  // "Dictionary"

// C# 14 - use unbound generic types directly
var name = nameof(List<>);        // "List"
var name2 = nameof(Dictionary<,>); // "Dictionary"

Use empty angle brackets, with commas separating multiple type parameters (just like typeof(Dictionary<,>)).

This is a minor improvement, but it makes your intent clearer: "I want the name of this generic type, and the type arguments don't matter."

.NET 10 New Features

File-Based Apps

This is one of the most significant changes Microsoft has introduced. Despite being one of the most popular languages, C# has always had one major drawback: adoptability. For a new developer trying out C#, even the simplest "Hello World" console app requires a surprising amount of ceremony. You need a solution (an .sln file), a project (a .csproj file), a Program.cs file with usings, namespaces, a Program class, all before you even write your first line of code. Nobody enjoys that, even us, .NET developers who are relatively more used to that.

Compare this to languages like Python, where you can create a single .py file and immediately run print("Hello World!"). Microsoft is now pushing C# in that same direction, making it more approachable for beginners. And to be honest, this change isn't just for newcomers. I've been writing .NET for almost eight years now, and I've always missed this simplicity. Sometimes all you want to do is just test a quick snippet without spinning up an entire solution. This update finally makes that possible.

I've actually written a dedicated article about this change and why it's such a big leap forward. Check out the link below for more details.

Giorgi Kobaidze

May 27 '25

Why I Believe 'dotnet run app.cs' Is a Huge Leap Forward

#dotnet #cli #softwareengineering #csharp

Comments 5

4 min read

Alright, let's give it a try and create our own file-based app. In my repository, I've set up a folder called SingleFileApp, which contains just one file: HeyThere.cs. That's literally all you need, no additional files or setup required to run C# code.

Let's start with a simple line of code that prints a greeting message. Open your command prompt, navigate to the folder containing your file, and run the following:

Quick note: I'm using PowerShell as my CLI. The commands will be similar in other CLIs, but there may be a few subtle differences if you're using Bash or another shell.

echo 'Console.WriteLine($"Hey there {args[0]}!");' > HeyThere.cs

dotnet run .\HeyThere.cs "Folks"

Or simply:

dotnet .\HeyThere.cs "Folks"

Yes! You can actually run the file without explicitly using run. Notice that "Folks" is passed as an argument, this is used by the code to display a customized greeting message.

Now, what if your app needs external dependencies or packages?

Let's make things a bit more interesting: suppose we want to display a calendar below our greeting message. To do this, we'll use the Spectre.Console library.

If you're familiar with C#, you know that dependencies are typically defined in a .csproj file. For example, to add a dependency on this library, you would write something like this:

<ItemGroup>
  <PackageReference Include="Spectre.Console.Cli" Version="0.53.0" />
</ItemGroup>

And the .csproj file would look like the following:

Except now there's no .csproj file, because that's the whole point of the file-based app approach. So how do we handle dependencies?

Well, handling dependencies is quite easy, you just specify the required packages right in the file using the following syntax:

#:package Spectre.Console.Cli@0.53.0

The #: directive is officially called an Ignored Directive

You can even specify an SDK the similar way you specify the package, if you need to, for example, in case you need to include the Aspire AppHost SDK:

#:sdk Aspire.AppHost.Sdk@13.0.0

But we don't need the SDK at this moment so let's just focus on the package. Add the following code to the file:

#:package Spectre.Console.Cli@0.53.0

using Spectre.Console;

var calendar = new Calendar(2025, 11);
calendar.AddCalendarEvent(2025, 11, 16);
calendar.HighlightStyle(Style.Parse("blue bold"));
AnsiConsole.Write(calendar);

Since we don't have to pass any arguments, we can simply run the following command:

dotnet .\HeyThere.cs

The first time you run it, fetching all dependencies and setting everything up may take a little time. Subsequent runs will be much faster.

It will display a neat little calendar right in the console.

You can use the ignore directive for more than just packages. .csproj files contain lots of properties, and the directive can be applied there too.

#:property TargetFramework=net8.0

But what if your app also needs to reference other projects?

You can reference other projects in classic .csproj setups. If you're hoping for the same capability in file-based apps, you're in luck, it's already supported.

Imagine this: you have a class library project in your solution and want to reference it from your file-based app. Let's see how we can make that work using our example.

Let's add a class library containing a single method: string TellMeAJoke();. It will return a random, perfectly awful "knock, knock" joke.

dotnet new classlib -o KnockKnock
cd ..
dotnet sln add .\src\KnockKnock\KnockKnock.csproj

And let's add a new static class where our method will be implemented.

public static class Joke
{
    readonly static string[] jokes =
    {
        "Knock, knock.\nWho’s there?\nLettuce.\nLettuce who?\nLettuce in, it's cold out here!",
        "Knock, knock.\nWho’s there?\nCow says.\nCow says who?\nNo, silly—cow says mooooo!",
        "Knock, knock.\nWho’s there?\nTank.\nTank who?\nYou're welcome!",
        "Knock, knock.\nWho’s there?\nBoo.\nBoo who?\nAw, don’t cry!",
        "Knock, knock.\nWho’s there?\nEtch.\nEtch who?\nBless you!",
        "Knock, knock.\nWho’s there?\nNana.\nNana who?\nNana your business!",
        "Knock, knock.\nWho’s there?\nIce cream.\nIce cream who?\nICE CREAM every time I see a scary movie!",
        "Knock, knock.\nWho’s there?\nHarry.\nHarry who?\nHarry up and answer the door!",
        "Knock, knock.\nWho’s there?\nInterrupting cow.\nInterrupting cow wh—\nMOOOO!",
        "Knock, knock.\nWho’s there?\nWooden shoe.\nWooden shoe who?\nWooden shoe like to hear another joke?"
    };

    public static string TellMeAJoke()
    {
        var rnd = new Random();
        int index = rnd.Next(jokes.Length);

        return jokes[index];
    }
}

Now, we need to reference that project in our file-based app. Take a look at the screenshot:

And now let's run the application to see the output:

You can even build entire web APIs as file-based apps. To do this, you'll need a web SDK, this is exactly where the #:sdk comes into play.

You need to add the following to enable your file-based app to act like a web API:

#:sdk Microsoft.NET.Sdk.Web

Once that's set up, you can start exposing your endpoints and handling requests.

But wait, there's more!

Imagine this scenario: you wrote your code in a single file, and now you want to turn it into a full project. You don't have to do anything manually, there's a handy CLI command that converts it for you. Let's try it:

dotnet project convert .\HeyThere.cs

It will likely ask you to specify an output folder. Once you do, it will generate a new project there. If you take a look inside, you'll see that it also includes a freshly created .csproj file.

Let's open it in Visual Studio Code and take a closer look:

.cs file:

.csproj file:

.sln file

As you can see, it's now a regular .NET project with both .csproj and .sln files. The dependencies are no longer listed inside HeyThere.cs, instead they've been moved into the .csproj file, just like in a traditional setup.

Keep in mind:

If you're a beginner and just want to experiment or see how things work, the file-based app approach is a great starting point. However, for medium to large projects, I wouldn't really recommend it, it simply isn't suited for complex scenarios. Trying to manage a full enterprise application in a single .cs file quickly becomes counterproductive. .sln and .csproj files exist for a good reason, so use them to your advantage.

Validation in Minimal APIs

.NET has introduced built-in, attribute-based validation for Minimal APIs, addressing one of their biggest pain points. Previously, validation had to be handled manually. While this is not a complete disaster, it was far from ideal and often led to cluttered, harder-to-maintain code.

Let's try it out ourselves.

First things first, let's create a new minimal API.

 dotnet new webapi -o TheMostMinimalisticApiOnEarth

Now open the project in Visual Studio 2026. You'll notice quite a bit of code generated by the default template. I'll remove anything unnecessary to keep the solution clean and focused, but feel free to keep everything as is if you prefer.

Once we've removed the unnecessary pieces, add the following endpoint

This is just a dummy endpoint for testing validations, so nothing fancy is needed. It accepts a username, email, and password in the request and registers the user. Next, we'll add validation to the model. But how do we do that?

First, let's enable validations by adding the required service:

builder.Services.AddValidation();

Now, let's apply validation attributes directly to the record. Yes, you can do that! Let me show you how:

Now, let's test these properties using Postman:

It works!

When registering anywhere, you usually need to confirm your password to ensure it matches the original. You could compare passwords manually without validation attributes, but that's not particularly the best practice, this check is part of proper validation.

Let's add a ConfirmPassword property and use attributes to make sure it matches the original:

Uh-oh, looks like we have a red underline situation. Time to investigate and see what's causing the issue:

Okay, now it makes sense. Let's fix it by using the property: keyword:

The error is gone! Let's test it now. This time, we'll provide both correct values and mismatched passwords to see the validation in action.

Finally, let's enter all the correct values and see the demo end with a successful response:

Important! To ensure validations work, your classes or records must be public. If you make them internal, the request will still go through, but the validation won't run.

To be honest, I'm not entirely sure why this is the case, it's a bit counter-intuitive, but it's a quirk you need to keep in mind when using attribute-based validation in Minimal APIs.

MCP for .NET Developers

What Exactly Is MCP?

If you're not familiar with it, MCP is an open-source standard created by Anthropic for connecting AI applications to external systems. Think of it like this: you're building an app that uses an AI model, and you need that model to interact with external tools or data sources, databases, APIs, services, whatever. You can't just tell an AI model to "go get 'em" because models don’t have native access to external systems, they run in isolated environments for security and safety reasons.

Instead, you'd have to build your own API layer or integration for each external system. And if you need to connect to several of them, you end up writing a bunch of custom integrations, which quickly becomes tedious and hard to maintain.

MCP solves this by acting as a universal hub, a standardized protocol for hooking AI systems into external tools. With MCP, developers can build context-aware applications without writing custom integrations for every AI-to-system combination.

MCP in .NET

Microsoft is partnering with Anthropic to develop the official MCP SDK for .NET, with the goal of bringing first-class MCP server support to Microsoft products.

Check out the Repository and docs

There's already a project template you can use to create an MCP server yourself. To install the template, run the following command:

dotnet new install Microsoft.Extensions.AI.Templates

Once you run this script, the following templates will be installed:

And now let's create a new MCP server:

dotnet new mcpserver -n AwesomeMcpServer

Let's open Visual Studio 2026 and take a look at what the template has generated for us:

In this screenshot, you can also see the contents of the Program.cs file for the MCP server project. I won't walk through every file and folder in this template, that's a topic for a separate article, but let's open Tools/RandomNumberTools.cs to see what's inside:

As you can see, the default file includes a simple random number generator. It's not something you'd typically use in a real-world scenario, but it serves as a basic demonstration of how MCP works. At this point, you could just as easily connect to an external source, like a database, and feed real contextual data to your agent.

You know what? Let's use an in-memory storage and save all the unfunny jokes we came up with earlier in this article.

First let's add a new tool in the Tools folder containing our code:

And change the Program.cs file to include this tool instead of the random number generator:

Now let's add it to Copilot. Click the Tools button in the bottom-right corner of the Copilot chat, then click the green plus icon:

And add the new tool:

Once you do that, you'll see your tool listed in the window:

And now, I'm all set to ask my Copilot to generate either all the jokes or just a random one:

Click 'Confirm':

As you can see, it outputted all the jokes, well, you can spot three here, but the full list is much longer, and this is just a part of it.

Now, let's ask Copilot to use the second method and fetch a random joke:

Awesome isn't it?

This example is just scratching the surface, is a bit silly and simple. MCP can do much more, but as I mentioned, that deserves a separate article.

Security Improvements

WebAuthN & Passkey support have been added. Passkeys are essentially cryptographic credentials that replace traditional passwords. They're resistant to phishing, easy to use, and secure by design. Passkeys are built in into the identity framework, though this is actually inspired by an open-source technology: fido2-net-lib, which is widely adopted and reliable.

.NET project templates include passkey support by default. If you have an existing project that uses asp.net identity, you can actually add a passkey support to it, but keep in mind that you'll need a database schema migration.

Aspire 13

Support for JavaScript and Python scripts have been added. It's not .NET Aspire anymore, it's Aspire, but it still runs on .NET.

Observability & Diagnostics

Now that we've touched Aspire 13 and it's new upgrades, let's not skip one cool feature that can come in handy in quite a few cases. Let's see it by example. I'm going to generate a new Aspire Starter App from the template, check out the screenshot:

It'll generate a project with a few different projects like AppHost, ApiService, Web, and ServiceDefaults. I won't go that deep to explain what each does in details, because that'll take a whole another artile, but in short, you have a whole stack ready to go with Aspire, which can be deployed directly to Azure for example. Let's run the application and see what's in there for us:

Let's run the web application and execute a few requests. You can run the application directly from the aspire. Go to the Resources tab and click the URL in the webfrontend column. Now, let's check out the "Metrics" tab:

Go to the "Weather" tab and also the "Counter" tab and click the "Click Me" button several times.

Now let's get back to Aspire and see what has changed in the metrics:

There are a bunch of different metrics right out of the box available for us to observe the performance of the application.

OK let me show you where all this comes from:

This actually comes from OpenTelemetry, which is an observability framework. This is a a cross-platform, open standard for collecting and emitting telemetry data.

Performance

Microsoft have been doing deep refinements in Jitter, garbage collection.

.NET 10 executes high level C# with the efficiency of hand-tuned native code.

.NET 10 uses 93% less memory than .NET 8, which was already very powerful and well-performing LTS version.

Even if you don't change anything in your code and just update the version, you'll get huge performance gains.

Improved Kestrel memory pool management. Previously the memory was retained in the pool. In .NET 10, this memory can be returned to the system to use it for other purposes.

JSON deserialization performance has also improved by utilizing streaming deserialization technique, so JSON can be deserialized in stream instead of doing it all at once.

There are tons of other performance improvements that definitely deserve their own article. However, a comprehensive article already covers pretty much everything, so there's not much to add here. I'll just link it for you, definitely check out that amazing work!

Performance Improvements in .NET 10 - .NET Blog

devblogs.microsoft.com

Other Changes

Visual Studio 2026

Visual Studio 2026 now uses your system resources more efficiently. The more CPU cores you have, the more tasks it can parallelize.

Previously, the UI could hang during loading because the UI thread was blocked by ongoing tasks. In this version, those tasks are moved to background threads, keeping the interface responsive and preventing freezes.

If you're still working with good old WinForms, or have never used it but need to, Visual Studio 2026 has your back! The WinForms Expert Agent helps make the process much less painful. Building or maintaining a WinForms UI can be confusing, especially if you're dealing with a legacy, complex codebase. Think of it like having someone pair-programming with you, handling the tedious stuff so you can focus on the fun parts.

That's pretty cool, but still, please don't use WinForms for new projects, there are many modern, far superior alternatives, such as .NET MAUI.

Github Copilot App Modernization

This feature can be a real lifesaver when upgrading to .NET 10. Not only does it help with the upgrade itself, but it can also deploy your updated application to Azure. Essentially, this assistant will handle the following tasks:

Upgrade your application to .NET 10
Fix existing issues and apply best practices
Take all dependencies into account
Deploy your application to Azure

Keep in mind, this is a brand-new feature, so if you decide to fully delegate the upgrade and deployment to it, make sure to review the code and test your application thoroughly. This is especially important if you have many dependencies, a complex codebase, or an application that hasn't been touched in years.

How to use the feature?

Easy. You can right-click your solution in Visual Studio and you'll see a new menu item. Check out the screenshot below:

Alternatively, you can open the GitHub Copilot Chat window, type @modernize, and provide instructions on how you want to upgrade your code.

Keep in mind:

There are a few requirements to use this feature:

Your codebase must be written on C#.
You need to have Visual Studio 2026 or Visual Studio 2022 version 17.14.17 or newer.
GitHub copilot and GitHub Copilot app modernization for .NET enabled
Either of these Copilot subscription plans:
- Copilot Pro
- Copilot Pro+
- Copilot Business
- Copilot Enterprise

Summary

.NET 10 represents an important moment in the platform's evolution. This isn't just another incremental update, it's a comprehensive reimagining of what a modern application development framework should deliver. With C# 14's powerful language enhancements, dramatic performance improvements, simplified development workflows, and enterprise-grade LTS support, .NET 10 checks every box that matters.

At the end of the day, .NET gives you the freedom to build just about anything, making this an especially great time to be a .NET developer.

The ecosystem and community is continuously growing, check out the stats:

What We Covered

This article explored the most impactful and interesting features from my perspective.

While this article dives deep into the features I find most compelling, .NET 10 includes many other significant improvements that deserve attention:

Runtime & Performance:

Native AOT compilation enhancements with better size and startup time
Garbage collector improvements for specific workload patterns
JIT compilation optimizations for ARM64 and other architectures

Library Improvements:

LINQ performance optimizations and new methods
System.Text.Json serialization enhancements
Collections improvements and new collection types
Span and Memory improvements for zero-allocation scenarios
Regex source generators and performance improvements
Cryptography API updates

ASP.NET Core:

Blazor improvements (rendering modes, streaming rendering, enhanced navigation)
SignalR performance and reliability improvements
Middleware pipeline optimizations
Output caching enhancements
Rate limiting improvements
HTTP/3 and QUIC support enhancements
Minimal API improvements beyond validation

Data Access:

Entity Framework Core 10 features (complex types, primitive collections, JSON columns enhancements)
Database provider updates
Query performance improvements
Better database migration tooling

.NET MAUI:

Cross-platform UI improvements
Performance optimizations for mobile
New controls and gestures
Better tooling support

Cloud & Containers:

Container image size optimizations
Better Kubernetes integration
Azure-specific optimizations
Improved health checks and metrics

Developer Tools:

SDK improvements
MSBuild performance enhancements
NuGet package management improvements
Testing framework updates
Debugging experience improvements

Covering all of these in detail would require a book (or several). The features I chose to highlight are the ones I believe will have the most immediate impact on day-to-day development work and demonstrate the direction Microsoft is taking the platform.

Migration Recommendations

For New Greenfield Projects:

.NET 10 is the obvious choice: You get LTS stability (3 years of support) combined with all the latest features, performance improvements, and language enhancements. There's no reason to start a new project on an older version.

For Existing .NET 8 Applications:

Plan migration before November 2026: .NET 8 support ends in November 2026, giving you about a year to plan and execute your migration
Low-risk upgrade path: Moving from one LTS to another LTS is the safest migration strategy
Test thoroughly: While .NET typically maintains excellent backward compatibility, always run comprehensive tests, especially if you use advanced features or third-party libraries
Migration strategy: Start with non-critical services or applications to gain confidence, then progressively migrate your core systems
Performance gains: Even without code changes, you'll likely see performance improvements just from the runtime enhancements

For Existing .NET 9 Applications:

Strongly consider upgrading to .NET 10: .NET 9 support ends in November 2026, while .NET 10 extends support until November 2028
Extend support window: Upgrading from .NET 9 to .NET 10 gives you 2 additional years of support
Early adopter advantage: If you adopted .NET 9 early, you're already comfortable with recent changes, making the .NET 10 migration straightforward
Minimal breaking changes: The jump from .NET 9 to .NET 10 is smaller than jumping major versions

For .NET 6 and Older Applications:

.NET 6 support already ended: If you're still on .NET 6 (support ended November 2024), migration is urgent
Multi-version jump considerations: Migrating from .NET 6 or older requires careful planning due to accumulated breaking changes
Use GitHub Copilot App Modernization: This tool can help automate much of the upgrade process and identify potential issues
Incremental migration: You can also consider migrating to .NET 8 first if .NET 10 seems too large a jump, then plan for .NET 10 before .NET 8 support ends, but I wouldn't suggest that, you don't want to do it twice.
Dependencies audit: Check all your NuGet packages and third-party libraries for .NET 10 compatibility

For Enterprise Systems:

This is your LTS release—no need to wait: .NET 10 combines cutting-edge features with the stability and long-term support enterprises require
ROI considerations: Performance improvements alone can justify the migration through reduced infrastructure costs
Risk mitigation: Establish a comprehensive testing strategy including unit tests, integration tests, and performance benchmarks
Training investment: Ensure your team is familiar with new C# 14 features and .NET 10 capabilities to maximize the benefits

General Migration Best Practices:

Audit Dependencies: Check all NuGet packages for .NET 10 compatibility. Most popular packages already support .NET 10
Run Compatibility Analyzer: Use .NET Upgrade Assistant and compatibility analyzers to identify potential issues
Monitor Performance: Establish performance baselines before migration to measure improvements
Review Breaking Changes: Check the official breaking changes documentation for your current version → .NET 10
Plan for C# 14: If your team is using new C# 14 features, ensure everyone understands them through code reviews and documentation
Update CI/CD Pipelines: Update build agents and deployment scripts to use .NET 10 SDK
Container Image Updates: Update base images to .NET 10 runtime images

Final Thoughts

The timing couldn't be better for .NET 10. Organizations currently on .NET 8 LTS have a clear upgrade path to another LTS release with significant improvements. .NET 9 adopters can extend their support window by 2.5 years and gain substantial performance benefits. And teams starting new projects get the best of both worlds: cutting-edge capabilities wrapped in enterprise-grade support commitments.

.NET 10 isn't just about adding features, it's about refining the entire development experience. From simplifying the getting-started experience with file-based apps to providing enterprise-grade observability and performance, every change feels intentional and well-considered.

Microsoft has consistently demonstrated their commitment to making .NET the best platform for building modern applications, whether you're creating cloud-native microservices, AI-powered applications, cross-platform mobile apps, or high-performance backend systems. .NET 10 continues this tradition while pushing the boundaries of what's possible with a managed runtime.

If you've been on the fence about upgrading or adopting .NET, this is your release. The combination of LTS stability, dramatic performance improvements, developer productivity enhancements, and future-forward features like AI integration makes .NET 10 an easy choice for serious application development.

The .NET platform has never been in a better position. With .NET 10, Microsoft isn't just keeping pace with modern development needs, they're setting the standard for what a world-class application framework should deliver. This is the release that proves .NET isn't just relevant in 2025, it's essential.

If you found this article helpful, consider checking out the playground repository to run these examples yourself. Feel free to share your .NET 10 migration experiences or questions in the comments below. Happy coding!

Thank you for reading, and happy holidays!❄️☃️🎄🎉

The Popstar Developer

Giorgi Kobaidze — Wed, 05 Nov 2025 22:59:05 +0000

Previously in the Series
Rockstar Developer 🎸
Popstar Developer 🪩
What Goes Into Understanding a New Technology
Same Applies to LLMs and Their Versions
When Does It Actually Make Sense to Go All In on New Tech?
Be Extra Cautious When Your Decision Might Affect Others
Make Sure You Pick Tech for Long-Term Use
You Don't Have to Pick Sides, Don't Label Yourself
Conclusion

Previously in the Series

Last time, we dove into what it really means to stay old school in this chaotic, AI-powered era and the pros and cons that come with it. Catch up on the full article here:

Giorgi Kobaidze

Nov 1 '25

What Happens If You Stay Old School in the AI Era?

#discuss #ai #machinelearning #career

Comments 4

12 min read

We discovered that being too cool for school and proudly shouting "I'm old-school!" doesn't really do wonders for productivity, it's simply not pragmatic. And we, as software engineers, are supposed to be the most pragmatic people out there.

To stay relevant, we've got to stay open-minded, ready to explore new ideas, frameworks, and languages. That's how we keep up with the rapid pace of innovation and avoid missing out on opportunities that could completely change our careers (and maybe even our lives).

However, there's another extreme: the developers who chase every new shiny thing and just can't seem to focus on one thing for long. This post is about them, the Popstar Developers.

Rockstar Developer

As you might've guessed, the term that I've created "Popstar Developer" was inspired by the famous "Rockstar Developer."

A rockstar developer is basically a software engineer who stands out for exceptional skill, speed, and creativity, basically someone who can tackle tough problems, deliver high-quality code, and often drive major progress within a team. It's like a 10x developer, but with more personality.

Pretty cool, isn't it?

Popstar Developer

YOU KNOW AT LEAST ONE

Ever met a developer who gets way too excited about some shiny new piece of tech that hasn't even been properly released yet, let alone time-tested?

Or someone who's following way too many "industry influencers" (with no technical knowledge) on different platforms and sharing their ideas and takes almost blindly without even asking questions? That's who I call a Popstar Developer.

For the record, “vibe coders” don't fall into this category, because vibe coders simply aren't developers or engineers.
Change my mind!

Another classic example: developers who instantly jump on social media or record a video the moment a new framework drops, claiming it's "10x faster", "10x more efficient", and "the future of everything..." or, sometimes, dramatically declaring the opposite. And I'm always like: "How did you even have time to research or use it in practice so deeply to be so confident about that?”

What Goes Into Understanding a New Technology

A lot actually and no matter how much you test-drive it, real validation only comes with time.

Let's say some new "X" has just been released. This X can be anything, including but not limited to:

A new programming language
A new framework
A new LLM model
A new library

...or even a new version of any of the above.

Before jumping to conclusions (or straight onto the hype train 🚂), try asking yourself a few essential “WH” questions first:

When was it released?
What new features does this X bring?
Who developed it? (Can be a company or an individual)
What about potential security vulnerabilities?
What dependencies does it introduce?
How does it actually perform in real-world metrics?
What problem is it trying to solve in general?
What problem can it solve for me specifically?
What alternatives exist, and how do they compare?
Why is this tool supposedly better than what I'm using now?
How can I simulate a realistic, production-level use case?
Is it backwards-compatible to my current version?

There are plenty more questions you could ask, but this is a solid starting point, enough to separate genuine innovation from temporary hype.

As a professional, your goal is to deliver products that are high-quality, fast, and reliable, not to constantly jump between languages, frameworks, or even versions. In the real world, stability matters.

Same Applies to LLMs and Their Versions

The other day, I had to quickly build a visual component for one of my personal projects. I'm a backend engineer, so whenever I need to create complex markup, I sometimes have to rely on a bit of AI assistance (otherwise, it could take me days, if not weeks).

I won't name the specific LLM I was using, because it's not really about the model itself, it just happened to struggle in this one scenario. There were two different versions available, one newer and supposedly better, at least on paper. I decided to go with the older one.

Then I ran into a tricky styling issue: making a component responsive and mobile-friendly across different screen sizes. Sounds simple, right? Nope. It turned into a complete nightmare, even for the LLM.

I went several rounds with this LLM trying to make it work, but nothing clicked. Then it hit me, there was that other, supposedly better version I could've used. So I switched over and fed it all the context I had.

Sadly, still nothing. The results were no better than before. In the end, I did manage to get a working solution, but only after what felt like an endless back-and-forth with the model.

The point I want to make is simple: a new version or a new product doesn't inherently mean it's better. In fact, its newness can often be the main reason it comes with hidden drawbacks. Whenever I try anything new, I approach it cautiously — checking security, resource usage, correctness, and everything else that could impact my product negatively.

When Does It Actually Make Sense to Go All In on New Tech?

Sometimes, you don't even have a choice, a change is necessary. There are several scenarios where adopting new technology or upgrading a version makes sense:

Your company's tech stack is phasing out the old technology or version.
You need to upgrade because the previous version is no longer supported or is approaching its end-of-support deadline.
You've thoroughly researched the new tech or version and are confident it will improve your application's performance.
The new version enhances the security of your products.
You plan to add features that aren't supported by the old version.

...and plenty of other valid reasons.

Be Extra Cautious When Your Decision Might Affect Others

When you're a one-person team, the impact of a decision mostly affects only you. But if you're a technical manager, architect, principal engineer, engineering manager, or anyone responsible for a team (or multiple teams), you need to be extra thorough when evaluating any new shiny technology you want to introduce.

In enterprises or even mid-sized companies there's usually a process for adopting new tech, don't take it at face value. Review that process carefully, understand how it works, and look for ways to improve it. That way, you can make informed decisions that benefit your team and other teams, while minimizing risk.

Make Sure You Pick Tech for Long-Term Use

We've already covered several important criteria for deciding whether a new technology or version is worth adopting. But here's one more that often gets overlooked, especially by Popstar Engineers.

At some point, things should become boring and routine. Sounds counterintuitive, right? But it's true. Constantly switching frameworks, libraries, versions, or dependencies means you're not focusing on the product itself, or on selecting the right components for your project in the first place.

Even updating a minor version of a library or framework can trigger a cascade of changes in your code. And even if you implement everything correctly, you could still end up with 50+ bugs in production. Fun times, right?

You Don't Have to Pick Sides, Don't Label Yourself

This was also covered in the previous article when we discussed why being entirely old-school can be limiting, and it wouldn't feel right to leave it out here.

For some strange reason, people are obsessed with the idea that they should pick sides in literally everything, which is really strange. It's like they want to label themselves for no reason. I think that's because they want to build a personality they think is cool, one that might be based on someone they know or an imaginary person they're obsessed with becoming. And it's not only in tech. Let me give you a few examples:

Rock music vs. Pop music - you might be a huge rock fan (just like I am) but you can't convince me that you haven't lip-synced and chair danced to a pop song while being alone, nobody watching (I have). It really depends on a particular song, not the genre.
Ford vs. Chevy - while I'm a massive Ford fan (and owner), I appreciate quite a few Chevy cars that are out there. They're fun, cool, and do the job. It really depends on a particular model, not the brand.

Now a few examples from tech:

Backend vs. Frontend - why not both, depending on preferences, what you need currently, what you want to build and tons of other factors?
Microservices vs. Monolith - how about you tell me what you're building first and then we discuss. Though some people consider a monolith as an anti-pattern. Guess what? Microservices can be an anti-pattern in equally many cases (if not more).

See? The same principle applies here. Which brings us to the final and logical conclusion.

Conclusion

You don't become a good software engineer by typing fast, drinking too much coffee, having a flashy editor or terminal theme, driving an electric vehicle, or sharing memes. Those are all just gimmicks.

Similarly, you don't become a "rockstar" or a "10X" engineer by constantly chasing every new shiny thing that comes out, you simply can't keep up with it all, whether it's a new LLM model, a JavaScript framework, or the latest VS Code release notes. What really matters is creating products, living them, diving deep into technical nuances, and finishing them. You can always update your tech stack or dependencies, but can you actually finish the project? That's the real question.

What makes a good software engineer is flexibility and adaptability. Religiously following just one approach will only take you so far. To make meaningful progress in a project, or in your career, you need to be adaptive. Not by switching technologies every other day, but by developing situational awareness: knowing when it's better to stick with the tried-and-true, and when it's the right moment to embrace something new.

What Happens If You Stay Old School in the AI Era?

Giorgi Kobaidze — Sat, 01 Nov 2025 22:53:48 +0000

AI Hype is Wearing Off Slowly But Surely
So Staying Old School Isn't That Bad After All?
- 0 or 1?
- You Don't Have to Pick Sides, Don't Label Yourself
What's so Cool in Old-School Anyway?
- Picking the Right Tool for the Right Job
- Example: Can You Write a Website on C Programming Language?
- Now, Let's Apply That Context to AI
- Don't Be Too Cool for School
- "AI Makes You Dumber, AI Makes Your IQ Lower, AI This... AI That..."
When Does It Make Sense to Go Old-School?
- There's Still No Excuse
Summary and What's Next

AI Hype is Wearing Off Slowly But Surely

AI is here to stay, it's not going anywhere despite videos and articles claiming its bubble will pop. While there's some truth to these concerns, most such titles are clickbait. Sure, people are realizing that AI won't solve all their problems or make them rich without effort, but let's not be too dramatic - AI is going to stay like it is now for the most part. Though, it's encouraging to see both software engineers and non-technical people recognize that "vibe coding" isn't something to trust your business and career on - it's a slippery slope.

Check out my article about vibe coding:

Giorgi Kobaidze

Jun 24 '25

I'm All In on AI, But We Need to Talk About Vibe Coding

#ai #vibecoding #machinelearning #coding

126

Comments 64

16 min read

But hey, let's be honest, if you're experienced enough in this field, you've seen this pattern before - it's the natural cycle of any hyped technology. Everything that gets hot eventually cools down, just like this race car brake rotor does after the race, and AI is no exception.

Here's a visual representation of how hype works for any new hot thing in tech.

We'll talk more about the AI bubble later in this series.

So Staying Old School Isn't That Bad After All?

0 or 1?

Our field is completely built upon the idea of 0 and 1, but pretty much anything built on top of that concept involves one magic phrase - "it depends." The higher the abstraction, the more "it depends" answers we encounter when discussing any topic, and AI is no exception. In fact, AI is the topic with the highest share of "it depends" right now.

However, you're not wasting your time reading my article only to end up with me saying "it depends," right? So let's dive into this topic and find out what exactly it depends on.

You Don't Have to Pick Sides, Don't Label Yourself

Rock music vs. Pop music - you might be a huge rock fan (just like I am) but you can't convince me that you haven't lip-synced and chair danced to a pop song while being alone, nobody watching (I have). It really depends on a particular song, not the genre.
Ford vs. Chevy - while I'm a massive Ford fan (and owner), I appreciate quite a few Chevy cars that are out there. They're fun, cool, and do the job. It really depends on a particular model, not the brand.
Pizza vs. Burger - now that's a tough one for me, I still don't know. Again, it depends on about 150 different factors.

Now a few examples from tech:

Backend vs. Frontend - why not both, depending on preferences, what you need currently, what you want to build and tons of other factors?
Microservices vs. Monolith - how about you tell me what you're building first and then we discuss. Though some people consider a monolith as an anti-pattern. Guess what? Microservices can be an anti-pattern in equally many cases (if not more).
Old school coding vs. modern coding - this one's quite vague and general, so let's discuss it in a more detailed way.

Important: as the title suggests, this article is going to focus only on old-school. In the next article we'll talk about the modern approach. To make the comparison fair, the next article will also have a similar structure.

What's so Cool in Old-School Anyway?

Picking the Right Tool for the Right Job

The main appeal that old-school has is that when a person claims they're old-school, it's a social convention that this person is inherently cool, no matter the context, because they seem like someone who's been around for quite some time and is knowledgeable enough not to care about new trends and technologies... and that's a mindset issue, well at least in software engineering.

I think it goes without saying that as a software engineer, you should always be trying to improve your skills and effectively the products you make. You can't just pick any technology, framework, library, or language and create a product that will be efficient, maintainable, and performant at the same time. One of the best skills you can have as a software engineer is picking the right tool for the right job, and make no mistake, this skill is one of the hardest skills you can obtain, even though it sounds pretty straightforward, it's not.

Example: Can You Write a Website on C Programming Language?

Absolutely. You can... technically.

However

While it's entirely possible to develop a web server or even a complete website backend using the C programming language, it's generally not the most practical approach for modern web development. C provides very low-level control over networking, memory management, and I/O operations, which means a developer can, in theory, implement every layer of the HTTP stack manually, from parsing requests and generating responses to handling sockets and concurrency. However, this level of control comes at a significant cost in terms of development speed, security, and maintainability.

Modern frameworks and languages such as Go, Rust, Node.js, Python (Flask, Django), or .NET abstract away most of the boilerplate network handling and offer robust standard libraries, concurrency models, and built-in HTTP servers. In contrast, writing a web server in C typically involves directly managing sockets via the Berkeley sockets API, implementing the HTTP protocol manually (including headers, content length, and encoding), and ensuring thread safety and memory correctness - tasks that are both error-prone and time-consuming.

C-based web servers can be extremely efficient in performance-critical, embedded, or specialized environments (for instance, using libraries like Mongoose, libmicrohttpd, or CivetWeb), but for general-purpose website development, higher-level languages and frameworks deliver far better productivity and maintainability without sacrificing reliability. And to be honest, you don't lose that much in terms of speed and performance as well.

Now, Let's Apply That Context to AI

As much as we love our job—software engineering—it can be extremely stressful. It's incredibly competitive and doesn't forgive standing still.

Software engineers are pretty much like professional athletes: we need to work to survive and, at the same time, constantly improve our general skills outside work to make sure we're in a good position in a global perspective.

Well, there are a few key differences though: if we tear our ACLs or injure our Achilles, we can still work. However professional athletes, unlike us, don't have to learn completely new things over and over again, they mostly drill what they already know and deepen their skill and understanding in that regard. Us, the software engineers? We have to do both. We need to constantly learn new things, and that includes AI.

As we already mentioned, our industry is extremely competitive, not only at the individual engineer level, but also at the company level too (even more so). That's why companies are so desperate to find as good engineers as possible. Have you checked out the recent news about big tech giants literally poaching AI engineers and researchers from each other? Crazy right? I guarantee you that none of those engineers have ever complained that AI is taking their jobs and it's evil. Instead they used the situation for their benefit and it worked out pretty well for them, hasn't it?

Don't Be Too Cool for School

"So you're tellin' me that tin Lizzie of yours is better than my Quarter Horse? Ha! You've lost your senses, boy." 🤠

I'm 100% (a hundred percent) sure this conversation happened much more than once way back in the beginning of the 1900s when Henry Ford produced a brand new Model T and popularized it. Look at the world now. Now horses are transported using a special trailer towed by Ford F-150s. Fair play, horses!👏

The point I want to make is, don't be that person who's always trying to gain validation from society by parroting popular ideas, that's easy and cheap. Try to think about stuff yourself. Out-of-the-box thinking isn't only thinking of a business or AI startup idea that nobody even cares about, or saying something controversial that you don't even believe.

Out-of-the-box thinking can be subtle, not even comprehensible for other people. As subtle as decluttering your mind from other people's perspectives and thinking about something by yourself. Tech and software engineering isn't about how things work, or how people think things work, it's all about how you make things work your way to create something special or solve a specific issue. While everyone else is just complaining about tech going backwards and AI ruining everything, the best thing you can do is sit down and brainstorm how you can use the whole AI situation to make your career even better.

Do Me a Favor and Once You've Read This Article Do the Following:

Take a notebook and a pen and write down the following questions:

What are the most repetitive tasks that I can delegate to AI?
How can I use AI tools to make my personal repositories cleaner and more efficient?
What are the ways to communicate with AI to make sure my development skills aren't getting rusty?
What skills am I lacking and how can I sharpen them using AI tools?
How to decide when I use an AI-assisting or AI-assisted approach?
Which AI tools should I use?
Should I limit myself on how much I use AI during coding?
In what ways can I validate that I actually understand the code AI generates for me?

You don't have to answer all these questions right away, just write them down and think about them. Let off the LinkedIn influencers and YouTube clickbaiters for some time, because more often than not, they either don't fully understand how the industry really works (which is normal because some of them aren't even technical people) or they're just throwing hot takes or popular takes into the public so they can get hundreds of likes/comments. Make your own path with your own mind.

"AI Makes You Dumber, AI Makes Your IQ Lower, AI This... AI That..."

I see tons of posts, articles, and videos with a title like this. And I'm not a big fan of it. Not that I'm an AI power-user and I'm taking it personally, but because it's nothing but a "wanna be smart and cool" statement that's totally out of context and something that's easy to get many people nodding at you and liking your comment/post.

In reality, it's not AI that'll make you dumber, it's you and how you use AI. It's like saying that automatic gearbox cars cause more accidents because people have more ability and freedom to use phones while driving. It's not the cars, it's the irresponsible and bad drivers who don't have the first idea how to drive a car safely.

Any tool out there is there standing still waiting for your input and does stuff based on it. So if you think that AI is making you dumber and that's why being old school is the way to go, please pause for a moment and think and reflect about what's the actual reason why that happens.

Maybe you're doing something wrong?
Maybe you're delegating way too much to AI?
Maybe you should stop vibe coding?
Maybe before you ask ChatGPT to generate an email for you, you should try it?

There are so many maybes that you should think about before discouraging others from using a tool that can absolutely be used productively.

When Does It Make Sense to Go Old-School?

Even though staying up-to-date is what every developer should focus on, in some specific scenarios, it's better to stay old-school.

When I think about this topic, what comes to my mind is the tweet I came across on Reddit:

A friend learned COBOL and received a codebase 
where the last change was done in the 90s... 
by. his. mum.

There's an extremely good reason why that code was so old and why that person had to maintain code that was maintained by his mum. You might not even have heard of COBOL, especially if you're a gen-z software engineer. It's a programming language that is still used, even though it's over 60 years old. Not only that, plenty of unbelievably critical systems run on COBOL, like: banking systems, insurance systems, government, transportation, you name it.

When you have a working system for several decades, THE VERY LAST THING you ever want is going modern. Just stop for a moment and imagine rewriting these systems written in COBOL in modern alternatives. It's a terrible idea, right? I've actually had a discussion about this topic with a few people and some of them were even advocating that point because "it's a good investment in the long term." But in reality, it's not. It's a good investment when the update isn't that hugely significant AND you gain something out of it. Don't be just a purist who thinks only about modern technologies and the cleanest code possible—think about what you're going to bring to the table for the client. And let me tell you that if anyone touches that COBOL code written and developed for decades by the people who are retired now (at least most of them), you're not going bring nothing but bugs and tons of issues to the table. Doesn't matter how good you are, or how good your team is, you're going to cause a catastrophe.

Imagine messing up the whole financial system in the USA. That will not only affect the country, but the whole rest of the world, because every other country is at least indirectly dependent on the USA's economy. And even if everything goes perfectly and there are no issues, there's still no point in doing this modernization work, because it's going to cost so much, there's literally no value whatsoever, quite the contrary.

Whether you can use AI to maintain your super-legacy code, that's questionable, but if you're a COBOL developer and you're planning on using AI for maintaining your systems, please do a thorough review before you update the code.

This is a perfect example when it's better to stay old-school and don't try to do crazy stuff with the system.

Another example can be Real-Time and Embedded Systems.

Embedded systems are specialized computers built into devices rather than general-purpose machines. Examples include microcontrollers (Arduino, STM32, ESP32), device drivers (GPUs, sensors, storage), aerospace flight control software, and medical devices (pacemakers, insulin pumps, MRI machines). These systems often have hard real-time requirements, meaning they must respond to events within strict timing constraints, missing a timing window can cause system failure or even be life-threatening.

Why Assembly / Embedded C Works:

Maximum control: Direct access to hardware registers, precise memory management, and deterministic instruction execution.

Predictable timing: No garbage collection or dynamic allocation, ensuring interrupts and timers fire exactly on schedule.

Minimal overhead: Small, efficient machine code suitable for devices with limited RAM, flash, or slow CPUs.

Hardware-specific features: Bit-level operations, DMA control, and inline assembly allow precise control impossible in high-level languages.

This is another case where caution is crucial, especially when dealing with older systems dedicated to critical functions. For example:

Flight control software: Airbus, Boeing... these systems cannot risk unexpected pauses.

Medical devices: Pacemakers, infusion pumps—any failure can be life-threatening.

With systems like these, you simply don’t take risks, because the consequences can be far more catastrophic than financial loss.

There's Still No Excuse

We've identified a few examples when it's better to stick to your current tech and not upgrade it, no matter how appealing it might sound. Remember, we software engineers are here to solve problems, not to create them. Some legacy systems are legacy for a good reason—they just work and they're time-tested, quite a lot. In these cases, find something else to test your adaptability skills and learn new languages and frameworks.

Summary and What's Next

Being old school is useful when it comes to critical scenarios like this and it's mainly about technology and infrastructure, but your mindset should never be only old-school, you need to also look forward and try to stay up-to-date. There's still no excuse for being old-school when it comes to your mindset. Stay hungry, stay competitive, stay awesome!

The next chapter will be a complete opposite of this one, we'll talk about the pros and cons of being too obsessed with being up-to-date.

How a Simple Race Condition Bug Can Take Down Even the Biggest Systems

Giorgi Kobaidze — Tue, 28 Oct 2025 19:34:51 +0000

Introduction
What is a Race Condition?
The Scenario: A DNS Management System
The Race Condition: A Perfect Storm
Visualizing the Race Condition
The Core Bug Pattern
Why This Bug is So Insidious
How to Fix It: Proper Cleanup Logic
Advanced Prevention: Fencing Tokens
Lessons for Distributed Systems Engineers
Real-World Applications
The Broader Context: Why This Matters
Practical Checklist for Your Systems
Conclusion: The Humbling Reality of Distributed Systems
Summary

Introduction

Imagine this scenario: Your production system has been running flawlessly for years. You have redundancy, automated recovery, and multiple independent components working in harmony. Then one day, under a perfect storm of conditions, everything crashes. Not because of a hardware failure, not because of malicious actors, but because of a tiny race condition that only manifests when several unlikely events happen simultaneously.

This isn't hypothetical. This exact pattern has caused major outages in global production systems, bringing down critical infrastructure and affecting millions of users. The culprit? A subtle timing bug in automation software that, under specific conditions, deletes resources that are actively being used.

In this article, we'll explore one of the most insidious types of race conditions in distributed systems: the "cleanup catastrophe." We'll break down exactly how it works, why it's so hard to catch, and most importantly, how to prevent it in your own systems.

Whether you're building microservices, distributed databases, or cloud infrastructure, understanding this pattern will help you avoid a category of bugs that can remain dormant for years before striking catastrophically.

What is a Race Condition?

Before diving into the complex scenario, let's establish the basics.

A race condition occurs when the behavior of a system depends on the sequence or timing of uncontrollable events. In software, this typically happens when multiple processes or threads access shared resources without proper coordination.

Simple Example: The Bank Account Problem

# Two threads trying to update the same account
balance = 1000

# Thread 1: Deposit $100
temp1 = balance  # Reads 1000
temp1 = temp1 + 100  # Calculates 1100
balance = temp1  # Writes 1100

# Thread 2: Withdraw $50 (happens at the same time)
temp2 = balance  # Reads 1000 (before Thread 1 writes!)
temp2 = temp2 - 50  # Calculates 950
balance = temp2  # Writes 950

# Final balance: $950
# Expected balance: $1050
# Lost: $100

This is a classic race condition. Both threads read the balance before either writes, so one update gets lost.

But the race condition we're exploring today is more subtle and more dangerous.

The Scenario: A DNS Management System

Let's examine a realistic distributed system that manages DNS records for a high-availability service. This pattern applies to many systems: configuration management, cache invalidation, distributed task scheduling, and more.

System Architecture

Our system has three key components designed for reliability and automation:

1. The Planner

Purpose: Monitors infrastructure health (load balancers, servers, etc.)
Function: Generates configuration "plans" based on current state
Output: Versioned plans (Plan 1, Plan 2, Plan 3, etc.) specifying which IP addresses should be active
Operating Model: Continuously running, generating new plans as infrastructure changes

2. The Enactors (3 instances)

Purpose: Apply configuration plans to the production DNS system
Function: Execute the actual DNS record updates based on plans from the Planner
Redundancy: Three separate instances running independently for fault tolerance
Operating Model: Pick up plans, validate them, apply changes to DNS

3. The Cleanup Process

Purpose: Remove obsolete and "stale" plans to prevent confusion
Function: Identifies plans that are no longer needed and deletes their associated resources
Logic: If a plan's generation time is older than the most recently completed plan, mark it as stale
Assumption: Plans complete quickly, so generation time ≈ completion time

This architecture looks solid. Redundant Enactors provide fault tolerance. Continuous planning adapts to infrastructure changes. Cleanup keeps the system tidy.

But this design has a fatal flaw.

The Race Condition: A Perfect Storm

The race condition occurs when several things go wrong simultaneously, creating a timing window that the system's designers didn't anticipate.

Step 1: The Slowdown (Time T1)

Enactor #1 begins processing Plan A at time T1. Under normal circumstances, this takes a few seconds. But something unusual happens:

Network congestion delays communication with DNS servers
Resource contention on the Enactor instance slows processing
Temporary throttling from the DNS API causes retries
A software bug triggers unexpected retry logic

Whatever the cause, Enactor #1 is stuck processing Plan A far longer than expected.

Timeline:

T1: Enactor #1 starts applying Plan A (generated at T1)
    └─> Expected completion: T1 + 5 seconds
    └─> Actual completion: T1 + 5 minutes (unusually slow!)

Step 2: The World Keeps Turning (Time T2-T3)

While Enactor #1 struggles, the Planner doesn't know about the delay. It continues its job:

At T2: Generates Plan B based on updated infrastructure state
At T3: Generates Plan C with even newer information

The Planner assumes eventual consistency will work everything out. After all, that's what it was designed for.

Timeline:

T1: Enactor #1 starts applying Plan A (still in progress...)
T2: Planner generates Plan B
T3: Planner generates Plan C

Step 3: The Speedster (Time T4-T5)

Enactor #2, operating independently and unaware of Enactor #1's troubles, picks up the newer plans:

At T4: Quickly processes and applies Plan B (completes in 5 seconds)
At T5: Quickly processes and applies Plan C (completes in 5 seconds)

Enactor #2 is doing exactly what it was designed to do—applying the latest configuration as fast as possible.

Timeline:

T1: Enactor #1 starts applying Plan A (still in progress...)
T2: Planner generates Plan B
T3: Planner generates Plan C
T4: Enactor #2 applies Plan B (completes quickly)
T5: Enactor #2 applies Plan C (completes quickly)

Step 4: The Cleanup Catastrophe (Time T5)

Here's where everything falls apart. After completing Plan C, Enactor #2 (or the cleanup process) examines the system state:

# Cleanup logic at time T5
current_time = T5
most_recent_completed_plan = Plan_C  # Generation time: T3
active_plans = [Plan_A, Plan_C]

# The fatal logic
for plan in active_plans:
    if plan.generation_time < most_recent_completed_plan.generation_time:
        # Plan A was generated at T1, which is < T3
        # Conclusion: Plan A is "stale" and "obsolete"
        delete_plan_resources(plan)
        # This deletes ALL IP addresses associated with Plan A

The cleanup logic sees:

Plan A was generated at T1 (old)
Plan C was generated at T3 and completed at T5 (new)
Conclusion: Plan A is stale and should be deleted

The fatal assumption: The cleanup assumes that if a plan is "old" by generation time, it isn't being actively used. But Enactor #1 is still applying Plan A at T5!

Timeline:

T1: Enactor #1 starts applying Plan A (STILL in progress at T5!)
T2: Planner generates Plan B
T3: Planner generates Plan C
T4: Enactor #2 applies Plan B (completes)
T5: Enactor #2 applies Plan C (completes)
    └─> Cleanup runs: "Plan A is old, delete it!"
    └─> Deletes Plan A's resources (IP addresses, DNS records)

Step 5: The Collision (Time T6)

At T6, Enactor #1 finally completes its delayed processing of Plan A. But there's a catastrophic problem:

Plan A's resources (IP addresses, DNS records) were just deleted at T5
Enactor #1 tries to finalize Plan A with non-existent resources
Result: Empty DNS record or corrupted configuration

Timeline:

T1: Enactor #1 starts applying Plan A
T5: Cleanup deletes Plan A's resources
T6: Enactor #1 finishes applying Plan A
    └─> ERROR: Resources don't exist!
    └─> Result: Empty/corrupted DNS state

Step 6: The Inconsistent State

The system now has:

No valid IP addresses in the DNS record (or a corrupted configuration)
Metadata indicating multiple plans in various states of completion
An inconsistent state that prevents automated recovery

The Enactors can't fix this automatically because their logic assumes they can always start from a known good state. But there is no good state—the ground truth has been deleted.

Visualizing the Race Condition

Here's a visual representation of the timing:

Time →  T1      T2      T3      T4      T5      T6
        |       |       |       |       |       |
Plan A: [================================●]     ← Slow (Enactor #1)
                                         ↑      ↑
Plan B:         [====●]                  |      |
                                         |      |
Plan C:                 [====●]          |      |
                                         |      |
Cleanup:                        [Deletes A]     |
                                                |
Collision:                              [Enactor #1 finishes]
                                         [Resources gone!]

Legend:
[===] = Plan being applied
●     = Plan completed
↑     = Critical event

The problem: Cleanup deletes Plan A's resources at T5, while Enactor #1 is still using them, completing at T6.

The Core Bug Pattern

Here's the essential code pattern that causes this race condition:

# BUGGY: The Dangerous Cleanup Logic
def cleanup_old_plans(plans, most_recent_completed):
    for plan in plans:
        if plan.generation_time < most_recent_completed.generation_time:
            # BUG: Doesn't check if plan is currently being applied!
            delete_plan_resources(plan)
            # This can delete resources that are actively in use

Why this is dangerous:

It assumes generation time correlates with application status
It doesn't check if a plan is currently being applied
It doesn't verify when the plan was last accessed
It has no safety buffer or grace period

Why This Bug is So Insidious

This race condition is particularly dangerous because:

1. It Works 99.99% of the Time

Under normal conditions:

Plans complete in seconds
Generation time ≈ Completion time
Cleanup never deletes in-use resources
The system appears perfectly reliable

2. It's Invisible in Testing

To trigger this bug, you need:

Unusual delays in one Enactor (hard to reproduce)
Continued plan generation during the delay (timing-dependent)
Another Enactor completing plans quickly (normal behavior)
Cleanup running at exactly the wrong moment (probabilistic)

Standard tests won't catch this. Even stress tests might miss it.

3. It Fails Catastrophically

When this bug triggers:

It doesn't cause a partial failure
It doesn't throw an obvious error
It creates an inconsistent state that automated systems can't fix
Recovery requires manual intervention

4. It Can Lie Dormant for Years

The system could run for years without triggering this condition, then suddenly fail when the perfect storm of timing occurs.

How to Fix It: Proper Cleanup Logic

Here's how to implement safe cleanup that prevents this race condition:

# SAFE: Proper Cleanup Logic with Multiple Safeguards
def cleanup_old_plans(plans, most_recent_completed):
    for plan in plans:
        # Check 1: Is the plan old by generation time?
        if plan.generation_time >= most_recent_completed.generation_time:
            continue  # Plan is current, skip it

        # Check 2: Is the plan currently being applied?
        if plan.is_currently_being_applied():
            continue  # Plan is in use, don't delete!

        # Check 3: Was the plan accessed recently?
        if (current_time - plan.last_access_time) < SAFETY_BUFFER:
            continue  # Plan was accessed recently, be cautious

        # Check 4: How many other plans reference this one?
        if plan.reference_count > 0:
            continue  # Other plans depend on this, keep it

        # All checks passed, safe to delete
        delete_plan_resources(plan)

Key Improvements:

1. State Tracking

class PlanState(Enum):
    CREATED = 1
    PICKED_UP = 2
    IN_PROGRESS = 3
    COMPLETING = 4
    COMPLETED = 5
    FAILED = 6

def is_currently_being_applied(plan):
    return plan.state in [
        PlanState.PICKED_UP,
        PlanState.IN_PROGRESS,
        PlanState.COMPLETING
    ]

2. Last Access Tracking

# Update access time whenever a plan is touched
def apply_plan(plan):
    plan.last_access_time = current_time()
    plan.state = PlanState.IN_PROGRESS
    # ... apply the plan ...
    plan.last_access_time = current_time()
    plan.state = PlanState.COMPLETED

3. Safety Buffer

# Don't delete anything accessed in the last 10 minutes
SAFETY_BUFFER = timedelta(minutes=10)

# Even if a plan looks old, give it a grace period
if (current_time - plan.last_access_time) < SAFETY_BUFFER:
    # Too recent, keep it for safety
    continue

4. Reference Counting

# Track how many Enactors are using this plan
class Plan:
    def __init__(self):
        self.reference_count = 0
        self.lock = Lock()

    def acquire(self):
        with self.lock:
            self.reference_count += 1

    def release(self):
        with self.lock:
            self.reference_count -= 1

    def can_delete(self):
        return self.reference_count == 0

Advanced Prevention: Fencing Tokens

Another powerful technique is using fencing tokens to prevent stale operations from succeeding:

class ConfigurationStore:
    def __init__(self):
        self.current_version = 0
        self.data = {}
        self.lock = Lock()

    def apply_plan(self, plan, expected_version):
        with self.lock:
            # Atomic check-and-set
            if self.current_version != expected_version:
                raise StaleOperationError(
                    f"Plan based on version {expected_version}, "
                    f"but current version is {self.current_version}"
                )

            # Apply the changes
            self.data.update(plan.changes)
            self.current_version += 1

            return self.current_version

# Usage
def enactor_apply_plan(plan):
    try:
        new_version = config_store.apply_plan(
            plan,
            expected_version=plan.base_version
        )
        print(f"Successfully applied plan, now at version {new_version}")
    except StaleOperationError as e:
        print(f"Plan is stale: {e}")
        # Don't apply this plan, it's based on old state

This ensures that even if a slow Enactor completes, it can't apply a stale plan because the version check will fail.

Lessons for Distributed Systems Engineers

This race condition offers several critical lessons:

1. Question Your Timing Assumptions

❌ Bad: "This operation usually takes 100ms, so timeout after 1 second"
✅ Good: "This operation usually takes 100ms, but timeout after 30 seconds and monitor p99"

❌ Bad: "If generation time is old, the plan is obsolete"
✅ Good: "If generation time is old AND it's not in use AND no one accessed it recently, it might be obsolete"

Key principle: Design for the exception, not the rule.

2. Implement Comprehensive State Tracking

Don't just track "started" and "completed." Track:

CREATED: Plan exists but not yet picked up
PICKED_UP: Enactor has claimed this plan
IN_PROGRESS: Plan is actively being applied
COMPLETING: Plan is in final stages
COMPLETED: Plan finished successfully
FAILED: Plan failed and is safe to clean up

This granular tracking makes it impossible to accidentally delete in-use resources.

3. Add Circuit Breakers to Cleanup Operations

Before deleting critical resources, verify:

Is this resource currently locked by another process?
When was this resource last accessed?
How many other resources will this deletion affect?
Is there a way to soft-delete first and hard-delete later?

Example:

def safe_delete(resource):
    # Soft delete: mark as deleted but keep data
    resource.marked_for_deletion = True
    resource.deletion_time = current_time()

    # Schedule hard delete for later (24 hours)
    schedule_task(
        hard_delete_resource,
        resource.id,
        delay=timedelta(hours=24)
    )

def hard_delete_resource(resource_id):
    resource = get_resource(resource_id)

    # Final safety check before permanent deletion
    if resource.last_access_time > resource.deletion_time:
        # Someone accessed it after marking for deletion!
        resource.marked_for_deletion = False
        return

    # Safe to permanently delete
    permanently_delete(resource)

4. Use Optimistic Concurrency Control

Implement version numbers that prevent stale operations:

class Resource:
    def __init__(self):
        self.version = 0
        self.data = {}

    def update(self, new_data, expected_version):
        if self.version != expected_version:
            raise ConcurrencyError(
                f"Expected version {expected_version}, "
                f"but current version is {self.version}"
            )

        self.data = new_data
        self.version += 1
        return self.version

5. Design for Observable Inconsistency

Make it easy to detect when the system is in an inconsistent state:

def verify_system_consistency():
    """Health check that verifies consistency"""
    issues = []

    # Check 1: Any plans in COMPLETING state for > 5 minutes?
    stuck_plans = [
        p for p in get_all_plans()
        if p.state == PlanState.COMPLETING
        and (current_time() - p.state_change_time) > timedelta(minutes=5)
    ]
    if stuck_plans:
        issues.append(f"Plans stuck in COMPLETING: {stuck_plans}")

    # Check 2: Do DNS records match the latest completed plan?
    latest_plan = get_latest_completed_plan()
    actual_dns = get_current_dns_state()
    if actual_dns != latest_plan.expected_dns:
        issues.append(f"DNS mismatch: expected {latest_plan.expected_dns}, got {actual_dns}")

    # Check 3: Any plans marked for deletion that are still being referenced?
    for plan in get_plans_marked_for_deletion():
        if plan.reference_count > 0:
            issues.append(f"Plan {plan.id} marked for deletion but still referenced")

    return issues

6. Test Timing Edge Cases

Your test suite should include:

def test_delayed_enactor_race_condition():
    """Reproduce the race condition with artificial delays"""

    # Create initial plan
    plan_a = planner.generate_plan()

    # Enactor 1 starts applying Plan A, but we'll delay it
    enactor_1 = SlowEnactor(delay=timedelta(minutes=5))
    enactor_1.apply_async(plan_a)

    # While Enactor 1 is delayed, generate newer plans
    time.sleep(1)
    plan_b = planner.generate_plan()
    plan_c = planner.generate_plan()

    # Enactor 2 applies newer plans quickly
    enactor_2 = FastEnactor()
    enactor_2.apply(plan_b)
    enactor_2.apply(plan_c)

    # Run cleanup (this should NOT delete Plan A's resources!)
    cleanup.run()

    # Wait for Enactor 1 to finish
    enactor_1.wait()

    # Verify: System should still be in consistent state
    assert verify_system_consistency() == []
    assert get_current_dns_state() is not None

7. Implement Gradual Rollouts for Automation

Even if automation has been running for years, treat changes carefully:

class CleanupAutomation:
    def __init__(self):
        self.enabled_percentage = 0  # Start disabled

    def run_cleanup(self):
        if random.random() > self.enabled_percentage:
            # Not enabled for this execution
            return

        # Cleanup logic here
        self.cleanup_old_plans()

    def gradual_rollout(self):
        """Gradually enable cleanup automation"""
        self.enabled_percentage = 0.01  # 1%
        time.sleep(hours=24)  # Monitor for 24 hours

        self.enabled_percentage = 0.10  # 10%
        time.sleep(hours=24)

        self.enabled_percentage = 0.50  # 50%
        time.sleep(hours=24)

        self.enabled_percentage = 1.0  # 100%

8. Build Manual Overrides

No matter how reliable your automation is, have manual controls:

class EmergencyControls:
    """Emergency manual overrides for production issues"""

    @classmethod
    def stop_all_automation(cls):
        """Immediately stop all automated processes"""
        CleanupAutomation.enabled = False
        PlannerAutomation.enabled = False
        EnactorAutomation.enabled = False

        log.critical("ALL AUTOMATION DISABLED via emergency control")

    @classmethod
    def manual_restore_dns(cls, plan_id):
        """Manually restore DNS state from a specific plan"""
        plan = get_plan_by_id(plan_id)

        # Bypass all automation and directly set DNS
        dns_service.set_records(plan.dns_records)

        log.critical(f"DNS manually restored from plan {plan_id}")

    @classmethod
    def force_cleanup_plan(cls, plan_id):
        """Manually force deletion of a specific plan"""
        plan = get_plan_by_id(plan_id)

        # Override all safety checks
        delete_plan_resources(plan, force=True)

        log.critical(f"Plan {plan_id} force-deleted via manual override")

Real-World Applications

This race condition pattern applies to many distributed systems:

1. Distributed Cache Invalidation

# Similar bug in cache invalidation
def invalidate_cache(key, generation_time):
    if cache.get_generation_time(key) < generation_time:
        # BUG: What if another process is currently updating this key?
        cache.delete(key)

2. Distributed Task Scheduling

# Similar bug in task cleanup
def cleanup_old_tasks(tasks):
    for task in tasks:
        if task.created_at < cutoff_time:
            # BUG: What if this task is currently executing?
            delete_task(task)

3. Configuration Management

# Similar bug in config rollback
def rollback_to_previous_version(current_version):
    if current_version.timestamp < latest_version.timestamp:
        # BUG: What if current_version is being applied right now?
        delete_version_resources(current_version)

4. Service Mesh/Load Balancer Updates

# Similar bug in endpoint updates
def update_endpoints(new_endpoints):
    old_endpoints = get_current_endpoints()
    if old_endpoints.version < new_endpoints.version:
        # BUG: What if requests are currently routing to old_endpoints?
        remove_endpoints(old_endpoints)

The Broader Context: Why This Matters

This race condition is more than just a specific bug. It's a window into fundamental challenges of distributed systems:

1. Complexity Breeds Fragility

The system was designed to be reliable through redundancy (3 Enactors) and automation (continuous planning). But the interaction between these components created new failure modes that weren't anticipated.

Key Insight: Adding redundancy doesn't always add reliability. Sometimes it adds new ways to fail.

2. Automation Moves Faster Than Humans

The race condition can happen in seconds. By the time humans can react, the system is in an unrecoverable state. Automation is powerful, but it needs safeguards against moving too fast.

Key Insight: Fast automation needs slow safeguards.

3. The Assumption Trap

The cleanup logic can work perfectly for years. It's only when unusual delays occur that the assumption about timing breaks down. Many systems have similar hidden assumptions.

Key Insight: Document your assumptions and test what happens when they're violated.

4. Timing is Everything

In distributed systems, you can't rely on operations completing in a predictable order or time frame. Networks have delays, processes get scheduled unpredictably, and timing assumptions break down.

Key Insight: Never assume operation A will complete before operation B starts, even if A started first.

Practical Checklist for Your Systems

Use this checklist to audit your own distributed systems for similar race conditions:

Cleanup Logic Audit

[ ] Does cleanup check if resources are currently in use?
[ ] Does cleanup use timestamps to determine staleness?
[ ] Is there a safety buffer before deletion?
[ ] Can you soft-delete before hard-deleting?
[ ] Is there a manual override to stop cleanup?

State Tracking Audit

[ ] Do you track in-flight operations separately from completed ones?
[ ] Can you query "is resource X currently being used?"
[ ] Do you log state transitions with correlation IDs?
[ ] Can you reconstruct the timeline of operations?

Concurrency Control Audit

[ ] Do you use version numbers or fencing tokens?
[ ] Can stale operations succeed?
[ ] Is there a way to detect when operations overlap?
[ ] Do you have locks or mutexes for critical sections?

Testing Audit

[ ] Do you test with artificial delays?
[ ] Do you test operations completing out of order?
[ ] Do you test what happens when automation runs during manual operations?
[ ] Do you have chaos engineering tests?

Observability Audit

[ ] Can you detect inconsistent state?
[ ] Do you alert on unexpected state transitions?
[ ] Can you trace a single operation through the entire system?
[ ] Do you monitor p95/p99 latencies for timing issues?

Conclusion: The Humbling Reality of Distributed Systems

Race conditions like this one remind us that distributed systems are inherently complex. Even with redundancy, automation, and careful design, subtle timing bugs can create catastrophic failures.

But this isn't a story about inevitable failure. It's a story about learning from failure modes and designing systems that are resilient to timing edge cases.

The key takeaways:

Never assume operation timing: What usually takes 100ms might occasionally take 10 minutes
Track in-flight operations: Don't just know what's complete; know what's in progress
Add safety buffers to cleanup: Aggressive cleanup is dangerous
Use optimistic concurrency control: Version numbers prevent stale operations
Test timing edge cases: The bugs you don't test for will find you in production
Design for observability: Make inconsistent states detectable
Build manual overrides: Automation needs kill switches
Document your assumptions: Today's safe assumption is tomorrow's critical bug

In distributed systems, race conditions are inevitable. But understanding them is what separates systems that fail mysteriously from systems that fail safely and recover gracefully.

Every system has timing assumptions. The question is: Do you know what yours are?

Summary

This article was written to help developers understand a subtle but devastating category of race conditions in distributed systems. The pattern described here has caused real production outages, affecting millions of users.

If you found this useful, consider sharing it with your team. Review your own systems with the checklist provided. Test timing edge cases that you've been assuming "will never happen."

Because in distributed systems, the timing edge case you don't test for is the one that will take down your production system at 3 AM on a holiday weekend.

Let's build more reliable systems together.

Forem: Giorgi Kobaidze

The Final 1% of Every GitHub Project: Sealing It Properly

Table of Contents

Introduction

What Does It Mean to "Seal" a Project?

The Release Checklist

README

The "About" Section

Branch Hygiene

Release Tags

Branch and Tag Rulesets

New Release and Release Notes

Move All Tasks to Done

Choose a License for Your Project

CI/CD Status & Pipeline Health

Versioned Builds & Artifacts

Optional: Write an Article or Record a Demo Video

Here's the Full Checklist to Copy and Use

Finish as Strong as You Start

365 Days of Building in Public, Perfectly Reflected By My Badges

Table of Contents

Introduction

365

Your DEV Badges Are Trying to Tell Your Story. Listen to Them

One Year Club

"Hey Mom, Your Son Is a Software Engineer"

And That's When I Discovered DEV Community

Two & Three Year Club

Fast forward to 2020

Boom: The Pandemic Hits. And It Hits Real Bad

I Had to Carve Time Out of Thin Air

If You're Expecting a Happy Ending, You Won't Find It Here

Four, Five, Six & Seven Year Club

I Refuse to Catch a Break, Ever

Then I Finally Started to Feel Comfortable... I Absolutely Hated It

Writing Debut

Community Wellness Streak

1. Always write a high-quality comment

2. Be a decent human being

3. Include as many details as possible

4. If you disagree, explain your point of view clearly

5. Don't be a hater. It will just eat you from the inside

6. Never rush to press the "submit" button

Top 7

I'm All In on AI, But We Need to Talk About Vibe Coding

I'm All In on AI, But We Need to Talk About Vibe Coding

20 Rules for Becoming THAT Manager (From a Principal Engineer's Perspective)

20 Rules for Becoming THAT Manager (From a Principal Engineer’s Perspective)

Can AI Generate Binary Directly? Is It Feasible? Does It Make Sense?

Can AI Generate Binary Directly? Is It Feasible? Does It Make Sense?

C#

Eight Year Club

GitHub Copilot CLI Challenge Winner

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

DEV Weekend Challenge Completion

Sunday DEV Drive: A Synthwave Driving Experience Through Your DEV Community Articles

Still Not Convinced?!

Time to Play the Game

The Game

NoteRunway: Because Your Notion Workspace Deserves an Elite Crew

Table of Contents

What I Built

Explanatory Video

Introduction

The Backstory

The 7 Tools

📊 Workspace Health Dashboard

🔍 Duplicate Detection

🗑️ Garbage Collector

🔗 Dead Link Detector

🔐 Sensitive Data Finder

🕸️ Dependency Graph

💬 Semantic Ask (Agentic Chat)

Show us the code

georgekobaidze / noterunway

NoteRunway

AI-Powered Notion Workspace Management

Table of Contents

Overview

Core Principles

`C#`