Chapter 3: Intent Layering

1 Why Layering is Needed

Intent is never a single-dimensional simple instruction, but a layered semantic system. Let us understand this through a concrete scenario: when an executive says “we want to develop a membership system” at a project kickoff meeting, different roles in the room actually receive completely different information—

The CEO envisions numbers on financial statements: can this system improve user retention? Can it bring considerable revenue growth? How does it support the company’s long-term competitive moat?

The product manager is thinking about the functional blueprint: how many tiers should members be divided into? How should benefits be designed for each tier? What gradient should the pricing strategy adopt? How should it integrate with the existing points system?

The technical lead’s focus has already sunk to the technical level: how should this system ensure performance? How should data security be ensured? How should it run stably under high concurrency scenarios?

The same concept of a “membership system” presents completely different aspects in the cognition of different roles. This cognitive difference is not a communication failure, but an embodiment of the inherent complexity of software systems—it simultaneously involves multiple levels such as business value, product functionality, and technical constraints.

The core purpose of intent layering is precisely to establish order within this complexity. It decomposes the vague “develop a system” into three clear levels: business intent sets the value direction, product intent defines specific functionality, and technical intent sets implementation boundaries. Among these, product intent and technical intent are the core operational interfaces of the IOSE transformation.

2 The Three-Layer Intent Model

In the practice of intent-oriented software engineering, we divide intent into three levels, forming a clear value transmission chain:

flowchart TB
    A["Business Intent Business"]
    A_desc["Answers why to do it—value direction"]
    B["Product Intent Product"]
    B_desc["Answers what to do—function definition"]
    C["Technical Intent Technical"]
    C_desc["Answers how to do it correctly—constraint boundaries"]

    A --> A_desc
    A --> B
    B --> B_desc
    B --> C
    C --> C_desc

    style A fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
    style B fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
    style C fill:#fff3e0,stroke:#f57c00,stroke-width:2px
    style A_desc fill:#fafafa,stroke:#bdbdbd
    style B_desc fill:#fafafa,stroke:#bdbdbd
    style C_desc fill:#fafafa,stroke:#bdbdbd

These three levels have clear division of labor and progress layer by layer. Among them, product intent and technical intent are the core battlefields of the IOSE transformation—product personnel directly drive development by defining product intent, while technical personnel ensure AI generation quality by defining technical intent.

Business Intent

Business intent focuses on macro-level business goals, answering the question of “why do it.” It usually comes from senior managers and sets the direction for the entire organization.

Core Elements of Business Intent:

Business intent is relatively stable and serves more as background context. In the IOSE transformation, it does not need to be frequently operated, but needs to be clearly understood and communicated.

Business Intent Example:

What we want to do:
Improve the renewal rate of annual members

Business Goals:
- Increase annual member renewal rate from current 75% to 85%, i.e., reduce about 2,000 passive churn users per month
- Through proactive service methods, let more members nearing expiration complete renewal in time
- Expected annual revenue growth of approximately 5 million yuan

Value Proposition:
Value to the company:
Reducing user churn means higher customer lifetime value. Each retained annual member can bring
an additional 3 years of subscription revenue on average. Compared to the high cost of acquiring new customers, retaining existing users has higher ROI.

Value to users:
Help users avoid benefit interruptions caused by forgetting or negligence, ensure they can continuously enjoy member privileges,
and enhance user loyalty and satisfaction with the platform.

Strategic Context:
- Intensifying market competition: In the past two years, customer acquisition costs in the same industry have risen by 40%. Relying solely on new customer-driven
growth models is no longer sustainable

- Company strategic transformation: This year, the company explicitly proposed transforming from "traffic-oriented" to "user value-oriented",
with existing user operations becoming a core strategy

- Data-discovered problems: User research shows that over 60% of churned members cite "forgot to renew" as the main reason,
rather than dissatisfaction with the service, indicating huge room for recovery

Product Intent

Product intent is the bridge connecting business and technology. It transforms abstract business goals into specific product functional solutions, answering the question of “what to do.”

Core Elements of Product Intent:

• Functional Goal: What specific functionality to implement, what problem to solve
• Target Users: Who is the user group served by this functionality, what are their characteristics
• Usage Scenarios: Under what circumstances is the functionality used, what are the trigger conditions
• User Experience: How do users perceive this functionality, what is the operation path
• Acceptance Criteria: How to measure whether the functionality is successful, what quantifiable indicators are there

