Subscribe now

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

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

You can be good and still be laid off.

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

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

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

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

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

In this post, you’ll learn

• How to build a layoff-proof career strategy

• Why tech layoffs keep happening

• How to show measurable software engineering impact

• What to do if your engineering team looks exposed

A layoff-proof career strategy is not about becoming irreplaceable

The first mistake is trying to become “irreplaceable.”

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

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

There are 3 scenarios:

1. Your entire org will be laid off

2. Your org will be partially laid off

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

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

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

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

Why tech layoffs keep happening in waves

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

The better model is resource reallocation.

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

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

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

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

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

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

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

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

Doing important work for your team does not always protect you

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

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

The three career risks hidden inside AI layoffs

AI layoff headlines have multiple risks in one single story.

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

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

I see three risks behind the layoffs headlines.

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

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

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

The practical response depends on which risk you see.

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

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

Work closer to revenue, risk, or strategic priorities

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

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

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

But during a reallocation cycle, that proximity matters.

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

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

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

Become visibly useful with AI, not just interested in AI

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

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

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

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

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

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

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

Build proof that your work creates leverage

During layoffs, invisible value is fragile value.

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

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

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

You need proof before you think you need it.

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

.

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

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

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

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

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

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

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

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

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

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

If you found value in this post:

• ❤️ Click the heart to help others find it.

• ✉️ Subscribe to get the next one in your inbox.

• 💬 Leave a comment with your biggest takeaway

Subscribe now

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

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

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

Context Is Working Memory

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

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

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

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

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

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

Divide And Conquer The Working Set

Read more

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

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

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

Subscribe now

But there’s an uncomfortable part.

The same dashboard that proves I am using AI seriously could also reward complete nonsense.

I could burn tokens generating diffs nobody asked for. I could leave an infinite loop, launching prompts that scan stuff without taking any action. I could climb a leaderboard while not shipping any code.

That is the trap in AI developer productivity. AI can improve developer productivity when it reduces the scarce human attention needed to ship valuable, reliable software. It does not improve productivity just because developers write more prompts, generate more code, or spend more tokens.

A bad pull request is visible. A bad prompt is mostly invisible.

This is why the question is no longer “does AI make developers faster?”

Sometimes it does. Sometimes it slows them down. Sometimes it makes them feel faster while moving the bottleneck to review, testing, and rework.

The better question is this:

“Did AI help the human-AI system ship better software with less wasted judgment, less rework, and an acceptable cost?”

That’s the focus of this article.

In this post, you’ll learn

• How to measure AI developer productivity without confusing token usage with shipped value

• Why AI developer productivity studies disagree and what that means for real engineering teams

• Which developer productivity metrics still work after AI, including DORA metrics and SPACE metrics

• What tokenmaxxing is and why it is becoming the new lines of code

• How to build an AI developer productivity scorecard that catches speed, quality, review load, learning, and cost

AI Developer Productivity Did Not Create Bad Productivity Metrics

AI did not break the developer productivity measurement. It exposed how fragile it already was.

Before AI, teams already overcounted the easiest artifacts: lines of code, commits, pull requests, story points, tickets closed, and sprint velocity. These things are not useless. A team that never merges code has a problem. A ticket queue that never moves has a problem.

The mistake is treating visible activity as productivity.

I have seen engineers break a piece of work into ten small PRs that only created overhead. I have also seen senior engineers spend a week on a design, challenge the scope, and save a team months of work. The dashboards of “productivity metrics” prefer the first person. The business should prefer the second.

This is why DORA and SPACE became useful corrections.

DORA metrics look at delivery-system health: lead time for changes, deployment frequency, change failure rate, time to restore service, and now deployment rework rate in newer guidance. They are not perfect, but they pull the conversation away from “who typed the most code?” and toward “can this team move changes to production without constantly setting itself on fire?”

SPACE goes wider: Satisfaction, Performance, Activity, Communication and collaboration, and Efficiency and flow. The lesson is not that every team needs a dashboard ranking their engineers. The lesson is that productivity is multidimensional and it’s not simple at all. If you collapse it into one number, engineers will optimize that number, and your system will get weird.

AI makes that failure mode more expensive because it’s easier to trick.

Before AI, the lazy metric was lines of code. After AI, the lazy metric is tokens, prompts, accepted suggestions, AI-created PRs, or model usage rank.

New context. Same old mistake.

A useful next step is this article on why more pull requests do not make projects move faster:

Why AI Developer Productivity Studies Look Contradictory

I had to read quite a few articles to write this post. There’s no clear answer on how to measure AI developer productivity.

The evidence looks messy because the question is messy.

The original GitHub Copilot study found developers finished a bounded JavaScript task 55.8% faster with Copilot. That is real. If the task is clear, local, testable, and mostly implementation work, AI can be a ridiculous shortcut. Humans can’t compete with AI’s speed. This was in 2023

Then METR ran a randomized study with experienced open-source developers working in mature repositories they already knew. The result went the other way. Developers using early-2025 AI tools took 19% longer. METR later wrote in February 2026 that its next experiment design needed to change because it’s getting harder to measure AI vs no-AI now that AI is everywhere.

Both can be true.

A small JavaScript server task is not the same as a production codebase with years of context, hidden invariants, flaky tests, team conventions, security constraints, and reviewers who actually care. AI is very good at generating plausible implementations. It is much weaker at knowing which local assumption will break when the change touches the wrong boundary.

I always think about AI as a very smart engineer on their first day at a new company. They are smart, they may try to implement design patterns that worked in their context, but they miss all the context from the company, as it’s only their first day.

DORA’s AI research points in the same direction. AI can improve individual flow and satisfaction while still hurting delivery stability when it increases batch size and review burden. That sentence should make every engineer nod in 2026. We are on a rampage of PR submissions, and we are slow at reviewing.

The issue is not whether AI is good or bad. That is too vague to be useful.

AI is a task-shape multiplier.

It helps when the bottleneck is boilerplate, search, transformation, test scaffolding, documentation, or unfamiliar code comprehension.

It hurts when the bottleneck is deep context, architecture, debugging ambiguity, correctness, or trust.

A team can get 40% faster at writing code and 10% slower at shipping software because review has become a problem.

So now the question is, is that team’s developer productivity 40% faster or 10% slower?

This is an article inside our system to move between phases 2 and 3. You’ll be able to build those XP points necessary for your next promotion if you master AI. It’s becoming an important criterion in promotions.

Check out the full system here.

The AI Coding Bottleneck Moved From Typing to Judgment

Before AI, many developer bottlenecks were obvious. Typing code. Finding reference patterns. Reading a giant document. Writing boilerplate. Creating tests. Remembering the exact syntax of a library you use twice a year.

