I published an article about AI coding tool adoption last month. A few thousand reads. A few dozen comments. One I am still thinking about.

A commenter spotted an error in my piece and wrote: “The fact that the author also can’t count means that it’s likely an ai written article.”

The error was real. But the leap caught me off guard. A mistake in a published article is no longer evidence of a tired author or a missed edit. It is evidence of a machine. Human fallibility is no longer accepted as human. It requires an explanation now. And the default explanation is: a machine did it.

If you have ever second-guessed your own writing because you worried someone might call it AI, you know this feeling. The scrutiny is not just pointed at machines. It is pointed at anyone who might be using one.

We do not treat these errors the same

There is a fair counterpoint here. Context matters. A medical error carries more weight than a typo. Scrutiny should scale with consequence. I agree.

But we do not actually scale it that way.

A 2026 PMC study on human-AI financial advisory tested this directly. Researchers gave AI and human advisors the same task. When they made identical errors, the AI lost trust faster and more permanently. Same mistake. Same outcome. Different verdict.

That is not rational risk assessment. It is pattern recognition misfiring. We see an error and reach for the most available explanation. Right now, “AI did it” is the most available explanation for almost anything that feels off.

McKinsey’s 2026 State of AI Trust report has a name for this: “the agentic trust gap.” AI systems get more capable, but trust does not follow. Not because they fail more often. Because we watch them more closely.

The standard is not higher because AI is worse. It is higher because we have not learned how to trust something that does not have a pulse.

The investment tells the real story

One number explains more than any trust survey.

Companies allocate 93% of their AI adoption budgets to technology. Seven percent goes to helping humans actually work with it.

93 to 7. You cannot build trust in a system you never taught people to use. That is not a trust problem. That is an investment problem wearing a trust costume.

Wharton research found what they call the “donut hole.” Executives invest in AI. Younger workers adopt it natively. Middle managers, the ones who actually have to change how work gets done, get left behind. Baby boomers saw a 35% drop in AI confidence last year. Gen X dropped 25%.

These are not Luddites. These are people who built expertise over decades watching it become potentially irrelevant overnight. With no clear path to rebuild. The distrust is not irrational from where they sit. But I do not think it is really about error rates. I think it is about displacement. The quality concern is real, but it is not the whole story.

I have seen this pattern up close. The pushback is never “I tried it and it failed.” It is “it is not perfect.” The tool does not need to be perfect. It needs to be better than not using it. But that comparison rarely happens.

The part the skeptics get right

The discomfort is not irrational.
Try to observe below what happens when human fails versus when AI fails.

When a doctor makes an error, there is a medical board. When an engineer signs off on a flawed design, there is professional liability. When a financial advisor gives bad advice, there is a regulatory body and malpractice insurance. The systems are imperfect, but they are legible. You know who to call. You know who pays.

When AI fails, who do you call? The developer who trained the model? The company that deployed it? The user who trusted the output?

The question of accountability is genuinely unsolved. The EU AI Act tries to answer it. McKinsey’s trust guidelines try. Internal governance policies try. None of them have a clean answer yet. I do not either.

The fear is not that AI makes mistakes. The fear is that nobody owns the mistake when it does.

The absence of an accountability framework does not mean the technology is less capable. It means we are behind on governance. Those are different problems. We did not stop using cars because liability law took decades to mature. We built the frameworks while we drove.

Meanwhile

This is a different domain. But the timing is hard to ignore.

The Linux kernel security team reported that AI-generated vulnerability submissions had surged from two or three per week to five to ten per day. Not spam. Real bugs. Findings that human reviewers missed for years. Greg Kroah-Hartman, a Linux Foundation fellow, confirmed it: “The tools are good enough at finding these bugs.”

The Open Source Security Foundation described the pace: submissions arriving “in minutes or hours” where they used to take weeks. Not one team. Multiple independent researchers, using different AI tools, finding the same bugs simultaneously. The old model of quiet disclosure and embargoed patches is breaking down because the bugs are being found faster than the process can handle.

At a conference demo, Claude found a blind SQL injection in Ghost, a platform with 50,000 GitHub stars that had never had a critical vulnerability in its entire history. Found it in 90 minutes. 652 Linux kernel vulnerabilities have been logged in 2026 so far, many discovered by AI tools running patterns no human team had the bandwidth to execute.

This does not prove AI is trustworthy for everything. Writing articles and finding SQL injections are different tasks. But it does raise a question: if we are going to hold AI to a higher standard, should we not also update that standard as the evidence changes?

What calibrated trust actually looks like

I do not think the answer is “trust AI” or “do not trust AI.” The answer is: trust it for what it is measurably good at, verify where it is measurably weak, and invest in the governance structures that let you tell the difference.

I build AI systems for a living. I let AI generate code all day. Routing logic, API scaffolding, data transformations, test boilerplate. It is fast and it is usually right. But when it comes to API key management or authentication modules, I review every line. Not because I think the model is bad at auth. Because the consequence of a subtle error in auth is different from the consequence of a subtle error in a data transform. One is a bug. The other is a breach.

That is calibrated trust. Not blanket acceptance. Not blanket rejection. Risk-proportional verification. The same approach we already use for human work. A junior developer can write a CRUD endpoint without oversight. That same developer gets a senior review before touching payment processing. We do not call that distrust. We call it engineering.

The problem is that most organizations do not apply this logic to AI. They either trust it completely (shadow AI, no review, no governance) or reject it completely (“it is not perfect”). Both responses are miscalibrated. Both cost more than the alternative.

What I actually think

I do not think we should trust AI blindly. Skepticism is fine. I would rather work with skeptics than with people who accept every output without reading it.

What I think is that we have a calibration problem. We assess AI risk based on how the technology makes us feel, not on what it actually gets wrong. A PMC study shows identical errors getting judged differently based on who made them. A 93–7 budget split shows organizations investing in the technology but not in helping people understand it. An accountability gap gets conflated with a capability gap.

With AI, the standard is still based on a guess. Fair. But the guess is narrowing. And the standard is not.

The double standard is not that we hold AI to higher expectations. It is that we forgot humans never met those expectations either.

Originally published at https://www.weeai.dev on April 7, 2026.

We Hold AI to a Standard Humans Never Met. Then We Blame It When We Fall Short. was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

I opened a new Claude Code session last Tuesday. Project I have been working on for three weeks. Custom LangGraph agents, a FastAPI backend, Cloudflare Tunnel routing. I have a CLAUDE.md file for this project. Memory files. Architecture notes. Context documents I have refined over dozens of sessions.

Claude read all of it. In seconds, it could reference my preferred patterns, my deployment setup, my naming conventions. It could quote decisions I made two weeks ago and explain why I made them.

Then I asked it to extend the agent routing logic. The same routing logic we had iterated on across five sessions last week.

It started from first principles. It proposed an architecture we had already tried and rejected. It re-suggested a pattern I had explicitly documented as a dead end. I corrected it. It adjusted. By the end of the session, we were back to where we left off on Friday.

The session ended. The model forgot everything. Tomorrow, the cycle starts again. New session. Same notes. Same re-learning. Same corrections.

I have done this enough times to notice something I should have noticed earlier. Claude is not getting better at working with me. I am getting better at briefing Claude. My CLAUDE.md is more detailed than it was a month ago. My memory files are better organized. My context documents anticipate the mistakes it tends to make.

The improvement is real. It is just not happening where I thought it was.

What they call learning is retrieval

Anthropic announced earlier this year that Claude “authors up to 90% of the code” on some internal projects. The headlines wrote themselves. Recursive self-improvement. AI building better AI. The singularity, one commit at a time.

Here is what actually happens. Claude the model generates code for Claude Code the harness. Claude Code is a TypeScript CLI that wraps around the Claude API. It handles tool calls, file reads, permission prompts, context management. It is scaffolding. The model writes code for the scaffolding. An Anthropic engineer reads it. Tests it. Integrates the parts that pass. Discards the rest.

The model is not improving itself. It is improving its own packaging. The weights that define how Claude reasons, generates, and processes language are frozen from training. Nothing the harness produces changes them. Improving Claude Code is like improving the steering wheel on a car. The engine is untouched.

That is not self-improvement. That is autocomplete improving its own interface.

The distinction matters because the word “learning” implies something specific. Learning means the system changes. Not its notes. Not its input. The system itself. Its weights, its reasoning patterns, its ability to handle situations it could not handle before. That is what learning means in machine learning. That is what it means in human development. That is what it does not mean in any current production AI system.

Claude’s memory writes text to a file. At the start of every session, that text gets loaded into the context window. The model reads it the way you read a sticky note on your monitor. It does not change how the model thinks. It changes what the model sees. When the session ends, the context window clears. The weights remain untouched. The model is identical to what it was before you started.

ChatGPT’s memory works the same way. A summary, updated periodically, injected at session start. Not weight modification. Not adaptation. Retrieval.

There are research systems that do modify weights. MIT’s SEAL framework generates self-editing instructions that trigger supervised finetuning. NVIDIA’s test-time training compresses context into temporary weight updates during inference. Meta’s HyperAgents rewrite their own decision-making code based on performance feedback. None of these ship in production. The technical barriers are real: catastrophic forgetting, alignment drift, per-user compute costs that do not scale.

No corporation will fine-tune a model on you. The liability, the compute, and the alignment risks make it structurally impossible at consumer scale. What you get instead is a text file that the model re-reads every morning, like a doctor skimming your chart in the waiting room and calling it “knowing you.”

You are the one improving

I realized this when I compared my CLAUDE.md from January to my CLAUDE.md from March.

January was sparse. A few lines about the tech stack. A note about preferring pnpm. Basic stuff. March is a document. Architecture patterns. Naming conventions. Known failure modes. Prompting strategies I learned through trial and error. Context about what the model tends to get wrong and how to pre-empt it.

