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

Many engineers still use AI like a very fast intern sitting next to them.

They write a prompt. Wait. Read the answer. Add more context and re-run. Paste the error back and ask again.

At some point, the limiting factor is not the model. It is you sitting there as the person who keeps the agent alive, one message at a time.

This is what the new AI fancy word, Loop Engineering, is about

Loop engineering is the practice of designing AI systems that repeatedly find work, prompt agents, call tools, observe results, evaluate progress, remember state, and stop when a condition is met.

Instead of prompting every step yourself, you design the process that prompts the agent for you.

This changes your work. You’re not the entrepreneur operating the company, but designing systems for the company to work without you.

In this post, you’ll learn

• What loop engineering is and why it comes after prompt engineering and agentic engineering

• How loop engineering changes work

• The evolution from GPT-2 to today

• What a good AI agent loop needs

• Why human judgment still matters

What Is Loop Engineering?

Loop engineering is what happens when you stop treating AI as a chat window and start treating it as a recurring system.

We started telling AI, “Do this thing.”

Nowadays, most people tell, “Do this thing, use the tools, inspect the result, and continue.”

A loop says, “Every morning, check this source of work. Run certain actions. Verify the result. Write down what happened. Escalate anything ambiguous.”

• Prompt engineering optimizes the instruction.

• Agentic engineering gives the model hands and tools.

• Loop engineering designs the machine that keeps those hands working.

This is why Addy Osmani’s framing in his blog clicked for so many engineers. The job is moving from prompting the agent to designing the system that prompts the agent.

I had agents who could review CRs and address comments. But I was still starting the workflow and gluing the system together.

At that point, the next productivity gain was obvious. Remove myself from the start button and frontload the work with AI so I just review the result.

The Pattern Behind Loop Engineering: More AI Work Per Human Input

The evolution of LLMs is usually described as “models got smarter.” We see it all the time, a lab releases a new model, the most shared screenshot is the table of benchmarks.

This isn’t what’s most useful for engineers.

Our real benefit is getting more AI work from the same amount of human input.

This is the timeline and where Loop Engineering fits:

Phase 1: Base LLMs Were One Prompt, One Answer

The first useful pattern was simple request-response. You wrote a prompt. The model predicted the continuation. You read the answer.

This was the GPT-2 era. The model was impressive because it could generate coherent text from raw input without task-specific training. But the unit of work was tiny.

One human prompt. One model response.

The model generated text. The human operated the workflow.

Phase 2: Reasoning Models Added More Compute Behind One Prompt

The next shift was not only bigger models. It was models that spent more compute at inference time.

With reasoning models, the interface is hte same. But the model now does more work before responding. It can break down the problem internally, evaluate options, and spend more tokens on hard tasks.

Still, the human remained the operator.

You had to decide the next prompt.

Phase 3: Agentic Engineering Turned One Prompt Into Many Actions

Agents changed the shape of the work. The model stopped being only a text generator and became a decision-maker inside a runtime.

It could inspect files, search the codebase, run commands, and try again.

One prompt became many actions.

And we could design different agents for different jobs: An agent to implement, and an agent for code review, etc.

But the work done was still limited to one task, the one we indicated in the input text

A useful next step is my breakdown of how I moved from manual prompting to autonomous agents that handle tickets, code, and reviews:

Phase 4: Loop Engineering Turns One Design Into Many Agent Runs

Loop engineering starts when you stop launching the workflow by hand.

Instead of saying, “Agent, implement this ticket,” you define the system

That is the loop.

For example, imagine a loop that runs every morning: It checks the backlog, filters ready tickets, sends one to a developer agent, validates the change, opens a PR, and writes back to the ticket. If the requirements are vague, it asks for clarification instead of guessing.

The important part is not that the agent can do one ticket. The important part is that the system can keep finding the next ticket without you sitting there.

This is why loop engineering feels different from agentic engineering. An agent is a worker. A loop is the workflow that decides when the worker should act.

That is also why loops need memory. A single model run forgets. A loop needs a place outside the conversation to store what happened.

Your role as a human isn’t anymore to input every unit of work, but to create an input once for the system, and the system will run that input in each unit of work. You still have to review a final output, but you will find the output without having written an input for this unit of work.

Read more about how harness engineering uses guardrails, state, and feedback loops to make AI coding agents reliable:

How To Start With Loop Engineering Without Breaking Everything

The best way I found to build loops is the same way I built my agents: do the work manually first.

You cannot automate what you cannot describe. So pick one boring workflow your team already does often, for example, Ticket triage. Do that work yourself a few times and write down the decisions you make without noticing.

Then automate the smallest useful version with an agent that does all the steps with one of your inputs: “Triage ticket JIRA-1234 and write the output in a comment in the ticket itself“

Only after you’re happy with its output, you add the loop. Then you have a system that works without you on jira tickets.

The human is left for higher leverage work.

This connects with my three-level AI productivity framework, where the real leverage comes from improving the system around the agent, not only the prompt inside it:

Conclusion: Build The Loop, Stay The Engineer

At some point, the best AI skill was to write better prompts.

Then it became about giving agents better tools.

Now the skill is moving again.

