DEV Community: Mohit ✨

Write Once. Publish Everywhere. Without Surrendering Control.

Mohit ✨ — Sun, 01 Mar 2026 14:04:47 +0000

This is a submission for the DEV Weekend Challenge: Community.

Why I Built This (And How)

I didn’t start this project with a prompt.

I started with a problem.

I write technical posts regularly. I genuinely enjoy the writing part.

What I don’t enjoy is rewriting the same idea four different ways for four different platforms.

DEV → X → LinkedIn → Reddit → Substack.

Same thinking. Different tone. Different format. Different constraints.

That friction slowly turns “sharing your work” into overhead.

So before I wrote a single line of code, I wrote:

a short spec
a high-level PRD
clear scope boundaries (what ships vs what doesn’t)

Only then did I bring in AI.

ContentSeed was built for a community I’m part of every day: developer-writers — people who want to publish consistently without spending more time repackaging than creating.

This project is fully solo.

And intentionally disciplined.

The goal wasn’t to build “an AI app.”

The goal was to build a small, focused tool that:

respects privacy
stays client-side
lets you switch between LLMs
solves one real pain point well

What I Built

ContentSeed is a client-side content repurposing app that turns one technical post into platform-native drafts for:

X / Twitter (thread-style)
LinkedIn
Reddit
Substack

Demo

YouTube demo:

Live app:

https://contentseed.vercel.app

GitHub:

https://github.com/mohitSharma74/contentseed

Core Principles

1) Easy and Accessible

Paste content → pick platform → generate → tweak → export.

No accounts.

No dashboards.

No friction.

2) Privacy-First

There is no backend.

No telemetry.

If you bring your own API key, it stays local.

3) Model Freedom

You’re not locked into one provider. You can generate using:

Minimax
OpenAI
Anthropic
Gemini

Use what you already pay for.

AI as Collaborator, Not Crutch

I care deeply about how AI is used.

For this project, I didn’t “vibe code.”

I wrote the spec and high-level PRD first.

Then:

I used Minimax M2.5 for the majority of implementation.
I used gpt-5.3-codex (high reasoning) for:
- validation
- edge-case analysis
- testing logic
- architectural review

I intentionally separated:

generation from validation
speed from correctness
features from product clarity

That separation mattered.

It kept the app:

fully client-side
privacy-first
small in scope
focused

There were features I wanted badly — image generation, short-form video generation — but they didn’t make the cut.

Not because they weren’t exciting.

Because they weren’t essential.

What It Can Do Today

Platform-native drafts (not copy/paste spam)
Demo mode (no API key required)
Tone controls: Casual / Professional / Technical / Storytelling
Length controls: Shorter / Default / Longer
Toggle hashtags and emojis
Copy / regenerate per platform
Export as PNG, JPG, or PDF

A Small Tool. On Purpose.

ContentSeed is not trying to become a content platform.

It’s not a dashboard.
It’s not a growth engine.
It’s not a subscription funnel.

It’s a utility.

It exists to remove one specific kind of friction:
rewriting the same idea for different platforms.

It stays client-side.
It stays privacy-first.
It stays model-agnostic.

If it grows, it will grow deliberately.

For now, it does one thing well.

And that’s enough.

🗓️ Monthly Dev Report: February 2026

Mohit ✨ — Sat, 28 Feb 2026 15:01:32 +0000

This is my first dev diary folks, and I'd wanna continue this every month. So you are all welcome to discover stuff with me! (:

So February was… dense.

Not the “I did a lot of meetings” dense.

More like: shipping, learning, writing, and somehow returning to a sport after 8 years kind of dense 🏓

Here’s the report 👇

🎯 Post Highlights (what I enjoyed reading)

1) Stop Ignoring RFC 2324 ☕🫖

A reminder that sometimes the “joke” spec is secretly a great engineering exercise.

Why it stuck:

It’s playful, but it forces real systems thinking
It’s a nice excuse to build something end-to-end without “business requirements”
Also… teapots deserve respect 😄

Link: https://dev.to/pascal_cescato_692b7a8a20/stop-ignoring-rfc-2324-its-the-most-important-protocol-youve-never-implemented-53pe

2) How AI is reducing clinician burnout 🏥🤖

This one treats AI like it should be treated: as a workload reducer, not a hype machine.

The framing is practical:

less documentation pain
faster note drafting + review
less “after-hours admin time”

Link: https://dev.to/vaiu-ai/how-ai-is-reducing-clinician-burnout-in-modern-clinics-44hb

3) A recovery guide for AI-dependent coders 🧠🛠️

If you’ve ever felt your brain go “wait… can I still code without the assistant?” — this one hits.

It’s basically a gentle reset:

slow down
read docs
think first, prompt second

Link: http://dev.to/canro91/a-quick-recovery-guide-for-ai-dependent-coders-4112

🔎 Monthly Discoveries (open source I tried / want to try)

nullclaw ⚡

Feels like someone asked:

“What if autonomous agent infra was small, fast, and not a giant platform?”

Repo: https://github.com/nullclaw/nullclaw

llmfit 🧩

A “reality checker” tool I respect: tells you what models can run on your machine without guesswork.

Repo: https://github.com/AlexsJones/llmfit

osaurus 🦖

Positioned as “AI edge infrastructure for macOS” with tooling/interop vibes.

Repo: https://github.com/osaurus-ai/osaurus

✅ Accomplishments (the “I actually did things” list)

1) Shipped two products for the GitHub Copilot Challenge 🚢

This was the biggest win of the month.

VoiceDev — voice-controlled dev workflows (not just dictation).

Repo: https://github.com/mohitSharma74/voicedev
Ukiyo-tone — theme bundle inspired by 17th-century Japanese aesthetics.

Repo: https://github.com/mohitSharma74/ukiyo-tone

Two very different products.

Same underlying obsession: reduce friction.

2) Learned Zig the old-fashioned way 🧠⚙️

No shortcuts. No “I skimmed tutorials.”

I actually put in the reps — and I’m feeling genuinely confident about Zig now.

(That confidence is rare. So I’m counting it as a real milestone.)

3) Started shaping the future of Ukiyo-tone ✨

I can’t share everything yet (and I kinda like it that way 😄), but:

Ukiyo-tone is not “done.” It’s becoming.

Stay tuned.

4) Stayed consistent with writing + research ✍️

Even with professional work being heavy, I kept the flywheel going:

learning
researching
publishing / drafting
showing up anyway

Consistency is the real flex.

5) Returned to table tennis after 8 years 🏓💚

This might be the most important one.

Coding is great. Shipping is great.

But nothing rewires your brain like moving your body again.

🧱 Still working on…

Ukiyo-tone (still cooking 🍲)
This weekend sprint challenge: DEV Weekend Challenge (submissions due March 2, 2026 7:59am UTC) Link: https://dev.to/devteam/first-dev-weekend-challenge-launches-on-feb-26-mar-2-mark-your-calendar-5dc3
Open source contributions to projects like OpenCode + nullclaw (slow and steady)

