Subscribe now

In this article, I want to share how my AI setup has evolved over time: the learnings that I got from each setup, and what is the current state of the art for working with AI (the metagame for those of you who played video games).

We keep working with AI exactly as it was in GPT-2 or GPT-3: A chatbot that produces text in English, and we communicate in English writing. The models have evolved a lot. They are now producing code, but we still communicate as if it were GPT-2 producing English text.

It’s time for a reset

For paid subscribers, you'll get the entire evolution of my setup so you can identify yourself in any of these steps. And what are the next steps towards a much better setup? All of you can find ideas from this evolution and adapt them to your use cases.

Let's get started!

👉 If this sounds interesting, subscribe now. 22,000+ engineers are already becoming more productive. Paid subscribers have access to premium resources

Subscribe now

Read more

Subscribe now

So you’re a developer who is very ambitious but at the same time very lazy.

It sucks. You know what you want, and you’re a software engineer, so you’re someone who can build it, but at the same time you never get to it.

You keep being the same person year after year. Basically, you are stuck.

I’ve been there and done that.

With this newsletter, I started two or three years later than I would have wanted. With other important projects, I would have liked to dedicate the time, but I never got to them.

It’s easier to say what we want to visualize it than to actually do it. In this article, I will help you identify where you are ambitious but lazy and put an end to it.

👉 If this sounds interesting, subscribe now. 22,000+ engineers are already becoming more productive. Paid subscribers have access to premium resources

Subscribe now

Why you’re ambitious but lazy

There is always a gap between what we want and where we are right now. If you don’t have such a gap, you may think that you have already achieved great things, and that is great, by the way. But you are not gonna get better at anything.

I have talked at length in this newsletter about my planning process from years all the way down to the days.

So I always have a gap between what I want and where I am. If I get closer to where I am, I update so I have more room for growth.

And that gap sucks.

If you get too crazy with your goals, you will find that you are not clear on how to get there. Or maybe you’re clear on how to get there, but it’s so intimidating, it’s so tedious, and you are so tired after work that you never start.

That’s why, while I keep envisioning how my life will be in five or ten years and have big goals, I go down into smaller experiments.

Take one meaningful project or learning goal that you have, something that is going to get you closer to that ideal life. Then instead of planning that project by itself, just plan an experiment. Something that you can just do in three months, and you can get some results, and you can iterate from there

I have been writing for three years here on Substack, but the reality is that I started with, “I will write this weekend and then try to write time to time on the weekends until the end of the year”

Remove friction

For the sake of continuing with the example of my writing as a project, there was so much friction in getting myself to write.

If you have never written online, just consider it any other project: you have many things in the pipeline in order to produce one article. You need to decide on an idea, create an outline, write it, edit it to remove any grammar mistakes, and make sure that the article still makes sense. Then you have to put it on Substack, publish it, share it in some forums…

Whenever you start something, you have to do absolutely everything. And even if you had the money or the resources in order to delegate, I will still encourage you to do everything at least at the beginning. Then you realize which areas you are really needed at and which areas someone else can do.

But now, my dear friend, we are in the era of AI. From all the pipeline of tasks that you have to do, you can decide to do literally everything with AI. Then you realize which parts you add no value to, and you can just delegate to AI. Those are the same tasks that someone with a million subscribers in a newsletter will delegate to someone else.

But you will also realize which areas you are really needed in. And even in those areas, you can improve your life a lot by reducing the friction to do it.

Now I’m still writing these articles, but instead of writing by myself, I’m talking to the computer, and the computer is transcribing word by word what I say. I think this is a great example of how you can lower the friction because getting myself to write on a blank page is daunting. However, getting myself to just talk to the computer is easier.

Whenever you’re feeling lazy about something, the first thing you have to do is get yourself started.

Finish work

Now that you’re started, you still want to do something meaningful instead of losing your time.

That’s why I asked you to define what progress means. For example, if you are doing a project by writing code, then progress can mean the number of commits. For someone doing some kind of content creation, it can be the number of articles, videos, or posts.

There are some times where delegation to humans or to the machine is worse than doing it yourself. And software engineers have usually the anti-pattern of automating a problem that was not worth automating.

This has happened to me at work in multiple times and now I’ve come up to the conclusion that rather than trying to fix that problem with the solution that I thought at the beginning, I need to find understand that the right problem and then probably I’ll find some other solution that requires less effort and does ninety percent of the job.

For example, I wanted to give myself an early review on any code commit or document that came my way. I thought it was going to be very hard to have some event-based system that, whenever I receive an event, triggers an agent to review.

So because the underlying problem was that I wanted to have some ready review whenever I arrived at a task, I ended up doing a cron job that just triggers agents and checks for work to review.

It solves the same problem, but it’s a much easier solution for me to implement.

Make the next session easy to start

Whenever you’re already taking action on your project, you think that you’ll be able to continue that every single day. We tend to project our future linearly.

But the reality is that you’ll still be lazy the next day.

That’s why you should plan when you end the activity. Instead of just finishing because you have a meeting or you have some hard stuff that makes you step away from the computer or from the task immediately, It’s better if you know when you will step out of the task, and you can dedicate the last five minutes to making your life easier whenever you come back.

For any piece of work that you’re doing, you should know what you were planning to do, what you did, and what you need to do next.

This works right because if you see that something is already started, you may only have to move it from 60% to 100% in the next session, instead of having to start it from scratch. It’s always harder to go from zero to one than from one to any.

Always be the one closing your working sessions instead of someone or something closing them for you.

