We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
The standout recommendation
An age of experimentation — BlueHat Asia 2026 slides
- Content type / creator: Talk slides. The sharing post is by Halvar Flake, who describes them as slides from his Microsoft BlueHat Singapore talk; the deck itself is titled An age of experimentation and credits Thomas Dullien, Cyber Security Research Team, OpenAI.
- Link:Slides
- Recommended by: Martin Casado, who calls it his favorite talk of the year and praises its clarity in an era of “AI shorthand.”
- Key takeaway: The deck treats reasoning LLMs as more like fire than an internal-combustion engine: discovered more than constructed, still poorly understood, and improved mainly through empirical work. Its practical rule is that every change in a probabilistic system is a hypothesis test; teams should ask what they want to show, measure rerun variation, identify randomness, and check whether changing conditions invalidate an IID assumption.
- Why it matters: This is a useful operating manual for evaluating AI-enabled systems without mistaking activity for progress. The deck also recommends a benchmark hierarchy—small tests for rapid iteration and larger tests for periodic validation—while warning that the small tests must remain representative.
Eidon AI’s egocentric robotics corpus
- Content type / creator: Open robotics dataset/resource, published by Solidic Labs Inc. (Eidon AI). The company has wound down, but the release remains available under CC-BY-4.0, with commercial use allowed when attribution is provided.
- Link:Eidon AI on Hugging Face, including the video corpus and paired motion data
- Recommended by: Clem Delangue, who praised the decision to open-source 1,274 hours of egocentric robotics data across 13,451 recordings and called it a gift to the robotics community. He explicitly argued that open source lets work outlive the organization that created it.
- Key takeaway: The release combines 13,451 egocentric videos with 779 million rows of 24 Hz orientation and motion data covering the same recordings; the two pieces join on
recording_id. The paired set contains 1,274 hours of video and arm tracking from 27 contributors, with automated quality-control scores. - Why it matters: This is an unusually actionable recommendation for embodied-AI work, as well as a concrete example of preserving research assets after a startup shuts down. The dataset is not a neutral snapshot of daily activity: the release warns that tasks are heavily weighted toward folding laundry, contributors are few and unevenly represented, and splits should be made by contributor rather than randomly.
Product and idea-generation picks
“I design teams like terrorist organizations” — Peter Ellis product-advice video
- Content type / creator: A 90-minute YouTube interview featuring Peter Ellis, published through the
@lennysaninterview series. The associated post links to the video. - Recommended by: Keith Rabois, with the unqualified endorsement “Highly recommend.”
- Key takeaway: The episode is organized around concrete product-leadership questions: managing Nikita Bier, why growth usually comes from the core, knowing when to stop, the shortcomings of the median product manager, and team design.
- Why it matters: It is a focused listening assignment for leaders working through the trade-offs between product taste, growth, and organizational design—not a generic startup interview.
Sharif Shameem’s posts archive
- Content type / creator: Personal blog/archive by Sharif Shameem. Posts
- Recommended by: Shaan Puri, who says he had just discovered the blog, calls it “very good,” and tells readers to read a couple of posts.
- Key takeaway: Puri does not identify a particular post or lesson, so this is a browse recommendation rather than a prescribed syllabus. The archive’s visible material ranges from The 28 AI tools I wish existed—framed by the question “where are the tools?”—to proposals about improving large video calls and modeling programming as a reinforcement-learning task.
- Why it matters: Treat it as an idea-generation archive: useful for finding sharp product and technical questions, but not evidence that the listed concepts were built, tested, or validated.
Direct answer: This is Sharif Shameem’s personal blog/posts archive. The page identifies “Sharif Shameem,” links to “Posts,” and labels the collection “Archive,” supporting attribution of the resource to him.
- The clearest concrete AI-related takeaway is that the archive contains a September 4, 2025 post titled “The 28 AI tools I wish existed,” described as “The models are powerful as is. But where are the tools?” This supports characterizing it as a collection of proposed or desired AI-tool ideas—not, from the index alone, evidence that 28 tools were built, tested, or endorsed.
- The resource is broader than an AI-tool list: visible entries include an ebook browser, ideas for improving large video calls, a startup manual, a React/Chromium/HTML-spec issue, and a programming/reinforcement-learning post. The safest description is therefore a personal collection of essays, technical notes, and project concepts rather than a single-purpose reference.
- The supplied material is an index showing titles, short descriptions, dates, and links—for example, the AI-tools entry—so it does not establish the posts’ implementation status, evidence, testing, or efficacy.
Direct answer: The linked Hugging Face resource is the Eidon AI organization release. It is one corpus organized into three components: tracker-pov, tracker-pov-imu, and the egocentric-pov Storage Bucket; the first two cover the same 13,451 recordings.
Creator/publisher and licence: The release is published by Solidic Labs Inc (Eidon AI). Eidon AI says the company has wound down, while the collected data remains publicly available under CC-BY-4.0; commercial use is allowed with attribution.
Dataset/resource titles and links:
tracker-pov— 13,451 egocentric MP4 videos, with one metadata row per video; listed size is 9.05 TB and the resource is loadable withload_dataset.tracker-pov-imu— 779 million rows of 24 Hz orientation and motion data for the same recordings; listed size is 9.5 GB and it is loadable withload_dataset.egocentric-pov— an additional 1.55 TB of egocentric video without sensor data. It is a Storage Bucket rather than a Dataset, so it must be accessed withhf buckets syncor the S3-compatible API.
Substantive contents: The paired tracker release contains 1,274 hours of egocentric video and seven-point arm tracking from 27 contributors in their homes; recordings underwent automated QC for hand presence, lighting, blur, and camera stability, with QC scores included. The additional bucket contains 306 hours across 1,370 recordings from 37 contributors, including 14 who also appear in the tracker set; it uses the same rig and QC pipeline but has no IMU harness.
Usable access details:
from datasets import load_dataset video = load_dataset("eidon-ai/tracker-pov", split="train") imu = load_dataset("eidon-ai/tracker-pov-imu", split="train", streaming=True) meta = pd.read_parquet("hf://datasets/eidon-ai/tracker-pov/recordings/metadata.parquet")The bucket can be synced with
hf buckets sync hf://buckets/eidon-ai/egocentric-pov ./egocentric-pov.Recommendation caveat: The source warns that the task distribution is heavily weighted toward folding laundry, contributors are few and unevenly weighted, and train/test splits should use
contributor_idrather than random splitting; it links to the dataset limitations section.
Direct answer
The supplied BlueHat deck supports an operating recommendation to treat LLM-enabled software and security work as an empirical, stochastic activity: it says software engineering and software security are in an “age of experimentation,” with no strong abstract model currently available.
Source identity and coverage caveat
- Authorship conflict: the supplied deck is titled An age of experimentation and its title page credits Thomas Dullien, Cyber Security Research Team, OpenAI.
- Missing comparison source: the supplied video bundle contains only one YouTube site-navigation line, not the requested full Peter Ellis/Lenny Rachitsky transcript; no substantive video takeaways or cross-source comparison can therefore be extracted.
Concrete takeaways from Dullien’s deck
- Treat reasoning LLMs as discovered, not fully engineered. Dullien compares reasoning LLMs to fire rather than the internal-combustion engine: they were “discovered more than constructed,” understanding is nascent, and improvements are very empirical.
- Assume semantic nondeterminism. The deck says adding LLMs introduces a source of stochasticity and claims that LLMs mean the “death of semantic determinism”; it describes outputs as random in practice, with additional randomness from hardware and concurrency. Small prompt changes are not analytically predictable: the slide says that, in formal-verification terms, “anything can happen” (but rarely does).
- Make every change a measured hypothesis test. For probabilistic systems, Dullien says teams should define what they want to show, account for variance, measure identical rerun variation, identify randomness sources, and determine whether time-varying factors make observations non-IID.
- Control shared-environment noise where possible. In the cloud-performance example, noisy neighbors are said to add ±15% runtime variation, require hundreds or thousands of runs to show an improvement, and destroy the IID assumption. The proposed “Tomato farmer protocol” uses paired experiments on the same VM so both instances experience the same noise, with the caveat that this is not always possible.
- Do not assume ordinary CI/CD is adequate for prompt changes. Dullien calls regular CI/CD processes poorly adapted to prompt changes and says evaluating whether a prompt-changing PR is worth merging can cost more than a developer workday. His caveat is that merging on a hunch is not necessarily harmful; the danger is spending substantial effort on iterative changes while mistaking activity for steady progress.
- Evaluate agent improvements with dependence and sample size in mind. A full-codebase agent run may be only one trial because path dependence means bugs are not independent—for example, an agent may skip a file. Even apparently independent bug tests can share underlying success factors, producing confidence intervals that are too narrow. A worked example says that, under deliberately false assumptions of normality and 2% standard deviation, 52 paired runs would be needed for a 95% chance of detecting a 1% improvement; the slide warns that reality is worse.
- Treat LLM code review more like fuzzing than traditional SAST. Dullien says each run is analogous to a fuzzing run, code review is never “done,” and exact reruns, small prompt variations, and new model generations can produce different bug sets. He identifies useful discoveries per dollar of compute as the relevant metric.
- Use a two-level benchmark hierarchy. The proposed pattern is to use small benchmarks for rapid iteration and larger benchmarks periodically for validation, while explicitly checking that the small benchmarks remain representative.
- Avoid claiming complete bug coverage. Dullien’s “fishery” model says security bugs are introduced and removed at rates nobody fully knows, so teams can track effort and catch rates rather than total bugs. He says catching every bug may be unrealistic; a more attainable outcome is making further discoveries uneconomical, while acknowledging that improved technology may find previously hidden bugs.
- Keep harnesses moving, but label this as an expectation. Dullien expects clever harnessing to boost any model on any task over the next few years, while also expecting those gains to be absorbed into later training runs; consequently, each harness would need to keep evolving to remain relevant.
- Pair rigor with proportionality. Dullien says there is no way around accepting stochastic systems and uncertainty, but also says statistical rigor is not an absolute necessity because some true claims are costly to demonstrate; his warning is against “treading water while feeling productive.”
Direct answer: The Halvar Flake talk, the Lenny-linked resource, Sharif Shameem’s blog, and Morning Brew receive clear positive endorsements; the Stratechery item is favorably described but not explicitly recommended.
- Halvar Flake’s talk — recommender: Martin Casado. Casado calls it “my favorite talk this year” and “just exceptional,” adding that, “in the era of AI shorthand,” clear thinking is “at a premium” and the talk is “as clear as it gets.” This is an explicit, strong endorsement; its substantive takeaway is the value of clear thinking and clarity in the AI-shorthand era.
- Stratechery’s Frontier Overhangs — recommender: Keith Rabois. Rabois says only “Several highly provocative thoughts” and shares a Stratechery link. That is favorable sharing or description, not an explicit recommendation to read it, and the post gives no substantive takeaway beyond the “provocative” characterization.
- Peter Ellis/Lenny Rachitsky product-advice video — recommender: Keith Rabois. The exact recommendation is “Highly recommend,” attached to a @lennysan link. This is explicit endorsement, but the supplied post contains no product-advice takeaway and does not name Peter Ellis.
- Sharif Shameem’s blog — recommender: Shaan Puri. Puri says he “just discovered” the blog, calls it “very good,” and explicitly tells readers to “go read a couple posts,” linking to sharif.io/posts. The context is a newly discovered blog; no specific post or substantive blog takeaway is identified.
- Morning Brew — recommender: Tobi Lutke. Lutke’s exact recommendation is “definitely use it” and “use it well.” His follow-up says the instructions were “Too complex a set of instructions for various people around here it seems,” providing usage context. This is explicit endorsement plus usage guidance, not mere promotion, but no content-level takeaway about Morning Brew is supplied.
- “I design teams like terrorist organizations” — Peter Ellis product-advice video (YouTube). Keith Rabois wrote “Highly recommend” while linking to Lenny Rachitsky’s post about the resource. The 90-minute episode covers managing Nikita Bier, why growth usually comes from the core, knowing when to stop, the median PM’s shortcomings, and designing teams; the video is available at https://www.youtube.com/watch?v=97LRJUUPy_w.
- Keith Rabois highlighted Stratechery’s article “Frontier Overhangs”, calling it “Several highly provocative thoughts.”
- The article’s central idea is that slowing frontier progress, even if sincere, could strategically give frontier labs time to reduce overhangs created by rapid model advancement.
- “An Age of Experimentation” — BlueHat Asia 2026 talk slides (PDF by Halvar Flake): access the slides. Halvar Flake shared the slides from his Microsoft BlueHat Singapore talk. Martin Casado called it his favorite talk of the year and praised it as “exceptional,” highlighting its clear thinking in an era of AI shorthand.
Shopify CEO Tobi Lütke explicitly recommends Morning Brew, writing “definitely use it” and “use it well.”
- Eidon AI egocentric robotics dataset — dataset/resource: Clem Delangue endorsed Eidon AI’s release of 1,274 hours of data across 13,451 recordings of humans performing everyday tasks, describing it as a gift to the robotics community. He highlighted open source’s ability to let work outlive the organization that created it and encouraged more startups to follow this model. Resource: https://huggingface.co/eidon-ai
- Sharif Shameem’s blog (blog): Shaan Puri calls it “very good” and recommends reading a couple of posts. https://sharif.io/posts
An age of experimentation — BlueHat Asia 2026
BLUEHAT ASIA SINGAPORE
An age of experimentation
Thomas Dullien Cyber Security Research Team OpenAI


