Subscribe now

I finished reading a book called Scarcity Brain.

Long story short, it starts with why slot machines are addictive and all the other areas in life where the same pattern makes us addicted to something.

Knowing those rules serves 2 purposes

1. Breaking bad habits

2. Building new good habits

I decided to apply them to the second point, so I asked myself: How do I become addicted to coding?

What are the rules to become addicted

The book defines a scarcity loop that keeps us addicted. The rules are 3:

1. Opportunity: The action is available to you, without friction. Slot machines are available in many restaurants and bars, not only in casinos

2. Unpredictable reward: Doing the actions doesn’t guarantee results, but you also have some results. That’s why there’s more than 1 winner in any lottery game, and why slot machines don’t give only 1 big prize, but many smaller prizes.

3. Quick repetition: You can repeat fast. That’s why slot machines were made digital, because pressing a button and slots in a screen was faster than pulling a bar and physical reels.

Now coding already had ingredients to get addicted to coding, but AI just added steroids to it:

1. Opportunity: Anyone with a computer could code, but you had to learn a bit about it. Now AI writes code from natural language, and you can even send prompts from your phone.

Friction is smaller now. You can start an iteration of the Scarcity loop with a quick prompt and go to sleep, or go commute to work, and the next phase of the loop will be ready for you.

2. Unpredictable reward: Sending a build command didn’t guarantee the code would compile. You may find bugs, or it may work; it’s a bit unpredictable. Now AI makes the results of a prompt unpredictable too, so you want to see if the prompt results were good and if the code will work as expected

That “maybe” hooks us addicted to sending the next prompt. Especially when it looks like this time will be the right one, but it’s not.

3. Quick repetition: The write-build-verify loop of coding was tedious, and any small productivity trick that tightened the feedback loop was a huge productivity win and made coding feel better. Now with AI you can run many more feedback loops in parallel, making the limit your AI usage limits and your wallet.

We can even queue prompts one after another, or scale horizontally with more agents working in parallel that will do the work and provide us the results.

You can get addicted to AI coding because it turns a difficult problem into a fast sequence of uncertain but potentially valuable results

Create your own loop for software coding

First, we have to create the opportunity.

Choose a real problem with a visible outcome. Don’t build for the sake of building, but break down the work into milestones.

The same way agile methodologies aim for working software and a visible outcome from each ticket, you want something visible for each agent session.

Then, we have to create rewards.

Besides the predictable rewards of advancing in your plan, you want unpredictable rewards provided by AI.

All AI outputs are unpredictable rewards. Discovering all the alternative solutions to solve a problem and picking one is a reward from a design session. Finishing the code implementation and launching your software to test if it works as expected is another unpredictable reward

Finally, we have to make repetition fast.

Coding experiences with fast models like Cursor with Composer is one alternative. You just stay in that session iterating rapidly with AI. But if you’re using models that take around 15 minutes per prompt, you’ll want to have multiple agents working.

To have many agents working without switching from one to another all the time, you have to give them permissions and teach them to do many steps, like running the builds and tests, inspecting logs, iterating, etc.

Fast repetition doesn’t mean switching from one agent to another for small internal steps. The real feedback loop is running our software and testing if it works or not. The faster we can make that iteration, the more addicted we become to working on it.

Don’t code for the sake of coding

A great power comes with a great responsibility.

Now that you’re becoming addicted to coding, you should know that “tokenmaxxing” (wasting tokens without any real outcome) is not the point of this article.

This is about getting you to code and to enjoy coding. But coding some software you don’t even want to use is useless.

Instead, you need to define your goals, and once you’ve met them, you should define what’s “enough”

There’s right answer is not about coding more or less. It’s about what’s enough to meet your goals.

So at the beginning of each coding session, write the 3 things you need to achieve. Don’t add more features to your software because htey are cheap to build now. Prioritize them.

AI is very good at generating artifacts, and this creates another problem.

We may think we are getting “more throughput” because we generate more PRs or more docs, but the reality is that we are decreasing our real delivery throughput compared to using AI correctly.

This is a loss disguised as a win. If you create more review work, more future rework, and more on-call problems for a feature that people don’t use, then that was not a win, even if it looks like it at the beginning.

Conclusion

