The gap between how AI is talked about and how it's actually used is enormous. Conference talks promise autonomous agents shipping features overnight. LinkedIn posts claim 10x productivity. Meanwhile, the average developer is copy-pasting a function from Copilot, double-checking it manually, and quietly wondering if this is really that different from Stack Overflow. It is different. Just not in the ways the marketing suggests.
So let's cut through it. Based on what developers are reporting across forums, surveys, and real-world codebases, here's what AI use at work actually looks like in practice.
Boilerplate Is Where AI Earns Its Keep
Ask any developer where they feel the most immediate value from tools like GitHub Copilot, Cursor, or ChatGPT, and they'll tell you the same thing: boilerplate. Nobody wants to write a TypeScript interface for an API response for the twentieth time. Nobody enjoys scaffolding yet another Express route with the same error-handling wrapper they've written a dozen times before.
AI handles this well. Not perfectly, but well enough that the workflow becomes: accept suggestion, skim it, tweak two lines, move on. That's a real time savings. It won't revolutionize how software is architected, but shaving 15 minutes off a repetitive task ten times a day adds up to hours every week.
Where this breaks down is anything with project-specific context. If your codebase has a custom ORM layer, a non-standard folder structure, or an internal design system, Copilot has no idea. It suggests generic patterns that technically compile but don't fit. You still need to know your codebase to use AI well.
Debugging: Surprisingly Useful, With a Catch
This one surprised a lot of developers. Dropping an error message and a stack trace into ChatGPT or Claude and getting a clear explanation of what went wrong is genuinely helpful, especially for errors that are vague or produced by a library you don't know well.
Consider something like this runtime error in a React app:
TypeError: Cannot read properties of undefined (reading 'map')
at ProductList (ProductList.jsx:12:22)A junior developer might spend 30 minutes puzzling over this. An AI will immediately tell you the array you're trying to map over is undefined at render time, suggest adding an optional chain or a default value, and explain why it's likely an async data-fetching timing issue. That's a solid answer. Fast.
The catch is hallucination. Ask about an obscure edge case in a library's internals, and the AI might confidently give you a solution that simply doesn't work, or references an API that doesn't exist. The fix is to treat AI debugging suggestions the same way you treat a junior dev's answer: read it, verify it, don't just paste and run.
This ties to something worth reading: AI won't fix the fundamental honesty problems in how developers work, and that includes over-trusting tools that sound authoritative.
Writing Tests Nobody Wanted to Write
Test coverage is one of those things every team agrees is important and nobody has enough of. AI has become a genuinely popular shortcut here. You paste a function, ask for unit tests, and get a reasonable starting set back in seconds.
The tests aren't always ideal. They sometimes miss edge cases, test implementation details instead of behavior, or make assumptions about mocking that don't match your setup. But they're a starting point. Having something to delete and rewrite is faster than starting from a blank file.
Developers using Jest, Vitest, or Pytest report this as one of their most consistent AI wins. Not because the tests are brilliant, but because the activation energy to write tests is high, and AI lowers it. That's not nothing.
Code Review Assistance and Documentation
Two tasks that developers historically do poorly because they're time-consuming: writing documentation and reviewing code for issues. AI has found a foothold in both.
For documentation, asking an AI to produce a JSDoc comment block for a complex function is faster than writing it yourself, and the output is usually clear enough to keep with minor edits. For a React component, that might look like:
/**
* Renders a paginated product list.
*
* @param {Object} props
* @param {Product[]} props.products - Array of product objects to display.
* @param {number} props.currentPage - The currently active page number.
* @param {Function} props.onPageChange - Callback fired when the page changes.
*/
function ProductList({ products, currentPage, onPageChange }) { ... }Getting AI to generate that takes about 10 seconds. Writing it yourself, with the cognitive overhead of context-switching from coding to documentation mode, takes closer to 3 minutes. At scale, that matters.
For code review, some teams are using AI to do a first-pass scan before human review. It catches obvious things: missing null checks, inconsistent naming, functions that are doing too much. It's not replacing the human review, but it's filtering out the noise so the human reviewer can focus on architecture and logic.
Where Developers Are Still Skeptical
The honest answer is that most experienced developers don't trust AI for anything that touches system design, security, or performance-critical code.
Security is the biggest concern. An AI might write SQL that technically works but is vulnerable to injection if you don't parameterize queries correctly. It might suggest storing a JWT in localStorage without flagging the XSS risk. These aren't hypothetical examples. They're patterns that show up in AI-generated code regularly enough that any security-conscious team keeps a human in the loop on anything auth-related.
Performance is the other gap. AI doesn't know your actual data volumes, your database indexing strategy, or which endpoints are hot paths. It can write a working query. Whether that query scans 50 rows or 5 million rows in production, it has no idea.
There's also the deeper issue around project architecture. AI is very good at the local, the specific, the isolated function. It struggles with decisions that depend on understanding how the whole system fits together. If you ask Copilot to refactor a module, it'll make it look cleaner. Whether that refactor is correct given your service boundaries and data flow is something only a developer with full context can judge.
The Vibe Coding Reality
Vibe coding, the practice of describing what you want in natural language and letting AI generate the implementation, is real and it's genuinely useful for certain contexts. Prototyping a UI, spinning up a quick script, exploring an unfamiliar library. These are cases where the speed-to-working-thing ratio is hard to beat.
But there's a trap. Developers who lean too heavily on vibe coding in production contexts accumulate code they don't fully understand. That code works until it doesn't, and when it breaks, they don't have the mental model to fix it. If you're setting up a new React and TypeScript project, using AI to scaffold the initial config is fine. Letting it write every component without reading what it's generating is where things go wrong.
The developers who get the most out of AI aren't the ones who use it most. They're the ones who use it at the right moments: high-repetition tasks, first-draft generation, quick explanations of unfamiliar code. They stay in control of the decisions that matter.
The Workflow That Actually Works
Across the range of real developer experience, a pattern emerges. The most effective AI-assisted workflow looks roughly like this:
- Write the function signature and a brief comment describing what you need.
- Accept the AI suggestion as a first draft, not a finished product.
- Read every line before committing it. Not skimming. Reading.
- Use AI for the follow-up: "what edge cases am I missing?" or "write a test for this function".
- Keep AI out of security-sensitive, performance-critical, and architecture-level decisions until you have a strong reason to bring it in.
That's not magic. It's just treating AI as a fast, knowledgeable collaborator that needs supervision. Which, if you think about it, is exactly what a good senior developer does with a strong but junior teammate.
The one question worth asking yourself after every AI interaction: do I understand this code well enough to explain it in a code review? If the answer is no, you're not done yet.
For further reading on real-world developer workflows and the honest picture of how AI fits (or doesn't), the original article by Sylwia Lask at dev.to is worth your time. It's grounded, practical, and refreshingly free of vendor spin.