💚 Life Stuff

Todoist: “Ramble” is actually good 🎙️✅

Todoist shipped Ramble, a voice-to-tasks feature where you speak naturally and it turns it into structured tasks.

And honestly? It’s been working flawlessly for me so far.

This is exactly the kind of productivity feature I like:

reduces friction
makes capture instant
doesn’t demand “perfect organization” upfront

Anime arc: I started with Demon Slayer + My Hero Academia 🍿🔥

I’ve never watched anime before.

Now I get it.

I’m hooked already 😅

Gaming: Cronos: The New Dawn 😈🎮

I started playing Cronos: The New Dawn and I’m loving every minute of it.

Just curious: Do you watch Anime? Do you play Video Games? Suggest me some 'coz honestly these are my stress busters.

Happy Weekends, friends!

The 5 Future-Proof Language + Framework Combos Crushing It Right Now 🔥

Mohit ✨ — Thu, 19 Feb 2026 14:07:02 +0000

Whether you're a college student, upskilling on weekends, or looking to contribute to open source — you want to move fast. You want to hit the ground running.

Software development is changing faster than ever. And none of us can afford to get left behind.

That's why I went through TIOBE, GitHub Octoverse, Reddit, and X to figure out which language and framework combos aren't just trending — they're here to stay. Backed by community sentiment, real adoption data, and what developers are actually shipping with right now.

Honestly? The range surprised me. AI tooling. Enterprise backends. Cloud infrastructure. Systems programming. Mobile. One list, every layer of the stack.

Here's what's worth your time in 2026.

🃏 1. Python + FastAPI

The AI builder's default stack.

Python was already everywhere. FastAPI made it unstoppable. If you're building anything that touches AI or ML — an inference endpoint, a data pipeline, a tool that wraps a model — this is the combo you reach for first. It's fast to start, auto-generates docs, and plays natively with the entire Python AI ecosystem. I've used this stack myself and the speed from idea to working API is genuinely ridiculous.

Django still holds the enterprise web lane. But FastAPI is where the energy is right now.

Community Sentiment: "FastAPI is what modern Python API development should look like" — the most repeated sentiment across Reddit's r/Python and r/FastAPI. GitHub Octoverse shows a 38% adoption surge. Devs call it "the most loved Python framework right now."

🃏 2. TypeScript + Next.js

The full-stack web default.

TypeScript is no longer a preference — it's the default. And Next.js is what happens when React grows up and gets serious about production. Server components, API routes, edge functions — it handles the hard stuff so you can focus on building. High job demand, dominant in SaaS, and the framework Vercel, Notion, and Twitch's web team trust.

If you're entering the job market or building a web product in 2025, this combo is the safest bet and the highest signal on a resume.

Community Sentiment: "TypeScript is non-negotiable at this point" — consistent across X dev threads and Stack Overflow surveys. Reddit's r/nextjs is one of the fastest growing dev communities. Devs describe Next.js as "production-ready out of the box."

🃏 3. Go + Gin / Fiber

The cloud-native backbone.

Kubernetes is written in Go. Docker is written in Go. When the tools that run modern infrastructure needed a language, they picked Go. Fast, readable, no runtime surprises — Gin and Fiber give you a clean web layer on top of that reliability. Fiber in particular benchmarks impressively, handling more requests per second than most Node alternatives at a fraction of the memory.

For microservices, CLIs, or anything cloud-adjacent — Go is the answer that keeps coming up.

Community Sentiment: "Go is boring in the best possible way" — a phrase that shows up repeatedly on r/golang and X. GitHub Octoverse consistently ranks Go in top growing languages. Cloud engineers describe it as "the language that just ships."

🃏 4. Rust + Axum / Actix

The safety-first power move.

Rust has been Stack Overflow's most admired language for years running. That's not hype — devs who use it don't want to go back. Memory safety without a garbage collector, zero-cost abstractions, and performance that makes C developers pay attention. Axum is the modern async choice. Actix is the raw performance beast.

What's changing now is where Rust is showing up — security tooling, WebAssembly, AI infrastructure, embedded systems. It's not theoretical anymore. Discord rewrote parts of their backend from Go to Rust for performance. Cloudflare builds with it. npm runs on it.

Community Sentiment: "Rust doesn't let you write bad code — it forces you to think" — the dominant take across r/rust and X systems programming circles. TIOBE shows steady climb. Devs call it "the language worth the learning curve."

🃏 5. Java / Kotlin + Spring Boot

Enterprise's quiet giant.

Java isn't exciting. It's dependable. And in the kind of environments where downtime costs real money — banking, healthcare, large-scale enterprise — dependable beats exciting every time. Spring Boot is the framework that runs a significant chunk of backend infrastructure that most people never see but always rely on.

Kotlin is what makes this combo feel alive again. Cleaner syntax, fully interoperable with Java, and increasingly the language of choice for Android-to-backend developers. Spring Boot with Kotlin doesn't feel like Java. It feels like a modern backend language with decades of battle-testing behind it.

Community Sentiment: "Not glamorous, but Spring Boot jobs don't disappear" — the honest consensus on r/java and enterprise dev forums. TIOBE keeps Java in the top 5 consistently. Devs describe the ecosystem as "stable, serious, and always hiring."

⚡ Worth Watching — Honourable Mentions

Kotlin + Ktor — Lightweight, Kotlin-native, and the go-to for devs migrating from Android into backend. Spring Boot without the overhead.

Swift + Vapor — Apple's ecosystem pays well and Swift is genuinely fast and safe. Vapor brings it server-side. If you're building iOS and want your backend in the same language — this is your path.

Zig + Native Tooling — The no-nonsense C replacement quietly gaining ground in systems and embedded circles. Niche right now. Watch it closely as hardware tooling heats up into 2026.

The Takeaway

What hit me putting this together wasn't which combo is "best."

It was the range. AI tooling to enterprise banking to cloud infrastructure to mobile to systems programming — these aren't competing stacks. They're different tools for different builders solving different problems.

There's something on this list for you — whether you're picking your first stack, switching lanes, or doubling down on where you already are.

Learn one properly. Build something real with it.

More From Me

If you enjoyed this, check out my similar blogposts 👇🏼:

I write about AI tools, developer workflows, and who gets power when technology becomes accessible.

The Most Important Tool in Your Dev Stack Is One You've Never Heard Of

Mohit ✨ — Sun, 15 Feb 2026 05:01:17 +0000

You've seen it. That little spinning icon in the VS Code status bar. "Initializing JS/TS language features..." followed by some loading animation while your editor "thinks."

I always noticed it. Every time I opened a TypeScript project, there it was — indexing, loading, doing something behind the scenes.

I never questioned it. Just waited for it to finish and got back to work.

Then one day I actually looked into what was happening behind that loading icon. And what I found changed how I think about every code editor, every AI coding tool, and honestly — the entire developer tools ecosystem.

