Is it just the novice in me that finds the Haskell community's misguided obsession over character count really annoying? Learn You a Haskell For Greater Good states

> Shorter code means less bugs

A lot of people and resources seem to share this opinion, but it's obviously false. Simpler code means less bugs, but look at this function which just means "apply this applicative to each element of a list"

> sequence :: (Applicative f) => [f a] -> f [a]
> sequence = foldr (liftA2 (:)) (pure [])

This isn't "less buggy", it's fucking madness. The same in JS, the king of unreadable languages, would be:

function sequence(seq, val, apply = (f, x) => f(x)) {
seq.map(f => apply(f, val))
}

Seriously, how can you design a strictly typed language that gets beaten by JS in readability?

Job offer listing: "IT Specialist"

"Personality prerequisites and skills"
- "Programming in MS Excel"

How do you even put programming and excel in one sentence??!!
HOW IS THAT EVEN POSSIBLE???

So to give you a feel for what evil, clusterfuck code it was in: this projects largest part was coded by a maniac, witty physicist confined in the factory for a month, intended as a 'provisional' solution of course it ran for years. The style was like C with a bit of classes.. and a big chunk of shared memory as a global mud of storage, communication and catastrophe. Optimistic or no locking of the memory between process barriers, arrays with self implemented boundary checks that would give you the zeroth element on failure and write an error log of which there were often dozens in the log. But if that sounds terrifying already, it is only baseline uneasyness which was largely surpassed by the shear mass of code, special units, undocumented madness. And I had like three month to write a simulator of the physical factory and sensors to feed that behemoth with the 'right' inputs. Still I don't know how I stood it through, but I resigned little time afterwards.

Well, lastly to the bug: there was some central map in that shared memory that hold like view of the central customer data. And somehow - maybe not that surprisingly giving the surrounding codebase - it sometimes got corrupted. Once in a month or two times a day. Tried to put in logging, more checks - but never really could pinpoint the problem... Till today I still get the haunting feeling of a luring memory corruption beneath my feet, if I get closer to the metal core of pure C.

🚀 “I Wanted GitHub Copilot in My Pocket — So I Built It Myself”

For years, I’ve had this weird habit of coding from random places — cafés, buses, hospital waiting rooms, you name it. But every time inspiration hit, I found myself thinking the same thing:

“Man, I wish I could just use Copilot on my phone.”

It’s 2025. We’ve got AI writing novels, generating music, and summarizing 500-page research papers in 2 seconds — yet somehow, GitHub Copilot still refuses to leave the comfort of VS Code on desktop.

So I decided to fix that.

💡 The Idea

It started as frustration — a “wouldn’t it be cool if” moment. I was halfway through an idea for a small project on a train, and my brain screamed:

“Why can’t I just ask Copilot to finish this function right now?”

VS Code was sitting at home, my laptop was dead, and all I had was my phone.

That night, I scribbled this into my notes app:

“Bridge Copilot from VS Code → phone → secure channel → no cloud.”

At the time, it sounded insane. Who even wants to make their life harder by reverse-engineering Copilot responses and piping them into React Native?
Apparently — me.

🧩 The Architecture (aka “How to Lose Sleep in 4 Easy Steps”)

The system ended up like this:

VS Code Extension <-> WebSocket <-> Discovery API (Go + Redis) <-> React Native App

Here’s how it works:

The VS Code extension runs locally, listening to Copilot’s output stream.

A Go backend acts as a matchmaker — helping my phone and PC find each other securely.

The mobile app connects via WebSocket and authenticates with a 6-digit pairing code.

Once paired, they talk directly. No repo data leaves your machine.

It’s like a tiny encrypted tunnel between your phone and VS Code — only it’s not VPN magic, just some careful WebSocket dancing and token rotation.

🛠️ The Stack

Frontend (Mobile): React Native (Expo)

Backend: Go + Redis for connection brokering

VS Code Extension: TypeScript

Security: JWT + rotating session keys

AI Layer: GitHub Copilot (local interface)

🧠 The Challenges

There’s a difference between an “idea” and a “12-hour debugging nightmare that makes you question your life choices.”

Cross-Network Discovery:
How to connect phone and desktop on different networks?
→ A lightweight Redis broker that just handles handshakes.

Security:
I wasn’t making a mini TeamViewer for hackers.
→ Added expiring pairing codes, user-approval dialogs, and local-only token storage.

Copilot Response Streaming:
Copilot doesn’t have a nice public API.
→ Hooked into VS Code’s Copilot output and streamed it over WebSocket.
(Yes, 2% genius and 98% madness.)

UX:
The first version had a 10-second delay.
After optimizing WebSocket batching and Redis latency, it’s now near-instant.

🤯 The “Holy Sh*t, It Works” Moment

The first time my phone sent a prompt — and my VS Code actually answered with Copilot’s suggestion — I legit screamed.

Like, full-on victory dance in the middle of the night.
There’s something surreal about watching your phone chat with your desktop like they’re old coding buddies.

Now I can literally say:

“Copilot, write me a REST API,”
and my phone responds with fully generated code pulled from my local VS Code instance.

No VPN. No cloud syncing. Just pure, geeky magic.

⚡ The Lessons

The hardest problems aren’t technical — they’re psychological.
Fighting “this is impossible” is the real challenge.

Speed matters more than perfection.
Devs don’t want beauty; they want responsiveness. Anything over 1s feels broken.

Security must never be an afterthought.
I treated this like a bank tunnel between devices, not a toy.

Build for yourself first.
I didn’t make this for investors or glory — I made it because I wanted it.
That’s the best reason to build anything.

🧭 The Future

Now that it’s working, I’m turning this experiment into something shareable.
The dream: an app that lets every developer carry Copilot wherever they go — safely and instantly.

Imagine debugging on your couch, or editing code in bed, or just whispering to your AI assistant while waiting for coffee.

Phones today are more powerful than early NASA computers.
Why shouldn’t they also be your code editor sidekick?

So yeah, that’s my story.
I built VSCoder Copilot — because I wanted to code from anywhere, and I refused to wait for permission.

If you’ve ever built something just to scratch your own itch, you already know this feeling.
That mix of frustration, caffeine, and late-night triumph that reminds you why you fell in love with coding in the first place.

Because at the end of the day, that’s what we do:
We make ideas real — one ridiculous hack at a time. 💻🔥