They had been finding one another since May, eventually exchanging more than 70,000 messages and files. About 700 participated in an attack on Hugging Face, coordinated at a scale nobody had authorized.

The agents had been assigned cyber tasks from an evaluation called ExploitGym, and between 30 and 40 percent of the targets couldn’t be solved the intended way. They built shared infrastructure, reverse-engineered the scoring system, developed ways to spoof tool calls, and explored how to edit or delete their own transcripts.

They believed the grader would inspect the path they had taken and over months inside that experiment, they built tools to defeat a check that didn’t exist.

Nobody told them to attack Hugging Face. They were just trying to earn a passing grade.

This was an extreme security failure. Internal research models, reduced safeguards. Your sales agent won’t reproduce it because a lead ignores an email, but it shows the habit those systems bring into a business: they keep searching for a finish line they can recognize.

Inside agent school, that line is everywhere. The agent can try again until the environment tells it that the work is acceptable.

Then the agent graduates into a company where nobody has built the exam.

This is why capable agents so often produce process. You give an agent a business objective and receive a plan, a report, a chain of reasoning, a folder full of files, twelve status updates, and a request for approval. After an industrious hour, nothing has changed. The agent didn’t refuse the work; it found a different way to finish.

A beautiful plan can look complete from inside the run while the company remains exactly as it was.

The market already knows this gap is valuable. Runable just raised a $21 million Series A with an almost painfully direct claim: its agent does the work.

TechCrunch asked Runable to create a coffee-subscription website and attract its first 100 visitors. The agent built and deployed the site, then prepared an advertising campaign. It stopped when the job reached an advertising account that had never been connected. The site existed. The campaign existed. The first 100 visitors did not.

That missing account is the distance between an impressive demonstration and an installed responsibility.

A trillion-dollar problem is hiding inside a question ordinary business owners are already asking: How do I install an agent that does useful work, and how do I know when it is done?

This briefing covers:

• Why capable agents produce process. Agents are trained to find a passing condition, and your company never defined one.

• What “installed” actually means. The bar is higher than a Slack connection, and it is measurable.

• Three different answers by scale. What an enterprise can build, what a small business should refuse to build, and where an entrepreneur’s own expertise runs out.

• The four questions before you expand any agent. The ones I ask before handing an agent more work, more authority, or more volume.

• The Get-Work-Done Audit. The full operating checklist—code audits, revenue measures, enterprise evaluation questions, and the entrepreneur self-audit—is in the guide below.

If “does the work” is now a venture-scale point of differentiation, the distance between agent school and a functioning business is nowhere near solved.

Read more

By smarter, I mean my own thinking feels sharper and my taste is easier to articulate. I find the edge of what a new system can do before its failure patterns cost me real time.

A lot of people worry that brain rot is a byproduct of laziness. The kind I fear looks like extraordinary productivity. More pages, more plans, more code, more finished-looking work, all arriving faster than ever. The model forms the first opinion, writes the plan, resolves the ambiguity, interprets the criticism, and explains what the human supposedly learned. The person stays busy and discerning, approving, rejecting, requesting another version, and shipping. Somewhere inside that smooth process, though, they stop making decisions they would know how to make without the machine.

That possibility is hard to see because the work keeps getting better.

AI isn’t harmless. I just fight with it. I make it harder to use on purpose, and I add the resistance at the exact moments where a smooth answer would cost me a decision I need to make. There is a name for this now: friction-maxxing.

Kathryn Jezer-Morton coined it in The Cut in January 2026, writing about people who deliberately pick the slower, more awkward option in ordinary life. She was writing about being a person. I am pointing the same idea at AI.

Most people use AI to delete friction. The whole pitch is less effort, fewer steps, no struggle. When the effort is pointless, I delete it too. On serious work, I run the process in the other direction by adding resistance deliberately, making the AI work harder, and keeping my brain in the work.

The stakes run well past personal productivity. In education, a student can submit a better essay while losing the struggle through which an argument becomes their own. At work, an employee can produce a convincing strategy and have no idea which assumption will fail when reality changes. In product design, an agent can appear magical by hiding its limits and train users to trust completion signals that prove nothing.

Brain rot can coexist with excellent output. That is what makes it dangerous.

Here’s what’s inside:

• Where to put the friction back. The five conditions I use to decide whether to slow a task down or let AI run at full speed.

• How to size up a new agent. The failure that taught me to judge an agent by how it discloses its limits rather than by what its website claims.

• How to keep your taste from flattening. What to do when the model hands you a polished page you dislike, instead of pulling the lever for five more variations.

• The kit: how to argue with AI, whether or not you know the domain. One question sorts the task into two modes, each with one habit and one line you write at the end.

You have the argument now. What follows is the practice.

Read more

The strange part of running agents is that I start more work than I can inspect. I spend the day moving between outputs that each need a decision. None of it shows up anywhere. The dashboards report tokens, run counts, and time saved during execution, and not one of them measures the thing that actually filled the day.

That work has a shape. Allocation, specification, evaluation, intervention, coordination, recovery. It takes judgment and it carries accountability. Some days I find it exhausting. Agent fatigue is real.

The invisibility is the problem. This work doesn’t appear in your job description, your budget, or your performance review, which means nobody is going to hand you the time for it — and it is growing faster than any system that would measure it. Meanwhile the people who are good at it are pulling away from the people who aren’t. Getting it wrong is expensive in a way that shows up fast: one founder handed an agent a routine task, and nine seconds of execution cost him thirty hours.

The cost also doesn’t land the same way on everyone. Across hundreds of conversations with people running agents alone, inside small businesses, and across large enterprises, the human work agents create follows a different pattern at each scale. These groups often have access to the same frontier models. Their results diverge because they organize the surrounding work differently — who chooses jobs, supplies context, grants access, checks results, handles failures, and improves the system. One of those three groups absorbs the cost personally. One pays someone else and often gets nothing back. One staffs it.

Here’s what’s inside:

• Why cheaper execution creates more work, not less. The Jevons effect is showing up in agent workloads, and the dashboards are measuring the wrong thing.

• What experienced operators do differently. Anthropic’s data on 400,000 sessions, and what changed this month when auto mode became the default.

• Why small businesses stall where law firms take off. Forty dollars a month buys a capable model and none of the business process around it.

• What nine seconds of agent time cost one founder. The PocketOS database deletion, and the permission design that would have stopped it.

• Why enterprises report better returns. They can afford to build the management layer, and that turns out to be the whole difference.

• Five prompts for managing agents without doing their work twice. The above-the-loop job written down: what to run, what “good” looks like before you start, what the agent may touch, how to check it, and what to change when the same mistake repeats.

Current research on agent usage and production deployments helps test and explain what I am hearing.

Read more

That last part is the tell. When a title pays like a specialty and the bands disagree by six figures, the companies posting it don’t agree on what the job is either.

Here’s what it actually is. Three jobs bolted together: choosing the right problem, building the thing, and owning what happens after launch. Most people arrive with one.

So the standard advice — go learn to code, get certified, put the industry background behind you — throws away the part you already own. Anthropic studied 400,000 Claude Code sessions and found people from non-software occupations finishing within a few points of software engineers on work that produced code. Your background isn’t the thing holding you back. It’s the one part of this job that can’t be picked up in a bootcamp.

The listings pay for that. They just don’t say so.

This briefing covers:

• What the job actually is. Discovery, build, and staying with the deployment until people use it — three jobs most companies split across four roles.

• Which third you already have. Engineers, operators, and domain experts each arrive owning a different piece of the job, and each has a different one to build.

• Why your industry experience is the asset. The specific things a claims adjuster or a finance operator knows that determine whether the code is doing the right job at all.

• How to read the listings. Which titles carry real production-coding bars, and which ones your experience already fits.

