DEV Community: Quique Fdez Guerra

Hello senior developer: tell me which AIs you use (and please, you already use some)

Quique Fdez Guerra — Tue, 16 Sep 2025 07:07:32 +0000

My experience using LLMs in day-to-day work and how they are changing programming.

A necessary introduction

In recent months, the noise around "programming with AI" and "the end of programmers" has multiplied.\
What's curious is that most of these claims come from people who don't program. It's like to say "we don't need lawyers anymore" having knowledge of how a trial works: it wouldn't make sense or have any rigor.

What is clear is that AIs already act as super accelerators in technical work. What many thought would arrive in one or two years is already happening today. And far from being something to fear, what senior profiles need to do is adopt them now and learn how to integrate them into daily work.

In my case, I code much less than before because my role is now more about management and strategy. However, when I do program, the change has been radical: I'm faster, more efficient, I focus on complex parts and delegate the repetitive work to AI. Form validation, wiring, scaffolding, utility generation... all the things that used to consume time are now solved in seconds.

AI does not eliminate the need for a senior developer. It reconfigures the role: less time writing mechanical lines of code and more time applying judgment, designing architectures, and ensuring quality.

My setup and how I work with LLMs

Before getting into backlogs and code, I start with a key file in my projects: **Agents.md**.

The Agents.md file

This document contains the rules and practices I want the AI to always follow when working with me. It's my "contract" with the machine.\
I base it on previous versions I've tested, but I always update it with the help of AIs like ChatGPT.

Some of the practices I include there:

Don't add comments to the code. The code should be self-explanatory.
Write at least one small test for each new block of code.
Always check against the backlog before closing a task.
Update documentation (README, agents.md) whenever something relevant changes.
Keep style, dependencies, and patterns consistent.

Thanks to this file, every project starts with a solid foundation and with clear expectations of how the AI should work with me.

Backlogs and specification

Afterwards, I use AI to work on backlogs. First I think them through and draft them myself, because that's where human input adds the most value. Then I run them through AIs like ChatGPT or CheckInAI to polish: making them clearer, more consistent, and easier for everyone to understand. This saves a lot of time lost in misinterpretations.

Programming with AI

On the technical side, my setup is simple:

I use a lightweight editor, such as VS Code, without excessive configuration.
I always keep an assistant AI agent running (for example, GitHub Copilot).
This has taken me from coding 100% of the time to coding barely 1--3% in small projects.

When I tackle large tasks with these AIs, it's not as simple as saying "create this infrastructure" and being done. I work with AI as if it were another person: I question what it suggests, give feedback, ask for changes, and push for improvements until I get the result I want. Although they're still not very good at complex refactoring, I do encourage them to refactor very specific small parts. That constant interaction is what makes the difference.

How I distribute tasks by size

Large and small.\
Here AI is very useful:

Large → infrastructure, initial structures, module skeletons.
Small → minor design changes, visual tweaks, button or icon modifications.\
In both cases, I clearly define the task and closely supervise the result.

Medium.\
This is where AI shines the most today.\
I use agents like Codex or Devin AI, which work synchronously and are often described as "junior developers." In my experience, they handle these tasks very well:

Creating a new page based on another.
Adding a simple editor with data import/export.
Maintaining consistent design with the rest of the system.

The most relevant advantage is that I can use these AIs not only while sitting at my computer, but also by leaving them tasks in the background.

I assign a task, go to a meeting, and when I return the branch is ready for review.
I can even leave something running overnight and check it fresh the next morning.

This has brought a profound change in how I manage my time: it allows me to progress in parallel without extending my workdays or accumulating pending tasks.

How I think this will evolve

Although I've said several times that I don't think AIs will replace us, I do believe their evolution will broaden the spectrum of medium tasks.

We can already see that what used to be complex (like validating a form or setting up an importer/exporter) is now considered a "medium" task. And I think this trend will continue:

Very small tasks (especially in Frontend and design) will still need people with great aesthetic sensitivity and user experience skills.
Very large tasks (in Backend, Frontend, QA, data, architectures...) will still require human teams capable of making decisions, integrating systems, and handling growing complexity.
But the range of medium tasks will expand more and more. What we currently see as "difficult" will become "medium," and that's where AIs will play a bigger role.