So now, if you’re feeling ambitious but lazy, Let’s plan a system to make your life easier for your lazy self:

1. Define small experiments that feed into bigger goals

2. Remove most of the friction with AI

3. Define what is progress and start tracking it. It will get you motivated

4. Make the next session easier to start

If you found value in this post:

• ❤️ Click the heart to help others find it.

• ✉️ Subscribe to get the next one in your inbox.

• 💬 Leave a comment with your biggest takeaway

• ♻️ Share it with your peers

Share

This article helps you move from phase one, having no time, toward phase two: becoming proactive and regaining time. Small experiments, less friction with AI, and a clear next step make it easier to act on the goals you keep postponing.

I’m building this system below for paid subscribers. Thanks for your continued support!

Subscribe now

🗞️ Other articles people like

Subscribe now

Throughout my career, and even before AI, people have given me positive feedback about my writing.

They found value not only in fluent writing, but mainly in being able to explain complex things and gather a lot of information, and put it into a simple document where we can make a decision.

The reason why I am sharing this is that being good at writing gave me more value than being the best at one single programming language.

In this article, we will discover abilities that combine with your programming expertise. They will be very rewarding and powerful in your career.

Let me introduce you to the M-shaped career strategy.

👉 If this sounds interesting, subscribe now. 22,000+ engineers are already becoming more productive. Paid subscribers have access to premium resources

Subscribe now

What an M-shaped career means for software engineers

People are M-shaped regarding their career when they have many areas of interest. They know enough to do some work in all those areas, but at the same time they are going deep in multiple of them. That’s why it’s an “M” because it has multiple peaks.

We have compared this directly with the T-shaped career strategy. In that one, we are fluent in many things, but we are very good at just one of them. This is useful by itself because it makes sense to be known for one thing because you do it very well. But at the same time, the problem is that it is very hard to be the best at that one thing.

Imagine that you are very good at the Java programming language. It is very hard to be one of the top ten people in the world programming in Java.

However, there is a more powerful idea which is called skill stacking. This is about the fact that it is much easier to be a good Java programmer who communicates well.

This kind of skill stacking allows you to reach better roles. For example, you can be a great developer, but if you don’t have any leadership skills or communication skills, you are not going to be a tech lead. The tech lead doesn’t have to be the best Java developer.

It’s quite the opposite. The value of the tech lead is about stacking skills that are very good together. Because you are stacking different skills, it is harder to find people with those same skill stacks. So you are competing with fewer people in the world.

Stack skills that let you own more of the problem

Let’s go with another example. Imagine that you are a strong Golang developer. You can keep pushing through the limits of Go, or you could add infrastructure and DevOps skills in order to contribute more to your team. You can keep learning Go, or you can add product judgment and improve the things that you build. You can also focus on communication to make proposals and trade-offs clear to the rest of your team and to leadership.

I can tell you that it is much easier, and you have a higher likelihood of success if you learn the different skills. And you have multiple of these chosen skills instead of just focusing on one and the rest being very average.

Let’s use these numbers that I made up to understand the idea. Imagine a $200k/year role:

• You can be in the top 1% at Java to achieve this salary.

• Or you can be in the top 10% Java developers with strong leadership skills and product judgment.

These percentages and the salary are hypothetical. The point is that it is easier for you to be in the top 10% than in the top 1%, because at those levels, each percentage point is very hard to achieve.

You’re essentially making your life easier because you don’t have to be on the very top. You just have to be in the upper mid-table.

A great way to develop those extra skills is to do an additional activity where that skill is the main thing. For example, I told you about my experience in software engineering plus writing. At work, my main thing is doing software engineering, of course. But here I have a newsletter where the main thing is writing. Essentially, I have two roles where I have a separate skill as the main thing. So, by the combination of these two T-shaped activities, each of which has a different skill, I’m becoming an M-shaped developer.

I have, of course, to give the caveat of being careful with which skills you choose. There are skills that are completely unrelated and that may not be useful together. Or even if they are useful together, they may not be useful at your job. For example, I can be a great software engineer and a great video editor. This means that I can create a YouTube channel for software engineering. However, my job may have zero requirements for video editing. So, in the end, I have skills, but I don’t have the right place to use them together. I may write an article about this in the future.

How I make progress without changing direction every week

Probably one of the objections that you have in your mind right now is that, yes, Fran, this is great for someone who has time to pursue several interests. But I don’t even have enough time to be a good software engineer because I have too much work to do. I cannot add more activities to my day. I cannot switch frenetically and rapidly between tasks and make zero progress.

This is where my productivity workstation, a resource that only paid subscribers have access to, comes into play. With it, you would be able to plan ahead for one main goal and other side quests, and be able to schedule those work slots through your quarters and then later through your weeks and days.

I try to plan my goals in the way that workstation shows it. For each year, I have a main goal. And depending on the year, some years have been about my work at Amazon to grow and get promoted. Other years have been about my personal projects. The key here for yearly planning, paid subscribers also have access to my yearly review template, is to make sure that you have a goal for that year, but that you are not repeating the same goal every single year.

👉 If this sounds interesting, subscribe now. 22,000+ engineers are already becoming more productive. Paid subscribers have access to premium resources

Subscribe now

Read more

Subscribe now

There are two ways of working. And I’m sure that you will be able to identify which one you have and which one people around you have.

One of them is chasing people for answers and answering every question with another question.

For example, you know that you have a dependency, and you are just pushing the work into them. They are blocking me; they are pending this; they are pending that.

In the case of the second way of working, you’d do things differently. You know that you have a dependency, and rather than just pushing the ball to them and waiting for an answer, you make a proposal. You are making progress in the work, instead of moving the work around.

