DEV Community: Vishal Pandey

AI code review just delayed PostgreSQL 19. Finding bugs is now cheap and fixing them isn’t.

Vishal Pandey — Sat, 17 Oct 2026 16:30:43 +0000

PostgreSQL 19 was supposed to ship in October. The release team now says general availability is November 19, with RC 2 on November 12 (postgresql.org’s RC 1 announcement has the dates). The reason is the interesting part.

What happened

According to The Register’s report, developers reverted or pulled between 8 and 10 significant features and pushed them to PostgreSQL 20. Some of them, like SQL/PGQ graph queries, had architectural issues that would have been hard to fix during beta.

LLM-assisted code review also surfaced a long list of defects. The Register cites roughly 40 defect reports, mostly small edge cases that would previously have turned up later, if at all.

It wasn’t “vibe coding”

Peter Eisentraut (EDB, a PostgreSQL committer) was explicit, as relayed by The Register: vibe coding did not cause the reverts, because those tools weren’t available when most of the features were written. The AI didn’t write the bugs. It found them.

One caveat. Independent write-ups argue that AI wasn’t the only cause. Review capacity, and late-cycle review timing, mattered too. Treat “AI found the bugs” as the headline, not the whole story.

The real lesson: the bottleneck moved

Every defect still needs a human to triage it, fix it, test it, and review the fix. Finding bugs got cheap. Fixing them didn’t.

If you maintain a codebase, the practical takeaways are:

Run AI review before you merge, not after. Late findings are expensive. Early findings are cheap.
Keep changes small. A small diff means a small fix.
Verify every fix with tests. AI-suggested fixes still need proof.
What I’m doing about it

I’m biasing toward small, verified commits. I build Vigilante, a free game that turns GitHub-verified commits into a settlement you build. It’s a small nudge toward the habit this story argues for.

Sources: postgresql.org RC 1 announcement; The Register (Oct 16, 2026).

My PixiJS game worked locally and broke in production. The culprit was one CSP word.

Vishal Pandey — Fri, 16 Oct 2026 18:27:49 +0000

Vigilante’s town is a PixiJS 8 scene inside a React 19 and Vite app, hosted on Vercel. Locally it was fine. In production, the settlement scene broke.

The screen became a blank canvas and one console error.

Nothing in the code had changed between the two environments. The page’s security headers had.

Dev and production aren’t the same browser environment

Our production Content Security Policy is set in vercel.json. It’s strict on purpose: scripts only from our own origin and a short list of payment and ad domains, and no 'unsafe-eval'. That blocks eval() and new Function().

npm run dev doesn’t serve those headers. So anything that evaluates code at runtime works locally, and you only find out in production.

Why a renderer needs eval

For speed, PixiJS generates small pieces of JavaScript at runtime, such as the functions that upload shader uniforms, and compiles them with new Function(). It’s a common performance trick, and a strict CSP blocks it.

The fix: one import with a confusing name

PixiJS 8 ships eval-free versions of that generated code. You opt in with a side-effect import before creating the renderer:

// Production CSP has no 'unsafe-eval'; this swaps Pixi's generated
// shader/uniform code for eval-free versions.
import 'pixi.js/unsafe-eval';

Despite the name, this import lets Pixi work without unsafe-eval. We kept the policy strict and fixed the renderer, rather than loosening security for one game scene.

Making sure it can’t come back

A unit test holds both halves in place. It checks that the production CSP still has no 'unsafe-eval', and that the scene file still starts with that import. If someone “cleans up” the odd-looking import, or loosens the policy, the test fails.
Anything that adds a library, worker, canvas or WebGL code, or an external request gets tested as a production build served with the real headers, not just in npm run dev.

Other ways to handle it

Add 'unsafe-eval' to the policy. It’s the easiest option and the worst one: it weakens the whole app to fix one scene.
Serve different headers in dev. It catches this class of bug earlier, but the two drift apart easily.
Test a production build locally with the real headers. That’s what we do now for anything risky.

What the scene is for?

The Pixi scene is a town that your real GitHub work rebuilds. Every verified day drops a crate, and the crates build Lantern District.

Play: https://myvigilante.ocix.in/?utm_source=devto&utm_medium=article&utm_campaign=settlement-autumn-2026&utm_content=devto-2

