DEV Community: Giorgi Kobaidze

A New Personal Best: What Six Months of Locking In Can Do

Giorgi Kobaidze — Sat, 04 Jul 2026 16:44:58 +0000

Setting a New Benchmark for Myself
My Most Productive Six Months Yet
2 Hackathon Wins
- GitHub Copilot CLI Challenge Win: Metal Birds Watch
- Notion MCP Challenge Win: NoteRunway
Raised Money for Charity
Became an Engineering Manager
Collected More Than 25 Stars on My GitHub Repositories
Beat My Own Record in Terms of Likes per Article
One Article Made It Into the Top 7 of the Week
Got Accepted into the Virtual Coffee Community
Joined Devengers
To Sum It All Up
Zero Luck, All Hard Work
Share Your Wins and Achievements, and Set a New Benchmark Starting Now

Setting a New Benchmark for Myself

This short piece serves as a quick reminder of what my current benchmark looks like in terms of how much I should aim to do and achieve within a six-month period for it to feel successful.

Six months is a solid amount of time, you can accomplish a lot in that window. I'm not someone who tends to look back too often, but every now and then, it's important to check in with yourself to make sure you're still moving forward and not slipping backward. And slipping backward is never a good sign.

Some people might argue that just because you've been successful during a certain period, it doesn't necessarily mean you'll keep improving from there.

And that is true, there's no doubt about that. Sometimes things just go south, and we fail to achieve even half of what we set out to accomplish.

But that's the whole point!

Success doesn't teach us much, failure does. Failure is where the most important lessons come from. So set your standards high. If you fail, don't worry about it. Every failure is a lesson, and the more you fail, the more opportunities you have to learn and grow.

My Most Productive Six Months Yet

At the beginning of the year, I made a pact with myself that the first half of this year would be the most successful period of my life. Plans often don't work out, but this one worked like a charm.

Don't get me wrong though, I'm still not fully happy with myself, I feel like I could've done even better but still, it's good enough for now.

Here are the most important things that happened during that time:

2 Hackathon Wins

If I set out to do something, I want to succeed every way possible, whether it's industry work, writing code, writing articles, managing people, or presenting my work. I had already done all of that, but I had never participated in a hackathon.

As a long-time member of the DEV Community, I was well aware of the dev challenges and hackathons that occasionally pop up, especially after the merge with MLH. That felt like the perfect opportunity to finally go after that goal.

And boy did it turn out even better than I expected.

GitHub Copilot CLI Challenge Win: Metal Birds Watch

This was my first-ever hackathon. Over 400 people took part, as it was a large event with great prizes for the winners, one of them being a ticket to the GitHub Universe conference, which is happening later this year in beautiful San Francisco.

As an aviation enthusiast, I poured my heart into this project. I could barely work on it, as my neck, shoulder, and arm were in constant pain, I was in complete agony. A few days earlier, I had spent a long time clearing snow from my driveway, which took a serious toll on my body. I was in terrible pain.

Here's me (the fool) trying to clear up the driveway:

But I pushed through it and finished the project anyway.

GitHub Copilot CLI Challenge Submission

Giorgi Kobaidze

Feb 13

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

#devchallenge #githubchallenge #cli #githubcopilot

11 min read

When I saw that I had taken first place, I literally shouted out of excitement. That project will always be special to me.

By the way, these are my initial sketches and outlines of the project. A lot of math was involved, and I'm glad I'm good at it. Sorry for my ugly handwriting, as I mentioned, my arm was killing me.

Notion MCP Challenge Win: NoteRunway

This one was special too. I built a large, complex, AI-powered tool that helps manage your Notion workspace. I've been a Notion user for six years now, and I wanted to give something back to this incredible team. It turned out far better than I expected.

Notion MCP Challenge Submission 🧠

Giorgi Kobaidze

Mar 29

NoteRunway: Because Your Notion Workspace Deserves an Elite Crew

#devchallenge #notionchallenge #mcp #ai

7 min read

And do you know the best part?

Because of that project, I got to meet Ivan Zhao himself, the founder of Notion. We talked about my project and many other interesting topics. How awesome is that?! Life is full of surprises, let me tell you that!

Raised Money for Charity

This was also a huge win. I regularly donate to charity, but this one was by far the largest contribution I've made. It came as a result of winning the GitHub Copilot CLI challenge (my first hackathon).

The prize included a Copilot Pro Plus subscription, which I already had. GitHub gave me a few alternative options instead, and I chose to donate it to charity, an easy decision.

Now the best part:

GitHub matched my contribution, bringing the total donation to a significant amount.

Once again, a huge thank you to GitHub for making that possible, you're awesome!

Became an Engineering Manager

As I mentioned above, if I set out to do something, I want to be the best at every part of it. I've been writing code for more than 10 years now, and I felt it was time to explore other dimensions of engineering. This role made the most sense to me, as I'm still closely involved in engineering, but now I also take on more responsibility and get to see things from a different perspective.

So far, I'm absolutely loving it!

Collected More Than 25 Stars on My GitHub Repositories

A number of people became interested in my work and started starring my repositories, which is always great to see.

Beat My Own Record in Terms of Likes per Article

One of my articles received significant engagement and became the most liked piece I've written so far. Many people also reached out to tell me they used it to train their LLMs or to build new skills around it.

Check out the article below:

Ready-to-use markdown template

Giorgi Kobaidze

Apr 26

15 Essential Sections Every README Needs: Give Your Project What It Deserves

#documentation #opensource #tutorial #development

162

11 min read

One Article Made It Into the Top 7 of the Week

If you're not a technical writer on DEV.to, it's hard to appreciate how difficult it is to get an article into the weekly top 7, it really needs to stand out. This article made it there, which I was extremely happy about.

Check it out below:

Giorgi Kobaidze

Mar 8

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

#discuss #ai #compilers #programming

11 min read

Got Accepted into the Virtual Coffee Community and the Devengers Team

I've always wanted to be part of this community. I knew the people there were great and supportive. I got accepted, and I'm incredibly happy about it. It's always important to have good people around you.

You really are who you surround yourself with.

Joined Devengers

Thanks to @francistrdev I joined the Devengers team. It makes me think I've done something special on this platform, which feels awesome!

To Sum It All Up

Won the GitHub Copilot CLI Challenge
Won the Notion MCP Challenge
Raised a significant amount of money for charity with GitHub
Won a ticket to the GitHub Universe conference
Met Ivan Zhao, the founder of Notion
Became an Engineering Manager
Built 4 new personal projects
Collected 25+ GitHub stars
Published 13 new articles
Wrote my all-time most loved article
Reached the Top 7 of the week with an article
Joined 2 new communities: Virtual Coffee and the Devengers team here on DEV Community.

Zero Luck, All Hard Work

