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

A huge pain point that I’m sure many of you have is that you get a subscription for one AI provider like OpenAI or Anthropic. And then the other one releases some amazing features that you would like to have.

This happened to me when I had an OpenAI subscription, but I wanted to use Claude Design. So I decided to take a look at the open-source community to see if there was anybody who released a tool like Claude Design but open source so that I could bring my own agent.

And indeed, there was one. So I started digging into other tools that we are using a lot nowadays and whether I could bring my own agent.

That’s why I decided to write this article, because I think it’s something that can be useful to all of you unless you are paying for absolutely every single tool that is out there.

And in some examples, you’ll see that open source is actually better than closed-source software.

So maybe we can say that these companies are the ones introducing a new tool. But very soon the open source community is catching up and improving it faster than what closed source can do.

If you are like me and you have this FOMO whenever you hear about a new tool and you would like to try it instead of buying one subscription for each major AI provider, what you can do is use the open-source alternative with the provider that you already paid for.

Now, 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

Coding

Most likely, you already pay for a subscription to an AI provider to write code. In the end, you have to know that these subscriptions are subsidizing the usage of AI. This means that it’s cheaper to use AI through a subscription than using AI through an API.

But still, there are many things that maybe you would like to customize that the closed-source provider doesn’t allow you to. So even if you’re already using a subscription, for example, providers like OpenAI are very open about allowing you to use your subscription in another harness. Keep in mind that for Anthropic, that doesn’t apply.

1. Claude Code and Codex

These tools let an agent work inside your repository. But besides coding and understanding the code, you can also use them for any kind of knowledge work because in the end they are an agent with access to tools and MCPs.

OpenCode is the one I would start looking at if you want to change the model without changing the harness. If you are not sure what’s the difference, the harness is every single thing around the model, while the model is the brain. The harness is the part that reads your files and uses the tools. That’s what works with your repository.

You can also check Pi, Goose, and Aider. Pi is smaller, and you can extend it. Goose is extensible too. And if you like working in the terminal, take a look at Aider.

But if you already pay for Claude Code or Codex and you know how to use it, why change? You can stay with what you have.

Maybe tomorrow you want to use another model. And that’s the main problem with the current state of AI tools. They are keeping the memories that it learns from you for themselves, so if you wanted to switch to another you may find that it’s dumber or it’s harder to move your workflows.

And actually, Codex CLI is already open source. You have to separate that from the model and from the service that OpenAI hosts. There are ways to put another model inside the Codex harness too.

2. Cursor, Windsurf, GitHub Copilot

They bring AI into the code editor, for example completing the next lines of code or having a sidebar to request changes.

In the open source world, you have Continue, Cline, and Kilo Code. However, I’d say the biggest open source competitor is Visual Studio Code. This is the code editor that most of them are based on, and it’s very modular with the extensions marketplace. So you can install extensions for any AI provider that you may already have, like Claude or Codex.

The reason to keep Cursor, Windsurf, or Copilot is that you may already have an editor setup that works well for you. Changing tools has a time cost too.

I would consider the open-source options to have more control to change model providers while keeping my already configured editor. You never know. When using closed source like Cursor, you may find from one day to another that there is a deal broken and you can no longer use OpenAI models inside Cursor. You can prevent that by using an open-source one.

3. Devin

Devin is for delegating a development task to an agent, let it cook, and it’ll bring you something to review. The point was that you would review just the final resource instead of intermediate steps, but I think nowadays all the agent harnesses are about reviewing the final status.

OpenHands gives agents an environment where they can work, and you can configure the model they use. I would also consider Herdr and FirstMate if you want to work from the terminal.

If you want a service that takes care of the environment for you, then you can go with Devin. You’re also paying for the convenience of someone hosting everything for you.

OpenHands makes more sense if you want to control how that environment works. It also makes sense if you have a requirement about not giving an external company access to some proprietary information.

4. Lovable, Bolt.new, and v0

These tools help you go from a description to a working interface or an app prototype, without writing every part by hand.

bolt.diy is an open source option for generating and editing apps with different model providers.

The reason to use the closed-source ones is the convenience of their own workflow. If you like the output, you can host it with them and have a link that you can share.

For Bolt.diy I think the biggest advantage is choosing the model or changing the tool. The downside is that you have to set up everything yourself. Also, you will be responsible for releasing it.

