DEV Community: shan kulkarni

Why Country/State/City Pickers Are Weirdly Hard

shan kulkarni — Sat, 23 May 2026 04:21:40 +0000

Every time I see this on a wireframe, I lie to myself.

"Yeah, that's easy."

Three dropdowns. Country → State → City.

Then three days disappear.

It starts innocent

Select a country, load states, select a state, load cities.

Then: Singapore has no states. Some countries call them provinces. Some APIs return empty arrays. A handful aren't in the dataset at all depending on which source you're pulling from.

Product wants search because nobody scrolls 195 countries on mobile. Then keyboard nav. Loading states. Error handling for when the city call fails mid-form. Caching so you're not hammering the API on every keystroke.

None of it is hard. It just keeps accumulating. By the third project you're copy-pasting code from your last one and hoping nothing changed. By the fifth you're a little angry.

The data is the actual problem

Country and city names feel stable until you work with them. Turkey officially became Türkiye in 2022. Cities get renamed. The Philippines has over 1,600 municipalities and that number moves. Some datasets recognize Kosovo. Others don't.

Most npm packages I tried were one of two things: a component sitting on a JSON file nobody had touched in two years, or solid current data with no UI layer at all.

Five rebuilds in, I stopped pretending this was handled.

What I built

I built react-country-state-city-picker.

Cascading logic, search, loading states, countries without states, keyboard nav, caching, dark/light mode. There's a single <CountryStateCityPicker> if you want the whole thing wired up, individual pickers if you only need one level, and headless hooks if you want your own UI. No dependencies outside React 18.

I wasn't trying to build something clever. I wanted a picker I could install and not think about again.

Quick start

npm install react-country-state-city-picker

import { CountryStateCityPicker } from 'react-country-state-city-picker'

function ShippingForm() {
  return (
    <CountryStateCityPicker
      onCountryChange={(country) => console.log(country)}
      onStateChange={(state) => console.log(state)}
      onCityChange={(city) => console.log(city)}
    />
  )
}

That's the basic setup. Individual pickers and custom render props are there if you need them.

Try it

MIT licensed, on GitHub: react-country-state-city-picker

If you've rebuilt this before, you know what it's worth.

Originally published at shankulkarni.com

Stop Paying Twice for Claude: Use Your Subscription Like an API

shan kulkarni — Fri, 15 May 2026 13:58:21 +0000

A lot of developers are doing this without realizing it: paying for Claude Pro/Max and separately buying Anthropic API credits for small automation work. For production systems, that split makes sense. For a PR review bot, release note generation, or a few scheduled AI workflows, it usually doesn't.

A GitHub bot with 12 runs per day does not need enterprise AI infrastructure.

Anthropic supports OAuth tokens for Claude Code workflows, which means some automation tools can authenticate using your existing Claude subscription instead of a separate API billing account. Starting June 15, Claude subscriptions also include separate monthly Agent SDK credits specifically for this kind of automation usage.

What's included in your plan

Anthropic is adding official Agent SDK credits to Claude subscriptions on June 15:

Plan	Monthly credit
Pro	$20
Max 5x	$100
Max 20x	$200

This covers Claude Agent SDK usage, the claude -p command, Claude Code GitHub Actions, and third-party apps authenticated through the Agent SDK. Credits refresh monthly and don't roll over.

If you exceed the monthly credit, usage spills over to standard API rates — but only if you've enabled extra usage on your account.

What this covers

Small developer workflows: GitHub Actions, n8n agents, local coding helpers, repo automation, CI scripts, cron jobs, personal tooling. Not production infrastructure.

How it works

Install Claude Code:

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

Generate a token:

claude setup-token

The command opens a browser-based Claude authentication flow and stores credentials locally for Claude Code workflows.

You'll get something like:

sk-ant-oat01-xxxx

This is different from a standard Anthropic API key (sk-ant-api03-xxxx). The OAuth token ties to your subscription rather than a separate billing account.

GitHub Actions

Anthropic's GitHub Action supports CLAUDE_CODE_OAUTH_TOKEN directly, so your workflow draws from your monthly Agent SDK credit instead of a separate API account:

env:
  CLAUDE_CODE_OAUTH_TOKEN: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}

That's enough for most lightweight coding workflows.

n8n and other tools

Some community tools and wrappers already support Claude OAuth tokens directly. Others still expect standard Anthropic API keys, so compatibility depends heavily on the ecosystem you're using.

When to use this vs. the API

Subscription OAuth makes sense for personal projects, prototypes, developer tooling, and anything low-volume. Switch to the official API when you're building something customer-facing, need predictable throughput, or running at any real scale.

Limitations

Credits are per-user — there's no pooling across a team. A Pro plan's $20 goes fast if your agent is tool-heavy. This is usage credit, not unlimited access. OAuth token support is patchy across frameworks, so you'll hit compatibility issues depending on what you're building on.

Anthropic is already separating consumer subscription usage from large-scale automation. Treat this as a lightweight developer workflow feature, not stable backend infrastructure. Don't build critical business systems around it.

Most developers optimize for scale before they even have usage.