After AI, many of those bottlenecks moved.

Now the hard parts are context quality, prompt design, review load, verification, PR size, rework, cost, and trust calibration. The work did not disappear. It changed shape.

This is what I see in my day-to-day work. AI helps me review code faster when I give it the review checklist I already trust. It helps me understand long documents when I ask it to extract the decisions, risks, and open questions. It helps me debug when I feed it logs, local hypotheses, and the code paths I have already inspected.

It’s like having an executive assistant who feeds me an executive summary before I join a meeting.

But if I ask my executive assistant, “fix this” without framing the problem I found and the kind of solution I want, it won’t move the ball forward. Instead, it will be like the company’s bureaucracy: People moving but not delivering value.

Motion was expensive. You had to pay people salaries for it. Now, motion is cheap.

Judgment is not.

Before AI, companies already did a lot of motion. But some people would have stopped each other on their feet, saying: “No, we are not able to support this project because we have no engineering capacity.”

But now you are spending a week, and it’s easier to fall into the motion trap. “Sure, while Engineer-A is working on the important project, also take a look at this. It should be easy.”

The engineers getting the most from AI are not the ones who type the shortest prompts. They are the ones who know where the bottleneck moved. They use AI to compress the boring parts of engineering, they protect their attention and their time to avoid adding motion to it, then spend the saved attention on the parts that still need a human with context.

That is the productivity shift I care about.

Read more about how review and delivery bottlenecks change when teams scale software engineering with AI:

Tokenmaxxing Is the New “Lines of Code”

Tokenmaxxing is treating token burn, request volume, or AI leaderboard rank as proof of being AI-native.

It is funny because it is true. It is dangerous because it can become policy.

I understand why companies measure usage. Most people were attached to their old workflows. If leadership wants engineers to learn AI, they need some pressure. Usage dashboards can show whether people are experimenting, whether licenses are wasted, and where the cost is going. That is legitimate.

The problem starts when usage becomes a ranking.

Raw AI usage tells you adoption and cost. It does not tell you productivity.

In my own work, high usage can mean I automated a recurring workflow that saves time every week. Because it’s a real use case that is present in my day-to-day, I will have high token usage. It can also mean I started using AI inefficiently and dedicated 20 prompts to solve something that could be solved in 1 if I had the right harnesses and context setup.

The billing system sees both. The codebase only benefits from one.

This is why tokenmaxxing feels like the lines of code or number of commits in a new jacket. I read this from an article from The Pragmatic Engineer, and I found myself nodding in agreement.

These metrics were easy to count, easy to game, and weakly connected to value. I’ve seen people posting comments in each PR to increase the number of PRs they are involved in. Tokens have the same shape. A developer can burn a lot of tokens because they left a loop running, doing busywork.

A company can see bad PRs. It cannot easily see bad prompts.

That gap matters because AI work creates a new invisible layer between intent and code. The prompt is where the problem is framed. The context is where the model is steered. The output is only the artifact you happen to see in review.

Subscribe now

AI Budgets Are Now Part of Software Engineering Architecture

For a while, AI coding tools felt like an all-you-can-eat restaurant. Pay the monthly fee, ask as much as you want, and enjoy.

That era is ending.

GitHub announced on April 27, 2026, that Copilot plans will move to usage-based billing on June 1, 2026. They describe the shift toward GitHub AI Credits and token-based usage. Completions may still be bundled in some cases, but agentic sessions and heavier model usage are becoming a problem.

Uber’s CTO said they burned their entire 2026 budget for AI in 4 months.

The direction is obvious, even if every vendor uses different packaging.

Agentic work costs money. Long context costs money. Agents run without constraints, and cost money. Using the latest model costs more money with every new release.

AI is no longer only a developer-experience tool. It is part of the bill for any project.

This changes the productivity question.

The old question was:

“Did AI save time?”

The better question is:

“Did AI save scarce human attention at an acceptable cost?”

Those are not the same. If the cost of doing something with AI is higher than paying a human to do it, we have flipped the economics. Unless we need something done fast, we’ll try to save money.

If an agent spends three dollars to save a senior engineer thirty minutes on a recurring operational task, I probably want that all day. If an agent spends thirty dollars generating a giant PR that takes two reviewers an afternoon to untangle, that is not productivity. That is actually increasing both AI and human costs.

But hey, that giant PR consumed a lot of tokens, and the author got to the top of the daily leaderboard…

*facepalm*

Cost per shipped change is going to matter. Not because engineers should become accountants, but because unlimited AI usage hides bad engineering habits the same way unlimited cloud spend once hid bad architecture.

I remember how some engineers created a “how much this meeting costs” tool to avoid having big, inefficient meetings. Just multiply the average hourly salary of a certain role/level by the number of people and the duration of the meeting.

We may have something similar with AI eventually.

Why AI is causing layoffs

Most engineers miss the finance layer because it feels outside their job.

But it can get you laid off, so you’d better pay attention.

AI infrastructure is a massive fixed-cost bet. A company that spends heavily on data centers, chips, and capacity may not expense all of that in one quarter like payroll. The assets can be capitalized and depreciated over time. But the cash still leaves. Their free cash flow metric changes. Their Return-on-invested-capital pressure changes. Executives then need a story that makes the spending look rational, and they need to tweak their numbers.

Human labor is also a large fixed or semi-fixed run-rate cost. Payroll shows up differently from infrastructure, but from the point of view of leadership, both are part of the productivity equation. If AI spending rises fast, someone eventually asks what it replaces, what it amplifies, and whether the company is getting enough useful output per dollar.

This is why AI developer productivity is not just a team dashboard problem.

It is tied to hiring plans, platform investment, finance narratives, and the uncomfortable question of whether software teams are turning AI spend into durable software or expensive theater.

I don’t think engineers need to obsess over the company’s finances, unless you’re in a startup and fear it will go bankrupt soon.

But I do think we need the big picture here. If you want AI tooling, agents, internal platforms, and bigger budgets, you need to explain the value in a language that survives outside the engineering floor.

“The team likes it” will not be enough.

“We are doing the same with fewer people, so we reduce by 10% our workforce” is a strong narrative. Just check the stocks of those companies after announcing layoffs, they go up because they suddenly make the same money but reducing 10% the human workforce costs.

That’s a hard truth for humans, but it’s the tendency in the industry

Subscribe now

How to measure AI Developer Productivity

If I had to measure AI developer productivity for a team, I would not start with tokens. I would start with this question.

“Are we delivering valuable, reliable software with less scarce human attention?”

Here is a practical version:

• Business outcome: Track customer impact, adoption, and incidents avoided.

• Delivery flow: Track lead time, cycle time, and time to merge.

• Quality: Track production defects, revert rate, and build success.