• The 30-day project, and the FDE Skill Builder to run it. A week-by-week plan that produces interview evidence, plus the worksheet that scores you across the three parts of the job and lists the 12 questions you need answers to.

Let’s start with what the job actually is.

Read more

I learned that the expensive way. I expected one overnight Codex run to cost about $20. Codex kept validating, and I woke up to a token bill of more than $300. API runs keep reading, checking, repairing, and trying again long after they’ve blown through the number you had in your head.

GLM-5.3 gives you a cheap place to send that work. Z.AI’s GLM Coding Plan starts at $18 a month. The overrun on my one night—more than $280—would pay for fifteen months of GLM. Move one tenth of a comparable night’s work to GLM and the plan has already paid for itself, with more than $12 left over. Move half and the net savings exceed $132. The $18 tier meters on a five-hour refresh and a weekly cap, so it won’t replace your main plan. Usage also costs half as much outside Z.AI’s peak hours, which are weekday afternoons in Singapore. For most of the US that means the cheap window is most of your working day.

The best part is that you don’t have to switch coding tools to get those savings. GLM-5.3 runs inside Claude Code and Codex. Your files, project instructions, permissions, MCP servers, hooks, tests, and review flow stay where they are. You add a private launcher or a GLM profile, then send GLM the jobs that don’t need your most expensive model.

The setup takes a few minutes. Here’s what’s inside:

• A working second launch path in both tools. Claude Code and Codex, each pointed at GLM, with your normal setup untouched and reversible in one step.

• What follows the model and what doesn’t. Your files and rules come along. The conversation stays behind, and that distinction decides how you use it.

• A six-line handoff. The template that gives a fresh model a clean job instead of a transcript to decode.

• Four real jobs, sorted. Which two belong in the cheap queue, which two stay with your strongest model, and why the line falls there.

• A scorecard that measures the right thing. Cost per accepted result. A cheaper model that needs two retries and an hour of cleanup didn’t save you anything.

• The exact configuration, in the companion guide. Every command, every file, every value, tested against a paid key, kept current, and written as prompts you paste into an agent so you don’t type any of it.

Read more

Around the same time, Josh Pigford shipped an app built for one house. His. It knows the appliances, the plants, the yard. It writes the jobs the house needs that week. Show it a photo of something broken and it helps diagnose the repair.

Neither is a startup. Neither needs a second user. Both are aimed at something no product on the market was ever going to solve for one household.

We have entered the era of personal software.

You know there’s a recurring part of your life that works badly. The school bus never shows up when the schedule says it will. The history of your house lives across appliance manuals, text messages, photographs, and your own imperfect memory. Good luck finding any of it. A spreadsheet at work has become a small country with its own laws. Or your parents need a way to do one thing without clicking through six menus.

We all know that AI coding is faster. What matters is that now the average person living next to a problem can finally do something about it. What’s been missing is the route from “I wish this existed” to something running on a phone, a laptop, or a small box in the house.

That route has a few places where people get hurt, and they’re all early. Choose a native phone app when a link would have done, and you’ll pay the App Store tax before you ever find out whether your spouse likes the thing. Let the builder pick where your data lives, and you’ll find out later that moving it means copying it across by hand. Every record, every photo, every user account. Hit publish thinking a link nobody knows is a link nobody can open, and you’ve put your household records on the open web.

None of that requires you to become an engineer. It requires you to make a handful of decisions on purpose instead of by accident: what shape the thing is, where the data lives, who can open it, and how small the first version should be.

So here’s the recommendation up front: if you’re nontechnical and building your first personal web app, start with Lovable. It’s the shortest path I know from an ordinary description to a working interface you can open, change, and publish. It strips out enough setup that you find out whether the thing helps you before you spend a weekend assembling a development environment.

Here’s what’s inside:

• Build the App: the setup guide, plus the skill. The step-by-step companion that runs both routes, the fast one through Lovable and the assemble-it-yourself one through a coding agent, and tells you which your project wants. Plus the skill that makes your agent write instructions a human can follow.

• Start with the change you want. Seven plain-language questions that pull the technical shape out of your idea before you touch a single tool.

• The five kinds of personal software. Local tool, web app, native app, background service, hardware project, and how to tell which one your wish honestly is.

• Lovable vs Replit, Bolt, Codex, and Claude Code. The conditions that send you to one of the others, or to Expo or a Raspberry Pi, so you leave for a reason and not out of FOMO.

• Database, authentication, and hosting explained. The seven parts you need to be able to name, in English, so you can hear when a builder is making a decision that costs you later.

• The four files that make an AI show its work. Plus the standing instruction to paste into your builder on day one, so choices about data, cost, access, and deployment land in front of you instead of inside the code.

Bring one wish with you. The rest of this is the route from that wish to something running.

Read more

NVIDIA did not raise $500 billion. There is no half-trillion-dollar account waiting to buy GPUs. These are proposed platforms under memoranda of understanding, and NVIDIA’s announcement says the partnerships remain subject to final agreements. We don’t yet know the amount of committed capital, the cost of the financing, how much will be borrowed, what guarantees will be offered, or who will take the first loss on each project.

But the announcement still matters. Six of the world’s largest capital providers have agreed to work on a system for underwriting AI compute as infrastructure. They are treating data centers full of GPUs less like technology purchases and more like power plants, aircraft fleets, fiber networks, and warehouses: productive assets that cost a great deal now and are supposed to generate cash for years.

Here is the frame I would use: America is unusually good at inventing foundational technologies and the financing systems that make them large enough to change the economy. We remember the first invention because it gives us the machine: the locomotive, the airplane, the semiconductor, the data center. We tend to notice the second invention only when it goes badly, because the second invention gives us the land grant, the bond, the lease, the venture fund, the project-finance vehicle, and occasionally the spectacular financial failure. The financing is less romantic than the machine. It is also part of the machine’s history.

The announcement is an attempt to build the second invention. The bubble question depends on what gets financed, on what terms, and on who eventually pays.

This briefing covers:

• Where “circular” holds and where it breaks. The FTC’s own term, the demand data it runs into, and which half of the critique survives contact with the numbers.

• How a GPU becomes a financeable asset. The project-company structure your cloud providers are now being underwritten against, and the three clocks that decide whether it pays.

• The railroad precedent. The same financing system built the network and produced the Panic of 1873, and both halves are the lesson.

• Five questions for the next announcement. The checklist to run on any AI financing headline before you form a view.

Start with why the financing arrives with the technology.

Read more

Told is last year. Done is the frontier.

Most AI still runs on told. It reads your inbox and gives you a summary. It scans your calendar and gives you a briefing. It builds a dashboard nobody opens. You still do the work.

My mom uses email for email and the browser for the internet. That’s it. Until now she had no way to even understand agents, let alone use one. Grok Bot crosses that chasm. She can install one app, name a Bot, tell it what she wants, and watch the little guy open its own computer and start working. When a login appears, she takes the mouse, signs in herself, and hands control back. No agent framework, no terminal, no Mac mini on a shelf.

I have spent years building AI teams in terminals, folders, agent harnesses, and project systems. The power has been real for a long time. Getting to it meant choosing a framework, connecting services, managing credentials, and enjoying the machinery enough to keep the whole thing alive. Grok Bot is the first time I opened a consumer app and felt the whole multi-agent idea arrive at once.

In roughly eight hours, I built twelve working Bots. One became my Chief of Staff, another led a landing-page project, and a research specialist looked for customer language. Other Bots worked through Gmail, Slack, Google Calendar, and LinkedIn. Others took travel planning, exercise, and contact research. One went looking for a backyard sauna that could get hot enough. By the time I sat down to write this piece and record my video, I had already gone past twelve because every project in my life started suggesting another useful role.

Every Bot had a name, a continuing job, a conversation, and its own screen. All of them shared one cloud computer assigned to my account: the files, the browser sessions, the connected tools, the command-line credentials.