BlueHat Asia 2026 | September 17-18 | Singapore

BLUEHAT ASIA SINGAPORE
“there are decades where nothing happens, and there are weeks in which decades happen”

BlueHat Asia 2026 | September 17-18 | Singapore

BLUEHAT ASIA SINGAPORE
- 1995 to 2022 saw rapid technological progress in IT, but few “surprising jumps”
- new technology arrived: the internet, smartphones, etc – but they were “inside the expected trajectories”
- the last 2–3 years feel qualitatively different: “surprising” leaps in technology

BlueHat Asia 2026 | September 17-18 | Singapore

BLUEHAT ASIA SINGAPORE
- not all technologies are born the same way
- the internal combustion engine was constructed after its principles were well understood
- most applications today resemble what the inventors imagined


BlueHat Asia 2026 | September 17-18 | Singapore

BLUEHAT ASIA SINGAPORE
- some technologies are more like “discoveries” than “development”
- fire was discovered, and humanity had little understanding of how it works
- absent abstract models, experimentation was the only way to advance

BlueHat Asia 2026 | September 17-18 | Singapore
BLUEHAT ASIA SINGAPORE
- reasoning LLMs are more like fire than like the internal combustion engine
- We discovered them more than we constructed them
- understanding is nascent
- improvements very empirical

