DEV Community: Giorgi Kobaidze

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

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

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

Hotel California

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

Hands Off the Mouse

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

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

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

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

Vim Was Never About Typing Speed

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

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

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

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

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

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

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

The Case for :q!

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

The Learning Curve is Harder to Justify

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

AI-First Tools Aren't Built for Modes

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

The Next Generation May Never Need It

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

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

Plot Twist: The Terminal Strikes Back

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

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

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

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

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

The Last 10% Is Where Vim Lives

This is the part that changes everything.

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

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

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

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

The Editor Might Leave, The Motions Won't

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

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

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

So... :q! or :w?

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

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

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

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

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

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

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

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

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

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

Showtime on the Balcony (Gone Wrong)

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

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

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

"I have just the thing for ya"

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

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

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

It wasn't browser-related.

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

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

I said.

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

A Quick Layover

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

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

Why This One Is Personal

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

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

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

But I won.

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

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

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

Engine #1: The Map That Said No

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

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

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

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

A Quick Patch on the Tarmac

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

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

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

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

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

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

Past me, thank you for that architecture decision.

Pre-Flight Checklist

There were a few details to think through, though.

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

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

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

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

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

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

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

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

Time to deploy.

Engine #2: Where Did All the Birds Go?

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

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

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

The Instrument That Lied

The backend logs were very clear about the problem:

Authentication failed - check OpenSky credentials

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

So I rotated them. It didn't help.

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

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

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

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

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

Opening Up the Engine

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

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

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

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

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

signal: AbortSignal.timeout(30000)

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

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

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

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

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

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

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

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

I deployed, waited, and waited some more.

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

Silence on the Frequency

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

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

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

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

Tower, Do You Copy?

So I asked OpenSky directly:

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

Can a specific address be allowlisted?
"No."

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

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

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

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

Back to the Hangar

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

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

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

Ten Seconds of Doubt

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

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

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

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

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

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

Speaking Fluent Aviation

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

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

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

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

Looking for a New Engine

Replacing the data provider is tracked in issue #98.

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

Reading the Black Box

If I had to summarize the flight recorder:

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

Final Approach

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

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

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

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

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

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

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

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

A Sci-Fi Scenario Come True

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

Nostalgia Isn't an Argument

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

The Most Dynamic Era to Be an Engineer

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

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

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

We've Been Here Before

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

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

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

The Hard Part Was Never the Typing

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

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

The Bottleneck Moves

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

Cheaper Software Means More Software

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

Coding Was Never the Point

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

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

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

I hope this little note helps a bit.

Enjoyed this brief note? Let's stay connected!

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

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

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

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

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

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

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

But...

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

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

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

Some Code Can't Explain Itself

Here's a perfectly clean piece of C#:

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

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

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

Now, quick quiz. Which of these are valid?

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

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

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

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

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

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

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

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

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

The Code Knows What. Only You Know Why

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

private const int MaxConcurrentRequests = 47;

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

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

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

Here's what was missing:

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

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

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

1. Translates

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

2. Explains

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

3. Warns

What breaks if you change this, and how badly.

4. Records

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

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

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

"Just Put It in the Commit Message"

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

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

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

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

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

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

Nobody runs `git blame` on code that looks fine

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

Blame decays

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

People leave

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

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

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

So What's the Worst That Can Happen?

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

The most common argument I hear is this:

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

And... so what?

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

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

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

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

Nuh-uh.

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

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

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

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

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

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

How Not to Write Comments

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

The echo

// Increment the retry count
retryCount++;

The XML doc that says absolutely nothing

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

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

The liar

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

The eternal "temporary" fix.

// TODO: temporary workaround, remove later

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

The graveyard

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

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

The novel

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

Clean Gets You Halfway

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

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

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

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

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

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

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

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

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

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

Let's Address the Elephant in the Room Again

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

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

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

Engineering is Part of Creation

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

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

Definitions Matter Here, Critically

Vibe Coding

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

AI-Assisting

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

AI-assisted

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

Where This is Going

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

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

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

The line I'd draw:

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

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

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

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

What I Actually Do?

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

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

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

So what's stopping you from doing the same?

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

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

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

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

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

I Write More Than I Read

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

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

The Rules

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

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

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

Why Bother

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

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

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

Showcase your work, appreciate everyone else's.

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

Let's stay connected!

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

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

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

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

— Chuck Close

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

This Wasn't Supposed to Be the Next Article

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

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

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

What the days actually looked like.

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

Let's just get it done.

What Locking In Actually Means

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

Quite the contrary.

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

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

There are reasons it has to run that long.

The Longer You Practice Consistency, The More Consistent You Get

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

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

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

Here's roughly how that went for me:

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

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

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

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

The Rule of 100: The Compounding Effect of Life

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

The rule of 100 basically means the following:

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

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

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

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

This is called the compounding effect of life.

Vacations Happen Roughly Once Every Six Months

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

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

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

Just Plan Things

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

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

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

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

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

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

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

Sharpen Your Tools

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

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

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

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

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

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

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

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

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

And many other things.

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

Now That You're Well Into The Camp Everything Matters

The System Is the Point

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

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

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

Same Hours, Every Day

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

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

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

Clock Out Twice

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

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

Do one thing in a given time. Only one.

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

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

Put Your Phone Away

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

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

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

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

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

The Body Is Part of the System

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

Think like a professional athlete.

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

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

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

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

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

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

Day Five Is Usually When It Turns

Here's the part nobody warns you about.

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

Day two, slightly less.

By day five you absolutely hate it.

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

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

Checkpoints Get You Through the Gap

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

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

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

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

That's when it stops being hard.

Recharge on Purpose

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

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

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

How to Deal With Bad Days

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

I had one recently.

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

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

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

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

It sucks, right?

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

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

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

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

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

Commit to More Than One Thing, Just Not at Once

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

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

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

So allocate days, not attention.

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

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

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

My Suggestion to You

Congratulations

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

Start Slow

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

Lonesome Is a State of Mind

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

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

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

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

By The Way

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

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

Let's get to that checkered flag!🏁

Enjoyed this deep dive? Let's stay connected!

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

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

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

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

Prefer Watching Instead?

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

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

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

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

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

Good morning! Good afternoon! Good Evening!

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

Let's get started!

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

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

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

...

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

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

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

The Game

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

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

Demo
Submission article
GitHub Repo

The Game Loop

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

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

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

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

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

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

animate(); // start the loop

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

The Game Physics

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

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

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

It Worked on My Machine Goddammit

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

Everything felt perfect.

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

