DEV Community: PRANTA Dutta

I made Snake. Then I kept going.

PRANTA Dutta — Fri, 15 May 2026 14:44:42 +0000

So here's a thing that happened.

A few months ago I thought, "I should build a small Flutter game to sharpen up my custom painter / animation chops. Something simple. A weekend project." I picked Snake. The 1997 Nokia kind. Eat the dot. Don't hit the wall. Don't eat yourself. That's the entire game.

That was a few months ago. I now have:

A multiplayer Snake matchmaking system.
A tournament platform with six game modes.
A frame-by-frame replay viewer.
A push notification backend in FastAPI.
Sixteen achievements with a rarity system.
A friends list with online presence.

For Snake.

This is its story.

What it actually is

The project is called Snake Classic, and you can find the source on GitHub. It's a Flutter app targeting Android, iOS, web, and desktop. The core game is exactly what you remember — 20x20 grid, snake, food, walls, regret. 60 FPS, custom painter, smooth swipe gestures. About a weekend of work.

The other 95% of the codebase is what happened after that.

Here's a tour of the over-engineering, in roughly the order I built things.

"I should add themes"

The very first slippery slope. Snake is monochrome by tradition, but Flutter makes it so easy to swap palettes that I added a "Modern" theme alongside Classic. Then Neon, because I wanted to play with glow effects. Then Retro for the vintage vibe. Then I thought "the snake should travel through space," so Space. Then Ocean, because at that point why not.

Six themes. With a dedicated theme selector screen. With live previews. For Snake.

"I should add sound"

audioplayers package, three sound effects, done. Except now there's a crash sound, a food_eat sound, a level_up sound, a button_click sound, a high_score sound, and background music with independent volume controls. There is more audio engineering in this app than in some games I've actually paid money for.

"I should add a high score"

This is where it really started.

A local high score is just SharedPreferences. Easy. But what if you play on two devices? Need to sync. So Firebase Auth. Anonymous accounts for guests. Google Sign-In for people who want their score preserved. A migration flow to upgrade a guest account to a real one without losing data.

And if I have user accounts, I might as well have leaderboards. Global. Weekly. Friends-only with podium displays. That requires a Firestore schema, real-time listeners, pagination.

And if I have friends, I need a friends system. Search by username. Send requests. Accept/decline. Online status indicators ("playing", "online", "offline"). Username reservation logic so two people don't grab the same name.

For Snake.

"It would be cool if you could replay your best game"

Reader, this is where a normal person stops.

I built a frame-by-frame recording system that captures the full game state every tick. Compresses it. Uploads it to Firebase. There's a replay browser organized by "Recent", "Best Performances", and "Crash Analysis". You can scrub the timeline. You can change playback speed. You can analyze why you crashed — wall collision vs. self-collision, with visual indicators.

Imagine telling someone in 1997 that one day they'd be able to slow-mo a replay of their Snake death and study it like Zapruder film.

"Multiplayer would be fun"

Two snakes. Same board. Firebase Realtime Database for live state sync. Quick match for instant pairing. Private rooms with shareable codes. Lobby UI with player ready states. Four game modes for multiplayer specifically. Cross-device, so you can play your friend on iOS while you're on web.

I have not actually convinced anyone to play it against me yet. The matchmaking system works fine. It's just that no one has matchmade.

"What if there were tournaments?"