BlueHat Asia 2026 | September 17-18 | Singapore
BLUEHAT ASIA SINGAPORE
- The big surprise: the unreasonable effectiveness of statistically emulating a consistent inner monologue
- arguably more “artificial thought” than “artificial intelligence”?
- “intelligence” implies continual learning, “thought” is the inner monologue.
- But “artificial thought” can solve so many problems already!

BlueHat Asia 2026 | September 17-18 | Singapore

- Perform long-horizon tasks using Bash and Python
- Read code and write coherent understanding on how it works
- Translate code between languages
- Translate human language into code and vice versa
- Create plausible solutions to Millenium math problems

BlueHat Asia 2026 | September 17-18 | Singapore

BLUEHAT ASIA SINGAPORE
- Capabilities that were deemed impossible 4-5 years ago
- “Computer, please tell me what the intent of this code is”
- Translate human language into code
- Translate code into human language
- LLMs are used to generate code, but calls to LLMs are also becoming intrinsic parts of many workflows

BlueHat Asia 2026 | September 17-18 | Singapore

BLUEHAT ASIA SINGAPORE
Adding LLMs to your workflow adds a source of stochasticity!

BlueHat Asia 2026 | September 17-18 | Singapore

BLUEHAT ASIA SINGAPORE
- CS was born somewhere between EE and math
- Apparent determinism in computers was a tremendous achievement by EE and process engineers
- Allowed CS to aspire to be mathematics


