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 code that looks fine until it breaks.

I’ve been noticing this pattern in myself and on my team for months. Then Anthropic published the study.

The question isn’t whether AI is making developers lazy. It does. The better question is which kind of lazy, and whether you’re the one steering it.

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

Subscribe now

In this post, you’ll learn

• What Anthropic’s 2026 randomized controlled trial found about AI-assisted developer comprehension and why the results are worse than most people realize

• How Carnegie Mellon’s 807-repo study shows AI tools increase code complexity by 41% without delivering sustained velocity gains

• The three modes of AI use at work, and why only one of them actually makes you a better engineer

• How the Expertise Reversal Effect explains why AI hurts junior developers far more than seniors, and what that means for the talent pipeline

• The Explainability Gap metric and how to use it to know whether you actually own the code you ship

What Anthropic’s 2026 Study Actually Found

In January 2026, Anthropic published a randomized controlled trial that directly answers the question everyone is arguing about in comment sections.

52 junior Python engineers, all with one to three years of experience. Their task was to learn Trio, a novel async Python library they had never seen. Half the group used Claude throughout the learning process. Half worked manually, the same way engineers learned before AI tools existed.

Here is what happened.

The AI group finished roughly two minutes faster. That gap was not statistically significant. Then came the comprehension quiz.

The manual group scored 67%. The AI group scored 50%. That is two full letter grades. This was not a rounding error or a noisy result. The gap was real, measurable, and significant.

Debugging was the worst-performing category for the AI group. The section where you most need to understand what you built was exactly where the AI-assisted engineers fell furthest behind.

Anthropic gave this effect a name: the illusion of competence. Developers feel fast and capable while failing to internalize what they actually built. The code works. The mental model does not exist.

The Code Itself Gets Worse: Carnegie Mellon’s 807-Repo Study

If the Anthropic study is about what happens in your head, the Carnegie Mellon study is about what happens in your codebase.

Researchers ran a difference-in-differences analysis across 807 repositories that adopted Cursor between January 2024 and August 2025, comparing them to 1,380 matched control repositories that did not. They measured code quality using SonarQube, a static analysis tool most engineering teams already use for CI pipelines.

Month one after adopting AI tooling: a 3 to 5x spike in lines of code written. Engineers were shipping more code than they ever had. By month three, velocity had reverted to baseline. No sustained gain.

But the quality numbers kept climbing in the wrong direction.

Security and static-analysis warnings increased by 30%. Code complexity increased by 41%, growing disproportionately faster than the actual amount of code. The researchers called this complexity debt. AI speed is a loan against future maintenance hours. The interest does not announce itself. It compounds slowly, invisibly, until the day someone has to touch that code and the whole session turns into archaeology.

The pattern is consistent with what you would expect if a tool lets people write code faster than they understand it. More code, more warnings, more complexity, same velocity after the initial burst. Faster input, worse output.

For example, the press said Amazon was adding more human reviews for AI-generated code. This is the reality:

AI Does Make Developers Lazy — But Which Kind Depends on You

The yes/no framing is wrong. It makes for good arguments on social media and produces nothing useful for the engineers actually trying to work well.

I know, I started the article with a yes/no question. Now it’s time to reframe it.

The Anthropic study, if you read past the headline, is not an indictment of AI. It is an indictment of one specific way of using it. The effect depends entirely on how you interact with the tool.

Three modes exist. Most engineers use the first one almost exclusively. Only one of them makes you smarter while you work.

Subscribe now

3 Ways to Use AI at Work. Only One Makes You Smarter.

Blind Delegation (the Self-Automator)

This is the default mode. You describe what you need, AI generates it, you check that it runs, and you ship it.

It is the fastest interaction pattern. It is also the one that produced the worst comprehension outcomes in the Anthropic study, under 40% for engineers who relied on it heavily. A Boston Consulting Group study found a parallel result: engineers in pure delegation mode developed neither domain skills nor meaningful AI skills. They got faster at prompting and slower at thinking. The effect on deep work and focused output runs deeper than most engineers realize until it is too late to course-correct.

I have seen this play out in specific ways at work

• Solutions built before defining the problem.

• Documents that don’t contain any decisions.

• Code that solves a problem we don’t have.

With AI, it’s common to think “it compiles, it works“

That assumption is exactly the illusion of competence the Anthropic study quantified.

This framework of 3 AI coding loops helped me fix my AI Slop:

Manual (No AI)

