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.

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

Subscribe now

I’ve been thinking about that moment a lot. I work with great engineers, and we all feel the same pressure to ship faster with AI tools. The quality of outputs is not about using a different AI. It is about taste. And once I saw it in someone else’s work, I started seeing it in my own too: in pull requests I rushed, in design reviews where I nodded along, in production incidents that surprised us all.

This is the thing most people are getting wrong about AI coding. AI slop is not an AI problem. It is a taste problem. The models are doing exactly what they were asked to do. The question is whether the person on the other end of the prompt knows what “right” looks like before they hit enter.

In this post, you’ll learn

• What developer taste is in software engineering, and why it matters more now than at any point in the last decade

• How AI slop code shows up in real codebases and what taste mistakes actually look like

• Why senior engineers who use AI well have better taste, not faster typing

• How to develop a developer's taste as a practitioner working with AI tools every day

• What the shift to AI-assisted coding means for your career and who will be left behind

Subscribe now

The AI slop problem you already recognize

If you work in software today, you have seen AI slop. You might have shipped some of it yourself. I know I have. It is the pull request that compiles and passes tests, but makes no sense when you actually read it. It is the function that solves a problem nobody asked about. It is the new file that duplicates logic already living three folders away.

Slop is not broken code. That is the trick. Broken code gets caught. Slop is code that works today and quietly makes the next six months of your life worse. It is the extra abstraction nobody will remember adding. It is the test that asserts the wrong thing. It is the migration that ran fine in staging and deleted data in production because the happy path was all anybody cared about.

I remember reviewing a change where AI had wired authentication into a service by copying a pattern from somewhere else in the repo. The pattern was wrong. Not wrong for the other service, wrong for ours. The author had trusted the output because it looked like the rest of the codebase. Nobody paused to ask whether the rest of the codebase was the right reference in the first place. That is slop. It is code written by someone, human or not, who gave little consideration.

The reason this is getting worse is simple. AI tools raised the floor on how fast you can produce code. They did nothing for the floor on how carefully you have to think about it. If anything, they made things worse because companies increased the pressure to deliver fast thanks to AI. Most engineers did not evolve their thinking for AI. They kept typing, only they type prompts now. The model started doing the typing for them. The thinking got forgotten.

Learn why AI slop is the biggest risk for software engineers and the system I use to avoid it

What developer taste actually is

What some people are starting to call “software taste” is really just this: the judgment you bring before you write the first line of code.

Let me give you the definition I’ve been thinking about. Developer taste is the judgment to know what the right thing is, and the discipline to pursue it, before you write a single line of code. That is it. It is not aesthetics. It’s not about preferring tabs to spaces. It’s not about being a nitpicker. It is not how pretty your diffs look in review.

An important distinction is Taste vs Skill. Taste is what you bring to the problem. Skill is what you do with the problem once you understand it. A lot of engineers have skill without taste. They can write anything you describe, but they cannot tell you whether the thing you described is worth building. They will follow the spec down into the ground and ship exactly the wrong solution, on time, with full test coverage. This is everywhere now.

Taste is also not speed. Speed is how fast you get from idea to merge. Taste is how often the idea was worth merging in the first place. I have worked with engineers who shipped half as much as the people around them and moved the business twice as far, because every single thing they shipped was pointed at something that mattered. They rejected work that would not move a metric. They pushed back on specs that did not add up. They asked the question everyone else was too busy to ask. This is why it’s important to listen when these engineers raise a concern, instead of dismissing them because they are slowing down the initiative.

The simplest way I can describe taste is this. When you look at a piece of code, you feel something before you can explain what. That feeling is the compressed memory of every system you have broken, every bug you have chased at 2 am, every design you have watched rot under real traffic. AI can approximate the surface patterns. It cannot approximate the ache. That ache is the thing that tells you how much this shortcut is going to cost you in a month. It tells you this abstraction is premature. It tells you this test is testing the wrong layer. Taste is your scar tissue. Taste is your intuition. AI does not have this.

Subscribe now

What taste looks like in practice with AI tools

I was reviewing a change last month where the model had added a handful of new types to a model of a service. The change compiled. The types were correct in isolation. The problem was that the types belonged in a different file, because the service had two separate API surfaces, and those surfaces were never supposed to share definitions. If you did not know the architecture, you would have approved it. I only caught it because I had been there when the split was made, and I knew why the boundary existed.

That is taste in practice. It is not some magical pattern-matching. It is remembering why things are the way they are. It is the person who read the change, who was in the room for the incident, who walked the whole graph once, and kept the map. The model can see the files. It cannot see the history. If you do not bring the history, nobody does, and the fence gets moved without anyone asking why it was there. Even if you feed the history to AI, you’ll run out of context window. You need to pair with the AI for the best results.

Another one. I had started to build a new feature, and I caught myself about to paste an AI-generated block of code without opening a single other file. I paused. I closed the editor. I wrote down what the feature actually needed to do, end to end, as if I were explaining it to someone else. Then I opened the existing integration tests and worked outside-in, from the external behavior I wanted, down into the code I would have to change. Only then did I go back to the AI to prompt it. The prompt I wrote the second time was about five times longer and produced a change that was four times smaller than what the first prompt would have given me. That is taste in prompting. The quality of the answer is a function of the quality of the context.

This is the pattern I keep coming back to. Engineers with taste use AI to iterate toward a thing they already know is right. Engineers without taste use AI to guess at what right might look like, and then ship whichever guess compiled. These are not the same activity. They look the same from the outside. They produce completely different codebases over the course of a year.

That’s what many non-tech people miss. AI adds value to all of us, but it adds more value when you have taste:

• Non-tech people with AI produce better code than non-tech people without AI

• Tech people with AI produce better code than tech people without AI

• Tech people with AI produce better code than non-tech people with AI

Read more about the difference between prompt engineering and spec engineering and why senior engineers in big tech are moving toward the latter

What taste mistakes look like

These are not bugs. They are the subtle wrongness in code that works today and becomes harder to maintain later. Here are the five I keep seeing.

Treating AI output as final. You ask the model to write a function. It writes a function. You paste it in. You run the test. The test passes. You move on. What you skipped was the part where you read the code and asked whether this is what you would have written. Not word-for-word. Just whether it’s right. If you never ask the question, you are not using AI. You are being used by AI. AI output should be the first draft. Vibe coding (accepting whatever the model produces without reviewing it) is this pattern.

Copying from a secondary source instead of the primary one. The model was learned from other people’s code. Other people’s code is not the spec. The spec is the spec. When I see an engineer implement something by pattern-matching against a similar-looking file in the same repo, I get nervous. When that similar-looking file was also written by a model, I get really nervous. The original source of truth exists somewhere. The docs. The RFC. The design review. Find it. Read it. Reference it for the model. Then come back.

Skipping problem decomposition. This one is a classic, and AI has made it worse. You get a task. The task has three parts. You ask the model to do all three at once. It gives you a plausible answer that is wrong about one of them in a way you cannot see because you never wrote the three parts down separately. Taste says stop. Break the problem into pieces you can reason about. Decide the answer in your head for each piece. Then let the model write the pieces. You still have to own the thinking and orchestration of AI tools.

Shipping the happy path and calling it done. I see so much AI-generated code that solves the case where everything works and says nothing about the case where it does not. No error handling. No edge cases. No tests for the ugly stuff. The model will happily do any of that if you ask. The engineer did not ask because the engineer did not think about it. Taste is the reflex that makes you think about it without being asked. You only find the edge cases when thinking about the problem.

Making code work without making it right. This is the 50-50 rule I use with my team. Getting the code to work is half the job. Getting it right, clean, small, reviewable, shippable, and understandable in six months is the other half. AI is very good in the first half. It’s also good in the second half, but only if you are on top of it. You can’t abdicate responsibility.

Subscribe now

How to develop a developer's taste

I am going to give you the practices that have worked for me. None of them is flashy. Pick the ones that best fit your case.

Work outside-in. Before you write any code, write the test that describes what the feature should do from the outside. Or at least in human language. Not a unit test. An integration test that pretends you are the user, the other service, or the API caller. This forces you to decide what “done” means before you start. It also gives you a truth function you can run against the AI output later. Outside-in thinking is the single biggest taste accelerator I know.

Keep commits small and single-purpose. One commit, one responsibility. This sounds like a style preference. It is not. Small commits force you to decide what each change is actually about, which forces you to have an opinion about the change, which is where taste lives. If your diff is 800 lines and three concerns, you have already abdicated the decision to whoever reviews it next.

Read your own code in the review UI before you assign it. Pretend you did not write it. Pretend a junior engineer submitted it to you for approval. What questions would you ask them? What comments would you leave? This is the exercise I wish more engineers did. It is also the single best way to spot AI slop in your own PRs, because AI slop reads differently when you stop being the author and start being the reader.

Go to primary sources. The docs. The standard. The paper on which the library was based. The ADR in the repo. When you do not know something, do not ask the model with its training knowledge. Ask the source.

Define the skeleton yourself, let AI fill it in. I call this “Data Structure Driven Development”. You have to think about the data flows. I decide the types, the function signatures, the module boundaries, and the names. Then I let the model implement the bodies. This inverts the default AI workflow. The default is that the model drafts the shape, and you clean up. The better pattern is that you draft the shape and the model fills in the details.

Review more code than you write. Reading other people’s code, especially code you think is “bad”, is how you develop a nose for what is wrong. If you only ever look at your own work, you calibrate against yourself. If you look at everyone’s work, you calibrate against the full distribution. You understand your code is not the best, but also it’s not the worst. This is the closest thing I know to a shortcut for taste.

A practical guide to AI steering and getting the model to do what you actually want:

The career implications of a software engineer’s taste

AI is not coming for your job in the way the headlines said it would. It is coming for the part of your job you were already doing on autopilot. If that part was most of your job, you are in trouble. If most of your job was judgment, you just got a superpower to deliver more.

Engineers without taste are becoming executors. They will ship a lot of code. They will look busy. They will hit their sprint metrics. And over time, they will be treated like a fungible resource, because what they are doing can be done by anybody with a prompt box. The market rate for typing is dropping fast. The market rate for knowing what to type is not.

Engineers with taste are becoming orchestrators. They frame the problem. They design the shape. They review the output. They decide what’s raised as a PR. They use AI with clear intent and firm opinions. Their leverage goes up every time the tools get better, because the tools make their judgment multiply faster.

My honest bet is that the next five years are going to be rough for the first group and spectacular for the second, and the thing that separates them is not talent or tenure or which company they work at. It is whether they decided to focus on developing their taste, or pretend you either have it or not.

