Test obsessively: asserts, fuzzing and verification from FFmpeg to Cursor

The Short Version

Across three conversations, one lesson keeps coming back: code only becomes trustworthy when checks are built in from the start and never switched off. FFmpeg and VLC keep internet video working with an exact standard ("bit-exactness"), a volunteer-run test matrix called FATE that spans operating systems, compilers and CPU architectures, and slow reverse engineering against real sample files [1]. ThePrimeagen says projects start teaching him the most at around 5,000 to 10,000 lines. That is where he adopted crash-on-impossible-state asserts and simulation testing in the style of TigerBeetle, and they found bugs he says he would never have caught otherwise [2]. The Cursor team explains why today's AI is still poor at finding bugs, how models might be trained to get better at it, and why formal verification, however appealing, runs into the problem of writing down what you actually intended [3]. Taken together, they suggest a layered protocol: exact reference outputs, asserts that stay on, randomized and simulated input, clearly labeled dangerous code, and a healthy suspicion of anyone, human or machine, who claims to have found or fixed a bug without proof.

Table of contents

What They Said

Kieran Kunhya and Jean-Baptiste Kempf: correctness as a bit-for-bit contract

The FFmpeg and VLC maintainers work at a scale where a mistake reaches almost everyone. Kieran notes that home videos and trillion-dollar companies run on the same FFmpeg stack, some of them with command lines thousands of characters long [1]. He estimates, with his "finger in the air," that more than 80% of FFmpeg pipelines rely on VideoLAN's x264 [1]. JB points out that compiling VLC for Windows involves about 16 million lines of code, of which only one million live in VLC's own repository [1]. So when these two talk about testing, they mean testing for code that everyone quietly depends on.

Bit-exactness as the specification. The core idea in the FFmpeg conversation is bit-exactness. Kieran explains it plainly: modern codecs "certainly from about the 2000s onwards have a bit exact definition so every implementation must produce exactly the same bits bit for bits" [1]. He makes it personal: "lex's implementation jb's implementation and my implementation of h264 must match bit exactly" [1]. This turns correctness from a matter of opinion (does the picture look right?) into a mechanical check: the decoded output either matches the reference exactly or it doesn't. Kieran says the lack of this rule in MPEG-2 in the 1990s was "probably fair to say one of the biggest mistakes the video industry made" [1]. The summary puts it more bluntly: he calls it one of the industry's great mistakes [1].

FATE: the test matrix. Bit-exactness is enforced through FATE, FFmpeg's volunteer-hosted testing system, which covers a huge matrix of operating systems, compilers and CPU architectures [1]. The size of that matrix matters because of how widely this software is expected to run. JB notes that VLC still runs on everything from Windows XP to Windows 11, from iOS 9 onward, and even on OS/2 [1]. Code that has to behave identically across that range can't be checked by hand on one developer's laptop. The checking has to be automated, shared and constant.

Real-world samples as test data. Kieran describes how the project gathers the files it tests against. When you are reverse engineering a format, "sometimes you don't have access to an encoder so this is even more difficult because you just you just ask and you have to ask for samples" [1]. He recalls that VideoLAN "used to tweet for samples at one stage" [1]. Most of the time the harvest was thin: "you'd get nothing or you get one or two" [1]. Sometimes, though, "you'd find a gold mine like yeah my company has a hundred thousand of these files because we depended on it for some reason" [1]. Those are the best finds, he explains, "because then they can test bit exactness across the huge range of coding tools" [1]. The lesson: a large and varied set of real inputs is what makes an exactness check meaningful. One file only tests the paths that one file happens to use.

Reverse engineering: debugging with almost no signal. Kieran's account of reverse engineering proprietary codecs shows how much patience correctness can demand. You find the decoding module inside a large binary, hook in to dump raw YUV output for comparison, then step through the disassembly instruction by instruction, often inside a virtual machine [1]. He estimates about a month of work per megabyte of binary [1]. The hard part, he says, is that "for a long time you don't see anything right so you're debugging purely in memory debugging guesswork" [1]. A wrong guess costs a lot: "you may have the buffer that the coefficients are completely wrong and so you may be going down a complete rabbit hole" [1]. And the work is slow and manual: "you're stepping through the debugger like one by one you know instruction by instruction" [1]. Sometimes you need a VM so you can pause it and dump memory, because "some of the codecs could have encryption there could be um like a DRM on there" [1].

