A co-write on what three months of autonomous-agent funding didn’t close. Lewis Gavin, Head of Growth at easyfundraising, and Paul Johns, co-founder of Else.
The first time I said it out loud
When Paul and I first spoke in February, we were three months into running Reforge Build on a regular cadence. Our UX team is super proficient, and Reforge let us put something in front of customers fast, talk to them, iterate. That side of the loop worked.
The other side didn’t. The moment the prototype was ready for engineering, the work effectively restarted – designing the breakpoints, mapping it onto the real components, rebuilding the front-end in something the engineers could actually merge. The fidelity gap between what we showed customers and what we handed engineering was wide enough that the prototype barely survived the trip. I described it to Paul on that February call like this:
“What it doesn’t do is give us a handoff. It’s not actually built on our code base at all, so it is throw away.
The frustration wasn’t with Reforge. Reforge was solving the customer-prototype problem fine. The frustration was that no tool we had was solving the engineering-handoff problem at the same time. Cursor was the only other option, and it’s too technical for a UX team to drive end-to-end.
Three months that moved the field
Between Lewis’s February call and the week we’re writing this, the AI prototyping and autonomous-coding-agent market consolidated faster than in the prior twelve months. Cognition’s Devin entered talks at $25B, more than double its September 2025 mark. Cursor shipped Cloud Agents in February, making background agents that produce merge-ready PRs the default engineering surface. GitHub Copilot Coding Agent went GA in every paid tier. OpenAI Codex crossed 3M weekly actives with a desktop app, Bedrock managed agents on AWS, Workspace Agents inside ChatGPT, and a GPT-5.5 release in late April. On the other side of the field, Lovable hit $400M ARR by May behind Lovable 2.0, Workspaces, and multiplayer, and Replit rebranded around Agent 4 and a Design Canvas with a Pro plan aimed at product builders.
The whole sweep consolidated on two poles. One is the autonomous-engineer pole – Devin, Cursor Cloud, Copilot Coding Agent. PR-as-output, sold to people who already ship code. The other is the non-engineer-builder pole – Lovable, Bolt, Replit Agent. Hosted demos, sold to anyone who wants to ship something that looks like a product without writing the code. That two-pole split is the same map drawn in AI coding tools versus AI prototyping tools; what neither pole built is the seat in the middle. Both poles raised eye-watering money. Both poles shipped material new capability. Neither pole shipped a tool for the seat Lewis was sitting in when he made that February call.
What Lewis described in February didn’t close. It moved. The field built faster ways to build on either side of it and skipped the part in the middle.
What the field actually built
Over the last few months I’ve kept a running scorecard on twenty-five of the prototyping and coding-agent products that have shipped. Five dimensions: does it work on the customer’s real production codebase, does it produce a production-ready PR, is the UX shaped for non-engineers, does it run user testing on the prototype, is the artifact shareable as a working preview.
One column is empty across the entire matrix. The user-testing column. None of the products ship a way to run a user test against the real product as part of the prototype loop. Not Lovable, not Devin, not Cursor Cloud, et al.
Tempo Labs put a price on the concession. In March they introduced a $4,000-a-month Agent+ tier with human reviewers attached, because self-serve AI output doesn’t reach production quality. They’re staffing the rebuild with humans.
Owen Williams, a design manager at Stripe who shipped a tool called Protodash in April, put it like this on the How I AI podcast in May:
“The prototype is the source of truth – they literally have a pull request of a prototype.
That’s the version Lewis was after in February. None of the products in the matrix actually ship it.
Lewis put it to me again on a call in late April, four months after the first:
“I can’t point Lovable at easyfundraising because it just can’t do that.
Easyfundraising is the product Lewis runs Growth for. He had tried Lovable in the intervening months. Even at $400M ARR Lovable doesn’t reach his product – it builds a new app next to his product, and the validation he runs on the new app doesn’t transfer.
The seam the field claims to be closing is being closed from sides that don’t touch the product the PM is responsible for.
The Reddit signal
The cohort wrote about the failure modes in the same window. Between February and May, a shared vocabulary hardened across the developer and PM-adjacent subreddits, and the shape of every term in it points back to the same upstream cause.
The single most-cited artifact in our social-signal log is the r/vibecoding thread Vibe coded for 6 months. My codebase is a disaster – 540 comments, cross-posted to r/AI_Coders, settling six months as the canonical time-to-rot for a codebase a PM or solo founder has shipped through a vibe-coding tool. A companion thread, Vibe coding feels amazing until an experienced developer reviews your code, picked up 390 comments and named the quality ceiling. Senior engineers on r/ExperiencedDevs converged on architectural drift – code that compiles, ships, and slowly stops resembling a system anyone can reason about – with a separate thread tracking the rollback to autocomplete after teams gave Claude Code and Codex a serious run. Designers on r/UXDesign named the sibling failure mode design debt. PMs on r/ProductManagement opened the read-access question. Indie builders on r/SaaS landed on the throwaway branch on Vercel or Netlify as the consensus workaround – the same workaround Lewis was sitting inside in February.
Architectural drift, design debt, throwaway branch, time-to-rot, rebuild from scratch. The cohort named the failure modes with real precision and never reached the seam underneath them. Every one of those terms is a downstream symptom of the same upstream cause: the artifact that got validated is not the artifact that got merged.
The seam, from inside one team
Three months later the loop looks different. I have started building changes inside the actual codebase with Else, opening the PR myself, and letting engineering review it the way they review any PR. One feature I shipped that way has now been used organically by hundreds of users – a strong enough demand signal that we are working on fleshing it out into a more rounded proposition.
That was a deliberate call – customer validation in production over the research and pre-validation route I would normally have run. I would rather have real users running the real feature than a research deck telling me they probably will. The cost of being wrong is small if engineering can roll the change back. The cost of being slow is the customer who stays on the version they did not like.
We did a company-wide demo on May 6 – about fifteen people across product, UX and marketing. The response was good and complicated at the same time. The main pushback the following week came from UX and senior product. They were not worried about engineering quality – engineering was actually the more relaxed seat in the room. They were worried about people going rogue, non-engineers shipping features that did not align with the UX and product vision the team has been building toward. That is a real concern. PMs and UX both carry a view of the product, and a tool that lets one of them ship without the other in the loop pulls the view apart.
We are not all the way through that conversation yet. What I can already see is the shape of where it is going. Non-engineers are not going to be shipping new features left, right and centre – nobody on our team wants that. The validation work, the UX tweaks, the small changes that get stuck on backlogs for months – those are the obvious lane. The question the team is asking has moved from is this possible to what is the process behind this. That shift is the signal that something has actually changed.
Paul’s framing of the seam is one degree more general than mine. He thinks the field has solved validated-to-merged on the build side and skipped the part where the bet itself gets tested. From inside one team, that lines up. The build capacity has arrived. The validation capacity has not.
What changes when the prototype is the PR
The shortest version of what I have learned over the last three months is that show is much better than tell. A working prototype built against the real codebase changes the conversation with engineering more than any document I have ever written, and it lets me discover the art of the possible – and the pitfalls – before engineering get involved. As a side benefit, it is also a lot more fun than writing yet another doc or queueing up a load of tickets.
What I had been carrying into engineering conversations for years is not really a spec or a Figma. It is a bet. The Figma is the prop. The PRD is the prop. The bet is the thing I actually believe about which change is worth making, who it is for, and why. The prop helps me make the bet legible. The prop is not the bet.
That is the thing I missed in the old loop. When engineering rebuilt the Reforge prototype, what they were rebuilding was the prop. The bet was already lost in translation by the time the rebuild started – I had encoded it in a Figma file and a doc, both of which engineering had to read and reinterpret. The thing that should have survived the rebuild was the bet. The artifact was always going to be redone somewhere. This is the chasm between the prototype and the product, seen from the PM seat: what falls into it is not engineering hours, it is the bet.
Look at the field’s twelve-month trajectory and the code step keeps getting cheaper, faster, more reliable. Devin, Cursor Cloud, Copilot – pick your pole, the line is the same. Code is on its way to being a commodity. What is not a commodity is figuring out which code is worth writing. That decision lives in the PM and UX seats, and a tool that hands those seats a real prototype against the real codebase is a tool that puts the bet in the place it can survive.
Inside our team the conversation has already moved. The question is not can PMs ship code. It is which kinds of changes go without heavy engineering involvement. That second question is the productive one. It assumes the lane exists and asks how wide it should be.
The PM seat does not get automated by the autonomous engineer. It gets unlocked by it. The autonomous engineer takes care of the code. The PM is freed up to take care of the bet.
When engineering rebuilds, the thing that should survive is not the artifact. It is the bet.
Lewis Gavin is the Head of Growth at easyfundraising. Paul Johns is co-founder of Else, a prototyping tool for product teams. Lewis is an Else design partner.
The competitive scorecard referenced above is maintained at Else. Twenty-five products, five dimensions, last refreshed 2026-05-12.
A version of this piece was first published on Lewis Gavin’s Substack.