5. Claude Design

You work with AI, but instead of only getting text, you can see what it is making and give feedback on that.

OpenDesign. This is the one that made me start looking into all these tools.

I already had an OpenAI subscription, but I wanted to use something like Claude Design. So I looked for a tool where I could bring my own agent instead of getting another subscription.

And for me, being able to see something and annotate on it is what changes the game. If you give me the text of a Mermaid diagram, I will have a harder time understanding it than if I can actually see what we are discussing.

If you are already using Claude and you like how the design part works, you can stay there. For me the value of OpenDesign was being able to do that visual work with my own agent. I can use the model provider that I already pay for.

6. Retool

Retool is a no-code or low-code solution that helps you build retools for your company. For example, you can build some simple UI’s like an admin banner or a dashboard or things like that. And you can connect with multiple data sources.

Both AppSmith and Tooljet have open source editions. The thing is that Retools includes stuff like hosting, integration and a team that you can support. If you already have something in Retools, the cost of moving may be higher than the cost of just paying the subscription.

Now with AI, it’s easier to move than ever. So you can check AppSmith and Tooljet. And then if you are a software engineer reading this newsletter, you can figure out how to host yourself the application. As a software engineer, that shouldn’t be too difficult.

I had an internal dashboard at work that was using Retool. But then Ring decided to remove the Retool license that they were paying for, and we had to deprecate it and migrate somewhere else. If you are building your own with these open-source tools, you won’t have that kind of problem in the future.

Chat and Research

7. ChatGPT, Claude, and Gemini

These are the chats where you talk to the AI and upload artifacts for reference

LibreChat. Like many others, this is just the chat interface and you’ll have to bring your own model.

If you already have ChatGPT or Claude and you like its features, I don’t see why you would move everything just because there is an open-source option. You would have to set up another interface.

But maybe you keep moving between providers. In that case, I would take a look at LibreChat, because you can keep the same place to work and change the model there.

8. Perplexity

Perplexity searches the internet and it will give you an answer with the sources. It’s about delegating the human work of searching for information

Vane (previously known as Perplexica). You can configure the model and also the search.

I understand paying for Perplexity because you don’t have to set up any of that. You open it and ask your question.

But think about the same thing that we have been discussing in the other examples. Maybe you want to use another model, but you don’t want to lose that way of searching. Or you want to change how the search works. That’s where I would consider Vane, because you can decide how those parts work together.

9. NotebookLM

NotebookLM helps you work with a collection of sources, like documents and notes, and ask questions about what they contain.

Open Notebook is an open-source alternative.

I was surprised when I saw that OpenNotebook can even generate a podcast similar to NotebookLM. And you can plug in any model that you want.

The difference, like with the other tools, is that NotebookLM is ready to use. For people who are non-technical, that may be easier.

Personally, I don’t have any reason to pay Google, so I go with OpenNotebook and host the workspace myself and select the model that I already pay for.

Also, considering that Google hasn’t released any major AI model lately (they have one announced but unreleased), I think it’s worth using the open-source alternative to their products with a better model like the recent OpenAI Sol 6.1 or Claude Opus 5.5.

Agents and Automation

10. Grok Bot, ChatGPT Dots, and Meta Muse

The assistants use tools and continue their work after a chat response.

Of course, the open-source alternative here is OpenClaw. It was the original one that introduced this category of software.

Hermes has gotten very popular. racazo describes itself as an open-source alternative to GrokBot, and it lets you choose the model and also operate in a sandbox. There have also been many other alternatives to the recent products like OpenBot, OpenDots, and OpenMuse, so you can check them all.

Of course, if you use one of the already hosted assistants, you just have to pay, and you are ready to start working. With an open-source one, you will need to decide which model to bring, as well as change the tool and configure the tools that are connected. I know that those are things that we are happy to do as developers because we like them, but we can understand that non-technical people won’t do any of this.

I think OpenClaw was earlier than any of the closed-source alternatives in this group.

11. Zapier and Make (automation workflows)

Zapier and Make are no-code software to connect applications to each other. They were there way before AI, and they were specialized in connecting events from one app to trigger something in another app.

The ActivePieces open-source REPL is a good alternative, but I also recommend N8N as an alternative to Zapier and Make.

