ChatGPT for Developers: How I Actually Use It in My Daily Workflow

There’s a version of this post I could write where I tell you ChatGPT has transformed the way I code and I never want to work without it. There’s another version where I tell you it’s overhyped and you’re better off reading documentation.

The honest answer is somewhere between those two — and it depends entirely on how you use it.

I’ve been using ChatGPT almost daily for about a year and a half now, across React projects, Magento 2 work, Node.js with TypeORM, and general debugging sessions. I’ve had sessions where it saved me two hours. I’ve had sessions where it confidently wasted forty minutes of my time with a solution that looked right and wasn’t.

So this isn’t a “here are 10 ChatGPT prompts for developers” post. This is just an honest breakdown of how it fits into my actual workflow — the parts I trust, the parts I don’t, and why that line exists where it does.

The thing I use it for most: understanding code I didn’t write

This one is underrated and I don’t see it mentioned enough.

When I’m dropped into a codebase I didn’t build — which happens more than I’d like — there’s always that period of reading through files trying to figure out what’s actually going on. Some of that time is genuinely useful. But some of it is just slow.

Pasting a confusing function into ChatGPT and asking “what does this do, step by step, and why would someone write it this way” cuts that slow part significantly. It’s not always right, but it’s usually right enough to give me a starting point I can verify faster than I could figure it out from scratch.

I do the same thing with error messages I haven’t seen before. Not just “what does this mean” — that’s what Google is for. I paste the full stack trace, the relevant file, and ask “what is likely causing this and where would you look first.” The quality of that response depends heavily on how much context I give it, but when I give it enough, it’s often pointing in the right direction.

Writing boilerplate I know how to write but don’t want to

This is probably the most common use case people talk about, and it’s genuinely valid.

TypeORM entity definitions, basic Express route handlers, repetitive React component structure, SQL queries for standard CRUD operations — I know how to write all of these. I’ve written hundreds of them. Writing another one from scratch adds nothing to my skills and costs me time I could spend on the parts of a problem that are actually interesting.

ChatGPT is fast at this. I describe what I need, it generates a first draft, I read it, adjust what’s wrong or specific to my setup, and move on. The key word there is “first draft” — I never paste it in and walk away. I read every line before it goes into a codebase.

For Magento 2 work specifically, I’ve found it useful for generating the boilerplate XML — di.xml, module.xml, registration files — because the structure is always the same and always just slightly annoying to type from memory. That said, Magento is niche enough that I verify the output more carefully than I would for something like basic JavaScript.

Debugging — with caveats

ChatGPT can be useful for debugging, but this is where I’ve also been burned the most.

The pattern that works: I describe the problem clearly, share the relevant code, share the exact error, and ask what could cause this. When the bug is a common pattern — a missing dependency in a useEffect, a promise that’s not being awaited, a TypeORM query that’s returning undefined because a relation isn’t loaded — it spots it quickly.

The pattern that doesn’t work: vague descriptions. “This function isn’t working, here’s the code” gets you a generic checklist. “This TypeORM findOne is returning null even though the record exists, I’ve confirmed the ID is correct, and the relation is defined as ManyToOne — here’s the entity and the query” gets you something actually useful.

The biggest caveat is hallucination. I’ve had ChatGPT tell me to use a method that doesn’t exist in the version of a library I’m running. It does this confidently, with no indication it’s guessing. I’ve learned to always check the official docs when it references something specific — a method name, a config option, a package feature. That takes thirty seconds and has saved me more than a few rabbit holes.

Writing and improving documentation

This one isn’t glamorous but it earns its place.

Writing a README, documenting a utility function, writing inline comments for something complex — I don’t enjoy this work and I’m not particularly good at making it clear to someone who didn’t write the code. ChatGPT is decent at it.

My usual approach: I write rough notes about what something does, paste in the code, and ask it to write documentation aimed at a developer who’s seeing this for the first time. Then I edit the output to match how we actually talk about things on the project. It’s faster than writing from scratch and usually catches things I’d have left out because I already know them.

Learning something new — but carefully

When I’m picking up a concept I haven’t worked with before, ChatGPT is useful as a starting point. I’ll ask it to explain something like I’m a developer who knows JavaScript but hasn’t used this specific API before. That framing usually produces a practical explanation rather than a textbook definition.

The important thing I’ve learned: use it to get oriented, then go to the official documentation to actually learn. The docs are what’s correct. ChatGPT’s training has a cutoff, and in fast-moving ecosystems like React or Node.js, the specific details can be out of date or just subtly wrong. The mental model it gives you is usually fine. The specific syntax or API details — verify them.

What I’ve stopped using it for

Anything involving security. Authentication logic, permission checks, data sanitisation — I don’t want AI-generated code in those places without a thorough review, and at that point I’m better off writing it myself and knowing exactly what it does.

Anything my team will rely on in a critical path without me understanding it completely. If I can’t explain to a colleague exactly how a piece of code works, it doesn’t belong in the codebase regardless of where it came from.

Architecture decisions. “How should I structure this feature” is a question that needs context about your team, your codebase, your constraints, and your future plans. ChatGPT doesn’t have any of that. Its suggestions will be generically reasonable and specifically unhelpful.

The honest summary

ChatGPT is a productivity tool, not a replacement for knowing what you’re doing. Used well, it handles the repetitive and time-consuming parts of development so you can focus on the parts that actually need your judgment. Used badly, it produces plausible-looking code that you haven’t understood and can’t maintain.

The developers I’ve seen get the most out of it are the ones who treat the output like a code review — useful input from someone who might be right, that you verify before you trust.

If you’re just getting started with it, I’d suggest reading my earlier post on how AI coding tools actually work under the hood first — understanding what these models are actually doing makes it much easier to know when to trust them.

What do you actually use ChatGPT for in your own workflow? I’m curious whether people find the same patterns useful or whether it varies a lot by the kind of development work you do.