This means there will be less repetitive or routine programming work, and more human focus on tasks that truly define quality, experience, and the long-term vision of a project.

And if you're not senior?

If you're a junior developer (or don't know how to program at all), the message is different.\
First of all: don't get carried away by the hype. The internet is full of messages whose only goal is your clicks or your money.

What I do consider essential is learning the technical foundations. Just like in math not everyone solves integrals, but everyone knows how to add, subtract, or solve a simple equation, in programming you should learn the basics: logic, data structures, simple patterns.

Today it's much easier to learn than 10 years ago: you have AIs that teach, compare approaches, and correct mistakes. But it's also harder, because technology has become much broader and more complex. That will be one of the biggest challenges in the coming years: learning enough to be productive without getting lost in the flood of tools.

There's also a deeper issue: without junior developers, there will be no seniors in 10 years. AIs are reducing many of the entry-level tasks that used to serve as training. That was the school where future seniors were formed. If it disappears, how will we train the next generation of professionals?

Companies will need to solve this challenge. Training, mentoring, and creating real practice spaces will be key. Because AI can accelerate, but it cannot replace the learning curve that turns someone into a complete professional.

What I think about all this

If you're senior, you should already be using AI in your day-to-day work. Not doing so means missing out on an accelerator that's already here.
If you're junior (or just starting out), learn the fundamentals first and use AI to practice and understand better, not to skip steps.
The future poses a huge challenge: how to train the next generation of developers in a context where entry-level tasks are increasingly automated.
The answer will not be choosing between humans or machines, but learning how to integrate both worlds to keep building together.

Deploying Next.js to Azure Web App with Github Actions

Quique Fdez Guerra — Wed, 03 May 2023 07:18:03 +0000

This is not going to be a detailed post, this is more like a checklist to remember of all the required things in 2023 to have a correct deployment from Github to Azure Web App when I'm working with Next.js framework.

If I'm using Bicep or terraform for deployment this step is not necessary, otherwise Create a Web App in Azure and configure the deployment with Github.

This will create a Github Deployment file, but I'll like something simpler like this:

name: Build and deploy

on:
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    environment:
      name: production

    steps:
      - uses: actions/checkout@v2

      - name: Set up Node.js version
        uses: actions/setup-node@v1
        with:
          node-version: "18.x"

      - name: npm install, build, and test
        run: |
          npm install --force
          npm run build
          mv ./build/static ./build/standalone/build
          mv ./public ./build/standalone
        working-directory: ./src
        env:
          NEXTAUTH_SECRET: ${{ vars.NEXTAUTH_SECRET }}
          NEXTAUTH_URL: ${{ vars.NEXTAUTH_URL }}
          AZURE_AD_TENANT_ID: ${{ vars.AZURE_AD_TENANT_ID }}
          AZURE_AD_CLIENT_ID: ${{ vars.AZURE_AD_CLIENT_ID }}
          AZURE_AD_CLIENT_SECRET: ${{ vars.AZURE_AD_CLIENT_SECRET }}
          NEXT_PUBLIC_CONNECTION_PROVIDER: ${{ vars.NEXT_PUBLIC_CONNECTION_PROVIDER }}
          NEXT_PUBLIC_CONNECTION_PRESENCE: ${{ vars.NEXT_PUBLIC_CONNECTION_PRESENCE }}
          NEXT_PUBLIC_CONNECTION_MEETING: ${{ vars.NEXT_PUBLIC_CONNECTION_MEETING }}

      - name: "Deploy to Azure Web App"
        id: deploy-to-webapp
        uses: azure/webapps-deploy@v2
        with:
          app-name: "teamshousepre"
          slot-name: "Production"
          publish-profile: ${{ secrets.AZUREAPPSERVICE_PUBLISHPROFILE_134181791EE54060B31CE60610FB9DAE }}
          package: ./src/build/standalone

Some interesting things here are:

I'm installing with --force because I sometimes need Next.js canary version.
After building I am moving static and public folders inside standalone folder.
I shared the ENV variables with the deployment (not always needed but depending on how you have created the project)
I'm uploading the standalone folder.

Configure Next.js to use standalone and don't use .next folder (this folder is sometimes forgotten during the deployment).

