DEV Community: Chandrabhan Shekhawat

AI and Your Privacy: What Really Happens to the Data You Paste ·

Chandrabhan Shekhawat — Thu, 16 Jul 2026 21:39:33 +0000

You’ve got a messy spreadsheet of customer emails, a confidential contract, or a chunk of your company’s code, and an AI chatbot that could sort it out in seconds. So you paste it in.

Pause for a moment: where did that data just go?

This isn’t a “be scared of AI” article. It’s a “know what you’re doing” article — because the honest answer is it depends, and the difference matters a lot.

Paste is a send

Here’s the mental model that fixes most privacy mistakes: with a cloud AI chatbot, pasting is uploading. The text doesn’t stay on your device. It travels to a company’s servers, gets processed there, and the reply travels back.

That’s not sinister — it’s just how cloud software works. But it means the moment your data leaves your screen, it’s subject to that company’s policies, security, and jurisdiction, not yours. For a joke or a blog draft, who cares. For a client’s contract or a customer database, that’s a real decision you just made in half a second.

What providers may do with it

Policies vary wildly between providers and between their free and paid tiers, so always check the specific one you use. But in general, be aware that pasted data may be:

1. Retained for some period — for abuse monitoring, debugging, or support.
2. Reviewed by humans in some cases, to improve the service.
3. Used to train future models, depending on the product and your settings. Consumer/free tiers are more likely to do this; business and API tiers often don’t by default. None of that is necessarily bad. But “I pasted our salary data into a free chatbot” is the kind of sentence that ends up in an incident report. Assume anything you paste into a cloud tool could be seen by someone else, and decide accordingly.

The things you should basically never paste

Regardless of provider, keep these out of chatbots unless you’re certain of the terms and have permission:

1. Secrets and credentials — API keys, passwords, tokens, private keys. If you’re sharing code to debug, strip these first. Our secret scanner catches keys and tokens hiding in a snippet before you share it.
2. Personal data of other people — customer lists, health info, anything covered by privacy laws.
3. Confidential or contractual material you don’t own the rights to share.
4. Hidden metadata. Images quietly carry EXIF data — GPS location, device, timestamps. If you’re sharing a photo, run it through our metadata remover first so you’re not leaking where it was taken. A good filter: If this leaked publicly tomorrow, would I be fine with it? If not, don’t paste it into a cloud tool.

On-device beats cloud — when you can get it
Here’s the quiet superpower most people miss: not all “AI” or file work needs the cloud at all. A surprising amount can happen entirely inside your browser, on your own device, where the data never leaves.

That’s the whole idea behind how we build Gigai’s tools: compressing an image, converting a PDF, cleaning metadata, formatting JSON — all of it runs locally in your browser, so your files are never uploaded, stored, or logged. Gigai Smart Assist works the same way: you hand it a file and a goal, and it does the work on your device. When something genuinely needs a server for a better result, the honest approach is to tell you and let you choose — not to quietly ship your data off.

The principle generalizes: prefer the tool that processes locally. If two tools do the same job and one keeps your data on your machine, that one wins every time.

A 30-second privacy checklist

Before you paste anything into an AI tool, run this:

1. Is it sensitive? Secrets, personal data, confidential material → stop.
2. Whose data is it? If it’s not yours to share, don’t.
3. Do I know this provider’s policy? Check whether free-tier inputs train the model; turn that off if you can.
4. Could this be done on-device instead? If a local/browser tool does the job, use it.
5. Would I be fine if this leaked? If not, keep it off the cloud.

The bottom line

AI tools are genuinely useful, and you don’t need to be paranoid to use them. You just need to remember that convenience and privacy are a trade you’re making every time you paste — and make that trade on purpose.

Know what leaves your device. Keep the sensitive stuff off the cloud. Prefer tools that process locally. Do that, and you get almost all of the upside with very little of the risk.

New to how these systems actually work? Start with how large language models work, then read how to use AI without losing your own judgment — together they’ll make you calmer and sharper about the whole thing.

Regular Expressions Without the Fear: A Working Mental Model