Think about working with this second type of person. Someone who is absorbing bureaucracy. Someone who is shielding you from having to deal with the complexities of the entire team or even the entire company. Someone who understands that as a software engineer, you have to focus on the technical details. So they protect your focus on development.

Which type of way of working would you prefer in your team? Which one do you think is better?

In this article, we will explore the two ways of working. We will also understand the drawbacks of this second way and how to make sure you have the good without having the bad. If it were perfect, everybody would be working like this.

👉 If this sounds interesting, subscribe now. 22,000+ engineers are already becoming more productive. Paid subscribers have access to premium resources

Subscribe now

Taking ownership at work means helping resolve the problem

There is one keyword that all the leadership books like, which is ownership. For me, ownership is about having a skin in the game. It doesn’t mean that you do all the work yourself, but you are responsible for this work. So you are contributing where you can and connecting people where you can’t do it yourself.

Ownership is about you wanting to make progress on the problem. I’m helping anyone who is making progress on the problem. It’s about actually thinking about how you can make progress on the problem instead of delegating to an AI or pushing the problem to someone else.

For example, part of doing the thinking is never saying “This is not part of my task”. If someone asks you something that is out of the scope of your task, you at least have some thinking and propose some actions, even if you don’t take them.

You are going to change one test, and then suddenly someone says that you should take a look at all the other tests. Then you take a look and say: “Okay, I see that there are more changes needed. Let me create a separate ticket or let me take action in a new code review, as this one was for X purpose, and it’s still valid”

The bad way of working would be just not doing anything.

Unfinished thinking becomes someone else’s work

There’s an anti-pattern in the corporate world, which is threads. Be it in email or any other tool like Slack, it’s very tempting to just add someone else to a thread and push the problem to them.

My team uses Slack, and I’m constantly getting pinged on things where it’s true that I can contribute, but other people could have made progress, so when I arrive, I’m just… having less work to do.

At least if you are adding someone else to a conversation, you have to give them a brief context and also a clear action needed from them.

Coordination that removes work from an engineer’s plate

This way of working is especially important for software engineers. We are people who need time to think and focus. And now, with AI doing all the implementation, it’s more important than ever. We can get very fast down the wrong path if we don’t have the time to think.

Now imagine the opposite way someone is adding you to something where they have a clear proposal and they need five questions from you. It is very easy for you to answer those questions, refine the proposal with your information, and get alignment very quickly.

This is what at Amazon is called internally: asking questions the right way. You don’t ask something like “Hey, I don’t understand.” You do your investigation, you form an opinion, and you ask targeted questions, given the proper context.

Don’t be the engineer who only relays AI output

I already wrote about this anti-pattern, but I think it’s more important than ever.

The other day I saw this post on X about people working in the biggest AI labs. They still write their own text.

And it’s true that there is a benefit in writing because writing is thinking. I have been journaling for a while, and it’s almost therapeutic to write down your thoughts.

Everybody has AI tools nowadays, so I am not asking anyone to get an AI output. I will just ask the AI directly.

This website below is quite funny. It reminds me of the days of the other websites about no hello (don’t say hello and wait; say hello and send what you want directly)

https://dontpastetheai.com/angry/ (Yes, there are different versions and I share with you the angry version)

Now you should be convinced that the point where you are employed is to think. It wasn’t always about writing code; it was always about thinking.

So we need your actual thinking applied anywhere you are required.

Do the thinking that makes your next action useful

So now let’s make this article practical. Whenever you are involved, at least do the following:

1. Clarify the expected outcome (with people)

2. Check the relevant facts (You can use AI here; it’s pretty good at it)

3. Identify any assumption or any decision that is not yet resolved.

4. Resolve as many as you can based on your knowledge or your responsibilities.

5. For the ones that you can’t resolve, make a suggestion and find the relevant person, giving them the precise input that they need and the right expectations.

So now, going back to my example: you are changing one test, and someone asks to change something else in other tests.

At a minimum, what you should do is check it. At least you get an informed opinion to answer that person.

You will also identify what kind of improvements we can make, even if you didn’t dive too deep. And answer with an approach, even if you are not doing it at all. You should have clear next steps.

And you can still use AI in all of this, but you have to form an opinion yourself. Gather the evidence with AI. Review your opinion with AI to challenge it in an adversarial review. But you are still the one responsible for doing the thinking.

It’s like if a manager or a director or a vice president was not doing anything themselves because they just plainly relay what their reports tell them to the higher-ups, that person will be fired immediately.

This is not only about adding value to the rest of the company. This is helping yourself because you will have an understanding of things. You can check this article that I wrote about Automate the Work, Not Your Understanding —

Conclusion

Remember once again, your contribution is the thinking and the judgement.

One challenge that I give you is reviewing your last messages and emails that you sent. Are you actually moving the problem around, or are you actually making progress towards solving the problem?

Let me know in the comments any example that you want to share, from you or from someone else, that shows the patterns in these articles.

If you found value in this post:

• ❤️ Click the heart to help others find it.

• ✉️ Subscribe to get the next one in your inbox.

• 💬 Leave a comment with your biggest takeaway

• ♻️ Share it with your peers

Share

This article helps with phase two: becoming proactive and regaining time. Clarifying problems and making useful requests can reduce unnecessary coordination and protect your focus.

I’m building this system below for paid subscribers. Thanks for your continued support!

Subscribe now

Related Software Engineering Guides

Subscribe now