{
  reactStrictMode: true,
  output: "standalone",
  distDir: "build",
}

This can be changed in the deployment file but is also easy to change the startup command on Azure Settings, we want node server.js.

Remember to fill the variables on Azure and Github:

Still receiveing 500 ERROR?

Then you will need to investigate the Azure Logs

Nothing else on my checklist right now, enjoy if you need this :)

Inbox zero method as a professional - F&L #4

Quique Fdez Guerra — Sun, 09 Apr 2023 15:30:01 +0000

Do you know how many emails you have in your inbox right now? No? More than 20? More than 100? Take a look, I'll wait.

Whatever the number is, does it make you feel anxious? Do you feel like it's too much? Do you not have any strategy for managing it? Throughout my professional career, I have encountered a large number of people who don't follow any strategy for managing their inbox, NONE!

During the first few years, I was really surprised to find this, but nowadays, it seems normal to me. However, it was the first thing my colleague Alex Campos taught me when I was an intern at Microsoft. I remember he told me that I had to learn to manage my inbox well, that it was something basic.

Well, apparently, it wasn't so basic, but luckily for me, I learned it at an early stage. For me, having an immaculate inbox is completely natural, and it doesn't require any effort. Want to know how I do it?

Basically, I apply everything I learned at Microsoft, and I've added a few things over time. In my case, I have some clear principles:

My inbox is my list of important tasks.
My inbox cannot be a source of anxiety.
Your lack of planning is not my emergency.

Based on these principles, I use a series of techniques in my day-to-day life. Let's see them:

Emails never create notifications.
I have a rule in my email that marks any new email as read. I never have notifications for emails on my computer or phone. This allows emails to not distract me from my current task. No emergency should come through email, and if it does, it's poor planning on the part of the sender. To be strict about this, I have an internal rule that I can take up to 24 hours to read an email and as many to reply (if I remember correctly, I was taught double this time frame at Microsoft).
The first task of the day (and sometimes the last) is to spend 10 minutes organizing email.
Organizing doesn't mean replying, it means organizing. I open my inbox and start deleting anything that is not important, move notifications I want to keep to folders, and leave in the inbox anything that needs a reply from me. There are many ways to organize folders, in my case, and due to my work, when I was a developer, I had a folder for each project. Nowadays, I have one folder for each client and different folders for internal issues (Billing, Teams, IT, etc.)
If I'm copied on an email, I'm not expected to reply.
Many people create endless threads where they add many people in copy. As an internal rule, if someone puts me in copy, I classify it as a notification and try not to reply to that thread. I read it, and if necessary, I take asynchronous actions, taking the time I consider necessary. But if I'm copied, I shouldn't be the person who has to manage that problem.
The wall of shame.
There is no need to be afraid to leave an email in your inbox for days, if there is an important email and the task needs days to be resolved, the email stays in the inbox reminding me every day that I haven't finished that task yet. Which helps me see every day that I haven't finished something and that I should probably try to deliver a result soon. When you have a healthy email management system, you can end your day with 4-5 emails in your inbox, of which 1 or 2 may have been there for several days (because I haven't replied, not because other people have added replies).
Create a meeting with yourself.
A good way to save time to solve tasks that have been sent to me by email and need time is to create meetings with myself dedicated to that specific task.
Learn to deal with people.
There are people who are bad professionals and their way of reacting is to start sending emails, outside of working hours and with urgency, over time you have to learn to understand one of the most important phrases that many people repeat "Your lack of planning is not my emergency." So that you choose the moment when it is an emergency because it is best for everyone or there is no other choice and when it is not my problem and I have other more urgent matters.

As you can see, I haven't put any secret formula, you just need to dedicate some time each day, be organized and understand that emails are asynchronous messages and you can take the time you need to deliver a good result.

If you want to receive this article in your inbox as a newsletter just press the button.

Job hoppers generation - F&L #3

Quique Fdez Guerra — Thu, 09 Feb 2023 08:04:20 +0000

The only way to get a better salary is to change companies! That's it, I've said it, we've got it out of the way, now that we've done it, could you accompany me and internalize the concept of job hoppers?

It's been about 3-4 years since I discovered this concept of "job hoppers" and like any concept on the internet, there are many people in favor and many others against it. What is clear and are statistical data is that young people are increasingly inclined to change jobs. You invest one to two years in a company and then make the leap.

There are many reasons to make that leap, salary, change of role, boredom with the current position, bad managers, etc.

If one thing is certain, it is that our generation is less and less willing to be in a job just for the job and looks for a good place to be, to be recognized and to have a salary in line with their expectations. And is that realistic? Can I have all that in one job?

The truth is that it depends. As I write these lines, I am about to complete 8 years in my same company, a company that I entered with the lowest salary and that I gradually climbed in roles and money. If instead of being 8 years in this company I had been jumping, would I earn more? Probably yes, but I probably wouldn't have worked with the clients I have worked with, I could have delved into different roles and above all, I don't know how they would have tolerated all the mistakes I make every day in those other companies.

The problem with this is that it is very uncertain, I could change jobs tomorrow and discover that the new place is even better, or not. Or it doesn't matter, because in the end a job is like the search for a soul mate, it's not a magical connection company-employee, it's the day-to-day work of all employees in a company and the effort they make to make it a better place for everyone.

As in any relationship, there are many failures on both sides. I don't want to think about how many times I have felt that my job was very improvable or how many times I have felt that a decision someone made disappointed me. It's in those moments that you can end the relationship and look for another company "there are plenty of fish in the sea" or you can decide to work to help improve and bring visibility to the problems you see.

What is clear is that the second path is much longer and tedious and that, as in any relationship, it may be that no matter how much you put in, the other side doesn't put in any effort.

In my experience, every failure, every disappointment, and every mistake has been worth it to be who I am today and to see that the company I work for has come as far as it has. I still remember when I was the fifth employee in Barcelona, the 170th in the company, and today we are more than 500 employees and more than 800 will have passed these years. The company I entered is nothing like the company it is today and nor will it be in the future.

But returning to the topic, what about job hoppers? Is it okay? Is it wrong? If you see that a relationship can't improve for either side, run away from that company whether you've been there for a month, half a year, or two years. But if you have little experience in the technology world, if you're on a team that more or less works, if the company believes in your potential and is more or less capable of demonstrating it, I think it's a good decision to not jump to another company just to earn more money (as long as your needs and those of your family are covered).

If you are restless and what you do is not enough, let your managers know, look for internal change opportunities, interact with other teams or in other roles. It is very difficult to find a decent company, if you find one, don't break this relationship just because someone else promises you more money or a better role. Try to improve where you are and if in the end it's not possible, go ahead, JUMP!

If you want to receive this article in your inbox as a newsletter just press the button.

The least bad move in tech - F&L #2

Quique Fdez Guerra — Sat, 31 Dec 2022 12:28:31 +0000

We live in a society that always thinks about winning and winning and we have turned the human being into something specifically made to win over the rest, to be above the others.

To success means to be better than others, to success means to earn more money, to get the best position, to have a better title on LinkedIn, to success means always making the best move.

It is possible that throughout your career in technology, you have experienced some, if not all, of the above points either in others or in yourself.

Fortunately, it seems to be something that is easily fixed, with enough time and experience.

These needs to be better and to win end up causing many people to get lost along the way and, instead of understanding failures as part of the journey and knowledge, they understand them as mistakes and penalties. And how not to get lost?

To my surprise, I learned this lesson by listening to a professional video game player. Professional players are usually people who have seen failure very closely and who have managed to reach a very small percentage of their profession, which basically gives them something to live for.

That player explained that casual people always try to make the best move with the elements they have, that the best move is often the most complex and the one that can make you lose against stronger rivals but win against the average. This can help you to stop being a bad player but it will not help you reach the top.

And how do they do it? They mostly base their strategy on "the least bad move" which statistically and in the long term, gives you regularity and if you maintain it for long enough it will eventually make you a professional, because the least bad move can make you lose but in the long run it is much more likely that you will end up winning.

And then I wondered, how can I apply something like this to my profession? And the truth is that we cannot lack examples.

Since 100% test coverage does not provide much more than 32% coverage in which you are sure that the important things have been tested.

That it is better to go to production with 3 out of 6 stories done than try a perfect sprint and need 12 hours per day. Or that it is better to have a project with real users and a very simple architecture than to have the best architecture in the world but no one uses your product.

Let's remember that there are startups being sold for thousands and they are just a few slides… As people who really like technology, we may not go to that extreme, but knowing how to apply these rules and many others that will surely occur to you can be the difference between a Minimum VIABLE Product and an idea that did not work because: we had "bad luck" or we "did everything right".

And that's when I wonder… What if at the end, the best move is the least bad move?

If you want to receive this article in your inbox as a newsletter just press the button.

My first mistake as a dev - F&L #1

Quique Fdez Guerra — Fri, 23 Dec 2022 10:09:56 +0000

Over the past decade, I've made thousands of mistakes while working in tech. Each mistake was a stressful situation and a complex challenge, but they have helped me grow and learn in my career. These experiences have prepared me for the challenges ahead and have been instrumental in my professional development.

Although my career is still in its early stages, I've gained a lot of knowledge and I want to share my experiences and insights with others.

When I was 13, a classmate encouraged me to create websites with him and what a great discovery it was! That moment when Aleix encouraged me to create websites together changed the next 7-8 years of my life. I had a new hobby, I could spend hours studying and creating websites for friends, family, or small businesses and many times I even lost track of time. I was so sure that I would never dedicate myself professionally that I decided to study a more interesting career: Telecommunications.

But then, halfway through the career, I made what I consider my first mistake as a technology professional, I decided to give up coding as a hobby and turning it into a career.

A hobby is almost always fun. It is innocent, a pastime that usually does not have many obligations but has plenty of rewards. A hobby does not have any strings attached and when you turn it into your job, something changes. In my experience, that something goes through a series of phases: initial excitement, melancholy, and normalization.

The initial excitement is probably the period with the most highs and lows that I remember from turning my hobby into my job. Everything is absolutely amazing and you invest a lot of hours into everything but you are happy because

"I'm working on something that is my hobby." (damn quote).

On the one hand, the feeling of rush is really amazing, no matter how difficult the task is, and on the other hand, it is terrible that you can spend 13-15 hours studying something new or trying to do something with a technology that you did not know, it is not at all necessary and the experience teaches you that resting often makes that effort more productive.

Who hasn't spent 4 hours trying to solve something, not being able to do it, and the next day solving it in 5 minutes? Of those 4 hours, surely 1-2 were really useful to understand the problem and look for possible solutions, but the following 1-2 hours could have been spent resting or dedicating time to yourself and your loved ones.

In those red zones, we can enter them alone but the people in our professional environment can help provoke them or avoid them. Fortunately, my first mentors and bosses were quite insistent on not working extra hours or on weekends and made it known to us. I fondly remember a Friday when a boss said he was going to turn off our computers.

At that time, I thought it was silly and that they should let us do what we wanted, but I learned a valuable lesson and now that I am responsible for some people, I act similarly. Although on the other hand, I understand, as happened to me, that there are people who prefer to spend more time than usual on their studies to improve. For those people, I would simply say, take care of your rest to take care of your mind.

After a few years of highs and lows, you may start to feel regret or feelings of sadness: Have I dedicated too much time to this? What if I took the wrong direction? Was it worth it? Am I in time to change? Is it worth it?

In my experience, it was at that moment that I had one of my many reality checks. Work is work and although you work on something you like, there are boring moments, hard moments, and moments when you would rather have opened a small bookstore or a small coffee shop. It is at that moment that you can decide, I have come this far and I am going to do something else, but happy about everything you learned.

Or like I did, and many before me, understand that in every profession there are better and worse moments and that it is worth working on something you like more than something you hate, and that any profession is good and respectable.

By then, leaving behind the melancholy and normalizing the profession as what it is, a place where you spend several hours a day, which allows you to contribute value first to yourself as a human being, to a group as society, and who knows if to someone else. It is normal to suffer in the lows and it is correct to get excited in the peak moments, as well as it is normal to have diverse groups of work in which not everyone has reached that moment in the same way as you, combining all of those experiences to create something unique together, in our case: software, what a great invention!

Was it a big mistake to turn my hobby into my profession? There are times when I still think it was and that I would live more peacefully running that bookstore... But after more than 10 years, I start to think that the mistake was idealizing any profession and that only time allow us to sort things in their place.

If you want to receive this article in your inbox as a newsletter just press the button.