His own work on CineForm shows how the right test input can unlock a problem. CineForm, he explains, "is actually a collection of different approaches and toolkets within that codec" [1], and "the hard part is finding the sample that gets you kind of somewhere to start without having to implement 10 different other things" [1]. He got lucky: "i found a sample by pure chance had a lot of flat blocks it was animation so that really helped a lot because it wasn't using particularly complex coding tools" [1]. From there you "build up and build up until you figure hey here's a few bits here i miss this i miss this this if branch that it does" [1]. Lex likened the process to archaeology, saying "you're like like archaeologists with a little brush" [1]. The Ukrainian developer Kostya went further still, reverse engineering 20 to 30 megabyte blobs, including GoToMeeting's codec, one of VLC's most requested features [1].

Robustness designed in from day one. VLC was built from the start to handle broken or incomplete input, a habit that dates back to its origins playing lossy network streams [1]. VLC and FFmpeg ignore file extensions and look inside the file to see what it actually contains [1]. Both are correctness decisions made at the architecture level: never trust the label, always inspect the data, and expect it to be damaged. Kieran is also frank about the risk this brings. FFmpeg's own homepage acknowledges that "it processes untrusted data there can be security issues when you pass untrusted data that's very normal" [1].

The same bar for any new tool. When the talk turns to Rust, Kieran values its memory-safety goals but says the language has an "Esperanto vibe" [1]. He would welcome Rust in FFmpeg if it meets the same testing and stability bar [1]. JB, whose startup Kyber is written mostly in Rust, says it is excellent for new projects but warns against rewrites, since reading code is far harder than writing it [1]. He adds that pairing Rust with handwritten assembly breaks the safety model and suggests compile-time checked assembly as the answer [1]. In both men's view, a language's safety promises don't replace testing. They are one more layer, and they break down wherever the code drops into unchecked territory.

Performance code needs checks too. The same project writes huge amounts of handwritten SIMD assembly. dav1d, VideoLAN's AV1 decoder, has roughly 30,000 lines of C and 240,000 lines of handwritten assembly, under the motto "every cycle matters" [1]. It even uses its own internal calling convention to avoid saving registers the standard way [1]. Kieran says this assembly typically runs 10x to 50x faster than C, and shows one function at 62x [1]. Code that clever and that low-level is exactly where a reference implementation and exact output comparison earn their keep. Bit-exactness lets a hand-tuned routine be checked against a plain one.

Who gets to call code broken. The maintainers also describe the downside of automated bug hunting done without context. Kieran explains that "google started using ai to create security reports on an open source project" [1]. Google applied a standard 90-day disclosure deadline and promoted its AI in the media before fixes were ready [1]. One of the vulnerabilities "was on an obscure 1990s game codec" [1]. He compares it to a household lock: "it's not there to protect nuclear secrets it's not there to protect fort knox" [1], and describes AI being used "at a level of scale to go and pick those locks and then say hey your locks your lock's not secure" [1]. He criticizes "a portion of the security community that um look at themselves a bit like building architects that never have to go to site" [1], and the security industry's habit of labeling everything high severity [1]. He is fair about it: he notes that "google are one of the biggest supporters of open source out there" [1], and that Google later began sending patches and rewarding fixes [1]. His point isn't that bug finding is bad. It's that finding bugs without fixing them, or without a sense of which ones matter, pushes the cost onto whoever maintains the code.

ThePrimeagen: asserts that crash, and simulation that runs for hundreds of years

Michael Paulson, known as ThePrimeagen, spent about ten years at Netflix before streaming full time [2]. His case for correctness checks comes from experience, from breaking production himself as well as from projects he builds.

The 5,000-line threshold. Prime says he learns the most when a project reaches roughly 5,000 to 10,000 lines of code, where early design choices either weigh you down or free you, and he aims to push that number higher as he improves [2]. That's the point where a program no longer fits in your head, and where the assumptions you made early start to break quietly.

Asserts that stay on in production. Inspired by Lex, John Carmack and Joran, the creator of the TigerBeetle financial database, he adopted asserts that crash the program when an impossible state occurs [2]. TigerBeetle follows NASA-style rules, including at least two asserts per function that stay on in production [2]. The key detail is stay on in production. These aren't debug-only checks stripped out before release. They are part of the running system, so a violated assumption stops the program right away instead of corrupting data further down the line.

Deterministic simulation testing. TigerBeetle also runs deterministic simulation testing equivalent to hundreds of years of random input [2]. When Prime tried this approach in his own proxy and game projects, he found bugs he never would have caught otherwise [2]. That's the strongest first-hand evidence in his conversation: a practicing engineer reporting that the method found real defects in his own code that his usual habits had missed.