In the early days of AI, back when we didn’t have these tools like Cursor, Claude Code, or Codex, I remember that I was copy-pasting code into a web-based chat interface and getting the code snippets to use in my editor.

Back in the time I didn’t know how much we could trust AI or not. So I remember that this was making me faster at generating code. But the actual shipping to production was getting slower because I had to iterate more in code reviews.

Now we have much better models, bigger context windows, but still… The biggest improvement was not about the tool. It was about the system that I built around generating and shipping code with AI.

In this article, I want to cover the difference between tools and systems and why we have to focus on the second.

👉 If this sounds interesting, subscribe now. 22,000+ engineers are already becoming more productive. Paid subscribers have access to premium resources

1. Find the bottleneck in your AI software development workflow

There is a reason why AI has taken over the software engineering world, and there are many other jobs that are still doing things the same way.

We, software engineers, already have a very clear step-by-step life cycle for generating software.

You start by clarifying with the customer what they actually want and putting it on paper in the form of requirements. Then you do a bit of a technical design, investigating how to actually fulfill these requirements and what consequences each of the alternatives will have. Then you write the code, review it with peers if you work in a team, write tests that make sure you don’t regress and break any requirements, and finally put it into production so customers can use it.

This was already there before AI, and now we have a clear roadmap, so we just need to use AI in each of these phases to improve it.

Read more

Subscribe now

Read more

Subscribe now

I want you to picture two people.

The first one is a very experienced engineer who is always advocating for following best practices. Someone who has been in the company for a long time. And someone that you actually trust, like you look up to them regarding their code quality.

The second one is a new hire who doesn’t have much experience and doesn’t have any experience in the company. Someone who is starting to write their first contributions in code. And you have seen that they are lacking some of the mental models that this company requires.

When you arrive at work in the morning, you realize that you have one code review from each of these people. And let’s say that those code reviews are more or less the same complexity. Which code review would you spend more time on?

In theory, if AI had already reached the point to replace all software engineers and we were already into AGI. Provided that both people have the same models available, you would just say that both should be the same level of trust. But the reality is that no, you are trusting the experienced engineers more than the new engineers.

So, if both people are using the most powerful model and we still trust one more than the other, why is that happening?

👉 If this sounds interesting, subscribe now. 22,000+ engineers are already becoming more productive. Paid subscribers have access to premium resources

AI-first software engineering still needs a human standard

So many people think that they are AI-first engineers just because they are using AI. I think nowadays in 2026, everybody is using AI.

Where I think we’re making a mistake is when we think that we can ask it, “Build me an iOS application”. And the AI will make all the decisions and don’t need any supervision over it. And just the code will be good.

It’s great that the AI is removing and abstracting you from many micro decisions that otherwise you would have to make. However, the AI abstracting you doesn’t mean that the AI is making the best decision all the time. This is where your judgment comes into play.

Now think about someone who, instead of asking the AI, “Build me an iOS application”, used AI to investigate what the best practices of iOS development are. Someone who put the AI to work and made it ask the most important decisions. And someone that made the AI surface what are the trade-offs and the architecture decisions that it’s taking in order to approve or reject.

The difference will be clear, and not only in the actual output, the actual artifact, but also in the understanding and the learning that the person behind the AI is having.

It’s not about not using the AI; it’s about using it but not making it play against you.

Sometimes when I interview candidates, some of them tell me that they are proud of not using AI in the actual code. They say they only use AI to write unit tests or to write documentation. They may have thought that the answer I was looking for was not to use AI. But the actual answer to the AI problem is not avoiding having to think hard about how to make AI work for you. The actual answer is making AI work for you, building everything around the AI.

I know that there are a lot of people who are against reading AI-generated articles. I’m not personally against it, but at the same time I know that it’s hard to build trust if you write everything with AI. That’s why I’m writing this manually.

But take, for example, two articles. The first one was from someone who had been doing a lot of research. Someone who built their own software. Who tried, failed, and tried again. Someone who had the hard-earned scars of experience. And then that person told the AI to write an article from all those learnings.

Now take a second person who just told AI, “Hey, write me an article about whatever topic”. It can be true that the actual syntax is similar, you know, because AI is having the same patterns. AI is repeating the words in the same way. But I will trash the first-person article, and I will actually read it. And I will just trash away the second person’s article.

The reason is simple. It’s not about how much time it took you to write the article. It’s about what authority and credibility you have to actually write about it.

The same thing with PRs. I will trust the senior engineer’s PR more than the junior engineer’s PR. Both use AI to generate the code, but I trust the person behind it differently.

Borrow judgment from people who have earned your trust

Read more

Subscribe now

Read more

Subscribe now

I’ve heard many times recently that we are lowering our code quality because of AI.

Some people argue that AI is stupid and writes working code that is not maintainable. Others argue that we can’t go fast and have good code.

I think those are not accurate. We’re not lowering our bar because of AI; it’s probably because we got used to coding “the old way” and didn’t learn about doing it with AI.

It’s time to re-learn what “good software engineering” is about. In this article, I’ll shift our mindset from focusing on the code to focusing on the harness that writes the code…

👉 If this sounds interesting, subscribe now. 22,000+ engineers are already becoming more productive. Paid subscribers have access to premium resources

AI isn’t forcing a quality tradeoff.

For those of you who have been coding before AI, like I’ve been, you may remember an impossible deadline in a different way.

Instead of just asking AI to code something, you had to prototype things, barely skim through library documentation until you got something that works, and have no time to refactor.

It was always normal to ship short-term solutions to favor speed, and later refactor once we had more time.