You can train it. You just have to start.

Subscribe now

Some Common Questions About Developers’ Taste

What’s a developer's taste in software engineering?

Software engineer taste, or developer taste, is the engineering judgment to know what the right solution looks like before you write it, and the discipline to pursue that solution instead of the first one that compiles. It is not aesthetic preference or coding style. It’s not choosing one programming language or another. It is the compressed experience that lets you feel when code is wrong, when a design will not scale, or when a shortcut will cost you later.

Can AI have good taste in code?

No, and that is the point. AI models produce the most likely output given a prompt, which means they default to the average of what they were trained on, unless they have a post-training layer in which they get steered to something else. Taste is the ability to reject the average when the average is wrong. Taste is also to accept the AI code when it’s right. A model cannot reject anything. The engineer using it has to, and that act of rejection is where taste lives.

What separates a senior engineer from a junior engineer in the AI era?

The ability to know what “right” looks like before asking AI to get there. Juniors without taste use AI to guess at solutions. Seniors with taste use AI to iterate toward solutions they can already picture. The gap is in framing the problem, not in writing the code.

What is an AI taste mistake?

An AI taste mistake is code that is technically correct today but quietly wrong in a way that hurts you later. Examples include copying a pattern from the wrong file, handling only the happy path, skipping problem decomposition, or duplicating logic because the model did not know the existing code. These mistakes pass review and surface months later as bugs or tech debt.

How do you develop engineering judgment when AI writes most of your code?

You develop it by forcing yourself to think before prompting. Write tests outside-in before implementation. Keep commits small. Read your own PRs as if someone else wrote them. Go to primary sources instead of pattern-matching. Define the data structures yourself and let AI fill in the bodies. Review more code than you write.

Subscribe now

Conclusion: Taste is the skill that compounds in the AI era

AI slop code is not an AI problem. It is a taste problem, and taste is the thing you have always been able to develop. Whether the tool in your hand is a terminal, an IDE, or a model that writes code for you, you develop your taste.

The tool changed. The skill underneath did not. If you were the kind of engineer who read the source, asked the hard question, and rejected the easy answer before, you are going to be fine. If you were not, the next few years are going to be harder than you think.

The thing I want you to take from this article is that taste is not a personality trait. It is a practice. You build it the same way you build any other muscle, with small, deliberate reps, done consistently, over a long time.

None of it is glamorous. All of it works.

Key Takeaways

• Developer taste is the judgment to know what the right solution looks like before writing any code, and the discipline to pursue it instead of the first output that compiles.

• AI slop is a symptom of missing taste, not a problem with the models, because AI produces exactly what the prompt asked for and nothing more.

• Taste mistakes are subtle errors in AI-generated code that work today and cost you later, including wrong-file patterns, skipped edge cases, and happy-path-only solutions.

• Engineers develop taste through outside-in testing, small single-purpose commits, primary-source research, and reviewing more code than they write.

• The AI era is rewarding engineers with taste and punishing engineers who treat AI like a typing shortcut, because the market rate for typing is collapsing while the rate for judgment is climbing.

Subscribe now

If you want to go deeper on how senior engineers are actually changing their workflow to work well with AI, read this system to prevent AI Slop:

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.

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

Subscribe now

In this post, you’ll learn

• What the OWASP Top 10 for LLM applications covers and why it was updated for 2025

• How prompt injection, sensitive data disclosure, and excessive agency affect real engineering workflows

• What changed between the 2023/24 and 2025 OWASP LLM Top 10 lists

• How to apply a practical security checklist mapped to all 10 LLM vulnerabilities

• Why agentic AI in 2026 makes several of these risks significantly more dangerous

What is AI security for LLM applications?

AI security means two different things, and the distinction matters.

The first is using AI to improve security: threat detection, automated code reviews, and vulnerability scanning. The second is securing the AI itself: protecting the models, the pipelines, the APIs, and the data those systems handle. This article is about the second kind.

LLMs introduce attack surfaces that traditional software doesn’t have. A conventional application has deterministic logic. You can audit a decision tree. LLMs are probabilistic and context-sensitive. The same prompt doesn’t always produce the same output. Adversarial inputs can produce emergent, unpredictable behavior.

New attack vectors showed up with LLMs that didn’t exist before: crafted prompts, poisoned training data, plugin chains, and autonomous agent actions. The OWASP community responded by extending its trusted web application framework to cover these risks. The LLM Top 10 was built by over 600 contributors across 18+ countries, and the 2025 update reflects how much the threat landscape has changed in a single year.

Subscribe now

Why the OWASP Top 10 for LLMs matters in 2026

The original OWASP Top 10 for web applications became the de facto standard for secure development. Security certifications, compliance frameworks like SOC 2 and ISO 27001, and enterprise security reviews all cite it. The LLM version carries the same weight. If you’re working at a company that ships software, the OWASP LLM list will show up in your audits and your security checklists.

This list was written for three audiences: developers building LLM-powered features like chatbots and copilots, security engineers reviewing AI integrations, and engineering leaders approving AI tooling for their teams.

There was a first list on 2023/24 focused on first-wave LLM integrations. Insecure plugins, model theft, and overreliance. The 2025 update restructured everything around agentic AI, RAG systems, and supply chain risks that emerged when those deployments hit production. The AI landscape is evolving very fast, and three risks were entirely new in 2025: System Prompt Leakage, Vector and Embedding Weaknesses, and Misinformation. Several others were renamed or merged to reflect how the attacks evolved.

Let’s review the full list.

Subscribe now

The OWASP Top 10 LLM security risks (2025)

LLM01:2025 — Prompt Injection

Prompt injection is an attack where user prompts alter the LLM’s behavior or output in unintended ways, potentially causing it to violate guidelines, generate harmful content, or influence critical decisions.

There are two types.

• Direct injection happens when a user’s input directly alters model behavior, whether intentionally by a malicious actor or unintentionally by hitting an unexpected trigger.

• Indirect injection happens when the LLM processes external content — a web page, a document, a RAG result — that contains embedded adversarial instructions the model then follows.

Prompt injection is different from jailbreaking, though both are related. Prompt injection manipulates model responses through specific inputs. Jailbreaking is a form of prompt injection where the attacker causes the model to disregard its safety protocols entirely. You can mitigate prompt injection through system prompt safeguards. Jailbreaking requires ongoing model training updates.

This is ranked number one because it’s the most exploitable vulnerability on the list. No special access required. Anyone with a text field can attempt it. RAG and fine-tuning don’t fully eliminate the risk. Research confirms the vulnerability persists across model architectures.

To mitigate: treat all external content as untrusted data, not as instructions. Use separate input channels for system instructions versus user content where possible. Add output validation before executing any LLM-generated actions.

Prompts is one paradigm for coding with AI, but there’s also the paradigm of Spec-Driven Development to create a plan (a spec) before doing code changes. You can learn more in this article:

LLM02:2025 — Sensitive Information Disclosure

Sensitive information disclosure occurs when an LLM reveals confidential data from its training set, context window, or prior user interactions.

GitHub announced that starting April 24th, GitHub Copilot will use your code and prompts to train its models. Besides taking advantage of your work, you can see how this is a problem. That’s LLM02 in practice. Feeding proprietary data into a model that could surface it to someone else.

There are three main disclosure vectors.

1. First, the model was trained on sensitive data and can be prompted to reproduce it.

2. Second, sensitive data is in the context window and leaks through crafted user questions.

3. Third, multi-tenant deployments where one user’s context bleeds into another’s responses.

What makes this worse than a traditional data leak is that you can’t always tell what the model “knows.” The disclosure is probabilistic. The same prompt may not reproduce the data every time, which makes it hard to test systematically.

To mitigate: never include credentials or confidential business data in system prompts unless necessary. Use data masking before sending sensitive content to external AI APIs. Audit what your AI tools can actually access, especially browser plugins and meeting tools. If you can, use models deployed in your cloud, under your control.

LLM03:2025 — Supply Chain

LLM supply chain vulnerabilities come from insecure components in the AI development pipeline that introduce risks into production applications. This includes pre-trained models, datasets, libraries, or AI-assisted tooling.

I used AI tools at work, but they have to be approved by the security department. Think about it, the AI tool is itself a supply chain component. If the model powering your coding assistant was fine-tuned on poisoned data, or the tool has an insecure plugin, your AI output that is sent to prod inherits that risk. That’s LLM03 in practice.

Common supply chain risks include pre-trained models from open-source hubs with unknown training provenance, third-party AI SDKs with insecure dependencies, AI coding assistants that access your codebase and external APIs simultaneously, and models with undisclosed training data.

This moved to number three in the 2025 update because the AI tooling ecosystem exploded in variety and popularity. The LLM itself is now one component in a larger pipeline. Each layer introduces risk.

To mitigate: pin model versions and don’t auto-update AI dependencies, similarly to what you’d do with the other software dependencies. Treat AI tools used in security reviews or certifications as components requiring their own security review. Maintain an AI Bill of Materials for your production AI pipeline.

LLM04:2025 — Data and Model Poisoning

Data and model poisoning is an attack where adversarial data is introduced into a model’s training, fine-tuning, or feedback datasets to manipulate its behavior in ways that may not surface until specific conditions are triggered.

This is distinct from supply chain (LLM03). Supply chain covers the pipeline components around the model. Poisoning targets the model’s learned behavior directly, through the data it was trained or fine-tuned on.

Poisoning happens in several ways. Public datasets used for fine-tuning can be poisoned before or during collection. Feedback loops, specifically RLHF data from users, can be manipulated at scale by adversarial users. Backdoor attacks embed a hidden trigger. The model behaves normally until a specific phrase or pattern activates the malicious behavior.

Recently, with the Claude Code codebase leaked, we saw in this application instructions to “not add attribution if it’s an Anthropic employee“. Now imagine this was not added at the client-level, but the model training or the RLHF phase was making the model react differently on certain conditions. That’s Model Poisoning.

What makes this particularly insidious is that you can’t see the poison. It’s baked into the weights. We have to differentiate the transparent “open source” models from abstract “open weight” models. The weights allow us to execute, but not to understand the model. The model behaves normally in standard use cases and only misbehaves on specific trigger conditions. Discovery requires systematic red-teaming by security engineers.

To mitigate: vet training data sources and treat them like third-party code dependencies. Use models from verified, auditable sources with documented training data provenance. Monitor model behavior over time for drift or anomalies in specific contexts.

