Next.js is not a good fit for vibe engineering

If you haven’t already, read Simon Willison’s post on “Vibe engineering”. It perfectly lays out what many people who rely heavily on coding agents observe every day, and the unique challenges in getting the most out of these tools without becoming the bottleneck.

Like many others, I’ve been using Next.js for new projects for a while. Although it has its pain points, it generally provides a fast development loop without much setup. It’s obvious, though, that it stems from a pre-LLM era, when the most important requirements for a framework were different. It falls short for several of the vibe engineering practices that Willison describes:

• Parallel development: Being able to run multiple coding agents in parallel provides amazing leverage, but can be hard to set up correctly. Spinning up multiple instances of a plain Next.js app is fine, but if you add anything full-stack — a database, for example — that suddenly becomes a lot more complicated and requires manual setup.
• Testing and automation: Unsurprisingly, testing is usually not a top priority for someone building a new product on top of Next.js. Coding agents change that value equation, though: test loops let them work more autonomously and tackle more complex things, and agents can also help with tedious test writing.
• Documentation: Next.js is well represented in training data, but that mostly covers the frontend. Once you venture into backend land, Next.js is largely unopinionated and you need to pick a stack for yourself. That is nice in many ways, but it also means you need to give your coding agent proper context for the full stack.

I’ve been experimenting with an alternative to Next.js optimized for coding agents, supercharging the flow of agents writing code with us guiding them. I’m aiming to provide a familiar developer experience for people using Next.js, while at the same time addressing the issues above:

• Parallel development: Built-in support for spinning up isolated development environments with all dependencies — databases and other services — that parallel coding agents can work against.
• Testing and automation: Includes a testing framework designed to be written and iterated on by coding agents, using those same isolated environments to run. Also supports letting coding agents manually test pages and APIs with code they wrote, for even more autonomy.
• Documentation: Provides a local MCP that you can plug into your coding agent, which offers accurate and complete documentation for building across the whole stack.

The project isn’t ready yet, but will be open-sourced soon. If you want to follow along or have thoughts on vibe engineering, reach out at fabian@flapplabs.se.