But now that AI is writing the code, couldn’t it write it in good shape from the beginning?

Let me tell you a story about a management book. There were two farmers; each had a hen that was producing a lot of eggs. The first farmer decided to force it to lay more eggs, all the time, to sell them. He was focused on the eggs. The second one was focused on creating the right environment to lay eggs, taking care of the hen producing the eggs. The first one stopped laying eggs; the second one was producing more and more.

This story is about taking care of your engineers before they burn out, so they will produce better code. But we’re now managing AI, and it applies to us as well. It’s not about telling sweet things in your prompts, but about designing the system that makes AI write good code.

AI is fast by itself, but it may not be right by itself. The quality of software generated with AI depends on the system that you, as a human, have created for it. If it’s generating bad code, you are the problem.

Some of the things that impact AI-generated software quality:

1. Clear standards, consistent in current code

2. Fast feedback: Unit tests, functional tests

3. Close the feedback loop: Allow the AI to deploy the changes, run the tests, and inspect against a quality checklist.

Your AI can’t follow a standard it can’t validate

At work, I’m constantly trying new tools and approaches. The thing with a technology like this is that everything is new, and you may find benefits in something you didn’t expect.

One such tool seemed promising at first; it was triggered after a ticket was added to a sprint, generating code and raising a PR. This is the dream of everyone, the AI replaces end-to-end the implementation.

But there was a catch, as you may already be guessing.

Read more

Subscribe now

Read more

Subscribe now

I’ve been on vacation for the past couple of weeks, just ready to come back to work.

While enjoying time away is great for your mental health, some time ago I thought about it as downtime. Time not working means time not achieving results.

But I reframed vacations and time away from the computer once I learned how Bill Gates managed his “Think Weeks”. It was his time to go away for a week without any phone calls or email from Microsoft. This time was for him to focus on reading books and papers.

The point of the Think Week is not about the quantity of reading material, but about quality. You select your reads ahead of time, you remove all inputs from your day-to-day work, and you make decisions.

So this is not about spending your vacations reading papers, but more about finding some quiet time when you’re not working to actually improve the system instead of only working the system.

A Think Week tells you whether you lack clarity or knowledge.

A question I asked myself a lot of times is why I was having “low energy”. Physical factors like your nutrition and sleep have an impact, but I’m talking about the situation in which you have a lot of energy to do anything except work. That’s not about physical energy; it’s more about motivation.

We lose motivation when we lack either clarity or knowledge.

• If we lack clarity, we don’t know which goal deserves the effort. You may talk about things instead of doing them; you may look for optimizations but make zero progress.

• If we lack knowledge, we know the direction, but we don’t see any path that will take us there. We may have vague plans and repeated decisions.

In your day-to-day work, both gaps look like procrastination on your goals. But when you take distance, you find out if you’re clear on what you want in the future and if you have any path that will take you there.

Some problems need continuity, not just more hours.

You may have heard of the 10,000 hours for mastery. It was an idea that anyone who wants to become an expert needs dedication, and 10k hours are for sure a lot of dedication.

But this can be misleading in a given week. I may have worked for 10 hours on my personal projects, or I may have worked 40 hours for my day job, but not all hours are created equal.

Imagine reading only for 6 minutes, repeated 100 times during that week. That’s 10 hours. However, in 6 minutes I won’t be able to get the context and think about what I’m reading. But now think about reading for 10 hours in one or two days, thinking about what you read, and making a decision. I only work on reading for 1 or 2 days instead of the full week, for 10 hours, but I can think about the problem and draw conclusions.

It’s true that spaced sessions help long-term retention of knowledge. And you may come the next day with a fresh mind that solves a problem faster than brute-forcing hours. But each work session needs enough continuity to think about the problem.

While day-to-day you may not have enough time to dedicate a few hours in a row to reading, use your time outside work, weekends, or vacations to grab a book and enjoy the uninterrupted time (it doesn’t have to be a technical book; this is generic advice for anything you’re procrastinating)

Subscribe now

You cannot improve a system while you only run it.

While you’re working, your incentives are to fix things with local optimizations (e.g., make something faster) instead of higher-level questions (refactor to simplify).

And this applies to any area in life; I’m sure you have things at home that you’ve postponed because never is the right time to properly fix it.

There’s a story about two lumberjacks who were tasked with chopping as much wood as possible for 4 hours. Each of them had no help from anyone, and their only tool was an axe; both were identical.

The first lumberjack started rushing to chop wood, but they were getting tired as time passed, and their axe was getting dull.

The second lumberjack dedicated the first hour to sharpening their axe, warming up their muscles, and asking someone else about the best technique to chop wood. Then they chopped wood with a much better process, having more results by the end of the 4-hour period.

We are all like the first lumberjack in our day-to-day lives. We are so rushed into doing everything we have to do, at work and in life, that we never stop to sharpen the axe. We don’t even know what the equivalent of sharpening the axe is for ourselves.

A Think Week creates room to get a higher-level view of your life and work, to fix the root causes and inconveniences, and gain leverage that you’ll be grateful to have once you’re operating in your day-to-day. And even if you think you don’t have anything to improve, reading a book will give you the knowledge to realize how much you can still improve.

How to run a Think Week as a software engineer

Read more

Subscribe now

Read more

Subscribe now

Last week, reading a pretty old book about software engineers’ productivity.

It felt like the author was living in the dinosaurs’ era. Typing code by hand, getting crazy about some macros and scripts for small automations.

All of the things that were great productivity improvements at the time just became outdated. The bar was raised way higher than that.

