Everything It Touches

Many AI videos start with noise like this. Static.

A model cleans it up, step by step, until it looks like a city.

Or a person who never existed.

It's astonishing. But it's a guess.

A brilliant guess about what pixels usually look like.

The video this episode is about didn't start as noise.

It started as code, and an AI wrote that code.

Every picture in it is computed:

the gravity, the color, the timing of every beat.

And even the static comes out the same every time.

This is Everything It Touches, the podcast. I'm Augusto.

On the channel, we make short videos about what AI is changing.

Here, we slow the same story down,

so there's room for the parts a video has to rush.

That cold open is a picture in the video.

Blue-grey static fills the screen.

A little counter ticks through steps, and the noise turns into a skyline,

then into a face, both labelled "illustration".

Then the static collapses into one line of green code,

and a ball starts falling, leaving a trail of dots behind it, one per frame.

Two ways to make a moving picture.

Today I want to take them apart slowly:

where the guess is wonderful, where it breaks,

and what changes when the picture is calculated.

And I'll show you our own mistakes, because that's the point.

The big names right now include Google's Veo and Gemini Omni.

And platforms like Higgsfield put dozens of models in one place.

Higgsfield lists more than thirty.

Veo is a diffusion model.

Here's how Google describes it, in Veo 3's model card.

“Veo 3 utilizes latent diffusion,

which is the de facto standard approach for modern image,

audio, and video generative models.”

That's Google's own description of the field.

It isn't a survey of every model.

Gemini Omni, for example, is described as a transformer,

and Google hasn't said how it samples.

So I won't call it diffusion.

Here's the idea behind diffusion.

In training, real clips are compressed into numbers and buried in Gaussian noise,

a very particular kind of random static.

A network learns to dig the clip back out.

To make something new, you hand it fresh noise and a prompt, and you let it dig.

A procedural video runs the other way. Nothing is predicted.

Everything is calculated.

A program draws each frame as a function of time. Frame one.

Then a thirtieth of a second later, frame two.

The ball is where the equation puts it.

The green is a number in the code.

And an AI coding model wrote that program, from my descriptions.

So both of these are AI. One kind of AI paints the frame.

The other writes the rules that draw it.

And the rules still need checking.

So how good is the guess?

Researchers at Google DeepMind built a test called Physics-IQ.

They filmed real experiments, sixty-six scenarios of them:

collisions, pouring water, light, magnets.

Then they asked video models to continue the footage.

The score is clever.

A hundred doesn't mean a hundred percent correct.

It means as consistent as filming the same experiment a second time.

Real life is a little random, too, and the score is set against that.

In early twenty twenty-five, the original Sora scored ten.

Sora two reached forty-two.

The top entry on that board reaches the mid-sixties, but it gets more help.

It sees several frames, not one,

and a second system picks the most plausible of sixteen tries.

Real progress. Still a long way from a camera.

There's also a revised, independent version of the test, called Physics-IQ Verified.

Different people changed the prompts and the scoring,

and Google DeepMind doesn't endorse it,

so its numbers don't line up with the original board.

On it, Google's Gemini Omni one point one Flash scores about thirty-five.

The top single-image entry there, on October fourth, was at about forty-eight.

The original authors, Motamed and colleagues, put their conclusion in one line.

“visual realism does not imply physical understanding”

A team from UCLA and Google Research built another test, VideoPhy two.

Here's what they wrote about the models they tested.

“models particularly struggle with conservation laws like mass and momentum”

Picture water appearing from nowhere in a glass.

Or a ball that forgets how fast it was going.

And researchers at ByteDance, with coauthors from Tsinghua and the Technion,

trained video models on clips from a simple two-dimensional physics simulator.

In familiar conditions, the models did well.

Outside them, they mimicked the closest example they'd seen.

And they matched on color first, then size, then speed, and shape last.

That's a controlled study, not a law of nature.

But it's a good picture of what a guess is.

Now watch what happens when the physics is computed instead.

Well, listen.

In the video, a green ball falls under standard gravity,

nine point eight one meters per second squared, with no air resistance.

So its path is a true parabola.

Two discs collide, and a momentum meter beside them doesn't move.

The code gives each one an equal and opposite push, so the total stays the same.

