# 20260513 WTB X Article GPTPro v600 

Status: converted corpus source

Source file: `20260513 WTB X Article GPTPro v600 .docx`

This Markdown file is a mechanical conversion from the original DOCX source. Treat it as source material, not polished public text.

---

### Why Not Build This?

Over the last several months, it has become hard to miss that software building has changed. Agentic coding tools have moved from novelty to practical workflow. A builder can describe what they want, inspect what comes back, revise the direction, and keep moving. Engineering does not disappear, and judgment still matters. But the effort required to get from an idea to working software has fallen enough that the shape of the work changes.

That shift creates an obvious opportunity, and an obvious problem. If you can build more, more quickly, you can also spend more time building the wrong thing. Lowering the cost of execution does not answer the question of direction. It makes that question more important. When many more paths are open, the value of choosing well goes up.

So the agentic coding moment does not make ideas less important. It makes them more important. The relevant question is no longer only whether something can be built, or whether a small team can reach a working version. Increasingly, the question is: given that more can be built, what is worth building?

This essay offers one way to think about that question: how to look for ideas worth building in a moment when building itself has become easier.

### Outcome-Based Idea Space

I want to present one way to think about build ideas that may be more useful now because agentic coding has lowered the effort and cost of turning them into software.

The idea is to work from desired outcomes rather than from build ideas. More specifically, to focus on outcomes where the user realizes higher-order states in the systems sense.

***the individual life as a systems problem of maintained higher-order states.***

***what happens when digital systems become capable of participating directly in the maintenance of meaningful individual states?***

That is the part I want to focus on here—what it is about these outcomes that makes them useful for generating build ideas.

These outcomes are useful for generating build ideas because they require many things to happen over time. A user has to make decisions, take actions, get feedback, adjust, and keep participating. Each of those requirements can suggest something software might help with.

These outcomes are not all equally useful. They still have to matter—people have to care about them in a real way. I’ll use a simple way to evaluate that.

When they do, they tend to describe fuller outcomes that are durable enough to support more substantial build efforts.

And there are straightforward, practical ways to generate these outcome ideas. It is not as hard as it might sound. The methods in the rest of the paper are meant to make this easy to try.

These methods follow from something we already have: a way to model people moving from one state to another and what helps them get there. That is what story structure gives us.

That is the intent of this paper. In the context of what ideas may be viable now with agentic coding, I want to point to an existing space defined by higher-order states, lay out the concepts that make it useful, and show how to generate ideas within it. If this holds, it should be a practical way for builders to find and work with ideas in this moment.

None of this is new in itself. People already build parts of these outcomes. What is less common is treating the full outcome as the target, rather than the individual supports underneath it. Historically, that has been too large and messy to take on directly.

I use a single example throughout: personal (fashion) styling. It is simple, but it has all the characteristics of the type I’m describing.

### Story Structure as the Organizing Shape

I am trying to show a space of possible build ideas: fuller outcomes people want, especially outcomes that require higher-order states and where software has a good chance of helping.

To work with that space, I use classical story structure as the organizing shape. Story structure can be understood in many ways, but the part I need here is simple: it describes how actions over time lead from one state to another in a meaningful way.

Story structure is not arbitrary. It reflects how people make sense of problems and actions over time, and how that understanding leads to behavior.

I use that structure to model these fuller outcomes and to make them easier to see as targets for build ideas that may now be more practical to pursue directly with agentic coding.

Story structure is typically used to tell stories. Here, I use it instead to model actions we would like to see happen for others.

I’ll lay out the basic structure we need here. In the next sections, I’ll fill it in with the concepts that define the space of ideas I’m pointing to.

All stories can be reduced to a narrative series of events that starts with a complication and ends in its resolution. I’ll keep to just the basics here.

We usually anchor this on a person with a complication, because that is what we care about. We use that to understand and plan our own actions, and to understand and predict the actions of others.  This is why stories center on people.

The resolution is the point of the story. To the extent it is comprehensible, relevant, and impactful to the main character, it is meaningful, and we care about it.

The complication defines the starting state and what needs to change for the story to be complete, especially for how we are using it to model actions rather than tell stories.

The narrative series of events brings in time and actions over time. To the extent we care about the resolution, the causal steps matter. They show how the starting state changes into something better.

Finally, the theme is what the resolution is about. Here, it is about the outcome we want to see happen.

In the next sections, I’ll fill in each part of this structure with the concepts that define this space of ideas, so they can be seen as a coherent whole.

### Applying the Structure: A Simple Example

To make this concrete, I’ll use a single example throughout: personal fashion styling. It has the characteristics I’m trying to show, and I know it from experience. It is also ordinary enough that if this structure is visible there, it is likely visible in many other areas too.

