

In Part 1, I argued that AI made custom software economically viable. Tools can finally learn clients instead of clients learning tools. But I ended with a question. If AI handles the building, what's left for humans? The answer: figuring out what to build. And that's harder than it sounds.
A few years ago I went to a physical therapist for ankle and knee pain. I expected him to work on my ankle and knee. Instead, after his assessment, he told me the problem was my IT band. The tightness there was creating strain down my leg. The fix wasn't treating where it hurt. It was hip mobilization and strengthening exercises. He'd found the actual problem, not the stated one. That's the job of a Solution Architect now. Clients come in describing their pain. "We need to automate our transportation requests." "We want to build a kiosk." Those are symptoms. The job is to find what's actually causing them.
A client wanted to automate transportation requests to hauling agencies. When a shipment was ready, an AI agent would contact haulers and arrange pickup. As we worked through the architecture, something surfaced. By the time the transportation request would trigger in their current process, it was already too late. Haulers were being contacted with insufficient lead time. Higher costs, lower reliability.
The interesting problem wasn't "automate the request." It was "when should the request trigger in the first place?" That's a business process question. It required understanding their operations, their relationships with haulers, their inventory patterns. We weren't just automating anymore. We were redesigning when a key decision happened. We could have built exactly what they asked for. It would have worked. It would have automated a broken process faster.
A client kept returning to an idea: a kiosk avatar solution. Every time we steered elsewhere, we circled back. The ROI was minimal. By any objective analysis, not the highest-value solution. But the energy in the room changed when they talked about it. There was excitement. Ownership. So I stopped trying to talk them out of it. What I uncovered: this solution had emotional and political value. They needed something visible to champion internally. Something that demonstrated progress on their digital transformation initiative. Was it the highest ROI? No. Was it right for this client at this moment? Yes. A pure ROI analysis would have killed this project. Sometimes value doesn't show up in spreadsheets.
In both stories, the client said one thing and needed something else. Here's what's counterintuitive. The structure of human conversation is what makes discovery work. When clients explain their problem to another person, they have to prioritize. You can only say one thing at a time. What comes first? What gets emphasized? That act of prioritizing reveals what actually matters. When I ask a clarifying question or push back, they have to re-articulate. They find new words for the same idea, or realize the idea wasn't quite right. The back-and-forth forces clearer thinking.
AI didn't eliminate the human bottleneck. It moved it upstream. Building used to be the constraint. Companies settled for generic tools because custom was unaffordable. The question was: can we build it? Now the question is: do we know what to build? That's where the value sits. Finding the knot the client didn't know they had. But discovery doesn't end when building begins. That's Part 3.