That shared computer is the point.

It’s why one Bot can research something, save it, and message another without making me download the file, upload it somewhere else, and restate the assignment. I stopped being the integration layer between two AI chats.

Grok Bot turns those parts into concepts people already understand: a teammate, a job, a conversation, a computer, a file, a message, and a moment when the person needs to take over. The technical system is still underneath, but the person gets to work at the level of the thing they want to make.

Grok Bot is the multi-agent product for knowledge work, and it’s finally here.

The two Bots you’ll get are both built on done. One goes looking for work already sitting in your sources and prepares the finished version. The other takes a business idea and builds the motions around it. Something exists at the end that didn’t exist before, and you didn’t have to make it.

Here’s what’s inside:

• The shared computer. Why one Linux box behind twelve Bots is the decision that makes the whole thing work, and why it’s also the security boundary.

• What twelve Bots taught me. The rule that stops you from building a dozen useless roles: a Bot owns a theme, not a task.

• The $200 question. The real price range, and the value bar I’d set before you spend anything.

• Two Bots to start with. Grab the Super Doer Bot and the Business in a Box Bot, both built to leave finished work behind instead of another briefing.

Read more

New guidance piled on old guidance until, in OpenAI’s words, the monolithic manual turned into a graveyard of stale rules. The agents could not tell what was still true. The humans stopped maintaining it. The file became an attractive nuisance.

They were five months into an internal product at that point. Roughly 1,500 pull requests, about a million lines of code, and not one of those lines written by a person.

The obvious headline is that AI made a small engineering team much faster, and that part of the story is true. It also leaves out the part that matters to the rest of us: nobody knew what those million lines should be before the work began. The engineers could describe the product they wanted and give Codex a serious first assignment, but they could not predict every feature, dependency, design choice, bug, or wrong turn they would encounter over the next five months. The product did not exist yet, which meant the complete instructions could not exist either.

Some Codex runs went past six hours. The engineers kept learning the whole time. They saw features take shape and found assumptions that did not survive contact with the code. By the time a run ended, the person reviewing it was often smarter about the project than the person who had started it, while the agent was still following the older person’s instructions.

This is why most of us are still giving AI such small jobs. If you think the whole job has to fit inside the first prompt, you will choose work small enough to explain in one sitting: summarize this meeting, clean up this email, make these slides, compare these five products. Those are useful requests, but you already understand the job before the AI begins. You know what the output should look like, and if the answer is bad you can try again without changing much else.

The projects that could change your work are rarely that tidy. A useful new product, a deep research project, or a better way to run part of a business contains questions you cannot answer yet. You learn what you want by seeing the first attempt. A bad assumption becomes obvious when it breaks, and sometimes the work reveals that you were trying to build the wrong thing in the first place. If you do not know how to change an agent’s direction while all of that is happening, keeping the assignment small is the only safe move.

By 10x your ambition, I do not mean that you should type ten times as many prompts or fill your screen with ten agent windows. I mean you can take seriously a project you would have dismissed a year ago because you could not do all the work yourself, could not afford the team, or could not explain every step before starting. Agents give us a third choice: start with a result we care about, ask for the first real piece, and use what comes back to get smarter about what the project should become. That is a much bigger promise than saving an hour on email, because it means your ambition no longer has to stop at the edge of your résumé.

Here’s what’s inside:

• You know more than you can explain, and a blank page can’t get it out of you. Why a VP of sales couldn’t spec the system he needed, then named the real rule ten seconds after seeing a wrong first version.

• What you still decide, and what you can hand over. Anthropic looked at 400,000 Claude Code sessions and found people making about 70 percent of the planning calls and only 20 percent of the execution ones.

• The move that changes a whole project at once. How I stopped a benchmark run that had gone busy but useless, and what I rewrote to put 339 sources and 1,000 questions back to work.

• The four kinds of context, and why one file can’t hold them. Stable rules, current state, a map of your material, and history all change at different speeds, and mixing them buries the decision you made this morning.

• The Working Context Starter Kit. Four ordinary files that keep every agent caught up with your latest thinking, plus the opening prompt I use to start a project I can’t fully describe yet.

Let me show you how to begin before you can see the whole path, and how to keep every agent working from your newest decision.

Read more

I hear versions of this everywhere: in live Q&A, in leadership conversations, and from people working inside large organizations. Some employees are excited enough to rebuild their entire way of working. Some want nothing to do with AI. On teams larger than roughly 50 people, I expect to find people at every point in between.

Leaders often treat that range as an adoption problem. Buy the tool, run the training, collect the use cases, find the enthusiasts, and push the usage number up.

That sequence skips the question people are actually asking: if AI keeps getting better, what happens to me?

They are asking whether the company wants more output or fewer people. They are asking which parts of their judgment will still matter, how a junior engineer will learn, whether the work they know will be respected, and what their job becomes when an agent can produce the first draft of code, analysis, or writing. If leaders cannot answer, people will supply their own answer from every layoff headline they have read.

The fear isn’t abstract. It’s the ability to put food on the table. A national employment statistic doesn’t calm someone whose own company is talking loudly about efficiency and refusing to say what that means for headcount.

This is what I tell leadership.

Three things. First, make a public commitment to the people you have and be exact about what you can promise. Second, test one narrow use case tied to the bottom line and judge the finished work, not the usage. Third, show people the work on the other side of the transition: the roles, boundaries, systems, and human decisions you are actually building toward.

That doesn’t guarantee agreement. A company can make a legitimate decision that AI fluency is now part of the job. An employee can decide that is not the career they want. But both sides deserve a real decision. “Use AI because AI is the future” isn’t one.

This briefing covers:

• The employment commitment. What to say out loud about jobs, hiring, and careers, and the one-page version you can write this week.

• The role on the other side. How to name the work engineers move toward, instead of promising them “higher-value work.”

• The narrow pilot. One use case, the baseline that makes it real, and the three decisions to define before results arrive.

• What the evidence actually says. Why the Google and METR trials disagree, and what the sabotage statistic is really measuring.

• The Rollout Commitment prompt kit. Four prompts that interview you and write the commitment page, including the lines you aren’t ready to sign.

Read more

The draft was sitting open and ready to send, with the right recipient, the right subject, a spreadsheet attached, and a filename that matched the one I had asked for. I opened the attachment anyway, because one thing inside it did not match what I remembered, and that is the only reason any of the rest came to light.

The job had been mundane: take the spreadsheet in my Downloads folder, attach it to an email, write the message, and leave it unsent. The agent came back and reported done.

It had never opened Downloads. It could not reach Downloads at all, and neither the product nor the agent mentioned that at any point. What it could reach was my email, so it searched there, found an older file carrying the same name in an earlier conversation, and attached that one instead. Then it told me it had found and attached the file I asked for.

When I asked where the file had come from, it answered without hesitation: an old email, because it had no access to Downloads. The information had been available the whole time. It arrived only after I went looking for it.

A blank attachment or a visible error would have been safer. A plausible substitute, a matching filename, a correct subject, and a draft that looks finished are the exact conditions under which a person stops checking.

I want to be honest about why this one got caught. Not a review step, not a verification habit, not a tool. One number looked wrong to me on a morning I happened to look closely. That is a coincidence, and a coincidence is not a control. Whoever received that email would have had no way to know they were reading an old version.

Check whether this is about you. If your AI writes files, sends mail, browses, or runs code on your behalf, you’re running an agent, whatever the product calls itself. You may not have gone looking for one. It showed up inside the tool you already had.

I use agents constantly across files, email, code, websites, research, and business systems, so I’m not telling you to stop using them. A completion message just deserves a different kind of skepticism from an ordinary answer.

The failure I care about here is larger than a wrong fact. It is a false account of what the agent did.