But those tools were only the means to an end. And that end was some productivity fundamentals that are still present. Knowing them will help you become really productive with AI, instead of being as average as everyone else using those tools.

Let’s learn the 4 principles for software engineers’ productivity.

Acceleration

Acceleration is about reducing the time between your intent and the verified result. In the old days, when writing code, if you intended to write a function and a type checker flagged errors in your code while you were typing, you got much faster at typing correct code.

Now with AI we’re not writing our own code. We’re not even building and checking our own code. I’m just telling the AI to send some curls and “gimme a report of the results”.

However, just imagine that you’re one of those people who require approval for each shell command the AI wants to run. You’d be increasing the steps to get to working code too much. It’d be faster to write it yourself.

So the principle of acceleration is all about tuning your workflow steps in order to be just one prompt away from having working code.

Note: I wouldn’t consider a workflow faster or slower depending on how much time it takes. I’d consider the workflow “accelerated” if it works without me having to be on top of it. The point is about reducing interactions with the computer needed to make something happen.

Focus

Focus is a hard one. I’m multiplexing a lot of agents running in parallel nowadays, which means that my attention is fragmented. And I was told by all productivity books that switching between tasks, getting notifications, and interruptions were the enemy of focus.

The book has this same understanding of focus: Reduce notifications, close windows you’re not using, search instead of using navigation...

So based on this definition, I should work with a single AI agent.

But regarding the principle of Acceleration, the point is that I can one-shot the results I want with a single prompt. It means that in an ideal world, I want a single interaction to complete a task.

So what if focus isn’t about “work in 1 task”, but about “work in one project”?

Read more

Subscribe now

Apologies for writing this one with a 1-day delay! Some tight deadlines and my pager ringing in the middle of the night got my time and attention this past week 🙇

I have multiple AI agents finish work before I arrive.

One can inspect a pull request. Another can investigate a test failure blocking me from raising a PR. Another can implement an approved plan and return with a ready-to-review diff

But I have also opened the queue of completed work and realized that the passing build did not solve the actual ticket. Or that the AI tried to reconstruct the whole system instead of solving only the task at hand. In those cases, it removed my implementation effort to move it into review effort.

Let’s focus on how to make good use of AI and avoid the common pitfalls.

In this post, you’ll learn

• What codebase cognitive debt means in software engineering

• How cognitive debt differs from technical debt and intent debt

• Why AI coding agents can improve code while weakening team understanding

• How to detect and reduce cognitive debt before it becomes a production or career problem

What Codebase Cognitive Debt Is and Why AI Accelerates It

Codebase cognitive debt is the gap between how a software system works and the team’s ability to explain why it works. AI coding agents increase that gap when they produce changes faster than engineers can review and understand.

Margaret-Anne Storey introduced this idea as part of a Triple Debt Model. Martin Fowler later summarized the framework for software practitioners. The model separates three kinds of software health:

• Technical debt lives in code. Implementation choices make future changes harder or riskier.

• Cognitive debt lives in people. The team’s shared mental model erodes faster than it is rebuilt.

• Intent debt lives in artifacts. The goals, rationale, and constraints behind the system are missing, stale, or trapped inside old conversations.

A team can reduce technical debt by asking an agent to remove duplication, add tests, rename confusing abstractions, and simplify a module. The resulting code may be objectively easier to read. But if the agent made the decisions, the reviewer skimmed the diff, and nobody recorded why one option was chosen over another, the team may still owe more cognitive and intent debt than before.

The code improved. But it’ll be one of these scenarios where history is doomed to repeat itself.

This is why I like focusing now on this cognitive debt vs technical debt. Technical debt limits how easily the code can change. Cognitive debt limits how safely the team can reason about that change. Intent debt limits whether anyone can prove that the change still serves the original goal. Even if the code is easy to change and you understand what it’s doing, you don’t know why you’re doing it.

Thoughtworks Technology Radar Vol. 34 treats managing cognitive debt as a theme across the AI engineering landscape. Its codebase cognitive debt entry carries a Caution recommendation. They warn that weaker understanding makes it harder for developers to guide AI, spot hidden coupling, and steer agents away from architectural mistakes.

That creates a downward spiral, a spiral of bad outcomes that keep growing. The less the team understands, the more it depends on the agent to explain and modify the system. The more it delegates without rebuilding that understanding, the larger the gap becomes.

AI is not creating this as a new problem. Before AI, teams have always lost knowledge when people left, documentation became stale, or an abstraction hid too much. AI changes the speed and scale. A team can now create more changes, across more parts of a system, with fewer moments where a human has to build the complete model first. I’m creating in a month the amount of PRs that I created in a year before.

AI is useful only if you understand the bottleneck.

The Code Can Improve While the Team Gets Weaker

I see the first symptom in code reviews.

AI can prepare several changes while I work on something else. When I reach the review queue, every pull request can have green tests, a plausible summary, and a tidy diff. But they only include the evidence the agent remembered to collect, what the human remembered to point to the AI.

They do not automatically give me the model that connects the change to the rest of the system.

This is the pattern:

1. Agents increase the number and speed.

2. Humans review the result more shallowly

3. Important decisions remain inside a chat, a prompt, or the agent’s temporary context. At best, 1 human knows it. At worst, nobody is paying attention

4. The team becomes worse at explaining the system, worse at prompting for the next change.

5. More generated work is used to repair symptoms, so all three debts keep growing.

This is a bad snowball effect. If nobody can explain its behavior, constraints, and failure modes after the agent session disappears, the team has become more dependent on regenerating the explanation later.

