Software Engineering Is Becoming Plan and Review

What do software engineers do as AI gets better at the work they currently perform? Louis Knight-Webb approaches that question through planning and review. He introduces himself as the founder of Vibe Kanban and the person who started London’s AI Tinkerers chapter. His experience includes coding-agent research: he reports having appeared ahead of OpenAI on a SWE-bench Verified leaderboard, while acknowledging that the snapshot he is showing is already months old. The practical question is how those improving capabilities change an engineer’s day—and, eventually, the business of building tools for engineers.

Start with four activities: planning, writing code, reviewing your own code, and reviewing other people’s code. Before GitHub Copilot, writing occupied most of Knight-Webb’s allocation; the proportions naturally varied between people and companies.

Successive tools shrink that writing portion. GitHub Copilot begins with completion assistance. ChatGPT makes it practical to generate functions and paste them into a project. The original Cursor extends completion to a page of code. Claude Code then takes over enough implementation that Knight-Webb finds himself doing little direct code writing. These are stages in his experience of the tools, rather than descriptions of their current feature sets.

Suppose you previously spent four hours a day coding. Automating that work does not simply return four free hours: some of it becomes planning and review. Knight-Webb’s rough estimate is that a half hour previously spent coding might return twenty minutes, with some of the displaced time going into those other activities. The work changes shape even when total output increases.

One approach puts substantial human effort into defining the task before the agent starts. Its recognizable artifacts are comprehensive Markdown plans and specification documents. Another technique makes the model ask questions repeatedly until it has exhausted its uncertainties about the requested work. The important mechanism is not a particular framework: it is supplying missing context and resolving edge cases before they become implementation decisions.

That preparation should reduce mistakes and the number of review rounds. It has an explicit cost—more time planning—but it lets the agent carry more of the task without returning for clarification or repair.

The alternative starts with a loose request, such as adding a contact form to a webpage, and lets the agent produce something to react to. The request is quick; the payment comes afterward in corrections to styling and other details. The two approaches allocate the human’s attention differently:

When human time is the scarce resource and the task permits a choice, Knight-Webb favors planning. Repeatedly receiving half-finished work is expensive because each correction requires returning to the task’s context, not merely typing another message.

The preference for planning has an important qualification: front-end feature work is difficult to specify exhaustively. A new interface combines state, interactions, animations, styles, and functionality. Some of the desired behavior becomes clearer only when you can interact with the result. For that work, Knight-Webb prefers to stay in the loop with the agent.

Back-end features offer more opportunities to express the desired behavior through tests. Refactoring and migrations are also strong candidates for a plan followed by test-driven execution, on either side of the application. His proposed balance is therefore:

For the plan-heavy cases, his ambition is to remove the human from the agent’s execution loop, with tests guiding the work rather than a stream of manual corrections.

Knight-Webb summarizes the trade-off with a heuristic: five minutes of planning saves thirty minutes of reviewing AI-generated code. Read that as his practical rule for allocating attention, not as a measured conversion rate for every task.

As models improve and coding CLIs gain access to more tools, an agent can do more before handing control back. That also means waiting longer after each prompt. Knight-Webb illustrates the progression with approximate runtimes and his own experience:

These examples describe increasingly substantial work, not a speed comparison on an identical task.

The added time has a mechanism. Returning generated code is fast. Running a type checker takes longer. Testing the change adds more work still. Knight-Webb characterizes Playwright MCP browser testing as an order of magnitude slower than the preceding operations, without supplying a controlled timing comparison. The relevant optimization is human time spent working with the agent: a longer run can be worthwhile if verification produces a result that needs less correction.

At the time of the talk, he forecasts autonomous front-end QA as a major breakthrough over the following nine months. He has seen Chrome and Playwright MCP demonstrations, but says he has not met anyone using that workflow in mainstream development. The anticipated loop is concrete: run the project, click through it, discover bugs, fix them, and check the result. Work that currently requires back-and-forth with a human would then happen inside the agent’s own run.

Longer runs eventually change the human workflow. Knight-Webb puts the rough waiting threshold at five minutes: short enough to watch logs or browse something else, but beyond it passive waiting becomes increasingly awkward. If an agent takes twenty minutes, the developer needs another way to organize the job rather than sitting in front of its terminal.

One response is to run multiple agents at once—the proliferation of terminals Knight-Webb calls terminal maxing. In his example, each agent runs for ten minutes. While one works, the developer reviews another result; ideally, another task is ready when that review finishes. Vibe Kanban began roughly a year before the talk as an attempt to make this parallel work easy to manage.

