How AI Is Changing the Way We Approach Code — and More
Time to stop fearing and start understanding
Let me be blunt: most conversations about AI among developers are either panic or denial.
AI will replace developers. Chatbots don’t understand context, they’re a toy. Two more years and half of us will be out of work.
I’ve been writing code for years. I care about application architecture, about AI and machine learning, and about security — and in every one of those fields, AI gave my skills a boost I didn’t expect. I build something, I hit a wall, I reach for AI. Over time I built my own flow around it: a way of working that carries me instead of getting in the way. I build faster now. I don’t flinch at the next obstacle. And I have more ideas than I used to, not fewer — which is the opposite of what the panic predicted.
AI doesn’t replace the programmer. It replaces the programmer who doesn’t use AI.
That’s not a slogan. So let me pay for it with a real example, because I’m tired of reading this claim from people who never do.
Two years, then a day
The clearest example I have is my own. mailmock.app — a side project of mine — sat untouched for two years. Not abandoned on purpose, just cold. There were features I’d wanted the whole time, things I kept turning over in my head and never built — because coming back to two-year-old code means rebuilding the entire mental model before you can safely change a line, and I never had the run of evenings that takes.
I came back to it with AI in my flow. The features I’d been thinking about for years, I added in a day.
A security layer, specifically: spam scoring for incoming mail, and a ClamAV hook that actually scans message bodies and attachments for malware. Real features, the kind I’d sketched in my head a dozen times and never sat down to wire up.
Here’s the part worth being precise about, because “AI built it in a day” is the lazy version of this story and it’s wrong. AI didn’t know which features mattered — I’d been carrying those for two years. It didn’t know the project’s constraints, or why I’d made the odd choices I did. What it removed was the tax: the cost of re-entering my own code, the friction of the plumbing, the activation energy that had kept a one-day job sitting for the better part of a thousand days.
That’s the boost, and it’s the same in every field I work in. The wall was never the code. The wall was the cost of starting — and when starting gets cheap, you don’t just finish faster. You attempt more. You stop pre-emptively killing ideas because they’d cost a lost weekend to even try. That’s the change nobody warned me about: not that I’d write code faster, but that I’d stop talking myself out of things.
None of which works if you don’t know what you’re doing. Which is exactly the point.
Where the difference is real
🐛 Debugging Before: hours with logs, stack traces, and Stack Overflow. Now: I describe the system’s behavior and get a few hypotheses back — and at least one usually hits the mark. Not because AI “knows better.” Because it forces me to state the problem out loud, in order, with the constraints named. That’s already half the solution. I’ve solved bugs while typing the prompt.
🔁 Code review and refactoring You paste in old code, ask “what could go wrong here when this scales?” — and you get a conversation, not a checklist.
🔐 Application security Reviewing code for vulnerabilities, CVEs, potential attack vectors — AI does a credible first pass in the time it takes me to open my tools.
It does not replace a pentester. It replaces the excuse for not looking. Most vulnerabilities in most codebases aren’t exotic; they’re the ones nobody had a spare afternoon to go find. A first pass that costs ninety seconds changes the economics of who gets reviewed and how often. It raises the floor for the whole team.
And it takes knowledge to judge every one of these answers. Which brings us to the point.
Where it still needs me
There’s a flip side, and it’s consistent enough that I’ve learned to watch for it. AI is good with business logic — give it the rules and it encodes them faithfully. Where it slips is one level up: the architecture. Separation of responsibilities. Where one module should end and the next begin.
Ask for a feature and you’ll often get it working, but with everything piled into one place — the controller doing validation and business rules and persistence, or a service quietly taking on four jobs. It runs. The tests pass. And it’s exactly the kind of thing that’s cheap to accept today and expensive to live with in a year.
So I don’t accept it. I pull the responsibilities apart, draw the module boundaries, put the mapping where mapping belongs — before it lands. The AI optimized for working, because working is what I asked for and what it can see. It has no stake in the version of this codebase that exists eighteen months from now. It can’t want the structure to be good later, because for the model there is no later.
That judgment — this belongs here, that doesn’t, this seam will cost us — isn’t something I can prompt my way to. It is the competence. The tool doesn’t supply it; it assumes I already have it.
Knowledge still matters. Maybe more than ever.
AI is not a magic box for someone who doesn't know the fundamentals. It's a multiplier for someone who knows what to ask — and knows how to judge the answer.
If you don’t understand architecture, you can’t tell whether a proposed pattern makes sense in your context. If you don’t know security basics, you won’t catch that the AI just suggested a vulnerable solution. If you don’t have domain experience, you won’t notice that the generated code is technically correct but makes no business sense.
And there’s a second-order effect worth naming. The fundamentals travel in a way languages don’t. A developer who knows patterns, paradigms, and how systems are structured isn’t bound to one language or one stack — the hard part was never the syntax, and AI now fills that in for whatever you point it at. So the transferable knowledge — architecture, design, judgment — is exactly what compounds. In a market where anyone can generate code, that fundamental knowledge is a bigger edge than it’s ever been.
AI makes a good developer faster. It doesn’t make a bad one good.
But then where does competence come from?
Here’s the uncomfortable question, and I’d rather raise it than let you raise it in the comments.
I learned architecture by writing bad architecture and living with it. I learned security by shipping something exploitable. The reps were boring — boilerplate, plumbing, the tenth CRUD endpoint — and the reps are exactly what AI now eats. So if AI only multiplies competence you already have, and it’s quietly removing the drudgery where competence used to be forged, what happens to the person who joins the industry next year?
I don’t have a clean answer. I have a suspicion: the reps don’t disappear, they move. They move from producing to judging. The junior who reads every AI suggestion, argues with it, and makes it justify itself is doing reps — harder ones, earlier, at a level of abstraction I didn’t reach for years. The junior who accepts the diff and moves on isn’t learning slower than I did. They’re not learning at all.
Which means the whole thing turns on one habit: do you interrogate the output, or do you accept it?
Both stances are risky — including the one that looks like enthusiasm
The industry talks endlessly about the developer who fears AI. Fine. That person is inconvenienced.
The person who trusts it is the one shipping the incident.
I’ve watched code go into review where the author could not explain a line of it. Not because they’re lazy — because it looked right, the tests were green, and nothing in the process forced them to ask. That’s the failure mode nobody posts about, and it’s the one I actually see. Fear costs you speed. Blind trust costs you the thing you can’t get back: the ability to tell whether your own system is correct.
Autopilot isn’t dramatic. It doesn’t look like a crash. It looks like a smooth, productive week where nobody understood anything.
And it isn’t only about code
The same rule holds across every field I work in, and the pattern is what convinced me it’s a rule and not a preference.
In security and CTF, AI accelerates recon and hypothesis-building — but the expertise is in telling a real vector from noise, and noise is what it produces most of.
In architecture, it proposes options fluently. What it can’t tell you is which constraint in your system is non-negotiable — the one nobody wrote down, that you only know because you’ve been burned by it.
In machine learning and AI work itself, it speeds up the plumbing while staying completely indifferent to whether the problem is worth solving in the first place.
Different fields, one rule: the tool is a multiplier on what you already understand. Give it nothing to multiply, and you get nothing back.
What’s actually being revalued
I won’t pretend nothing will change — that would be dishonest. What’s changing is what we value in a developer’s work.
| Less | More |
|---|---|
| Mechanically churning out boilerplate | Asking the right questions |
| Copying ready-made solutions | Understanding the system as a whole |
| Working on autopilot | Assessing risk and making decisions |
Good news for those who want to understand what they’re doing. Hard news for those who’ve spent years on autopilot.
What this looks like in practice
Four things I actually do:
🤝 I treat AI like a pair programmer with an enormous memory and no stake in the outcome — not like an oracle
🔍 I verify every suggestion — especially in security and architecture, where being plausibly wrong is worse than being obviously wrong
⚡ I use it to speed up exploration, not to replace thinking
🔀 I ask for alternatives, not just “how do I do this” — a single answer tells you nothing about the space it came from
If you take one, take the last. A model asked for the solution will always produce one, with total confidence, from a space it never showed you.
Wrapping up
I’m not writing this to reassure the industry.
There’s a real divide, and it isn’t between “old” and “young” developers. It’s between people who interrogate the output and people who accept it. Everything else — years of experience, language, stack — matters less than that one habit.
Conscious use of AI is a new professional competence. Just like the debugger, version control, or CI/CD once were — first “why would I need this,” then “how did I ever work without it.”
We’re in the “why would I need this” moment. Better to wake up sooner than later.
This was the why. In the next post, I’ll get concrete about the how — the exact way I work with AI day to day: how I set up context, where I let it run, and where I refuse to.
Because mindset without method is just an opinion. Follow along — and let's build the method together.