Sarah Chieng of Cerebras discusses adapting developer workflows to extremely fast AI code generation. Codex Spark, built with OpenAI, generates code at ~1,200 tokens per second versus 40–60 for Sonnet/Opus models; at that speed a context window fills in ~30 seconds instead of ten minutes, making habits built around slow generation a source of technical debt. Her playbook includes continuous validation and linting, orchestrating sub-agents to generate many output variations and cherry-pick the best, real-time collaboration mental models, active steering to avoid low-quality ("slob") output, continuous refactoring, and a four-file external memory system (agents, plan, progress, verify) for context management across sessions. Timestamps cover model speed history, hardware/stack optimization behind faster inference, and each playbook item. # Channel Identity Observations — "Fast Models Need Slow Developers — Sarah Chieng, Cerebras" ## Explicit Self-Description - **Speaker role and affiliation (stated directly):** > "My name is Sara Cheng. I'm the head of developer experience at Cerebras, where we are building the world's largest and fastest AI processor." - Repeated at the close: "My name is Sarah Cheng. I'm visiting from SF." - **Claimed job function:** > "A large part of my job is that I get to introduce fast inference and fast coding models to developers for the very first time." - **Product claims (creator/organization claims, not independently verified here):** - "we at Cerebras and OpenAI released a new model, state-of-the-art model, called Codex Spark" at **1,200 tokens per second**, versus "40 to 60 tokens per second" for Sonnet/Opus families. - "the Cerebras wafer where all of the memory is distributed across the chip in SRAM." - "Cerebras and AWS are now partnering to serve the wafer and AWS premium together." - **Personal contact offered publicly:** > "if you have any questions or need any credits, my handle is milksandmatcha across every platform." ## Intended Audience - **Software developers using AI coding assistants**, evidenced by: - Opening frame: "we as developers have developed a series of bad habits when it comes to developing as a result of slow AI code generation." - Practical tips referencing **Claude Code / Codex workflows**, agent swarms, "skills," pre-commit hooks, linting. - **In-person developer conference audience**, likely in **London**: > "It's an honor to be here in London." Also references "Modal who's also here" and talks "over the past few days," implying a multi-day developer event. - Audience presumed familiar with current tooling — no explanation given for terms like **KV cache**, **mixture of experts**, **compaction**, or **prefill/decode**. ## Claimed Scope of the Talk - **A "practical playbook" for developer workflows under fast inference:** > "this talk really is a practical playbook for how we as developers can think about how we interact with the models in this new regime." - Topics covered: the AI inference stack (hardware, model architecture, inference optimizations), model orchestration, validation-at-speed, cherry-picking outputs, pair-programming mental model, avoiding "slop," refactoring, context management (agents.md / plan.md / progress.md / verify.md four-file system), and Codex commands. ## Demonstrated Presentation Patterns (Observable) - **Educational conference-talk format** with slides, graphs ("we even had to change the Y axis"), diagrams of the inference stack, and a closing slide of commands. - **Promotional dimension:** the talk centers on a product the speaker's company built (Codex Spark), benchmarks it against competitors (Sonnet, Opus, Gemini, GPT), and closes by offering credits. - **Balanced/critical framing** despite promotion: warns against agent swarms — "we're generating massive amounts of code that nobody is verifying" and "generating technical debt at a level that we've never seen before." - **Opinionated developer-culture voice**: casual, meme-aware references ("you spawn a session, you go get a hamburger, you scroll Twitter," "cogitating, gesticulating, terminating," "everyone's trigger word... slop"). - **Trend commentary**: describes industry events ("This is why Nvidia bought Groq for $20 a few months ago") and names ecosystem companies (Together, Base10, Modal, Fireworks, Groq). ## Claims vs. Demonstration — Notes for Synthesis - **Creator claims:** speed figures (1,200 t/s), "state-of-the-art" status, "world's largest and fastest AI processor," partnership claims — all presented from Cerebras's position without external verification in the material. - **Demonstrated:** deep technical fluency across the full inference stack; developer-advocacy role; speaker identity as a Cerebras employee presenting externally at a third-party conference (channel context unknown from this source alone — the video shows a guest talk, not necessarily channel-owned content). # Delivery Observations — "Fast Models Need Slow Developers" (Sarah Chieng, Cerebras) ## Overall Tone & Register - **Conversational, casual conference-talk style** with frequent filler words and self-corrections: "And uh a lot of these bad habits," "And so, this is the topic of today's uh talk." - **Direct address to the audience** throughout: "we as developers," "many of you probably work on on a day-to-day," "I'm sure that so many of you guys have already heard these two words." - **Light humor and playfulness**, especially invented rhyming words: "your 10 agents all on the screen at the same time **combobulating, cogitating, thinking**" and "we're tired of the cogitating, gesticulating, terminating." ## Structural / Teaching Habits - **Signposting and roadmap language**: "So, to get started," "before we get into the actual playbook and tips, I want to talk about why this is happening," "And so, starting with the first one," "The next category I think is even more exciting," "The last category that I want to talk about." - **Categorical organization**: the talk moves through a stack (hardware → model architecture → inference optimizations → developer) and then a "practical playbook" of numbered categories (model orchestration, verification, refactoring, context management). - **Concrete numeric anchors repeated for effect**: "1,200 tokens per second" appears many times, contrasted against "40 to 60 tokens per second" and "50 to 150 tokens per second" for slower models. - **Concrete examples per tip**: e.g., the navbar example — "I want it to be midnight blue, I want four different icons… generate 15 versions… now I have 75 versions, and I pick the one that's best." - **Named tooling/filesystem example**: the "four-file system" — agents.md, plan.md, progress.md, verify.md — each explained briefly with its function. ## Recurring Phrases & Vocabulary - **"Bad habits" / "bad code"** as a recurring framing: "a series of bad habits," "50 tokens per second of bad code… 1,200 tokens per second of bad code," "the only way that you are going to avoid having bad code." - **"Mental model"** used repeatedly: "A good mental model is to use a larger model," "a helpful mental model as an example," "a good mental model for how full your context is." - **"Real-time collaboration" / "pair programmer"**: "it's a real-time collaboration that you're able to have with this model. You should view it much more as a pair programmer." - **"Basically free"** framing for cheap validation: "a model like Codex Spark makes validation basically free. There is no excuse and no reason why you should not be doing things like this." - Repeated intensifiers: "very exciting," "even more exciting," "most exciting part." ## Self-Aware Asides - Acknowledges audience fatigue with buzzwords: "I hate this slide cuz it's everyone's trigger word and overused word, but how do we avoid slop?" - Humorous admission on an acronym: "An example is REAP, router weighted expert activation pruning. **I had to read that one.**" - Casual aside on cost: "Unless our company pays for whatever we want." ## Parallelism & Rhetorical Patterns - **Contrast structure** (before vs. after fast inference) appears repeatedly: "you spawn a session, you go get a hamburger, you scroll Twitter" vs. sitting down in real time; "doing it at the very end right before you're about to commit" vs. "bake this into your automatic workflow." - **Imperative advice list-structures** when giving tips: "Test suites, linting, pre-commit hooks, diff reviews, browser-based QA automations." - **Simple arithmetic made rhetorical**: "if you take 10 minutes divided by 20, you are now getting compaction in 30 seconds." ## Delivery Uncertainty Notes - Speaker's name is rendered inconsistently in the transcript ("Sara Cheng," "Sarah Cheng," title says "Sarah Chieng"); the title is likely authoritative but the transcript itself is inconsistent — uncertain which spelling is correct. - No visual delivery cues (pace, pauses, gestures) are observable from transcript alone; tone judgments rest solely on text. # Fast Models Need Slow Developers — Sarah Chieng, Cerebras ## Speaker - **Sarah Chieng** (transcript also rendered "Sara/Sarah Cheng"), Head of Developer Experience at Cerebras. Note: transcript contains inconsistent spellings of her surname ("Chieng" in title, "Cheng" spoken twice); handle: **milksandmatcha**. ## Core Thesis - Developers have developed **bad habits** from slow AI code generation: massive one-shot prompts, huge commits, running many parallel agents. - Cerebras and OpenAI released **Codex Spark** (~1 month before talk), generating code at **1,200 tokens/sec** vs. ~40–60 tokens/sec for Sonnet/Opus families — roughly **20x faster**. - Warning: bad habits that generated "50 tokens per second of bad code" will now generate **1,200 tokens/sec of bad code** unless developers change workflows. ## Why Models Are Faster Now (Claimed) Sarah attributes speed gains to the **entire AI inference stack being optimized simultaneously**: ### Hardware - **Memory wall**: memory movement takes 50–80% of inference latency. - Nvidia GPUs store weights/KV cache in **off-chip HBM** → memory bandwidth bottleneck. - Companies like **Cerebras and Groq** move memory on-chip; Cerebras wafer distributes memory across the chip in **SRAM**, giving every core direct access. - **Disaggregated inference** (commercialized in recent months, per her): splitting **prefill** (parallel, compute-bound) onto compute-optimized hardware and **decode** (sequential, memory-bound) onto memory-optimized hardware. - She claims "Nvidia bought Groq for $20 [unclear unit — likely 'billion', but as stated] a few months ago" and that Cerebras and AWS are partnering to serve "the wafer and AWS premium together." *(Both claims delivered as stated; the "$20" figure is garbled in transcript.)* ### Model Architecture - **Mixture of experts**: activating a subset of experts per token — "intelligence of a much larger model for the compute cost of a much smaller model." - **REAP** (router weighted expert activation pruning): pruning never-activated experts. ### Inference Optimizations - Companies cited: **Together, Base10 (Base 10), Modal, Fireworks**. - Key technique: **KV cache reuse** — storing/reusing computed token representations to avoid recalculating attention. ## The Problem State - Current internet culture (Twitter/LinkedIn) celebrates extreme setups: six Claude Code terminals, 500+ agent swarms, eight agents across five screens. - Her assessment: "massive amounts of code that nobody is verifying" — fast inference makes this dangerous, generating **technical debt at a level we've never seen before**. ## Practical Playbook ### 1. Model orchestration - Don't only weigh intelligence and cost — add **speed** as a vertical. - Mental model: large model (e.g., **GPT 5.4/5.3**) for planning/long-horizon work; fast model (**Codex Spark**) as executor. - **Skills from sessions**: capture successful trajectories with a large model as repeatable skills, then let a fast agent run them repeatedly. ### 2. Newly practical capabilities - **Validation becomes "basically free"** at 1,200 tokens/sec: test suites, linting, pre-commit hooks, diff reviews, browser-based QA — at every step, not just before pushing. - **Cherry picking**: generate 15 versions in the time one took before; 5 sub-agents × 15 = 75 versions, pick the best. Good for research directions, architecture choices, graphic design. - Her reasoning: this "artificially induces **taste**" into output — models lack taste, and previous workarounds (writing examples, over-specified prompts) are time-consuming. ### 3. Real-time collaboration mindset - Stop spawning sessions and leaving; treat the model as a **pair programmer**. - "The AI should always be helping you make decisions, not the other way around." ### 4. Avoiding slop - Work with 2–3 sessions instead of 10; steer actively. - Specific constraints: ban file deletion, set **max diff size**, read/write only, targeted steering ("only change this," "don't touch types yet"). ### 5. Continuous refactoring - Automatic cleanup is "basically free" — bake refactoring into the workflow after each task (delete unused imports, normalize function structure) instead of doing it at the end. ### 6. Context management - At 20x speed, context that took 10 minutes to fill now **compacts in ~30 seconds** — sloppy context practices are no longer viable. - Break large tasks into **small bounded goals**; avoid the 80–100% context range where compaction loses information. - **Four-file external memory system**: - `agents.md` — define agents/subagents - `plan.md` — full plan and step-by-step checklist created at start - `progress.md` — tracking done/remaining so each new session knows where to resume - `verify.md` — per-step verification that code is clean before proceeding ## Closing Position - The point is not just faster models but a **better developer experience** — avoiding bad code "in a way that isn't miserable or us staring at a screen for 30 minutes." ## Qualifications & Notes - Speaker repeatedly frames claims as her views/mental models ("a good mental model is…"). - Historical claim: coding speeds stayed roughly constant (50–150 tokens/sec) across popular families (Gemini, Claude, GPT, Sonnet) for the past 2 years, while intelligence and context grew. - Codex Spark is positioned as **"the first of many"** faster models — a prediction, not an established fact. - Transcript contains garbled/unclear moments (the Nvidia/Groq "$20" figure; "GPT 5.4 or 5.3" phrasing) preserved as spoken. # Video Attribution & Provenance Record ## Video - **Title:** Fast Models Need Slow Developers — Sarah Chieng, Cerebras - **ID:** 01a15ca9-42f2-7873-8c65-390f959861b8 ## Speakers & Roles | Speaker | Role | Evidence | |---|---|---| | Sara/Sarah Cheng (self-introduced; title spells "Chieng," spoken as "Cheng") | **Creator / sole presenter** | "my name is Sara Cheng. I'm the head of developer experience at Cerebras" (opening and closing) | No guests, narrators, or other speakers appear. Event appears to be a conference talk in **London** ("It's an honor to be here in London"), speaker visiting from SF. ## Promotional Segments (Flagged) - **Product promotion — Codex Spark:** presented as a Cerebras/OpenAI release, "1,200 tokens per second," "state-of-the-art," described repeatedly as making validation "basically free." Much of the talk promotes Codex Spark workflows. - **Company promotion — Cerebras:** "building the world's largest and fastest AI processor"; Cerebras wafer/SRAM description; Cerebras–AWS partnership mention. - **Promotional close:** "if you have any questions or need any credits, my handle is milksandmatcha" — credits offer and contact push. ## Referenced Sources & Third-Party Claims - **Nvidia/Groq claim:** "This is why Nvidia bought Groq for $20 a few months ago" — third-party acquisition claim (unverified; "$20" likely misspoken). - **Model families cited:** Sonnet/Opus ("40 to 60 tokens per second"), Gemini, Claude, GPT ("50 to 150 tokens per second" over two years). - **GPT 5.3 / 5.4** — referenced as planning-model examples. - **Companies named:** Together, Base 10, Modal, Fireworks (inference optimization layer); Groq, AWS, OpenAI. - **Technique cited:** "REAP, router weighted expert activation pruning." - **Social-media anecdotes:** screenshots of "six cloud code terminals," "500-plus agent coding swarm," "eight agents across five screens" attributed to "Twitter/LinkedIn" — unverified third-party examples. - **Framework described:** four-file external memory system (agents.md, plan.md, progress.md, verify.md). ## Availability & Uncertainty - **No curated metadata supplied**; provenance relies on transcript only. - Speaker name spelling is **uncertain**: title says "Chieng," transcript spells "Cheng" — recorded as-is without resolution. - Timestamps: not present in source; none recorded. - Comments: availability not indicated in source. Hi everyone. So, we'll just get right into it. So, over the past few years, we as developers have developed a series of bad habits when it comes to developing as a result of slow AI code generation. And so, we we're all familiar with it. We do things like write massive prompts and try to one-shot. We'll make huge commits, or we'll have our 10 agents all on the screen at the same time combobulating, cogitating, thinking. And so, about a month ago, we at Cerebras and OpenAI released a new model, state-of-the-art model, called Codex Spark. Codex Spark can generate code at 1,200 tokens per second. And to put that into perspective, if you look at the Sonnet family or the Opus family, those can generate code at about 40 to 60 tokens per second. So, in this new era, as we're starting to see much faster coding models, this is 20 times faster, not only does it unlock new capabilities and use cases, but it also requires us to rethink how we as developers interact with the coding model. And uh a lot of these bad habits that we had before that were generating maybe 50 tokens per second of bad code, unless we fix them, they're going to start generating 1,200 tokens per second of bad code. And so, that is the topic of today's uh talk. So, to get started, my name is Sara Cheng. I'm the head of developer experience at Cerebras, where we are building the world's largest and fastest AI processor. A large part of my job is that I get to introduce fast inference and fast coding models to developers for the very first time. And for most people, it's a very exciting moment. There's no thinking and waiting and starting up that you might be really annoyed about. But at the same time, as I said, unless we change our habits, we are not going to have good code in the future. And so this talk really is a practical playbook for how we as developers can think about how we interact with the models in this new regime, especially in a future where the models are generating code faster than we the human can keep up. So I want to look back at history a little bit. We've had a very exciting past 2 years. The models have gotten bigger, they're getting smarter, we have bigger context windows. But the thing that has remained relatively constant over the past 2 years is coding speeds, is model speed. So if we look at a lot of the popular families, we have Gemini, Claude, GPT, Sonnet. Over the past 2 years, they've always been within, you know, 50 to 150 tokens per second. And this is Codex Spark. Again, Codex Spark is just the first of many models that we as developers can expect to be much faster than what we're previously used to. And we even had to change the Y axis because it's so much faster. And so before we get into the actual playbook and tips, I want to talk about why this is happening. Why are we suddenly seeing such faster models? And it's actually a very exciting development. It's It's what many of you probably work on on a day-to-day, but it's There's so many companies that are working on this problem all at the same time. And as a result, the entire AI inference stack is getting optimized all at once. And so breaking it down, let's go through it really quickly. We have hardware. This is a physical device that inference, training, all of our computers happening on. One of the biggest things that we have to think about with hardware is the memory wall. And this is exactly why hardware and memory movement takes up 50 to 80% of that latency time for inference. This is where a lot of the frustration comes from. And so, when we are running inference, we have to constantly move our weights and KV cache values between memory and our actual chip. On the Nvidia GPU, this is the most traditional type of hardware. All of this memory is stored off-chip on off-chip HBM. And we're now have a memory bandwidth bottleneck. What a lot of newer companies are doing, are thinking about companies like Cerebras or Groq, they're thinking about how do we move this memory to be as close to the chip as possible. And so, here's an example of the Cerebras wafer where all of the chip is um all the memory is distributed across the chip in SRAM. So, every core has direct access to the values it needs. Even more exciting, we have disaggregated inference. And this is an um disaggregated inference really has become commercialized in the last few months. This is why Nvidia bought Groq for $20 a few months ago. And this is also why Cerebras and AWS are now partnering to serve the wafer and AWS premium together. So, in traditional inference, there's two steps. There's prefill and there's decode. Traditionally, both of these steps have always been run on the same piece of hardware. Prefill is where we're taking every token that the user inputs and processing it, embedding it, and adding it to our KV cache. This is a sequent This is a step that can happen in parallel, and so it's compute bound. Decode, on the other hand, is where we're actually generating the output token by token. And this is sequential and is, as we mentioned, memory bound. Again, it goes to the same problems that we mentioned before. And so, what we're doing and seeing now, commercially, is that we're splitting up these two steps so that prefill is done on one type of hardware that is compute optimized, and decode is done on another piece of hardware that is memory optimized. Going up the stack, there's the diagram. Going up the stack, we look at model architecture. There's so many ways that we are training our models and shaping our models to cater to our hardware. We have specific layer dimensions and memory and model size that we're always thinking about. A great example is a very standard model architecture mixture of experts. Here, instead of activating the entire model all at once for every single token, we're only activating a subset of experts for every time. And what this does is it allows us to have the intelligence of a much small larger model for the compute cost of a much smaller model. And again, we're always thinking about memory and the size of our models. And a lot of people have been building on top of this in recent years. An example is REAP, router weighted expert activation pruning. I had to read that one. Um and here we're looking at the specific use case. We're seeing which experts aren't being activated all at at all, and we're pruning them all together. We're getting rid of them. Again, we're always thinking about model size. And then at the very top layer of this stack, we have inference optimizations. And this is where many of you might be working in. And a lot of companies that you're probably familiar are also working at. These are companies like Together, Base 10, Modal who's also here, Fireworks. And one of the biggest things that we're thinking about at this level is KB cache reuse. And so by storing and reusing previously computed token representations, we don't have to recalculate attention over the sequence at every step. And now I want to get to the very top and most exciting part, the developer. This is the current state uh what the internet looks like or what Twitter LinkedIn looks like. We have someone running six cloud code terminals at once. A 500-plus agent coding swarm. Um someone running eight agents across five screens. And I get how tempting doing something like this can be. I feel like if you're on Twitter at all these days, unless you are doing something like that, the internet is basically convincing you that you are living in the Stone Age. And that you need to catch up. But the reality, what is the reality of what is happening in all these setups? Is that we're generating massive amounts of code that nobody is verifying? And in the new future with much faster inference, this becomes increasingly dangerous. And so, especially with fast inference, we're now going to be generating technical debt at a level that we've never seen before and we're not going to know what to do with it. And so, I'm going to pivot now to spend the rest of the talk on the practical playbook and tips and workflows and how we can reimagine how we as a developer should operate in this new regime of faster inference. And as I mentioned, Codex Spark operates at 1,200 tokens per second. But it really is just the first model in what we should as developers expect and prepare for to be a new regime of faster models across the board. And so, starting with the first one, the first category is just choosing the right models and how do we orchestrate our agents so that we're leveraging different model strengths? And historically, we always think about intelligence. There's no There's no secret that we as developers are not particularly loyal and that we will switch to whatever model, whatever family is the most intelligent at a given time. And maybe we also think about cost. Unless our company pays for whatever we want. And so, here now the inference speed is a 20x difference. Now we also have another vertical to think about, speed. And so, a good mental model is to use a larger model like GPT 5.4 or 5.3 for your planning or your long horizon workflows and then using a faster model like Codex Spark as your actual executor. And so, here's an example. You might ask your 5. GPT 5.4 to generate your plan. You would generate a You would spawn all of your sub agents with Codex Spark and have it actually have it actually execute on all of the steps one by one. Another really helpful trick is to actually make skills out of successful sessions and capture trajectories that are working really well. A thing that you can do here is use a model like GPT 5.4 to actually have it do the initial harder larger task, capture that as a skill, and therefore making it a verifiable repeatable workflow, and then having a small faster agent like Codex Spark just do it again and again in the background. The next category I think is even more exciting because this is a category of things that just were not possible and were not practical. These are things we wouldn't do because we're tired of the cogitating, gesticulating, terminating that you might have seen. And so here I really want us to think about this and internalize this. But at 1,200 tokens per second, a model like Codex Spark makes validation basically free. There is no excuse and no reason why you should not be doing things like this. Test suites, linting, pre-commit hooks, diff reviews, browser-based QA automations. There's all these things that you can add to every step of your workflow because it is instant. It's not slowing you down and it's not you do this all of this at the very end or right before you're about to push your code. Another tip that I really like is exploring cherry picking. So let's say that I wanted code a navbar and I want it to be midnight blue, I want four different icons. I give it to the model and and the result's fine. Instead, what I can do with Codex Spark or much faster model is I can have it tell it to generate 15 versions in the same time that it would have taken the a previous model generate one version, and I can cherry pick the version that I like the best. Even better, I can generate five sub agents that are each generating 15 versions, and now I have 75 versions, and I pick the one that's best. And this is great for things where we really value quantity or variety. So things like research direction, different types of architecture directions, or even just graphic design. And the reason why I really like this one is because it almost allows us to artificially induce taste into our model output. So, traditionally, with no secret, it's very easy to sniff out any UI or text that a model writes. The models themselves do not have taste. And the ways that we've kind of brute force worked around this is that we either create an example ourselves, we find examples for the model, which is time-consuming, or we give the prompt so much detail that we might as well have completed the task ourselves. This is a great way of saving our time and also getting much better results. The next tip is kind of more more so a a mental model. Well, now that the models are so fast, it should not be you spawn a session, you go get a hamburger, you scroll Twitter, and then you come back. Now, you can actually sit down, and it's a real-time collaboration that you're able to have with this model. You should view it much more as a pair programmer, and this is the only way that you are going to avoid having bad code. So, you can sit down and ask questions like have having it collect all the context across your repo, and actually asking it how does it work, being the one in the front seat making decisions and implementations. The AI should always be helping you make decisions, not the other way around. The next one, I hate this slide cuz it's everyone's trigger word and overused word, but how do we avoid slop? So, as I was mentioning before, it really shouldn't be, you know, you spawn 10 agents, you never verify the code, you don't know what's happening under the scene. Someone asks you to explain, you have to read the code for the first time. Now, you can actually have two to three sessions and actually sit down next to your code, and I know this is something we're not really used to, but sit down with it and actually steer it. Understand what's happening, because again, we now are now experiencing real-time collaboration as we code with this agent. You can be super specific. You can think do things like ban the model from deleting files, give it a max diff size. The model have the model only read and write, and even give it steering directions. Things like only change this. Don't touch types yet. Wait, that implementation wasn't quite right. Let's redo that. The graph on the left is a is a helpful mental model as an example of how the developer, the AI agent, and the code base can all work together and what that should look like. This next step refactoring is very similar to what I was talking about with the valid with verification. Just like with verification, something like constantly refactoring and cleaning up your code automatically is basically free at 1,200 tokens per second. So, you can do things instead of doing it at the very end right before you're about to commit your code, you can just re you can just bake this into your automatic workflow so that after every single task on that checklist is complete, you're just asking the model to automatically, you know, delete unused imports, clean up unnecessary lines of code, make it so that all of my functions are structured the same way. The last category that I want to talk about, and I'm sure that so many of you guys have already heard these two words accountless amount of time over the past few days and across so many talks, is context management. But the reason I'm going to talk to you about it again is because let's say that historically it took you 10 minutes to fill up your context before you saw, you know, the god-feared word compaction. Now, if you take 10 minutes divided by 20, you are now getting compaction in 30 seconds. And so, context managing, especially with fast inference, is more important to think about than ever, and you can't get away with sloppy practices anymore. And so, all of these these really are just good practices no matter what coding model you are using or what speeds, but a general a very high-level framework is just always always break up large tasks into smaller bounded goals. And this graph on the right is a good mental model for how how full your context is will then affect your behavior. The model behavior. So, you always want to avoid the 80 to 100% because you're going to get compaction right now. We all know uh some things might get lost. And so, a good way that you can think about how do I externalize this memory so that I can have these small bounded goals. Like, what does that look like? So, an example of how you can do this and set up an external memory system that is persistent every time you set up a new session is with this four-file system. We have agents.md, which is where we're actually defining all our agents, our subagents. We have plan.md, which is what we're creating at the very beginning, and this is where we're just generating the entire plan and step-by-step step-by-step checklist that we're going to go through. We have progress.md, which is where we're keeping track of what's do we need to do and what has been done before. So, every time you spawn a new agent or session, has no context. It comes in, it looks at progress.md. It sees what's been done before and it's like, "Okay, here's where I pick up. Here's where the next task needs to be done." And then the last is verify.md, and this is what we're using at every single step to just make sure everything looks good. It's clean code, and we can move on to the next step. And so, an example of this is again, leveraging different models. Using a GPT 5.3 or 5.4 Codex, having it create your plan, and then having your GPT 5.3 Codex spark actually execute the checklist one by one much faster than before. And as a final slide, I want to do these um a few helpful commands for how you can get the best out of Codex. Things like permissions, experimental skills, review, and rename. But, the biggest thing that I really want to emphasize here is that honestly, it's not really about just having faster coding models. What I really means is that the developer experience is actually going to become so much better. And when it's becoming so much better, there's so much more we can do. And there's so many ways that we can now avoid creating bad bad code in a way that isn't miserable or us staring at a screen for 30 minutes. So, thank you guys so much for welcoming today me today. My name is Sarah Cheng. I'm visiting from SF. It's an honor to be here in London. Um, if you have any questions or need any credits, my handle is milksandmatcha across every platform. Thank you guys.