Now it’s all about designing loops: recurring systems that find work, run agents, verify progress, remember state, and stop when they should.

Think about the era before AI. As engineers, we were not only operating the system by coding tickets and reviewing PRs.

We were setting shared templates for technical designs, quality criteria checklist for PRs, and setting up tools like linters and formatters in our code.

Loop engineering is all about applying engineering principles to AI.

You are not replaced.

You become the person designing the system.

If you want to go deeper, I’d recommend following these 10-step guide to create your first Agent in a Loop

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

The wrong question after the layoffs news is, “Am I good enough?”

That is the impostor syndrome question. It feels personal, but it is often the least useful way to understand what just happened.

You can be good and still be laid off.

Your work can be solid. But then the company moves the budget, shuts down a product, or decides your entire area no longer fits the strategy.

That does not prove you were an impostor. It proves your career risk was attached to something bigger than your performance.

The better question is not “Am I good enough?” It is “Is my work still attached to something the company wants to fund?”

A layoff-proof career strategy is not about becoming impossible to fire. It’s not about becoming a knowledge silo so people don’t fire you. The people who will fire you aren’t the people working with you directly.

We can’t find a layoff-proof job. But we can build a robust career strategy to avoid layoffs.

In this post, you’ll learn

• How to build a layoff-proof career strategy

• Why tech layoffs keep happening

• How to show measurable software engineering impact

• What to do if your engineering team looks exposed

A layoff-proof career strategy is not about becoming irreplaceable

The first mistake is trying to become “irreplaceable.”

Companies do not protect engineers in a perfect ranking from best to worst. They protect funded priorities. Sometimes, the person who knows the old system best is tied to the exact area leadership wants to leave behind.

Your manager's liking of your work matters. Your team being better with you matters. But layoffs often happen above that conversation.

There are 3 scenarios:

1. Your entire org will be laid off

2. Your org will be partially laid off

3. Your org won’t be impacted by layoffs.

Being very useful in your team only matters in the second case. For the others, it’s more about where you work than how you work.

A resilient software engineering career takes care of both the outside (where you work) and the inside (how you work)

Layoff-proof does not mean immune. It means less fragile.

Why tech layoffs keep happening in waves

The lazy explanation is “AI is taking jobs.” It’s all over the news, but it’s not the whole story.

The better model is resource reallocation.

• COVID hiring created teams sized for demand that did not last in the same form.

• Higher interest rates made executives care more about margins, efficiency, and profitability.

• Hardware-heavy companies dealt with demand digestion after pandemic purchases.

• Then AI pulled money, attention, and talent toward a new strategic story.

That is why layoffs arrive in waves. They are often not one cause. They are budgeting, moving from yesterday’s plan to tomorrow’s priority.

Remember, it’s not about relocating people, but relocating money. I’m sure many companies would keep having many engineers while investing billions in AI hardware.

But money is a zero-sum game. If you spend it on one item, you can’t spend it on another.

This is why good engineers still get cut. A strong engineer can sit in the wrong org at the wrong time, attached to a product with shrinking executive attention.

Doing important work for your team does not always protect you

You protect yourself if you work in something that makes money. If someone in a budget meeting can clearly explain why your work matters, your position is stronger.

Read more about aligning your work with company priorities instead of just staying busy:

The three career risks hidden inside AI layoffs

AI layoff headlines have multiple risks in one single story.

If you think every AI layoff means “developers are being replaced,” you feel helpless. Why worry at all if AI will take over the world?

If you think none of it matters because a human with an LLM will still provide more value than the LLM by itself, you can do something.

I see three risks behind the layoffs headlines.

• Automation risk: The company says, “This workflow now needs fewer people.”
  
  And that’s true, I’ve automated an entire team’s work before AI. Watch for specific tasks being changed by AI and be the one who automates them. This way, you are not the one automated away, but the one who is providing value in the AI era for the company.

• Headcount compression: The company says, “We can do more without adding headcount.”
  
  You can watch for hiring slowing while the scope grows. In my team, we have doubled our services while having the same people. That’s also a way of headcount compression without having any layoffs. Your response is to show you can be the engineer who stays and handles 2x the load that you handled before.

• Narrative risk: The company says, “AI transformation requires restructuring.”
  
  I always watch for broad AI language (weasel words) without workflow detail. A lot of executives sell the AI promise without understanding AI at all. You should follow the money and see why something else became a priority over paying human workers.

The practical response depends on which risk you see.

The key is to prove yourself and prove your team so you’re not in the team that gets cut. And be judicious about your org’s health. Your leaders will tell you everything is great until you’re at the edge of the cliff. If you work at a public company, find the real numbers, find the memos from the leaders of the wider org.

Companies are changing what they evaluate faster than people re-skilling themselves.

Work closer to revenue, risk, or strategic priorities

If I wanted to reduce layoff exposure, I would first look at the budget map.

Which projects are newly funded? Which ones get executive reviews? Which incidents make leadership nervous?

I’ve worked in multiple orgs in projects that had executive attention. It’s never funny. Those people will create a lot of pressure on everyone around you, your closer managers will be pushy, and they will never accept your initila plan but try to compress it in half the time.

But during a reallocation cycle, that proximity matters.

