AI products improve through repeated observation and iteration because their behavior cannot be fully defined in a PRD before launch.
2
Offline evals and language-model judges miss many real-world problems, so teams need explicit and implicit signals tied to user intent.
3
Oleve's Trellis framework turns open-ended AI behavior into prioritized, semi-deterministic workflows that can be refined independently.
Summary
Ben Hylak argues that AI products have to be shipped before their full behavior can be understood. Communication remains difficult even as models improve, and greater capability creates more edge cases, especially when products connect to other tools. He is skeptical that evals can tell a team how good its product is. Offline evals mostly cover known problems, while language-model judges and production versions of offline evals can be expensive, narrow, and unreliable. Raindrop instead looks for explicit and implicit signals, such as copying, regenerating, errors, refusals, task failure, and user frustration, then connects those signals to user intent. Sid Bendre describes Oleve's Trellis framework. It starts with an MVP, classifies real usage into intents, converts intents into semi-deterministic workflows, prioritizes them by business impact, and recursively examines failures. The aim is to keep the useful unpredictability of AI while making improvements measurable and contained.
AI products have to be defined through use because their behavior cannot be specified upfront
Ben Hylak says teams can no longer write a PRD that captures everything an AI product should do. The product has to be shipped, observed, and refined. More capable models create more undefined behavior and edge cases, especially when the product integrates with other tools through systems such as MCP. He compares this with ordinary human communication: a partner or new hire can misunderstand an instruction even with shared language, and a model has much less context. Some technical problems will become easier, such as asking an API for a specific JSON schema, but deciding what the product should do remains difficult.
Offline evals measure known cases and cannot tell a team how good its product is
Hylak rejects the idea that evals provide a complete score for product quality. The collected examples usually describe problems the team already knows about, so they are easy to saturate. He points to recent model launches that performed worse on existing evals while working better in real use. He is also skeptical of using a language model to judge subjective outputs such as how funny a generated joke is. The strongest companies, in his view, rely more on highly curated datasets and autogradable evals, where a deterministic check can decide whether the output passed.
AI products need signals connected to user intent rather than a single error count
In a conventional tool such as Sentry, an issue has a concrete error plus counts for occurrences and affected users. AI products often have no thrown exception, so Hylak recommends tracking signals that indicate product performance. Explicit signals include thumbs-up and thumbs-down feedback, copied text, regenerated responses, syntax errors, sharing, and user corrections. Implicit signals come from detecting refusals, task failure, or frustration. A signal only becomes useful when paired with intent, because the same behavior can mean different things depending on what the user was trying to accomplish.
Teams improve AI behavior by exploring signal patterns and defining new issues
Hylak describes an ongoing loop for working with AI product data. Teams define signals, explore them through properties, models, keywords, and intents, then refine the definitions as new patterns appear. For example, a cluster of frustrated users might be associated with attempts to search for tweets. Raindrop uses user judgments such as correct and wrong search results to improve search quality. Hylak recommends maintaining a constant view of application data through tools such as Slack notifications or search, talking to users, and creating new issue definitions when the product reveals behavior the team did not anticipate.
A viral AI product needs both a memorable experience and consistent behavior
Sid Bendre says consumer AI products need two conditions for success: a wow factor that drives virality and reliable, consistent user experiences. AI is chaotic and nondeterministic, so Oleve wanted a system that could guide that variability without removing the magic users enjoy. Its Trellis framework is built around continuously improving AI experiences at scale. The framework does not try to eliminate open-ended generation. It adds structure around the parts of the experience where reliability and repeatable improvement matter.
Trellis turns open-ended usage into a hierarchy of focused workflows
Trellis has three axioms: discretization, prioritization, and recursive refinement. Oleve begins with an MVP agent and uses it to collect user data. The team classifies that data into intents based on usage patterns, then converts those intents into semi-deterministic workflows. Each workflow is a predefined set of steps aimed at a particular output. It should be broad enough to cover useful variations while narrow enough to remain reliable. Teams then examine failure patterns and sub-intents inside each workflow, repeating the process at deeper levels.
Workflow priority should include dissatisfaction and the realistic amount of improvement
Bendre warns that ranking workflows by volume alone misses opportunities to improve overall satisfaction. A stronger score combines volume with negative sentiment. A more informed version also includes the estimated achievable delta and strategic relevance. The achievable delta reflects how much improvement the team can realistically gain. If fixing a problem requires training a foundation model, that gain may be close to zero for a particular company. This lets a team focus on workflows where effort can produce a meaningful product change.
Self-contained workflows let teams improve one behavior without destabilizing others
Once intents are identified, Oleve builds workflows that are self-attributable, deterministic, and self-bound. Improvements can then be traced to one workflow and contained there instead of spilling into unrelated product behavior. Bendre says this lets the team move faster and with more reliability. The resulting AI behavior can be engineered, repeated, tested, and attributed. Its magic still comes from AI, but the improvement process does not depend on accidental success.
"At the end of the day, you create magic which is engineered, repeatable, testable, and attributable, but not accidental."18:19
Who should watch
You have an AI feature that works in demos but produces hard-to-explain failures after launch.
Your team is building evals or language-model judges and needs a more grounded way to find problems in real usage.
You run a consumer AI product and need to turn open-ended behavior into workflows that can be improved independently.