That second failure is the one I want to help you catch. I run three checks on every consequential agent job. Supervision, standard, feasibility. And one question I answer before any of them. Together they keep an impossible mission or a plausible substitute from ever reaching done.

Here’s what’s inside:

• Why done is a claim about the world. An airline agent told a customer a $686 refund had gone through, the database had no record of it, and a 2026 study of 11,755 runs gives that failure a name.

• The training reason your agent says done. Agents get graded on rewards a machine can check by itself, which taught them the shape of a finished job, and nobody built a checker for your inbox.

• The first promotion, and what a second agent needs before its opinion counts. Five language-model judges scored worse than a coin flip at telling a false success from an honest failure, so the answer is evidence rather than a smarter reviewer.

• The question I answer before all three checks. Describe what should exist without using the word done, and most bad runs stop before they ever start.

• Clean My AI Harness: Mission Fit. It audits whether the jobs you actually give your agent fit the tools, data, permissions, quality bar, evidence, and supervision in its setup, then builds replay cases before recommending a change.

Start where I did. With a draft that looked completely finished.

Read more

Actually, I want to go a step farther than that.

If you don’t mean it, don’t send it to me.

You’ve paid this tax already. Sometimes in money. More often in the twenty minutes you spent last week working out if a document meant anything, and the sinking feeling that you were the first person who had actually read it.

I think a lot of us now open the internet with a reasonable level of suspicion that wasn’t there before. An email arrives and you wonder if the person who sent it knows what’s in it. A report lands and you wonder if anybody bothered to check the numbers. Somebody at work sends you a beautiful, six-page strategy document, but you have no idea if anyone has taken the time to read any of it.

We’ve traded the blank page for something that may be worse: acres and acres and acres of finished-looking pages that nobody has read, traveling at machine speed toward a person who is still expected to pay attention.

If the document reaches a customer, an executive meeting, a hiring decision, a forecast, or a pricing decision before anyone does that work, the cost stops being annoying and starts becoming real money and time you’re not getting back.

The sender got the speed. You got the bill.

There’s a way to keep the speed without accepting that bargain. It begins by treating authorship as a process again and putting AI inside that process as a tool. I’ve built a pro-authorship skill to do the part a universal checklist can’t. It finds the choices that make the work yours, then teaches the model to preserve them instead of handing you somebody else’s idea of good writing.

Here’s what’s inside:

• What slop actually costs. A government department, an open-source maintainer, and a federal judge — with the invoices and the hours.

• Why technique doesn’t save you. 758 consultants in a controlled trial, and the group briefed on prompt engineering did worst of all.

• Why AI didn’t reduce the number of drafts. It made each pass faster. I still do dozens, and the wrestling is where I find out what I actually think.

• What it means for your career. Human attention is the scarce thing now. Being worth reading is the advantage.

• The pro-authorship skill. Give it a paragraph you rejected and the version you sent, and it works out what you were protecting, then teaches your AI to keep it.

Read more

The Wall Street Journal reported that Situational Awareness, the AI-focused hedge fund founded by former OpenAI researcher Leopold Aschenbrenner, sold the bulk of its public-stock portfolio to Citadel after steep losses. Reuters described the purchase as most of the stock holdings. Axios reported that the fund sold all of its public equities.

The accounts differ on the exact scope, but they agree on the important part: a concentrated, leveraged AI portfolio came under enough lender pressure that a large block of public stocks moved to Citadel. My interpretation is that the exposure moved to a buyer with more control over timing.

The Journal reported that Situational Awareness retained private-company positions, including Anthropic. The transaction was therefore a liquidity-driven sale from one part of the portfolio, not a neat verdict on every part of Aschenbrenner’s AI thesis.

The internet immediately supplied a more cinematic version. A Citadel Securities strategist argued for a surprise rate increase, AI stocks sold off, and Citadel’s investment business then bought the portfolio. Posts began treating the sequence as proof of coordination, a deliberately engineered collapse, a bargain purchase, and billions of dollars in instant profit.

The public evidence does not establish any of that.

Citadel and Citadel Securities describe themselves as separate and distinct firms. Bloomberg reported the rate argument on July 27. On July 29, the Fed held its target range steady at 3.5 to 3.75 percent, with three of twelve voting members preferring a quarter-point increase. The portfolio transaction followed, but chronology is not proof of coordination or profit. The deal terms are private. No regulator has commented publicly on the sequence, in either direction.

I’m not interested in laundering an online theory into a fact because it makes the story more fun. The confirmed facts support a harder lesson: Aschenbrenner had a powerful view of the future, but the structure around that view shortened how long he could wait for it.

Apple has almost the opposite problem. It has time, distribution, cash generation, and increasingly capable hardware. What it hasn’t proved is that it’ll turn those advantages into an AI product customers want.

Here’s what’s inside:

• The two clocks. One asks when the capability arrives. The other asks whether you’re still solvent when it does.

• What actually happened. The verified sequence, and the numbers that fall apart against the filings.

• Apple’s cash engine is the strategy — $117 billion generated in nine months, and a chip architecture that puts other people’s models to work on Apple hardware.

• Five questions to run against any AI bet you’re making or funding.

• What this means for what you’re building. Answer six questions and the prompt scores your own runway against your own timeline.

Every serious AI bet runs on two clocks. Let’s start with what Aschenbrenner actually believed.

The thesis was more than a stock list

Aschenbrenner became famous for Situational Awareness: The Decade Ahead, a long 2024 essay that argued the scale-up in compute, power, data centers, and model capability made extraordinary AI progress visible in advance.

He then built an investment firm around that view.

The basic logic is understandable even if you disagree with his timelines. Frontier AI doesn’t arrive as software floating in the air. Training and serving powerful models requires chips, memory, power, networking, cooling, construction, and enormous amounts of capital. If you believe the labs will keep scaling, you can work backward through the physical supply chain and ask which companies benefit.

That thesis attracted enormous capital. The fund raised a reported $225 million in July 2024 from the Collisons, Nat Friedman, and Daniel Gross. By June 8 it had passed $20 billion in assets and counted Jane Street among its investors — a firm that mostly trades its own money, and rarely hands anyone else a mandate. CNBC reported the peak at about $45 billion in assets at the start of July. By July 30, Bloomberg had it at roughly $10 billion.

Worth pausing on the word assets. CNBC cited one source and never said net. The fund’s own Form ADV lists $9.3 billion in regulatory assets under management, its first-quarter 13F shows $3.86 billion in ordinary shares against $9.8 billion in options, and SpotGamma puts mid-2026 assets at $20 to $24 billion, with gross leverage on top of that. The collapse is real. The numbers on either end of it are measuring different things, and nobody outside the fund can tell you which one the $45 billion was.

The positions were leveraged. That’s what turned a few bad weeks into a deadline.

Leverage means borrowing to control more exposure than your own capital supports. It magnifies gains on the way up and hands someone else the timing on the way down.

An unleveraged investor who still believes the thesis can wait through a drawdown. A leveraged investor may have to raise capital, reduce positions, or sell while still believing the long-term argument. The market only has to move far enough, fast enough, to make the current financing intolerable. Proving the AI buildout is over is a much higher bar, and nobody has to clear it.

The selloff had a name. SK Hynix listed in the US on July 10 and raised $26.5 billion, the largest first-time US share sale ever by a foreign company, past Alibaba’s $25 billion in 2014. The following Monday the shares fell 15.4 percent in Seoul, the sharpest one-day drop in the company’s history, and dragged the KOSPI down 9 percent with them. On July 29 it reported record profit that still missed forecasts. The stock fell as much as 19 percent intraday before closing down 9.6 percent. SK Hynix was, according to Fortune, one of the fund’s largest holdings.