This does not mean chasing a flashy AI project. Most of the time, the flashy project is just an experiment to see how far you can reach, but when it’s time to relocate resources, those experiments are killed. So focus on the boring project that is tied to a money-making machine. A boring migration in the payments system can be more protected than the flashy AI initiatives.

You can surely find a list of initiatives in your org. Once you have it, remove 20% of the initiatives, the 20% that seem less important

If your project is one that you’d remove, don’t panic. But stop treating the work as automatically safe. Try to finish it fast to move into something more valuable, or be selfish and look for moving into those higher-value areas.

Become visibly useful with AI, not just interested in AI

“Learn AI” is too vague to be career advice.

There are two useful paths. Go deep into AI systems, or become unusually effective at applying AI inside your current domain. The second path is the one that matters, it’s more practical for most software engineers (unless you’re doing research on AI, which is the minority of people reading this newsletter)

Your goal is to become the engineer who uses AI to write better docs, test risky changes, review AI-generated code, prototype faster, and debug faster, all without lowering standards.

I do not care if someone “played with agents” for a weekend. I care if they can show engineering standards applied to AI so that AI helps them in doing real engineering work.

AI has an adoption cost. The first parts of the learning curve feels bad because AI makes mistakes. It gives plausible answers. It writes code that works on the happy path and fails where the system is messy.

The strongest engineers have gone past those phases and started using AI instead of blindly delegating.

A useful next step is this breakdown of how to turn AI from a random code generator into a reliable teammate:

Build proof that your work creates leverage

During layoffs, invisible value is fragile value.

I have caught myself assuming good work explains itself. It does not.

Nobody is looking at you. You have to put your work in front of them.

And you can’t wait until a leader asks, “Which work matters most?” They won’t be asking you, they will be making the decision and later communicating it

You need proof before you think you need it.

A brag document should not read like a task log. “Implemented service X” is weak. It must link that action to business goals and to evaluation criteria for your role, showing you’re are a top performer

.

Many people got obsessed with the tokens leaderboards, to the point that companies removed them (see this article about Amazon removing it). The point wasn’t that you waste tokens. It’s about finding how to apply AI to your work to make it better

This also helps outside the company. In an interview, you’d apply the same linking between your actions and the business results and role guidelines. Your work is already done, but the perception of how valuable it is would be different depending on how you tell the story.

Do not wait for someone else to translate your engineering work into business evidence.

Read more about tracking achievements in a way that makes your impact easier to explain:

Conclusion: Your job can be cut, but your career can be designed

I do not like career advice that pretends you can outwork every market cycle.

It’s like selling an investment that always beats the market.

Sometimes you can do excellent work and still get caught in a company decision that was never really about you. That is not comforting, but it is clarifying.

Don’t wait for the layoff memo to find out whether your work still looks important.

You cannot make your job layoff-proof. You can make your career harder to break.

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

Subscribe now

Today’s article will allow you to do your work faster with AI, moving from phase 1 to phase 2. I’m building this system below for paid subscribers. Thanks for your continued support!

If you want to go deeper on building AI agents to help on your work, read this next:

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

That’s too large to be acceptable.

The code is there. The feature works. The tests pass.

It runs. What else is there to check?

AI tools don’t make developers lazy by force. They create conditions where laziness is the path of least resistance. The assumption that working code is good code.

Working is not the same as correct. Correct is not the same as maintainable. And AI is not in the room when the edge case hits production and someone has to dig in without a mental model of what was built.

I’ve been building software and working with engineering teams at Amazon for years. I know this. I also watch myself do it anyway. Once AI generates code that does what I asked, I don’t want to spend time inside it. The review feels like a chore.

That is exactly where the real bugs live. In the co…

Read more

Last week, I saw it at work. The doc looked fine on the surface. The structure was there. The sentences were clean. But when I read it carefully, I could feel something was off. The reasoning was shallow. The recommendations were generic. The parts that should have been hard were the ones that felt the easiest.

Something was missing.

Read more

That’s when something clicked. We used task-management apps when humans were executing tasks, but now we are delegating to agents. We need the same with AI agents. We need the agent to be the interface of a task management system.

Get the free AI Agent Building Blocks ebook when you subscribe:

Subscribe now

Now I never open an app anymore. I say, “Add this task, due Friday,” and the agent handles it. I say, “What do I have today?” and I get an answer in three seconds. No app. No clicking. No context-switching.

That’s what this post is about. This is Post 1 in a series on building an AI productivity agent, and I’m starting with task management for a good reason: tasks are the highest-frequency productivity action you take every day. It’s a low effort, high-reward situation. Once it’s working, you feel the shift right away.

Here’s what comes next in the series:

• Post 2: Calendar: adding a calendar and building the morning briefing from this post combines tasks and events in one message.

• Post 3: Notes: conversational save and retrieve your knowledge with a notes backend.

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

• Post 5: Quick Capture & 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:

• Why task systems fail (and why it’s not a discipline problem)

• What makes a task system actually work for an agent-driven workflow

• How the daily briefing replaces your morning app routine

• Why Beads is the right backend for an agent, and how to install it

• How to wire a skill file on top so the agent behaves like a real productivity partner