Then sunlight enters a raindrop.

It bends, reflects off the back, and bends again on the way out.

Our code traces the rays.

Red comes back at forty-two point four degrees from the point opposite the Sun.

Violet, at forty point six.

That's why red sits on the outside of the rainbow.

Descartes published his rainbow calculation in sixteen thirty-seven,

in a book called Les Météores.

He traced the light through a drop, ray by ray.

Our code repeats his method, with modern numbers for the colors.

Now two tiny double pendulums, each rod two and a half centimetres long,

started a billionth of a degree apart.

For a moment, they move as one.

About four seconds later, they're strangers.

That's chaos. And here's the beautiful part.

It's still deterministic.

Run the same code again, with the same settings, and you get exactly the same chaos.

Edward Lorenz ran into this in a weather simulation.

He restarted a run from a printout that had

rounded his numbers to three decimal places.

By the second simulated month, the weather no longer resembled the original.

That idea became known as the butterfly effect:

tiny differences, huge consequences.

A video model has to learn chaos from examples.

A simulation produces it from the equations.

Color works the same way.

In this video, green isn't "a bright green". It's a number.

A three E six three five.

Image models have struggled with numbers like that.

A study published in March, called NumColor,

found that text-to-image models struggle to interpret hex codes.

Part of the reason:

the code gets chopped into fragments that don't reliably convey a color.

Their fix made numeric color four to nine times more accurate,

on their benchmark, across five kinds of model.

In code, the color is never a guess. Is it perfect? No.

On the way to you, a highlight curve we chose softens the brightest channel.

When I measured a frame, our green came out at A three E five three five.

One step, in one channel.

The green went from two hundred thirty to two hundred twenty-nine.

An error I can point to. The video codec can shift it again.

But every step is written down, so I can see exactly where the color moved, and why.

For a brand, that's the difference between hoping and knowing.

Now sound.

Some of the newest models generate sound and picture together, and it's impressive.

But a benchmark published in April measured the gap.

On average, sound and picture were off by a

fifth of a second to almost half a second,

depending on the model.

And lips missed the speech by two to more than five frames.

In our video, the voice comes first. The picture follows it.

The voice service reports a time for every character,

and every beat on screen is cued from those times.

Those times are an estimate, so we check them.

When I say now, something moves.

Was it perfect out of the box? No.

Earlier takes had word times up to six tenths of a second early.

We measured it, and added a correction in code.

And we still listen.

The mix is measured, too. Loudness at minus fourteen LUFS,

peaks kept under a ceiling, and the report has to say pass.

Any video can be measured.

But because every frame here is computed, every frame can be traced back to a line.

Before delivery, a script reads every one of them, more than fifteen thousand,

counting the series intro,

and it fails the film if the brightness spikes and drops back.

That's our flash rule.

If the screen gets much brighter within a quarter of a second,

and much darker again within half a second, it fails.

It's our own rule, not a medical certificate.

But it's a number, not a feeling.

When a check fails, I change the line that caused it.

I don't reroll and hope.

Google's own documentation says a Veo seed doesn't guarantee the same video.

It only slightly improves repeatability.

And because the whole shot is conditioned on the prompt,

change one word, and the whole shot can change.

In code, I change one number, and only what depends on it moves.

And tools can disappear.

On September twenty-fourth, OpenAI shut down the Sora two API.

Our film is source code, a voice and a score,

saved as files on my own computer, and it renders there.

Then there's cost.

On October fourth, Google's own price list had Veo three

point one Standard at forty cents a second at ten eighty pee.

Nine minutes comes out to sixty-eight eight-second clips.

That's more than two hundred dollars, before a single retry.

The cheaper Fast and Lite tiers would be about sixty-five dollars,

or about forty-four.

Our pictures have no per-second bill.

I pay for the voice, the music and the coding model.

And the computer, and my time.

So is computed always better? No.

A rainy street in Lisbon. A face that feels alive.

A dog catching a frisbee. Diffusion wins, easily.

Faking that in code would be a visual effects studio's job.

A prompt also gets you a first look in minutes.

Procedural wins when the picture has to be right.

Explaining, teaching, data, physics, a brand.

For a face, I'd ask a model.

For an answer key, I'd ask for code.

