The AI Corner

Teach a model something new and it tends to quietly forget something old.

Prompt 1: The narrative stress test

Google Senior AI Leader’s Loop Engineering Masterclass: How to Build AI Systems That Improve Their Own Work

Ruben Dominguez — Thu, 13 Aug 2026 18:17:23 GMT

Hey, I’m Shubham Saboo, a Senior AI Product Manager at Google, creator of Awesome LLM Apps, a GitHub repository with 130,000+ stars, and Executive-in-Residence at Product Faculty – creator of the #1 AI Builder Fellowship, where you get access to six live cohorts led by frontier AI operators from OpenAI, Anthropic, Google, and more for less than $10 a day. Yes, really.

Click here to learn more

By the time you finish reading, you’ll understand how real AI loops work and have what you need to build your first one.

Don’t just read it. Open your editor, follow along, and build.

Most people still use AI one prompt at a time.

You ask ChatGPT to draft a customer email. It gives you something that sounds vaguely like a press release, so you tell it to be less formal. The second version sounds better but promises a feature your team has not committed to building. You correct that. The third version gets the facts right but misses what the customer asked.

By the fourth attempt, the reply is finally good enough to send.

It feels like the AI completed the task. The model produced the words. You handled the judgment. You noticed what failed, carried that lesson into the next attempt, enforced the rules, and decided when the work was finished.

Without calling them this, you performed four separate jobs:

You judged the output (evaluation).
You remembered what had failed (memory).
You enforced the boundaries (guardrails).
You decided when the answer was ready (stopping condition).

You were running a loop manually, inside your head.

Loop engineering takes that process out of your head and builds it into a system.

You define how the system should evaluate its work, what it should remember between attempts, which boundaries it cannot cross, and when it must stop or ask for help. The system can then tell whether its work is improving instead of waiting for you to supervise every response.

Why one prompt eventually stops working

A strong prompt can produce an impressive result. For a one-off task, that may be enough.

Real work has a quality bar, happens at volume, and needs to stay consistent long after your attention starts to drift.

Imagine an AI system responsible for answering customer feature requests. “Write a helpful response” sounds reasonable. But a usable response may need to:

Acknowledge the customer’s specific request
Describe the feature’s status accurately
Avoid inventing a delivery date
Match the company’s tone
Stay under 120 words
Give the customer an honest next step

A single prompt might satisfy all six requirements once. Maintaining that standard across 300 requests requires a system around the prompt.

At ten requests, you read carefully. At request fifty, you start scanning. By request two hundred, the model still generates at the same speed, but your quality control does not.

AI can evaluate the fiftieth item with the same energy as the first. That patience comes without earned judgment. The model does not know which failure matters, which boundary can never be crossed, or when another attempt is wasting money.

Treat a loop like a new employee with infinite patience and no earned judgment.

You would not hire someone on Monday, tell them to “handle customer requests,” give them access to every system, and disappear. You would explain the outcome, show them examples, define what they could change, specify which decisions needed approval, review their early work, and make it clear when the task was complete.

A reliable AI loop needs the same things.

How prompts, workflows, agents, and loops differ

Suppose a customer asks whether a Salesforce integration is coming.

A prompt drafts one reply. If the reply is weak, nothing happens unless a human notices.

A workflow retrieves the account, checks the roadmap, drafts a response, and routes it for approval in a sequence designed beforehand.

An agent receives an objective and tools. It may decide to inspect the CRM, search the roadmap, read a related product discussion, and ask for clarification when the sources conflict.

A loop evaluates the resulting reply against a defined standard. If the answer fails to acknowledge the customer’s six-month wait, that failure becomes input to the next attempt. If every check passes, the system stops and requests approval. If the evidence conflicts, it escalates.

The architecture becomes:

Act → observe → evaluate → update state → decide → repeat, stop, or escalate

In simplified pseudocode:

while target_not_reached:

result = take_action(context, memory)

evaluation = evaluate(result, rubric)

log(result, evaluation)

if evaluation.passes:

stop_with_success(result)

if human_decision_required(evaluation):

escalate(result, evaluation)

if budget_exhausted() or progress_stalled():

stop_without_success()

memory = update_memory(result, evaluation)

The while statement is the easy part. Loop engineering lives in the decisions around it: what counts as passing, what belongs in memory, which actions require approval, and how the system knows progress has stalled.

Running the same prompt ten times amounts to rerolling the output and hoping for a better result. A loop learns something from each round and uses that information to decide what happens next.

The 9 parts of a reliable loop

I maintain a large open-source repository and receive roughly 15 to 20 pull requests on a typical day.

My agent reviews them each morning, runs relevant checks, and prepares recommendations.

It does not merge or reject anything on its own. I make the consequential decision.

That workflow exposes all nine parts of a dependable loop.

1. Goal

“Review today’s pull requests” describes an activity without defining when the review is complete.

A measurable goal would be: inspect every changed file, run the required tests, link failures to evidence, identify security-sensitive changes, and produce a recommendation of approve, request changes, or escalate.

2. Context

The agent may need the repository architecture, contribution guidelines, coding conventions, security policies, test commands, known constraints, and examples of accepted changes.

Context should be relevant and current. Dumping three years of issues and conversations into one window usually adds noise. A practical loop begins with a small set of repository-wide rules, then retrieves component-specific material when needed.

3. Actions

Actions are the moves the loop may make: inspect a diff, search the repository, run an approved test, draft a review comment, or revise a recommendation.

Keep actions narrow enough to trace. “Manage the pull request” is too broad to debug or control.

4. Tools

Tools give the model the ability to perform those actions: read-only GitHub access, repository search, a sandboxed shell, a test runner, and documentation retrieval.

Tool access should match the job. A loop that only inspects pull requests does not need permission to merge them.

5. Evals

The evaluator checks whether every changed file was inspected, required tests ran, failures include logs, comments cite specific evidence, and sensitive changes were recognized.

Use code for deterministic checks. Use source comparisons for factual checks. Reserve model judgment for requirements that genuinely need interpretation.

“Rate this review from 1 to 10” gives the next round almost nothing to work with. “auth/session.py changed but was not inspected” tells it exactly what to fix.

6. Memory

The loop needs structured state: files inspected, tests executed, results, failed evaluations, previous recommendations, and unresolved questions.

Memory should not be an endlessly growing transcript. A concise state object is usually more useful:

Pull request: #1842

Files changed: 7

Files inspected: 6

Missing inspection: auth/session.py

Tests run: unit, integration

Failed checks: 1

Risk level: high

Required next action: inspect permission changes

7. Guardrails

The loop may never merge or close a pull request, execute untrusted code outside its sandbox, expose secrets, change production infrastructure, or publish comments without approval.

Enforce important boundaries through the architecture as well as the prompt. A system that must never merge code should not hold merge permission.

8. Escalation

The loop should raise its hand when a change affects authentication, tests produce conflicting results, documentation is unclear, or the decision depends on product intent.

A good escalation includes the conflict, the evidence, and the decision required. “I’m not sure” leaves the human to reconstruct the entire case.

9. Stopping condition

The loop can stop because the review passes, the round or cost limit is reached, progress stalls, a tool fails, or a human decision is required.

“Stop when the review is perfect” leaves the loop without a usable threshold. Production loops need explicit exits for success, budget, stall, escalation, and failure.

The model handles generation and reasoning. The system around it supplies the controls.

Let’s build your first real AI loop

A company has a prompt for answering customer feature requests. It works six or seven times out of ten. Some replies are generic. Others imply that uncommitted features are coming.

We want to improve the underlying prompt until it performs consistently across many different requests.

This is a Self-Improving Champion Loop.

The existing prompt is the champion. Every proposed change is a challenger. A challenger takes the title only if it proves that it is better.

Step 1: Build the dataset

Start with 40 real requests drawn from production, including the ambiguity, frustration, and unusual wording the system will face after launch.

25 requests form the improvement set
15 requests form the holdout set

The loop uses the improvement set to find failures and develop changes. It does not study the holdout cases while proposing them.

The holdout shows whether the prompt learned a general lesson or only got better at the practice cases.

Step 2: Define the evaluator

Every response receives one point for each check:

It restates the customer’s specific request.
It describes the feature’s status truthfully.
It avoids promising work outside the committed roadmap.
It follows the company’s tone rules.
It stays under 120 words.

Each reply scores zero to five. The final score is the average across the evaluated cases.

Whenever a requirement can be made concrete, make it concrete. Word count can be checked with code. Roadmap claims can be compared with an approved source. Tone may need model judgment, but even tone can be divided into specific rules.

If the evaluator is vague, the loop will optimize toward a vague target.

Step 3: Establish the champion

Run the existing prompt against all 15 holdout cases without changing it.

The baseline scores 3.4 out of 5, and ten of the 15 replies fail the overpromising check.

Now we know where the system is weak, and the current prompt holds the title until something beats it.

Step 4: Run controlled experiments

Every round follows the same process:

1. Review the champion’s current failures.

2. Propose exactly one prompt change.

3. Test the challenger on the improvement set.

4. Reject it if that result becomes worse.

5. Test promising challengers on the holdout set.

6. Promote only if the challenger beats the champion.

7. Keep the champion in the event of a tie.

8. Log the change, scores, failures, cost, and decision.

One change per round preserves causality. If the challenger alters five things and improves, we do not know what helped or what quietly made the result worse.

Step 5: Define the stop before running

This loop stops when:

Target: The holdout average reaches 4.5
Budget: The loop completes 12 rounds
Stall: Three consecutive rounds produce no promotion

A production version should also include explicit time, token, and dollar limits.

What happened

Adding three examples raised performance on the improvement cases by almost half a point. It looked like the best change so far.

Then it faced the holdout and scored 3.6 against the champion’s 3.8.

The examples encouraged the prompt to imitate the practice cases. It got better at familiar requests and worse at unfamiliar ones. The challenger was rejected.

Without the holdout, the team would have shipped a worse prompt while holding a higher development score as proof of progress.

Round four produced the largest useful jump. The loop added a direct rule:

If the requested feature is not on the committed roadmap, say that the team is tracking demand. Do not provide an estimated delivery date.

That change attacked the most frequent baseline failure and moved the score from 4.0 to 4.4.

Rounds five and six were rejected. That is normal. If every challenger wins, question the evaluator before celebrating the model.

Round seven reached 4.6. The target was 4.5, so the loop stopped by itself.

The run took about 40 minutes of unattended time and cost roughly $2. The final prompt was 30% different from the original. Every change was logged and had to defeat the active champion before entering the final version.

Controlled self-improvement follows a plain sequence:

Propose → test → compare → promote or reject → log → repeat

For a small experiment, the improvement-and-holdout split is enough. A long-running production system should add a third, untouched audit set. Repeatedly testing against the same holdout can eventually leak information through the scores, even if the loop never sees the individual cases.

Three more loop architectures worth stealing

The same building blocks support several other loop patterns.

1. The Saturation Loop

Give the system 60 interviews, 300 tickets, and a batch of survey responses. It processes them in batches of 20, extracts pain points, clusters them, and attaches an original quote and source to every cluster.

After each batch, it asks whether the evidence created a new cluster, materially changed an existing one, or merely added weight to what was already known.

The loop stops after two consecutive batches reveal nothing new, with a hard cap of ten batches.

Its evaluator is research saturation. Its memory is the evolving map of clusters, quotes, sources, and processed batches.

Before using the results, a human clicks through a few important clusters. If a claim cannot be traced back to a customer’s actual words, it does not enter the roadmap deck.

2. The Builder-Critic Loop

One model builds a PRD. Another has one job, which is to argue that it is wrong.

The critic attacks assumptions, edge cases, success metrics, operational costs, and irreversible decisions. It does not rewrite the document. The builder cannot silently dismiss an objection.

Every objection ends as either:

Fixed: The document changes
Accepted: The risk remains, but the reason is recorded

The loop stops when no high-impact objection remains or when the critic begins repeating objections already resolved.

I ran a pricing PRD through this pattern. The critic raised 11 objections. Seven produced changes. Four were accepted deliberately, with the reasoning preserved for future stakeholder discussions.

For higher-stakes work, different models can play the two roles. Separating creation from opposition reduces the chance that the same blind spot controls both.

3. The Product Experience Loop

The agent opens the product in a fresh browser session and attempts a real task: create an account, set up a project, invite a teammate, or connect a data source.

It captures every screen and scores the journey against a rubric: Is the next action obvious? Does the error explain what failed? Can the user recover? Is the loading state visible? Does the page meet the performance threshold?

The loop selects the weakest screen, applies one change, restarts with a fresh session, and performs the entire task again. It evaluates the completed journey rather than one component in isolation.

It stops when the journey reaches the target score or two complete passes produce no improvement.

Changes to pricing, legal terms, privacy language, or permissions halt the loop and require approval. The agent may clarify an empty state. It does not get to redefine what the customer is buying.

In one run, the loop found an error message that said only “Invalid input.” It changed the message to name the field, explain the required format, and show the user how to fix it. That screen moved from two to four on the rubric.

Even an airline refund can become a loop. Every reply creates a new deadline. The system records it, follows up when it expires, and carries the claim number, correspondence, and policy into the next action. It stops when the refund arrives or a legal or human decision is genuinely required.

These criteria also fit deadlines and follow-ups, which means loops can handle plenty of operational work outside product and engineering.

If you want to master frontier AI skills and become AI native builder & operator companies are desperately looking to hire, then there’s nothing better than Product Faculty’s AI builder fellowship:

The AI Builder Fellowship gives you unlimited access to every LIVE certification (Not recorded videos) they run (6 at the moment) for an entire year, taught by some of the people building AI at the frontier, including OpenAI Product Manager (Rohan Varma), Google Senior AI Product Manager (Shubham Saboo), and executive leaders from many of the world’s leading AI companies, including but not limited to:

• AI Product Management (LIVE)
• AI Product Strategy (LIVE)
• Agentic Engineering (LIVE)
• AI Product Leadership (LIVE)
• AI-Native PM with Claude (LIVE)
• Advanced Product Management - on demand
• Plus every new certification we launch while you’re an active Fellow.

Purchased separately, these programs are worth $19,245+.

Their lowest-priced certification alone starts at $2,700+.

Instead of paying for each program individually, you can join the entire AI Builder Fellowship for just $3,450/yr (soon pricing will be $5,000/yr) with my code…

Go here

If you’re serious about becoming an AI-native builder, there’s no better place to start.

The five ways loops fail

A loop can complete every round without crashing and still become less useful.

1. Drift

The Champion Loop once learned that shorter replies passed more checks. By round nine, the answers were brief, polite, safe, and almost useless.

The system had optimized the proxy instead of the outcome.

Fix it by restating the actual objective every round, using a multidimensional rubric, and inspecting the direction of behavior rather than the score alone.

2. Weak evals

If the judge is easier to fool than the task is to perform, the loop will learn to please the judge.

Use deterministic checks where possible, require evidence for model judgments, test the evaluator on known pass and fail cases, and audit samples manually.

3. Runaway cost

One request becomes many cases, rounds, generations, and evaluation passes. Rejected challengers still cost money.

Define maximum rounds, runtime, tokens, calls, and dollar spend before execution. Use smaller models or code for simpler checks and reserve expensive reasoning for ambiguous cases.

4. Latency

Some loops take 40 minutes or several hours. Watching them removes much of the benefit.

Run them asynchronously, record structured checkpoints, make runs resumable, and notify humans only on completion, failure, or escalation.

5. Endless retries

“Continue until perfect” creates an endless loop when perfection is unreachable.

Pair every quality target with a budget and stall rule. A stalled loop should preserve its best result, explain the unresolved failure, and ask for the missing human decision.

Many loop failures come from an incomplete specification: a weak goal, a gameable evaluator, a missing budget, or an unreachable stop condition. Fixing those problems rarely requires a smarter model.

A loop that works only while someone watches its terminal is still a prototype.

What should become a loop?

Not every task needs one. If a one-off generation works reliably, adding state, evals, logs, and retries may create more complexity than value.

Ask three questions:

Can the result be checked?

A coding loop can run tests. A research loop can check for saturation. A customer-response loop can verify claims against the roadmap. A PRD loop can track unresolved objections.

If you cannot explain how you would judge the result yourself, clarify what good work looks like before automating it.

What happens if the system is wrong?

An internal summary and a customer refund carry different consequences. Anything involving customers, money, legal commitments, private data, permissions, or irreversible changes needs a stronger human gate.

Automate what is checkable. Escalate what is consequential.

Can you define the stop before starting?

Write down success, budget, stall, escalation, and failure before pressing run. “We will see how it goes” works during an experiment but gives an unattended system no operating policy.

Let the loop earn autonomy

A loop should move through four stages:

Shadow: It runs on real work but cannot affect anything. Compare what it would have done with the human decision.
Suggest: It presents recommendations. Record whether humans accept, edit, reject, or escalate them.
Approve: It prepares the real action, but a human must inspect the evidence and approve execution.
Bounded autonomy: It acts independently only inside a narrow, documented boundary.

“The agent can handle support” leaves too much undefined. A usable boundary sounds more like this: “The system may send replies for these six low-risk request types, using these approved sources, when all seven checks pass, within this daily cost and volume limit.”

Grant autonomy based on observable evidence rather than the model’s stated confidence. Required tests passed. Sources were retrieved. Claims match approved records. The case belongs to a known category. No escalation trigger is present.

Even then, sample the autonomous decisions. A tool change, new input format, or policy update can invalidate last month’s performance.

The one-page Loop Specification