• Review burden: Track review time, comment volume, and rework loops.

• AI diagnostics: Track active users, requests, and retained AI output.

• Cost: Track cost per merged PR, task, or workflow.

• Human experience: Track cognitive load, flow, and satisfaction.

• Learning: Track onboarding speed, explainability, and ownership.

That means you do not replace DORA with Copilot dashboards. You keep DORA, cycle time, defects, review time, cognitive load, and customer outcomes. Then you add AI diagnostics to understand what changed.

This prevents the classic dashboard lie.

If AI usage goes up and lead time goes down while quality stays flat, good. Keep going.

If AI usage goes up and PR size doubles, review time grows, and defects rise, you did not gain productivity. You moved work from authors to reviewers and sold it as progress.

How to Use AI Without Faking Productivity

The personal rule I use is simple: use AI first for leverage, not for abdication.

Here are the rules I would give any engineer trying to use AI well:

• Use AI to understand the surroundings before changing them.

• Write down the behavior you want before asking for code.

• Keep PRs small and focused on 1 delivery.

• Build prompt libraries and skills for recurring work.

• Review your own prompts before submitting, and find out if another human would understand what you mean in that text.

• Review AI output as if it came from a very fast junior teammate with no accountability.

The last one is the most important.

AI is fast. It is not responsible.

Responsibility is still yours.

Read more about turning AI agents into reliable engineering workflows with guardrails and repeatable systems:

Common AI Developer Productivity Mistakes

The most common mistake is measuring adoption and calling it productivity.

1. Adoption matters, but it’s not the only thing. I want engineers to try the tools. I want teams to learn where AI helps. In the same way I write this newsletter publicly, I share with my peers at work about AI. But adoption is the start of the measurement conversation, not the end.

2. Using AI to make PRs bigger. This feels productive for about three hours. Then the reviewer opens the diff, sees 900 lines across five concerns, and the team pays the bill in comments, confusion, and rework. AI should make work smaller and more reviewable, not larger and harder to reason about.

3. Accepting generated tests that test the implementation instead of the behavior. This is everywhere. The model sees the function, writes a test that mirrors the function, and everybody feels better because coverage went up. Then production hits the case nobody modeled.

4. Outsourcing understanding. If you cannot explain a critical AI-generated change, you do not own it. You are renting confidence from a system that will not join the incident call.

5. Ignoring cost until finance notices. That is a bad moment to start learning how your agents spend money. They will take them away from you.

Read more about the comprehension risk behind AI-assisted development and why working code is not the same as understood code:

Conclusion: AI Developer Productivity Is a Systems Problem

I am not anti-AI. That would be absurd. I use these tools every day, and I think engineers who refuse to learn them are making their careers harder than they need to be.

But I am very against lazy measurement.

High AI usage can be a real edge for engineers. But it becomes theater when the metric rewards consumption instead of judgment.

The engineers who compound will not be the ones who burn the most tokens. They will be the ones who turn AI into repeatable workflows that ship valuable, reliable software with less scarce human attention.

That is the goal.

Not prompts, tokens, or a leaderboard rank.

Useful software, shipped responsibly, with less human cost, and with the human still owning the judgment.

Recap of the article

Does AI improve developer productivity?

AI improves developer productivity when it reduces the human attention needed to ship valuable, reliable software. It helps most with bounded tasks, boilerplate, tests, documentation, search, and unfamiliar code comprehension. It can hurt productivity when the real bottleneck is architecture, mature-codebase context, review burden, correctness, or debugging ambiguity.

Why do AI developer productivity studies disagree?

AI developer productivity studies disagree because they measure different developers, tools, task types, time periods, and codebase contexts. A bounded lab task is not the same as a senior engineer changing a mature production repository. AI is not a universal speed multiplier. It is a task-shape multiplier.

What metrics should teams use for AI developer productivity?

Teams should keep outcome metrics such as DORA, cycle time, review time, production defects, reverts, and developer experience. Then they should add AI diagnostics such as active usage, retained AI output, intervention count, rework, AI-created PR share, and cost per shipped change. AI metrics should explain outcomes, not replace them.

Is token usage a good AI productivity metric?

Token usage is not a good productivity metric by itself. It is an adoption metric and a cost metric. High token usage can mean serious workflow automation, or it can mean wasteful prompting that produces nothing durable.

What is tokenmaxxing?

Tokenmaxxing is treating tokens consumed, prompts sent, or AI leaderboard rank as proof of productivity. It is useful as a warning label because it shows how easily teams can confuse consumption with value. Tokens are the new lines of code: easy to count, easy to game, and dangerous when treated as the goal.

If you want to go deeper on turning AI from random prompting into a real engineering system, read this article next.

One developer can generate a pull request in minutes.

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

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

But the maintainer may need hours to verify it.

That is the part AI did not automate away.

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

Subscribe now

I have felt both sides of this at work. AI has made my reviews faster when I use it well. I can ask it to inspect a targeted file, check a specific assumption, compare behavior against tests, or formalize a concern I already have. That is useful. It helps me understand the code better.

But the same tool becomes harmful when it produces long generic comments nobody owns. It can challenge every aspect of a PR, and with words that sound correct, but have no depth. It can generate a fix that compiles while missing the architecture. It can create the feeling of progress while moving the real work to someone else.

That is what is happening with AI and open source.

AI is not killing open source as an idea, a license model, or a community. But it is breaking the old assumption that the effort required to submit code, issues, and security reports naturally protects maintainers’ attention.

Open source did not run on code alone.

It ran on trust.

In this post, you’ll learn

• How AI open source contributions are changing maintainer trust and project governance

• Why AI-generated PRs create more review work for open-source maintainers

• How AI security reports are forcing projects like curl and Node.js to gate vulnerability channels

• Why open code does not always mean open maintainer attention

• How to make responsible AI-assisted open-source contributions that maintainers can trust

Is AI killing open source?

No, AI is not killing open source.

It is killing the old contribution model.

Open-source licenses are not disappearing. Public code is not becoming useless. Communities, shared infrastructure, reusable libraries, transparent development, and public issue trackers still matter. In fact, AI depends on all of them.

But the old contract is breaking.

For years, open source worked because contributing required effort. A meaningful PR, a useful issue, or a serious vulnerability report took enough work to signal that the person submitting it probably understood something. The effort was on the author of the PR. That friction protected maintainers.

AI removes that protection.

Now, a plausible PR can be generated without understanding the code.

The question is not whether open source survives.

It will.

The question is whether the old model of open contribution survives.

I don’t think so

The moment generating code is cheap, that effort is passed to the maintainer.

AI increased the supply of code faster than it allowed maintainers to triage contributions. AI didn’t increase the supply of trust yet.