That little icon? It's the most important thing in your editor. And it has nothing to do with VS Code.

The Feature You Think VS Code Built

Hover over a function and see its type signature. Ctrl+click to jump to a definition. Rename a symbol across your entire codebase.

These feel like VS Code features. They feel built into the editor.

They're not.

Every single one of those — hover info, go-to-definition, auto-completions, error squiggles, rename refactoring — comes from a separate program running in the background. For TypeScript, that program is called tsserver. It's a language server. And it talks to VS Code through a protocol called LSP — the Language Server Protocol.

VS Code is just the messenger. The intelligence lives elsewhere.

That loading icon I kept seeing? That was tsserver booting up, parsing my entire project, building a map of every type, every function, every connection in my codebase. VS Code was just... waiting for it.

Before LSP: The Dark Ages Nobody Talks About

Here's the thing most developers don't realize — before 2016, none of this existed as a standard.

If you wanted smart code features in your editor, the editor itself had to understand your programming language. Every editor. From scratch. Separately.

Think about what that means.

Want TypeScript support in Vim? Someone had to build TypeScript intelligence specifically for Vim. Want it in Sublime Text? Build it again. Eclipse? Again. Atom? Again.

Every editor team was solving the same problem independently. Every language community was doing the same work five, ten, fifteen times over for different editors.

The result was predictable. Most editors had mediocre language support. A few editors had great support for a few languages. And developers were locked into editors based on which ones happened to have decent tooling for their stack.

It was a mess. A slow, fragmented, duplicated mess.

The HTTP Moment

In 2016, Microsoft introduced LSP. And honestly, this is the part that doesn't get enough credit.

The idea was almost embarrassingly simple: separate the editor from the language intelligence.

Let the editor handle what editors are good at — showing text, managing tabs, rendering UI. Let language-specific intelligence run in its own server. Then define a standard protocol for them to talk to each other.

Editor says: "Hey, the user is hovering over line 42, column 15. What's there?"

Language server responds: "That's a function called processOrder that takes a CartItem[] and returns a Promise<OrderResult>."

That's it. JSON messages over a standard protocol. The editor doesn't need to know TypeScript. The language server doesn't need to know what editor you're using.

This is why I call it the HTTP moment for code editors.

Think about what HTTP did for the web. Before HTTP, if you wanted to access information on a network, you needed specific client software for specific servers. HTTP separated the browser from the server. Suddenly any browser could talk to any server. The web exploded.

LSP did the same thing for developer tools.

Build one language server for Python, and it works in VS Code, Neovim, Helix, Sublime, Emacs — everywhere. Build one editor with LSP support, and it instantly gets intelligence for every language that has a server.

One protocol. The entire ecosystem unlocked.

The Love Story That Built an Empire

Now here's where it gets interesting.

TypeScript's language server, tsserver, wasn't just any language server. It was arguably the most sophisticated one ever built. And VS Code wasn't just any editor — it was built by the same company, Microsoft, specifically designed to be a thin, fast LSP client.

This pairing was intentional. And it was devastating for the competition.

When you opened a TypeScript project in VS Code, the experience was magical. Instant type information. Intelligent auto-imports. Refactoring that actually worked across files. Error detection before you even saved.

None of this was VS Code being clever. It was tsserver being brilliant, and VS Code being the perfect lightweight client for it.

But here's the beautiful part — because it was all LSP, that same tsserver intelligence worked in Neovim. In Helix. In any editor that spoke the protocol. VS Code just happened to be the smoothest client for it.

That's how VS Code won the editor wars. Not by building the best editor. By being the best client for the best language servers.

The Plot Twist Nobody Saw Coming

Fast forward to today. AI coding tools are everywhere. Cursor, Continue, GitHub Copilot, Cody, Windsurf — every month there's a new one promising to revolutionize how you write code.

Want to know what they all have in common?

They're LSP clients. Advanced ones, sure. But LSP clients nonetheless.

When Cursor's AI suggests a refactoring, it doesn't magically "understand" your codebase by reading files. It sends LSP requests — the same requests VS Code sends — to get type information, symbol references, diagnostics. It feeds that structured context to an LLM, which generates smarter suggestions.

The AI didn't replace LSP. It built on top of it.

Think about that for a second. The protocol designed in 2016 to let editors talk to language servers is now the backbone feeding context to AI models. Language servers provide the structured understanding — types, references, errors, symbols — that makes AI coding tools actually useful instead of just autocomplete on steroids.

LSP didn't just survive the AI wave. It became the foundation the wave is built on.

The Quiet Revolution

Honestly, this is what gets me.

We talk endlessly about which AI coding tool is best. Which LLM writes better code. Whether agents will replace developers.

But underneath all of that noise, there's a nine-year-old JSON-RPC protocol quietly doing the actual work. Making sure your AI tool understands that user on line 47 is the same user defined on line 12. That renaming a function here doesn't break an import there. That the type signature your agent needs to make a smart suggestion is available in milliseconds.

Code intelligence became open, composable infrastructure. Not locked inside any one editor. Not owned by any one company. A shared foundation that editors, plugins, and now AI agents all build on equally.

A freelance developer in Lagos using Neovim gets the same TypeScript intelligence as a staff engineer at Google using VS Code. A brand new AI startup gets the same structured code understanding that GitHub Copilot does.

That's what LSP actually did. It didn't just connect editors to language servers. It made code intelligence a public utility.

So next time your editor magically understands your code, or your AI agent suggests a refactoring that actually works — look for that little loading icon in the status bar. Thank a 2016 protocol that quietly became the HTTP of developer tools.

That's exactly what I'd like you to take away from this article.

The most transformative infrastructure isn't the kind that makes headlines. It's the kind that disappears into the background — so invisible, so reliable, that you forget it exists. Until you realize everything you depend on was built on top of it.

That, My Friend, is the Language Server Protocol, The unsung Hero that nobody talks about.

More From Me

If you enjoyed this, check out my GitHub Copilot Competition submissions — two projects where I pushed the boundaries of what developer tools can do:

I write about AI tools, developer workflows, and who gets power when technology becomes accessible.

I Built a Voice-Controlled IDE in 16 Days. My Voice Is Now My Editor.

Mohit ✨ — Tue, 10 Feb 2026 07:54:55 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

I built VoiceDev — a VS Code extension that lets you control your entire development workflow with your voice. Not just dictation. Real workflows. Git commits, file navigation, Copilot CLI queries, all of it — spoken.

It started with a simple question I kept asking myself: What if I could be even more productive?

I was tired of hunting down VS Code shortcuts. Tired of configuring keybindings just to do something simple. Tired of dictation tools that let you talk at your editor but never to it.

I wanted more.

I wanted to say "git commit message fixed the auth bug" and have it just... happen. No terminal. No command palette. No twelve-step shortcut sequence I'd forget by next week.