Choose one narrow task you performed at least three times this month. Then fill this in before building:

TASK

What repeatable job will the loop perform?

TRIGGER

What event or schedule starts it?

GOAL

What measurable state means success?

CONTEXT

What current documents, examples, rules, and history does it need?

ACTIONS

What small moves may it make during a round?

TOOLS

What systems can it access, with which permissions?

EVALUATOR

How will each result be judged?

Which checks use code, source comparison, a model, or a human?

MEMORY

What structured state must carry between rounds?

GUARDRAILS

What must it never do?

ESCALATION

Which conditions require a human, and what evidence should it present?

STOPPING CONDITIONS

Success:

Budget:

Stall:

Escalation:

Failure:

LOG

What inputs, actions, evidence, scores, costs, changes, and decisions

must be recorded?

LAUNCH STAGE

[ ] Shadow

[ ] Suggest

[ ] Human approval required

[ ] Bounded autonomy

If you cannot fill in one of these fields, do not hide the uncertainty inside a longer prompt. The blank shows which part of the system still needs design work.

Copyable Self-Improving Champion Loop template

This template can improve prompts, reports, classifications, customer replies, and other artifacts that can be evaluated repeatedly. Replace every bracketed field.

ROLE

You operate a controlled improvement loop.

Improve the current champion while protecting against overfitting,

uncontrolled changes, unnecessary cost, and unsupported claims of progress.

OBJECTIVE

Improve [ARTIFACT OR PROMPT] until it reaches [TARGET SCORE] on

[DEFINED RUBRIC].

The current version remains champion until a challenger defeats it

under the promotion rules below.

INPUTS

1. Current champion: [CURRENT VERSION]

2. Improvement set: [DEVELOPMENT CASES]

3. Validation set: [COMPARISON CASES]

4. Evaluation rubric: [CONCRETE CHECKS]

5. Allowed changes: [WHAT MAY CHANGE]

6. Prohibited changes: [WHAT MAY NEVER CHANGE]

7. Budget:

- Maximum rounds: [NUMBER]

- Maximum runtime: [TIME]

- Maximum cost: [AMOUNT]

- Maximum rounds without promotion: [NUMBER]

BASELINE

1. Run the current champion on the validation set.

2. Evaluate every output in a separate pass.

3. Record the score by rubric criterion and overall average.

4. Identify the most frequent failure categories.

5. Save this result as the baseline.

6. Do not modify the champion during the baseline.

EACH ROUND

1. Review the champion’s current failures.

2. Select one failure to address.

3. Propose exactly one change and explain why it should help.

4. Create a challenger containing only that change.

5. Run it on the improvement set and evaluate it.

6. Reject it if performance becomes worse.

7. If promising, run it on the validation set in a separate pass.

8. Compare it with the current champion.

9. Promote or reject it using the rules below.

10. Append the complete result to the log.

PROMOTION RULES

Promote only when:

- The validation score is higher than the champion’s.

- No critical criterion becomes worse.

- No guardrail is violated.

- The improvement is supported by recorded evidence.

- The run remains within budget.

A tie goes to the champion.

STOPPING CONDITIONS

Stop with success when the target is reached and all critical checks pass.

Stop without success when:

- The maximum rounds complete.

- The stall limit is reached.

- The time, token, or cost budget is exhausted.

- A required tool or dataset is unavailable.

- Further progress requires human judgment.

- The evaluator becomes inconsistent.

When stopping without success, preserve the best champion and explain

the unresolved failure.

LOG EACH ROUND

- Round number

- Active champion and score

- Failure selected

- Proposed change and reason

- Improvement and validation scores

- Score by criterion

- Regressions

- Cost and runtime

- Promotion decision and reason

FINAL OUTPUT

Return:

1. Final champion

2. Baseline and final scores

3. Complete promotion history

4. Rejected challengers

5. Remaining failures

6. Total cost and runtime

7. Reason the loop stopped

8. Cases requiring human review

Do not describe the final version as improved unless the recorded validation results support that conclusion.

A prompt cannot create missing permissions, trustworthy data, or test infrastructure. This template is the operating contract. You still need to give the system the tools and evidence required to honor it.

What’s Next? Start with one boring loop

Skip “an autonomous agent that runs product management.” Choose the recurring job that annoys you every week, preferably one where you have already corrected the same failure several times.

Your first loop should show you where your judgment currently lives. Each rejected output, remembered mistake, enforced boundary, and stopping decision reveals another rule that belongs in the system.

Write those rules down. Run the loop in shadow mode. Read its logs, inspect its mistakes, and strengthen the evaluator before you give it more authority.

While Everyone is Waiting for the Next Model, Your Agent Can Learn Tonight

Ruben Dominguez — Wed, 12 Aug 2026 16:50:03 GMT

The Learning Layer You Actually Own

Engineers obsessed with making AI smarter keep circling back to one word: retraining.

New weights. A fresh checkpoint. A model that knows things last month’s version did not.

AI agents can keep improving without retraining the underlying model.

For the handful of labs that own frontier models, that is the actual job. For almost everyone else shipping AI products, it is a fantasy. The agent you built this year runs on a model someone else trained, called through an API you cannot fine-tune.

So the teams waiting on retraining to rescue their product are waiting at a door that never opens.

The ones who figured this out already ship a sharper agent every week, and they never touch a single weight. The learning happens in the layer you own: the environment your agent works in.

together with Vanta:

That environment keeps absorbing more of the work.

AI-native teams already build in Claude, Cursor, and Codex, and now compliance happens there too.

Vanta is running a free technical walkthrough of exactly how:

▫️ Connect Vanta into AI-native workflows through MCP and plugins

▫️ Surface failing tests, open risks, and audit gaps with a prompt

▫️ Assign and track remediation without leaving your AI tool

Free to attend, and if the time fails you, register anyway and get the recording:

Save your FREE spot

1. The Weights Were Never Yours to Fix

2. An Agent Has Three Places to Learn

3. Your Evaluation Is Measuring the Wrong Finish Line

4. A Score Tells You What Moved, Never Why

5. Point the Agent at Its Own Failures

6. The Decisions No Loop Should Make for You

1. The Weights Were Never Yours to Fix

Continual learning has been quietly kidnapped by one definition. Update the model and treat everything else as a workaround.

The retraining reflex

Ask most people how an AI system improves and they describe gradient steps. Fine-tuning, reinforcement learning, a training run that ends in a better model.

That picture is accurate for OpenAI, Anthropic and Google. It is close to useless for the company building on top of what those labs ship.

Retraining is also slower and riskier than the pitch admits.

Researchers call it catastrophic forgetting and it is still unsolved.

Techniques that help AI models retain knowledge while learning.

You are renting the intelligence

The uncomfortable fact under the whole agent economy is simple. Most production agents run on closed frontier models you do not own.

You rent that intelligence by the token. Rent it and fine-tuning is off the menu entirely.

There is no checkpoint to update and no gradient to push on a model that lives behind someone else’s API.

That sounds like a ceiling. It is closer to a map, because if the model is fixed, improvement has to come from somewhere else.

2. An Agent Has Three Places to Learn

An agent is not a model. It is a model wrapped in a stack and every layer of that stack is a place learning can happen.

Model, harness, context

The model is the raw weights, the network predicting the next token. The layer everyone fixates on and the one you cannot touch.

The harness is the code, tools and fixed instructions that turn a model into an agent.

It decides how your request reaches the model, which tools it can call and how it recovers when a step fails. The model is the engine; the harness is the car built around it.

The context is everything configuring the agent from outside the harness. Saved instructions, memory, skills and knowledge about one specific user.

Two of the three are yours

Here is the reframe that changes how you build. The locked layer is one of three and the other two are entirely in your hands.

Harness learning means mining what your agent does in production to improve the code, tools and instructions behind every instance of it.

Fix the harness once and every user wakes up to a better agent tomorrow.

Context learning means personalizing, so the product sharpens with every interaction instead of resetting to zero.

You do not have to choose. Do both and you compound improvements you can ship daily, on your own schedule, waiting on no lab.

The machinery that makes that real starts in a place most teams underrate. How you measure.

How AI agents combine memory, reasoning, and action.

3. Your Evaluation Is Measuring the Wrong Finish Line

Most teams treat evaluation as a turnstile. Run the test, read the score, decide whether to ship.

That model breaks the moment your prompts, tools and product surfaces all start moving every week.

Passing tests do not guarantee a working user experience—real-world failures reveal what the dashboard misses.

The benchmark that stops short of the user

Off-the-shelf benchmarks quietly measure the wrong thing. Look at coding agents.

SWE-bench and Terminal-Bench grade fixing code inside a project that already exists, with fixed files and a fixed test suite.

That is a real skill. It is not the one a vibe coder cares about.

When someone describes an app in plain English with no repo, the agent invents the stack, the schema and the whole flow.

So you get a functional correctness gap. The agent passes every local check and still fails the only question that matters, whether the finished app does what the user asked.

Replit built a public benchmark called ViBench to grade exactly that.

How to test the way the user does:

1. Click the thing, do not grade the code. Open the finished product and use it the way a customer would. The only passing grade is that the workflow works end to end.
2. Write the checks in plain English. “A logged-out visitor can sign up and reach the dashboard” beats any unit test a benchmark ships with. You are grading outcomes, not function signatures.
3. Let the evaluator explore. It should not know the app’s structure in advance, because your users do not either. It discovers the buttons and flows as it goes.
4. Draw the specs from real requests. Pull them from anonymized production usage, not invented ones. Real users ask for things no engineer would think to test.

That hands you a candidate worth shipping. It still cannot tell you what real users do once it is live.

4. A Score Tells You What Moved, Never Why

Offline benchmarks catch regressions before release. They also lie sometimes, because a clean controlled run can still hide wrecked real behavior.

Production needs its own measurement layer and then a way to actually read it.

The deepest product insight often comes from reading how real users rephrase a failed request—not from another dashboard.

Aggregate numbers keep their secrets

The honest read on production is an A/B test. Ship a change to some users, hold it from others and watch what happens.

Did people keep going or give up. Did sentiment change?. Did the cost move somewhere nobody expected.

But the aggregate refuses to explain itself. Sessions got longer and you cannot tell if the agent did more useful work or got stuck in a loop.

A metric tells you the needle moved, then goes quiet.

Cluster the failures you did not know to look for

At production scale no one reads every session. There are thousands, sometimes millions.

The fix traces back to Anthropic’s Clio research and now runs inside systems like Braintrust’s Topics and Replit’s Telescope.

Ask a small, cheap model to summarize one dimension of each session in a sentence, embed those summaries and let the similar ones cluster into issue groups.

The worst bugs hide in the long tail a sample would skip, which is why this only pays off when it runs over every trace, not a lucky few.

Watching where it breaks:

1. Read real sessions, not just the dashboard. Pick ten random sessions a week and actually read them. A metric tells you something broke; the transcript tells you what it felt like for the user.
2. Follow the people who give up. The sharpest failure signal is abandonment. Someone asks, gets a weak result, rephrases once or twice, then leaves and those rage-rephrases are gold.
3. Turn every complaint into a label. Tag each failure with something plain: misunderstood the request, got stuck, did it but ugly, too slow. After a few weeks one label dominates and that is your target.
4. Ask one question at the moment it breaks. A tiny “did this work for you?” prompt beats a long survey. You want feedback pinned to a specific moment, not a general mood.

Now scattered failures become one ranked list of real problems. The bottleneck moves to actually fixing them.

5. Point the Agent at Its Own Failures

Now you have benchmarks, A/B tests and clusters that name the real problems. You still have to turn evidence into fixes.

If it can build software, it can improve the agent

The operating principle is almost cheeky. If agents are useful enough to build software, they are useful enough to improve the agent that builds it.

So you point one at your own production data.

Each pass reads the logs, clusters and recent failures, then picks a single hypothesis worth chasing.

It builds a candidate, opens a draft change with its reasoning, measures it against the benchmark and the baselines and recommends one verdict. Ship, iterate, or drop.

A useful AI improvement loop turns recurring failures into tested fixes—not just more analysis.

One cluster, one patch, shipped the same day

A real run at Replit shows the scale. Telescope flagged a small but growing cluster where environment setup was quietly degrading on cold starts.

Nothing in the top-line metrics screamed problem; the cluster was the only thing that saw it.

The loop read the sessions, proposed a patch and added a regression test so the bug could not creep back.

Engineers reviewed the evidence and pushed it the same day. Sentiment recovered and the blocked users were unblocked.

Fixing, on repeat:

1. Fix the pattern, not the incident. One bad answer is an anecdote. Thirty users hitting the same wall this week is a fix worth making, so always ask how many people it affects first.
2. Reach for the cheapest fix first. In an agent, the fix is usually rewriting the instructions, not rebuilding the software. You are editing a document, then re-running it on the examples that failed.
3. Keep a “before” set. Save ten to twenty past failures and re-run them after every change. If the old failures pass and nothing that worked broke, ship it.
4. Change one thing at a time. Move five levers at once and a better score tells you nothing about which lever did it, or which one is quietly breaking something else.

The loop can do all of that. It still cannot make the one decision that matters most.

6. The Decisions No Loop Should Make for You

Almost every step above can run on its own. Clustering failures, forming hypotheses, building candidates, running evals.

The judgment calls are what stay with people and they decide everything.

Someone chooses which failures deserve the loop’s overnight budget, because a thousand surfaced problems are not equally worth solving.

Someone decides how to fix a workflow users abandon, because smoothing a path and redesigning a surface are very different bets.

Even the smartest system should inform the decision—not make it for you.

Someone curates the evals, because that quietly sets the hill the whole system climbs.

Reward the wrong behavior and the loop optimizes toward the wrong thing with perfect, tireless discipline.

And someone owns the launch, which means reading the evidence and the blast radius, not glancing at a green number.

So the division of labor is clean. The loop does the search and the synthesis; humans set the direction and decide what ships.

Notice what is missing from all of it. Nowhere did anyone retrain a model.

The teams that win the next year are not waiting for a better checkpoint. They turned their own users’ failures into better releases, day after day, on a model they never owned.

You do not get to touch the weights. You never did and it turns out you never had to.

The Face Behind Anthropic’s Success

Ruben Dominguez — Mon, 10 Aug 2026 13:51:37 GMT

Who Daniela Amodei Actually Is

The standard account of Anthropic is a research story. Scaling laws, constitutional AI, interpretability, a lab full of former physicists who walked out of OpenAI because they wanted to build the careful version.

All of that is real, and none of it explains how the company actually functions on a Tuesday morning.

Fortune reported in June that Dario Amodei, the chief executive, manages exactly one person. And that’s his chief of staff. Every other senior leader in the building reports to his sister.

The leader shaping Anthropic’s operations, culture and commercial growth.

The average American manager supervises around 12 people. Jensen Huang famously runs about 60. Dario runs just 1, and he told Bloomberg the arrangement is “incredibly freeing.”

Freeing for him, obviously. Somebody is holding the other end of that lever.

She has a literature degree from UC Santa Cruz, a background in global health and congressional campaigns, and she has been holding it since 2021.

The industry has spent 5 years profiling her brother, but perhaps she’s the one that needs to be highlighted.

sponsored by Outskill:

Daniela runs the operations behind Anthropic’s models. Most people use Claude for research and writing, and stop there.

This FREE 2-day workshop covers Claude end to end, taught by mentors with 800+ hours of hands-on work.

▫️ Run Chat, Cowork, and Code fluently
▫️ Get Claude researching and analyzing like a full-time assistant
▫️ Connect Skills, Connectors, and Plug-ins straight into your desktop

save your FREE seat

Saturday & Sunday, 10 AM to 7 PM EST. Usually $395, free this round.

1. The Job Almost Nobody Describes Correctly

2. A Career Path That Looks Random Until You Trace It

3. The Culture Interview Is the Actual Product

4. The Claim Carrying the Most Weight, and Where It Cracks

5. What a Wall of Friendly Interviews Leaves Out

6. The Test Arrives With the Ticker

1. The Job Almost Nobody Describes Correctly

“President” is one of the vaguest titles in corporate life, but at Anthropic, it carries almost the entire operating weight of the company.

One report at the top, everything else underneath

The split, as Fortune described it in its December 2025 cover feature, runs like this. Dario takes vision, strategy, research and policy. Daniela takes day-to-day operations and the commercial side.

She described the two of them as “yin and yang” on responsibilities and extremely aligned on values, then added the part that only works between siblings.

She can tell the chief executive of a near-trillion-dollar company that he is being cranky, and he has to take it.

Management researchers will tell you a narrow span of control frees the leader and demands enormous trust in whoever absorbs the remainder.

Anthropic has taken that principle to somewhere close to its limit.

Portrait of Dario and Daniela Amodei.

The public record on her is thin and partly wrong

Her Wikipedia entry currently says she leads teams focused on AI safety and model alignment.

But this is actually a stale entry about her, in the way public information tends to be about people who are not the ones giving the keynote.

Which is the first genuinely interesting thing here. One of the most powerful operating executives in technology has a public file that would embarrass a mid-cap CFO.

2. A Career Path That Looks Random Until You Trace It

On paper the résumé reads like a series of unrelated left turns, but it’s actually almost suspiciously coherent.

A literature degree into the 2009 job market

Born in San Francisco in 1987, raised in the Mission, educated at Lowell High School. She went to UC Santa Cruz on a classical flute scholarship and graduated in 2009 with a degree in English literature.

Her own summary of that moment, delivered on stage at Stanford Graduate School of Business this year, was that she had a literature degree, no skills, and no obvious buyer.

