For millions of developers, ChatGPT was the first AI coding assistant they ever touched — and for many it's still the default. It sits somewhere between a rubber duck and a very fast junior colleague: always available, endlessly patient, and confidently wrong just often enough to keep you honest.
But "reach for ChatGPT" and "get good code out of ChatGPT" are two different skills. This guide is about the second one: how developers actually use it day to day, where it genuinely shines, where it quietly wastes your afternoon, and when you're better off in a purpose-built coding tool.
First, some scale. On our live map at whoisusingai.com, we track the developer populations that make up the audience for tools like this one.
That reach matters here. A general-purpose assistant like ChatGPT isn't a niche tool for one tech hub — it's used by developers in nearly every city we plot, from the biggest metros to towns with a handful of active repos. When something is that broadly adopted, learning to use it well pays off for almost everyone reading this.
How developers actually use it
Strip away the demos and the day-to-day pattern is pretty consistent. Most developers use ChatGPT in a browser tab or a companion window, alongside their editor — not inside it. The dominant modes are:
- Explaining and exploring. Pasting an error message, a stack trace, or an unfamiliar chunk of code and asking "what is this doing and why is it breaking?"
- Scaffolding. Generating boilerplate, a first-draft function, a regex, a config file, or a throwaway script to test an idea.
- Translating. Converting a snippet from one language, framework, or API style to another, or rewriting something more idiomatically.
- Rubber-ducking design. Talking through an approach out loud, listing trade-offs, and pressure-testing a plan before writing anything.
- The tedious stuff. Writing test cases, docstrings, commit messages, and one-off data transforms.
Notice what most of these have in common: they're bounded, self-contained, and easy to verify. That's the sweet spot, and it's the through-line for everything below.
Where it genuinely shines
ChatGPT is excellent at the "blank page" problem. Getting from nothing to a rough-but-workable first draft is where it saves the most time, because reviewing and fixing a draft is almost always faster than writing from scratch.
It's also a superb explainer. When you inherit a gnarly function, or hit a language feature you've never seen, a plain-English walkthrough is genuinely faster than reading docs cold. And it's patient — you can ask the "dumb" follow-up question you'd hesitate to ask a teammate for the fifth time.
Where it's strong, it's reliably strong:
- Common languages and popular frameworks with lots of public examples
- Well-known algorithms, data structures, and standard-library usage
- Small, pure functions with clear inputs and outputs
- Refactoring for readability when you can eyeball the result
Where it struggles — and why
The failure modes are just as consistent as the wins, and they trace back to one root cause: ChatGPT doesn't see your codebase. It works from the text in the conversation plus its training, so anything that depends on context it can't see is where things go sideways.
- It invents things confidently. Plausible-looking function names, library methods, and flags that don't exist. The more obscure the library, the higher the risk.
- It drifts out of date. Fast-moving APIs, framework versions, and pricing change constantly, and the model's knowledge has a cutoff. Always verify version-specific details against the official source.
- It loses the thread on big context. Multi-file changes, project-wide conventions, and subtle cross-module dependencies are hard to convey in a chat window.
- It's agreeable to a fault. Push back and it may "fix" correct code. It rarely tells you your whole approach is wrong.
- Security and correctness aren't guaranteed. Generated code can carry injection risks, weak defaults, or subtle logic bugs that pass a casual read.
None of this makes it unusable. It makes it a tool you supervise, not one you trust blindly.
Good vs. poor use cases, at a glance
| Task | Fit | Why |
|---|---|---|
| Explain an error or unfamiliar snippet | Good | Self-contained; you verify against real behavior |
| Draft a small, pure function | Good | Easy to test and eyeball |
| Boilerplate, configs, regex, one-off scripts | Good | Tedious, low-risk, quick to check |
| Write unit tests for existing code | Good | Bounded input, you review coverage |
| Language/framework translation of a snippet | Good | Clear before/after to compare |
| Multi-file refactor across a real repo | Poor | Can't see the whole project |
| Anything on a bleeding-edge or private API | Poor | Prone to invented or outdated calls |
| Security-critical logic you won't review | Poor | Silent vulnerabilities slip through |
| "Just build the whole feature" with no verification | Poor | Confidently wrong at scale |
The pattern is hard to miss: the "good" rows are small and checkable; the "poor" rows are large, context-heavy, or unverified.
Prompts that actually work
The difference between a mediocre answer and a great one is usually the prompt. A few habits that consistently help:
- Give it the context it can't see. Paste the relevant code, the exact error, your language and framework versions, and what you already tried. Vague question in, vague answer out.
- State the constraints. "No external dependencies," "must run on the version I'm pinned to," "keep it under 20 lines," "match this existing style." Constraints sharpen the output dramatically.
- Ask for the reasoning, then the code. "Explain your approach first, then implement it" catches bad plans before they become bad code.
- Request tests alongside. "Include a few test cases, including edge cases" both improves the code and hands you a way to verify it.
- Iterate in small steps. One focused change per turn beats "rewrite everything." You stay in control and can catch drift early.
- Make it argue with itself. "What could be wrong with this? What did you assume?" counteracts the model's eagerness to agree.
Treat every answer as a draft from a fast, confident colleague who has never seen your repo — useful, but always reviewed.
Where a dedicated coding tool wins
The single biggest limitation above — no view of your codebase — is exactly what editor-integrated tools are built to fix. IDE assistants and agentic coding tools can read your files, respect your project conventions, run in your terminal, and make coordinated edits across many files. For real work inside a real repository, that context is the whole game.
| Dimension | ChatGPT (chat) | Dedicated coding tool |
|---|---|---|
| Sees your full codebase | No | Yes |
| Multi-file, coordinated edits | Manual copy-paste | Native |
| Runs and iterates on code | You do it | Often built in |
| Best for | Explaining, drafting, exploring | Shipping changes in a project |
| Learning & quick answers | Excellent | Varies |
This isn't a knock on ChatGPT — it's about matching the tool to the task. Plenty of developers use both: a chat window for thinking, explaining, and drafting; an integrated tool for actually making changes inside the repo. (We stay neutral on which specific products you pick, and for current features and pricing, check each tool's official source.)
The bigger picture
Zoom out and the adoption story is genuinely global. Our top cities by tracked developers span continents — London leads at 147,775, followed by Bangalore at 140,393, São Paulo at 121,533, and Pune at 115,282 — and the countries behind them are just as spread out.
Where the developers are: top countries by tracked developers
developers
The takeaway for your own workflow: the skill isn't "use ChatGPT" — nearly everyone already does — it's using it deliberately. Lean on it for the bounded, checkable, blank-page work it's great at; reach for a codebase-aware tool when you're making real changes; and verify everything either one hands you.
Curious where your own city lands on the adoption map? Search for it on whoisusingai.com — and see how we build the numbers if you want the methodology behind them.
Search your city on the map →