The manual group in the Anthropic study scored 67% on comprehension. That is the baseline. It is slow, metabolically expensive, and cognitively demanding.

It is also the only mode that forces schema formation. Schema formation is the cognitive process where you build a mental structure for how something works, not just what the output looks like. Senior-level intuition, architecture judgment, and debugging ability: these come from schemas built through repeated, difficult cognitive effort.

Cognitive psychologists call this the “desirable difficulties” principle. The struggle is not a bug in the learning process. It is the feature. When things are hard to process, the brain encodes them more durably. When AI removes the friction, it also removes the encoding.

Manual mode is not the goal for every task. But for any concept you need to own, it is non-negotiable.

AI for Learning (Socratic Mode)

This is the mode almost nobody uses by default, and it is the one that produces better outcomes than working without AI at all.

When you use AI as a Socratic tutor instead of a code generator, restricting it from writing the solution and instead asking it to explain, question, and guide, you get a 19.6% improvement in learning outcomes compared to traditional methods. A LearnLM experiment found an additional 5.5% improvement on novel problem-solving tasks.

The key constraint is that the AI does not write the code you ship. You iterate toward your own solution using AI as a thinking partner. This is different from copy-paste. You ask AI to explain a concept, form your own hypothesis, write the code, and then ask AI to critique it.

The difference between this and Blind Delegation is the same as the difference between using Stack Overflow to check your approach versus using it to replace your thinking. It’s the same as checking with some peers your proposal versus waiting for your peers to solve everything by themselves.

Besides the intention, you must make AI give you the right answers instead of hallucinations. This is how:

The 6 Interaction Patterns from the Anthropic Study

The Anthropic study identified six interaction patterns. Three of them hurt comprehension. Three of them help it.

Three detrimental patterns:

• AI Delegation → Prompt, copy, ship. No comprehension transfer.

• Progressive Reliance → Starts manual, escalates to full AI when stuck. Rewires the problem-solving instinct.

• Iterative Debugging → Paste the error back to AI without reading it. Trains helplessness, not debugging skills.

Three beneficial patterns:

• Generation-Then-Comprehension → Generate code, then explain every line before shipping. Forces schema formation.

• Hybrid Code-Explanation → Alternate between writing code and explaining what you built. Keeps understanding in-head.

• Conceptual Inquiry → Ask AI to explain the concept, not write the solution. Builds the mental model first.

Most engineers drift into the detrimental column without noticing. The beneficial patterns require deliberate choice every session.

Subscribe now

7 Laziness Patterns I Have Seen in Software Engineers

Auto-Generating documentation Nobody Will Read

A document gets circulated for a real operational need. You can tell if it’s AI-generated because the author skipped any step that would require actual thinking. The structure is there. The analysis is not.

If the person who wrote it did not invest the time to reason through what was actually needed, nobody will invest the time to engage with the output.

I’m someone interested in productivity. Some time ago, I learned how to evaluate what content was worth my time and what it was not. The best content to consume is the content that took most effort the author to create

• A TikTok takes 1 hour to produce

• A YouTube video or newsletter takes ~10 hours to produce

• A book takes ~1 year to produce

The same person can produce the 3 of the examples, but their book will be a better source to consume.

The same with any document at work. If the author is not spending time creating the doc, it’s actually increasing the effort of the review.

Output without ownership. AI-generated documents without thinking are not documents. They are noise.

Building Proposals Without Investigating the Problem

A proposal for a new internal tool arrives with an impressive scope. UI, knowledge base, progressive disclosure of information, automated code reviews, one-stop App for all the software engineering work. Ambitious.

But none of the foundational questions are answered. Who owns this data? Who keeps it current? What problem does this solve that existing tools do not already cover? The proposal, written with AI, generated 10s of features in minutes.

The real question is, what of that is really needed? Building is cheaper with AI, but is still not free. Maintaining software still requires human work. You don’t want to solve problems you don’t have.

At any point in time, there’s a single bottleneck in your team. Only one. You just need to find it and put your efforts into solving it. Once you solve it, the bottleneck will be in another area. Only then do you move to the next one.

Scope without substance. AI can generate ten features in minutes. It cannot decide which problem is worth solving.

Skipping the Review of AI-Generated Code

This one is personal.

Once AI-generated code appears to work, the instinct is to move on. The code is there. The tests pass. The feature runs. Reviewing the code feels like going backward.

