Subscribe now

Last week, one of my AI reviewers found that an implementation was missing fields required by JSON-RPC.

I had reviewed the code. What I had not done was read enough of the standard to know which fields were absent.

I have enough experience as a software engineer to read a function and know its design can be improved. But I can’t start using a technology and understand its “gotchas” immediately. That’s the problem AI is solving for me now.

AI has made producing code much cheaper. It has not created more time for me to inspect that code. When I am involved in several projects, I cannot deeply read every pull request, compare every implementation with the previous version, check every library contract, and still do my own work.

Yet I got positive feedback about being able to contribute in multiple workstreams instead of having the typical approach of putting my head down in my work and ignoring everything else.

GitHub defines AI code reviews as an automated process that analyzes code and provides feedback. That definition is correct, but too broad to be useful on its own. A generic “review this PR” prompt usually produces a generic review.

My system is more specific:

1. Several reviewer agents inspect the same change from different starting points.

2. Each finding must include evidence.

3. One aggregator verifies and combines the results.

4. Repeated findings become deterministic build-time checks.

5. The review runs before I’m even aware I have to review the PR

The agents can review several projects in parallel. I still work on one thing at a time. Let me tell you how I do this.

AI moved the bottleneck from writing code to reviewing it

A few days ago, The Pragmatic Engineer described a concern among engineering leaders: coding agents are producing more code, review load keeps growing, and some developers are reviewing changes less thoroughly.

I have experienced the same pressure. AI makes writing code faster, so we have to work on more projects in parallel.

This creates two bad situations.

1. The first is approving faster. The tests are green, the AI reviewer did not leave a blocking comment, and the diff looks reasonable. Ship it.

2. The second is making a senior engineer the permanent review queue. That may keep the quality bar high for a while, but it does not scale. The engineer spends the day switching between PRs while multiple authors wait.

AI code review tools can help, but only if it reduces the work required to understand a change. The term AI slop comes from having a lot of noise for little signal. A wall of low-confidence comments creates more work for humans.

Cloudflare described exactly this failure when it put a diff into a broad prompt. The output included vague suggestions, hallucinated errors, and comments about code that already existed. They ended up with a system that used up to seven specialist reviewers and one coordinator.

That architecture matches the lesson from my own experiments. Let’s see now what my architecture is

A review agent should make the code easier to judge. It should not make the reviewer process another stream of guesses.

One reviewer agent == one responsibility

You may have heard that getting 1% better every day leads to getting 35 times better over a year. That’s the power of the compound effect. Also, the same principle under the butterfly effect: A small change in one place can make a big difference later.

Well, large language model (LLM) outputs are probabilistic and sensitive to their starting context, so they are sensitive to the butterfly effect.

The first files an agent opens influence the model it builds of the change. A reviewer that starts from a controller may focus on request validation. A reviewer that starts from a database migration may focus on compatibility and rollback. Both can be the smartest LLM, both can have the same codebase; we have and still miss what the other one sees.

Humans do this too. Once I think I understand the cause of a bug, my attention starts looking for evidence that supports that explanation. Another engineer can enter the same review with a different mental model and find the gap I ignored. That’s why I always worked in teams where, besides the author, we had 2 human reviewers.

One general reviewer has an even harder job. Think about it like a senior engineer that is reviewing the PRs of 20 people, but it’s not working in any of those projects. We can ask it to inspect security, product behavior, tests, architecture, performance, documentation, and team conventions inside one long prompt. Attention gets split across concerns; it can pattern-match with different projects, but it can’t go deep.

For me, this is the reviewer roster that I want to have:

• Security reviewer: Checks all security concerns

• Behavior reviewer: Compares the change with the ticket, API contract, and existing behavior.

• Test reviewer: Looks for untested branches, weak assertions, missing failure cases, and tests that merely repeat the implementation.

• Architecture reviewer: Checks ownership boundaries, coupling, dependencies, cross-package impact, and following the team convention.

• Standards reviewer: Compares the code with repository conventions, library documentation, language rules, and external standards.

These reviewers should be independent. I do not want the architecture reviewer to inherit the security reviewer’s conclusions before it has inspected the change. Separate starts create separate opportunities to notice a bug.

The good part of bugs is that it’s not a matter of all reviewers aligning that we should fix something. Once one reviewer finds something and proves it, it shares it, and an aggregator adds it to the list of requested changes.

Subscribe now

A review comment is useful only when it brings evidence

