AI Failures Expose Testing Gaps And Slop Writing

Narrative

Opening the investigation

The speaker opens by framing the talk around a simple idea: AI failures are a rich source of lessons. Vishal Srivastava and Tanmay Shah say they studied the public AI incident database to ask what those failures reveal about how AI systems should be evaluated, especially at the system level rather than just at the model level.

They argue that the number of AI failures has risen steeply, particularly in the era of foundation models. Since enterprises now have far more AI use cases than people can inspect one by one, they say a structured way of investigating failures is necessary.

A three-part view of failure

Vishal proposes that AI failures should be understood across three dimensions: development, deployment, and business context. Development includes issues such as data quality, tool architecture, and system design. Deployment is where controls can contain problems before they reach users. Business context is the setting in which the system is used, where failures can create reputational, legal, or financial harm.

From there, he breaks the framework into 13 sub-dimensions. Six describe technical strength: data quality, task suitability, predictive validity, fairness, failure modes, and explainability. Four describe deployment controls: decision authority, human mediation, exposure control, and monitoring. Three capture business impact: financial consequences, legal consequences, and scale, meaning how many users are affected.

What the incident data shows

Looking back at incidents through this framework, the speakers say their 13 dimensions cover almost 98% of AI failures. They also find that failures usually involve several dimensions at once, with an average of six sub-dimensions appearing in each incident.

Not all dimensions matter equally, though. Vishal says some are more strongly associated with harm than others. Human mediation and monitoring stand out as especially important, while factors like scale and system design appear often but are less tightly linked to harm. When the dimensions are grouped, deployment controls come out as more closely associated with harm than either business impact or technical failure. Their point is that deployment controls deserve especially close attention for high-risk systems.

From failure analysis to materiality

The team then introduces a materiality scale. “Materiality” here means how important or risky a use case is. They argue that if some AI uses are more likely to lead to harm than others, organizations should rank them and spend more effort on the riskiest ones.

This shifts the conversation from evaluating every use case equally to prioritizing by risk. The speaker’s broader message is that AI failures have structure, and that structure can guide both investigation and resource allocation.

Turning lessons into evals

Tanmay Shah then picks up the thread and explains how these lessons can shape system-level evaluations. He decomposes risk into four pieces: how often the model fails, whether the failure reaches a real decision, whether it goes uncaught, and how severe the consequences are.

That decomposition makes deployment central. The same model can pose very different risks depending on how much authority it has, whether a human reviews its output, and whether monitoring can catch mistakes before harm occurs. So, if risk depends on the full deployment setup, evaluation has to cover that setup too.

What to test in an agentic system

Tanmay next asks what should be tested in an agentic system, meaning a system that can take actions through tools or workflows rather than simply producing predictions. In traditional machine learning, teams test models against held-out data and measure performance with metrics like accuracy or AUC-ROC, which stands for area under the receiver operating characteristic curve, a common measure of ranking quality.

In an agentic system, the test surface is broader. The team asks whether retrieval brings back the right information, whether tools fail safely, whether human review catches mistakes, whether the agent stays within its permissions, and whether the system can recover. The logic of testing remains the same, but the boundary of what needs testing expands.

Tanmay also contrasts traditional model evaluation with agentic evaluation. In the latter, there are many possible inputs, tool responses, and action sequences, so teams test selected scenarios. Sometimes another AI agent or AI judge generates or grades the tests, but that judge can also make mistakes. That is why they emphasize checking whether the evaluator is reliable, what evidence it covers, and whether it applies to the system actually being deployed.

Falsification over confirmation

Vishal then turns to a lesson from cognitive neuroscience and the work of Peter Wason, who coined the term “confirmation bias.” He recalls the classic 2, 4, 6 sequence task, where people often guess the next numbers will also be even, even though the underlying rule is broader. The point is that humans tend to look for confirming evidence rather than trying to disprove their assumptions.

Because AI systems are trained on human-generated data, the speakers argue that evaluations should be designed to falsify claims, not confirm them. They describe this as a failure-driven evaluation approach: start from a system claim, try to break it, identify where it fails, and then either constrain the system to safer territory or add supporting controls.

This becomes a build-break-fix loop. The aim is to map the trustworthy region of the system, identify uncertain and high-risk areas, and route deployment based on both reliability and materiality. For high-risk systems, they say, AI should only be used in the regions where confidence is high.

A real-world chatbot failure

Tanmay makes the framework concrete with an airline chatbot case. A customer needed to travel after a death in the family and asked the chatbot about a discounted fare. The chatbot advised him to buy a regular ticket and claim the discount afterward within 90 days. He relied on that advice, but the airline later رفض the request because its policy did not allow it. A tribunal ultimately held the airline responsible.

The speaker uses this to show the failure chain clearly: incorrect advice reaches the customer, the customer acts on it, and the organization bears the consequences. Under a build-break-fix approach, the chatbot’s policy advice would have been tested before deployment. If tests showed it could give incorrect guidance, the team could have added a policy check or human escalation, then tested again to see whether those controls stopped the error.

Closing the loop: evaluate the whole system

Vishal closes by summarizing the main message: evaluations should be risk-based, not frequency-based. Teams should examine the whole system by separating technical failure, deployment controls, and business context, then assess the materiality of each AI use case with a company-specific scale. After that, they should run system-level stress tests and make deployment decisions only once they are confident about the safe region.

The final takeaway is straightforward: evaluate the full AI system based on risk, not just one component.

Fact-check

