This Is Software’s iPhone Moment

In 2007, humans took roughly 85 billion photos a year. Photography was a specialized craft that required expensive equipment, years of practice, and lots of time. Then the iPhone came out. Today in 2026, humans take roughly 2.1 trillion photos per year, a 25x increase. A single company, Instagram, is now worth 5x more than the entire global photography market combined back then.

The vast majority of photos today aren't taken by photographers anymore either. They're taken by people like you and me on the phones in our pockets. For us, photography isn't our craft — it's a reflex. You probably don't think twice about the 10 photos per day you snap on average. It's an everyday skill we've developed as a result of the radical democratization of the technology. This explosion of photography post-iPhone is one of the most concrete examples we have of "Jevons Paradox". When technology makes things cheaper and more abundant, our overall consumption counterintuitively increases.

Are there still photographers in the world in 2026? Absolutely. In fact, despite many eerily familiar doom-and-gloom predictions, the number of professional photographers worldwide has remained remarkably consistent for decades. We still hire them for life's biggest moments. Conferences, weddings, graduations. We probably always will too. When the game is on the line, you want the expert on your team.

The same way that the iPhone transformed photography, AI is transforming software now. The 40 million software engineers in the world today will quickly be dwarfed by the billion "software creators" coming online tomorrow. We have an opportunity to learn from the past in order to predict the future of our industry.

The Future of Software Is Hyper-Personalized and Disposable

The software of the future will look drastically different from the high-stakes production software of today. Most software will be hyper-personalized and entirely disposable. Rather than worrying about scaling to millions of users, this software will often have a user base of one. It will solve an immediate problem and may very well never run again.

We're still in the earliest days of this transformation. In the same way that it would be hard to imagine social media as the future of the web looking at the web portals of the 1990s, it's impossible to imagine the new interaction paradigms that AI-generated code will enable once the technology matures. It's tempting to see AI as a cheaper way to build the software we already have. It misses the point. The iPhone wasn't a cheaper camera. It gave us the selfie, the story, the photo sent instead of a text. Cheap, abundant software won't just let us do the same things for less. It'll let us do things that never made sense to build before. Whatever it looks like, it'll have exponentially more software in it than today.

So how do you know what to build? In a world where code is effectively free, the three things that matter are your ideas, taste, and distribution. How do you know what problem to solve, what good looks like, and how to get it into users' hands? When you're writing software for yourself, you implicitly have the answers. You're the world's leading expert on your own problems, you know what a useful solution looks like, and you're the only person you need to convince to use it. For these throwaway tools, scalability and technical debt stop mattering. As long as the agent has the spec, you can throw it away and rebuild it tomorrow.

DevRel Is Dead. Long Live DevRel.

For 30 years, DevRel has been about one thing: winning the hearts and minds of the engineers who make technology decisions. You write the docs, give the talks, build the sample apps, answer the Stack Overflow questions – all so that when an engineer reaches for a database or an API, they reach for yours. It works because engineers have opinions about their stack, and they defend them. That model breaks in a world of disposable, hyper-personalized software built by nonengineers. The person describing the app they want has no idea whether it's running Postgres or MongoDB, and more importantly, they don't want to know. They'll delegate every one of those decisions to an agent and never think about them again. The developer we spent 30 years courting is being replaced by someone who will never read your docs. DevRel is dead.

Except it's not. It just got bigger. The audience isn't shrinking from 40 million engineers — it's exploding to a billion creators and the agents acting for them. When the volume of software written goes up 1,000x, becoming the default tool is one of the most valuable growth functions in tech. The question is no longer "How do I get this engineer to choose me?" It's "How do I become the default an agent reaches for?"

We don't have the playbook for that yet. Docs traffic, conference booths, workshop signups — all of it was built for humans who read and decide. We need new business models and new ways to think about ROI when your most important customer isn't a person at all, but an agent acting for a million of them. Whoever earns that default will own distribution in the next era of software. Long live DevRel.

The Camera in Everyone's Pocket

We've seen this movie before. The iPhone didn't end photography — it just put a camera in everyone's pocket and changed what photography was for. The professionals are still here, still booked for the moments that matter. But the trillions of photos we take every year aren't theirs. They're ours.

Software is having that same moment right now. The 40 million engineers won't disappear any more than the photographers did. We'll still want the experts when the game is on the line, for the systems that have to scale, stay secure, and not go down. But everything else — the quick fix, the personal tool, the app with a user base of one — is about to belong to everyone.

The people in this room get to decide what that world looks like. We're the ones who'll build the tools, set the defaults, and write the playbook nobody has yet. Photography took 20 years to become a reflex. Software is going to be faster. The only question is whether you're documenting the change or driving it.