I've seen a lot of people talk about the importance of luck, which I agree plays a role to some extent. But it often creates a mindset where people start relying on luck more than they should, and that's a big mistake, I hate that.

These things I just mentioned didn't happen because of luck. They came from pushing myself to the limit, at times even through severe physical pain (no exaggeration), and sacrificing a lot of my personal life along the way. My evenings, nights, and weekends were dedicated to all of this.

It's not a lot of time in the grand scheme of things, but I'd rather use that limited time than not do it at all.

Of course, this isn't for everyone, or maybe even for most people. I've even been called a few "funny" names because of it: weird, psycho, freak, nerd. But who gives a "fork"? I certainly don't.

Share Your Wins and Achievements, and Set a New Benchmark Starting Now

Now I'd love to hear about your new baseline and your new standards, share them, and let's talk about them.

Let's keep grinding!

If you want to follow my work or connect, you can find me here:

LinkedIn
GitHub
Twitter/X
YouTube

Southwest Airlines Embraces Cloud and AI Architecture. Are They Setting a New Standard for the Industry?

Giorgi Kobaidze — Thu, 25 Jun 2026 18:46:33 +0000

Overview
Southwest and AWS
From On-Prem to Cloud
AI Comes Into Play
Kiro
Why This Matters?
Closing Thoughts

Overview

Southwest Airlines is one of the largest carriers in the world. Other than having by far my absolute favorite airplane livery, it's a massive enterprise based in Dallas, Texas, with more than 72,000 employees, over 4,000 daily flights during peak travel periods, roughly 134 million customers annually, and service across 120+ airports in 12 countries.

At this scale, what really matters is operational reliability and speed. Because in aviation, slow operations cause delays, delays cause unhappy customers, and unhappy customers aren't particularly great for the company's revenue. A few minutes of latency in one system can turn into hours of disruption in the real world.

So... can cloud and AI solve it? Absolutely, if done right.

Southwest and AWS

Southwest has selected Amazon Web Services (AWS) as its primary cloud partner to help modernize its technology stack and transform how the airline runs, develops systems, and serves its customers. Through this collaboration, Southwest plans to move away from a predominantly on-premises infrastructure toward a cloud-based, AI and agent-enabled architecture on AWS by 2028.

2028 is not far away from now (Jun 25, 2026). This is very ambitious considering the amount of work that needs to be done.

From On-Prem to Cloud

Moving an enterprise of this size from on-prem infrastructure to the cloud is way more complex than it sounds. It doesn't sound easy either. It's one of the hardest things you can ever do as a software engineer, DevOps engineer, architect, engineering manager, or anyone else involved in it.

It involves a lot of steps, including but definitely not limited to:

Assessing existing systems, dependencies, and infrastructure to understand what needs to move and how
Defining a migration strategy (lift-and-shift, replatforming, or full refactoring to cloud-native architecture)
Designing and building the target AWS architecture, including networking, compute, storage, security foundations, etc.
Migrating applications and data while maintaining reliability, consistency, and minimal downtime
Implementing observability, security, and compliance controls in a cloud-native environment
Setting up automation for infrastructure provisioning and deployment using CI/CD and Infrastructure as Code
Transitioning teams to cloud-native development and operations practices while gradually decommissioning legacy systems

And around 10 billion other steps/decisions that you want to make before wrapping things up.

And unlike greenfield systems, airlines don't get the luxury of downtime. Everything has to work while it's being rebuilt. That alone makes airline modernization one of the hardest engineering problems in enterprise software.

AI Comes Into Play

AI changes the equation, but not in the simplistic sense of "developers write code faster now." In large enterprises, the real bottleneck is not code generation, it's context. Decades-old systems accumulate implicit knowledge: business rules, edge cases, operational constraints, and undocumented dependencies. Understanding what should change, what must not change, and how everything connects is the hardest part of modernization.

So the real question becomes:

Can AI understand a system well enough to safely change it? That shift, from code generation to system comprehension, is where things start to get interesting.

Also, there are so many important considerations when planning AI agent workflows and their integration into a system, particularly to minimize unintended side effects and maintain efficiency.

Kiro

Southwest is using Kiro, AWS's agentic development platform, as part of its broader modernization effort, particularly for customer-facing systems and legacy platform refactoring. The goal is not simply to rewrite code, but to systematically evolve large, complex systems into something more maintainable, scalable, and cloud-native, without breaking what already works.

What makes this approach notable is its underlying philosophy.

Kiro is built around SDD: Specification-Driven Development, where you begin by defining what the system should do in a structured, explicit specification before any implementation begins.

That specification then becomes the foundation for:

Implementation
Code generation or refactoring
Validation and alignment across teams

I'll go deeper into specification-driven development in a separate article, but for now, what I can say is that this is by far my favorite approach to AI workflows. It's significantly more reliable than vibe coding, AI agent looping, or other experimental patterns we see today.

This is especially true for large enterprises with extensive legacy codebases that need refactoring. At a certain scale, systems become so domain-specific and historically layered that even advanced LLMs struggle to reason about them without proper context.

In those cases, the bottleneck is no longer code generation, it's understanding. Without clear specifications, documentation, and well-defined behavior, even the best models start to make unsafe assumptions.

Specification-driven development directly addresses this by forcing clarity upfront. You begin with explicit specs that define behavior, constraints, and expectations before any implementation starts. It forces engineers to understand the system more deeply instead of blindly delegating reasoning to AI. And that's critical, because in complex, mission-critical software, trusting AI without structure is not a strategy, it's a risk. Of course, it's still not 100% deterministic (which it shouldn't be), but it's absolutely much more deterministic than just vibe coding.

In my view, this is one of the most promising approaches for AI-assisted software engineering at enterprise scale. Compared to looser workflows like vibe coding or agent loops, spec-driven development introduces structure and context where it matters most. And that matters especially in environments like airlines, where correctness, safety, and predictability are non-negotiable.

Way to go Southwest, well done!

Why This Matters?

Southwest's move is not just a cloud migration story. It's a signal of something larger: how enterprise software development itself may evolve in the AI era. If successful, this approach could reshape how airlines design, build, and maintain their systems. Southwest could become one of the pioneers in this shift, modernizing not just its infrastructure, but also decades of legacy software along the way to make its systems more efficient, maintainable, and adaptable.

Closing Thoughts

What makes this partnership interesting is not just what Southwest is doing, but what it might trigger across the industry. Airlines are traditionally cautious adopters of new infrastructure paradigms. These are systems where "if it works, don't touch it" is often the dominant philosophy, because failures are measured in delayed flights, stranded passengers, and operational chaos. So when a major carrier moves this fast toward cloud-native, AI-assisted, spec-driven modernization, it raises a natural question: will others follow?