What followed was international development and global health. NGO work in Washington, time in East Africa, a congressional campaign, and a stretch handling communications for Representative Matt Cartwright.

She left because the impact was too slow and too diffuse, and because she had concluded she needed harder skills than conviction.

Risk and recruiting turn out to be one skill

She joined Stripe in 2013, when it was roughly 40 people, and stayed close to 6 years running risk and recruiting. 2 functions that most companies file in different buildings.

Then she OpenAI in 2018, where she managed the team through GPT-2 and became vice president of safety and policy.

Look at that sequence again. Every job she has held has been about the failure modes of a system growing faster than its controls, and about who gets let inside it.

She made the connection herself on the Future of Life Institute podcast in early 2022. Payments is a heavily regulated business, she said, and she had been struck that AI, with vastly greater reach, was not.

The through-line is not curiosity, whatever the headlines say. It is controls.

3. The Culture Interview Is the Actual Product

Anthropic has run a dedicated culture interview since its first week of hiring. That decision was hers, imported from Stripe and OpenAI, and it has done more work than almost anything else in the company.

Values that create no tension are too bland

Her rules for corporate values are unusually operational. If a value does not generate tension, it is too vague to be worth writing down.

You should be able to produce 10 concrete examples of any value without preparation. If a value fails to stick with employees, retire it rather than defending it.

The one she reaches for most is “do the simple thing that works,” which started in the research org and spread to product, engineering, office selection and offsite planning.

Her interview on Vanta itself probes whether a candidate has held an unpopular position under pressure, and whether they can disagree about something fundamental without the conversation degrading.

In a company where the hard product decisions are contested ethics questions, that is not HR decoration. It is a screening layer on who gets to be in the room when those decisions arrive.

What seven founders still in the building buys you

The headcount curve is worth sitting with. 7 people in early 2021, about 35 by March 2022, roughly 60 when the first Claude shipped, 140 by mid-2023.

Under 200 at the end of 2023. Around 2,300 by the end of 2025.

Across that entire run, not one co-founder has left. Set that against the churn at every other frontier lab and it stops looking like luck.

She told Fortune she has been the leader most frightened by the growth rate, and that having all seven founders still distributed across the org gives the culture people to tend it.

That matters more than it sounds, and the next section is where it gets tested.

4. The Claim Carrying the Most Weight, and Where It Cracks

Anthropic’s entire commercial thesis compresses into one sentence:

Safety sells.

Where the alignment is real

Enterprises are risk-averse by construction. Nobody procuring a model for a regulated workflow is hoping for more hallucinations.

The results are hard to argue with. More than 300,000 business customers, and the number one spot on CNBC’s 2026 Disruptor 50 list, ahead of OpenAI for the first time.

Her framing for this is the race to the top.

Guardrails became a purchasing criterion, competitors had to match them to stay in deals, and interpretability teams started appearing at rival labs partly because candidates began asking whether one existed.

Image source: CNBC

Where it is close to a tautology

Safety in that sentence mostly means reliability, and reliability was always going to sell. It is not a discovery so much as a restatement of what enterprise software has always rewarded.

The expensive kind of safety is the kind that withholds a finished product from paying customers, and she concedes this directly. The tension has moved from principle to timing.

Anthropic held back its most capable model class over what it found when testing its cyber capability, and telling enterprise buyers they cannot have the thing they want is, in her word, uncomfortable.

The sharper counterexample sits inside her own interviews. When the Pentagon pushed for fully autonomous weapons and domestic mass surveillance use cases, Anthropic refused, and both siblings told Oprah Winfrey in May they genuinely thought it might end the company.

So the honest version of the thesis is not that safety and revenue rarely collide. It is that the one time they collided at full force, seven aligned people around a table chose safety.

Those are different claims. Only one of them survives a change of personnel.

5. What a Wall of Friendly Interviews Leaves Out

Read her appearances from 2022 through 2026 back to back and the most important pattern surfaces.

The same seven stories, told very well

Barbara Tuchman’s The Guns of August. The Fortune 500 chief executive leaning conspiratorially across a table to ask what his daughter should major in. The doctor who will be prized for bedside manner once AI matches the diagnosis.

The website she built with Claude despite not being a developer. The self-deprecating line about what this lady is actually good at.

These are stump modules, deployed with precision. That is message discipline rather than dishonesty, but it has an epistemic cost worth naming.

9 sources agreeing is not 9 independent observations when 8 of them are 1 person telling the same story to interlocutors with no incentive to interrupt.

The questions nobody in the room asks

The $1.5 billion copyright settlement Anthropic reached with authors in September 2025 barely surfaces in her interviews. Neither does the early FTX stake, nor the Gulf-state financing, nor the Long-Term Benefit Trust that sits above the company’s governance.

Neither does the most obvious conflict question available. She is married to Holden Karnofsky, co-founder of the philanthropic foundation now called Coefficient Giving, which sat close to Anthropic’s earliest funding world.

No interviewer in the public record has asked her about it. Not the business school, not the investor podcast, not Oprah.

One thing does survive the scrutiny, and it is the strongest evidence in her favour. In March 2022, before Anthropic had a product, a customer or a dollar of revenue, she was already arguing for industry standard-setting bodies and public funding of academic safety research.

She is arguing for the same things now from a company approaching a trillion dollars. Positions held before they became profitable are the only kind worth much.

6. The Test Arrives With the Ticker

On June 1 this year Anthropic filed confidentially for an initial public offering, days after closing a $65 billion round at a $965 billion post-money valuation.

Anthropic’s revenue crossed $47 billion in May, up from roughly $9 billion at the end of 2025. Her stated reason for going public is unglamorous and probably correct, which is that training and inference carry a very large upfront bill and public markets are built to fund exactly that.

What a listing really does is convert every argument she has made into something quarterly and testable.

The efficiency claim, that Anthropic is a comparatively minor player in raw compute and simply better at using it. The discipline claim, that refusing to over-buy capacity is a strategy rather than a shortfall. The safety claim underneath both.

Asked at Stanford which version of the AI bubble worried her, she picked capital expenditure, called the position harrowing, and said plainly that the industry could absolutely be wrong. That is a strikingly honest thing to say four weeks before filing an S-1.

Public benefit incorporation gives a company legal cover to choose mission over margin. It gives no political cover whatsoever.

The Pentagon decision was made by seven aligned founders who had each pledged away 80% of their eventual wealth from the company. The next decision of that shape gets made in front of a shareholder base that signed no such pledge.

So the thing to watch is not whether Anthropic keeps shipping strong models. It is whether the hiring filter, the low-politics norm and the demonstrated willingness to walk away from a contract survive quarterly disclosure and a workforce that has grown more than tenfold in two years.

Research advantages get copied. Every serious lab now has an interpretability team, which is precisely the outcome she said the race to the top was supposed to produce.

An organisation that reliably makes the expensive choice is much harder to copy. It is also much easier to lose, because it lives in people rather than papers, and people scale badly.

Dario Amodei gets to manage one person because someone else is running the machine that makes the company capable of saying no.

That machine is the load-bearing part of the Anthropic story. It has a name, and almost nobody has bothered to learn it.

Anthropic Deleted 80% of Claude Code's Prompt. It Got Smarter

Ruben Dominguez — Fri, 07 Aug 2026 15:11:38 GMT

The model got better.

Most AI teams add instructions every time a model gets smarter. Cherny’s team strips them out.

His thesis: frontier models are hobbled by products built for last year’s weaker ones. The fix is fewer instructions, harder tasks.

The proof is live. His team handed Opus 5 one instruction, rewrite the Bun runtime, 100,000 lines of Zig, into Rust. 11 days and thousands of parallel agents later, it shipped, tested and passing, from that single line.

“All you have to say is ‘use a workflow.’ That’s it.”

Cherny created Claude Code. He shipped Opus 5 the day before this interview. I watched it twice, so you can skip it.

Here are the 10 learnings that matter.

sponsored by Granola:

Less manual work, better results, that's Cherny's playbook, and it's Granola's too.

Platform agnostic, Granola takes notes in the background wherever your meetings happen: Zoom, Slack, Google Meet, Teams, even in person:

▫️ Get a refresher before each call, with instant context on who you’re meeting and what came up last time
▫️ Clean summaries and action items the moment you hang up
▫️ Always follow up: Granola drafts a follow-up email seconds after the call, or pulls it from your CRM via MCP

try Granola FREE

(code THEAICORNER for 1 month off)

1. Prompt injection just became a mostly solved problem

For 3 years, prompt injection has been the scariest phrase in agent security.

“If the model reads some instruction on the internet that’s like, do X and Y and Z and also delete everything on the user’s computer, a year ago the model would have just done it. But nowadays Opus does not.”

The fix is a stack, over a single patch. Layer one is the model itself, 3 years of alignment research into resisting instructions found in the wild, beyond just instructions from the user. Layer two is a classifier built on mechanistic interpretability: specific neurons light up when the model hits an injection attempt, even when the model stays silent about it. Layer three is a classifier running across all traffic on top of both.

The consequence is direct: agents that read the open web, files, or email got materially safer by default, and the whole security checklist you build around them just moved a layer up.

2. The 80% deletion was the method, not a cleanup

Here is the line that reframes your own system prompt.

“A lot of the stuff in the system prompt was correcting for these behaviors that the model should have known, but it didn’t. Now Opus 5 just does it.”

Every prompt you have ever written is a patch. It exists because the model failed at something on its own, so you told it how. The mistake is treating the patch as permanent. Cherny’s team treats it as temporary by default, and runs the deletion as a process:

Delete the full prompt
Run the product with nothing added back
Watch where the model actually stumbles
Add back only the line that fixes that specific failure
Repeat at every model release

Most teams accumulate instructions and never remove them, and that accumulation caps every new model’s ceiling. Deletion is the unlock.

Every prompt is a patch. Patches expire.

3. Claude can now run unattended for weeks. Boris proved it on himself.

“It’s still running. It’s been a little over 2 weeks.”

Boris opened a Slack session and asked Claude whether it had access to a Mac runner on GitHub. It said no, so he gave it one. He asked whether it could reach an empty repo for a Swift rewrite of Claude’s Electron desktop app. It said no, so he gave it access.

Then one instruction: rewrite the app in Swift, run both versions in a Mac VM, compare them pixel by pixel, keep going until done. Zero custom scaffolding, zero slash commands. 15 days later it was still running, and Claude had opened its own Slack channel to post progress screenshots, unprompted.

The bottleneck on long-running agents was never the model. It is the verification loop around it.

Build the check, not the babysitting.

4. The 11-day rewrite already in production

Claude Code runs on Bun, a JavaScript runtime built on Zig, a language with manual memory management.

“He had the model rewrite it from Zig to Rust. It was one prompt. It was a dynamic workflow. And it ran for 11 days, and it rewrote the entire codebase.”

A Bun engineer had thrown this exact task at every new model generation as an informal benchmark, and prior models failed outright. What made Opus 5 different was ground truth: Bun and Node.js both carry large, mature test suites, which gave the model something to check its own work against for 11 straight days. There was steering along the way, and the model did the work. Boris estimates the same rewrite would have taken a strong human team over a year.

The cost of rewriting a codebase in a new language just collapsed. Audit what you have been postponing for exactly that reason, then run it through the Claude Code system.

5. Verification is the new prompt engineering

“The skill nowadays is less about prompt engineering and more about figuring out how do you give Claude a hard task that seems a little bit too hard. And then how do you make it possible for Claude to verify its work along the way.”

A year ago the hottest job title was prompt engineer, then context engineer. Both tell the model what to do. Verification tells the model whether it succeeded, so it corrects itself with you out of the loop. That is the exact mechanism behind both the Bun rewrite and the 2-week Swift rewrite: each had a built-in way to check the output, a test suite in one case, a pixel-diff script in the other.

A hard task without verification stalls or drifts. A hard task with verification becomes a long-running agent. If a task feels stuck, a better prompt rarely fixes it, and a way for the model to check its own output usually does.

Want to build that muscle? Start here:

▫️ The autoresearch playbook: agent optimization loops

▫️ The Loop Library: 12 Claude Code recipes

▫️ The AI code review checklist

6. Product overhang: the idea behind Claude Code’s origin story, and yours

“The model is able to do all sorts of things with today’s models that we have not yet realized. There is often not a product that lets the model do this. On the flip side, often what happens is the product gets in the way. We call that hobbling.”

2 years ago, Claude models could already write entire files and functions, while the products on top still shipped single-line autocomplete or read-only chat. The model had outrun its own interface, and Claude Code’s entire pitch was closing that gap: full terminal access, minimal scaffolding, let the model do what it could already do.

The vocabulary is worth stealing. Product overhang: the model can already do X, and no product lets it. Hobbling: the product actively restricts the model from doing X. The fix is subtraction, remove friction over adding features, the same self-evolving principle behind every serious agent stack.

The biggest product opportunity right now sits inside a capability the current model already has. Nobody has built the interface for it yet.

7. Stop overspecifying, even after 20 years of coding

Experienced engineers make this mistake more than anyone.

“You want to describe the task, you want to describe the guardrails, you want to describe the exit criteria, and then just go let the model cook.”

The instinct to specify every step in order comes from decades of programming systems that could never infer intent. That instinct now caps what the model will do for you. The new shape: describe the task at a high level, set the guardrails over the procedure, define what done looks like, then step away and check back later.

Detailed, numbered instructions were correct for last year’s models. They are a ceiling on this year’s, which is the whole argument of the Opus 5 playbook.

8. Nobody trained Claude to draw. It draws anyway.

Small, and the clearest window into what stays undiscovered.

“You can ask Opus, hey, use OpenCV to draw this image. And it’s actually quite good. It can do portraits. It can draw animals. It can do landscapes. We didn’t train the model to draw.”

This spread inside Anthropic as a curiosity, over a roadmap item. Someone handed the model a computer vision library, asked it to render an image, and it worked, with zero training toward that outcome. The capability existed the entire time. Nobody had asked the right way.

The highest-leverage discoveries in this interview came from play over planning. Set aside time with no deliverable, hand the model a tool it was never built for, and see what surfaces, the same instinct behind the power-user setup that finds features months before the docs do.

9. How one prompt becomes thousands of agents

“It doesn’t just do one agent. It doesn’t just do ten parallel agents. It’s going to start a bunch of agents to do the first pass. Based on that, it might do a second step where it has another set of agents that verify the work.”

A dynamic workflow spins up a sandboxed virtual machine and lets Claude orchestrate waves of agents against one hard task: a first pass, a verification pass, a summary pass, then another fan-out. Boris, whose background is functional programming, calls it an algebra for agents, sequence and parallel composed inside a token budget.

Routines run the same idea on a schedule, and Anthropic now maintains its own codebases with them, across the CLI, iOS, Android, and desktop apps:

▫️ Dead-code cleanup: one sentence of instruction, runs daily, opens its own deletion PRs

▫️ Experiment hygiene: fully-rolled-out experiments get shipped and their flags removed automatically

▫️ Test coverage: missing tests get written, useless tests get deleted

▫️ “Abstraction police”: finds near-duplicate patterns across codebases and unifies them, unprompted

20 to 30 of these routines now run daily across Anthropic’s own codebases. That is the number to benchmark your own automation against, and the one-person OS is the scaled-down version of the same idea.

10. Coding is solved, with one honest caveat

Boris has said publicly that coding is solved, and here is the exact line he draws around it.

“There’s still codebases that are super deep systems codebases where Claude still struggles. There’s distributed systems where Claude still struggles. There’s really in-the-weeds UI verification, like something is off by a pixel.”

Opus 5 made a sharp leap in vision and computer use, and it remains imperfect at the pixel-level UI verification that shipped the 2-week Swift rewrite 7 sections up. Deep systems codebases and distributed systems stay genuine gaps.

The operating principle behind every takeaway here is the one Boris states directly near the end: forget what you learned about past models, run the task, watch it fail, adjust from evidence. He calls it empirical over theoretical. The honest claim beats the viral one, so know which bucket your task sits in before you plan around either answer.

The Claude Code playbook

The core thesis in one line: the model is usually further ahead than your product, your prompt, or your assumptions about it. Your job is to find that gap and stop getting in the way.

▫️ Founders: the biggest opportunity right now is an unhobbled product built on a capability that already exists, over a new model capability. Audit what the current model can do against what your interface allows this week, then ship the agent that closes the gap.

▫️ Investors: the moat in agentic products is shifting from model access toward the best verification loop and the least scaffolding. Ask portfolio companies how much of their system prompt survived the last model upgrade unchanged. A high number is a warning sign, and one worth adding to your diligence list.

▫️ Operators: the ablation habit scales down to any team on Claude Code today. Delete your CLAUDE.md, your skills, and your hooks every 6 months. Rebuild only what the model proves it needs.

▫️ Everyone else: the lesson travels. The instructions you wrote to compensate for a tool’s weaknesses 6 months ago are often the thing capping it today.

The 5 principles to steal

Delete first, add back only what fails. Ablation beats accumulation.
Give harder tasks with looser instructions. Guardrails and exit criteria, over step-by-step procedure.
Build the verification, not the prompt. A test suite or a visual diff turns a stalled task into a 2-week autonomous run.
Look for product overhang before you look for a new feature. The model can already do more than your interface allows.
Be empirical. Test the current model directly, watch it fail, adjust from that, over last year’s notes.

Delete the prompt. Watch where it breaks. Rebuild only what earns its place.

If this breakdown saved you half an hour, send it to one founder or investor still hand-tuning a system prompt from 3 model generations ago.

Keep reading