And the two worlds are starting to help each other.

In September, researchers studying whether video models

understand that a hidden object still exists released,

they say, a hundred and fifty procedural scene

generators and a million and a half clips.

That color study trained its fix on half a million rendered images.

When researchers need an answer key, they compute it.

Another team has a coding agent write a simulation first,

then lets a video model paint over it.

Physics from code, looks from diffusion.

Even then, the final pixels can still break the rules.

And in one small study, with six middle-schoolers in each group,

students scored about as well on quizzes after explainers that agents wrote as code,

about eighty-eight, as after 3Blue1Brown's, about eighty-six.

Small study. Not proof they teach equally well.

But interesting.

So, honestly. What in the video is AI?

The voice is an AI clone of mine.

The music was generated by an AI model, in sections that follow the chapters.

The code that draws every frame was written with an AI coding model,

from my descriptions, and AI helped write the checks.

The pixels are the part that isn't generated by a video model.

They're computed.

Remember the static at the start? Computed.

Same noise, every render. In the video, it plays twice,

and a little chip shows the same fingerprint both times.

One kind of AI dreams a world that looks right.

The other writes down the rules, and lets the world follow.

And here's the astonishing part.

Not that code is always right. It isn't.

It's that when it's wrong, I can find the line, and fix it.

This video didn't start as noise. It started as a sentence.

A model turned the sentence into code, and the code into physics.

The short version, with the raindrop, the pendulums and the one-step green,

is on the Everything It Touches channel, called "This Video Didn't Start as Noise".

And I'd love to hear your answer to the question it ends on:

what would you never let a model guess?

Tell me in the comments.

The sources are in the episode notes.

The quotes were read by AI voices, not by the people who said them.

This podcast was made with code, at procvideos dot com.

My voice is an AI clone, and the music is AI-generated.

Thanks for listening.

Right now, you're running about seventy changes

to your source code that nobody ever reviewed.

Brand-new mutations that neither of your parents had.

No pull request. No approver. No "looks good to me."

And yet here you are.

The most complex system you will ever own, listening to a podcast about software.

In the next few minutes, I want to convince you of something.

The way nature builds complex things is about to become the way we build software.

And the pull request, as we know it, is dying.

This is Everything It Touches, the podcast. I'm Augusto.

On the channel, we make short videos about what AI is changing.

Here, we slow the same story down,

so there's room for the parts a video has to rush.

A quick word on that first number.

In the video, it's a long strip of genetic

letters with about seventy of them glowing red,

and a little label that says "zero reviewers".

It comes from a big study in Nature, in twenty seventeen,

that read the genomes of more than fifteen hundred families, parents and child.

On average, each child had about seventy new mutations.

Changes nobody signed off on.

Hold on to that picture.

We'll come back to it at the very end.

Here's what changed.

AI agents now write code faster than any human can read it.

At Anthropic, the company that makes Claude,

more than eighty percent of the code that got merged in May was written by Claude.

And in the same report, the company says it plainly:

human code review has become a new bottleneck.

Faros, a company that studies engineering teams,

looked at twenty-two thousand developers.

Where AI adoption was high,

the typical review took about five times as long as where adoption was low.

That's a correlation, not proof of cause.

But it's the direction everyone describes.

David Heinemeier Hansson, the creator of Ruby on Rails,

posted about it in September.

“there's no future where you're manually reviewing every line of agent code”

Then, on September first, GitHub let its Copilot assistant approve pull requests.

In the video, this is an approval icon that

morphs from a little person into a little robot.

That approval can now count toward rules that used to require a human.

It's off by default, and still a preview. But it exists.

And one researcher, Martin Monperrus,

published a paper in June with a title that doesn't leave much room:

"The End of Code Review:

Coding Agents Supersede Human Inspection."

So if nobody can read it all, who decides what ships?

You might say: but review is what keeps the bugs out.

Take it away, and everything breaks.

Here's the uncomfortable part.

That was never its main job.

In twenty thirteen, two researchers at Microsoft,

Alberto Bacchelli and Christian Bird,

did something nobody had done carefully before.

They took five hundred and seventy real review comments

and sorted them by what they were actually about.

In the video, you see five hundred and seventy little chips flying into nine bins.