Why Task Systems Break (And It’s Not Your Fault)

There are three reasons task systems fail. None of them is about willpower.

The first is not trusting the system 100%.

You put some tasks in the app. You try to hold others in your head. You write a few on a sticky note on your monitor. This seems fine for a while. But partial trust equals no trust. Your brain is never fully offloaded to the system because it knows the system isn’t complete. Eventually, you stop using it.

The fix isn’t discipline. It’s reducing friction to zero. If adding a task takes ten seconds and many fields to fill, you’ll skip it. If it takes three seconds, you’ll capture everything.

The second is data getting stale.

Tasks pile up unchecked. You update something in your head, but never reflect it in the system. One day, you look at your task list and realize it’s fiction. It stopped being a real picture of your life weeks ago. This kills trust immediately and sends you right back to problem one.

Maintenance is the fix for this. But here’s the thing: nobody likes maintenance. It’s boring, and it adds friction. That’s fine, because now the agent does it.

The third is getting overwhelmed.

You open Todoist, you see 60 tasks staring at you, and analysis paralysis hits. You close the app and go check Twitter. This isn’t weakness. It’s a system design problem. The master list is not the right thing to look at. What you need is a daily list.

The common thread across all three failure modes is the same: friction and maintenance. These were human problems. Now they’re agent problems.

I wrote a bit more about how AI is increasing decision fatigue for software engineers in this article:

What an Agent-Driven Task System Needs

Those three failure modes map cleanly to what an agent needs to do its job. There are three non-negotiable properties.

Zero friction to add tasks.

Every extra click is a task that never gets captured. An agent conversation takes three seconds: “Add buy milk, tonight.” Compare that to unlocking your phone, finding the app, tapping add, typing the task, setting the date, and confirming. That flow is seven steps. Three seconds versus thirty. You’ll capture far more in three seconds.

The agent can add a task itself even when you’re not asking for adding a task explicitly. This is the first article of a wider productivity agent, so this will make sense once the agent is completed.

Organized by context, not chaos.

Work tasks, personal tasks, and grocery lists cannot live in one flat list. You need projects and sections. The agent needs to know where to route things. “Add this to the Work project” is a complete instruction. Without structure, the whole system collapses into noise.

Views that match how you actually think. “

What do I have today?” The agent answers this without you opening anything. “What’s coming up this week?” Same. “Do I have anything due before Thursday?” Now that’s a query no app UI does well. But an agent runs it in one command and gives you the answer in plain English.

The AI Daily Briefing: Replace Your Morning App Routine

A hack for the overwhelm problem is a daily task list. Every morning, you’d write down only what he needed to do that day, either in a notebook or a quick note in any app. Then you’d work from that, not the backlog with all the tasks. The master list is for planning. The daily list is for doing.

I wrote about my 5-minute habit to follow this approach and roll up all my daily actions to the goals of my quarter in this article:

With an agent, you don’t even need to write the daily list. You ask for it.

“Give me today’s briefing” returns your tasks due today, filtered by priority. P0 items first, then P1, then P2. Grouped by project so you can see what’s work and what’s personal. No scrolling. No decision fatigue. No staring at 60 items, wondering where to start.

You never see the full master list unless you ask for it. The agent surfaces only what matters right now. This is the same principle I was using in my spreadsheet checklist, except the agent generates it automatically every morning before you’ve had your coffee.

The compound effect gets even better when you add a calendar, which is coming in Post 2 of this series. One query will surface both tasks and meetings. You’ll get a full morning briefing in one message: what’s on your plate, what’s on your calendar, and what to tackle first. But that starts here, with tasks.

Continuing below, we’ll see the step-by-step setup of Beads for the local task backend, wiring it to Claude Code (or Codex or any other agentic tool) with hooks and a skill file, the exact natural language commands your agent will understand, and a downloadable SKILL.md you can drop in your agent and use today.

Read more

While writing this post, the articles covering this list that I read focus on external-facing chatbots. I wrote this one to also consider all 10 risks in the AI workflows engineers are already running inside their companies. If you’re a developer using AI tools like Claude Code, Codex, or GitHub Copilot, not just someone building an AI product, this is written for you.

Read more

Here is how I used it to ship 100+ PRs/month at Amazon

Get the free AI Agent Building Blocks ebook when you subscribe:

Subscribe now

I’m Fran. I’m a software engineer at Amazon during the day, and I write and experiment with AI during the night.

I want to tell you about the moment I realized that prompting alone would never work for production AI agents.

I was working on an automation project at Amazon. The goal was simple: update large JSON configuration files automatically based on requirements. These configs were thousands of lines long, and the updates followed predictable patterns.

A perfect job for an AI agent, right? That’s what everyone thought. Engineers on the team opened their AI-powered IDE or CLI, typed their prompts to modify the JSONs, and watched the LLM struggle to modify the target node correctly.

It failed to implement the changes properly. Every single time.

The model wasn’t broken. We were on Opus 4.6 with a one-million context window.

The context window was a problem. When you feed multiple 10,000-line JSON files into an LLM, the model loses track of the surrounding structure. It edits what you asked it to edit, but it quietly breaks everything around it. No error message. No warning. Just a structurally invalid file that passes a surface-level glance but fails in production.