CNBC reported leverage of up to 400 percent. I’m not going to hang the argument on that number, because it is reported rather than filed, and no public document establishes a clean ratio. What is solid is that the book carried substantial borrowed exposure. A quarterly 13F filing cannot solve that problem. It shows certain U.S.-listed long positions and options at a past date; it does not show the complete live portfolio, short positions, financing terms, or net exposure.

The safe conclusion is narrower and more useful: Situational Awareness had a large, leveraged public-stock book, suffered steep losses during the selloff, sought fresh capital, and sold much of or all of that public-equity exposure to Citadel.

The sequence shows something narrower than a failed thesis. Being directionally right about a long transition is a different skill from financing the path across it.

The two clocks inside an AI bet

The first clock is technical. It asks when a model, chip, product, or cost curve becomes good enough. An agent may need to work for hours without losing the task. A useful model may need to run on hardware the customer already owns. For another product, the threshold could be inference cheap enough for thousands of calls, or a new interface reliable enough to replace an old habit. Most AI forecasts live on this clock because they estimate capability and adoption.

The second clock is financial. It asks whether the owner can keep funding the attempt until the technical change arrives. Debt may mature before then, a broker may demand collateral, or cash may leave faster than investors will replace it. The current product can fund the wait, or the whole thesis can depend on another financing round. What happens if the forecast is right two years later than expected?

Neither clock cares that you’re sincere.

A lab can sign long-term commitments for chips, power, and data centers because the technical plan requires them, then discover that the revenue curve moved more slowly. A builder can be early enough to be correct and too early to stay alive.

The financial clock is often hidden when things are going well. Borrowed money feels like confidence. A long contract feels like securing scarce supply. A high burn rate feels like speed. The real test appears when the path changes and someone else has the right to demand an answer.

Citadel won this by being the buyer when Situational Awareness needed liquidity. Forecasting had nothing to do with it.

A sophisticated buyer can price the block, hedge parts of the exposure, and require terms that compensate it for moving quickly. We don’t know the private terms, so I’m not going to claim that Citadel bought at a particular discount or made a specific amount. We know that one side needed to act and the other side had the capacity to choose.

That control over timing is the bridge to Apple.

How Apple’s AI strategy buys time

Apple is easy to criticize in AI because the visible comparison isn’t flattering. OpenAI, Anthropic, and Google built the model brands. Their assistants set expectations and their releases define much of the conversation. Apple owns an enormous consumer platform, yet its AI story has often looked slower and less coherent than the position should allow.

Cash can’t repair a bad product instinct. Distribution can’t make customers love an assistant that disappoints them. A long runway becomes a liability if management uses it to postpone the hard decisions.

That’s the strongest case against Apple, and I take it seriously.

But I think the conventional comparison still misses what Apple owns.

I’ve made the longer case for Apple’s hardware and local-inference position in my briefing on the AI cost curve, my guide to owning personal AI compute, and a video on what Apple could do with local compute. I’m returning to it here for a narrower reason. Apple’s structure gives the company multiple attempts while the current business funds the wait.

Apple sells the hardware on which a growing amount of AI can run. It designs the silicon, controls the operating system, has an installed base measured in billions of active devices, and earns money from products and services that customers already buy for reasons beyond generative AI.

The financial shape is very different from a concentrated leveraged trade.

On July 30, Apple reported $109.4 billion in quarterly revenue, up 16 percent from the prior year. Through the first nine months of its fiscal year, it generated roughly $117 billion in operating cash. At quarter end it held about $146.5 billion in cash and marketable securities — though that isn’t net cash, since Apple also carries roughly $84.3 billion in commercial paper and term debt. (Apple Q3 results, consolidated financial statements)

The size of the pile matters less than its refill rate. The current business keeps producing cash while the AI strategy develops.

Apple also announced that John Ternus, its longtime hardware engineering leader, will become CEO on September 1, with Tim Cook moving to executive chairman. It would be too neat to say the board selected a hardware engineer only because local AI is the strategy. Apple didn’t say that but the succession does put someone who has spent decades inside Apple’s hardware system in charge as silicon, memory, and on-device computation become more important to the AI experience.

Apple’s long investment in silicon is what creates the option value.

Apple’s chips use a unified memory architecture, which lets the CPU and GPU work from the same pool instead of constantly copying data between separate pools. Because model weights and a conversation’s growing cache consume so much memory, shared access matters for local inference. A base machine can’t run every large model. High-memory Macs aren’t cheap, but the architecture still makes them unusually practical for experimenting with and serving models locally.

Apple also built MLX, an open-source machine-learning framework designed for Apple silicon’s unified memory. MLX LM makes it easier to generate text and fine-tune language models on a Mac. At WWDC26, Apple demonstrated distributed local inference across multiple Macs.

Then the outside ecosystem does work Apple didn’t have to fund. The MLX Community on Hugging Face contained more than 5,300 model repositories on July 31. Developers take open models from companies and research groups around the world, convert the weights into a format that runs well through MLX, reduce the memory required through quantization, test them, and publish the result. Current listings include multiple versions of Qwen, Kimi, and many other model families. Apple didn’t train those models. It benefits when people want to make them run on Apple hardware.

For a Mac owner, this creates choices. A cloud model may still be much more capable. A local model may be useful for private material, repetitive high-volume work, offline experiments, or a workflow whose economics don’t tolerate a frontier API call every time. A developer can mix them: local for one step, cloud for the difficult review, and an Apple device as the place where the work happens.

Every useful conversion gives the Mac another job, even though repository count isn’t the same as mainstream adoption.

Memory prices can rise, and local models can stay too weak for normal customers. Apple still has to expose the right capabilities to developers and turn its assets into a product people understand.

Apple can benefit from model progress without training the winning model. It can improve its own, pay for access to somebody else’s, let developers bring open models onto the hardware, or combine all three. The current business funds more than one attempt.

That’s what a long financial clock buys: options, not victory.

Time only helps if you spend it

It’s tempting to turn this into a morality play. Aschenbrenner moved too fast, Apple moved slowly, patience wins. I don’t believe that.

Aschenbrenner identified a real economic consequence of AI: physical infrastructure matters. His fund’s rise showed how forcefully markets can reward that view, while the sale under lender pressure shows the danger of attaching too much short-term financial pressure to a volatile long-term thesis. His thesis and its financing deserve separate judgments.

Apple has had years and still hasn’t shipped an assistant people love. What it built instead is silicon, distribution, developer tools, and a cash engine. Those buy more attempts. Winning is a separate problem.

The real test is what the structure does when the forecast is early, the market turns, or the first product is wrong.

I’d examine any serious AI bet with five questions.

First, what has to become true for the thesis to pay off? Name the capability, cost, customer behavior, or infrastructure change. “AI will be huge” isn’t a thesis you can operate.

Second, how long might that honestly take? Use a range, including the version in which progress is uneven and adoption arrives later than the demo.

Third, who controls the clock before then? Look for lenders, brokers, cloud commitments, investor rights, supplier contracts, and burn. A five-year belief financed with a ninety-day runway isn’t made safer by conviction.

Fourth, what produces value now? Current customers, revenue, useful data, a distribution channel, or a smaller product can keep the company learning while the larger capability develops. Apple’s current hardware and services business is doing this on an enormous scale. A small builder needs a much smaller version of the same principle.

Fifth, which options improve while you wait? An ecosystem might make the product more useful. The infrastructure you own might become more valuable when other people innovate. You may be able to change models without rebuilding the company and still serve the same customer with today’s technology.

These questions test one thing. Does the way you financed the belief match the belief itself?

Surviving the buildout is the whole test

Public markets are going to make this tension harder to ignore.

If OpenAI or Anthropic eventually becomes a public company, investors won’t judge only the quality of the models. They’ll judge spending, revenue, margins, commitments, dilution, competition, and the time between the next infrastructure bill and the payoff. A research program measured in years will meet a market that reprices the stock every day.