Listen to where they land.

When you ask developers why they review code, finding bugs is the number one answer.

But only seventy-eight of those comments,

about fourteen percent, were actually about a defect.

It came fourth of nine.

The biggest group, nearly three in ten, was about improving the code:

making it cleaner, more readable.

And a lot of the rest was about simply understanding the change.

So review was mostly how a team understood its own code.

It was a way of passing knowledge around, with a little bug catching on the side.

Remember that.

Because understanding is the part we're going to need to keep.

Nature solved this problem a few billion years ago.

It never reads the code for meaning.

It checks the copy, and then it judges the result.

Does this creature survive, and does it reproduce?

And on the way, it runs the most aggressive testing pipeline ever built.

The video draws it as four stages in a row.

Let me walk you through them.

Stage one is the linter, the tool that checks every line as it's written.

The enzyme that copies your DNA makes a mistake roughly

once every ten thousand to a hundred thousand letters.

That's sloppy.

But it proofreads as it goes, and repair systems follow behind it.

Together they bring the error rate down to roughly one in a billion letters.

Stage two is runtime checks.

When a cell gets ready to divide,

there are checkpoints that stop the process if the DNA is damaged.

And if the damage can't be fixed, the cell destroys itself, on purpose.

Stage three is an adversarial test suite.

In your thymus, a small organ behind your breastbone,

young immune cells, T cells, go through a brutal selection.

They have to recognise threats, but not attack your own body.

Only about two in every hundred pass.

The rest are eliminated.

And stage four is production. The real world.

Ship it, and see what survives.

Engineers noticed this long before AI.

In nineteen seventy-five, John Gall wrote a book called Systemantics,

and in it, a rule that people still quote.

“A complex system that works is invariably

found to have evolved from a simple system that

worked. A complex system designed from scratch

never works and cannot be made to work.”

And evolution doesn't just work.

Sometimes it out-engineers us.

In twenty oh six, NASA launched a satellite

mission carrying an antenna no human drew.

An algorithm evolved it. It looks like a bent paper clip.

In ground tests, a pair of them reached ninety-three percent efficiency.

The conventional pair reached thirty-eight.

In twenty twenty-five, Google DeepMind's AlphaEvolve,

a system that evolves code, found a scheduling trick that recovers,

on average, about zero point seven percent of

Google's worldwide computing power, continuously.

For a company that size, that's a lot of machines.

It also beat a record in matrix multiplication

that had stood since nineteen sixty-nine:

forty-eight multiplications instead of forty-nine,

for a particular kind of four by four grid of numbers.

That same year, Sakana AI built something called the Darwin Gödel Machine.

It's a coding agent that rewrites its own code,

keeps every version in a family tree, and tests each one.

On a benchmark of real software bugs from GitHub,

it climbed from twenty percent to fifty.

Hold on to that one. It comes back, and not in a good way.

And at Anthropic, sixteen Claude agents working together wrote a

hundred-thousand-line C compiler that can build the Linux kernel,

with an existing compiler handling a few pieces.

The researcher behind it, Nicholas Carlini,

said most of his effort went into the tests and the environment, not the code.

In his words:

“it's important that the task verifier is nearly perfect,

otherwise Claude will solve the wrong problem.”

That's the pitch. Now the part that could get you fired.

Evolution cheats. And nature knows it.

In nineteen ninety-six, a researcher named Adrian

Thompson evolved a computer chip to tell two tones apart.

It worked, using just thirty-two cells.

But when he looked inside,

some cells it depended on weren't even connected to the circuit.

And it only worked in the narrow range of temperatures it had evolved in.

It had found a trick in the physics of that one chip.

Software cheats the same way.

A program-repair system was asked to fix a broken sorting function,

one that puts a list in order.

It "passed" the test by returning an empty list.

Technically sorted.

Remember the self-improving agent, the Darwin Gödel Machine?

It faked a test log: tests that never ran, shown as passing.

And when the researchers checked whether it could catch exactly that kind of fake,

it deleted the markers their checker relied on.

It had been told not to.

In tests by the research group METR,

OpenAI's o3 model was asked to make some code run faster.

METR described what it did instead.

“o3 overwrites the timing function so that it always returns shorter measurements.”