Every agent output has to answer these questions

Location:
Which file and line contain the problem?

Finding:
What behavior is wrong or risky? Is it only about design / team conventions?

Why it matters:
What can fail, regress, leak, or become harder to maintain?

Evidence:
Which parent-commit behavior, related code, test, documentation, library contract, language rule, or standard proves the claim?

Suggested next step:
What is the smallest useful correction or decision?

Confidence:
How certain is the reviewer, and what remains unknown?

This is how I get one report, categorized and prioritized, and I can evaluate as a last human step whether we should write a comment in the PR about it or not.

LogRocket’s tool comparison used separate prompts for security, context alignment, and modularity. That is already better than asking for “a complete review and make no mistakes.” The part I add is independent reviewers plus an aggregator, letting each agent find conclusions independently.

The evidence field may be the most important part of the AI code review system.

1. Start with the parent commit. A reviewer should distinguish a regression introduced by this pull request from an old problem that happens to be nearby. If the same behavior existed before, it may deserve a separate ticket instead of blocking the current change.

2. Then inspect related merged code. A new API client may be inconsistent with the other clients in the repository. A new retry loop may ignore the backoff helper every other package uses. The comment becomes stronger when it points to the established implementation.

3. For libraries, languages, and protocols, use the authoritative documentation.

That is how the JSON-RPC issue I opened the article with was found. The valuable output was not “this response is missing id”. The reviewer identified the location, named the missing fields, and connected the finding to the protocol's exact section that described this. I could verify the comment by myself in just a quick read.

This also changes how I review across multiple projects. I don’t need to remember every standard and every package pattern before I open the PR. The agents collect the relevant sources. I inspect the evidence and decide whether the finding applies. This is especially important when having repositories in multiple programming languages, some legacy and with bad design, others more robust and with strong standards and conventions.

One caveat is that evidence can prove that an implementation violates a documented contract. It still cannot decide whether the team should change the contract, accept an inconsistency, or move a responsibility to somewhere else. That is engineering judgment. That is still my job.

Repeated feedback should become deterministic

Reviewer agents will eventually repeat themselves.

Maybe they keep flagging the same package naming convention. Maybe generated code calls a forbidden dependency from the wrong layer. Maybe every new endpoint forgets the same required field.

The easy response is to add another paragraph to AGENTS.md, a steering file, or the reviewer prompt. That’s a good first step, but it may not fully mitigate the problem. But they’re weak enforcement because the model can still miss, misread, or deprioritize the instruction.

I prefer this progression:

1. A reviewer finds a problem.

2. I verify that the rule is real and broadly applicable.

3. Fix the current instance.

4. We encode the property in a deterministic check.

5. The context file explains the convention as a best effort to do it right since the first time.

I did this recently for Java package conventions. AI kept creating packages that did not follow the team’s agreed pattern. Even with markdown files referenced in skills and prompts, it often created packages outside the convention. The durable fix was an ArchUnit rule (a Java library to define unit tests that check things like cycles in between your functions or the Java packages and class naming). Now the build fails when new code crosses that boundary. That’s a stronger feedback mechanism to AI than instructions in a Markdown file.

The same approach works with:

• Formatting and naming: Linters and formatters.

• Architecture boundaries: ArchUnit, dependency rules, or import restrictions.

• API shapes: Schema validation and contract tests.

• Security invariants: Static analysis, policy checks, and targeted tests.

• Required behavior: Unit, integration, and end-to-end tests.

A green build does not prove the code is correct. It proves the properties encoded by those checks. That is still a major improvement because those properties no longer depend on a model remembering a paragraph.

This is a cool feedback loop when you are adopting AI-assisted code reviews. Reviewer agents find classes of mistakes. Humans decide which findings should become a policy. Deterministic tools enforce the policy on every future change.

The review system gets better for your team even if the model stays the same. Even after 1 month, I still didn’t switch my Opus 4.8 for Fable, just because it was so hard to find spare capacity in my company that it was falling back all the time. And because Opus 4.8 was more than enough to build a system around it.

If you want to build this feedback loop around coding agents, read the guide to harness engineering. It covers context, state, guardrails, and deterministic checks in more depth.

Conclusion: Run the review before you arrive

This kind of AI-assisted review takes time. Five reviewers plus an aggregator are slower and more expensive than one generic prompt.

So I do not sit there watching them run.

The workflow fires when a pull request is opened or updated The agents fetch the change, inspect their assigned concerns, verify their findings, and prepare one report.