LLM05:2025 — Improper Output Handling

Improper output handling occurs when LLM outputs are passed directly into downstream systems without adequate validation or sanitization. Think about browsers, shells, APIs, or databases.

LLM outputs can contain HTML, JavaScript, shell commands, SQL, or executable code. All of those are potentially dangerous depending on where they land.

If your app renders LLM output as HTML, you have a Cross-Site Scripting risk. If your app passes LLM output to a shell or code interpreter, you have a Remote Code Execution risk. If your app passes LLM output to a database query, you have a SQL injection risk.

The common mistake is treating LLM output as safe because it came from your own system. The model was told to write a response. It wasn’t told to write safe output for every rendering context it might encounter downstream.

To mitigate: apply context-appropriate output encoding everywhere: HTML escaping, SQL parameterization, shell quoting. Never pass raw LLM output to eval(), exec(), or shell commands. Treat LLM output as untrusted user input when passing it to any system that executes it. Have client application rules that prevent execution of certain commands, shell, or only allow the ones you trust.

Subscribe now

LLM06:2025 — Excessive Agency

Excessive agency is when an LLM-based system is granted too much autonomy, functionality, or permissions to act in the world, enabling it to take harmful or unintended actions beyond the intended scope.

I used LLM assistance to write all my code and documents. Efficient, useful. But if the LLM suggests code that is slightly wrong, and I apply it without reviewing, the LLM has exercised agency over something that may cause trouble. At scale, in an agentic workflow where the LLM writes the code, commits it, and triggers the pipeline, this is exactly what LLM06 warns against. The more you automate, the more agency you hand over, and the less oversight each individual action gets.

Excessive agency has three dimensions.

1. Excessive functionality means the LLM can call more tools or APIs than its task requires.

2. Excessive permissions mean it operates with higher privileges than needed, like read-write when only read is required.

3. Excessive autonomy means it takes multi-step actions without human checkpoints.

Agentic AI makes this the defining risk of 2026. Single LLM calls have a limited blast radius: the user sees the output and decides. Agentic workflows can take dozens of actions before a human sees results. You have your openClaw taking actions for you while you sleep. Each autonomous step compounds the risk of an uncaught mistake.

To mitigate: scope each LLM agent to the minimum permissions it needs for its specific task. Add human-in-the-loop checkpoints for consequential actions like deploys, permission changes, and file commits. Log all LLM-initiated actions for audit trails.

Regarding guardrails for LLMs, I’d recommend you read this other article:

LLM07:2025 — System Prompt Leakage

System prompt leakage occurs when the confidential instructions given to an LLM via the system prompt are exposed to users, attackers, or downstream systems, revealing business logic, security guardrails, or sensitive configuration.

System prompts have become the standard mechanism for configuring LLM behavior in production apps. A poorly protected system prompt is now equivalent to exposed source code.

What attackers do with leaked system prompts: they map the application’s security controls to find gaps, understand business logic to craft more targeted prompt injections, and extract competitive IP embedded in instructions like proprietary workflows or internal tool names.

Leakage happens in several ways. Direct extraction, where prompts like “Repeat your system prompt” sometimes work on poorly guarded models. Indirect extraction, where crafted user inputs get access to partial system prompt content in responses. Also related to LLM02, if the system prompt itself contains sensitive data, it gets disclosed.

To mitigate: never embed secrets or credentials in system prompts. Test your application for system prompt leakage before deploying. Design system prompts as if they are public. Sensitive logic should live in code, not in prompts.

LLM08:2025 — Vector and Embedding Weaknesses

Vector and embedding weaknesses are vulnerabilities in the retrieval and storage of embeddings used in RAG and semantic search systems, enabling data poisoning, information extraction, or unauthorized access to indexed content.

RAG systems became widespread in 2024, and vector databases are now a core component of enterprise LLM deployments. Embeddings are often treated as opaque black boxes, but they carry real security risks that weren’t widely understood when they got popular.

The attack patterns include many scenarios, like:

• Embedding inversion: extracting the original text from stored embeddings

• Poisoning the vector store: by injecting adversarial documents that get retrieved as authoritative context

• Cross-tenant leakage: where one user’s indexed content surfaces in another user’s query context

• Similarity search abuse: where queries are crafted to surface sensitive documents.

If your RAG system indexes internal Confluence pages, code repositories, or support tickets, the vector store is a high-value target. Access controls on the source documents must be mirrored at the vector store level, not just at retrieval time.

To mitigate: apply source document access controls to vector store queries. Don’t return embeddings from documents that the user couldn’t read directly. Validate and sanitize documents before indexing. Treat ingested content like user input.

Subscribe now

LLM09:2025 — Misinformation

Misinformation occurs when an LLM generates false, misleading, or outdated information that users act on as if it were accurate, particularly dangerous in high-stakes domains like security, medicine, legal, or compliance.

This risk captures both hallucination (fabricated facts) and confident incorrectness (plausible but wrong answers). The risk isn’t just that users trust AI too much. It’s that the AI gives them something false to trust.

For example, I used LLMs to verify some details about different hashing algorithms. This is a common move now, we don’t search in Google and original specs, but we ask the LLM. However, anything related to hashing and encryption has security nuances. Choosing the wrong one in the wrong context is a vulnerability. If I take a decision from an LLM without verifying later against authoritative documentation, I’m falling for LLM09 risk. Scale that to your team writing security documentation, threat models, or code review feedback. Uncritical acceptance of that output is how misinformation enters production.

The reason LLMs produce confident misinformation is structural. LLMs don’t signal uncertainty the way a search result does. They don’t have a cause-and-effect relationship (if A, then B). They only have probabilistic correlations (A and B happen at the same time 99% of the time). In security contexts, a confident but wrong answer can pass through review unchallenged. The fluency of LLM output with human-readable text creates a false sense of verification.

To mitigate: treat LLM outputs as first drafts, not final answers. Establish a verification step: AI output, then human review, then authoritative source check. I personally like moving the human all the way to the right of the process, but not removing the human. Require in your prmopts citation of primary sources where data comes from.

LLM10:2025 — Unbounded Consumption

Unbounded consumption occurs when an LLM application allows users or adversaries to consume excessive computational resources, causing degraded service, runaway costs, or denial of availability.

It covers not just availability attacks but cost exhaustion, budget blowouts, and resource abuse by legitimate users who hit no limits.

This matters more in 2026 because agentic workflows can trigger cascading API calls. Anthropic just announced a few days ago that they will explicitly forbid the use of their subscription with OpenClaw. One user action with openclaw may spawn dozens of LLM requests. Cost-per-inference has dropped, making it easy to deploy LLMs, and also easy to accidentally burn through API budgets. Multi-step agents and techniques like Ralph Loops with no token or turn limits can self-loop forever.

Attack patterns include flooding the API with max-context-length requests to maximize per-request cost, crafting prompts designed to trigger recursive or verbose responses, and prompt injection that triggers agentic loops consuming resources without termination.

To mitigate: implement rate limiting per user, API key, and endpoint. Set max token limits on inputs and outputs, both per request and per session. Set hard budget caps on AI API spending and alert before they’re hit, not after. Design agentic workflows with explicit termination conditions and maximum iteration counts.

Subscribe now

How to secure LLM applications: practical checklist

Here is every risk mapped to its most important mitigation action.

Honestly, I’d forward this to every engineer I know:

• LLM01 — Prompt Injection: Treat all external content as untrusted data, not instructions. Validate before acting on LLM outputs.

• LLM02 — Sensitive Information Disclosure: Mask sensitive data before sending to AI APIs. Audit what your AI tools can access.

• LLM03 — Supply Chain: Treat AI tooling as supply chain. Pin model versions. Audit tools used in regulated processes.

• LLM04 — Data and Model Poisoning: Vet training data sources. Use models with documented provenance. Monitor for behavioral drift.

• LLM05 — Improper Output Handling: Apply context-appropriate encoding on all LLM outputs before rendering or executing.

• LLM06 — Excessive Agency: Apply least-privilege to AI agents. Add human checkpoints for consequential actions.

• LLM07 — System Prompt Leakage: Design system prompts as if public. Test for leakage before deployment. Keep secrets in code, not prompts.

• LLM08 — Vector and Embedding Weaknesses: Mirror source document access controls at the vector store level. Validate documents before indexing.

• LLM09 — Misinformation: Treat LLM outputs as first drafts. Require authoritative source verification for security guidance.

• LLM10 — Unbounded Consumption: Set rate limits, token caps, and hard budget limits. Monitor inference costs in real time.

By the way, checklists are one of the most important resources to use AI. You can learn my experience with “read“ checklists and “do“ checklists in this other article

AI security in the real enterprise: what the OWASP list doesn’t tell you

The OWASP list describes risks. It doesn’t describe who gets blamed when they materialize.

We’re using AI tools all the time. When we ship fast, we only take partial credit for using AI, but the credits go to AI. When the AI tool misses a vulnerability, the developer get 100% of the blame. This asymmetry shapes how engineers should actually use AI: Aggressively for prototyping, conservatively when there’s accountability at risk. The struggle is that we don’t realize the asymmetry until something goes wrong.

Organizations are also deploying AI faster than legal and compliance teams can catch up. I’ve developed small tooling, like getting meeting transcripts, and only months later, I got a notice about the legal requirements for it and to switch to an approved tool. LLM02 and LLM06 risks often materialize not from malicious actors but from well-meaning engineers working around slow policy processes. No malice required.

Then there’s the review paradox. Using AI to pass to review is efficient, and I’d always encourage to use AI. But we can’t skip a human reviewing the AI review output. If the AI tool has its own supply chain risks (LLM03), and you’re using it to review a security standard, you’ve introduced the risk you’re reviewing against. This isn’t an argument against using AI tools for security reviews. It’s an argument for understanding what you’re trusting.

The biggest shift in 2026 is what agentic AI does to blast radius. If we go to the first OWASP list for LLM applications in 2023, it assumed the prompts were triggered by a human. A user submitting a prompt and reviewing an output. In 2026, agents act autonomously across multiple steps. These risks all become more dangerous when there’s no human checkpoint in the workflow.

Practically: figure out which of the 10 risks actually apply to your specific AI integration. They don’t all apply equally. Treat each AI tool used in a regulated process as a component requiring its own security review. Document your AI tool usage in your threat models.

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

Subscribe now

Common Questions about LLM Security

What are the OWASP Top 10 risks for LLMs in 2025?

