Microsoft Research just shipped a tool called SkillOpt that takes that idea literally.

SkillOpt is a text-space optimizer that trains reusable natural-language skills for frozen LLM agents through trajectory-driven edits, validation-gated updates, and deployable best_skill.md artifacts.

It treats the skill markdown you hand an agent (the instructions, the system prompt, the SKILL.md) as trainable state. It runs epochs. It has a batch size. It has a learning rate. It just never touches the model weights. The weights stay frozen behind the API. The thing that gets trained is the text.

The loop is short. Run the agent on a batch of tasks. Score each one. A second model reads the failures and proposes small edits to the skill file. Keep an edit only if it improves a held-out score. Repeat. What you get at the end is a best_skill.md you drop in front of the same unchanged model.

I wanted to see it actually work, so I gave it a job…

The setup

I had OpenAI Codex do the writing. The task: take a paragraph stuffed with AI slop and clean it up. The skill it started from was short:

Improve the passage so it reads a little better. Keep the meaning and roughly the length.

No mention of slop. No list of banned words. Nothing to go on.

The verifier was the part that mattered. I wrote a dumb little counter that scans the output for the tells (the canned phrases, the em-dashes) and returns how many are left. Fewer is better. That is the whole eval. Objective, cheap, no judgment calls.

Then I let SkillOpt run.

What it wrote

The seed turned into a thirty-line deslop skill. SkillOpt wrote it.

It worked out, on its own, that “remove AI slop” is a removal constraint and not a tone nudge. It named the exact phrases that kept leaking through (“let’s dive in,” “have you ever wondered,” “it’s worth noting,” “furthermore,” “in conclusion,” “great question”). It flagged em-dashes. And it caught the sneaky failure mode I never told it about: the model dodging a banned word by swapping in a synonym. That one became its own rule, the last line of the file:

Before answering, do a quick scan to ensure none of the original flagged words remain, including close synonyms you may have introduced.

The score went from passing half the held-out passages to passing all of them. The skill it wrote is one I would actually keep.

The part worth keeping

The optimizer is the easy part.

I went in assuming the clever bit was the model proposing edits. It isn’t. The clever bit is the verifier. Give SkillOpt a score and nothing else and it does nothing. I tried that first. It saw the failures, shrugged, and changed not a single line, because “you got a 0.6” tells it nothing about what to fix. The run that worked was the one where the verifier also said which words leaked. Same model, same loop. The difference was the signal.

So the rule of thumb is less “use the self-improving optimizer” and more: can you score this cheaply, and can you tell it why it failed. If yes, the skill mostly writes itself. If no, there is nothing to train and the fancy loop sits there idle.

That is also the catch, and it is the same catch hiding under every self-improving-agent demo. A slop counter is a clean verifier. Most of what you do in a day is not. “Was this brief any good.” “Did this post land.” No cheap score, no training. The optimizer was never the bottleneck. The verifier is.

So build the verifier first. Get that right and the skill mostly writes itself.

Bonus: a taste of running it

The repo is github.com/microsoft/SkillOpt. MIT licensed, Python.

Get it:

pip install skillopt
# or, to poke at the internals:
git clone https://github.com/microsoft/SkillOpt && cd SkillOpt && pip install -e .

The mental model is one small folder per task. A loader that hands over your examples, a rollout that runs your agent and scores it, and a seed skill to start from. SkillOpt’s whole job is to grow that seed.

The config reads like a training run, on purpose:

train:
  num_epochs: 4
  batch_size: 40
optimizer:
  learning_rate: 4        # max edits to the skill per step
  lr_scheduler: cosine
evaluation:
  use_gate: true          # keep an edit only if it beats the held-out score
model:
  optimizer: gpt-5.4      # the model that proposes the edits

Then it is one command:

python scripts/train.py --config configs/yourtask/default.yaml

The only part that is really on you is the scoring. Your rollout returns, per task, a pass/fail and a number between 0 and 1:

return {"id": task_id, "hard": passed, "soft": fraction_correct}

That is the whole contract. Give it tasks, a way to score them, and a skill to start from. It runs the epochs.

One side note: keep the tasks hard enough that the agent fails some of them. If it aces everything on the seed skill, there is nothing to learn and SkillOpt politely does nothing. Ask me how I know.

I read through it expecting to roll my eyes. Instead I sat there nodding, because I’d accidentally built a tiny version of the same thing for this blog.

The pitch

gstack’s whole argument is that solo builders don’t lose to big teams because they’re worse engineers. They lose because they skip process. One person at a keyboard, prompting Claude into existence one vibe at a time, eventually ships something that works. Until it doesn’t. No review. No second opinion. No one asking “wait, should we even build this?”

So gstack bakes the process in. Every skill is a slash command, and each command plays a role in a pipeline:

Think → Plan → Build → Review → Test → Ship → Reflect

You start a project with /office-hours, which hits you with six forcing questions before you write a line of code. Then /plan-ceo-review challenges your scope. /plan-eng-review draws the data-flow diagrams and enumerates the edge cases. You build. /review does a staff-engineer pass and auto-fixes the obvious stuff. /qa opens an actual Chromium browser, clicks through your app, finds bugs, and writes a regression test for each one it fixes. /ship runs the suite and opens the PR.

Each stage feeds the next. The CEO’s decisions constrain the engineer. The engineer’s plan constrains the build. Nothing happens in a vacuum. That’s exactly the part solo work gets wrong.