Product intent is one of the core operational objects of the IOSE transformation. Under the IOSE paradigm, the product manager’s work focus shifts from writing PRDs and drawing prototypes to defining structured product intent. This structured product intent can directly drive AI to generate runnable software, giving product personnel the ability to directly create digital products.

Product intent expression has two main forms: text description is used to express functional logic and business processes, and Figma design drafts are used to precisely express user interfaces.

Text Expression: Describing Functionality and Processes

Text form is suitable for describing functional logic, business processes, algorithm rules, etc. that do not involve complex interfaces. It clearly elaborates in natural language “what to do,” “for whom,” “in what scenario to use,” and “how to measure success.”

Text-Based Product Intent Example:

Functional Goal:
Develop a benefit expiration reminder function for annual members. When user membership is about to expire,
reach them through multiple channels including app push notifications and email, reminding users to renew in time,
thereby reducing passive churn caused by forgetting.

Target Users:
Annual members, especially the user group within 30 days of expiration. According to data analysis, this group
has high renewal willingness but is prone to benefit interruption due to forgetting.

Usage Scenarios:
When a member's annual benefit is about to expire within 30 days, the system needs to proactively initiate reminders:
- 30 days before expiration: First friendly reminder, informing that benefits are about to expire
- 7 days before expiration: Second reminder, emphasizing benefit value and renewal discounts
- 1 day before expiration: Final reminder, creating urgency
Reminder channels include app push notifications and email.

User Experience:
- Reminder content is clear and explicit: clearly inform expiration time, remaining benefit value, and what will be lost without renewal
- Operation path is extremely simple: provide one-click renewal shortcut entry, users can complete payment without multiple jumps
- Respect user choice: provide "remind again in 7 days" and "do not remind again" options, avoiding excessive disturbance

Acceptance Criteria:
Functional Accuracy:
- Reminder trigger timing is accurate, triggered at 30 days, 7 days, and 1 day before expiration respectively
- Reminder target screening is correct, excluding users who have renewed or turned off auto-renewal

Business Effect:
- Reminder open rate > 60% (i.e., among users who receive reminders, over 60% will click to view)
- Renewal conversion rate > 15% (i.e., among users who click to view, over 15% will complete renewal)
- User complaint rate < 1% (complaints caused by excessive disturbance or inaccurate reminders)

Figma Expression: Precisely Describing User Interfaces

When product intent involves user interfaces, pure text description is often difficult to precisely convey visual details—the specific position of buttons, color values, font sizes, element spacing, and other information are both lengthy and prone to ambiguity when described in text. At this time, Figma design drafts are the best tool for expressing interface intent.

The essential advantage of Figma lies in its definition of design as data:

• Traditional design tools output pixels (images). Large models need to “understand” visual elements and reason about their structure and style. This process not only consumes significant computing power but also easily loses details (such as precise spacing, color values, font parameters).
• Every interface element in Figma—from button position coordinates, color values to text font and spacing parameters—is structured data. Figma’s file format is essentially a form of “pseudo-code” that can be precisely read and programmatically operated.

Therefore, when product intent includes interfaces, prioritize providing Figma design draft links or exported structured data rather than screenshots or pure text descriptions. This allows AI to accurately reproduce design intent, rather than guessing from vague visual information.

Interface-Based Product Intent Example:

Functional Goal:
Design push notification cards and email pages for member renewal reminders to improve user click-through and renewal conversion rates.

Interface Deliverables:
- Figma design draft link: https://figma.com/file/xxx/member-renewal
- Or exported structured data file (such as JSON generated by figma-to-code plugin)

Key Interface Descriptions:
1. App Push Notification Card
   - Display position: Phone lock screen and notification center
   - Content elements: Member level icon, benefit expiration countdown, renewal button
   - Interaction: Swipe left to close, click to enter renewal page

2. Email Reminder Page
   - Top: Brand logo and member exclusive identification
   - Body: Benefit list (used/unused), expiration time, renewal discount
   - Bottom: One-click renewal button, customer service contact, unsubscribe link