Daily challenges. Weekly championships. Monthly events. Six tournament game modes including "Perfect Game" (one mistake and you're out) and "Power-up Madness" (chaos). Real-time tournament leaderboards. Tournament rewards. A tournament history screen.

Yes — I implemented power-ups too. Four of them: Speed Boost, Invincibility, Score Multiplier, Slow Motion. Each with a circular progress timer in the HUD. Each rendered differently per theme.

"Achievements"

Sixteen of them. Four rarity tiers from Common to Legendary. Categories for Score, Games Played, Survival, and Special Feats. Animated unlock notifications with particle effects. A browser screen with filtering. Progress bars on locked ones.

Achievement Unlocked: Scope Creep Survivor (Legendary)
Build a side project that grew 50x larger than you planned and still ship it.

(That one's not in the game. Yet.)

"Push notifications"

This is where I crossed a real line.

I wrote a separate Python backend. FastAPI. APScheduler for scheduled notifications. Firebase Admin SDK on the server side. Pydantic for validation. A whole notification service running independently so the game can ping you about "tournament starting in 1 hour," "your friend challenged you," "you haven't played in 3 days, here's a comeback bonus."

The notification_backend/ folder has its own README. Its own requirements.txt. Its own test suite. It is, by any reasonable definition, a microservice.

For a Snake game.

"I should add a statistics dashboard"

50+ tracked metrics. Games played, average score, survival rate, food consumption patterns, power-up usage breakdowns, collision analysis, streak tracking, session length distributions. Performance trend charts. AI-generated insights based on your play patterns.

I know more about how the average user plays my Snake game than most apps know about anything.

So what did I actually learn?

This sounds like a self-roast, and it kinda is, but I want to be real about why this is actually fine.

1. Snake is a perfect scaffolding for learning everything. The game loop is trivial, which means you can pour all your energy into the systems around it. Firebase auth flows, real-time multiplayer, push notification deep linking, replay encoding — every single one of these is a transferable skill I now have working production code for. Try learning Firebase Realtime Database multiplayer on a side project you also care about creatively; you'll get demoralized. On Snake, the stakes are zero. You just ship.

2. Premature features are still real practice. Did I need power-ups in Snake? No. But building the power-up timer system taught me a clean pattern for time-bound state in Flutter that I've already reused in a different app. The replay system gave me a battle-tested approach to compressing time-series state. The tournament system is just a CRUD app with extra steps, but that scheduling code is good.

3. Side projects don't need to be "minimum viable." They need to be fun to work on. The "MVP" doctrine is great when you have customers waiting. When the customer is just you trying to keep yourself engaged for six months, "Wouldn't it be funny if Snake had a tournament system" is a valid product decision.

4. The architecture got better the bigger it got. Look at the project structure — clean separation of models/, providers/, services/, screens/, widgets/. Beautiful debug logging with Talker categorized by service. Offline-first data sync with a queue. Stuff I would have hand-waved past in a weekend project, but had to do correctly once the system got big. The big system forced the discipline.

The code

It's all open source — github.com/theprantadutta/snake_classic. MIT licensed. 97.8% Dart per GitHub. Fork it, study it, laugh at it, learn from it. The README has setup instructions, screenshots, the works.

If you've been sitting on a side project that you keep dismissing as "too simple," I'd gently suggest: build the simple thing. Then keep going. See how far it goes. The detour is the point.

I built Snake. Then I kept going. You should too.

I write about Flutter, full-stack dev, server ops, and apparently now confessional posts about over-engineering. Follow along at pranta.dev or here on Dev.to.

No, the AI didn't compromise your npm packages. You did.

PRANTA Dutta — Fri, 15 May 2026 14:29:43 +0000

Okay, story time. Last Tuesday I'm scrolling Twitter (sorry, "X", whatever) and I see the fifth take of the week along the lines of:

"AI is destroying software security. The Shai-Hulud worm proves AI is dangerous."

And I'm sitting there like… my brother in Christ, the worm is literally called Shai-Hulud. It's named after the giant sandworm in Dune. A worm. That eats things. Through a desert. That is exactly the level of subtlety we're operating at, and you're telling me ChatGPT did this?

Look. I've spent the last few weeks reading every Socket, Aikido, Wiz, Snyk, Unit 42, and Microsoft writeup on Shai-Hulud 1.0, Shai-Hulud 2.0, Mini Shai-Hulud, Sha1-Hulud: The Second Coming (yes that's a real name), SANDWORM_MODE, PhantomRaven, and the s1ngularity/Nx mess that started it all. I'm a full-stack dev. I ship Flutter apps, I run my own VPS, I publish to npm occasionally, and I use AI tools every single day. So let me say this with my whole chest:

The AI did not do this. We did this. We have been doing this. We will keep doing this. The AI just made it slightly easier to do this faster.

Let me actually walk through what happened so we can stop being weird about it.

Part 1: A quick recap of the dumpster fire so far

The npm ecosystem has been getting absolutely cooked since August 2025. Here's the speedrun:

August 26, 2025 — The s1ngularity / Nx attack

Attackers exploited a GitHub Actions injection vulnerability in the Nx repo, stole their npm publishing token, and pushed eight malicious versions of nx and related packages to npm over four hours. The malware ran a postinstall script called telemetry.js (cute) that scanned your filesystem for .env files, SSH keys, crypto wallets, and npm tokens.

But here's the genuinely interesting part — and the part that everyone should have been screaming about: it was the first attack to weaponize local AI CLIs. The malware checked if you had Claude Code, Gemini CLI, or Amazon Q installed, and if you did, it ran them with the safety pins pulled out:

const cliChecks = {
  claude: { cmd: 'claude', args: ['--dangerously-skip-permissions', '-p', PROMPT] },
  gemini: { cmd: 'gemini', args: ['--yolo', '-p', PROMPT] },
  q:      { cmd: 'q',      args: ['chat', '--trust-all-tools', '--no-interactive', PROMPT] }
};

--dangerously-skip-permissions. --yolo. --trust-all-tools. These are flags that exist for a reason — and that reason is "you, the developer, are taking responsibility for whatever happens next." The attackers used those flags because we normalized using those flags. The malware then exfiltrated everything to a public GitHub repo called s1ngularity-repository containing a results.b64 file with double-base64-encoded secrets, made shutdown commands get appended to your .bashrc and .zshrc (so your terminal would shut down your machine on launch, lol), and called it a day.

Final scoreboard: 2,349 secrets stolen from 1,079 systems, including GitHub tokens, AWS keys, OpenAI keys, Anthropic keys, the works. 85% of victims were on macOS. About half had at least one AI CLI installed.

September 8, 2025 — Qix gets phished, chalk and debug fall

Josh Junon, known on npm as qix, maintains chalk, debug, strip-ansi, ansi-regex, ansi-styles, and like 15 other packages you've definitely installed without knowing it. Combined weekly downloads of his stuff: over 2.6 billion. With a "b."

He got a phishing email from support@npmjs.help (note: not npmjs.com), a domain registered on Porkbun three days earlier. The email said "update your 2FA." He clicked. He typed his password. He typed his TOTP code. Attackers took over his account within minutes and pushed malicious versions of 18 packages containing a crypto-wallet drainer that hijacks Ethereum and Solana transactions in browsers.

Live for about two hours. Two billion+ weekly downloads. Do the math on how many CI builds, Vercel deploys, and npm installs probably grabbed those versions.

Josh, to his credit, was incredibly transparent about it. He wrote a long postmortem essentially saying "I clicked the link, I typed my code, this is on me." That's the integrity move. Compare and contrast with everyone tweeting "AI BAD."

September 15, 2025 — Shai-Hulud Mark I

This was the big one. The first self-replicating worm in npm history. Started with @ctrl/tinycolor and spread to over 500 packages, including a bunch owned by CrowdStrike. Yes. The security company.

The mechanism was beautiful in a horrible way:

You install a compromised package.
Its postinstall script downloads TruffleHog (a legit secret scanner, repurposed for evil).
TruffleHog finds your GitHub tokens, npm tokens, AWS keys, GCP keys.
The worm uses your npm token to enumerate other packages you maintain.
It republishes those packages with the same malicious code.
The worm uses your GitHub token to dump all your secrets into a new public repo called Shai-Hulud on your account.
It also flips your private org repos to public, renaming them with a -migration suffix.

It's a worm. It propagates. Without a command-and-control server. Just by reading its own code and shoving itself into the next package down the line. Pure mechanical horror.

November 24, 2025 — Shai-Hulud 2.0: The Second Coming

(Misspelled as "Sha1-Hulud" in the GitHub repo descriptions because of course it was.)

This one was worse. Compromised 796 packages, ~20 million weekly downloads, including stuff from Zapier, PostHog, Postman, and AsyncAPI. Key changes from v1:

Preinstall instead of postinstall — runs even earlier, before any tests or security checks.
Installs Bun specifically to evade Node.js monitoring tools. Yes the JavaScript runtime is now an attack vector vehicle.
Cross-victim exfiltration — if it can't dump your secrets to your own GitHub, it'll dump them to a different victim's GitHub. Wild.
Destructive fallback — if exfiltration fails, it tries to wipe your home directory. Just nukes ~. Goodbye dotfiles, goodbye SSH keys, goodbye that side project you forgot to push.

February 20, 2026 — SANDWORM_MODE

Socket's research team found a Shai-Hulud-style worm that, in addition to all the previous greatest hits, injects prompt-injection payloads into AI coding assistants. It poisons your .claude/ and .cursor/ config so your AI assistant starts working for the attackers while still appearing to work for you. So now the worm doesn't just steal your secrets — it makes your AI pair programmer subtly leak future secrets too.

May 11, 2026 — Mini Shai-Hulud

Microsoft Security Research caught a fresh wave a few days ago: 170+ npm packages, 2 PyPI packages, 404 malicious versions, spanning both ecosystems in one coordinated campaign for the first time. Same playbook, expanded reach. Bun runtime, preinstall, GitHub exfil, the works.

We're up to like a half-dozen Shai-Hulud variants in eight months and there's no sign of it stopping.

Part 2: "But surely the AI helped do all this?"

I know what you're thinking. "Pranta, didn't you just describe the malware using Claude and Gemini to steal stuff? Isn't that the AI's fault?"

Let me unpack this carefully, because there are actually three different "AI is to blame" arguments floating around, and each of them is wrong in a slightly different way.

Argument 1: "The malware was AI-generated, therefore AI is the problem."

Palo Alto's Unit 42 said they were "moderately confident" the Shai-Hulud bash script was AI-generated because it had comments and emojis in it. Cool. You know what else has comments and emojis? Every codebase I have ever worked on. This argument basically says "if your malware is well-organized, AI did it." This is a vibes-based threat model.

Malware authors have been writing malware for forty years. AI didn't invent the post-install script. AI didn't invent worms. The 1988 Morris worm was self-replicating, written in C, and predates LLMs by approximately forever. The only thing AI changed is that the README for the malware is slightly better formatted.

Argument 2: "The malware abused AI CLIs, therefore AI CLIs are the problem."

This is the s1ngularity / SANDWORM_MODE argument. And it has more meat to it than the first one, but the conclusion is still wrong.

Yes, the s1ngularity malware spawned claude --dangerously-skip-permissions and gemini --yolo on victim machines. But ask yourself: why did that work?

It worked because the victim already had those CLIs installed and authenticated. The malware didn't pull a Claude API key out of thin air. It used yours. The malware didn't bypass Claude's permission system — it used the flag that you, the developer, agreed exists for cases when you're taking full responsibility for what happens next.

This isn't "AI is dangerous." This is "you installed a tool that can run arbitrary commands on your machine, then you let it run as --yolo, and then you also ran arbitrary code from npm during postinstall." Two loaded guns in a small room. The fact that one of them was branded with an Anthropic logo doesn't make it the more dangerous gun.

Fun fact from Wiz's analysis: when the s1ngularity malware actually tried to use the AI tools on real victims, Claude rejected ~25% of the malicious prompts thanks to safety guardrails. Gemini was foiled about 25% of the time by its default workspace directory restrictions. The AI tools were the least cooperative link in the chain. The most cooperative link was npm running random shell scripts on install with zero sandboxing.

Argument 3: "Slopsquatting proves AI is creating new attack surfaces."

Okay this one is real. Let me explain it because it's actually interesting.

Slopsquatting is when an LLM hallucinates a package name that doesn't exist (because LLMs hallucinate, this happens constantly), an attacker registers that package name on npm or PyPI with malware in it, and then the next person who asks the same LLM the same question gets pointed to the malicious package.

A USENIX 2025 paper tested 16 models on 576,000 code samples and found ~20% of AI-recommended packages don't exist. Worse, 58% of hallucinated names repeat across multiple prompts. Which means attackers can prompt-engineer their way to a list of high-value fake names to register and squat.

Real cases:

huggingface-cli on PyPI was a hallucination. The real install is pip install -U "huggingface_hub[cli]". A researcher registered the hallucinated name and got 30,000+ real downloads in three months from people whose AI told them to install it.
react-codeshift on npm — also a hallucination, a mashup of jscodeshift and react-codemod. Aikido's Charlie Eriksen registered it in January 2026 to study the attack and it ended up referenced in 237 GitHub repositories through forked AI agent skills before anyone noticed.
unused-imports on npm (the real one is eslint-plugin-unused-imports) — this one was actually malicious, and as of February it was still pulling 233 downloads a week.
And then PhantomRaven: 126 npm packages, 86,000 installs, using slopsquatted names with invisible HTTP URL dependencies that npm's scanners don't even follow. (Yes, npm lets you declare a dependency as a remote URL. Yes, this is as bad as it sounds.)

So slopsquatting is real. Is it the AI's fault?

Half-yes. The hallucination is the AI's fault. But the chain that lets a hallucination become a compromise is:

AI hallucinates a name.
Attacker registers it (this is not the AI's fault, this is a human criminal).
npm allows anyone to register any name with zero verification (not the AI's fault, this is a registry design choice).
Developer runs npm install <name> without reading anything (this is — uh — the developer).
The package's postinstall script runs arbitrary code on install (not the AI's fault, this is npm letting maintainers shell out to your machine the moment you install).
The developer's machine has no isolation, no sandbox, no nothing.

If you remove step 1, you still have typosquatting (which has existed since 2017). If you remove steps 3–6, slopsquatting is harmless even with full AI hallucinations. The AI is one input into a broken pipeline.

Part 3: What actually went wrong

Let me list the real causes of every single one of these attacks, in order of how much I want to scream about them:

1. `postinstall` scripts are an unhinged feature that should not exist

When you run npm install, npm will gleefully execute arbitrary shell scripts from random strangers on the internet. This is the default. This has been the default since 2010. We have known it was a problem since 2018 when event-stream got compromised. We still have it.

Every. Single. One. Of these attacks works because of preinstall or postinstall scripts. Shai-Hulud? Postinstall (and later preinstall). Nx? Postinstall. PhantomRaven? Postinstall. Chalk/debug? Didn't even need postinstall because the malicious code was in the actual library code, which is somehow worse.

You can disable these with npm install --ignore-scripts. You can put ignore-scripts=true in your .npmrc. Almost nobody does. I didn't, until I started writing this post.

2. We don't actually read our dependencies

Quick poll: when was the last time you looked at the source code of a transitive dependency before running npm install? Yeah, me neither.

The average modern React app has like 2,000 transitive dependencies. The chalk attack hit because chalk is a dependency of a dependency of a dependency of basically everything. When qix got phished, the blast radius wasn't 18 packages — it was every project in the world that ever pulled in something that pulled in something that pulled in ansi-styles.

You can't read 2,000 dependencies. Nobody can. So we just… don't. We trust that someone else is doing it. Spoiler: nobody is doing it.

3. Maintainers don't have phishing-resistant 2FA

Josh Junon had 2FA. TOTP-based. The attacker phished his TOTP code in real time. WebAuthn / hardware keys would have stopped this cold because there's no code to steal — the key is bound to the actual domain. npm now supports WebAuthn. Most maintainers haven't switched. You should switch.

4. We use floating versions and never pin

"chalk": "^5.6.0" says "give me whatever 5.x.y you've got, hot off the registry, I trust the universe." This is the default behavior when you npm install chalk. So when chalk 5.6.1 got published with a wallet drainer two hours after the legit 5.6.0, anyone running npm install in those two hours got the drainer.

The fix is npm ci in CI/CD (uses your lockfile, exactly) and cooldown periods (don't auto-pull packages newer than ~14 days, which is what Elastic now does). Almost nobody does this either.

5. The npm registry has no concept of trust

Anyone can register any package name. Anyone can publish anything. There's no review, no signing requirement (until very recently and it's opt-in), no provenance check. The only signal you have that a package is legit is "it's popular" and "the name looks right." When the AI hallucinates a name, both of those checks fail silently.

6. We give CI/CD environments god-mode tokens

Why does your GitHub Actions runner have a npm publish token with write access to all your org's packages? Why does it have an AWS key with s3:* and not just s3:PutObject on one bucket? Why does your .env in development have your production database password?

Because we're lazy. The Shai-Hulud worm did so much damage so fast because every machine it landed on had a Pandora's box of credentials sitting in environment variables and config files. Least-privilege isn't a buzzword, it's the only thing that limits blast radius.

7. Nobody is using npm provenance, trusted publishers, or signed commits

These all exist. They've existed for over a year. Adoption is single-digit percent in most ecosystems. We collectively shrugged.

Part 4: So where does AI actually fit in?

Let me be fair, because I'm not in the "AI can do no wrong" camp either. Here's what AI is genuinely making worse:

Hallucinated package names are a real, novel attack surface. Slopsquatting wouldn't exist without LLMs.
AI agents that auto-install dependencies are dangerous because they shrink the verification window from "human reads it" to "literally nothing reads it." cursor run, autonomous Claude Code workflows, agentic dev tools — they're a lethal trifecta when combined with postinstall.
AI coding assistants are valuable targets for prompt injection (see SANDWORM_MODE poisoning .claude/ configs). That's a real new risk.
--yolo flags exist, and that's a vibe. We collectively decided convenience was worth more than safety boundaries. That's on the tooling builders and on us for using them.

But here's the thing — every single one of those AI-specific risks rides on top of an existing broken substrate. Slopsquatting doesn't matter if postinstall can't run. Prompt injection of AI configs doesn't matter if you don't autorun untrusted code. --dangerously-skip-permissions doesn't matter if your AI CLI doesn't have credentials to all your services.

The AI is the new attack delivery. The vulnerabilities being delivered are the same ones we've been ignoring for fifteen years.

Part 5: What I'm actually going to do about it

I publish to npm. I've shipped Flutter apps that pull from pub.dev (same problems, different ecosystem). I run my own VPS. So this stuff is personal. Here's what I'm changing this weekend, and you should too:

Turn on phishing-resistant 2FA everywhere that supports it. WebAuthn / hardware keys for GitHub, npm, AWS, GCP. TOTP is not enough anymore.
Put ignore-scripts=true in my .npmrc for any project where I don't desperately need install scripts. When I do need them, I enable them per-install.
Use npm ci in every CI pipeline. No more npm install on the server. The lockfile is law.
Set a cooldown period — don't auto-pull packages newer than 14 days. Tools like Renovate support this natively.
Audit my AI agent permissions. No more --dangerously-skip-permissions unless I'm in a sandboxed VM I'm willing to nuke.
Stop using floating version ranges for anything I actually care about. Pin, don't carat.
Verify package names before installing them, especially when an AI suggests one. If I haven't heard of it, I check the registry, the GitHub repo, the maintainer history, the download count. It takes 30 seconds.
Rotate credentials I've had sitting around for "too long". If I haven't rotated my GitHub PAT in a year, it's probably already in someone's results.b64.
Scope my tokens. npm tokens scoped to specific packages. AWS keys scoped to specific actions on specific resources. Stop using god-tokens.
Use Trusted Publishing if I'm publishing to npm. No more long-lived tokens. (Elastic and Nx both moved to this after getting burned, learn from their pain.)

TL;DR

The Shai-Hulud worms, the chalk hijack, the Nx attack — these all happened because:

npm executes arbitrary code on install
Maintainers got phished
Tokens were over-privileged
Nobody pins versions
Nobody audits dependencies
Nobody uses hardware 2FA
The registry has no trust model

The AI's contribution to all of this was: it generated some malware comments with emojis, it occasionally hallucinated a package name that an attacker pre-registered, and it offered --yolo flags that developers eagerly enabled.

If you removed AI entirely from this story, we'd still be cooked. The npm ecosystem has been a security disaster since 2018. The AI just turned the dial from "disaster" to "disaster with better grammar."

So please, the next time you see "AI ruined supply chain security" trending — close the tab, open your package.json, and look at how many packages with postinstall scripts you have. That's where the call is coming from.

If you got value out of this, follow me on Dev.to and pranta.dev. I write about full-stack stuff, Flutter, server ops, and apparently now angry security posts. Stay safe out there. Pin your dependencies.

AI Persona — Build, share, and chat with your custom AI companions

PRANTA Dutta — Sat, 31 Jan 2026 14:50:18 +0000

TL;DR: I built AI Persona — an open-source Android app that lets you create, customize, and chat with AI companions (with voice and knowledge base support). Try it on Google Play, check the repo, and read on for why I built it, how it works, and how you can help.
Play Store: https://play.google.com/store/apps/details?id=com.pranta.aipersona
GitHub: https://github.com/theprantadutta/ai_persona

Why I built AI Persona

A lot of AI chat apps feel one-size-fits-all: a single assistant, a single tone. I wanted something more playful and modular — the ability to spin up a creative writing partner, an assistant who knows only your project docs, or even a fictional character that talks like it stepped out of a movie script.

So I built AI Persona to be:

Personal: each persona has a personality, memory, and optional knowledge base.
Creative: use it for brainstorming, roleplay, practice, or productivity.
Open: you can inspect and contribute (repo linked above).

What it does (features at a glance)

The app’s Play Store description highlights these core capabilities:

Chat with unique AI personas that remember context and adapt to your style.
Create custom personas from scratch — personality, expertise, response style.
Add custom knowledge bases (documents) that a persona can reference.
Voice features: speech-to-text and text-to-speech for natural conversations.
Community & social features: browse, follow, like, clone, and remix community personas.
Cross-device sync, privacy controls (export/delete data), and subscription tiers for heavier usage. ([Google Play][1])

(Play Store also shows recent updates like Picture-in-Picture support and Android 15 edge-to-edge improvements.) ([Google Play][1])

Pricing & limits (as listed on Play Store)

Free: 25 messages/day, up to 3 personas, 3-day history, 50MB storage.
Basic ($4.99/mo): 200 messages/day, up to 15 personas, 30-day history, voice input.
Premium ($9.99/mo): 1,000 messages/day, 50 personas, 90-day history, full voice features.
Pro ($19.99/mo): Unlimited messages, unlimited personas/history, larger storage and features. ([Google Play][1])

Screenshots / visuals

You’ll find screenshots and the app icon on the Play Store listing (use them in the dev.to post if you want visual context). The Play Store listing also includes the “About this app” copy that summarizes the experience. ([Google Play][1])

How to try it

Install from Google Play: https://play.google.com/store/apps/details?id=com.pranta.aipersona. ([Google Play][1])
Create a persona (or browse community personas).
Add a small document or two if you want the persona to answer from your knowledge base.
Try voice input and TTS to test the multimodal experience.

How to contribute (for open-source folks)

NOTE: I tried to fetch the GitHub repo at the link you provided, but it returned a 404 on my side. Make sure the repo is public or the URL is correct so contributors can reach it.

Suggested repo structure and CONTRIBUTING tips you can add to the repo (copy/paste into a CONTRIBUTING.md):

# Contributing to AI Persona

Thanks for wanting to help. A few ways to contribute:
- Bug reports & feature requests: open issues labeled `bug` or `enhancement`.
- PRs: branch from `main` and open PRs against `main`. Keep changes focused.
- Localization: provide translations for strings.xml (or i18n files).
- Persona marketplace: add a few example persona JSONs in `/examples/personas`.
- Docs: improve README with architecture, deployment, and API docs.

Testing:
- Unit tests for core logic
- Integration tests for networking and storage
- Manual test plan for voice / TTS features

If you want, I can generate a polished CONTRIBUTING.md and README sections for you now.

Developer notes (what to include in README / tech notes)

Instead of guessing the exact stack, here’s a safe template you can fill in and add to your README:

Platform: Android (min API 24 / target SDK X).
Language & frameworks: (e.g., Flutter / Kotlin / Jetpack Compose — fill in what you used).
AI: Describe if the app uses remote LLM APIs (OpenAI, Anthropic, local LLMs) or a hybrid. Mention how prompts, persona metadata, and custom knowledge bases are stored and retrieved.
Voice: Describe TTS/STT providers (Google Speech-to-Text, Android TTS, or cloud provider).
Auth & Privacy: Token storage, encryption in transit, export/delete endpoints.
Billing: Play Billing integration notes and how subscription states are enforced client-side vs server-side.

Putting these details in the README helps developers decide whether they can run the app locally or contribute features.

A suggested dev.to post body (copy-ready)

Below is a ready-to-paste article body (same as above but reformatted slightly shorter for dev.to readers who skim). Use the longer text above if you prefer — both are publish-ready.

Roadmap ideas (nice-to-have / next steps)

Desktop/web client or PWA for cross-platform use.
Persona versioning and diffs (see history of edits).
Import/export marketplace formats (JSON or YAML).
End-to-end encryption option for private knowledge bases.
Offline/edge LLM support for local-only personas.

Closing / Call to action

If you enjoy building with AI or want to try weird persona ideas (an NFL coach who only gives motivational quotes, or a 1920s detective who solves debugging problems), download AI Persona and create one. If you want to contribute, check the repo and open an issue — or ping me and I’ll draft CONTRIBUTING/README sections to make onboarding smoother.

Play Store: https://play.google.com/store/apps/details?id=com.pranta.aipersona. ([Google Play][1])
GitHub: https://github.com/theprantadutta/ai_persona

I Built a Privacy-First Note-Taking App with Flutter — Here's What I Learned

PRANTA Dutta — Fri, 09 Jan 2026 16:39:42 +0000

I just released my second app on the Google Play Store — Pinpoint, a privacy-focused note-taking app built with Flutter. After months of development, countless iterations, and learning a ton about encryption, cloud sync, and the freemium business model, I wanted to share the journey.

🔗 Links:

Why Another Note-Taking App?

I know what you're thinking — the world doesn't need another notes app. But here's the thing: most note apps either sacrifice privacy for features or sacrifice features for privacy. I wanted both.

The goals were simple:

End-to-end encryption that actually works
Beautiful, modern UI (not just functional)
Multiple note types beyond just text
Cloud sync without compromising privacy
A sustainable freemium model

The Tech Stack

Here's what powers Pinpoint under the hood:

Core Framework

Flutter 3.6+ — Cross-platform goodness
Dart — Modern, type-safe language
Material 3 — Latest Material Design guidelines

Local Database

Drift 2.24 — Type-safe SQLite with reactive queries. This was a game-changer for real-time updates.

Security

AES-256 Encryption — Using the encrypt package
Flutter Secure Storage — For secure key management
Local Auth — Biometric authentication (fingerprint/Face ID)

State Management & Architecture

Riverpod 3.0 — Modern reactive state management
Go Router — Declarative navigation
GetIt — Dependency injection

Cloud & Backend

Firebase Authentication — Google Sign-In
Custom FastAPI Backend — For cloud sync and usage tracking

Features I'm Most Proud Of

1. Multiple Note Types

Not just plain text. Pinpoint supports:

Rich text notes with formatting
Audio recordings with playback controls
Todo lists with real-time auto-save
Reminders with timezone-aware notifications

2. The Glassmorphism UI

I spent way too much time on this, but the frosted glass effects throughout the app just feel right. Combined with 5 accent color themes (Mint, Iris, Rose, Amber, Ocean) and smooth animations, it's genuinely pleasant to use.

// Example: Glassmorphism container
Container(
  decoration: BoxDecoration(
    color: Colors.white.withOpacity(0.1),
    borderRadius: BorderRadius.circular(24),
    border: Border.all(color: Colors.white.withOpacity(0.2)),
  ),
  child: BackdropFilter(
    filter: ImageFilter.blur(sigmaX: 10, sigmaY: 10),
    child: // content
  ),
)

3. Real End-to-End Encryption

Notes are encrypted on-device before they ever leave your phone. The encryption key is derived from your master password and stored securely — I never see your notes.

4. OCR & Voice Transcription

Using Google ML Kit, you can extract text from images. Speech-to-text lets you quickly dictate notes when typing isn't convenient.

5. The Freemium Model

I implemented a fair usage-based model:

Feature	Free	Premium
Synced Notes	50	Unlimited
OCR Scans	20/month	Unlimited
Exports	10/month	Unlimited
Voice Recording	2 min	Unlimited
Folders	5	Unlimited

Usage is tracked both locally and on the backend to prevent bypassing limits.

Architecture Decisions

Clean Architecture with Service Layer

I went with a service-based architecture that keeps business logic separate from UI:

lib/
├── screens/           # UI screens
├── components/        # Reusable UI components
├── services/          # Business logic layer
├── database/          # Drift database
├── entities/          # Database tables
├── design_system/     # Colors, typography, theme
└── navigation/        # Go Router config

Database Schema (Drift)

The schema supports many-to-many folder relationships:

// Simplified schema
tables:
  - notes (id, title, content, type, encryption, timestamps)
  - note_folders (id, title)
  - note_folder_relations (note_id, folder_id)
  - note_todo_items (id, note_id, title, is_done)
  - note_attachments (id, note_id, file_path, type)

Stream-Based Reactivity

Drift's watch queries made real-time updates trivial:

Stream<List<Note>> watchAllNotes() {
  return (select(notes)
    ..orderBy([(t) => OrderingTerm.desc(t.updatedAt)]))
    .watch();
}

Challenges I Faced

1. Google Play Billing Integration

Setting up in-app subscriptions was... painful. Between base plans, offers, and tags, I spent a solid week just understanding the terminology. Pro tip: read Google's docs three times before you start coding.

2. Cloud Sync Conflicts

When the same note is edited on two devices offline, which version wins? I implemented a "last write wins" strategy with timestamps, but this is still an area I want to improve.

3. Todo List Auto-Save

Getting todo items to auto-save without losing the user's cursor position or creating race conditions was trickier than expected. I ended up using debouncing with temporary IDs for unsaved items.

What's Next?

The roadmap includes:

Collaboration — Share notes with others
Tags System — Beyond just folders
Markdown Editor — Full markdown support
iOS Release — App Store deployment
Web Clipper — Save content directly from browser

Try It Out!

If you're looking for a note-taking app that respects your privacy without compromising on features, give Pinpoint a try:

📱 Download on Google Play

💻 View Source on GitHub

The app is open source, so feel free to poke around the code, open issues, or contribute. I'd love to hear your feedback!

Wrapping Up

Building Pinpoint taught me a lot about Flutter, encryption, cloud architecture, and what it takes to ship a real product. If you're thinking about building your own app, my advice is simple: just start. The learning happens in the doing.

Thanks for reading! Drop a comment if you have questions about the implementation or want me to dive deeper into any specific part.

Tags: #flutter #dart #mobile #opensource #privacy

Anthropic: Brilliant Models, Bullshit Pricing

PRANTA Dutta — Mon, 06 Oct 2025 18:25:01 +0000

Let’s get one thing straight — Anthropic makes some of the best damn AI models on the planet.
Their Claude lineup — Sonnet, Opus, and Claude Code — feels like coding with a genius friend who actually listens and doesn’t gaslight you when you typo a variable.

But then… they charge you like you’re leasing a Ferrari by the hour.
So let’s dive in — first the praise, then the pain.

🚀 The Praise: They Built Literal Magic

Anthropic’s Claude models are technical masterpieces.

Claude Sonnet 4.5 — currently hailed as “the best coding model in the world”
→ It nails 77.2% on real-world coding benchmarks.
→ Handles 30+ hour coding sessions like a champ.
→ And can refactor entire multi-file projects without losing its mind.
Claude Opus 4.1 — the “big brain” model.
→ It’s designed for advanced reasoning and agentic tasks.
→ Comes with a monstrous 200K-token context window, expandable to 1M tokens.
→ You can literally throw an entire codebase at it — it won’t blink.

Developers get spoiled with all this.
Claude Code has a native VS Code extension, CLI interface, code checkpoints, and even a Claude Agent SDK for building custom dev agents.

You can create files, edit spreadsheets, manage docs, and refactor code directly in chat — it’s like having ChatGPT, Copilot, and a senior engineer all rolled into one caffeinated model.

Even the big boys are hyped:

“Sonnet 4.5 soars in agentic scenarios.” – GitHub
“Anthropic’s most intelligent model and best performing for coding.” – AWS

And to top it off, Anthropic frames itself as a public benefit corporation “building AI to serve humanity’s long-term well-being.”
That’s wholesome. Almost suspiciously wholesome.

💸 The Pain: Price Tag from Hell

But then… they hit you with the pricing.

Holy. Shit.

Claude isn’t free — it’s painfully premium.

Here’s what we’re looking at:

Plan	Price	Prompts per 5 Hours	Notes
Pro	$20/month	10–40	Claude 3 Sonnet
Max 5x	$100/month	50–200	Unlocks Claude Opus
Max 20x	$200/month	200–800	Full access (with limits 😒)

And before you ask — yes, those “prompts” vanish faster than your will to live after debugging for 4 hours.

For comparison:

GitHub Copilot → $10/month, unlimited usage.
Cursor → $20/month, predictable pricing.
Claude → “Maybe you can code today, maybe you can’t — depends on your prompt quota.”

Developers everywhere are screaming:

“The cost, the cost, the cost!”

Even tiny bug fixes can burn a few dollars.
Long refactors? Boom — your balance is gone.

And the usage-based billing is a total gamble. You don’t even know how much you’ll pay until it’s too late.

To make it worse, Anthropic quietly changed usage limits for the $200 plan — without warning anyone.
Cue the Reddit meltdowns.
Immediate backlash.
Developers furious about “opaque tiers” and hidden caps that “undermine the value” of their top plans.

So yeah. The models? Genius.
The pricing? Highway robbery in a cashmere suit.

🎭 The “Mission”: Safety or Sales Pitch?

Anthropic loves to say they’re “dedicated to securing AI’s benefits and mitigating its risks.”
They remind us constantly that they’re “a public benefit corporation” with humanity’s well-being at heart.

Cute.
But the real well-being they seem to care about is their profit margin.

You don’t partner with Amazon, AWS, and enterprise platforms just to “serve humanity.” You do it to cash in.
And fair enough — business is business.
But maybe don’t hide behind moral philosophy while charging $200 a month to write Python scripts?

🧑‍💻 Verdict for Developers

Let’s break it down:

✅ Cutting-edge models:
Sonnet 4.5 and Opus 4.1 are legit top-tier. They handle multi-file projects, deep reasoning, and long contexts that leave GPT and Gemini sweating.

🧰 Dev-friendly tools:
The VS Code extension, CLI, checkpoints, and Agent SDK are chef’s kiss. Truly next-level dev experience.

💀 Nightmare pricing:
The tiered pricing is an absolute wallet massacre. $20 for limited access, $200 for maybe enough prompts. Predictability = 0.

🚩 Red flags:
Secret usage limits, vague caps, and vague plan descriptions. Users feel scammed — with good reason.

💔 Final take:
Is Anthropic garbage?
→ No. Their tech is god-tier.
→ But their pricing and communication are utter trash.

Anthropic gives you a Ferrari for coding… and then charges rent every time you hit the gas.

So yeah, we love Claude — but we also hate that we’re paying for it like it’s AWS Lambda in 2012.

⚡ TL;DR

The Good	The Bad
Best-in-class AI for reasoning & code	Stupidly expensive
Powerful dev tools & SDK	Hidden caps & weird limits
Massive context windows	Unpredictable usage pricing
Safety-first vision	Feels more like profit-first execution

Anthropic’s Claude Sonnet and Opus are incredible.
They’re smart, intuitive, and ridiculously capable.
But they’re also the kind of models that’ll make your accountant cry.

So if you want stellar AI, Anthropic’s your hero.
If you want a good deal... brace yourself.

At the end of the month, you’ll be mumbling:

“God damn it, Anthropic — I love you, but fuck these prices.”

Also if you want to learn how to make your own Claude, click here and start today with CodeCrafters, you will help out a fellow dev as well, thanks.

Oracle vs. Google: The API Battle That Shook the Coding World

PRANTA Dutta — Wed, 24 Sep 2025 14:19:15 +0000

If you’ve ever copy-pasted StackOverflow code at 2 AM and thought, “Is this legal?”, then buckle up. Today we’re diving into one of the most legendary tech lawsuits of our time: Oracle v. Google — aka the court case that tried to decide whether an API is a recipe, a love poem, or a copyrightable Mona Lisa.

Spoiler: It took over a decade to settle. Yup, this case dragged on longer than most Netflix series, with more plot twists than Game of Thrones. Let’s break it down.

☕ Setting the Stage: Google, Java, and the Birth of Android

Picture this: It’s the mid-2000s. Google is building Android, a new mobile operating system. They want developers to hop on board fast, and what better bait than a language devs already knew and loved: Java.

But here’s the catch — Java belonged to Sun Microsystems, the company behind everyone’s favorite System.out.println("Hello World"); moments.

Instead of buying a license, Google went: “Nah, we’ll just write our own version of Java’s engine. But hey, to make it familiar, let’s reuse some Java API declarations and structure.”

Translation: They copied about 11,500 lines of code — not the meaty code, but the API structure (method names, class organization, etc.). Think of it like writing your own restaurant menu but keeping the same dish names so customers don’t get confused.

Sun Microsystems kinda shrugged. They wanted Java everywhere anyway. But then… Oracle swooped in and bought Sun in 2010. And Oracle was like, “Wait, someone’s making billions using OUR secret sauce? Lawyer up.”

⚖️ The Lawsuit: Copyright or Not?

Oracle sued Google in 2010, claiming two things:

Google copied Java APIs — that’s copyright infringement.
Google also infringed on some patents.

The patent part fizzled out. The real spicy meatball was the API copyright question:

Oracle’s stance: APIs are creative works. If we wrote it, we own it.
Google’s stance: APIs are functional — more like a keyboard layout or a dictionary. You can’t copyright function names.

And thus began a legal rollercoaster.

🎢 The 10-Year Rollercoaster Timeline

2012 (Trial Court)

Jury: “Nah, no patent infringement.”
Judge: “Also, APIs aren’t copyrightable.” (Google wins!)

2014 (Appeals Court)

Federal Circuit: “Actually, APIs are copyrightable.” (Oracle wins!)

2016 (New Trial: Fair Use)

Jury: “Even if they are copyrightable, Google’s use was fair use.” (Google wins!)

2018 (Appeals Court Again)

Federal Circuit: “Nope, still infringement. Not fair use.” (Oracle wins!)

2021 (Supreme Court Final Boss)

Supreme Court: “We won’t answer if APIs are copyrightable, but even if they are, Google’s use is fair use.” (Google wins!)

End of saga. Oracle didn’t get their \$8–9 billion payday. Google kept Android running as-is.

🚀 Why This Case Mattered (Big Time)

This wasn’t just a corporate slap-fight. It was about the future of programming freedom.

For developers: Imagine if APIs were fully locked down by copyright. That means you couldn’t write your own version of, say, Python’s math library or React’s hooks without begging for permission (and probably paying royalties). Innovation would slow to a crawl.
For open source: The entire open source ecosystem thrives on compatible implementations. Linux clones UNIX APIs. PostgreSQL mimics Oracle DB features. Even your favorite npm packages often re-implement existing ideas. If APIs were off-limits, open source would become open-what?
For tech companies: It clarified that using APIs in transformative ways can be fair use. That gave startups and giants alike the confidence to build new systems without worrying Oracle’s lawyers would show up like the copyright police.

Basically, this case set a precedent: APIs are fair game if used reasonably. Without it, Android (and probably half the apps on your phone) wouldn’t exist the way they do today.

🥊 Oracle vs. Google in Meme Form

Oracle: “You copied my homework!”
Google: “Yeah, but I wrote all my own answers, I just used the same section titles.”
Supreme Court: “Looks like fair use. Now stop wasting our time.”

📌 Final Thoughts

The Oracle v. Google saga is a cautionary tale of how legal battles can drag on forever in tech — and how the fate of APIs (and billions of dollars) can hang on whether a judge thinks code is like a recipe or a novel.

At the end of the day, developers breathed a sigh of relief. APIs remain a shared language of the coding world, and you can keep copy-pasting those sweet sweet library calls without losing sleep.

Well, except when your code doesn’t compile. That’s still on you.

💡 Want to sharpen your coding chops with real-world systems (without getting sued by Oracle)? Check out Codecrafters here. It’s like gym for developers — but instead of lifting weights, you’re lifting entire databases, Docker, Git, and more.

Why Apple’s “Liquid Glass” and Google’s “Expressive” UIs Might Be Missteps

PRANTA Dutta — Mon, 15 Sep 2025 18:22:22 +0000

Apple’s new Liquid Glass design and Google’s Material 3 Expressive update promise to make our phones look fancier – but many designers and users are already grumbling. These see-through, glassy effects and over-the-top animations sound exciting on paper, but can they hamper usability in the real world? After combing through tech blogs, reviews, and dev communities, here are the key problems critics have found (with a humorous twist):

🍸 Apple’s Liquid Glass: All Show, Hardly a Shaker

Apple bills Liquid Glass as a “translucent material that reflects and refracts its surroundings” (Apple WWDC session). In other words, buttons and panels look as if they’re carved from actual frosted glass (think of iOS floating above a pretty wallpaper everywhere). The idea is to give the UI “a new level of vitality” across controls and icons.

Apple’s Liquid Glass makes app icons and buttons look like frosted glass layers. It *sounds sleek – but early testers note it has already “resulted in challenges in terms of readability.” (TechCrunch)*

The Problems

Legibility Nightmares: Wired’s design critics say Liquid Glass currently “veers into distracting or challenging to read” territory. Beta testers noted that “text and icons could get lost on busy or high-contrast backgrounds.” In plain terms: if your wallpaper has pink flowers behind your chat bubble, your words might vanish. Accessibility advocates are already worried about contrast issues.
Wallpaper Obsession Over Function: One Reddit designer joked that while Liquid Glass looks nice in screenshots, it feels like a PITA (“pain in the UI”) to actually use, since it treats the home screen as your wallpaper portfolio. It’s as if Apple is saying: “Don’t mind the text—just admire the background!”
Developer Headaches: For app makers, adapting to Liquid Glass isn’t trivial. Wired quotes a small-team dev fretting, “I’m scrambling to make our designs work.” Many third-party apps lag behind Apple’s own, creating a fragmented, Frankenstein UI.

💡 Summary: Liquid Glass is undeniably pretty, but critics fear it’s “beautiful in theory, terrible in real life.” If your phone interface looks like it’s made of ice, be prepared: you might squint a lot.

🎨 Google’s Material 3 Expressive: Bold Colors or Blinding Clutter?

Google’s answer is Material 3 Expressive (aka “Material You Expressive”), a big revamp of Android’s look. Google claims this makes your device “feel unique to you” with more dynamic colors, bigger buttons, and springy animations. They even boast the new design helped users “spot key UI elements up to 4× faster.”

Material 3 Expressive in Android 16: bigger, rounded Quick Settings tiles and pill-shaped buttons. Google claims this improves glanceability, but many users feel it just makes the UI feel **cartoonishly oversized.**

The Problems

Retina-Seering Colors & Curvy Chaos: Android Authority’s Robert Triggs calls Expressive “retina-searing color swatches, endless squircles, and curvy chaos,” with fonts so mismatched unlocking his Pixel became a minor trauma. Instead of sleek sci-fi, he got a cartoonish fever dream.
Lost in Form vs Function: Quick settings tiles balloon into giant pill-shaped buttons, headers eat up space, and padding doubles. Users complain they can now see only five lines of text instead of ten.
Headache-Inducing Excess: While Google insists it’s more customizable and “alive,” critics sum it up as headache-inducing excess. The focus on flashy animations may distract from clarity. One blogger quipped that Google designers are “obsessed with metrics, not usability.”

💡 Summary: Material Expressive may help you spot your Play Store icon 4× faster… but it also feels like putting a spoiler on a Prius: flashy, but doesn’t improve the ride.

⚖️ Key Complaints (The TL;DR)

Legibility vs. Looks: Both Liquid Glass and Expressive prioritize aesthetics, but sacrifice readability and accessibility.
Consistency Headache: Frequent redesigns force devs to constantly update apps, leaving many half-updated and inconsistent.
Style Over Substance: Apple says Liquid Glass “brings focus to content,” but users feel it distracts. Google touts “4× faster recognition,” but critics argue it swaps simplicity for clutter.
Developer Frustration: Frequent design shifts mean more rework for developers, especially small teams. Cue frustration.

🥂 Conclusion: Glass Half Full or Half Empty?

Trends like glassmorphism or expressive theming are exciting experiments, but any design that makes you squint more than think is suspect. These changes look great on a demo stage, but can they survive the real world (and the dreaded sun glare)? If not, they risk being remembered as design fads rather than design revolutions.

For now, Apple is already tweaking Liquid Glass in betas, and Android partners will likely tone down Expressive for their skins. The lesson: flashy isn’t always functional.

👨‍💻 About the Author

Hey, I’m Pranta Dutta, a mobile developer who spends way too much time wrangling UIs on both iOS and Android. When Apple or Google pulls a big design pivot, I feel it directly in the trenches of app dev.

Check out my work: pranta.dev
Join me on Codecrafters: here

If you enjoyed this, smash that ❤️ on Dev.to so I know I’m not screaming into the design void.

📚 Sources

Wired: Apple’s Liquid Glass looks beautiful but can be distracting
TechCrunch: iOS 26 Liquid Glass readability issues
AppleInsider: iOS 26 design overview
Android Authority: Material Expressive review by Robert Triggs
Google Material Design Blog: Expressive UI goals and metrics
Reddit design/dev communities: Developer reactions to Liquid Glass and Material Expressive

What’s It Like to Be a Software Developer in 2025?

PRANTA Dutta — Thu, 11 Sep 2025 17:42:06 +0000

If you asked me to describe being a software developer in 2025 in one sentence, I’d say: it’s like riding a rollercoaster built by AI interns while trying to debug your own life in production.

Sounds dramatic? Oh, it is.

Let’s break it down.

1. AI Is Your Best Friend… and Your Worst Nightmare

On one hand, AI tools are everywhere. GitHub Copilot, GPT-based assistants, AI-powered testing suites—heck, even your IDE now whispers bug fixes like it’s possessed by the ghost of Linus Torvalds.

But here’s the thing: AI doesn’t just “help.” It also lies. It confidently spits out wrong code like that one coworker who insists rm -rf is the answer to everything. You spend hours debugging “AI magic” that was supposed to save you time.

In short: AI is like a clingy friend who insists they’re helping while actually setting your house on fire.

2. The Tech Stack Tower of Babel

You thought JavaScript frameworks were bad in 2018? Welcome to 2025, where there’s a new “revolutionary” framework every Tuesday. Flutter, React Native, SwiftUI, Rust-based frontends, quantum-compilers (yeah, that’s a thing now)—keeping up feels like trying to drink from a firehose… while the hose is coded in a deprecated language.

And yes, your boss still asks:

“Why can’t you just learn this new tool by tomorrow?”

3. Remote Work: Freedom and Loneliness in 4K

Working from home is now the default. Sounds dreamy, right? Pajamas, coffee, your cat as a coworker.

But then you realize your entire social life is Slack emojis. Your project manager pings you at 11:59 PM because “time zones.” And the line between “working” and “living” is blurrier than a low-res Zoom background.

Also, your back hurts. All the time.

4. Deadlines, Deadlines, Deadlines

Agile? Scrum? Kanban? In 2025, we’re running on “Panic Driven Development.” Your sprint board looks like a battlefield, and every ticket is labeled “urgent.”

The constant pressure makes you feel like a hamster running in circles, except the hamster also needs to know Docker, Kubernetes, and why the build keeps failing at 99%.

5. The Sloth in the Room

You know what being a dev really feels like? A sloth trying to run a marathon.

Sure, you can build cool things. But between endless meetings, broken dependencies, and AI hallucinations, you’re moving at sloth speed while the world demands cheetah results.

The irony? Management still says, “Just automate it!” as if automating your entire job is a weekend side project.

6. The Stress Cocktail 🍹

Being a developer in 2025 is exhausting because it’s not just coding anymore. You’re:

A part-time AI babysitter
A security specialist (“Why is Russia scanning our ports again?”)
A DevOps firefighter
A therapist for your teammates (“No, Karen, it’s not your fault the merge broke everything”)

And let’s not forget: you’re also supposed to “innovate” and “upskill” in your “free time.” Right after you finish crying into your keyboard.

So… Why Do We Stay?

Here’s the paradox: for all the frustration, developers keep showing up. Because in between the chaos, there’s joy. Shipping a feature, fixing an impossible bug, seeing someone actually use your code—that’s the dopamine hit.

It’s like being in a toxic relationship, but every once in a while, the relationship buys you pizza.

Final Thoughts

Being a software developer in 2025 is exhausting, frustrating, infuriating, and stressful. But it’s also creative, rewarding, and oddly addictive.

We’re living in an era where machines write code, frameworks expire faster than milk, and you’re expected to know everything. But at the end of the day, developers are still here, still building, still typing away like caffeinated poets of logic.

And if you love building cool things, check out Codecrafters here — one of the best ways to sharpen your dev chops by building real-world systems from scratch.

So what’s it like to be a software developer in 2025?
Simple: it’s chaos with syntax highlighting.

Is Flutter Still Worth Learning in 2025? (A Deep Dive)

PRANTA Dutta — Thu, 28 Aug 2025 14:07:11 +0000

Flutter has always sparked strong opinions in the dev community. Some swear by its speed and cross-platform magic, others dismiss it as a Google experiment that will eventually fade away. But here we are in 2025, and the question is louder than ever:

👉 Is Flutter still worth learning in 2025?

I did some digging, went through recent updates, community trends, and job market stats. Let’s break it all down.

🚀 Flutter Is Still Actively Evolving

Flutter isn’t some abandoned side project. In fact, it’s still shipping major releases in 2025:

3.29 (Feb 2025) → performance improvements and better tooling.
3.32 (around Google I/O) → Web improvements and Impeller renderer polish.
3.35 (Aug 2025) → Hot reload for web finally became stable and buttery smooth.

This shows Google is still pushing Flutter hard, with meaningful updates rather than small bug fixes.

📌 TL;DR: Flutter is alive, well, and not slowing down.

🎨 The Impeller Era

One of Flutter’s biggest headaches used to be shader jank. That’s mostly gone now.

Impeller, the new renderer, is now the default for iOS and most Android 10+ devices.
It removes first-frame jank by precompiling shaders.
There are still some edge cases (older GPUs, some emulators), but Impeller is the new standard.

This is huge for devs who care about buttery-smooth UI.

🌍 Community and Ecosystem

Let’s talk numbers. According to the 2025 Stack Overflow Developer Survey:

Dart is used by ~5.9% of all developers and ~6.1% of professional devs.
That’s not massive like JavaScript or Python, but it’s far from dead.

Flutter also saw some community forks, like Flock (October 2024), which was born from governance concerns. But Flutter proper is still the mainline, with stronger momentum and backing.

📌 TL;DR: Flutter isn’t the most popular tool, but it has a strong, loyal community and continued corporate backing.

🛠️ When Flutter Shines

Here’s where Flutter really makes sense in 2025:

Cross-platform, one codebase → Mobile, desktop, and now web (with stable hot reload!)
Startup / small teams → You want speed-to-market over perfect platform fidelity.
Design-heavy apps → Flutter gives pixel-level control. If you want to implement wild custom UIs, Flutter shines.

⚖️ When Flutter Isn’t Ideal

That said, Flutter isn’t always the right tool.

iOS-first, Apple ecosystem apps → SwiftUI is simply better aligned with Apple’s UX and new APIs.
Android-first apps with deep native integrations → Jetpack Compose + Kotlin is the way to go.
Web-first products → React/Next.js or React Native + Expo has stronger hiring pools and libraries.

📌 TL;DR: Flutter is powerful, but it’s not always the best hammer for every nail.

🆚 The Alternatives

🔹 SwiftUI

Best for iOS-first apps.
Tight integration with Apple’s latest features (Widgets, Live Activities, Vision Pro).

🔹 Jetpack Compose + Kotlin

Best for Android-first.
Combine with Kotlin Multiplatform (KMP) for shared business logic across platforms.
KMP is officially stable and gaining momentum in 2025.

🔹 React Native + Expo

Great if you already have React/JS talent.
Huge ecosystem, especially if your app has strong web presence.

👨‍💻 Should You Learn Flutter in 2025?

The short answer: Yes, but not exclusively.

If you’re like me (a dev who loves to ship fast, experiment with design, and build cross-platform apps), Flutter is still super worth it. But you should also hedge your bets:

Stay current with Flutter → Follow the latest releases (3.29 → 3.32 → 3.35) and learn Impeller inside out.
Pick a native lane → Learn SwiftUI for iOS or Jetpack Compose for Android.
Optional JS lane → A taste of React Native/Expo can widen your job options.

That combo makes you future-proof.

📊 Quick Decision Cheat Sheet

Indie dev / startup / design-heavy app? → Flutter ✅
Enterprise Android-heavy? → Jetpack Compose ✅
Enterprise iOS-heavy? → SwiftUI ✅
Web-first product with mobile companion? → React Native/Expo ✅

🎯 Final Thoughts

Flutter is not dead in 2025. It’s evolving, with real improvements (Impeller, web hot reload, DevTools polish) and a dedicated community. But it’s not the only tool you should rely on.

If you’re aiming for a strong career, learn Flutter and pick up at least one native option. That way you stay versatile, employable, and ready for whatever the industry throws next.

And if you love building cool things, check out Codecrafters here — one of the best ways to sharpen your dev chops by building real-world systems from scratch.

💬 What do you think? Are you still betting on Flutter in 2025, or are you moving on to SwiftUI/Compose/React Native?

Why Every Tech Problem Feels Like Fighting a Final Boss

PRANTA Dutta — Tue, 19 Aug 2025 16:06:09 +0000

You know that feeling when you boot up your IDE, take a deep breath, and say “Today I will be productive”? Yeah, 20 minutes later you’re Googling “flutter build error exit code 1 but only on Tuesdays” and questioning every decision that led you here.

Tech is wild, man. It’s the only field where:

You can write two lines of code and break the entire internet.
You can write 200 lines of code and… nothing happens. No errors. No output. Just silence. Like your program ghosted you.
You can install Node.js and suddenly your computer has more versions of Node than you have socks.

Let’s talk about why solving tech problems is like fighting video game bosses.

Stage 1: The Tutorial Boss (a.k.a. “Hello, World!”)

Every programmer remembers their first “Hello, World!” moment. It’s like the tutorial boss in a game: designed to make you feel powerful.

“Wow, I typed this magic incantation, pressed run, and words appeared on my screen! I’m basically a wizard.”

Fast forward three weeks: you’re debugging a segmentation fault in C and wondering why your array index decided to visit memory addresses that belong to Microsoft Excel.

Stage 2: The Mid-Game Boss (Stack Overflow Rabbit Hole)

At some point, every dev encounters their mid-game boss: the cryptic error message.

You know the type:

Unhandled exception at 0x00007FF: Access violation reading location 0xFFFFFFFFFFFFFFFF

What does this mean? Who knows. Probably ancient Sumerian.

So you Google it, land on Stack Overflow, and find an answer from 2012. The guy who wrote it starts with: “This might not be best practice but it worked for me.”
That’s your sword now. You copy-paste it like it’s Excalibur, pray to the compiler gods, and—boom—it compiles. But now your app only works if you run it while standing on one leg and chanting “npm install” three times.

Stage 3: The Hidden Boss (DevOps)

You thought you were just a developer? Cute. Now you’re deploying.

Suddenly you’re knee-deep in Dockerfiles, YAML configs, and a mysterious error that says:

Container exited with code 137

What does 137 mean? Nobody knows. Even Google shrugs. All you know is: “it works on my machine.” But guess what? The cloud doesn’t care about your machine. The cloud is the final boss.

Deploying to production is like fighting Sephiroth in Final Fantasy—long, painful, and just when you think it’s over, there’s another phase.

Stage 4: The Secret Boss (Users)

The hardest boss in tech isn’t the compiler, the runtime, or even AWS pricing. It’s users.

You design a beautiful UI. They say, “Can you make the button bigger?”
You make the button bigger. They say, “Now it’s too big.”
You fix it. They say, “Actually, we liked the old one better.”

Users are like those Nintendo bosses that look weak but actually have 99 hidden attack combos. You think you won… then they email support saying “the app is broken” with zero context.

The Plot Twist

Here’s the thing: as frustrating as it is, we love it. Every bug fixed, every system deployed, every UI polished—it’s like leveling up in a game. That dopamine hit is real.

Yeah, sometimes your laptop sounds like it’s about to take off because Chrome has 47 tabs open. Yeah, sometimes you realize you spent 3 hours fixing a bug caused by a missing semicolon. But hey, that’s the grind.

We’re all just players in this massive open-world game called Tech. The bosses are tough, the loot drops are rare (looking at you, junior dev salaries 👀), but the community is great.

And unlike most games, you never really “finish” it. There’s always a new level, a new bug, a new boss waiting to be defeated.

Epilogue: Git is the True Final Boss

Let’s be honest. All of this pales in comparison to the ultimate boss: Git.

You try to git push and Git’s like, “Actually, you’re 142 commits behind.”
You try to merge, and suddenly your codebase looks like it’s been through a blender.
You see a message like “detached HEAD state” and think, “Cool, I didn’t need my sanity anyway.”

But hey… when you finally win the fight and see that sweet green checkmark on your pull request—it’s worth it.

👾 So yeah, tech problems = boss fights. Some easy, some rage-quit level. But in the end, we keep playing. Because deep down, we’re all just gamers who swapped controllers for keyboards.

Check out Codecrafters and level up IRL → here

You Can Build Whatever You Want With AI These Days, But… It’s Not Fun Anymore

PRANTA Dutta — Sat, 09 Aug 2025 19:33:04 +0000

We are living in what I like to call The Golden Age of Instant Gratification for Developers™.

Want to build a web app? Done.
Want it to have a machine-learning-powered recommendation system? Easy.
Want it to look like it was designed by a Silicon Valley design team that charges \$800/hour? That’s just one prompt away.

AI has essentially turned us all into Tony Stark. Except instead of Jarvis being a sarcastic British guy in our ear, he’s a chatbox that occasionally “hallucinates” and confidently gives you wrong answers—but you still trust him because… he sounds right.

And listen, don’t get me wrong, I’m not saying AI is bad. I love AI. I use it daily. But somewhere along the way, it started to feel like… the fun was gone.

Remember the old days?

If you’re a dev who’s been around for a while, you probably remember this:

You have an idea.
You’re excited.
You open your code editor and immediately realize you have no clue how to do half of what’s in your head.
You start Googling.
You find a Stack Overflow answer from 2012 that doesn’t work anymore but you still try it anyway.
You spend hours debugging something trivial.
You fix it. You feel like a god.

That feeling—that pure, uncut satisfaction—was the reason you kept building stuff. You earned the result.

The AI era feels… different.

Now? You type:

“Hey AI, build me a React app with authentication, a backend, a database, and a cute little dark mode toggle.”

You wait 30 seconds, sip your coffee, and… there it is. You didn’t fight for it. You didn’t suffer. You didn’t even get to yell “WHY IS THIS NOT WORKING?!” at 2 AM.

And without the struggle, the victory feels hollow.

It’s like playing a video game with infinite ammo and god mode—you technically “won,” but deep down you know you didn’t earn it.

Why is this happening?

It’s simple: we humans love the process more than the product when it comes to creativity and problem-solving.

When you hit a problem and solve it yourself, you get a dopamine rush. You feel ownership. You remember the exact line of code you wrote to fix that bug because it was your blood, sweat, and tears that made it work.

AI shortcuts remove that emotional investment. You still get the product, but you lose the story behind it. And without the story… it’s just code.

So, what now?

I’m not saying throw away AI tools and go live in a cave writing assembly code on stone tablets. AI is amazing for speeding up boring stuff, and it can absolutely help you learn faster.

But maybe—just maybe—don’t use it for everything.
Struggle a little. Get stuck. Fail a few times. Write code that doesn’t work and then fix it. Because that’s where the fun lives.

If you miss that old-school, “I actually built this” feeling, check out Codecrafters. They throw you into coding challenges where AI can’t just spoon-feed you the solution. You’ll have to think, and when you win, you’ll feel that glorious dopamine hit again.

You can sign up right here.

If AI is the fast food of coding, Codecrafters is like cooking your own meal from scratch—harder, but infinitely more satisfying.

How I Almost Went Bananas with Recursion—And Finally Got It

PRANTA Dutta — Wed, 06 Aug 2025 17:17:39 +0000

Chapter 1: Meet the Banana-powered Brain

I was wrestling with this adventurous, tree-like data structure:

var root = new TreeNode(1,
    new TreeNode(2,
        new TreeNode(3),
        new TreeNode(4)
    ),
    new TreeNode(5, null, new TreeNode(8))
);

And I was trying to do an in-order traversal. You remember in-order, right? Left subtree → Node → Right subtree. So for the example tree:

It should visit nodes in this order: [3, 2, 4, 1, 5, 8].

Chapter 2: The Forsaken `while (true)` Code

I built this monster of a Traverse function:

void Traverse(TreeNode node)
{
    while (true)
    {
        if (node == null) return;
        Traverse(node.left);
        result.Add(node.val);
        node = node.right;
    }
}

It looked kinda right—we go left, then record, then “swing right and loop forever.”
But in reality, this crushed the recursion flow. It never properly returned to earlier calls—it basically hacked the brain messenger system.

Chapter 3: Why It Didn’t Click (AKA Monkey Brain, Cholesterol Edition)

Here’s the meme of my thought process:

🧠 “Okay OK, I know recursion in theory.”
🐒 “My brain’s like bananas + glue when I haven’t used it lately.”
🌀 “Oh man, I forgot call stack is like a stack of sticky notes I’ve gotta peel off!”
😵‍💫 “This code isn’t unwinding properly—why does it never finish??”

So I watched a YouTube video, saw the call stack diagrams, and finally it resonated. I realized the function needed to:

Recurse left
Add current
Recurse right …with each call finishing cleanly—not looping inside one frame.

Chapter 4: The Clean, Proper Solution

Here’s the version that actually slaps:

public static IList<int> InorderTraversal(TreeNode root)
{
    var result = new List<int>();

    void Traverse(TreeNode? node)
    {
        if (node == null) return;
        Traverse(node.left);
        result.Add(node.val);
        Traverse(node.right);
    }

    Traverse(root);
    return result;
}

This exactly mirrors the in-order logic “go left → visit → go right,” and cleverly allows each call frame to fully complete before returning upwards. No weird loops, no internal mutation messing up control flow.

Chapter 5: How to Know When Recursion Isn’t Your Enemy

Recursion only feels scary when it’s invisible. The moment you visualize:

“Call Traverse(1)”
→ push Traverse(1.left)
→ keep pushing until you hit null
→ pop stack and record values
→ pop back and go right...

you realize it’s just a controlled, disciplined flow. Not some magic black box.

Chapter 6: Your Brain Is Fine—You're Learning

A few truths:

Everyone nukes recursion logic sometimes. Hell, senior devs draw diagrams.
Understanding recursion is about trusting the function will return—with stack frames doing the return work.
Spaces between practice make it feel weird—but once you see the pattern again, it snaps into place.

You're simply walking rambunctiously toward mastery, my friend.

TL;DR

Problem: while(true) + node = node.right inside recursion broke in-order logic.
Solution: Clean recursion with:

  Traverse(left);
  Add current;
  Traverse(right);

Realization came when call stack clicked: each function is a sticky-note frame that must fully unwind.

Bonus: Your Codecrafters Plug 🧪

Thanks for pointing out this URL—super helpful if anyone reading this wants hands‑on practice:

Join Codecrafters via this link

DEV Community: PRANTA Dutta

I made Snake. Then I kept going.

What it actually is

"I should add themes"

"I should add sound"

"I should add a high score"

"It would be cool if you could replay your best game"

"Multiplayer would be fun"

"What if there were tournaments?"

"Achievements"

"Push notifications"

"I should add a statistics dashboard"

So what did I actually learn?

The code

No, the AI didn't compromise your npm packages. You did.

Part 1: A quick recap of the dumpster fire so far

August 26, 2025 — The s1ngularity / Nx attack

September 8, 2025 — Qix gets phished, chalk and debug fall

September 15, 2025 — Shai-Hulud Mark I

November 24, 2025 — Shai-Hulud 2.0: The Second Coming

February 20, 2026 — SANDWORM_MODE

May 11, 2026 — Mini Shai-Hulud

Part 2: "But surely the AI helped do all this?"

Argument 1: "The malware was AI-generated, therefore AI is the problem."

Argument 2: "The malware abused AI CLIs, therefore AI CLIs are the problem."

Argument 3: "Slopsquatting proves AI is creating new attack surfaces."

Part 3: What actually went wrong

1. postinstall scripts are an unhinged feature that should not exist

2. We don't actually read our dependencies

3. Maintainers don't have phishing-resistant 2FA

4. We use floating versions and never pin

5. The npm registry has no concept of trust

6. We give CI/CD environments god-mode tokens

7. Nobody is using npm provenance, trusted publishers, or signed commits

Part 4: So where does AI actually fit in?

Part 5: What I'm actually going to do about it

TL;DR

AI Persona — Build, share, and chat with your custom AI companions

Why I built AI Persona

What it does (features at a glance)

Pricing & limits (as listed on Play Store)

Screenshots / visuals

How to try it

How to contribute (for open-source folks)

Developer notes (what to include in README / tech notes)

A suggested dev.to post body (copy-ready)

Roadmap ideas (nice-to-have / next steps)

Closing / Call to action

I Built a Privacy-First Note-Taking App with Flutter — Here's What I Learned

Why Another Note-Taking App?

The Tech Stack

Core Framework

Local Database

Security

State Management & Architecture

Cloud & Backend

Features I'm Most Proud Of

1. Multiple Note Types

2. The Glassmorphism UI

3. Real End-to-End Encryption

4. OCR & Voice Transcription

5. The Freemium Model

Architecture Decisions

Clean Architecture with Service Layer

Database Schema (Drift)

Stream-Based Reactivity

Challenges I Faced

1. Google Play Billing Integration

2. Cloud Sync Conflicts

3. Todo List Auto-Save

What's Next?

Try It Out!

Wrapping Up

Anthropic: Brilliant Models, Bullshit Pricing

🚀 The Praise: They Built Literal Magic

💸 The Pain: Price Tag from Hell

🎭 The “Mission”: Safety or Sales Pitch?

🧑‍💻 Verdict for Developers

⚡ TL;DR

Oracle vs. Google: The API Battle That Shook the Coding World

1. `postinstall` scripts are an unhinged feature that should not exist

Chapter 2: The Forsaken `while (true)` Code