Lex's own practice. Lex adds that he treats warnings as errors and puts asserts everywhere, which makes debugging large systems far less painful, since a single bug in a 20,000-line codebase can otherwise take days to track down [2]. His point is about the cost of not having checks: without them, finding one bug in a large system turns into a long hunt.

What happens without guards. Prime's Netflix stories show what these checks are meant to prevent. He found a bug in the Falcor data-fetching library so severe it got its own name, the Repulsive Grizzly attack: a single request asking for huge ranges of data with a "materialize" flag could force a server to create billions of objects and die [2]. With about 50 servers behind the UI, roughly 50 requests could have taken down the Netflix interface across web, TV and mobile, and the bug had been in production for years, so there was nothing to roll back to [2]. He has broken production himself too: misusing PHP statics so users saw other people's data, freezing the Netflix homepage countdown for a Lady Gaga release, and shipping an infinite loop on an "add to my list" button [2]. He once locked up the entire staging environment by making a thread sleep [2]. Every one of these is an "impossible" state that happened anyway.

Understand before you delete. Prime's lessons about reading code point the same way. He stresses learning why existing code was written a certain way before rewriting it [2]. He tells the story of deleting a colleague's odd-looking code in Falcor, only to reproduce it almost line for line: "I am the idiot in the situation." [2] His everyday debugging tool at Netflix was printf debugging, a skill he built writing drivers for government robots in school [2]. He also recommends building things from scratch, like an HTTP server, when you want to truly understand a concept [2].

Speed versus scale. He contrasts his approach with Pieter Levels' push-straight-to-production style, which he admires for a solo developer but says wouldn't work at a company with hundreds of engineers [2]. How much checking you need depends on how many people and users are exposed to your mistakes.

AI and bugs. Prime's experience with AI coding tools supports his case for built-in checks. When he first used GitHub Copilot he was amazed, but over time he introduced more bugs: "I wasn't co-piloting well. I was autopilotting much better." [2] Reading code, he found, engages a different skill than writing it [2]. He also describes a "denial of attention" problem, citing the curl maintainer being flooded with bogus AI-generated security reports [2]. That echoes the FFmpeg maintainers' complaint [1]. Lex and Prime both agree AI is poor at hard debugging and that deep, hard skills will remain essential for steering it [2]. They also look at a Stack Overflow survey showing that most developers use or plan to use AI but only about 2.7% highly trust its output [2].

The Cursor team: AI bug finding, dangerous-code labels, and the limits of proof

The four Cursor founders, Michael Truell, Sualeh Asif, Arvid Lunnemark and Aman Sanger, come at correctness from the other side: they build AI tools that write and review code, and they're candid about where those tools still fall short [3].

Bugs are hard to avoid, even for experts. Discussing theories that Claude had gotten dumber, the team notes that different chips and numerics, and plain bugs, can matter, because "it's hard to overstate how hard bugs are to avoid." [3] The people building one of the most sophisticated coding tools start from the assumption that bugs will be there.

Frontier models are bad at finding bugs when simply asked. The team says frontier models are strikingly bad at bug finding when simply asked, because real bug detection is rare in pre-training data [3]. They also lack calibration about which bugs matter: the cultural knowledge a staff engineer has from seeing sketchy code take down a server [3]. That lines up with Kieran's complaint that an automated system flagged a vulnerability in an obscure 1990s game codec as if it were urgent [1]. Knowing which bugs matter takes context the models don't yet have.

Training bug finders on planted bugs. One idea for training bug finders is to have a model introduce plausible bugs into code, then train another model to find them [3]. Aman lists this among three kinds of synthetic data: problems that are easier in one direction, like introducing bugs to train bug finders [3]. He singles out a third kind, generating many outputs that can be easily verified, as with formal math proofs or code that passes tests, as the one most likely to produce massive gains. But he warns that perfect verifiers are hard to build for open-ended tasks [3]. On RLHF versus RLAIF, he notes that AI feedback works if verifying is easier than generating [3]. In all three cases the progress depends on having something that can check the answer.

Label dangerous code. Arvid's practice of labeling dangerous code with comments on every line helps both humans, who forget, and models, which pay more attention [3]. It's a low-tech measure with the same logic as an assert: write down, next to the code, what must never go wrong.

