Software Engineering Is Becoming Plan and Review — Louis Knight-Webb, Vibe Kanban

Is this mic on? Yes, this mic is on. How are we doing?

Doing great.

Woo! Fucking fantastic. Yeah, let's go. Allright.

So the title of this is about planning and review, but I think the real point behind this is, basically, 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 SwebEdge Verified Leaderboard ahead of OpenAI. 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 this space.

The agenda for today's class is we're going to 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.

I'm going to talk about time horizon and how agents are 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.

So let's get started. Everything is plan and review. So work that we software engineers do. 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, that basically the writing code part starts to shrink. 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 like, wow, I actually am not really doing much code writing anymore.

So it kind of poses an interesting question, though, which is, 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. I think it is an accelerant. You're probably getting more done in the day, but it's probably like you get 20 minutes back for every half an 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, I don't know, 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 kind of conceptually ground what we're talking about here today. So the first way is the plan-based approach. 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 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.

The benefits of this course are that you basically spend less time reviewing that work because you have invested time up front, 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, 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. 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, 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 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 maintenance work. And front end is very different from back end. So 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 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. Front ends are very stateful. There's interactions, animations, styles, there's functionality. And so personally, I find it much better to kind of 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 kind of test-driven development. So I guess 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-generated code. And that's basically the takeaway.

The other thing that I think is kind of interesting to consider 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 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, Louis, 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. Then you have the original cursor completing a single file, and that runs for 30 seconds. And then you have Claude 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 10-minute executions. And that is going to continue because basically, 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 its change.

I think 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.

But it's worth doing because what you're trying to maximize for, again, is how much time you are spending or minimize, rather, 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 at in nine 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 Chrome or Playwright MCP clicking around on stuff. 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 it.

But this poses an interesting question, which is, what happens when the average time that an agent is running for exceeds, say, five minutes? Because I think five minutes is roughly the time when you can sit there and wait for something, watch the logs, probably more realistically, browse Twitter, 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 or the job of being a software developer in a very, very different way.

This is something I'm sure everybody's seen, which is this kind of terminal maxing thing where you basically parallelism. 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 the project we started about a year ago called Vibe Kanban.

And essentially, it started as an attempt to make it possible to paralyze 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.

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 click on something and kind of be like, oh, 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 14, 2025. We did it first, I swear. OK, so the considerations. I think

so 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. So we need new interfaces to make this job awesome.

Because 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. 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 lock in in a deep way to one piece of work. So it's all about kind of I've put focus maxing. I don't know if that's a word. I'm coining it. You heard it here first.

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. And it should help you do code review. I think, obviously, 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 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 in 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've finished the task to I've deployed the task is just literally like following comments and reacting to them. So

I wrote this talk. I submitted this talk a few weeks ago. And on Tuesday, I decided to shut the company down. So 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 actually announced it yet.

OK, and we're going to do it using Vibe Kanban, of course. It has to be OK, so please add a blog post to the website with this content.

And I've pre-written

the weepy note. OK, so we've got Vibe Kanban website. Allright, 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. Well, 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 run whatever agent you've selected. I use Codex most of the time, but it supports eight of the most popular ones.

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 kind of relieved. You run a company for a few years, and you have this enormous responsibility to kind of you have staff and investors and all this stuff.

And I don't know, I feel like kind of a weight has been lifted almost. We can talk through why we're shutting it down as well. We have lots of 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. 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 Claude Code. And so people can we have a subscription. People spend like $30 with us and then press a button that helps them spend $3,000 with Codex.

It's just like 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 kind of move up into the enterprise. But I don't know. It's a kind of it's a mature market at this point, and it's no fun playing for eighth place.

So we decided to shut things down. OK, 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.

OK, that looks good. So we can go ahead, open a pull request.

Uncommitted changes.

I don't know what that's about.

Are we finding this out before your investors?

Oh, shit.

You're not. Don't worry. They most 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. OK, allright, 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 for you?

What's next? Take some time off, start another company. My co-founder is 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?

What about feeling? When you look back, is it positive or negative?

Oh, yeah. No, I wouldn't do anything differently. I think

it was like the most interesting thing I've worked on. And it'sright at the cutting edge of 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 these two 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. And you get to a point where it's like you're sitting there at midnight with 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. But it's difficult until you get there, I think.

Yeah, 12 seconds. No? OK.

Go back to the past. What will you change?

What would I change? I'd hire somebody who's really good at selling to enterprise. Allright, thank you very much.