We’ve learned the 3 rules to become addicted to anything, and we’ve applied them to coding.

AI makes coding more addictive by design, but if you’re procrastinating when you start coding, then apply the 3 rules:

1. Create opportunities to code more often, and remove opportunities to distract yourself with anything else

2. Surprise yourself with the alternatives that AI proposes that you would have never thought of yourself

3. Launch agents in parallel to constantly trigger new iterations of the loop that keeps you hooked on coding.

Happy coding!

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 will allow you to move faster through the phases of our system to become productive engineers and get promoted faster

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

Subscribe now

🗞️ Other articles people like

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

Some time ago I wrote about how I was able to merge 100+ PRs a month.

Those were mostly config changes in JSON, so you could argue that you can’t compare config changes with code. Well, now I reached the same throughput with code. It was just a matter of time.

But while AI has automated most of the manual steps that I had to take, my own understanding of the process is becoming more and more a black box.

No problem when things work well, and I have working code as an output. But it’s a problem when I want to optimize this system. I can’t optimize what I don’t understand.

In this article we’ll see how to increase our throughput without becoming a dumb proxy between requirements and prompts.

AI increases output but reduces your capability

Before AI, if I picked a task, I had to do things like

1. Explore the surrounding code

2. Create a plan to implement, at least in my head

3. Implement it, running the unit tests and iterating as needed

4. Deploy it to do some testing and attach the proof of testing to my PR

5. Raise the PR

6. Iterate, addressing any comments

Now AI does mostly all of this. I just point it to which task to implement, define the goal, and AI does all the other things.

But in the process of asking AI to do things, I lose visibility and understanding of the process. Is AI making a plan first, spotting gaps, and then implementing? Or is the AI implementing, then realizing it doesn’t work as expected, and course-correcting?

This may seem irrelevant if the end result is working code. But we know as software engineers that the ends never justify the means. Bad code, a bad process, and you’ll suffer from it when maintaining production code later.

The same way we have a metric for PRs raised, tickets closed, or story points delivered, we should have a metric for our level of understanding and our level of expertise as software engineers.

Your job is to operate at two levels

It’s a paradox that the same person has to oversee the process and stay very high-level to achieve high throughput, but also dive deep into the low-level details and tweak the process to optimize it. That single person in both sides of the process is you.

You definitely need to define the goal and constraints, and be on top of the architecture. But you should also optimize to make sure the agents follow a process that leads to no confusion. So how do we maintain our ability zoom-in and zoom-out in the software development process?

Let me tell you how I handled it in the last project that I worked on.

Every AI workflow that I’ve built starts from the inside. I start by building an agent/skill to deploy and verify. Another one to raise a code review. Another one to handle the implementation with the constraints of the project... Step by step, I’m removing myself from the low-level details, and a bigger part of the process is handled by AI.

The key for me is iteration. On the first attempt, I don’t try to make AI handle the end-to-end. It just happens over time.

If you follow these steps, the important part is always being aware of the high-level of the project. This is what good Senior engineers are able to do. They can implement but maintain a 10,000-foot view of the project.

After some time, you’ll face the opposite problem. It’s been months since you had to run the build yourself, but lately, for some reason, the agent is looping too much in build failures.

This is something that also happened before AI in software engineering. You don’t look into working code while it’s working. So rather than brute-forcing the AI into finding a solution, I’d recommend working in steps:

1. Isolate the part to optimize. Don’t ask AI to handle the end-to-end. Instead handle up to that part, and also after that part

2. Slow down and read. We’ve done this all the time. The stack traces and error logs are where we start investigating failures.

3. Figure out what’s wrong, and generalize it to update your agent/skills

Chances are that you find a failure that is trivial for you, because you’re an experienced engineer, but it was not obvious to AI. This is the most common failure scenario: We ask the AI to do things, but we don’t realize the AI can’t read our minds.

The good news is that AI can self-update agents and skills. You don’t need to write the markdown by hand, but just inspect the end-result.

Build the software engineering equivalent of 10,000 daily steps

There were no gyms thousands of years ago. The gym is the consequence of us moving less in our day-to-day.

We are in a moment in history where we could think less than ever. I’m not saying this is good, quite the opposite, but it’s the reality. Nowadays, people can delegate all decisions, all understanding, and all actions to AI