🗣️ "git status" → "git commit message fixed the auth bug" → "git push"

A full commit cycle. Just my voice.

🗣️ "open file server.ts" → "go to line 42" → "format document" → "save all"

Navigate, edit, save. Spoken.

🗣️ "ask copilot explain this file" → "copilot commit"

AI-assisted development, triggered by voice.

Here's the thing — I originally wanted to build a standalone voice app. But I spend most of my waking hours inside my IDE. I never want to leave it. So why would I build something that lives outside the place where I actually work?

That's how VoiceDev became a VS Code extension instead.

More Than Dictation

Most voice tools for developers are glorified speech-to-text. You talk, text appears. That's it.

VoiceDev is different. It understands intent.

Say "format the document" and it triggers format-document even though the wording isn't exact. Fuzzy matching with confidence scoring. If VoiceDev isn't sure what you meant, it falls back to dictation instead of guessing wrong. Nine commands support wildcard patterns — say "git commit message fixed the auth bug" and it extracts "fixed the auth bug" as your commit message.

Development using voice is always faster than typing. Voice lets you map your raw thoughts directly into action. No translation layer. No "let me remember the shortcut for that." Just think it, say it, done.

Privacy and Saving Money

Honestly? I'm tired of paying for things that should be free.

Privacy and saving money — that's the core philosophy of VoiceDev. Your voice, your rules.

Want speed? Use Groq or Voxtral (Mistral) — both blazing fast, both free tier.

Want your voice to never leave your machine? Switch to Local mode. It runs via faster-whisper, fully offline. Zero API keys. Zero cost. Unlimited usage. Your audio stays on your hardware.

That choice matters. A developer in a startup who can't expense API keys should still have voice-native workflows. A freelancer working from a cafe on public WiFi shouldn't have to stream their voice to the cloud. A developer who just values their privacy shouldn't have to compromise on features.

VoiceDev gives you cloud speed or local privacy. Always your choice.

Safety, Because Voice Is Powerful

Force push is blocked. Git push requires confirmation. VoiceDev doesn't guess on destructive commands.

When you give your voice the power to control your editor, you better make sure it can't blow things up by accident.

Demo

🔗 GitHub Repository: github.com/mohitSharma74/voicedev

🎨 Install from VS Code Marketplace: VoiceDev (Preview)

🎥 Watch VoiceDev in Action:

My Experience with GitHub Copilot CLI

This is my second submission for the Copilot CLI Challenge. My first was Ukiyo-Tone — a VS Code theme bundle inspired by Japanese woodblock art. That project taught me how to work with Copilot CLI. VoiceDev is where I pushed it to its absolute limits.

My Framework

I follow a pipeline for everything I build: Idea → Philosophy → Brand Identity → PRD → Milestones → Execution → Testing. (Hint: Im actually working on a blog series to talk about this framework in depth and how can someone leverage it with their own workflow)

Every product. Same framework. No exceptions.

GitHub Copilot CLI was my partner from Idea all the way through Milestones. Not just for writing code — for thinking through the product. During the Idea phase, I used it to research the landscape of voice-controlled dev tools and VS Code extension architecture. During Philosophy and Brand Identity, it helped me articulate VoiceDev's core beliefs. By PRD and Milestones, it was helping me break down a multi-provider speech-to-text architecture into shippable chunks.

But here's what made the difference.

Agent Skills: Giving AI Power and Boundaries

I created Agent Skills — guardrails that made sure Copilot CLI could never make a decision outside my philosophy and vision.

Think of it as a leash. Not because the AI is dangerous, but because AI agents drift. Without constraints, they optimize for "technically correct" instead of "aligned with what I'm actually building."

Privacy-first? Non-negotiable. Local offline mode? Must exist from day one. Progressive disclosure? Every suggestion had to fit the vision.

Agent Skills kept Copilot CLI building my product, not just a product. That's a distinction most people miss when they work with AI agents. You need to control its powers, not just unleash them.

Beyond Building: Reviews and Delegations

Copilot CLI wasn't just for building. Once code was written, I used it for code reviews on my own repository — catching patterns I'd miss after staring at the same codebase for days. And for cloud delegations — offloading deployment tasks and infrastructure decisions without context-switching out of my terminal.

Build, review, deploy. All from the CLI. All with context.

The Thing That Almost Killed It

I need to be real about something.

There aren't many audio libraries out there that work cross-platform and give you the fine-tuning you need for a product like this. In the early days, I was searching for a library that could handle recording, audio processing, and work on Windows, Mac, and Linux without falling apart.

I almost had to kill the idea.

Every library I tried had a dealbreaker. Wrong platform support. No fine-tuning. Bad audio quality. Limited format options. I spent days on this — not writing features, just trying to find the foundation.

The library I ended up with has a big compromise: size. It's heavier than I'd like. But it checks every other box — cross-platform, reliable, configurable. Sometimes shipping means accepting trade-offs and moving forward.

That's not the kind of thing you read about in product launches. But it's the truth of building something real.

The Connected Ecosystem

What surprised me most wasn't Copilot CLI by itself. It was the connected ecosystem.

I'm fully invested in the GitHub ecosystem, and with MCP servers plugged in, Copilot CLI always had the right context available. That's massive when you're building something complex.

The Microsoft Learn MCP server is a perfect example. When I was figuring out how to package and publish a VS Code extension — which has its own quirks and gotchas — I didn't have to tab out and dig through Microsoft's documentation. Copilot CLI already had that context through the MCP server. I could ask questions and steer my product based on real, up-to-date documentation without leaving my terminal.

Same with GitHub MCP. Issues, PRs, repo context — all available to the agent without me copy-pasting anything into a chat window.

That connected ecosystem is what made it possible to ship VoiceDev from idea to preview in 16 days.

Let me say that again. A voice-controlled VS Code extension with four speech-to-text providers, 30+ commands, fuzzy matching, wildcard pattern extraction, a local offline mode with faster-whisper, Copilot CLI integration, Copilot Chat integration, audio feedback, and a Command Center webview.

Sixteen days. I'll take that win.

The Moment It Clicked

There's a moment I keep coming back to.

I used GitHub Copilot CLI to build the feature inside VoiceDev that calls GitHub Copilot CLI by voice.

Say "ask copilot explain this error" and VoiceDev sends it to Copilot CLI. Say "copilot commit" and Copilot generates your commit message. Say "copilot suggest how to list docker containers" and you get an answer without touching your keyboard.

Seeing it work for the first time — my voice triggering the same tool that helped me build the feature — felt like a real sense of achievement. Not because it was technically impressive. Because it was following my vision. The thing I imagined during the Idea phase was now real and doing exactly what I designed it to do.

That's the feeling you build for.

Honestly...

I'm a TUI person. I live in the terminal. I want to do everything from my command line.

Copilot CLI meets me exactly where I already work. No new UI. No context switching. Just my terminal, my agent, and a product that shipped in 16 days because the ecosystem gave me superpowers without asking me to change how I work.

