Latest / Braid / Deployment, Discovery, and the Code You Keep

Transcript

Deployment, Discovery, and the Code You Keep · Braid

• 0:04
  Before we get into Braid, quick note on IMPULSE, our other daily show.
• 0:08
  It tracks how AI is changing markets and institutions, along with labor, science, medicine, geopolitics, robotics, media, education, and the open-versus-closed model fight.
• 0:20
  If Braid is the builder’s table, IMPULSE is the wider room around it.
• 0:25
  You can find it at the IMPULSE page on braid.opentangle.com, linked in the show notes.
• 0:31
  Okay.
• 0:31
  OpenAI announced the OpenAI Deployment Company today, and the announcement isn't subtle about what OpenAI thinks the next enterprise bottleneck is.
• 0:41
  The company says it's launching a majority-owned, OpenAI-controlled business that exists to help organizations build and deploy AI systems across their important work.
• 0:53
  It has agreed to acquire Tomoro, an applied AI consulting and engineering firm, which gives the new company about 150 forward deployed engineers and deployment specialists on day one.
• 1:05
  It also has nineteen partners around it: investment firms, consultancies, and systems integrators.
• 1:12
  TPG is leading the partnership.
• 1:14
  Advent, Bain Capital, and Brookfield are co-lead founding partners, and OpenAI says the company will launch with more than four billion dollars of initial investment.
• 1:25
  That is the factual part.
• 1:27
  OpenAI isn't just saying, here are better models, good luck wiring them into your procurement system and your field operation and your audit process.
• 1:37
  It's saying, we are going to own a company whose job is to put engineers inside those organizations and help change the work.
• 1:46
  The official copy says these engineers will connect OpenAI models to customer data, tools, controls, and the business processes people use every day.
• 1:56
  It also says they will work with business leaders, operators, and frontline teams.
• 2:01
  The goal is to identify where AI can make the biggest impact, redesign critical workflows around it, and turn those gains into durable systems.
• 2:11
  I think OpenAI is doing two things at once here.
• 2:14
  First, it's trying to capture more of the enterprise value chain.
• 2:19
  That part is plain.
• 2:20
  If the model is only a component, then a lot of the money and a lot of the customer learning goes to the people who turn the component into something a business can use every day.
• 2:32
  Second, OpenAI is admitting, in public, that deployment isn't a thin wrapper around a chat box.
• 2:39
  The expensive work is getting the model close enough to the actual business to help, while keeping it away from the places where a bad answer can hurt people or break a process.
• 2:51
  There is a Palantir flavor here, because forward deployed engineering is a very particular style of business.
• 2:58
  You send technical people into messy organizations.
• 3:02
  They learn the local nouns.
• 3:04
  They build against real data and old processes.
• 3:07
  They turn demos into operating systems for a team.
• 3:10
  That can be extremely powerful, and it can also make the vendor very sticky.
• 3:16
  If your AI workflows are designed by a company majority-owned by OpenAI, and those workflows are built to improve as OpenAI’s models and tools come online, you aren't buying a neutral adapter layer.
• 3:29
  You are buying into a path.
• 3:31
  I don't mean that as a dunk.
• 3:33
  For a lot of companies, that may be exactly what they want.
• 3:37
  Most enterprise AI projects aren't blocked because nobody can write the prompt.
• 3:42
  They are blocked because the data is weird and the permissions are weird.
• 3:47
  People don't trust the outputs yet, the legal team wants a record, and the team that owns the process often isn't the team that owns the model budget.
• 3:57
  A forward deployed engineer can help because the job is mostly translation between a capable system and a human organization that has twenty years of scar tissue.
• 4:08
  The builder angle is simpler: model capability isn't the product by itself.
• 4:14
  The product includes the model.
• 4:16
  It also includes the deployment path, evals, permissions, user experience, and the maintenance story after everyone stops calling it a pilot.
• 4:25
  OpenAI’s announcement is a corporate move, sure.
• 4:29
  Underneath that, it's also a technical claim: the frontier labs think the next serious contest is who can make intelligence usable inside ordinary work without losing control of the details.
• 4:41
  Daniel Stenberg, the lead developer of curl, published a useful post today about running Anthropic’s Mythos model against curl.
• 4:50
  The title is almost the whole attitude: Mythos finds a curl vulnerability.
• 4:56
  Singular.
• 4:57
  One.