Zapier and Make are ready to use. They run everything for you. Also, for the integrations, they’re already connected and require minor setup from your accounts in those dependencies, and you don’t have to maintain any servers.

If you’re not paying for any of this software, you’re going to start with ActivePieces or n8n. They have almost the same functionality, but you don’t pay for a license.

Dictation, voice, and images

12. Wispr Flow and Superwhisper

You talk to your computer and it writes what you said. So you don’t have to type everything yourself.

OpenSuperWhisper is the one I’m using on macOS, instead of Wispr Flow or Superwhisper. And you can also check Handy, VoiceInk and OpenWhispr.

For me, being able to talk to the computer is much better than having to write everything by myself. Especially when I want to explain something, and I already have the idea in my head. I don’t know why it took me so long to start talking to the computer, but now I cannot stop doing it.

Honestly, I haven’t found a reason to use a paid dictation app yet. Right now with OpenSuperWhisper, I’m running the model locally, so it’s better for privacy and all that stuff. At the same time, it’s so damn fast. And it understands both English and Spanish, so it’s good enough for me.

13. ElevenLabs alternatives for voice generation

You give ElevenLabs some text, and it generates the voice. It also has tools to work with that audio.

Chatterbox gives you text-to-speech capabilities

If the ElevenLabs voices are what you want, you have a reason to pay for it. Those are their own audio models. And you don’t have to get into running a model yourself or finding the hardware for it. You can generate the audio and use their editor.

But think about having to put this inside an application. If you have to pay too much to ElevenLabs to generate that speech, I would look at Chatterbox and see if you can do it yourself.

I think at some point audio and video will work like the other model subscriptions. You’ll pay a provider for the model and bring it to whatever tool you want to use. In this case, a tool like Chatterbox.

14. Midjourney and Adobe Firefly

Midjourney and Adobe Firefly are for generating images.

ComfyUI is an open-source alternative for generating images. However, bear in mind that you have to bring your own model.

Consider that Midjourney started with Discord as a UI, the open-source alternatives that we have nowadays are much better than when we started, when we only had a closed-source image generation model.

I’d start with ComfyUI, just controlling the process and testing different ways of generating images. In the end, you have to bring your own model, so in this case you can use a model provider like Magnific in ComfyUI.

Other work tools

15. Superhuman (AI email clients)

Superhuman is an email client with shortcuts and AI to help you get through your inbox.

Inbox Zero and Macro. I wouldn’t say they are copies of Superhuman, because they don’t approach email in the same way. Inbox Zero is more about having AI organize your email, apply rules, and prepare replies.

Maybe what you like about Superhuman is how fast you can work in the client. Adding an AI assistant to your inbox isn’t the same thing as replacing that client. But like I shared in a previous article, I don’t think we have to focus on speed of AI inference if we can have something working in the background and having results ready when you arrive

I would look at these projects if I wanted to change how the assistant sorts or processes email. But check the license and the self-hosting conditions, especially if you are going to use it for a business.

And having the code on GitHub doesn’t mean the website has to be free. Inbox Zero has its code there and also sells hosted plans.

16. Notion and Notion AI

Notion is an application for storing your documents and storing them as databases. They have other AI features in order to interact with your documents.

AppFlowy is an open-source alternative. AFFiNE also combines documents with a canvas.

Your team may already have a lot of information in Notion. That can be a reason to stay. I think this data makes it difficult to move to a competitor.

I would check the alternatives to control the workspace and choose where to host it. A tool that looked good five or ten years ago may no longer be the best choice.

17. Linear and Jira

Linear and Jira are for tracking issues and projects. They also help teams decide what to do next.

Plane, OpenProject, and Taiga are open-source alternatives. Plane has issues and cycles. OpenProject covers broader project plans. It is also older, and I think its interface looks worse. Taiga has agile backlogs and boards.

If your team already uses Linear or Jira, you’ll probably stay to avoid disrupting the work of people. A move can add work without solving any particular problem.

However, if you don’t have any of these tools now and you want to have an issue tracker, I’d start with an open-source one. For AI features, you can work separately because regardless if you have local Markdown files or if you have something hosted in a cloud, you can just have an MCP or a CLI in order to connect to it and use your regular AI agent with that information.

I also use Beads for task management. The different UIs built around Beads offer another way to manage this work.

18. Slack

Slack combines team conversations, shared information, and connections to other tools.