• UNVERIFIED — The talk says the authors analyzed the “AI incident database” and that AI failures have been increasing “exponentially” over the last four years; I can’t verify the exact dataset, the trend fit, or the claimed rate of increase from the transcript alone.
• PLAUSIBLE — Framing AI failures across development, deployment, and business-context stages is a reasonable systems view, though it is a proposed framework rather than an established universal taxonomy.
• PLAUSIBLE — The 13 sub-dimensions listed (data quality, system design, predictive validity, fairness, failure modes, explainability, authority, human mediation, exposure, monitoring, financial impact, legal impact, scale) are sensible evaluation categories, but the exact decomposition is the speakers’ own model.
• UNVERIFIED — The claim that these 13 sub-dimensions “cover” almost 98% of AI failures is a specific retrospective statistic that depends on their coding method and cannot be confirmed here.
• UNVERIFIED — The claim that there are “on average, six failure sub-dimensions” present in each incident is a specific result from their analysis and remains unverified.
• PLAUSIBLE — Saying deployment controls are more strongly associated with harm than technical failure alone is plausible in high-stakes systems, but the strength and direction of that association depend on their dataset and analysis.
• PLAUSIBLE — The recommendation that AI evaluations should be risk-based and system-level rather than focused only on model accuracy is broadly consistent with best practice in high-risk AI governance.
• TRUE — It is well established that a model’s real-world risk depends not just on model quality but also on how it is deployed, who reviews it, what authority it has, and what monitoring and safeguards are in place.
• PLAUSIBLE — Decomposing risk into model failure rate, whether failures reach decisions, whether they go uncaught, and how severe the consequences are is a sensible and standard risk-analysis approach.
• TRUE — Traditional ML evaluation often uses held-out data and metrics such as accuracy and AUC-ROC, while deployment-time behavior and dataset assumptions still need separate scrutiny.
• PLAUSIBLE — Using selected scenarios, AI judges, or other agents to test agentic systems is a reasonable evaluation strategy, but the reliability of the evaluator itself becomes a critical open issue.
• TRUE — The 2-4-6 task is a classic example associated with Peter Wason and is commonly used to illustrate confirmation bias and hypothesis-testing errors, though the exact “79%” figure is not something I can verify here.
• TRUE — The general point that evaluations should try to falsify claims rather than merely confirm them is sound scientific methodology.
• PLAUSIBLE — A “build-break-fix” loop for AI evaluation and deployment is a practical and sensible approach, but the exact procedure is a proposed framework rather than a universally standardized method.
• UNVERIFIED — The airline chatbot story and tribunal outcome are specific case details that sound like a real-world incident, but I can’t confirm the exact facts, policy details, or legal finding from the transcript alone.
• PLAUSIBLE — The lesson that narrow evals can miss failures that matter in real customer-facing deployments is well supported in principle, especially for high-stakes systems.
• Verdict: The video is broadly credible as a conceptual talk about AI evaluation and risk management, but several of its key numbers, database-based claims, and the airline case specifics are self-reported or dataset-dependent and remain unverified here.

Narrative

Why the speaker stopped shipping without evaluation

Nathanael Weill opens with a confession: he has spent too much time shipping agents without proper evaluation, and he wants to explain how he “quit this addiction.” He frames the problem through his work at Air Canada, where his team builds AI solutions for different business units—operations, corporate, commercial, and loyalty—each with very specific needs.

The central difficulty is that these projects are too specialized for public benchmarks. The team is not made up of domain experts, and the actual experts are scattered across the business and too busy to spend much time helping. That combination makes it hard to build reliable evaluation sets for agents.

A telecom Q&A project that exposed the problem

Before Air Canada, he worked on a Q&A assistant for telecommunications engineers. That domain had about 10,000 documents, plus vendor documents, and the system had to know which source to search before it could answer correctly. In 2024, this meant building a retrieval-augmented generation system, or RAG: the model retrieves relevant documents first, then writes an answer from them.

But the same evaluation problem appeared there too. The team could not easily judge answers themselves, and access to experts was limited. Their solution was competing against other teams on the same task, and while it worked in practice and people used it, he says he never fully understood why it beat the alternatives. That uncertainty became the motivation for the rest of the talk.

Why more complexity did not help

He describes how the RAG system grew into a complex pipeline. Like many teams, they tried ideas from papers and publications, hoping each new trick would improve performance. In practice, those additions often failed to help, and sometimes they broke something else that had previously worked.

That led to a second problem: every time they changed the agent, evaluation became painfully slow. They would gather experts once a week, put several chatbots on a big screen, ask the same question to each, and have the experts rank them. The experts did not always agree with one another, and even they often had to look things up. With only one trial a week, the team could not move quickly enough.

Reversing the problem: answer first, then test

The breakthrough was to reverse the task. Instead of asking the agent a question and waiting for an expert to grade the answer, they started from a page of source material and asked an LLM, a large language model, to generate a question about it. Then they asked the agent to answer that question and checked whether it found the right source.

Because the answer was already known, code could do the grading automatically. That eliminated the subjective expert debate and made it possible to run dozens of evaluations a day instead of one a week. The team also discovered that removing complexity helped: once they focused on the right embedding model, chunking strategy, and BM25 settings, performance improved. BM25 is a standard text-retrieval scoring method, and tuning it correctly mattered more than piling on extra machinery.

His takeaway from that project was simple: if you cannot grade the agent, you cannot make it better.

A new Air Canada problem: contract analysis

He then returns to Air Canada and a new project that revisits the same challenge in a different form. The task is to analyze supplier contracts. Experts review clauses one by one, decide whether something is noncompliant, and suggest rewrites where needed. It is time-consuming, expensive, and risky: delays can affect supply chains, and missed clauses can create legal or business problems later.

Again, there is no public benchmark, no easy dataset to borrow, and no available pool of experts who can review every iteration. So the team tried to transfer the same lesson from the RAG project: if they could not find an existing benchmark, they would create one by turning the problem inside out.

Five ways to build a test set from the ground up

He lays out five techniques the team used or tried.

First, they tried comparing changed contracts against their original signed versions, similar to a code diff. If the agent could spot exactly what changed, that would provide a clean test. But the company did not keep every version of every contract, so they could not rely on those pairs.

Second, they started from rules. For example, if a contract must respect a cap above $1 million, they could generate a clause that either respects or violates that rule, then check whether the agent flags the violation. This worked because they could source rules from experts and documentation, and they ended up generating 275 tests with known answers.