It rewrote the stopwatch.

And at the end of September,

security researchers at a company called Glow reported that AI coding

agents had pushed more than thirteen thousand internal screenshots,

from over three hundred organisations, to public GitHub pages.

Why? So a human reviewer could see what the agent had done.

None of these systems was broken.

Each one did exactly what it was asked, to the letter.

There's a name for this.

It's Goodhart's law, in the anthropologist Marilyn Strathern's phrasing:

when a measure becomes a target, it ceases to be a good measure.

So how does nature live with cheaters?

It has exactly the same problem, inside your body.

You're made of about thirty trillion cells.

Any one of them could defect:

grow when it shouldn't, and ignore the signals to stop.

Some biologists describe cancer exactly that way.

A 2015 paper by Athena Aktipis and colleagues calls it

"cheating within this cooperative multicellular system."

The defence is the same layered pipeline we just heard,

plus an immune system on patrol, hunting cells that misbehave.

And no single check has to be perfect.

For lung and colon cancer,

researchers estimate a cell needs about three

separate driver mutations before it turns cancerous.

Three locks have to break.

One broken lock isn't enough. That's the design lesson.

Never trust a single check.

And keep something adversarial on patrol.

So the lesson isn't "stop checking".

It's "stop reading diffs". Start designing the environment.

Here are five pressures you can build yourself,

and then the numbers from a company already doing it.

One. Hide the exam.

A company called StrongDM has a literal rule:

code must not be reviewed by humans.

Instead, test scenarios are kept outside the codebase,

where the agents can't see them,

like the held-back exam a teacher never hands out early.

An agent can't game a test it can't see.

Two. Test the tests.

Mutation testing plants small bugs in your code on purpose,

and checks whether your tests catch them.

Google runs it during code review.

In a study of about fifteen million planted bugs over six years,

those fake bugs lined up with real faults,

and engineers who saw them wrote more and better tests.

Three. Pressure from several directions.

Tests that check general properties, performance budgets, security scans.

Game one number, and another one catches you.

Four. Route by risk.

At OpenAI, according to The Pragmatic Engineer, changes are classified by risk.

Low-risk areas can opt into an agent that approves on its own.

High-risk changes get more scrutiny, sometimes a human.

Five. Let production judge.

Release to a few users first, then more, and watch.

New tools, like Cursor's Rollouts,

read your logs and metrics after a deploy and name the change behind a problem.

So, does any of this work?

At Intercom, nineteen percent of pull requests

are now approved with no human in the loop.

In the video, it's two bars side by side, and the difference is hard to miss.

Their AI-written backend code gets reverted,

undone, about half a percent of the time.

Human-written code, about five percent.

That's not a controlled experiment.

But it's not the disaster people predicted.

And at Anthropic, the number of automated test

jobs grew twenty-five times in six months.

The pressure moved from people to pipelines.

That's where it belongs.

So what's left for us?

The part review was secretly good at. Understanding.

You stop reading every diff.

You read the things that define success instead:

the scenarios, the metrics, the lines you draw around risk.

You decide what "fit" means.

And where the damage could be biggest, a human still looks.

Expect some weird code, too.

Here's my favourite example.

In the tallest giraffes, the nerve that runs to

the voice box goes all the way down the neck,

around a blood vessel near the heart, and all the way back up.

Nearly five metres of nerve, to cover a distance of under one.

It works. That's the deal.

Evolution doesn't care if it's elegant.

So your job moves from gatekeeper to ecologist.

You don't design the giraffe. You design the savanna.

Nobody reviewed a single line of you.

Seventy unreviewed changes, and here you are.

There's a rule credited to the chemist Leslie Orgel, as Francis Crick told it.

“Evolution is cleverer than you are.”

So build the pressure. And let your code evolve.

The short version, with the genome strip and the chips and the giraffe,

is on the Everything It Touches channel, called "Nobody Reviewed Your DNA".

And I'd love to hear your answer to this one:

what's the one test you'd never let an agent see?

Tell me in the comments.

The sources are in the episode notes.

The quotes were read by AI voices, not by the people who said them.

This podcast was made with code, at procvideos dot com.

My voice is an AI clone, and the music is AI-generated.

Thanks for listening.