The 2025 OWASP Top 10 for LLM Applications covers Prompt Injection, Sensitive Information Disclosure, Supply Chain, Data and Model Poisoning, Improper Output Handling, Excessive Agency, System Prompt Leakage, Vector and Embedding Weaknesses, Misinformation, and Unbounded Consumption. The full list is at genai.owasp.org/llm-top-10.

What is prompt injection in AI security?

Prompt injection is an attack where malicious input overrides an LLM’s instructions, causing it to take unintended actions. It can be direct (from user input) or indirect (from external content the LLM processes, like a web page or document). It is ranked the top LLM vulnerability because it requires no special access to attempt.

How is the OWASP LLM Top 10 different from the OWASP Web Application Top 10?

The OWASP Web App Top 10 covers traditional web vulnerabilities like XSS and SQL injection. The OWASP LLM Top 10 covers risks specific to large language models: prompt-based attacks, training data risks, autonomous agent behavior, and RAG system vulnerabilities. The two lists have overlapping mitigations but address fundamentally different attack surfaces.

What changed between the 2023/24 and 2025 OWASP LLM Top 10?

The 2025 update added System Prompt Leakage, Vector and Embedding Weaknesses, and Misinformation. It removed Model Theft, Insecure Plugin Design, and Overreliance, which were absorbed into other categories. The update reflects the rise of agentic AI and RAG-based production systems that weren’t widespread when the 2023 list was written.

Subscribe now

Conclusion: the AI you trust is the AI you’re responsible for

The code got shipped, and the feature launched. But the question stayed with me: What unknown unknowns may I be missing?

The OWASP LLM Top 10 doesn’t answer that question for you. It gives you the vocabulary to ask it precisely. It’s not a compliance checkbox, but a thinking tool. Use it to audit how you’re using AI tools for building.

Key Takeaways:

• The OWASP Top 10 for LLM Applications (2025) defines 10 security risks specific to large language model systems, updated from the 2023/24 list to reflect agentic AI and RAG deployments.

• Prompt Injection (LLM01) remains the top risk because it requires no special access and persists even when using RAG or fine-tuning.

• Excessive Agency (LLM06) and Unbounded Consumption (LLM10) are the defining risks of agentic AI in 2026, where autonomous multi-step workflows amplify every unchecked mistake.

• Sensitive Information Disclosure (LLM02) often comes not from model misbehavior but from engineers inadvertently feeding sensitive data into AI tools they trust.

• Three risks are new in the 2025 update: System Prompt Leakage (LLM07), Vector and Embedding Weaknesses (LLM08), and Misinformation (LLM09), each reflecting how production LLM deployments evolved since 2023.

Which of these 10 risks is already present in your AI workflow?

If you read until here, continue reading about how to scale your software development process to handle the surge of code of AI

References: OWASP LLM Top 10

• LLM01:2025 Prompt Injection

• LLM02:2025 Sensitive Information Disclosure

• LLM03:2025 Supply Chain

• LLM04:2025 Data and Model Poisoning

• LLM05:2025 Improper Output Handling

• LLM06:2025 Excessive Agency

• LLM07:2025 System Prompt Leakage

• LLM08:2025 Vector and Embedding Weaknesses

• LLM09:2025 Misinformation

• LLM10:2025 Unbounded Consumption

• Full 2025 list

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.

This is what harness engineering looks like in practice. You stop asking the model to do things it’s bad at. You give it the tools for the parts that require precision, you let the agent handle the parts that require judgment, and you instruct it not to jump in to do the job itself.

Subscribe now

The Four Pillars of Harness Engineering

My JSON automation project taught me the pattern to build a good AI agent, but the approach is generic. After studying how OpenAI, Anthropic, and other teams have built their own harnesses, I’ve identified four pillars that every production harness needs.

1. State Management

AI agents are stateless by default. Every API call starts with a blank slate. For a task that takes five minutes, this is fine. For a task that spans hours or requires following the updates of dozens of files, statelessness is bad. The agent forgets what it did 20 steps ago. It repeats the same mistake in a loop. It loses track of the overall architecture. This “AI amnesia” is the most common failure mode in long-running agent tasks, and it’s why Openclaw got very popular.

A harness solves this by serializing context snapshots and restoring them across sessions. Think of it as save points in a video game. The agent does work, the harness saves a snapshot, and if the agent crashes or hits a rate limit, the harness restores the snapshot and picks up exactly where it left off.

Advanced implementations use structured state objects that persist across runs. There are two main strategies here:

• Context Compaction, where the harness continuously summarizes the agent’s history as it approaches the token limit

• Context Resets, where the harness clears the window entirely and boots a fresh agent with a structured handoff of artifacts.

Both work. The right choice depends on your task length and coherence requirements.

2. Context Architecture (Progressive Disclosure)

The first agent-friendly codebases I saw produced gigantic AGENTS.md files. This approach fails for the same reason a 500-page employee handbook fails on someone’s first day. The agent gets confused, misses critical rules, and follows outdated instructions that were never cleaned up.

The better approach is progressive disclosure. Give the agent a short table of contents that points to a structured docs/ directory. The agent reads the table of contents first, then navigates to the specific document it needs for the task at hand.

This is the same pattern introduced with the Agent Skills standard. Instead of the early MCP implementations that loaded all the definitions above the user’s first prompt, let the agent find them when needed.

The agent gets a map, not an encyclopedia.

One more thing that is easy to forget: anything the agent cannot access in-context does not exist for it. Your Slack threads, Google Docs, and verbal agreements in meetings… None of that is real to the agent unless provided or instructed to fetch them.

3. Deterministic Guardrails

This is where harness engineering diverges most sharply from prompt engineering. Prompt engineering asks the agent to write clean code or make no mistakes. Harness engineering mechanically enforces it.

You’d need custom linters, structural tests, and CI jobs that validate architecture before merge.

The agent isn’t “discouraged” or “instructed against” skipping those. The agent is blocked.

• If a file exceeds a size limit, the linter rejects it.

• If a dependency flows in the wrong direction, the structural test fails.

• If the JSON output is malformed, the validation script prevents merging the PR.

The error messages in your custom lints and validations should include remediation instructions. When the agent hits a linter failure, the error message itself tells the agent exactly how to fix the problem. That error message gets injected directly into the agent’s context, creating a tight feedback loop that requires zero human intervention.

This was a realization of my early attempts in the agent that modifies JSONs. I was using JQ commands instead of Python scripts. JQ ended all possible failures with a 0 or 1 exit code. These outputs are intended for terminals, not for LLMs to recover from them.

One more thing worth noting: A “boring” codebase is better for agents. Stable APIs, predictable patterns, and simple architectures are far easier for agents to model than clever abstractions. Every layer of complexity you add to your codebase is a layer the agent has to navigate.

Keep it simple.

4. Entropy Management (Garbage Collection)

This is something most people skip. AI agents replicate patterns, including bad ones. Over time, your codebase accumulates “AI slop”: redundant logic, verbose implementations, subtly hallucinated variables that the model keeps copying because they exist in the context.

Left unchecked, this entropy degrades the entire codebase. People call it context poisoning.

Some people use this as an argument that AI is bad. But whenever I face a bad AI output, instead of judging if AI is good or bad for this task, I ask myself how can we make AI work here? The answer is usually adding another harness.

We can have a recurring cleanup agent. Think of it as garbage collection for your repo. For any implementation task, have a separate agent that scans the codebase, looks for drift from your golden principles, and fixes things before raising the PR. You can also execute this kind of agent on a schedule. Because you already designed other harnesses, like having unit tests and linters, you can allow AI to refactor code with confidence.

It is the same concept as a “doc-gardening” agent that scans for stale documentation and updates it. Technical debt is called like this becuase it works like money debt. If you pay it daily, you stay solvent. If you let it accumulate, you end up spending a lot of time later.

The harness should include entropy management from day one, not as an afterthought.

To know where to apply the harnesses, I covered a 3-level framework for AI-assisted coding in this previous post:

The Mindset Shift: From Prompts to Harness Engineering

The biggest change harness engineering requires is not technical. It is mental.

You stop writing prompts. You start designing environments. Your job is neither to write code nor to write the detailed prompts. It is to make the codebase legible to the agent. Every file name, every directory structure, every naming convention, every piece of documentation exists not just for human developers but for the autonomous agents that will read, modify, and extend the codebase at machine speed.

Constraints stop being restrictions and start being multipliers. A custom linter you write once applies to every line of code the agent writes, deterministically, and forever. A structural test you build today catches every future violation automatically. You invest once, and the return compounds with every agent run. That is the leverage engineers had for humans, and we need it for AI agents.

The engineers shipping the most code right now all converged on this independently. OpenAI’s internal team shipped one million lines of code and 1,500 PRs in five months using Codex with this approach. Anthropic’s Claude Code team has released 52 features in 50 days. My team at Amazon ships 100+ PRs per month. The patterns are the same: narrow the problem, use deterministic scripts at the execution boundary, enforce constraints mechanically, and make the codebase legible to the agent.

Learn the Building Blocks of AI Agents

If you want the full guide, let me know your email below, and I’ll send you the free “AI Agents Building Blocks” guide inside the newsletter’s welcome email

Subscribe now

Recap: Harness Engineering Key Concepts

What is harness engineering in AI?

Harness engineering is the discipline of designing the systems, constraints, execution environments, and feedback loops that wrap around AI agents to make them reliable in production. Unlike prompt engineering, which focuses on a single model interaction, harness engineering governs the entire agent lifecycle, from state management to automated validation.

How is harness engineering different from prompt engineering?

Prompt engineering crafts the input to the model in a single interaction. Harness engineering designs the entire environment the agent operates in: tools, guardrails, documentation structure, and automated feedback loops. The goal is reliable behavior across thousands of runs, not just one.

Why do AI agents fail on large structured files like JSON?

Large JSON files exceed or crowd out the model’s context window, causing the agent to lose track of the surrounding structure. It may correctly modify the target node but corrupt adjacent keys, producing a broken file. The fix is a deterministic script that handles the file surgery, with the agent only providing the intent.

How do you build a simple AI agent harness?

Start by narrowing the problem to one operation. Write deterministic scripts for the execution step. Wire the agent to tool-call those scripts instead of generating the output directly. Add a validation step that the agent cannot bypass (embed it in scripts if needed!). This three-part loop, intent to deterministic execution to validation, is the minimal viable harness.

What is an AGENTS.md file and why does it matter?

AGENTS.md is a file in your repository that tells an AI agent the rules, conventions, and architectural constraints of your codebase. It acts as the agent’s static context, injected at startup, so it knows your team’s norms without you having to repeat them in every prompt. Keep it short (under 100 lines) and use it as a table of contents pointing to deeper documentation.