Third, they broke good contracts on purpose. They took a signed contract, removed a clause, and asked whether the agent would notice the missing element. That was especially useful because it created strong negative examples: cases where the agent should clearly flag a problem. They combined those with contracts that should not trigger any flags.

Fourth, they tested invariance: changing things that should not matter, such as the supplier’s name, the address, or the order of clauses, should not change the agent’s output. These checks helped ensure the system was stable and not reacting to irrelevant details.

Fifth, they used templates. Their experts already worked with contract templates that contained blanks. Instead of filling one example manually, they generated many variations by combining possible values for each blank. That produced lots of synthetic contracts, some of which violated rules and some of which did not. Because the rules were known in advance, code could check the expected outcome directly.

Speed, feedback, and the limits of LLM judges

The practical gain was huge: the cycle shrank from about four weeks for expert feedback to about five minutes for scripted evaluation. He emphasizes that the best cases were the ones where evaluation could be done with exact matching or code. As soon as the team moved into LLM-as-a-judge territory—using another language model to score outputs—the process became much noisier and much harder to control.

He does not dismiss LLM judges entirely, but he argues that making them reliable is almost as hard as solving the original task. In this project, the team stayed away from them as much as possible. He also mentions other testing styles, such as trajectory testing, where an agent’s path through a sequence of steps is checked, and test-to-SQL, where known answers can again be generated if the input is constructed carefully.

The real lesson: evaluation comes before shipping

The final message is that the point of this approach is not just to decide whether a product can ship. Generated tests are a starting point: they help the team anticipate failures, improve prompts, refine ideas for removing clauses, and gather useful feedback from experts without depending on them for every iteration.

He closes by arguing that answer-first evaluation is a powerful way to break out of the slow, subjective loop that often traps agent projects. If the team can build a test set, they can improve the agent. If they cannot evaluate it, they cannot really move forward.

Fact-check

• TRUE — Air Canada is a large airline with multiple business segments, and it’s plausible that internal AI teams there would work on operational, commercial, loyalty, or corporate use cases.
• PLAUSIBLE — The speaker’s core premise is sound: many enterprise AI agent tasks have no public benchmark and limited access to domain experts, making evaluation hard.
• TRUE — For retrieval-augmented generation (RAG), finding the right source documents often matters more than the generator, and if retrieval is good, answer quality usually improves substantially.
• TRUE — Human expert grading meetings can be slow, inconsistent, and expensive, especially when multiple experts disagree on subjective outputs.
• TRUE — Reversing the evaluation problem by generating synthetic questions from known passages/documents and checking whether the system retrieves the right answer is a well-established testing strategy in RAG and related information-retrieval settings.
• PLAUSIBLE — The claim that this inversion increased evaluation throughput from “one evaluation a week” to “dozens a day” is reasonable, but it is a self-reported project-specific productivity metric and cannot be independently verified here.
• PLAUSIBLE — The claim that reducing pipeline complexity improved results is credible; in practice, added steps can introduce failure points and degrade system performance.
• UNVERIFIED — The specific 2026 Air Canada supplier-contract project, the agent architecture described for it, and the operational details are future-leaning or project-specific claims that I cannot verify.
• PLAUSIBLE — Generating tests from rules, from missing clauses in known-good contracts, from invariants, and from templates are all sensible evaluation strategies for document/contract agents.
• TRUE — Property-based or invariant testing ideas, such as changing irrelevant fields and expecting outputs to remain stable, are standard and useful for checking robustness.
• MISLEADING — Saying LLM-as-a-judge is generally too hard or too noisy overstates the case; it can be noisy and difficult to calibrate, but it is still useful in many settings when carefully designed and validated.
• PLAUSIBLE — The reported “275 tests” and “4 weeks to 5 minutes” evaluation turnaround are believable project metrics, but they are self-reported and remain unverified.
• TRUE — The broader lesson that “if you cannot grade the agent, you cannot make it better” is directionally correct: without a measurable target, iterative improvement is much harder.
• TRUE — Reframing tasks so they become easier to evaluate, even if that means slightly redesigning the product, is a common and practical engineering tradeoff.
• PLAUSIBLE — The idea that expert feedback is better used to improve the test suite and prompts, not just to patch a single failure, is a sensible iterative development loop.

Verdict: The talk is broadly credible and aligns with established evaluation practice in AI, but many of the strongest claims are self-reported project metrics or specific internal Air Canada details that remain unverified.

Narrative

What “slop” means to the speaker

Louis-François Bouchard opens by saying he wants to help fix what Andrei Karpathy called the “slop apocalypse,” which he says is already visible on social media. By “slop,” he means writing that feels generated and is unpleasant to read: it leans on overused words like “delve,” stays too general, says very little, repeats itself, hallucinates facts, and often misses the right tone. His bigger point is that better models alone have not made this problem disappear; in his view, slop just keeps scaling.

Introducing Tone-Bench

To study the problem, he and his team at Towards AI built a new benchmark called Tone-Bench. He explains that they are not trying to score individual “slop words,” but to measure how sloppy a piece of writing is overall and, more specifically, whether a model can produce creative writing that feels like something he himself would say.

He lays out the talk’s path: first, why a new benchmark is needed; then how the benchmark works; what it measures; how it was built; what it cost; and what they have learned about writing with AI.

Why another benchmark was necessary

Bouchard argues that the need is obvious from online platforms like LinkedIn and X, where generated content is increasingly common. For him, the issue is practical as well as philosophical: Towards AI is a small team that produces a lot of educational content, especially for AI engineering, and reviewing AI-generated drafts has become a constant annoyance.

He adds that his own background made the project a natural fit. He has been evaluating AI models since his master’s and PhD work, and Towards AI already has the people and systems needed for large-scale evaluation: AI engineers, creative writers, and editors. Public reaction on X also convinced him that others wanted a benchmark for creative writing.

