← Back to Blog
Mar 25, 2026

My workflow with AI

I started my workflow with Neovim over three years ago. Sitting down to code was the best thing in the world: new proposals to develop, new challenges, every problem to solve was exciting. Opening the editor, moving through code at keyboard speed, feeling like the environment was an extension of yourself… there was something almost addictive about it.

But after two years, something changed. The proposals started repeating themselves. Every new challenge felt more boring than the last, and the incoming requirements even more so. The job had turned into what many developers fear: maintaining a system. Nothing new, nothing to reignite that spark from the beginning.

That’s when I started feeling the urge to build something new. To find space to talk to managers, pitch ideas, show what I’m capable of. I also wanted to practice my English, since I’m a native Spanish speaker and I know that communicating well in English opens doors. To propose solutions, even if it sometimes got me into trouble. But always with that genuine drive to grow, to find new challenges that would make work feel worth it again.

To do that, it was always key to stay curious: how are the technologies and systems people use every day actually built? Looking at Google Sheets, for example, and asking myself “how is this made?”. Drawing ideas from that, setting myself the challenge of building something similar. That always lit me up.

And something I love about development is that “every idea is possible”. The only limitation is the time it takes to get there and the experience you’ve built along the way. When I got the green light to carry out those proposals, it was an incredible feeling. Writing every line of code, shipping every new feature of those own ideas. From 3,000 lines of code to even 7,000 lines a day, without AI, back then. It was something huge. Physically exhausting, but feeling on top of the world.

Me and my code editor, Neovim. My precious dotfiles in the terminal. A hardcore VS Code hater — the kind where I only found out this year, forced to use it for work, that it has an integrated terminal… wild. Already in a different universe now with AI-powered IDEs.

But what I really want to get to is that things have changed. AI adoption is inevitable, or at least that’s what I believe.

Something shifted in me. I no longer want to write code. I’m more of a tech lead now. The years of experience, my ability to learn quickly, the habit of always trying something new on weekends — all of it made me see and learn so much that now, with AI, I want to do something more.

Something inside me says that the code problem is solved now.

That said, don’t get me wrong: code always needs supervision. And that’s where I come in.

My current workflow

Everything starts with the analysis of “what do I want to build”, whether at the beginning of a project or when starting a new feature. Getting clear on what I want to achieve before writing a single line.

For this, I’m a full-on tinkerer (some call it being a “frameworker” — someone who tries everything but doesn’t specialize in anything; though in my case I already know the fundamentals, I just want to see how each framework or library solves things). What I do is ask the AI to generate proposals: what to use, how to achieve it, and from a palette of options A, B, or C, I choose.

I want to build a real-time notification system.
Give me 3 tech stack options with their pros and cons,
considering the project is in Vue 3 + TypeScript.

Then comes the architecture. I’ve noticed the best approach is to start with a hexagonal architecture and gradually move toward feature-first and eventually DDD. I used to be afraid of choosing the right architecture for a project. Now with Claude you can build the base and ask it to migrate the architecture, and it pulls it off. Impressive. At least 90% of the time. That’s why I love it.

The project currently has a basic hexagonal structure.
I need to migrate the users module to feature-first.
How will you do this? Show me the plan before touching any file.

On the stack: I used to like React. Now I’m a Vue lover. Evan You is my shepherd (lol). Vue is lightweight, supports native web components, has a very clean TypeScript structure, and its similarity to React is what pulled me in completely. I love it.

Then comes a review of what’s missing, and finally an implementation confirmation to make sure we’re not forgetting anything.

All of these steps are systematized in command files within my workflow:

idea.md — If it’s something from scratch, this is where I lay out the general vision with the requirements.

# Idea: Metrics dashboard for remote teams

## General vision
I want a dashboard where leaders can see the status
of their teams in real time: active tasks, blockers,
and focus hours per person.

## Target users
- Tech leads of teams of 5-15 people

## What it is NOT
- Not a time tracker
- Not a replacement for Jira or Linear

plan.md — The first points where it becomes clear what to do: what files to modify, what to use, what libraries and, very importantly, what NOT to do. This is where a developer’s experience matters most. A key thing I learned: ask the AI “how will you do this?” before it starts. It will tell you what it plans to do, and that’s where you can correct it or confirm it’s on the right track. I also always ask for options, because I’ve learned there’s always something more to pick up when you ask for alternatives.

