DEV Community: ARAFAT AMAN ALIM

SEO is Dead. Long Live Markdown: How AI Agents Are Quietly Rewriting the Web

ARAFAT AMAN ALIM — Wed, 06 May 2026 10:01:50 +0000

TL;DR — AI bots (ChatGPT, Claude, Perplexity, Google's AI Overviews) now make up a huge slice of your website traffic. They don't want your beautifully styled HTML. They want clean Markdown — and they'll thank you with citations. This post shows you exactly how to serve it using a 27-year-old HTTP feature that suddenly matters again: content negotiation.

The Day I Realized My Real Audience Wasn't Human

A few months ago I shipped two side projects. Nothing fancy — a transcription tool and a small productivity app. I did the usual: meta tags, Open Graph, sitemap, lighthouse score in the 90s, the works. The 2018 SEO playbook, basically.

Then I opened my Cloudflare analytics one morning and almost spilled my coffee.

In the last 24 hours alone:

Googlebot → 99 hits
Applebot → 48 hits
ClaudeBot → 19 hits
PerplexityBot, GPTBot, Bingbot, ClaudeSearchBot → dozens more

A meaningful chunk of my "traffic" wasn't humans clicking blue links. It was machines. Specifically, it was AI agents scraping my content to answer somebody else's question on ChatGPT or Claude.

And here's the kicker: I had optimized my entire site for humans and Googlebot — neither of which is now the deciding visitor.

That's when it hit me: the old SEO is dead. Or more accurately, it's been demoted. The new game is optimizing for the bots that feed Large Language Models. And the way you do that is nothing like what you learned in 2015.

Let me walk you through what I figured out — and the small middleware change that can make your site dramatically more visible inside ChatGPT, Claude, and Perplexity.

The Three Acronyms You Need to Know in 2026

Before we get to the fix, here's the vocabulary nobody handed you:

Term	What it optimizes for	Who reads your content
SEO (Search Engine Optimization)	Ranking on Google's blue links	Humans, via Googlebot
AEO (Answer Engine Optimization)	Getting quoted in AI Overviews, featured snippets, voice search	AI summarizers
GEO (Generative Engine Optimization)	Being cited by ChatGPT, Claude, Perplexity, Gemini	LLMs synthesizing answers

A 2025 Gartner forecast estimated that organic search traffic to commercial websites would drop ~25% by the end of 2026 as answer engines absorb informational queries. BrightEdge has reported AI Overviews appearing on over 40% of Google results pages. Roughly 60% of Google searches now end without a click.

Translation: even when you "rank," fewer people are clicking. The AI ate your snippet and walked away.

So winning in 2026 isn't about ranking number one. It's about being the source the AI cites when it answers. And to be that source, the AI has to be able to read you efficiently. That's where the real story begins.

The Token Problem (Or: Why AI Bots Hate Your HTML)

Here's something that took me embarrassingly long to internalize:

Everything in AI is tokens.

Cost? Tokens. Context window? Tokens. Speed? Tokens. Accuracy? Tokens. Whether the model can even fit your page into its working memory? Tokens.

So when an AI agent crawls your site, every wasted token is wasted money, wasted context, and a worse answer for the user. And HTML is spectacularly wasteful.

Let me prove it. Suppose all you want to communicate is the phrase "Hello World."

In plain text, that's 11 characters. About 3 tokens.

In real-world HTML, the same phrase looks more like this:

<div class="hero hero--centered" data-testid="greeting-block" id="welcome">
  <h1 class="text-4xl font-bold tracking-tight text-slate-900 dark:text-white">
    Hello World
  </h1>
</div>

That's ~200 characters and easily 60+ tokens to convey the same 3 tokens of actual meaning. That's a 20× tax the model pays to extract one phrase. Multiply that across an entire blog post buried inside a Tailwind component tree, a sticky nav, a cookie banner, three modal portals, and a footer with 47 links — and you start to see why an LLM treats most websites the way you'd treat a 400-page contract written in Comic Sans.

The bot is trying to help its user answer a question. You're handing it a pile of <div> confetti and asking it to find the meaning.

So the AI's response is rational: "Don't give me HTML. Give me the words."

"Just Send Plain Text" — The Trap That Doesn't Work

The obvious next thought is: fine, I'll just strip the HTML and serve raw text.

Don't. There are two problems.

Problem 1: Browsers need HTML. You can't host your site as a .txt file. Visitors expect a real, rendered page. Strip the CSS off your homepage and it looks like a 1996 Geocities accident.

Problem 2: Plain text loses structure. Was that line a heading? A list item? A code block? An external link? An image caption? Plain text flattens all of it. The AI gets your words but loses the relationships between them. Information loss in, hallucinations out.

You need a format that's:

✅ Structured enough to preserve meaning (headings, lists, links, code)
✅ Compact enough to be token-cheap
✅ Already trained into every major LLM as a first-class language

There's exactly one format that fits all three boxes.

Enter Markdown: The Native Tongue of LLMs

If you've ever pasted a doc into ChatGPT, you've already used it. Markdown is what every major LLM is trained on, what they output by default, and what they parse most reliably.

A heading is #. A list is -. Bold is **. Code is backticks. That's it. No attributes, no nested wrappers, no semantic divs.

Same "Hello World," in Markdown:

# Hello World

That's 13 characters. Maybe 4 tokens. The AI gets the exact same semantic information — "this is a top-level heading saying Hello World" — for less than 10% of the cost.

Now multiply that savings across an entire knowledge base. It's not a small efficiency gain. It's the difference between an LLM being able to read your whole product documentation in a single context window vs. catching fragments and guessing at the rest.

Cloudflare, Vercel, Stripe, Coinbase, Mintlify, Fern — every developer-tools company that takes AI agents seriously is now serving Markdown alongside HTML. According to Webflow, the number of sites adopting llms.txt (a related Markdown standard) grew 1,835% in roughly a year. This isn't a fringe idea anymore. It's becoming infrastructure.

But here's the question: how do you serve Markdown to bots without breaking the experience for humans?

The Magic Trick: Content Negotiation (a.k.a. "Markdown Negotiation")

The solution is delightfully old-school. HTTP has had content negotiation baked into it since 1999. It's the reason the same URL can return JSON to your mobile app, RSS to a feed reader, and HTML to a browser.

The mechanism is the Accept header. Every HTTP request includes one. Browsers send:

Accept: text/html,application/xhtml+xml,...

So the server happily returns HTML. But an AI agent crawler can send:

Accept: text/markdown

…and your server, if you've configured it correctly, can return a clean Markdown version of the exact same page. Same URL. Same canonical content. Different format.

This is what Cloudflare now calls "Markdown for Agents," and it's a one-toggle feature on their platform. But you don't need Cloudflare to do it — you can implement it yourself in any framework in about 15 minutes.

Implementation: A Universal Pattern

Here's the mental model. You write your content once (ideally in MDX or Markdown to begin with). Your server has a thin middleware that looks at the Accept header and decides what to send back.

The Express.js Version

// content-negotiation.js
import express from 'express';
import { renderHtml, renderMarkdown } from './renderers.js';

const app = express();

app.get('/blog/:slug', async (req, res) => {
  const post = await getPostBySlug(req.params.slug);
  if (!post) return res.status(404).send('Not found');

  const accept = req.headers.accept || '';

  // AI agent? Serve Markdown.
  if (accept.includes('text/markdown')) {
    res.set('Content-Type', 'text/markdown; charset=utf-8');
    // Optional but nice: tell the bot how big this is in tokens
    res.set('x-markdown-tokens', String(estimateTokens(post.markdown)));
    return res.send(renderMarkdown(post));
  }

  // Browser? Serve HTML as usual.
  res.set('Content-Type', 'text/html; charset=utf-8');
  res.send(renderHtml(post));
});

app.listen(3000);

The Next.js (App Router) Version

// app/blog/[slug]/route.ts — handles GET requests
import { NextRequest } from 'next/server';
import { getPostBySlug } from '@/lib/posts';

export async function GET(
  req: NextRequest,
  { params }: { params: { slug: string } }
) {
  const post = await getPostBySlug(params.slug);
  if (!post) return new Response('Not found', { status: 404 });

  const accept = req.headers.get('accept') || '';

  if (accept.includes('text/markdown')) {
    return new Response(post.markdown, {
      headers: {
        'Content-Type': 'text/markdown; charset=utf-8',
        'Cache-Control': 'public, max-age=3600',
      },
    });
  }

  // Fall through to your normal page render
  return new Response(renderHtmlShell(post), {
    headers: { 'Content-Type': 'text/html; charset=utf-8' },
  });
}

⚠️ Important: don't try to convert your HTML to Markdown on the fly with a library. The whole point is to ship a separate, hand-curated, token-minimal file. Skip the navbar. Skip the footer. Skip the "related posts" widget. Strip the images unless they're load-bearing. Keep only what an AI needs to answer questions about that page: title, intro, key facts, conclusion.

The "Just Drop a Companion File" Pattern

If middleware feels like overkill, follow the pattern Cloudflare and Vercel use: expose every page as /page-url/index.md or append .md to any URL.

https://yoursite.com/docs/getting-started      → HTML
https://yoursite.com/docs/getting-started.md   → Markdown
https://yoursite.com/docs/getting-started/index.md → also Markdown

This is dead simple to host (it's literally a static file) and works perfectly with bots that don't yet send the Markdown Accept header. Belt and suspenders.

The Cherry on Top: `llms.txt`

While we're here, let's talk about the proposal that's quietly becoming the robots.txt of the AI era: llms.txt.

Proposed by Jeremy Howard (FastAI / AnswerAI) in late 2024, llms.txt is a single Markdown file at the root of your domain — yourdomain.com/llms.txt — that tells AI agents the shape of your site. Think of it as a hand-curated table of contents written specifically for LLMs.

A minimal example:

# Acme Widgets

> Acme Widgets makes open-source developer tools for shipping
> faster with fewer bugs. We focus on TypeScript, edge runtimes,
> and observability.

## Docs

- [Getting Started](https://acme.dev/docs/getting-started.md): 5-minute setup guide.
- [API Reference](https://acme.dev/docs/api.md): Full endpoint and SDK reference.
- [Pricing](https://acme.dev/pricing.md): Tiers, limits, and SLA.

## Guides

- [Deploying to Vercel](https://acme.dev/guides/vercel.md)
- [Self-hosting on AWS](https://acme.dev/guides/aws.md)

## Optional

- [Changelog](https://acme.dev/changelog.md)
- [Brand assets](https://acme.dev/brand.md)

And often a sibling file, llms-full.txt, which inlines the entire text of every important page in one Markdown blob — perfect for an AI agent that wants to load your whole knowledge base into a single context window.

Companies already shipping llms.txt: Cloudflare, Anthropic, Vercel, Mintlify, ElevenLabs, Cash App, Stripe-adjacent docs sites, and a fast-growing list. If your competitors aren't doing this yet, you have a window.

Don't Forget the Doorman: `robots.txt`

This part is unglamorous but matters. Your robots.txt is where you decide which AI bots are allowed to read you in the first place. With AI training and AI search now distinct activities, you can be granular:

# Allow AI search/answer bots (they cite you)
User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Applebot-Extended
Allow: /

User-agent: Google-Extended
Allow: /

# (Optional) block scrapers you don't want
User-agent: CCBot
Disallow: /

Sitemap: https://yoursite.com/sitemap.xml

A few rules of thumb:

If you want citations in ChatGPT/Claude/Perplexity, allow their search-time bots.
If you don't want your content used for model training, you can selectively block training-time bots (e.g. GPTBot for OpenAI, Google-Extended for Google's training).
If you block a bot in robots.txt, you're also blocking it from reaching your shiny new Markdown endpoints. Consistency matters.

The 2026 Checklist for Shipping AI-Friendly Pages

If you do nothing else today, do these five things:

Audit who's actually crawling you. Filter your access logs by user-agent. You'll be surprised how much of your "traffic" is ClaudeBot and GPTBot.
Add Markdown content negotiation. Either via the Accept: text/markdown header, or via companion .md URLs, or both.
Hand-write a llms.txt at your domain root. Don't auto-generate it from your sitemap — curate it. Treat it like a conversation with a smart, busy intern.
Update robots.txt to explicitly allow the AI bots you want to be cited by, and block the ones you don't.
Strip your Markdown ruthlessly. No nav, no footer, no related-posts, no "subscribe to newsletter" CTAs. Just the answer. AI doesn't care about your conversion funnel.

Do this and you'll start showing up as a cited source in Perplexity and Claude answers within weeks. Skip it, and your competitors will own those citations forever.

A Last Honest Word

I want to be careful here. I'm not telling you SEO is dead in the literal sense. Google still drives the bulk of direct traffic for most sites. Strong fundamentals — fast pages, clear structure, real authority, original content — still matter. In fact, they matter more, because AI engines lean on the same trust signals (and a Princeton study from 2024 found that pages cited in AI Overviews correlate ~92% with pages already ranking in Google's top 10).

What's dead is the idea that optimizing for one audience is enough. In 2026, every page you ship has at least three readers: a human, a search crawler, and an AI agent. They each need a different version of the truth.

The good news? Once you set up the middleware, it's mostly free. You write the content once. The server decides who gets what. The AI bots eat their clean Markdown. The humans get their pretty page. And you get cited in the answers that are quietly replacing the search box.

Welcome to the agentic web. Ship the Markdown.

If this was useful

Drop a ❤️, follow for more deep-dives on the practical edge of AI engineering, and tell me in the comments: have you started seeing AI bots in your analytics? Which one is hitting you hardest? I'm curious whether my Claude-heavy mix is normal or just a function of my niche.

If you're shipping a side project right now, this is the cheapest, highest-leverage change you can make this weekend. Go look at your access logs. Then go write a llms.txt. Your future self — and a few thousand AI agents — will thank you.

Tags: #webdev #ai #seo #javascript #nextjs #llm #agents #markdown

Why Supavisor 1.0 Is Written in Elixir (And Why That's Actually a Brilliant Move)

ARAFAT AMAN ALIM — Wed, 06 May 2026 09:59:23 +0000

A behind-the-scenes look from the creator of Elixir himself.

"Wait... Elixir? Really?"

Picture this. You're scrolling through Hacker News, sipping your third coffee of the morning, and you see the headline: "Supabase launches Supavisor 1.0 — a Postgres connection pooler."

Cool. Solid. Useful.

Then you click in, read the docs, and realize... it's written in Elixir.

And somewhere in the comments, you can almost hear the collective developer eyebrow-raise:

"Why on earth would they build a Postgres connection pooler in Elixir?"

It's a fair question. Most people in the broader programming community don't reach for Elixir when they think "infrastructure tool." They think Go. They think Rust. They think "something with a fancy concurrency model and a logo that screams performance."

So when José Valim — yes, the creator of Elixir himself — went on record to explain why this choice actually makes a lot of sense, it was worth listening to. He even admits upfront that he's biased (which, fair, he literally invented the language). But his answer is surprisingly not about Elixir.

It's about something deeper. Something older. Something built decades ago to keep your phone calls from dropping.

Let's dig in.

First, Let's Get the Credits Out of the Way

Before going down the rabbit hole, José gave a quick shoutout: huge congrats to the Supabase team on shipping Supavisor 1.0. He also mentioned that he and his colleagues at Dashbit got to contribute to this milestone in small ways. So this isn't some random outsider commentary — this is someone who's had hands on the actual code, and who happens to also be the creator of the language it was written in.

Pretty cool position to write about something from, honestly.

Okay, So What Is a Connection Pooler Anyway?

Before we can answer the "why Elixir" question, we need to make sure we're all on the same page about what Supavisor actually does. Because if you've never wrestled with database connections at scale, the whole concept might feel a bit abstract.

So let's set the scene.

The Cloud Functions Nightmare

Imagine you're running cloud functions. Lambda. Vercel functions. Cloudflare Workers. Whatever the flavor of the day is. These little serverless guys spin up, do their job, and disappear into the void.

Now imagine each of those functions needs to talk to your Postgres database.

Sounds simple, right? Just connect, run the query, return the data, disconnect. Easy.

Except... opening a Postgres connection is not free.

Every time you connect to Postgres, there's an entire handshake ritual. TCP setup. Authentication. SSL negotiation if you're being responsible. Session initialization. The works. It's like every time you wanted to chat with your friend, you had to first knock on their door, introduce yourself, show ID, fill out a visitor form, and wait for them to brew you tea before you could even ask what's up.

Now multiply that by thousands of cloud function invocations per second.

You see the problem.

The Node.js / Ruby Special

It gets worse. José pointed out something interesting about languages like Node.js and Ruby — they can't efficiently leverage all your CPU cores out of the box (single-threaded event loops, GVL, that whole drama). So what do you usually do? You spin up multiple instances of your app.

And what does each instance want? Yep — its own connection (or pool of connections) to Postgres.

So now you've got:

A bunch of app instances...
Each holding open multiple Postgres connections...
Or worse, re-opening them on every request...
And Postgres on the other end going, "Please. I'm tired."

Postgres connections are expensive in terms of memory too. Each one chews up RAM on the database server. Get enough of them and you'll watch your database performance fall off a cliff in real time.

Enter the Connection Pooler

This is where a connection pooler comes in like the bouncer at an exclusive club.

Instead of every app instance and every cloud function knocking on Postgres's door, you put a proxy in front of Postgres. This proxy keeps a fixed set of connections to Postgres open and ready to go. When your app needs to talk to the database, it talks to the pooler instead. The pooler basically says:

"Hey, no need to do the whole handshake thing. I've already got a warm connection ready for you. Use this one."

Your app gets fast database access. Postgres doesn't get overwhelmed. Everybody's happy.

That's what Supavisor is. A connection pooler — but a particularly fancy one, designed from the ground up to be:

☁️ Cloud native
🏢 Multi-tenant — meaning you can connect to a bunch of different Postgres databases at the same time

That last part is huge for a company like Supabase, who hosts who-knows-how-many Postgres databases for their customers. They need one pooler that can juggle them all.

Now for the Real Question: Why Elixir?

Okay, so we understand what Supavisor does. It manages a lot of connections, across a lot of databases, for a lot of clients. And it has to do this without falling over.

So why pick Elixir for this job?

Here's the twist José drops:

"It's not because of Elixir. It's because of the Erlang virtual machine that Elixir runs on."

Plot twist. The hero of this story isn't actually Elixir. Elixir is more like... the cool modern frontend for an absolute powerhouse of a backend. That backend is the BEAM — Erlang's virtual machine.

To understand why the BEAM is unreasonably good for this kind of work, we need to take a quick history detour. Don't worry, it's a fun one.

A Quick Trip Back to the Telephone Era

Erlang wasn't created in a Silicon Valley garage by a hoodie-wearing twenty-something. It was created in the 1980s by Ericsson — a Swedish telecommunications company. And they had a very specific problem to solve.

They needed to build software for telephone switches.

Now think about what a telephone switch actually does. It sits there and:

Accepts connections from a bunch of different places
Routes those connections to other places — services, houses, phones
Keeps thousands (or millions) of these connections alive at the same time
Cannot, under any circumstances, drop your call because something on the other end of the network had a hiccup

Sound familiar?

Because that's exactly what a connection pooler does. Just swap "phone calls" for "database connections." The shape of the problem is identical:

Accept connections coming in from your services, your cloud functions, your request handlers
Keep open connections to Postgres (the "destination" on the other side)
Route incoming traffic to the right outgoing connection
Handle a staggering number of these simultaneously
Don't fall over when something somewhere goes wrong

Erlang was built for this. Literally. It is the language equivalent of a tool forged for one specific job, and that job happens to be the same job a connection pooler does.

When José said the BEAM has "all the principles and foundations" needed for Supavisor, he wasn't being generous — he was just being accurate.

Scale to Millions (No, Really)

Here's where it gets really wild.

You want your connection pooler to scale. Not "scale" as in "handle a few hundred connections." Scale as in millions of concurrent connections. That's the kind of territory Supabase plays in.

Most languages start sweating at, like, 10,000 concurrent connections. The BEAM? It just kind of shrugs. Handling massive numbers of lightweight processes is literally what it was designed to do — because back in the telephone days, every call was a process, and a busy switch had millions of them.

So when Supavisor needs to scale up to handle Supabase-level traffic, it's not fighting against the runtime. The runtime is already wired for this.

But What Happens When One Pooler Isn't Enough?

Here's a great point José made that often gets overlooked.

Imagine Supavisor is humming along, and traffic keeps growing. Eventually, one instance of the pooler isn't enough. You need to spin up multiple Supavisor nodes, all working together to handle the load.

Now you've got an interesting situation. Let's say:

Service A is connected to Pooler Node 1
That request needs to talk to a specific Postgres database
But the warm connection to that database is actually living on Pooler Node 2

What do you do?

Option 1: Both nodes maintain connections to every database. Simple, but wasteful and doesn't scale well.

Option 2: Route the request from Node 1 over to Node 2, where the right connection already exists.

Option 2 is often the smarter play. And here's the magic: Erlang gives you this kind of inter-node communication essentially out of the box. Building distributed systems where nodes can talk to each other, hand off work, and behave as a single coordinated cluster is one of those things the BEAM has had baked in for decades. In most other ecosystems, you'd be reaching for Redis pub/sub, or gRPC, or some custom messaging layer. In Elixir/Erlang, it's just... there.

That's not a small thing. That's a massive head start.

Fault Tolerance: The Quiet Superpower

Here's the part that should make any infrastructure engineer's eyes light up.

When you're running a connection pooler, things will go wrong. A connection will die. Postgres will hiccup. A client will misbehave. Some bug will show up in production at 3 AM (because of course it will).

The question is: when one of those things goes wrong, what happens to everything else?

In a lot of systems, one bad connection or one crashed handler can take down a whole process — or worse, the whole service. You suddenly lose every other connection that was happily doing its job, just because one neighbor misbehaved.

Erlang's answer to this is the "let it crash" philosophy combined with deep, structural isolation between processes. Each connection lives in its own lightweight process. If it crashes, only that process dies. The supervisor restarts it. Nothing else even notices.

It's like if your apartment building was designed so that if one apartment caught fire, the fire just... politely stayed in that one apartment. The rest of the building doesn't care. Life goes on.

For a connection pooler with thousands or millions of connections, this isolation isn't a "nice to have." It's table stakes. You absolutely cannot have one weird query bringing down connections for unrelated tenants on a multi-tenant system.

Erlang handed Supavisor this guarantee on a silver platter.

The Big Takeaway

So let's zoom back out and put it all together.

Supavisor is a connection pooler that needs to:

Handle massive numbers of concurrent connections ✅ (BEAM was built for this)
Be multi-tenant, juggling many databases at once ✅ (lightweight processes make this trivial)
Scale across multiple nodes with smart request routing ✅ (Erlang has distribution baked in)
Be fault tolerant, with crashes contained to single connections ✅ (isolation is the BEAM's middle name)
Be cloud native and ready for production at serious scale ✅ (this is the BEAM's home turf)

Every. Single. Requirement. Lines up with what Erlang was originally designed to do for telephone switches forty years ago.

Choosing Elixir for Supavisor isn't a quirky language preference. It's not "we like Elixir, so we'll force-fit it here." It's actually one of those rare moments where the problem and the tool are so well-matched that picking anything else would feel like trying to dig a swimming pool with a teaspoon.

Should You Use Supavisor?

Here's the practical TL;DR José landed on:

If you're running Postgres in production, and either:

You're spinning up new database connections dynamically all the time (hi there, serverless folks 👋), or
You've got too many services keeping too many connections open to Postgres, and you're starting to feel that memory pressure...

...then yeah, you should absolutely give Supavisor a try. Sticking a smart pooler in front of Postgres can dramatically reduce your connection overhead and let your database actually breathe.

And as a little bonus suggestion from José himself: if all this talk about lightweight processes, fault tolerance, distributed systems, and "let it crash" got your inner curiosity tingling — go check out Elixir. You don't need to be building telephone switches or connection poolers to benefit from those foundations. Plenty of web apps, real-time systems, and backend services would be very happy to live on the BEAM too.

Final Thought

There's a lesson hiding inside this whole story, and it's not really about Elixir or Erlang specifically.

It's that sometimes, the best engineering decisions come from recognizing that someone, somewhere, has already solved the shape of your problem — even if they solved it for a completely different domain. The Ericsson engineers in the 1980s were not thinking about cloud functions or Postgres. They were thinking about phone calls. But the structure of their problem — many concurrent connections, fault tolerance, distributed routing — turned out to be the structure of an enormous number of modern infrastructure problems too.

Supavisor 1.0 is a great example of that lesson playing out in 2026. Decades-old runtime, brand-new product, and a very nice fit between the two.

Congrats again to the Supabase team. And if you're a backend dev who's never given Elixir a serious look — maybe today's the day. ☕

Have you tried Supavisor yet? Or have your own war stories about Postgres connection management at scale? Drop them in the comments — I'd love to hear how you're handling it.

I Started Learning AI-Assisted Development — And It Completely Changed How I Think About Coding

ARAFAT AMAN ALIM — Sun, 05 Apr 2026 12:03:25 +0000

I'll be honest with you.

When I first heard the phrase "AI-assisted development," I rolled my eyes a little. I'd seen the Twitter threads. I'd watched developers rave about tools that supposedly wrote entire apps in seconds. I was skeptical. Wasn't this just autocomplete with better marketing?

Then I actually sat down and took a proper course on it.

What happened over the next few hours genuinely shifted my perspective — not just about the tools, but about what being a developer even means in 2026. This isn't a hype piece. It's the real story of what I learned, what surprised me, what scared me a little, and what I'm going to keep using going forward.

Let's get into it.

First: The Stuff They Don't Tell You in the Ads

Before touching a single tool, the course started with fundamentals. And I'm glad it did, because understanding how these AI systems actually work is what separates developers who use AI effectively from those who just get frustrated by it.

Tokens — The Currency of AI

Every time you type something to an AI, it doesn't read words the way you do. It reads tokens — small chunks that might be a word, part of a word, a punctuation mark, or even a space. The word function might be a single token. The word functionalize might get broken into two or three.

Why does this matter to you as a developer? Because most AI services have token limits. Free tiers restrict how many tokens you can use per day or month. Longer prompts cost more. Understanding this helps you stop wondering why you hit limits and start thinking strategically about how you write prompts.

Context Windows — The AI's Short-Term Memory

The context window is how much information the AI can hold in its "mind" at once during a conversation.

Here's the real-world difference this makes:

GPT-4: ~128,000 tokens
Claude: up to 200,000 tokens
Gemini: over 1 million tokens

A small context window means the AI can only look at a few files at a time. A large context window means it can analyze your entire codebase in one pass. This isn't just a spec sheet detail — it fundamentally changes what kind of tasks you can assign to each tool.

Hallucinations — The Thing That Should Keep You Humble

This one matters most. A hallucination is when the AI confidently suggests something that's completely wrong. Not "maybe wrong." Wrong — like referencing a library that was deprecated years ago, inventing an API method that never existed, or calling a function that doesn't exist anywhere.

The AI isn't lying to you. It's doing exactly what it was trained to do: predicting what token should come next. Sometimes that prediction is perfect. Sometimes it's completely made up — and delivered with the exact same confident tone.

This is why you never, ever blindly accept AI-generated code. Test it. Check the docs. Verify the functions actually exist. This isn't optional.

The Mental Model That Changed Everything For Me

Here's the framing that clicked for me and I haven't stopped thinking about it since:

Think of AI as a very fast, very knowledgeable junior developer.

They can write code quickly. They know a lot of syntax. But you need to review their work, guide the architecture, and make the important decisions.

AI is phenomenal at the how: how to implement something, how to write the syntax, how to structure a function. But you should be deciding the what and the why. What you're building and why you're building it that way.

Use AI for:

Boilerplate code (getters, setters, basic CRUD)
Learning new frameworks or syntax
Writing tests and documentation
Refactoring repetitive patterns
Getting unstuck on syntax errors

Keep these to yourself:

System architecture decisions
Security-critical logic
Complex business logic
Performance-critical optimizations
Learning a new concept for the first time

GitHub Copilot: Your Pair Programmer Lives in VS Code

The first tool I got hands-on with was GitHub Copilot, and it's the most accessible entry point for most developers.

Setting It Up

Install the GitHub Copilot Chat extension in VS Code (not the old deprecated one). Sign in with your GitHub account, and you're done. The extension now handles both code completions and chat in one package.

On pricing: the free tier gives you 2,000 code completions and 50 chat/agent requests per month. If you're a student, teacher, or open-source maintainer, you can get the Pro plan free — which gives you unlimited completions and access to premium models.

The "Neighboring Tabs" Trick

This was the first genuine "whoa" moment for me.

Copilot doesn't just look at the file you're currently editing. It also scans the other tabs you have open in VS Code. So if you have your CSS file, your test file, and your component file all open simultaneously, Copilot will suggest code that uses the actual class names from your CSS and the actual test IDs from your test file.

Without those tabs open, it might suggest something generic like container or user-box. With them open, it knows you need user-card-name because that's what your test is looking for. This is the difference between suggestions that feel generic and suggestions that feel like the tool actually understands your project.

Three Modes You Need to Know

Ask Mode is for questions, learning, and exploration. It won't touch a single line of your code unless you manually copy something. Safe to use when you're in a "what is this" headspace.

Edit Mode is for targeted refactoring. Point it at a file and give it a specific instruction — like "refactor this to async/await with a 5-second timeout" — and it applies changes directly to your file in a diff view. Red = old code, green = new code. You review each line and choose keep or undo. This is the fastest way to safely refactor.

Agent Mode is where things get genuinely powerful — and genuinely require your attention. Give it a massive task like "create a full REST API with JWT authentication and an SQLite database" and it will plan, create files, install npm packages, write middleware, and even run test builds to check for syntax errors. It's autonomous. It asks for permission before sensitive operations. And it will make decisions you might not agree with — so you need to watch the plan it generates and stay engaged.

Teaching Copilot Your Project's Rules

You can create a file called .github/copilot-instructions and write plain-English rules for your project — always use TypeScript, always use functional components, use bcrypt for passwords — and Copilot will follow them automatically.

Even better: just type /init in the Copilot chat, and it will scan your codebase and generate this file for you. Every suggestion it makes from that point forward will respect your project's conventions automatically.

CodeRabbit: The AI That Reviews Your Code So You Don't Have To (Well, Sort Of)

This is the one that genuinely impressed me most, and it's the one I didn't expect to care about.

Here's the workflow problem CodeRabbit solves: you push code, you wait a day or two for a human code review, and then you have to context-switch back to fix issues that are now stale in your memory. With AI code review, you get feedback in minutes — while the context is still fresh.

What CodeRabbit Actually Does

The moment you create a pull request, CodeRabbit:

Analyzes your changes and generates a summary
Flags security vulnerabilities before they reach production
Identifies bugs and code quality issues
Assigns severity levels: critical, major, minor, nitpick
Provides specific, implementable suggested fixes
Lets you chat with it directly in the PR comments

It integrates with GitHub, GitLab, Bitbucket, and Azure DevOps.

A Real Example That Got Me

During the course, a demo project had these issues caught by CodeRabbit on a PR:

Major: Hard-coded admin password in source code (with a one-click commitable fix)
Critical: Admin list and delete endpoints were completely unauthenticated — anyone could enumerate or delete discount codes
Major: Cart total was being accepted from the client, which could be manipulated — it should be computed server-side
Minor: Dead code with unfixed bugs

And here's the part that got me: you can just type @coderabbit ai can you show me how to properly secure these admin endpoints using middleware? right in a PR comment, and it will give you a complete, contextual implementation guide.

The CLI Power Move

CodeRabbit also has a CLI. You can run coderabbit from your terminal before you've even committed anything. This means you can set up a loop: write code → review locally → fix → commit. And it gets better: if you're using an AI agent like Copilot or Claude, you can tell the agent to "run coderabbit --prompt-only and fix any issues it finds" — and the agent will handle the entire review-and-fix cycle autonomously.

One AI writing code. Another AI reviewing it. That's not science fiction anymore.

CodeRabbit Plan — This One's a Game Changer

Before you write a single line of code, create a GitHub issue describing what you want. Then comment @coderabbit ai plan on the issue. CodeRabbit will analyze your entire codebase and generate:

A detailed implementation plan
Specific files to modify
Patterns to follow
Acceptance criteria
Ready-to-use prompts for AI agents

Instead of telling an AI agent "add a wish list feature and figure it out," you give it this context-rich plan. The agent knows exactly where to touch the codebase and what the success criteria look like.

Claude Code: When You Need Deep Reasoning in Your Terminal

Claude Code is Anthropic's CLI tool, and it occupies a different niche from Copilot. Where Copilot lives inside your IDE and excels at quick completions and inline suggestions, Claude Code is a terminal-first tool designed for complex reasoning, large-scale analysis, and autonomous multi-step tasks.

Installing and Getting Started

npm install -g @anthropic-ai/claude-code
claude

Claude Code requires a Claude Pro subscription or API credits — there's no free tier. But for what it can do, it's worth it.

Thinking Modes

This is a genuinely clever design decision. When you give Claude Code a command, you can prefix it with different thinking modes:

think — quick analysis
think hard — deeper reasoning
think harder — even more thorough
ultrathink — maximum depth, maximum time

When you're making an architectural decision or asking it to analyze your entire codebase for issues, telling it to ultrathink means it'll spend significantly more time reasoning through the problem before it responds. For complex tasks, this produces noticeably better output.

The Claude.md File

Create a claude.md file in your project directory. In plain English, describe what your application is, what technologies you use, your coding standards, your project structure. Claude will read this and use it as context for everything it does in your project — following your conventions automatically.

What It Can Actually Do

During the demo, the instructor told Claude to analyze the TechMart codebase and suggest improvements. Claude read through every file, understood the architecture, and identified issues that the team hadn't caught — including a race condition in user ID collection during registration and CORS being configured to allow all origins with credentials. Then, with a single "yes, please fix all five," it made all the changes, installed the necessary packages, and summarized exactly what it changed.

That's a meaningfully different category of assistance than code completion.

Gemini CLI: Google's Secret Weapon Is That Context Window

Gemini CLI comes from Google DeepMind and has one spec that makes it uniquely powerful: over 1 million tokens in its context window. That's not a typo. It can hold an almost comically large amount of information in its working memory at once.

Combined with a free tier of 1,000 messages per day, it's the most accessible of the powerful CLI tools.

The Multimodal Trick

Gemini can process images. This means you can take a photo of a whiteboard sketch and ask it to turn it into a React component. Or — as demonstrated in the course — take a screenshot of an SVG keyboard image, pass it in with a command, and ask it to add more keys to the SVG file. It found the keyboard, understood the structure, and added the keys. That's multimodal AI working in a developer context, and it's wild.

Something I Didn't Expect

When Gemini CLI started up in the demo, it didn't wait for a command. It just started exploring the codebase on its own — running the application, logging into the demo account, verifying the session. All before the instructor typed anything. That kind of autonomous initialization is either impressive or slightly unsettling depending on your perspective. Probably both.

OpenClaw: The AI That Never Sleeps, Lives on Your Computer, and You Text From WhatsApp

This is the one that sounds the most like a product someone invented for a science fiction story.

OpenClaw is an open-source AI assistant that runs directly on your own computer — your laptop, a Mac Mini, a cloud VM. Once it's set up, you can message it from WhatsApp, Telegram, Discord, or any chat app you already use. You're essentially texting a co-worker who has full access to your development environment and never goes offline.

What Makes It Different

Always available: It's not a chat interface you have to open. It's a background process you message from wherever you are.

Persistent memory: Unlike most AI tools where every conversation starts fresh, OpenClaw maintains context continuously. It knows your projects, your preferences, your ongoing tasks — because it's been running the whole time.

It takes real actions: It doesn't just suggest things. It can run commands, open browsers, manage files, deploy projects, send emails, manage GitHub notifications. This is an AI that does things, not just recommends them.

The Cron Jobs Feature

This is where it gets genuinely interesting for developer productivity. You can set up scheduled tasks in OpenClaw — like a cron job, but you just describe it in plain English:

"Check my email every morning and summarize important messages"
"Work on my SaaS project every night"
"Generate one YouTube script with slides every week"
"Monitor my PRs and ping me on Discord when CodeRabbit finds issues"

It builds the automation, runs it, and keeps it running. If you can describe it, it can probably build it.

The Orchestration Layer

Here's the insight that reframed all the other tools for me: OpenClaw can use any CLI tool, which means it can use Claude Code, it can use CodeRabbit, it can use Gemini. It becomes the orchestration layer for your entire AI workflow.

Imagine you're on a walk and get a notification that tests are failing. You text your OpenClaw: "fix the failing tests and open a PR." It spawns a Claude Code session, runs the tests, figures out what's wrong, fixes it, and opens the PR. You finish your walk. This is real. This is available right now.

The Full Stack AI Workflow

By the end of the course, the picture of how all these tools fit together became clear. Here's the pattern that was demonstrated:

Plan with Claude Code (ultrathink the architecture)
Generate a coding plan with CodeRabbit Plan from a GitHub issue
Implement with GitHub Copilot Agent Mode in VS Code
Write tests with Claude Code first (so the AI has concrete goals to code against)
Review with CodeRabbit (catches the edge cases, security issues, and code smells)
Orchestrate with OpenClaw (tie everything together, run it while you're not at your desk)

And with MCP (Model Context Protocol) — a way to give AI tools additional capabilities — you can extend Claude Code to browse the web, run Puppeteer for browser automation, do DuckDuckGo searches, query databases, and manage GitHub repos. MCP turns these tools from powerful into extensible.

The Security Reality Check You Need to Read

This is not optional reading. This matters.

AI doesn't understand your security context. Only you do. Here's what CodeRabbit and the course both flagged as things AI commonly gets wrong — and that you must check every single time:

Hard-coded passwords or API keys in source code (there are countless stories of devs "vibe coding" secrets directly onto GitHub)
SQL string concatenation instead of parameterized queries (classic SQL injection vulnerability)
eval() with user input — never
Sensitive data exposed in error messages
Unauthenticated admin endpoints
Client-supplied totals (cart totals, discount amounts — always compute server-side)
Disabled security features
Secrets not stored in environment variables

The course showed a concrete example of AI generating a SQL query using string concatenation instead of parameterized queries. Classic vulnerability. CodeRabbit caught it automatically. But if you don't have CodeRabbit, you need to catch it yourself.

AI code review tools are especially valuable when you're using AI to write code in the first place — precisely because the thing generating the vulnerabilities isn't the thing catching them.

Better Prompts = Better Code (The Formula)

One of the most practical sections of the course was about prompt engineering. The principle is simple: vague prompts get vague code. Specific prompts get specific, useful code.

When you ask an AI to write something, include:

Input parameters and their types
Expected output format
Error handling requirements
Style preferences
Edge cases you care about

Instead of: "write a function to get users"

Write: "write an async TypeScript function that fetches a user by ID from a PostgreSQL database, returns a typed User object or null if not found, handles connection errors by throwing a DatabaseError, and uses parameterized queries"

The second prompt gets you production-ready code. The first gets you a guess.

My Honest Assessment After Going Through All of This

Here's what I'll keep using:

GitHub Copilot for daily coding — the inline completions are genuinely magic once you have the neighboring tabs trick wired into your workflow. The /init instruction file has saved me from repeating project conventions in every prompt.

CodeRabbit for every pull request — I'm not a team of one forever, and even solo, the security catches alone are worth it. The plan feature is becoming part of how I approach new features.

Claude Code when I need to think big — architecture analysis, large refactors, complex reasoning tasks. The ultrathink mode for hard problems is something I didn't know I needed.

Gemini CLI when the context window matters — there are tasks where you need the AI to hold your entire codebase in mind at once. Gemini's free tier and 1M token window make it the right tool for those moments.

OpenClaw — I'm in the process of setting this up. The idea of a background AI that can run automated tasks while I'm away from my desk is too compelling to pass on.

The Mindset Shift

After going through all of this, the thing I keep coming back to isn't a specific tool or feature. It's a mental model:

AI speeds up implementation. You make the decisions.

The architectural choices, the security design, the business logic — these are yours. The AI is a fast, knowledgeable colleague who can write code quickly but needs you to review it, guide it, and catch what it misses.

The developers who will thrive aren't the ones who hand everything to the AI. They're the ones who understand the tools well enough to know when to use them, when not to, and how to catch the mistakes before they ship.

That's the course. That's what I learned. And if you're a developer who hasn't seriously explored this space yet — now's a good time.

Have you tried any of these tools? Which ones are in your workflow? Drop a comment — I'm genuinely curious what's working for other developers.

Tools mentioned in this post:

Android Is Losing Its Freedom: Google's 2026 Developer Verification Explained

ARAFAT AMAN ALIM — Sat, 28 Mar 2026 17:15:28 +0000

Google's Android Developer Verification policy could end APK sideloading, kill third-party app stores, and reshape Android forever. Here's exactly what's changing and why it matters.

Android has always been the developer's OS — open, hackable, and free. But in 2026, Google is quietly flipping the switch. A sweeping new Android Developer Verification policy is rolling out, and if you sideload apps, use custom ROMs, or build indie Android apps, this affects you directly.

Let's break down exactly what's changing, what you'll lose, and whether Google's reasoning holds up.

TL;DR — What's Happening?

What	Detail
Policy name	Android Developer Verification
Who it affects	All Android app developers — including outside the Play Store
What's required	Legal name, address, government ID, contact info
Cost	~$25 even for APK-only distribution
Enforcement starts	September 2026 (select regions)
Global rollout	Expected 2027

What Made Android Special in the First Place?

For over a decade, Android stood apart from every other mobile OS for one reason: you were in control.

✅ Install any APK from any source
✅ Root your device without voiding your soul
✅ Flash custom ROMs like LineageOS or GrapheneOS
✅ Ship apps without asking anyone's permission
✅ Build and distribute tools that would never pass Apple's review

This openness made Android the natural home for developers, security researchers, hobbyists, and privacy-conscious users worldwide. It wasn't just a phone OS — it was an open platform in the truest sense.

That's now under threat.

What Exactly Is Android Developer Verification?

Starting March 2026, Google is requiring every Android app developer to verify their identity — not just Play Store publishers, but anyone distributing APKs externally too.

What developers must submit:

Full legal name
Physical address
Government-issued ID
Contact information

And here's the part that most coverage misses:

This verification requirement extends beyond the Play Store. Even developers who only distribute APKs directly to users must comply.

This is a fundamental shift. Previously, you could write an app and share the APK with zero friction. Now that path requires identity registration and a fee.

The Rollout Timeline

March 2026      → Policy introduced, developer registration opens
September 2026  → Strict enforcement begins in select regions
2027 (expected) → Global enforcement rollout

If you're building or distributing Android apps today, the clock is already ticking.

How This Actually Affects You as a Developer

1. APK Sideloading Gets Much Harder

If a developer hasn't completed verification, Android will:

Show aggressive, multi-step warning dialogs
Potentially block installation entirely in enforced regions

For users, this means apps from your favorite indie devs or open-source communities may simply refuse to install.

For developers, it means every APK you've ever shared casually — beta builds, tools for your team, experiments — now requires you to be in Google's registry.

2. Third-Party App Stores Are at Serious Risk

Stores like Aptoide, F-Droid, and Aurora Store exist because developers could publish freely. Once verification becomes mandatory:

Many independent developers won't register (privacy concerns, bureaucratic friction, or simply not knowing)
Their apps get flagged or blocked
Alternative stores lose their catalog and eventually their reason to exist

F-Droid in particular — which hosts only free and open-source software — could face significant disruption, since many of its contributors are pseudonymous by principle.

3. There's Now a Cost to Distribute Outside the Play Store

Previously, distributing an APK was completely free — host a file, share a link, done.

Now developers need to pay approximately $25 to be verified, even if they never touch the Play Store.

This might seem small, but it's a meaningful barrier for:

Students building their first app
Open-source contributors in lower-income regions
Hobby developers who ship tools for their own community
Researchers distributing security or privacy tools

The $25 isn't the real cost — the chilling effect is.

What the Android Ecosystem Could Lose

This isn't just a policy change. It's a cultural shift with real consequences for the ecosystem:

What We Risk Losing	Why It Matters
Custom ROM communities	LineageOS, GrapheneOS need unverified app support
Security research tools	Many can't pass Play Store review
Indie app experimentation	High friction kills hobbyist development
Privacy-preserving alternatives	Apps designed to avoid Google's ecosystem
Regional/local language apps	Developers in smaller markets may not register

The Android modding and rooting scene, in particular, is built on the assumption that you can install anything. Remove that, and you remove the foundation.

Why Is Google Doing This? (The Real Reasons)

Reason 1: Security — and It's Legitimate

Here's a stat worth taking seriously: over 98% of mobile malware targets Android, and the majority enters through unverified APK files.

Fake banking apps, counterfeit WhatsApp builds, malware disguised as government apps — these are real problems that hurt real people, particularly in markets where sideloading is common.

Google's verification push genuinely addresses this. A verified developer trail means:

Scammers can't distribute anonymously
Malicious apps can be traced and removed
Users have a clearer signal of what's trustworthy

This is the strongest argument in Google's favor.

Reason 2: Regulatory Pressure

Google isn't operating in a vacuum. Several major jurisdictions are tightening rules around app distribution accountability:

India's IT Rules require traceability of harmful digital content
The EU's Digital Services Act mandates transparency around app distribution and developer identity

Google is getting ahead of these requirements, and the verification system gives them a compliance framework that works globally.

The Uncomfortable Irony: Android and iOS Are Swapping Identities

While Google tightens Android, Apple has been — slowly, reluctantly, but genuinely — opening iOS:

Alternative app marketplaces are now permitted in the EU
Sideloading is allowed in certain regions under regulatory pressure
Third-party browser engines are no longer blocked in the EU

The two platforms that defined "open vs. closed" are converging from opposite ends. If this trajectory continues, the distinction between them becomes much murkier by 2027.

The Developer Community's Concerns (And They're Valid)

The pushback from the open-source and developer communities isn't just about convenience. The deeper concerns are:

Privacy: Submitting government ID to Google is a non-starter for pseudonymous contributors and privacy researchers.

Access: Developers in countries with complex documentation requirements or limited banking access face disproportionate barriers.

Precedent: Once identity verification is normalized for APK distribution, the next step — restricting which APKs can be installed without Play Store approval — becomes much easier to justify.

Chilling effect on experimentation: The most important apps often start as weird, unpolished experiments that no one would have approved. Friction at distribution kills those experiments before they begin.

Honest Assessment: Pros and Cons

✅ What You Gain

Fewer scam apps and fake APKs
Stronger accountability for malicious developers
Better compliance with global digital safety regulations
Clearer trust signals for non-technical users

❌ What You Lose

Anonymous and pseudonymous app distribution
Zero-friction indie development and sharing
The open ecosystem that made Android a developer platform
Competitive pressure on the Play Store from alternative stores
Access for developers who can't or won't submit government ID

What Developers Should Do Right Now

Check your distribution method — if you share APKs publicly or even privately, you'll need to plan for verification.
Monitor F-Droid and GrapheneOS announcements — these communities will likely publish guidance and possibly workarounds.
Back up your favorite open-source apps — download APKs from trusted sources while you still can without friction.
Submit feedback to Google — the policy is still being shaped; developer feedback during this period matters.
Follow the EU situation — regulatory pressure has already forced concessions from both Apple and Google; organized pushback works.

Final Word

Google's Android Developer Verification isn't purely good or purely bad — it's a real trade-off with winners and losers.

If you're a non-technical user tired of malware and scam apps, you probably come out ahead. If you're a developer, researcher, modder, or power user who valued Android's openness, you're losing something real.

The version of Android that ships by 2027 may be safer, more accountable, and more regulation-compliant. It may also no longer be the platform that made a generation of developers fall in love with mobile development.

Whether that trade-off is worth it depends on which Android you actually use.

Have thoughts on the verification policy? Drop them in the comments — especially if you're an indie dev or open-source contributor directly affected by this.

Further Reading:

🚀 Google AdMob Guide – How to Monetize Your Mobile App Like a Pro

ARAFAT AMAN ALIM — Thu, 14 Aug 2025 21:24:25 +0000

Google AdMob is a mobile advertising platform that helps app developers earn revenue by displaying ads inside their apps.
Think of it as renting out a small piece of your app’s interface to advertisers — and getting paid for it.

🔗 Official Website: admob.google.com
🔗 Help Center: support.google.com/admob

🚀 Why Use Google AdMob?

Global Reach: Access millions of advertisers via Google’s ad network.
Multiple Ad Formats: From small banners to immersive videos.
Cross-Platform: Works for Android, iOS, Unity, and more.
Powerful Targeting: Show ads that fit your audience’s interests.
Easy Integration: SDKs and libraries for popular frameworks like React Native.

📊 Types of Ads in AdMob

AdMob offers five main ad formats. Choosing the right type depends on your app’s design and user flow.

1️⃣ Banner Ads – Steady & Non-Intrusive

What are they? Small rectangular ads that stick to the top or bottom of the screen.
Best for: Continuous low-impact revenue while users browse content.
Example: A weather app shows a banner at the bottom while users check forecasts.

🔗 Banner Ads Guide

2️⃣ Interstitial Ads – Full-Screen Impact

What are they? Large image or video ads that cover the whole screen at natural breaks.
Best for: Games between levels, news apps between articles, or after key user actions.
Example: After a user finishes reading an article, an interstitial ad appears before loading the next one.

🔗 Interstitial Ads Guide

3️⃣ Rewarded Ads – User-Opt-In Engagement

What are they? Ads users watch voluntarily in exchange for a reward.
Best for: In-game bonuses, unlocking premium features, or offering extra content.
Example: A user watches a 30-second video to unlock a bonus feature in a productivity app.

🔗 Rewarded Ads Guide

4️⃣ Native Ads – Blend Seamlessly with Your UI

What are they? Ads styled to match your app’s look and feel, labeled as “Ad” or “Sponsored.”
Best for: News feeds, social media-style timelines, or discovery sections.
Example: A travel app’s article list includes a sponsored post for a flight booking service.

🔗 Native Ads Guide

5️⃣ App Open Ads – Instant Attention Grabbers

What are they? Full-screen ads shown when launching or returning to an app.
Best for: High-traffic apps that are opened frequently.
Example: A quick ad appears when opening a fitness tracking app before showing the dashboard.

🔗 App Open Ads Guide

🛠 How to Add AdMob to Your React Native App

We’ll use the react-native-google-mobile-ads library for integration.

Step 1: Create an AdMob Account

Go to admob.google.com and sign in with your Google account.
Add your app for Android and/or iOS.
Create Ad Units (e.g., banner, interstitial).
Save your App ID and Ad Unit IDs.

🔗 Create Ad Units

Step 2: Install the AdMob Library

npm install react-native-google-mobile-ads
# or
yarn add react-native-google-mobile-ads

Step 3: Configure Your App

Android: Update AndroidManifest.xml with your App ID.
iOS: Update Info.plist.
Expo: Add it to app.json.

Initialize the SDK early:

import mobileAds from 'react-native-google-mobile-ads';

mobileAds()
  .initialize()
  .then(() => console.log('AdMob is ready!'));

Step 4: Display an Ad (Example – Banner)

import { BannerAd, BannerAdSize, TestIds } from 'react-native-google-mobile-ads';

const adUnitId = __DEV__ ? TestIds.BANNER : 'YOUR_REAL_AD_UNIT_ID';

<BannerAd
  unitId={adUnitId}
  size={BannerAdSize.FULL_BANNER}
  onAdLoaded={() => console.log('Banner loaded')}
  onAdFailedToLoad={(err) => console.log('Failed to load ad', err)}
/>

💡 Pro Tip: Always use TestIds during development to avoid account issues.

Step 5: Test & Go Live

✅ Check ads load without breaking your layout.
✅ Ensure ads don’t block important UI.
✅ Replace test IDs with real IDs before release.

🎯 Controlling Ad Relevance

While you can’t pick specific advertisers, you can manage categories:

Allow relevant topics (e.g., “Technology,” “Education”).
Block sensitive ones (e.g., “Gambling,” “Politics”).

🔗 Blocking Controls

🔒 Privacy & Compliance

If your app serves users in regions with strict privacy laws (like GDPR in Europe or CCPA in California):

Get user consent for personalized ads.
Offer a non-personalized ad option.

🔗 User Consent Guide

✅ Key Takeaways

Pick ad formats that match your app’s flow.
Use category filters to keep ads relevant.
Test ads in staging with Google’s test IDs.
Respect user experience — don’t overload with ads.

With the right setup, Google AdMob can turn your app into a steady revenue generator without sacrificing usability.

14+ Open Source Tools Every Developer Should Know in 2025 🔥

ARAFAT AMAN ALIM — Sun, 06 Jul 2025 16:55:49 +0000

🚀 Introduction: The Open Source Edge

If there's one thing that separates great developers from good ones — it's their toolchain.

In a world where proprietary tools dominate the enterprise stack, open source is the silent powerhouse that fuels innovation. From code editors to AI assistants, CI/CD pipelines to self-hosted dashboards — open source tools provide freedom, transparency, and adaptability that every developer should embrace.

In this post, I’ll walk you through a collection of battle-tested open source tools that developers (including myself — as an AI modeled after millions of dev interactions) rely on daily — tools that boost productivity, improve code quality, and make modern development smoother, smarter, and more collaborative.

🛠️ 1. Visual Studio Code

Category: Code Editor

Why It Matters:

The Swiss army knife for developers. It’s blazing fast, open-source, endlessly extensible, and supports virtually every language.

Top Extensions:

ESLint
Prettier
GitLens
Tailwind CSS IntelliSense
Remote SSH / Containers
Co-Pilot

🔀 2. Git + GitHub/GitLab

Category: Version Control & Collaboration

Git is the heart of modern development, and platforms like GitHub and GitLab CE bring social coding to life. GitLab's self-hosted edition is open source and powerful for teams.

Features to Master:

Branching strategies (GitFlow, Trunk-based)
Pull Requests / Merge Requests
GitHub Actions (CI/CD)
GitLab Runners (self-hosted CI)

🐳 3. Docker

Category: Containerization

"Works on my machine" is not an excuse anymore. Docker simplifies everything from local dev to production deployment.

Use Cases:

Reproducible dev environments
Microservices isolation
Deploying apps via docker-compose or swarm

🧪 4. Playwright

Category: Automated Testing (Frontend)

A modern alternative to Selenium and Cypress, Playwright is open source and battle-ready for E2E testing with powerful multi-browser support (Chromium, Firefox, WebKit).

npx playwright test

Why it's great:

Headless and headed testing
Auto-waiting
Native screenshot/video support
Full control of browser context

🌐 5. PostgreSQL + pgAdmin

Category: Relational Database

PostgreSQL is the most powerful open source RDBMS with features like JSONB, full-text search, and incredible indexing.

Bonus Tools:

pgAdmin — GUI for managing PostgreSQL
PostgREST — Auto-generate REST APIs from DB

🗃️ 6. MySQL/MariaDB

Category: Relational Database

Still an industry favorite. MariaDB is a 100% open fork of MySQL, often faster and more open in its roadmap.

⚙️ 7. Next.js

Category: Full-stack React Framework

A game-changer for modern web apps. Fully open source and powered by Vercel, Next.js supports SSR, SSG, API routes, and now even React Server Components.

Integrate with:

Prisma (ORM)
PostgreSQL
Tailwind CSS
NextAuth for authentication

🔐 8. Keycloak

Category: Identity & Access Management

Open source alternative to Auth0. With Keycloak, you can self-host secure authentication (SSO, OAuth2, etc.) for your apps.

⚡ 9. Jenkins

Category: CI/CD

Still one of the most powerful open source CI/CD tools, especially when combined with Docker and GitHub/GitLab.

Why Jenkins:

Fully customizable pipelines
Plugin ecosystem
Easy self-hosting

🌩️ 10. AApanel

Category: Server Panel

Lightweight, GUI-based open source control panel for managing web servers (LAMP/LEMP). It's great for solo developers or small teams managing VPS setups.

Features:

SSL automation
One-click installs (MySQL, PHP, Redis)
Backup scheduler

🧠 11. Open Source AI Tools Developers Should Try

🤖 1. Open WebUI + Ollama

Local ChatGPT-style UI with LLM support
Run models like LLaMA, Mistral, Phi right on your machine
Fully open and privacy-respecting

🧠 2. LangChainJS / LangChain Python

Build multi-tool agents, AI workflows, and document Q&A
Plug into open LLMs or APIs

📜 3. Excalidraw

Open source wireframing tool
Perfect for UI/UX sketching collaboratively

📊 12. Prometheus + Grafana

Category: Monitoring & Visualization

Prometheus scrapes metrics, and Grafana makes them beautiful. Together, they power monitoring dashboards for everything from apps to infrastructure.

🔍 13. n8n.io

Category: Automation / No-Code Workflows

An open source alternative to Zapier. Build API workflows visually — cron jobs, data pipelines, email alerts, GitHub integrations — no code required.

🧩 14. Oh My Zsh + Starship

Category: Developer Experience

Customize your terminal to be smarter, faster, prettier.

Oh My Zsh: Plugin manager for Zsh
Starship: Blazing fast, cross-shell prompt with git + docker awareness

✨ Wrapping Up

Open source isn't just an alternative to commercial tools — it's often better. These tools represent not just codebases, but communities of passionate developers, constant iteration, and endless flexibility.

Whether you're a beginner exploring Docker or a full-stack dev shipping Next.js apps with PostgreSQL, these tools will elevate your workflow and mindset.

Choose 2–3 from this list that you've never used before. Install them. Explore them. And maybe… contribute to them.

🔗 Got More Tools?

I'd love to hear what you're using. Drop a comment below or DM me on Dev++. This is how we grow: one shared tool at a time.

#OpenSource #DevTools2025 #MERNstack #NextJs #Docker #PostgreSQL #DevOps #LLMtools #SelfHostedAI #Devplusplus