Zulip is an open-source alternative. You can also check Mattermost and Rocket.Chat for team communication.

If your team and its contacts already use Slack, that is a reason to keep it. People must use a communication tool for it to help them.

Or check alternatives, primarily if you don’t have yet any reads, because probably there is no huge advantage of it that saving some money.

19. Airtable

Airtable organizes structured information in tables and different views. People can build workflows around this data.

APITable is an open-source alternative for visual databases. AFFiNE also describes itself as an Airtable alternative.

Your team may depend on Airtable’s interfaces, automations, and integrations. If you have data and automated word word reader, that can be a resource of state.

I would check APITable to host the workspace myself or build tools with its API.

These alternatives replace the main application. But someone has to pay the bill of the AI, so if you’re using an open source alternative, you’ll have to bring your AI mother provider. Check whether each alternative supports the work you need to do.

Conclusion

I keep seeing all the time people who are saying that they’re cancelling their subscriptions to traditional software as a service and they are building their own tools. They can save a lot of money with that.

However, software engineers have always had that option to build their own tools, but they decided to pay. Because it was cheaper to pay than to build it yourself. You may still consider that it is better to pay for a tool rather than having to build the tool yourself, even if you have AI now.

But what if you can have the best of both worlds? You don’t have to build the tool yourself because someone already built it. And at the same time, you have the customizability to fork it and implement your own details. You can self-host it instead of having to pay someone crazy amounts of money.

That’s the real benefit of open source for individuals like you or me. I have installed quite a few of these tools the moment that I discovered them while writing this post. So I hope that it was as useful to you as it was to me.

That’s everything for today. See you in the next article.

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

Today’s article supports phase three: use the time you’ve regained to build and adapt tools that strengthen your engineering skills. Choosing an open-source alternative gives you a practical place to start.

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

Subscribe now

🗞️ Other articles people like

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

Software engineers have a great career opportunity in front of them.

Being the one who knows about AI in your org is a great role, much better than being the one who knows about any other technology. This career edge doesn’t come from “innovating” or discovering anything new. It comes from noticing that something already works outside your company, then making it safe and useful inside your team.

You don’t need a PhD in AI for this. You just have to be a couple of weeks ahead of your peers.

The public debate is obsessed with frontier models, coding agents, benchmark scores, and whether AI will replace developers. You will be the one who realizes that inside a normal engineering org, the more practical question is which recurring task can you improve this sprint, prove with real artifacts, and turn into a workflow other engineers can copy.

The edge for software engineers is adoption, not invention

Most companies are already full of engineers using AI both at work and in their personal lives. They use it to explain code, draft messages, summarize docs, generate tests, and review their decisions. But this usage does not automatically become team impact.

The gap appears when one engineer turns a private trick into a shared process. You can start simple with a prompt in your notes that helps you with a recurring process. The gap for most engineers is moving from personal productivity to engineering leadership.

This is why the “2-week edge” I talked about matters. You do not need to be years ahead of the industry. You need to be slightly ahead of your local environment, then translate that lead into something your team can trust. When an AI term becomes mainstream, you’ll have already introduced a proven process in your team.

Start with the work nobody wants to write

The best AI workflow to start is usually not code generation. Code changes have too much hidden context, too much review burden, and too much risk when the author does not understand the output. There’s a reason why software engineers have been very well paid.

So start with the artifacts around the code. PR descriptions, design doc drafts, incident timelines, migration updates, test plans, on-call handoffs, and stakeholder summaries are better first targets. They are frequent, annoying, easy to compare, and safe to review.

Since the very first team I’ve worked on I’ve heard the same complains from engineers: “We have too much meetings”, “we are writing too many docs”, “we don’t have visibility on priorities”. These aren’t complaints about writing code. They are about everything else around the code. So you have a big opportunity in there.

Sending meeting notes takes minutes. A bug in prod can create a huge effort for the next few months. That difference matters. Only after you get used to working with AI for these first workflows, only after you prove to your leadership that you can create value with AI, you can jump into the difficult problem of setting a coding standard with AI.

The simplest test is to take something from last week that humans did manually, or something that was semi-automated. Use a real meeting or a real doc. Try your AI-assisted workflow against it, then compare the new output with the artifact your team actually used. If the new version is clearer, faster, or easier to review, you have evidence. Start getting these small wins.