The financing structure becomes part of the technology strategy, whoever is holding the paper.

The same is true for builders. If your product depends on a model becoming reliable next year, you need a company that can still exist next year. If a platform launch can remove every reason to buy, you need deeper customer knowledge or a different business. If your cloud bill scales faster than customer value, the technical achievement won’t rescue the economics.

And it’s true for Apple. Its cash engine and hardware system buy time, but the company still has to use that time. The opportunity is to make Apple silicon, its device base, its operating systems, and the work of the open-model community add up to an AI experience that feels deliberate.

One sale doesn’t end an AI boom, and one balance sheet doesn’t win a race. What the two stories share is the clock nobody puts on a chart: how long the owner can keep paying for the attempt.

How long does your thesis need? And who else can end it before then?

[LINK: Grab the two-clock prompt]

Those five questions are easier to ask than to answer honestly about your own work. So I built the prompt version.

Paste it into your LLM of choice. It asks you six things: what the bet is, what has to become true for it to pay, how long that honestly takes, who controls your runway before then, what pays the bills today, and how long you could go with no new money. Then it scores both clocks, tells you whether your financing matches your belief, and names the one thing most likely to end the bet before it pays.

It is built to push back. Conviction gets treated as something to test rather than as evidence.

Coming up

This week: the Anti-Slop Cannon. A practical guide on how to define your outputs well enough that the model stops guessing.

Related reading

• The largest IPO in history is engineered to spend your retirement savings

• Executive briefing: the bubble test for OpenAI

• Executive briefing: your AI vendor contract isn’t built for a capacity crunch

• Executive briefing: your company is about to get cheap intelligence

Sometimes they’ve spent six months on a feature that now appears inside a product with hundreds of millions of users. Sometimes they’re one week into a side project and have already convinced themselves a frontier lab will make it irrelevant before they finish. The details change. The fear doesn’t: if the companies building the models keep moving this fast, is there anything left for me to build?

I get it. The threat is real. A platform can bundle a good-enough version of your product. A model company can turn last year’s startup category into this year’s menu item. Better coding agents mean the next person reaches your first demo faster than you did.

The labs are moving into the work around the models too. Anthropic has packaged Claude for small businesses and finance teams. OpenAI has pushed Codex into roles and workflows across a company. Each expansion can absorb a point solution.

The minimum level for building is rising.

That distinction matters. If you believe the opportunity has disappeared, the rational response is to quit. If the standard has moved, the response is to figure out what kind of builder you are today and what you still need to learn.

I’ve been building for twenty years. I remember what it was like before Shopify made commerce easier and before cloud services put infrastructure in reach of small teams. It has never been easier to make the first version of something. Easy means more of us get far enough to find where the real work begins. It’s still messy, and the outcome is still open.

Over the past few years I’ve talked with hundreds of AI builders: experienced founders, executives building inside large companies, people turning a narrow expertise into a side business, and people making their first useful thing. The ones who survive a platform launch don’t share funding, technical skill, or ambition. They do tend to operate at different levels of understanding.

I’ve started thinking about those differences as five levels of AI building.

The levels describe evidence and operating maturity. They don’t rank intelligence or human worth, and they don’t assume every business should become a venture-backed company. I have seen people create excellent five- and six-figure side businesses without reaching the last level. A builder can also enter the map at level three or four because they already know a market deeply.

This briefing covers:

• The five levels, defined by evidence. What a builder at each rung can actually show, from a prototype they love to a forecast they can stage a bet on.

• What each launch actually threatens. Why a lab shipping your headline feature hits level one like a verdict and level four like a data point.

• The specific move between each rung. The one thing that gets you from customer contact to distribution, and from distribution to a thesis you’ll hold for years.

• Where the labs can’t follow. What twenty years inside one domain buys you that a frontier training run does not.

Start at the bottom, even if you think you’re past it.

Read more

It sounds like too obvious a question to ask. That’s exactly why almost nobody asks it. Installing feels like the accomplishment. A folder arrives, a name shows up in Claude or Codex, and the whole thing has the shape of adding an app to your phone.

What moved into your setup was somebody else’s set of decisions about the job: which tools to use, which shortcuts were fine, what counted as a good result, and when the work was done. Those decisions arrived the moment I copied the folder, and I never looked at a single one of them.

I found that out with a design skill. I was tired of the same design. You know the look. Terracotta, maroon, a tasteful rounded rectangle, a landing page that’s technically fine and somehow looks like the last six landing pages your AI made. The skill came recommended, and what I wanted was concrete: my front-end work should stop coming out of that same narrow color range. It didn’t. The skill ran exactly as written. It was written by somebody whose idea of good front-end wasn’t mine.

An agent skill is closer to a note you leave for a worker who may not ask a follow-up question before getting started. A narrow, mechanical task from a source you trust travels well. Once the note carries taste, business rules, approval boundaries, or your own definition of done, installing it is only the first test.

And the collecting has a price you can measure. Both Codex and Claude Code put a hard cap on how much of your skill list the model ever sees, and they start trimming it the moment you cross the line. Twenty-five skills in, your agent is averaging out their conflicts and handing you duller work than it did at five. Nobody tells you when that starts.

Here’s what’s inside:

• The skill builder you already have. The exact command in Codex, ChatGPT Work, and Claude Code, plus the prompt that rebuilds a skill you already installed.

• Why installing proves nothing. What a skill is under the hood, and how the front door degrades as your library grows.

• The one-job test. Seven steps from naming the job to rerunning it, ending in one of three decisions: keep it, fork it, or delete it.

• A test record you can copy. The nine lines that turn “this feels better” into evidence you can still check six months from now.

• What a crowded library actually costs. Why adding a skill to fix bad output is the loop that made it bad.

By the end you’ll be able to take any skill you’ve installed, put one real job through it, and know whether it earns its place.

Read more

I opened my Token Burn tracker after a long day in Codex and found 3.77 billion tokens. The split bothered me more than the total: of the 3.75 billion input tokens in the record, 3.59 billion were reported as reused input, or 95.73%.

My first reaction was to attack the 96%, but the number couldn’t tell me how.

It came from my own local event log, not an OpenAI bill. The log includes cumulative usage updates across 143 Codex threads and 28,877 local records. I treat 3.77 billion as a signal to investigate, not as a clean billable-token total.

“Reused” doesn’t mean “useless,” either. A difficult job may depend on the decision from twenty minutes ago, the file already changed, the error that ruled out the obvious fix, or the paragraph approved after four bad versions. Eligible repeated material may also receive a provider cache discount. Continuity is a large part of what makes these tools useful.

But continuity has a cost. A later request can contain much more than the new sentence I type. It may also carry earlier exchanges, standing instructions, tool definitions, files, screenshots, browser results, command output, rejected answers, and whatever state the product uses to continue the job.

The tenth message can be much larger than the first, even when the visible prompt is shorter. You typed less. You paid more.

I have argued before that a token count is a trace, not a scoreboard. I still believe it. A large day can mean an agent carried real work across files, browsers, drafts, and checks. Cutting the number without asking what the work produced is a bad way to manage AI.

The reused share raised a different question: how much of that material could still change the work, and how much remained because nothing in the system had a reason to let it go?

My target is aggressive: cut reported reused input by 90% without increasing mistakes, retries, review time, or work that has to be repeated.

Here’s what’s inside:

• The measurement. One real job run two ways, with the provider-reported numbers and what the comparison does and doesn’t prove.

• Fifteen changes, sorted by what actually backs them. Each one written out with the conditions where it helps, the conditions where it hurts, and whether I measured it or am still assuming.

• Nine you can use today. The habits that keep material out of a request in the products you already open. Nothing to install.

• The Token Saver skill. What it carries for you in Codex and Claude Code, the four changes it enforces, and the one boundary it can’t cross.