Design Specifications:
- Follow iOS/Android official push design specifications
- Email width limited to within 600px to ensure compatibility across clients
- Button color uses brand primary color #FF6B35 to ensure clear visual hierarchy

Acceptance Criteria:
- Design drafts fully cover both push cards and email forms
- All visual elements are marked with clear dimensions, colors, and font parameters
- Provide adaptation solutions for mobile and desktop

Technical Intent

The core mission of technical intent is to transform product intent into specific plans that coding agents can understand and execute, while ensuring the implementation process conforms to quality boundaries. It answers two key questions: “how to make AI understand requirements” and “how to do it correctly.”

Technical intent contains two major components:

Part One: Implementation Specifications (How to Implement)

This part focuses on decomposing product functionality into technical plans that agents can execute, and is the most transformative content of technical intent.

Part Two: Quality Constraints

This part defines the boundary conditions that must be followed during implementation.

Special Note on Architecture Quality Constraints:

Architecture quality constraints are a key mechanism in the IOSE paradigm to ensure long-term software maintainability. When AI agents continuously generate and modify code, without clear architecture boundary constraints, systems can easily fall into “chaotic growth”—blurred module responsibilities, complex interdependencies, and out-of-control code complexity. This not only affects human understanding but also significantly reduces the efficiency of AI agents’ subsequent work.

Core Architecture Constraint Elements:

• Layering Direction Constraints: Strictly define the dependency direction of each layer in a layered architecture (such as classic three-layer architecture: Controller → Service → Repository), prohibiting reverse dependencies or cross-layer calls. This ensures that AI does not break the clear boundaries of architecture when generating new code.

• Cyclomatic Complexity Control: Require that the cyclomatic complexity of each function/method does not exceed 10 (or team-agreed threshold). High complexity code is not only difficult to maintain but also makes it difficult for AI to grasp logical boundaries during subsequent modifications, easily producing bugs.

• Module Size Constraints: Limit the number of lines of code for a single file, single class, and single function (such as single file not exceeding 500 lines, single function not exceeding 50 lines). Appropriate granularity allows AI to more precisely locate modification scope, reduce the impact surface of changes, and improve generation efficiency.

Through these constraints, we ensure that AI agents always face a codebase with clear structure and well-defined boundaries during continuous work, thereby maintaining efficient code generation and modification capabilities.

Technical intent is the core operational object of the IOSE transformation. Developers shift from “personally writing every line of code” to “defining implementation specifications and reviewing AI execution.” High-quality technical intent should be clear enough that agent tools like Cursor and Claude Code can autonomously complete development tasks based on it.

Practical References for Technical Intent

In actual work, writing technical intent can refer to the following tools and concepts:

Reference Cursor’s Agent Mode: Cursor’s Composer function demonstrates how to transform requirement descriptions into multi-file code modifications. In technical intent, we need to provide a similar “context map”—explaining the responsibilities of each module, how they interact with other modules, and the organization structure of key files.

Reference Claude Code’s Spec-Driven Approach: When handling complex tasks, Claude Code first confirms the “Implementation Plan” with the user. The “task decomposition” section in technical intent is exactly such an implementation plan. It needs to clearly define the input, output, and acceptance criteria for each subtask.

Reference Kiro’s Specification-Driven Development: Kiro emphasizes “Specs as Code,” meaning that specification documents themselves are executable constraints. The “acceptance specifications” in technical intent should be precise enough to be validated by automated tools—such as through unit test assertions, API contract tests, or static code analysis to ensure implementation conforms to specifications.

3 Interaction Relationships Between the Three Layers

Business intent, product intent, and technical intent are not three independent islands, but an organic whole. Understanding their interaction relationships is crucial for effectively applying intent layering.

Top-Down Transformation Process

In actual software planning processes, high-level business intent needs to be transformed into executable technical plans layer by layer:

flowchart TD
    A["Business Intent: Increase member renewal rate by 10%"]
    B["Product Intent: Benefit expiration reminder function"]
    C["Technical Intent A: Reminder generation service"]
    D["Technical Intent B: Push notification service"]
    E["Technical Intent C: Renewal page optimization"]

    A --> B
    B --> C
    B --> D
    B --> E

    style A fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
    style B fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
    style C fill:#fff3e0,stroke:#f57c00,stroke-width:2px
    style D fill:#fff3e0,stroke:#f57c00,stroke-width:2px
    style E fill:#fff3e0,stroke:#f57c00,stroke-width:2px

