The Ability to Define Problems: Setting the Ceiling on What You Create

A question has troubled me for a long time. If everyone uses roughly the same level of AI, where does differentiation come from? How do you stand out, and where does your unique value lie?

“Taste” is one common answer. But taste comes from years of accumulation; it neither guides our daily hands-on work nor can it be improved overnight. After all, merely chanting the word “taste” will not make our work any better.

Recently, reading about the practices of top practitioners and a blog post by Thariq (former Anthropic engineer), a new answer began to take shape: the ability to define problems.

---

1. The Mathematician’s Answer

This idea actually migrates over from mathematics. Lately, mathematicians seem just as unsettled as programmers did a few years back. When the deduction and theorem-proving abilities they pride themselves on get surpassed by AI, what is left for mathematicians to do?

In his video, 3Blue1Brown broke mathematicians’ work down into several parts: proving theorems, asking questions, theory building, and applying theory. Among the work that remains uniquely human, one crucial part is asking questions—or put another way:

Even if large models can prove conjectures, they are not yet adept at posing new conjectures and questions that propel a field forward.

And as I realized, this answer is by no means limited to mathematics.

---

2. Prompt Engineering

When ChatGPT first emerged, a new field called Prompt Engineering sprang up. It sought to design better prompts to yield better outputs from AI. Back then, models were weaker, so people created formulaic prompt structures to help AI understand human intent. As models grew more capable, that particular need largely dissolved.

Yet I believe the field remains deeply valuable, because writing a prompt is essentially defining a problem for AI—getting AI to solve problems within a framework you establish. How well the problem is defined largely determines the quality of what AI produces. Defining clear problems for AI is the core topic I want to explore today.

However—

Because the ability to write prompts is not a transferable skill.

By that, I mean it is unlike learning to ride a bicycle. Once you learn to ride a bike, you never forget how. But being able to write brilliant prompts in scientific research does not mean you can write great prompts in graphic design.

Writing prompts depends fundamentally on domain background knowledge. You can craft effective prompts for research because you understand the steps, objectives, and standards of scientific inquiry. If you lack background knowledge in typography and graphic layout, no amount of prompt engineering theory will let you write good prompts for design.

Domain knowledge is the deciding factor in defining problems well for AI.

Let me share two examples.

Example 1: Making AI Output More Readable

Andrej Karpathy once shared how he gets AI to produce much more readable text. Reading his post was an eye-opener.

Most people have had the experience of AI “not speaking like a human.” Even though it uses human words, the sentences feel impossible to parse. When this happens, most people tell the AI: “I didn’t understand,” and the AI replies with a different, but equally unnatural explanation.

Slightly more advanced users might say: “Explain it like I’m a 3-year-old,” or “Explain it like I know nothing.” That is already an improvement over “I didn’t understand,” because it tries to describe the condition. But it is still too vague.

Karpathy, however, told the AI to explain things “80% of the way to ASD-STE100.”

ASD-STE100 is a controlled language specification originally developed for aerospace maintenance documentation, designed to make technical manuals clear and unambiguous. It has strict rules: each word has only one meaning, and procedural sentences must not exceed 20 words. Just like that, the problem of making AI output readable was defined with precision. This works by borrowing proven standards and collective wisdom. But if you never knew the standard existed, you could never write that prompt.

I added this guideline to my global AGENTS.md, and the results have been remarkable.

Example 2: How to Define a “Good Video”

Another example: Karpathy recently built HackerTube (hackertube.org), a site that surfaces high-quality YouTube videos, filters out low-effort noise, and puts you in control of recommendations.

The implementation was straightforward, but what actually makes a video “good”?

If you simply ask the model to “filter videos you think are good,” you end up with mediocre, average tastes. Karpathy instead tapped into twenty years of Hacker News community curation: he had Claude read through the entire archive of HN comments, retaining only videos recommended by at least 3 people across at least 3 different months, and evaluating whether each comment was recommending, citing, or mocking the video. In the end, it narrowed down to 6,454 videos.

The fuzzy idea of a “good video” was thus transformed into a clear, executable standard.

This logic extends widely—such as training models. Where do you find datasets for reinforcement learning? How do you design rewards? The difficult part is not iterative tuning, but defining a crisp problem right from the outset. In many ways, this is also the essence of loop engineering: designing closed loops where AI iterates, inspects, and corrects itself, rather than having a human rewrite prompts round after round.

---

3. How to Improve Your Ability to Define Problems?

Seeing these examples, you might ask: How can I improve my own ability to formulate problems?

Defining a problem is fundamentally modeling the unknown. A blog post by Thariq^[1] provided great clarity on this.

He opened with an apt metaphor: the map and the terrain.

The map is what we hand to AI: prompts, skills, and context. The terrain is where the real work happens: codebases, the real world, and practical constraints. On a map, paths are straight lines; in reality, you detour around obstacles. The gap between them is what he calls “unknowns.”

Whenever AI hits an unknown, it must guess your intent. The bigger the task, the more unknowns it encounters. He even noted that Claude Fable was the first model that made him realize “the bottleneck in output quality was whether I could clearly articulate the unknowns.”

What kinds of unknowns are there? He divided them into four categories:

• Known Knowns: What is already in your prompt—what you explicitly tell the agent you want.
• Known Unknowns: What you haven’t figured out yet, and know you haven’t.
• Unknown Knowns: Things so obvious to you that you never wrote them down, but you would recognize them immediately upon seeing them.
• Unknown Unknowns: Things you never considered—knowledge you did not even know existed. Do you know how good something can actually be?

Unknown Unknowns are the most critical: they set the upper limit on how you define problems. If you didn’t know a concise, readable language standard already existed (ASD-STE100), you couldn’t use it to define the problem.

Such knowledge doesn’t come out of thin air. But we can deliberately converse with AI first to fill in our gaps. Here are several approaches:

1. Blind Spot Pass

Entering an unfamiliar domain, the hardest part is often not knowing what to ask. Don’t rush into assigning tasks; ask AI to identify your blind spots (Unknown Unknowns) first.

When Thariq was editing the Fable launch video, he noticed the footage looked flat and knew it needed color grading, but knew nothing about the craft. Instead of asking Claude to generate arbitrary versions he couldn’t evaluate, he first had Claude teach him the fundamentals.

2. Brainstorms and Prototypes

Some requirements (like visual design) are hard to express in words, but obvious once you see them. Instead of struggling for words, have AI build several distinct prototypes to inspect. Having AI write a single-file HTML prototype takes minutes, whereas rebuilding after full development is costly.

3. Interviews

Once the broad direction is set, many details remain unclear. Turn the table and ask AI to interview you. Set two constraints: one question at a time, and prioritize high-stakes architectural questions first.

Beyond these, Thariq also discussed using references and implementation plans in his post (link below).

---

Conclusion

Taking time to acquire the relevant background might look like it slows down initial progress. In practice, it drastically cuts down rework and raises the ceiling on what you can achieve. As Thariq put it: every explainer, brainstorm, interview, and prototype is a low-cost discovery of things you didn’t know before they become expensive.

Returning to the question that bothered me at the start: When everyone has access to the same level of AI, where does differentiation lie? My answer is: whoever defines the problem most clearly.

This is my recent takeaway—I hope it sparks something useful for you!