Bug bounties inside the editor. Fridman suggested tipping or bug bounties for AI bug finding. The team says the idea is controversial internally, since they worry money might make the product feel less fun [3].

The shadow workspace: testing before touching. Arvid describes the shadow workspace, a hidden instance of Cursor where AI can edit code and get feedback from language servers (type errors, go-to-definition) without touching the user's files [3]. On Linux it could even mirror the file system in memory; on Mac and Windows it's trickier, and one idea is for the AI to hold a lock on saving [3]. Longer tasks may eventually run in remote sandboxes [3]. It's an automated check that runs before a change reaches the user. Arvid would love to hand off a well-specified bug, such as copy and paste not working in the chat input box, and come back to a verified fix [3]. Note the word "verified."

Review is the bottleneck. As models propose bigger changes, humans have to review more, and the team calls this the deeper challenge [3]. Aman says "Code review kind of sucks," [3] and suggests models could highlight the important parts of a diff, gray out the boring ones, flag likely bugs, and walk reviewers through changes in logical order [3].

Apply, and why "simple" matching fails. The team's product experience shows why exact checks matter. Frontier models are good at sketching a change but surprisingly bad at producing exact diffs, messing up simple things like counting line numbers in large files [3]. Simple deterministic matching, they say, fails at least 40% of the time [3]. So they train a separate model to apply changes [3]. Even a step as basic as placing an edit correctly can't be assumed to work.

Benchmarks can lie. They warn that benchmarks are misleading: real programming involves messy, half-specified instructions, and popular benchmarks like SWE-bench are contaminated in training data, so models can hallucinate the right file paths without seeing the codebase [3]. They lean heavily on qualitative vibe checks and private evals [3]. The same idea applies to your own tests: a test set the system under test has already seen can't tell you much.

Formal verification: the dream and the pushback. Arvid pushes the argument furthest. He imagines a future where "I think people will just not write tests anymore." [3] Instead, a model would suggest a spec for each function and a reasoning model would prove the implementation matches it, possibly scaling to whole codebases, since work already exists on verifying systems down to the hardware [3]. He even speculates that one might someday prove a language model is aligned, which Fridman notes would span the full range from AI safety to bug finding [3]. The others push back that intent is often hard to specify formally, and that side effects and external dependencies like a payment API are hard to cover [3]. That's the limit of formal verification in this conversation: a proof is only as good as the spec it proves, and writing the spec is the hard part.

Where They Agree, and Where They Don't

Agreement: correctness has to be mechanical, not a matter of feel. FFmpeg's bit-exactness turns correctness into an exact, bit-for-bit match with the reference [1]. TigerBeetle's asserts turn an impossible state into a crash the moment it does [2]. Cursor's most promising synthetic-data idea depends on outputs that can be easily verified, as with proofs or code that passes tests [3]. All three rely on checks a machine can run, not on someone looking at the output and judging it fine.

Agreement: scale changes everything. Kieran and JB talk about a test matrix spanning operating systems, compilers and CPU architectures [1], and a codebase whose Windows build pulls in about 16 million lines [1]. Prime says the 5,000 to 10,000 line mark is where design choices start to bite [2], and Lex says one bug in a 20,000-line codebase can take days to find [2]. The Cursor team says each extra zero in requests per second brought new surprises, including overflows in database tables [3]. Everyone agrees that informal habits that work at small scale fail at large scale.

Agreement: AI finds bugs badly and reports them carelessly. Kieran describes AI-generated security reports with industry deadlines landing on volunteers [1]. Prime cites curl's maintainer being flooded with bogus AI reports and calls it a "denial of attention" problem [2]. The Cursor team explains why: bug detection is rare in pre-training data, and models lack the calibration to know which bugs matter [3]. The maintainers see the effect, and the toolmakers explain the cause.

Agreement: understand the code before trusting a change to it. JB warns that reading code is far harder than writing it, which is why he's wary of rewrites [1]. Prime found that reading AI-generated code engages a different skill than writing it, and learned the hard way to understand old code before deleting it [2]. The Cursor team treats human review as the bottleneck and wants tools that make reviewing easier [3].

Disagreement: will tests disappear? Arvid imagines that people "will just not write tests anymore" because specs and proofs will take over [3]. His colleagues push back that intent is hard to specify formally and that side effects and external dependencies resist proof [3]. The FFmpeg world shows why the skeptics have a point in practice: the "spec" for a decoder is ultimately a reference output, and building up enough real samples to exercise every coding tool took years of asking the public for files [1]. Arvid holds his view because work already exists on verifying systems down to the hardware, and because reasoning models are improving [3]. The skeptics hold theirs because real software has messy intent and talks to the outside world [3].