There’s a whole security wing too. A /cso skill that runs OWASP Top 10 and STRIDE threat modeling. A sidebar Claude that watches for prompt injection. A /careful mode that warns you before rm -rf ruins your afternoon. It’s a lot. The point isn’t that you use all of it. The point is that the roles exist, named and on call.

Why this looked familiar

Here’s the thing. I don’t ship code through a blog. I ship words. But the moment I saw that pipeline I recognized it, because the posts you’re reading go through the same kind of relay.

When I write here, an idea doesn’t go straight from my head to WordPress. It moves through stages, and each stage has one job:

• Research does the digging and writes up a structured report. Pitch, key facts, angle, the competition check.
• Refine tightens the structure and pacing without touching the voice.
• De-slop strips out the AI tells. The em-dashes, the “it’s not just X, it’s Y,” the forced enthusiasm, the closer that tries to sound profound.
• Voice rewrites it to sound like me. Short sentences. Plain words. No throat-clearing.
• Format turns it into clean WordPress blocks.

Each one hands off to the next. Same shape as gstack. A CEO who reframes the product is doing what my research stage does for a post. A designer who catches AI slop is, almost word for word, my de-slop pass. Garry Tan built an org chart for shipping software. I built a smaller one for shipping writing, and I didn’t even notice the resemblance until his showed up.

I’m not claiming I invented anything. The idea is in the water. Once you spend enough time working alongside an agent, you stop treating it like one genius who does everything and start treating it like a team you have to manage. You give each role a narrow job and a clean handoff. That’s not a trick. It’s just how good teams have always worked, now running in a terminal.

The number everyone’s going to argue about

gstack ships with a doc making a bold claim: Garry measured his own output and found he’s writing about 810 times more code per day than he did back in 2013 when he was coding part-time around a day job. Eleven thousand logical lines a day across his first 108 days.

Your skepticism alarm should be going off. So was his. He concedes up front that lines of code is a garbage quality metric. His own line: measuring programming progress by lines of code is like measuring aircraft-building progress by weight. So he deflates the number hard. Strips comments and blanks, applies a 2x penalty for AI being verbose and defensive, and lands at something like 5,700 lines a day. Still a wild figure. Still self-reported, so take it with salt.

But the interesting claim isn’t the speed. It’s the quality holding steady while the speed goes up. A 2 percent revert rate, right in line with the open-source baseline. Two thousand-plus automated tests with CI. A 95 percent success rate across 305,000 skill runs. His actual thesis is buried under the headline number:

“Testing at multiple levels is what makes AI-assisted coding actually work.”

That one I believe without reservation, because it’s the same thing the pipeline is really about. The process isn’t there to make the agent faster. It’s there to catch the agent when it’s confidently wrong, which it will be, several times a day. Every stage is a checkpoint, a chance for something to get caught before it ships. The payoff isn’t speed, it’s fewer mistakes reaching the end.

What I did with it

I’m not installing the whole thing. gstack is TypeScript and Bun and Playwright, built for shipping web apps, and Windows is a second-class citizen in it. Not my stack. Not my use case.

So I stole the front of it instead. The skill I keep coming back to is /office-hours: six forcing questions you have to answer before you’re allowed to build anything. Who is this for. What’s the sharpest version of it. What are you quietly avoiding. It’s a CEO review for an idea that doesn’t exist yet.

That maps straight onto the worst part of blogging, which is deciding what’s even worth writing. So I pointed it at this blog. Before a topic earns a draft, I run it through the same kind of interrogation in Claude Code. What’s the one sentence. Who already wrote it better. What’s the angle only I have. Why now. Most ideas die right there, which is the point. The ones that live show up to the draft stage already knowing what they are.

This post is one of them. gstack was the raw idea. The forcing questions are what turned “gstack exists, that’s neat” into something with an angle worth your time. The tool I borrowed from is the tool that helped me write about borrowing from it.

So here’s what you should know today. gstack is out there, it’s free, and even if you never run a line of it, the shape is worth stealing. Garry Tan built that discipline for code. I run a lighter version of it on words. You can point it at whatever you make. The pipeline is the product. The agent’s just the labor.

Fine for a side-project web app. Does not work for an inverted pendulum spinning on your desk.

The Pit and the Pendulum

MathWorks just published a Tech Talk by Brian Douglas. It is worth watching if you build hardware.

The setup is a Quanser cube servo with an inverted pendulum, a Raspberry Pi running the controller, and a coding agent wired into Simulink through the Simulink Agentic Toolkit. The agent’s job is to swing the pendulum up and balance it.

Balancing an inverted pendulum is a classic control problem because it’s unstable by nature. Get the math wrong and the pendulum falls. Get the code wrong and a 12V motor jerks the cube into something it shouldn’t.

What Happens If You Just Prompt It

The tempting move is the one most of us have done with web apps. Open a chat, describe the system, ask for the code. One prompt, big blob, ship it.

The MathWorks engineers walk through why that falls apart for hardware:

“If you rely on AI to generate code directly, that process is much less structured… it’s often unclear exactly how or why a particular implementation was created, making it harder to trust and verify.”

Brian Douglas

Hardware is unforgiving. You can’t roll back a destroyed motor with a git revert. When a physical system fails, you need to know which assumption broke, which equation got the wrong constant, which sample rate the controller is actually running at. A black box of generated C code doesn’t tell you any of that.

“You don’t want to let your AI agent skip parts of your engineering workflow. That’s how you can get yourself into trouble with a final product that doesn’t meet your objective or worse, is just purely unsafe.”

Brian Douglas

The Workflow Is the Script