First, personal styling means helping someone pull together what they wear so they look and feel beautiful for what they are getting dressed for. I’ll focus on women for this example, since that is where this is most commonly used. That is enough for this example.

Now I’ll lay this out using the story structure. This also shows how I’m using story structure to model actions we would like to see happen for others, which is the orientation needed for building.

I’ll start with the resolution at the level of the ultimate outcome. In this case, it is not a single styling session, but the ongoing result: she looks and feels beautiful every time she gets dressed.

Using our base definition of story structure—a narrative series of events that begins with a complication and ends in its resolution—the resolution here is that ultimate outcome.

The complication is not having achieved that outcome. The central character, our protagonist, is not the stylist—it is the person getting dressed. The structure is about that outcome happening for her.

Finally, the narrative series of events is the set of actions over time that lead to that ultimate outcome.

### Higher-Order States Create Build Surface

This section introduces higher-order states. They tend to align with fuller outcomes, and they help explain where software can be useful. I’ll show how they fit within the story structure as the kind of resolution we are looking for, and demonstrate that with the styling example.

I mean this in the systems sense: a higher-order state is a more complex level of organization that arises from the interaction of simpler parts. What matters here is that you get emergent properties—results that do not exist without the full state. These are not single actions, but conditions that only hold when many smaller things keep going right over time. They depend on decisions, actions, adjustments, feedback, and maintenance.

The reason they matter here is that they create rich surfaces for building. When an outcome depends on many coordinated pieces, there are many places where support can matter.

A builder can ask: what information needs to be organized, what decisions need to be made, what feedback is missing, what actions need to be coordinated, what changes over time, and where the person needs help adapting. Each of these can point toward something buildable.

Software can help organize information, guide decisions, track progress, make feedback clearer, coordinate actions, and help someone adapt as circumstances change. These states also tend to involve context, patterns, judgment, and repeated decisions over time, which is where data and AI fit naturally.

In our story structure, this is the kind of resolution we are looking for: a higher-order state. Not all such states are worth building toward, but they naturally align with the fuller outcomes we are targeting.

The styling example shows why this is a higher-order state. The target is not one good outfit. It is the ongoing condition where getting dressed goes well, and more specifically, where she looks and feels beautiful when she gets dressed. It depends on wardrobe, taste, body, context, occasion, feedback, and learning over time.

This also shows the build surface. Once the outcome is structured this way, there are many concrete points where software can help. For example: understanding what suits her, building a wardrobe, using what she already owns, deciding what to wear in a specific situation, shopping for missing pieces, or updating choices as her life changes.

These are only examples, but they illustrate the pattern: each part of the state defines a place where support can be built.

### Which Higher-Order States Matter?

Higher-order states create strong opportunities for building. But that is not enough. For an idea to be worth building, the state also has to matter to someone.

I’ll use a simple set of working criteria for what people care about here. Terms like interesting, meaningful, desirable, and “what matters” all point to the same idea.

I’ll use a simple set of criteria: a higher-order state should be legible, relevant, and consequential. These are subjective, but they give us a way to evaluate what matters and to reason about it.

In our story structure, the complication is the absence of the higher-order state. This gives us a simple way to compare the two states and evaluate them.

The styling example provides a simple demonstration. It is legible: looking and feeling beautiful every time she gets dressed is a clear and understandable condition. It is relevant for many people because it concerns how they appear in their own bodies and how they present themselves in everyday life, as reflected in the size of related industries and the attention they receive. And it is consequential: it affects how she feels and how she shows up in a recurring part of life.

That combination is what makes the state useful for ideation: it gives the builder something to support, and gives the user a reason to care.

### The Path: Action and Participation

At this point, we have characterized the target: a meaningful higher-order state that functions as the resolution in our story structure. Higher-order states create opportunities for software because they depend on simpler parts interacting well. If the state depends on those interactions, software may be useful in helping them happen.

This fits into our story structure as the narrative series of events. It may sound like a linear sequence, but in this case—where the story is meant to happen rather than be told—it is messier than that. What matters is that the actions unfold over time.

With this kind of outcome, the setup is large enough that it can only happen over time. In practice, that means many smaller actions, each of which is only a partial contribution relative to the whole. The benefit comes from how they accumulate. That creates both the coordination problem for the person and the opportunity for software to help.

This breaks into two areas where support can help: supporting the actions and supporting ongoing participation.

Supporting the actions means helping with the decisions, information, coordination, feedback, and adjustments that move the person forward. Each action may be loosely connected and of limited value on its own, but together they accumulate. Over time, the person makes decisions, gets feedback, adjusts, and gradually moves closer to the state.

The second area is supporting ongoing participation. The person has to stay with the process over time, which is a matter of agency: they have to keep choosing, noticing, acting, adjusting, and following through. If participation drops off, the state does not emerge or hold. The path can be uneven, with delayed feedback and unclear next steps. This creates another place where support can help.