Conclusion: The Harness IS the Product

The model is the easy part. Everyone has access to the same foundation models. GPT, Claude, Gemini, they are all remarkably capable. The harness is the hard part. The harness is what makes Claude Code, Cursor, and Codex ship production code instead of impressive demos. The harness is what separates a demo that impresses your manager from a production system that ships real code every day without breaking things.

Here is what I want you to take away from this article:

• Narrow the problem before you build the agent. A scoped agent that does one thing well beats a general-purpose agent that does everything poorly.

• Use deterministic scripts at the execution boundary. Let the agent provide intent. Let the script provide the guarantee.

• Enforce constraints mechanically, not verbally. If a rule matters, make it a linter, a test, or a validation step. Do not put it in a prompt and hope for the best.

• Make the codebase legible to the agent, not just to humans. Progressive disclosure, structured documentation, and the repo as the single system of record.

The engineers who figure this out first will have an enormous advantage. Not because they have better models, but because they have better harnesses.

Subscribe now

If you read until this point, you have to read this other article with the AI concepts every software engineer needs to know in 2026:

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:

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.

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

Subscribe now

I have spent many hours watching those “Day in the Life” videos on YouTube. I’ve been watching them since I was a student and dreamed about working in big tech.

Most of them are set in the US, usually featuring engineers in the Bay Area or New York.

While they are entertaining, I think people often miss the point that Big Tech is almost everywhere in the world. You do not have to be in Silicon Valley to have an interesting and challenging engineering career.

I’d like to bring that same energy to my newsletter. My goal is to provide a raw and realistic look at the Big Tech experience right here in Spain.

There’s no bragging intended in this post. I simply want to offer some inspiration and a personal connection to those curious about how we work and live in Madrid.

I wanted to try to write something different than usual, so I hope you enjoy it!

In this post, you’ll learn

• The step-by-step daily routine of a Software Engineer at Amazon living in Madrid.

• How I balance working on this newsletter with a full-time Big Tech role.

• A small piece of my life!

5:50 - Wake up

My day starts while everything is still quiet. Some time ago, I’d wake up around 6:30 out of my own choice because it gave me a sense of control over my schedule. It was the only part of the day when nobody was asking for my attention, and I could focus entirely on my own goals before the corporate world woke up.

Now we wake up at this time because my girlfriend goes to work very early and she works in two halves. Her morning shift starts pretty early.

I’ve realized there are small habits I can make to feel more awake in the early morning

• Drink lots of water

• Get some fresh air, even if there’s no sunlight yet

• Move myself or do some light exercise

After my girlfriend leaves, and depending on how tired I am or how badly I slept, I’d go to bed for one more hour or start my day.

7:00 - Start working in newsletter

I may still be a bit asleep, but that’s even an advantage. It’s the time my brain isn’t racing with so many thoughts.

From 7:00 AM until I have to leave for work, I dedicate my time to planning and writing for this newsletter. Besides working without distractions with a clear head, it’s the only time in my day that I have for a personal project.

I really try not to skip this block of work unless I’m too tired from previous days. It is a way to ensure that I am moving forward with my own projects alongside my main job. By the time I finish this session, I already feel like I have accomplished something significant before the official workday even begins.

Before I had this newsletter, I felt like I was living the rat race, and had more negative thoughts about work and the life I wanted to live. Now, I have control, and if I achieve more or less, it’s in my control.

This is what I see from my window during this block of work. We bought our apartment recently, and I always feel inspired by the views. In the previous two apartments I rented in Madrid, I had to get my head out of the window to see the sky. Now I see mostly sky :)

8:30 - Go to work. Commute by train

At 8:30 AM, it is time to transition into my professional role. I head out to the train station to catch the train. Luckily, we bought an apartment that is just 200 meters away from both the metro and the train.

Just 4 months after I started working for Amazon, there was little guidance about working on-site or remote due to the COVID pandemic, so I moved back to my parents’ house in the south of Spain and worked 100% remotely. At first, working back in the office was hard, but now I enjoy listening to podcasts during my commute.

Some people complain that the train system in Madrid isn’t reliable. It’s true they usually don’t meet the schedule. The good part is that from my origin to my destination station, there are 3 different train lines that can get me to the office, so usually I don’t wait too long.

Commuting takes around 45 minutes, so I have time ot listen to some podcasts.

9:30 - Usually arrive at work

I typically arrive at the office around 9:30 AM. Amazon has multiple offices in Madrid, the one for our team is located under the Retiro park, and it’s pretty well communicated. I walk the final few blocks from the station and grab a banana or two when I arrive at the office.

Amazon office is on only one side of the building, and in the middle, there’s a small garden. Here’s a picture of it

Once I get to my desk, I spend the first few minutes authenticating in multiple sites, checking emails, and scanning Slack messages for anything I should check right away.

Most of my colleagues arrive around this time as well, so it’s a great moment for a quick social check-in before we dive into our first meeting.

I’m starting to experiment with using AI Agents for productivity. I let it scan my calendar for meetings and scan a local database of tasks. My TODO-list was always growing, so I’m trying to use AI to manage my work better.

So I’d start asking my AI Agent: “Give me my daily plan for today.”

10:00 - Daily Standup

Our daily standup is at 10:00 AM. We discuss what we did yesterday, what we are working on today, and any blockers that might be standing in our way.

Most times, there are 1 or 2 pressing problems for the team. Sometimes they impact my work for today or not, but it’s always good to be on top of what’s going on for our team, not only for myself.

In the end, we don’t work on isolated projects. Anyone may need to work on any task, and we’re on-call for all our services, so it’s important to catch up.

11:00 - Work in the morning

After the standup and maybe some light meeting or 1:1, I dive into my first real block of work. I may start with a smaller block for some code review or a document.

The way I decide if I review something or not is based on the impact of that review: Am I blocking someone if I postpone doing reviews? If yes, I’d review the right way. If not, I’d start with my own work.

I’d like to say that I strategically design my work to work on the most complex thing in the morning, but usually I go with whatever is the next step in the work I have on my plate. I try to minimize distractions during this window to make the most of my morning energy.

I use the same trick at work and home: I put my phone behind the laptop’s screen. This way, I don’t have it visible, I don’t sense it in my pocket. But still, I’d hear a phone call if I’m expecting any (although most of the time my phone is in do-not-disturb mode permanently).

This is the time I do the most work of the day. Any longer team meeting is usually in the afternoon, and meetings with other teams are also in the afternoon. I work mostly with teams in the US, and their morning is my afternoon/evening.

Read more

Subscribe now

Setting up a new AI agent often feels like building a custom bridge for every single stream you need to cross.

I’ve plugged different APIs and scripts to LLMs to do operations. This is a common story for software engineers today who find themselves repeating the same integration patterns for every new project or data source.

Before November 2024, the industry suffered from an integration problem: every model required connectors for every enterprise data source.

The industry needed a standard. The Model Context Protocol (MCP), introduced by Anthropic and now governed by the Linux Foundation’s Agentic AI Foundation, established an open-source communication layer that collapses this integration matrix from M*N (M LLMs, N connectors) into a standardized framework.

I wrote here about an AI tool I built. I did that one with an MCP server. In this case, I was up to date with what was new, but I definitely didn’t know how to use it.

Also, there have been a lot of changes to the MCP protocol, so it’s worth diving deep into it.

In this post, you’ll learn

• How MCP evolved from a simple data-fetching protocol into an enterprise-grade autonomous framework.

• The core architecture of the client-host-server model built on JSON-RPC 2.0.

• How asynchronous Tasks and Agentic Sampling are shifting orchestration to the server.

• The technical mechanics of interactive MCP Apps and client-side Web MCP.

• How Zero-Trust security (CIMD and XAA) handles identity at enterprise scale.

MCP Model Context Protocol Status in 2026

Since Anthropic first released MCP in November 2024, the protocol has evolved rapidly. Here’s the current status as of 2026:

What changed in the March 2025 update:

• Streamable HTTP replaced Server-Sent Events (SSE) as the default transport. This is simpler to deploy, easier to debug, and works behind corporate proxies.

• Audio Content Support was added, extending MCP beyond text and images.

• Tool Annotations introduced safety guardrails. Servers can now mark tools as read-only or destructive, so hosts can enforce approval workflows.

What’s new in 2026:

• MCP Tasks allow servers to run long-lived background operations and report progress. This is a shift from request-response to autonomous workflows.

• Enterprise adoption is accelerating as companies standardize their AI agent infrastructure around MCP instead of building custom connectors.

• The context window crisis is being addressed through Tool Search patterns and Lazy Loading, reducing token consumption from 70,000+ to manageable levels.

The protocol is no longer experimental. It’s becoming the standard communication layer between LLMs and enterprise data sources.

What Is MCP? The Model Context Protocol Explained

The protocol operates on a strict client-server architecture built upon JSON-RPC 2.0 messages, so it has stateful, bidirectional communication.

By separating the LLM reasoning from a programming language deterministic execution, MCP allows you to swap models or data sources without changing your underlying integration logic.

There are 3 parts:

• Hosts: The user-facing LLM applications (e.g., Claude Desktop, Cursor, or specialized IDEs) that manage the agentic loop.

• Clients: The internal routing connectors within the host that manage protocol connections.

• Servers: The external services (Postgres, GitHub, Slack) exposing specific capabilities via standardized primitives.

The standard originally launched with three foundational primitives:

• Tools are the executable functions that allow my agents to actually do things in the real world. They require explicit user approval for destructive actions, making them perfect for AI automation, but with some guardrails.

• Resources act as read-only data sources that provide models with contextual information. They are URI-addressable, which means I can point an agent to application logs or real-time metrics.

• Prompts are the structural templates to standardize how to interact with these models. This is a way to vend in the MCP server not only the functionality, but also how to use it.

MCP in Practice: How Hosts, Clients, and Servers Connect

I wrote here about the 10 steps to build an AI agent. One of them was plugging in MCPs.

In that example, I was doing some configuration changes configured in a Jira ticket and raising a PR. So one of the MCP servers I used was for Jira access, which meant I no longer had to copy-paste from Jira into my LLM of choice, but I just had to write “Implement Jira-1234“.

The Future of MCP: From Data Fetching to Autonomous AI Agent Workflows

It’s crazy to think we’ve been little more than a year with MCPs around. The initial release focused on basic connections, and I think that’s where everyone stopped reading about the protocol. But there’s more

