How I use AI in my dev workflow

AI didn't replace me. It replaced the parts of the job I liked least: searching Stack Overflow for the fifth time this month, writing the same boilerplate component, reading documentation at 11 pm. The rest of the work is still mine.

Here's how the tools actually fit into my day.

Autocomplete that understands context

I use an AI-powered editor that reads the whole file, not just the line I'm on. When I'm inside a typed React component, suggestions know what props exist. When I'm writing a query, they know the schema. The completions are often wrong, but they're wrong in interesting ways that make me think harder about what I actually want to write.

The key is treating suggestions as fast drafts, not answers. I accept, edit, move on.

First drafts of repetitive code

Anything with a clear pattern (a new API route, a typed fetch function, a test file) I describe in a comment and let the AI produce the skeleton:

// GET /api/projects: returns all projects sorted by date desc, typed as Project[]

That one comment usually produces 90% of what I need. The remaining 10% is the thinking that matters: error handling, edge cases, the bits that require understanding the actual system.

Documentation I'll actually read

Reading dense documentation is slow. I paste the relevant section and ask a specific question: "How does ISR revalidation work when using the App Router?" The answer is faster to act on than scrolling through a page of caveats.

I still check the source docs after. AI summaries miss nuance. But the question gets me to the right section faster.

Where I don't use it

I don't use AI to write client-facing copy. I don't use it to make architecture decisions. And I don't paste client code into an external model without being sure the terms are clear.

The work that requires judgment (understanding what a client actually needs, structuring a project so it's maintainable in two years) stays with me.

The honest take

AI tools make me faster on the work I've done before. They make me slightly slower on genuinely novel problems because I have to resist the pull of a confident-sounding wrong answer.

The developers who'll benefit most aren't the ones who hand off the most work. They're the ones who stay sharp enough to know when the suggestion is wrong.

If you're building something and want a developer who uses these tools well, I'd be glad to talk.