The styling example shows both sides. To get dressed well over time, she has to make many concrete decisions: what to wear, what to buy, what to keep, what to change, what works for a specific context, and how her preferences are developing. Those are all places where action support could help.

She also has to remain engaged. She has to pay attention, learn from what works, tolerate failed attempts, build confidence, and keep updating the process as her life changes. Those are places where participation support could matter.

This is why the full target matters. Without it, the individual supports can look like scattered features. With it, they become parts of the same path.

### Outcome Ideas as the Unit of Design

The last few sections define the idea space this essay is about: ultimate outcomes that are meaningful higher-order states. By placing those outcomes inside story structure, we can see more than the outcome itself. We can see the fuller structure: what the user wants, what is missing, and what has to happen for the outcome to become more attainable.

There are two levels of ideas here. The first is the outcome idea: the fuller condition the user wants. The second is the concrete build idea: the tool, feature, or product that might help make that condition more attainable.

That distinction is familiar. Here, the outcome idea defines the space, and the concrete build ideas follow from it.

Two things about these ultimate outcomes matter here. First, they work as the primary unit of design. Because they are closer to the full thing the user actually wants, they are clearer and more coherent than partial targets.

And that same quality makes them generative. When the outcome is a higher-order state, it creates many possible paths for support, and therefore many possible build ideas.

Second, traditionally, these outcomes were too broad, messy, and large in scope to target directly. Builders could pursue concrete ideas underneath them, but the fuller outcome itself was usually too much to take on.

In the styling example, the idea of “getting dressed to go well every time” is clearly meaningful and generative, but it would traditionally be too broad to take on directly.

This is really the point for ideas in this paper. The outcome-level structure already exists, and it is highly generative. What may be different now is that it could be practical to build toward the full target directly with agentic coding.

### Agentic Coding and Building Toward the Full Target

Agentic coding does not remove the difficulty of the full target. It changes the tradeoff. If building and revision are faster and cheaper, it becomes more practical to treat the ultimate outcome as the target and build toward it one support at a time.

The approach itself is not new. It is the familiar pattern of incremental, iterative development and discovery. What changes is how far that approach can be applied.

First is speed and capability. You can build and revise much more quickly, which makes more ambitious ideas practical to try.

Second is cost. You can do more with fewer resources, which increases how much you can try and how much you can produce before needing scale.

If the target is the ultimate outcome, each build idea sits inside a larger, coherent goal. It is not just a standalone feature, but part of something the user already has reason to care about.  That can make it more meaningful and more viable.

With the ultimate outcome as the unit of design, the build ideas sit inside a shared direction rather than standing alone. Agentic coding makes it easier to try them. You can build one support, put it in front of users, learn from what happens, and then build the next one. The work stays incremental and iterative, but it can now be applied against a larger, more coherent target.

As the cost of code comes down, this may look closer to how creators learn by publishing and adjusting, except the signal is not only attention. It is whether a support helps the user move closer to the outcome.

In styling, that might mean starting with wardrobe intake, or outfit generation, or help deciding what to wear for a specific context. Each one is a real build idea, not the whole target. But if the target is getting dressed going well every time, each support can be built, tested, and improved in relation to the larger outcome.

### Media and Audience Around the Outcome

Agentic coding makes it easier to build toward the full target, but the full target also gives you something to make media about, and that media can make the effort more viable.

If the target is an ultimate outcome people care about, that same outcome can also organize media. Media can validate the outcome, build distribution around it, and create a better environment for iterative development.

This is where the story structure matters again. We have already framed the ultimate outcome as a story meant to happen for others: a person starts outside the desired state, moves through actions over time, and reaches a resolution that matters. That same structure can also organize media. The creative is not just about the product. It can be about the desired outcome, the obstacles, the actions, the progress, and the resolution people want.

First, media can help validate the ultimate outcome. It is usually easier for someone to engage with a piece of media than to try a piece of software, so the hurdle is lower. If the media is organized around the same outcome, the response gives you signal on whether people care, who cares, and what parts of the outcome resonate. For idea generation, that matters because it gives you a faster way to test whether the target is worth building toward.

Second, media can build distribution. An audience gathered around the same ultimate outcome becomes natural distribution for whatever you build to support it. You are offering a way to make progress on something they already care about.

Third, it creates a better build environment. An audience gathered around the ultimate outcome gives you a direct connection to people who care about it. That makes it easier to test ideas, get feedback, and iterate in context. The work becomes a dialogue: you are building supports for something the audience has already shown they want.

#### The Styling Example: Viability and Monetization

In the styling example, this is easy to imagine because the creator side already exists. There are already personal styling and fashion creators with large audiences, clear expertise, and businesses built around helping people dress better. They are already making media around the outcome.

