A talk by Louis Knight-Webb (Vibe Kanban) arguing that as AI takes over implementation, software engineers increasingly spend their time planning and reviewing AI-generated work — so the biggest lever for shipping more is speeding up planning and review. The talk covers plan-based vs. review-heavy approaches, a matrix of feature development vs. migrations and maintenance, the impact of agent execution time (including the 'five-minute' agent threshold), parallelization and workflow management, a vision for future coding interfaces and 'focus maxing', an announcement of Vibe Kanban's shutdown, and a Q&A with reflections on the startup journey. Note: the assertion that engineers' work is shifting to plan-and-review is the speaker's argument presented in the talk. # Channel Presentation Observations ## Explicit Self-Description (Creator Claims) - **Role claim**: Speaker introduces himself as "Louie… the founder of a startup called Vibe Canvas [Kanban]" and as having "started the London chapter of AI Tinkers." - **Credibility claim**: States he "get[s] on the SweeBench verified leaderboard ahead of OpenAI" as evidence of expertise — "always nice to know that the people talking have done some research in the space." - **Organizational transparency**: Announces live on stage that "on Tuesday, I decided to shut the company down," noting "30,000 monthly active users and 25,000 stars on GitHub." ## Intended Audience - **Practicing software engineers**, confirmed interactively: "Everybody in here is a software engineer, right? Yes. Okay, most people." - Audience is presumed familiar with the AI coding tool landscape — references to GitHub Copilot, Cursor, Claude Code, Codex, and Playwright MCP go unexplained. - In-person conference/event audience ("this event" has "tons of fascinating talks" on specs and MCPs). ## Claimed Scope - Topic framing: "the title of this is about planning and review, but… the real point… is basically what are we all going to do after AI continues to get really, really good." - Explicit thesis: "all software engineers are going to do all day is plan and review stuff." - Distilled takeaway offered: "spending 5 minutes of planning saves you 30 minutes of reviewing AI-generated code." - Forward-looking forecast: "in 9 months' time… AI starts to be able to QA front-end work, and that's going to be a huge breakthrough." ## Demonstrated Presentation Patterns - **Balanced product transparency**: Spends much of the talk demonstrating Vibe Kanban but openly dismantles the sales pitch: "there's a whole part of this talk which was just me telling you more about Vibe Kanban and trying to sell it to you, but that's not going to happen anymore." - **Commercial candor**: Frankly explains the business failure — "everybody who is making money is doing two things. They're selling to enterprise and they're reselling tokens. And we were doing neither." - **Live demonstration style**: Performs the company shutdown using his own tool on stage ("we're going to do it using Vibe Kanban, of course"), including handling an error ("Uncommitted changes. Oh. Don't know what that's about.") transparently. - **Interactive Q&A close**: Takes audience questions on what's next, lessons learned, and retrospective feelings ("I wouldn't do anything differently… it's increased my value as a human"). - **First-person, experience-based argumentation**: Grounds claims in personal ratios ("the ratios until GitHub Copilot hit the scene were roughly this for me") and observed usage ("this year I've been getting some pretty good results with 5- or 10-minute executions"). - **Coining terminology**: "I put focus maxing… I'm coining it. You heard it here first." ## Observable Positioning Signals - Positioned at the intersection of **AI tooling commentary** and **startup founder experience**; willing to discuss investor relations ("some of them I need to call them after this") and team outcomes. - Community-oriented framing: promotes AI Tinkers London as "a great community if you're in London looking for events." # Delivery Observation: Louis Knight-Webb — "Software Engineering Is Becoming Plan and Review" ## Overall Delivery Style - **Conversational, informal talk format** with frequent filler words and self-corrections: *"Um this I've This is So, the the title of this is is about planning and review."* - **Direct audience engagement**: opens with mic checks and call-and-response — *"How we doing? Woo!"*, *"Everybody in here is a software engineer, right? Yes. Okay, most people."* - **Live demo component**: the second half shifts from presentation to an on-stage product demonstration, ending with an unscripted Q&A. ## Tone - **Casual and humorous**, with profanity and slang used freely: *"Ah, let's add a contact form to the webpage"* framed as *"you can just YOLO something"*. - **Candid and self-deprecating**, especially around the company shutdown: *"We did it first, I swear."* - **Openly confessional in the live moment**: *"I'm fully committed to shutting this down live on stage."* ## Vocabulary & Recurring Phrases - Repeated framing of the job as two verbs: **"plan and review"** appears throughout ("*we plan stuff, we write code, we review code*"). - Product names cited repeatedly as evidence markers: **GitHub Copilot, Cursor, Claude Code, Codex, Playwright MCP**. - Recurring time-quantification habit — supports claims with concrete numbers: - *"spending 5 minutes of planning saves you 30 minutes of reviewing AI-generated code"* - *"you get uh 20 minutes back for every half an hour"* - *"5-minute executions"*, *"20 minutes to run"*, *"1 minute 45"* - Emphatic intensifiers: *"really, really good"*, *"a very very different way"*, *"phenomenally better"*. ## Teaching / Rhetorical Habits - **Chronological progression to make an argument**: Copilot → ChatGPT → Cursor → Claude Code, each step showing the shrinking "writing code" portion. - **Two-option framing**: contrasts "the plan-based approach" vs. letting agents run and reviewing later. - **Self-aware meta-commentary on his own rambling**: *"if you had to distill that long, meandering spiel into a sentence, it would be spending 5 minutes of planning saves you 30 minutes..."* - **Explicit distillation habit** — ends sections with a stated takeaway rather than leaving the audience to infer one. - **Rhetorical questions to transition**: *"what happens when the average time that an agent is running for exceeds, say 5 minutes."* - **Coining terminology playfully**: *"I put focus maxing. I don't know if that's a word. I'm coining it. You heard it here first."* ## Structure & Patterning - **Agenda stated up front**: walks through agenda, and teases the ending: *"at the end, we're going to shut my company down. And [snorts] we'll get on to that later on."* - **Pivot mid-talk from pitch to disclosure**: *"on Tuesday, I decided to shut the company down"* — repurposes the demo into the shutdown itself (*"we can actually shut the company down together"*). - Handles a live-demo failure transparently: *"Uncommitted changes. Oh. Don't know what that's about."* - **Time-boxed Q&A**: *"Uh 12 seconds. No? Okay."* ## Uncertainty Notes - The transcript lacks audience audio for most questions (only speaker answers are visible), so question delivery cannot be observed. - Emotional tone around the shutdown (*"I feel like a kind of weight has been lifted"*) is directly quoted but stated once; no stable pattern of emotional delivery can be claimed from a single passage. # Position Extraction: "Software Engineering Is Becoming Plan and Review" — Louis Knight-Webb ## Speaker - **Louis (Louie) Knight-Webb** — founder of a startup (Vibe Kanban / "Vibe Canvas" as transcribed), founder of the London chapter of AI Tinkers. Cites having placed on the SWE-bench Verified leaderboard ahead of OpenAI (a few months before the talk) as evidence of research experience. ## Central Thesis - **All software engineering work converges toward planning and review.** Work previously spent writing code has been **displaced, not eliminated** — moved into planning and reviewing AI output. - Qualification: AI is "an accelerant"; you get "20 minutes back for every half an hour," not the full coding time. ## Core Claims & Reasoning ### 1. Two modes of working with agents - **Plan-based approach**: heavy up-front planning (plan docs, spec frameworks, models interrogating the user until questions are exhausted). Benefit: fewer review rounds, better outputs, model less likely to fail. Cost: more planning time. - **Review-heavy approach**: minimal spec, "YOLO" the task, then iterate correcting output. - **Stated preference**: always prefer planning, because human time is the valuable resource and constant back-and-forth with a half-delivered agent is time-consuming. ### 2. Distilled heuristic > "Spending 5 minutes of planning saves you 30 minutes of reviewing AI-generated code." ### 3. Work-type matrix - **Front-end feature development**: essentially impossible to fully spec (stateful, animations, styles, edge cases) — better to stay in the loop with the agent. - **Back-end feature development**: nearly test-driven development possible; plan-heavy. - **Refactoring / migrations / maintenance**: should be entirely plan/test-driven — "you shouldn't be in the loop with any of that work." ### 4. Time horizons are lengthening - Trajectory: Copilot (seconds, line completion) → original Cursor (~30s, file) → Claude Code (1–2 min last year; 5–10 min now). - Reason: agents moved from returning code to running type checkers to testing changes (e.g., Playwright MCP — an order of magnitude slower but worth it for accuracy). - **Forecast** (tentative, 9 months out): AI able to **QA front-end work** will be the next major breakthrough. He notes he has seen demos on Twitter but has "not met a single person who actually does this in mainstream development." ### 5. The 5-minute behavioral threshold - ~5 minutes is the limit of passively waiting; beyond that, developers must work in **parallel** (terminal maxing, multiple agents), which changes the job fundamentally — a manager of multiple work streams rather than deeply locked into one. - His wish-list for the ideal tool: support long agent runs then yield to the human; help write tasks, QA, code review, and **shepherd changes to deployment** (e.g., react to GitHub PR comments). He coins "**focus maxing**." - Claim: code review will persist because "very few companies with money on the line are actually going to ship stuff that's fully vibe coded without actually checking the code." ### 6. Live company shutdown (Vibe Kanban) - Announced on stage, previously unannounced ("Are we finding this out before your investors?" — "some of them I need to call after this"). - Demonstrated the product adding a shutdown blog post via the agent, with a Git worktree, setup script, diff review, live preview, and PR. - **Stated reasons**: 30,000 MAU and 25,000 GitHub stars, but not commercially sustainable. "Everybody who is making money is doing two things: selling to enterprise and reselling tokens" — they did neither. Users spent ~$30 on the subscription then pressed a button to spend $3,000 with Codex. Users were individuals/startups, not enterprise; the market is "mature" and "it's no fun playing for eighth place." - The project **continues non-commercially**. - Emotional register: "I'm kind of relieved... a weight has been lifted." ### 7. Q&A positions - **What's next**: time off, another company; co-founder joining "the lab"; team largely hired by agent labs. - **Retrospective feeling**: positive — "wouldn't do anything differently"; increased his value; most interesting work he's done. - **Lessons learned**: work with great people (final team "phenomenally better"); learned what hard work actually is. - **What he'd change**: "I'd hire somebody who's really good at selling to enterprise." ## Unresolved Tensions / Qualifications Preserved - Coding-time savings are partial, not total (displacement claim vs. "accelerant" framing). - AI front-end QA is claimed as the next breakthrough while simultaneously acknowledged as not used by anyone he knows in practice. - Contradiction acknowledged live: shutting down publicly before all investors were informed. - Success metrics (30k MAU, 25k stars) coexist with commercial failure — no smoothing offered. # Speaker & Provenance Record — Video `01a15ca9-7f9d-7afd-b996-7a41393fb2e4` ## Video **Title:** Software Engineering Is Becoming Plan and Review — Louis Knight-Webb, Vibe Kanban ## Speakers & Roles - **Louis "Louie" Knight-Webb** — **Creator / Presenter** - Self-identified: founder of a startup ("Vibe Canvas" per transcript audio; the title references **Vibe Kanban**, the project discussed) and founder of the London chapter of AI Tinkers. - Credibility claim made by speaker: got on the **SweeBench verified leaderboard** ahead of OpenAI "a couple of months" before the talk. - Announces live on stage that he is shutting the company down. - **Audience members (unnamed)** — **Q&A participants / hecklers** - Audience voice: "Are we finding this out before your investors?" - Questioner "Steve": asks "What's next?" - Unnamed audience questions: overall feeling looking back; most valuable lessons; what he would change. - **No narrator**; talk-format presentation with applause, music, and audience reactions noted in transcript. ## Promotional Segments - **Flagged:** Segment introducing **Vibe Kanban** — demo of the tool (multi-agent parallelism, workspaces, diff review, commenting, live preview). The speaker explicitly notes the original talk contained "a whole part … trying to sell it to you," which he replaces with a live company-shutdown demo. - Speaker self-promotes the **AI Tinkers London** community. - Mentions of third-party products (**GitHub Copilot, Cursor, Claude Code, Codex, Cloudflare, Playwright MCP**) are descriptive/comparative, not flagged as paid promotion. ## Referenced Sources & Third-Party Claims - **Personal experience only** — no cited publications, studies, or external documents. - Referenced tools/products: GitHub Copilot, Cursor, Claude Code, ChatGPT, Codex, "Cool Code" (transcript rendering), Playwright MCP, Chrome, Cloudflare CDN, GitHub. - Third-party ecosystem claims (speaker's own assertions, unverified): leaders monetizing via enterprise sales and token reselling; AI QA of front-end work demos on Twitter as the next frontier. - Company metrics stated by speaker: **30,000 monthly active users**, **25,000 GitHub stars**; Vibe Kanban "started as early as June 14th, 2025" (speaker's "we did it first" claim). ## Availability & Uncertainty - **Comment availability:** not stated in transcript or metadata — unknown. - **No curated metadata supplied** beyond the video title; title identifies speaker as Louis Knight-Webb, while transcript self-introduction renders as "Vibe Canvas" (likely transcription artifact vs. title's "Vibe Kanban"). - Timestamps: none present in transcript. \>\> Is this mic on? Yes, this mic is on. How we doing? Woo! \[ \_\_ \] fantastic. Yeah, let's go. All right. Um this I've This is So, the the title of this is is about planning and review, but I think the real point behind this is like basically what are we all going to do after AI continues to get really, really good. Uh I'm Louie. I'm the founder of a startup called Vibe Canvas, and I also started the London chapter of AI Tinkers, uh which is great community um if you're in London looking for events. And you should listen to me because I have done some stuff like get on the SweeBench verified leaderboard ahead of Open AI. This is a couple of months old now, but anyway, you know, it's always nice to know that the people talking have done some research in the space. Um the agenda for today, class, is we're going to uh I'm going to walk you through why I have arrived at the conclusion that basically all software engineers are going to do all day is plan and review stuff. And I'm going to talk about how to think about balancing that if that is what you do all day. Uh I'm going to talk about time horizon and how agents are getting uh running for longer and how that changes the behavior of the job. And then at the end, we're going to shut my company down. And \[snorts\] we'll get on to that later on. So, let's get started. Everything is plan and review. So, work that we software engineers do. Who's Everybody in here is a software engineer, right? Yes. Okay, most people. Um we plan stuff, we write code, we review code, and we review other people's code. Roughly, the work that we do. The ratios until GitHub Copilot hit the scene were roughly this for me. I know it depends on whether you work in a big company or a small company and things like that, but a lot of it was writing code and not very much of it compared to that was planning and reviewing code. And what we see is over time with things like the first version of GitHub Copilot, that basically the writing code part starts to shrink. So, you know, ChatGPT arrived, suddenly, you know, you can like generate functions and paste them in, and then Cursor, not Cursor today, but like the original version of Cursor arrives, and then it's like able to complete a whole page of code. Um and then you get Claude Code, and it's like, "Wow, you know, I actually am not really doing much code writing anymore." Um so, it kind of poses an interesting question though, which is what, you know, say we were spending 4 hours a day coding before, does that mean I now get 4 hours back if I'm not doing any actual coding? The answer, of course, is no. It has displaced work. Work that you or time that was previously spent doing the coding has moved. It has moved to planning and reviewing. I think it is an accelerant. You're probably getting more done in the day, but it's probably like, you know, you get uh 20 minutes back for every half an hour that you were, you know, spending coding, and some other time has gone to planning and reviewing. So, I want to talk about that. Like, what is this new way of working? And I think there's there's fundamentally two approaches that people take. I'm not going to get too specific about, you know, I don't know, specs or uh Playwright MCPs or things like that. I think there's tons of fascinating talks about that at this event. I just want to kind of conceptually ground what we're talking about here today. So, the first way is the plan-based approach. Um this is where you spend a lot of time up front planning the work that you want a coding agent to do. So, the smells of whether you are doing this type of work would probably look like you're writing a very comprehensive plan doc, markdown file. You're maybe using like one of these spec frameworks. You're uh interrogating. So, you know, I've seen some cool stuff where the model asks you questions repeatedly until it's like completely exhausted all possible questions it could have about what the work is that needs to be done. The benefits of this, of course, are that you basically spend less time reviewing that work because you have invested time up front uh eliminating edge cases, giving the the the models as much information as possible about the work you're trying to do. The outcome of that will be that it the models less likely \[ \_\_ \] up, and you're going to get like better, better outputs, and probably, you know, fewer rounds of review. The downside is you have to spend more time planning, but, you know, that's just obvious, isn't it? The other way of doing this, uh the the other big way of working with AI is you don't define a very detailed plan, but instead, uh you let it, you know, run, and then you you end up spending more time reviewing that work. So, you know, benefits of this, you can just YOLO something, be like, "Ah, let's add a contact form to the webpage." And then, you know, the the the payback you have to do is like you're going to go back and forth a few times correcting the styles, figuring things out. Um I would say if you think about the valuable thing being your human time, and you have a choice, you always want to be doing the first of these behaviors, the planning the planning approach, basically, because it will save you a lot of time. It is very time-consuming to have to switch back and forth with an agent that is like giving you some half-delivered work, and you're constantly having to review it. I think another way of breaking down the modes of work, where one is plan and one is review, is to think about the type of thing that you're working on. And I think feature development is actually very different from migrations and uh maintenance work. So, and front end is very different from back ends. I was I was trying to kind of think about this before the talk, and this is the matrix I've come up with, where basically, if you're working on uh the front end and you're doing feature development, it's basically impossible to kind of really spec everything out. There's so many edge cases and you know, front end is very stateful. Uh there's like interactions, animations, styles, there's functionality. And so, personally, like I find it much better to kind of be in the loop with a coding agent. So, the second uh one of those behaviors that we talked about. Uh but for everything else, I think it really is possible to be plan-heavy. So, back-end feature development, you can almost do test-driven development. And for anything like refactoring and migration-based, you certainly uh you certainly can be doing that, and you shouldn't be in the loop with any of that work at all, really. That should all be kind of test-driven development. So, the I guess if you had to distill that long, meandering spiel into a sentence, it would be spending 5 minutes of planning saves you 30 minutes of reviewing AI-generated code. And that's basically the takeaway. Uh the other thing that I think is kind of interesting to consider is is how things are running for longer. So, as coding agents become more capable, so as models get better, as tool calling improves, you go from calling a very small set of tools to now, you know, the the coding CLIs can call a a huge range of tools and do testing and things like that. The outcome of that is that every time you send off a prompt, you are waiting longer before it comes back to you and says, "Hey, Louie, it's time for you to do something." So, to illustrate this, I mean, you you know, like think back to GitHub Copilot. It completes a single line of code, and it takes seconds. Then you have like the original Cursor completing a single file, and that runs for, you know, 30 seconds. And then you have uh Claude Code, which, you know, last year would run for maybe a minute or two, and this year I've I've been, you know, getting some pretty good results with 5- or 10-minute executions. And that is going to continue because basically, we've gone from uh you asking the AI to do something and it just responds to the AI running a type checker to the AI testing its change. I mean, this is like the frontier of things. And these things take increasing amounts of time. Just returning the code was really quick. Running the type checker is a bit slower than that. Running Playwright MCP is an order of magnitude slower than any of those things. Um but it's worth doing because, you know, what you're trying to maximize for, again, is how much time you are spend or minimize, rather, is how much time you are spending working with the agent. So, you know, if you can get higher accuracy by waiting longer, um that is a a worthwhile trade-off. And this is like where the frontier probably is is like, you know, if I had to forecast where we'd be at in 9 months' time, I would say basically, AI starts to be able to QA front-end work, and that's going to be a huge breakthrough. You see some cool demos of this on Twitter with, you know, Chrome or Playwright MCP clicking around on stuff. The reality is I haven't met a single person who actually does this in their in their mainstream development. But I'm really excited for it, and I think it will be the next major breakthrough, where essentially, most of the back and forth that you do with a model is going to just be done by the model itself because it'll be able to actually run your project, click around, and find the bugs, and make sure it's done it. But this poses an interesting question, which is like, what happens when the average time that an agent is running for exceeds, say 5 minutes. Cuz I think 5 minutes is roughly the time when you can like sit there and wait for something, watch the logs, probably more realistically like browse Twitter, something like that. And when we cross that 5-minute mark, you have to change your behavior. You know, imagine these things are going to take 20 minutes to run. You're not going to sit there for 20 minutes watching agent logs. You're going to have to think about coding and all the job of being a software developer in a very very different way. Um this is something I'm sure everybody's seen, which is, you know, this kind of terminal maxing thing where you you basically parallelism, right? You run multiple of these things at once. Say each of them take 10 minutes to run. So, the way you get around the waiting problem is you have multiple of them on the go at any given time. So, as soon as you finished, say reviewing one piece of work, another has finished and you can move on to that. And that's basically what we started working on. So, this is uh this is the the the project we started about a year ago called Vibe Kanban. And uh essentially it started as as an attempt to make it possible to paralyze agents very easily. Um we built some cool stuff. There is uh a sidebar where you can create multiple workspaces that run any coding agent, like Codex, Cool Code, things like that. Uh when you want to review the code, you get the diffs. If you want to comment on something, you can do it just kind of like how GitHub does. If you want to preview something or, you know, click on something and kind of be like, "Ah, actually make this a bit bigger or that a bit smaller." You can do that, too. And you probably have seen all of this stuff before, but you may not have seen this stuff started as early as June 14th, 2025. We did it first, I swear. Okay, so the considerations. I think like what so so so human behavior is going to change because agents are going to cross this like 5-minute threshold. Um and who knows, that may continue. You may end up crossing an hour threshold. So, we need new interfaces to make this job awesome. Cuz if you try and do it using the existing tools, it kind of sucks. You have to jump around reviewing code in one thing, previewing things in another. Um if I had a wish list for what I would want the ultimate coding agent tool for software developers to look like, it basically embraced the fact that I have to be a manager of multiple streams of work at any given time, which is not something most software developers have had to do. They've just been able to like lock in in a in a deep way to one piece of work. So, it's all about kind of I I put focus maxing. I don't know if that's a word. I'm coining it. You heard it here first. Um but it should embrace the fact that you can't pull humans out of something and back into something else every 30 seconds cuz it just fries their brain and it's not it's no way to live. Um so, you know, it it should be built around, you know, getting the most out of the human so that an agent can run for as long as possible and then yield back to the human rather than encouraging patterns where you're constantly jumping in and out and in and out of needing to get back into the context of what a particular agent is doing. It should help you write tasks and plan things, obviously. It should help you QA work because that's what a lot of the human's work is going to be. And it should help you do code review. I think obviously code review, you know, a lot of it's being done with AI, but very few companies with money on the line are actually going to ship stuff that's fully Vibe coded without actually checking the code. So, reading code is probably something most people in this room are going to still have to do. And then shepherding the change until it's deployed, which is kind of a new emerging one. So, you know, at its simplest form, it's like monitor GitHub pull requests and just look for comments and kind of be reactionary to those automatically. A lot of the admin involved in getting something from I finished the task to I've deployed the task is just literally like, you know, following comments and and reacting to them. So, this I wrote I wrote this talk I I I submitted this talk a few a few weeks ago. And on Tuesday, I decided to shut the company down. So, \[snorts\] I had a whole basically there's a whole part of this talk which was just me telling you more about Vibe Kanban and trying to sell it to you, but that's not going to happen anymore because now the company's shutting down. So, what I thought I'd do instead is we can actually shut the company down together. I haven't I haven't actually announced it yet. So, \>\> \[applause\] \>\> Okay, and we're going to do it using Vibe Kanban, of course. It has to be, you know. Okay, so uh please add a blog post to the website with this content. Uh \>\> \[groaning and snorts\] \>\> and I've pre-written the uh you know, the weepy the weepy note. Okay, so we've got Vibe Kanban website. All right, that's going to go and do it. I can give you a little tour of this thing as well. So, it's running a setup script. What it's created a Git work tree. It has run a setup script in the work tree to install the dependencies for our website. And once that's done, it proceeds to uh run whatever agent you've selected. I use uh Codex most of the time, but it supports eight of the most popular ones. Um and it's going to go ahead and try and figure out how to do that. Um what else is cool? Are you sad? Am I sad? I think I've just done so much thinking about it. I'm kind of relieved. Like you run a you run a company for for a few years and you have this like enormous responsibility to kind of, you know, you have staff and investors and all this stuff and and I don't know, I feel like a kind of weight has been lifted almost. Um we can talk through like why we're shutting it down as well. We have we have lots of you We have 30,000 monthly active users and and 25,000 stars on GitHub. And actually the project will continue non-commercially. Um and we're already pushing changes even though we're we're shutting things down, but it's actually very difficult uh to make money in the current environment. Uh the everybody who is making money is doing two things. They're selling to enterprise and they're reselling tokens. And we were doing neither of those things. We're not a coding agent. We have a button that helps you run something in Codex or or Cool Code. And so, people can we we have a subscription. People would spend like $30 with us and then press a button that helps them spend $3,000 with Codex. It's just like not sustainable. Um and all of our users are like individuals, startups, uh smaller companies. And we could have done the work, I think, to address that and kind of move up into the enterprise, but you know, I don't know. It's uh it's a kind of it's it's a mature market at this point and it's no fun playing for eighth place. So, we decided to shut things down. Uh okay. Blog post is ready. Let's see if it works. So, we've got the live preview feature, obviously. Let's wait for it to compile. Okay. That looks good. So, we can go ahead, open a pull request. Uh uncommitted changes. Oh. Uh Don't know what that's about. Uh Are we finding this out before your investors? Oh, \[ \_\_ \] \>\> \[snorts\] \>\> Uh you're not. Don't worry. Uh they most of Well, actually some of them I need to I need to call them after this. That's a really good point. I'm fully committed to shutting this down live on stage. Okay. All right, it's done. That's going to go through Cloudflare's CDN. \>\> \[applause\] \>\> Thank you. Um I think we've got time for one or two questions. I don't know if anybody in the audience has a a one 1 minute 45. Just \>\> Steve? What's next? Uh take some time off, start another company. My co-founders going to join the lab. And most of the team have already found good jobs at Agent Labs, things like that. Yeah. Any other questions? \[snorts\] Overall feeling when you look back is positive or negative Oh, yeah. No, I wouldn't I wouldn't do anything differently. I think like uh it it it it was like the most interesting thing I've worked on and uh is right at the cutting edge of like agents and all of this stuff. I think certainly I don't know. It's increased my value as a human by doing this, so I would do it all again. Yeah. Go for it. What are the most valuable things you've learned from a few years of running a company? Uh most valuable things I mean, just work with great people. You know, we went through several rounds of the team uh and the team we ended up with was like phenomenally better. No no offense to previous team, but that's probably how to, you know, I think and and hard work as well. I think like it took us a while to learn like what hard work really was. Um and you get to a point that's like you're sitting there at midnight with the, you know, the team in the office on a Saturday and everybody's kind of motivated and that's yeah, it takes you a while to kind of figure out how to get to that point. And once you feel it, you know, kind of what that's like. It's difficult until you get there, I think. Yeah. Uh 12 seconds. No? Okay. \>\> Looking back to the past, what would you change? What would I change? And I'd I'd hire somebody who's really good at selling to Enterprise. All right, thank you very much. \>\> \[applause\] \>\> Cheers. \>\> \[music\]