Business intent answers “why do it,” providing direction guidance for product intent; product intent answers “what to do,” transforming business goals into specific functional solutions; technical intent answers “how to do it correctly,” setting quality boundaries for product implementation.

Bottom-Up Support Relationship

Conversely, each layer of intent provides implementation support for the layer above:

• Technical intent supports product intent: Without performance constraints, reminder services may crash during peak periods, and product functionality cannot operate normally; without security constraints, user data leaks, and product value is lost.
• Product intent supports business intent: If product functionality design is unreasonable and users are unwilling to use it, business goals cannot be achieved; if acceptance criteria are improperly set and actual effects cannot be measured, business value cannot be verified.

Product intent and technical intent are the core operational interfaces of the IOSE transformation. Product personnel directly drive AI to understand “what to do” by defining clear product intent; technical personnel ensure AI knows “how to do it correctly” by defining complete technical intent. Together, they constitute the main channel for human-AI collaboration.

Focus Subjects of Each Layer

4 Precision Principles of Intent Expression

The quality of intent expression directly determines whether AI agents can accurately understand and execute. Here are two key principles:

Avoiding Ambiguity: From Vague to Precise

Natural language itself has inherent ambiguity, but intent documents require eliminating this ambiguity as much as possible. Here are some common comparison examples:

Verifiability: Ensuring Intent Can Be Verified

Every intent should be objectively verifiable. If an intent cannot be verified, it cannot serve as an execution target and acceptance criterion for AI agents.

Not-so-good intent example: “The system should run stably”

Problem: “Stable” is a subjective concept, different people may have different understandings

Improved intent: “System availability > 99.9%, fault recovery time < 30 minutes, unplanned downtime < 43 minutes per month”

Advantage: Clear metrics, measurable, verifiable

5 Chapter Summary

Intent layering is the theoretical cornerstone and practical guide of intent-oriented software engineering. Through this chapter’s study, we should master the following core points:

1. Business intent answers “why do it”—it sets the value direction and provides background for product intent;
2. Product intent answers “what to do”—it transforms business goals into specific functional solutions and is the core operational object of the IOSE transformation;
3. Technical intent answers “how to make AI understand and implement”—it includes implementation specifications (requirement decomposition, technical design, task decomposition) and quality constraints, and is the technical core of the IOSE transformation;
4. Precision expression principles eliminate natural language ambiguity, ensuring intent can be accurately understood and verified by AI.

The benefits of this three-layer structure are manifold:

• Business personnel can focus on value direction without getting bogged down in functional details;
• Product personnel can focus on functional definition, directly driving development through structured intent;
• Technical personnel shift from coding executors to specification definers, guiding AI to complete implementation through technical intent;
• AI agents obtain clear, structured, executable input, capable of autonomously completing the entire process from design to coding.

Core Insight: Under the IOSE paradigm, the value of technical personnel is no longer reflected in “speed of writing code,” but in “ability to define clear specifications.” An excellent technical intent should be complete enough that agents like Cursor and Claude Code can autonomously complete development tasks based on it, while humans only need to review and accept.

In the next chapter, we will further compare the core differences between old and new software engineering paradigms, deeply understanding the profound impact and significance of this transformation.

Practical Exercise

To help you better master intent layering, it is recommended to complete the following practical exercise:

Exercise Task: Choose a specific feature you are currently responsible for or familiar with, and try to write according to the templates introduced in this chapter:

1. A business intent document (briefly explain business background and goals)
2. A product intent document (refer to section 3.2.2 template, describe functional definition in detail)
3. A technical intent document (refer to section 3.2.3 template, clarify technical constraints)

Self-Check List After Completion:

• Do the three levels of intent form a clear value chain?
• Does product intent transform business goals into specific executable functional solutions?
• Does technical intent contain complete implementation specifications (requirement decomposition, technical design, task decomposition)?
• Is task decomposition detailed enough for agents to understand each task’s input and output?
• Are acceptance specifications quantifiable and automatically verifiable?
• If these documents are given to Cursor or Claude Code, can it autonomously complete development based on them?