The answer is to keep the AI inside the workflow engineers already trust: Model-Based Design. The agent doesn’t replace the workflow. It runs each step inside it, faster.

Define quantifiable requirements. Before any code, the human and the AI agree on what success looks like. Spin-up speed. Wobble limits. The 12V motor constraint. These targets become the benchmarks for verification later.

Use a trusted model. Instead of letting the AI invent a custom physics engine, the workflow points it at an existing Simulink model. The agent runs linearization through the Simulink Agentic Toolkit and reports the system’s poles back to the human. The math comes from validated tools, not from a language model freestyling differential equations.

Use a trusted controller. Same logic. The agent is told to use the MPC Toolbox. Model Predictive Control has decades of theory behind it and a deterministic implementation. If something looks wrong, you can tune it manually. You’re not debugging an optimizer the AI invented on the fly.

Verify in layers. Three stages before the code touches hardware:

• MIL (Model-in-the-Loop): the controller runs against the theoretical model
• SIL (Software-in-the-Loop): the generated embedded C code runs on a computer, behaving exactly like the simulation
• PIL (Processor-in-the-Loop): the C code runs on the actual target Raspberry Pi

Each layer catches different bugs. Skip one and you’ll catch that bug on hardware instead.

Deploy and iterate. Only after layered verification does the code go on the real pendulum.

“Instead of asking an agent to solve your problem however it wants, you tell it to follow an engineering workflow that you understand.”

Brian Douglas

The AI executes. The human directs.

The Hardware Truth

Here’s the part of the video I liked best. They ran the verified controller on the real pendulum and it didn’t quite work. The physical hardware behaved differently from the model.

This is what the vibe-coding fantasy ignores. Reality disagrees with simulation, especially the first time. You will need to iterate. The thing that matters is whether you can.

Because the team followed the workflow, they could. The model was traceable. The requirements were quantifiable. The controller was inspectable. They used the AI to update the physics model, ran it back through MIL, SIL, and PIL, and tried again. No starting over.

The workflow doesn’t promise perfect code on the first pass. It promises code you can fix.

The Director Pattern

A few months ago, I wrote about Seth DeLand’s framing of agentic AI for engineers. The headline idea: you’re not being replaced, you’re being promoted. The engineer becomes the one who defines the problem, sets the constraints, and shapes the space where the AI works.

The MathWorks Tech Talk is what that looks like in hardware. The AI isn’t the engineer. It’s the agent. You’re the director.

“Agentic AI is powerful, but for engineering, the value comes from how you use it. You get the speed and productivity benefits of AI without sacrificing trust, safety, or understanding.”

Brian Douglas

You don’t get speed and safety together by handing the AI a prompt and crossing your fingers. You get there by keeping the workflow you trust and letting the agent move faster inside it.

Speed without losing safety. Productivity without losing traceability.

For software, vibe coding is mostly fine. The blast radius is a wasted afternoon.

For hardware, the blast radius is a sparking motor and a pendulum on the floor.

Five months later, I owe that post an update. The stack evolved.

The Agent Engineer

Seth DeLand has been at MathWorks for fifteen years. He started in mechanical engineering, building mathematical models for diesel combustion and NOx emissions. Control strategies, optimization, statistics. The kind of work where getting the math wrong means the engine doesn’t meet spec. Now he’s a Product Manager focused on generative AI, and he recently sat down with Jousef Murad on the Engineered-Mind Podcast to talk about what agentic AI means for engineers.

He’s not selling hype. He’s describing what he sees happening in real engineering workflows.

On what makes agentic AI different from chatting with an LLM:

“Rather than it just generating a bunch of text, it’s actually going to generate calls to APIs… now they’re not limited just to generate text as an output, they can actually start to work on the same artifacts that we humans are working on.”

Seth DeLand

That distinction matters. An LLM gives you text. An agent gives you results. It runs your code, checks your tests, detects your toolboxes, and iterates on errors. No copying and pasting between windows. The agent works on your project, not a hypothetical version of it.

Seth didn’t frame this as tools replacing engineers. He framed it as engineers leveling up.

“It’s more that we are working at a higher level now. We are thinking much more in terms of what are the problems, what are the constraints, how do I shape the solution space so that I can turn my AI loose in that solution space and have it go work… and then come back to me.”

Seth DeLand

You’re not being replaced. You’re being promoted. The engineer becomes the one who defines the problem, sets the constraints, and shapes the space where the AI works. That’s not a demotion. That’s what senior engineers have always done, except now the junior engineer on your team is an agent that never sleeps and never complains about the build system.

Seth also nailed something I’ve been feeling since I started using agents for prototyping:

“Why not have it implement four prototypes of all of those different options and see which one I like the best… it allows me to shorten that cycle to get from kind of an idea to some type of proof of concept.”

Seth DeLand

Four prototypes. Not four design docs. Four working implementations. You compare running code instead of arguing about architecture diagrams. I wrote a whole post about this idea (Twenty Prototypes), and hearing a MathWorks PM describe the same workflow independently tells me this isn’t a niche trick. It’s becoming the default.

What Changed Since November

When I wrote the original super stack post, the MATLAB MCP Core Server was at version 0.1. First release. Five tools. It worked, but everything is moving fast.

Here’s where things stand now:

The MCP server is at v0.6.1. MathWorks shipped cross-platform MCP Bundles for one-click installs, added headless mode so MATLAB can run without the desktop GUI, and introduced MCP Resources that feed coding guidelines directly to your AI agent. Nine releases in five months.