Disagreement, or at least tension: AI bug finding as a gift or a burden. From Google's point of view, as Kieran fairly presents it, "they have substantial resources working on the security of open source projects" and see themselves as "contributing by doing that" [1]. Kieran's view is that without fixes, funding or a sense of proportion, the reports mostly shift work onto volunteers [1]. The Cursor team is optimistic about training better AI bug finders [3], but their own point about calibration suggests the burden will continue until models learn which bugs matter [3].

Different emphasis: crash versus survive. TigerBeetle-style asserts crash the program when an impossible state occurs [2]. VLC was built from the start to handle broken or incomplete input [1]. These don't contradict each other. A player should cope with a damaged file from outside, while a program should stop when its own internal logic is violated. But builders need to decide consciously which kind of failure they are dealing with. The sources don't spell out this distinction; it comes from putting the two practices side by side.

Different emphasis: languages as a safety net. Prime likes Rust's automatic memory freeing and explicit mutability, and Zig's optionals, which help prevent null pointer bugs [2]. Kieran and JB value Rust's goals but insist it meet FFmpeg's testing bar, and warn that mixing it with handwritten assembly breaks the safety model [1]. Safer languages help, but none of the speakers treats them as a substitute for testing.

Why It Works

The sources offer several mechanisms.

Exact reference outputs make every change checkable. With bit-exactness, every implementation has to produce identical output for a given sample [1]. So a hand-tuned assembly routine that runs 62x faster than C [1] can be checked against a slower reference just by comparing bytes. Without that rule, as in MPEG-2, there is no single right answer to compare against, which Kieran calls one of the biggest mistakes the industry made [1].

Breadth of input finds breadth of bugs. A large collection of real files lets maintainers "test bit exactness across the huge range of coding tools" [1], because different files exercise different parts of a codec. Kieran's CineForm story shows the flip side: one simple animation sample was enough to get started precisely because it used few coding tools [1]. That's why it couldn't prove the whole decoder correct. Deterministic simulation testing gets the same kind of breadth artificially, running the equivalent of hundreds of years of random input [2].

Asserts shorten the distance between cause and symptom. Lex's reason for asserts everywhere is that, without them, a single bug in a 20,000-line codebase can take days to track down [2]. An assert that crashes on an impossible state stops the program close to where things went wrong, instead of letting bad state spread. Keeping them on in production, as TigerBeetle does [2], means the checks also cover the conditions real users create.

Comments and labels steer attention. Arvid's per-line danger comments work because humans forget and models pay more attention to what's labeled [3]. Writing the risk next to the code keeps it in front of whoever touches it next, whether that's a person or a model.

Verification is easier than generation, and progress depends on it. Aman's point that AI feedback works when verifying is easier than generating [3], and that verifiable outputs such as proofs and passing tests are the most promising source of synthetic data [3], explains why built-in checks will matter more as AI writes more code. A codebase with strong tests and asserts gives any generator, human or AI, a way to find out quickly that it's wrong.

Formal proof removes the need for sampling, but only against a spec. Arvid's vision replaces sampled testing with a proof that an implementation matches its spec [3]. The objection his colleagues raise explains the limit: if intent can't be written down formally, or the code depends on something like a payment API, the proof can't cover what matters [3].

Where It Applies, and Where It Doesn't

Applies strongly: code that processes untrusted or messy input. FFmpeg says outright that "it processes untrusted data" [1], and the Repulsive Grizzly bug came from one malicious request [2]. Anything that parses files, network requests or user-supplied queries is where asserts, fuzzing-style random input and exact reference checks pay off most.

Applies strongly: long-lived, widely shared code. VLC runs from Windows XP to Windows 11 and on OS/2 [1]; the Falcor bug had been in production for years with nothing to roll back to [2]. The longer code lives and the more people depend on it, the more a permanent test suite is worth. Fridman's closing quip from Reddit fits here: "nothing is as permanent as a temporary solution that works." [3]

Applies strongly: projects past a few thousand lines. Prime's 5,000 to 10,000 line threshold [2] and Lex's 20,000-line example [2] mark roughly where a codebase stops fitting in one person's head.

Applies with care: hand-optimized code. The assembly in dav1d and FFmpeg [1] is exactly where subtle mistakes hide, and where bit-exact comparison against a reference is most valuable. JB's warning that pairing Rust with assembly breaks the safety model [1] means language-level guarantees can't be relied on here.

