What digital photography can tell us about managing the AI-infused product development lifecycle

For a while, my tech brainworm has been the idea of ‘the perfect AI software development lifecycle (SDLC) (opens in new tab)’. The pursuit of designing a software development pipeline as autonomous as possible, using tooling to multiply the effectiveness of development teams. It’s what Anthropic call the “AI-native SDLC” (opens in new tab). Yet something feels amiss in this take. The language tends to leave out those business stakeholders that don’t traditionally consider themselves part of that lifecycle: product owners, testers, and product owners. The SDLC is about getting from an idea to working code. The product development lifecycle (PDLC) is wider, focusing on what to build in the first place, and whether it actually helped anyone (opens in new tab). So while we may have faster code, the bottleneck has moved - and so must our focus.

The oldest surviving photograph, View from the Window at Le Gras (opens in new tab), was created in the summer of 1827 by French inventor Nicéphore Niépce. By coating a pewter plate with bitumen and exposing it for many hours (quite possibly days), the photo gradually took shape. The point being, with one shot and days of waiting, Niépce had to think quite hard about where to point his camera.

Over the next 150 years, film photography improved. More exposures fit on a roll of film, but the core economics stayed the same; results still took time to develop, and a miss was expensive.

The beginning of the end of film started in December 1975, when an engineer at Kodak built the first self-contained digital camera. (opens in new tab) This technology eventually revolutionised the photography industry. Today, shots cost nothing, and you can view the results instantly. Of course, this means that we take hundreds in an attempt to take the best one. Indeed, phone cameras now take ‘live photos’ where you can choose the exact frame you want.

This is exactly the frontier that we find ourselves at with building software. The build is no longer the time-consuming, delicate practice that it once was. The effort now needs to focus on when to press the shutter button, and which shot(s) to keep.

Shopify gave a neat example recently when they moved their mobile apps from React Native back to native Swift and Kotlin (opens in new tab). Their 2020 decision rested on the assumption that building twice meant the work. Coding agents broke that assumption. This shift had nothing to do with code; it was a first-principles business decision. And they measure success by “better experiences for merchants and buyers”, not lines shipped.

At Softwire, we’re seeing the same behaviour with our clients. Their end users can now design and start building prototypes based on how they want to interact with software. The code comes quickly, but getting it safely into production and iterating on these initial ideas still takes time.

So if building is no longer the hard part, where does the effort go? For me, it’s discovery and prioritisation: deciding which ideas are worth a shot in the first place, and which results are worth keeping.

This new focus is where the change really pays off. When a feature took months to build, every idea was an expensive bet. We’d spend weeks on business cases and estimates, pick a handful of ideas, and hope we’d chosen well. More often than not, we hadn’t. The DevOps Handbook (opens in new tab) quotes Ronny Kohavi at Microsoft, who found that of experiments designed to improve a key metric, “only about one-third were successful at improving the key metric”.

If two-thirds of our bets were always going to miss, the answer isn’t to agonise for longer over which one to place: it’s to place more. When a prototype takes a day or two, we can try three versions of an idea, put them in front of real users, and let the evidence decide. That’s the live photo: take the burst, then pick the frame.

But someone has to pick. Engineers can build the bets, but product owners, testers, operations teams, and end users know which ones are worth placing and which ones actually land. If they’re only brought in at the start to hand over requirements, or at the end to sign things off, we’ve bought a faster camera and kept the same handful of shots.

An AI SDLC is still the foundation. But I think the biggest gains will come from widening it into an AI-infused product development lifecycle: one where the people who own the problem are as much in the loop as the people writing the code.

Check out our guide on how AI is reshaping the SDLC (opens in new tab), and what it takes to get it right.