• 4:58
  Back in April, Anthropic drew a lot of attention to Mythos and its security work.
• 5:04
  Daniel was offered access through the Linux Foundation and Alpha Omega path for open source projects.
• 5:11
  Access didn't arrive directly, so eventually someone who had access ran the scan for him and sent the report.
• 5:19
  That report analyzed curl’s git repository, specifically the source and library directories.
• 5:26
  The scan covered about 178 thousand lines of code.
• 5:30
  Daniel gives a lot of context here that matters.
• 5:33
  curl isn't a random weekend library.
• 5:36
  He says curl is about 176 thousand non-blank lines of C, 660 thousand words, installed in more than twenty billion instances, running on more than 110 operating systems and 28 CPU architectures.
• 5:50
  He also says the project had already been scanned by several AI-powered tools, including AISLE, Zeropath, and OpenAI’s Codex Security.
• 6:00
  Those tools had already triggered somewhere between two and three hundred bug fixes across the last eight to ten months.
• 6:09
  So Mythos wasn't walking into untouched ground.
• 6:13
  It was walking into a codebase that has years of fuzzing, conventional analyzers, careful compilers, human review, and AI review.
• 6:22
  A security team takes reports seriously too.
• 6:26
  The Mythos report claimed five confirmed security vulnerabilities.
• 6:31
  After Daniel and the curl security team worked through the list, five became one.
• 6:37
  Three were false positives around documented API behavior.
• 6:41
  One was just a bug.
• 6:42
  One was a confirmed vulnerability, planned as a low-severity CVE for curl 8.21.0 in late June.
• 6:49
  The report also had about twenty non-security bugs that were described well and are being investigated.
• 6:57
  That is a much more interesting outcome than either side of the argument usually wants.
• 7:04
  If you want the most dramatic possible AI-security story, one low-severity CVE in curl after all that hype falls short.
• 7:12
  Daniel’s personal conclusion is that the hype around this model was mostly marketing, at least from this one repository.
• 7:21
  But if you want the anti-AI story, the post doesn't give you that either.
• 7:27
  Daniel says AI-powered analyzers are significantly better than old-style analyzers at finding security flaws and mistakes in code.
• 7:36
  He says modern AI models are good at this now, and projects that haven't scanned their source with AI-powered tooling will likely find a lot of flaws.
• 7:48
  He's using them as part of the work.
• 7:50
  The line I keep coming back to is very plain: AI reviews are used in addition to human reviews.
• 7:57
  They help; they don't replace the humans.
• 8:00
  Then Rival Security added a second piece of context on a different Mythos security claim, and this one is about provenance.
• 8:10
  Anthropic had discussed CVE-2026-4747, a FreeBSD network file system remote-code-execution issue, as part of the Mythos story.
• 8:19
  Rival went looking at the history and argued that the vulnerable FreeBSD function is closely related to old MIT Kerberos code that had a very similar bug, CVE-2007-3999, patched back in 2007.
• 8:33
  The comparison in their write-up is direct.
• 8:36
  A fixed stack buffer receives the RPC header fields, then a credential body gets copied without a bounds check.
• 8:45
  The new FreeBSD fix and the old Kerberos patch even rhyme structurally.
• 8:50
  Rival’s conclusion isn't that the finding is useless.
• 8:54
  Their point is that the discovery may be closer to combinatorial reuse of something represented in training data than to a wholly new bug class.
• 9:05
  I think that distinction matters, but not in the cheap way.
• 9:09
  If an AI system can rediscover a 2007 bug pattern in FreeBSD and then help exploit it, the provenance question doesn't make the operational problem disappear.
• 9:21
  Attackers don't need philosophical novelty.
• 9:24
  They need a path from code to exploit.
• 9:27
  Defenders need a path from old code to fix.
• 9:30
  The curl post and the Rival post together put the Mythos story at a reasonable altitude.
• 9:36
  We aren't looking at magic vulnerability omniscience.
• 9:40
  We're also not looking at a toy.
• 9:43
  These systems can scan huge amounts of code and explain candidates.
• 9:48
  They can find ordinary but dangerous patterns and produce reports maintainers can act on.
• 9:54
  They also overstate.
• 9:56
  They call things confirmed before the maintainers confirm them.
• 10:01
  They rediscover old shapes.
• 10:03
  They need human review, and in the best cases they make that review more productive.
