SPEAKER_01
Is this mic on? Yes, this mic is on. How are we doing? Fantastic! Yeah, let's go! All right. So the title of this is about planning and review, but I think the real point behind this is what are we all going to do after AI continues to get really, really good? I'm Louis, I'm the founder of a startup called Vibe Kanban, and I also started the London chapter of AI Tinkerers, which is a great community 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 OpenAI.
SPEAKER_01
This is a couple of months old now. But anyway, it's always nice to know that the people talking have done some research in the space. The agenda for today is I'm going to walk you through why I have arrived at the conclusion that 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. I'm going to talk about time horizon and how agents are getting 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 we'll get onto that later on.
SPEAKER_01
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. OK, most people. 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, the writing code part starts to shrink.
SPEAKER_01
So ChatGPT arrived, suddenly you can generate functions and paste them in. And then Cursor, not Cursor today, but the original version of Cursor arrives. And then it's able to complete a whole page of code. And then you get Claude Code and it's wow, I actually am not really doing much code writing anymore. So it poses an interesting question, though, which is what—say we were spending four hours a day coding before. Does that mean I now get four 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.
SPEAKER_01
I think it is an accelerant. You're probably getting more done in the day. But it's probably you get 20 minutes back for every half hour that you were spending coding. And some other time has gone to planning and reviewing. So I want to talk about that. What is this new way of working? And I think there's fundamentally two approaches that people take. I'm not going to get too specific about specs or Playwright MCPs or things like that. I think there's tons of fascinating talks about that at this event. I just want to conceptually ground what we're talking about here today. So the first way is the plan-based approach.
SPEAKER_01
This is where you spend a lot of time upfront 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 one of these spec frameworks. You're interrogating. So I've seen some cool stuff where the model asks you questions repeatedly until it's completely exhausted all possible questions it could have about what the work is that needs to be done.
SPEAKER_01
The benefits of this course are that you basically spend less time reviewing that work because you have invested time upfront, eliminating edge cases, giving the models as much information as possible about the work you're trying to do. The outcome of that will be that the model's less likely to fuck up and you're going to get better outputs and probably fewer rounds of review. The downside is you have to spend more time planning, but that's just obvious, isn't it? The other way of doing this, the other big way of working with AI is you don't define a very detailed plan, but instead you let it run and then you end up spending more time reviewing that work.
SPEAKER_01
So benefits of this, you can just YOLO something, be like, ah, let's add a contact form to the web page. And then the payback you have to do is you're going to go back and forth a few times, correcting the styles, figuring things out. 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 approach, 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 giving you some half delivered work and you're constantly having to review it.
SPEAKER_01
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 maintenance work. And front end is very different from back end. So I was trying to think about this before the talk and this is the matrix I've come up with. Where basically if you're working on the front end and you're doing feature development, it's impossible to really spec everything out. There's so many edge cases. Front ends are very stateful. There's interactions, animations, styles, there's functionality.
SPEAKER_01
And so personally, I find it much better to be in the loop with a coding agent. So the second one of those behaviors that we talked about. 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 can be doing that. And you shouldn't be in the loop with any of that work at all, really. That should all be test driven development. So if you had to distill that into a sentence, it would be spending five minutes of planning saves you 30 minutes of reviewing AI generated code. And that's basically the takeaway.
SPEAKER_01
The other thing that I think is interesting to consider is how things are running for longer. So as coding agents become more capable, as models get better, as tool calling improves, you go from calling a very small set of tools to now the coding CLIs can call a huge range of tools and do testing and things like that. And you shouldn't be in the loop with any of that work at all, really. That should all be test driven development. So if you had to distill that long meandering spiel into a sentence, it would be spending five minutes of planning saves you 30 minutes of reviewing AI generator code. And that's the takeaway.
SPEAKER_01
The other thing that I think is interesting to consider is how things are running for longer. So as coding agents become more capable, as models get better, as tool calling improves, you go from calling a very small set of tools to now the coding CLIs can call 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, Lou, it's time for you to do something. So to illustrate this, think back to GitHub Copilot. It completes a single line of code and it takes seconds.
SPEAKER_01
Then you have the original cursor completing a single file and that route runs for 30 seconds. And then you have Code, which last year would run for maybe a minute or two. And this year I've been getting some pretty good results with five or ten minute executions. And that is going to continue because we've gone from you asking the AI to do something and it just responds to the AI running a type checker to the AI testing. It's changing. This is the frontier of things and these things take increasing amounts of time. Just returning the code was really quick. Running the type checkers is a bit slower than that.
SPEAKER_01
Running Playwright MCP is an order of magnitude slower than any of those things. But it's worth doing because what you're trying to maximize for, or rather minimize, is how much time you are spending working with the agent. So if you can get higher accuracy by waiting longer, that is a worthwhile trade off. And this is where the frontier probably is. If I had to forecast where we'd be in nine months time, I would say 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 Chrome or Playwright MCP clicking around on stuff.
SPEAKER_01
The reality is I haven't met a single person who actually does this 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. But this poses an interesting question, which is what happens when the average time that an agent is running for exceeds, say, five minutes?
SPEAKER_01
Because I think five minutes is roughly the time when you can sit there and wait for something, watch the logs, or more realistically, browse Twitter or something like that. And when we cross that five minute mark, you have to change your behavior. 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 the job of being a software developer in a very different way. This is something I'm sure everybody's seen, which is this terminal maxing thing where you basically parallelize, right?
SPEAKER_01
You run multiple of these things at once, say each of them takes 10 minutes to run. So the way you get around the waiting problem is you have multiple of them going at any given time. So as soon as you finish 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 the project we started about a year ago called Vibe Kanban. And essentially it started as an attempt to make it possible to parallelize agents very easily. We built some cool stuff. There is a sidebar where you can create multiple workspaces that run any coding agent like Codex, Claude Code, things like that.
SPEAKER_01
When you want to review the code, you get the diffs. If you want to comment on something, you can do it just how GitHub does. If you want to preview something or click on something and be like, 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. OK, so the considerations. Human behavior is going to change because agents are going to cross this five minute threshold. And who knows, that may continue. You may end up crossing an hour threshold.
SPEAKER_01
So we need new interfaces to make this job awesome, because if you try and do it using the existing tools, it sucks. You have to jump around reviewing code in one thing, previewing things in another. If I had a wish list for what I would want the ultimate coding agent tool for software developers to look like, it basically embraces 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 lock in a deep way to one piece of work. So it's all about focus maxing. I don't know if that's a word. I'm coining it. You heard it here first.
SPEAKER_01
But it should embrace the fact that you can't pull humans out of something and back into something else every 30 seconds, because it just fries their brain and it's no way to live. So it should be built around 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 work is going to be.
SPEAKER_01
And it should help you do code review. 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 AI 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 shepherding the change until it's deployed, which is a new emerging one. In its simplest form, it's monitor GitHub pull requests and just look for comments and be reactive to those automatically. A lot of the admin involved in getting something from I finished the task to I've deployed the task is literally following comments and reacting to them.
SPEAKER_01
So I wrote this talk and submitted it a few weeks ago. And on Tuesday, I decided to shut the company down. So there's a whole part of this talk, which was 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 is shutting down. So what I thought I'd do instead is we can actually shut the company down together. A lot of the admin involved in getting something from I finished the task to I've deployed the task is just literally following comments and reacting to them.
SPEAKER_01
So I wrote this talk, I submitted this talk a few weeks ago. And on Tuesday, I decided to shut the company down. So 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.
SPEAKER_01
But that's not going to happen anymore, because now the company is shutting down. So what I thought I'd do instead is we can actually shut the company down together.
SPEAKER_01
I haven't actually announced it yet. So, okay, and we're going to do it using Vibe Kanban, of course, it has to be. Okay, so please add a blog post to the website with this content. And I've pre-written the weepy note. Okay, so 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 was 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 run whatever agent you've selected. I use codex most of the time, but it supports eight of the most popular ones.
SPEAKER_01
And it's going to go ahead and try and figure out how to do that. What else is cool? Are you sad? Am I sad? I think I've just done so much thinking about it. I'm relieved. You run a company for a few years, and you have this enormous responsibility. You have staff and investors and all this stuff. And I don't know, I feel like a weight has been lifted almost. We can talk through why we're shutting it down as well. We have 30,000 monthly active users and 25,000 stars on GitHub. And actually the project will continue non-commercially. And we're already pushing changes even though we're shutting things down.
SPEAKER_01
But it's actually very difficult to make money in the current environment. 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 code. And so people can, we have a subscription, people would spend $30 with us, and then press a button that helps them spend $3,000 with codex. And it's just not sustainable. And all of our users are individuals, startups, smaller companies. And we could have done the work, I think, to address that and move up into the enterprise.
SPEAKER_01
But it's a mature market at this point. And it's no fun playing for eighth place. So we decided to shut things down.
SPEAKER_01
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.
SPEAKER_01
Okay, that looks good. So we can go ahead, open a pull request. Uncommitted changes. Don't know what that's about. Are we finding this out before your request is?
SPEAKER_01
Oh, shit. No, no, no. You're not. Don't worry. They, most of, well actually some of them, I need to call them after this. That's a really good point. I'm fully committed to shutting this down live on stage.
SPEAKER_01
Okay. All right, it's done. That's going to go through Cloudflare CDN. Thank you. I think we've got time for one or two questions. I don't know if anybody in the audience has a. One minute 45. What's next? What's next? Take some time off, start another company. My co-founder's going to join a lab. And most of the team have already found good jobs at Agent Labs. Things like that. Yeah. Any other questions? Is the feeling when you look back positive or negative? Oh yeah. No, I wouldn't do anything differently. I think it was the most interesting thing I've worked on. And it's right at the cutting edge of agents and all of this stuff.
SPEAKER_01
I think certainly, 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 the years running the company? Most valuable things. I mean, just work with great people. We went through several rounds of the team. And the team we ended up with was phenomenally better. No offense to previous team. But that's probably how to, and hard work as well. I think it took us a while to learn what hard work really was.
SPEAKER_01
And you get to a point where you're sitting there at midnight with the team in the office on a Saturday and everybody's motivated and that's, yeah, it takes you a while to figure out how to get to that point. And once you feel it, you know what that's like, it's difficult until you get there. Yeah. 12 seconds. No. Okay. If you go back to the past, what would you change? What would I change? I'd hire somebody who's really good at selling to enterprise.