Its sidebar organizes multiple workspaces running agents such as Codex and Claude Code. Review happens through diffs and GitHub-style comments. A live preview supports visual feedback, including clicking an element to ask for it to become larger or smaller. Knight-Webb dates these features to June 14, 2025, with a playful claim to having built them first.

If agent runs grow beyond minutes toward an hour, the interface must support a developer managing several streams of work. Existing tools often scatter code review and application previews across different places. That is a substantial change from concentrating deeply on one implementation task. Simply adding more terminals does not solve the attention problem.

Knight-Webb calls the desired property focus maxing: do not pull a person into a different context every thirty seconds. An agent should run as long as it usefully can, then yield in a way that lets the human give the task sustained attention. The interface should support task writing, planning, QA, and code review. Even with AI-assisted review, he expects companies with money at stake to keep inspecting generated code before shipping it.

The workflow also extends beyond producing and reading a diff. A change must be shepherded until it is deployed. At its simplest, agent assistance can monitor a GitHub pull request for comments and respond to them automatically. Much of the administrative gap between finishing a task and deploying it consists of following those comments and acting on the feedback. Task completion is an intermediate state, not the end of the workflow.

The demonstration takes an unexpected turn. Knight-Webb submitted the talk weeks earlier, but decided on Tuesday to shut down the company behind Vibe Kanban. The planned product pitch becomes a live task: publish the shutdown announcement using the product itself. The distinction matters throughout what follows—the company is closing, while the software project will continue.

He supplies a prewritten announcement and asks the agent to add it as a blog post on the website. This is the Goodbye bloop announcement. The writing is already prepared; the delegated work is integrating that content into the website.

The workspace starts through a definite sequence:

1. Create a Git worktree for the task.
2. Run a setup script inside that worktree to install the website’s dependencies.
3. Start the selected coding agent against the prepared workspace.

Knight-Webb normally uses Codex and says the demonstration supports eight popular agents. The worktree gives the task its own checkout, while the setup step prepares that checkout before agent execution.

The Git portion of that arrangement can be expressed directly in a shell. For a task branch named shutdown-announcement, this creates a separate checkout and inspects its working-tree state:

git worktree add -b shutdown-announcement ../website-announcement
git -C ../website-announcement status --short

The website’s setup script and the selected agent would then run in ../website-announcement, following the sequence shown in the demonstration.

While the agent works, someone asks whether Knight-Webb is sad. After extensive deliberation, he describes feeling relieved: running a company carries responsibility for staff and investors, and some of that weight has lifted.

Knight-Webb reports 30,000 monthly active users and 25,000 GitHub stars at the point of shutdown. The project will continue non-commercially, and the team is still pushing changes. The problem is not an absence of users; it is making money from the product in that market.

His diagnosis is that the businesses making money are selling to enterprises and reselling tokens. Vibe Kanban does neither. It is an interface for running external agents, not its own coding agent, so much of the spending it enables goes elsewhere. He illustrates the mismatch with a customer paying Vibe Kanban about $30, then using its button to spend $3,000 with Codex. Those amounts illustrate the commercial relationship rather than establish average customer spending.

The customer base consists largely of individuals, startups, and smaller companies. Knight-Webb thinks an enterprise move might have been possible, but no longer finds it attractive in a mature market. His blunt description is that there is “no fun playing for eighth place.”

The agent then returns with the blog post ready. Knight-Webb opens the live preview, waits for compilation, and approves the appearance. He attempts to open a pull request, but encounters an uncommitted-changes obstacle whose cause he does not explain. The demonstration has reached precisely the gap between a completed implementation and a published change.

An audience member asks whether the investors are learning about the closure after the room. Knight-Webb initially says no, then acknowledges that some still need a call. He remains committed to announcing it onstage. Finally, he says the task is done and that the change will go through Cloudflare’s CDN. The intervening commit and merge steps are not explained, so the endpoint of the demonstration is his reported completion and expected delivery through Cloudflare.

Asked what comes next, Knight-Webb plans to take time off and then start another company. His co-founders plan to join a lab, and most of the team have already found jobs at agent labs or similar organizations.

His retrospective is positive. He initially says he would not do anything differently: this was the most interesting work he has done, at the cutting edge of agents, and the experience made him more valuable. He would do it again despite the commercial outcome.

The most valuable lessons concern people and effort. Several iterations of the team led to a final group he considered substantially stronger. Learning what hard work meant also took time. His concrete memory is of being in the office at midnight on a Saturday with the whole team still motivated—a shared commitment that he found difficult to understand before experiencing it.

The final question makes the counterfactual specific: if he could go back, what would he change? He would hire someone who was very good at selling to enterprise. The closing lesson is a business decision, even after a talk about how profoundly the engineering workflow is changing.