MATLAB Copilot launched with R2025a in May 2025. It’s a purpose-built AI assistant inside the MATLAB desktop with chat, code generation, autocomplete, and error explanations. They even upgraded the underlying model to GPT-5 mini a month after launch.

Simulink Copilot entered beta. You can chat with your Simulink models, search and trace features with natural language, and troubleshoot errors through a dedicated panel on the canvas. If you do model-based design, this is worth watching.

And the MCP ecosystem around it exploded. MCP now has 97 million monthly SDK downloads and over 10,000 active servers. Anthropic donated it to the Linux Foundation. OpenAI, Google, Microsoft, and Amazon all support it. MathWorks calls MCP “USB-C for AI,” and that metaphor has held up.

The super stack isn’t experimental anymore. It’s infrastructure.

The Setup: MATLAB MCP + VS Code + GitHub Copilot

The original post showed the stack with Claude Code. This time I’ll set it up with GitHub Copilot in VS Code. Same MCP server, different AI client. That’s the whole point of an open protocol.

What you need:

• MATLAB R2020b or later, installed and on your system PATH
• Visual Studio Code with the GitHub Copilot Chat extension
• The MATLAB Extension for VS Code (optional but recommended)
• A GitHub Copilot subscription (the free tier works)

Step 1: Download the MCP server

Go to the MATLAB MCP Core Server releases page on GitHub and download the binary for your platform:

• Windows: matlab-mcp-core-server-win64.exe
• macOS Apple Silicon: matlab-mcp-core-server-maca64
• macOS Intel: matlab-mcp-core-server-maci64
• Linux: matlab-mcp-core-server-glnxa64

On macOS or Linux, make it executable: chmod +x matlab-mcp-core-server-*

Step 2: Configure VS Code

Create a .vscode folder in your project root (if it doesn’t exist), then add an mcp.json file:

{
    "servers": {
        "matlab": {
            "type": "stdio",
            "command": "C:\\path\\to\\matlab-mcp-core-server-win64.exe",
            "args": [
                "--matlab-root=C:\\Program Files\\MATLAB\\R2025a",
                "--initial-working-folder=C:\\Users\\you\\YourProject"
            ]
        }
    }
}

Replace the paths with your actual MATLAB installation and project directory. On macOS or Linux, use forward slashes.

Step 3: Validate

Open GitHub Copilot Chat in VS Code and ask: “Which MATLAB toolboxes are available?”

If everything is wired up, the MCP server launches MATLAB in the background and Copilot responds with your installed toolboxes. The first call takes a few seconds while MATLAB starts. After that, it’s fast.

What you get:

Five tools, available to any MCP-compatible AI client:

• detect_matlab_toolboxes: Lists your installed MATLAB version and toolboxes
• check_matlab_code: Runs static analysis on a .m file (style issues, errors, deprecated functions)
• evaluate_matlab_code: Executes a MATLAB code string and returns the output
• run_matlab_file: Runs a .m script file
• run_matlab_test_file: Runs MATLAB unit tests

Plus two MCP Resources (added in v0.3) that feed your AI agent the official MATLAB coding guidelines. The agent doesn’t just write MATLAB code. It writes MATLAB code that follows MathWorks conventions. 1i instead of i for imaginary numbers. k for loop variables. Error handling the way the documentation says to.

“I think one of the impressive things about a lot of these AI models is that if you can teach it about the system that it’s working on… they can build on top of existing things that you have.”

Seth DeLand

That’s exactly what the MCP server does. It teaches the AI about your MATLAB installation, your toolboxes, your project. The agent isn’t guessing. It’s building on what you already have.

You Are the Engineer

The tools got better. The MCP server matured. The ecosystem grew. But the most important upgrade in the super stack isn’t software.

It’s you.

You decide what problem to solve. You set the constraints. You shape the solution space and turn the agent loose inside it. When it comes back with four prototypes, you’re the one with the engineering judgment to pick the one that actually works for your system.

The agent writes code, runs tests, checks for deprecated functions. It can’t decide what matters. That’s your job.

Seth put it well: engineers are working at a higher level now. Not because the tools forced them to, but because the tools finally caught up to where the interesting problems live. The math. The constraints. The design decisions that determine whether the system works when it meets the real world.

The super stack is MATLAB, VS Code, and an AI agent connected through MCP. The stack doesn’t work without the engineer at the top of it.

Here’s what actually happened. The World Economic Forum ran the numbers in its 2025 Future of Jobs Report. By 2030, AI will displace 92 million jobs. It will also create 170 million new ones. That’s a net gain of 78 million jobs that didn’t exist before.

The List (So Far)

Prompt Engineer

We automated programming and accidentally invented a new kind of programming that’s just typing English very carefully. Average salary: $130K. The job didn’t exist in 2022. By 2025, postings had grown 135%. The skill is knowing that “write me a function” and “write me a function that handles edge cases, returns typed errors, and doesn’t hallucinate an API that doesn’t exist” are very different sentences.

Vibe Coder

This is a real job title. There are 372 open positions on ZipRecruiter right now. Upwork has a dedicated marketplace category. One company posted a listing for “Vibe Coder, Applied AI & Rapid MVP Builder” paying $75K to $95K. There is an entire job board called VibeCodeCareers.com. Second Talent published an official Vibe Coder Job Description Template. I checked. Twice. We are living in a simulation.

Context Engineer

A Prompt Engineer got promoted. Context Engineers design systems that give AI the right information at the right time. Not the prompt. The stuff around the prompt. The job is making sure the AI knows what it’s talking about before it starts talking. You’d think that would be automatic. It is not.