ALWAYS TEST IT ON ANOTHER COMPUTER.

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

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

A few minutes later, they texted me back:

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

So I started troubleshooting.

And troubleshooting.

And troubleshooting some more.

Nothing made sense.

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

I had no idea what was going on.

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

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

...

I questioned my life choices.

And then it just clicked.

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

Yep.

My physics weren't actually frame-rate independent.

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

That's a 45 Hz difference.

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

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

I had messed up... And badly.

And now it was time to fix it.

Understanding the Root Cause

My animate loop looked like this:

function animate() {
  requestAnimationFrame(animate);

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

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

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

Look at what actually happens across different hardware:

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

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

The Fix: Delta Time

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

const clock = new THREE.Clock();

function animate() {
  requestAnimationFrame(animate);

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

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

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

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

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

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

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

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

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

Pattern 1: Linear operations

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

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

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

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

Pattern 2: Exponential decay:

Math.pow(factor, dt)

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

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

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

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

The correct fix uses exponentiation:

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

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

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

speed after 1s = speed × 0.97^60

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

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

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

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

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

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

Pattern 3: Lerp smoothing

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

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

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

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

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

The correct formula:

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

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

remaining = (1 - alpha)^n

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

adjusted_alpha = 1 - (1 - alpha)^dt

Plugging in the numbers:

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

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

Summary: The Three Patterns

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

One More Thing: Re-tune Your Constants

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

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

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

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

Pull Request

Check out the pull request for this bug fix:

Click Here to Check Out the Pull Request

The Takeaway

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

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

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

Enjoyed this deep dive? Let's stay connected!

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

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

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

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

Overview

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

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

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

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

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

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

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

Vibe Coding Is Easy. Doing It Well Isn't

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

Just a different kind of skills.

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

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

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

You try different approaches.

Different prompts.

Different models.

Different levels of context.

Different tasks.

You screw things up (inevitable).

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

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

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

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

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

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

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

Everyone Can Drive. Not Everyone Can Drive Well.

Who would you call a good, skilled driver?

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

They don't overspeed.

They park accurately, between the lines.

They can drive inside a lane consistently.

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

They're predictable on the road.

They care about the car.

They care about other drivers.

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

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

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

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

Now imagine the opposite.

You go 30 km/h over the speed limit.

Cut people off.

Floor the accelerator the millisecond the light turns green.

Brake so hard your passengers start reconsidering their life choices.

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

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

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

And that's an important distinction.

The same thing happens with AI

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

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

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

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

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

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

Sometimes you should let the AI explore the problem.

Sometimes you should give it very strict boundaries.

Sometimes you should ask it to implement something.

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

And sometimes the best prompt you can write is:

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

That's where the real skill starts showing up.

It's Not Just About Prompting

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

They reduce the skill to:

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

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

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

More tokens don't automatically mean better software.

More iterations don't automatically mean better software.

More context doesn't automatically mean better answers.

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

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

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

You don't necessarily need to be the person manually turning every screw anymore. Not every driver should be a car mechanic or a mechanical engineer.

You need to know which screws to turn, when to turn them, how hard to turn them, and when to stop touching things before you break something.

And the better you become at working with AI, the less you'll think about "getting AI to write code" and the more you'll think about orchestrating a system that produces good software efficiently.

Similarly to driving, you don't need to build the engine to drive the car. But you still need to know the rules of the road, you need to understand what the pedals do.

You need to recognize when something sounds wrong. You need to know when to slow down and definitely need to know that flooring the accelerator doesn't make you a better driver (it actually makes you look like a terrible driver).

The same applies to AI coding. Throwing more tokens at a problem isn't a skill nor is having the biggest context window or using the most powerful model for everything.

Being able to consistently get the result you need with the least unnecessary wastem, while keeping quality and safety high, is.

And the more time you spend operating around that sweet spot, the better you become at recognizing it.

And that's why:

"AI can write the code for me"

doesn't mean:

"I don't need skills anymore."

The skill just moved.

So yeah.

Be efficient.

Drive safe.

Hypermile.

Enjoyed this deep dive? Let's stay connected!

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

TypeScript Just Got 10x Faster by Not Being TypeScript

Giorgi Kobaidze — Sun, 02 Aug 2026 15:28:10 +0000

Introduction
Putting the 10x Claim Into Perspective
How Did We Get Here?
- This Was an Extensive Evaluation
- The Priority Was Compatibility
- Why Not Rust?
- Why Not C#?
- Why Go Fit the Existing Compiler
A Port, Not a Simple Translation
Where Does the Performance Come From?
- Native Execution
- Parallel Processing
Memory Efficiency and Larger Projects
The Benchmarks
- Memory Usage
The JavaScript API Trade Off
Is It Still TypeScript?
- The F1 Analogy
Large Companies Helped Test TypeScript 7
Should You Upgrade?
Final Thoughts

Introduction

At the end of March 2025, I published this article:

Giorgi Kobaidze

Mar 31 '25

Go-ing Beyond TypeScript: Microsoft Picks Go: How Will This Change the Landscape?

#microsoft #typescript #go #csharp

12 min read

At the time, Microsoft's decision to port the TypeScript compiler to Go sparked quite a bit of discussion and controversy. Many people questioned whether moving such a critical piece of the ecosystem away from TypeScript was the right choice.

And boy, did Microsoft deliver what it promised: an order-of-magnitude performance improvement on some of the world's largest TypeScript codebases.

The results are here, and the benchmarks speak for themselves.

Putting the 10x Claim Into Perspective

The phrase "10x faster" describes the scale of the improvement Microsoft has demonstrated. It does not guarantee that every codebase will become exactly ten times faster.

The results depend on the size of the project, the work being performed, and the available hardware. Some projects might see a 5x improvement, while others could reach 8x, 10x, 12x, or potentially even more.

No, this doesn't make every TypeScript developer a 10x developer, But it does mean that compiling a TypeScript project, loading it in an editor, and receiving diagnostics could become dramatically faster after moving to the native toolchain. The word "dramatically" isn't an exaggeration at all in this context.

But hold on, there are still some important caveats. So before you open your editor and start upgrading an enterprise application to TypeScript 7, read this article all the way to the end.

How Did We Get Here?

When I first covered this initiative in 2025, Microsoft had just announced Project Corsa, an effort to port the TypeScript compiler and tooling from TypeScript to native code written in Go.

The announcement immediately triggered the controversy and hot takes:

Why not Rust?
Why not C#?
Is Microsoft abandoning its own technologies? (Yeah, this one is particularly popular among Microsoft haters...)

The real explanation was much less dramatic. This was a pragmatic engineering decision focused on performance, compatibility, and maintainability.

This Was an Extensive Evaluation

The TypeScript team did not select Go after a superficial comparison. It evaluated several languages, built prototypes using different data representations, investigated hybrid architectures, and studied native TypeScript tools such as swc, oxc, and esbuild.

One possible approach was to move only performance-critical components to a native language while leaving the core type-checking algorithms in JavaScript. Ultimately, the team concluded that a complete native port would provide greater benefits.

That does not make Go the universally best language for compiler development. Several languages could have been excellent choices for a ground-up rewrite. Go performed best against the specific requirements of this project.

The Priority Was Compatibility

The most important requirement was not raw performance. It was compatibility.

Microsoft expects the existing and native implementations to coexist for some time. During that period, fixes and features may need to move between both codebases. A language that permits a similar program structure makes that work considerably easier.

A language requiring the team to rethink ownership, mutation, polymorphism, laziness, or fundamental data structures might produce an elegant new compiler, but it would no longer be a straightforward port. Idiomatic Go happens to resemble the function-and-data-oriented style already used throughout the TypeScript compiler.

Why Not Rust?

Rust could have been a strong option for a new compiler designed from the ground up. That, however, was not the team's objective.

The existing compiler relies heavily on automatic memory management and cyclic data structures. Rust's ownership model would have required the team to redesign those structures and rethink significant parts of the implementation. In Anders Hejlsberg's words, rewriting the compiler in Rust might have been possible, but faithfully porting it was not considered practical.

Why Not C#?

C# was also evaluated. This is important because C# is Microsoft's primary language, and Anders Hejlsberg himself is its original designer.

Hejlsberg described C# as a possible contender, but its higher-level, object-oriented model did not align as closely with the existing compiler. The TypeScript codebase follows a more procedural style built around functions and data structures. In fact, its core compiler does not use classes at all.

He also noted that C# did not have a native-code generation story as mature as the alternatives the team was considering. Go, by comparison, had more than a decade of native deployment across all major platforms and closely matched the compiler's existing programming style.

Microsoft did not choose Go because it had stopped trusting C#. It chose the tool that best matched this particular engineering problem.

Why Go Fit the Existing Compiler

Go provides garbage collection, supports cyclic and pointer-heavy data structures, offers control over memory layout and allocation, and enables shared-memory concurrency.

It is also a procedural language built primarily around functions and data structures. Go does not have traditional classes or inheritance, but it supports interfaces, first-class functions, closures, and other patterns used extensively throughout the JavaScript implementation.

TypeScript also performs an unusually large amount of graph processing, including upward and downward traversal through trees of polymorphic nodes. Go supports these patterns while allowing the native implementation to remain recognizably similar to its JavaScript counterpart.

A Port, Not a Simple Translation

Calling this work a simple translation would be misleading.

The team developed tooling to convert some TypeScript syntax into Go, but important structures, including abstract syntax tree nodes, symbols, types, and control-flow data, still required substantial engineering.

Compatibility remains the priority. The native compiler's behavior and output are continuously compared with the existing implementation through approximately 100,000 tests. The goal is to preserve TypeScript's semantics, diagnostics, and years of carefully developed optimizations rather than reinventing the language.

Where Does the Performance Come From?

The widely advertised 10x improvement comes from two major sources: native execution and parallel processing.

Native Execution

Native code removes much of JavaScript's startup, JIT-compilation, allocation, and runtime overhead.

In one demonstration, compiling roughly 250,000 lines took around seven seconds with the existing compiler. The single-threaded native implementation completed the same work in approximately two seconds.

Parallel Processing

Go then allows operations such as parsing, binding, emitting, and parts of type checking to run concurrently. After parallelization was enabled, that same 250,000-line compilation completed in less than one second.

On the much larger Visual Studio Code codebase, approximately 1.5 million lines, the compilation time dropped from more than a minute to around six seconds.

Anders Hejlsberg described the overall gain as roughly half native-code efficiency and half parallelism, although the exact balance naturally depends on the project and available hardware.

Memory Efficiency and Larger Projects

Memory management was another decisive factor in choosing Go.

Go gives the team control over the layout of objects, fields, and allocations without forcing every part of the compiler to manage memory manually. Although Go uses garbage collection, its usual disadvantages are less relevant to TypeScript's workload.

Batch compilations can allocate what they need and terminate before garbage collection becomes a major concern. In long-running processes, structures such as abstract syntax trees often survive for the lifetime of the program, and the compiler has enough domain knowledge to identify sensible moments for collection.

Go's UTF-8 strings, allocation-free substring operations, compact data layouts, and object-pooling techniques further reduce memory pressure. These improvements matter because out-of-memory failures have historically been one of the compiler team's most common categories of reported problems.

The result is not merely a faster compiler. It is a tool capable of processing projects that previously approached or exceeded the practical memory limits of the JavaScript implementation.

The Benchmarks

Microsoft published the following full-build benchmarks in the official TypeScript 7 announcement. Both versions were tested on the same machine, with TypeScript 7 using its default configuration of four type-checker workers.

Codebase	TypeScript 6	TypeScript 7	Speedup
VS Code	125.7s	10.6s	11.9x
Sentry	139.8s	15.7s	8.9x
Bluesky	24.3s	2.8s	8.7x
Playwright	12.8s	1.47s	8.7x
tldraw	11.2s	1.46s	7.7x

The largest relative improvement in this group comes from VS Code, where compilation drops from 125.7 seconds to 10.6 seconds, an 11.9x speedup. Sentry sees the greatest absolute reduction, saving more than two minutes on a single run.

These are not synthetic projects created to make the new compiler look good. They are large, mature codebases containing the complex type relationships, project structures, and dependency graphs that put real pressure on TypeScript.

The results should still be interpreted carefully. They measure TypeScript tooling performance under a particular benchmark environment, they do not mean that the JavaScript produced by TypeScript 7 will execute 10x faster. Results will also vary depending on project configuration, hardware, available CPU cores, and how much of a build pipeline is spent outside the TypeScript compiler.

Memory Usage

Codebase	TypeScript 6	TypeScript 7	Memory Delta
VS Code	5.2GB	4.2GB	-18%
Sentry	4.9GB	4.6GB	-6%
Bluesky	1.8GB	1.3GB	-26%
Playwright	1.0GB	0.9GB	-11%
tldraw	0.6GB	0.5GB	-15%

The memory improvements are less dramatic than the compilation-time gains, but they are still significant. Bluesky uses 26% less memory, while VS Code drops from 5.2GB to 4.2GB. On developer machines and CI agents running several jobs simultaneously, saving hundreds of megabytes, or even a full gigabyte, can make an important difference.

The variation between projects is also expected. Parallel execution can require additional working memory, while Go's compact data layouts, UTF-8 strings, allocation strategy, and object pooling reduce it. The final result depends on the shape of each codebase and the amount of concurrency being used.

Overall, the improvement is outstanding. I am especially looking forward to using VS Code with the native TypeScript language service. Faster startup, navigation, diagnostics, and type checking should make large projects feel considerably more responsive.

The JavaScript API Trade Off

One area where Go presents a genuine trade-off is JavaScript interoperability.

The existing TypeScript API allows consumers to access and sometimes modify a large amount of compiler state directly inside the same process. That flexibility has also constrained the team's ability to change internal representations and introduce new optimizations.

The native implementation cannot expose Go objects to JavaScript in the same way. For that reason, TypeScript 7.0 does not ship with a compiler API. Microsoft expects TypeScript 7.1 to introduce a new and deliberately designed API rather than reproducing unrestricted access to the old compiler's internal objects.

Applications that depend heavily on the TypeScript compiler API or undocumented internals will need to adapt. Until the new API is available, Microsoft provides the @typescript/typescript6 compatibility package so tools can use the TypeScript 6 API alongside the TypeScript 7 compiler.

Is It Still TypeScript?

Yes. The programming language is still TypeScript, and you will continue writing the same code as before. What runs in the background is completely different, but there is nothing particularly strange or outrageous about that.

As of August 2026, TypeScript 7.0 is stable and available through the standard typescript package. This is still a port rather than a new programming language: developers continue writing the same TypeScript while the machinery behind compilation, diagnostics, and editor tooling has changed.

The F1 Analogy

If you are an F1 nerd like me, you might know that McLaren used Ford-Cosworth engines for much of the period between 1968 and 1983. That partnership helped McLaren win its first Constructors' Championship in 1974, along with Drivers' Championships in 1974 and 1976.

The car was still a McLaren. Its chassis, aerodynamics, controls, strategy, and overall identity belonged to the McLaren team. The engine, the main component that turned all of that engineering into motion, came from Ford because it was the right tool for the job. Not that McLaren couldn't build engines, but Ford's engines were exponentially better for F1 racing.

TypeScript 7 follows a similar idea. The language, syntax, type system, and developer experience remain TypeScript. The engine running underneath them is being replaced because the native Go implementation is significantly better suited to the workload.

This is not a language war, corporate rivalry, or evidence that Microsoft is ditching C# for Go. It is simply an engineering team choosing the right tool for a specific job.

Large Companies Helped Test TypeScript 7

Microsoft did not rely only on its internal test suite. According to the official TypeScript 7 announcement, the team worked with companies including Bloomberg, Canva, Figma, Google, Linear, Miro, Notion, Sentry, Slack, Vanta, Vercel, and VoidZero. Internal Microsoft teams such as Loop, Office, Power BI, Teams, and Xbox also tested the compiler against their codebases.

This testing exposed TypeScript 7 to complex monorepos, custom build pipelines, unusual module-resolution patterns, and workloads that are difficult to reproduce with isolated test cases.

The results went beyond controlled benchmarks. Slack reduced type-checking time in CI from approximately 7.5 minutes to 1.25 minutes and reported a 40% reduction in merge-queue time. Canva reduced the time required to display the first editor error from around 58 seconds to 4.8 seconds.

That kind of feedback matters because performance is only useful when the compiler remains stable and compatible under real production workloads.

Should You Upgrade?

The short answer is: yes, but treat it as a major-version migration rather than a drop-in performance patch.

TypeScript 7 is now available through the standard typescript package:

npm install --save-dev typescript@7
npx tsc

The --save-dev flag, which can also be written as -D, records TypeScript 7 as a development dependency. Running npx tsc then uses the version installed locally in the project instead of relying on a global installation.

Core features such as parsing, type checking, JavaScript emission, declaration emission, watch mode, incremental compilation, project references, and the language server are production-ready. However, the move to a native implementation still introduces compatibility considerations. TypeScript 7.0 does not ship with a compiler API, adopts TypeScript 6.0's new defaults and hard deprecations, and includes intentional differences in some JSDoc and JavaScript-specific behaviors.

Projects that use TypeScript mainly through tsc will probably have the easiest migration path. Projects that directly import the TypeScript compiler API, depend on undocumented internals, use custom language-service plugins, or rely heavily on legacy JavaScript and JSDoc behavior will need more careful testing or may need to run TypeScript 6 alongside TypeScript 7 temporarily.

A sensible evaluation process is to:

Run the existing TypeScript 6 build and record its diagnostics, output, execution time, and peak memory usage.
Upgrade the project to TypeScript 7, run npx tsc, and compare the results.
Test watch mode, incremental builds, project references, and declaration generation separately.
Enable TypeScript 7 support in your editor and test navigation, diagnostics, completions, and refactoring workflows.
Keep the TypeScript 6 compatibility package available for tools that still require the old compiler API.

TypeScript 7 is clearly the future of the ecosystem, but a faster compiler is only valuable when it remains compatible with the workflows built around it. Upgrade deliberately, test the requirements of your actual codebase, and keep compatibility tooling where necessary, not simply because the headline says "10x faster."

Final Thoughts

When Microsoft announced Project Corsa, the 10x performance target sounded extremely ambitious. TypeScript 7 has now turned that promise into measurable results: faster builds, lower memory usage, and a more responsive development experience.

The broader lesson is simple. Technologies are tools, not identities, and good engineering means choosing the right one for the job. TypeScript became faster by no longer being written in TypeScript, and there is nothing wrong with that, quite the contrary.

Enjoyed this deep dive? Let's stay connected!

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

HTTP QUERY Is Finally Here: Here's Why It Matters More Than You Think

Giorgi Kobaidze — Sun, 12 Jul 2026 14:51:26 +0000

Introduction
The Long Road From GET to QUERY
- HTTP/0.9
- HTTP/1.0
- HTTP/1.1
The HTTP Semantics That Absolutely Matter
- Safety and Idempotence: The Foundations of HTTP Semantics
- Safety
- Idempotence
- Pizza Explains Everything
- Safety and Idempotence Table (Before QUERY)
Enter HTTP QUERY
- Why Do We Need Another HTTP Method?
- HTTP QUERY for the Win
- How Do Clients Know a Server Supports QUERY?
- Giving a Query a URI
- A Few Things to Watch Out For
Personal Take
- A Step in the Right Direction
- Don't Rush
- GraphQL
Conclusion

Introduction

I've been waiting for this for a long time. Not because HTTP is broken, but because there has always been a subtle but awkward gap in the protocol. A gap that developers have been working around for years, usually by stretching GET a little too far or by reaching for POST even though its semantics never quite fit read-only queries.

Every time I had to squeeze one more filter into a GET request or use POST for something that was obviously just fetching data, a voice in my head kept saying:

"There has to be a better way."

And boy, do we have a better way now... finally!

HTTP QUERY fills that gap.

And this is no longer just an interesting proposal floating around the internet. In June 2026, it was officially published as RFC 10008, an IETF Standards Track document.

Before we get into all of that, let's talk about why this article is worth your precious time.

This isn't going to be one of those articles that simply says, "Here's a new HTTP method," and calls it a day. If we're going to talk about QUERY, we first need to understand why it exists at all. That means taking a step back, looking at the history of HTTP, understanding the semantics behind its methods, and seeing how we even got here.

By the end of this article, you won't just know what QUERY is, you'll understand why adding a brand-new HTTP method was considered a better solution than continuing with the workarounds we've been using for decades.

The Long Road From GET to QUERY

HTTP/0.9

To understand why a new HTTP method like QUERY matters, we first need to understand how HTTP methods came to exist in the first place.

HTTP (Hypertext Transfer Protocol) was created in the early 1990s by Tim Berners-Lee while working at CERN. The original goal was simple: allow computers to exchange documents over the newly created World Wide Web.

The earliest version of HTTP, later known as HTTP/0.9, was extremely minimal and simple. It supported only one operation: retrieving a document.

A client would send a request like:

GET /index.html

The server would respond with the contents of that file. There were no headers, no status codes, and no concept of different operations. The web at that time was essentially a collection of linked documents, so this simple model was enough.

Those were simpler times, weren't they? I wasn't even born back then, so I can only imagine.

But as the web grew, it became much more than a document-sharing system. Websites became applications. Users needed to submit forms, upload data, modify resources, and interact with servers in more complex ways.

HTTP evolved to support these new requirements.

HTTP/1.0

With HTTP/1.0, documented in RFC 1945 in 1996, the protocol introduced a richer request and response model, including status codes, headers, and two new methods alongside GET: HEAD and POST. Interestingly, PUT and DELETE appeared only in an appendix of RFC 1945 as "Additional Request Methods", they weren't part of the core specification yet.

HTTP/1.1

Then HTTP/1.1, standardized through RFC 2068 (1997) and RFC 2616 (1999), formally defined PUT, DELETE, OPTIONS, and TRACE, refined the semantics of all methods, and established principles that still define HTTP today. PATCH arrived later through RFC 5789 in 2010. These core method definitions were later carried forward and polished in RFC 7231 (2014) and consolidated in RFC 9110 "HTTP Semantics" (2022), which remains the authoritative reference for general HTTP semantics.

The HTTP Semantics That Absolutely Matter

If you've ever worked with web development, whether on the back end or the front end, this should already be familiar territory.

However, this article is for everyone, not just web developers. So let's quickly recap the fundamentals.

HTTP Method	The Official "RFC-Speak" Version	The "Explain It Like I'm Human" Version
GET	Retrieve a representation of a resource.	"Hey server, can I have this thing?"
POST	Submit data to be processed by the target resource.	"Here is some data. Process it according to this resource's rules."
PUT	Create or replace a resource at the target URI.	"Here is the complete version of this thing. Save it exactly here."
DELETE	Remove the resource identified by the target URI.	"This thing is no longer needed. Remove it."
HEAD	Same as GET, but the server must not return response content.	"Tell me about this thing, but don't send me the actual thing."
OPTIONS	Describe the communication options available for the target resource.	"Hey server, what can I do here?"
PATCH	Apply partial modifications to a resource.	"I don't need to replace everything, just change this small part."

The important idea is that HTTP methods are not just shortcuts for database operations. They define semantics: what a client is asking the server to do and what guarantees intermediaries can rely on.

Safety and Idempotence: The Foundations of HTTP Semantics

Safety and idempotence are two concepts that should always be taken into consideration when designing APIs. I cannot stress enough how important they are.

API design is not only about making a request succeed or fail. It is about making sure everyone involved: clients, servers, proxies, caches, and automated systems can predict what happens when that request is sent, repeated, or retried.

Safety

Safety means that the client neither requests nor expects a state change to the target resource. GET, HEAD, OPTIONS, and TRACE are considered safe because their defined purposes are retrieval or diagnostics, not changing the target resource.

Technically, you absolutely can change a resource with a GET request. HTTP verbs don't really care what you implement in your back-end.

You could create a GET /users/{id} endpoint that wipes your entire database with a single request, instead of just retrieving the user.

But because you CAN doesn't mean you SHOULD!

The purpose of HTTP method semantics is not to physically prevent developers from doing something. It is to communicate intent and create predictable behavior across the entire ecosystem. Browsers, caches, proxies, crawlers, and other tools rely on the assumption that GET, HEAD, Trace and OPTIONS requests are safe.

So if your application has a GET endpoint whose purpose is to change business state... please stop. Seriously. You can be better than that!

OK, Now Before You Say "Actually..."

Let's address a few important exceptions.

Calling GET a safe method does not mean that absolutely nothing is allowed to change on the server.

In fact, a perfectly valid GET request may still:

Write access logs.
Update analytics or page view counters.
Populate or refresh server-side caches.
Create a user session or issue a session cookie.

However, these are all incidental side effects of serving the request. They support the operation, but they are not the purpose of it.

Check out the diagram below, which illustrates the main flow of a GET request along with some of its possible incidental side effects.

The key idea is that the client is asking to retrieve information, not to modify the application's business state.

In other words, incidental changes to operational state can be acceptable. Making a business-state change the purpose of a safe request is not.

Idempotence

Idempotence means that making the same request multiple times has the same intended effect on the server as making it once. Methods such as GET, HEAD, PUT, DELETE, OPTIONS, and TRACE are idempotent by definition, while POST and PATCH are not guaranteed to be.

Before the "Actually" Squad Arrives Again...

Just like with safety, there are some important exceptions and nuances.

Idempotence does not mean that every repeated request produces the exact same response. The server is allowed to return different responses each time.

For example:

DELETE /users/42

The first request might return:

204 No Content

Because the user was successfully deleted.

The second request might return:

404 Not Found

Because the user no longer exists. (Some might argue that the service should return 204 No Content even when the resource has already been deleted, but that discussion needs a separate article.)

The operation is still considered idempotent because the intended result is the same: after the request completes, the user is gone.

Idempotence also does not mean that the server has no side effects. A repeated PUT or DELETE request may still create logs, update metrics, or trigger internal processing. These are incidental effects, not changes to the intended resource state.

The important question is not:

"Did absolutely nothing happen twice?"

The question is:

"Did repeating the same request produce the same intended state?"

That distinction is what allows HTTP infrastructure to safely retry certain requests when needed.

Pizza Explains Everything

A good pie of pepperoni pizza is the answer to everything in this world. This topic is no exception.

Imagine ordering your favorite pizza.

A safe operation is asking the pizza place: "What pizzas do you have?" You get information, but nobody starts cooking anything.

An idempotent operation is telling them: "Replace my order with one large pepperoni pizza." If your phone accidentally sends the request five times, the result is still one large pepperoni pizza.

In both scenarios, a new entry was created in the receptionist's call log. That's an incidental side effect, the business state is not affected.

A non-idempotent operation is saying:

"Add another pizza to my order."

"Add 10 more pepperoni slices to my pizza." Mamma mia! That's the greatest non-idempotent operation I've ever seen!

...Now I want some pizza.

Safety and Idempotence Table (Before QUERY)

HTTP Method	Safe	Idempotent
GET	Yes	Yes
HEAD	Yes	Yes
OPTIONS	Yes	Yes
TRACE	Yes	Yes
PUT	No	Yes
DELETE	No	Yes
POST	No	No
PATCH	No	No

Enter HTTP QUERY

Why Do We Need Another HTTP Method?

Alright, enough with the prerequisites. Let's finally talk about HTTP QUERY.

As the name suggests, the QUERY method is designed for querying resources... duh.

Imagine you're building a large airport management system. It obviously has a vast number of data points and supports hundreds, if not thousands, of filtering options.

If all you need is the basic information for a specific flight, a simple GET request is exactly the right choice:

GET /flights/BA217 HTTP/1.1
Host: api.airport.example
Accept: application/json

The server might respond with:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=60

{
  "flightNumber": "BA217",
  "origin": "LHR",
  "destination": "IAD",
  "status": "Boarding",
  "gate": "A12"
}

Nothing fancy here. Just a good old HTTP GET request.

Now, let's say you're not looking for one specific flight anymore. You want to build an operations dashboard that shows all flights matching certain conditions.

For example:

Flights departing from London Heathrow (LHR)
Arriving at Washington Dulles (IAD)
Between 6:00 PM and 10:00 PM
Currently delayed
Operated by British Airways
With at least 200 passengers
Sorted by delay duration
Returning only the first 50 results

A GET request might become:

GET /flights?origin=LHR&destination=IAD&departureStart=18:00&departureEnd=22:00&status=delayed&airline=BA&minPassengers=200&sort=delayDuration&page=1&limit=50 HTTP/1.1
Host: api.airport.example
Accept: application/json

This is a very realistic example of what a request like this might look like. At first glance, everything seems perfectly fine, and theoretically, there shouldn't be any issues. And for simple cases, that's absolutely true.

However, things start to change in the real world. Once a query becomes too large or too complex, this approach begins to break down.

There are several reasons for this:

URI length limits are unpredictable: A request can pass through many systems: browsers, proxies, gateways, and servers, each with their own limits. The sender often cannot know the maximum supported size in advance.
Some data is inefficient to encode in a URI: Complex filters, nested conditions, sorting rules, and other structured data become difficult to represent and maintain once everything has to be serialized into a URL.
URIs are more exposed than request bodies: URLs are commonly stored in logs, browser history, analytics tools, and bookmarks, which makes putting large or sensitive query data inside them undesirable.
Every query representation becomes a distinct URI: Different parameter orderings or serializations can create distinct resource identifiers even when they express the same logical query. This can fragment monitoring data and make one logical operation appear as many different request targets.

I actually ran into a similar problem myself years ago while working with an API that required advanced sorting and filtering.

I tried to follow HTTP conventions and use GET, which seemed like the right approach at first. After all, I was only retrieving data, so GET was the obvious choice.

But as the number of filters, sorting options, and query parameters kept growing, the query strings started becoming massive.

Eventually, they got so large that the server basically looked at my request and said: "Nah, I ain't processing that."

And just like everyone else in this situation, I went with the most common workaround.

I am deliberately emphasizing the word workaround here because it is not the same thing as a proper solution. A solution addresses the underlying problem in the way the system was designed to work. A workaround simply gets the job done, but it may come with trade-offs and doesn't necessarily follow the original conventions.

And that workaround? HTTP POST.

Let's talk about why POST isn't the best tool for the job either.

Technically, it works. You can simply put your large, complex query inside the request body of a POST request, process it on the back end, and move on. Easy!

The request would look like the following:

POST /flights/search HTTP/1.1
Host: api.airport.example
Accept: application/json
Content-Type: application/json

{
  "origin": "LHR",
  "destination": "IAD",
  "departureStart": "18:00",
  "departureEnd": "22:00",
  "status": "delayed",
  "airline": "BA",
  "minPassengers": 200,
  "sort": "delayDuration",
  "page": 1,
  "limit": 50
}

But here's the catch. Well, actually, there are several catches.

The first catch is caching

Unlike GET, POST responses are not reusable by caches in the usual way. HTTP does allow a POST response to be cached when it includes explicit freshness information and a Content-Location matching the POST request's target URI, but that cached response can be reused for later GET or HEAD requests, not another equivalent POST request. Most browser caches, CDNs, and proxies do not implement this pattern automatically anyway.

For complex queries, this can be a significant limitation. These requests often involve expensive filtering, sorting, database operations, or aggregations, and caching repeated results can save substantial processing time and improve performance.

Of course, you can implement custom caching on top of POST. However, now you need to solve additional problems yourself, such as creating reliable cache keys, handling invalidation, and ensuring that cached responses correctly match the original request.

Another reason why POST is not an ideal fit for these operations comes down to the semantics of the method itself

Remember what we discussed earlier about HTTP methods? POST is defined as neither safe nor idempotent. It is intended for submitting data to be processed, often resulting in some kind of state change.

A query operation is fundamentally different. When we are retrieving data, we are performing a read-only operation. We generally want it to be safe, repeatable, and compatible with HTTP's caching mechanisms.

The semantics of POST do not provide those guarantees. Along with methods like PATCH, it is simply not the natural semantic fit for this type of operation.

So why is it still commonly used for complex queries? Because POST is widely supported, familiar, and flexible. When developers hit the limitations of GET, POST becomes the obvious workaround, even if it is not the perfect tool for the job.

Think about it

If we can use POST for querying data, why can't we use PUT or DELETE instead? After all, they are idempotent, so on paper they might seem like better candidates.

But that still wouldn't make much sense.

Idempotence alone does not mean a method is suitable for reading data. PUT and DELETE are still designed for operations that modify resource state, replacing or removing resources respectively. They simply guarantee that repeating the same operation produces the same intended result.

POST became the common workaround not because it is the perfect fit, but because it is flexible, widely supported, and allows clients to send complex data in the request body. Over time, using POST for complex queries became such a common pattern that it started feeling natural, even though it doesn't perfectly match the semantics of a read-only operation.

GET with a request body?

Some of you might ask the following question: instead of using POST, why don't we just use GET? After all, the HTTP message format can technically carry content with a GET request, just like it can with POST, right?

Well, yes, at the message-format level, that is possible. But HTTP does not define generally applicable semantics for content in a GET request. In other words, you can send it, but there is no universal agreement about what anyone should do with it.

But as we've already seen several times, theory and real-world behavior are not always the same thing. Reality hits us with a left hook. Many existing systems, including some servers, proxies, and CDNs, do not reliably handle GET request bodies. Some may ignore them, reject them, or just not forward them as expected.

HTTP QUERY for the Win

HTTP QUERY combines the best parts of both worlds. Like GET, it is designed for safe, read-only operations. Like POST, it allows clients to send structured data in the request body. Its responses are cacheable, and the method can be automatically retried after something like a connection failure because repeating it is not supposed to cause business-state changes.

Here's the same example request as we had previously, but now using HTTP QUERY:

QUERY /flights HTTP/1.1
Host: api.airport.example
Accept: application/json
Content-Type: application/json

{
  "origin": "LHR",
  "destination": "IAD",
  "departureStart": "18:00",
  "departureEnd": "22:00",
  "status": "delayed",
  "airline": "BA",
  "minPassengers": 200,
  "sort": "delayDuration",
  "page": 1,
  "limit": 50
}

One important detail here is that QUERY does not invent a universal query language. The body could contain JSON, SQL, JSONPath, form-encoded data, or another format understood by the resource. The request's Content-Type tells the server how to interpret it, and RFC 10008 requires that field to be present and consistent with the content.

Whatever format is used, processing the request must remain safe. Putting a state-changing instruction inside a QUERY body does not magically make that operation safe, it would simply violate the method's semantics.

That also gives servers a clear way to reject invalid requests:

A 4xx response such as 400 Bad Request when the media type is missing.
400 Bad Request when the declared media type is inconsistent with the content.
415 Unsupported Media Type when the resource does not support that query format.
422 Unprocessable Content when the format is valid but the query itself cannot be processed.
406 Not Acceptable when the server cannot produce a response in one of the formats requested through Accept.

Based on these semantics, QUERY is both safe and idempotent, making it a much better fit for complex read operations.

Now, some might argue: instead of introducing an entirely new HTTP method, why not simply update GET and officially allow request bodies?

There are two major reasons why that approach is problematic.

First, GET already has a well-established meaning: retrieving a representation of the resource identified by the request target. A complex query is not always a simple representation of a single resource. It can represent a set of filters, conditions, and operations that produce a result. Expanding GET to cover this use case would make its semantics much less clear.

Second, the existing HTTP ecosystem has been built around the assumption that GET bodies are not meaningful. Many intermediaries, caches, and CDNs were designed with this behavior in mind. Changing that assumption would require significant updates and could introduce unpredictable compatibility issues across the web.

How Do Clients Know a Server Supports QUERY?

You could simply send a QUERY request and see what happens, but HTTP provides a cleaner discovery mechanism.

A client can send an OPTIONS request:

OPTIONS /flights HTTP/1.1
Host: api.airport.example

And the server can respond with:

HTTP/1.1 200 OK
Allow: GET, HEAD, QUERY, OPTIONS
Accept-Query: application/json

Allow tells the client that the resource supports the QUERY method. The new Accept-Query response header goes one step further and advertises the query formats accepted by that resource.

For example, a different resource might support several formats:

Accept-Query: application/jsonpath, application/sql

So clients don't have to blindly guess whether a server expects JSON, SQL, or interpretive dance. The resource can tell them.

Giving a Query a URI

Putting the query in the request body solves the URI-length problem, but it creates another interesting question:

"What if I want to refer to this query or its result later?"

RFC 10008 introduces the concept of an equivalent resource: a resource that represents the combination of the QUERY target, its content, and relevant metadata.

After processing our flight query, the server could respond like this:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Location: /flights/results/17
Location: /flights/queries/42
ETag: "flights-42-1"

{
  "items": [
    {
      "flightNumber": "BA217",
      "origin": "LHR",
      "destination": "IAD",
      "status": "Delayed"
    }
  ]
}

These two location headers look similar, but they describe different things:

Content-Location identifies a resource containing the result that was just returned.
Location identifies the equivalent query resource, allowing the client to repeat the same operation later with a normal GET request instead of resending the query body.

The server is not required to create either resource, and any URI it provides may be temporary. But when it does, clients gain a GET-accessible link that can be cached, shared, or revisited.

A server can also skip returning the result directly and send the client to that GET-accessible resource:

HTTP/1.1 303 See Other
Location: /flights/queries/42

The 303 See Other is important here because it explicitly tells the client to follow the redirect using GET. Other standard redirects, including 301, 302, 307, and 308, preserve the QUERY method for this operation.

A Few Things to Watch Out For

As we discussed earlier, using POST for querying data has become such a common workaround that, at this point, it almost feels natural. Many systems have been built around this pattern for years, and switching from existing POST-based query endpoints to QUERY across an entire ecosystem will require significant effort.

Another thing to be careful about is caching.

With GET requests, caching is relatively straightforward because the request target (URI) already contains the information needed to identify the requested resource. With QUERY, the request body becomes part of what defines the query itself.

That means caching implementations must take the request content and relevant metadata, such as its media type, into account when generating cache keys. Otherwise, two completely different queries sent to the same endpoint could accidentally be treated as the same cached response, which is obviously not something anyone wants.

QUERY also supports conditional requests. A client can send an If-None-Match header with an ETag from an earlier response, and the server can return 304 Not Modified when the selected query result has not changed. So QUERY doesn't merely claim to be cacheable, it can participate in the same validation model we already use with GET.

However, the fact that query content lives in the request body does not make it magically private.

Request URIs are more likely to appear in browser history, access logs, analytics systems, and intermediary logs, so moving complex query content out of the URI can reduce accidental exposure. But request bodies may still be logged, inspected, cached, or stored by your own infrastructure. If a query contains secrets, the correct solution is not to assume the body is invisible.

And if the server generates a Location or Content-Location URI for a sensitive query, that URI should not contain sensitive pieces copied from the original request body. Otherwise, we would move the data out of the URL... only to put it right back there.

There is one more browser-specific detail worth knowing: QUERY is not a CORS-safelisted method. A cross-origin browser request therefore requires a preflight OPTIONS request before the actual QUERY request can be sent.

And outside the browser, API gateways, firewalls, reverse proxies, and server configurations often use explicit method allowlists. Until they are updated, some of them may look at QUERY, raise an eyebrow, and reject it before your application ever sees the request.

Personal Take

A Step in the Right Direction

I really believe this is a step in the right direction.

As someone who values logical design and following conventions, I think conventions exist for a reason: they make our lives easier by making systems more intuitive, predictable, and less confusing.

For years, whenever I needed to implement a complex query endpoint, I usually reached for POST. And while it worked, I always had that annoying voice in my head telling me something was off, because its semantics don't perfectly match the problem we are trying to solve.

A query is a read operation. Ideally, it should be safe, idempotent, and compatible with HTTP's built-in capabilities. The semantics of POST don't provide those guarantees, which is why it always felt like a workaround rather than a perfect fit.

Don't Rush

That said, I wouldn't recommend rushing to replace every existing query endpoint with HTTP QUERY.

Adoption takes time. CDNs, API gateways, proxies, frameworks, libraries, and tooling all need to understand and properly support the new method. Without that ecosystem support, you may simply introduce compatibility problems instead of solving existing ones.

And even when QUERY is fully supported, a normal GET request remains the right choice for simple queries. GET URLs are easy to bookmark, share, paste into a browser, and inspect. If a few query parameters express the request clearly and remain within practical URI limits, there is no problem that needs fixing.

If you're maintaining legacy systems or working with older infrastructure, sticking with the traditional GET and POST approach is probably the practical choice for now. But if you're building something new and your entire stack supports HTTP QUERY, it is absolutely worth considering.

Just like with any new technology, the key is not blindly adopting it, it's understanding the problem it solves, knowing when it fits, and making sure the rest of your ecosystem is ready.

Because, as we've learned throughout this article, these kinds of problems always show up eventually.

GraphQL

One interesting area where HTTP QUERY could potentially make a lot of sense is GraphQL.

I don't know, I'm just thinking out loud.

Today, GraphQL APIs commonly send both query and mutation operations through HTTP POST. And while this works perfectly fine from a practical perspective, using POST for the read-only side has always felt a little strange from a pure HTTP semantics point of view.

After all, a GraphQL query operation is fundamentally a read operation. You are asking the server to retrieve and compose data, not modify anything. Yet we often represent that operation using a method that is not safe, not idempotent, and not naturally cache-friendly.

The reason POST became the standard approach is understandable. GraphQL queries can be large, highly structured documents with variables and nested selections, which makes a request body a natural fit.

However, this is exactly the kind of problem HTTP QUERY was designed to address: sending complex query instructions while preserving the semantics of a safe, idempotent read operation.

To be clear, this would apply only to GraphQL query operations. GraphQL mutations intentionally change state, so representing them with a safe method like QUERY would violate the method's semantics.

Whether GraphQL ecosystems will eventually adopt QUERY remains to be seen, but conceptually, the two technologies seem like a very natural match.

Conclusion

After more than three decades, HTTP is still evolving.

And that's one of the most fascinating things about it. It would be easy to assume that a protocol as fundamental as HTTP is already complete, but real-world usage always finds new challenges.

GET was never designed for massive, complex queries. POST became a common workaround, but it was never a perfect semantic fit either.

HTTP QUERY doesn't replace the methods we already have. It simply fills a gap that has existed for years: a way to send complex queries with a request body while keeping the semantics of a safe and idempotent operation.

It's not just another HTTP method. It's a reminder that even the foundations of the web can continue improving when we find a better way to build.

What are your thoughts about all this?

Enjoyed this deep dive? Let's stay connected!

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

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

171

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

DEV Community: Giorgi Kobaidze

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

Table of Contents

Hotel California

Hands Off the Mouse

Vim Was Never About Typing Speed

The Case for :q!

The Learning Curve is Harder to Justify

AI-First Tools Aren't Built for Modes

The Next Generation May Never Need It

Plot Twist: The Terminal Strikes Back

The Last 10% Is Where Vim Lives

The Editor Might Leave, The Motions Won't

So... :q! or :w?

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

Showtime on the Balcony (Gone Wrong)

A Quick Layover

Why This One Is Personal

Engine #1: The Map That Said No

A Quick Patch on the Tarmac

Pre-Flight Checklist

Engine #2: Where Did All the Birds Go?

The Instrument That Lied

Opening Up the Engine

Silence on the Frequency

Tower, Do You Copy?

Back to the Hangar

Ten Seconds of Doubt

Speaking Fluent Aviation

Looking for a New Engine

Reading the Black Box

Final Approach

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

A Sci-Fi Scenario Come True

Nostalgia Isn't an Argument

The Most Dynamic Era to Be an Engineer

We've Been Here Before

The Hard Part Was Never the Typing

The Bottleneck Moves

Cheaper Software Means More Software

Coding Was Never the Point

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

Table of Contents

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

Some Code Can't Explain Itself

The Code Knows What. Only You Know Why

1. Translates

2. Explains

3. Warns

4. Records

"Just Put It in the Commit Message"

Nobody runs git blame on code that looks fine

Blame decays

People leave

So What's the Worst That Can Happen?

How Not to Write Comments

The echo

The XML doc that says absolutely nothing

The liar

The eternal "temporary" fix.

The graveyard

The novel

Clean Gets You Halfway

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

Let's Address the Elephant in the Room Again

Engineering is Part of Creation

Definitions Matter Here, Critically

Vibe Coding

AI-Assisting

AI-assisted

Where This is Going

What I Actually Do?

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

I Write More Than I Read

The Rules

Why Bother

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

Table of Contents

This Wasn't Supposed to Be the Next Article

What Locking In Actually Means

Nobody runs `git blame` on code that looks fine

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