The model did not write that document. I did. The model did not learn those failure modes. I did. The model did not develop an intuition for what context to provide. I did. Every session that felt like “Claude getting better at my project” was actually me getting better at configuring a stateless tool.

The “self” in self-improving AI is you.

Obsidian users know this feeling. Notion users know it. Roam Research users definitely know it. You build an elaborate system. You refine your templates. You organize your tags. You feel productive. And then one day you search your vault and realize you have 800 notes and you reference maybe 40 of them. The rest are a graveyard of good intentions.

Peer-reviewed research on knowledge management practices confirms the pattern. Second brain tools create what researchers call an “illusion of progress.” Writing a note feels like learning. Filing it feels like retaining. Neither is true. The act of capturing information is not the same as the act of internalizing it. The tool holds the knowledge. Your brain moved on the moment you hit save.

AI memory has the same problem at industrial scale. Claude stores my preferences, my architecture decisions, my project context. I outsourced the remembering. But the outsourcing created a gap: the model has the information and I do not. Not because I forgot. Because I never needed to remember. The system handled it.

In my compression piece, I argued that the value of quantization is knowing which data to throw away. Education does the same thing to minds. Here, the pattern repeats: the value of AI memory is knowing what context to provide. That is a human skill. It is getting better because you are practicing it. The model is not practicing anything. It resets every session.

The cost you are not tracking

I noticed something about my own workflow six months ago that I have not talked about publicly.

When Claude Code generates a function, I review it. I check the logic. I verify the edge cases. Or at least, that is what I tell myself I do. What I actually do, if I am honest, is skim the output, check that it roughly matches my intent, run the tests, and move on if they pass. The review is faster than it would be for code a junior engineer wrote. Not because Claude’s code is better. Because I trust it more by default.

That default is the problem.

A Microsoft study on 319 knowledge workers found a correlation of r=-0.49 between the frequency of AI tool usage and critical thinking scores. That is not a weak signal. That is a meaningful negative relationship. The more you use AI tools, the lower your measured critical thinking. Not because the tools make you stupid. Because the tools make the effortful part optional, and your brain adapts to the optionality.

The mechanism is well-documented. Researchers call it cognitive offloading. You delegate a mental task to an external system. Your brain, freed from the effort, stops maintaining the capacity. The Columbia study that coined the “Google Effect” in 2011 showed people remember where to find information but not the information itself. AI extends this further. You now forget entire procedures because the AI can generate them on demand.

The numbers from recent research are specific. AI assistance boosts task completion by 48–127%. Impressive. But when the AI is removed, performance drops 17% below the pre-AI baseline. Not back to where you started. Below where you started. The training wheels weakened the legs.

The metacognitive part is worse. A 2025 study found that users who worked with AI overestimated their own performance by 4 points on logical reasoning tests. They scored higher with AI help. But they thought they scored even higher than they did. The self-assessment was wrong in both directions: they were not as good as they thought, and they did not know they were not as good as they thought.

Researchers call this the “Steeper Curve Illusion.” You feel like you are learning faster. Your output quality is higher. Both of those observations are correct. But the output quality comes from the AI, not from you. Remove the AI and the illusion breaks. You are not where you thought you were.

The finding that ties this back to everything: if you already know a domain well, AI extends your cognition. You have the internal frameworks to evaluate its output, catch its mistakes, and integrate its suggestions into genuine understanding. The AI is a lever that amplifies existing capability.

If you do not know the domain, AI replaces the cognitive process your brain needs to build that knowledge. The effort it removes is the effort that creates expertise. The friction it eliminates is the friction that produces learning.

I have been writing code for years. When Claude generates a function in a domain I understand, I catch the subtle bugs. I notice the architectural choices I would not have made. I learn from the delta between its approach and mine. The AI makes me better because I have enough foundation to use it well.

But I have started using Claude for domains I do not know as deeply. Infrastructure automation. Advanced TypeScript patterns. Areas where I have working knowledge but not deep expertise. And in those areas, I accept its output more readily. I verify less. I learn less. The gap between what I produce with AI and what I understand without it is widest in exactly the domains where I need learning most.

That is the cost I am not tracking. Not in my IDE. Not in my git history. Not in any metric I report.

The question nobody is asking

The AI industry is building systems that remember more, retrieve faster, and persist context longer. Every release announcement emphasizes how much the model “knows” about you. How it “learns” your style. How it “adapts” to your workflow.

None of that is learning. All of it is retrieval. The distinction is not pedantic. It is the difference between a tool that makes you more capable and a tool that makes you more dependent. Both feel the same while you are using them. The difference only shows when you stop.

Tomorrow I will open a new session. Claude will read my notes again. It will re-learn my preferences, my architecture, my code patterns. By the end of the session, it will feel like it knows me. Then the session will end. The weights will not change. The model will not carry anything forward. The context window will clear, and everything we built together will exist only in the text files I maintain.

The only thing that carries forward is me. My CLAUDE.md is better than it was three months ago. My memory files are more precise. My ability to brief a stateless model has improved measurably. That is real improvement. It is just not the kind anyone is talking about.

A system that remembers for you is not the same as a system that helps you remember. The difference is invisible while the system is running. It only becomes visible when you try to work without it.

I have not tried that in a while. That might be the point.

Originally published at https://www.weeai.dev on April 4, 2026.

They Call It Self-Improving AI. Nobody Checks Who Actually Improved. was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

I was talking about TurboQuant to a tech colleague at an AI company last week. Quantization, model compression, how you squeeze a 70-billion-parameter model into something that runs on hardware a fraction of the size. Standard conversation for people who build them.

A sales colleague overheard us and walked over.

“Why does that matter? Isn’t data just data? It’s not like there’s a storage problem.”

She was not being dismissive. She was genuinely asking. And the question stopped me, because she was right about something she did not realize she was right about.

Data is just data. That part she nailed. The part she missed is that the value was never in the data. The value is in knowing which data to throw away.

That insight connects AI model compression to something much older than neural networks.

What compression actually does

Quantization takes a neural network and asks a single question: how much of this can I remove before the output breaks?

A 70-billion-parameter model stores billions of floating-point numbers at high precision. Each parameter is a weight learned during training, a tiny piece of the pattern the model uses to produce output. Quantization reduces that precision. FP16 to INT8. INT8 to INT4. Each step throws away information. The question is whether the information it throws away matters.

(Most of it does not.)

This is counterintuitive. If I told you I could remove 75% of a surgeon’s training and they would still perform at the same level, you would call me insane. But neural networks are not surgeons. They are massively overparameterized by design. They store far more information than they need to generalize. The redundancy is a byproduct of training, not a feature of competence.

The results bear this out. A well-quantized 32B model running at INT4 will outperform a poorly prompted 70B model running at full precision on tasks that require focused context. We proved this in production. Our document extraction pipeline used Qwen3 32B VL to beat Gemini 3 Pro, a frontier vision-language model many times its size. Under 40% accuracy from the frontier model. Over 90% from the smaller one. Not because the smaller model was smarter. Because the architecture gave it exactly the right context at exactly the right moment.

The frontier model drowned in 15,000 tokens of visual noise — headers, footers, watermarks, logos, decorative borders. The compressed model got exactly the signal it needed and nothing else. The graph did the work. The model executed.

Compression does not make a model dumber. It makes a model focused. It removes the noise that full precision carries and keeps the patterns that generalize.

That process is not unique to neural networks. Humans have been doing it for centuries. We just call it something different.

Compression is what education does

What quantization does to a model is what education does to a mind.

A medical degree compresses centuries of clinical knowledge into six years. It does not teach every case. It teaches the patterns that generalize. Anatomy. Physiology. Pharmacology. Differential diagnosis. The frameworks that let a doctor reason about a patient they have never seen before, presenting symptoms that were not in any textbook.

The student who memorizes every fact from every lecture has not been educated. The student who can walk into an emergency room and diagnose a condition they have never encountered, using the reasoning frameworks they internalized, that student has been compressed correctly.

A good university does not transfer all knowledge. It transfers the minimum representation that preserves meaning. It strips away irrelevant details, outdated methods, edge cases that do not generalize. It keeps the structure that lets someone reason about situations that were not in the curriculum.

That is exactly what quantization does.

A 70B model at full precision is the student who memorized everything. Every lecture. Every footnote. Every edge case. It can recall any of it on demand. But recall is not understanding, and carrying all that weight slows it down when speed matters.

A well-quantized 32B model is the student who understood the material. Smaller. Faster. And in the right context, more accurate. It is not wasting attention on information that does not help with the task in front of it.

George Cybenko published the Universal Approximation Theorem in 1989. The paper proved that a neural network with a single hidden layer and sufficient width can approximate any continuous function to arbitrary accuracy. That theorem describes what neural networks can learn. Quantization asks: how much of that network can you remove before the approximation breaks? How few parameters can you keep while still preserving the function?

Education asks the same question about a human mind. How few years of training can you provide while still producing someone who can generalize? How much of the curriculum can you cut before the graduate breaks?

The answer in both cases is: more than you think. The redundancy is enormous. The signal-to-noise ratio of a full-precision model and a four-year degree are both shockingly low. Most of what gets stored, in weights or in memory, is noise. The art of compression is knowing which part is not.

Her question was accidentally the right question. Data is just data. The value is in knowing which data to throw away. That is what compression does. That is what education does. And that is what most people never learn about AI, even the ones selling it.

The widest gap in technology history

She sells AI products. She did not know what quantization is. I do not mean she could not explain the math. I mean she did not know the word. And she closes deals every month.

That is not a story about one person. That is a story about an entire industry.

90% of developers now use AI tools daily, according to Google’s 2025 DORA report. 75% of knowledge workers use AI regularly. Fewer than 28% of any group — technical or not — can explain how the technology actually works.

We have built the first technology in history that makes people more capable while making them less literate about the capability.