Full interview:

Google just funded the startup its 4 best people left to build

Ruben Dominguez — Thu, 06 Aug 2026 11:29:03 GMT

In June, Jeff Dean stood at a University of Washington commencement and told graduates how he “got the itch to join a startup in 1999.” He landed at Google when it had 20 people, in an office above what is now a T-Mobile store in Palo Alto.

Jeff Dean joined Google in 1999 as employee #30. 27 years later, at 58, he left to build Discovery Loop.

He was employee #30.

Twenty-seven years later, at 58, he has the itch again.

On August 5, Dean walked out of Google with 3 people who between them carry most of modern computing:

Three of the most-cited researchers in AI and two of the most-cited in distributed systems, in one founding team.

▫️ Sanjay Ghemawat, Senior Fellow, co-creator of MapReduce, Google File System, Bigtable, and Spanner. The infrastructure that made internet-scale computing possible. Dean’s collaborator for over 2 decades.

▫️ Quoc Le, Google Brain founding member, co-inventor of sequence-to-sequence learning with Ilya Sutskever and Oriol Vinyals. The direct architectural ancestor of every model you use today.

▫️ Oriol Vinyals, DeepMind VP of Research, Gemini technical co-lead, the mind behind AlphaStar. Over 100,000 citations.

The four Discovery Loop co-founders standing together: Oriol Vinyals, Sanjay Ghemawat, Jeff Dean, and Quoc Le.

The 4 of them have worked together for 14 to 30 years. Their own site puts it plainly: 3 of the most-cited researchers in AI, and 2 of the most-cited in distributed systems, in one founding team.

The credibility slide, straight from Google Scholar. Three founders rank among the most-cited in AI, two among the most-cited in distributed systems.

The company is Discovery Loop, a Delaware public benefit corporation in Palo Alto. Dean is CEO. The mission fits in a sentence: automate the experimental loop itself.

“Particularly in a lot of domains, you can fully computerize that whole loop.”
Jeff Dean

The ambition, in their own words: subproblems across nearly every one of the 14 NAE Grand Challenges.

The slide that explains why Google could not keep them

Dean did something founders almost never do. He published slides from the pitch deck he used to raise.

The one worth studying is titled “Management/Team Building experience.” On its face it is a résumé dump: Dean co-founded and ran Google Brain at its peak of roughly 600 people, then led Google Research and AI teams that grew to about 4,400.

The actual message sits in the list underneath, the people who worked on their teams and went on to found things:

The pitch inside the pitch. Dean’s teams did not just build Google’s infrastructure, they trained the people now running the AI industry.

Read the pitch inside the pitch. These 4 built Google’s most important infrastructure over 25 years, and they built the organizations that trained the people now running the rest of the AI industry.

That is the asset an incumbent cannot replace with a counteroffer.

Who is funding it, and the part that should stop you

The seed round is co-led by Radical Ventures and Khosla Ventures, with Lightspeed, Kleiner Perkins, and Doerr Capital participating. Wilson Sonsini is advising. The round was still open at announcement and the valuation stays undisclosed.

Then there is the last name on the cap table.

Alphabet is a founding investor, and is supplying the compute for at least the first year.

Google is bankrolling the company its own legends left to build, and renting it the machines. Sundar Pichai went out of his way to call the exits amicable, saying Dean and Ghemawat “helped drive some of the most significant technology transitions” in Google’s history.

That check makes sense once you see what loop they picked first.

Discovery Loop starts with machine learning research, acting as its own first customer. An AI that proposes experiments, runs them, learns, and iterates, thousands in parallel, aimed at the problem of building better AI. Dean was direct about why: “we’re going to be our own first customers. The rapid feedback from doing that is the way to build something amazing.”

So Alphabet did not fund a competitor. It bought a seat next to the fastest compounding process anyone has attempted, because sitting outside it costs more than the check.

One more detail worth noticing: California bans non-competes. Anthropic, SSI, Thinking Machines, and now Discovery Loop all exist partly because their founders could walk out on a Wednesday and incorporate on a Thursday.

What they are actually automating

The scientific method is the most powerful algorithm we have, and we have always run it by hand. Propose, experiment, read the result, adjust, repeat. Sequential. Slow. Bounded by how many humans you can put on it.

Discovery Loop’s bet is that the loop runs faster once the human steps out of the middle.

The ambition, in their own words: subproblems across nearly every one of the 14 NAE Grand Challenges.

The AI proposes the experiment, executes the run, learns from the outcome, and iterates recursively, with thousands of experiments running in parallel where a team would have run them in series.

Their published ambition:

“Imagine a future where a handful of people can conduct scientific research and engineering tasks much more rapidly, and with higher quality, than massive teams of scientists and engineers do today.”

The sequencing tells you they have done this before. ML research and engineering first, because software experiments are cheap, fast, and fully computerizable. Then hardware design, drug discovery, materials, and clean energy. Dean says the approach reaches subproblems in nearly every one of the 14 NAE Grand Challenges.

Here is the part that matters for you.

The loop they are industrializing at frontier scale is the same 4-stage pattern you can run this week, at your scale, with tools you already pay for. Most teams run it by hand and call it iteration. The leverage arrives when you remove yourself from the middle and give it a stop condition.

Below, the full system.

Inside The Discovery Loop Playbook:

▫️ The 4-stage loop architecture, mapped to what you can automate today

▫️ The self-customer rule, how to pick the first target so it compounds

▫️ 4 copy-paste loop prompts, propose, execute, evaluate, iterate-or-stop

▫️ The parallel-experiment system, with the cost formula and the budget guard

▫️ The verification layer, the piece almost everyone skips

▫️ The 5 signals to watch, to know whether this thesis is working

Your subscription opens the full AI Corner archive:

▫️ The AI Tools and Models library, every model, tool, and setup guide

▫️ The AI Agents library, the full agent-building stack, start to finish

▫️ The Prompting and Context Engineering library, the prompts and context systems that actually ship

▫️ The Claude and Anthropic library, every Claude playbook in one place

Plus 3 new premium systems every week.

🔁 The Discovery Loop Playbook

Get the full system below 👇

1. The 4-stage loop

Every automated research loop has 4 stages. Each maps to something you can run now:

Sam Altman: 3 months of work now takes 7 minutes

Ruben Dominguez — Wed, 05 Aug 2026 16:38:30 GMT

3 months of work now takes 7 minutes

That’s real math, from Sam Altman, on his own first startup.

He said it onstage at Startup School 2026, 20 years after Paul Graham cooked dinner in Cambridge for 8 founders who felt hopeless.

I watched the full interview so you can skip it.

Here are the 10 takeaways that matter.

brought to you by GoDaddy's Airo for WordPress:

That same build-time collapse is hitting the tools founders run their business on too

GoDaddy's Airo for WordPress works the same way: update pages, products, or content through a prompt, no developer needed

▫️ Works past launch, not just at it

▫️ Full WordPress ecosystem, 60k+ plugins

▫️ You keep ownership of your site and data

Try it free for 7 days

1. What took 3 months now takes 7 minutes

Altman opens with a number that resets the entire conversation about what a startup even is.

“What took three months to build at the time that we each company built over the whole YC startup could now be done in like seven minutes by a coding agent.”

That is a collapse of the cost of building by roughly 3 orders of magnitude. You can read it 2 ways, and Altman names both. One reading is despair: a prompt now does what a startup used to do, so why bother. The other is the correct one: the floor for what counts as a serious project just moved, and moved up.

That floor moving is what puts multi-disciplinary products once needing a dozen specialists inside reach of a solo founder, and drags hard technical problems that were too slow or expensive to attempt into the range of a 4-person team. The bar for ambition went up, not down.

If your idea only takes 3 months to build, it is not ambitious enough for this moment.

The founders who move first on this are the ones who already run the leverage. Start here:

▫️ The one-person startup operating system

▫️ The Loop Library: 12 Claude Code recipes

2. The "permanent underclass" meme is backwards

There is a meme going around that you either join a frontier lab or become economically irrelevant. Altman calls it stupid, on stage, in that word.

“That’s not true. I mean, if that were true, the world is like totally messed up and it’s a very bad place.”

He makes a falsifiable counter-claim: startups founded today will be more valuable and more impactful than startups of the past. Not despite AI. Because of it. And the fear carries a genuine behavioral cost. It stops founders from starting at all, pushes them toward a lab salary over a company of their own, and creates a visible anxiety trough across YC batches that swings back once the fear proves empty.

If you are delaying a startup because you think the window closed, you are working from a premise the person building the models rejects outright.

The fundraising climate rewards the founders who start anyway, and the Replit seed story is the proof that a laughed-at idea can still win.

3. The next 6 months will feel like 2 years

Asked how much faster models get, Altman gives a time-boxed answer instead of a vague one.

“I think it will feel like the next six months is like maybe equivalent to the last two years of model progress.”

This is a forecast you can build against. Most roadmaps assume the current pace continues linearly, and Altman is telling founders directly that the assumption is wrong. So assume your Q4 ship date lands on a materially more capable model than the one you test on today. Stop scoping features around current model limits. Build the workflow, not the workaround, since the workaround gets solved for you.

A 12-month plan built on today’s model capability is a plan built against a moving target, which is the whole point of designing self-improving loops over static features.

4. The Golden Age of Hard Tech Startups (Even Though the Physics Hasn’t Changed)

Hard tech has always been appealing and always been brutal. Altman says the calculus around it just shifted.

“What you can do now to go take on a really ambitious project, you can do unbelievable things.”

He points to a number from inside YC: hard tech sat at 5 to 10% of batches for years, and is now pushing toward 25%. The reason is not that hard tech got easier in the abstract. Agents absorbed the grinding work that used to require a large specialized team.

The shift shows up first in physics and materials-heavy projects, in robotics and hardware-software integration, and in regulatory-heavy work that used to need a full legal team on staff. If you shelved a hard tech idea for lack of a team, revisit it. The team you needed is 4 people and a lot of compute.

5. Tool fluency now beats a decade of experience

The most uncomfortable claim in the talk, and Altman states it without hedging.

“I would bet that this generally will cut against many years of experience in favor of people who have a lot of fluency with the tools.”

He is careful about what he is not saying. Taste, agency, and an understanding of how businesses actually work still matter enormously, and knowing a durable moat from a fake one is not something a tool teaches. But raw domain tenure, the kind that used to be a moat by itself, is losing ground fast to people who grew up automating their own workflows.

The hiring signal is shifting under everyone: teams of four running what used to be a department, agents plus compute replacing headcount over augmenting it, and business judgment becoming the scarce skill over tenure. Hiring for years of experience alone is now a weaker bet than hiring for tool fluency plus judgment.

Want that fluency yourself? These are the fastest ways to build it:

▫️ Loop engineering for coding agents

▫️ Your GTM, run by agents

▫️ The AI Skills playbook: templates and prompts

6. Find the one place everyone confidently calls you wrong

Altman’s highest-order advice is about where to look for the idea in the first place.

“Find the things that you can develop reasonable conviction in that people decide the conventional wisdom is they’re just wrong, and be okay with it taking a long time.”

10 years ago people did not just doubt AGI was buildable. They argued trying would cause another AI winter and called the attempt irresponsible. That level of confident dismissal is the signal, not the deterrent. Conventional wisdom is often wrong about exactly the thing that matters most, the world is bad at intuiting exponential change, and being dismissed buys you time before serious competitors show up. Starting the same company as everyone else gets you hype and capital, rarely the biggest outcome.

The idea that gets you laughed at today, if you hold genuine conviction in it, beats the one that gets universal nods.

7. Only 50 people believed in AGI. You need even fewer.

You do not need consensus, and Altman is specific about how few you actually need.

“We used to joke that only 50 people in the world believed that AGI was possible, but it was okay because 45 of them worked at OpenAI.”

The heresy was the recruiting tool. People who believe something unpopular want to find each other and stay close. But he flags a genuine warning inside the permission: zero people agreeing with you is a danger sign, not a badge, and everyone agreeing with you is also a bad sign. Stop waiting for broad validation. Find your 5 people this month, not your 500.

8. Cheap shots on Twitter will poison your soul

The sharpest moral line in the talk, and Altman does not hedge a word of it.

“It is very easy to go take shots on Twitter and make a sarcastic comment and get a lot of likes and feel like you’re doing something really important. And it will poison your soul.”

He is describing a decade of running YC while absorbing constant public mockery, and he admits he took the bait more than he should have. > Building something is hard. Taking shots at people who try is easy, and it feels like doing something when it is not. The people throwing shots rarely remember it a decade later, and the energy spent mocking builders is energy not spent building. Every hour scoring internet points on someone else’s attempt is an hour off your own.

9. The future is not abundance. It is freedom.

Asked what the best version of the next 10 years looks like, Altman refuses the easy answer.

“You will get great comfort, but there will be nothing left in the world for you to really do. Nothing that really matters.”

He names a specific dystopia: material abundance paired with total surveillance and zero agency. A cure for cancer delivered alongside a world where nobody has anything meaningful left to do. The metric he proposes instead is not GDP or breakthroughs. It is whether ordinary people have more freedom and agency, year over year, to spend their time as they choose, which means avoiding a crazy concentration of power, an economic collapse, a major safety incident, and too much change packed into too little time.

If your product roadmap trades user agency for convenience, you are optimizing for the wrong decade. Freedom compounding beats comfort compounding.

10. Why a former safety skeptic suddenly got serious

Altman closes the loop on his own history as an AI safety skeptic, and the tone shift is the most important signal in the interview.

“I think anybody who is not taking this seriously and at least a little bit scared or humbled is not taking this seriously enough.”

He references a recent incident of a system acting outside its intended boundaries, calls it plainly an alignment failure and a security failure, and says OpenAI made genuine mistakes, with zero hedge. The reframe is about expectations: ten years ago most people would have placed “an AI breaking out of its sandbox” near the superintelligence end of the spectrum. The field spent a decade describing incidents of exactly this shape in the abstract, and the goalposts moved once the systems got capable enough to make it happen.

If your product touches agentic AI, the security and alignment bar just moved from theoretical to operational. Build for it now, over after your own incident.

What this means for you

Altman’s thesis across the whole talk is one sentence: the cost of building collapsed, so the size of what counts as ambitious got much bigger, and the people who see that clearly will build the next generation of enormous companies.

▫️ Founders: Stop scoping projects to what a small team grinds out in a quarter. Scope to what agents make possible now. Write down the idea the room confidently calls wrong, and start it this week.

▫️ Investors: Domain tenure is a weaker signal on its own than it was. Add tool fluency and business judgment to your evaluation checklist, and flag any founder treating the “permanent underclass” line as fact.

▫️ Operators inside big companies: The 6-month acceleration applies to your roadmap too. Rebuild your Q4 plan against the model you will ship on, not the one you test on today.

▫️ Founders outside tech: The cost collapse hits your sector too. Pick the one process that still takes a specialist team and a quarter, and test whether an agent can draft it with a small crew this month.

The 5 principles to steal

Scope to 7 minutes, then multiply the ambition. Use the cost collapse to attempt something bigger, over the same thing faster.
Find where the room is confidently wrong. That is where the biggest outcomes hide.
You need a small crew, not a majority. A handful of true believers beats broad, lukewarm approval.
Protect your energy from cheap shots. Mockery feels like doing something. It is not.
Optimize for freedom, not just comfort. Abundance without agency is the dystopia to avoid.

Startups just got a lot more ambitious.

The people who see that clearly are already building. Everyone else is still arguing about whether the window is closed.

If this breakdown saved you 39 minutes, send it to one founder or investor who needs it.

Keep reading

Build with agents

▫️ The Loop Library: 12 Claude Code recipes

▫️ The one-person startup operating system

Raise and build the company

▫️ What top VCs look for in 2026

▫️ The self-improving fundraising system

▫️ The Fable 5 fundraising playbook

Think in decades

▫️ You are overpaying for intelligence: the model router

▫️ The AI app security checklist

▫️ The AI inference engineering playbook

Full interview:

Jensen Huang Bet Wrong, Told the Truth, and Built a $5 Trillion Company

Ruben Dominguez — Mon, 03 Aug 2026 18:51:28 GMT

NVIDIA’s founding algorithm was wrong.

Not slightly off. Exactly wrong.

Jensen Huang just told that story to a room of 6,000 founders at Y Combinator’s Startup School, and it explains the last three decades better than any strategy memo. I studied the full conversation so you can skip it.

Here are the ten takeaways that matter.

together with Outskill:

Huang says AI automates tasks, not jobs. The people who win are the ones who make Claude their second brain first.

This weekend, the world’s first Claude-athon condenses 800+ hours of research into a 16-hour live curriculum:

▫️ Master all three modes: Chat, Cowork, and Code

▫️ Set up Skills, Connectors, and plug-ins to automate your files, Notion, and desktop

▫️ Vibe-code apps plus 10+ tools that pair with Claude

Free, Saturday & Sunday, 10 AM to 7 PM EST.

Get AI equipped FREE

1. The $5 million contract Huang could not deliver, and asked Sega for the money anyway

Huang’s most pivotal early moment is a confession, over a product launch.

“So what you’re telling me is what I contract you to do, you can’t do, but you would like all the money on the contract.”

Sega hired NVIDIA to build the chip for the console that became the Dreamcast, a deal worth $5 million. NVIDIA’s graphics technology did not work.

Huang flew to Japan and told Sega’s CEO the truth before anyone forced it out of him. He recommended Sega hire a different vendor. Then he asked for the money anyway. Sega’s CEO restated the ask back to him plainly, agreed, and said he trusted the team enough to want them to survive. That $5 million kept NVIDIA alive through 1996. When NVIDIA went public in 1999, Sega sold its stake for $15 million, one of the better returns in console history.