• 10:09
  For builders, the practical answer is process, not fear.
• 10:13
  If you maintain a serious codebase, AI security review is becoming normal toolchain work.
• 10:20
  You still need fuzzing and tests.
• 10:22
  You still need static analysis, compiler warnings, and maintainers who know the code.
• 10:28
  But it's getting harder to justify never running an AI analyzer, because the people looking for bugs from the outside are absolutely going to run one.
• 10:39
  James Shore published an essay with a line that should be taped above every coding-agent adoption plan: your AI coding agent needs to reduce your maintenance costs.
• 10:50
  He isn't arguing that agents can't make you faster.
• 10:54
  He's arguing that speed by itself is the wrong number to optimize.
• 10:59
  Every month of code you add creates future work.
• 11:02
  Bugs need fixes, dependencies need upgrades, design mistakes need repair, and the software has to stay alive after the feature lands.
• 11:11
  His model is intentionally simple.
• 11:14
  Imagine a team spends a month writing code, and in the following year that month of code costs ten days of maintenance, then five days every year after that.
• 11:25
  The exact numbers matter less than the shape.
• 11:28
  As the codebase grows, more and more of the team’s time goes into keeping old work usable.
• 11:34
  In his example, after two and a half years, more than half the time is maintenance.
• 11:40
  After ten years, there's barely room for new work.
• 11:44
  Now put a coding agent into that model.
• 11:46
  If the agent doubles your output, but the code costs the same to maintain per unit, you have doubled the future maintenance work.
• 11:56
  If the code is harder to understand, or the team stops reading diffs carefully because there are too many of them, the bill gets worse.
• 12:05
  Shore’s cleanest claim is arithmetic: if you produce twice as much code, the code needs to cost half as much to maintain.
• 12:14
  If you produce three times as much, it needs to cost one third as much.
• 12:19
  Otherwise the speedup decays, and then it turns on you.
• 12:22
  That could sound abstract, except the k10s devlog gives the concrete version.
• 12:28
  The author built a GPU-aware Kubernetes terminal UI across seven months, 234 commits, and around 30 weekends, heavily using Claude.
• 12:37
  The project started with a clear niche: something like k9s for people running NVIDIA clusters, with GPU utilization and DCGM metrics in a purpose-built interface.
• 12:48
  It also tracked idle nodes, temperature, power draw, and memory.
• 12:53
  Early on, it felt amazing.
• 12:55
  It gained pod and node views, then deployments and services.
• 12:59
  It also gained a command palette, live updates, and Vim keybindings.
• 13:04
  Then the fleet view arrived, and it looked good.
• 13:07
  After that, switching back to pods broke.
• 13:10
  Live updates stopped.
• 13:11
  Tables showed stale data.
• 13:13
  Tab counts went wrong.
• 13:15
  The author finally read the code.
• 13:17
  The central model file was 1,690 lines.
• 13:20
  One state object held third-party UI widgets and the Kubernetes client.
• 13:25
  It also held current resources and watchers.
• 13:28
  Logs, describe views, navigation history, mouse handling, fleet state, cached rows, raw objects, layout details, and a lot more lived there too.
• 13:38
  The update function was about 500 lines with more than a hundred switch branches.
• 13:44
  The fleet view had been special-cased inside the generic resource-loading path.
• 13:49
  View-specific state was being cleared by manual nil assignments scattered through the file.
• 13:56
  Key handling depended on the current resource string.
• 13:59
  The same key meant autoscroll in one view and shell into a pod in another.
• 14:05
  Structured Kubernetes data was flattened into positional string arrays, so the meaning of column three depended on remembering the column order somewhere else.
• 14:16
  One async handler even mutated render-visible state from a background command.
• 14:21
  The writer’s short version is sharp: AI writes features, not architecture.
• 14:27
  I would soften that slightly.
• 14:29
  A good model can implement architecture if the architecture exists and is enforced.
• 14:34
  It can follow ownership rules, respect typed messages, and split view state if the project already has that pattern.
• 14:43
  But left to the shortest path, it will often satisfy the prompt in the nearest place.
• 14:49
  The code gains another branch, another field, another string comparison, and another parameter.
• 14:55
  The code compiles, the feature works, and the cost moves into the next change.
• 15:01
  Shore’s maintenance math gives me a better test.
• 15:04
  The first week probably got faster.
• 15:07
  Seven months later, is the system cheaper to change than it would have been without the agent?