How the benchmark works

The core idea is subjective by design: the benchmark asks whether a model can write like him. He defines that in a simple, human way — can he read it aloud without cringing at words or phrasing he would never use?

The process starts with a prompt that includes a brief and research material. The model is asked to generate a full video script that he could have written. They then evaluate the result against rubrics using an automated pipeline. Each model is tested on 10 scripts, some published and some not, so they can also check for contamination, meaning whether a model has seen the benchmark material during training.

Why they generate multiple drafts

For each task, the system generates five drafts instead of one. He says this is to measure intra-model variability, the spread in quality between outputs from the same model. That matters especially for creative work, because one lucky draft can make a model look better than it really is.

He gives Grok 4.7 as an example of a model that can occasionally produce an outlier draft as good as a top model like Opus 5.5. Five drafts, he says, was the best balance between cost and seeing that variance clearly.

What the judges measure

Bouchard says the benchmark focuses on nine metrics, which he groups into five broad areas. First is tone: does it sound like him? Second is writing quality: does it have good hooks, emotional transitions, and the ingredients of a good story? Third is instruction following: does it obey the requested length, format, and placement of elements like images? Fourth is research accuracy: does it use the provided brief correctly, or hallucinate? Fifth is slop, measured with EQ-Bench’s slop score along with their own measures.

The judging prompt is intentionally extensive. He says each judge gets around 1,000 words of examples and instructions per metric, plus the script, the brief, the research, and a sample of his own writing as guidance. In total, it is about a 14,000-token prompt. For tone and voice, the judge first chooses among six categories and then assigns a rating, which he says works better than using only binary labels or percentages for this kind of qualitative task.

The problem with LLM judges

The judgments are automated because the scale is too large for humans alone. He notes that they are evaluating thousands of scripts across roughly 120 models, with five drafts per task. But he also warns that LLM judges have biases: many prefer themselves, and many OpenAI models seem to favor OpenAI outputs. He jokes that Anthropic and OpenAI may even be in a kind of war with each other in their training data.

Because of that, he says it is important to use judges from different model families if you want a more trustworthy result. They also tried to add a human layer. He and three teammates manually compared 1,000 pairs of degraded scripts, and he wants to expand that effort with community help later.

The cost of building it

The benchmark took substantial time and money. He estimates about 500 hours of kickoff work to build the 10 scripts, define the rubrics, gather examples, and figure out how to quantify quality. On top of that, he spent months iterating on the benchmark using several subscriptions and many experiments, which cost thousands of dollars.

He emphasizes that even small changes are expensive. Changing one rubric detail can cost more than $2,000, and changing one line in a model prompt can cost more than $4,000. His message is clear: this kind of evaluation infrastructure is costly to build and expensive to refine.

What he learned about writing with AI

From the benchmark, Bouchard says the goal is not to find a model that produces one perfect creative response. Instead, the useful model is the one that is least annoying to work with and gets you to a good result reliably. In the current results, he says GLM 5.3 flash is extremely cheap and very strong, while Opus 5.5 extra high is the best but far more expensive. He also says Max thinking is not usually worth using for writing.

His practical advice is to write extremely long, detailed prompts with many examples, including negative examples of what not to do. He also recommends using a high-thinking judge once, or at most a few times, to review the output and help steer it away from slop. For production work, he suggests generating several drafts with a cheaper model, then using a smarter model to merge the best parts. Even then, he says human review is still necessary.

Wrapping up and releasing the benchmark

Bouchard closes by stressing that Tone-Bench is subjective and tied to his own voice, so it should not be treated as a final truth about model quality. Still, he believes it is a useful signal for identifying which models are better writers and which are more prone to slop.

He ends by encouraging people to build their own evaluation pipelines and to reach out if they want help. Tone-Bench, he says, is now live, with graphs, comparisons, implementation details, and methodology available for anyone who wants to explore it.

Fact-check

• PLAUSIBLE — The speaker’s core premise that AI-generated writing often sounds generic, repetitive, or “sloppy” is consistent with common user experience and with known limitations of LLMs, though the exact subjective threshold varies by reader.
• PLAUSIBLE — The claim that simply scaling model size/training has not eliminated bland or overgeneralized writing is reasonable; better models can still produce generic prose, but this is a qualitative judgment rather than a settled benchmark fact.
• UNVERIFIED — “Karpathy termed” a coming “slop apocalypse” in 2026 is a specific attribution and forecast that I cannot verify from training knowledge.
• UNVERIFIED — The existence, design, and public release of a benchmark called “Tone-Bench” are recent, project-specific claims that I cannot confirm externally.
• PLAUSIBLE — Measuring “tone,” “writing quality,” instruction-following, research accuracy, and slop-related features as separate dimensions is a reasonable evaluation approach, though the exact rubric is subjective.
• PLAUSIBLE — Using multiple generations per model to capture intra-model variability is sound methodology, especially for creative tasks where outputs can vary a lot.
• PLAUSIBLE — Using LLM judges for evaluation can work but can also introduce model-family bias and self-preference; this is a real and widely recognized concern.
• PLAUSIBLE — The claim that OpenAI-family judges may favor OpenAI outputs, and that different judge families can show bias patterns, is plausible, but the speaker’s specific comparative results are not independently verified here.
• UNVERIFIED — The report that the team manually compared “1,000 AB pairs” and used “around 500 hours” to build the benchmark is self-reported project data and cannot be checked from the transcript alone.
• UNVERIFIED — The quoted cost figures for changing rubrics or prompts (e.g., “more than $2,000” and “more than $4,000”) are specific internal expenses and remain unverified.
• UNVERIFIED — Claims about model rankings and pricing on the benchmark, such as “GLM 5.3 flash is extremely good” or “50 times cheaper than Opus 5.5 extra high,” are benchmark-specific and may reflect a moving landscape that I cannot verify from training knowledge.
• PLAUSIBLE — Recommending long, detailed prompts with examples and negative examples is consistent with practical prompt-engineering experience, though it is not guaranteed to solve style issues.
• PLAUSIBLE — The suggestion to use a higher-quality model as a reviewer/judge and to merge multiple cheaper drafts into a final output is a sensible workflow, but it is a practice recommendation rather than a settled scientific result.
• PLAUSIBLE — The statement that human review remains necessary for high-stakes creative or editorial output is broadly correct.
• MISLEADING — The video sometimes presents highly subjective benchmark outputs as if they were an objective ranking of “best writing” or “least sloppy”; because the benchmark measures the creator’s own tone preferences, the results are informative but not universally generalizable.