Copilot CLI + MCP servers + Agent Skills isn't just "AI writes code for you." It's an agent that builds with you, inside boundaries you define, with access to the documentation and context it needs. That's a development partner.

And VoiceDev is proof of what happens when that partnership works.

What's Next

VoiceDev is at v0.1.0-preview. Here's where it's heading:

Action Chaining — say "git workflow" to run diff → stage → commit → push in one voice command. Chain any combination of built-in commands.

Custom Macros — say "deploy staging" to trigger your own sequence of git pull → build → deploy.

AI-powered workflows — inline completion and coding assists, triggered by voice.

Real-time translation — speak in any language, VoiceDev understands in English.

The vision is simple. Your voice is your IDE.

That's exactly what I'd like you to take away from this.

Voice-native development isn't about replacing your keyboard. It's about giving developers a faster, more natural way to do the things that pull them out of flow. Voice maps your raw thoughts directly into action — no shortcuts to memorize, no menus to navigate, no flow to break.

And GitHub Copilot CLI made it possible to ship this in 16 days instead of 16 weeks. Not because it wrote the code for me. Because it thought through the product with me, stayed inside my guardrails, and had the context it needed through a connected ecosystem that just works.

If you want to try it: install VoiceDev from the marketplace. Press Ctrl+Shift+V. And just... talk to your editor.

🔗 Repo: github.com/mohitSharma74/voicedev
🎥 Demo: youtube.com/watch?v=65OpDcS4oHM
🎨 Marketplace: VoiceDev (Preview)

While you are at it, show me some love on these 🥰 -

🆇 Twitter/X: https://x.com/MohitSharm95396
⛓️‍💥 Linktree: https://linktr.ee/onlyonemohitsharma
📸 TerminalSnap: https://terminalsnap.online/
🎋 Ukiyo-tone: https://marketplace.visualstudio.com/items?itemName=OneMohitSharma.ukiyo-tone

When Enterprises Vibe Code On A Grand Scale and Its a Rare W!

Mohit ✨ — Fri, 06 Feb 2026 09:56:56 +0000

Let me tell you exactly how this started.

I'm scrolling through tech Twitter, minding my own business, and OpenAI drops a blog post about their new coding model. Standard stuff. Benchmarks, charts, "state-of-the-art performance," the usual.

Then I read this:

I stopped scrolling.

They used early versions of Codex 5.3 to debug its own training. To manage its own deployment. To diagnose its own test results. The model helped build the model.

Are we living in a simulation? Because that reads like the opening crawl of a sci-fi movie, not a product announcement.

Alright hear me out I don't normally do testing on new models but this intrigued me a lot.

I had to stress-test this thing immediately. Not with a todo app. Not with a dashboard. I wanted to throw the weirdest, most out-of-comfort-zone design prompts I could imagine — and see if a model that apparently helped create itself could handle creative direction that most human developers would need days to execute.

The Setup

Four prompts. Four wildly different visual styles for a personal portfolio website. Each one packed with specific aesthetic direction, 12-16 negative constraints telling it what NOT to do, and exact content for every section.

One shot each. gpt-codex-5.3, high reasoning mode. No follow-ups, no corrections.

Prompt 1: 90s American Comic Book

Todd McFarlane's Spawn. Jim Lee's X-Men. Early Image Comics.

Halftone dot textures, POW/ZAP action bursts, speech bubble CTAs, angled comic panel layouts with gutters. I told it explicitly: don't use generic fonts, don't use a standard grid, don't make it look like every other developer portfolio on the internet.

The panels had actual gutters. Action bursts pulsed on hover. The palette was loud, saturated, and unapologetically 90s. Minor alignment quirks — ten-minute fixes. But the design intent? It understood it.

Prompt 2: New York Cartoonist Minimalism

The polar opposite. Saul Steinberg. Roz Chast. New Yorker covers.

Thin pen-and-ink line art. Generous whitespace. Wobbly hand-drawn borders. Witty margin annotations. I told it: no bold colors, no sans-serifs, no CSS gradients, no hamburger menus, no corporate startup energy whatsoever.

This one surprised me the most. Codex generated inline SVGs that actually looked hand-drawn — wobbly lines, crosshatch patterns, pen-sketch icons. The layout breathed. It didn't fall back to the standard card grid every AI defaults to.

Honestly, this was the prompt I expected to break it. A comic book style has clear rules. But "make it feel like a New Yorker illustration" is vibes. It's the kind of brief that makes junior designers ask twelve follow-up questions.

Codex just... got it. First try.

Prompt 3: Deep Space Sci-Fi Terminal

Nostromo from Alien meets 2001: A Space Odyssey.

CRT scan lines, glowing neon text on void-black, radar grids, HUD overlays. Skills as ship system diagnostics. Projects as classified mission briefings. Contact form as a communication terminal — "SENDER IDENTIFICATION" instead of "Name." I even asked for a hidden easter egg.

CSS-generated star field. Authentic typing boot-up animation. Glow effects balanced perfectly — bright enough for sci-fi, readable enough to use. And yes, it built the easter egg.

Prompt 4: Pixel Art / Minecraft Style

The wildcard. Design the entire website as a Minecraft inventory screen.

Skills in a 3×2 inventory slot grid with Minecraft-style tooltips — dark purple background, rarity tags like "LEGENDARY." Projects as quest log entries. An XP bar showing "Level 8" for years of experience. I specified: all animations must use steps() timing, image-rendering: pixelated everywhere, generate all icons using CSS box-shadow pixel art, no image files.

Pure CSS pixel art. Block textures from repeating gradients. Stepped frame-based animations. The inventory slots looked right. The tooltips felt right. It even hid a creeper easter egg.

What Actually Impressed Me

The "created itself" headline is wild. But what sold me wasn't the existential sci-fi of it all. It was three practical things.

Negative prompting actually worked. I didn't just tell Codex what to build — I told it what NOT to do. No generic fonts, no smooth gradients, no card grids, no "every portfolio ever" energy. And it listened. Each result had a distinct personality because the constraints forced it away from its defaults.

That matters. The biggest problem with AI-generated code isn't capability — it's that everything looks the same. Negative prompting breaks that pattern.

Asset generation was genuinely good. Every prompt said "generate all visual assets — no placeholders, no broken links." Codex created inline SVGs, CSS pixel art, code-generated star fields, hand-drawn borders — all from scratch, self-contained, no external dependencies.

Speed and token efficiency surprised me. These weren't simple prompts. Detailed aesthetic direction, a dozen-plus constraints, four page sections with exact content, high reasoning mode. Still processed fast without truncating.

The Bigger Point

Here's what bugs me about the "Codex created itself" discourse.

Everyone's focused on the existential angle. Simulation theory. Recursive AI. Should we be worried?

Fun questions. But they miss the practical truth staring us in the face.

The gap between imagining something and having it exist just collapsed.