AI Trainer (Formerly “Intern”)

Same tasks as before. Writing code, solving problems, answering questions. But the output trains a model instead of building a career. Pay ranges from $15/hr for basic annotation to $200/hr for specialized domain work. AI labs are spending over a billion dollars a year on human training data. Someone has to be the human.

Agent Manager

Harvard Business Review wrote about this role in February. Microsoft calls it “agent boss.” The job is tracking quality, refining prompts, managing handoffs, and figuring out why the agent just told a customer something completely made up. A third of managers now plan to hire people whose primary job is managing AI agents. Not building them. Babysitting them.

Hallucination Auditor

Reads AI output and checks whether the facts are real. The citations. The statistics. The API endpoints. The version numbers the agent invented for a library that’s still on 1.4. A Deloitte team skipped this step and delivered a $440,000 government report with at least twenty fabricated sources. Then they did it again on a million-dollar report. Full-time hallucination auditing is not overkill. It is, apparently, not enough.

AI Red Teamer

Gets paid to break AI systems on purpose. Salary: $60K to $160K depending on how good you are at tricking a language model into saying things it shouldn’t. Only 14% of organizations believe they have enough AI security talent. That means 86% of organizations are hoping nobody tries.

GEO Strategist

SEO, but for AI. GEO stands for Generative Engine Optimization. The job is making sure your company shows up when someone asks an AI a question instead of Googling it. Same game, different referee. The referee hallucinates sometimes.

Data Labeler (Specialized)

Simple labeling pays $15/hr. Medical annotation pays $50 to $100/hr. The gap tells you everything about where AI actually struggles. Labeling a picture of a dog is easy. Labeling a radiology scan is hard. The harder the task is for humans, the more humans get paid to teach the machine. The job AI was supposed to kill (repetitive classification) turned into the job AI can’t live without.

Lore Engineer

Not an official title yet. Give it six months. This person maintains documentation so AI agents don’t develop false beliefs about the codebase. When an agent keeps rebuilding a feature you deleted because it found a stale Confluence page from 2023, someone has to hunt down the ghost and kill it. We used to call this “technical writing.” Now it pays more because the reader is a bot that takes everything literally.

AI Ethics Officer

Someone whose job is making sure the AI doesn’t do the things that humans were already doing. The role requires balancing privacy, fairness, transparency, and the company’s desire to ship fast and worry later. The “worry later” part keeps the Ethics Officer employed indefinitely.

Model Whisperer

The unofficial title for the person on every team who’s just… better at talking to AI than everyone else. Nobody trained them. They don’t have a certificate. They just know that adding “think step by step” to the end of a prompt makes the output 40% better, and they can’t really explain why. Every team has one. Nobody put it in their job description. Yet.

The Pattern

Every one of these jobs exists because AI is good enough to be useful and bad enough to need supervision.

That’s the whole thing. AI can write code, but someone has to check it. AI can answer questions, but someone has to verify the answers. AI can make decisions, but someone has to make sure those decisions aren’t insane. AI can generate content, but someone has to make sure it doesn’t sound like it was generated by AI. (Hi.)

The jobs didn’t disappear. They shapeshifted. The new work is weirder, more specialized, and occasionally involves losing an argument to software about whether a function is deprecated. It usually isn’t. But sometimes it is. That “sometimes” is what keeps things interesting.

They weren’t visitors. They were agents.

You Are Now the Minority

In 2024, automated traffic surpassed human traffic on the internet for the first time in a decade. Bots now account for 51% of all web traffic. Cloudflare processes 50 billion AI crawler requests per day. GPTBot traffic alone grew 305% in one year.

The web you built for humans? Humans aren’t the primary audience anymore.

Retail sites see 59% bot traffic. Travel sites: 48%. These aren’t all scrapers or spam bots. Increasingly, they’re shopping agents, research agents, booking agents. Doing things humans used to do, on websites humans used to visit.

Cloudflare published a stat that stopped me cold. For every single visitor Anthropic refers back to a website, its crawlers have already visited 38,065 pages. OpenAI’s ratio is 1,091 to 1. Perplexity: 194 to 1. The agents read your site a thousand times for every one human they send your way.

The web hasn’t died. But it’s molting.

The Protocol War

If 2024 was the year we noticed agent traffic, 2025 was the year everyone started building the plumbing.

Anthropic released MCP (Model Context Protocol) in November 2024. People call it “USB-C for AI,” a universal adapter that lets any AI system talk to any tool or service. It now has 97 million monthly SDK downloads and over 10,000 active servers. In December 2025, Anthropic donated it to the Linux Foundation’s new Agentic AI Foundation, co-founded with Block and OpenAI. Platinum members include AWS, Google, Microsoft, Bloomberg, and Cloudflare.

Google launched A2A (Agent-to-Agent Protocol) in April 2025. It lets agents from different vendors discover each other using “Agent Cards,” basically JSON resumes. Over 150 organizations signed on, including Microsoft, Amazon, SAP, Salesforce, and PayPal. Adobe and S&P Global already use it in production.

Then the commerce-specific protocols showed up. Shopify and Google co-developed UCP (Universal Commerce Protocol), endorsed by Etsy, Wayfair, Target, and Walmart. OpenAI and Stripe built ACP (Agentic Commerce Protocol), which powers “Buy it in ChatGPT,” launched February 2026.