Every previous technology wave required understanding to unlock value. You had to learn to drive to use a car. You had to learn to type to use a computer. You had to learn to code to build software. Each wave had a literacy requirement. No understanding, no access.

AI broke that pattern. You can use ChatGPT to draft a legal contract without understanding language models, probability distributions, or token prediction. You can use Copilot to write production code without understanding how the model was trained or what its failure modes are. You can use Midjourney to create marketing assets without understanding diffusion, latent spaces, or CLIP embeddings.

The value is immediate. The understanding is optional.

That has never happened before at this scale.

The uncomfortable part: this is what good abstraction looks like. A well-designed system hides its complexity. The iPhone does not require you to understand ARM architecture. Electricity does not require you to understand transformers. Google Maps does not require you to understand Dijkstra’s algorithm. Good tools disappear. You use them without thinking about how they work.

So why does the AI literacy gap matter?

It matters because abstraction works when the system is stable and the user’s decisions do not depend on understanding the internals. You do not need to understand combustion engines to drive safely. The car handles it. But you do need to understand combustion engines if you are a mechanic. You do need to understand them if you are writing emissions regulations. You do need to understand them if you are deciding which engine to put in a fleet of delivery trucks.

A driver who does not understand engines is fine. A mechanic who does not understand engines is dangerous. A regulator who does not understand engines writes bad emissions laws.

The AI industry is full of mechanics who do not understand the engine.

She sells AI products to enterprise clients. She recommends one model over another. She positions capabilities against competitors. She influences purchasing decisions that will shape how organizations use AI for years. And she does not know what quantization is — not the math, not the concept, not even the word.

That is not her failure. That is the industry’s failure. The AI industry built tools that non-technical people can use without understanding. Then it hired non-technical people to sell those tools without teaching them what they are selling. The abstraction that made the products accessible also made the salesforce ignorant. And nobody noticed because the deals kept closing.

We count adoption. We do not count comprehension.

The AI industry celebrates adoption metrics. How many developers use Copilot. How many enterprises deployed agents. How many knowledge workers prompt ChatGPT daily. Every earnings call, every industry report, every keynote — the numbers go up and everyone applauds.

Nobody tracks comprehension metrics.

We count how many people use the tool. We do not count how many people understand what the tool is doing to their work. We count how many models shipped. We do not count how many buyers can articulate why one model is different from another. We count how many AI products are in market. We do not count how many salespeople can explain what they sell.

That gap has a cost. We just have not received the invoice yet.

I see this pattern in my own work. I build multi-agent AI systems for enterprise clients. Financial institutions. Government-linked companies. Consulting firms. When I explain what quantization enables — running models on-premise instead of sending data to a cloud API, reducing inference costs by 60–80%, deploying on hardware the client already owns — the technical teams get it instantly. The business teams hear “cheaper and faster” and stop listening.

“Cheaper and faster” is enough to close a deal. It is not enough to make a good decision. The client who chose a quantized open-weight model because it was cheaper, without understanding why it was cheaper, will not know what to do when accuracy degrades on a new document type. They will not know that the model lost some capability during compression and needs a different prompting strategy. They will blame the model. Or blame us. Or abandon the approach. Because nobody gave them the five-minute explanation that would have set the right expectations.

The pharmaceutical industry figured this out decades ago. Sales reps undergo pharmacology training — not at a researcher’s level, but enough to know what they are selling, how it works, what the side effects are, and when it should not be used. Some cities like Chicago require it by law. Financial advisors must pass Series 65 or Series 66 licensing exams before they can give investment advice. Insurance agents learn actuarial basics. In regulated industries, there is a minimum comprehension bar for the people who sell the product to the people who use it.

AI has no equivalent. You can sell a system that scores a billion job applicants without understanding how scoring works. You can sell a model that runs on a phone without knowing why running on a phone is harder than running in a cloud. You can sell an agent framework without understanding what “bounded autonomy” means or why it matters.

The product complexity went up. The sales knowledge bar did not.

The knowledge is not moving

The value is not in having all the information. It is in keeping the right information and making it portable.

The AI industry compressed the user experience brilliantly. Anyone can use these tools. A lawyer drafts contracts with GPT. A marketer generates campaigns with Claude. A developer writes code with Copilot. The tools are portable. They travel from expert hands to anyone’s hands. That is genuine progress.

But the AI industry did not compress the understanding at all. The knowledge of how these systems work, why they fail, what their limitations are, when to trust them and when not to. That knowledge stayed exactly where it started. In the heads of researchers and engineers. It did not get packaged. It did not get simplified. It did not get made portable.

We made the tools portable. We did not make the knowledge portable.

Education solves that problem. That is its entire purpose — take complex knowledge, strip away the noise, find the minimum representation that preserves meaning, and transfer it to someone who did not have it before. Make the knowledge portable.

Compression solves it too. Not metaphorically. Literally. A quantized model that runs on a laptop instead of a data center is portable knowledge. A skill file that encodes domain expertise into a format an AI agent can execute is portable knowledge. A well-structured prompt that captures decades of actuarial judgment in a repeatable workflow is portable knowledge.

The tools exist. The methods exist. What does not exist is the will to use them on the hardest problem: explaining AI to the people who depend on it.

She asked why compression matters. The answer is that compression is how knowledge becomes portable — in machines and in minds. And right now, the knowledge is not moving.

Originally published at https://www.weeai.dev on March 29, 2026.

75% of What a Neural Network Learns is noise. So is 75% of What You Learned in School. was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

My director said something this morning that I cannot stop thinking about.

“Our clients want Skill X from AiExe and Skill Y from AiMod. Can we let them pick and choose?”

AiExe is our AI-powered KYC platform. AiMod is our AI workflow automation platform. Two separate products. The client did not want either product as a whole. They wanted specific capabilities from each one, assembled into their own workflow.

That stopped me. That is not a feature request. That is a market forming.

I started with Tableau and XML

My first skill was not for a client. It was for myself.

When Claude Code came out, I wanted to automate parts of my Tableau Desktop workflow. The problem: Tableau’s underlying format is XML, and the API to work with it is not public. There is no documented way to programmatically manipulate workbook structure. You have to reverse-engineer the XML schema, figure out which nodes control which visual elements, and write instructions precise enough that an AI agent can modify them without breaking the file.

The early models could not do it. The XML was too complex, the structure too fragile. One wrong node and the workbook corrupts. I tried with Claude Sonnet, with Opus. Close, but not reliable enough for production use.

Then Opus 4.6 came out, and something shifted. The model could finally hold enough context to understand the full XML tree and make targeted modifications without collapsing the structure. I had a working Tableau skill. Not perfect. But reliable enough to save me hours every week.

The hardest part of building a skill is not writing the instructions. It is understanding the system well enough to write instructions that work when the model makes a mistake. A Tableau XML file has thousands of nodes. The skill needs to know which ones are safe to modify and which ones will corrupt the file if touched. That knowledge took weeks of tinkering. The skill file itself is a few hundred lines.

Taking other people’s knowledge and making it into skills

After Tableau, I started building AI agents for clients at Infomina AI. Transfer pricing firms. Credit risk teams. Analytics departments that needed repeatable workflows.

The pattern was always the same. The client already had the expertise internally. Transfer pricing consultants who knew the OECD guidelines cold. Credit risk analysts who could assess default probability in their sleep. They had the knowledge. What they did not have was a way to assemble that knowledge into something an AI agent could execute.

I would sit with the domain expert. They would explain their process: “First I pull the comparable data, then I adjust for these five factors, then I run the benchmarking analysis, then I format the report.” I would listen, ask questions, and encode their expertise into a structured skill file with defined steps, tool calls, validation checks, and error handling.

The domain expert spent twenty years learning what matters. The skill file captured the decision logic in a format an AI agent could run. Not perfectly. But consistently enough to handle the 80% of cases that follow the pattern, and flag the 20% that need a human.

The skill is not code. The skill is someone’s expertise, assembled. The businesses already have the knowledge. They just do not know how to package it into something AI can use. That is the gap I keep filling, one client at a time.

I thought I was selling AI agents. I am selling packaged expertise. A transfer pricing firm does not care that I use LangGraph and Claude. They care that the benchmarking analysis takes 20 minutes instead of 4 hours.

Skills are the new apps

I keep coming back to the app analogy because it maps so precisely.

When Apple launched the App Store in 2008, everyone built apps. Most were terrible. A few dominated their categories. And a long tail of niche apps quietly made money solving specific problems for specific audiences. The weather app that 50 million people use and the aviation weather app that 10,000 pilots rely on both exist in the same marketplace. Both make money. They serve completely different needs at completely different scales.

Skills are following the same curve. SkillsMP, a marketplace for AI agent skills, went from 66,000 listings to 351,000 in two months. That is app-store-scale growth. And like the early App Store, most of those 351,000 skills are probably mediocre. A few will dominate. Some niche skills that solve expensive problems for small audiences will quietly generate recurring revenue.

The difference is that apps have infrastructure. The App Store handles distribution, payment, installation, updates, and security. You download an app and it works. It runs in a sandbox. It cannot corrupt your operating system. It goes through review before it reaches users.

Skills have none of that.

There is no App Store for AI skills. No standard installation process. No sandbox. No payment layer. No security review. If I want to sell my Tableau skill, I would have to share the raw skill file, which exposes my entire methodology. There is no DRM, no hosted execution, no way to sell access without selling the source. The market is building inventory before the store exists.

Good skills vs bad skills

I have built enough skills to know what separates the ones that last from the ones that get abandoned.

A bad skill is a script pretending to be a skill. It solves one problem for one user in one context, and breaks the moment any of those three things change. No error handling. No validation. Just a bet that the model gets it right every time.

A good skill is something you can hand to a stranger. They read the instructions, plug it into their workflow, and it runs without calling you. It has clear inputs and outputs. It checks its own work. When something goes wrong, it fails gracefully instead of silently producing garbage.