I described four visual styles — styles requiring genuine design taste — in plain English. They materialized. Not perfectly. But well enough that the remaining work is tweaking, not building.

Honestly, the real shift isn't about whether AI can create itself. It's about what it lets you create.

A product manager who's never written CSS can now describe their vision and see it built. A developer with strong backend skills can now explore visual directions they'd never attempt manually. A freelancer who can't afford a designer can prototype four aesthetics before their first client call.

You're the pilot now. Codex is the ship. And a ship that helped build itself? Turns out it flies pretty well.

The Prompts

I'm sharing all four prompts — complete with direction, constraints, and specs. Grab them, stress-test Codex yourself.

Public Github Gist to all the prompts

Try throwing something weird at it. Something you'd need a few days and a mood board to build yourself.

A model that helped create itself can probably handle your landing page.

Couple of Announcements

Checkout a couple of Open-Source Projects created by yours truly -

Ukiyo-tone: Themes inspired by ancient japanese techniques
TerminalSnap: Imagine carbon.now.sh but for terminals! Create beautiful terminal screenshots for your own docs and blogs.

Loved this post?
I write about AI, Productivity, and Code in my Substack newsletter - Coffee, Code & AI. Join curious minds to get way more stuff like this in your inbox.

🔗 Subscribe now and never miss an update!

If you followed me recently, I really appreciate it! <3 I really wanted to know if you have tried the Unikyo-Tone themes in your workspace yet! Do you have any thoughts? Any feedbacks? Anything? I'm all ears here! #watercooler #discussion

Mohit ✨ — Thu, 05 Feb 2026 09:20:15 +0000

I Watched an Anime and Built a VS Code Theme Bundle Inspired by 17th-Century Japanese Art

Mohit ✨ — Wed, 04 Feb 2026 17:09:28 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

I built Ukiyo-Tone — a six-theme VS Code bundle inspired by 17th-century Japanese Ukiyo-e woodblock prints and Sumi-e ink traditions.

It started with a Netflix binge.

I was watching Blue Eye Samurai and couldn't stop staring at the animation. Gorgeous. Every frame felt like a painting. That sent me down a rabbit hole — researching Ukiyo-e techniques, woodblock printing, mineral pigments, the whole aesthetic tradition.

And somewhere in that rabbit hole, I thought: What if my code editor felt like this?

Not flashy. Not trendy. Just... calm. Sharp. Built for long hours of focused work.

Honestly? Most VS Code themes feel like they're designed for screenshots, not actual coding sessions. They're either too sterile (corporate vibes) or too chaotic (rainbow syntax highlighting that makes your eyes bleed after two hours).

Ukiyo-Tone is different. It treats color as syntax, not paint. Keywords define grammar. Functions express motion. Variables carry weight. Nothing exists purely for aesthetics.

The bundle includes six distinct themes, each inspired by specific elements of Edo period culture:

Asahi (旭 - Morning Sun) — Light theme. Fresh washi paper and early morning light.

Karesansui (枯山水 - Dry Landscape) — Zen garden theme. Moss, stone, and raked sand.

Tasogare (黄昏 - Twilight) — Soft dark theme. Evening landscapes and faded indigo.

Koke-Dera (苔寺 - Moss Temple) — Monotone dark. Deep forest shadows.

Kuro-Sumi (黒墨 - Black Ink) — Deep dark theme. Charcoal ink and midnight shadows.

Kachi-iro (勝ち色 - Victory Color) — High contrast dark. The "lucky" navy indigo worn by samurai.

Each theme follows the same philosophy: restraint over abundance. If a visual choice improves screenshots but harms long-term focus, it gets rejected.

Demo

🎨 Install from VS Code Marketplace: Ukiyo-Tone

🔗 GitHub Repository: github.com/mohitSharma74/ukiyo-tone

🚀 Install on VS Code Forked IDEs from Open VSIX: Ukiyo-tone

Asahi (旭 - Morning Sun)

Karesansui (枯山水 - Dry Landscape)

Tasogare (黄昏 - Twilight)

Koke-Dera (苔寺 - Moss Temple)

Kuro-Sumi (黒墨 - Black Ink)

Kachi-iro (勝ち色 - Victory Color)

My Experience with GitHub Copilot CLI

GitHub Copilot CLI didn't just help me build this — it helped me think through this.

Extracting Color Palettes from Art

I fed Copilot CLI a bunch of reference images — actual Ukiyo-e paintings, woodblock prints, photos of zen gardens. Then I asked it to analyze and extract color palettes that would work for syntax highlighting while staying true to the aesthetic.

This wasn't just "give me hex codes." It was a conversation about which colors carry enough contrast for readability, which ones feel organic versus mechanical, and how mineral pigment limitations in traditional art could translate to a modern coding environment.

Developing the Philosophy Document

The PHILOSOPHY.md file in my repo isn't an afterthought — it's the project's north star. I used Copilot CLI to help articulate my vision clearly.

I'd describe what I wanted ("a theme that disappears once deep focus begins") and Copilot would help me sharpen the language, identify contradictions in my thinking, and structure the document so it could guide future decisions.

The result is a decision framework that works for both humans and AI agents:

When evaluating any change, ask:

Does this improve long-session clarity?

Does this preserve visual hierarchy?

Does this reduce cognitive noise?

Would removing this make the theme weaker?

If the answer is unclear — do nothing.

Learning VS Code Theme Standards

I used the Microsoft Learn MCP server with Copilot to stay up to speed on VS Code theme development standards. Instead of jumping between documentation tabs, I could ask contextual questions while building — what token types exist, how semantic highlighting works, which scopes to target for specific languages.

It kept me in flow instead of breaking my concentration to search docs.

The Honest Truth

Copilot CLI made this project possible in the time I had. Without it, I would've spent weeks just researching color theory and VS Code APIs. Instead, I spent that time on what mattered: making deliberate design choices that serve developers who actually want calm in their editor.

What's Next

Ukiyo-Tone itself is just the beginning.

I'm currently working on a companion project: VS Code icons inspired by Ukiyo-e art and Sumi-e brush strokes. Same philosophy — restraint, clarity, cultural grounding. Designed to pair seamlessly with these themes.

Because honestly? Your editor shouldn't feel like six different design languages duct-taped together. It should feel like one intentional space.

Who This Is For

This theme isn't for everyone. And that's intentional.

It's for developers who spend long hours in their editor and want something that doesn't fight for their attention. For night-shift coders who need low eye strain without sacrificing readability. For anyone who's ever looked at their VS Code setup and thought: this feels like a corporate tool, not a craftsman's instrument.

Ukiyo-Tone is for people who want their workspace to feel like a zen garden — calm, intentional, and built for seeking clarity.

If you've ever felt like your editor's theme was designed for someone else's demo video instead of your actual workflow, give this a try.

That's exactly what I'd like you to take away from this.

