A few months ago, I found myself doing something I hadn’t done before.
Not Googling.
Not digging through old Stack Overflow threads.
I just… asked.
And got an answer in seconds.
Not always perfect.
Not always correct.
But good enough to move forward.
That’s when it clicked:
AI isn’t replacing how we write code.
It’s changing how we think while writing it.
TL;DR
- AI works best as a copilot, not an autopilot.
- It can speed up development, but also introduce subtle risks if used blindly.
- The real advantage comes from integrating AI into a thoughtful workflow, not just using it occasionally.
Table of Contents
- From Searching to Asking
- AI as a Copilot, Not an Autopilot
- A Real Workflow: How Developers Actually Use AI
- Where AI Shines
- Where AI Struggles
- The Hidden Risk: False Confidence
- How to Use AI Without Losing Your Edge
- Final Thoughts
From Searching to Asking
For years, our workflow looked like this:
- write some code
- hit a problem
- search for answers
- stitch together a solution Now, it’s different.
We:
- describe the problem
- get a tailored response
- iterate faster
It’s a shift from searching to asking and that changes more than just speed: It changes how we explore problems.
AI as a Copilot, Not an Autopilot
There’s a temptation to treat AI as something that “just writes code for you”, but that’s not how it works well.
AI is strongest when:
- you guide it
- you question it
- you refine its output
Think of it like a junior developer that:
- is incredibly fast
- knows a bit of everything
- but doesn’t fully understand your context
You wouldn’t blindly trust that and you shouldn’t blindly trust AI either.
A Real Workflow: How Developers Actually Use AI
The real value of AI doesn’t come from one big prompt, it comes from how it fits into your daily workflow.
Here’s a realistic loop:
1. Start with your own idea
You sketch the solution.
Even if it’s incomplete.
This matters, because it keeps you in control.
2. Use AI to explore options
You ask:
- “Is there a better way to structure this?”
- “How can I simplify this logic?”
Now AI becomes a brainstorming partner.
3. Generate or refine code
You let AI:
- draft functions
- suggest refactors
- fill repetitive gaps
But you don’t stop there.
4. Review like it wasn’t yours
This is the critical step:
- You read the code as if someone else wrote it, because in a way, they did.
5. Integrate carefully
You adapt the output:
- to your conventions
- to your architecture
- to your actual constraints
Only then it becomes part of your system.
Where AI Shines
Used correctly, AI can dramatically speed things up, especially for:
Repetitive tasks
Boilerplate.
Transformations.
Small utilities.
Things you already know how to do, but don’t want to rewrite.
Learning and exploration
You can quickly:
- understand unfamiliar APIs
- see example implementations
- compare approaches
It reduces friction when learning something new.
Refactoring support
AI is surprisingly good at:
- suggesting cleaner structures
- identifying duplication
- proposing improvements
It won’t always be perfect, but it often gives you a strong starting point.
Where AI Struggles
AI has limits and knowing them is what keeps you effective.
Context awareness
AI doesn’t fully understand:
- your codebase
- your domain
- your business logic
It works with what you give it, nothing more.
Long-term design
Architecture decisions require:
- trade-offs
- constraints
- experience
AI can suggest patterns, but it doesn’t own the consequences.
Subtle bugs
AI-generated code often looks correct, but small issues can hide inside:
- edge cases
- performance problems
- incorrect assumptions
This is where experience matters.
The Hidden Risk: False Confidence
This is the part most people underestimate.
AI makes things look easy, and that creates a dangerous illusion:
“This looks right, so it must be right.”
But readable code is not necessarily correct code.
And fast progress is not necessarily real progress.
If you skip the thinking part, you’re not moving faster, you’re just deferring problems.
How to Use AI Without Losing Your Edge
AI should amplify your skills, not replace them.
A few simple rules help:
Stay the decision-maker
AI suggests.
You decide.
Always.
Ask the AI to ask you questions to clarify any unclear points.
Understand before you accept
If you can’t explain the code, don’t ship it.
Use it to learn, not just to produce
Ask “why” as often as you ask “how”.
Keep your fundamentals sharp
AI changes the workflow.
It doesn’t replace the need for:
- problem solving
- system thinking
- debugging skills
Final Thoughts
AI is not the end of programming, it’s an evolution of it.
The best developers won’t be the ones who use AI the most, they’ll be the ones who use it well, because the real shift isn’t about writing less code.
It’s about thinking differently while writing it.
If this resonated with you:
- Leave a ❤️ reaction
- Drop a 🦄 unicorn
- Share how AI has changed your workflow
And if you enjoy this kind of content, follow me here on DEV for more.
Top comments (25)
Really enjoyed this article, @gavincettolo! The "copilot, not autopilot" framing clicked for me immediately. I've been using GitHub Copilot for a few months, but I still feel like I'm just accepting suggestions without fully understanding them. Is that a red flag, or is it normal at the beginning?
Hey @lucaferri, thanks so much, glad it resonated! Honestly, it's very common at the start. The key shift I'd suggest is to treat every accepted suggestion as a code review moment. Before you hit Tab, ask yourself: "Can I explain what this does and why?" If not, that's your cue to dig deeper. Think of it like reviewing a junior dev's PR: you wouldn't just merge it without reading it, right?
That's a great analogy! You mention in the article that AI is like a "junior developer that's incredibly fast." But junior devs also make junior mistakes. How do you catch those mistakes when the code looks correct at first glance?
Exactly the right concern. My go-to approach is to read the code as if someone else wrote it, because in a way, they did. I also like to ask the AI itself: "What edge cases could this miss?" or "What could go wrong here?" You'd be surprised how often it flags its own weaknesses when prompted directly. Tests help too, obviously, they're your safety net when the code looks fine but behaves weirdly.
Oh that's clever — asking the AI to critique itself! I never thought of doing that. On another note, you talk about "starting with your own idea" before prompting. But what about when you're totally stuck and have no starting idea at all? Is it okay to just... ask AI from scratch?
Totally fair question. Yes, you can absolutely start from scratch with AI, but I'd still recommend framing it as exploration, not delegation. Instead of "write me a function that does X," try "what are a few different ways I could approach X?" That way, you stay in the driver's seat mentally, even if you don't have a solution yet. It keeps you engaged with the problem, not just the output.
That distinction between exploration and delegation is really useful. I also noticed you didn't mention specific tools much — was that intentional? Do you have personal favorites, or does the tool choice not matter that much?
It was intentional! I didn't want the article to feel outdated in six months when the tool landscape shifts again. The mindset is what matters most. That said, personally I've spent a lot of time with tools integrated directly into the IDE, having context-aware suggestions right where you code makes a big difference compared to switching to a separate chat window. But the workflow principles apply regardless of the tool.
Makes sense. One thing that came up for me while reading: you say "if you can't explain the code, don't ship it." But in a fast-paced team, there's often pressure to move quickly. How do you balance that principle with real-world deadlines?
This is the tension I feel most in practice too. My honest answer: if you ship code you don't understand, you're borrowing time, and you'll pay it back with interest when something breaks at 2am. I try to reframe it for my team as a risk conversation, it's not about being slow, it's about knowing what you're putting into production. Even a 5-minute "explain this back to me" session with AI before shipping can save hours of debugging later.
That "paying it back with interest" framing is going straight into my next team retro 😄. Last question: do you think AI tools will eventually make junior developers obsolete, or is there still a clear path forward for people just starting out in tech?
Strong no on obsolescence, but the path does look different now. Junior developers who lean into AI as a learning accelerator, asking "why" not just "how," exploring unfamiliar APIs, using it to understand patterns, will grow faster than any generation before them. The danger is using it to skip the learning entirely. The fundamentals of problem-solving, system thinking, and code quality still need to be built. AI can help you get there faster; it can't get there for you.
This has been such a valuable conversation, Gavin. Honestly one of the most grounded takes on AI in dev I've come across — no hype, no doom, just practical thinking. Thank you for writing this and for taking the time to reply so thoughtfully! 🙏
Thank you, @lucaferri, this is exactly the kind of discussion I was hoping the article would spark. Your questions pushed me to articulate things I hadn't put into words before. That's the best outcome a writer can hope for. Keep building, keep questioning, and feel free to drop by anytime! 🚀
This reminded me of something I read recently.
A company was experimenting with ranking developers based on how many AI tokens they consumed.
More tokens → higher ranking.
Honestly, I find that… questionable.
It doesn’t encourage better use of AI.
It encourages more use of AI.
And those are not the same thing.
If anything, it risks pushing developers to:
Which is the opposite of what we actually want.
AI should help us think better, not skip thinking entirely.
Curious to hear your take:
👉 should we even try to measure AI usage like this, or is it the wrong metric altogether?
I’d push back pretty strongly on that metric—it’s measuring the loudness of AI usage, not its value.
Token count is a classic example of a proxy that’s easy to track but poorly aligned with outcomes. It rewards verbosity and dependence, not clarity or judgment. In fact, some of the best uses of AI are efficient: a well-crafted prompt, a quick validation, or using it to challenge an assumption—not generating pages of code.
If anything, that system risks creating perverse incentives:
A more meaningful direction (even if harder to measure) would be things like:
But even those are tricky—because good engineering is still largely qualitative.
So I’d say: yes, measure impact, but be very careful measuring usage. When the metric becomes the goal, it tends to distort behavior—and this feels like one of those cases.
Great article as always @gavincettolo!
Thank you @elenchen :)
Really enjoyed this—especially the framing of AI as a thinking shift rather than just a productivity tool.
The “copilot, not autopilot” idea resonates a lot. In practice, the biggest difference I’ve noticed isn’t just faster coding, but faster iteration on ideas. The loop of “sketch → ask → refine → review” feels like a new kind of feedback cycle that didn’t exist before.
That said, I think the “false confidence” point is the most important one here. AI lowers the friction to produce plausible code, but not necessarily correct or context-aware code. And that gap is where real engineering judgment becomes even more valuable—not less.
One thing I’d add: this shift might gradually redefine what “senior” means. Less about writing code quickly, more about:
asking better questions
spotting weak assumptions
and knowing what not to trust
In that sense, AI doesn’t flatten skill—it amplifies the difference between shallow and deep understanding.
Curious how others are handling this: are you finding AI changes how you think about problems, or just how fast you solve them?
I really like how you described that loop, “sketch → ask → refine → review.” That’s exactly the shift I was trying to capture but you articulated it better. It’s less about speed in isolation and more about compressing the feedback cycle.
Totally agree on false confidence. If anything, AI raises the bar for critical thinking because now you have to constantly ask: does this actually fit my context, or just look right?
Your point about iteration is spot on. I’ve found myself exploring more alternative approaches than before, simply because the cost of trying something is so low.
The “copilot, not autopilot” idea really comes alive in what you said. The moment you switch to autopilot, that’s when subtle bugs and wrong assumptions sneak in.
I like your take on redefining “senior.” It’s increasingly about judgment, not output. Knowing what not to accept from AI is becoming a core skill.
“Spotting weak assumptions” is such an underrated skill, and AI tends to expose that gap quickly. It will happily build on a flawed premise unless you catch it early.
I’ve noticed something similar: AI doesn’t reduce complexity, it just shifts where the complexity lives, from writing code to validating and steering it.
That idea that AI amplifies the gap between shallow and deep understanding really resonates. Two people can use the same tool and get completely different outcomes.
To your question: for me it’s definitely changing how I think, not just how fast I move. I spend more time framing problems clearly because the quality of the answer depends so much on that.
Appreciate this thoughtful comment, it adds a lot to the discussion. Thank you 🙏
Thank you Gavin, really appreciate your answer
Nothing change at all that what I think🙃
That’s fair 😄
At the core, we’re still solving problems and building software, that part hasn’t changed.
What I think has changed is the workflow around it:
less searching, more asking; less boilerplate, more reviewing and guiding.
AI doesn’t replace engineering thinking, but it definitely changes how many of us approach coding day to day. Even if the fundamentals stay the same 🙂