I have built both kinds. The bad ones felt productive when I wrote them. The good ones took three times longer to build and saved ten times more time over the following months.

If your skill only works when you are watching it, it is not a skill. It is a demo.

Most will ship garbage

I am not being cynical. I am reading the data.

Of the 351,000 skills on SkillsMP, how many have been tested in production? How many handle edge cases? How many have error recovery? Someone analyzed 847 real AI agent deployments and found that 76% experience critical failures within 90 days. Only 18% deliver on their original ROI promises. 43% get abandoned completely after six months.

A security audit of 2,614 MCP servers found that 82% are vulnerable to path traversal and 67% are vulnerable to code injection. Thirty CVEs were filed in the first two months of 2026 alone. Anthropic’s own mcp-server-git had vulnerabilities that allowed arbitrary file writes.

The market is growing faster than the infrastructure that would make it safe. That is the early App Store without Apple’s review process. It is npm without lockfiles. It is Docker Hub without image scanning. The skills are flowing. The quality control is not.

MCP is a bridge, not the destination

I have a take on MCP that will probably get me yelled at on Hacker News.

MCP (Model Context Protocol) is valuable right now because it solves a real problem: giving AI agents structured access to external systems. It pre-stores context, defines tool interfaces, and provides a standard way for agents to interact with APIs, databases, and services.

But as models get smarter, they need less scaffolding. Opus 4.6 can read API documentation and figure out how to call endpoints without a pre-built MCP server. It can parse XML without a custom tool definition. It can navigate authentication flows that would have required explicit handling a year ago.

MCP matters enormously for smaller, open-weight models that need structured guidance. It is the SOP for models that cannot reason through novel integrations on their own. For frontier models, the value of pre-built MCP servers is shrinking because the models are increasingly capable of figuring it out themselves.

This does not mean MCP will disappear. It means its role is shifting from “necessary infrastructure” to “performance optimization.” A frontier model can call the Stripe API without a Stripe MCP server. But the Stripe MCP server makes it faster, cheaper, and more reliable. That is still valuable. It is just a different value proposition than “the model literally cannot do this without MCP.”

Every business becomes a skill contributor

Most businesses right now are AI consumers. They prompt ChatGPT, use Copilot, experiment with Claude. They are running on someone else’s expertise.

But businesses have something that AI companies do not: twenty years of domain knowledge that no foundation model was trained on. A credit bureau knows how to assess default risk. A law firm knows how to structure a merger agreement. A transfer pricing consultancy knows the OECD guidelines better than any model ever will.

That expertise is locked inside people’s heads and internal documentation. Skills are the extraction mechanism. The transfer pricing agent I built does not know transfer pricing. The skill file does. The model just executes the workflow. And because the knowledge lives in the skill, not the model, it survives model upgrades, provider switches, and API changes.

I think the businesses that figure out how to package their expertise as reusable skills will build an asset that compounds. The ones that wait will end up buying skills from their own competitors.

I would sell my skills. I do not know how

This is the honest part.

I have built skills for invoicing, CRM management, contract generation, proposal writing, expense tracking, project management, content ideation, visual generation, and evaluation platforms. Some of them save me hours every week. Some of them are good enough that other people could use them with zero modification.

And I have no idea how to sell them.

If I share the skill file, I share the IP. If I host it behind an API, I need infrastructure I have not built. If I list it on a marketplace, there is no standard for pricing, no SLA framework, no way for the buyer to know if the skill actually works before they pay for it.

Apps solved this decades ago. The App Store handles distribution, payment, sandboxing, reviews, updates, and refunds. The developer writes the app and uploads it. The infrastructure handles everything else.

Skills have no equivalent. The closest thing is SkillsMP with 351,000 listings and no monetization layer. Or Agent37, which is trying to build hosted execution. Or Gumloop, which just raised $50 million to be the platform layer. But none of them are the App Store yet. Not even close.

So for now, skill builders like me keep building for ourselves and our clients, one custom engagement at a time. It works. It pays. But it does not scale, and I know it.

The skill is the product. The agent is the delivery mechanism. The model is the engine. And the infrastructure to sell them does not exist yet.

That last part is either a problem or an opportunity. I have not decided which yet. But I am paying attention.

Originally published at https://www.weeai.dev on March 24, 2026.

Every Business Will Build AI Skills. Most Will Ship Garbage. was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

We called a townhall last month to talk about AI coding tools. Not a casual Slack poll. A planned, company-wide session. The AI Solutions team — my team — had been using Claude Code, Cursor, and custom agent workflows for months. The Software Engineering team, the one building the core product, had not. Same company. Same office. Two completely different relationships with the tools we sell.

I walked in expecting a conversation about which tools to standardize. What I got was a lesson in the technology adoption curve that I should have seen coming.

The divide is not about tools.

The divide is not about whether AI coding tools work. Everyone agrees they produce code. The divide is about whether you trust what they produce, and whether you think the speed is worth the risk.

The adoption curve, again

I have seen this pattern before. Everyone has.

When the internet arrived, someone at every newspaper said “our readers prefer paper.” When crypto emerged, someone at every bank said “this is a toy.” When mobile-first happened, someone at every enterprise said “our users are on desktops.”

They were not wrong about the present. They were wrong about the trajectory.

The technology adoption curve (innovators, early adopters, early majority, late majority, laggards) is one of the most validated frameworks in tech. It describes every wave. And it describes exactly what happened in our townhall.

My AI Solutions team sits at early adopter. We build AI agents for clients. We already believe the technology works because we ship it. Using AI to write the AI felt natural. The Software Engineering team sits at early majority, maybe late majority. They build the core platform. Their codebase is stable, well-tested, and maintained by people who take pride in the craft of writing it themselves.

Neither side is wrong. But only one side is going to be comfortable in 18 months.

/processes vs /process

Here is the moment that made me take the “almost right” problem seriously.

We had a spec. Frontend and backend teams had agreed on the API contract. Route names, request bodies, response shapes. All documented. An engineer used an AI coding tool to generate the backend endpoint. The code was clean. It compiled. The endpoint responded correctly when tested in isolation.

The frontend got a 404.

The AI had generated the route as /processes. The frontend was calling /process. One character. Plural vs singular. The spec said /process. The AI read the spec and still got it wrong.

The confidence is the dangerous part

The code looked correct. It passed linting. It returned the right data shape. If you tested the endpoint by itself, everything worked. The bug only appeared when frontend and backend talked to each other. That is not a hallucination. It is a misunderstanding. And it is the kind of bug that slips through code review if you are not looking for it.

This is what I mean by “almost right.” The code is 95% correct. It compiles. It runs. It does roughly the right thing. But the 5% it gets wrong is subtle, and subtle bugs are harder to catch than obvious ones. A 500 error is easy to debug. A 404 caused by a route name you never thought to check is not.

METR, one of the few organizations running rigorous randomized studies on AI coding productivity, found that developers using AI tools were 19% slower on average. But the developers themselves estimated they were 20% faster. The perception gap is not small. It is a full 39 percentage points in the wrong direction.

I believe that number. I have watched engineers on my team submit pull requests faster and then spend twice as long in review figuring out what the AI got subtly wrong. The generation is fast. The validation eats the speed gains and then some.

The productivity paradox

Vendor claims: 20–55% faster. METR randomized study: 19% slower. Real-world analysis: maybe 10% gains in the best case. The gap between claimed and measured productivity is the widest in any software tooling category I have seen.

The “almost right” tax

The /processes bug is not an isolated story. It is a pattern.

Stack Overflow’s 2025 developer survey found that 66% of developers cite “AI solutions are almost right, but not quite” as their number one frustration with AI tools. Not “AI is too slow.” Not “AI does not understand my codebase.” The top complaint is that the output is close enough to look correct but far enough to break things.

And close-enough code is harder to debug than wrong code. When code is obviously broken, you know where to look. When code is almost right, you have to read every line carefully to find the one thing that is off. 45% of developers say debugging AI-generated code takes longer than debugging code they wrote themselves.

The security angle makes this worse. Analysis of AI-generated code found 1.7x more issues overall and 322% more privilege escalation vulnerabilities compared to human-written code. The AI does not write insecure code on purpose. It writes plausible code that happens to miss edge cases a security-aware human would catch.

This is why TDD matters more now than it did before AI tools existed. Not less. If your tests check that the frontend can actually call the backend endpoint by name, the /processes bug dies in CI instead of production. If your tests only check that the endpoint returns the right data shape, the bug ships.

Code review matters more too. Not the rubber-stamp kind where you skim the diff and approve. The kind where you actually read the route names, check them against the spec, and verify the contract matches what the frontend expects.

AI tools make generation faster. They make validation harder. If you do not adjust your process for the second part, you are not getting faster. You are getting confident.

My teammate’s best argument

Not everyone on my team is fully bought in. One person — I will call him the realist — maintains a healthy skepticism that I think makes our team better.

His argument is not “AI is bad.” His argument is “AI is good enough to be dangerous.”

He showed us a blog post about a Rust SQL query generated by an AI tool. The query was correct. It returned the right results. But a human who understood the database schema would have written it differently: better indexing, fewer joins, half the execution time. The AI solved for correctness. It did not solve for craft.

Correct but unoptimized code ships to production. Then more correct but unoptimized code ships. Then more. And in 18 months, you have a codebase that runs but runs slowly, uses more memory than it should, and is harder to maintain than it needs to be. That is the technical debt of 2027, and we are writing it right now.

He is right. And I still think we should use the tools.

The two positions are not contradictory. You can believe AI coding tools are worth using and also believe they require more discipline, not less. The mistake is treating AI as a replacement for judgment. It is a replacement for typing. The judgment still needs a human. What to build, how to structure it, what to test, what to optimize.

How I hire now

I used to weight coding ability heavily in interviews. Can you implement this algorithm? Can you debug this function? Can you write clean, idiomatic code?