Been using and testing Kimi 2.5 in Kilo Code + Openrouter, and I gotta it is bloody incredible. 🔥 It's amazing how open weight or open source models are closing the gaps to Frontier Models 🚀 #ai #productivity #softwaredevelopment #webdev

Mohit ✨ — Fri, 30 Jan 2026 11:19:20 +0000

Subscription Fatigue Got Me. 6 Open-Source Solutions Saved Me $150/month.

Mohit ✨ — Fri, 30 Jan 2026 08:26:51 +0000

Dashlane sent me a renewal notice. $120 for the year.

Two years earlier? I paid $12.

Same features. Same product. 10x the price because they could.

I exported my passwords that night and built my own stack instead.

That's when I stopped renting my infrastructure from companies that could change the deal whenever they wanted. I started owning it.

Self-hosting open-source projects isn't some extreme DevOps move. Railway has a generous free tier and charges you only for what you actually use. Most of these tools cost me nothing. The ones that do? Maybe five dollars a month total.

You can also run these on a Raspberry Pi sitting in your closet, an old laptop, or any machine with some RAM, storage, and network access. No cloud provider needed if you don't want one.

Here are the six projects I actually use every day. Full control. Zero subscription fatigue. Code I can fork if I need to.

Small Disclaimer: Not a promotion for Railway or anything, just some love for a platform who is trying to be unique and consumer friendly in the industry.

1. Vaultwarden + Bitwarden (Password Manager)

Replaces: LastPass, Dashlane, 1Password

Cost: $0 on Railway free tier

License: GPLv3 (open source)

Bitwarden's premium service costs $10/year. Dashlane wanted $120.

Vaultwarden is a lightweight, open-source implementation of the Bitwarden server. Same apps, same browser extensions, same everything. But the vault lives on your server.

When Dashlane raised prices, I had no choice but to accept or leave. With Vaultwarden, if development stops tomorrow, I fork it. The passwords are mine. The encryption keys are mine. Nobody's holding them hostage for a subscription renewal.

2. Ollama + Llama Models (Local Code Reviews)

Replaces: GitHub Copilot code review features, paid AI assistants

Cost: Runs locally (free), or Railway $5/month for remote access

License: MIT (Ollama), various for models

I was burning through Claude credits reviewing pull requests and refactoring code. Ollama with Llama 3.2 runs on my laptop. Instant code reviews, no API costs, zero latency waiting for responses.

The code never leaves my machine. Proprietary projects, client work, experimental features—all reviewed locally without touching third-party servers.

When you're iterating fast, that privacy and speed matters more than you'd think.

Btw if you want me to make this an open source project, don’t forget to comment below.

3. Memos + Moltbot (Writing & Quick Notes)

Replaces: Notion quick capture, Apple Notes, Google Keep

Cost: $0 on Railway free tier

License: MIT (open source)

Notion's great until you need offline access or want your notes as actual markdown files you control.

Memos is stupid simple. Markdown-based, tagged, searchable. Moltbot automates publishing and organization. I draft article ideas during meetings, tag them for later, and my entire writing backlog lives in plain text files I can grep through.

No vendor lock-in. No proprietary formats. Just text files I own.

4. Gitea (Private Git Hosting)

Replaces: GitHub private repos, GitLab hosted plans

Cost: Railway $5/month handles multiple repos easily

License: MIT (open source)

GitHub owns your private repositories. Microsoft can read them, train models on them, change API access whenever they want.

Gitea gives you Git hosting, issues, pull requests, and webhooks on your infrastructure. I use it for side projects I'm building before they're ready to ship, experiments I don't want public yet, and tools I'm tinkering with that might never see the light of day.

When you're in that messy exploration phase—trying ideas, breaking things, figuring out what works—you don't want that on public GitHub. And you definitely don't want to pay for private repos when you can host them yourself.

When GitHub changes their terms or pricing, I don't care. My code isn't there.

5. Linkding + Custom MCP Server + Claude (Research System)

Replaces: Raindrop.io Premium, Pocket Premium, Instapaper

Cost: $0 on Railway free tier + Claude usage (which I was already paying)

License: MIT (Linkding, open source)

This is where it gets interesting.

I built a custom Claude MCP server that connects to my Linkding instance. When I'm writing an article, Claude can pull from every research link I've saved, tagged, and archived over the past months.

Raindrop.io Premium wanted $28/year for full-text search and tagging. With Linkding, I get that plus a direct pipeline into my AI workflow. The research I do for one article becomes accessible context for every future article.

My second brain isn't trapped in some startup's database. It's queryable, backed up, and integrated into the tools I already use.

6. Pairdrop (File Sharing)

Replaces: AirDrop, WeTransfer, Dropbox file requests

Cost: $0 on Railway free tier

License: GPLv3 (open source)

I'm constantly moving files between my laptop, phone, and desktop. Screenshots for articles, code snippets, mockups.

AirDrop only works on Apple devices. WeTransfer limits file sizes. Dropbox wants $12/month for features I need once a week.

Pairdrop runs in a browser. Open it on any device, drag and drop. Files transfer peer-to-peer through your local network, or via your Railway instance if you're remote. No Bluetooth pairing, no account creation, no file size limits.

It just works.

Honorable Mentions

Umami (Analytics for Shipped Projects)

Replaces: Google Analytics, Fathom, Plausible paid tiers

Cost: $0 on Railway free tier

License: MIT (open source)

I run Umami for terminalsnap.online—a tool I built for generating beautiful terminal screenshots for documentation and social media. Clean metrics showing me which features people actually use, what browsers they're on, where traffic comes from. No cookies, no tracking users across the web.

Google Analytics is free because you're selling your users' data. Fathom and Plausible charge $14-19/month for privacy-respecting analytics.

Umami gives you the same insights without making your readers the product, and it costs nothing to run on Railway's free tier.

Vikunja + Custom MCP Server (Project Management)

Replaces: Todoist Premium, Asana, ClickUp

Cost: $0 on Railway free tier

License: AGPLv3 (open source)

Todoist Premium costs $58/year. Vikunja gives me the same task management features for free.

But here's the thing. I didn't like the UI. So I forked the repo and changed it.

That's the real power of open source. If something annoys you, you don't file a feature request and wait. You open the code and fix it yourself.

I added my own UI tweaks, integrated a custom MCP server for automation, and now I have a version of Vikunja that works exactly how I think. Nobody else in the world has this exact version. It's mine.

Who Actually Benefits From This

Software developers like me who are tired of subscription fatigue.

You're paying $10/month for GitHub, $20/month for productivity tools, $15/month for analytics, $10/month for a password manager, $30/month for file storage. Before you realize it, you're $100+/month deep in SaaS subscriptions.

I was paying over $150/year just on the tools I replaced with this stack. Now? Railway costs me maybe $5-10/month total, depending on usage.

But honestly, it's not even about the money.

When Dashlane raised prices 10x overnight, I had no recourse. Accept it or leave. When Evernote pivoted and features disappeared, people lost access to years of notes. When Mint shut down, users scrambled to export financial data.