The direction is clearly positive: better tooling, more automation, and systems that are finally closer to how engineers and businesses actually think.

AI Psychosis Is No Longer Fiction

Giorgi Kobaidze — Sun, 21 Jun 2026 17:46:14 +0000

Overview
- Cyberpunk 2026
- Resistance Turns Into Reliance
The Recent AI Drama
What to Expect in the Rest of the Article and Why You Should Read It
- Clear Perspective Takes Time
- I'm Not Big on the AI Hype Train
These Vulnerabilities Aren't New
National Security Comes First
Project Glasswing
- Mythos Is Exposing Every Major System and Software
- But It's Not Only About Systems
Anthropic's Ways of Promoting These Models Are Super Weird
The Bottom Line
Summary

Overview

Cyberpunk 2026

If you're into video games, especially those with deep, well-written stories, you've probably heard of Cyberpunk 2077. I played it last year, and I became completely hooked. Not just because of its stunning visuals or its complex mechanics, but because of the story.

What amazed me most is how believable its world feels. Sure, it's fiction and it's set in the future, but in a strange way, it's also realistic, or rather future-realistic (I guess I just invented a new term). The trends we're seeing today in technology and the cyber world seem to be pushing us in the same direction as the world depicted in the game. And that's what makes its story so fascinating: it doesn't feel like pure fantasy. It feels like a glimpse of where we're headed.

And it's quite terrifying, not gonna lie.

There's a term in the game called Cyberpsychosis, a fictional dissociative mental disorder in the Cyberpunk universe. It occurs when an individual replaces too much of their organic body with cybernetic implants, gradually losing their humanity and the natural behaviors that define a human being. As their dependence on technology grows, empathy, emotional stability, and their connection to reality begin to deteriorate, often leading to unpredictable behavior.

It's a fictional concept, of course, but it's also a fascinating metaphor for what can happen when technology starts to blur the line between human and machine.

Even though Cyberpsychosis is an extreme, fictional scenario, the underlying idea doesn't have to be physical. Cognitive and psychological dependence on technology and AI can be just as significant, and in many ways, we're already there.

AI has become an extension (and in some ways a replacement) of how people think, work, and make decisions. It's integrated so deeply into daily life that, for many, imagining life without it already feels unrealistic. And what makes this shift even more striking is how fast it happened, almost in a blink of an eye.

The evolution of our minds and brains is much slower than the rate at which AI and technology are growing and developing. This creates a growing mismatch between human cognition and the environment we now live in, a kind of incompatibility that can potentially backfire over time.

And in some ways, we're already beginning to see the effects of that gap in how we think, behave, and interact with information.

Resistance Turns Into Reliance

People are strange about AI. They criticize it at every opportunity, yet many of them already rely on it daily. Whether they realize it or not, it has become embedded in how we write, search, create, and even think.

If you look at social media, it's already clear how much content is AI-influenced or AI-assisted. But what many people miss is that AI isn't just another tool for reducing effort, it's a huge equalizer that changes what effort even means. If you simply use it to do the same things you were doing before, only faster, you're not really gaining anything. In fact, you risk falling behind. The real shift happens when you use it to expand what you're capable of producing with the same amount of energy.

That's also why the fear of replacement feels so contradictory. People worry about AI taking their place, while at the same time actively using it in ways that make it easier for it to do so. In many cases, it's less about being replaced and more about gradually outsourcing parts of the work without redefining what their role should be.

There's a parallel here with Cyberpunk 2077. Just like cybernetic enhancements in the game, AI offers immediate advantage. And just like in that world, people are often quick to adopt anything that gives them an edge, even when they're uneasy about the long-term consequences.

People may express hostility toward AI in principle, but in practice, they're integrating it more deeply every day. And when access to it is suddenly removed or limited, everyone loses their mind.

This tension is what I refer to as AI psychosis, not as a clinical condition, but as a cultural and psychological dependency pattern that's already starting to emerge.

Let's talk about it in detail.

The Recent AI Drama

On June 12, 2026, Anthropic released a statement regarding a U.S. government directive to suspend access to Fable 5 and Mythos 5.

If you skip the formal wording, the core of it is this: the U.S. government issued an export control directive requiring the suspension of access to both models for all foreign nationals.

And the most striking part is this: even foreign national Anthropic employees wouldn't be allowed to use them.

Everyone was excited about these models. There were posts, articles, and videos everywhere. In the AI space, it felt like the equivalent of a GTA 6 release, hype at a global scale, with everyone watching closely.

And then, almost overnight, it was gone.

Every workflow that depended on those models was brought to a complete stop, unless companies or individuals had prepared a backup plan (which they should when working with models that just came out of the oven). Entire systems that had quietly integrated them suddenly found themselves disrupted, forced to adapt immediately or halt operations entirely.

So, where exactly did it all go south?

What to Expect in the Rest of the Article and Why You Should Read It

Clear Perspective Takes Time

Now, everyone seems to have lost their minds over the ban. There are even more articles, posts, and videos circulating about it than before.

In this article, I want to share my perspective and analyze the situation as a whole. I waited a week before writing it because I wanted everything to settle and the noise to fade a bit. When something has just happened, perceptions are often distorted and details can feel different in the moment. With time, the perspective usually shifts and that's exactly what I wanted before forming my thoughts.

I'm Not Big on the AI Hype Train

I'm going to objectively analyze the situation from multiple angles, including my own perspective. I believe I'm in a fairly neutral position to do that, since I'm not heavily invested in the Fable and Mythos ecosystem yet. I don't rely on AI models too deeply, I use them more as assistants than dependencies.

Right now, I'm using Claude Sonnet (not even Opus), and it gets the job done perfectly well. Because of that, I don't fully relate to the reactions from AI influencers who go insane every time a new model drops. Of course, Fable 5 is reportedly a major improvement over Sonnet and Opus, and it's not even close, but as much as I enjoy using AI for coding, I don't need it to always be at the absolute cutting edge.

I'm comfortable with "good enough" tools. And it's interesting, because not long ago, models like Sonnet and Opus were considered state of the art, now they're already casually labeled as baseline/mediocre in some discussions.

I also prefer a balance: I like using AI where it helps, but I still enjoy doing parts of the work myself.

These Vulnerabilities Aren't New

As stated by Anthropic itself, these vulnerabilities are not unique to Fable or Mythos, they can be found in other models as well. I find this particularly interesting, as it contrasts with some of the narratives that have surrounded these systems.

I won't claim to know what on earth is going on behind the scenes, and I'm not interested in speculating. Instead, I prefer to focus on the information that is actually available and verifiable.

There are plenty of conspiracy theories and rumors circulating around this topic, but I never trust rumors. I try to stick to facts and only facts, when forming an opinion.

Here's one key statement that should be taken into consideration:

"If this standard was applied across the industry, we believe it would essentially halt all new model deployments for all frontier model providers."

So, it sounds like regardless of how many guardrails frontier models have, they still remain vulnerable in one way or another. This isn't exactly breaking news... it's more a reflection of how AI systems fundamentally work.

Unlike deterministic systems, AI models are inherently non-deterministic. Even fully deterministic software can contain thousands of vulnerabilities, so it's not surprising that AI systems, especially those that behave in more probabilistic, human-like ways, also have weak points.

In a sense, humans themselves are an example of this unpredictability: flexible, adaptable, but also inconsistent, error-prone, and sloppy when it comes to precise tasks. When you scale that kind of variability through AI systems operating at massive scale, the result can become pretty spooky.

National Security Comes First

The jailbreak research was done in Amazon. Andy Jassy - the Amazon CEO himself was one of the tech leaders who raised concerns to the government of the United States.

What's interesting here is that Amazon is one of Anthropic's biggest investors. At first glance, it doesn't make sense. However, when national security concerns are involved, priorities often shift in ways that override literally everything.

In such contexts, security becomes the primary concern. The potential consequences of exposure or misuse are significant, and the last thing any system wants is to compromise sensitive information at a national level.

This is especially important for a country like the US which is really on the very top in terms of AI and technological development, where the stakes are particularly high and the margin for error is extremely small.

And when things get concerning at that scale, it's reasonable to expect that a country like the United States, that aims to maintain leadership across every major field, including the AI race, will take a close interest in it.

History shows that even small mistakes can have significant consequences when the stakes are this high. The closest historical parallel is the space race decades ago, where technological and strategic dominance was treated as something that couldn't be compromised, even slightly.

In races like that, maintaining an edge often means not giving up even an inch of ground to competitors.

It's possible there was a miscommunication and that the ban was simply too harsh. I don't really know, time will tell. However, the way it was communicated by Anthropic themselves, gives the impression that this outcome may not have been entirely unintended.

The framing around Mythos and Fable was, for some reason, based on fear, and it did create fear across the entire ecosystem. Whether that was the intention or just the result of cautious communication is hard to say, but the reaction it triggered was significant.

Let's break that down a bit.

Project Glasswing

Let's go back a bit, because this feels like a turning point in AI, where everything started, and where much of the later controversy can be traced.

A new generation of models was introduced, with Mythos standing out as a major leap in capability, significantly more powerful, efficient, and effective than its predecessors. However, instead of releasing it publicly, it was kept closed.

Rather than broad deployment, access was limited to a small number of major technology organizations, with the stated goal of securing and supporting some of the world's most critical software systems.

Their cause with this new model was to improve cybersecurity for highly critical systems and help protect them from AI-powered tools and attacks.

See where's the problem here?

AI models have become so good at coding and scripting that, in some cases, humans can no longer reliably secure software against cyberattacks on their own. As a result, we end up building even more capable AI systems to defend against threats created by previous generations of AI.

But then comes the next step: those defensive systems need to be even stronger to handle new, more advanced attacks caused by those new generations of models. And so the cycle continues, each layer of defense requiring a more powerful tool than the last.

So where does it end? In practice, it may not.

It's like inventing faster cars for the police to catch street racers. At first, it works. But over time, those same street racers get access to similar, or even better cars, and the cycle continues. Now you need even faster vehicles just to keep up.

And the faster those cars become, the higher the stakes. When criminals gain access to more powerful tools, the potential damage they can cause increases as well compared to earlier, less capable systems.

The same logic applies to AI. And it's not like this wasn't carefully considered, those people at Anthropic are pretty smart (well, duh). That's part of why access was limited to a small number of major companies: to strengthen the systems those organizations rely on, and to make them robust enough that a model like Mythos could eventually be deployed more safely at scale before releasing it to the public.

But there's a catch, and it's a big one:

If Mythos is as capable as it is claimed to be, it could potentially be used to improve itself over time, alongside the natural improvements made by Anthropic through updates and training.

If that's the case, there is still a significant risk that such a system could be used maliciously against critical infrastructure, even if indirectly. The concern isn't just theoretical capability, but how that capability could be applied at scale.

These systems can include, for example:

Financial and banking systems
Military systems
Healthcare systems
Airport control systems

And the list goes on. When you multiply that level of risk by the scale at which AI operates, the potential consequences can become absolutely catastrophic.

Mythos Is Exposing Every Major System and Software

Here's what they wrote in the project announcement:

Zero-day vulnerabilities are something that were unnoticed by anyone. Nobody had any idea they existed the whole time... until Mythos found them. That's how good it actually is.

Alright how about this one:

Imagine discovering a vulnerability in a system known for its reliability, one that powers some of the most critical infrastructure in existence. Now imagine that vulnerability had been there for 27 years...

Let that sink in for a moment. We're talking about something that dates back to the previous century, built and maintained by some of the most experienced engineers in the field. And yet, none of them were able to detect it, even with the advanced tools we have today. Tell me that's not insane.

Now this one:

And check out this tweet right here:

So it really does act like a human.

But what's even more significant, is this:

As they mentioned, this is an operating system that runs the whole world. And that's not even an exaggeration. Now, that is actually pretty scary, because as beneficial these tools can be, it can also be a destructive weapon in the wrong hands. Especially today, when information and data is literally everything.

But It's Not Only About Systems

On top of that, the risk doesn't only apply to systems themselves, it also extends to the people working within organizations.

As mentioned, Mythos is described as having more human-like characteristics and behavior than previous models, which increases the likelihood that it could convincingly manipulate users into taking actions they shouldn't.

This is particularly relevant in the context of phishing and scam attempts. Large companies are already primary targets for these kinds of attacks. If AI becomes advanced enough that it's nearly impossible to distinguish between a legitimate email and a malicious one, the problem becomes significantly more serious.

There have already been numerous cases where companies suffered major damage simply because an employee clicked on a deceptive link or responded to a convincing message.

Now imagine a scenario where those emails are generated by AI and appear completely legitimate, down to the smallest detail.

Anthropic's Ways of Promoting These Models Are Super Weird

Oh, almost forgot, speaking of emails, here's what Sam Bowman, who's working as "AI alignment + LLMs" at Anthropic, Tweeted:

If this tweet alone doesn't raise a petaquintjillion questions, I don't know what does.

But first of all, why on earth did that model even try to access the internet, let alone how it actually managed to access it? If it was restricted programmatically, well, it's less terrifying. However, if it was properly secured and isolated in the internal network, then it would raise some pretty uncomfortable questions about how it managed to reach beyond its intended environment... did it hack its way through the Anthropics internal environment? That's something straight out of a science fiction movie, if that's the case.

Here are other tweets by him and Boris Cherny

I don't know, this whole fear-based promotion is kind of strange. However I really do appreciate that they're completely open and honest about all that. This is something that should never be hidden.