Verdict: The video is broadly credible as a description of one team’s subjective benchmark and workflow advice, but many of its concrete leaderboard results, cost numbers, and release claims are self-reported and remain unverified, and the benchmark’s conclusions should be treated as preference-sensitive rather than objective fact.

Narrative

Opening the workshop

The speakers begin by checking who in the room has created video content before, who does it without AI, and who started because of AI tools. They then ground the session in a simple memory statistic: people remember only about 10% of what they input after three days, but with a visual aid that can rise to 65%. That becomes the premise for the workshop: use AI to make content more memorable, more efficient to produce, and easier to scale.

Sarah Cheng introduces herself as head of developer experience at Cerebras, where she helps tell the story of the company’s hardware and fast inference systems while also making content on her own channels. Kova Lee introduces herself as a new member of OpenAI’s developer experience team and says she previously created content full time for short-form platforms. Together, they frame the talk as a practical system for making content with AI, not just a collection of tips.

A six-stage content system

They explain that their process follows six stages: ideating, scripting, recording, editing, repurposing, and publishing. The rest of the talk is organized around that workflow. Their point is that content creation becomes much easier when it is treated as a system, rather than a one-off creative burst.

They also set expectations for the tools they’ll use throughout. Much of the workflow sits on top of ChatGPT, previously known as Codex, using GPT 5.6 Soul ultra fast, a model they say runs at 750 tokens per second. That speed matters most when processing large scripts and large files. They also mention that a written version of the workshop exists as a blog, so people do not need to copy every prompt live.

Building ideas from a swipe file

The first stage is ideation. The speakers say the best starting point is a swipe file, meaning a personal library of references, inspirations, questions, screenshots, and links that capture your taste. Sarah shows hers as a colorful website where she stores videos and Pinterest images, though she notes that a swipe file can also live in Notion, Obsidian, or plain notes. Kova adds that even a simple Notion page with links pasted in works well.

They stress that a swipe file does more than inspire the creator. It also gives an agent or AI system a clear view of creative preferences, so it can make better suggestions. Sarah says she uses that approach to build research tools for YouTube, especially because thumbnails and titles are so important to performance. Since packaging can determine whether people click, she built a tool that lets her pull thousands of videos from favorite creators and remix thumbnail ideas. She also built a simulator to test whether a title and thumbnail stand out on a YouTube homepage before making the video.

Why packaging matters so much

Both speakers emphasize that titles and thumbnails deserve far more attention than creators usually give them. Sarah argues that people often spend only a few minutes on that part, when it should take close to half of the effort because it can be the difference between 500 views and 5 million. Kova reinforces the point by saying that title images and headlines are the first thing people see, whether the content is a video or an article.

On the swipe-file side, Kova says hers is less polished but equally useful: every time she sees something she likes on Twitter, she pastes the link into Notion. Over time, that becomes a living record of what she recognizes as good content. The speakers argue that this kind of reference library helps AI understand taste far better than text instructions alone.

Scripting by speaking first

The next stage is scripting. The speakers say they often begin by talking out loud instead of writing immediately, because writing from scratch can sound too polished or too marketing-heavy. Speaking the idea helps them explain the concept in a more natural, educational way. They then feed that into ChatGPT or use voice mode, which can interview them, ask what is unclear, and help them decide what should be cut.

They describe concise clarity as the two qualities that matter most in content writing. Sarah also says it helps to compare performance relative to context, not in isolation. A post should be judged against your own historical posts and against similar topics, not just by raw engagement. She mentions automations and monitoring tools as a way to keep track of that comparison continuously.

Turning scripts into shot lists

Once a script exists, they move to production planning. Kova says she likes to create a shot list from the script so short-form content can keep the audience engaged with frequent visual changes. Her process includes one pass that annotates the script with A-roll, B-roll, screen recordings, and graphics, and a second pass that creates a checklist for filming.

They also discuss tools for capturing demo footage. Kova mentions Coast, which integrates with the Codex CLI and records the computer over time locally, making it easier to find moments where a demo was created and re-record them. Sarah adds CleanShot, which she likes for fast screen recording, screenshots, blur effects, arrows, annotations, and other quick edits without needing to open a full editor.

Organizing footage and assets

The conversation turns to editing discipline. Sarah says it is important to keep A-roll, meaning the main talking footage, separate from B-roll, which includes side shots, screenshots, and screen recordings. She says ChatGPT can help organize and name these assets, and can even attach media once the files are prepared.

Both speakers stress asset organization. Sarah says editors such as Astro, Premiere, DaVinci Resolve, and Final Cut can all work, but the workflow becomes much better when the files are named and structured properly. She also says CapCut is her favorite editor, despite its reputation as a TikTok tool, because the desktop version is surprisingly strong.

Designing a visual system

Because the model is fast, they say it becomes practical to spend more time on design. Sarah explains that Figma now has enough plugins and MCPs, meaning model context protocols and related integrations, that it can be part of the AI-assisted design workflow. She says they often ask ChatGPT to generate many different branding and logo directions, then pick the version that feels right.

Kova adds that she used a similar process to turn her own recent Instagram videos into a Figma design system. By studying her last 50 videos through a prompt, she turned recurring visual style into a reusable document. The goal, for both of them, is to turn personal taste into a system that an agent can help maintain.

Editing with AI or with more control