But reviewing AI-generated code is not optional. AI makes errors at the conceptual level, not just the syntactic one. A function can compile, pass tests, and still be fundamentally wrong in how it handles the edge case that matters. You will not find that in the happy path.

The mental effort of reviewing code you did not write, code that already appears to work, is exactly the effort that keeps you from shipping the wrong thing to production.

Redefine correct. Working is not the same as correct. Correct is not the same as maintainable.

Subscribe now

Trusting AI Output Without Verification

AI’s confidence is dangerous. It does not hesitate when it is wrong. The output looks identical whether AI got it right or got it subtly incorrect in a way that will only surface under specific conditions. The plausibility of the output is not evidence of its correctness.

Because AI communicates in natural language like another engineer, we start trusting it like we’d trust a human. “AI handled it, I can move on,” is exactly what the Anthropic study labeled the illusion of competence. You feel like you understood what was built. You did not. You saw it run.

And the worst part is this: You can’t push responsibility to AI. AI makes code writing faster, but you’re still responsible for it.

Responsibility is still yours. Read the output before you ship it. AI’s confidence is not your confidence.

Auto-Generating Comparatives Without Understanding What Is Being Compared

I worked on a proposal comparing database technology alternatives. AI made it incredibly fast to produce a comparison. The keyword is “I.” I used AI to sharpen a comparison I had already reasoned through. I understood the trade-offs before the table existed.

I have seen the inverse. A technology comparison gets produced fast. The result is a table of bullet points with no understanding behind it. You can’t explain the tradeoffs because you did not reason about them, AI did. It’s borrowed intelligence from a model.

The borrowed opinion. A comparative you cannot explain is not yours. It belongs to the AI, and the AI does not go to the design review.

Generating Code Too Fast to Understand the System

The lesson I keep relearning: the temptation is to generate the code as quickly as possible and move on. The cost shows up later. When something breaks, and you do not have the mental model to debug it, you are starting from zero in a system you think you understand.

The better path is to dig deep into how things work before reaching for generation. Understand the system first. Automate writing code on the parts you already understand.

Velocity debt. Generating code fast is not the same as moving fast. The debt comes due when something breaks.

Using AI as an Excuse for Low-Quality Work

I see the complain from many people that AI means lowering quality. I see it at work, but the problem isn’t AI. I’ve seen that before AI. It happens when leaders demand unreasonable deadlines for projects.

Some people say, “If we are going to do it with AI, it is going to have bad quality.” I’d rephrase to “if we are doing it this fast, we’re going to have bad quality, or we need more people.“

It’s wrong to blame the tool for a decision made by the person. And it ignores the fact that you can still do it the old way if it’s arguably better. If the tool was only having downsides, we’d just stop using it.

AI is used as an excuse to demand faster work. That’s fine, but we shouldn’t remove other constraints like the standards.

Outsourced accountability. The tool does not own the output. You do.

Read more about how to maintain deep work while using AI

Why This Is Worse for Junior Developers: the Expertise Reversal Effect

The same tool has opposite effects depending on your level of experience. This is one of the most important findings from the research, and almost nobody talks about it.

Why Vibe Coding Harms Junior Developers Worse

For novice developers, AI acts as a separate brain brain. It stores the outputs that the junior engineer never built internally. It skips the cognitive struggle that forms schemas. The result is fast output and shallow understanding, which is the illusion of competence in its purest form. No schema means no debugging intuition. No debugging intuition means no path to senior.

For experienced developers, AI acts as an extension of their brains. It offloads boilerplate and syntax, the artificial cognitive load that does not require judgment. The expert keeps architecture, logic, and system understanding in their head, where those things belong. AI removes friction. It does not remove thinking, because the thinking already happened before the prompt.

The consequence of this split is already visible. Entry-level compensation is under pressure as the supply of AI-assisted juniors grows. Meanwhile, the shortage of engineers who can genuinely architect and own complex systems is intensifying.

The risk is this: if AI prevents juniors from doing the hard cognitive work that produces seniors, the talent pipeline breaks at the source. Faster juniors who never become seniors. That’s a structural problem for every organization that needs experienced technical leadership five years from now.

Read this system for learning in the age of AI, and how to decide what to learn and what to do with AI

The Explainability Gap: the One Metric Worth Watching

Explainability Gap is the distance between the complexity of AI-generated code and your own conceptual understanding of it.

It measures if you are shipping code you do not own.