There are speculations and rumors circulating that Anthropic wants to be regulated by the government so they can potentially become the go-to organization for AI in the public sector. I have no idea whether that's true or not, I only heard it mentioned in a video by ThePrimeagen.

There's also another rumor that this is being done for marketing purposes. But if that's the case, I think it may have backfired, because I don't believe banning both Mythos and Fable was their primary goal, unless they're playing a much, much longer game.

The Bottom Line

The bottom line is this: if you say your AI is dangerous and terrifying, there's a pretty good chance people will believe you. So if it's all honest, the government will do everything it can to avoid compromising national security, and you shouldn't be surprised by that. Granted, there might be some miscommunication here and there, but how things appear often outweighs how they actually are.

Sure, you can add as many guardrails as you want to Mythos, which effectively gives you Fable, but as mentioned above, guardrails can always break. And breaking the guardrails on Fable is much, much worse than breaking them on any other model, because when you break those guardrails, you essentially unwrap Mythos - the model that is capable of finding vulnerabilities in some of the most critical systems imaginable.

On the other hand, if this is all just hype to attract more attention to the new models, then that's arguably even worse. Playing with something as sensitive as national security rarely ends well, and people will inevitably start asking questions.

Summary

The whole situation is kind of weird, and we don't really know what's going on behind the scenes. But regardless, it all shows that AI psychosis is already a real thing, and we should do our best not to fall into that rabbit hole. AI can be an absolute blessing, I use it every single day, and it has made me at least ten times more productive, but we need to be smart about it.

We need to find a balance between AI being fully controlled and AI being completely independent with no regulations. Neither extreme is good.

If you're someone who jumps on the latest AI tools the moment they launch, take a moment and let things settle. Maybe give it a week or two until they're more thoroughly tested. And if you're running a company, always have a safety net, because AI is not deterministic, far from it. In fact, the more complex these systems become, the more unpredictable and potentially risky they are.

Like every technology before it, AI is a tool. A very powerful one. But tools are most useful when they complement human judgment, not replace it.

NeuralHats: I Put Edward de Bono’s Six Thinking Hats on Local LLMs Using Gemma 4

Giorgi Kobaidze — Sun, 24 May 2026 19:10:31 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

The Exact Moment It Clicked

Two weeks ago, when Jess posted about the Gemma 4 challenge, I got stuck in a decision-making loop. I didn't know which idea to build, and I had a few competing options.

Usually, when I think about a new project idea, I don't tell anyone until it is completely done. That is just how I like working. I speak with results, not with plans.

Because of that, I did not really have anyone to brainstorm with. I found myself wishing I had a room full of people I could talk through the decision with, to help me figure out which idea to actually commit to.

Then it suddenly reminded me of Edward de Bono's Six Thinking Hats, which I had read about five years ago. And I thought, damn, I wish I had a local AI system where I could actually run that kind of structured discussion.

Then I stopped...

Whoa, wait a second... Why am I wishing for this? Why don't I just build it RIGHT NOW?

And not just build it, but make it fully local on my own PC. No APIs, no cloud. Just something I can run instantly and talk to like a thinking room inside my machine!

That felt like the idea!

What if I could conjure six of those personas on demand, locally, for free, and let them argue about anything I wanted? And even participate in the discussion when needed?

So I built NeuralHats - a local web app where six AI personas, each running on its own tuned instance of Gemma 4, sit around a virtual debate table and argue about any topic you give them. They follow the canonical order. They actually disagree. The Blue Hat, the chairperson, decides when the debate is over. And when the dust settles, a seventh model, the Facilitator, writes a final report you can save as a PDF.

What it Actually Does

🎩 Six tuned personas debate any topic you choose
🔄 Up to 5 rounds, with the Blue Hat deciding when to wrap up via a CONTINUE / STOP token
🧑‍💼 You can join in, claim one of the hats and contribute your own perspective live
📡 Server-Sent Events stream each hat's turn the moment it's ready
📄 PDF report synthesised by a dedicated Facilitator model at the end
💯 100% local: no API keys, no cloud calls, no telemetry, no internet required after setup

Demo

Check out the video walkthrough:

Code

The Essentials

georgekobaidze / neuralhats

Six AI personas debate any topic using Edward de Bono's Six Thinking Hats framework. Powered by Gemma 4 via Ollama. Runs fully local.

NeuralHats

Six AI personas. One structured debate. Every perspective covered

🎥 Demo Video · 📖 Article · 🐛 Report a Bug

About

NeuralHats brings Edward de Bono's legendary Six Thinking Hats framework to life through AI. Instead of reading about the method, you experience it. Six distinct AI personas debate any topic you choose, each embodying a different mode of thinking.

Each hat is a fully independent AI model persona powered by Gemma 4 via Ollama, with its own system prompt, voice, and reasoning style:

Hat	Role	Focus
⚪ White	The Analyst	Pure facts, data, and objective information
⚫ Black	The Critic	Risks, flaws, and devil's advocacy
🟢 Green	The Creative	Bold ideas, lateral thinking, alternatives
🔴 Red	The Feeler	Emotions, gut instinct, raw reaction
🟡 Yellow

…

View on GitHub

To run it yourself:

git clone https://github.com/georgekobaidze/neuralhats.git
cd neuralhats
./setup.sh   # or .\setup.ps1 on Windows
./start.sh   # or .\start.ps1 on Windows

That's it. The setup script pulls Gemma 4, creates the seven custom models, installs the Python and Node dependencies, and start boots the FastAPI backend and Vite frontend together. You'll be debating at http://localhost:5173 within minutes.

Architecture in one breath

React + Vite + Tailwind v4  ──HTTP/SSE──►  FastAPI (Python)  ──HTTP──►  Ollama  ──►  Gemma 4
                                                  │
                                                  └──► SQLite (aiosqlite, ON DELETE CASCADE)

Three layers, zero external services. The frontend is a single-page React app with a virtual debate table. The backend is a small FastAPI server with one main orchestrator and an SSE stream. The AI layer is seven custom Ollama models - six hats plus a Facilitator, all built from the same Gemma 4 base.

Let me walk you through the parts I'm most proud of.

One Base Model, Seven Personalities

Running seven separate copies of Gemma 4 would turn my GPU into lava. Instead, I used Ollama's Modelfile system to create seven lightweight aliases over the same base weights - each with its own temperature, top-p, and system prompt:

# backend/modelfiles/Modelfile.template
FROM {{BASE_MODEL}}

PARAMETER temperature {{TEMPERATURE}}
PARAMETER top_p {{TOP_P}}
PARAMETER num_ctx 8192

The setup script bakes in personality through parameters:

