Back in May 2026, our team at Metalab spoke at Web Summit in Vancouver, following up on our 2025 talk, “From Prompt to Product”. Humbling to revisit our old predictions and find them dated. Learning nothing, we got back up and did it again.
You can watch the entire talk here.
If there’s one aspect that has played out more than expected, it’s the shift in developer roles and responsibilities. Paul Straw shared the following predictions during his segment, contrasting the previous software development lifecycle we all occupied with his current observations (you can watch him explain this here):
Then:
- Small code volume
- Developers manually writing every line
- Separate QA team focusing on integration
Now:
- Large code volume
- More team members contributing code
- Developers focusing on code quality, review, and automated integration
We’ve seen instances of a single developer reviewing 10 PRs from designers who have little traditional coding experience, but valuable product acumen. We’re not alone in this — half the designers surveyed in the AI in Design Report 2026 say they’ve shipped code to production. Lots of ink has already been spilled on the Jevons paradox — make something cheaper to produce and you get more of it, not less. The current state of the App Store is a good example of this phenomenon.
Some of the work we’ve been confronting hasn’t even been scoped accurately — but it’s just as easy (if not efficient, we’ll come to that) to close two or three of these PRs as not relevant or needed. There’s very little emotional or practical attachment to the work. Simon Willison builds three versions of every feature and throws two away. Code is cheap now (if it was ever the most expensive part — I’m not entirely convinced).
Now that code generation doesn’t have to be a manual process, or done by developers at all, there’s simply a lot more of it. That means review and validation are more important than ever. Your review speed decides how many PRs you can trust. So things like preview deployments, and circulating changes with other humans before they’re merged, are coming back to the forefront.
A source of truth for code quality and review is becoming more important than ever.
This way of working rests on code being cheap to generate. If inference costs climb — or the subsidized pricing era ends — throwing away two of every three PRs stops being a rounding error and starts being a line item.
The workflow follows the economics. As long as code stays cheap, the developer’s job is deciding what deserves to exist — and the moment it stops being cheap, we’ll write a very different post.
After all, that’s how we got this post.