Applies less: solo, fast-moving work. Prime admires Pieter Levels' push-straight-to-production style for a solo developer but says it wouldn't work at a company with hundreds of engineers [2]. A prototype with one user may reasonably trade some rigor for speed. The sources suggest that trade flips as teams and user bases grow.

Doesn't fully apply: fuzzy intent and external dependencies. The Cursor team's pushback on formal verification shows that proof-based checking struggles where intent is hard to specify, or where side effects and outside services like a payment API come in [3]. There, tests against real behavior and human review remain necessary.

Doesn't apply as a blanket severity rule. Kieran's garden-shed point is that not every bug is a crisis. Of the lock on a home he says "it's not there to protect nuclear secrets" [1], and a flaw in an obscure 1990s game codec [1] shouldn't be treated like one in a core path. The Cursor team says models still lack calibration about which bugs matter [3]. Checks tell you something is wrong. Judging how much it matters still needs human context.

Doesn't apply: trusting AI output unchecked. Only about 2.7% of developers in the survey Prime and Lex discuss highly trust AI output [2]. Prime introduced more bugs once he started "autopilotting" [2], and the Cursor team says frontier models are strikingly bad at finding bugs when simply asked [3]. AI can help with verification, but it can't replace it yet.

What To Do With It

1. Define a reference output and demand exact matches. Wherever your code transforms data, such as parsing, encoding, rendering or computing, follow FFmpeg's bit-exactness model: keep reference outputs for a set of inputs and fail the build on any difference [1]. Kieran's verdict on MPEG-2 shows what happens when there is no exact definition [1].

2. Build a shared, automated test matrix early. Like FFmpeg's FATE, run your tests across every operating system, compiler and architecture you claim to support, on machines other than your own [1]. If you say you run on it, test on it.

3. Collect real-world samples on purpose. Ask users and partners for the odd files and inputs they depend on, as VideoLAN did when it tweeted for samples [1]. One company's "hundred thousand of these files" [1] can do more for coverage than weeks of writing test cases by hand. Keep simple samples too: a plain case, like Kieran's animation file with flat blocks, is where debugging a new component should start [1].

4. Add asserts that crash on impossible states, and leave them on in production. Take TigerBeetle's NASA-style rule as a benchmark: at least two asserts per function, kept on in production [2]. Treat warnings as errors, as Lex does [2]. Start before the 5,000-line mark, when adding them is cheap [2].

5. Run deterministic simulation or large-scale random input. Feed your system randomized input in a reproducible way, as TigerBeetle does to simulate hundreds of years of use [2]. Prime found bugs in his own proxy and game projects this way that he says he would never have caught otherwise [2].

6. Test your system against malicious requests. Prime's Repulsive Grizzly bug came from one request asking for huge ranges with a "materialize" flag [2]. For every endpoint or parser, ask what the most expensive input someone could send would be, and write a test for it.

7. Label dangerous code on every line. Follow Arvid's practice and comment risky code heavily. It helps humans who forget and models that pay more attention to labeled code [3].

8. Check AI changes before they reach your working files. Borrow the idea of Cursor's shadow workspace: let AI changes run against type checks and tests in an isolated copy before they reach your files [3]. Review AI output as closely as Prime learned to after his Copilot "autopilotting" experience [2].

9. Triage bug reports by real-world severity, and send fixes with them. If you run automated or AI bug hunting on someone else's code, learn from the FFmpeg dispute: understand how volunteer projects work, don't announce before fixes exist, and send patches or funding, which Google eventually started doing [1]. If you're on the receiving end, rank reports by how much the affected code matters, not by the label on the report [1][3].

10. Use formal specs where intent is crisp, and tests where it isn't. Where a function's contract can be stated precisely, consider specs and proofs along the lines of Arvid's vision [3]. Where side effects, external services like payment APIs, or fuzzy intent are involved, keep writing tests, as his colleagues argue [3]. Whatever tools or languages you adopt, hold them to the testing and stability bar Kieran sets for Rust in FFmpeg [1].

Sources

1. FFmpeg and VLC with Jean-Baptiste Kempf and Kieran Kunhya: Codecs, Assembly, and the Volunteers Behind Internet Video · Lex Fridman Podcast
2. The Primeagen: Programming, AI, ADHD, Productivity, Addiction, and God · Lex Fridman Podcast
3. Cursor Team: Future of Programming with AI · Lex Fridman Podcast