How I Actually Use LLMs Day to Day as a Developer

There is a lot of noise about AI replacing developers and almost none about the boring reality: LLMs have become a normal tool in the working day, like a debugger or a good search engine. They are neither magic nor useless. Here is where they actually fit into mine, after the novelty wore off and only the genuinely useful habits survived.

The tasks I now delegate by default

Some work I no longer do by hand unless there is a reason to:

• Boilerplate and scaffolding. A new API route, a Zod schema from a sample payload, a config file in a format I use twice a year. Mechanical, verifiable, gone in seconds.
• First-draft tests. The model writes the obvious cases; I spend my time on the edge cases that actually matter. The blank-page cost of testing drops to near zero.
• Explaining unfamiliar code. Dropped into a legacy module, "walk me through what this does and where the side effects are" is faster than reading top-to-bottom cold.
• Format and language translation. Bash to Dockerfile, cURL to fetch, a stack trace into a plain-English cause. This is the most reliably correct category, because I can check it instantly.

The tasks I keep for myself

Delegation has a boundary, and staying on the right side of it is the whole skill:

• Architecture and data modeling. The decisions that are expensive to reverse are exactly the ones worth thinking through myself. An LLM is a fine sounding board here, but the call is mine.
• Anything security-sensitive. Auth flows, input validation at trust boundaries, permission checks. I will use a model to review these, never to originate them unexamined.
• The final read of any diff. Whatever generated it, I read every line before it merges. The subtle bugs — a missing await, a swapped comparison, a swallowed error — hide in code that looks completely reasonable.

The workflow that ties it together

The habit that made the biggest difference was matching the tool to the shape of the task:

Small, in-file, "help me type this"  ->  editor autocomplete
Clear, cross-cutting, "just do this"  ->  an agent
Fuzzy, "help me think"                ->  a chat conversation

Most of my day is the first bucket — inline completion while I write code I already understand. The second bucket is where whole tasks disappear: a dependency upgrade across the repo, adding validation to every endpoint, wiring tests for an existing module. The third bucket is thinking out loud when I am stuck or designing something new.

The mistake I see people make is forcing one tool to cover all three. An agent is overkill for a one-line edit; autocomplete is useless for "migrate this whole feature." Reaching for the right shape is most of the productivity gain.

What actually changed, honestly

The headline is not that I write less code — it is that I spend less time on the parts of coding that were never the point. Less boilerplate, less format-wrangling, less staring at an unfamiliar file. More time on design, on edge cases, on the judgment calls that are genuinely mine to make.

That is the quiet version of the AI coding story. Not replacement, not magic — just a sharp tool that, used with a bit of discipline, removes a real amount of friction from the day and leaves the interesting work intact.