BlueHat Asia 2026 | September 17-18 | Singapore

BLUEHAT ASIA SINGAPORE
- Software engineering workflows are very geared toward (semantic) determinism
- example: ci/cd Pipelines – test something once to see if it still behaves as it did last time
- determinism allows rapid iteration
- adding stochasticity messes with the workflows we are used to

BlueHat Asia 2026 | September 17-18 | Singapore

BLUEHAT ASIA SINGAPORE
Claim: Determinism is dying, and it’s unclear how much will remain.
Security is affected each time.
Three stages I observed:
- cracks in hardware determinism (row hammer)
- death of temporal determinism (spectre)
- LLMs mean the death of semantic determinism


BlueHat Asia 2026 | September 17-18 | Singapore

- ● CS folks take determinism for granted
- ● Generations of EE and process engineers sacrificed themselves to keep that illusion
- ● contract between hardware and software over the last decades: We keep visible semantics stable, but we get to do whatever underneath
- ● determinism isn’t natural, it’s a fragile construct
“The death of hardware determinism”
- row hammer really made me understand that computers are “average case deterministic”
- they are deterministic most of the time
- and you have to be nice to them - hammering, glitching, EMFI
- Economics enforce: You’ll be sold the worst hardware you can’t detect as bad
When hardware determinism fails, security boundaries tend to fail.