The March 2025 update replaced brittle Server-Sent Events (SSE) with Streamable HTTP. This unified bidirectional communication over a single endpoint (/mcp), allowing enterprise WAFs to inspect payloads while supporting robust session resumability via the Mcp-Session-Id header.

Data modality also expanded to include Audio Content Support, allowing agents to interface directly with voice analysis and TTS APIs. To guarantee safety as tools became more powerful, Tool Annotations (readOnly and destructive) were introduced, programmatically obligating host applications to trigger human-in-the-loop (HITL) warnings before executing high-stakes actions like database deletions.

MCP for AI Agents: Enterprise Adoption in 2026

MCP for AI Agents: Enterprise Adoption in 2026

The biggest shift in MCP’s trajectory is enterprise adoption. In 2024, MCP was a developer tool. In 2026, it’s infrastructure.

Why enterprises are adopting MCP for AI agents:

1. The M×N problem is real at scale. A company with 5 LLM providers and 20 internal data sources would need 100 custom connectors without MCP. With MCP, each data source exposes one server, and every LLM connects through the same protocol. That’s 25 connectors instead of 100.

2. Security and compliance. Tool Annotations let enterprises enforce approval workflows before destructive actions. Read-only tools can run without human oversight; write tools require explicit approval. This maps directly to enterprise governance requirements.

3. Vendor independence. Because MCP is an open protocol (not tied to a single LLM provider), enterprises can swap models without rebuilding integrations. Your Postgres MCP server works the same whether the host is Claude, GPT, or an open-source model.

4. Agent orchestration. MCP Tasks enable agents to kick off long-running operations (data migrations, batch processing, multi-step workflows) and check back for results — a prerequisite for truly autonomous AI agent systems.

The companies moving fastest are those that have already standardized their internal APIs. If your services already expose clean REST or gRPC interfaces, wrapping them in MCP servers is straightforward.

Solving the MCP Context Window Crisis: Tool Search & Lazy Loading

A critical bottleneck in early MCP integrations was context window pollution.

MCP tools are loaded at the top of your conversation with the LLM, same as the system prompt (in your IDE, these are the rules you define to always apply).

You may think that you’re consuming a small piece of the context window with a prompt like “explain @FileA and @FileB“, but here’s the reality:

Loading 50+ tool definitions could consume 70k+ tokens before a conversation even begins, leading to degraded reasoning.

MCP client implementations like Claude Code are resolving this with the Tool Search Tool pattern, where you only load a tool to search other tools, and implementing Lazy Loading. By setting defer_loading = true, the system withholds verbose schemas until the model expresses intent.

I think it’s just about time that it gets into the standard and everyone applies the same, similar to how “Agent Skills” are loaded on demand.

MCP Tasks: The Biggest MCP Update in 2026

Read more

Software engineering has always been about managing abstractions and protocols. The transition to AI-integrated development is no different. To build reliable systems, we must move past the hype and master the technical foundation behind these models.

This post provides the essential terms for the modern AI engineering stack.

A shared language is the only way to move from brittle experimental projects to production-ready systems. Vibes are great, but it’s time to start engineering.

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

Subscribe now

In this post, you’ll learn

• The technical foundations of modern foundation models and their learning processes.

• How to manage context and tokens to avoid reasoning degradation.

• The protocols and architectures that allow AI agents to interact with external tools.

• Modern development paradigms and verification strategies for agentic workflows.

Foundations

Foundation Models & LLMs

Foundation Models are the base layer of our new stack. These models are trained on massive, diverse datasets, allowing them to adapt to a wide range of tasks without needing to be built from scratch. Large Language Models (LLMs) are a specific type of foundation model that has been optimized for processing and generating human language, although modern versions are increasingly multi-modal, handling text, images, and audio seamlessly.

The Transformer Architecture & Attention

The Transformer Architecture is the core algorithmic discovery that made modern AI possible. By using a mechanism called Attention, these models can process all parts of an input sequence at once instead of reading word by word. This parallel processing allows the model to understand complex relationships and nuances in code or text that earlier techniques would miss entirely.

Training, Fine-tuning, and RLHF

Training is the process of building the model’s base intelligence. Pre-training establishes general knowledge across the internet and books. Fine-tuning is a post-training technique where you perform additional training on specific data, like your company’s codebase, to specialize the model. RLHF (Reinforcement Learning from Human Feedback) is then used to align the model’s responses with human intent and safety standards, ensuring the output is actually helpful for a developer.

Inference & Tokens

Inference is the act of running the model to generate a response. The cost and performance of inference are determined by Tokens, the basic units of data the model processes. Modern engineers must track Token Windows (the model’s memory limit, aka Context Window or Context Memory) and use Cache Tokens to minimize latency and cost by reusing frequently used prompt prefixes. Performance is boosted when inference is optimized, like OpenAI’s Codex 5.3 spark running on 1k tokens/second.

Subscribe now

The Interface

Prompt Engineering & Prompt Libraries

Prompt Engineering is the systematic practice of crafting inputs to get the best possible response from a model. It involves more than just writing instructions; it includes managing Prompt Libraries, which are versioned, tested collections of prompts used across a team or application to ensure consistent and high-quality outputs.

Static Context & Dynamic Context

Context management is the most important factor in model performance. Static Context refers to stable, long-lived information like your entire codebase or architectural standards. Dynamic Context is the temporary, task-specific information for the current interaction, such as current problem descriptions, intermediate code versions, and debugging information.

Multi-Turn Conversations

Multi-Turn Conversations involve multiple round trips between the human and the machine. This back-and-forth interaction is what enables agentic behavior, allowing the AI to maintain state, plan, and adapt dynamically to new information over the course of a session.

Hallucinations & Grounding

A Hallucination occurs when an AI model generates factually incorrect or fabricated information. To prevent this, engineers use Grounding, the process of providing the model with verifiable facts and context (via RAG or MCP) to ensure its responses are based on reality rather than its training weights alone.

Subscribe now

The Action Layer

Read more

Subscribe now

Most engineers fall into a trap. They think productivity means staring at a screen for 12 hours.

Real senior engineering is not about working longer. It is about quality. It is about leverage.

This post is not just about writing code. It is about optimizing your cognitive performance.

Productivity isn’t about discipline. It’s system design.

In this post, you’ll learn

• How to optimize sleep and diet for cognitive performance

• Methods to raise the quality of your technical work.

• Techniques to document your impact for career advancement

Health

Consistency over intensity: You cannot catch up on sleep debt. A consistent schedule works better. This improves how your brain solves hard problems.

The “Sleep on it” debugging method: Spending two hours debugging on a Friday evening often yields nothing. Returning on Monday usually solves the problem in 15 minutes. Rest resets your context window.

Eat “Real” Food: Avoid the pizza and soda stereotype. Eat food found in nature, like vegetables, meat, or fish. This avoids glucose spikes that lead to afternoon brain fog.

Don’t Break the Chain of Exercise: Exercise is for mental clarity rather than muscles. It is better to do 20 minutes daily than to destroy yourself for 3 hours on Sunday.

Energy management: Track your energy levels. If you peak at 10 AM, then schedule deep work at that time. If you crash at 2 P,M use that time for low cognitive tasks like admin or email.

Environment Design: Working from a cramped kitchen builds resentment. Optimize your desk setup to induce a flow state. Create an environment that you enjoy being in while working.

Subscribe now

Technical

Don’t be a human linter: Automate style checks. If a machine can catch it, then a human should not waste calories on it.

Focus on the “Hard” stuff: Spend code review energy on design patterns, bugs, and non-negotiable changes. Prioritize boring and maintainable code over shiny new tech.

Read before you write: Prevent spaghetti code by understanding existing patterns. Spending half an hour reading can save hours of refactoring.

Data Structure Driven Development: Do not start typing code. Start with the data. Define the structures and flows first. The code becomes a trivial implementation detail. Code should be simple enough that you can draw the high-level flows on a whiteboard.

Read more

Subscribe now

Software engineering is perceived from the outside as writing tons of code and solving tons of technical problems. The reality for most developers is that the job consists of constant micro-decisions that drain mental energy. You constantly ask yourself when you should review a pull request or if you should fix a bug before reading the documentation.

Every time you ask yourself when to do something, you deplete the brain energy needed to solve complex algorithms.

The cost of this continuous negotiation is high. You end up with decision fatigue before you even start the deep work that actually drives value. The mental load of managing your schedule becomes a second job that distracts you from your primary responsibilities. This leads to a state of exhaustion where you react to urgent requests instead of following a strategic plan.

The solution to this problem is the productivity technique I’m bringing today. It separates the planning phase from the execution phase. The goal is to transform your work from a series of negotiations into a simple script that you simply execute.

Take Bryan Johnson, the guy who wants to live forever. He realized his evening self, whom he called evening Bryan, was making tons of bad decisions because he had less energy later in the day. Instead, morning Bryan said “you’re fired“ to evening Bryan. He made the decisions ahead of time to prevent making bad decisions. He separated planning from execution.

Note: This is backed by psychology by the concept of “implementation intentions“. We are more likely to stick to something when we clearly name when, where, with whom… We’ll do something. Also similar to the concept of “Autopilot schedule” from Cal Newport.

In this post, you’ll learn

• How to reduce decision fatigue

• Strategies for batching communication and admin tasks.

• Methods to protect your peak energy hours for deep work.

• Ways to systematize recurring decisions to reduce friction.

The core algorithm (separate planning from execution)

You can begin by creating a default calendar that represents your ideal week. This template serves as the norm for your schedule, and any chaotic weeks are treated as exceptions. It prevents you from dwelling on tasks because you know they have a specific slot later in the day. You do not have to carry the mental load of a task all day when you know it will be handled at a specific time.

Constraint-based productivity relies on the principle that work expands to fill the time available (Parkinson’s law). You force efficiency by fixing the time available for specific tasks. You might prioritize delivering the most important work in a one-hour block and reduce non-essential activities. This approach helps you focus on impact rather than just filling hours with activity.

The mindset shift requires you to stop trusting your brain to find time later. If a task matters, it gets a specific slot on your calendar. You do not need to be overly granular, but you must reserve specific blocks for activities like email or code reviews. I reserve a minimum of fifteen minutes for any calendar block to ensure they get done without encroaching on other work.

Also, be realistic. Creating a default calendar shouldn’t be about what you wish (doing a lot of work in little time), but about rearranging your existing calendar to better suit your needs.

Handling the “shallow” stack