There’s more. Jeremy Howard proposed llms.txt, a file that tells LLMs where your best resources are (the inverse of robots.txt, which tells crawlers where NOT to go). Over 600 sites adopted it, including Anthropic, Stripe, and Cloudflare. Vercel went further, proposing embedded LLM instructions directly in HTML: <script type="text/llms.txt">. Their 401 error pages already serve agent-specific instructions.

This is the HTTP moment for agents. The protocols being written right now will shape how the agentic web works for the next decade.

When Your User Has No Eyes

We’ve spent thirty years making websites look good. Careful typography. Hero images. Hover effects. Cookie banners with the “Accept All” button slightly bigger than the “Manage Preferences” button. All designed for humans who see, click, and feel.

Your next billion users won’t see any of it.

An AI shopping agent doesn’t care about your hero image. It doesn’t notice your brand colors. It doesn’t feel the emotional pull of your “Limited Time Only” banner. It parses your structured data, checks your Schema markup, reads your JSON-LD, and makes a decision based on price, specs, availability, and reviews.

CSS is irrelevant when your user has no eyes.

Bain found that 80% of consumers already rely on zero-click results for at least 40% of their searches, reducing organic traffic by 15-25%. Google referrals to news sites dropped 9-15% in 2025. That funnel where you attract visitors with content, dazzle them with design, and convert them with psychology? Agents skip the entire thing. They go straight to the data layer.

HubSpot put it bluntly: “The fastest-growing decision-maker in your funnel cannot see your ad, feel your brand, or be persuaded by your story.”

The advertising model of the internet is about to face its first existential threat since ad blockers. Except ad blockers were opt-in. Agent browsing is default. When Perplexity’s Comet browser started bypassing Amazon’s advertising, Amazon sued. A federal judge blocked Comet from Amazon on March 10, 2026. Perplexity argued the real motivation was protecting ad revenue, not cybersecurity.

That lawsuit is a preview. The entire attention economy was built on the assumption that humans look at screens. Agents don’t look at anything.

The Money Is Already Moving

This isn’t theoretical. The money has already started flowing through agent channels.

During Cyber Week 2025, one in five orders globally were associated with AI tools or agents. That’s 20% of all orders, roughly $67 billion. On Cyber Monday alone, AI traffic to US retail sites increased 670%. AI-influenced shoppers converted 38% more frequently than traditional visitors.

McKinsey estimates agentic commerce could redirect $3-5 trillion in global retail spend by 2030, with nearly $1 trillion from the US alone. Payment executives told CNBC this could be “more transformative than the rise of e-commerce platforms such as Amazon.”

The platforms are racing to own the checkout. Shopify launched Agentic Storefronts, letting merchants appear on ChatGPT, Perplexity, Microsoft Copilot, and Google AI Mode without needing a traditional website at all. Amazon built “Buy for Me,” an AI agent that purchases from third-party brand sites so customers never leave Amazon. OpenAI launched “Buy it in ChatGPT” in February with Stripe’s Agentic Commerce Protocol behind it.

Visa launched its Trusted Agent Protocol in October 2025, an open framework to distinguish legitimate AI agents from malicious bots. Mastercard is building its own trust framework. Both are running real transactions. Not pilot stage. Deployment.

47% of US shoppers already use AI tools for at least one part of their shopping journey. That number is going one direction.

What to Do About It

The agentic web is coming whether your site is ready or not. The transition will be messy, dual-interface, and gradual. Here’s what the practical path looks like.

Structured data first. Schema markup, JSON-LD, clean OpenGraph tags. This is the content layer agents actually read. If your product pages don’t have machine-readable pricing, availability, and specs, you’re invisible to agent shoppers.

Add llms.txt. It takes ten minutes. Create a /llms.txt file that tells LLMs where your most useful resources live. Over 600 sites have done this already. It’s the new robots.txt, but instead of “go away” it says “here’s the good stuff.”

Build an MCP server. If you have an API, wrap it in MCP. Anthropic, OpenAI, Google, and Microsoft clients all support the protocol. This is how agents will interact with your service natively, without scraping your UI.

Rethink your metrics. Traffic is no longer a proxy for interest. An agent visiting your site 38,000 times doesn’t mean you have 38,000 interested customers. You need to distinguish agent traffic from human traffic and measure what agents actually do: transactions, API calls, data retrieved.

Plan for agent authentication. Visa and Mastercard are already building trust frameworks. If your business involves transactions, you’ll need a way to verify that the agent placing an order is authorized to act on behalf of a real customer.

The visual web isn’t going away tomorrow. Humans still browse. But the share of your traffic that sees your CSS is shrinking every quarter, and the share that reads your structured data is growing. Design for both.

Your Homework

Go to your website’s analytics right now. Look at your traffic. Filter for known bot user agents. The number will be higher than you expect.

Then add a llms.txt file to your site root. Ten minutes. Tell the agents where the good stuff is.

The web is being rebuilt. You can watch, or you can leave the light on for your new visitors.

They won’t see it. But they’ll know it’s there.

Here’s the thing that’s been bugging me. I’ve been building stuff for a long time. Software, hardware, IoT platforms, weird pinball mods — you name it. And every single time I start a new project, there’s this moment where I think, “Didn’t I already do this part?” The setup. The boilerplate. The config files. The architecture decisions I’ve already made a dozen times before.

I call it the Groundhog Day Problem.

Your tools don’t remember you. You close the tab, and it’s like you never existed.

“Sixty to eighty percent of what you do on a new project, you’ve already done before.”

Hans Scharler

And yet, every time, you start from scratch. That’s not a feature. That’s a bug.

TL;DR

