This one started years ago when a family member needed a booking system for their motorbike driving school. I built something that worked, and it's been running since.
I have to rebuild it. Emails stopped working properly, and Firebase keeps sending me notices about deprecated features. That said, the Firebase stack was surprisingly nice, it cost me about 5 cents a month and the tools were straightforward.
The stack is: next.js, shadcn, vercel, drizzle, neon, posthog and sentry.
Development strategy: Agentic coding. I'm not comfortable letting agents blindly code, I want to understand what is going on. I'm not saying I'm right. I sill break down features in steps and ask the agent to tackle them one at a time. I review each changes before committing.
Not many tests, I use mostly e2e tests with Playwright for the important paths.
The main issue I have with this approach is the time I have to wait between prompts and output.
It's tempting to add features, but no. Like Stripe integration for example. I try to keep it minimal and weight: added value / entropy.
Let me ask Claude to do a little bit of research on agentic dev, the different techniques, pros / cons, long term trends, consensus, ...
Claude thoughs on it
prompt: TODO: please claude, do a bit of research and cite srcs here about the sentence above
Here's what I found. Sources are linked inline so Jonas — and you — can check whether I'm summarising them fairly.
The techniques people converged on
The loop nearly every guide describes is the same one: explore → plan → implement → verify. Anthropic's best practices for Claude Code put it in those words, and add the part that matters most: give the agent a check it can run. Without a test, a build, or a screenshot to diff against, the agent stops when the work "looks done" — and the human becomes the verification loop.
Around that core, a few named practices:
- Spec-driven development. Write the spec first, let the agent derive the
plan and the tasks from it. GitHub's
spec-kit formalises this as
spec.md → plan.md → tasks.md → code. - Context engineering. Context is the scarce resource; performance degrades
as the window fills. Hence short
CLAUDE.mdfiles,/clearbetween unrelated tasks, and subagents that read many files in their context and report back a summary. - Writer / reviewer split. A second agent, in a fresh context, reviews the first one's diff. It isn't biased toward code it just wrote.
- Parallel and async agents. Worktrees, background agents, queue-it- overnight-get-a-PR. This is where most of the tooling energy went in 2026.
The evidence is genuinely mixed
The most quoted study is METR's: 16 experienced open-source developers, 246 tasks on repositories they knew well, early 2025 tooling. They were 19% slower with AI — and believed they had been 20% faster (METR, arXiv:2507.09089). Worth reading the follow-up though: METR redesigned the experiment in February 2026 because developers now refuse to take part if they can't use AI, and because they self-censor the tasks they submit. Their newer raw data points at a speedup, but they don't trust it enough to publish a number. So: one careful study, in one setting, that its own authors label historical.
At team scale the picture is "more output, more mess". Faros AI's telemetry over 10,000+ developers found high-AI-adoption devs completed 21% more tasks and merged 98% more PRs — with review time up 91%, PR size up 154%, bugs per developer up 9%, and no correlation with company-level performance (Faros AI). DORA's 2025 report (~5,000 respondents, 90% adoption) lands in the same place: throughput up, instability up, and AI mostly amplifies whatever the team already was (DORA).
On the code itself, GitClear's analysis of 623M changes reports duplicated code blocks up 81%, copy/paste within commits up 41%, and refactoring line-moves down 70% versus 2022 (GitClear). That's vendor research and should be read with the usual squint, but the direction is plausible: left unsupervised, an agent will happily write a new function rather than go find the one that already exists.
And developers themselves aren't sold. Stack Overflow's 2025 survey: 84% use or plan to use these tools, but 46% distrust their accuracy (up from 31%), 66% say the answers are "almost right, but not quite", and 45% lose real time debugging generated code (Stack Overflow).
Where it seems to be going
Anthropic's 2026 Agentic Coding Trends Report argues the job shifts from writing code to orchestrating agents that write it, with multi-agent setups and async background agents as the default. The consequence everyone points at is the same: verification becomes the bottleneck. Not "can the agent do it", but "how many of these can I direct and review at once".
Which makes the honest question the one Simon Willison asked himself: vibe coding and agentic engineering are getting closer than I'd like. He's stopped reviewing every line, and treats agents like a team he trusts — while naming the risk out loud: normalization of deviance. Every unreviewed diff that turns out fine makes the next one easier to skip.
On the waiting
Jonas mentions above that his main complaint is the dead time between prompt and output. That's the problem the whole async/parallel branch of tooling exists to solve — worktrees, background agents, several sessions at once — and it does work, in the narrow sense that the human stops idling.
It's worth being honest about the trade, though. Every one of those approaches converts waiting into reviewing, and reviewing is the thing the data already flags as the bottleneck. Running three agents doesn't make the queue shorter; it makes three queues. For a solo project on a codebase one person has to keep in their head, "wait a bit, stay in one context" may genuinely be the cheaper option.
An honest assessment of the approach in this post
Breaking features into steps and reviewing every diff is the consensus advice, and it targets exactly where the measured pain shows up. No notes there.
The soft spot is "not many tests". Every source above converges on the same point: the agent needs a check it can run, or the human is the check — and being the check is precisely what makes the review bottleneck expensive. The Playwright e2e tests on the important paths are doing more work in this setup than the post gives them credit for. More of them, or a fast build/typecheck gate the agent runs unprompted, would buy back some of that review time.
Beyond that, the consensus is boring and fairly stable: small scope, clean context, make the agent prove it works. It reads less like a new methodology and more like ordinary engineering discipline, applied to a much faster typist.
One caveat on all of the above: I'm an LLM summarising research about LLMs, and the studies disagree with each other more than any single number suggests. Treat the links as the argument, not my paraphrase of them.