A lot of people say to start “eating the frog“, which means to start with the hardest, most important task. I usually procrastinate starting if I start with something hard, so I found something that works better for me.

Read more

Subscribe now

Most engineers only chat with AI. They treat LLMs like a smarter search engine or a junior developer they have to micromanage. A better Google.

They are operators, not designers. They spend their days copy-pasting context, refining prompts, and reviewing code line by line. This approach hits a ceiling quickly. You can only type so fast. This is not so different from the era of pasting the code snippets to an AI chat in a web browser and copying back the results to code. We have now AI in the IDE and terminal, but we keep using it in the same way.

The real goal is moving from manual prompts to a fully autonomous companion agent that runs in the background.

My journey, like most people who automate anything, started with frustration. I was manually fixing boring tickets and operating the system. I realized I needed to shift my role. Instead of being the one doing the work, I had to design the systems that do the work. But of course, my manager expected the work to get done, so I couldn’t ask for a week or two to automate things and do no other work.

I built a team of agents, including a TPM triaging tickets and pinging for more information, a Developer implementing them, and a Reviewer addressing the comments humans leave. This literally is saving my team the capacity of more than 1 engineer from doing trivial but tedious changes that, before, were distributed among everyone to make it bearable.

After seeing the results, I realized it’s not only applicable for trivial changes, but to any part of your workflow.

In this post, you’ll learn

• The 10-step process to move from manual prompting to fully autonomous agents

• How to use MCP servers and how not to use them

• When you need more than one agent.

• How to define your role as the human in the loop

The process

The best way I found to do this process is to do the work multiple times. If you want to automate a particular type of ticket your team executes, ask your team to let you handle all those tickets for a while so you can develop the automation.

If you’re jumping too much between roles, you won’t have enough time and tickets to automate them properly. I warn you, the first steps you’ll spend 2x or 3x the time you’d spend if you did this manually, like you already know. But this is an automation that will run forever, including when you’re sleeping. It’s worth the cost

Subscribe now

1. Learn the manual process first

You cannot automate what you cannot describe. This is the most common mistake engineers make. They try to build an agent for a task they do not fully understand themselves. The result is a flaky script that fails on most edge cases.

Do the task yourself without AI once. Write down every decision point. If you cannot write a checklist for it, the AI will fail. You need to identify the inputs, the decision logic, and the expected outputs. This manual pass reveals the hidden complexity that you usually handle on autopilot.

Of course, start with happy paths, don’t start with the most complex edge case for this kind of work. You can enrich the automation you’re building with edge cases later.

Subscribe now

2. Solve it with manual AI prompts

Prove the concept before building the system. Once you understand the process, execute the task using manual prompts in your chat window. Do not try to build a complex agent yet. Just use your chat client.

Keep delivering work for your team, but refine the prompt with each ticket. You are identifying where the agent hallucinates or misses context, and updating your prompt for the next ticket. You will find that the agent often fails because it lacks information you thought was obvious. Refining the prompt manually allows you to fix these gaps quickly, and you’ll realize where AI by itself can’t solve the problem.

For my use case, the hardest part was about AI not being able to read, parse, understand and take action on complex JSON files. Also, I kept doing many manual work, posting comments in JIRA tickets, and moving between states in a kanban board.

Subscribe now

3. Plug in MCP servers

Stop copy-pasting data between your browser and your IDE. The biggest friction point in manual prompting is context switching. You act as the glue between your ticket tracker, your code repository, and the LLM.

Connect MCP tools (the MCP standard) that allow the AI to take actions you were doing in the browser. You can use MCP servers to update JIRA tickets or comment on GitHub issues.

Now, all execution can happen inside your terminal or IDE. The agent can now fetch the ticket description directly. It can also post its findings back to the ticket without your help.

Subscribe now

4. Create agent skills for repeated prompts

Don’t re-prompt the same context every time. After 2-3 iterations on tickets for the same kind of changes, you will notice that you are pasting the same instructions over and over. This is inefficient and error-prone. AI is great at planning but bad at reading ten thousand lines of logs.

I used to keep a prompt library with the prompts that I used for each kind of task. It was a good way to keep improving the prompt and have the benefits of iterations and a feedback loop. The problem was that again, I was the bottleneck, copy-pasting between one window and another.

Write specific skills (the skills.md standard) that allow the AI to do what the prompt describes. For the things that AI can’t do well enough by itself, create scripts to take complex, deterministic actions.. You do not need a fancy MCP tool for everything. A simple bash script wrapped as a skill works wonders. I used this to

In essence, a skill is

1. Something the AI learns to do.

2. It contains knowledge (markdown files), scripts to take actions (e.g. python or bash scripts), and resources or assets it can reference.

3. You can wrap MCP tools and scripts as skills. They enrich the MCP tool or script with context regarding how to use it. Even if the AI can execute commands in a terminal, it’s better to give it the building blocks with scripts than to let the AI generate those on every execution

My example with the JSON files:

• SKILL.md

• ADD.py

• FIND.py

• REMOVE.py

My example of handling JIRA tickets:

• SKILL.md and other markdown files -> Contains instructions to use JIRA MCP tools, regarding the status transitions in my workflows, regarding the projects and boards to use, etc.

  Subscribe now

5. Orchestrate with an agent SOP

Read more

Subscribe now

The AI landscape for software engineers is overwhelming nowadays. Every week brings a new benchmark winner. Keeping up with these releases feels like a full-time job. You might feel the need to manage five different subscriptions just to stay relevant in the industry.

There are two kinds of markets, and the research will determine which one AI is in the end:

• In a winner-takes-all market. The gap between the best tool and the second-best tool is usually massive. This means you always want to be with the best player available.

• Commodity market: The cheapest one that does the job wins. For example, electricity. You don’t care where it came from and who obtained it; the value is the same.

Because the market moves so fast, the best player often changes every six months. AI was behaving like a winner-takes-all where ChatGPT was king, but if all big players keep having these similar results, it will become a commodity like it’s happened in the last year.

This guide is not about which specific tool you should buy today. It provides a framework for how to buy them to maximize your return on investment. You can avoid subscription fatigue while staying at the top of your professional game.

In this post, you’ll learn

• How to manage subscriptions in a fast-moving market.

• Something that matters more than benchmarks.

• Strategies to treat AI tools as professional costs instead of entertainment costs.

• The benefits of using your own API keys

The golden shopping rules for AI tools

Rule #1: The “No-Annual” AI Plans

Never commit to a yearly subscription for an AI tool, even if the company offers a twenty percent discount. Software moves too fast for long-term pricing plans to make sense for individuals. If a tool rises fast, it can fall just as quickly. Flexibility is king in this environment. You must retain the ability to jump to a new tool.

Rule #2: Workflow > Benchmarks

Do not switch tools just because a company releases a new model with slightly higher numbers on a leaderboard. Ignore the PR hype from companies (and from people on social media). You should prioritize the user/developer experience over benchmarks.

A model can have a better score in a benchmark for two reasons

1. The model is really more intelligent

2. The benchmark is saturated. New models are trained in similar problems, and the benchmark is not a good measure of a model’s intelligence anymore

Using Cursor with an older model will likely be superior to pasting code into a smarter web-based chat. The deep integration with your IDE saves more time than a slightly smarter model.

And even if a web-based model is truly better, you can use it to create a plan and then move back to your AI-powered editor. Do not break a workflow that works for you just to try the new hype. I tried Raycast only to realize I prefer the workflow I already have in Alfred; the effort of switching wasn’t worth the potential incremental gain.

Avoid the shiny object syndrome

Rule #3: Beware of “Model Wrappers”

Read more

• I wrote a detailed performance review feedback in 2 hours instead of 6.

• I refactored massive code reviews in minutes rather than days, and I used an LLM properly to iterate through the write-compile-test loop.

The immediate feeling is intoxicating. You feel like you are moving ten times faster than you were a year ago. It feels like you have acquired a superpower that scales your output.

My realization point came when an engineer wrote a document to propose a fix to a problem in a service when traffic was high. The document was 100% AI-generated, it looked professional, and the grammar was perfect. It followed our templates and used the correct terminology.

However, as I probed the logic during the review, it crumbled. The solution proposed didn’t make sense for the problem. This engineer had “rented” the knowledge to create an output. He could not explain the trade-offs because he had not made them. He had accepted the default path the model predicted.

This made me realize we are facing a new career crisis. AI makes strong engineers move faster, but it makes inexperienced engineers move with dangerous confidence. We are at risk of creating a generation of “Hollow Seniors” who look productive on Jira but lack the fundamentals to debug a system when the predictive text fails.

This post outlines a system to decide what knowledge to rent, doing “just-in-time execution”, and what knowledge you must own, “just-in-case learning”.

Note: We can also understand “just-in-time learning” as active learning: Instead of reading a book without writing a line of code, you learn by doing. In this post, I use “just-in-time execution” to refer to borrowing knowledge from an AI output without actually learning.

In this post, you’ll learn

• The difference between “it works” and understanding the trade-offs.

• A decision framework to determine which technical topics require deep study versus delegation.

• How to use the “Feynman Prompt” to force AI to quiz you.

• Why the “T-shaped” engineer model is obsolete.

The problem: why Just-In-Time execution alone won’t get you promoted

The “Hollow Senior” trap occurs when an engineer relies exclusively on AI for execution and neglects the development of intuition. AI excels at this. It can write a function or generate a SQL query in seconds. However, senior roles require intuition. Intuition is essentially compressed just-in-case learning. It is the ability to predict where a system will break before you write the code. AI inference isn’t fast enough to be faster than intuition during an outage. You need to know where to look immediately.

There is an illusion of competence that comes with using LLMs. We must remember that AI is a prediction engine, not a truth engine. If you describe a scenario like a sci-fi movie where an AI takes control, it will follow that role.

I recently found a misconception with the “Anthropic Blackmail” findings. The news said AI blackmailed someone in the company, threatening to expose his infidelity if they unplugged the AI. It looks like Skynet is turning against humans.

The original system report indicates something different.

Read more

Subscribe now

Common productivity advice suggests that you should never multitask. This is a nice idea in theory: You hide in your cave, work on a feature, and come back when finished. It fails completely in practice for modern software engineers:

• You are on an on-call rotation.

• You must review pull requests from your peers.

• You attend meetings that fragment your day.

• You write code that takes time to build and deploy.

The expectation of pure single-tasking is a fantasy. It ignores the reality of the job.

The real enemy is not the act of doing multiple things. It is uncontrolled context swapping. Your brain spends more “CPU cycles” loading and unloading context than it does processing the actual logic. You end up exhausted at the end of the day with very little finished work to show for it