Even if you think this is not your case, you’re reading this article, so you’re better than the average developer... you’re also experiencing, to some degree, the atrophy of the brain.

Many people try to walk 10k steps per day as a baseline of activity. We now need an equivalent for our brain.

If you’re already having some goals for your fitness and health, let’s also add some goals for your brain health:

1. Read every day. Ideally, some technical material in the context of becoming a better software engineer, but any reading, including reading a novel, will make your brain focus on one thing and achieve a deeper level of focus than if you’re switching between agents.

2. Define the problem in depth upfront without help. This is not about ignoring AI, but for AI to work well, it’s better if you have a good definition of the problem and constraints. You can work in a whiteboard with peers or just write down all the context yourself to send it to AI for review.

3. Run periodic system audits. Even if you see the code reviews flowing, from time to time it’s good to review what the process is once again. It may have been months since you implemented some parts of it into an agent/skill, so refreshing your mind is always good. You may find optimizations that you wouldn’t do otherwise.

For the first brain goal, reading this newsletter is already a good one. Make sure to subscribe to access all the techniques and systems

Subscribe now

Conclusion: Automate the manual work, not the understanding

I don’t know how things are going in your company, but I see the leadership at Amazon pushing all the time for AI adoption and removing ourselves from the process.

Yet we have to own it. We have to explain it to other teams. We can’t afford to wait for an AI agent to finish to give an answer in a meeting.

With the ideas from this article, you’ll be able to zoom-in and zoom-out, you’ll preserve your engineering skills while delivering faster than ever. Thanks to your in-depth understanding, not only will you deliver faster, but you’ll deliver at higher quality.

Now let me ask you: What will be your brain goal, the equivalent to the 10k daily steps but for your brain?

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

AI is already helping you to save time (phase 2). Today’s article will allow you to do the things that make you grow and create evidence that you can work at the next level, making progress toward your promotion

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

Subscribe now

🗞️ Other articles people like

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

Subscribe now

Read more

Agents have the same problem. When they forget something, lose the thread, or start making strange decisions after a long session, our instinct is to ask for a bigger context window. If the model could see more code, more logs, more everything, then maybe it would behave better. And often it does. But context is not intelligence. Context is closer to working memory. In the same way we have memory leaks, we can have context leaks. Context is where current computation happens. It is not where the whole system should live.

Context Is Working Memory

This is why “just give it more context” feels right and still fails. A prompt full of requirements, logs, design notes, failed attempts, tool output, meeting context, preferences, and old chat history is like a process with a bloated working set. Everything is technically available, but relevance gets harder. The agent may remember a stale decision, miss the current constraint, or treat a temporary workaround as truth. The problem is that it has too much information in the wrong place. It may have the wrong information

I have noticed this in my own use of agents. The best sessions are not the ones where I paste the most context. They are the ones where the current task is small enough that the relevant context is obvious. “Look at these three files and explain the failure.” “Given this plan, implement only this part.” These prompts are not big or complex. They do not look like an “uber-agent” that replaces software engineers. But they work because the agent does not have to search through irrelevant material before doing the next useful thing.

This is also how good software systems work. We do not process a large dataset by loading the whole database into RAM and hoping the machine survives. We stream. We paginate. We index. We cache. We keep durable data in durable places with many 9s and load only what we need for the current operation. The trick is not merely having memory. The trick is having the right boundaries between memory, storage, indexes, logs, state, and temporary buffers.

Agents need the same boundaries. The prompt is the working set. Source control, tests, issues, and docs are durable truth. Persistent memory should contain selected facts worth reloading, not every thought the agent ever had. State should tell the agent where the workflow is. Scratch notes and tool output should expire. If everything goes into the same bucket, the system becomes harder to reason about. It is the AI version of an invisible global state.

Persistent memory is especially tempting because forgetting is annoying. We want the agent to remember our preferences, our codebase conventions, the architecture decisions we already explained, and the mistakes it made last time. That is reasonable. But memory that remembers too much becomes dangerous. A stale decision can be applied with confidence for months. A temporary workaround can become a permanent assumption. A private piece of context can leak into a task where it does not belong.