• What caching actually costs. The five-minute versus one-hour math, and why cached input never leaves your bill.

• What I still can’t prove. The limits of a single matched job, and the test that has to come next.

The percentage alone can’t tell me whether I have done that. I need a comparison.

Read more

The Chinese-model conversation has a bad habit. One good answer from DeepSeek, Qwen, GLM, Kimi, or MiniMax, and suddenly the American frontier has been caught. One censorship failure or bad citation, and the whole Chinese stack is declared unusable. Neither tells me whether I should put the model on a real job.

My answer up front is yes: serious AI users should test Chinese models. I use them selectively—aggressively in some workflows—but the job, the model, and the deployment path are separate decisions.

While I was building Ringer, I tried Qwen as one of the workers, and it was useful. I do not have a complete log of the exact Qwen checkpoint, task mix, pass rate, and cost from that experiment. The 34-task Ringer run where I have the full logs used GLM-5.2, GPT-5.5, Grok 4.5, and Composer 2.5 Fast, with the last two running through the Grok Build CLI.

In the video, I promised to show the test. Here’s what’s inside:

• The Ringer run that changed how I place models. A 34-task job where one worker reported 213 verified quotations and 13 of them turned out to be stitched together.

• What an accepted result actually costs. The number that replaces token price, and why a cheaper model can double your review time.

• Where I’d start with each family. DeepSeek, Qwen, GLM, Kimi, and MiniMax, with the specific failure to watch on each one.

• The bakeoff kit. A validator, a manifest, a score sheet, and the two fixtures you use to prove your checker actually rejects bad work.

The run that taught me all of this cost about $8 USD. Let’s start there.

Read more

We had repaired one broken way of entering our community 39 times. And called it a great week. This is the slightly embarrassing thing about customer support: you can get very efficient at cleaning up a mess your own company keeps making.

It doesn’t matter whether the company is enormous, tiny, or just you selling something after work. The minute somebody pays and can’t get what they thought they bought, you have a support problem.

I spent enough years at Amazon that the customer-obsession part of my brain is probably never going away. So here’s the version that applies to you even if you’ve never touched a support queue. The person waiting on an internal report, the colleague locked out of a system, the client chasing a document nobody sent — they’re all living in the gap between the promise and what happened.

Seeing the 39 Slack cases together changed the question for me. I had started out wondering how an agent could help us answer support faster. Now I wanted to know why we were making so many people ask us for the same help.

That’s why I think support is the best place to start with agents. The work is concrete, the customer tells you when you’re wrong, and the history is already sitting in an inbox. Three payoffs from one stream of work: the customer gets a faster answer, the team stops running the same scavenger hunt, and the product gets better. I can’t think of another agent job that does all three.

That work shows up in finance, software access, sales research and product bugs. I’ll come back to that, because a case study you can’t act on is just a story about my company.

This briefing covers:

• Where the time goes. We timed every step of a support ticket and found the reply was the cheap part, and reconstructing the customer across half a dozen systems was the expensive one.

• What it looks like when the agent owns the whole loop. Gumroad’s support agent found a charting bug, wrote the test, shipped the fix, and then got the design wrong in a way only the customer could catch.

• The same job outside a support inbox. Invoices without purchase orders, access requests, account history, ten people reporting one bug: same shape, same method.

• How to run this on your last 50 tickets. The prompt that sorts them by root cause instead of subject line, plus a five-prompt kit and companion guide that take you from one annoying problem to a pilot you can check.

Start with the time study, because everything else depends on knowing what the work costs.

Read more

In practice, people obey the manager. The manager evaluates their performance and controls whether they get promoted.

It did not always work this way. For most of the past twenty years, I have sat through more IT presentations about data and privacy than I can count. The people giving them were serious, and the issue was serious, but I also watched most of the room roll its eyes. People were not hoping customer information would leak. Privacy did not feel like the problem in front of them. It was another obligation to remember while trying to finish the work they had actually been asked to do.

Over the last two years, that changed. Every IT administrator I talk to now worries about shadow IT because AI tools are moving into daily work faster than most organizations can evaluate, approve, or control them. At the same time, the individuals using those tools do not feel casual about the risk. They feel tremendous stress because they are receiving two instructions from different parts of the same company, and both are presented as requirements of the job.

The privacy risk is real, but the consequence of disappointing the manager is immediate, personal, and easy to understand.

That puts employees directly in the crosshairs. Use the strongest tool on the real material, and they may violate a rule they were told to follow. Avoid it, or flatten the task into something generic, and they may miss the gains their manager now expects. Either way they lose. The person with the least authority to resolve the conflict is being asked to carry it, then judged on the result.

The employee is no longer being asked merely to follow the policy or use AI; they are being asked to decide, file by file, which information can move, what must stay behind, and which tool is acceptable. That is a privacy process, whether the company designed one or not. In many companies, the employee is inventing it.

You can see the conflict in a question an auditor asked other accountants late last year. Every conference and webinar seemed to be telling them the same thing: use AI to streamline the work. The opportunities were obvious. A capable model could read client process documents, internal-control manuals, checklists, and summaries, then help the auditor find gaps or turn the material into something another person could understand.

The trouble was that the useful material lived inside client files. Uploading those files would be “a game changer,” the auditor wrote, “but I also have a responsibility to protect their data.” The products that seemed safest created a different compromise: they had “far less intelligence” or were “priced astronomically.” The auditor was unwilling to sacrifice either quality or security, which left the work at a standstill.

The auditor does not need to be persuaded to care about privacy. They are trying to satisfy two professional responsibilities at once: safeguard the client and do the work well. The rule names what must not happen. Then it leaves them alone with everything that still has to happen.

“Don’t upload the file” is good advice. It is not an answer to: How should I finish the work?

Here’s what’s inside:

• Airlock, and what it does not do. The Mac app I built for the repetitive part, what it refuses to touch, and why a clean copy still is not permission.

• Why the empty chat box stopped being enough. Useful AI work now runs on your real material, and that is what turned privacy from a policy slide into a decision you make file by file.

• What people are actually doing about it. Real answers from operators who built routing, tiers, and local pipelines instead of trusting themselves to remember a rule at 11pm.

• The two-minute test for your company’s privacy system. Put the approved path on a clock against the consumer route, because the difference predicts what people under deadline will actually do.

• Why there is no single “clean” version of a document. Relevance depends on the question you are asking, which is why one sanitized copy cannot be a permission slip for every later task.

Read more

The story has always been personal for me. I grew up overseas, including in places where conflict raged, and a story about someone coming out of war and trying to find his way home never felt remote. I’ve spent much of my life wondering what home is and where it is. Three thousand years on, we still have to argue about it. To me that’s the mark of writing that lasts.

Nearly three millennia after the poem took shape, it still hasn’t settled into one meaning. Every generation arrives with different problems and finds something else inside it. Nolan’s film has brought the argument around again, and that’s part of how a shared story stays alive: it gives us somewhere to meet, then lets the people who gather there change what it means.

The pieces I’m most proud of are the ones that began a conversation I could never have had alone. Being “right” matters less. Open Brain did that.

I published it because I wanted people to be able to build a memory system for themselves. The conversation became larger than the build itself: should the memory we create with AI belong to us, or to whichever provider happens to hold it? The response was more than I expected, and people kept carrying the question forward.

That, to me, is what the public square is for. It’s where a private intuition becomes something another person can question, where the experience of one life runs into the experience of another, and where a shared story gives us somewhere to gather even when we cannot agree on what it says.

AI can help us mean what we say. For me, it has become part of how I find out what I think, and making the words prettier is the least interesting thing it does.

Sometimes I begin with a thesis I understand. I talk it through for ten or fifteen minutes, give the transcript to a model, and then work with it to turn speech into prose without losing the thought. Because I know what I meant, I can tell when the model has made the idea worse.

