How AI Changed How I Code (And It Wasn't What I Expected)

I've spent 7+ years building systems for banks, insurance companies, and enterprises across Latin America. I've migrated 500K+ records, built serverless architectures with 45+ Lambdas in production, and processed contracts with AI for 15 financial institutions. I'm saying this not to brag, but for context: I'm not someone who just discovered programming. And yet, AI completely changed how I work.

But not in the way most people think.

---

I Don't Start With Code Anymore

My old process was the classic one: open the IDE, create folders, install dependencies, start writing code. Figure out the architecture in my head as I went. It worked, but it was slow — and a lot of time went to boilerplate, repetitive config, and solving things I'd already solved in previous projects.

Today my first step is completely different: I write documentation before a single line of code.

Yes, documentation. The dev who used to avoid documenting now does it first. The irony isn't lost on me.

---

The Real Change: Context Before Code

The biggest shift wasn't asking an AI to write code for me. It was understanding that the quality of the output depends directly on the quality of the context you provide. If you say "build me an expense CRUD," you get generic code you'll end up rewriting. If you give it your project context, entity relationships, business rules, and design standards, the result is completely different.

That forced me to structure what previously only lived in my head.

Now, before touching code, I create context files: what the project does, how it's structured, what architectural decisions I made and why, API contracts, the design system. I give the AI — and my future self — a complete map of the terrain.

---

The Structure That Makes It Work

Before writing a single line of code, my project already has something like this:

It's not about having lots of files. It's about having clear, reusable context. You write once and every prompt after that already has 80% of the context resolved. Skills prevent the AI from generating generic code. Prompt templates prevent you from writing generic prompts.

---

My Current Workflow Step by Step

1. I define context in writing. Architecture, stack, technical decisions, design. All in markdown, all versioned. This isn't formal client documentation — it's the project's brain. 2. I create reusable skills. Templates with patterns I already know work: how I structure a backend module, how I build a frontend component, what validations I always include. When you've built 20+ APIs for banks, you know what pattern works. Document it once and the AI replicates it consistently. 3. I write structured prompts, not improvised ones. Instead of improvising each time, I use templates where I fill in the blanks. Every prompt always includes three things: what exists (context), what I need (objective), and how I want it (constraints). Without that, the AI guesses. And guessing doesn't scale. 4. I iterate by complete modules. Backend first, frontend second. Every module ships with validations, loading states, error handling, and consistent design from day one. No "I'll fix it later" — it ships complete or it doesn't ship.

---

The Prompts I Actually Use

I'm not going to give you a list of magic prompts because they don't exist. But there are patterns that work consistently:

For architecture (before anything else): I give the AI the complete map — stack, folder structure, naming conventions, project constraints. This is the most important prompt because it defines everything that follows. For features with context: I reference what already exists. If I already have a well-implemented users module, I say "follow that pattern." Consistency kills technical debt. For corrections: I describe the symptom, give the framework context and version, and ask for the specific fix. No "give me 5 alternatives" — I need the solution. For validation: Before implementing, I validate technical decisions. "I'm thinking of using X for this use case, what problem am I not seeing?" This type of prompt has saved me weeks of refactoring.

---

What Actually Changed

It's not that I code less. It's that I code differently. My energy goes to design decisions, technical trade-offs, and validation — the parts that actually matter. Boilerplate, repetitive patterns, initial configuration... that stopped being my problem.

Projects that used to take weeks of scaffolding now start in hours with a solid foundation. Not perfect — there are always adjustments — but consistent, well-structured, and with standards from the start.

When I worked on the 500K+ record migration that other developers couldn't complete in 8 months, it wasn't because I typed faster. It was because I understood the architecture of the problem first. AI amplifies exactly that: the technical judgment you already have.

---

The Irony

To use AI well, I had to become a better architect. Documenting for the AI forces me to justify every decision. And when I can't justify something, that's a sign I need to rethink it.

You can't delegate what you don't understand. If you don't know why you chose NestJS over Express, or why you're using multi-tenant with separate schemas, the AI isn't going to make that decision well for you either.

AI didn't change what I build. It changed how I build it. And the secret isn't the perfect prompt — it's having absolute clarity about what you want before you ask for it.

---

Migrating legacy systems or need cloud architecture for your business? Let's talk.