Chandrabhan Shekhawat — Tue, 14 Jul 2026 08:33:33 +0000

Regular expressions look like line noise and scare off people who would benefit most from them. With the right mental model, they become one of the most useful skills you can learn in an afternoon.

Regular expressions have a reputation. To the uninitiated they look like a cat walked across the keyboard: ^\d{3}-\d{4}$ means something, apparently, but what? That intimidation keeps a lot of capable people from learning one of the highest-leverage skills in everyday computing. The truth is that regular expressions are not hard. They are just dense. Once you have the mental model, the density stops being scary and starts being useful.

What a regular expression really is

A regular expression, or regex, is a pattern that describes a shape of text. That is the whole idea. You are not writing code that runs step by step; you are describing what matching text looks like, and a matching engine finds every piece of text that fits the description.

“A five-digit number.” “An email address.” “Any line that starts with a capital letter.” “The word 'colour' spelled either the British or American way.” Each of those is a shape, and each can be written as a pattern. When you read a regex, translate it back into a plain-English shape and it stops being noise.

The handful of ideas that cover most cases
You do not need the whole language to be productive. A small core does most of the work.

Literal characters match themselves. The pattern "cat" matches the letters c, a, t in order.
Character classes match one of a set. "[aeiou]" matches any single vowel; "\d" matches any digit.
Quantifiers say how many. "+" means one or more, "*" means zero or more, and "{3}" means exactly three.
Anchors tie the pattern to a position. "^" means the start, "$" means the end.
Groups, written with parentheses, bundle parts together so a quantifier or an alternative applies to the whole bundle.
With just those, ^\d{3}-\d{4}$ decodes cleanly: start, exactly three digits, a hyphen, exactly four digits, end. It is a phone-number-ish shape. Not so frightening once you read it in pieces.

Where it pays off

Regex earns its keep the moment you need to find, validate, or transform text at scale. Searching a large document for every date, or every email address, or every price. Validating that user input looks like a postcode or a URL before you accept it. Doing a find-and-replace that is smarter than an exact string, like “replace every run of multiple spaces with a single space.” Extracting the interesting fragments out of messy log files or exported data.

Anywhere you would otherwise do the same tedious text edit fifty times by hand, a regex does it once.

Build patterns by describing, then testing

The productive way to write a regex is not to type it perfectly from memory. It is to describe the shape you want, generate a first draft, and then test it against real examples, tightening as you go.

Start by describing your target in words and letting the Regex Generator turn that description into a pattern. Then paste in real sample text and watch what matches, adjusting live, with the Regex Tester. The test-and-refine loop is where understanding actually forms; you learn far more from seeing why a pattern matched one line and missed another than from reading a reference.

The traps worth knowing early

Two mistakes catch everyone at first. The first is greediness: quantifiers grab as much as they can by default, so a pattern meant to match one short span can swallow half the line. The second is forgetting that some characters are special. A dot means “any character,” so to match a literal full stop you have to escape it. When a pattern behaves strangely, these two are the usual suspects.

And one piece of wisdom the veterans share: do not try to validate genuinely complex formats, like every legal email address on earth, with one monstrous regex. Match the common, sensible shape and let the rare edge cases fall to other checks. A readable pattern that handles the real ninety-nine percent beats an unreadable one that theoretically handles everything and that no one, including you, can ever modify again.

*A skill that compounds
*

A worked example, from words to pattern

Say you want to find every date written like 2026-03-14 in a document. Start by describing the shape in plain words: four digits, a dash, two digits, a dash, two digits. Now translate each piece. Four digits is "\d{4}". A literal dash is just a dash. Two digits is "\d{2}". Stitched together you get \d{4}-\d{2}-\d{2}, and reading it back confirms it matches the shape you described.

Then test it against real lines and watch what happens. You will notice it also matches something like 99999-99-99, which is not a real date. If that matters, you tighten, perhaps by anchoring the pattern so it must sit on its own with "^" at the start and "$" at the end, or by narrowing the first digit. This is the whole loop: describe, draft, test, tighten. Doing it live in the Regex Tester is far more instructive than staring at the pattern, because you learn from watching exactly what it catches and what it lets through.