Based on idea.md, create a detailed plan that includes:
- What files to create or modify
- What libraries to use and why
- What NOT to do (avoid over-engineering)
- How will you handle the Vue store integration?
  Explain it before writing a single line of code.

/command/review.md — I ask it to review the plan against the current state of the project. It might seem like a waste of tokens, but it’s helped me catch things I was missing.

Review the plan in plan.md against the current state of the project.
Identify:

- Inconsistencies between what was planned and what already exists
- Dependencies that weren't mentioned
- Things we might be duplicating

Key areas to review:
- [ ] Stores (Pinia): is there one already handling this state?
- [ ] Existing composables: is there reusable logic that applies?
- [ ] Services/repositories: is there an existing data access layer related to this?
- [ ] Routes: are there conflicts or routes that already cover this?
- [ ] Types and contracts (TypeScript): are the defined types consistent with the plan?

References to consider:
- @plan.md — the base plan
- @src/stores/ — current stores
- @src/composables/ — existing reusable logic
- @src/types/ — data contracts

Do not make any changes yet. Just report what you found.

/command/confirmation.md — Helps me detect unresolved ambiguities before kicking off. This step prevents the AI from making decisions on its own. Because my first vibe coding attempts ended with me having no idea how the AI got there, and honestly I didn’t feel like reviewing it all.

Before starting the implementation, I need to confirm the following points.
Answer each one and wait for my validation before moving forward:

Design decisions:
- [ ] What new components will you create and where will you put them?
- [ ] Will you modify any existing component? Which one and why?
- [ ] How will you handle state? New store or an existing one?

Contracts and types:
- [ ] What new types or interfaces do you need to define?
- [ ] Are the existing types in @src/types/ enough or will you extend them?

Data flow:
- [ ] Where does the data come from? API, store, props?
- [ ] How do components communicate with each other? emit, store, provide/inject?

References to keep in mind:
- @plan.md — what we agreed to implement
- @src/components/ — existing components to avoid duplication
- @src/composables/ — composables you could reuse

Do not write any code until I confirm every point.

With this workflow, my work with AI has had a lot more control and skill than before — not like the old days lol, where I’d throw something at it and only the GPU somewhere in a US data center knew what the AI would come up with. The work was horrible.

But now, the real problem was just communicating better, specifying better. That’s why SDD (Spec Driven Development) makes so much sense now — more than ever. The ability to communicate ideas clearly is the most important skill. And honestly, that was something I struggled with. But coordinating a team, communicating with other tech leads, using tools like Excalidraw — my communication has improved a lot.

Recently a coworker told me: “I use AI too, but NOT for everything” — meaning they’re still writing code themselves. I wanted to respond: “You have to use AI, for everything, EVERYTHIIING.” Because as I mentioned, the code is solved. I don’t see JavaScript frameworks popping up every single week like before — that used to be so stressful. Now AIs will have time to stay on top of the latest and greatest without falling behind. I didn’t respond to my coworker in the end, but if I had said something it would’ve been: “Use AI for everything, because if you don’t, you’re at a disadvantage — at least against me.” But I won’t say that out loud, because this is a competitive world. Better they stay behind and I grab a piece of their pie lol.

Critical thinking is what’s maturing the most in my head right now. Now that code is solved — and it saddens me to say it, because I genuinely loved writing code, proof being my dotfiles with Neovim, tmux, zsh, fish, WezTerm and more — I feel like I should focus on building products. When I was younger I loved making everything from scratch. Now I want to create products, develop more creativity. My country is full of problems I want to solve, to improve the daily lives of my people with AI-powered tools.

This reminds me of a comment from @midudev, the Spanish-language dev content creator on YouTube, who said something like: “every dev has to become an AI developer.” Meaning we should already know how to integrate AI into the products we maintain or build — by default, and fast. None of this “we’ll bring in someone or a team to handle the AI stuff.” No. You have to know it yourself: what AI is about, how to write good prompts, how to integrate an LLM in your language of choice, how to use MCPs, SSE for real-time in the frontend, JSONL for structured content — there’s a ton of things you can already do.

Final thoughts