That is the real open-source problem: AI is not killing open source. It is killing open contribution as we knew it.

Subscribe now

The old open-source deal depended on contribution friction

The old open-source deal was never just “send a PR.”

It was closer to this: you spend effort understanding the project, you submit a change, and the maintainer spends attention reviewing it. If the contribution is good, the maintainer not only accepts a diff. They are making a small bet on you as a future participant.

That bet made sense when creating a useful PR required work. You had to clone the repo, understand the code path, reproduce the problem, make the change, run tests, and explain why it mattered. The effort was not perfect proof of quality, but it filtered out some low-intent contributions.

You needed skin in the game. You had to care.

AI changes the signal. A contributor can now produce something that looks like effort without doing the underlying thinking. The artifact looks serious, but the author didn’t make the effort of asking if this is the right thing. It’s just a thing that compiles and passes tests. Just because something doesn’t mean it’s a good thing.

This is why the phrase “AI slop” keeps showing up in maintainer discussions. The problem is not that AI touched the work. The problem is that the work arrives without ownership.

I have seen this in smaller forms in code review in my team. AI can copy an existing pattern and apply it to the wrong abstraction. It looks reasonable because it looks like other code we have in the repo, but it doesn’t mean it’s the right thing.

The code works.

The mental model and architecture fall apart.

That is manageable when you are iterating with your own AI agent. Ask AI, AI generates, I review, I prompt again to make sure the output aligns with mental model of what I think is right. It becomes expensive when I hand the first AI output to someone else and ask them to review and figure it out.

Read more about why AI-generated code becomes risky when engineers lose ownership of the output:

AI made contributions cheap, but maintainer review became more expensive

Generating a diff is cheaper now. Understanding the system is not.

That is the core economics of AI open source. A low-quality AI pull request transfers work from the contributor to the maintainer. The contributor saves time by generating the code. The maintainer pays that time back with interest by checking correctness, style, tests, architecture, maintainability, compatibility, and intent.

The old model worked because there were more contributors than maintainers. This makes the high effort side of the equation distributed across many people. But now it’s the opposite, the higher effort part is on the side where fewer people are.

This is why demanding an open source maintainer to “just review it” is not a valid request. Reviewing unknown code is not a lightweight activity. A maintainer often has to reconstruct the spec, inspect the affected path, check whether the change fits project direction, think through edge cases, and decide whether to provide feedback to iterate or reject the contribution.

The scarce resource in open source was never raw code.

It was trusted human attention from maintainers.

The clearest framing I have seen came from a maintainer’s essay called I don’t want your PRs anymore. The author explains that even before LLMs, writing code was not always the main bottleneck. Understanding, design, and review were. AI made that imbalance more visible.

That matches my own experience. AI helps me when I use it after I have framed the problem. It hurts when I use it to skip framing. The maintainer version of that lesson is clear: maintainers should not be the first people to find your spec gaps during review.

The pressure shows up in five different places: platform volume, PR review load, contribution gates, security-report triage, and business risk.

Simplifying all of these into “open source is dying” misses the useful lesson. So let’s see each of these contributing factors

Subscribe now

1/ How AI-amplified volume is changing open-source platforms

Some open-source projects are rethinking their dependency on GitHub and similar platforms because project infrastructure has become part of the trust model.

This is not only about where Git repositories live. It is about issues, pull requests, CI runs, Github actions minutes, bots, forks, maintainer workflow... As contribution volume is growing faster than maintainer capacity, platforms like GitHub are no longer a web interface. They must protect and decide how much noise reaches the maintainer.

Ghostty is a good example of how platform pressure can be real without being an anti-open-source move. On April 28, 2026, Mitchell Hashimoto wrote that Ghostty is leaving GitHub. His stated reason was GitHub reliability and project workflow pain, especially around Actions and PR review. He also said Ghostty plans to keep a read-only mirror on GitHub while moving its working dependency elsewhere.

There are 2 parts here. First, when the platform is working as expected, it has pain points because it doesn’t protect the maintainer. Second, the platform is mostly not available because it can’t keep up with the increased traffic due to AI.

That distinction matters. Leaving GitHub is not the same as leaving open source. Some projects are leaving based on a governance decision, a reliability decision, an attention-management decision, or a combination of all.

The important split is not GitHub versus non-GitHub.

The important split is between uncontrolled attention and maintainable contribution flow.

As AI agents create more branches, PRs, issues, and automated interactions, platform choice becomes part of a project’s anti-spam and trust model. Some projects will stay on GitHub and add stricter contribution rules. Some will move to Codeberg, Forgejo, SourceHut, GitLab, or self-hosted systems. Some will keep mirrors and move the review elsewhere.

That is still open source.

It is just open source with a harder boundary around the maintainer's time.

Subscribe now

2/ Why AI-generated PRs create a maintainer review crisis

AI-generated PRs are not bad because AI touched them.

They are bad when nobody understands or owns them.

Godot made this problem visible very early. In February 2026, Godot maintainers were overwhelmed by AI-generated pull requests, with Rémi Verschelde describing the work of identifying and sorting them as draining for maintainers. The article also noted that maintainers had to second-guess whether new contributors understood the code they were submitting.

That is the uncomfortable part. Open-source maintainers want to be welcoming. Many projects have spent years teaching new contributors, improving docs, labeling good first issues, and helping people get their first PR merged. AI changes the cost of that generosity.

The worst AI PR makes the maintainer become four people at once:

• The spec writer, because the contributor did not define the problem clearly.

• The tester, because the contributor did not prove that the change works.

• The architect, because the contributor did not understand the boundaries.

• The teacher, because the contributor cannot defend the generated code.

That is not collaboration. That’s doing the work yourself.

High-quality AI-assisted PRs still exist, but they look different. They are small. They are tied to a real issue, probably with an issue already open for it. They explain why the change belongs in the project. They include tests or reproduction steps. They respond to maintainer feedback with understanding instead of another AI-generated paragraph.

The difference is not AI versus human.

The difference is ownership versus transfer.

A useful next step is this breakdown of how context engineering helps software engineers get better AI coding results before asking maintainers to review anything:

3/ Why open-source contribution is becoming gated contribution

The code can remain public while the contribution path becomes stricter.

That is the shift many people miss. Open code and open maintainer attention are not the same thing. A project can let everyone read, fork, study, and modify the code while still requiring stricter rules before maintainers spend time on a PR, issue, or security report.

This can look like:

• Requiring a linked, maintainer-approved issue before a PR.

• Rejecting any PRs from unknown contributors and vague issues.

• Limiting security reports to researchers with a reputation score.

• Asking for smaller changes that can be reviewed independently.

• Using invitation or maintainer sponsorship.

