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. And you should listen to me because I have done some stuff like get on the SweeBench verified leaderboard ahead of OpenAI.

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. Everything is plan and review. Work that we software engineers do: 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 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. ChatGPT arrived, suddenly, you know, you can like generate functions and paste them in, and then 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."

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 there's fundamentally two approaches that people take. 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. 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. The outcome of that will be that the models less likely to [__] up, and you're going to get like better, better outputs, and probably, you know, fewer rounds of review.

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

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

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.

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. 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. Running Playwright MCP is an order of magnitude slower. Um but it's worth doing because 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.

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

I submitted this talk a few weeks ago. And on Tuesday, I decided to shut the company down. So, what I thought I'd do instead is we can actually shut the company down together. Please add a blog post to the website with this content. Okay, so we've got Vibe Kanban website. All right, that's going to go and do it. It's created a Git work tree. It has run a setup script to install the dependencies. I use uh Codex most of the time.

Am I sad? I think I've just done so much thinking about it. I'm kind of relieved. We have 30,000 monthly active users and 25,000 stars on GitHub. 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. 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. It's a mature market at this point and it's no fun playing for eighth place. So, we decided to shut things down.

Overall feeling when you look back is positive. I wouldn't do anything differently. It's increased my value as a human by doing this, so I would do it all again. Most valuable things... I mean, just work with great people. And hard work as well. 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 team in the office on a Saturday and everybody's kind of motivated. Looking back... I'd hire somebody who's really good at selling to Enterprise.