The Work Surface That Learns

Compound Engineering is the idea that your work surface — the environment where you actually do the work — should learn, adapt, and accumulate knowledge over time. Not like templates. Templates are dead things. I’m talking about living intelligence that evolves with you.

Think of it like compound interest, but for productivity. Every workflow you capture, every pattern you codify, every piece of knowledge you extract — it doesn’t just help you today. It helps you tomorrow, next month, and next year. It accrues.

I’ve been experiencing this firsthand. When I wrote about The Engineering Super Stack, I was already circling this idea — stacking the right tools so they yield something greater than the parts. But Compound Engineering goes further. It’s not just about picking good tools. It’s about tools that get better because you used them.

Five Layers That Stack

When I break it down, there are five layers to this compounding:

Workflows are the foundation. You do something once, capture the sequence, and now you can replay it, remix it, evolve it. That deployment script you write from memory every time? Capture it. Done.

Skills take it further — encoding your domain expertise into reusable, shareable modules. The stuff that lives in your head? Make it executable.

Commands are where you start to feel the leverage. Those ten steps you do every Monday morning? Collapse them into one. One click. Gone.

Agents are where it gets fun. Autonomous workers that carry your intent forward while you’re doing something else — or sleeping, which I hear some people do.

Knowledge is the substrate beneath everything. Context that doesn’t just persist — it deepens and connects across projects, across teams, across your career.

Each layer feeds the next. That’s the compounding.

Project 1 vs. Project 10

Here’s how it plays out in practice:

Project one, you build everything from scratch. You’re exploring, making mistakes, learning. It’s slow, and that’s fine.

By project three, your workflows are captured. Setup takes half the time. You’re not reinventing the wheel anymore.

By project five, agents handle the boring parts. Boilerplate? Done. Config? Done. You’re spending your time on the interesting problems — the ones that actually need your brain.

By project ten, you describe what you want, and the system drafts the first 70%. You refine, you polish, you add the creative spark. But the heavy lifting? Already handled.

Project ten shouldn’t feel like project one. And now it doesn’t have to.

I’ve talked before about how empathic AI prompting changed the way I work — treating your AI like a collaborator instead of a vending machine. Compound Engineering is the next step. It’s not just about how you talk to your tools. It’s about your tools remembering every conversation you’ve ever had.

What Actually Changes

This isn’t incremental. This rewrites the economics of work.

Onboarding gets transformed. New team members don’t get a wiki link and a “good luck.” They inherit the team’s compound knowledge from day one — the workflows, the skills, the patterns.

Expertise becomes portable. When your best engineer moves on, their expertise stays. Codified, not tribal.

The gap between “senior” and “junior” shrinks. Not because junior developers suddenly gain ten years of experience, but because the tools carry the seniority. The tools know the patterns. The tools remember the pitfalls.

Solo operators gain the leverage of teams. Small teams gain the leverage of enterprises. That’s not a tagline. That’s just what happens when you make expertise executable.

The Risk of Not Doing This

I’ll be blunt. If you’re not compounding, you’re falling behind.

Linear workers — folks doing great work but starting from zero every time — hit a ceiling. There’s only so fast you can move when you’re rebuilding the foundation each time. Compound workers hit escape velocity. Same talent, same hours in the day, dramatically different output over time.

Organizations feel this even harder. Institutional knowledge that isn’t captured gets lost to attrition, to time, to entropy. Your best person leaves, and a decade of expertise walks out the door with them.

The future belongs to whoever builds the flywheel first.

Where This Is Going

I see three things coming.

• Connected work surfaces… where your tools talk to your teammates’ tools. Work surfaces that negotiate and share context without a meeting.
• Skills marketplaces… codified expertise becoming a tradeable asset. A senior DevOps engineer publishes their deployment workflow. A startup buys it and deploys like a Fortune 500 company on day one.
• Career-long AI… a personal AI that doesn’t reset when you change jobs. It compounds across your entire career. Every problem you’ve solved, every domain you’ve mastered, every lesson you’ve learned.

Start the Flywheel

Here’s your homework. Codify one workflow this week. Just one. That deployment script you always write from memory. The project setup you’ve done forty times. The onboarding checklist that lives in your head.

Write it down. Automate it. Make it reusable. Watch what happens.

Claude Code might be the most significant event of 2025 in the field of AI. For me, it changed the course of the year and led me to unthinkable places. I followed every twist and turn and stayed on top of the wave. What an amazing tool that delivers on its promise. It amplifies and scales your ability, keeps you moving forward, and leads to some serious compounding.

An overlooked impact of AI is its compounding nature. From the first prompt, where everything is wrong. But, slowly, you learn, you figure out how to harness. At some point, you forget about the first hallucination, and you are in a new spot. When I talk to others, I can immediately tell where they are on the curve by how they talk about these tools. A scary thing, though, is how far behind you can get, and that you might not be able to catch up to those who have started. If you do anything this month, go down the bumpy road and get on the other side.

As a baseline, here’s the AI-generated image from two years ago, created with DALL-E 3.

The original DALL-E 3 photo looks kind of crazy when you look back. I would never garnish a drink with a grapefruit wedge; it would have been a peel.

To remind you of the cocktail recipe for The Merry Manhattan:

Print

The Merry Manhattan

Recipe by Hans Scharler

Prep time

5

minutes