For a creator like that, audience is not theoretical. It validates demand, creates distribution, and may already support the business financially. Agentic coding could make it more practical for that creator to build software supports around the same outcome: wardrobe intake, outfit generation, context-specific recommendations, shopping help, or preference learning.

The same logic can apply to larger companies in the space. A retailer, brand, or women’s apparel business may already have customers, data, merchandising expertise, and media reach. If the outcome is valuable enough for a creator to build around, it is also a serious strategic target for incumbents.

### Projection: From Build Idea to Outcome

If the essay defines this outcome-based idea space, how do you actually find ideas inside it?

One claim I want to make directly is that you can do this with very simple reasoning. I’ll start with a straightforward tool I’ll call projection.

In practice, people usually start with concrete build ideas rather than with fuller outcomes. From there, you can take a concrete idea and project it to the higher-order state it would support.

That does not mean the resulting outcome is especially interesting or worth building toward. Projection does not pre-screen for a strong higher-order state or for meaning. It simply maps a concrete idea to the fuller outcome it would support.

This is close to the familiar idea from storytelling of raising the stakes. In our structure, the stakes are the difference between the absence of the outcome and realizing it. Projection is just taking that idea to its natural limit: what is the fullest version of that outcome?

For a given build idea, you can ask: if a user had the fullest and best use of this idea over time, what would be the ultimate desired outcome?

Or more simply: what part of life would be going well if this worked completely?

Once you have the projected outcome, you can evaluate it with the concepts already introduced. First, look at the structure: how much coordination and ongoing activity it requires, and what that implies for support. Second, look at how much it seems to matter: is it legible, relevant, and consequential?

In the styling example, take something concrete like an AI outfit generator. If you project it, the question becomes: if a user had the fullest and best use of this over time, what would be the ultimate desired outcome?

The answer is not just generating better outfits. It is the ongoing condition where getting dressed goes well, and more specifically, where she looks and feels beautiful every time she gets dressed.

From there, you can evaluate it. Structurally, it depends on many coordinated elements—wardrobe, context, preferences, feedback—which creates many places for support. And in terms of meaning, it is legible, relevant, and consequential.

The point is that you can just do this. It does not require specialized methods or extended practice. You can apply it directly to any particular idea you already have and see what they point to.

### Generating Outcome Ideas with Projection

Projection starts with a concrete build idea and works upward to the fuller outcome it supports.

But a builder may not have a specific idea to start from. They may just want to find outcome ideas worth exploring. Here are a few direct ways to get started.

First, you can try to think of these outcomes directly. That can be harder than it sounds. It is usually more natural to start from concrete build ideas. But if you can think at the outcome level directly, that’s great—do that.

You can also use projection without starting from your own idea. If you have an area you care about, take any existing product or service in it and project it. Ask what fuller outcome it would support if it worked completely. This makes it easy to explore related higher-order states and see which ones might be worth pursuing.

This is not limited to software. You can project goods and services in the same way.

Another useful source is the creator space. Creators are often organized around the value they try to provide. You can treat that “value” as the starting point and project it to a fuller outcome. This can surface outcome ideas that are less obvious from existing products.

In practice, this is something you can play with. You can do it quickly and repeatedly, trying different starting points and seeing what outcomes they suggest.

It is also the kind of task that could be extended with LLMs. You could take a set of existing products, services, or creator ideas and systematically project them to map out a space of related outcomes.

The point is that, with the story structure in place, there are direct and relatively frictionless ways to generate many of these outcome ideas. That does not mean they are all strong candidates, but we’ve already covered how to evaluate them.

### What This Points Toward

The starting question was what to do with the new ability to build more. If agentic coding makes it easier to get from idea to working software, then the quality of the idea matters more. Not every buildable thing is worth building.

The answer I’ve tried to develop here is one way to look for ideas worth building: find higher-order states that matter. Look for conditions where some part of life could go better, where that better state requires many actions over time, and where the person has reason to care about reaching it.

That kind of target creates a different kind of idea space. The ideas are not just isolated features. They are possible supports for a fuller condition. The full success condition gives them coherence. It lets you ask what should become true in the person’s life, and then reason backward into what could be built to help make that condition more attainable.

That does not mean building the whole condition at once. The practical path is incremental. Define the condition, build one support, learn from use, adjust, and continue. Media can help test whether people care about the condition and gather an audience around it. Story structure and projection can help move from concrete ideas to the fuller outcomes they might serve.

None of this depends on the claim that this is the only way to think about building. It is a lens. It starts from familiar things: people care about parts of life going well; some outcomes require many actions over time; people need support to stay with those actions; and a movement from problem to resolution can be modeled clearly enough to work with.

The opportunity is not just to build more features. It is to look for fuller, messier, more consequential conditions that may now be more practical to build toward. In a moment when more software can be made, that seems like a useful place to look.