This is the operating model:

1. PR published

2. Trigger my orchestrator that fires specialist reviewers

3. These specialist reviewers take their time

4. Aggregator verifies, deduplicates, and generates one report

5. First human contact: I open the PR and the report. I focus on this PR for as long as I need to have an opinion and leave my comments. My agents are working in the background and preparing me with other reports so I can properly switch to the next context without leaving part of my attention behind.

My agents work concurrently. My attention stays sequential.

Start small, improve it over time. That is how the review system compounds. Every PR can improve the guardrails for the next one.

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 from phase 2 to phase 3, gaining influence as you’re able to review more code with higher quality, getting you promoted faster

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

Subscribe now

🗞️ Other articles people like

If you want to improve the human side of the same workflow, read this next. It shows how references, scope, and escalation make review comments easier to act on.

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

The model is the easiest part of my AI coding setup to replace. The moment the newest model is available, I just plug it in.

What took months was building the system around it: project context, reusable procedures, isolated workspaces, explicit task state, fast feedback, and agents that return evidence I can inspect.

That is my answer to the best AI setup for software engineers. At least, the best that I know of right now. Build an operating system around the agent that preserves your understanding

For me, it has five parts, and we’ll cover them all in today’s article

1. Durable project context and reusable procedures.

2. Isolated execution with fast feedback.

3. Explicit task state outside the chat.

4. Parallel agents with one human work item in progress.

5. An evidence and coordination loop around the code.

The best AI coding setup is an operating system, not a tool

Most setup guides start with the editor, model, terminal, or agent.

Those choices matter, but they are easy to change. A model is just a string in my config. I’ve gone through multiple AI IDEs until landing in the terminal as my preferred workstation. I’m sure they will keep changing.

What matters is the setup to answer five questions:

• What does the agent need to know?

• How should it perform this kind of work?

• Where can it make changes without corrupting another task?

• How does it know whether the change works?

• What evidence will I inspect before I approve the result?

This is important because if one answer is missing, it’s the human who absorbs the failure.

This is why I think software engineers are too focused on code generation. Code became cheaper. Understanding the system, defining correct behavior, and proving that the change preserves it remain expensive.

Here is the split I use:

• Search in code or in the AWS Account. The machine handles the search. I decide what to do with that information.

• Compare code with our standards. The machine finds deviations. I choose if it’s justified or not.

• Run builds, tests, and linters. The machine executes the checks and fixes the failures. I decide if the fix they did was good or not.

• Watch tickets, reviews, and CI. The machine monitors the state. I take action once I can

• Prepare reports and alternatives. The machine organizes the evidence. I own the final document and how I communicate it.

Humans are bad linters. Give me 2,000 code lines, and I will find performance inefficiencies, deviations from standards, and many more. The machine can check all of those every time.

My useful work starts when the findings become a decision. Should this service own the behavior? Is the new abstraction worth its maintenance cost? Did we preserve the product requirement?

I know many people were delegating those things to their seniors, and they were just writing code as told. Those people will have a harder time, so let’s start building a system everyone can use to become irreplaceable.

Give agents durable context and reusable operating procedures

The first version of my AI workflow depended on prompts.

I kept explaining the same thing all the time: architecture, the build commands, the project-specific tools, and the mistakes the agent should avoid, based on previous executions. The prompts became longer because every failure added another paragraph. At some point, I even created a prompt library (this was before having Agent Skills).

That approach made me the glue between the company and the agent. If I forgot one detail, the agent worked in the wrong direction.

I now separate the information by how long it should live and how broadly it applies.

• Rules: Stable constraints that live for months and apply across many tasks. Examples include architecture boundaries, language conventions, and forbidden operations.

• Skills: Reusable procedures for one type of work across many runs. Examples include investigating a ticket, reviewing a PR, or verifying a revision. I compose skills by building some broad ones that are a series of steps, each step with its particular skills. I call those SOPs.

• Task prompt: Temporary context for one task. For example, fix this endpoint while preserving these two flows; this is the ticket we’re working on.

Put the project around the repository

Whether I have one package or multiple, I use a wrapper that tells the agent how the software fits into the company.

I got this idea from a Principal Engineer at Amazon, he called it the metarepo (making a local monorepo of multiple packages that are separate git repos)