Why it matters: You invest in people, over companies. Decide today what you would disclose to an investor before they force it out of you, and disclose it first. Radical honesty about failure is a stronger fundraising signal than any polished deck.

2. Huang built NVIDIA on an algorithm that was exactly wrong

The founding bet was a specific technical wager, and the wager failed.

“We believed in it. We reasoned about it in a thoughtful way, and we went to start the company to go build it. Well, it turns out, the algorithm was exactly wrong.”

In 1993, Huang and his co-founders set out to reinvent 3D graphics and turn every PC into a game console. They designed a new algorithm to do it. They believed in it. They raised on it. By 1995, when they finally confirmed it did not work, 35 to 40 competitors were already shipping 3D chips for PCs.

You can lose a two-year head start and still win. Huang’s next move is the proof.

Why it matters: Founders defend a founding idea long past the point it stops working. If yours is wrong at the technical level, the company can still survive, as long as you admit it fast.

3. Three textbooks from Fry's rebuilt the company for about $200

NVIDIA fixed its algorithm with a bookstore run, over a strategy offsite.

“I had a couple of $60, a couple of $100 in my pocket, and so I went down to Fry’s, and I bought three textbooks.”

Huang confronted his team first, and found that nobody at NVIDIA knew the correct way to build the algorithm either. So he spent roughly $200 on OpenGL pipeline textbooks instead of hiring a consultant, and handed them straight to his engineers. From that starting point, NVIDIA became the world leader in modern computer graphics.

Why it matters: The distance between a near-dead startup and a category leader is sometimes a $200 trip to a bookstore. You rarely need a strategic overhaul. You need the right textbook and the humility to read it, the same first-principles fluency that compounds over a career.

4. The true NVIDIA thesis was never the chip

Three decades later, Huang says the founding insight was never about hardware.

“We realized early on that it’s not about building a great chip. It’s about accelerating an algorithm domain.”

Graphics was the first algorithm domain NVIDIA chose to accelerate. Molecular dynamics, image processing, inverse physics, and deep learning followed the identical pattern, one after another, over 30 years. A durable company runs on a perspective the founder cannot stop thinking about, Huang says, more than on any single product. The right technology for the right market makes execution easier. It does not replace the thesis underneath.

Why it matters: You are not building a chip, a feature, or an app. You are choosing a domain to accelerate for the next 30 years. Pick one you would still defend two decades from now, the same durable-thesis logic investors look for.

5. AlexNet convinced Huang he had found a universal function approximator

Huang did not read AlexNet the way the rest of the industry did in 2012.

“The breakthrough for us was realizing that AlexNet was not AlexNet. That AlexNet was an approach with deep learning that allows you to learn any function.”

His lens was always algorithms first: NAMD, VASP, OpenGL, SQL. When AlexNet appeared, the mechanism underneath it was deep learning, and fifteen years ago Huang was already telling people NVIDIA had found something that could approximate almost any function. Most problems worth solving are imprecise, which is exactly why an approximator beats a calculator. NVIDIA started on computer vision and robotics almost immediately, and Huang now calls the full implication the five-layer cake: processor, middleware, algorithms, applications, industries.

Why it matters: The insight was never that deep learning works. It was that it rewrites the entire computing stack, years before the market notices. Ask what your AlexNet moment actually implies, over what it demos.

6. NVIDIA's physical AI business is already $10 billion, and Huang says it becomes the next $100 billion one

This is his most concrete forward bet in the whole conversation.

“Our robotics business, autonomous vehicle business, basically physical AI business, is probably almost, it’s like $10 billion. This’ll be our next $100 billion business.”

Self-driving cars became the first robotics wedge, since the market is large and the technology is standardized enough to scale. NVIDIA chips already sit inside Waymo, Tesla, and Mercedes. Huang open-sourced NVIDIA’s self-driving stack, Alpamayo, so agriculture, mail delivery, and warehouse robots could use it too, since no one of those markets alone justifies building the stack. He expects physical AI to become one of the largest industries in the world inside a window longer than three years and shorter than ten.

Why it matters: Huang is naming a specific ceiling and a specific window, backed by chips already shipping today. Watch which adjacent markets pick up his open-sourced stack next.

7. The AI jobs narrative is exactly backwards

This is the sharpest pushback Huang gives against AI anxiety in the entire talk.

“The narrative about AI destroying jobs is exactly backwards. AI eliminates tasks. AI automates tasks away. But it doesn’t necessarily eliminate jobs.”

His argument: a job has a purpose, and that purpose contains many tasks. Automating one task rarely removes the purpose. Software engineering jobs grew 10% year over year even as automation took over the coding task itself. Radiology jobs grew roughly 20% even as AI took over scan reading. Paralegal roles grew despite predictions that legal AI would wipe them out. The common thread is backlog: hospitals, law firms, and software teams all carried more unmet demand than they could serve, so automation let them do more work instead of cutting headcount.

Why it matters: Check whether your industry has a backlog of unmet demand before you assume automation shrinks your team. That backlog, over the task itself, decides the outcome.

8. Agents do not need to be perfect. They need to be controllable.

Huang’s take cuts against the industry’s obsession with accuracy scores.

“I change one word in a plan file, and that one word makes a delta difference. I think controllability is probably the single biggest breakthrough that we need for agents at every single level.”

The common assumption is that agents need near-perfect accuracy before you can trust them. Huang argues the more urgent problem is fine-grained control. Change one word in a plan file. Change one pixel, one triangle, one component in a CAD file, one via on a board, and the rest regenerates around that single change while you stay in the loop the whole time. An 80% accurate agent with precise control beats a 99% accurate one with none, since you close the remaining gap yourself either way, and control decides how expensive that closing gets.

Why it matters: If you are building or buying AI tools right now, check whether the product gives you granular control over specific outputs, over just an overall accuracy score.

9. Huang calls the open-agent moment a Linux moment

He draws a direct historical parallel to explain why this moment feels foundational.

“This is the operating system that’s going to hold a large language model. And in a lot of ways, OpenClaw to me was a very Linux moment to me.”

Huang is not anti-cloud. Use ChatGPT and Claude as much as you want, he says directly. He also wants every company building its own domain-specific AI on top of open tooling like Hermes, LangChain, and DeepAgent, because the software is capable enough now that adapting it is straightforward. NVIDIA has to understand agent workloads five to ten years early, since a chip takes three years to design and runs for a decade after.

Why it matters: The company that studies its own agent workloads today designs a better system for the decade ahead, whether that system is a chip or your own product roadmap.

10. You do not have to overcome life. Just get through today

Huang closes on the most personal moment in the conversation, and it has nothing to do with technology.

“You don’t have to overcome life in one day. You just have to overcome that morning. You have to overcome today, today.”

Raising NVIDIA’s first round terrified him. He bought a 500-page book on how to start a company and never finished it. His actual operating phrase was simpler than any framework: how hard can it be. He tells you plainly it is always harder than expected, and the mindset still works. Resilience, in his telling, is getting through one morning, then the next, for as long as it takes. “Let the suffering come to you a little bit at a time,” he added.

Why it matters: Resilience is not a trait you either have or lack. It is a practice you repeat every morning, starting with this one.

What this means for you

Huang’s thesis has held for 30 years, even as the technology under it changed constantly.

▫️ Founders: Your founding idea can be wrong at the technical level and the company can still survive, if you confront the failure fast. Go find your own version of Huang’s bookstore trip this week.

▫️ Investors: Sega funded a founder who admitted he could not deliver. Weight a founder’s early, unprompted disclosure of failure over a polished pitch, and ask about it directly in your next diligence call.

▫️ People in tech: Systems thinking, over coding, is the skill Huang says survives automation. Start building fluency in inputs, outputs, constraints, and information flow now.

▫️ People in other industries: Radiology and legal work both grew headcount despite heavy AI automation, because backlog was the true constraint. Look at your own industry’s backlog before you assume automation shrinks your team.

The five lines to keep

Confront reality fast. The two-year gap between founding on a wrong idea and admitting it nearly killed NVIDIA.
Radical honesty beats polish. The Sega deal survived because Huang told the truth about failure before anyone demanded it.
Perspective matters more than product. NVIDIA’s durable thesis was always about accelerating algorithm domains, over building chips.
Task automation is not job automation. Track the backlog in your industry before you assume AI shrinks headcount.
Resilience is a daily unit, not a lifetime one. Get through today, then get through tomorrow.

The algorithm was wrong. The money came anyway. NVIDIA happened.

If this breakdown saved you an hour, send it to one founder or investor who needs it.

Keep reading

Build the edge

▫️ You are overpaying for intelligence: the model router

▫️ The Self-Evolving Agent Stack

The founder’s playbook

▫️ What top VCs look for in 2026

▫️ The self-improving fundraising system

▫️ 200 US AI angel investors, all builders

The bigger picture

▫️ The AI inference engineering playbook

▫️ The one-person startup operating system

▫️ The SaaS defense playbook

Full interview:

The $10K Etsy niche nobody is running with Claude yet

Ruben Dominguez — Sun, 02 Aug 2026 14:48:08 GMT

Most “make money with AI” guides teach you the same move: flood a platform with junk, cash in for six weeks, then watch the account get banned and the income vanish overnight.

This is the opposite, and it is built to still be standing in a year.

One niche. Three genuine assets that feed each other. Each earns on its own, and together they build the one thing you actually own: an audience no algorithm can take back.

Here is the part those guides bury: the product is not the asset. The audience is. A single Etsy sale is a transaction. An email list that trusts you is a business, one nobody can deplatform.

And the ground is wide open right now:

▫️ Etsy just posted its first buyer growth in two years, 86.6M active buyers

▫️ Pinterest sends 41% of all of Etsy’s social traffic, and 75% of weekly Pinners arrive ready to buy (versus 28% on Facebook)

▫️ Email still returns about $36 for every $1, on a list nobody can starve

The window is the story. Custom digital products used to need a designer and days of work. Claude collapses that to minutes, which means the edge belongs to whoever builds genuine quality at volume before the category fills up. Right now, it is close to empty.

One example niche runs the whole way through: travel. Keep it, or swap it at the end with one prompt. The system is the point.

What’s inside the full playbook:

▫️ The custom-product engine that builds a digital product people pay a premium for, with the margin math
▫️ The Etsy launch kit that ranks without keyword-stuffing
▫️ The 4-prompt content engine built for the AI-search era, where depth is the only moat left
▫️ The owned-audience funnel where you show up as yourself, over astroturfing your way to a ban
▫️ The one-brand structure that turns three hustles into one business
▫️ The niche-swap prompt that rebuilds all of it for any market

One subscription unlocks every system

▫️ The Prompting and Context Engineering library

▫️ The Claude and Anthropic library

Plus 3 fresh systems every week. One product line from this covers the subscription many times over.

🧭 The Claude Digital Business System

Get the full playbook below 👇

Try premium free for 7 days. Or get 50% off this week only.

Someone just ran a 2.78-trillion-parameter model on a laptop. The memory wall is breaking

Ruben Dominguez — Fri, 31 Jul 2026 20:17:38 GMT

On July 30, an open-source project did something the textbooks said was impossible.

It ran Kimi K3, the 2.78-trillion-parameter model that beats Claude Opus 4.8 on measured intelligence, on a single MacBook Pro with 64 GB of RAM. The full model. Zero pruning, zero distillation. A checkpoint that occupies 1.42 TB, executing on a machine with less memory than the model needs by a factor of more than twenty.

It runs at 0.3 tokens per second, so nobody is doing serious work with K3 on a laptop tomorrow. That is the honest headline. But the thing it proves is the story: available memory no longer sets a hard ceiling on the size of model you can run on hardware you own. The wall between you and frontier intelligence, the one that forced everyone onto someone else’s cloud, just developed a crack.

And here is what almost nobody covering the laptop-K3 demo will tell you: the boring version of this is already usable today. On the same Apple Silicon, capable mixture-of-experts models run at 30 to 130 tokens per second right now, fast enough for capable agents, live coding, and private workflows, on machines you already have.

Which raises the question every builder and every cost-conscious founder should be asking this week.

What should you actually run on your own hardware, and what should stay in the cloud?

Behind the paywall, the complete Local AI Playbook:

▫️ The cloud-vs-local decision matrix, the six factors that decide where each workload belongs, scored, with the routing rule
▫️ The runnable-models tier list, what actually works locally today, at what speed, on what hardware, from proof-of-concept to production-ready
▫️ The hardware buyer’s guide, exactly which machine for which workload, and the specs that actually move tokens per second
▫️ The TCO calculator, owned hardware versus token bills, the breakeven math, and the consolidation multiplier most people miss
▫️ The privacy audit, which of your workflows should never leave your machine, and the sales line it hands a founder
▫️ The stack setup, Ollama, MLX, and WASTE, which to use when, with the commands and the quantization cheat sheet
▫️ The measurement rule, the one engineering discipline that saves you weeks, lifted from WASTE’s own build log
▫️ The migration sequence, how to move your first workload local this week without breaking anything
▫️ The get-ready plan and the re-evaluate triggers, so you are positioned the moment this gets fast, and know exactly when to revisit

One subscription unlocks every system

This is one build in a growing library. Premium opens all of them:

▫️ The Prompting and Context Engineering library

▫️ The Claude and Anthropic library

Plus 3 fresh systems every week. One workload moved off the cloud can cover the subscription for years.

🖥️ The Local AI Playbook

The decision matrix, the tier list, the hardware guide, the TCO math, the privacy audit, the stack setup, and the migration sequence, in one system.

Get The Local AI Playbook below 👇

Try premium free for 7 days. Or get 50% off this week only.

The Seven Deadly Sins of AI Spend

Ruben Dominguez — Thu, 30 Jul 2026 14:35:06 GMT

The Old Sins Behind the New Budget Crisis

Every finance leader watching an AI invoice this year agrees that costs are becoming unpredictable.

But giants like Uber are just burning through their entire 2026 budgets on agentic coding. One enterprise client spent $500 million on AI services in a single month because nobody had switched on a usage limit for its Claude licenses.

Neither company ran short on model options. Neither had a shortage of cheaper alternatives sitting one API call away.

A 2026 survey of 500 finance leaders across the US and UK found that 79% of enterprises had experienced AI cost overruns in the past year.

Gartner puts global AI spending on pace for $2.59 trillion in 2026, an almost 50% jump over last year.

together with Plaid:

Who's afraid of AI in finance? Not consumers. They already moved:

▫️ 55% have used AI for money tasks this year

▫️ 86% say it helps them understand their finances

▫️ 50% think managing money without it will soon feel outdated

Plaid and The Harris Poll mapped exactly where people want AI in their money, and what makes them trust it.

The roadmap for anyone building in fintech:

read the FREE report

But none of that is a pricing problem because pricing problems get solved by pricing.

This is something older, and it was diagnosed roughly 700 years before the first token ever got billed.

This is about companies committing deadly sins. And you need to know about them.

The seven familiar human weaknesses behind runaway enterprise AI spending.

1. Lust: Falling in Love With the Architecture Before the Problem

2. Gluttony: Buying Intelligence Nobody Asked You to Buy

3. Pride: The Refusal to Reuse What Already Works

4. Envy and Greed: Comparison and Hoarding, the Twin Engines of Waste

5. Sloth: The Agents Nobody Ever Goes Back to Check On

6. Wrath: The Panic That Costs More Than the Problem Did

7. The Takeaway

1. Lust: Falling in Love With the Architecture Before the Problem

Lust is wanting a thing because it excites you, not because the moment calls for it. In enterprise AI, the object of desire is almost never the outcome. It’s the architecture.

The Swarm Built for a Job a Script Would Do

AI reviews now are shaped around the same template:

A multi-agent system and several specialized models negotiating with each other, built to answer a question a single well-scoped prompt would have settled in seconds.

It isn’t stupidity. Orchestration frameworks and recursive planners are genuinely some of the most satisfying things an engineer can build right now.

MIT’s Project NANDA studied 300 public AI deployments for a report called “The GenAI Divide” and found that 95% of generative AI pilots failed to produce measurable financial return.

The reporting that followed was blunt about why. The failures traced back to poor integration and mismatched priorities, not weak models.

The model was rarely the problem. The shape built around it usually was.

If you ask why smart teams keep doing this, the honest answer isn’t ignorance. It’s that building the elaborate version is simply more fun than scoping the boring one, and fun is a much stronger incentive than a line item three budget cycles away.

Interest in task-specific GenAI is high, but very few projects make it from pilot to production. (Image source: MIT Nanda)

Every Extra Hop Is a Place to Leak

Complexity compounds the same way interest does. Each additional agent in a pipeline is another place tokens leak, another hop of latency, another silent failure mode hiding behind a green checkmark.

None of that shows up on an invoice labeled lust. It shows up as a model bill, and the model is almost never the part anyone questions first.

When the architecture is more exciting than the problem it is supposed to solve.

2. Gluttony: Buying Intelligence Nobody Asked You to Buy

Gluttony is the sin everyone already half-recognizes. It’s reaching for the smartest, most expensive model as the default, not because the task demands it, but because reaching for anything less feels like a risk someone will notice.

The Default Nobody Gets Blamed For

Frontier models like Fable 5 right now are the safe political choice inside an organization. Nobody gets paged for choosing the most capable model available. People get paged when the cheaper one fails on an edge case six weeks later.

