What Changed in My Workflow When I Started Using AI

Six months ago, AI was everywhere. Every day, there seemed to be a new tool, a new feature, or a new prediction about how AI would change web development.

Some said AI would become an essential part of every workflow. Others said it was mostly hype and wouldn't make much difference in the long run.

I wasn't sure what to believe. Instead of following the debate, I decided to test AI tools in my own web development work and see what happened.

Over the next six months, I was using AI regularly for coding, debugging, research, and everyday tasks. Along the way, I learned where it saved time, where it struggled, and where human judgment still mattered most.

Here's what I found.

The First Thing That Changed: Where I Spend My Attention

Before AI tools, a big chunk of my day went to work I'd describe as mechanical.

What That Mechanical Work Looked Like

• Writing repetitive component structures from scratch


• Looking up syntax I'd used a hundred times but couldn't quite remember


• Writing tests for straightforward, predictable functions


• Setting up boilerplate configurations I'd built a dozen times before

This work wasn't hard. It was just slow. And it pulled my attention away from the parts of development I find genuinely interesting, architecture decisions, novel problems, and figuring out why something breaks.

After six months, that ratio shifted. Not because the mechanical work disappeared, but because it got faster. What used to take 30 minutes now takes 5. The attention I was spending on boilerplate is now available for the problems that actually need thinking.

That's the real change. Not "AI writes my code." More like "AI handles the parts I don't need to think about so I can focus harder on the parts that matter."

What I Actually Use and What Each Does Well

I've tested several tools seriously enough to have real opinions. Here's how each one fits into my workflow.

GitHub Copilot

Copilot lives inside the editor and autocompletes as you type. It feels like having a fast typist next to you who knows your codebase.

It's excellent at pattern completion. If you write a function similar to something you've built before, Copilot fills in the rest accurately. Where it struggles is with novelty, new patterns, complex logic, and unusual requirements. It guesses based on patterns and sometimes guesses wrong with full confidence.

Claude

Claude handles longer context better than any tool I've used. When I need to work with a large file, explain a complex codebase decision, or debug something that requires reading across multiple components, Claude's ability to hold and reason about more context produces better results.

DIY web development is popular among most devs, but I would recommend hiring an agency if you are building a serious project, even when building a website using AI. There are a lot of things that AI still can't do until an expert or a subject knowledge peson is giving prompts.

ChatGPT (GPT-4o)

I use ChatGPT mostly for quick reference and exploratory thinking. When I'm unsure what direction to take on a problem, talking it through with GPT-4o helps me clarify my own approach. It's more conversational than Copilot. The context window is smaller than Claude's, so I use it for shorter, more focused interactions.

Cursor

Cursor changed how I think about the whole workflow. It's a code editor built around AI, not a plugin bolted on, but the actual core of the product. The Composer feature lets you describe what you want and generates code across multiple files at once.

For spinning up new components or features, Cursor is faster than anything else I've tried. The trade-off: it's optimized for speed, so the output sometimes needs cleanup before it meets production standards.

Tool Comparison at a Glance

Each tool has a specific place. The mistake most developers make is trying to find one tool that does everything. The better approach is to figure out which tool handles each type of task best.

The Debugging Shift

Debugging used to follow a predictable pattern. Read the error. Google it. Find a Stack Overflow thread from 2018. Try the solution. Discover that the API has changed. Google again. Eventually figure it out.

How That Changed

When I paste an error with the relevant code into Claude or ChatGPT, I get a diagnosis that's usually correct, explains why the error is happening, and suggests a fix with context about what the fix actually does.

This isn't always faster; sometimes the old approach works immediately. But for unusual errors, complex stack traces, or errors in unfamiliar codebases, AI diagnosis saves significant time.

The more important shift is in how I approach debugging now. I spend less time trying random fixes and more time understanding what's actually wrong. Explaining a problem clearly to an AI forces you to understand it well enough to articulate it, which often gets you halfway to the solution before the AI even responds.

What AI Is Still Bad At

I want to be honest here because a lot of writing about AI tools skips the failures.

Limitations

• 
  Hallucinated APIs: Copilot will autocomplete a function call to a method that doesn't exist. ChatGPT will confidently tell you a library supports something it doesn't. Claude is better about this than the others, but it still happens.


• 
  Subtle code issues: AI-generated code often passes the surface test; it looks right, it runs without errors, but has problems underneath. State management bugs. Unhandled edge cases. Security issues that only surface under specific conditions. You cannot ship AI-generated code without reviewing it as carefully as you'd review code from a junior developer.


• 
  Novel problems: If you're working on something without good training data, a niche framework, an internal API, or an unusual architecture, AI becomes less useful fast. The pattern-matching breaks down when there are no patterns to draw from.

What It Means for How You Learn

When I encounter a library or framework I haven't used before, I used to read the documentation linearly and work through examples. Now I start by asking Claude to explain the core mental model, what it does, why it works the way it does, and what the key concepts are. Then I look at the documentation for specifics.

The Risk Worth Naming

Understanding the mental model first means the documentation makes more sense when I read it. But there's a risk: if you use AI to write code you don't understand, you're accumulating technical debt in your own knowledge.

You can ship faster short-term, but you can't debug problems, make good architecture decisions, or explain your codebase to your team. The developers getting the most out of AI tools use them to go faster on things they already understand, not to skip understanding things they need to know.

The End

AI tools made me faster. The gains are real, measurable, and consistent.

The biggest gains came in mechanical work, boilerplate, repetitive patterns, and standard configurations. Smaller but meaningful gains showed up in debugging, code review, and learning new technology.

What didn't change: the need to understand what you're building, the judgment required for good architecture decisions, the ability to read code and spot problems, and the skill of shipping code that actually works in production.

AI is a leverage tool. It amplifies what you already know. If you know how to build good web applications, AI helps you build them faster. If you don't know yet, AI can help you learn faster, but only if you treat its output as a starting point to understand, not a finished product to ship.

That's the honest version of what changed.