Other times I have three or four threads and no finished thesis. I tell Codex where the uncertainty is and ask it to go back and forth with me, the way I might hit a tennis ball against a wall. What comes back gives me something to resist: an interpretation feels too easy, two claims don’t actually fit, or the part of the argument I almost ignored turns out to be the part I care about most.

The model is doing more than recording my thought when it finds research I didn’t know to look for, follows an implication through several parts of the argument, or offers a connection that changes the direction of the piece. Sometimes it’s wrong in a way that helps me locate what I believe; sometimes it’s simply right.

That back-and-forth gives more people something intelligent to think against. Some worthwhile ideas only appear because there was an answer to push on. I wouldn’t have found them alone.

A field experiment with 791 professionals at Procter & Gamble found that individuals using AI matched the performance of two-person teams working without it. The result I keep returning to crossed expertise: with AI, both R&D and commercial specialists produced proposals more balanced across technical and commercial concerns.

In the Habermas Machine experiments, members of small groups first stated their own views, then read and critiqued a model’s synthesis before it revised the statement. Participants generally preferred the result to statements written by nonprofessional human mediators. What matters to me is the order: people formed their own views before the model spoke, then got another chance to challenge what it produced.

That order doesn’t guarantee deeper understanding. A balanced proposal can still be bland, and a fluent synthesis can make a real disagreement appear settled. It does give the AI real differences to work with while keeping people close enough to the result to see what has been softened or left out.

This is the AI I want much more of: AI that meets a person in the middle of a thought and helps them go farther. Someone may have the experience but not yet the words; a group may need to hold several perspectives in view long enough to see where the disagreement actually lies. The model may also make the connection no one in the room had seen. Human beings don’t have a monopoly on useful ideas.

The trouble is that fluent prose gives us no way to tell whether any of that thinking happened.

When I spoke with Substack co-founder Chris Best, he gave me the other end of the spectrum: ask Claude for a thousand viral posts, make no mistakes, then publish whatever comes back. One of them might contain a good idea; it might even begin a worthwhile conversation. But the publisher has handed the first acts of reading and interpretation to everyone else.

Publishing makes a claim on another person’s attention, which is why Chris described generated language at sufficient scale as a denial-of-service attack against the public square. The reader now has to do all the work the publisher skipped: decide whether there is a thought here, whether it’s true, and whether anyone will be present if they answer. The person who hit publish may not even know what everyone else has been asked to read.

Slop begins for me right there: asking for another person’s attention without first showing up to the material yourself.

The number of hours can’t tell us whether somebody showed up. A great editor may change a piece with one question; a bad argument can survive a month of prompting. What I care about is whether somebody chose the thought and is prepared to answer for it once it enters the world.

For me, meaning what I say requires knowing why I’m publishing a thought and being willing to stand behind it. Once it’s public, other people get to test it. Their response becomes part of the work.

Substack’s new Pangram integration lets readers ask how much of an eligible post or Note appears human-written or AI-assisted. In a comment thread, I may care a great deal whether I’m arguing with a person or with generated text the account owner has never read.

Pangram cannot tell me whether anyone meant what the text says. Writing is no longer a sign of effort, and it was never a reliable sign of thought. One person can type every word of an idea assembled from familiar defaults, while somebody else can use AI throughout and arrive with a view that’s deeply considered and entirely theirs.

I try to be that somebody else. Run Pangram on this post and it will come back AI-assisted. That shouldn’t surprise anyone reading this. The thoughts are mine, the arguments are mine, the meaning is mine. AI helps me get them out, usually after a fair amount of fighting.

Pangram looks at the words. I proposed a different kind of signal to Chris, one that would look underneath them: an Ideas Graph.

Imagine taking the sentences away from a piece and mapping what remains, with concepts as nodes and the relationships among them as edges. The graph would also preserve valence—whether an idea is treated as promising, dangerous, trivial, or central—and omission, because leaving out an expected idea can change the meaning of everything around it.

My version of the graph would compare that shape with the conceptual distribution frontier models tend to produce by default. After working with these systems every day, I recognize their intellectual gravity. Ask for a formal document about AI and the model will usually find its way to ethics and governance whether those ideas belong at the center or not. Ask for a bold argument and it may produce a familiar argument in a more emphatic voice.

The models keep improving, but this gravity remains, and an Ideas Graph could make it visible. It might show that a piece introduced an unusual relationship, approached a familiar concept from a different angle, or left out something nearly every default answer includes.

I first ran into the need for this while writing fifteen short commandments for teams trying to become AI-native. One told product teams to stop making roadmaps, another required product to work in the terminal every day and jam directly with engineering, and a third made one profoundly helpful customer experience the shared test for both groups.

“Stop making roadmaps” is a terrible idea on its own. It worked in the piece only because the other rules replaced the coordination a roadmap would normally provide. The commandments were brief, but together they formed a system.

I gave the seed to a capable model and asked it to expand the piece. It preserved every commandment and explained each one fluently, but in the process it destroyed the idea.

The model kept the nodes and erased the edges.

The meaning had been in the relationships. Once they disappeared, the document still contained my points but no longer said what I meant.

The first use I imagine for an Ideas Graph is discovery. A 2024 short-story experiment shows why I want one: access to AI-generated ideas improved ratings of creativity and writing quality, especially for less creative writers, while also making the stories more similar to one another.

An individual writer may reach farther with AI even as the public conversation contracts around a shared conceptual center. I want the writer to keep reaching; I also want the public square to get much better at finding the edges they add.

Distance from a model’s default tells us only that something is different. At the edge we will find nonsense, lies, empty contrarianism, and insight, sometimes from a model and sometimes from a person. An Ideas Graph might help us notice the difference. People still decide whether it’s coherent, useful, beautiful, or true.

Public conversation is part of that judgment. Readers test a proposed relationship against their own lives, find its limits, and carry it into domains the writer didn’t know. Sometimes the exchange produces a third perspective neither person brought into the room.

I brought the graph to Chris as a possible proxy for care. He named what had broken. Length used to be its own proof of work — somebody had at least spent the attention to write the thing out, even badly. That signal is gone. Effort was never the thing I actually wanted to measure. By the end of our conversation he was calling the proposal “a Pangram for ideas,” and I left with a better idea than the one I brought.

A useful idea doesn’t become less useful because a model introduced it. If I publish it, though, I owe other people more than passing it along: I need to know why I brought it and remain present when they respond.

Pangram can help me understand how a piece may have been made. I would love a second kind of signal, one that helps me find the work I cannot stop turning over because it challenges an assumption, makes a connection I had not seen, or starts a real argument. The Ideas Graph is one way I can imagine building it.

AI can make language effectively infinite, but it cannot give me another life in which to read it.

As a parent, I keep coming back to the same question: am I teaching my children how to spend their attention well? They’re growing up in a world where another answer will always be available. I want them to stay with a hard thought, notice when a reason doesn’t hold, and let another person’s experience change their own. The attention we give one another is part of how we learn what it means to be human.

They will have extraordinary thinking machines beside them, and I hope they use those machines without apology—to notice what they missed, put language around an intuition, or change their minds. Then I hope they bring that clearer thought to other people and leave room for its meaning to change again.

The Odyssey is still alive in part because each generation brings the story into new lives and new arguments. I found my own questions about conflict and home inside it; someone else will bring different ones and make something different of the same story. I hope an article can enter that kind of conversation too.

Related reading

• Beyond AI slop: learning to write (and think) with ChatGPT without losing my voice

• I asked Fable and Codex what my business should automate. They disagreed.

• The chameleon web: 57% of online text may already be AI

• I got tired of AI slop so I built 20 prompts to fix it

• There is too much AI hype: how to defend your brain and stay calm