The goal is not an agent that remembers everything. The goal is an agent that can cheaply reload the right thing.

Divide And Conquer The Working Set

Read more

Not in the “AI suggested a for loop” way. I mean, implementation agents, document curation agents, or code review automation. I add AI to all areas of my work as a software engineer.

At Amazon, I am in the top 250-ish usage worldwide of kiro-cli, Amazon’s equivalent to Claude Code or Codex CLI. I regularly go above the monthly limits if I were an external user on the highest plan. It saves me time repeatedly because I have turned individual prompts into workflows that execute periodically for my individual work and my team's projects.

Read more

One developer can generate a pull request in minutes.

One security researcher can generate a scary vulnerability report in minutes.

One person can open an issue, write a reproduction that looks technical, add a long explanation, and make it sound serious enough that a maintainer has to stop and look.

But the maintainer may need hours to verify it.

That is the part AI did not automate away.

Read more

We know when a service is slow. We know when an endpoint fails. We know when CPU, memory, or latency crosses a threshold.

But we often have no idea where our own time went.

Get the guide to build your first AI agent directly in your inbox on newsletter signup:

Subscribe now

I had that problem for years. I would finish the week feeling busy, but when I tried to name what I had actually accomplished, the answer was vague. Some meetings. Some Slack. Some coding. Some review. A lot of context switching.

That is not a discipline problem. It is an observability problem.

A few years ago, I saw Rob Dyrdek explain how he runs his life in 15-minute color-coded blocks. It looked obsessive. It also looked useful. So I built my own version.

The system worked when I used it.

The problem was that I often did not use it.

Manual time tracking fails because it asks you to interrupt your work in order to measure your work. So I moved the logging into the AI agent I already use to manage my tasks.

I’m already using AI all the time for work. I just have to type, “I’m switching to code review,” and the agent closes the previous block, creates a new one, applies the right tags, and updates Google Calendar.

The calendar becomes a log of reality, not a plan I abandoned by Tuesday.

This article is the second post in my Build a Productivity Agent series:

• Post 1 - Tasks: Creating a personal backlog to track all your work, both for planning ahead and for reflecting in a retrospective.

• Post 2 - Calendar: Turning Google Calendar into an AI-powered time tracking system.

• Post 3 - Notes: Conversationally save and retrieve knowledge with a notes backend.

• Post 4 - Email: Manage your most important information stream, the email.

• Post 5 - Quick capture and review day automation: Make this agent an extension of your brain and create a tight feedback loop with weekly reviews.

In this post, you’ll learn

This is not a generic time management post. It is a technical system for turning your calendar into a productivity database controlled by an AI agent.

• How AI time tracking reduces the friction that makes manual time logs fail

• How to build an AI calendar agent that creates, closes, and tags Google Calendar blocks

• How calendar observability shows where your week actually goes

• How to use a two-tag calendar system for work, life, meetings, study, exercise, chores, and review

• How the downloadable Calendar Skill turns natural language into repeatable calendar actions

Your week needs observability

A production system without observability fails silently.

Your week does the same.

Meetings expand. Deep work disappears. Learning blocks get postponed. Social media leaks through the cracks. You reach Friday with the feeling that you were busy, but no clean answer to the question, “What actually happened?”

Without logs, you call it a busy week. With logs, you see the failure mode.

That is why calendar observability is a better framing than time tracking. Time tracking sounds like a quantified-self hobby. Calendar observability sounds like what it is: a system that helps you inspect reality before you make decisions.

The point is not to become a robot. The point is to stop guessing. If my calendar says I spent 22 hours in meetings and 4 hours in focused work, I do not need a productivity quote. I need to redesign my week.

Subscribe now

How an AI calendar agent changes time tracking

Here is what manual calendar tracking used to look like for me:

Before:

1. Open Google Calendar.
2. Create a block.
3. Choose a title.
4. Estimate the start time.
5. Guess the end time.
6. Add tags manually.
7. Repeat several times per day.

And here is what the AI calendar agent does now:

After:

1. Me: "I'm switching to code review."

