Something I've been circling around as I build Qupi with AI is a question about where I actually add value in the process. Claude Code is genuinely impressive at implementation -- give it a well-defined task and it figures out the how with a competence that still surprises me. So what is it that I'm actually contributing beyond pointing it in a direction and reviewing what it produces?
The more I've sat with that question, the more I think the answer is: the why and the what. Not the how. And I've come to think that's not a modest or consolation-prize kind of contribution -- it's actually the harder and more important work. These are my thoughts on why that is, and what it means for how I work with AI.
Note: this document is a companion to the multi-agent loop deep-dive. A lot of what's discussed here explains the reasoning behind the thinking/building split described there -- specifically why the product advisor setup exists and what it actually needs to do.
The Why, What, and How of Building Software
Breaking It Down
Every piece of software that gets built involves three distinct kinds of decisions, and they operate at different levels:
The business reason. What problem exists, who has it, why solving it matters, and why now. This is strategy -- it requires understanding users, context, and priorities.
The feature or solution. What specifically gets built to address the why. This requires judgment about scope, trade-offs, and what 'good enough' looks like.
The implementation. The code, architecture, and technical decisions that turn the what into working software. This is where AI coding agents genuinely shine.
Where Agents Are Strong
AI coding agents are, in my experience, remarkably capable at the how. Give Claude Code a clear, well-scoped task and it will figure out implementation approach, handle edge cases, write tests, suggest better patterns than I would have reached for on my own, and iterate when something doesn't work. The how has largely been solved, at least for the kinds of work I'm doing.
This is a function of what agents are built from. They've been trained on enormous amounts of code, documentation, and technical discussion. They've effectively seen how thousands of similar problems have been solved before. When you hand them a clearly defined task, they're drawing on a deep well of patterns.
Where Agents Are Not Strong
The why and the what are a different story. These require something agents fundamentally don't have: accumulated context about your specific users, your product history, your business priorities, and the judgment that builds up from living with a problem over time.
An agent starting a new session has no memory of what you learned from the last feature you shipped. It doesn't know which user complaints have been nagging at you, or why you tried something six months ago and abandoned it, or what the one thing is that would make the product genuinely useful for the people you're building it for. That context doesn't build up in the agent over time -- it lives in you.
Agents are strong at figuring out how to build something once you've decided what and why. They should not be relied on to generate the what or supply the why -- not because they're unwilling, but because they don't have the context to do it well.
The Subtle Risk: Confident Without Context
Here's the part that took me a while to see clearly. If you ask an AI agent why a particular feature matters, it will give you an answer. It will probably give you a pretty good-sounding answer -- logical, structured, plausible. The problem is that answer is constructed from general patterns about what tends to matter in software products, not from actual knowledge of your users or your specific situation.
Agents are not well-calibrated about the limits of their own context. They don't typically say 'I don't have enough information about your users to answer that.' They reason from what they have -- which is a lot of general knowledge and whatever you've told them in the current session -- and produce something that sounds authoritative.
The practical risk is that you can end up in a loop where the agent is helping you build things, and when you ask it whether those things are the right things to build, it tells you yes with a confidence that isn't warranted. The feedback loop closes around the how without anyone really pressure-testing the why.
I've caught myself doing this with Qupi -- asking Claude whether a particular feature makes sense and taking the answer more seriously than I should have, because it sounded thoughtful. The better question to ask is: does this feature make sense given what I know about the people I'm actually trying to help? That's a question only I can really answer.
Worth keeping in mind: Agents can be genuinely useful as thinking partners for pressure-testing your reasoning about the why and what. But the judgment itself has to stay with you. An agent engaging confidently with a strategic question is not the same as an agent that has the context to answer it well.
What This Means for How You Work
The Human Role Is Not the Bottleneck
There's a temptation, when you're working with a capable AI coding agent, to feel like you're the slow part of the process. The agent can implement faster than you can think through what to build next. It can write tests while you're still reading the output. It can suggest architecture changes while you're still figuring out whether the feature worked.
But I've started to think that framing is wrong. The human isn't the bottleneck -- the human is the source of the only inputs that give the whole process direction. Without a clear why, you end up with a codebase full of features that don't add up to anything coherent. Without a considered what, you end up building the easy things rather than the right things. The agent's speed is only valuable if it's pointed at something worth building.
What You Actually Need to Bring
This has shifted how I think about my own preparation before a development session. The work that matters most isn't getting my development environment set up or knowing exactly which files to touch. It's being clear on the why and the what before I hand anything to an agent.
In practice, that means being able to answer questions like:
- Who specifically is this for, and what problem does it solve for them?
- Why is this the right thing to build now, given everything else I could be working on?
- What does 'done well' look like -- not just technically, but from the user's perspective?
- What have I tried before that didn't work, and why?
- What am I not building, and why am I making that choice?
These aren't questions an agent can answer on your behalf. They're also not questions you can skip and make up for later with better prompting. They're the foundation the whole thing rests on.
The Product Advisor Setup -- and Its Limits
What It's For
In the multi-agent deep-dive, I described running a Claude project configured as a product advisor for Qupi alongside Claude Code. The idea is that the product advisor holds the why and helps shape the what, while Claude Code handles the how. Thinking in one window, building in another.
That split is genuinely useful. Having a dedicated space for strategic thinking -- separate from the implementation context -- makes both the thinking and the building cleaner. But working through the why/what/how distinction has made me realize that the product advisor setup only works well if you take seriously what it actually requires.
The Problem With a Thin Setup
A Claude project with a brief system prompt and a few notes isn't really holding the why. It's holding a sketch of it. The reasoning, the user context, the history of what's been tried -- most of that is still sitting in my head, getting applied inconsistently from session to session depending on how much I remember to share.
If the product advisor's job is to be the place where the what and why live, then it needs to actually have them. Which means two things:
- Richer context, deliberately built: Who the users are. What problems have been validated. What's been tried and abandoned and why. What the current strategic bets are. The kind of thing a good product brief captures -- not as a one-time setup, but as a living document that gets updated as the product evolves.
- Active human judgment in every session: Not loading context once and trusting the advisor to reason from it, but regularly pushing back on what it surfaces, updating it when thinking shifts, and treating it as a thinking partner rather than an oracle. The advisor extends and externalizes your judgment -- but only if your judgment is actually in there.
The product advisor isn't a tool you configure -- it's a practice you maintain. The value it provides is proportional to the quality and currency of the context you've put into it, and the quality of the judgment you bring to each session.
What This Means for Qupi Specifically
Honestly, my current product advisor setup for Qupi is closer to the thin version than the rich one. I've been relying on it more as a sounding board than as a genuine repository of product context. That's useful, but it's not the same thing as having the why and what properly documented and consistently applied.
What would make it better: a more deliberate product brief living in the project -- the core user problem, the key decisions I've made and why, what I've ruled out, where I think the value actually is. Not a formal document for its own sake, but a working artifact that means I'm not reconstructing the same strategic context from scratch every session. That's what I'm working on building out now.
A Broader Lens: Beyond Software
Everything above is grounded in the software development context, and I think it holds there. But it's hard not to notice that the why/what/how distinction probably extends further.
In most knowledge work, the how is increasingly something AI can handle competently -- writing a first draft, analyzing data, structuring an argument, generating options. The bottleneck is shifting toward the judgment calls that require context AI doesn't have: understanding what a particular audience actually needs, knowing which of several good options is right given the organization's history, sensing when something technically correct is strategically wrong.
The risk in any of these domains is the same as in software: that the fluency and confidence of AI outputs makes it easy to skip past the harder questions about whether you're doing the right thing, not just doing things well. The how can be so smooth that the why gets glossed over.
I don't think the answer is to be more guarded about using AI -- the capability is too valuable to hold at arm's length. I think the answer is to be more deliberate about where you put your own thinking. The how is increasingly handled. The why and what are increasingly yours.