Use the subscription you're already paying for. Move to API billing when your workload actually earns it.

Originally published at shankulkarni.com

Hello, world

shan kulkarni — Tue, 12 May 2026 10:36:51 +0000

I learned most of what I know from people who had no reason to share it but did anyway. A blog post from some engineer explaining exactly the bug I'd been stuck on. A Stack Overflow answer that saved me an afternoon. Source code I could read and actually learn from.

That's the whole reason I'm doing this.

I've spent over a decade building things - web, mobile, SaaS, backends that had to hold up under real load, and more recently AI. A lot of that knowledge just sits in my head, or in Slack threads from three jobs ago that nobody's going back to read.

Why I'm writing

Free, public writing by other engineers is how I got here. No course, no bootcamp - mostly just people who decided their knowledge was worth putting on the internet. I'm not where I am without that.

So I'm putting mine out there too. If something I write saves someone a few hours on a problem I've already solved, that's a good enough reason.

What I'll cover

Ten years across a lot of different terrain:

Web and mobile product development
SaaS - building it, scaling it, keeping it alive
Backend systems and what happens when they break under load
AI integrations - what's actually useful and what isn't
The stuff that doesn't fit neatly anywhere: decisions, tradeoffs, hiring, the unglamorous parts

The real version. Not the retelling where everything worked out.

How often

When I have something worth saying. Not on a schedule.

If you want to follow along, there's an RSS feed.

Your AI-generated code works. It's probably not production ready.

shan kulkarni — Tue, 12 May 2026 10:10:49 +0000

Shipping features with Claude Code or Cursor is fast now. Getting that code to hold up in production is a separate problem entirely. AI reduces implementation time. It does not produce production engineering.

I went through 8 AI-generated production apps. They all had roughly the same issues:

Supabase RLS misconfigured
secrets sitting in the codebase
no rate limiting, no caching
bad data structures
components re-rendering constantly
AI features open to prompt injection and RAG attacks
basically no tests around anything important

Most of them worked. Hardly any were production ready.

A year ago, writing code was the bottleneck. Now it's reviewing and hardening what got generated. That's a different skill, and most teams aren't there yet.

The reason this keeps happening: AI is excellent at extending local patterns. It's much worse at understanding long-term system boundaries, scaling behavior, and operational risk. It generates code that looks right in isolation and breaks under real conditions.

Six things I look at before calling AI-generated code production ready.

Security

This is where things go quietly wrong. The code compiles, tests pass, and then someone finds a misconfigured auth check six months later.

Auth flows: does every protected route actually verify the session? Are role checks on the server, not just the client?
Exposed secrets: API keys in frontend code, .env values hardcoded as fallbacks, secrets logged during error handling
Injection risks: SQL, command, and path injection in any user-controlled inputs
LLM prompt injection: if your app passes user input into an AI prompt, can a user rewrite what the AI does?
RAG document injection: can a user upload a document that manipulates your AI's behavior?

Quality

Happy path works fine. The edges are where it falls apart.

Dead code and unused imports — AI generates confidently, including things it never wires up
Weak typing: any used to paper over uncertainty, missing null checks, unsafe type assertions
Anti-patterns: misused hooks, unnecessary useEffects, logic in the wrong layer
Architecture drift: after 50 prompts, does the codebase still follow the same conventions it started with?

Performance

AI-generated code tends to duplicate logic instead of abstracting correctly, miss caching layers entirely, and generate DB access patterns that work fine in development and fall apart under load.

Slow queries: missing indexes, N+1 patterns, fetching more columns than the page needs
Cold starts: heavy dependencies, unoptimized bundles, serverless functions loading too much on init
Render cascades: components re-rendering on every state change because nothing is memoized
Heavy bundles: entire libraries pulled in at the top level when one function was needed

Compliance

Some of this is stack-specific. PII handling isn't.

Payment flows: are Stripe webhooks handled correctly? Any card data stored that shouldn't be?
App Store: are in-app purchases routed right? Anything that'll get the app rejected on review?
Data handling: GDPR basics — deletion, consent, data residency for EU users
PII and external APIs: are you sending user data to an AI API you haven't agreed to share it with?

Testing

There are usually tests. They usually test the wrong things.

Critical paths: auth, payments, data writes — the flows that actually hurt users when they fail
Are tests checking behavior, or just that the function runs without throwing?
Are edge cases there, or just the happy path the AI was given in the prompt?

Observability

Most AI-generated codebases have none. Everything's fine locally. Then it breaks in production and there's nothing to look at.

Error tracking: are exceptions being captured, or swallowed silently?
Logging: structured and useful, or just console.log statements scattered around?
Alerting: do you find out when something breaks, or do users tell you?
Tracing: for AI calls and external APIs, can you follow a request end to end?

Most teams are treating code generation and code review as the same problem. They're not. The faster teams ship with AI, the faster review debt accumulates — and most teams have no process for it yet.

That's why I built Vibe Audit. It runs this audit automatically across your codebase and surfaces production risks before they become incidents. GitHub

Ran it on a real app. This is what came back.