Taking AI's Impact on Coding Seriously for the First Time

Last month, something I noticed while working on a feature has been stuck in my head ever since. I needed to write a regex pattern — nothing complex, but the kind that takes a moment to fully form in your mind. Normally I’d open a browser tab, make a few attempts, test it on regex101.com. This time I typed it into a ChatGPT tab that was already open. Two seconds. It worked.

That small moment stayed with me longer than I expected. What I was asking was simple — but what bothered me wasn’t the correctness of the answer. What bothered me was that my mental process had never engaged at all in those two seconds.

Time to Move Past the First Impression

When ChatGPT was announced in November 2022, reactions around me split into two camps: either “this will change everything” or “all it’s really doing is predicting tokens.” Both are somewhat true, but neither is complete. I spent the first few months staying out of that argument — I used the tool but didn’t take seriously what it actually meant.

What I saw in March was this: the tool writes decent code — not always, it’s inconsistent, it doesn’t earn blind trust. But a different use case had emerged for me: breaking the knowledge-retrieval chain. If you don’t know something, you open documentation, search for an example, then return to your code. That process breaks context. In certain situations, the tool reduces that disruption.

Noticing this felt far more interesting to me than the “AI will replace developers” debate.

Observing What Has Changed

Here’s what I noticed: when I use the tool, some things speed up and some things stay the same.

In the “faster” column: writing repetitive patterns (migration templates, test fixtures), double-checking syntax when I’m not confident, recalling the API of a particular library. These aren’t things that take a long time individually — but they are things that break focus. Being able to keep moving without interrupting the main flow matters more than I realized.

In the “unchanged” column: deciding how to design a feature, thinking through a data model, figuring out where a bug actually lives. The tool either stays shallow on these or fails to inspire confidence. Verifying its output sometimes means going back to the original source anyway — which is exactly the context break you were trying to avoid.

Is There a Cost to Convenience

The question that really makes me think is this: if you always solve something quickly, have you actually learned it?

Let me go back to the regex example. I got a working pattern in two seconds. But in those two seconds I saw nothing — not what each special character meant, not the alternative approaches. It worked, I moved on. If I need something similar within the month, I’ll probably take the same shortcut again.

Is this a problem? I don’t know. It probably depends on context. Regex isn’t a core skill for me — it’s a utility. But if you start applying that logic to everything, you eventually have to ask which skills are genuinely yours.

For an experienced developer, the answer to that question may be different; the fundamentals are already there. I can’t give the same answer for someone early in their career using the same tool the same way.

What I’m Doing Now

In practice, I’ve found that using the tool requires being deliberate. “Does this work?” is a different question from “do I understand why it works?” I try to avoid taking the output blindly — I don’t always succeed, but keeping the intention matters.

I also do this: I quickly read through code the tool produces, especially in an unfamiliar domain. Sometimes the output is wrong and I only catch it by reading. Sometimes it’s correct but written in a way I wouldn’t have written it. That reading moment lets me see something I wouldn’t have learned if I’d skipped it entirely.

When I manage to maintain this habit, the tool is genuinely useful. When I don’t, I gain speed — but something slips away too.

When a new tool enters your toolkit, the real question isn’t what it does — it’s when you should choose not to use it. That’s still something I’m working out.