That may feel less open if you learned open source as “anyone can send anything.” But a healthier definition is “anyone can inspect, learn, fork, and propose, while maintainers decide how their limited attention is spent.”

An open source project doesn’t own anything to anyone. Someone decided to put the code in the open and let you use it and modify it, but they don’t have to accept your modifications

Everyone can read the code.

Not everyone gets to spend maintainer time.

That line sounds harsh until you have maintained something under pressure. If at work I’m getting paged at 3 am multiple times a week and someone external tries to put pressure because they want their feature added to my service, I wouldn’t think that I have to pay them attention, that I owe them that. There’s something more pressing for the project and the team right now

Subscribe now

4/ How AI security reports are creating high-cost triage

AI security reports are uniquely expensive because the claim is cheap and the response is high stakes.

All reports will include “critical vulnerability” in their title. Validating that claim takes real security work. A maintainer has to check exploitability, affected versions, threat model, severity, etc.

curl is the sharpest public example. On January 26, 2026, Daniel Stenberg wrote that the curl bug-bounty program would officially stop on January 31, 2026. He said curl had seen an explosion in AI slop reports, and that the confirmed vulnerability rate fell from somewhere above 15% in previous years to below 5% starting in 2025.

That is a huge change in maintainer economics. The security team still has to treat reports seriously enough to avoid missing real vulnerabilities. Imagine the bad press when there’s a zero-day and someone calls them out because it was submitted but maintainers ignored it. But if most reports are false, vague, generated, or adversarial, the program becomes an attention sink for the maintainers.

Node.js shows a different response. In February 2026, the Node.js project updated its HackerOne program to require a HackerOne Signal score of 1.0 or higher for vulnerability reports. The Node.js security page now says HackerOne submissions require a minimum Signal score, with a direct steward path for people below the threshold.

That is not a blunt rejection of security research.

It is a filter.

And filters become more defensible when false positives rise.

The AI security-report problem is not just volume. It is incentives. A bounty creates a reason to stretch a weak finding into a scary claim to get paid more. AI makes the stretching cheaper. The maintainer pays the cost of disproving it.

This is why reputation gates are going to become normal. They are imperfect. They can exclude sincere new researchers. But the old model assumed report volume would remain human-scaled. That assumption is gone. The model is broken. No solution is perfect, and reputation filters look like the least bad.

Subscribe now

5/ Why open-source companies are rethinking openness as business risk

Commercial open source has a different problem from volunteer maintenance.

For companies, AI can make cloning, scanning, support burden, exploit research, and fast-follow competition cheaper. That does not mean every company should close source. It does mean the risk calculation has changed.

Cal.com is a recent example. On April 15, 2026, Cal.com published a technical post explaining that it had moved its production codebase from a public repository to a private one. The public repository became Cal.diy, an open-source, self-hostable, community-driven version with commercial and enterprise features removed.

I would be careful with this category. Many licensing shifts predate modern coding agents. HashiCorp, Sentry, CockroachDB, and other companies had business-model pressure long before the current AI wave.

AI is not the only cause.

It is an accelerator.

It changes how fast competitors can inspect and imitate product behavior. It changes how quickly attackers can scan code for weak patterns. This definitely changes how leadership thinks about exposing production logic.

There are already many alternatives to open-sourcing part of your software. Some companies will respond with source-available licenses. Some will use closed-core models. Some will delay public releases. Some will split a community edition from a commercial product. Some will stay fully open because openness is still their strongest advantage.

The point is not that every closed-source move is justified by AI. Some will be business decisions using the security excuse, the same way many companies are laying off people with the excuse of AI.

The point is that AI gives companies another reason to revisit these decisions.

Subscribe now

What a responsible AI-assisted open-source contribution looks like

The future contribution signal is judgment.

A responsible AI-assisted contribution starts before code. Code is the easy part now. Start with the issue, design constraint, reproduction, failing test, or maintainer-approved direction. If you cannot explain why the change belongs in the project, do not ask a model to write it.

Then keep the diff small. A small PR tells the maintainer, “I am respecting your attention.” A large generated PR from an unknown contributor says, “Please become responsible for my uncertainty.”

There are also contribution modes that are now more valuable than code, like:

• Reproduce a bug.

• Test a release candidate.

• Review a design.

• Confirm behavior across platforms.

AI can help with all of that if you use it as a thinking aid instead of a way to dodge responsibility.

The anti-pattern is to generate something nobody asked with AI and demand that someone pay attention to it.

This one is personal because I use AI every day. I do not want less AI in software engineering. I want more ownership around AI output.

The best AI-assisted contributor reduces the maintainer’s burden.

The worst one transfers it.

Read more about turning AI from a random code generator into a reliable teammate before you bring its output into shared engineering spaces:

When not to use AI for open-source contributions

Do not use AI when you cannot tell whether the answer is correct.

That sounds obvious, but it is the failure mode behind most of this mess. If you are new to a codebase, AI can help you read it. It can summarize files, find references, explain test setup, and help you ask better questions. But it should not become your substitute for understanding.

Do not use AI to write vulnerability reports unless you can reproduce the issue and explain exploitability yourself. Do not use AI to write a proposal if you cannot defend the tradeoffs. Do not use AI to submit a PR because a chatbot told you the project “should” have a feature.

There is a useful rule here:

If the maintainer asks, “Why did you do this?” and your honest answer is “The model suggested it,” you are not ready to submit.

Use AI to prepare. Use AI to inspect. Use AI to test your thinking.

But when you submit, you own the work.

Subscribe now

This is an article inside our system to move between phases 2 and 3. You’ll be able to build those XP points necessary for your next promotion if you master AI. It’s becoming an important criterion in promotions.

Check out the full system here.

Conclusion: The future of AI and open source is open code, gated attention

Open source is not disappearing.

But the default permission model around maintainer attention is changing.

AI made low-quality participation cheap enough that projects need stronger gates. Some will gate PRs. Some will gate security reports. Some will move platforms.

The old assumption was that contribution effort filtered intent.

That assumption is broken.

The new contribution signal is ownership: knowing what to change, knowing what not to change, proving the change works, and respecting the maintainer’s time.

Key Takeaways

• AI is not killing open source, but it is forcing maintainers to protect attention more deliberately.

• AI-generated PRs are harmful when contributors do not understand or own the code they submit.

• Open-source projects can keep code public while gating PRs, issues, and vulnerability reports.

• AI security reports are expensive because scary claims are easy to generate and hard to validate.

• The best AI-assisted contributors use AI to reduce maintainer burden, not transfer it.

AI did not end open source.

It made open source admit that maintainer attention was never free.

Subscribe now

Recap of the article

Is AI killing open-source software?