• 15:13
  In k10s, the answer was no, and the author archived the Go version and started rewriting in Rust, with the human doing the architecture first.
• 15:23
  The small companion piece today was AllThingsSmitty writing about positional booleans, the classic true, false, true problem.
• 15:32
  A call that passes a user, then true, then false technically works.
• 15:37
  TypeScript can tell you the values are booleans.
• 15:40
  It can't tell the reader whether true means admin, whether email should be sent, whether validation should be skipped, or whether something else is going on without a jump to the function definition.
• 15:54
  The author puts it simply: he isn't reading code anymore; he's decoding it.
• 15:59
  That is the same maintenance story at the scale of one call site.
• 16:04
  Options objects aren't a grand architecture.
• 16:07
  Separate functions for separate actions won't win a design award.
• 16:12
  They are the little choices that decide whether future-you can move quickly without a model re-reading the whole codebase on your behalf.
• 16:21
  The speedup only counts if the system you inherit is cheaper to understand, cheaper to test, and cheaper to change.
• 16:29
  The next cluster of items is about what happens when the agent isn't just writing a file and exiting.
• 16:37
  Eric Allam from Trigger.dev gave a talk called Two Roads to Durable Agents: Replay vs.
• 16:43
  Snapshot, and it starts from a backend history most web engineers know in their bones.
• 16:49
  For decades, the dominant shape was stateless compute.
• 16:53
  A request arrives, code runs, state lives in the database, and the process doesn't need to remember much.
• 17:00
  Then durable workflow engines arrived for multi-step side effects.
• 17:05
  Charge the card, send the receipt, resize the image.
• 17:09
  If something fails halfway through, you don't want to charge the card twice, so every step gets recorded and replay can skip the completed work.
• 17:19
  That replay model works well for workflows.
• 17:22
  Allam’s point is that agents don't fit it cleanly forever.
• 17:27
  Once the large language model is orchestrating tools, every model call becomes part of a growing journal.
• 17:34
  Tool calls, tool results, and assistant responses pile into it too.
• 17:39
  A single turn is fine.
• 17:41
  Many turns start to stretch the log.
• 17:43
  A session that lasts hours, or eventually days, is different from a transaction.
• 17:49
  His line is that an agent isn't a transaction; it's a session.
• 17:53
  It lasts as long as the user wants it to last.
• 17:57
  The useful split in the talk is context state versus execution state.
• 18:02
  Context is the append-only record of what the model saw and said: system messages, user messages, tool calls, tool results, and assistant responses.
• 18:12
  That can live in a database or object storage.
• 18:16
  Another durable store works too.
• 18:18
  Execution state is the machine the agent is using.
• 18:22
  It may have cloned a repo and installed packages.
• 18:25
  It may have started a dev server, opened files, created subprocesses, and built up local state that can't be reconstructed just by reading a chat log.
• 18:36
  For that half, Allam argues for snapshot and restore.
• 18:40
  Save the machine, shut it down, and restore it when the next user turn arrives or when a retry window opens.
• 18:47
  The numbers in the talk are useful because they pull this out of vague architecture talk.
• 18:54
  Trigger.dev previously used process checkpointing, then moved toward Firecracker micro VM snapshots.
• 19:01
  A naive snapshot of a 512 megabyte machine is 512 megabytes on disk.
• 19:06
  They compress and layer the snapshot, and he says they can get it down to around 14 megabytes compressed, with snapshots under a second and restores in the hundreds of milliseconds.
• 19:19
  He also says they are doing around 15 thousand VM starts per minute in a benchmark.
• 19:25
  I wouldn't build a roadmap off conference-demo numbers alone, but the design direction is clear: long-running agents are pushing backend teams toward recoverable machines, not only recoverable logs.
• 19:39
  Sally-Ann Delucia from Arize hit the same class of problem from the context side.
• 19:45
  Their agent, Alex, analyzes trace data from AI applications.
• 19:49
  That means it's often analyzing the very kind of material that makes context grow: prompts and metadata.
• 19:57
  It also sees spans, conversation history, tool calls, and model outputs.
• 20:02
  They got stuck in a loop where Alex would run on trace and span data.
• 20:07
  The spans would grow, the context limit would hit, the agent would fail, and the failed attempt would add even more data.
• 20:16
  They tried the obvious moves.