BlueHat Asia 2026 | September 17-18 | Singapore

“The death of temporal determinism”
BLUEHAT ASIA SINGAPORE
- in order to make things fast we need caching
- and/or speculation
- leads to ugly, multi-modal and nonparametric distributions
- Temporal semantics are not specified, hardware implementers need full liberty
Discrepancy between timing models and reality leak information which should semantically not be accessible across security boundaries (Spectre).

BlueHat Asia 2026 | September 17-18 | Singapore

“The death of semantic determinism”
BLUEHAT ASIA SINGAPORE
- LLMs are in practice random
- Random sampling necessary for problem exploration
- The sampling can in theory be reproducible
- more randomness from hardware
- more randomness from concurrency

BlueHat Asia 2026 | September 17-18 | Singapore

“The death of semantic determinism”
BLUEHAT ASIA SINGAPORE
- LLMs are also chaotic
- recurrence equations over a state space
- Lyapunov exponent (butterfly principle)
- long trajectories for problem solving

BlueHat Asia 2026 | September 17-18 | Singapore

BLUEHAT ASIA SINGAPORE
- consequences of single token change in prompt not analytically solvable
- Any tiny change in a prompt means (in formal verification terms) T – “anything can happen” (but rarely does)
- we are absolutely in an empirical / experimental domain
- death of semantic determinism
BlueHat Asia 2026 | September 17-18 | Singapore
- Software engineering and software security is now in an age of experimentation
- this is different from the past
- we have no strong abstract model how things work
- experimentation and empiricism is all that is currently available

BLUEHAT ASIA STUDENTURE
What does this mean?

BlueHat Asia 2026 | September 17-18 | Singapore

BLUEHAT ASIA SINGAPORE
- CS is historically not an empirical science
- CS majors know little about experimental design and are often weak in statistics
- First realization during Rowhammer: Sitting in a room with highly competent CS PhDs, difficulties modeling Rowhammer experiments, confidence intervals etc.
- I was extremely weak myself: Background in CS, some Econ, and a lot of commutative algebra while avoiding statistics.

BlueHat Asia 2026 | September 17-18 | Singapore

BLUEHAT ASIA SINGAPORE
In a probabilistic system, every change is a hypothesis test!

BlueHat Asia 2026 | September 17-18 | Singapore

BLUEHAT ASIA SINGAPORE
- this means we have an experiment
- you need to think about what you want to show
- you need to account for the sources of variance in your system
- “The first principle is that you must not fool yourself, and you are the easiest person to fool.” – Feynman

BlueHat Asia 2026 | September 17-18 | Singapore

Questions to ask
BLUEHAT ASIA SINGAPORE
- How much does my measurement vary on identical re-runs?
- What are the sources of randomness?
- Is there any time-varying factor like the noisy VM neighbors that influences multiple runs, or are the measurements IID?
- (IID meaning there is randomness, but the distribution is the same on each draw)

BlueHat Asia 2026 | September 17-18 | Singapore

Effect sizes and # of samples
BLUEHAT ASIA SINGAPORE
- experiments aren’t free
- number of samples is proportional to (stddev / effect size) squared
- you want your effect to be bigger than stddev if at all possible
$$N \propto \left(\frac{\sigma}{\Delta}\right)^2$$