Regex is one of those rare skills that pays off across every tool and language you will ever touch. Text editors, search boxes, spreadsheets, programming languages, and countless utilities all speak some dialect of it. Learn the small core once, practise by testing against real text, and you gain a quiet superpower: the ability to describe a shape of text and act on every instance of it at once. An afternoon of deliberate practice, and the line noise turns into a language you can read.

I Built an AI Feature Without Using ChatGPT — Here’s Why

Chandrabhan Shekhawat — Fri, 10 Jul 2026 03:45:00 +0000

Artificial Intelligence is everywhere.

Every new product proudly announces, “Powered by ChatGPT.”

But when I started building AI features for real applications, I realized something important:

ChatGPT isn’t the only way to build AI-powered software.

In fact, some of the best AI features I’ve built don’t use ChatGPT at all.

The Problem

A client wanted an AI assistant inside their application.

The obvious solution seemed simple:

User → OpenAI API → Response

It worked.

Until we started asking the difficult questions.

What happens if thousands of users use it simultaneously?
What about API costs?
Can users’ private data leave our servers?
What if the internet is unavailable?
Can we switch AI providers later?

Those questions completely changed our architecture.

AI Is Bigger Than One Model

Many developers think AI equals ChatGPT.

It doesn’t.

ChatGPT is an application.

The real building blocks are Large Language Models (LLMs), and today developers have several excellent choices.

Depending on the project, we’ve used:

OpenAI
Google Gemini
Gemini Nano
Local models
Hybrid AI architectures

Each solves different problems.

The Architecture We Chose

Instead of connecting users directly to an AI model, we added an intelligent layer between them.

User
│
▼
Frontend
│
▼
Backend API
│
▼
Validation
│
▼
Context Builder
│
▼
AI Model
│
▼
Response Validation
│
▼
User

This gave us complete control.

We could change prompts, validate input, sanitize sensitive data, cache responses, log errors, and even switch AI providers without changing the frontend.

Why We Didn’t Depend on ChatGPT

ChatGPT is an amazing product.

But building production software requires thinking beyond one provider.

By designing around an AI interface instead of a single API, we gained several advantages:

Easier model switching
Better privacy controls
Lower operational costs
More predictable responses
Better monitoring
Future flexibility

Our application became AI-powered—not provider-dependent.

One Feature Changed Everything

One of my favorite implementations was an AI content assistant.

Instead of asking users to write from scratch, the application generated structured drafts based on context already available inside the system.

Users spent less time typing.

The AI wasn’t replacing people.

It was removing repetitive work.

That’s where I think AI creates the most value.

The Biggest Lesson

The hardest part of building AI isn’t calling an API.

It’s designing everything around it.

The questions that matter are:

What context should the model receive?
What information should never reach the model?
How should responses be validated?
What happens when the AI is wrong?
How do you measure quality over time?

Those are engineering problems—not AI problems.

Looking Ahead

The future of software isn’t about adding an “Ask AI” button to every screen.

It’s about designing products where AI quietly helps users complete tasks faster, more accurately, and with less effort.

Sometimes that means using OpenAI.

Sometimes it means using Gemini.

Sometimes it means running AI directly on the user’s device.

The technology will continue to evolve.

Good software architecture will always matter.

⸻

Final Thought

The biggest mistake developers make is asking:

“Which AI model should I use?”

A better question is:

“What problem am I trying to solve?”

Once you answer that, choosing the right AI becomes much easier.

The Django Mistake That Made My API 20 Slower (And How I Fixed It)

Chandrabhan Shekhawat — Wed, 08 Jul 2026 20:43:44 +0000

If you’ve been working with Django for a while, you’ve probably experienced this.

Your API works perfectly in development.

You test it with a few records.
Everything feels fast.

Then one day production data arrives.

Suddenly an endpoint that used to respond in 300ms now takes 6–10 seconds.

That happened to me.

The Problem

I had an API returning a list of companies along with their owners and projects.

The code looked completely normal.