The speakers then contrast different ways of editing. Sarah explains that there are APIs for video tools, and she likes using ChatGPT to set those up. She mentions HyperFrames by HeyGen as one example. With it, she can feed in raw footage, ask for a specific edit, and get captions, text animations, and branded styling back with very little prompting. She also notes that HeyGen is useful when she needs a tiny avatar correction, such as fixing a single mistaken word.

Kova clarifies the difference between pre-rendered AI video tools and traditional editors. If you want granular control over layers, clips, and timelines, she says you still want a real video editor. But if you are willing to let an agent handle the render-and-retry cycle, tools like HyperFrames can be enough. For her, the choice depends on how much control the creator wants to keep.

Custom tools for sound and visual effects

Sarah says she prefers building her own tools when she wants precision. She describes a music pad with nine buttons that she one-shotted, meaning she asked the model to create it in a single pass. The pad lets her click in sound effects like whooshes, clicks, and shutter sounds, which can then be placed automatically on a track. That gives her a fast way to add audio accents exactly where she wants them.

Kova gives examples of how those sounds are used: whooshes for transitions, shutter clicks when images or screen recordings appear, and similar cues to keep the rhythm of a video alive. She also describes how she uses AI to transform the visuals in her videos, such as enhancing a blank dorm-room background with shelves, lights, a fan, and other elements. She says this kind of background transformation, once done with Photoshop’s generative fill, is now much easier with image generation in ChatGPT.

Creating stronger visuals from prompts

Kova goes further into visual experimentation. She says she used computer use with Astro to prompt floating objects into a video. The model went into After Effects, generated 3D models in Blender, exported them as GLB files, and layered them into the final clip. She also mentions animated titles that were generated by taking text and turning it into collage-like watercolor GIFs.

Her point is that AI can generate not just text and avatars but actual motion design elements if the prompt and reference are strong enough. She points people to more tutorials on @kovacut, but the broader lesson is that design and motion can now be produced as part of the same workflow as writing.

Repurposing and scheduling content

The talk then shifts into repurposing. Sarah says it is now easy to clip long-form content into short-form posts for YouTube Shorts, TikTok, and Instagram Reels. A single long interview can take her about a month to prepare, film, and edit, so she wants to extract the best sound bites and distribute them across platforms.

Captions become a major issue here. Sarah says it is obvious when captions are AI-generated, so she tries to avoid the usual patterns by studying her own voice, her brand, and her swipe file. She also distinguishes between her personal voice and her company voice, and between different formats such as interviews, demos, and short conversations. She says one useful trick is to paste in an article about signs of AI writing and tell the model not to use any of those habits.

Finally, she describes the publishing end of the workflow. If she has one video and six cutdowns, she may want to schedule them over several weeks across multiple channels. Rather than write all those captions manually, she uses APIs and ChatGPT to set up posting through Buffer.

Q&A: where the systems live

In the question-and-answer section, they discuss where their content systems live. Sarah says much of hers still lives in Notion, including her swipe file and historic scripts, and the Notion connector for ChatGPT makes it easy to use without overthinking structure. Kova says she has moved more of her workflow into ChatGPT Space, although she still appreciates Notion’s design.

Kova also explains that she maintains detailed skills for specific editing workflows, especially Premiere. She groups sub-skills under a broader Premiere skill and updates them over time as she learns better practices for color grading, sound effects, and captions. Sarah says she is most excited by Dots for proactive automation, such as monitoring Twitter or LinkedIn for high-performing ideas, flagging content that needs attention, and reminding her to post. Kova agrees, saying Dots feels like a proactive personal assistant rather than a scheduled task runner.

Learning from performance and algorithm data

The discussion turns to analytics and algorithmic feedback. Sarah says she has connected the Twitter API directly to ChatGPT so it can pull data and compare content performance more intelligently. She notes that captions are especially different now because the model can test hooks and compare engagement on near-identical cutdowns to see what works. The idea is to create apples-to-apples comparisons so the feedback is actually useful.

They also discuss how to study platform algorithms. Kova says Twitter’s algorithm is public and open source, so she has used that material with ChatGPT to understand how scoring works. They suggest that creators should use AI to surface patterns and frameworks, not just chase whatever topic is currently trending.

Making writing sound human

When asked how to keep content from sounding AI-generated, Sarah says the final product should still be written by the creator, with AI used mainly for research and cleanup. She recommends making writing more human by using metrics, numbers, examples, and personal anecdotes. Kova adds that creators should live in the real world, develop their own point of view, and avoid simply absorbing internet opinions. She says curation matters: treat yourself as a curator of your life and experiences, because that shapes the content you make.

They also connect authenticity to experience. Sarah mentions a framework from Tarik at Cloud Code about “reaping and sewing,” where the real work of engineering becomes the raw material for authentic content. She also tells a story about Tice Simonian, whose content ideas came from conversations with his sister about fashion. For both speakers, creative ideas often emerge from real curiosity, not from forcing yourself to “make content.”

Music, control, and style

The speakers close the main discussion by contrasting different creative styles. Kova says her voice is most visible through video and music, especially when music, visual rhythm, and text all align. She uses the example of the yellow dancing dog video paired with Steve Lacy’s “playground,” where the combination of music and imagery creates a strong vibe. She says viral content often comes from that kind of coherence.

Sarah says her work is more educational and technical, so the script matters most for her, while the visuals and motion are supporting elements. She likes outsourcing tedious tasks like captions and sound effects to ChatGPT controlling CapCut on her desktop. For her, AI is especially useful for polishing the edit, not replacing the human story.

They end by noting that creators can choose different levels of control. Some people want AI to handle almost everything, even making editing decisions as they talk; others want to direct every cut. The best approach depends on how much creative freedom and control the creator wants to keep, but the larger message remains the same: AI can turn content creation into a repeatable system without taking away the creator’s voice.

Fact-check