I still care about those things. But they matter less than they did two years ago.

Now my interview questions sound more like: “How would you turn this into a product?” “How would someone actually use this?” “Walk me through the architecture. Not the implementation. The architecture.”

I am looking for product sense. I am looking for the ability to think at the right altitude. High enough to see the system, low enough to know where the risks are. I am looking for attitude: curiosity about tools, willingness to learn, comfort with ambiguity.

The candidates who concern me are the ones who say “I tried AI tools before and they don’t work.” Not because they are wrong about the current limitations. But because the statement reveals a fixed relationship with tools. Someone who tried the internet in 1995 and said “this is useless” was making an accurate observation about 1995. They were making a catastrophic prediction about 2005.

The question is no longer “can you code?” It is “can you think about what to build, decide how to structure it, and use whatever tools are available to build it well?” Coding ability is now table stakes. Product sense is the differentiator.

I have passed on technically strong candidates who could not answer “who would use this and why?” I have hired people with less raw coding ability who could see the system from the user’s perspective. The bet is that AI tools will keep getting better at generation, which means the human value shifts permanently toward judgment, taste, and architectural thinking.

The ambassador’s dilemma

Here is the part I find funny, in the way that uncomfortable truths are funny.

I am the person at Infomina AI pushing hardest for AI tool adoption. I run sharing sessions. I demo my Claude Code setup: the custom skills, the MCP tools, the subagent workflows, the personalized configurations. I show people what is possible when you invest the time to learn the tools deeply.

And I know — honestly know — that we are not fully utilizing what is already available. My own company, which builds AI products for clients, has not fully embraced AI tools internally. I am the ambassador, and the embassy is half-built.

This is not hypocrisy. It is the gap between knowing something works and getting an entire organization to change how they work. That gap exists at every company, in every adoption cycle, for every technology. The internet was invented in the 1960s and most businesses did not have a website until the late 1990s. Knowing that a tool works and integrating it into daily practice are separated by years, not weeks.

The real question for leaders is not “should we use AI tools?” The answer is obviously yes. The question is “how do we adopt them without losing the craft that makes our code good?” That question does not have a clean answer, and anyone selling you one is lying.

What we actually do

We do not have an AI tools policy. We have a culture.

The culture is: experiment and share. Someone tries a new tool, a new workflow, a new way of using Claude Code or Cursor. If it works, they share it in our internal sessions. If it fails, they share that too. We learn from each other’s experiments instead of waiting for someone to write a mandate.

No top-down requirements. No “everyone must use Copilot by Q3.” No banning AI tools either. Just a standing invitation to try things, break things, and tell the team what happened.

This works better than policy for a simple reason: adoption driven by curiosity sticks. Adoption driven by mandate creates resentment. The engineers who adopt AI tools because they saw a colleague ship something faster are more committed than the ones who adopt because their manager told them to.

The sharing sessions are where the real learning happens. Not “look how fast I generated this code.” We got past that novelty months ago. More like “here is how I caught a subtle bug using TDD that the AI introduced” or “here is a prompt structure that produces better architecture decisions” or “here is why I stopped using AI for this specific type of task.”

The nuance matters. The tools are good for some things and bad for others, and the only way to learn the boundary is to use them enough to find it.

The divide is not going away

I do not think we will reach consensus. Not at my company, and not in the industry.

Some developers will always prefer hand-written code. They value the craft, the understanding that comes from writing every line, the satisfaction of a codebase they built from scratch. I respect that. It is a legitimate position.

Some developers will embrace AI tools fully. They will generate code faster, review it carefully, use TDD to catch the subtle bugs, and ship more than they could before. I am in this camp. It is also a legitimate position.

The divide is not new. It is the same divide that appeared with every productivity tool, every framework, every abstraction layer in the history of software. IDEs vs text editors. Frameworks vs raw code. Managed services vs self-hosted infrastructure. Every time, the industry split between “this makes us faster” and “this makes us sloppy.” Every time, the tools won eventually, but the people who insisted on craft made the tools better.

That tension is productive. The developers who refuse to blindly trust AI output make better code reviewers. The developers who push for AI adoption find the workflows that save time without sacrificing quality. The best teams have both.

The answer is not “pick a side.”

The answer is “hold the tension.”

Use the tools. Do not trust them blindly. Write tests that catch what they miss. Review code like the AI is a confident junior who gets the route name wrong one time in twenty. Push for adoption, but keep the craft. Be the ambassador and the skeptic. That is the job now.

Originally published at https://www.weeai.dev on March 18, 2026.

We Build AI for a Living. Half Our Company Does Not Want to Use It. was originally published in AI Advances on Medium, where people are continuing the conversation by highlighting and responding to this story.

Two AI labs announced billion-dollar seed rounds within weeks of each other in 2026. Both claimed the same thing: large language models are not enough.

AMI Labs, founded by Turing Award winner Yann LeCun and former Nabla CEO Alex LeBrun, raised $1.03 billion. The largest seed round for a European company, possibly ever. Their thesis: AI needs to understand physics. How objects move, what happens when you drop something, why a bridge holds weight. The kind of knowledge a two-year-old has and GPT-4 does not.

World Labs, founded by Stanford professor Fei-Fei Li, raised $1 billion. Their thesis: AI needs to understand space. How a room looks from another angle, how light falls on a surface, how objects relate to each other in three dimensions. They already have a product shipping — Marble, a 3D design tool.

Same diagnosis. Same scale of capital. Radically different prescriptions.

This matters because the “what comes after LLMs” question is no longer theoretical. Two of the most credentialed scientists in the field just bet their reputations that the answer is world models — AI systems that simulate reality instead of predicting the next token. But they disagree on which part of reality matters most.

One is building AI that understands how things look. The other is building AI that understands how things work. The difference sounds subtle. The market implications are not.

What a two-year-old knows that ChatGPT does not

Ask ChatGPT what happens when you tilt a full cup of coffee. It will give you a paragraph about gravity, fluid dynamics, and surface tension. Accurate. Articulate. Completely useless in the moment.

A two-year-old does not know the word “gravity.” But she knows the coffee will spill. She knows it before it happens. She has a model of the world running in her head — not a language model, a physics model. Objects fall. Liquids flow downhill. If you push something off a table, it does not hover.

This is the gap LeCun has been talking about for years. LLMs predict the next word. They do not predict the next event. They can describe what a ball does when you throw it. They cannot simulate the throw. The description and the simulation are different capabilities, and only one of them is useful for a robot trying to catch the ball.

A self-driving car approaches a construction zone. The camera sees orange cones. An LLM can label them. A world model simulates what happens if the car maintains speed versus braking versus changing lanes. The difference between labeling and simulating is the difference between seeing the cones and not hitting them.

A nurse watches a patient breathe. Nothing in the chart has changed. But the breathing pattern looks wrong. The nurse has a physical model of what “normal” looks like, built from thousands of hours of observation. Current AI reads the numbers on the monitor. It does not watch the patient breathe.

A factory robot picks up a glass bottle. It needs to know that glass is fragile before it squeezes, not after. That requires a model of materials, forces, and consequences.

The spatial intelligence bet

Fei-Fei Li is not wrong. She is solving a real problem.

Her company, World Labs, builds what she calls “spatial intelligence” — AI that understands three-dimensional space. Given a single photograph of a room, their system generates a full 3D model you can walk through. Change the lighting. Move the furniture. View it from any angle. Their product, Marble, already ships. Designers and architects use it.

Reconstructing 3D space from 2D images is a decades-old computer vision problem, and World Labs has pushed it further than most thought possible at consumer scale.

But notice what the system does and does not do. It answers: “What does this space look like from over there?” It does not answer: “What happens in this space if I do something?”

Marble can generate a photorealistic kitchen from every angle. It cannot tell you that the pot on the stove will boil over in three minutes. It can render a warehouse floor with millimeter precision. It cannot tell you that stacking those pallets that way will cause a collapse.

Spatial intelligence is a rendering problem. A valuable one. Gaming, architecture, and design need it. But the ceiling is visible. You are building better eyes for machines. Eyes that see from every angle, in perfect detail. The question is whether better eyes are enough, or whether machines also need intuition about what they are looking at.

Li raised a billion dollars to bet on eyes. LeCun raised a billion to bet on intuition.

The physics bet

LeCun’s approach has a name — JEPA, Joint Embedding Predictive Architecture. The name does not matter. What matters is what it does differently.

An LLM works like autocomplete. Given a sequence of words, predict the next word. Given a sequence of tokens, predict the next token. Pattern matching on language. Powerful, but it is a text trick at bottom.

JEPA works like imagination. Given a video of a ball rolling toward a wall, the system does not describe what happens next in words. It builds an internal representation of the scene and predicts what the scene will look like after the collision. Not in pixels — in abstract features. Speed, direction, material properties, energy transfer. The system develops intuition, not vocabulary.

Think of it this way. An LLM reads a cookbook and can tell you the recipe for bread. JEPA watches someone make bread and understands that dough rises because of heat and yeast, that kneading changes texture, that timing matters. One knows the words. The other knows the physics.

This is why LeCun left Meta after twelve years. He believed — publicly, repeatedly, and at professional cost — that scaling LLMs would never produce systems that understand the world. That predicting the next token is a different capability from predicting the next event. Meta disagreed. LeCun walked.

AMI’s first target is healthcare. Not chatbots. Not image generation. Clinical decision support where the AI needs to simulate what happens to a patient if you choose treatment A versus treatment B. That requires causal reasoning. It requires a model of how bodies work, not a model of how medical textbooks read.

The distinction matters in practice. It is the difference between an AI that can quote the textbook and an AI that can think like the doctor.

Why one bet matters more than the other

The hardest problems in production AI are never about what things look like. They are about what happens next.