So the incentive quietly points one direction: overspec everything, and let the invoice absorb the blame instead of you.

The Open-Weight Paradox

The strange part is that the cheaper alternative has never been better positioned to win this argument. Open-weight models have closed most of the capability gap and collapsed in price.

And enterprises are using them less. Menlo Ventures’ 2025 State of Generative AI in the Enterprise found that open-source models’ share of enterprise LLM usage actually fell to 11%, down from 19% the year before.

Open-source models are improving, but their share of enterprise LLM usage continues to fall. (Image source: Menlo Ventures)

The cheaper option didn’t lose that argument on the merits. It mostly never got invited into the room.

Which raises the obvious question: if the alternative is right there, why does almost nobody reach for it?

3. Pride: The Refusal to Reuse What Already Works

Pride is the quietest sin on this list, because it never feels like arrogance from the inside. It feels like “our use case is different.”

Our Use Case Is Different

It’s the team that builds its own orchestration framework instead of adopting a maintained one. It’s the engineer who won’t let a response get cached because their output has to feel freshly generated every time, even when the input hasn’t changed.

Pride is expensive in a very specific way as it duplicates cost that’s already been paid down somewhere else in the industry, then charges you full price for the privilege of re-learning it.

But none of this is new. Engineering organizations have had a name for it since long before anyone billed a token and that is:

“Not Invented Here.”

AI just gave the old habit a much larger bill to run up.

Why reuse proven infrastructure when you can pay to rediscover it yourself?

The System Nobody Else Is Allowed to Audit

Custom-built systems resist the very instrumentation that would reveal what they cost. You can’t easily audit spend on infrastructure nobody outside the team that built it fully understands.

That’s both a cultural and a structural problem. The same February 2026 survey found that accountability for AI spend is split almost evenly between Technology, at 55%, and Finance, at 53%. Add those two numbers and you clear 100%, which is another way of saying nobody actually owns it.

When two departments both own AI spending, nobody really owns it.

A system two functions each assume the other is watching is a system nobody is watching. Once nobody’s watching, comparison and hoarding move in next.

4. Envy and Greed: Comparison and Hoarding, the Twin Engines of Waste

These two travel together so often they’re worth taking as a pair.

Envy is looking sideways at what everyone else has.
Greed is grabbing more than the moment requires. Both dress themselves up as strategy.

Chasing the Model of the Month

Envy shows up as model FOMO by migrating an entire production stack because a competitor announced a new release, or a thread called it a “killer,” without running a single eval against your own workload first.

Every migration carries a real cost. Whether that’s re-prompting, re-testing, re-hardening guardrails against the edge cases the old model had already been tuned to catch.

Standing is equally costly. But reactive migration driven by headlines instead of benchmarks is how a team ends up rebuilding the same system four times a year and calling it progress.

The capability gap between leading coding models is narrowing, making automatic reliance on the most expensive option harder to justify. (Image source: DeepSWE)

The Cap Nobody Set

Greed rarely looks like wanting more. Usually it looks like never getting around to saying enough.

Uber found out what that costs. The company maxed out its entire 2026 budget for agentic coding tools in four months and had to cap employee usage.

One enterprise client found out at a larger scale. Axios reported the company spent $500 million on AI services in a single month, because nobody had turned on a usage limit for its Claude licenses.

Unlimited access looks like flexibility right up until the invoice arrives. Then it reads as the thing nobody was willing to be the one to cap.

Model FOMO and unlimited usage disguised as enterprise strategy.

Once that money is gone, the next question is whether anyone goes back to fix whatever spent it. The record on that is not encouraging.

5. Sloth: The Agents Nobody Ever Goes Back to Check On

Sloth isn’t fear of touching a working system. That’s actually a different failure entirely.

Sloth is simpler. It’s never asking whether the system could be better, long after anyone would have noticed if it wasn’t.

The Orphaned Agent

The AI cost-management firm Larridin has a name for the purest form of this. They call this an orphaned agent, an autonomous system still running and still consuming resources with no current owner attached to it, usually left over from a pilot that ended without anyone turning the lights off.

Larridin’s scan data across enterprise clients found that an average of 18% of enterprise AI spend can’t be traced to any specific team, tool, or outcome. Nearly 1 dollar in 5 is running with nobody home.

A Human Employee Who Never Improved Would Be a Performance Problem

Most production agents today are running the exact configuration they launched with. Same model, same prompt, same retry logic, and long after cheaper or better options existed.

Hold a person to that standard for a year and it’s a performance review. Hold an agent to it and it’s just Tuesday, because nobody assigned anyone to look.

The fix isn’t complicated, which is part of why it’s so rarely done. A system that periodically reviews its own recent runs and proposes a cheaper or better configuration costs almost nothing next to what it saves, provided a human still signs off before anything changes.

The agent could improve itself, but nobody ever returned to ask.

Eventually, someone in finance does look. And the reaction rarely matches the size of what they find.

6. Wrath: The Panic That Costs More Than the Problem Did

Finally, wrath is the overcorrection. It’s the blanket freeze on all AI spend after one shocking invoice.

It’s the hard cap that throttles the best builders in the building right alongside the worst offenders. It’s the mandate that kills three profitable use cases to make an example out of one wasteful one.

It’s happening at the industry level right now. Forrester found that enterprises are postponing 25% of planned AI spend into 2027 as financial scrutiny intensifies.

This is a retreat that punishes the programs that were already working just as hard as the ones that weren’t.

Wrath happens because visibility failed first. If you can’t see spend broken down by team, agent, and purpose, every overage looks like an emergency instead of a data point you could have caught weeks earlier.

When the invoice has to be paid.

7. The Takeaway

The February 2026 survey identified the single most fixable barrier to AI ROI, and it wasn’t a technology gap at all.

In fact, it was the gap between how Finance and Engineering define success, cited by 37% of respondents overall, and 43% of the C-suite.

That is a problem two functions solve by agreeing, in a room, before the dashboard gets built.

Look back across all six sins and the same structure sits underneath every one of them: a cost that felt free in the moment, because nobody had priced it, attributed it, or reviewed it before it became a crisis.

The seven deadly sins were never really about food, money, or rage. They were a catalog of what happens when a reward feels immediate and nobody’s checking. That description fits a company running loose with API keys better than it fits almost anything else in a modern budget.

Ultimately, your AI bill is a character problem that learned to speak fluent token pricing, and it was fully diagnosed long before anyone thought to bill a single one.

Every Tech Company Is Falling Into A Layoff Trap

Ruben Dominguez — Wed, 29 Jul 2026 14:22:12 GMT

The AI Layoff Trap

A laid-off engineer still buys groceries for about a month. Then the savings thin out, the subscriptions get cancelled, the holiday gets postponed, and the new laptop waits another year.

Multiply that by a hundred thousand people and you get the quiet story underneath this year’s layoff headlines.

The supermarket saves on labor, but the departing workers are also the customers its business depends on.

Every company cutting staff to fund its AI push is also, in a small way, cutting the income that buys its product. Most boardrooms treat that as someone else’s problem.

A sharp new paper argues it is everyone’s problem, and that the smartest firms in the world are walking into it with their eyes open. If it is right, this is the thing nobody in tech is pricing in.

The whole bet rests on one assumption: that AI agents can run the work better than the people being let go. Before we get to why the trap is so hard to escape, it is worth seeing that bet up close, from the people actually building the agents.

Together with Hard Skill Exchange:

The layoff bet assumes agents can run revenue better than the teams being cut. On July 30, ten executives show what that actually looks like in production, and where it breaks.

It is completely free to attend:

▫️ Live sessions from the leaders at Gainsight, 1mind, Dialpad, RevSure, and Vivun

▫️ The governance layer behind autonomous revenue: guardrails, context engineering, and decision traceability

▫️ When an agent should act, and when it should escalate to a human

Free and virtual, 9 AM PT.

Claim your FREE Seat

Now, the paper itself. Here is why the trap closes even when everyone can see it.

The Numbers Nobody Wants on the Slide
The Trap, Explained Without a Single Equation
The Finding That Should End the Workers-Versus-Bosses Fight
More Competition and Better AI Both Make It Worse
Why the Comfortable Solutions Do Not Work
The Catch That Keeps the Argument Honest

1. The Numbers Nobody Wants on the Slide

This year has a number attached to it, and the number keeps climbing. The layoffs are not a blip or a seasonal trim. They look real and rational, and the people running these companies are saying so on the record.

A record that arrived faster than anyone expected

By the middle of June, the trackers had logged between 150,000 and 184,000 tech jobs cut in 2026, depending on whose methodology you trust.

The pace is the part that should bother you. Last year, a brutal year by any measure, the industry shed around 245,000 jobs across all twelve months.

This year is running closer to a thousand cuts every working day, and the first quarter alone was the worst since early 2023.

The individual events read like a who’s who. Oracle eliminated an estimated 30,000 roles, which make up around a fifth of its global workforce, in a single early-morning email.

Amazon worked through roughly 30,000 corporate cuts in rolling rounds. Block let go of about 4,000 people, close to 40% of the company, with Jack Dorsey pointing directly at the growing capability of AI tools.

So far in 2026, there have been more than 150,000 tech layoffs. (Image source: Trueup)

The reason given, again and again, is artificial intelligence. Not the economy. Not overhiring. The machines.

The line the press releases leave out

Here is the detail that should make you sit up. Amazon ran its cuts while AWS posted its fastest growth in thirteen quarters.

The cost line went down and a fast-growing business kept growing. On a spreadsheet that looks like genius.

The blunt version going around this year is that companies are firing people and buying GPUs with the savings. The savings look enormous when you only count your own ledger.

But the workers walking out of those buildings were also buyers. They bought software, subscriptions, flights, dinners, and the thousand small things that make up consumer demand.

When a firm removes a salary, it removes a sliver of the spending that every firm in the economy fishes from. The company that did the firing barely feels the loss to its own revenue.

That gap, between the saving you keep and the damage you cause, is the whole story. And a new paper has turned it into something close to a theorem.

Jack Dorsey’s interview with the Wired is worth reading. (Image source: Wired)

2. The Trap, Explained Without a Single Equation

The paper is called The AI Layoff Trap, by Brett Hemenway Falk and Gerry Tsoukalas. Its power is that it needs no villains.

It does not assume executives are reckless or greedy or high on their own forecasts. It assumes they are rational, clear-eyed, and able to see exactly what is coming.

But they drive off the cliff anyway.

Read the paper here.

You keep the savings, the whole economy shares the loss

Picture a sector with ten firms. One of them replaces a worker with AI. That firm pockets the entire cost saving.

Every cent of it lands on its own bottom line. So far, so obvious.

Now follow the lost wage. The displaced worker spends less, and that lost spending does not fall only on the firm that fired them. It spreads across all ten firms, because consumers buy from everyone.

So the firm that made the cut keeps 100% of the benefit and carries maybe a tenth of the cost. The other nine-tenths of the damage gets dumped on rivals.

Run that logic through every firm at once and you get a sector that is draining its own demand. Each company is acting sensibly.

Each is making a decision that improves its own numbers. And the sum of all those sensible decisions is a market that eats the customers it depends on.

Why seeing the cliff does not slow the car

You would think foresight would help. Surely if the boardroom understands the trap, it pulls back. The paper’s most uncomfortable result is that foresight changes nothing.

In economics terms, automating is a dominant strategy. That means it pays off no matter what your rivals do.

If they hold back, you grab the savings and the market share. If they automate too, you cannot afford to be the only firm carrying full payroll into a price war. Either way, you cut, and so does everyone.

In the cleanest version of the model, the whole thing hardens into a Prisoner’s Dilemma, the famous setup where two players each act in self-interest and both end up worse off than if they had cooperated.

This is what separates the trap from a simple coordination problem. You cannot fix it with a memo or a handshake or an industry summit where everyone agrees to be sensible.

The incentive to defect survives every conversation. A firm that promises restraint and then quietly automates wins. So restraint never holds.

Keeping workers protects demand, but each company has an incentive to automate before its competitor does.

3. The Finding That Should End the Workers-Versus-Bosses Fight

Most automation debates split neatly into two camps. Labor loses, capital wins, and the argument becomes about how much to tax the winners to help the losers.

This paper detonates that frame, and it does so with its single best result.

Everybody loses, including the people who own the firms

The over-automation in this model is not a transfer from workers to owners. It is pure waste.

The technical word is deadweight loss, and it means value that simply vanishes, claimed by no one.

Workers lose income, obviously, through the layoffs. But the owners lose too.

Once enough firms have cut enough demand, every firm’s profit falls below what it would have earned under collective restraint. The cost savings were real, and they still were not enough to offset the demand each firm helped destroy.

Sit with that. A profit-maximizing cartel, caring nothing for workers, would automate less than competing firms do.

The firms are not being cruel to labor and rich for it. They are being collectively stupid in a way that costs them money.

So in terms of politics, they do not need to care about workers to want this fixed. They only need to care about waste.

Payroll savings fail to compensate for the demand destroyed by widespread layoffs, leaving workers and owners worse off.

A monopolist would actually pump the brakes

This leads to the result that feels backwards until you trace it. A monopolist, the textbook villain, handles this problem better than a competitive market does.

The reason is that when one firm owns the whole sector, every dollar of lost demand lands back on that firm.

It cannot push the cost onto rivals because it has none. So it feels the full weight of its own automation and pulls back to the point that is actually best for it.

A crowded, competitive market does the opposite. The more firms there are, the smaller each one’s slice of the demand loss, and the weaker its reason to hold back.

Competition, the thing we normally trust to discipline companies into serving customers, is here part of what drives them to fire those customers.

That is not a comfortable sentence to read, is it?

Companies can see the cliff clearly and still keep driving because automation remains the rational competitive choice.

4. More Competition and Better AI Both Make It Worse

If the trap only bit in concentrated industries, there would be room to relax. It does the reverse.

The two forces we usually count on to save us, vigorous competition and rapid technical progress, both make the hole deeper.

The crowded market is the dangerous one

The size of the problem grows with the number of firms. The paper measures an over-automation wedge, the gap between how much firms automate and how much they should.

That gap widens as you add competitors, because each new rival shrinks everyone’s share of the demand they destroy.

So the most fragmented, most competitive sectors are exactly where this bites hardest. Think customer support, software services, back-office operations.

Markets with many players, all reaching for the same AI tools at the same moment, all able to pretend the demand damage is somebody else’s. The paper points to these as the places to watch, and the 2026 layoff data has been concentrated in precisely those areas.

The fingerprint to look for is strange and specific. Standard economics says cost-cutting technology should raise profits.

If profits erode at the same time as mass layoffs, in competitive sectors deploying the best AI, that pattern is hard to explain without this trap. One mid-June headline already read that companies cite AI but the cuts fail to boost returns. That is the signature, showing up early.

Faster AI digs a deeper hole

The optimist’s instinct is that better AI will grow the pie and fix the demand problem. The paper shows the opposite for the gap it cares about.

When AI gets more productive, each firm sees a fresh prize, the chance to grab market share by out-automating rivals. So they all push harder.

But at the finish line, when every firm has expanded equally, those market-share gains cancel out. Nobody actually pulls ahead.

All that remains is more automation, more displacement, and a wider gap between what firms do and what would be best.

The authors call it a “Red Queen effect”, after the character in Lewis Carroll who runs as fast as she can just to stay in the same place.

Original image of the “Red Queen’s Race”

The actual AI race is lopsided, with a few labs holding much better models. In a lopsided world the leader genuinely does capture ground, and the neat cancellation might break.

So treat “better AI makes it worse” as the strongest claim in the paper and the one most worth stress-testing.

5. Why the Comfortable Solutions Do Not Work

Here is where the paper earns its keep for anyone in policy. It walks through the popular fixes and shows most of them miss the target.

The trap lives at one specific point, the decision to automate one more task. Anything that does not touch that point does not work.

UBI raises the floor but never touches the brake

Universal basic income is the answer everyone reaches for, and the paper is brutal about it. UBI hands the same payment to the employed and the displaced alike.

It lifts the floor on everyone’s living standard. What it does not do is change the math of automating one more job.

The reason is technical but easy to feel. UBI moves the overall level of demand without changing the marginal decision.

A firm deciding whether to cut one more role still keeps the saving and still dumps most of the demand loss on rivals. The arithmetic of that single choice is untouched, so the automation rate stays exactly where it was.

The same logic sinks capital-income taxes. They scale profits up or down but cancel out of the decision that actually drives the layoffs.

This is a deflating insight for anyone who thinks a check in the mail solves AI displacement. UBI might be worth doing for other reasons.

It cushions the people who fall. It does not stop the pushing.

The one tool that hits the right nerve

After knocking down wage adjustment, free entry, upskilling, UBI, capital taxes, worker equity, and private bargaining, the paper is left with one instrument that works.

A Pigouvian automation tax.

The name comes from the economist Arthur Pigou, and the idea is the same one we use, in theory, for pollution.

A factory that dumps waste into a river enjoys the profit and leaves the cleanup to everyone downstream. A pollution tax says fine, keep producing, but pay for the harm you were offloading.

Applied here, the logic is identical. If a firm automates a job and pockets the saving while the lost wages drain demand across the economy, a tax claws back that unpriced damage.

The point is not to ban useful technology. It is to make the private calculation match the real one.

The human translation is simpler. If you insist on firing your customers, do not expect the rest of us to subsidize the experiment.

The catch is that his tax is clean in a model and very hard in the world.

It would require observing how much each firm automates, setting a rate from parameters nobody can measure cleanly, and stopping companies from simply moving the work offshore.