The Merry Manhattan is a festive twist on the classic Manhattan cocktail, perfect for holiday celebrations. This elegant drink features a rich amber hue, achieved by blending rye whiskey with sweet vermouth. The traditional flavor is enhanced with a unique addition of smoked cherries, adding a subtle, smoky sweetness. A sprig of rosemary infuses the cocktail with a fragrant, herbaceous aroma, invoking the essence of winter. The drink is served in a rocks glass containing a large ice chunk. The finishing touch is a gracefully twisted grapefruit peel, adding a citrusy zing and completing the cocktail’s holiday charm.

Ingredients

• 1 oz Carpano Antica Formula Vermouth

• 2 oz Whistle Pig Rye Whiskey

• 2 dashes Sour Cherry Bitters

• 2 dashes Peychaud’s Bitters

• Fresh cherries (for smoking)

• Fresh rosemary (for smoking)

• Grapefruit peel (for garnish)

• Ice

Directions

• Prepare the Smoke:
  Gather a few fresh cherries and a sprig of rosemary.
  Using a kitchen torch, gently torch the rosemary and cherries until they start to smoke. Be careful not to burn them.
  Immediately cover the smoking rosemary and cherries with a rocks glass to trap the smoke inside. Let it sit for a minute to infuse the glass with the smoky aroma.
• In a mixing glass, combine 1 oz of Vermouth and 2 oz of Rye Whiskey.
• Add two dashes each of Sour Cherry Bitters and Peychaud’s Bitters.
• Fill the mixing glass with ice and stir well to chill and dilute the cocktail.
• Add an ice chunk to the smoked rocks glass.
• Strain the stirred cocktail into the smoked rocks glass.
• Finish and Garnish:
  Take a grapefruit peel and express (squeeze) its oils over the drink.
  Use the grapefruit peel as a garnish.
  Use one of the smoked cherries as a garnish.
  Use the sprig of rosemary as a garnish.

Notes

• Enjoy the smoked cherries as a treat, or save them for a future cocktail garnish.

Here’s the first try with Nano Banna Pro. I gave it the recipe card along with the prompt to create a realistic photo for a Christmas or New Year’s party setting.

I am still not in love with the photos. They are better for sure. Let me try a new approach. I am going to just send a link to the blog post and ask for the photos again.

This time it was much better. I like that it used a fancy cocktail cherry, like a Luxardo cherry, instead of one with a stem.

I found this an interesting way to visualize how a drink can come together. I like inventing my own cocktails for parties. This gives me a way to experiment with the visual presentation.

Now, Nano Banana Pro has way more capability than DALL-E 3 had, so I can do more things. I can make process diagrams for the recipe card. Let’s try that.

Now, we are talking.

A few takeaways:

• Models are improving rapidly.
• You can do something new with Generative AI models.
• And, the power of AND. I started with a photo, then pivoted to a recipe card diagram. I could keep anding. I could make it a YouTube video script. I could make it a series of cocktails. This is the most critical takeaway for 2026. It is not just about doing one thing more efficiently; it is about doing more things than you could before.

Buckle up. You might need a drink in 2026.

Gemini 3 Pro

Google went a different direction. Gemini 3 Pro is all about reasoning, multimodal inputs, and that million-token context window.

The benchmark numbers are wild. It hit 91.9% on GPQA Diamond. On ARC-AGI-2, the abstract reasoning benchmark, it scored 31.1% (and up to 45% in Deep Think mode). That is a huge leap over previous models. On LMArena it took the top ELO spot.

If your work is heavy on reasoning, vision, video, or you need to throw massive context at a problem, Gemini 3 Pro is built for that.

Claude Opus 4.5

Anthropic announced Opus 4.5 on November 24, 2025. They are calling it the best model in the world for coding, agents, and computer use. Bold claim.

On their internal engineering benchmarks, Opus 4.5 scored higher than any human candidate ever on their take-home exam. It also delivers higher pass rates on tests while using up to 65% fewer tokens than Sonnet 4.5. That efficiency piece matters if you are building agents that run for hours.

The pitch is clear: if you care about code, automation, and not burning through tokens, Opus 4.5 is the one.

How They Compare

Opus 4.5 is aimed at engineers building agents and writing code. It is optimized for efficiency. Gemini 3 Pro is aimed at everything else: reasoning, multimodal, long context, general purpose.

Both are frontier models. Both are available on major clouds and APIs. The honest answer is you might end up using both depending on the task.

The Real Point

The meta-point is not which model wins. The point is that two frontier models landed in the same week, both pushing hard on different axes. Reasoning, coding, agents, vision, efficiency. The pace of improvement is nuts.

If you are building with AI right now, the table is full. Pick your model, match it to your task, and start experimenting. There has never been a better time.

What excites me about Claude Opus 4.5?

While I was writing this post, a friend texted me to ask what excited me about Claude Opus 4.5. I spent a couple of hours with it today, and I would have to say… tool search.

Tool search lets Claude discover and load tools on-demand instead of pre-loading every definition at the start.

Here is how it works. You provide a catalog of tools to the API with names, descriptions, and input schemas. You mark most of them with defer_loading: true, which means they stay out of the model’s context until needed. Then you include a tool-search tool in the list. When Claude needs a new capability, it searches, finds the right tool, and only then does that tool get loaded into context.

There are two pain points this solves… expensive tokens and picking the right tool.

When you load dozens of tools upfront, the definitions alone eat up thousands of tokens. That is space you could be using for reasoning, tool outputs, and user messages. With tool search, you load only the search tool and maybe three to five relevant definitions. The overhead drops significantly.

With large libraries of tools, the model can struggle to pick the right one, especially when names or parameters are similar. The search step narrows the candidates to tools that actually match the task.