A few years ago, my workflow had a lot of friction in it that I'd simply accepted as "the job." Reading unfamiliar docs for an hour to use a library for ten minutes. Writing the same boilerplate for the hundredth time. Staring at a stack trace from a corner of the codebase I'd never seen. None of that was the interesting part of engineering, but it ate most of the day.
AI didn't replace the interesting part. It mostly deleted the friction around it. That's the honest version of how AI changed the way I build software — not magic, not "it writes the app for me," but a real shift in where my hours go.
The story
I resisted it at first. The early hype made it sound like you'd type a sentence and get a finished product, which is nonsense, and the nonsense made me dismiss the whole thing. What changed my mind wasn't a demo. It was a boring Tuesday where I needed to integrate a payment provider I'd never used, on a tight deadline.
Normally that's a half-day of reading docs, copying examples, and debugging the gap between what the docs say and what actually happens. Instead I described what I was building, pasted the errors I hit, and worked through it in a conversation. What used to be four hours of context-switching became forty minutes of actual problem-solving. I shipped that integration before lunch.
That was the moment it clicked: AI is best at the work that sits between the real work. The lookups, the translations, the first drafts, the "how do I even start" friction. The part where I decide what to build, how it should be structured, and whether it's actually correct — that's still mine, and it always will be.
Since then it's become part of how my whole team works. We use it to draft components, explain unfamiliar code, write the tedious tests nobody volunteers for, review diffs for obvious mistakes before a human looks, and turn a vague idea into a starting point we can react to. It's like having a tireless junior engineer who has read everything and remembers nothing about your specific context — incredibly fast, and incapable of being trusted blindly.
What actually got better
Speed on the boring 80%. The repetitive, well-understood parts of building software collapsed in time. Scaffolding, boilerplate, config, the tenth CRUD form — these are minutes now, not hours.
Less fear of unfamiliar territory. A new language, an unfamiliar API, a legacy file I've never opened — the cost of stepping into the unknown dropped sharply. I explore more because exploring is cheap now.
Better starting points. A blank file is intimidating. A flawed first draft is easy to improve. AI is excellent at getting me to "this is wrong, but now I know what right looks like."
Faster feedback. I can ask "what's the risk in this approach?" and get a useful answer in seconds, the way I'd bounce an idea off a colleague — except at 2am when no colleague is awake.
What did NOT change (and shouldn't)
This is the part people miss. The fundamentals got more important, not less.
AI made writing code cheap. That makes knowing what to write, and whether it's right, the expensive and valuable skill.
I still read every line that goes into a codebase I'm responsible for. AI is confidently wrong often enough that trusting it blindly is how you ship subtle, expensive bugs. It'll invent an API that doesn't exist, pick an approach that works for ten users and collapses at ten thousand, or solve the wrong problem beautifully. Catching that requires the same judgment it always did. If anything, the engineers who struggle now are the ones who never built that judgment and lean on AI to replace it instead of accelerate it.
Architecture, data modeling, security, knowing why one approach scales and another doesn't — none of that got automated. AI will happily generate a design that's fast to build and miserable to maintain. Deciding that tradeoff is the job.
Key lessons
Treat it like a fast junior, not a senior. Delegate the drafting, keep the deciding. Read its output the way you'd review a new hire's PR — helpfully, but carefully.
Your judgment is the moat. When generating code is free, the value moves entirely to taste, correctness, and knowing what's worth building. Invest there.
Speed reveals weak foundations. If you don't understand the system, AI just helps you build the wrong thing faster. It amplifies whatever you already are.
Verify, especially when it's convincing. The most dangerous AI output is the plausible one. "Looks right" is not "is right." Test it, run it, read it.
Action steps
If you want AI to genuinely improve how you build:
- Use it for the friction, not the thinking. Lookups, boilerplate, drafts, tests, explanations. Keep architecture and correctness in your own head.
- Read everything before it merges. Make "I understand every line I'm committing" a hard rule, for you and your team.
- Ask it to argue with you. "What's wrong with this approach? What breaks at scale?" It's more useful as a critic than as an author.
- Keep building fundamentals. Data modeling, system design, debugging from first principles. These are what let you catch AI's mistakes.
- Set team norms early. Decide together what AI is allowed to do unreviewed (nothing important) so speed never quietly erodes quality.
Final thoughts
AI changed my workflow more than any tool in my career, and I'd never go back. But it didn't change what makes a good engineer — it raised the price on it. The grunt work is cheap now. Judgment, ownership, and the ability to tell "looks right" from "is right" are worth more than ever.
The engineers who win in this era aren't the ones who let AI think for them. They're the ones who let it handle the friction so they can spend all their energy on the part that was always the real job.