This is not a model quality problem. It is an environment problem. And the fix is not a better prompt.

You may think the fix is Anthropic to release a 10M context window, but we know that a bigger context window still degrades after 100k or 200k tokens.

The real fix is a harness.

Harness engineering is the discipline that turned my broken prototype at Amazon into a system that now ships over 100 PRs per month. Fully autonomous.

I wrote a 10-step guide to build that agent in this previous post:

In this post, you’ll learn

• What harness engineering is and how it differs from prompt engineering, context engineering, and agent engineering

• Why AI agents fail on large structured files like JSON, and how to fix it with deterministic scripts

• The four pillars of a production AI harness: state management, context architecture, guardrails, and entropy management

• How I built a harness at Amazon that ships 100+ PRs/month without human intervention

• The mindset shift that separates engineers who demo AI from engineers who deploy it

Why AI Agents Fail on Large Files

Most engineers today interact with AI coding tools the same way: open Cursor, Claude Code, or Codex, type a prompt, review the output, repeat. For small files and isolated tasks, this works beautifully. But the moment the problem involves a large amount of files, the whole approach falls apart.

Large Language Models are probabilistic engines. They predict the next token based on patterns in their context window. When the context window is filled with thousands of lines of structured data, the model’s attention gets diluted. It correctly identifies the node you want to modify, but it loses track of sibling keys, nested brackets, and structural integrity. The result is a file that looks right at the point of change but is broken somewhere else.

We have to understand that Context Window isn’t the same as Context Attention. As a human, I can store hundreds of items in a storage unit, but I will remember about a fraction of the items I have there.

Same with LLMs. Performance degrades as the context window gets filled (and costs).

Did you know that every message you send is sending all the previous conversation in an API call? Yes, you’re billed also for those past messages. The servers in the cloud don’t keep any state, they only have a cache.

When the model fails to make an update, the instinct is to write a better prompt.

Add more constraints.

Tell the model to “preserve the surrounding structure.”

“Make no mistakes.”

But that is like asking someone to juggle while blindfolded and then giving them more detailed instructions about hand positioning. The problem is not the instructions. The problem is the blindfold.

The context window itself becomes a liability when it’s packed with thousands of lines of repetitive structure. No prompt can fix that.

I covered in this post how to scale AI setting up guardrails

What Is Harness Engineering?

Harness engineering is the discipline of designing the systems, architectural constraints, execution environments, and automated feedback loops that wrap around AI agents to make them reliable in production.

The term was first coined by Mitchell Hashimoto, the founder of HashiCorp. The metaphor comes from horse riding. Think of the LLM as a powerful horse. It has raw energy, speed, and strength. But without reins, a saddle, and a bridle, that energy is undirected and potentially destructive (the horse kicks you, the LLM runs a rm -rf, and I don’t know which is worse). The harness allows the rider to direct the horse’s power productively.

To understand where harness engineering fits, here’s how it relates to the other disciplines you’ve probably heard about:

• Prompt Engineering → Single interaction to craft the best input to the model (single request-response interaction).

• Context Engineering → Control what the model sees during a whole session (multiple interactions until clearing).

• Harness Engineering → Designs the environment, tools, guardrails, and feedback loops (multiple sessions).

• Agent Engineering → Design the agent’s internal reasoning loop (define specialized agents).

• Platform Engineering → Infrastructure to manage deployment, scaling, and cloud operations (where agents can run).

Prompt engineering is about what you say to the model.

Context engineering is about what the model sees.

Harness engineering is about the entire world the model operates in. It includes the tools the agent can call, the constraints it cannot violate, the documentation structure it reads, and the automated feedback loops that catch its mistakes before they reach production.

Subscribe now

How I Built a Harness That Ships 100+ PRs/Month at Amazon

Let me walk you through the specific problem I solved, because abstract talk about agents only becomes useful when you see them applied to a real constraint.

The problem: We had large JSON configuration files that needed automated, repetitive updates. These files were too big for the LLM’s context window. Every manual update was tedious, error-prone, and time-consuming.

What everyone else tried: Engineers on the team opened their IDEs and started prompting. The LLM would correctly modify the target node, but would fail to identify which other files had to be updated, and it would fail to keep the correct JSON structure. There was no awareness of JSON structural integrity as a hard constraint. Every run was a coin flip. Sometimes it worked. Most times it broke. You can’t trust an AI like this.

The harness approach: Instead of trying to update the prompt, I narrowed the problem to one specific operation: How to read and write into our JSON files. I wasn’t trying to build a general-purpose agent. I built a scoped one. I wrote deterministic Python scripts to handle the actual JSON surgery: read the file, apply a precise modification, validate the structure, write it back. The agent’s only job was to provide the intent, the what, and the where. The script provided the execution guarantee.

The key insight was this: the agent calls the script as a tool. It does not generate JSON directly. It tells the script what to change, and the script changes it with zero ambiguity. This means the AI is the brain that chooses which steps to take, like a CEO indicating directions. The AI didn’t have to make the groundwork itself.