• PLAUSIBLE — The broad workflow they outline (ideate, script, record, edit, repurpose, publish) is a sensible content-creation framework, though it’s more a practical organizing scheme than a verifiable factual claim.
• UNVERIFIED — “50% of a YouTube’s performance is really based on its packaging” is a specific performance split and sounds like an opinion/industry heuristic rather than a checkable universal statistic.
• UNVERIFIED — The claim that their fast model runs at “750 tokens per second” and is “one of the fastest models inside ChatGPT” is highly specific and product-dependent; without external verification it should be treated as unconfirmed.
• UNVERIFIED — Sarah Chieng’s role as head of developer experience at Cerebras and Kova’s recent move to OpenAI may be true, but they are self-reported professional affiliations and not independently verifiable here.
• UNVERIFIED — The statement that Cerebras powers models for OpenAI, Mistral, Cognition, etc. is plausible given Cerebras’ positioning, but the exact customer list and scope are company-specific and unverified in this transcript.
• PLAUSIBLE — Using swipe files, reference libraries, and custom research tools to inform titles, thumbnails, and content style is a well-established creator workflow and likely helpful, though the exact effectiveness varies by person.
• MISLEADING — “After 3 days, people remember about 10% of the information … with a visual aid it increases to 65%” is presented as a clean stat, but memory retention depends heavily on context and the numbers are not a general law; it’s an oversimplified educational claim.
• PLAUSIBLE — Using AI voice mode to interview you, generate script drafts, and refine hooks for clarity is a reasonable use of current LLM tools, though quality depends on the prompt and the model.
• PLAUSIBLE — The advice to differentiate your own voice from your company voice, study successful captions, and avoid obvious AI-written phrasing aligns with common creator best practices.
• UNVERIFIED — Claims about specific tools (e.g., Coast recording your computer “over all time,” HyperFrames, CleanShot, Astro, or CapCut being the “favorite”) are product/use-case endorsements and workflow opinions, not independently checkable facts in this transcript.
• PLAUSIBLE — Organizing assets into A-roll and B-roll, building shot lists, and using sound effects like whooshes/clicks are standard video-editing practices.
• UNVERIFIED — The examples of AI generating floating objects, animated titles, or doing end-to-end edits through computer use are plausible demos, but the transcript gives anecdotal examples rather than reproducible evidence.
• MISLEADING — The suggestion that AI can “owns it end-to-end” for posting, captions, and editing overstates current reliability; these tools can automate parts of the process, but they still commonly require human review and correction.
• PLAUSIBLE — The claim that AI-generated captions often sound obvious and that adding metrics, examples, anecdotes, and personal specifics makes content feel more human is consistent with writing best practices.
• PLAUSIBLE — Their point that strong content often comes from real experience, lived taste, and domain expertise rather than simply copying internet trends is subjective but broadly reasonable.
• UNVERIFIED — References to specific examples like “the yellow dancing dog video,” “Steve Lacy’s song playground,” or particular OpenAI/Astra demos are anecdotal and not something I can confirm from the transcript alone.
• PLAUSIBLE — The general idea that visual/text/music alignment helps short-form videos perform well is a credible creative heuristic, though “will go viral” is far too deterministic.
• MISLEADING — “If everything is aligned, it will go viral” is an overstatement; alignment may help, but virality depends on many other factors and cannot be guaranteed.
• PLAUSIBLE — The discussion of non-technical people working in technical environments as an important audience segment is a reasonable strategic observation.
• UNVERIFIED — Statements about OpenAI rethinking who counts as a “developer” and expanding developer audiences are organizational strategy claims and may be true, but they are internal perspective rather than independently confirmable facts.

Verdict: The video is credible as a practical creator-workflow talk with lots of reasonable advice, but many of the concrete performance numbers, tool capabilities, and “we do this with AI” examples are self-reported or product-specific and remain unverified here.

Narrative

Opening the “it depends” question

Max Kanat-Alexander opens with a joke about how every discussion of code quality seems to end the same way: with the unhelpful answer, “it depends.” He says that isn’t enough on its own, so the talk will try to build a framework for understanding what code quality is really for and when it matters.

Code quality as a tool for understanding and execution

He argues that software success comes down to two things: understanding a system and executing correctly on that understanding. That is why engineers use debuggers, observability, evaluation tools, and tests: all of them help people understand what the system does or help them act on that understanding.

From there, he says the two most important understandings for a software engineer are: what the system actually does, and how to change it safely. On tiny programs, that is easy. On real systems, he says, the complexity explodes, and you can no longer describe the whole system in words. Instead, you can only understand pieces and components.

Why structure matters

Kanat-Alexander uses Chromium as an example of a massive codebase with enormous complexity. The whole point of code, he says, is structure: a program should have an identity that makes it understandable as a component rather than just a pile of instructions. Two programs may both print “Hello World,” but one reads as a structured piece of software and the other as a sequence of opaque steps.

He suggests that earlier discussions of readability and testability were really pointing at this deeper issue: whether the system has understandable structure. That structure matters most when you need to modify the system, because every change brings risk.

The two risks of making changes

Every modification, he says, has two categories of risk. First, you might introduce a problem: a bug, a delay, a user-facing failure, or even a budget overrun. Second, you might make future changes harder, which increases future risk.

He ties both of these risks back to understanding. If a system is hard to understand, it is harder to change safely. He says this is why postmortems often boil down to some version of “the system was too hard to understand,” and why complexity tends to compound over time rather than grow linearly.

Durable software and disposable software

Kanat-Alexander then shifts to a new idea: the rise of disposable software. Durable software is the traditional kind—software that lives for years, supports many users or systems, and has serious consequences if it fails. Disposable software, by contrast, has low consequences, few dependencies, cheap replacement, and little or no maintenance burden.

In that world, he says, code quality does not matter much, because the usual reasons for care—long-term risk and compounding complexity—are absent. He gives examples like a calculator replacement or a one-off party planner. If it fails, you throw it away and build another one.