# setup.ps1
$HatParams = @{
    white       = @{ temp = "0.3";  top_p = "0.9"  }   # cold facts
    black       = @{ temp = "0.4";  top_p = "0.9"  }   # cautious critic
    green       = @{ temp = "0.9";  top_p = "0.95" }   # creative chaos
    red         = @{ temp = "0.85"; top_p = "0.95" }   # raw emotion
    yellow      = @{ temp = "0.6";  top_p = "0.9"  }   # warm optimist
    blue        = @{ temp = "0.3";  top_p = "0.9"  }   # disciplined chair
    facilitator = @{ temp = "0.2";  top_p = "0.9"  }   # near-deterministic synthesis
}

Red Hat runs hot (0.85) - its job is intuition, gut feelings, vibes. White Hat runs cold (0.3) - its job is facts and only facts. Switching from one to another costs nothing because they all share weights in memory. Personality is just parameters and prompts.

The Blue Hat is a Controller, Not Just a Debater

The Blue Hat is the chairperson. Its prompt forces it to end every response with exactly one of two tokens on its own line:

End your response with exactly one of these two tokens on its own line:
    CONTINUE — if meaningful new ground can still be explored
    STOP — if consensus has been reached or no new insights are likely

The orchestrator parses that token to decide whether to start another round or end the debate. The LLM's output literally becomes control flow.

# backend/orchestrator.py
def _parse_blue_decision(blue_response: str) -> bool:
    """Return True if debate should CONTINUE, False if it should STOP.
    Scans lines in reverse to handle trailing text. Defaults to CONTINUE."""
    for line in reversed(blue_response.strip().splitlines()):
        token = line.strip().upper()
        if token == "CONTINUE":
            return True
        if token == "STOP":
            return False
    return True

That tiny function is the heartbeat of the whole loop. Reverse-scanning so trailing whitespace or quote marks don't break parsing. Safe default to CONTINUE because terminating early is worse than running one too many rounds.

The debate loop

Here's the actual orchestrator stripped down. Six hats, in order, up to five rounds, controlled by the Blue Hat's verdict:

HAT_ORDER = [HatColor.WHITE, HatColor.BLACK, HatColor.GREEN,
             HatColor.RED, HatColor.YELLOW, HatColor.BLUE]
MAX_ROUNDS = 5

for round_num in range(1, MAX_ROUNDS + 1):
    await _push({"type": "round_start", "round": round_num})

    for hat in HAT_ORDER:
        if hat == user_hat:
            content = await _await_user_turn(hat)   # human steps in
        else:
            await _push({"type": "hat_thinking", "hat": hat})
            messages = _build_messages(topic, conversation_history,
                                       hat=hat, round_num=round_num)
            content = await ollama_client.chat(messages, hat=hat, mode=mode)

        conversation_history.append({"hat": hat, "content": content,
                                     "round": round_num, "is_user": is_user})
        await _push({"type": "message", "hat": hat, "content": content, ...})

        if hat == HatColor.BLUE:
            blue_response = content

    if not _parse_blue_decision(blue_response) or round_num == MAX_ROUNDS:
        await _push({"type": "debate_end", "status": "completed"})
        return

That's almost the entire thing. No agent framework, no LangChain, no LangGraph. Just a loop, a queue, and a parsed token. The simplicity is the point.

Real-time streaming with SSE

Waiting 30 seconds for an entire debate to finish before showing anything would be unbearable. So I push each completed hat turn over Server-Sent Events the moment it's ready:

async def event_stream():
    while True:
        event = await _event_queue.get()
        yield event
        if event.get("type") in ("debate_end", "error"):
            # Hold the connection open briefly so the browser receives the
            # final event before the server closes.
            await asyncio.sleep(2)
            break

The frontend's EventSource reacts in real time, a new chat bubble appears as soon as each hat finishes thinking. Watching it unfold feels like watching a real panel discussion.

🎯 Structured conversation history beats flat transcripts

Earlier on I noticed the hats were ignoring each other. The Yellow Hat would give a generic positive answer that didn't actually respond to the Black Hat's specific risk. That was a context problem, they were getting a flat blob of text and skimming it.

So I restructured the history: separated previous rounds from current round so far, surfaced the most recent Blue Hat direction prominently, and gave each hat per-hat reminders to prevent drift:

_HAT_REMINDERS = {
    HatColor.WHITE: (
        "REMINDER: Review the conversation history above. Do not repeat any fact, "
        "statistic, or metric you have already stated in a previous round. "
        "Every sentence must be new information."
    ),
    HatColor.YELLOW: (
        "REMINDER: White Hat's data points and Black Hat's identified risks are "
        "valuable findings — not just Green Hat's ideas. If you endorsed Green Hat "
        "last round, you MUST endorse a different hat this round."
    ),
    HatColor.RED: (
        "REMINDER: Pick ONE emotional state for this response and stay in it the "
        "whole way through. Do NOT swing between opposite feelings in a single turn."
    ),
    # ... and three more
}

After this change, the debates suddenly felt coherent. Hats started naming each other ("As Black Hat just pointed out..."). The Yellow Hat actually engaged with risks instead of pretending they didn't exist. Same model, same temperatures, just a smarter conversation envelope.

A separate Facilitator

The seventh model, neuralhats-facilitator, runs at temperature 0.2, almost deterministic. It's not in HAT_ORDER. It never debates. Its only two jobs:

Title generation: when the user types a topic, the Facilitator drafts a short title for the debate
Final report synthesis: after the Blue Hat votes STOP, the Facilitator reads the entire transcript and writes a neutral, structured summary the user can export as PDF

Splitting it off from the hats keeps the synthesis voice neutral and the temperature low enough to actually be useful as a summary. Mixing those jobs into one of the colored hats would compromise both.

Cascade Deletes

The schema looks like this:

CREATE TABLE rounds (
    id          TEXT PRIMARY KEY,
    debate_id   TEXT NOT NULL,
    round_number INTEGER NOT NULL,
    created_at  TEXT NOT NULL,
    FOREIGN KEY (debate_id) REFERENCES debates(id) ON DELETE CASCADE
);

CREATE TABLE messages (
    id          TEXT PRIMARY KEY,
    round_id    TEXT NOT NULL,
    hat         TEXT NOT NULL,
    content     TEXT NOT NULL,
    is_user_message INTEGER NOT NULL,
    timestamp   TEXT NOT NULL,
    FOREIGN KEY (round_id) REFERENCES rounds(id) ON DELETE CASCADE
);

ON DELETE CASCADE from messages → rounds → debate means deleting a debate is a single atomic operation. Hundreds of related rows disappear with one DELETE FROM debates WHERE id = ?. No application-level cleanup, no orphaned data, no foot-guns.

How I Used Gemma 4

I went with Gemma 4 E4B as my default base model.

Here's why:

The constraint: it has to be local, and it has to be fast