I then added a structural validation step as a guardrail. If the resulting JSON is malformed, the agent cannot proceed. It physically cannot ship a broken config. This provides a feedback loop, which is something managers and C-level executives also want when delegating to humans.

The result: 100+ PRs per month. Zero structural corruption. Fully autonomous. The system has been running for months, and after a few weeks of tweaking edge cases in the deterministic scripts, the Agent nails the updates.

At some point, we realized the only reason a PR gets rejected is that the requirement was wrong, not because the AI didn’t execute the requirement.

That’s when you are into something good.

If you want to build agents that ship production code instead of only doing demos, the paid section that follows breaks down the exact harness framework I use: state, context, guardrails, and entropy control.

Read more

Subscribe now

I spent my early years in the software industry thinking that the more code I shipped, the higher salary I’d get.

I thought that putting in the hours would automatically lead to career progression.

I was wrong and ended up feeling completely stuck in the same position.

I realized I was good at the exact same things I had been doing the year before. I also had the exact same gaps in my skill set. Writing code isn’t the only requirement to move up the ladder.

I had to change my approach completely. I stopped being just a developer who executes the same routine every day. I became an organized professional who plans ahead of time to generate the right evidence for career advancement.

Today, we’ll learn about a technique commonly used for KPI management. We’ll apply it to the KPIs for our growth.

There’s also a template at the end to start applying it right now.

In this post, you’ll learn

• How to stop doing only the routine tasks your team needs.

• How to measure your career progress.

• How to use AI to reclaim your time for high-leverage work.

Problem statement:

Many developers today face a core problem that keeps them from advancing: What got you here won’t get you there.

This happens because they lack the organizational skills to align their daily work with actual promotion criteria.

Simply executing routine tasks is not enough to show senior/staff-level impact. You end up doing the tasks the team needs done instead of the tasks you need for your career growth.

Don’t get me wrong, you should not complain or refuse to do your job. In the end, they pay you for that. But you have to be a bit selfish and bold to be the driver of your growth.

Simply offer yourself for the tasks that actually matter for your progression. Nobody else is thinking about what is best for you, so you have to take charge of your own trajectory.

I’ve offered myself for things and got a “no“ for an answer. Not because someone had also offered, but because they wanted to give it to someone else. That’s fine, you can go to sleep without regrets.

The important part is to never stop taking action.

The technique:

Read more

But last month, I merged more than a hundred PRs at Amazon.

I did this by building my own autonomous AI agents.

If you only use AI, you spend hours context-switching and cleaning up “AI Slop”.

You need to design AI solutions.

As I built more agents to work for me, I realized the underlying pieces are always the same.

I call them the “AI Agents Building Blocks.”

With this concise ebook, you will:

• Free up your time by designing AI solutions

• Solve any problem by creating your team of experts

• Prevent “AI slop” by creating guardrails

• Delegate your work to an AI Agent that takes actions for you

I’ll send you the ebook for free to your best email:

Most people are receiving the first email in their Promotions/Social Gmail tab or similar. Please find the welcome email and move it to your primary inbox so you don’t miss it!

Subscribe now

This developer knew how to write clean functions and build solid features. They were the top code contributors of the team.

But despite their technical skills, they felt completely overwhelmed by the sheer volume of work. Raw coding speed was not enough to keep up.

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

Subscribe now

The role of a software engineer has been changing lately. Having basic programming knowledge is necessary, but not sufficient.

Now we have to learn productivity and workflows with AI to scale our output. Developers who lack organizational skills quickly fall behind in this new environment.

Real productivity means understanding your feedback loops. You must keep them tight. You must also close them

Let us look at how to apply these concepts in daily practice.

In this post, you’ll learn

• How to speed up coding tasks using the inner loop.

• How to manage project states and handoffs with the middle loop.

• How to plan software architecture using the outer loop.

• How to position yourself as an internal AI leader.

The three loops of AI productivity

AI isn’t just a fast code generator. It’s the brain behind our new productivity system. To leverage it effectively, we need to understand the three loops of AI productivity.

We’ll call them the inner loop, the middle loop, and the outer loop. These are the names that Steve Yegge and Gene Kim used in their book Vibe Coding

The inner loop is where a developer and AI rapidly exchange ideas and code in minutes. Treat it like a chef managing orders by focusing on tiny tasks.

The middle loop manages projects and task handoffs. This phase spans hours to days and involves the systems needed to pick up where work was left off. It’s like how chefs prepare ingredients before service and clean up after.

The outer loop thinks in the long term. The chef moves focus from cooking individual dishes to weeks or months of menu planning and kitchen improvement.

While reading, you may have imagined systems for all of these 3 loops

• Inner loop: A developer using their IDE and executing unit tests

• Middle loop: A kanban board with all the tasks and dependencies for a project

• Outer loop: Documentation of architectural patterns and API contracts between services.

We’ll see how to adapt the three loops to AI

The inner loop for fast execution

Keeping AI interactions tight and focused maintains momentum.

LLMs have a decay curve where the quality of output degrades as the conversation goes on. Writing micro prompts that target one specific function or bug fix at a time keeps the inner loop tight.

A few months ago, I’d have told you to build a personal library of prompts for common tasks like unit tests.

Now we don’t need to micromanage AI anymore.