BlueHat Asia 2026 | September 17-18 | Singapore

Example: Performance optimization in the cloud
BLUEHAT ASIA SINGAPORE
Multi-tenant host
Your VM
Neighbor VM
Neighbor VM
Shared CPU, memory, cache and I/O
- Noisy neighbors can slow me down
- Adds +/- 15% runtime variation (!)
- 100s or 1000s of runs necessary to show improvement, if at all.
- Destroys IID assumption.Ouch.

BlueHat Asia 2026 | September 17-18 | Singapore

Solution: “Tomato farmer protocol”
BLUEHAT ASIA SINGAPORE
- Paired experiments on the same VM: Two instances side-by-side.
- Exposed to the same noise.
- Adapted from fertilizer testing, “Statistics for Experimenters”
- Not always possible.


BlueHat Asia 2026 | September 17-18 | Singapore

BLUEHAT ASIA SINGAPORE
- let’s look at LLM bug detection
- example: Raptor, Codex Security, any other LLM+prompt system / harness.
- How do we know we have made an improvement?
- Do we know the variance of our metrics?

BlueHat Asia 2026 | September 17-18 | Singapore

BLUEHAT ASIA SINGAPORE
- Let’s assume we have a codebase with 100 known bugs
- Let an agent loose on that codebase – how many will the agent find?
- If the agent is just allowed to run on the whole codebase, there is path dependence, and the individual bugs are not independent trials (e.g. if the agent decides to skip a file). So a full run is really just one trial?

BlueHat Asia 2026 | September 17-18 | Singapore

BLUEHAT ASIA SINGAPORE
- how many test runs do you need to have 95% chance of detecting a 1% improvement?
- let’s make a bunch of assumptions we know are false (normal distribution, stddev 2%) - reality is worse
- result: 52 paired sample runs
- show of hands: Who does that to test a prompt improvement?

BlueHat Asia 2026 | September 17-18 | Singapore

BLUEHAT ASIA SINGAPORE
- Ok, so let’s say we have 100 bugs that we can test independently
- If they are truly independent we can make narrow confidence intervals from a small number of runs (example: TermBench)
- But … uh … the problems have underlying success factors (“does the model know how to use XYZ”) to make them correlated.
- This leads to overly narrow confidence interval estimates.

BlueHat Asia 2026 | September 17-18 | Singapore

BLUEHAT ASIA INNOVATION
Uncomfortable conclusion 1:
Most of us are playing slot machines

BlueHat Asia 2026 | September 17-18 | Singapore

[LOGO]
BLUEHAT ASIA INNOVATION
Uncomfortable conclusion 2:
Regular CI/CD processes are poorly adapted to dealing with prompt changes

BlueHat Asia 2026 | September 17-18 | Singapore

LLMs as part of a workflow destroy semantic determinism
LLMs also make experiments relatively costly
Existing Software dev processes are a poor fit
It is easy to end up in a situation where checking whether a PR that changes a prompt is worth merging may cost more than the developer’s workday.

BlueHat Asia 2026 | September 17-18 | Singapore

BLUEHAT ASIA SINGAPORE
- This does not mean that merging the PR on a hunch is harmful.
- We have all merged prompt changes on 3-5 experiments.
- The risk is spending a lot of time on iterated changes, thinking one is making steady progress, without getting anywhere.
- Beware the “Gas Town” phenomenon: Steve Yegge’s attempt at a software factory.

BlueHat Asia 2026 | September 17-18 | Singapore

BLUEHAT ASIA SINGAPORE
- small effect sizes may be too expensive to evaluate.
- it may be worth stacking 5-6 suspected improvements and measuring them jointly.
$$N \propto \left( \frac{\sigma}{\Delta} \right)^2$$

BlueHat Asia 2026 | September 17-18 | Singapore

BLUEHAT ASIA INNOVATION
Uncomfortable conclusion 3:
Congratulations. Y’all have to be empirical scientists and (amateur/professional) statisticians now.

BlueHat Asia 2026 | September 17-18 | Singapore