NeuralHats fires 6–7 model invocations per debate round (one per hat, plus the facilitator for final synthesis). With 5 rounds max, that's up to 31 inference calls in a single debate. If each call takes 30 seconds, that's a 15-minute debate which is pretty unusable.

I needed a model that was:

Small enough to run smoothly on consumer hardware (laptops, mid-range desktops)
Fast enough that a hat's response feels like watching someone think, not waiting for a printer
Capable enough to actually hold a position and engage with arguments, not just produce plausible-sounding mush

Why E4B specifically

The 26B model would have been the safe "capability" choice, clearly better at reasoning. But it still turned out to be too much for the turn-based UX I needed. Each round would take minutes, killing the live-panel feeling.

The E2B (2B) model is lightning fast but it didn't hold its hat persona well enough, under pressure it would drift, lose the role, or repeat itself.

E4B hit the sweet spot. It runs comfortably on a 16 GB VRAM machine, generates a hat response in 3–8 seconds depending on hardware, and is capable enough that with the right system prompt and per-hat parameters it genuinely stays in character. Watching the Red Hat shift emotional tone between rounds, or the Black Hat surface genuinely novel risks each time, that's all E4B.

What Gemma 4 unlocked that nothing else could

Three things, specifically:

1. Native multi-instance personality. Because Ollama lets me create lightweight aliases over the same base weights, I get seven distinct AI personas without seven copies of the weights in RAM. Try that with a hosted API and you're paying for seven independent context windows. With Gemma 4 local, it's free.

2. The Blue Hat's CONTINUE / STOP discipline. Small models often fail at strict format constraints, they want to ramble. Gemma 4 E4B reliably ends every Blue Hat turn with exactly one of those tokens on its own line. Without that reliability, the whole control-flow trick falls apart.

3. The freedom to ship "100% local" as a feature, not a constraint. No API costs, no rate limits, no internet dependency, no privacy concerns about feeding personal dilemmas to a third party. For an app whose entire premise is "let six minds help you think through something you wouldn't want to discuss with anyone else" - that's not a nice-to-have. That's the product.

Summary

NeuralHats started because I was stuck inside my own head and needed another perspective. It turned into a project about how, with the right architecture, a single E4B model can play six different roles convincingly enough to actually help you think.

The Gemma 4 family made that possible, small enough to run on my own machine, smart enough to genuinely disagree with itself, and disciplined enough that a 200-word Blue Hat summary ends with the exact token my orchestrator needs to make a decision.

If you've ever been stuck inside your own head, clone it, run it, give it your problem, and let the hats argue. Worst case, you have a good laugh. Best case, you get unstuck.

15 Essential Sections Every README Needs: Give Your Project What It Deserves

Giorgi Kobaidze — Sun, 26 Apr 2026 14:31:29 +0000

Overview
README Files Are Never Perfect
The Primary Purpose of README Files
A Good README Starts With a Proper Structure
The Essential README Sections
- Title and Introduction
- Table of Contents
- About
- Features
- Tech Stack
- Architecture
- Project Structure
- Getting Started
- Configuration
- Security
- How to Contribute?
- What's Next?
- License
- Acknowledgements
- Author
Ready-to-Use Template
Conclusion

Overview

Imagine building an amazing software product that no one can use, or even knows exists simply because it lacks proper documentation. Unfortunately, there are plenty of projects like that.

Yours doesn't have to be one of them.

Earlier I published an article The Final 1% of Every GitHub Project: Sealing It Properly, where README was literally the first item on the list. Yes, it's that important, and that's why I decided to take a deeper look into this topic.

If you're a software engineer, knowing how to write proper documentation is one of the most critical skills you can have. There's no excuse for skipping it or considering it as optional.

Yes, coding is way more fun. But coming back later and trying to understand what you did (and why you did it) without any reference is far less fun than writing a few clear notes upfront.

And if you want your work to be recognized, used, contributed to, or even starred, documentation isn't optional. It's one of the first things people see, and often the reason they stay... or leave.

But this article isn't about documentation as a whole, that's a massive topic and it deserves to be broken down. There are many different types of documentation, each serving a different purpose.

Here, we're focusing on the most essential one: the README.

README Files Are Never Perfect

I've seen so many variations of README files throughout my career. Some were good, others not so good, and a few were close to perfect.

But one thing is always true: having a README with somewhat useful information is way better than having no README at all.

You have to start somewhere. Perfection doesn't happen from the beginning, it's something you work your way up to over time.

I've been a software engineer for almost a decade now, and even today, I still look at my own README files and think they could be clearer, more consistent, or simply better. You're never fully satisfied with how you write documentation and that's exactly the point.

It's something you continuously refine, just like your code.

In this article, I'll walk through the essential README sections, and explain why each of them matters.

At the end, I'll also provide a ready-to-use README template you can take and adapt for your own projects.

The Primary Purpose of README Files

The primary purpose of a README is to quickly guide someone through the essential information about a repository.

It should include just enough detail for others to understand what the project is about, how to get it running, and how to contribute. Not everything needs to live in the README, trying to cover too much will only make it harder to read.

There's a reason different types of documentation exist. Each serves its own purpose, and the README is meant to be the entry point, not the entire manual.

A Good README Starts With a Proper Structure

README files are typically written in Markdown, which has become the universal format for a few good reasons: it's simple, widely supported, easy to learn, and flexible enough to cover almost everything you need in a README.

If you've never used Markdown before, it's worth checking out a quick reference. In less than half an hour, you can learn everything you need to write solid README files. For anything more advanced, you can always refer back to the documentation later.

The key point is this: don't write your README as just plain text. It's just terrible to read and doesn't scale well. Instead, use Markdown features to make your documentation not only informative, but also clean, structured, and easy to scan.

The Essential README Sections

Alright, it's time to go through the essential sections you should include in your README.

But the key thing to keep in mind is this: this is not a definitive checklist. Every project is different, and your README should reflect that. In addition to these core sections, you might need custom ones specific to your project, so don't feel limited by this list.

Also, not every section is necessary in every case. If you're building a simple "hello world"-level application, you don't need to overthink things or include everything mentioned here. The goal of this article is to cover the sections that make sense for most real-world projects.

And if you think I've missed something important, feel free to share your experience in the comments, it can be valuable for both me and the wider developer community.

So here's my list:

Title and Introduction

Before diving into your project details, it's important to start with the most essential elements: the title and a short description.

This is where you capture attention. As you probably know, first impressions matter a lot, if you want people to keep reading, this is the section that determines whether they do or not.

You can also make this section more engaging by adding visual elements like a logo, tags, or a screenshot of your project. For example, the homepage, dashboard, or any interface that looks clean and appealing works really well.

Here's an example from one of my projects: Sunday DEV Drive.