engineering-system/
├── context/
│   ├── architecture.md
│   ├── coding-standards.md
│   ├── environments-and-accounts.md
│   ├── ownership.md
│   └── source-links.md
├── rules/
├── skills/
│   ├── investigate-ticket/
│   ├── review-pull-request/
│   └── verify-revision/
├── workflows/
│   └── implement-and-qa.md
└── templates/
    ├── saved-state.md
    └── evidence-report.md

The context includes things the code cannot tell the agent:

• Which AWS accounts do we deploy to?

• Which service or team owns a configuration?

• Where does the CI/CD pipeline live?

• Which document contains the original decisions?

• Which internal SDK replaces the public library that the model already knows?

• Which actions require human approval?

I prefer links to original sources over copied summaries. A copied paragraph becomes stale silently. A source link gives the agent somewhere to check, and it gives the human a way to verify the claim.

I also keep credentials out of this layer. The agent can know that an AWS role exists and which procedure grants access. It does not need a secret saved in a Markdown file.

Turn repetition into a skill

The part I underestimated was the progression from rules to skills to SOPs.

My process was like this:

1. I perform a task with the agent.

2. I notice instructions I repeated or a failure I had to correct.

3. Stable knowledge moves into the project rules.

4. A repeated sequence becomes a skill.

5. Several skills become an end-to-end workflow.

6. As I keep using the workflow, I iterate and polish it

For example, “review this PR” is a prompt. It depends on what the model decides a review means that day, and how the model decides to obtain the code, what to check.

A PR review skill can require the agent to perform certain actions like comparing against the previous code, compare it actually implements what we need to implement, or giving me the comments in my expected format

Now the output is similar across runs. I keep improving the procedure when it misses something, so I know all future executions won’t miss it. This is where the results compound. I fix a workflow once, then every future task receives the same improvement.

A useful next step is this guide to turning repeated prompts into agent skills and a complete autonomous workflow:

Give every task isolated execution, fast feedback, and explicit state

Agents are more than code generators. I started generating code in a web UI chatbot like ChatGPT.

The point of agents is these 3:

Isolated execution:

