LLMs as Dev Tools: How I Use AI in My Engineering Workflow

LLMs as Dev Tools: How I Use AI in My Engineering Workflow

Let me be honest about something upfront: I was skeptical.

Not in a "I don't believe the hype" way. More like... I'd seen too many developers treat AI as a replacement for thinking. Prompt it, copy it, ship it. And the code was always almost right in a way that was somehow worse than being obviously wrong.

So for a while I kept my distance. And then I actually started paying attention to how I was using it, and something shifted.

The Wrong Way to Use It

"Write me a REST API for user authentication in NestJS."

You'll get something. It'll look reasonable. It'll probably even run. But it won't know your project structure, your error handling conventions, your auth strategy, your database schema. It's a stranger's code wearing your codebase's clothes.

That's not useful. That's tech debt that compiles.

The problem isn't the LLM. It's the question. Vague input, vague output. Garbage in, confident garbage out.

Where It Actually Helps

Here's what changed for me: I stopped asking LLMs to write code and started using them to think with.

When I'm designing a system, I'll describe the problem out loud — what I'm trying to do, the constraints I'm working with, the tradeoffs I'm seeing — and use the response as a pressure test. Does it catch something I missed? Does it suggest a tradeoff I hadn't considered? Sometimes the answer is no and I learn something by understanding why the suggestion is wrong for my case.

That's useful. That's like rubber duck debugging with a duck that occasionally knows what a B-tree is.

The Specific Things I Actually Do

Boilerplate is the obvious one. Setting up a new NestJS module, wiring up a new Prisma model, scaffolding a Next.js page with the right data fetching pattern — I'll let the LLM handle the skeleton while I focus on the logic that actually matters.

Regex and string parsing. I'll be real — I don't enjoy writing regex. Nobody does. If I need to parse NMEA sentences or extract structured data from messy text, I describe the format and let it draft the pattern. I still verify it. But I didn't spend forty minutes in a regex debugger first.

Unfamiliar APIs and SDKs. When I'm integrating something new — AWS SDK, a new payment provider, an unfamiliar Rust crate — instead of reading through three layers of documentation, I'll ask for a working example of the specific thing I need, then read that alongside the docs. It's faster and the docs make more sense with a concrete anchor.

Explaining weird behavior. This one surprised me. When I hit a bug I don't understand — something subtle in Rust's borrow checker, an unexpected async behavior, a PostgreSQL query plan that doesn't make sense — explaining it to an LLM often helps me understand it myself. And sometimes the response actually knows what's going on.

The Part Nobody Admits

LLMs are confidently wrong with alarming regularity. They'll hallucinate API methods that don't exist. They'll suggest patterns that were deprecated two versions ago. They'll write Rust that doesn't compile and act like it definitely should.

So the mental model I've landed on is this: treat every output like code from a junior developer who's very smart, very fast, and has zero knowledge of your specific context. You wouldn't merge that PR without reading it. Same rule applies here.

Review everything. Understand what it's doing before you use it. The moment you ship code you don't understand because an LLM wrote it, you've created a liability you can't debug.

What It Doesn't Replace

System design. Knowing when to use a queue vs. a direct call. Understanding why your p99 latency is spiking. Deciding whether to normalize that database table or denormalize for read performance.

These require context, judgment, and experience that lives in your head — built up from the times things broke in production, the architectural decisions you got wrong and had to undo, the edge cases you found at 2am.

An LLM can discuss these things. It can surface considerations you might have missed. But it can't feel the weight of a decision the way you do when you're the one who has to maintain what gets built.

The Honest Conclusion

AI made me faster. Not because it writes my code. Because it handles the parts of coding that are mechanical so I can spend more time on the parts that actually require me.

That's the job — knowing which is which.