LLM code review and fuzzing
BLUEHAT ASIA SINGAPORE
- LLM code review is more like fuzzing than like traditional SAST
- Every run is similar to a fuzzing run (but in most APIs you do not get to freeze the seed)
- LLM code review is never “done”, in the same way that fuzzing is never “done”.

BlueHat Asia 2026 | September 17-18 | Singapore
LLM code review and fuzzing
BLUEHAT ASIA SINGAPORE
- Expect exact re-runs to produce different sets of bugs.
- Expect small prompt variations to produce different sets of bugs.
- Expect new model generations to produce different sets of bugs.
Similar to fuzzing, the “right” metric to track is the rate of useful discovery per dollar of compute spent.
Over time, this will go down, and new discoveries are hopefully expensive for everybody.
BlueHat Asia 2026 | September 17-18 | Singapore
Security bugs and fishery models
BLUEHAT ASIA SINGAPORE
I have jokingly suggested renaming “bugs” to “fish”: A lot of our problems are similar to fishery management.
- Security bugs are introduced into applications at a certain rate.
- Security bugs are removed at a certain rate.
- Nobody knows how many bugs there are.
- We can only track effort and “catch rates”.
- New technologies help us catch more fish.

BlueHat Asia 2026 | September 17-18 | Singapore

Catching all the fish?
BLUEHAT ASIA SINGAPORE
- It may be unrealistic to catch all the fish.
- You never know if a Tuna hid somewhere during your hunt, the ocean is too vast.
- You can hope that catching fish becomes uneconomical because you have depleted the stock.
- Improvements in technologies may find the last hide-outs.

BlueHat Asia 2026 | September 17-18 | Singapore
BLUEHAT ASIA FONDATION
Where are we headed from here?
Concrete advice?

BlueHat Asia 2026 | September 17-18 | Singapore

Observation: The current change is pretty big
BLUEHAT ASIA SINGAPORE
- my confidence intervals around predictions have gotten very wide
- we are looking at a period of rapid change
- certainly as big as the smartphone, likely as big as the internet, possibly as big as railroads, perhaps as big as electrification.

BlueHat Asia 2026 | September 17-18 | Singapore

Accept empiricism, accept uncertainty
- There is no way around accepting that we are dealing with stochastical systems.
- Being statistically rigorous isn’t an absolute necessity – there are many true things that are onerous to demonstrate as true. But: Be wary of treading water while feeling productive.
- “Statistics for experimenters” is a great book!

BlueHat Asia 2026 | September 17-18 | Singapore

Hypothesis generation, testing, and progress
BLUEHAT ASIA SINGAPORE
- Observation: Hypothesis generation is now cheaper
- Implementation of the test is now cheaper
- actual experiment cost/duration is often the bottleneck
- Try to build a hierarchy of benchmarks – small ones you can iterate rapidly on, big ones you use periodically to validate the small ones.
- Danger zone: Make sure the small ones are representative!

BlueHat Asia 2026 | September 17-18 | Singapore

The value of harnessing and prompting
BLUEHAT ASIA SINGAPORE
- Will the long-term value be in the models or in the harness? Both.
- For the foreseeable future (the next few years) I expect that clever harnessing can boost any model on any task.
- But also: Each improvement from harnessing can feed into the next training run.
- I expect these boosts to be absorbed in new training runs, so each harness needs to keep moving to stay relevant.

BlueHat Asia 2026 | September 17-18 | Singapore

BLUEHAT ASIA SINGAPORE
- OODA loops apply here too:
- A cheap experiment means a faster “OO” part of the loop.
- The “A” part has been sped up.


BlueHat Asia 2026 | September 17-18 | Singapore

BLUEHAT ASIA PROGRESS
No visible technical reason the current progress should come to an end soon
Progress will slow down when expected benefit from further progress falls under cost of progress. Where is that?

BlueHat Asia 2026 | September 17-18 | Singapore

Rapid technological change can be scary…
BLUEHAT ASIA SINGAPORE
I try to think of my grandfather: Born in 1902, died in 1982.
- Born in the Prussian Kingdom, horse carriages & gaslight.
- Died in an era of Concorde travel, computers, and moon missions.
- Survived two world wars and great upheaval.
The changes he saw were much more drastic than what I saw 1981 to today.
BlueHat Asia 2026 | September 17-18 | Singapore
BLUEHAT ASIA INNOVATION
It is a (perhaps uncomfortably) exciting time in technology.
Rapid change, high levels of uncertainty. The right response is focus, not fear.