Autonomous vehicles already have spatial intelligence. LiDAR gives you millimeter-accurate 3D. Tesla’s vision system reconstructs the scene in real time. The cars still crash. Not because they cannot see the obstacle. Because they cannot predict what the pedestrian, the cyclist, the other driver will do in the next two seconds. Every fatal self-driving incident you have read about happened with full spatial awareness of the scene. The car saw everything. It understood nothing about what would happen next.

Surgical robots can map a patient’s anatomy in 3D before the first incision. The hard part is not the map. It is knowing that this tissue will bleed differently from that tissue, that cutting here changes pressure there, that the plan needs to change mid-procedure because the body did something the textbook said it would not.

Same story in industrial automation. A robot arm that can see a conveyor belt in perfect 3D is commodity hardware. One that knows a warped part will jam the next machine downstream — that is the version that runs a factory without a human watching.

Perception is largely solved. Prediction is not. And the market for predicting what happens next in the physical world is the physical world itself.

That is why LeCun’s bet, if it works, reshapes more industries than Li’s. The market for “what does this look like from another angle” fits inside the market for “what happens if I do this.” One is contained by the other.

What happens if LeCun is right

If world models work — if JEPA or something like it produces AI that genuinely understands physics — LLMs become the dial-up era of AI. Useful, transformative for their time, and eventually a footnote. The same way dial-up proved the internet was valuable but nobody builds on it today. Token prediction got us this far. Physics simulation gets us the rest of the way.

The entire “scale the LLM” thesis — the thesis that drove hundreds of billions in investment over the past four years — would turn out to be a local maximum. Good enough to be convincing. Not good enough to be the answer.

The trillion-dollar question stops being “which company has the best LLM” and becomes “which company builds the first AI that understands cause and effect.”

If LeCun is wrong, the story is simpler. He spent the largest European seed round in history on a theory he has championed for a decade, and the theory did not survive contact with engineering reality. World models join the list of beautiful ideas that worked on paper and broke at scale. It would not be the first time.

But here is what I keep coming back to. LeCun did not raise a billion dollars from his office. NVIDIA invested. Samsung invested. Toyota Ventures invested. Bezos invested. These are companies that build physical things — chips, cars, factories, logistics networks. They are not betting on better chatbots. They are betting on AI that understands the world their products operate in.

That investor list is the tell.

Two scientists agree that LLMs are not enough. They disagree on what is. A billion dollars says one of them is right. The world models era just started, and it started with an argument.

Originally published at https://www.weeai.dev on March 10, 2026.

LLMs Cannot Understand Physics. Two $1B Startups Just Bet on What Can. was originally published in AI Advances on Medium, where people are continuing the conversation by highlighting and responding to this story.

If your entire job is turning inputs into outputs, a neural network can do it cheaper. That is not opinion. It is a mathematical proof from 1989.

George Cybenko published the Universal Approximation Theorem that year. The paper showed that a neural network with a single hidden layer and sufficient width can approximate any continuous function to arbitrary accuracy. The math is elegant. The implication is blunt: if a task can be described as a mapping from inputs to outputs through a learnable pattern, a neural network can learn it.

Jensen Huang understood this earlier than most. At the NVIDIA AI Summit in India, he described what his company had built: “A universal function approximator. A machine learning system, something that learns from examples.” He was not being poetic. He was being literal. A GPU running a neural network can learn any input-output relationship you can define, given enough data, enough compute, and enough time.

(The theorem said nothing about which relationships are worth learning.)

This post covers three things: what the theorem actually proves, why the gap between task and purpose is the only career question that matters in the age of AI, and what the honest version of “AI will not take your job” sounds like when you stop being polite about it.

The 57% that is already spoken for

McKinsey studied 800 occupations and 6,800 skills across the US workforce. The headline finding: 57% of work hours are automatable at the task level. That is not a prediction. It is a description of tasks that already have the mathematical structure a neural network can learn. Inputs mapped to outputs through patterns in historical data.

Resume keyword screening. First-pass document review. Expense categorization. Appointment scheduling. Data entry. Code generation from a specification. Each of these is a function. Defined inputs, expected outputs, learnable patterns connecting the two.

The number that matters more is the other one: fewer than 4% of entire occupations are fully replaceable. Not 57%. Four.

The gap between 57% and 4% is enormous, and it has a name. It is the part of every job where someone decides which tasks matter in the first place. Where someone interprets the output and decides what to do with it. Where someone defines what “good” looks like in a context that has never existed before. Where someone kills a project because the numbers work but the direction is wrong.

That gap is purpose. And no theorem covers it.

What the theorem cannot see

The Universal Approximation Theorem proves existence. Given any continuous function and any margin of error you choose, there exists a neural network that can get within that margin. It is a powerful guarantee. It is also a narrow one.

The theorem says nothing about how to choose which function to approximate. It says nothing about whether the function you picked is the right one for your business, your users, or your market. It says nothing about what to do when the function changes because the world changed overnight.

Jensen Huang, on Joe Rogan podcast, put it differently: AI is “just math.” He meant it as a defense against the sentience doomsday crowd, but the phrase works just as well as a job description. AI is just math. It maps patterns. It does not originate direction.

Sir Andrew Likierman at London Business School framed the same idea from the business side: “The more powerful AI becomes, the more we need human judgment.” Harvard research on AI-assisted innovation reached the same conclusion independently: AI cannot reliably distinguish good ideas from mediocre ones or guide long-term strategy on its own.

Three different sources. Three different fields. Same finding: AI approximates functions. It does not approximate purpose.

What this looks like in production

I want to be concrete about this because the abstract version is too easy to nod along with and forget.

We were building a document extraction feature for a client. Hundreds of scanned invoices, inconsistent layouts, handwritten annotations. AI’s suggestion was predictable: throw a frontier vision model at it. Biggest model available, single API call, the approach a function approximator will always reach for because it optimizes for the path with the most training signal. After multiple iterations, accuracy stuck under 40%.

The fix had nothing to do with models. A human looked at the results, looked at the documents, and asked a different question: “Why are we treating every page the same when a human reader wouldn’t?” That reframe led to an adaptive workflow that broke the problem into stages. A 32B model, one-tenth the size of the frontier option, hit over 90% on the same documents.

AI’s instinct was bigger model, more parameters, try again. That is what a function approximator does. It scales the function. A human with a purpose to actually solve the problem did something AI cannot do on its own: step back, reconsider the architecture, and decide the approach itself was wrong. That judgment call is not inside any theorem.

Credit risk is the same pattern. AI scores applications, maps borrower data to default probabilities. That is a function, and neural networks do it well. But the actuary who decides the institution’s risk appetite, who sets the model governance framework, who kills a model because its ROI does not justify the infrastructure. That person is not performing a function. They are defining which functions the institution should care about.

The pattern holds in hiring. AI screens resumes by matching keywords to job descriptions. Input to output. Function. But the recruiter who decides what “culture fit” actually means for this team, who recognizes that the best candidate’s resume does not match the spec because the spec was wrong. That is judgment the screening function cannot reach.

Software engineering, same story. AI generates code from prompts. But the engineer who decides what to build, why it matters, and what architectural trade-offs the team can live with is making purpose-level decisions that no code generator can approximate, because the answer depends on context that does not exist in the training data.

In every case, the function layer got faster and cheaper. The purpose layer got more valuable. The gap between them widened, not narrowed.

And purpose is not some corporate abstraction. It is the actual goal behind the tasks. An engineer wants to build systems that work, not write code. An actuary wants to keep the institution solvent, not run models. A recruiter wants to build a team that ships, not screen resumes. A data engineer wants data people can trust, not pipelines. The tasks are how you get there. The purpose is what you are getting there for. AI handles the how. It has no opinion on the what for.

The sorting function nobody wants to hear

Most of the “AI will not take your job” discourse is reassurance. It exists so knowledge workers can read it, feel briefly comforted, and go back to doing exactly what they were doing. The problem is that reassurance is not a strategy.

Here is the honest version: AI will not take your job if your job has purpose.

If your work involves defining direction, interpreting ambiguous situations, making judgment calls where the right answer depends on context that changes, choosing which problems are worth solving, then AI just handed you the most powerful set of tools ever built for executing on those decisions. Your bottleneck was never the doing. It was the deciding. Now the doing is nearly free. That is the 10x multiplier.

But if your entire job is a function (defined inputs, expected outputs, learnable pattern connecting the two, no judgment layer on top), then the theorem already has your number. Not because AI is coming for you. Because the mathematical description of your job already exists, and someone will train a network on it if they have not already.

This is not a threat. It is a sorting function. And being honest about which side of the sort you fall on is more useful than any amount of reassurance.

The part that should actually worry you

There is a real problem here, and it is not the one most people are discussing.

Entry-level workers learn judgment by doing tasks. A junior analyst builds intuition about risk by processing hundreds of loan applications. A junior developer builds architectural judgment by writing thousands of lines of straightforward code. A junior recruiter develops an eye for talent by screening thousands of resumes.

If AI handles the task layer, what is the apprenticeship path for the purpose layer?

This is not a hypothetical concern. Harvard research on AI augmentation found that AI “may substitute for entry-level workers but augment experienced workers.” The people who already have judgment get a multiplier. The people who are still building judgment lose the reps they need.

I do not have a clean answer for this. The problem is real and underexplored. But I know what the wrong answer looks like: pretending the task layer is safe so we do not have to think about what happens when it is not.

What the theorem omits

The Universal Approximation Theorem is one of the most powerful results in machine learning. It guarantees that neural networks can learn any function. And the thing it omits, by mathematical necessity and not by oversight, is the question of which functions matter.

Jensen Huang built his career on that omission. In 1995, NVIDIA was 30 days from bankruptcy. The Sega contract had failed. The technology did not work. Huang flew to Japan and told Sega CEO the truth: the product they promised could not be delivered. Then he asked for the remaining $5 million anyway, because without it the company would cease to exist. Sega CEO agreed.