• 20:18
  Naive truncation, taking the beginning and dropping the rest, made follow-up questions feel like new conversations.
• 20:26
  Summarization sounded sensible but was too inconsistent, because the model couldn't reliably decide which details to preserve for later reasoning.
• 20:37
  Their working approach is more specific.
• 20:40
  They keep the head and tail, store the middle, keep the latest tool results, avoid resetting the system prompt, and let the agent retrieve stored context when it needs it.
• 20:52
  Delucia phrases it nicely: context decides what the model sees, memory decides what survives.
• 20:59
  They also added long-session evals.
• 21:01
  Load ten turns, test the eleventh, and see whether the context strategy still works when the conversation has had time to decay.
• 21:10
  I like that because late-session breakage is the kind of bug you miss when you only test the happy first turn.
• 21:18
  A chat that feels smart for five minutes can become confused after twenty turns, and your users usually won't restart just because your context manager wants a clean slate.
• 21:31
  The Arize team also moved heavy work into sub-agents.
• 21:34
  Search over hundreds of spans doesn't need to live inside the main conversation.
• 21:40
  The main agent can keep the user thread lighter, delegate data-heavy work, and receive a result back.
• 21:48
  That isn't a magic pattern, but it's a practical one.
• 21:51
  If everything lives in one conversation, every task pays for every other task’s intermediate mess.
• 21:58
  Put Trigger.dev and Arize together and you get a clean builder lesson.
• 22:03
  Durable agents need two forms of memory.
• 22:06
  They need a durable account of what has been said and done, and they need a recoverable execution environment for the work that can't be reduced to text.
• 22:17
  Save only the chat, and you lose the machine.
• 22:21
  Save only the machine, and you lose the reason the model was doing the work in the first place.
• 22:27
  The engineering problem is keeping those two histories aligned without making every turn more expensive than the work it's trying to perform.
• 22:38
  Mehedi Hassan from Granola gave the product version of the same lesson in a talk called You can’t just one shot it.
• 22:46
  The setup is a meeting-notes product with chat.
• 22:49
  You can ask questions about a meeting, across meetings, and across shared context.
• 22:54
  That sounds like the kind of feature the model vendors make look easy: add the web search tool, call the model, ship the chat box.
• 23:03
  Hassan’s examples are the problems you hit immediately after that.
• 23:08
  Web search looks like one line of code, but complex queries can blow up context and token cost.
• 23:14
  He mentions each chat costing around ten pence in some cases, which doesn't sound like much until you have a large user base and people ask messy questions all day.
• 23:26
  Provider behavior can also change underneath you.
• 23:29
  He says they had been using a model for a while, then an overnight update degraded web search and the team had no direct control except switching providers.
• 23:40
  Output shape is another problem.
• 23:42
  A salesperson may want meeting notes organized around the deal.
• 23:46
  An engineer may want action items, blockers, and Linear tickets.
• 23:51
  HR may want something else entirely.
• 23:53
  A single generic prompt isn't going to serve all of those people equally well.
• 23:58
  So Granola started building its own tracing tools.
• 24:02
  Not as a purity exercise, but because the team needed to inspect tool calls and search behavior.
• 24:09
  They also needed reasoning, costs, and outputs in a shape that product, data, customer support, and engineering could all use.
• 24:17
  Hassan says their founder goes through the agent loop front to back to see what went wrong.
• 24:23
  That is a very different posture from treating the model as a sealed box and arguing with it through prompt adjectives.
• 24:32
  The other nice detail is their testing loop.
• 24:35
  Granola is an Electron app, which means local product testing has more friction than a normal web app.
• 24:42
  They split the render process so it can run as a web shell, then put preview links on pull requests.
• 24:49
  Now people can test variants without building the whole desktop app locally, and Cursor can test changes and upload screenshots into the pull request.
• 24:59
  Every desktop app doesn't need to copy that exact pattern.
• 25:03
  But AI makes variants cheaper, so teams need a faster way to feel and verify those variants.
• 25:09
  Otherwise you have cheap generation and expensive judgment.
• 25:13
  AllThingsSmitty’s true, false, true essay fits here too.
• 25:17
  It's a tiny post compared with the enterprise announcements and security claims, but the craft lesson matches them.
• 25:25
  You can create an API that is fast to write and slow to read.
• 25:29
  An AI feature can be fast to demo and slow to debug.