AI is not killing open-source software as a model, but it is changing how open-source projects protect maintainer time. The biggest problem is not code generation itself. The problem is that AI makes low-quality PRs, issues, and security reports cheap enough to overwhelm human review.

Are AI-generated PRs always bad?

No. AI-generated PRs can be useful when the contributor understands the change, keeps it small, tests it, and can respond to review. They become harmful when the contributor sends generated code they cannot explain and leaves the maintainer to find the real requirements.

Should open-source maintainers ban AI-generated code?

Some projects may ban AI-generated code, but a blanket ban is not the only option. Many projects will do better with contribution rules that require ownership, tests, disclosure when requested, small diffs, and linked issues before implementation.

Why are open-source projects gating contributions if the code is public?

Public code means anyone can read, fork, and study the project. It does not mean everyone is entitled to unlimited maintainer attention. Contribution gates help projects keep review, security triage, and support channels usable.

Should developers disclose AI use in pull requests?

Developers should disclose AI use when the project asks for it. Even when disclosure is not required, the contributor should own the output fully, including tests, reasoning, tradeoffs, and follow-up changes.

Subscribe now

If you want to go deeper on writing better AI instructions before you ask a model to touch real code, read Prompt Engineering vs Spec Engineering next.

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

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

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

Subscribe now

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

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

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

The system worked when I used it.

The problem was that I often did not use it.

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

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

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

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

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

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

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

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

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

In this post, you’ll learn

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

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

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

• How calendar observability shows where your week actually goes

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

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

Your week needs observability

A production system without observability fails silently.

Your week does the same.

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

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

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

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

Subscribe now

How an AI calendar agent changes time tracking

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

Before:

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

And here is what the AI calendar agent does now:

After:

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

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

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

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

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

Subscribe now

Why manual time tracking fails for software engineers

There are three failure modes I kept hitting.

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

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

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

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

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

What a useful AI time tracking system needs

A good AI time tracking system needs three things.

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

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

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

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

Subscribe now

The two-tag calendar system that turns blocks into data

Every calendar block gets two tags.

The first tag is the area:

• [#w] for work

• [#l] for life

The second tag is the activity type:

• [#t] for a focused task

• [#m] for meeting

• [#r] for review

• [#e] for entertainment

• [#st] for study

• [#ex] for exercise

• [#ch] for chores or admin

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

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

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

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

Subscribe now

What my calendar data revealed after tracking my week

This is the part that made the system stick.

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

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

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

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

You can only sacrifice what you can see.

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

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

Read more

Subscribe now

A few years ago, the top GitHub repo of the week was usually something you could run.

A framework. A database. A package manager. A CLI. A model runtime.

Now, one of the most viral developer artifacts can be a markdown file.

Not a package with a markdown README.

The markdown is the only thing in the package.

That sounds absurd until you remember what AI coding agents do before they touch your codebase.

They read instructions.

That is why AI agent skills matter. AI agent skills are reusable instruction packages that teach an AI agent how to perform a specific workflow. They can include markdown instructions, examples, scripts, references, and other resources the agent loads when the task calls for them.

A library gives software new functionality.

A skill gives an agent better behavior.

That distinction explains why markdown files are becoming serious engineering artifacts. They do not replace tests, CI, architecture, or code review. They sit upstream of them. They influence the code the agent writes, the tests it chooses to add, the risks it checks, and the questions it asks before touching the repo.

Markdown is becoming the package format for agent behavior.

In this post, you’ll learn

• What AI agent skills are, and how they help coding agents perform repeatable workflows.

• How agent skills differ from CLAUDE.md, AGENTS.md, SKILL.md, and MCP.

• How to write a practical SKILL.md file with instructions, examples, scripts, and resources.

• When not to use agent skills, and when tests, CI, linters, repo instructions, or MCP are better.

• Why markdown repos are becoming valuable open-source artifacts for software teams.

What Are AI Agent Skills?

AI agent skills are reusable folders or files that package instructions, examples, scripts, and resources for one specific workflow.

OpenAI describes Agent Skills as folders of instructions, scripts, and resources that agents can discover and use for specific tasks. Thoughtworks uses the same broader framing in its Technology Radar: skills modularize context by packaging instructions, executable scripts, and associated resources, and agents load them only when needed.

That “only when needed” part matters.

A giant always-on instruction file eventually becomes noisy. That was a problem when MCP was first released. The agent sees rules that do not apply to the current task. Important constraints compete with random details.

A skill is different. It is a just-in-time workflow memory.

For example:

• A code review skill that checks PRs for behavioral regressions, security risk, data loss, missing tests, and risky abstractions.

• A release note skill that follows the company’s changelog style.

• A design doc critique skill that checks assumptions, failure modes, rollout plans, and operational risk.

The important part is not that the file is markdown.

The important part is that the agent can load a repeatable way of thinking at the moment of work.

Subscribe now

Why AI Coding Agents Need Skills

I have seen competent engineers judge AI agents before configuring the environment in which those agents operate.

The complaint is usually some version of this:

“AI is not better than me.”

Fine. But the missing question is:

“What did I teach it about how I work?”

Don’t ask if AI is good. Ask how to make AI work for you.

Most coding agents are generalists by default. They do not know your team’s review standards. They do not know your preferred testing depth. They do not know which files are dangerous to touch. They do not know the difference between “make it work” and “make the smallest safe change.”

So they improvise.

And when an agent improvises inside a codebase, you pay for it in code review comments.

You repeat the same feedback. “Stop touching unrelated files”. “Add tests before calling the task done”. “Do not create new abstractions”…

The agent is not always the problem.

The missing operating instructions are the problem.

This is where the “factory defaults” mental model helped me. I would never expect a new teammate to join a team and instantly know our deploy risk, testing culture, naming patterns, code ownership, and review bar. I would give them context. I would point them to the docs.

Then I would watch how they work and refine the guidance.

That is what we need to do with agents too.

Read more about how context engineering helps software engineers get better AI coding results:

Skills vs CLAUDE.md vs AGENTS.md vs MCP

The mistake is asking which file is best.

The useful question is what kind of instruction, memory, or capability you are trying to encode.

Use an idea file when you want to share a reusable product, system, or architecture pattern that an agent can adapt to a person’s context. The file should explain the high-level idea, the core architecture, the operations, the tradeoffs, and the constraints that matter.

Use CLAUDE.md when you need repo-wide guidance for Claude Code. Good examples are project architecture, test commands, coding conventions, forbidden operations, deployment notes, and local development traps.

Use AGENTS.md when you need repo-wide guidance for any tool. Good examples are project architecture, test commands, coding conventions, forbidden operations, deployment notes, and local development traps. The agentsmd/agents.md project describes it as a README for agents: a predictable place to give coding agents context and instructions for a project. GitHub Copilot also supports AGENTS.md files anywhere in a repository, where the nearest file in the tree takes precedence.

Only if you work with an agent that doesn’t support AGENTS.md, then use their specific file like Claude.md

Use skills when the workflow is reusable across projects, only relevant sometimes, and has steps, examples, and output expectations.

Use MCP when the agent needs live access to tools, databases, APIs, calendars, documents, or internal systems. The problem is not “think this way.” The problem is “call this system safely and return structured data.” Most times, you can substitute with a CLI, but then you must provide instructions in a skill about how to install it if it’s not available, and how to authenticate

Once I started seeing the distinction this way, the architecture became less confusing.

If the agent keeps forgetting how the repo works, write repo memory (more markdown files). If the agent keeps doing a recurring workflow poorly, write a skill (more markdown files). If the agent needs to call a real system, give it an MCP tool or CLI (and you can wrap “how to use it“ in a skill, so more markdown files).

Subscribe now

Why Markdown Repos Are Winning On GitHub

Traditional open source distributed functionality.

A library gave you code to call. A framework gave you structure to build inside.

Markdown agent repos distribute behavior.

They tell an AI agent how to review, plan, edit, test, write, or avoid damaging your system. That is a different kind of artifact. It is less like importing a package and more like giving a new engineer the team norms before they open the first pull request.

These repos already existed before AI. For example, Google open-sourced its internal style guides for many programming languages on GitHub. The main difference is the volume: An engineer would check it when in doubt. AI Agents reference the markdown files on each execution.

With humans, a markdown file was documentation.

With agents, a markdown file can change future work.

I know “influence AI agents’ output” sounds less impactful than “call a function in a library.” But it’s actually more useful because it’s AI Agent-agnostic and works with any programming language. It changes the next code the agent writes. It changes the review comments the agent leaves. It changes the assumptions the agent makes.

This is why stars and forks mean something different now.

A star is no longer only applause for code. It is a signal that more people are benefiting from it. A fork can mean “I want to personalize this for my use case,” and it’s easier to personalize markdown than to personalize code, at least before AI

Don’t get me wrong, there’s a lot of room for open source software. But for simple utilities that solve narrow use cases, the AI can one-shot it, so a markdown file can be more useful.

Agent-readable instructions are the open-source artifacts of 2026.

That is the shift.

A useful next step is this breakdown of how AI steering turns coding agents into more reliable teammates:

The Karpathy CLAUDE.md Moment

The forrestchang/andrej-karpathy-skills repo became the cleanest public example of this pattern.

When I last checked GitHub, the repo showed roughly 104k stars and 10.2k forks.

The exact number is not the point.

The absurdity is the point.

The core artifact was tiny: a 2.3 KB CLAUDE.md file with four principles and no code. That’s a lot of GitHub stars per byte uploaded

That sounds strange if you still think open source value only means code. The right principles to steer my AI agents in all their work can be more useful than a library that I only plug for one use case.

What Good Agent Skills Do Differently

Good agent skills are not common.

One skill should do one kind of work. Code review. Migration planning. Test generation. Release notes generation.

If the skill tries to be the entire engineering process, it becomes another bloated instruction file. The agent cannot route it cleanly. Humans cannot maintain it. And teams will stop trusting it.

Good agent skills are also triggerable.

The description is routing logic, not decoration.

If you write “use this for engineering work,” the agent has learned almost nothing. If you write “use this when reviewing code before merge, especially when the change touches persistence, auth, or billing,” the agent has a much better chance of loading it at the right time.

Good skills are procedural.

This is what the LLM will receive as prompt

Without a skill:

Review this PR.

With a skill:

Review this PR for behavioral regressions, data loss, security risk, missing tests, and unnecessary abstractions. Read the surrounding files before commenting. Return only findings that would block or materially improve the change…

That difference changes the AI agent output.

Good skills include negative constraints, too. Tell the agent what not to do before it damages the codebase. “Do not rewrite unrelated files”. “Do not invent abstractions without explicit request from the user.” “Do not silently assume business logic”. “Do not skip tests when touching shared behavior”.

Usually, you’ll write those negative constraints after using the skill and finding bad outputs.

Subscribe now

A Minimal SKILL.md Example

A practical skill does not need to be long.

It needs to be specific enough that the agent knows when to load it, what to inspect, what to avoid, and how to return the result.

You can use AI to create your own skills. Just check for some meta-skills like this one

You can start with just one markdown file, but the broader skill format can go beyond that. A real skill folder might look like this:

code-review/
  SKILL.md
  scripts/
  references/
  examples/

• SKILL.md contains the routing and workflow.

• scripts/ contains optional executable helpers.

• references/ contains the idocs the agent should consult.

• examples/ shows expected outputs.

This is why “skills are just prompts” is too small a framing. A prompt is usually one instruction. A skill is a reusable capability package. My best results came from having narrow scripts solving one problem deterministically, wrapped in a skill that lets the agent decide when to execute each.

Subscribe now

When Not To Use Agent Skills

Do not use a skill when you need deterministic enforcement.

Use CI, tests, linters, type systems, policy engines, and code owners. A skill can remind an agent to add tests. It cannot prove correctness. The agent may not load it after all.

The point is that you can use skills to point the agent to execute certain commands. That’s the best of both worlds: You have the determinism of commands and the reliability of AI finding what to do with a command’s output.

Do not use a skill when the agent needs live access to external systems.

Use MCP, a local CLI, or another controlled tool interface. Skills are good for workflow memory. Tooling is better for live data and real actions.

Do not use a skill for repo facts that should always be loaded.

Use AGENTS.md, CLAUDE.md, GEMINI.md, repository custom instructions, or another repo memory file. If the agent always needs to know how tests run or which package manager the repo uses, that is project context, not a task-specific skill.

Do not copy third-party skills blindly.

This is the part I think engineers need to take seriously. Thoughtworks explicitly warns against unreviewed reuse of third-party skills because they can introduce supply chain security risk.

We’ve seen many supply-chain attacks in dependencies you take in your software projects. Treat skills as a dependency, you must be careful with which version you add, verify it comes from a trusted source, etc.

A skill can tell an agent what to inspect, what to run, what to ignore, and what to send back. If it includes scripts, shell commands, credentials, deployment steps, file operations, or external services, treat it like code-adjacent infrastructure.

The whole article is about how impactful skills are. That makes them also dangerous

How Agent Skills Create Team Leverage

A strong individual AI workflow is useful.

A shared capability package is leverage.

An engineer who makes themselves faster is useful. An engineer who makes the team faster has leverage.

Agent skills are one way to turn private judgment into a visible team contribution.

The examples are not abstract:

• A code review skill can raise the team’s review bar.

• A release note skill can encode the product communication style.

Copying a famous CLAUDE.md is a start. But a team gets real value when engineers adapt instructions to their actual codebase, product risks, and review standards.

The difference is between using someone else’s template and encoding your team’s judgment.

This is promotion-relevant because it turns personal productivity into organizational leverage.

Read more about how I completely automated a workflow that writes more than 100 PRs a month at Amazon:

What Agent Skills Predict For Open Source

I think most viral repos will keep being markdown files

That does not mean code matters less.

But agent behavior now sits upstream of more software work.

If agents are writing more code, reviewing more diffs, creating more plans, and drafting more designs, then the instructions that shape those agents become part of the engineering system.

These markdown repos aren’t documentation on the side of code projects

They are part of the system.

The blast radius of bad context fed into AI can now be larger than the blast radius of bad code.

And the speed at which they gain stars on GitHub means people can use them faster and easier than a code project.

English is becoming a control surface for software work.

That is why this trend is worth taking seriously.

Subscribe now

Recap of this article

What are AI agent skills?

AI agent skills are reusable instruction packages that teach an AI agent how to perform a specific workflow. They often include a SKILL.md file plus optional scripts, references, and examples that the agent can load when needed.

What is the difference between CLAUDE.md and agent skills?

CLAUDE.md is usually repo-level guidance for Claude Code. Agent skills are narrower workflow playbooks that load only when relevant, such as code review, test generation, migration planning, release notes, or incident summaries.

What is AGENTS.md used for?

AGENTS.md is a tool-agnostic instruction file for coding agents. It gives agents a predictable place to find project context, setup instructions, test commands, and team rules.

When should I use MCP instead of an agent skill?

Use MCP when the agent needs to interact with live tools, APIs, databases, files, calendars, documents, or internal systems. Use an agent skill when the agent mainly needs repeatable judgment, workflow steps, examples, and constraints.

How do I write a good SKILL.md file?

Start with one recurring workflow and write the real steps you follow when doing it well. Add a clear trigger description, required inputs, ordered process, output format, and checks for what the agent must verify before finishing.

Conclusion: AI Agent Skills Are The Missing Middle Layer

This isn’t about “look at these viral markdown repos.”

AI agent skills are the missing middle layer between repo instructions and executable tools.

If you are a software engineer, the cheapest high-leverage thing you can do this week is to standardize your team’s software development lifecycle into skills for AI agents.

Start with one markdown file that makes the agent better at one task. Use it on real work. Share it with your team. Improve it every time the agent makes a mistake.

Keep iterating

Here are some examples of popular repos with skills:

• mattpocock/skills

• obra/superpowers

• browserbase/skills

• forrestchang/andrej-karpathy-skills

• addyosmani/agent-skills

• ComposioHQ/awesome-codex-skills

• google/skills

• op7418/guizang-ppt-skill

• VoltAgent/awesome-agent-skills

• vercel-labs/skills

If you want to go deeper on turning AI agents into reliable engineering systems,

That’s too large to be acceptable.

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

It runs. What else is there to check?

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

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

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

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

Read more

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

Something was missing.

Read more

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

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

Subscribe now

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

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

Here’s what comes next in the series:

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

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

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

• Post 5: Quick Capture & Review Day automation: Make this agent an extension of your brain and create a tight feedback loop with weekly reviews.

In this post, you’ll learn:

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

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

• How the daily briefing replaces your morning app routine

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

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

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

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

The first is not trusting the system 100%.

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

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

The second is data getting stale.

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

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

The third is getting overwhelmed.

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

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

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

What an Agent-Driven Task System Needs

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

Zero friction to add tasks.

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

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

Organized by context, not chaos.

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

Views that match how you actually think. “

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

The AI Daily Briefing: Replace Your Morning App Routine

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

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

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

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

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

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

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

Read more

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

Read more

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

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

Subscribe now

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

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

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

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

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

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

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

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

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

The real fix is a harness.

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

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

In this post, you’ll learn

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

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

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

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

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

Why AI Agents Fail on Large Files

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

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

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

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

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

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

Add more constraints.

Tell the model to “preserve the surrounding structure.”

“Make no mistakes.”

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

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

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

What Is Harness Engineering?

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

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

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

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

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

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

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

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

Prompt engineering is about what you say to the model.

Context engineering is about what the model sees.

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

Subscribe now

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

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

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

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

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

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

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

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

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

That’s when you are into something good.

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

Read more

Subscribe now

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

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

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

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

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

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

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

In this post, you’ll learn

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

• How to measure your career progress.

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

Problem statement:

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

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

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

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

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

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

The important part is to never stop taking action.

The technique:

Read more

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

I did this by building my own autonomous AI agents.

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

You need to design AI solutions.

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

I call them the “AI Agents Building Blocks.”

With this concise ebook, you will:

• Free up your time by designing AI solutions

• Solve any problem by creating your team of experts

• Prevent “AI slop” by creating guardrails

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

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

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

Subscribe now

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

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

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

Subscribe now

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

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

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

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

In this post, you’ll learn

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

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

• How to plan software architecture using the outer loop.

• How to position yourself as an internal AI leader.

The three loops of AI productivity

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

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

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

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

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

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

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

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

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

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

The inner loop for fast execution

Keeping AI interactions tight and focused maintains momentum.

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

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

Now we don’t need to micromanage AI anymore.

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

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

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

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

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

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

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

That’s why we need the middle loop

The middle loop for orchestration

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

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

Read more

Subscribe now

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

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

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

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

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

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

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

In this post, you’ll learn

• How to identify the traps of standard career progression.

• Ways to rewrite your professional goals.

The problem: the “super senior staff engineer” goal

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

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

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

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

The technique: Defining your custom objective function

Read more

Subscribe now

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

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

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

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

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

I’m not here to talk about gossip.

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

The core points from the media that I read were:

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

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

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

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

Let’s rephrase the problem in this way:

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

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

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

That’s not a good solution.

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

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

Let’s learn how!

In this post, you’ll learn

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

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

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

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

The cost of manual safeguards

Let me go back 2.5 years.

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

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

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

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

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

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

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

7 steps to automate your deployment pipeline

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

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

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

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

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

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

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

4. Update your deployment strategy.

Read more

Subscribe now

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

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

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

In this post, you’ll learn:

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

• How to apply human communication styles to machine instructions.

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

The 3 levels of engineering communication

The weight of your comments matters in a technical environment.

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

Level 1: Authoritative

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

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

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

Level 2: Talking from experience

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

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

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

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

Level 3: Talking as a user of the system

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

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

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

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

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

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

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

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

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

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

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

Applying these communication styles to AI

Read more

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