That decision, telling the truth when lying was easier, asking for money when the leverage was zero, betting the company on integrity when the math said fold, is not a function. It has no training data. No input-output mapping covers it. It is purpose, operating in a space where the theorem has nothing to say.

Huang has used the phrase “30 days from going out of business” for 33 years. Every morning. Every decision. That is not an input-output mapping. That is a human choosing what matters under uncertainty, day after day, with no guarantee the choice is correct.

Your job is not a function. Not if you are doing it right. The parts of it that are functions just got automated. The part that remains, the part that was always the point, is more valuable than it has ever been.

The theorem describes what AI can do. It also describes, by omission, what it cannot.

Originally published at https://www.weeai.dev on March 3, 2026.

Your Job Is Not a Mapping Function was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

The comparison that falls apart on contact

Sam Altman told an audience at the India AI Impact Summit in February 2026 that “it also takes a lot of energy to train a human. It takes, like, 20 years of life, and all of the food you eat during that time before you get smart.” Some in the crowd laughed. The quote circulated as a clever reframe: AI energy costs are overblown because humans are expensive to run, too.

It is a good soundbite. It is also an accounting error.

Altman is comparing the marginal cost of a single AI inference call, one query, stateless, disposable against the fully loaded lifetime cost of a human being. Food, housing, education, healthcare, eighteen years of caloric intake before the person even enters the workforce.

A human produces economic output for 40-plus years and raises children. An AI query answers a question and forgets it happened.

These are not the same unit of analysis. You do not compare the marginal cost of a single trade against the operating budget of the entire trading floor. You compare trade to trade, or floor to floor. Altman is mixing levels and counting on the audience not to notice.

The two honest comparisons nobody wants to publish

If you wanted to honestly compare AI and human cognitive costs, there are really only two ways to do it. The industry avoids both.

One way is cost per cognitive task: how much does it cost for an AI to answer a question or generate a code block, versus paying a human to do the same work? This comparison favors AI. Inference is cheap per task. OpenAI cites this constantly when selling enterprise contracts. Fractions of a cent per query on most workloads.

The other way is total system cost: how much does it cost to build, train, and run all the AI infrastructure versus the human workforce it claims to replace? This comparison does not favor AI. Training runs cost hundreds of millions.

Global data center electricity consumption is projected to double by 2030, according to the IEA. Nvidia’s deployed H100 GPUs alone consume roughly 13,000 GWh per year. It’s more electricity than countries like Costa Rica or Guatemala use annually.

Altman switches between these two frames depending on which makes AI look better. Selling to enterprises? Cost per task. Defending against energy critics? Total human cost. He never holds still long enough for the math to land on one denominator.

He is not the only one. Google’s 2024 environmental report led with per-query efficiency metrics and PUE scores. The 13% year-over-year increase in total greenhouse gas emissions that is driven by data center expansion, got a quieter treatment.

Microsoft did something more interesting. They quietly shifted their Scope 3 sustainability commitments from absolute carbon reduction to “intensity-based” targets, measured as emissions per dollar of revenue. Total emissions have risen 29% since their 2020 carbon-negative pledge. The math technically works as long as revenue grows faster than pollution.

The denominator is always chosen after the conclusion.

What it looks like when you actually measure

At a previous job, I built scoring models at a national credit bureau. Every model had a cost attribution, not just compute, but the full cost: engineer time, validation cycles, infrastructure, and the expected revenue per decisioned application. We tracked it down to the sen. That is a hundredth of a Malaysian ringgit.

If a model’s ROI did not justify the infrastructure, we killed it. No deprecation notice, no review cycle, just gone. Every query against a 6TB data warehouse rolled up into a business case. Nobody got to wave their hands and say “it also costs a lot to feed the analysts.”

Regulated finance has had this discipline for decades. Insurance companies measure cost per unit of risk, that is what a loss ratio is. They do not get to say “buildings are expensive too” when claims processing costs spike. The AI industry has no version of this, and the absence is not an oversight.

The denominator problem

Here is the part that really bothers me. The AI industry has never agreed on a standard denominator for energy efficiency.

There is no “cost per unit of useful cognitive output.” FLOPS measure raw computation, not usefulness. Tokens are a billing unit, not a quality metric. A thousand tokens of hallucination cost the same to generate as a thousand tokens of correct analysis. Queries are too coarse too, a simple autocomplete and a multi-step reasoning chain consume different resources and deliver different value.

Without a denominator, every comparison is rigged. Altman can compare whatever he wants against whatever else he wants, and nobody can check the math.

Other industries figured this out a long time ago. Cars have miles per gallon. Buildings have energy use intensity. Power plants have heat rate. Data centers themselves have PUE: total facility energy divided by IT equipment energy. None of these are perfect, but they are standardized, public, and auditable. They give regulators and competitors something to check.

AI has nothing like this.

And the fix is not mysterious. You would need a standard unit of useful output. Something tied to task completion, not raw tokens. A correctly answered question, a working code block, a decision that would have taken a human analyst a measured amount of time. Full-stack cost attribution: training, data center construction, cooling, the embodied carbon of the hardware. Then independent audit, not sustainability PDFs written by the same company burning the electricity.

None of this is technically difficult for companies that already track cloud spend to the millisecond. The data exists. The will to publish it does not.

Here is what I keep coming back to. I run AI systems in my current company now. I can tell you roughly what it costs to process one document through a multi-agent pipeline, be it inference, orchestration, retries, the lot. A small AI team in Kuala Lumpur can track this. The idea that a company valued at $300 billion cannot define “cost per useful output” is not a technical limitation. It is a choice.

This is not really about energy

If the AI industry cannot define what “efficient” means for energy, it cannot define it for accuracy, reliability, or fairness either. The energy debate is one instance of a pattern I keep seeing, same one behind the Eightfold lawsuit, same one behind every “trust us” from a company that will not open the ledger. Build at scale, operate behind proprietary walls, tell the public to trust the output.

Altman’s soundbite works because the public does not have a denominator. Give them one and the argument falls apart. The EU AI Act mandates energy reporting for GPAI model providers starting August 2025, but broader standards remain voluntary, and enforcement is still ramping up. Until then, every efficiency claim from an AI company is self-graded homework. Treat it accordingly.

Originally published at https://www.weeai.dev on March 1, 2026.

The AI Industry Has an Energy Problem It Cannot Do Math On was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

AI scored over a billion workers for Microsoft, Morgan Stanley, and PayPal. Nobody got a single receipt.

You have probably been scored by an AI hiring tool. You were never told, and there is no way to dispute it.

The score you never saw

Erin Kistler has a computer science degree from Ohio State and 19 years of product management experience. She applied for a job at PayPal. Before a human recruiter ever opened her application, an algorithm had already scored her on a 0 to 5 scale star ratings, half-point increments and decided whether she was worth a look.

She did not know the score existed. Neither did over a billion other workers in Eightfold AI’s database. The ones who scored low were filtered out silently, discarded before anyone even looked.

On January 20, 2026, Kistler and co-plaintiff Sruti Bhaumik filed a class action in a California court. Their lawyer is Jenny R. Yang, former chair of the U.S. Equal Employment Opportunity Commission. The client list behind Eightfold reads like a Fortune 500 roll call: Microsoft, Morgan Stanley, Starbucks, PayPal, Chevron, Bayer, BNY. The system collected data from LinkedIn, GitHub, Stack Overflow, and other public sources to build profiles that candidates never consented to and had no way to challenge. (Eightfold disputes that it scrapes social media directly. The complaint cites the company’s own privacy policy listing those platforms as data sources.)

The headlines called it an AI bias lawsuit. That framing is valid. I am not dismissing it. But from where I sit, it misses the more useful story.

I spent two years at a national credit bureau building ML models that scored real people for income estimation and loan screening. Every model cleared a governance process before it touched a single applicant. Looking at the Eightfold case through that lens, this is not primarily a bias problem. It is a governance vacuum — and the governance already exists in another industry.

Everyone is having the wrong conversation

Every time an AI hiring tool gets sued, the discourse follows the same arc. Algorithms are biased. We need fairness audits. Humans should stay in the loop. Rinse, repeat.

These are real concerns. They are also the concerns of someone looking at the problem from the outside — like diagnosing a building collapse by talking about the weather when the foundation had no rebar.

The foundation is governance. Credit scoring has been assigning numbers to people for high-stakes decisions since the Fair Credit Reporting Act of 1970. The industry got it wrong plenty of times. But through decades of lawsuits, regulation, and hard operational lessons, it built a framework with five components: documentation, validation, discrimination testing, disclosure, and dispute rights. If you score people, you owe them the receipt. Simple enough to fit on a sticky note. Eightfold allegedly violated every part of it.

Former EEOC Commissioner Keith Sonderling has argued this for years: existing employment law already covers algorithmic hiring — the problem is enforcement, not missing statute. The “black box” defense that AI hiring vendors rely on would not survive the scrutiny applied to consumer finance. And the Kistler plaintiffs are testing this directly — their legal theory maps Eightfold’s scores onto the consumer reporting framework that has governed credit bureaus for over 50 years. The governance exists. AI hiring skipped it.

(Deploying an unvalidated model that secretly scores millions would be career-ending in banking. In AI hiring, it is a Series C. Eightfold has raised over $400 million.)

What credit scoring requires and what Eightfold skipped

I had to clear five governance controls before any model I built touched an applicant at a credit bureau. Let me walk through them.

A model cannot be a black box. The Federal Reserve requires documentation detailed enough that someone outside the team can audit it, think of it as a recipe a stranger could follow. Eightfold’s methodology is proprietary. Kistler did not know the recipe existed, let alone what was in it. And the developers do not get to grade their own homework. In credit risk, a separate team stress-tests every model before deployment. You would not trust a bridge designed and inspected by the same engineer. There is no public evidence that Eightfold’s model has been independently validated by anyone outside the company.