Have you been caught by a dev/production header mismatch? What broke for you?

I built a browser game where your GitHub pushes will help build a city. Read the Journey and provide your brutally honest feedback

Vishal Pandey — Thu, 15 Oct 2026 20:04:47 +0000

So, I was working on a project called Vigilante (by Ocix) for the last 6-7 months. And now people have started looking into it and actually using it. The numbers are still very low but I feel Reddit will help me to reach this project to all the developers out there.

Problem statement -

For the last year, I have been very serious about building something so that I can survive if AI takes over my job. But whenever I try to build something. I'm just motivated for the initial 5-6 days, and then motivation fades.

I planned to do something for this first.

How I proceed:

Currently, we are at v7 of the application, and it was not like this from the start.8

The first version only had the dashboard and Pomodoro + it charged money if I missed a day.
Response: It doesn't even let people try it. Worst UI and bugs. But it helped me to stick around it.
Second version: I improved the UI a bit, but it was still a dashboard; no one liked it.
Till v5, the same story was repeating: I was improving the font, UI, adding unwanted features, and no one was giving a f*.
In v6, I got the idea of why not to make it a game; this one was completely not my idea at all, but a subtle hint I got from one of my followers. I built it and made it an action game.
Now people are starting to show interest, but a big issue came up as the games are costly. So need to think about the cost also. For some of the fields, I used the image in the background, and that was spoiling the game.
In v7, I figured out what I needed... I was playing a city builder game, and it was so addictive that I played it day and night for 3 days just to complete all its levels. That's when I got the final idea.

It took me a lot of time, but every time I learned a lot.

What does Vigilante even do?

Till now, I told you the story. Now let me tell you what it does.

Log in with GitHub.
Attach the repo you are going to work on.
Create a goal
and you will enter the game.
Every day, whenever you push your commit to GitHub, the game automatically progresses. It's super fun.

Play: https://myvigilante.ocix.in/?utm_source=devto&utm_medium=article&utm_campaign=settlement-autumn-2026&utm_content=devto-2

I turned GitHub pushes into a town-building game, and kept the honest part

Vishal Pandey — Tue, 13 Oct 2026 19:30:06 +0000

Most streak apps trust you. You tap “done,” the number goes up, and nothing checks. On a good day that’s fine. On a bad day, that trust is the problem, because nothing stops you letting yourself off.

I wanted a streak that checks the one thing I can’t fake: whether code reached GitHub.

What it checks, and what it doesn’t

Setup takes about a minute. Connect GitHub, pick a repo, and set a daily commit target.

GitHub sends push notifications. Vigilante uses the push payload: commit IDs, timestamps and file names. Commit messages are stored only if you turn on sharing them. It never requests your code or diffs.

Not every push counts. Merge commits, empty commits, and changes to documentation, lock files or repo config alone don’t count. A day needs at least one other changed file. I drew that line on purpose: a day is “did you ship something real,” not “did you touch a file.”

The honest limit: it can’t tell a thoughtful commit from a typo fix, and it doesn’t try. What it guarantees is that a verified day means code actually reached GitHub.

Why a game on top

Every verified day drops a crate with Materials, XP and a chance of a bonus. Streaks raise the reward: ×1.2 at 3 days, ×1.5 at 7 and up.

You spend Materials on a settlement called Lantern District, which has six buildings with five levels each. Survivors move in as you upgrade. The game is a ledger for the streak: when you miss a day, the salvage pauses and the town goes quiet, so the gap is something you can see. Revival Fluid can repair one missed day.

Design decisions
Only verified work makes progress. Logging in, tapping, or watching anything grants nothing. That rule is in the code, not just the copy.
Store as little as possible. The app keeps counts. Commit text is kept only with consent. Deleting an account removes its data and keeps one anonymous row of totals.
Try it

Play: https://myvigilante.ocix.in/?utm_source=devto&utm_medium=article&utm_campaign=settlement-autumn-2026&utm_content=devto-1

If you’d rather not connect GitHub yet, the free check-up needs no sign-up: https://vigilante.ocix.in/audit

What’s the one signal you’d trust in a streak tool? I’d like to know what you’d check first.

Is it relatable to you too?

Vishal Pandey — Sun, 11 Oct 2026 12:45:54 +0000