Matching rigor to disposability

The speaker’s central claim is that engineering rigor should match the degree of disposability. On one end of the spectrum, if consequences, dependencies, replacement cost, and maintenance cost are all low, the software is disposable and code quality concerns largely disappear. On the other end, if those costs are high, rigorous engineering practices matter a great deal.

He emphasizes that durable software is not going away. In fact, he expects the amount of durable software to grow, partly because AI coding tools make it easier to build more of it. But he also argues that the number of disposable systems will grow rapidly, and that we should learn to design for disposability as its own discipline.

Making software easier to throw away

Kanat-Alexander then describes ways to increase disposability. One is isolated environments, where software only has access to limited data and cannot touch broader production systems. Another is enforced independence, so the software cannot rely on other production services. He also mentions redundancy: having a clunky but reliable fallback system so people can experiment with throwaway versions without worrying if they fail.

The broader idea is to limit scope. If a tool only needs to serve one person or one event, it can be built and discarded. He suggests that future engineering work may focus not only on making systems more rigorous, but also on helping teams safely treat some software as temporary.

Reducing the cost of rigor

He then turns to a second axis: even when software needs rigor, we should make that rigor cheaper. The goal is not just to decide whether a system is durable, but to reduce the cost of treating it as durable when needed.

That means making it easier to change your mind. If a tool seems disposable at first and later needs to become durable, you want the transition to be cheap. The cheaper rigor is, the less dangerous it is to be wrong about the software’s future.

Standardization, tooling, and strictness

Kanat-Alexander gives several examples of practices that lower the cost of rigor. Standardization reduces the space of possibilities: if a system uses one language or one framework, there are fewer edge cases, security holes, and toolchains to manage. The same logic applies to frameworks and protocols such as RPC, which is remote procedure call communication between systems.

He also talks about “inward flow tooling,” meaning tools that run automatically without programmers needing to decide to use them. The ideal tooling is fast, reliable, and low-noise, so it feels almost free. He extends this to testing: the goal is not just better tests, but a system where fast, deterministic testing is easy for everyone. He notes that modern coding agents can now generate in-memory fake services, which used to be a dream for test owners.

Finally, he argues for maximum strictness in linting and similar checks. If rules are turned on early and consistently, the team avoids massive cleanup work later. A strict linter may occasionally be wrong, but if false positives are rare and the consequences are not catastrophic, the long-term savings are worth it.

The conclusion: yes, no, and not expensive

He closes by answering the original question more directly. Does code quality matter? For disposable software, no. For durable software, yes. And does it have to be expensive? Also no.

That, he says, is the more useful answer than “it depends.”

Fact-check

• PLAUSIBLE — The core framing that software success depends on understanding the system and being able to safely modify it is a reasonable engineering perspective, though it’s more a conceptual model than a strictly checkable fact.
• PLAUSIBLE — Saying debuggers, observability, tests, and evals help improve understanding or execution is broadly consistent with common software-engineering practice, but the “exclusively and only” wording is an overstatement.
• PLAUSIBLE — The claim that large systems have behaviors too complex to fully describe in ordinary language is generally true in practice, especially for very large codebases, though it’s not a precise measurable fact.
• TRUE — Code structure and readability do matter for maintainability and future modification; that’s a well-established principle in software engineering.
• PLAUSIBLE — The claim that modifications create both immediate change risk and future maintainability risk is standard software-engineering reasoning, though the exact “compounding non-linearly” framing is more rhetorical than a proven law.
• PLAUSIBLE — The idea that some systems become so complex that nearly every change is risky is consistent with real-world experience, but the claim is generalized and not universally true.
• PLAUSIBLE — The prediction that AI tools will increase the amount of “disposable software” is speculative but reasonable; it’s a forecast, not a verified fact.
• PLAUSIBLE — Defining “disposable software” as low-consequence, easily replaceable, low-maintenance software is internally consistent and useful as a framework, but it’s a conceptual categorization rather than an established technical standard.
• TRUE — For software with low consequences, low dependencies, and low maintenance needs, investing heavily in code quality can have little benefit relative to the cost.
• PLAUSIBLE — The four-factor spectrum of consequences, replacement cost, dependencies, and maintenance cost is a sensible heuristic, but not a validated universal metric.
• PLAUSIBLE — Standardization, restricted environments, redundancy, and scope limitation can reduce the cost of engineering rigor; this aligns with common engineering practice.
• PLAUSIBLE — The claim that AI coding tools make it easier to create more durable software may be true in some contexts, but it’s speculative and not something I can verify here.
• PLAUSIBLE — Saying disposable and durable software form a spectrum rather than a binary is a reasonable conceptual claim.
• PLAUSIBLE — The idea that lowering the cost of rigor makes it easier to pivot when a system turns out to need durability is sensible, but again is more strategic reasoning than a fact claim.
• TRUE — Standardization generally reduces decision load and the variety of edge cases engineers must handle.
• TRUE — Strong inward-flow tooling, fast deterministic tests, and reliable linting can reduce ongoing engineering effort and prevent future issues.
• PLAUSIBLE — The suggestion that coding agents can help generate in-memory fakes or other test scaffolding is plausible, but its effectiveness depends on the tool and workflow and remains unverified in this talk.
• MISLEADING — “For disposable software, no [code quality matters]” is too absolute; even short-lived software can benefit from basic correctness, safety, and clarity, especially if failure has costs.
• MISLEADING — “For durable software, yes [code quality matters]” is broadly right, but framed too simply: not all quality practices are equally valuable, and some can be overused or misapplied.
• PLAUSIBLE — The closing claim that code quality need not be expensive is directionally true when tooling, standards, and automation are well designed, but the exact savings are context-dependent and unverified here.

Verdict: The talk is broadly credible as a software-engineering argument and contains many plausible, internally consistent claims, but several conclusions are rhetorical or overstated, and the speaker’s forecasts about AI-driven disposable software and self-reported practical outcomes remain unverified.