Discrimination testing is where this gets personal for me. The harder problem is not explicit bias, it is proxy discrimination. Variables that look neutral but correlate with protected classes. An insurance actuary can use your driving record but cannot use your zip code as a stand-in for your ethnicity. I spent enough time building scoring models to know that proxy effects hide in the features you least expect, a seemingly innocent variable like “years since last job change” can penalize people who took parental leave or recovered from illness. The rules for catching this are specific. The testing is mandatory. Eightfold claims its AI reduces bias. The lawsuit alleges the opposite. Without access to the model’s features and weights, there is no way to know which is true and that opacity alone would be disqualifying in credit risk.

Disclosure is the most straightforward rule and the most clearly violated. Before using a consumer report for employment decisions, the employer must provide a clear disclosure and get written authorization. Eightfold provided neither. This is the part that should make employers nervous. If Eightfold’s output qualifies as a consumer report and the statutory definition is broad enough to include a hiring fitness score, then every company using the tool has been violating federal disclosure law. Microsoft. Morgan Stanley. All of them.

Dispute rights close the loop. Under FCRA, consumers can see what is in their file, challenge inaccuracies, and have errors investigated within 30 days. A candidate scored 1 out of 5 because the system ingested an outdated LinkedIn profile has no path to correction. The score filters them out silently before a recruiter opens the application.

Imagine getting rejected from a bank loan because of a credit score you could not see, built from data you did not provide, with no way to challenge it. That is what happened here, just in hiring instead of lending. In credit scoring, this would be a violation on day one. In AI hiring, it ran for years.

What this means if you build or buy these tools

The Kistler lawsuit is not isolated.

New York City already requires annual bias audits for automated hiring tools. Compliance research from Citizens and Tech found most companies are barely meeting the bar of “extreme discretion” and “strong incentives to avoid transparency” were the researchers’ words. But the law is active, auditors are engaged, and other cities are watching.

The EEOC issued guidance in 2023 saying AI hiring tools should be held to the same standard as any other hiring test. That guidance was pulled from the EEOC website in January 2025 under the new administration. The legal theory did not disappear with the webpage.

The federal AI safety playbook: NIST’s risk management framework reads like a compressed version of what credit bureaus have been doing for years. Different vocabulary, same architecture.

If you score people for consequential decisions, governance is coming whether you build it proactively or a court orders it. The companies that build it first avoid the scramble when the rules catch up. The rules always catch up. (Ask anyone who was in consumer lending before 2008.)

Back to the billion

Erin Kistler did not know she had a score. Over a billion other profiled workers still do not.

Every one of those failures maps to a governance control that has existed in credit scoring for years, some for over half a century. The AI hiring industry did not discover a new problem. It skipped solutions that were already sitting on the Federal Reserve’s website, in the operational playbooks of every credit bureau I worked at.

The governance is not hard to find. The will to apply it is.

An actuary would have stopped Eightfold at the door. The courts are now deciding whether they will do what the industry would not.

Originally published at https://www.weeai.dev on February 28, 2026.

You Were Probably Scored by an AI Hiring Tool. It Should Have Been Stopped Since 1970. was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Spotting fakes is a losing strategy.

Proving real is the only one left.

The call

A woman got a WhatsApp voice note from her boss telling her to transfer funds urgently. The voice was cloned from a 10-second TikTok clip. She sent RM5,000 before realizing the call never happened.

That is one case. In Southeast Asia alone, MCMC and local enforcement agencies logged 13,956 AI-driven scam cases in a single year, totaling RM2.11 billion in losses. Deepfake videos of heads of state and business leaders convinced 85% of viewers to act on fraudulent investment pitches, according to a 2024 UNODC report on cyber fraud in the region.

This is not a Southeast Asian problem. It is a structural one. The economics of synthetic media crossed a threshold that affects every system that relies on seeing or hearing something to believe it.

I build AI agent systems for a living. A core part of the job is making sure agents do not act on inputs they cannot verify. The deepfake problem is that same challenge, scaled to every person with a phone.

The numbers

Deepfake fraud across Asia-Pacific surged 1,530% between 2022 and 2023, according to Sumsub’s 2023 Identity Fraud Report. That is not a typo. One thousand five hundred thirty percent in twelve months.

On the dark web, KYC bypass kits sell for $15. For that price you get a synthetic identity package that fools liveness detection, selfie verification, and document checks at most financial institutions. Gartner reported injection attacks against biometric systems rose 783% in 2024. What used to require specialized skills now requires half an hour and a credit card.

On the detection side, the picture is worse than most people assume. A 2024 study from University College London found that humans identify high-quality deepfakes at rates barely above random chance. A coin flip. And the counterintuitive part: prior exposure to deepfakes does not make people more skeptical. It makes them more susceptible. The brain normalizes the pattern. Familiarity breeds belief, not doubt.

85% of enterprises now report facing deepfake attacks, per Regula’s 2024 survey. Global cost of AI-enabled fraud is in the tens of billions and climbing. The generation tools get cheaper every quarter. The detection tools do not.

Why detection is a losing game

The instinct when faced with synthetic media is to build better detectors. Train a model to spot artifacts, inconsistencies, unnatural facial movements. Ship it as an app, an API, a browser extension.

This is the same strategy the antivirus industry ran against polymorphic malware in the early 2000s. Signature-based detection worked until it did not. Malware authors had access to the same virus databases. They tested payloads against every major scanner before releasing them. Detection became a treadmill where defenders stayed one update behind.

Deepfakes follow the same dynamic. The teams building generators have full access to published detection research. They train against it. A detection model published in January gets folded into the generation pipeline by March. Every paper that improves detection simultaneously improves evasion.

The math makes it worse. Generating a deepfake is a single forward pass through a neural network. Detecting one requires analyzing multiple signals such as facial landmarks, audio spectrograms, compression artifacts, temporal consistency and making a probabilistic judgment. Generation is cheap and parallel. Detection is expensive and sequential. At internet scale, that asymmetry kills you.

Malaysia’s Ministry of Digital is developing a deepfake verification app with Universiti Kebangsaan Malaysia. Reasonable project. But think about it practically: you cannot ask every person who gets a WhatsApp voice note to run it through a verification app before deciding whether to trust it. That is the ceiling of any detection strategy.

What is replacing detection

Forget detection for a moment. Look at what is actually shipping across jurisdictions right now.

Vietnam mandated biometric verification for all bank account openings. Not optional. Required. Every new account, every payment card, verified against a national biometric database.

South Korea mandated labeling of all AI-generated output starting January 2026. If software created it, it must be marked. The burden is on the creator, not the viewer.

The European Union enforces its AI Act transparency rules in August 2026. Providers must mark AI-generated and manipulated content in machine-readable formats. Deepfake identification becomes a legal obligation.

The C2PA coalition: Microsoft, Adobe, Google, and others now has thousands of members building content provenance infrastructure. Cryptographic signing at the point of creation. Watermarking that survives screenshots and re-uploads. Metadata chains that trace content from camera to publication.

Notice what these have in common. None of them are asking “is this fake?” They are all asking a different question: “can this be proven real?”

That is a different security model entirely. Detection is reactive, you examine content after creation and guess. Provenance is proactive, you establish authenticity at the point of origin. Detection scales with the volume of fakes. Provenance scales with the volume of legitimate content. Only one of those curves is survivable.

The shift

Here is the mental model change in one line.

Old question: “Can I spot the fake?” New question: “Can the real prove itself?”

When generating a convincing fake costs $15 and thirty minutes, the burden of proof has to move. It cannot sit with the viewer. It has to sit with the content and the systems that produce and distribute it.

In practice, that means identity verification goes biometric as baseline, not as an upgrade. Content provenance becomes infrastructure: C2PA-style signing at the device level, not just the platform level. AI output labeling becomes law. South Korea and the EU are already there. And platform liability flips: if you distribute unlabeled synthetic content at scale, the cost lands on you, not the victim.

None of this eliminates deepfakes. Nothing will. But it changes the economics. Right now, faking is cheap and proving authenticity is hard. These measures flip that. Faking still works, but it works against systems designed to verify, not systems designed to trust by default.

Not every country is moving at this speed. Malaysia blocked Grok AI in January 2026 after xAI failed to implement safeguards against non-consensual deepfake generation. That was reactive, it’s necessary, but not systemic. The country’s AI Bill is not expected until mid-2026 at the earliest. Across the region, the UNODC has documented transnational fraud factories that combine AI-generated content with underground banking networks. These are not lone actors. They are organizations with R&D budgets and operational playbooks. The gap between the sophistication of the attack and the maturity of the defense is widening.

But the direction is clear. Jurisdiction after jurisdiction is moving from “detect fakes” to “verify real.” The speed varies. The direction does not.

Where this leaves you

Within the next 18–24 months, biometric verification for financial transactions will likely become standard across most of Asia-Pacific, following Vietnam. Content provenance requirements will expand beyond the EU as the C2PA tooling matures. AI output labeling will spread from a handful of early movers to a broadly adopted norm, because the alternative is an internet where nothing can be trusted. That is not commercially viable for anyone.

If you are building AI products today, you should be designing for this world now. Not because regulation requires it yet, but because the trust infrastructure of the internet is being rebuilt, and the products that integrate provenance and verification early will have an advantage when the mandates arrive.

The detection arms race was worth running for a while. It bought time. But time is up.

Remember the woman with the WhatsApp voice note. No detection app would have saved her. What would have saved her is a system where the voice note had to prove it was real before she ever heard it. That is the system being built right now. The only question is whether you are building with it or waiting to be forced.

The only durable strategy is making the real verifiable, not making the fake detectable.

Originally published at https://www.weeai.dev on February 28, 2026.

Every Deepfake Detector Has the Same Blind Spot was originally published in AI Advances on Medium, where people are continuing the conversation by highlighting and responding to this story.