BlueHat Asia 2026 | September 17-18 | Singapore

BLUEHAT ASIA SYNOPORTUNITY
Thank you.

BlueHat Asia 2026 | September 17-18 | Singapore

Direct answer
The supplied BlueHat deck supports an operating recommendation to treat LLM-enabled software and security work as an empirical, stochastic activity: it says software engineering and software security are in an “age of experimentation,” with no strong abstract model currently available.
Source identity and coverage caveat
- Authorship conflict: the supplied deck is titled An age of experimentation and its title page credits Thomas Dullien, Cyber Security Research Team, OpenAI.
- Missing comparison source: the supplied video bundle contains only one YouTube site-navigation line, not the requested full Peter Ellis/Lenny Rachitsky transcript; no substantive video takeaways or cross-source comparison can therefore be extracted.
Concrete takeaways from Dullien’s deck
- Treat reasoning LLMs as discovered, not fully engineered. Dullien compares reasoning LLMs to fire rather than the internal-combustion engine: they were “discovered more than constructed,” understanding is nascent, and improvements are very empirical.
- Assume semantic nondeterminism. The deck says adding LLMs introduces a source of stochasticity and claims that LLMs mean the “death of semantic determinism”; it describes outputs as random in practice, with additional randomness from hardware and concurrency. Small prompt changes are not analytically predictable: the slide says that, in formal-verification terms, “anything can happen” (but rarely does).
- Make every change a measured hypothesis test. For probabilistic systems, Dullien says teams should define what they want to show, account for variance, measure identical rerun variation, identify randomness sources, and determine whether time-varying factors make observations non-IID.
- Control shared-environment noise where possible. In the cloud-performance example, noisy neighbors are said to add ±15% runtime variation, require hundreds or thousands of runs to show an improvement, and destroy the IID assumption. The proposed “Tomato farmer protocol” uses paired experiments on the same VM so both instances experience the same noise, with the caveat that this is not always possible.
- Do not assume ordinary CI/CD is adequate for prompt changes. Dullien calls regular CI/CD processes poorly adapted to prompt changes and says evaluating whether a prompt-changing PR is worth merging can cost more than a developer workday. His caveat is that merging on a hunch is not necessarily harmful; the danger is spending substantial effort on iterative changes while mistaking activity for steady progress.
- Evaluate agent improvements with dependence and sample size in mind. A full-codebase agent run may be only one trial because path dependence means bugs are not independent—for example, an agent may skip a file. Even apparently independent bug tests can share underlying success factors, producing confidence intervals that are too narrow. A worked example says that, under deliberately false assumptions of normality and 2% standard deviation, 52 paired runs would be needed for a 95% chance of detecting a 1% improvement; the slide warns that reality is worse.
- Treat LLM code review more like fuzzing than traditional SAST. Dullien says each run is analogous to a fuzzing run, code review is never “done,” and exact reruns, small prompt variations, and new model generations can produce different bug sets. He identifies useful discoveries per dollar of compute as the relevant metric.
- Use a two-level benchmark hierarchy. The proposed pattern is to use small benchmarks for rapid iteration and larger benchmarks periodically for validation, while explicitly checking that the small benchmarks remain representative.
- Avoid claiming complete bug coverage. Dullien’s “fishery” model says security bugs are introduced and removed at rates nobody fully knows, so teams can track effort and catch rates rather than total bugs. He says catching every bug may be unrealistic; a more attainable outcome is making further discoveries uneconomical, while acknowledging that improved technology may find previously hidden bugs.
- Keep harnesses moving, but label this as an expectation. Dullien expects clever harnessing to boost any model on any task over the next few years, while also expecting those gains to be absorbed into later training runs; consequently, each harness would need to keep evolving to remain relevant.
- Pair rigor with proportionality. Dullien says there is no way around accepting stochastic systems and uncertainty, but also says statistical rigor is not an absolute necessity because some true claims are costly to demonstrate; his warning is against “treading water while feeling productive.”