How coding with AI Changed My Developer mindset

I know… I know. Vibe coding this, AI that. But what can we do? We’re living through a revolution in our field, a change without precedent, a clear before and after. And like every major change, it comes with sacrifices, mindset shifts, and basically one thing: ADAPTATION.

And sure, who am I to talk? With relatively little experience in software development (6 years, to be exact), I’m living through this change myself. A change that is impacting pretty much every role you can imagine within software development.

But once reality is accepted, let’s get into it. Do we really need to change the way we think in order to integrate AI into how we develop software?

The answer is: Definitely yes.

I’ll explain this with an example. The way I, Pablo, was used to building something from scratch started with running npx create-react-app my_app and getting that canvas. Not exactly blank, but with a counter that increased every time you clicked it.

---

How I used to start 🚀

Starting a project has never been easy. Sitting down with an idea in your head or with a set of requirements and translating that into code is something you have to get used to. While everyone has their own workflow, mine was very concrete and usually applied to almost every project.

Let’s take the creation of a personal project as an example:

1. Have an idea
2. Put that idea into a small document, writing at a high level what I wanted to achieve and which goals it should fulfill
3. Define, roughly, the design I wanted it to have
4. Start writing code

Simple, straightforward, and straight to the point. Since the most fun part for a developer is starting to write code, not much time passed between conceiving an idea and starting development.

But this approach comes with certain implications.

Development and the feeling of control 🚫

Yay! I’m coding. Fighting with Tailwind, or with my own CSS styles if I was feeling brave. Trying out some new technology or attempting to apply a recently discovered design pattern.

But working under the belief that everything is in our head and fully under control is overly optimistic. There are always things we ignore, because at the end of the day, we’re human.

So how do we try to mitigate these errors? With testing.

• A new function? Unit testing
• Modules integrating with each other? Integration testing
• Want to know if an endpoint works? Functional testing

There’s even a programming approach called Test Driven Development (TDD), where the focus is on control before coding. Tests are never going away. They’re necessary and they give us confidence.

But once we’re deep into development, this constant need for security and control over what we’re doing comes at a cost in time and effort.

That had been my way of working until now. Believing I had a certain level of control over what I was doing, and that I’d be able to mitigate any issues that came up.

How everything changed 🦆

Do you know the rubber ducky technique? Have you ever explained a problem you’re stuck on to someone, only for the solution to magically appear in your head? That’s rubber ducky: having some external help (even if it’s just a rubber duck) to unload what’s in your mind, debug your own thoughts, and arrive at a solution.

Now imagine having that kind of help where you can unload your ideas not only when you’re stuck, but also when you want to explore the best option for a solution, or brainstorm different ways to reach a goal. That’s what AI has been turning into lately, and it’s how I’m trying to apply it to my work.

My workflow changed radically:

Before: Code → Test → Code → Test

Now: Definition → Context → Conversation → Refinement

My way of thinking has changed. My approach is different. Now, before I start coding, I try to talk to this tool. That document I used to write to loosely define what I wanted to achieve? What if I polish it a bit more, spend more time on it, as if I were working with someone else and needed them to truly understand it?

Within this new way of thinking

This completely changed the game. I no longer rush into coding and figure things out as I go (at least when I don’t have clear requirements). Now I have this ally that understands what I want to achieve and how it should coexist with everything else.

You definitely still need to review what it’s doing, but the mindset is different. Now I can try multiple decisions in minutes. Is option A better, or option B? I try both, get results, and decide based on quick evidence instead of assumptions.

It’s a companion that’s always by your side, just waiting for instructions. And it’s not just a “here’s what you asked for, goodbye” situation. You can generate something, then correct it by giving even more context about why those corrections matter, so the next time it tries to do something, it’s aware of those changes. This step is crucial, and it’s why having this tool constantly by your side is so powerful. It’s aware of what you’re working on and what exists within your project.

My new workflow looks like this:

1. Define the idea in a document
2. Write what you want to achieve and how you want to achieve it
3. Define some requirements
4. Create your prompt
5. Correct what was generated
6. Add tests as part of the process

Of course I still code. But now I try to integrate this powerful tool into my workflow, no longer as a code autocomplete or a Stack Overflow replacement (like it was not too long ago), but as a second brain.

As software engineers, we’re no strangers to change. We’re aware of it, and we know that those who don’t try to stay up to date will fall behind. Taking a leap this big is scary, sure. But the sooner we accept that we need to change how we work today, the faster we’ll grow into this new path.