• 25:33
  An agent loop can work on turn one and forget the user’s intent on turn twenty.
• 25:38
  The small local cost is the same kind of cost as the big system cost.
• 25:43
  Someone has to interpret what happened.
• 25:46
  Someone has to know which value means admin, which tool call blew up the context, which provider update changed behavior, and which view owns the state.
• 25:56
  So I am getting more allergic to AI product demos that skip the inspection layer.
• 26:02
  Show me the trace and the eval that catches turn eleven.
• 26:05
  Show me the preview link, the user role that changes the output, and the place the team looks when the answer feels wrong.
• 26:14
  A model can give you a surprising amount, but if the product has no way to see itself, the team ends up debugging through vibes.
• 26:23
  Granola’s closing line says the answer isn’t to one-shot better.
• 26:27
  That sentence fits today.
• 26:29
  Better one-shotting is nice.
• 26:31
  I will take it.
• 26:32
  But the builder advantage is in the loop around the shot.
• 26:36
  That means the typed interface, the trace, the preview, and the long-session eval.
• 26:41
  It also means the handoff between context and execution, plus the human taste that decides when plausible code is becoming expensive code.
• 26:51
  The last item is a different kind of capability beat.
• 26:54
  Prince Canuma from Arcee gave an AI Engineer talk on MLX Genmedia, and the simplest description is: Apple Silicon keeps getting more interesting for local multimodal AI.
• 27:06
  MLX is an array framework for Apple Silicon.
• 27:09
  It gives builders a way to run model work close to the metal on Macs, iPhones, and iPads.
• 27:15
  Canuma says the ecosystem has more than 1.5 million downloads and over 4,000 ported models, with day-zero support for open models from major labs.
• 27:25
  The talk is personal at the start.
• 27:28
  He talks about wanting to help his father read and navigate after losing his sight, and then connects that to on-device vision and audio.
• 27:37
  The demos move quickly.
• 27:39
  Object detection runs in real time on a Mac.
• 27:42
  Background blur works locally.
• 27:44
  A local vision-language model can describe an image.
• 27:47
  The audio examples include text-to-speech, speech-to-speech, and a modular pipeline where you pick the speech recognizer, language model, and voice model.
• 27:58
  A small robotics setup uses local vision and audio too.
• 28:02
  There is also an on-device video generation example, where a user chained generations together to make a more coherent story on a MacBook with 16 gigabytes of video memory.
• 28:14
  A couple of caveats.
• 28:15
  Conference demos are demos.
• 28:17
  The talk itself has a moment where a demo stumbles, which I appreciated because local AI work still has drivers and model files.
• 28:26
  Memory pressure and practical weirdness are part of the work too.
• 28:30
  Also, Canuma is clear that you shouldn't expect a small local open model to behave like the strongest cloud model today.
• 28:38
  The local machine is becoming a serious creative surface again, even without parity on every task.
• 28:45
  The technical detail that stood out was Turbo Quant.
• 28:49
  Canuma says it can reduce key-value cache memory by about four times, and he connects that to very long local context, depending on model and hardware.
• 28:59
  First reference: key-value cache is the memory models use to keep attention state around while generating.
• 29:06
  If you can shrink that without wrecking output quality, local long-context work becomes less ridiculous.
• 29:14
  That matters for the same reason the Trigger.dev snapshot talk matters.
• 29:19
  Agent systems are hungry for state.
• 29:21
  They need context and files.
• 29:23
  They need tools, audio, images, and sometimes a running machine.
• 29:27
  Some of that will live in the cloud.
• 29:30
  Some of it's going to live on the laptop in front of you.
• 29:34
  I like ending there because it keeps the day from becoming only an enterprise deployment story or only a maintenance warning.
• 29:42
  OpenAI is building a company to embed engineers into large organizations.
• 29:47
  Security models are finding bugs and overclaiming some of them, while still changing the defender’s toolkit.
• 29:55
  Builders are learning, again, that generated code has to be owned after it lands.
• 30:00
  Backend teams are building memory and recovery for agents that run longer than a request.
• 30:07
  Product teams are building traces and previews because AI features need observation as much as they need prompts.
• 30:14
  Local toolmakers are making the machine on your desk more capable than it was last month.
• 30:20
  The line I’m carrying into Tuesday is simple: capability is exciting, but the code you keep decides whether the excitement survives.
• 30:30
  Lenar Kess.