We can put a series of steps in an Agent Skill. We’ll avoid the context rot by creating a simple multi-agent architecture where the main agent can spawn child agents.

Parent agents manage the work. Child agents do specific tasks. One child might write tests. Another might refactor code. A third could write documentation. This keeps the inner loop focused.

In this loop, the tools that matter the most are version control and unit tests.

• You need to save the progress through commits, to have a separate branch for the agent to work on a particular task

• You need to have unit tests to validate that the agent doesn’t break other functionality.

One of the problems with the inner loop is that the agent has a very narrow goal.

Tell an AI to make an API return a value. It might remove other data by mistake. It might also return fake data instead of using the database.

That’s why we need the middle loop

The middle loop for orchestration

Some time ago, every new session with the AI was a brand new start.

We needed a system to manage the state of the project and the handoffs between sessions. This is where the middle loop comes in.

Read more

Subscribe now

Many developers assume the only definition of success is a straight climb up the corporate ladder.

I used to think the same way when I just started working after university. Later, I realized that climbing is just one option.

You can step off the ladder completely and choose a path that fits a different life.

I remember watching a work colleague hustle for Principal Engineer titles. This engineer worked late nights and some weekends, often sending PRs at 3 am. I’m sure they skipped family and friends’ events to prioritize work. This worked, and this colleague got the promotion. But the question here is, does this effort-reward relationship work for you?

I noticed there are many paths to achieve a destination, and at the same time, many destinations.

Intentionally choosing your work expectations is the real way to achieve personal happiness. If you want to be the fastest promoted engineer, then by all means, go for it. But if you want to transition to self-employment to get a remote job, to prioritize your life outside of work... then you need to be strategic about how you spend your time.

In this post, we’ll cover a technique to make work fit your life.

In this post, you’ll learn

• How to identify the traps of standard career progression.

• Ways to rewrite your professional goals.

The problem: the “super senior staff engineer” goal

An objective function is the specific metric a system is designed to optimize.

Your company will define a default one: Work hard, many hours, and climb the corporate ladder. This is fundamentally broken for engineers who want to achieve something different with their coding skills. This system assumes your highest priority is always the company. It ignores your desire for a personal life and family time

At some point, you may realize these metrics don’t serve their actual life goals. Getting involved in every meeting will drain your daily energy if what you want is to finish early and celebrate your kid’s birthday.

This cycle leads directly to burnout. The pressure to constantly be visible causes developers to lose track of their priorities. Even worse, most people only have basic organizational skills. This makes work spill over into evenings. The problem with overwork, besides ending up exhausted, is that you don’t have time for anything else in your life, so you’re always at work.

The technique: Defining your custom objective function

Read more

Subscribe now

Note: My opinions are my own. I do not speak for a company, and I don’t care what’s true and what’s not from the press releases below.

Recent tech headlines about Amazon and outage incidents miss the point entirely.

The media loves a flashy story about AI breaking code, like this recent article:

Those apparent leaks got so much attention that even Amazon had to write its own PR communication to correct the narrative.

You should treat any news about big companies with skepticism unless it is communicated directly by someone from the company. Even internally, there are so many layers that direct information is hard to find.

I’m not here to talk about gossip.

I’m here to approach the real problem: How can we do good software engineering with AI?

The core points from the media that I read were:

1. AI causes outages by breaking production directly or by flooding engineers with so much code that reviews become sloppy.

2. All non-seniors’ code needs senior approval. Press and social media are making a point that Amazon fired many engineers and is now asking to have engineers as the guardrail.

I think those headlines are looking at this situation the wrong way.

The thesis of modern development is that the bottleneck is no longer coding speed.

Let’s rephrase the problem in this way:

• Pre-AI: A company was able to handle 1 diff per engineer per day.

• Post-AI: Now, engineers can raise 5 diffs per engineer per day.

So is the press and social media saying that the solution is to hit the brakes and make engineers write only 1 diff per day?

That’s not a good solution.

Companies change their engineering processes when they go from 10 engineers to 1000 engineers. So companies should adapt to AI the same way.

We need to apply good engineering practices to how we use these new tools to become truly productive.

Let’s learn how!

In this post, you’ll learn

• Why manual safeguards create a false sense of security and drain productivity.

• Concrete steps to automate your deployment pipeline and get your time back.

• How the bottleneck in software engineering has shifted from writing code to reviewing code.

• How to build an engineering culture that scales with rapid code generation.

The cost of manual safeguards

Let me go back 2.5 years.

I switched teams internally from Amazon retail to the Ring team by the end of 2023. I was told when interviewing for Ring that the company was still in progress to “transition” into Amazon’s ecosystem. The first day, when I arrived at my new desk, I saw we had continuous integration pipelines. So this wasn’t an outdated company at all, right?

Well, the promotions to production environments were disabled in all pipelines.

Deployments were entirely manual, relying on human reviews and checklists. We treated our code like mobile app store releases, freezing updates weeks in advance for testing. This process was built on the belief that human eyes were safer than automated machines.

Teams documented more than necessary: Commit hashes, summary of the changes, links to regression tests, and approvals from multiple leaders. They did all of this documentation by hand (it was before the AI boom).