The self-check takes two minutes. After any AI-assisted session, close the AI tool. Explain what you just built back to yourself in plain language, out loud or in writing. Not the output. The logic. Why does this function behave this way? What happens when this edge case hits? What assumption is baked into this design?

If you cannot do that, the gap is real.

The MIT Media Lab EEG study on ChatGPT use found something that matches this: brain activity scales inversely with AI autonomy. The more the AI drives, the less the brain engages. Researchers measured reduced neural signal in the prefrontal cortex, the region responsible for reasoning and decision-making, during high-AI-autonomy sessions. The feeling of flow during AI-assisted coding may be the brain switching off, not speeding up.

Most people don’t realize we have an opportunity to do this while AI is generating the outputs. This is how:

The Stack Overflow Test: Are You Iterating or Copy-Pasting?

Most engineers have used Stack Overflow at some point. The question was never whether to look things up. It was always how you used what you found.

Two modes existed with Stack Overflow. The first: find a solution, copy it, paste it, move on. The code is in your file now. The understanding is not. The second: find a solution, read it, understand why it works, adapt it to your context, and own the result.

AI is the new Stack Overflow. The same reasoning applies.

Auto-accepting everything from AI is Blind Delegation. It is the detrimental pattern. Iterating with AI, generating code, and then working through it until you can explain it, is Generation-Then-Comprehension. It is a beneficial pattern.

The test is simple. Before you ship, ask yourself: Can I explain this code back to myself without looking at the AI output?

If yes, you are iterating. You own it.

If no, you are copy-pasting. The AI understands the code. You are shipping someone else’s work under your name.

Subscribe now

How to Use AI Every Day Without Getting Lazy

These are the habits I return to when I notice myself sliding into the detrimental patterns.

1. When the concept is new, ask AI to explain, not to generate. If you have never worked with a library or pattern before, Socratic mode is the only mode that builds a usable mental model.

2. After generating, rewrite the key logic in your own words before shipping. One paragraph. Natural language. If you cannot write it, you do not understand it.

3. Never paste an error back to AI without reading it first. Read the error. Form a hypothesis about what caused it. Then ask AI to help you test the hypothesis. Do not delegate your diagnostic process. Even if AI is faster at solving it, you’re not understanding the edge cases.

4. Treat AI confidence as marketing, not signal. The model does not know when it is wrong. You have to be the one who checks.

5. Write something without AI from time to time. This is not about productivity. It is about keeping the schema formation pathways active. It’s like having calculators, but playing the Brain Training game in your Nintendo to keep your brain active.

6. Watch your Explainability Gap. If you cannot explain it, you do not own it. Close the AI window and try. Like when you were a student, just re-reading didn’t mean you understood the concepts.

7. In a new codebase or concept, restrict AI to explanation mode. This is the period when schemas form. Don’t skip the struggle. Think by yourself.

   Subscribe now

Common Questions

Does AI make developers lazy?

Per the Anthropic 2026 randomized controlled trial, AI-assisted junior developers scored 17% lower on comprehension quizzes than peers who worked without AI. The effect is real and statistically significant with a Cohen’s d of 0.738. Whether it makes any individual developer lazy depends on how they use the tool, but the default interaction patterns trend toward the detrimental outcomes.

What did the Anthropic AI coding study actually find?

52 junior Python engineers were split into two groups. Half used Claude to learn a novel async library. Half worked manually. The AI group finished approximately two minutes faster, a difference that was not statistically significant. On the comprehension quiz, the AI group scored 50%, and the manual group scored 67%. Debugging was the weakest category for the AI group. Anthropic called the underlying effect the illusion of competence.

Is vibe coding bad for junior developers?

Yes, and the research explains why. This is called the Expertise Reversal Effect. AI helps expert developers offload boilerplate while keeping architecture and logic in-head. For junior developers, it skips the cognitive struggle that builds the judgment and schema formation they need to reach the senior level. Vibe coding for juniors is not a shortcut. It is a detour around the work that creates expertise.

How do senior developers use AI differently?

Seniors use AI to handle extraneous cognitive load, boilerplate, syntax, and formatting, while keeping intrinsic load in their own heads. The mental model is theirs. The code structure, the architectural judgment, the edge case reasoning: all internal. AI removes friction from work that the senior already understands. It does not replace the understanding.

Can you still learn to code with AI?

Yes, but only in Socratic mode. Using AI to explain concepts, guide your thinking, and critique your approach produces better learning outcomes than working without AI at all, around 19.6% improvement. Using AI to generate code, you then copy, which produces worse outcomes. The tool is identical. The question is whether you ask it to show you the answer or help you find it.