Subscribe now

The workflow is the work artifact

When I’m interviewing candidates, and I ask about their use of AI, I see a pattern across many of them. Saying “I’ve heard about Claude” or saying “I ask Claude to create agents and figure out” is the same. It tells which tool you opened, but it does not show judgment, repeatability, or team value. Everybody can use AI tools at the user level. We’re looking to become power users.

The workflow is an artifact for your promotion or your next interview. It should explain the task, the input, the expected output, the review rule, and the boundary where the human takes over. With those pieces, you have something a teammate can run without you. You moved from personal productivity to a team impact.

For example, an engineer can use AI to generate PR descriptions. You just have to ask your AI, and it will generate something. The useful part is setting it automated, connecting the necessary tools for context, and having evals that catch regressions.

Those guardrails are where engineering judgment appears. AI is just another technology where we have to apply our engineering judgment. It’s not enough to “just use it”.

Make the before-and-after impossible to ignore

Don’t pitch AI adoption with hype. Show the old artifact vs the new artifact.

Imagine you come and say in a team meeting:

Read more

Subscribe now

Read more

So engineers try to become available for everything.

They add more tools to the resume, accept more vague job searches, and describe themselves as full-stack, AI-native, product-minded builders who can jump into whatever the company needs.

I understand the instinct. When the market feels uncertain, flexibility feels safe. If you need the job, you’ll jump into anything.

But what most engineers need is not more flexibility. It is more direction.

To reset your software engineering career, stop presenting yourself as someone who can do anything. Choose a clearer engineering lane, rebuild depth in that lane, and create visible proof that makes your next direction obvious.

AI can help, but only if you use it to sharpen your judgment instead of hiding the lack of it.

AI makes some engineering work faster, but it also makes vague career identities weaker.

In this post, you’ll learn

• How to reset your software engineering career without starting from zero.

• How to choose an engineering specialization in the AI era.

• Why “builder” roles can confuse software engineers instead of clarifying their path.

• How to use AI for career growth without outsourcing technical judgment.

• How to create visible proof of your engineering direction.

Why Software Engineers Feel So Lost Right Now

Software engineers are not only worried about finding work. Many are worried about what kind of engineer they are supposed to become.

The advice keeps shifting. Become an AI engineer. Become a product-minded builder. Join smaller pods. Use agents. Own more of the product. Work across disciplines.

Meta has reportedly experimented with “AI builder” titles and AI-native pods, and Business Insider also reported Meta goals around AI tool adoption and agent-assisted code. LinkedIn has discussed AI-powered “full-stack builders”. Reuters reported that Amazon tested replacing some traditional product titles in Ring and Blink with generic “builder” labels (I work in Ring, you can just check the job titles in the open positions).

Companies want people who can use AI, work across boundaries, and ship with less coordination overhead. That signal is worth noticing.

It is not enough to become your personal career strategy.

A company can rename roles because it wants a flatter org. You still need a story that explains your level, taste, scope, and technical depth. If everyone is called a builder, your own identity has to become more precise, not less.

The dangerous response is to become vague. You can be a builder, but you still have to go deep into something and become the “go-to“ person for something. I know who I would ask when it comes to security. I know who I would ask about frontend. Even if we are all “builders“

Do not let a corporate reorg become your career identity.

Read more about how AI can make developers worse when they ship faster without understanding the work:

Stop Applying To Software Engineering Jobs Just Because They Mention Code

Broadly applying is sometimes necessary. If you need a job now, survival comes first.

The problem starts when broad applying becomes your career strategy. Every role you chase teaches you what identity you are willing to accept. A React developer today. DevOps engineer tomorrow. AI automation person next month. After a while, your resume stops looking flexible and starts looking accidental.

The better filter is simple:

Would this job make my future self more coherent?

That question changes how you read job descriptions. You can deliver good work in a new role and still be strategically bad for your career.

I would rather see an engineer apply to fewer roles where their profile makes immediate sense than hundreds where they look like a partial fit. This career reset means you leave panic aside and create a strategy.

Choose The Engineering Lane You Want To Be Known For

“Software engineer” is too broad to guide decisions in a noisy market. It is a job family, not a career identity. Making everyone that works at tech a “builder“ makes that matter worse.

A useful lane combines three things:

Read more