I built a game that only grows when you push real GitHub commits. Roast it?

Vishal Pandey — Tue, 06 Oct 2026 21:04:09 +0000

I'm the solo dev behind this, so take my enthusiasm with salt.

My problem: I start side projects and quietly drop them around week three. So I built Vigilante, a free game where you connect one repo, and your settlement only grows when you push verified work. No push, no daily supply crate.

How it works, briefly:

You connect a single GitHub repo. It never clones the repo or reads your source, private diffs, or credentials. It only sees push signals.
Verified pushes earn daily supplies that build six buildings (Lantern House, Salvage Yard, and so on).
Streaks give bonuses, and there's one "mend a missed day" item a month so a bad day doesn't wreck everything.
There's a story campaign, plus a daily share card if you want to show your progress.

It's free to start. There's also a free GitHub check-up that audits your repo's recent activity with no signup, in case you only want that.

What I'd like to know:

Does "game progress tied to real commits" feel motivating, or gimmicky?
What would make you stop using it after day 3?
Is "it doesn't read your code" enough to make you comfortable connecting a repo?

Link: https://vigilante.ocix.in

Happy to answer anything, including "why does this exist."

Your Side Project Died Because You Stopped Pushing Code (The 72-Hour Rule)

Vishal Pandey — Sun, 19 Jul 2026 17:22:22 +0000

We’ve all been there.

You get a burst of inspiration late on a Friday night. You purchase the domain, bootstrap the repo, configure your Tailwind variables, and write 800 lines of beautiful, clean code. You go to sleep feeling like a future startup founder.

Fast forward three weeks: the repository has been silent for 15 days, the domain is sitting unused, and you’re already thinking about a new project.

Why does this happen?

It’s not because your idea was bad, and it's not because you ran out of time.

It’s because you broke the 72-Hour Rule of momentum.

The Anatomy of a Abandoned Repo

Momentum in software development behaves like a heavy flywheel. It takes immense energy to start spinning, but once it's moving, it carries itself.

However, developer momentum decays exponentially. The moment you stop pushing code:

Day 1 offline: You still remember the context. You know what function to write next.
Day 2 offline: You start losing the mental map. Re-starting requires a minor effort.
Day 3 offline: Cognitive friction sets in. You have to spend 15 minutes reading your own code just to remember what you were doing.
Day 4+ offline: The project is dead. The thought of opening the code feels like a chore, so you avoid it.

If your inactive gaps stretch past 72 hours, the probability of abandoning your side project increases by over 80%.

The Audit: Look at the Mirror

Before you promise yourself that "this time will be different," you need to look at your actual baseline.

A lot of developers think they are consistent because they commit code in massive, 12-hour weekend sessions once every two weeks. But that is the programming equivalent of crash dieting. It doesn't build the habit.

I wanted a way to visualize my own shipping gaps without looking at the cluttered GitHub heatmap (which hides inactive gaps behind total contribution counts).

So, I built a free, zero-signup utility called Vigilante Audit. It scans your public GitHub profile and extracts three simple metrics from the last 30 days:

Active Days: Out of 30, how many days did you make a meaningful commit?
Longest Streak: Your consecutive coding run.
Longest Inactive Gap: The silent periods where momentum died.

Here is what the dashboard looks like when you run it:

You can run it for free on your username in 5 seconds:
👉 vigilante.ocix.in/audit

How to Fix Your Rhythm (The No-Zero-Commit Protocol)

If your audit shows a high "Longest Gap" (e.g., 5+ days), your main focus shouldn't be writing more code. It should be narrowing the gaps.

Here is how you do it:

Establish a Daily Minimum Quota: Commit to making just one meaningful line change per day. Even if it's just fixing a typo, renaming a confusing variable, or adding a single unit test.
Automate Accountability: Don't rely on self-discipline. Use a tool like Vigilante to link your repository. It automatically monitors your commits via webhooks. If you miss a day, your streak resets, and you face a virtual penalty.
Protect Your Streaks: Use streak freezes on days you genuinely need a rest. Rest is fine; silent, unexcused gaps are what kill momentum.

Stop trying to code for 4 hours a day. Start by coding for 10 minutes a day, every single day.

Go run your audit, see your reality, and drop your score in the comments below. Let's see who has the lowest "inactive gap" this month!