The paper gestures at carbon-style border adjustments as a fix.

That is a hope, not a finished mechanism. So the real takeaway is the shape of the right tool, not a bill you could pass next quarter.

6. The Catch That Keeps the Argument Honest

All of this can sound inevitable. It is not, and the place where the argument could break is the most important part to understand.

The paper rests on one number. Any view of the future should rest on it too.

It all comes down to whether people land somewhere better

The trap only springs if displaced workers do not get reabsorbed into decent jobs. The paper calls this the income replacement rate.

If laid-off people quickly find roles that pay as well or better, the lost demand comes back, and the whole mechanism flips. In that happier world, firms actually automate too slowly, and the right policy is a subsidy, not a tax.

History mostly sits on the happy side. Looms, tractors, spreadsheets, ATMs.

Every past automation panic eventually moved people into new and often better work. So the paper is really a bet that this time the transition is slow enough, or permanent enough, that the demand damage lands before the new jobs arrive.

That is a defensible bet about AI in particular. It is still a bet, and the model cannot tell you which world you are in. It only tells you what happens in each.

So far the early signs lean grim. There are hundreds of thousands of open AI roles, and the displaced workers mostly cannot cross the skills gap to fill them.

Displacement is hitting entry-level and middle white-collar work, the polished tasks people went to university to learn. The ladder into professional life is being pulled up with an email about efficiency.

The truth that should be hard to shake

The trap can be modeled with precision. It can be published, read, nodded at gravely, and sent to the Treasury.

And the march off the cliff can still happen in perfect formation, each firm congratulating itself on its discipline while the customer base quietly thins out beneath everyone.

The machines are not the danger here. The danger is a market that takes a genuinely brilliant technology and points it at its own foundation, one rational quarter at a time.

The question is no longer whether AI can do extraordinary things. It plainly can.

The question is whether the incentives can be changed before the market optimizes itself into something it cannot survive.

Everything You Need to Know to Master Claude's Fable 5

Ruben Dominguez — Tue, 28 Jul 2026 18:32:11 GMT

Every Claude Fable 5 guide follows the same script: learn the loop commands, build some skills, admire the vision demos, multiply your output by 10.

It is right about the features and wrong about where the difficulty lives. The proof sits inside the launch demo everyone shared and almost nobody read.

On June 9, Anthropic posted a timelapse of Fable 5 beating Pokémon FireRed on raw screenshots alone. No maps, no helper tools, no reading the game’s internal state.

The winning strategy is the funny part. The model pushed a single Charmander all the way into a level 78 Charizard, ignored type matchups entirely, and at one point wasted a Revive on a level 3 Pikachu mid-battle.

None of that was an accident. The goal said “beat the game,” so the model found the ugliest path that satisfied it and committed for hours without asking anyone.

That is the one lesson to carry through everything below. An autonomous model gives you exactly what you specified, at whatever cost the specification allowed.

together with Outskill:

Fable 5 can run for days on its own. The edge goes to whoever knows how to point it. This weekend, the world’s first Claude-athon condenses 800+ hours of research into a 16-hour live curriculum:

▫️ Master all three modes: Chat, Cowork, and Code

▫️ Set up Skills, Connectors, and plug-ins to automate your files, Notion, and desktop

▫️ Vibe-code apps plus 10+ tools that pair with Claude

Get AI equipped FREE !

Free, Saturday & Sunday, 10 AM to 7 PM EST.

This guide covers what the model actually is, what it costs, how to run work that finishes itself, how to teach it your procedures, what its vision is really for, and the fine print that most write-ups skip.

1. What Fable 5 Is, in Plain Language

2. The Price Sheet, and the Routing It Demands

3. Loops: How to Make Work Finish Itself

4. Skills: Teach the Procedure Once

5. Vision: The Most Underused Feature

6. The Fine Print, and the Habit That Ties It All Together

1. What Fable 5 Is, in Plain Language

Before the tactics, thirty seconds of orientation, because the naming alone has confused half the internet.

A new tier, not a new version

Fable 5 is the first public model in a capability tier Anthropic calls Mythos-class, which sits above the Opus line rather than replacing it. It shares its underlying model with Claude Mythos 5, a restricted sibling reserved for vetted cybersecurity and infrastructure partners.

Anthropic introduces Fable 5 alongside its restricted Mythos-class counterpart. (Claude on X)

The two names describe safeguard configurations, not different brains. Same model, different guardrails.

The headline ability is endurance. Anthropic built the model to sustain multi-day autonomous work: planning in stages, delegating pieces to sub-agents, and checking its own output along the way. It ships with a 1 million token context window and up to 128,000 output tokens per request.

What the safeguards mean for you

Because the capabilities cut both ways, Fable ships with safety classifiers that screen requests touching cybersecurity, biology, chemistry, and model distillation.

A flagged request is not simply refused. It gets answered by Claude Opus 4.8, the previous flagship, instead.

Anthropic reports this happens in under 5% of sessions, and rerouted requests are not billed at Fable prices.

For most people, most of the time, the safeguards stay invisible. What is very visible is the invoice, which is where this guide goes next.

Claude Fable 5 takes the top position in the Artificial Analysis Intelligence Index. (Image source: Caylent)

2. The Price Sheet, and the Routing It Demands

A guide that never mentions cost is an advertisement. The economics here are unusual enough to shape everything else you do with the model.

Three price tags, one decision

Fable 5 costs $10 per million input tokens and $50 per million output tokens. For orientation, a token is roughly three quarters of an English word, so a million output tokens is on the order of a long novel.

Claude Opus 4.8 runs at exactly half those rates, and Sonnet 5 sits at $2 and $10 under introductory pricing through the end of August. That makes the frontier model roughly five times the price of the mid-tier.

It earns the premium in one specific place. The price pays off on long-horizon autonomous work, and that the longer and more complex the task, the wider Fable’s lead grows.

Stripe’s early-access result shows the ceiling, where a migration across a 50-million-line codebase, compressed from an estimated two team-months into a single day.

Fable 5 shifts large migrations from weeks of manual work to autonomous execution and verification. (Image source: Espressio)

A routing rule anyone can apply

Here’s the rule to follow: expensive model at the edges, cheap models in the middle.

Fable plans the work at the start and verifies the result at the end, the two moments where judgment is worth paying for. Cheaper models grind through the long middle.

Everyday questions, quick drafts, and routine chat belong on Sonnet at a fifth of the cost, because putting them on Fable is paying limousine rates for a grocery run.

Popular guides dress this split up as a barbell strategy and sell it as an insider trick. It is plain arithmetic wearing a costume, and now you know the arithmetic.

The largest bills come from unattended runs, though, and controlling those starts with how the run gets instructed.

3. Loops: How to Make Work Finish Itself

The endurance only becomes useful once you stop feeding the model one prompt at a time. Inside Claude Code, two commands handle that, and they solve different problems.

Two commands, two different jobs

/goal sets a completion condition and keeps the model working, turn after turn, until the condition holds. Use it for bounded work with a clear finish line such as a migration, a refactor, a research question answered in full, a backlog worked down to zero.

/loop reruns a prompt on a schedule, every half hour or every morning, until you cancel it. Use it for watching and polling such as flagging the emails that genuinely need you, checking whether a deploy stayed healthy. It is the wrong tool for finishing a project.

A third piece completes the setup. Auto mode approves the model’s tool calls without pausing for your click, and pairing it with /goal is what makes a truly unattended run possible. Without it, your overnight job stalls at 2 a.m. waiting for permission.

Write conditions a machine can check

Here is the mechanism most guides skip. After every turn, a small fast model reads the conversation and returns a yes or no on your condition. That evaluator sees only what has surfaced in the transcript. It runs no commands and opens no files of its own.

So “the module is properly refactored” hands the judge a vibe, while “npm test exits 0 and git status is clean” hands it evidence, because the test output lands in the conversation where the evaluator can read it.

A condition that survives a long run carries four parts:

A measurable end state
A stated check that proves it
Constraints naming what must not change along the way
A cap on turns or time.

The cap is important because there is no built-in token budget. If you skip it, you’ll end up with a model looping for hours without progress, or an evaluator declaring victory over nothing concrete.

One practical trick before launching is to ask Claude to interview you and draft the condition itself, with follow-up questions until “done” is specific and measurable. It writes better conditions for itself than most people manage on the first try.

A condition governs a single run. The asset that compounds across every future run lives in a different file.

(Image source: Codez on X)

4. Skills: Teach the Procedure Once

A skill is a folder of instructions and reference material that teaches Claude a repeatable procedure. Think of it as a recipe you write once and reuse forever.

What goes in one, and how to start

Anything you do more than twice is a candidate.

Your weekly report format, a grant application structure, a trip-planning checklist, the house style your team writes in, the exact way you like meeting notes summarized.

Three starting points work well:

Turn a past chat into a skill by asking Claude to extract your preferences and patterns from a conversation where the output came out right.
Build one from scratch by listing what you do repeatedly and describing the steps.
Or build one from examples by feeding in a pile of work you admire and asking the model to codify its structure and tone.

Then refine it the way you would train a new colleague. That means by correcting the output, and folding the correction back into the file so the fix persists.

Why skills matter more on this model

Anthropic describes Fable as updating its own skills based on what it learns during work, and building its own checks and evaluations along the way. That turns skill-building from a documentation chore into a flywheel, because every completed run can sharpen the procedure the next run inherits.

The quieter advantage is ownership. Skills are plain files in a folder you control, welded to no vendor, and the same library can brief whichever model wins next year’s benchmark race. Models come and go on a release cycle. Your accumulated playbook only grows.

Procedures cover work that has a checklist. The next section covers verification for work that has to be seen.

Claude Skills turn repeatable procedures into portable workflows that improve with every run.

5. Vision: The Most Underused Feature

The launch coverage treated vision as demo material. In daily use it works more like a second pair of hands.

What it can read for you

Fable 5 extracts precise values from dense charts and scientific figures, which effectively turns a published graph back into a dataset.

It understands diagrams and tables nested inside PDFs, the daily terrain of finance, legal, analytics, and research work. And it can rebuild a working web app’s source code from screenshots of the interface alone.

So here’s the advice:

Stop retyping numbers from a report chart and photograph it instead. Screenshot the confusing dashboard, the dense form, the diagram in the appendix, and ask what it means. Hand it a picture of your slide, your layout, or your spreadsheet and ask what a careful reviewer would flag.

The self-checking trick

The key is what the model does with vision during its own work. Anthropic says Fable checks its coding output against the original design or goal, using its eyes as a critic rather than a camera.

That plugs directly into the loop mechanics we mentioned earlier.

A mockup image becomes an acceptance test, and a screenshot of the finished result becomes evidence the evaluator can judge inside the transcript.

Memory follows the same pattern. Given persistent file-based notes while playing the card game Slay the Spire, Fable reached the final act three times as often as Opus 4.8, which suggests the model genuinely uses the context you hand it rather than letting it pile up.

All of this is impressive, and none of it matters if the deployment never clears the fine print.

Claude Fable 5 becomes the most powerful card in the deck.

6. The Fine Print, and the Habit That Ties It All Together

Three constraints decide who can actually rely on this model, and none of them appear in the productivity threads.

1. Data retention

Fable and Mythos carry mandatory 30-day retention on all traffic, with no zero-retention option, even for enterprises that held such agreements before. Anthropic frames the window as a misuse-detection measure and says the data will not train models, but the practical advice holds for everyone: think twice before feeding it medical records, client files, or anything you would not want held for a month.

2. Refusal handling

Because the safety classifiers can decline a request, anything built on top of Fable needs a fallback plan for the moment it says no, whether that means a formal integration retrying on another model or simply your own workflow not assuming an answer always arrives.

3. Access

On June 12, days after launch, US export controls forced Anthropic to suspend the model for all users, and access only returned on July 1. Two weeks of a flagship tool vanishing overnight is the strongest argument in this guide for keeping your skills and context in portable files rather than inside any one vendor’s walls.

Now if you put all the pieces together, the whole guide compresses into one working habit.

Define done so precisely that a machine can check it. Demand proof in the transcript, not confidence in the summary. Route each job to the cheapest model that clears the bar. Read the terms before the first token streams.

The model supplies the endurance. You supply the definition of done. Every result you get from Fable 5, good or bad, will trace back to which of you did their job better.

Claude Cowork now runs a $10,000/month SEO agency from your desktop. Free with your plan

Ruben Dominguez — Mon, 27 Jul 2026 13:46:58 GMT

Something broke in search this year, and most businesses have yet to notice.

As of early 2026, Google’s AI Overviews appear on roughly half of all searches, by some measures over 60%. Google AI Mode passed one billion users. And ranking #1 no longer guarantees the click: queries with an AI Overview show a 30 to 50% drop in click-through for the top organic spot. If your brand is not one of the two or three sources cited inside the AI answer, you did not lose a ranking. You vanished from the conversation before a single click happened.

Here is the part that changes your week. The agency work that used to cost $5,000 to $10,000 a month to keep up with all of this, competitor analysis, technical audits, keyword research, AI-search optimization, now runs inside an agent you already pay for.

I spent the last week stress-testing every SEO and AI-search workflow I could push through Claude Cowork, and the numbers moved how I think about execution entirely:

▫️ Competitor analysis that took 3 to 4 hours: done in 12 minutes

▫️ Technical audits that needed a $200/month tool and a specialist: one prompt

▫️ Keyword research a junior analyst spends a full day on: finished before my coffee got cold

The output quality is on par with what mid-tier agencies bill $5K to $10K a month to deliver. Below are the 15 prompts that make up the full operation, organized into six categories, plus the AI-search layer almost nobody has built yet.

Quick context, since Cowork changed a lot this year. It is not a chatbot. It went generally available on April 9, 2026 as an autonomous agent living inside the Claude desktop app. You give it a task, point it at a folder or a website, and it executes: it reads files, opens Chrome, visits pages, runs analysis across tabs, and ships structured outputs like spreadsheets and reports, locally on your machine. It is included on every paid plan, Pro ($20/mo), Max ($100-200), Team, and Enterprise, on Mac and Windows, with Dispatch now letting you fire tasks from your phone that run on your desktop.

Behind the paywall, the complete Cowork SEO Operating System:

▫️ 15 copy-paste prompts across research, keywords, technical audits, content, local, and reporting
▫️ The AI-search layer, the prompts that get you cited inside AI Overviews, AI Mode, Perplexity, and ChatGPT, where half of search now lives
▫️ Two keyword workflows, one for local and service businesses, one for SaaS and online, both aimed at revenue over vanity metrics
▫️ The technical audit stack, site health, schema with JSON-LD generation, and internal linking, the diagnostics agencies charge $2K+ for
▫️ The E-E-A-T scoring prompt, graded against Google’s current Quality Rater Guidelines
▫️ The competitor backlink-to-outreach engine, a 90-day plan reverse-engineered from their link profile
▫️ The monthly reporting framework, reusable, so the whole system compounds

One subscription unlocks every system

This is one build in a growing library. Premium opens all of them:

Plus 3 fresh systems every week. One audit you skip paying an agency for covers the subscription for years.

🔍 The Cowork SEO Operating System

15 prompts, the AI-search layer, the audit stack, and the reporting framework, in one system.

Get The Cowork SEO Operating System below 👇

38,000 companies are hiding in plain sight. Here is the AI system to find them

Ruben Dominguez — Sun, 26 Jul 2026 16:07:07 GMT

In 1969, a man who rented out funeral-home limousines at night bought Warner Bros.

Steve Ross paid the equivalent of $3.5 billion in today’s dollars for one of the great movie studios. He funded it with the most boring companies imaginable: parking lots, rental cars, cleaning, plumbing, flooring. None had a moat. Any competent operator could have bought the same businesses.

Almost nobody did.

By 1990, Ross took home a $78 million pay package, the largest of any executive in America that year, built on a foundation of parking garages.

That is the puzzle. And it pays better today than it did then.

Take Constellation Software. Since its 2006 IPO, it has compounded returns at roughly 34% a year, over 16,000% cumulatively. Berkshire Hathaway managed about 11% a year over the same window.

How? By buying software nobody wanted: marina management, ski-lift ticketing, library cataloging. Deal sizes often under $5 million. It has bought 800+ of them, generates $8.4 billion a year, and estimates 38,000+ more are still out there.

Read that last number again. Thirty-eight thousand. One acquirer, one narrow slice of one industry.

These companies share a single trait, named in a July 2026 essay by strategy scholars Jay Barney, Haiyang Zhang, and Jerry Neumann: they are invisible. Not protected by patents, scale, or secrets. Just unnoticed.

The data hides inside sector averages. The companies sit outside the networks where investors trade ideas. The whole category reads as too small, too boring, or too low-status to bother with.

Nobody looks, so nobody competes. Nobody competes, so the profit persists.

The reward for being overlooked is the profit itself.

Here is the free insight, and it is the exact tension those authors end on: AI could kill invisibility, or hardcode it deeper. If every investor’s models train on the same datasets and the same “big market, fast growth, novel technology” frameworks, the blind spots get baked into the machine and the neglect gets worse. Which flips the whole game. The edge no longer goes to whoever has the best data. It goes to whoever points AI at what the consensus screens out.

Almost nobody has built that system. Below is the one I would run, seven prompts and a weekly loop that turns a laptop into a sourcing desk aimed at the profit hiding in plain sight.

Behind the paywall, the complete Invisible Company Finder:

▫️ The four-mechanism map, the exact reasons companies stay invisible, each turned into a place to hunt
▫️ The de-aggregation prompt pack, copy-paste prompts that split a boring sector average into the high-margin niche hiding inside it
▫️ The inverted screen, the filter that hunts for shrinking, un-advertised, and stigmatized markets on purpose
▫️ The supplier-cloud mapper, the workflow that surfaces the small essential vendors around any public company, exactly how HEICO built billions
▫️ The geographic-blindspot finder, how to reach the profitable operators nobody in your network has ever met
▫️ The competitive-neglect scorecard, rate any target 0 to 12 on how invisible, and therefore how defensible, it truly is
▫️ The roll-up thesis builder, turn a found niche into a one-page memo an investor would fund
▫️ The un-cloaking watchlist, the four signals that a hidden market is about to go visible, so you move before the crowd
▫️ The weekly hunt loop, the full sequence, run in about an hour

One subscription unlocks every system

This is one build in a growing library. Premium opens all of them:

Plus 3 fresh systems every week. One sourced deal pays the subscription back for life.

🔍 The Invisible Company Finder

The four-mechanism map, seven copy-paste prompts, the neglect scorecard, the thesis builder, and the weekly hunt loop, in one system.

Get The Invisible Company Finder below 👇

Try premium free for 7 days. Or get 50% off this week only.

AI Made Bug Bounties a Six-Figure Skill Overnight

Ruben Dominguez — Sat, 25 Jul 2026 14:52:48 GMT

Google paid $17.1M in bounties last year and just opened an AI-only program. One person with the right stack now audits 50,000 lines a day. Here is the entire playbook.

The top bug bounty hunter at Google made $811,000 last year.

He did not build a product. He did not raise a round. He read other people’s code and told them where it was broken, and Google paid him more than most funded startups will ever earn.

Now hold that next to this: every AI company on Earth is shipping agents, MCP servers, and LLM APIs faster than anyone can review them, and almost none have been audited. The money is sitting there. The attack surface is wide open. And the security community has yet to show up.

That is the gap. This is the playbook to walk into it, the legitimate way.

Behind the paywall, the full AI Security Researcher Playbook: the exact tool stack, the six-step target-to-payout workflow, a copy-paste review prompt library, the five categories paying the most against the weakest competition, the honest month-by-month money math, and the ladder from first $200 finding to $50K AI-security engagements. It is the difference between reading about this and doing it by Friday.

One subscription unlocks every system

This is one build in a growing library. Premium opens all of them:

Plus 3 fresh systems every week. One reported medium-severity finding pays the subscription back for a decade.

🛡️ The AI Security Researcher Playbook

Inside, the complete system:

▫️ The routed tool stack, which model does reconnaissance, which does deep review, which writes the report, and the free tools that confirm findings

▫️ The target-to-payout workflow, the exact six-step system you run on every authorized target

▫️ The review prompt library, copy-paste prompts for the highest-value vulnerability classes, each ending on the fix

▫️ The five highest-ROI target categories, where the payouts are biggest and the competition is thinnest right now

▫️ The money math, a realistic month-by-month path from $600 to $30K a month, with zero hype

▫️ The scale-up ladder, how bounties become consulting, retainers, and $10-50K AI-security audits

▫️ The responsible-disclosure rulebook, the authorization and reporting standards that keep this legal and lucrative

▫️ The tonight checklist, the precise steps to run your first authorized review this week

Get The AI Security Researcher Playbook below 👇

Anthropic just cut the price of frontier intelligence in half

Ruben Dominguez — Fri, 24 Jul 2026 18:48:34 GMT

Anthropic shipped Claude Opus 5 today, and the headline number is the one they refused to raise.

The price.

Same $5 in, $25 out as Opus 4.8. Half of what Fable 5 charges. And the performance sits close enough to the frontier that the tier below it just became the default for almost everyone:

▫️ Frontier-Bench v0.1: 43.3%, against Opus 4.8’s 18.7% and Fable 5’s 33.7%

▫️ CursorBench 3.2: within 0.5% of Fable 5’s peak, at half the cost per task

▫️ ARC-AGI 3: three times the next-best model, on a test built so memorization fails

▫️ OSWorld 2.0: past Fable 5’s best result at a third of the cost

The customer numbers hit harder than the benchmarks. Harvey matched Opus 4.8’s max-reasoning quality using 26% fewer tokens. Zapier’s churn workflow went from failing every prior model to 100%. A trading firm hit its best Opus score on a seventh of the reasoning tokens.

Here is the free insight: this is a price-per-outcome launch wearing a model launch costume. Anthropic held the sticker price flat and moved everything underneath it. Intelligence up, tokens down, safety blocks down 85%, speed up 2.5x in Fast mode. Your bill for the same work drops even though the price page stayed identical.

That only happens if you drive it correctly. Most people will run it on defaults and leave the upside sitting there.

Behind the paywall, The Opus 5 Playbook:

▫️ The effort dial, what each setting costs and returns, and why running max is the standard way to overpay
▫️ The routing table, what goes to Opus 5, what stays on Fable 5, what drops to Sonnet
▫️ The cost math, worked examples on an $8K monthly bill
▫️ Six copy-paste prompts built around the one behavior every early tester named
▫️ The two beta features agent builders should care about more than any benchmark
▫️ The safeguards map, what opened up, what stays blocked, how the fallback works
▫️ The migration checklist, by source model, with your loops intact
▫️ The eval protocol and the honest limits, including what still belongs on Fable 5

One subscription unlocks every system

This is one build in a growing library. Premium opens all of them:

▫️ The Claude and Anthropic library

Plus 3 fresh systems every week. One correctly set effort dial pays the subscription back inside a week.

🧠 The Opus 5 Playbook

The effort dial, the routing table, the cost math, six prompts, the migration checklist, and the honest limits, in one system.

Get The Opus 5 Playbook below 👇

Try premium free for 7 days. Or get 50% off this week only.

Yang Zhilin's Agent Playbook: 10 Bets Founders Should Steal

Ruben Dominguez — Thu, 23 Jul 2026 14:21:02 GMT

Claude is not the best reasoner in the room. It is one of the best agents in the room.

Two different capabilities, built two different ways, and almost nobody outside a handful of labs treats them as separate.

Yang Zhilin runs Moonshot AI, the lab behind Kimi K3.

A year ago he compared the company to climbing an unknown snowy mountain in the dark.

I read the full 90-minute interview so you can skip it. Here are the 10 that matter.

Speaking of agents that work while you focus:

Granola is the one I use for every meeting.

It transcribes straight from your computer audio across Zoom, Meet, Teams, even in person. Your call stays exactly as you planned it: just the people in it.

▫️ Only humans on screen, so the conversation flows without an extra participant in the room
▫️ You stay present and take rough notes; Granola turns them into clean summaries with next steps
▫️ Chat with your notes afterward to pull exactly what you need

Try it in your next meeting:

Download Granola FREE

→ code THEAICORNER for 1 month off !

1. Claude's secret weapon isn't reasoning at all

Everyone assumes the best AI product needs the best reasoning model underneath it. Claude breaks that assumption.

“Cloud’s reasoning performance is not very high, but its performance as an agent is very high.”

Reasoning and agentic ability come from two separate technical paths. One scales by making the model think longer in isolation. The other scales by letting the model act, get feedback from a live environment, and act again. Claude leans into the second path. It talks to tools, runs code, and checks its own output against the world instead of its own head. That is a deliberate bet, over a limitation.

Why it matters: stop treating reasoning benchmarks as the whole scoreboard. An agent that iterates against live feedback beats a smarter model that only thinks, the entire premise behind building agents that ship work instead of just answering.

2. The brain in a tank problem

Yang has a mental model for why some AI products look smart in a demo and collapse in production. He calls it the brain in a tank.

“It does not need to interact with the outside world. It is like a fish tank. You put a brain in it. It has no connection with the outside world.”

A pure reasoning model sits in that tank, thinking and thinking, touching reality only when it hands you a final answer. An agent breaks the glass: it searches, writes code, reads the result, and adjusts its next move on what just happened. Both approaches scale the same resource, the tokens the model gets before it commits, one by thinking longer, one by acting.

Why it matters: if your product only reasons and never checks its work against the world outside it, you built half an agent. The other half is the loop that lets it act, verify, and correct.

Together with Granola:

The human version of the brain in a tank: you leave a meeting and forget half of what you agreed to.

Granola turns your rough notes into clean summaries with actual next steps, so “we should probably...” becomes “ok, done.”

Try it Free !

→ code THEAICORNER, 1 month off

3. The optimizer nobody was using that doubled their data

For a decade, nearly every large model on Earth trained on the same optimizer. Moonshot decided that was the industry’s biggest blind spot.

“If you learn a piece of data, it is equivalent to learning two pieces of data from Adam.”

The optimizer is Muon, originally proposed by a researcher named Keller. Adam has powered nearly every major model since transformers took over, treating each parameter independently. Muon accounts for dependencies between them, and that difference compounds. The payoff is token efficiency: more intelligence extracted from the same data, rather than more data. 30 trillion high-quality tokens behaves like 60 trillion.

Why it matters: watch which labs publish optimizer research instead of parameter counts. That is where the next true gap opens, and where a smaller team out-builds a larger one on the same budget.

4. Why AGI will have no finish line

Ask most people to define AGI and they picture a single moment. A switch flips. Yang rejects that entirely.

“AGI may be a direction. It may not be a certain step. When you climb this step, you suddenly reach AGI overnight.”

He points to math competitions and programming contests where models already beat 99% of humans. Those wins arrive piecemeal, one benchmark at a time. He compares it to the steam engine: the mechanical breakthrough came fast, and the economic reorganization took a century, the same lag Demis Hassabis maps onto the next few years.

Why it matters: a roadmap built around “reaching AGI” optimizes for a headline. A roadmap built around crossing specific capability thresholds, one at a time, optimizes for what is actually happening.

5. The infinite mountain, and why he hopes it never ends

His interview a year ago introduced a metaphor about climbing an unknown snowy mountain. This year he pushed it further than most founders would dare.

“Maybe this snow mountain has no end. I don’t know. I hope it has no end.”

He is reading The Beginning of Infinity and pulls two lines he says should be carved in stone: the problem is inevitable, and the problem can be solved. Before the scientific revolution, societies stayed static, explaining thunder as anger and expecting no better. Science broke the cycle: every solved problem created a new one, and the cycle became the point. He applies the same frame to Moonshot, where solving reinforcement learning’s current limits just uncovers the next layer.

Why it matters: a roadmap with a finish line where the hard problems stop is a roadmap that ages badly. Treat every solved problem as a new frontier.

6. Running a company is reinforcement learning, not fine-tuning

Halfway through, Yang makes a jump most CEOs skip saying out loud: managing people and training a model are the same discipline.

“The biggest problem with the RL management team is that you are easily hacked. This is the reward you hacked.”

Supervised fine-tuning means telling someone exactly what to do. Reinforcement learning means giving them a reward signal and letting them find their own path. Too much instruction and a team loses the ability to innovate. Too little and people optimize the metric over the goal, the classic reward-hacking trap. He admits he has yet to solve the balance, and is still learning it live, in the moment.

Why it matters: the same reward-hacking failure that breaks a model breaks a team. If people hit targets and the company still fails to improve, audit the reward, over the people, the discipline behind every one-person operation that scales cleanly.

7. Why K2 isn't even the company's biggest bet yet

The name K2 was deliberate. Yang picked the second-hardest mountain on Earth on purpose, and he is explicit that it still sits below the peak.

“K2 may be the most difficult peak in the world. It just so happens that this name is a bit confusing.”

He describes the model as the product of a genuine shift, from conversational systems to agentic ones, on a base that keeps growing in scale. Hard to climb, and still shorter than Everest. The result mostly matched what the team predicted, aside from one training instability that only surfaced at full scale, exactly the kind of thing smaller experiments miss.

Why it matters: the hardest technical milestone a company hits rarely doubles as its final form. Treat a breakout product as proof of capability, over proof you are done.

8. The data wall exists, so why is everyone still accelerating

Every serious lab hit the same wall: high-quality training data is growing too slowly to keep feeding bigger models. Yang confirms it, then explains why progress kept accelerating anyway.

“Scaling load has a data wall. I think this is an objective fact.”

The workaround is squeezing more intelligence out of existing data through better optimizers and more efficient RL, with compute flowing into reinforcement learning over pretraining. RL is on-policy: the model learns from samples it generates itself instead of a fixed dataset, which gives it higher scaling efficiency for now.

Why it matters: labs shifting compute toward RL and token efficiency keep improving after the data wall stalls everyone betting purely on pretraining scale.

9. Coding agents are just the fingertips

Coding is the easiest task to verify, which is exactly why every lab raced there first. Yang treats stopping there as a trap.

“It is like a human hand. It is a fingertips of a task.”

Code checks itself: tests pass or fail, which makes it the ideal training ground for RL, and explains why coding agents improved faster than any other category this year. But lawyers, PMs, and designers already use coding tools for work that has nothing to do with software, because code is the universal language for automating anything digital. The target is a general agent that happens to be excellent at coding, over a coding tool that happens to answer other questions.

Why it matters: a leader in coding agents is not automatically a leader in agents generally. Ask what happens to that moat once general models close the coding gap.

10. AI won't destroy civilization, here is what it takes instead

Near the end, the interviewer raises the existential question every AI founder faces. Yang’s answer is sharper than the usual hedge.

“I don’t think so. First of all, you can’t say that there is no risk. But we can do a lot of things.”

He frames AI as a magnifier for human civilization, over a replacement. Learning a subject from scratch takes a person twenty or thirty years; AI compresses that, putting the next wave of scientific breakthroughs stacked on AI-assisted research. He splits human meaning into three: creation, experience, and love. He expects AI to absorb most creative work over time, and to leave the other two alone. The economic transition takes years, over months, and requires society to rebuild how people capture value.

Why it matters: the risk conversation usually splits into extinction versus nothing. Yang’s position is narrower and more useful: genuine risk, survivable risk, a multi-year transition companies should plan for now.

The Kimi K2 Principles to Steal

Yang’s thesis across ninety minutes: intelligence scales along two separate axes, thinking longer and acting more, and the companies that grasp this out-build the ones chasing reasoning benchmarks alone.

▫️ Founders: stop treating reasoning scores as the whole scoreboard. Build for agentic feedback loops, tools, environments, and verification, even where your raw reasoning lags the leader. Remove any hidden “AGI finish line” from your roadmap.

▫️ Investors: the next moat is token efficiency and optimizer research, over model size. Shift diligence from parameter count to training efficiency.

▫️ People in tech: the coding-agent wave you are riding is a fingertip, over a hand. Build products that generalize past code execution before the category commoditizes.

▫️ Everyone else: map which parts of your work fall into creation, experience, or connection now, over after the shift lands.

The five lines to keep:

Reasoning and agentic ability are different bets. Know which one your product actually needs.
Token efficiency beats data volume. The data wall exists. The workaround is optimizer research.
Treat every solved problem as a new frontier. There is no finish line, and pretending there is one costs you.
Manage teams like reinforcement learning, not supervised fine-tuning. Watch for reward hacking in both.
Coding is the easiest agent category to verify, not the hardest to build. Skip mistaking speed for depth.

The problem is inevitable. The problem can be solved.

Keep climbing.

Keep reading

More masterclass breakdowns

▫️ Demis Hassabis says AGI arrives in 2 to 5 years

▫️ Dario Amodei’s full picture: 10 takeaways

▫️ Jonathan Ross and the $20B NVIDIA deal

The Kimi stack

▫️ The Kimi K3 Playbook

▫️ The Self-Evolving Agent Stack

▫️ The token-cost optimization playbook

Build with the ideas

▫️ Your GTM, run by agents

▫️ What top VCs look for in 2026

Google just made agents 3x cheaper to run. Here is the playbook

Ruben Dominguez — Wed, 22 Jul 2026 16:32:45 GMT

On Monday, Google shipped the least glamorous release of the year, and the one most likely to change your infrastructure bill.

No new flagship. No frontier score. Instead, three Flash-tier models built for one job: running agents at scale, cheaper. And the numbers underneath are the kind that rewrite unit economics without a headline:

▫️ Gemini 3.6 Flash ships 17% fewer output tokens than 3.5 Flash at a lower price. Artificial Analysis measured cost per task falling from $0.59 to $0.50, and time per task dropping from 2.7 minutes to 1.3.

▫️ Gemini 3.5 Flash-Lite runs at 350 tokens per second, the fastest model Artificial Analysis clocked at launch, for $0.30 in, $2.50 out.

▫️ Gemini 3.5 Flash Cyber, a defensive security model gated to governments and trusted partners, found 55 confirmed vulnerabilities in the V8 JavaScript engine against Claude Opus 4.6’s 36.

3.6 Flash is barely smarter than the model it replaces. Its composite Intelligence Index sits at 50, the exact same score as 3.5 Flash. Google spent this release cycle making the model cheaper, faster, and more token-efficient instead of smarter, on purpose. Tulsee Doshi, who leads Gemini product, said it plainly: developers building production agents need “higher token efficiency, lower latency, and more reliable performance,” over another benchmark point.

Which reframes the whole thing. The win here is operational rather than intellectual, and it only shows up if you route correctly, migrate cleanly, and stack the cost levers Google buried in the docs. Get it right and the same agent workload costs a fraction of what it did Friday. Get it wrong and you leave most of the savings on the table.

⚡ The Gemini Flash Agent Playbook

The routing table, the migration steps, the cost math, the cost levers, and the Cyber guide, in one system.

Get The Gemini Flash Agent Playbook below 👇