What is the Explainability Gap?

The Explainability Gap is the distance between the complexity of AI-generated code and your own understanding of it. The self-check: close the AI window and explain what you built in plain language. If you cannot, the gap is open and you are shipping code you do not own.

Subscribe now

Conclusion: The Developers Who Stay Sharp Choose to Look

The illusion of competence is not something that happens to you. It is a decision. You make it the moment when the code runs and decide to move on.

It is not.

“The feature worked. I moved on”. That is the whole pattern. The research quantifies it, the examples make it visible, and the fix is simple enough to be annoying.

You just have to decide to look, every time, at the code you are about to ship.

The developers who stay sharp are not the ones who use AI less. They are the ones who never stop owning what they build.

Key Takeaways

• AI-assisted junior developers scored 17% lower on comprehension in a 2026 Anthropic randomized controlled trial, with a large and statistically significant effect size.

• Carnegie Mellon’s 807-repo study found AI tools increase code complexity by 41% and security warnings by 30%, with no sustained velocity gain after month three.

• Three modes of AI use exist: Blind Delegation (detrimental), Manual (builds schemas), and Socratic (19.6% better learning outcomes). Most engineers default to the first.

• The Expertise Reversal Effect means AI helps senior developers amplify their judgment while preventing junior developers from building judgment in the first place.

• The Explainability Gap, the distance between code complexity and your understanding of it, is the one metric that tells you whether you own what you ship.

Subscribe now

If you want to go deeper into using AI.

If you want to become the engineer AI can’t replace.

This next article is for you:

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

Something was missing.

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

Subscribe now

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

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

In this post, you’ll learn

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

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

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

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

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

Subscribe now

The AI slop problem you already recognize

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

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

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

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

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

What developer taste actually is

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

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

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

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

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

Subscribe now

What taste looks like in practice with AI tools

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

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

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

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

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

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

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

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

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

What taste mistakes look like

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

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

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

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

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

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

Subscribe now

How to develop a developer's taste

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

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

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

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

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

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

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

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

The career implications of a software engineer’s taste

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

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

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

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

You can train it. You just have to start.

Subscribe now

Some Common Questions About Developers’ Taste

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

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

Can AI have good taste in code?

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

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

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

What is an AI taste mistake?

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

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

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

Subscribe now

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

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

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

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

None of it is glamorous. All of it works.

Key Takeaways

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

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

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

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

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

Subscribe now

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

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

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

Subscribe now

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

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

Here’s what comes next in the series:

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

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

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

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

In this post, you’ll learn:

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

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

• How the daily briefing replaces your morning app routine

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

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

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

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

The first is not trusting the system 100%.

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

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

The second is data getting stale.

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

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

The third is getting overwhelmed.

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

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

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

What an Agent-Driven Task System Needs

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

Zero friction to add tasks.

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

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

Organized by context, not chaos.

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

Views that match how you actually think. “

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

The AI Daily Briefing: Replace Your Morning App Routine

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

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

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

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

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

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

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

Read more

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

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

Subscribe now

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

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

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

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

In this post, you’ll learn

• How to optimize sleep and diet for cognitive performance

• Methods to raise the quality of your technical work.

• Techniques to document your impact for career advancement

Health

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

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

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

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

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

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

Subscribe now

Technical

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

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

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

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

Read more

Subscribe now

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

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

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

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

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

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

In this post, you’ll learn

• How to reduce decision fatigue

• Strategies for batching communication and admin tasks.

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

• Ways to systematize recurring decisions to reduce friction.

The core algorithm (separate planning from execution)

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

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

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

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

Handling the “shallow” stack

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

Read more

Subscribe now

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

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

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

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

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

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

In this post, you’ll learn

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

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

• When you need more than one agent.

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

The process

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

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

Subscribe now

1. Learn the manual process first

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

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

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

Subscribe now

2. Solve it with manual AI prompts

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

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

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

Subscribe now

3. Plug in MCP servers

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

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

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

Subscribe now

4. Create agent skills for repeated prompts

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

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

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

In essence, a skill is

1. Something the AI learns to do.

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

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

My example with the JSON files:

• SKILL.md

• ADD.py

• FIND.py

• REMOVE.py

My example of handling JIRA tickets:

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

  Subscribe now

5. Orchestrate with an agent SOP

Read more