Some skeptics may think that this is fine. We can always use AI to explain the system back to us. But then we’ve lost our ability to become the Senior Engineer that guides the AI towards the good path.

We have always traded low-level knowledge for higher-level abstractions. Python developers do not need to reason about every machine instruction. A well-designed abstraction removes unnecessary cognitive load.

The difference is whether the abstraction preserves the concepts the team needs to make the next decision.

We don’t need every engineer to remember every line. But we need the team to know how to verify whether a future change is safe.

But it’s not all bad news. Good agent instructions can reduce the debt. That is useful, but it also reveals the limit of prose instructions. A growing rule file records lessons, yet the model can still miss or deprioritize them. The team also needs to know why those boundaries exist and which ones are important enough to enforce in code.

I learned this while building my AI code-review workflow. A generic reviewer gave me noise. Specialist reviewers became more useful when I combined them. The report did not replace my understanding. It gave me a better place to start rebuilding it.

Maybe you’ve heard that AI cybersecurity attacks need a stronger AI defending the system. We have the same situation here: AI-generated code changes need an even stronger AI reviewing those changes to help the human.

Notice I keep the human understanding as one of the goals. Doing changes faster, more reliably, and more safely are great, but they can’t be achieved with zero human understanding

Automation removes mechanical work. Understanding preserves ownership.

Read more

Subscribe now

Read more

Subscribe now

Read more

Subscribe now

Last week, it was the performance cycle at Amazon, and I was told everything went as planned.

I had shipped a lot of code during that period. But the conversation with my manager was barely about particular commits. It was about decisions, documents, reviews, launches, incidents, and outcomes that other people could remember and explain.

That distinction matters for a promotion.

A software engineer promotion artifact is durable evidence of engineering judgment or impact. Sure, a commit can be, but most times, commits are treated as bulk. You raised 100 commits in a month, which makes you the best in your team in terms of quantity. But you need to build a narrative around it, like how you argued tradeoffs in a design document, a test plan uncovering blockers, a launch checklist, an incident analysis, etc

The artifact lets another person understand what you changed, how you operated, and why the work was above your current level. It’s not just a number.

I learned this lesson when I got promoted earlier in my career. The flagship project I drove involved an escalation and my involvement in a meeting with my L7 and the other team’s L7. That was more important than the code I wrote, which was mostly disambiguated already. I am applying it again now as I work toward the next level, and I’m recommending the same for my mentees, so I thought I’d write about it.

If you wait until review season, you will remember some tickets. You will forget the nuances of the requirements you negotiated, the risks you found, or the team you unblocked

In this post, you’ll learn

• What counts as a software engineer promotion artifact?

• Which artifacts should be created across the software development lifecycle?

• How to distinguish useful evidence from documentation theater?

• How to turn raw work artifacts into a concise promotion case?

What counts as a software engineer promotion artifact?

A promotion artifact is something another person can inspect to verify your judgment, influence, ownership, or results.

A task says what you did. An artifact preserves why the work mattered.

For example:

• Requirements meeting: The calendar event proves you attended. A PRD comment and decision record shows the requirement you changed, your reasoning, and the final agreement with the product manager. If you save that evidence proactively in a brag doc, it’ll be much easier to find later than if you have to dive through old documents and comments.

• Technical design: Even if it’s a one-page recommendation with alternatives, reviewers, decisions changed, and dependencies unblocked. This document proves your engineering judgment.

• Implementation: A list of PRs proves activity, and it’s great to monitor your numbers to be at the top of your team/org. But it’s easy to game the metric by doing low-value work that generates tons of PRs. You need to be able to reference a critical-path contribution tied to quality, adoption, reliability, or a delivery outcome.

• Production incident: Joining a war room proves presence. A timeline, diagnosis, decision, and implemented mitigation show how you helped resolve the problem. Being the one who analyzes and solves the problem, even if someone else writes the code, is a good narrative to save.

Promotion systems tend to evaluate 1/ the impact of the work and 2/ the competencies demonstrated while delivering it.

Code can support both. It rarely explains both on its own. The promotion committee will not reconstruct your reasoning from a pull request six months later. Your manager needs a shorter, defensible story that connects the problem, your decision, the people affected, and the result.

As you grow in level, the promotion committee will include more people who are not working with you every day. They will evaluate evidence where they were not present. Would they be able to use your artifact to explain your contribution when you are not in the room?

If the answer is no, important context still lives in your head.

If you need to map your daily work against the expectations of the next level, this role-gap analysis gives you a concrete system:

Build promotion evidence across the entire software lifecycle

I recommend that my mentees generate artifacts throughout the whole software development lifecycle.

Besides generating those artifacts (links), write in your brag doc a small narrative about what the context was (situation and task you had to do), what you did (action), what the results were (results), and then index all the links to the artifacts as evidence. Artifacts are the data; the entry in your brag doc is the narrative.

Some people work in companies where the software engineers are just one gear in the machine. Requirements come from PM, designs from architects/tech-leads, implementation from developers, testing from QA, and release from devops/SRE. Where I work, an engineer is supposed to contribute to all of these, so for a promotion, you need evidence through all of these.

I created something that I call the Artifacts Pipeline, and it looks like this:

Requirements

Create:

• PRD comments.

• A decision record for important tradeoffs in requirements and proposals you made.

The weak version says, “Worked with Product to define requirements.”

The stronger version shows the original requirement, the edge case you found, the tradeoff discussed with the product manager, and the requirement that changed because of your input.

Both texts above could be talking about the same situation. But the second one is much stronger.

Design