Remember, this section is the main poster of your entire project. Make sure it's clear, effective, and catchy, it's often the first thing people see, and it sets the tone for everything that follows.

It can also be functional, not just visual. You can include useful links like a demo, video walkthrough, article, or any other relevant resource that helps people understand your project faster.

Whenever I write any kind of structured content, whether it's a document, a README, an article, or anything similar, I always try to include a table of contents.

It's one of the most underused and underrated parts of documentation. I wouldn't call it absolutely critical in every case, but it adds a lot of clarity and structure.

Think of it like the opening credits of a movie. The movie might be great, but those opening credits already give you a sense of who's involved and what to expect. They set the context before the story even begins.

A table of contents does the same thing for your project. It helps readers quickly understand what's inside and jump straight to the section they care about.

Here's an example from one of my projects: NoteRunway.

Additionally, you can add links to each section so users can easily navigate through the README without having to scroll and search for what they need.

About

This is where you actually start describing your project: what it is, what it does, and at a high level, how it works. Focus on the key highlights and the core idea behind it, but don't go too deep into implementation details just yet, that comes later.

Here's an example from another one of my projects: Metal Birds Watch.

Features

Now it's time to expand the details a bit and start talking about the major features your project supports.

There are two common ways to structure this section. You can either use a simple table format, where you list each feature alongside its description, or you can go deeper and use subheadings for each feature if you want to provide more context and detail.

Here's an example of the features section from my Metal Birds Watch project:

Even though this section goes into more detail, the descriptions should still stay at a high level. The goal is to help readers understand what each feature does, not how it's implemented.

In most cases, you shouldn't include implementation details here. Those belong in deeper documentation or technical sections. Only include them when there's a specific reason they're important for understanding the feature itself.

Tech Stack

One of the most important pieces of information a README should include is the tech stack.

First, because it represents the building blocks of your project. And second, many developers actively look for projects built with specific technologies so they can contribute using their existing skills.

So make it clear what your project is built with, it helps both understanding and discoverability.

Here's the tech stack section from my NoteRunway project:

Architecture

This section is typically where you describe your architecture, a bird's-eye view of how the different parts of your system work together.

For example, this might include the front-end, back-end, database, caching layer, external services, load balancers, firewalls, and anything else relevant to your system design.

It's also a good practice to visualize your architecture using diagramming tools like draw.io, Lucidchart, or similar tools. A visual representation is almost always easier to understand than a purely textual explanation, especially for more complex systems.

Here's the architecture diagram from the Metal Birds Watch project:

As you can see, you don't need to create something overly sophisticated. In most cases, the simpler the diagram, the better.

Clarity should always come first. Keeping things simple and easy to understand is usually more valuable than adding unnecessary complexity, and it's something fellow developers will always appreciate.

Project Structure

This one is a bit controversial, I don't see it in many README files, and I understand why. You can always explore the source code and figure out the structure yourself, right?

But the benefit of including this section is that you can clearly describe the key folders and files, what they do, and what their purpose is.

Yes, it can be a bit tedious to write. But it pays off, not just for future contributors, but for your future self as well. When you come back to the project later, this section quickly reminds you how everything is organized.

Always take care of future you.

Here's an example from Metal Birds Watch:

Getting Started

Some prefer calling it "Setup", both work, the main idea of this section is to clearly explain how someone can clone your repository and set it up on their local machine.

This is one of the most important parts of a README, if not the most important, because no one can contribute to your project if they can't even get it running locally.

Once you've listed all the setup steps, make sure to actually test them yourself. This helps you catch missing details early and reduces frustration for both you and other developers.

This section can include things like installing required frameworks and dependencies, setting up external service accounts (if needed), creating local databases, configuring environment variables, and any other steps required to run the project locally.

Here's the example from the NoteRunway app:

Configuration

This can be part of the "Getting Started" section, but I sometimes keep it separate because configuration is one of the most fundamental parts of any project.

Configuration can quickly become complex and tedious, so it's important to document it clearly in your README. This ensures you always understand what each parameter does and how everything is set up.

You can include any type of configuration here, like environment variables, database-related settings, feature flags, or external JSON configuration files stored in the cloud.

Unlike the high-level overview sections, this is where you go into more detailed, practical setup information that's necessary for the project to actually run correctly.

Here's an example from Metal Birds Watch:

Security

Security is one of the most important aspects to address in your documentation.

This section ensures that if someone adds new features or modifies existing ones, they follow the established standards and understand how security is handled throughout the project.

Here's where you outline the key security considerations of your system, so contributors don't accidentally introduce vulnerabilities or break existing protections.

Here's an example from the NoteRunway app:

How to Contribute?

This is where you briefly describe the contribution guidelines for your project.

Sometimes this can't be kept short, especially in large open-source projects with thousands of contributors. Without clear rules, things can get messy quickly.

However, if your project is still early-stage, there's no need to overcomplicate it. Simple guidelines are usually enough to start with, such as the ones below:

What's Next?

It's a good practice to let readers know that your project isn't finished and that you plan to continue supporting it and adding new features over time.

This is where you can list what's coming next. It not only shows the direction of the project, but also gives contributors ideas for where they can start contributing.

Here's an example:

License

The license information is absolutely essential. This is where people understand what they're allowed to do with your project and under what conditions.

You don't need to include the full license text or explain it in detail. In most cases, it's enough to simply state the license type and link to the license file, like the following example:

Acknowledgements

Show gratitude to anyone who has contributed to your project, as well as any tools, libraries, or resources that helped you build it.

It's a simple but meaningful section, and it's always good practice to include it when appropriate. Here's an example from the NoteRunway app:

Author

And last but not least, leave your mark, because you are the main person behind the project. You put everything together and made it work.

Make it easy for others to reach out, ask questions, or even propose collaborations.

Here's my example:

Ready to Use Template

Here's a template you can copy, paste into your project, and customize as needed. Feel free to adjust it, add new sections, or remove anything that doesn't fit. This is meant to be a flexible starting point for building a well-structured README.

# Title and Introduction (replace this with your project title)

---

## Table of Contents

---

## About

---

## Features

---

## Tech Stack

---

## Architecture

---

## Project Structure

---

## Getting Started

---

## Configuration

---

## Security

---

## How to Contribute?

---

## What's Next?

---

## License

---

## Acknowledgements

---

## Author

Conclusion

Like in most areas of software engineering, writing good README files takes experience and practice.

But having a solid starting point can make the process much faster and more straightforward. That's the main reason I'm sharing this, so you can get up to speed quickly and start improving your documentation from day one.

Good documentation doesn't just help others, it makes you a better engineer overall.

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

135

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

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

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

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

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

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

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
📝 DEV.to Article → Read the write-up
▶️ YouTube → Watch the demo

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

…

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

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

135

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