Self-hosting open-source projects means you're immune to those decisions.

Fork it. Host it. Own it. The code lives on your server. If a project dies, you maintain your fork. If pricing changes, you don't care. You're not a customer anymore.

The Bottom Line

You don't need to be a DevOps engineer to self-host. Railway makes it dead simple. Most of these projects have one-click deploy buttons. (Again Not a promotion).

The psychological shift from "I hope this company doesn't change pricing" to "I control this infrastructure" is massive.

You stop optimizing around what SaaS vendors allow and start building, what you actually need.

Just Own it.

That's exactly what I'd like you to take away from this article.

Couple of Mentions 🔥

I recently created an open source web app, TerminalSnap, to create beautiful and gorgeous screenshots for your terminal. Totally free! Its in active stage and my aim is to make it a go-to app for terminal screenshots. So a lot more to come (including Excalidraw styled hand drawn terminal themes 👀)!

I just launched my own Weekly Substack newsletter where you’ll find a lot more similar stories(in future), tips & tricks, foundational knowledge and tools from my own experience to help you along with your own journey.

Best Part? One Coffee at a time! And Its totally free!

I Promise!

My 2026 AI Stack: 8 Tools That 10x My Coding & Productivity (Free Tier Only)

Mohit ✨ — Sat, 24 Jan 2026 13:12:28 +0000

I was late to AI coding tools. Skeptical, honestly.

Then I tried Claude Code and Cursor. Hit the $100/month mark, ran out of credits in two weeks.

That's when I stopped paying for subscriptions and started building my own stack from open-source tools and dirt-cheap Chinese models.

Here's what I actually use every day—and why it works better than the paid stuff.

1. Dev Containers (VS Code's Secret Weapon)

VS Code's Dev Containers changed how I work completely. Spin up a containerized dev environment on any platform—no "works on my machine" nonsense.

Here's what nobody talks about: your AI context, MCP servers, autocomplete—all of it works inside the container exactly like it does locally.

// .devcontainer/devcontainer.json
{
  "name": "My Project",
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/devcontainers/features/node:1": {}
  },
  "customizations": {
    "vscode": {
      "extensions": ["continue.continue", "github.copilot"]
    }
  }
}

Python ML project → Node.js API → Rust debugging? One click, new container, full AI support. No subscription needed.

2. Devstral 2 for Autocomplete (Mistral's Free Gift)

Mistral released Devstral 2 with genuinely generous free limits. Thousands of completions per day. Completely free.

Fast, accurate, doesn't try to rewrite your entire function when you just need the next line.

GitHub Copilot: $10/month.
Devstral 2: Free.

3. OpenRouter Chat + Hugging Face (My Model Testing Lab)

Before I commit to using a model for a big project, I test it.

OpenRouter Chat is my playground. Same prompt → Claude, GPT-4, DeepSeek, Gemini, Qwen → see which one actually gets the job done. I was building a Rust learning app, needed terminal UI code. Tested five models in ten minutes. DeepSeek won. Cost me pennies.

Hugging Face is where I go deeper. Leaderboards, benchmark comparisons, fine-tuning on my own data.

When prepping for Tech Lead interviews, I fine-tuned a smaller model on system design scenarios. Ran it locally, completely private, no API costs.

This combo is how you figure out which LLM can do your specific job for a fraction of the price.

4. Antigravity IDE + MCP Servers (Google's Productivity Monster)

Google's Antigravity IDE has built-in MCP integrations—Notion, entire G Suite, Context7, all preconfigured.

Generous Gemini limits: thousands of requests per day on free tier. That's $100+/month of access with other providers.

When I tell the AI "summarize this week's meeting notes and update the roadmap"—it reads my calendar, pulls Drive docs, updates Notion, creates follow-up tasks.

Most underrated MCP servers:

Server	What It Does
Rube (ComposioHQ)	Connects 100+ SaaS tools with one integration
Github	Read repos, create PRs, review code in-IDE
Firecrawl	Scrapes and structures web content for context
Context7	Unified search across all your docs
YepCode	Serverless functions from your prompts

5. Chinese Open-Source Models (The Price-Performance Champions)

This is where the paid AI market got disrupted. Frontier-quality, almost nothing in cost.

Model	Context	Input Price	Output Price	Best For
GLM-4.7	128K	$0.60/M	$2.20/M	Long context coding
MiniMax M2.1	4M	$0.30/M	$1.20/M	Agent workflows
DeepSeek R1	64K	$0.14/M	$0.56/M	All-around best value
Qwen VL	32K	$0.09/M	$0.30/M	Vision tasks
FLUX.2 Klein 8B	N/A	Free (local)	Free (local)	Image gen in <1 second

Why so cheap? Mixture of Experts architecture, cheaper Chinese GPUs, market share > profit.

Performance? I've run the same tasks on Claude Sonnet and DeepSeek. Can't tell the difference.

6. Obsidian + Agent Skills (Second Brain, Supercharged)

My second brain lives in Obsidian. Articles, research notes, ideas.

I created Agent Skills that connect to my vault. Now when researching, the AI has context on everything I've saved. Surfaces related notes I forgot about, suggests connections between ideas.

Agent Skills aren't just for coding:

Learning workflows (study plans, resource tracking)
Research (summarizes papers, finds gaps)
Career development (tracks skills, suggests paths)

Your Obsidian vault becomes the knowledge base. Agent Skills become the interface. You're not starting from zero every time.

7. Claude Code Extension + Excalidraw (Visual Thinking, Fast)

The Claude Code Chrome extension lets me create visuals in Excalidraw without leaving my browser.

Need a system architecture diagram? Describe it → Claude generates Excalidraw code → paste → clean diagram.

Faster than Miro, cheaper than Lucidchart.

8. Bonus: Almost-Free Tools

Free LLMs: Xiaomi's MiMo-V2-Flash, BigPickle, Grok-code-1, Devstral Small 2, GLM-4.7-flash

Kilo Code: Free $20 credits on signup

n8n: Open-source workflow automation. Self-host for free.

Google AI Studio: 1,000-1,500 requests/day free, 500K+ TPM

Mistral AI: Several models completely free via API

The pattern? Every paid tool has a free or dirt-cheap alternative.

Who This Actually Helps

Developers where $100-200/month for AI tools is real money.

Indie hackers juggling side projects.

Students who can't expense subscriptions.

Anyone stacking Cursor + Claude + Midjourney + ChatGPT watching bills pile up.

I'm not rationing AI anymore. I built that Rust learning app because I wanted to—not because it was "important enough" to justify credits.

The psychological shift from "is this worth spending tokens on?" to "let me just build it" is massive.

The Bottom Line

The free alternatives are good enough now. The only thing stopping you is not knowing they exist.

Now you know.

What's in your AI stack? Drop your favorite free tools in the comments—I'm always looking for new discoveries.