Preface
"We want to use AI to boost productivity" — there's nothing wrong with this goal.
The problem is in execution. Many enterprises' approach is: take the existing development process, then replace each step with "let AI do it."
On the surface, this seems reasonable. In practice, it's putting old wine in a new bottle and wondering why there's no effect.
This article aims to clarify one thing: What is the essential difference between an AI-Native Workflow and a "transplanted" workflow that just has AI do each step?
Root Cause: Wrong People Using Wrong Frameworks to Define Workflows
In many enterprises, the people leading AI Workflow definition come from process consultant backgrounds, with experience concentrated in standard process frameworks like ASPICE and CMMI.
These frameworks can provide high-level phase breakdowns (requirements analysis, architectural design, detailed design, coding, unit testing...), but they can't answer operational questions: who exactly does what in each phase, with which tools, executing which steps, and where the real information flows and waiting points are.
The root cause is capability model mismatch: ASPICE frameworks describe what, not how. Using them to design AI Workflows is working at the wrong level of abstraction.
But the bigger problem isn't the wrong framework — it's the method of discovering workflows.
The Right Way to Discover Workflows: Not Through Interviews
If the execution method is interviews, what you get is "what people think they do," not "what people actually do."
There's a huge gap between cognition and behavior. The most valuable implicit operational steps are often things that even the developers themselves can't clearly articulate:
- "Before analyzing the root cause, I always glance at the timestamps in the log..." — can't explain why, but does it every time
- "I'll quickly scan through the recent code commits..." — a subconscious action that never comes up in interviews
- "If there's this error in CI, I usually first check the xxx configuration..." — experience-accumulated shortcuts that were never documented
More effective discovery methods:
Embedded Observation: Follow a developer through the complete process from receiving a ticket to merging a PR, recording every tool switch, documentation lookup, and waiting-for-feedback moment. The key isn't hearing what they say — it's observing what they do.
Tool Log Analysis: Git commit time distribution, Jira status transition times, PR review rounds — data exposes real bottlenecks and friction points.
The real Workflow nodes are hidden in transition costs and waiting, not in phase names.
What Is a Truly AI-Native Workflow
AI-Native's essence is not "using AI to redo every human step" but redesigning the constraint conditions.
Humans are constrained by attention-switching costs, memory capacity, and serial processing; AI is constrained by context window limits, hallucination rates, and lack of execution permissions. A truly AI-Native Workflow is designed around the basic assumption that humans are responsible for judgment and decisions, AI is responsible for context aggregation and draft generation.
Here are four diagnostic tests to check whether a Workflow is truly AI-Native:
Test 1: Degradation Test
If you remove the AI, can the Workflow degrade into a human process that's less efficient but logically complete?
If yes, AI is only an accelerator, not a structural component. A truly AI-Native process, when AI is removed, has its process form itself collapse — because AI is handling tasks that humans fundamentally cannot or should not perform manually (like real-time aggregation of context across 50 related PRs).
Test 2: Information Flow Direction Test
Human process: humans go collect from various places → humans aggregate and judge → humans output results.
AI-Native: AI continuously listens and aggregates context → pushes structured information when humans need to decide → humans only make judgments.
If the information flow direction hasn't changed after redesign, and it's just that each step has been replaced with "let AI help me do it" — that's still transplantation.
Key question: In this Workflow, who is proactive, who is reactive?
Test 3: Human Role Test
In this Workflow, is every operation that humans perform a matter of judgment/decision/creation, or information collection/format conversion/transmission?
The latter should be completely taken over by AI. If humans are still doing the latter, the Workflow design isn't complete.
Test 4: Time Structure Test
Human processes are linearly synchronous (complete one step before starting the next). AI-Native can be asynchronously parallel — AI continuously processes in the background, human involvement is event-driven rather than polling-based.
If the new Workflow's time structure is still linear and synchronous, it usually indicates a transplantation mindset.
Positive and Negative Examples
Negative example (AI transplantation): AI replaces humans in reviewing PR diffs file by file
- What humans did originally: review each file diff, judge whether changes are reasonable
- After AI transplantation: AI reviews each file diff, outputs review opinions, humans then read the AI's review opinions
- Information flow direction unchanged, human role unchanged — just added an intermediate layer
Positive example (AI-Native): When a PR is created, AI automatically aggregates "requirements background + architectural decisions + test coverage + historical bug patterns," generates structured review context, reviewers make high-level judgments based on this context
- Information flow direction changed: humans no longer collect context from multiple places — AI proactively pushes it
- Human role changed: from "information collection + judgment" to "pure judgment"
- Time structure changed: AI's aggregation work starts when the PR is created, asynchronously; human involvement is event-driven
Talent Profile for This Work
Defining AI-Native Workflows requires an intersection of several capabilities — each missing piece is a genuine bottleneck:
Essential capabilities:
- Real understanding of AI capabilities: Not "knowing AI is amazing" but knowing context window limits, hallucination patterns, tool call overhead, and being able to judge which steps AI can do well versus where it'll fail
- First-hand software development experience: Having actually written code or done requirements/design work at some stage, able to understand the developer's actual mental model — not just "knowing the development process"
- Process redesign mindset: When looking at a process, the first reaction is "what problem does this process solve, is there a better way to re-solve it" — not "how do I use AI to do this step"
- Field research capability: Able to observe without disrupting, ask questions that make people elaborate, distinguish between "what they said they did" and "what they actually did"
Harmful backgrounds (mindset biases that need active overcoming):
- Deep ASPICE/CMMI background: habitual tendency to view things through the "phase/activity/artifact" framework — AI-Native design requires breaking this framework
- Only AI product usage experience without development background: tends to design processes that "look good in demos but aren't usable in actual work"
The most likely talent source: senior engineers who have done development and later deeply engaged with AI tools and developed systematic thinking; or product managers with technical backgrounds.
Collaboration Patterns Between Developers and Workflow Designers
There's a natural asymmetry: developers have information but lack redesign perspective, workflow designers have design capability but lack information. The key to collaboration is making information truly flow, not just having developers "provide requirements" or "review proposals."
Effective collaboration patterns:
Shadow Session: The workflow designer observes a developer completing a real task without bringing questions — just records, doesn't interrupt. Afterward, the developer marks "where it felt difficult" — far more authentic information than interviews.
Friction Mapping: Ask developers to record "what annoyed me today" rather than "where do you think the process could be optimized" — the former is genuine feeling, the latter is a processed answer.
What-If Conversation: Don't ask "what do you think AI can help you do" — ask "if you didn't need to do X, where would you spend that time" — getting developers to themselves identify truly valuable directions.
Prototype Fault-Finding: The workflow designer proposes a redesign proposal and asks developers to "find the flaws" rather than "approve it" — developers expose a large amount of tacit knowledge when criticizing.
Anti-patterns:
- Organizing a workflow diagram for developers to "confirm whether it matches reality" — developers say "roughly right" but a large amount of detail is wrong
- Asking developers "tell me what AI capabilities you need" — developers can't imagine from a blank slate; this question produces no effective output
Critical prerequisite: Developers participating in this work must feel that "this is solving my problems, not standardizing my work." The first deployed Workflows must make participating developers personally feel that their work has become lighter — this is the word-of-mouth foundation for subsequent adoption.
Practical Path
- Start with one specific task, not covering the entire process from the beginning (e.g., "from receiving requirements to producing a technical design document")
- Observe rather than interview: Sit beside a developer and watch them complete a real task, recording every step
- Identify information aggregation points: Which steps require collecting information from multiple sources — these are often where AI can most improve efficiency
- Redesign rather than transplant: For each step, ask yourself: if AI does this step, what should the inputs and outputs be, and what's the human's role in this step?
- Accumulate from small Workflows, then consider end-to-end integration
Summary
To determine whether a Workflow is truly AI-Native, use four tests:
- Degradation test: Can the process still run when AI is removed?
- Information flow direction test: Has AI changed the direction of information flow?
- Human role test: Are humans only making judgments and decisions?
- Time structure test: Is the process event-driven rather than linearly synchronous?
Discovering truly AI-Native Workflows can't be done through interviews — it requires embedded observation and tool log analysis. The people who define them need AI cognition, development experience, and process redesign capability simultaneously — a rare and valuable combination.
Visit PrimeSkills — a curated AI Agent and skills marketplace where all content is validated through real enterprise workflows. No hype, just what actually works.
For more practical knowledge and interesting products, visit my personal homepage