Ideally, you’ll have some strong documents with a technical design. But even if the project is small, write at least a one-pager before implementation when the project contains a meaningful decision.

The document should include:

• The problem and constraints.

• Your recommendation.

• Alternatives you rejected.

• Dependencies and risks.

• Open decisions and owners.

Then review it with people who need to know your work and can improve it. That can include your tech lead, an architecture group, dependency teams, operations partners, or the senior engineers who understand adjacent systems.

A big part of a promotion is making your work visible for the people who will promote you.

Remember that once you have done the work to write the document, each review is almost free; you just have to go to a meeting with that person to review it. Each review becomes a new artifact. Record who reviewed the proposal, what concerns they raised, and what changed afterward.

“Attended a design review” is weak evidence. “Identified an unhandled flow and changed the design before implementation” is much better.

Create the backlog

Break the project into workstreams and identify the critical path.

The useful artifacts are boring:

• A list of workstreams and owners.

• A dependency map.

• A milestone calendar.

• The risks and open questions that need to be resolved, with owners.

Try to own a core workstream. Core means another part of the project depends on it, or the launch cannot happen without it. Another way of working is always jumping into the workstream that becomes the critical path. I remember I was doing this a few years ago in my previous team. I owned a smaller piece but then I jumped into any work where one engineer was blocking another.

Shipping many tickets is just a number. Dividing the work and picking one critical-path item shows you can be trusted with a project..

Implementation

Read more

Subscribe now

Read more

They ask for code, wait for a diff, review what changed, and repeat. That can work for isolated tasks, but it breaks down when the work needs repo context, team conventions, test evidence, rollout thinking, and clear boundaries around what the agent can touch.

The fact that your company pays for Cursor, Claude Code, Copilot, or Codex does not make you an AI-native software engineer. It means you have access to a tool.

This is where the term “AI native software engineer” should mean something practical.

An AI-native software engineer defines the working system that makes an agent useful on a real codebase: context, memory, tools, permissions, loops, verification, and evidence.

The interesting skill is creating a system where AI can produce reviewable work.

Generating code that compiles is cheap. Increasing the delivery speed of production-ready software is harder, but as you’ll read today, it’s not impossible.

What is an AI-native software engineer?

An AI-native software engineer uses AI as part of the engineering system. The AI harness that you use becomes a workflow component inside the software delivery process.

The difference is whether you can make AI work reliably inside a real repo, with your team's conventions (not the biases of the model), deliver under pressure, adapt fast to changes, and hold a high bar in code reviews.

Here is my definition:

An AI-native software engineer defines the system an AI agent needs to produce reviewable work.

That definition matters because most AI failures I see at work come from missing local knowledge.

The model can write working code, but at Amazon we have A LOT of internal tooling that the models don’t know about. So somehow I have to make the model know how to operate in that ecosystem. And you should do the same.

OpenAI makes this point in its Codex agent loop write-up, where the harness orchestrates the user, model, tools, and context needed to do meaningful software work.

The model is one pluggable part of the system.

The useful distinction looks like this:

• AI tool user: Their company gives them a license and asks the model to implement a task, usually gets code that works for the most part but doesn’t manage well the edge cases and changes in direction. AI speeds things up but lowers quality

• AI-assisted engineer: Gives good context, reviews the diff, iterates with AI, changing some pieces of code until the code meets their standard. Often feels like they have to micromanage AI and wonders if they would have been faster by themselves.

• AI-native engineer: Defines a system for AI to work: specs, repo memory, tools, execution loops, produces reviewable work to keep the human in the loop at the right time, verification papertrail. This engineer takes time to create the system and always keeps refining it. But it’s like a plane: once it takes off, it’s faster than any other approach.

The third model doesn’t care too much about benchmarks or the new model because they have a system where it’ll just change one string and keep working with the new model.

It sounds boring because it is.

Most things that work are boring.

From better prompts to better operating systems

Prompting still matters. A vague instruction creates vague work.

But nowadays it’s no longer the highest-leverage layer for serious software work. The better question is: what operating environment does the agent need so the prompt stops carrying the whole system on its back?

Anthropic’s context engineering guidance pushes in this direction. Agents should assemble understanding layer by layer, keep only what matters in working memory, and use tools to retrieve what they need instead of drowning in every possible document.

OpenAI’s harness engineering article says something similar from the Codex side. A giant AGENTS.md eventually becomes a junk drawer. The better pattern is a short map that points to deeper docs, examples, specs, and checks.

That matches what I see in practice.

The same model can feel brilliant in one workflow and reckless in another.

A useful next step is this breakdown of harness engineering and why production AI agents need tools, state, guardrails, and feedback loops: https://strategizeyourcareer.com/p/harness-engineering-ai-agents

The toolkit is context, memory, tools, loops, and evidence

If I had to reduce AI-native engineering to one checklist, it would be this:

Read more

Then I found the value was correct for some flows and wrong for others, which meant it was not as easy as replacing the value.

This is where AI would have swapped the value if I had just prompted “implement the fix for ticket JIRA-1234”. But I also found, thanks to AI, the different flows, the backend service that owns these configurations, and what the impact is on other parts of the system when changing those values.

My AI did an investigation, adversarial review, decided which follow-ups we needed and with which people, created a plan with multiple alternatives, implementation, and QA.

So what’s the difference between one AI and the other?

In this article, we’ll see how to use AI for software engineers. I’ve checked, and I consumed $20k in June in my AI workflows at work, so I’ve experimented a lot until I landed in this workflow.

When the output is an investigation report, a review checklist, a test-gap list, …

Read more