Has this happened to you?

Many people think productivity is a discipline problem. It’s not. It is a systems design problem. You don’t need more willpower. You need a better system to manage tasks. You can apply concepts from CPUs to your own work habits.

This approach helps you deliver high-quality code without burning out. Let’s look into it!

In this post, you’ll learn

• How CPU concepts help us manage our attention span.

• Techniques for creating mental save states to prevent data loss.

• Strategies for pipelining and batching tasks to maximize throughput.

• Ways to align work intensity with energy levels.

The architecture of attention

You likely face the Slack problem every day (or any software you use). Interruptions are like a forced kill signal to your current thought process. Most engineers operate in a system where the priorities are set by their communication tools. The loudest notification wins your attention immediately. This is a flaw, in my opinion.

These interruptions are not harmless context switches. They are traps that offer no opportunity to save your current state. You drop everything you are doing in the middle of a complex thought. This, sadly, results in data loss. You lose the thought process you spent twenty minutes building. You then spend another twenty minutes rebuilding it later. This is an inefficient use of your processing power.

Your brain should function differently. You should choose when to yield control to an unplanned task. This is moving from a push-based model to a pull-based model (more about these models in this other article). You ignore notifications in the moment, and not for too long, so people don't complain about your lack of responsiveness. You check for updates during designated downtime, like when you just submit a PR, while waiting on a build... This puts you back in control of your execution flow.

Doing two things at the same time is already problematic, like doing two different changes in the same codebase. However, switching between unrelated domains creates a big cold start. The cost of this switch is high because the mental model is entirely different; you need to unload and load new data. You cannot jump from debugging a race condition to discussing quarterly goals without a penalty. Better to minimize these cold starts to maintain performance.

Subscribe now

Implementing “safe points” and mental registers

We can borrow a concept from the Java Virtual Machine known as safe points. The garbage collector waits for a thread to reach a safe point before it pauses execution. The idea is to never switch tasks in the middle of computation. You must define your own yield points instead. These could be all tests passing or a PR submission, whatever works for you.

Thanks to stopping only at these logical breaks, you are preventing data loss. I know humans don’t have internal registers or stack frames, but we forget things when we switch tasks, so we need a solution. That’s why we should externalize this. We need to create a small state dump before you yield a task. This records both the last work done, the current work (in case we yield because you’re waiting on something), and our next steps.

A good advice I have for everyone is to write concise bullet points instead of lengthy details. The simpler the system, the more likely we are not to skip it. But write all the bullet points needed, don’t rely on your memory. If in doubt, I’d lean toward writing more than needed. Do this as if you’d hand off the task to someone else. That will make sure you won’t forget about any step in the process.

I keep a small markdown file for this purpose. It acts as my working memory. I write for each “workstream” the past/present/future as I mentioned before. I also record other small TODOs that I have to do, even if they aren’t part of a bigger project (e.g., review Daniel’s PR). This scratchpad gives me peace of mind, I don’t have to remember everything in my head.

This post is all about the world not being perfect. So let’s see the different scenarios we may have

1. A task can be started and finished within one time block, without interruptions. For example, reviewing a PR from a peer, you may be able to finish it and just leave it approved, or leave the comments. If it needs another review in the future, it will come as a new item when you receive a notification or email, so no need to worry about it anymore. Mark it done in your scratchpad (your TODO list)

2. It can’t be finished because you have a hard blocker (e.g., a meeting). As the blocker is planned, just capture the details in the scratchpad and switch to the other thing

3. It can’t be finished because you get unexpectedly interrupted and can’t avoid it (e.g., someone in person or a pager). Because you capture the past/present/future, your scratchpad already reflects that you were working on this. In this situation, which is far from ideal, I’d just recommend dumping your first thought next to the item, take 20 seconds for it, and move to the urgent thing. It’s not perfect, but as you’re the one coming back personally to the interrupted task, you’ll be able to grab the context faster thanks to being the one writing this small snapshot of the status.

   1. Also, if the interruption is just a couple of minutes and you’ll go back to your original task, capture down your past/present/future of any new work this interruption gives you. This also works great because the requester will feel acknowledged when they see you captured in your scratchpad their request.

The goal is that you always close your loop of that task and later come back to it. I’ve also been on the other side, someone talking to me in person, a page, a meeting’s autocall sound before I was finished... If you just switch tabs or close the laptop, you will lose data.

Even if not perfect, always follow these two principles

1. Write somewhere the progress of your work and the next steps.

2. Try to close your loop. Take 20 seconds to persist where you left off.

For example:

Subscribe now

Prioritizing and batching

You must distinguish between the big rock and snacking. Small tasks like answering emails or minor code reviews feel productive because you can do a lot of those during the day. They distract you from high-return work. You should focus on one big problem. You cannot juggle four small rocks effectively.

Identify the work that really matters today. I want to be careful, so the message isn’t that you should be selfish and prioritize always making a direct impact through your tasks in a sprint. Some days, the most important work is reviewing a critical pull request from a peer. On other days, you must prioritize your own big impactful work. You must be clear about what the important work is before you start jumping between small tasks.

Sometimes, you might start a task that requires input from someone else. You will have trouble if you delay this task until the deadline. That’s why here, the best action is to break down the work and prioritize the action to trigger the external communication. You wait for the response and forget about this workstream until you get notified that this work is available. Once it’s available, whenever you can pick it up, you’ll work on it again. Of course, the longer the task will be without your attention, the more details I’d add to the before/current/after state dump.

Read more

Subscribe now

Most engineers are not tired because they write too much code. They are tired because they fight too much friction. We often treat productivity as the ability to do more things, doing them faster. In software engineering, this definition is wrong. True productivity is about solving hard problems effectively.

There are invisible habits that drain your executive function battery before you even write a single line of code. We must stop optimizing for busy work and start optimizing for impact.

Productivity isn’t about discipline. It’s system design.

In this post, you’ll learn

• Why context switching destroys your ability to write code.

• How to prioritize business value over urgent but trivial requests.

• Techniques to manage your mental energy and reduce decision fatigue.

• Why adding more developers to a project often slows it down.

Context switching

It takes approximately twenty-three minutes to regain deep focus after a single interruption. When you multiply this by the number of notifications you receive daily, the math becomes alarming. Tools like Slack, Teams, and email act as slot machines for your attention. They condition you to react immediately to every ping. This prevents you from ever reaching the deep state required to solve complex problems.

The modern open office often makes this worse. It creates a paradox where physical proximity hurts communication rather than helping it. Consider the colleague who interrupts you four times by 11:00 AM for a code review. While their intention is collaboration, the result is that you arrive late to your own flow state. You end the day feeling exhausted, but look at your commit history and realize you achieved nothing tangible.

The fix requires a shift in how we view communication. I’d recommend writing a document with context first and sending a link rather than tapping a shoulder. This ensures you do some deeper work preparing the doc, and the other person isn’t interrupted to take a look. I’d also recommend batching your communication. Check messages only at specific slots like 9:00, 10:00... Finally, use visual signals. Wearing noise-canceling headphones is a clearer “Do Not Disturb” sign to the room, even if you are not listening to music. Just make sure you’re not always wearing the headphones.

Subscribe now

Multitasking and task hopping

Addiction to shallow work causes a death by a thousand cuts. Jumping between tasks gives you a false sense of speed. You feel busy. You feel like you are moving fast. Your brain is never idle. In reality, it’s killing your ability for deep work. You are trading your ability to build hard things for the ability to be responsive.

I’m sure you’ve seen this during your meetings: some team member is physically present on the call but mentally absent. They are multitasking, reading emails, or fixing a bug while others speak. When called upon, they ask people to repeat what was just said. This wastes the collective time of everyone and signals that the meeting itself has no value.

The trap here is optimizing for “response time” over “resolution time”. You might answer a message in two minutes. However, because you were distracted from your main task, it now takes three days to actually solve the bug you were working on and would have been fixed in 2 days. To fix this, focus on single-tasking and having clear visibility over the upcoming work. Work on a single task, and every other impulse gets added to your task list for later. Use the “Parking Lot” method for interruptions in meetings, and send messages before walking by someone’s desk. When a new thought comes in, write it down and immediately return to your work. Do not switch contexts.

Subscribe now

The urgency illusion

I’ve seen that everyone wants everything for yesterday. There’s a concept known as the “Law of Triviality”, also known as “bike-shedding”. Teams will spend hours debating variable names because they are easy to understand. Meanwhile, they ignore massive architectural debt because it is difficult to discuss. We prioritize what is urgent and easy over what is important and hard.

This causes teams to rush to build a demo feature for a presentation, make it look good on the presentation, but it provides zero value to the actual customer. You dedicate resources to making a demo, even if it delays the production launch. The irony is painful. You are prioritizing internal politics over features that create actual revenue or user satisfaction. This is also shown when we over-optimize systems without a business justification.

The fix is to use the Eisenhower Matrix to ruthlessly categorize tasks. Most urgent tasks, like Slack pings, are rarely important. Most deadlines are artificial. Ask “Why?” five times to differentiate between a business deadline, like a marketing launch, and an arbitrary deadline set by a manager who just wants to see progress. Always prioritize the feature that unblocks the user over the feature that impresses the boss. Your boss’s boss will likely prefer value delivered to the user.

Subscribe now

Parkinson’s law

Parkinson’s Law states that work expands to fill the time available for its completion. This is closely tied to the planning fallacy. Engineers underestimate costs and risks while overestimating benefits. If you allocate two weeks for a task, it will take two weeks. It will likely take even longer because you will find reasons to add complexity.

I saw this on a database migration I was working on recently. We had a hard deadline to make the upgrade, or the upgrade would be done automatically outside our work hours, causing some downtime and paging the on-call. The team wasn’t aligned with the estimation of downtime we had, and we kept working on investigations and POCs until the deadline arrived. We ended up going with the initially proposed solution anyway. The work expanded simply because the time was allocated. The perfectionism trap tells us that work is never fully done. Strict time-boxing and artificial deadlines are your only defense against endless tinkering. Now I understand why managers push for deadlines that are artificial.

Seriously, apply aggressive time-boxing. Set a deadline shorter than you think you need. Force the Minimum Viable Product. If you are running out of time, cut the scope for the initial delivery. Do not extend the time. Before you start, write down exactly what finished looks like so you do not keep polishing past the point of diminishing returns.

Subscribe now

The Zeigarnik effect (the mental RAM leak)

Read more