This manual process gave everyone a false sense of security. Humans make mistakes when reading long checklists and manually verifying hashes. These processes drain productivity and prevent engineers from doing their best work.

We think things are safer when we see them, but the only way to grow and scale is to delegate. And there’s nothing better than delegating to machines.

We needed to automate these steps to actually protect our systems and our time.

7 steps to automate your deployment pipeline

Since those early days, my team has done a lot of automation and applied DevOps learnings to our pipelines to adopt real continuous delivery.

The transition from manual checks to automated deployment requires some specific improvements. I agree that it’s risky to just enable a transition between non-prod and prod without any of these automated guardrails.

This upfront investment in an organization brings great returns in the long run. A team of six engineers can now manage eight services because they do not waste time on manual pipeline tasks (this same team only owned three, from which two were in KTLO).

Here are some of the guardrails needed to have a real CI/CD pipeline

1. Deploy all your infrastructure as code. This is the best way to maintain environment parity and be able to audit it.

2. Add testing to the pipeline. Improve the pipeline to run integration tests, canary tests, and load tests automatically before promoting any changes.

3. Establish robust monitoring. You need to track core metrics like availability, latency, and resource utilization for any backend service. For asynchronous workflows, you should monitor the oldest event and track messages in dead letter queues to measure failure rates. You need these metrics in all non-prod environments too, so you catch issues early in the pipeline and stop deploying them.
   And you should also ensure that changes don’t break dependencies. Add contract testing to ensure backwards compatibility.

4. Update your deployment strategy.

Read more

Subscribe now

The difference between a junior developer and a senior leader often comes down to communication precision. Junior developers might know how to write code, but they often lack the organizational habits to scale their impact across a team.

This gap becomes obvious when we look at how different engineers interact with artificial intelligence. Treating an AI tool like a casual chat partner leads to a productivity loss. If you want to deliver your best work today, interacting with both humans and AI, you must know how to communicate to each of them.

We can break down communication into three distinct levels of authority. I learned about this framework from Luu Tran, a Senior Principal Engineer working on Alexa at Amazon. This mental framework will change how you interact with both your colleagues and your AI agents.

In this post, you’ll learn:

• How to categorize your feedback using Luu’s proven framework.

• How to apply human communication styles to machine instructions.

• Techniques to stop your coding assistant from blindly agreeing with bad ideas.

The 3 levels of engineering communication

The weight of your comments matters in a technical environment.

When a Senior Principal Engineer speaks, most people will take those words very seriously. If it’s a junior engineer instead, people would assume their level of confidence is lower due to their limited experience. This creates a need for a system that helps teams distinguish between mandatory changes and casual thoughts.

Level 1: Authoritative

Luu Tran defines a clear framework starting with the authoritative veto. This is your level one input, which acts as a non-negotiable directive based on deep expertise.

You use this level when you know your feedback applies directly to the core architecture or strict security constraints of a project. It leaves no room for debate and requires immediate compliance.

If the person didn’t accept the feedback, you’d escalate to your management chain or their management chain, and you’d ask other peers to jump in. In essence, you’d move heaven and earth to make sure they don’t make the mistake you are foreseeing.

Level 2: Talking from experience

The second tier is the advisory experience. This level of input offers guidance without enforcing a strict path.

As an experienced engineer, you’ve worked on many projects with many people, and you can see parallels between present situations and your past work.

You cannot be completely sure what the exact impact will be on their specific project, or you know that multiple options are good, so you offer it as a suggestion rather than a mandate.

You’d often end with “but YMMV“ (your mileage may vary)

Level 3: Talking as a user of the system

The third tier is the unverified opinion, which is casual feedback from a user perspective. It’s like thinking out loud. You are just another opinion.

You don’t intend your input to be used for any decision. You don’t want people to quote what you said. You just wanted to share a thought.

Most times, if you find yourself in a room with people who will take your words seriously and use them for decision-making, shut up. Use this level of talking only when you have very good communication with those people, and your words won’t have consequences.

The real problem: People misunderstand the level, and you misunderstand yourself

If there’s enough tenure and seniority, even with people at the same level, they can take your words as a commitment or the words from someone with deep experience.

Imagine a director of software engineering talking casually about the predictions of AI replacing 90% of the job in 2 years, and talking about starting to use AI in human resources. Then the HR director does layoffs, only to find that AI is not good enough yet.

These are things that happen because they didn’t understand the message at the same level

Most people will take any words from a Senior Principal engineer as a mandate, while taking any words from a junior as an opinion. Sure, the Senior Principal is most likely right, and the junior may have missed most of the complexity of the problem, but that may not happen 100% of the time.

If you can’t express which level you are coming from, as you grow in experience, you’d find yourself afraid to talk. Anything you say may be taken as a mandate, even if it was just a joke or an opinion. You will find you can’t think out loud or talk casually to brainstorm ideas. You end up being conservative, not taking any risk, not thinking outside the box.

That’s why it’s important that you understand which level you are coming from, that you communicate it clearly, and that people act according to the level of communication you’re using.

The framework only works if you know how to apply it to AI. Here’s exactly how.

Applying these communication styles to AI

Read more