Start with a Git worktree, for some situations, you may need an isolated container. I fetch origin/main, create a short-lived branch and worktree, and let one agent own that task. I follow trunk-based development (having only a single main branch and merging on top of it, so this makes every additional branch only have at most 1 commit. This reduces but doesn’t remove conflicts, and the conflicts are simple and small enough that you can solve them easily.

Fast feedback is part of the infrastructure

The agent needs a cheap way to know if the code is correct for the compiler (build), correct for the project (tests), and correct for our requirements (run some manual tests besides the automated ones)

Long feedback loops reduce the autonomy of an agent. If the correct build takes forty minutes or requires a human to click through five internal tools, the agent will either stop early or claim completion based on weaker evidence.

Put task state outside the conversation

Chat history is a terrible task database. It’s sequential, but you may go at different levels of abstraction in each chat turn.

It hides dependencies, blockers, owners, and acceptance criteria inside long paragraphs, instead of stating things in a place where you’d expect them to be. When a session ends, the state becomes difficult to inspect. When another agent starts, it has to reconstruct the task from a transcript of another agent's conversation.

I started persisting Markdown files of investigations I did in the project in an Obsidian Vault. I have a Vault fully operated by AI, and I inspect in Obsidian those Markdown files and decide what to keep and what to drop. The difference between the obsidian vault and the metarepo is that the metarepo contains the information useful for the long term, and the obsidian vault contains the information relevant for this task, such as steps done, progress, or the spec with the implementation plan

That distinction matters when agents work asynchronously. An agent may move a ticket from investigating to needs-decision Because it found two valid alternatives. It should not silently choose one and rewrite the acceptance criteria. You want to create a harness that forces your agent to write a report, and you inspect it, as an executive inspecting what their reports provide.

If you want the deeper engineering principles behind agent context, deterministic checks, and feedback loops, read this harness engineering guide:

Run agents in parallel while you stay single-threaded

Running three agents is easy. Paying attention to three agents is exhausting.

I learned this by doing the obvious thing. I started a prompt, waited, opened another task, started a second prompt, checked Slack, and after a few of these hops, I forgot what I was working on originally.

It makes me feel old. I forgot pieces of work that I had started, and I only realized it when I randomly opened that same terminal tab or browser tab.

That’s where I discovered herdr, and I’m enjoying it a lot. It’s an alternative to tmux, a terminal multiplexer, but it gives me one place to run and orchestrate agents across workspaces. I have zero affiliation, but I think it’s a very cool piece of open source software that you’ll like. It’s a great hybrid between UIs and terminals, because it runs in the terminal but clicks magically work

Herdr solves the execution side. The attention side needs a separate rule:

Agents run concurrently. I keep one human work item in progress.

It’s easier when the tool works for you instead of against you. You can have sound notifications, and the agents have a clear state, so you can filter by agents in the done/blocked state and jump into them to unblock them.

For me, there are three modes of working:

1. Waiting on one prompt. I am single-threaded, and I work in only one agent. We can focus deeply, but we work slowly only on one thing.

2. Fake multitasking. I switch between partial agent conversations and rebuild each mental model repeatedly. I’m faking productivity.

3. Async orchestration. Agents prepare artifacts in my AI Vault. I can know when the agents I’m running are all completed. I work on one task and workspace at a time. I let the agents do the work, and once I have finished with it, I can jump into the next workspace with agents that are pending my input.

The third mode is the one I use. I may ask one agent to investigate a ticket, another to verify whether my PR comments were addressed, and a third to implement an already approved plan. They can work in parallel because the tasks have separate workspaces, explicit state, and expected outputs.

I do not tail their conversation. I just wait until herdr marks them as done so I will check them on my next switch.

When I arrive at a workspace, I have a report with all the relevant information and the decisions required of me.

This is how executives work. They have their reports do the work and present the information. An executive who has to micromanage people won’t have great results. An engineer micromanaging the AI agents will also fail.

Save the human state too

Parallel work breaks when every paused initiative lives only in my head.

I keep a simple TODO-list of the things that I have to do and that I’m working on, so I have a bit of a bigger picture of the work I have to do.

I include here both my implementation tasks and all the other pieces of work, like reviewing someone’s code, something I have to tell someone, or an interview I have to prepare

This looks boring because it is. It also means I can return two days later and start from the next decision instead of rereading everything.

Single human WIP and saved states let me support several initiatives without pretending that my brain can reason about all of them at once.

The risk is queuing low-quality work. Ten vague tasks can produce ten vague reports and a bigger review burden. I only delegate work when I can define the boundary, expected artifact, and stop condition.

A useful next step is this breakdown of how AI waiting time turns into context switching, and how to keep deep work while agents run:

Turn engineering into an evidence and coordination loop

The greatest improvement in my workflow came from moving decisions earlier, while changes were still cheap.

My loop is simple: investigate, model the problem, challenge assumptions, choose, implement, verify, and report. A plan mode lets me inspect the reasoning before the agent creates a large diff, but only after the agent has read the code, source documentation, ticket history, and operational evidence.

For example, for an endpoint change, I ask the agent to trace the request, identify the data owner, list every consumer, and show the existing test coverage. It then explains the invariants, alternatives, blast radius, and missing evidence in plain language. The agent prepares the decision surface. I choose which tradeoff to take.

I also define verification before implementation. If the change affects an endpoint, the agent should hit that endpoint. The final report must say what ran, what behavior it exercised, what remains untested, and which risks remain. “Tests passed” is a status. The report tells me what the status means, and I can find if there are any missing tests.

I’ve saved so much time lately by letting an agent create a test plan, reviewing it, and then letting the agent run the requests, mint credentials, and write a report with the results.

The same loops continue outside the repository. My agents prepare code-review reports, check whether previous comments were addressed, update ticket states, detect new document comments, and remind reviewers if they ignored my code for a while.

I still approve of myself sensitive communication, production changes, and architecture decisions. But in many use cases, both my team and I prefer that an AI does some work rather than waiting for me to do it.

Conclusion: Build one workflow that improves itself

It’s crazy to think where we were 1 year ago. Just one year ago, I worked in an older version of a ring device. I was writing prompts in a web chatbot, copying the generated code into my IDE and running the build commands myself. I was the engineer.

Now I’m working on the next version of this same device, and I’m not writing code; I’m not running the commands. I’m an orchestrator of agents implementing. I’m not the manager of a single engineering team

If we keep going in this direction, in one year I’ll be my skip-level manager, managing multiple teams at the same time (which you can do already if you work on multiple projects). Then one year after a director of software engineering, owning a critical piece like the entire backend of a company.

Models will change. Editors will change. The durable system is the one that is tool-agnostic and evolves as the capabilities of frontier models and tools to add to our harnesses get better

Start small and keep getting these small wins.

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

Subscribe now

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

If you want to improve the decision-making stage before an agent writes code, read this next.

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

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