Agent:
- closes the previous block at the current timestamp
- creates a new block titled "Code review"
- adds my code review tags: [#w] [#r]
- stores it in Google Calendar
- confirms the switch in one sentence

This is the whole value. The agent does not make time tracking magical. It makes it cheap enough to survive a real workday.

I still have to tell the agent when I switch context. That is the obvious objection, and it is fair. The difference is that I no longer maintain the calendar. I do not choose times, tags, colors, titles, or durations. I just narrate the transition in the tool I already use. That small distinction is the difference between a system I abandon and a system that survives real work.

This is like having an Executive Assistant that does the busywork for me.

Subscribe now

Why manual time tracking fails for software engineers

There are three failure modes I kept hitting.

Failure mode 1: Friction at the wrong moment. You work 90 focused minutes on a feature, forget to start a timer, and now there is nothing accurate to log. One skip becomes two. Two become the new normal.

Failure mode 2: Data goes stale faster than you expect. You log Monday and Tuesday. By Thursday, the log is built from memory instead of reality. You stop trusting it, so you stop looking at it.

Failure mode 3: Raw data has no signal. “I worked 8 hours” tells you almost nothing. Were those hours deep work, meetings, review, study, admin, or scattered context switching?

The common thread is not laziness. The common thread is that the system depends on manual calendar maintenance. Most time tracking is repetitive enough for an agent to handle.

Read more about how top software engineers structure their day for deep work and focus

What a useful AI time tracking system needs

A good AI time tracking system needs three things.

First, it needs zero-friction logging. “I’m switching to email” has to be a complete command. The agent handles the timestamp, closes the previous block, and opens the new one. I should not need to open a timer app, switch tabs, or clean up Google Calendar later.

Second, it needs automatic tagging. Raw calendar blocks are not enough. I need to know whether time went to work or life, and whether the block was a task, meeting, review, study, exercise, entertainment, or chores.

Third, it needs actionable reporting. The right question is not “how many hours did I work?” The better question is “how much of my work time was focused, how much was meetings, and did I protect any learning time?”

This is where an agent fits better than a dashboard. I do not want to maintain another app. I want to ask questions in natural language and get answers from the calendar I already use.

Subscribe now

The two-tag calendar system that turns blocks into data

Every calendar block gets two tags.

The first tag is the area:

• [#w] for work

• [#l] for life

The second tag is the activity type:

• [#t] for a focused task

• [#m] for meeting

• [#r] for review

• [#e] for entertainment

• [#st] for study

• [#ex] for exercise

• [#ch] for chores or admin

This two-tag model is the difference between a pretty calendar and useful data. One tag tells me volume. Two tags tell me quality.

For example, [#w] [#m] is work meeting time. [#w] [#t] is focused work. [#l] [#ex] is exercise. [#l] [#e] is entertainment. The agent infers both from what I say.

“Starting a code review” maps to [#w] [#r]. “Joining standup” maps to [#w] [#m]. “Going for a run” maps to [#l] [#ex]. “Reading a technical book” maps to [#l] [#st].

At the end of the week, I can ask the agent for time by tag. That gives me the information to know how much my actual week deviated from my ideal week.

Subscribe now

What my calendar data revealed after tracking my week

This is the part that made the system stick.

My calendar showed me I am a morning person before I fully admitted it. Longer, unbroken blocks consistently produced better work than short, scattered ones. After lunch, my attention drops, so I now schedule code reviews, email, and admin in that window instead of pretending every hour is equal.

The data also showed me that learning blocks are mostly fictional unless they are on the calendar. I wanted to study more, but wanting did not create the time. Scheduling did.

The same thing happened with code reviews. They do not happen reliably unless I put them in the week. I now have a recurring [#w] [#r] review block timed with my team’s rhythm, and the turnaround is much more consistent.

The most painful reveal was social media. Five or ten minutes at a time felt harmless. Tagged as [#l] [#e] and summed across the week, those checks became 3 to 5 hours. The point was not guilt. The point was finally seeing the number.

You can only sacrifice what you can see.

Read more about how to use the time waiting for AI output for deep work

The rest of this post covers the full GWS CLI setup, the tagging skill, and the downloadable Calendar Skill, which you can use in an agent like Claude Code, Cursor, or Codex. You can drop it in today and have the core loop running quickly. Paid subscribers also get Post 1’s task management skill. Together, they give you the start of a full productivity agent.

Read more

Subscribe now

Read more