companies = Company.objects.all()
data = []
for company in companies:
data.append({
"name": company.name,
"owner": company.owner.name,
"projects": [project.name for project in company.projects.all()]
})

Nothing looked suspicious.

Yet the endpoint became painfully slow as the database grew.

What Was Actually Happening?

Every time the loop executed, Django performed additional database queries.

One query fetched the companies.

Another query fetched the owner.

Another query fetched the projects.

If there were 500 companies, Django wasn’t executing 3 queries.

It was executing more than 1,000 queries.

This is known as the N+1 Query Problem.

Many developers unknowingly ship this to production because everything appears fast with a small development database.

How I Found It

The first thing I checked wasn’t the Python code.

It was the SQL queries.

Using Django Debug Toolbar, I discovered the API was generating hundreds of nearly identical SQL statements.

Instead of asking the database once, Django kept asking the same question repeatedly.

The Fix

The solution was surprisingly simple.

Instead of letting Django fetch related objects one by one, I told it to fetch everything in advance.

companies = (
Company.objects
.select_related("owner")
.prefetch_related("projects")
)

Now the rest of the code stayed exactly the same.

No major refactoring.

No caching.

No Redis.

Just better ORM usage.

Why It Works

select_related() performs SQL joins for ForeignKey and OneToOne relationships.

prefetch_related() performs efficient separate queries for Many-to-Many and reverse relationships, then joins the data in Python.

The result?

Instead of executing hundreds of queries, Django executes only a handful.

The Result

Before:

1,043 SQL queries
Response time: 8.4 seconds

After:

3 SQL queries
Response time: 320ms

That’s more than a 20× improvement without changing the database schema or adding any caching.

When Should You Use It?

Use select_related() for:

ForeignKey
OneToOneField

Use prefetch_related() for:

ManyToManyField
Reverse ForeignKey relationships

Choosing the right method can dramatically reduce database traffic.

Final Thoughts

One of the biggest lessons I’ve learned after years of building Django applications is this:

Performance problems often aren’t caused by slow databases.

They’re caused by asking the database the same question hundreds of times.

Before introducing caching, Redis, Celery, or expensive infrastructure, inspect your SQL queries.

Sometimes the biggest performance improvement comes from changing a single line of Django ORM code.

⸻

Have you ever encountered an N+1 query problem in Django? I’d love to hear how you discovered it and what you did to fix it.

Gigai Tools — Every tool you need, in one place.

Chandrabhan Shekhawat — Sat, 04 Jul 2026 06:32:01 +0000

Gigai Tools is a free, all-in-one platform of 240+ online tools that run entirely in your browser — no sign-up, no watermarks, and nothing to install.

Instead of juggling a dozen different websites, you get everything in one place across nine categories:

Link :- https://tools.gigaikripaservices.com/

🖼️ Image — compress, convert, resize, crop, remove backgrounds
📄 PDF — merge, split, compress, edit text, convert, sign, protect
💻 Developer — JSON/SQL/HTML formatters, JWT decoder, hash & UUID generators, regex tester
🔳 QR Code — a full QR studio with logos, colors, WiFi/vCard/UPI codes, plus a scanner
🔍 Website & SEO — meta tags, schema markup, sitemaps, robots.txt, SERP preview
✒️ SVG — optimize, convert to React/CSS, generate blobs, waves and patterns
📁 Document — CSV/Excel/Markdown converters, viewers and editors
🎬 Video — compress, convert, trim, and turn videos into GIFs
🎧 Audio — trim, convert, record, make ringtones and more
What makes Gigai Tools different is privacy: because the tools process your files locally in your browser, your images, PDFs and data never get uploaded to a server. That means it's faster (no waiting on uploads), safe even for sensitive files, and there are no accounts, no limits, and no ads inside the workspace.

Whether you're a developer formatting JSON, a designer optimizing SVGs, a marketer building QR campaigns, a student converting documents, or someone who just needs to compress a PDF once — Gigai Tools gives you a fast, clean, privacy-first toolkit that just works.

Free forever. No sign-up. 240+ tools and growing.