AI 原生开发复盘：流程没变，角色变了——从 Issue 到功能上线

Many people think of AI development as “getting AI to write code for me.”

That understanding isn’t wrong, but it’s incomplete. Writing code is only one step in the whole software development process. In the AI era, it is actually the step that changes least and worries you least, because today’s large models are already extremely well trained at coding—a simple natural language prompt is enough.

The truly interesting changes are outside the code: how requirements are analyzed, how solutions are designed, how prototypes are made, how tests are run. These “beyond the code” matters are where AI-native development really changes the game.

A few days ago, I used AI to add a new feature to my own app. The process was fairly typical, so it’s worth a complete retrospective.

Here’s the conclusion first: the process hasn’t changed, but the roles have.

Before diving into the case, let me state the core insight:

AI-native development is still fundamentally the traditional software development flow—feasibility analysis, solution design, prototype design, coding, and test verification. Not one of these steps is missing.

What has changed? The executor.

Previously, humans did every step by hand. Now, humans become commanders and agents become executors. Humans only confirm and make decisions on the critical path; the concrete analysis, design, coding, and debugging are all left to agents.

To put it metaphorically, you get promoted from an individual contributor programmer to a technical director. You no longer write every line of code, but you decide whether to do it, how to do it, and whether it’s done right.

Doesn’t sound like a big deal? But once you run through a complete flow yourself, you’ll realize the efficiency gain is an order of magnitude.

The feature came from a GitHub issue. A user left a comment on my subtitle transcription/translation app (BaoCut) asking whether remote transcription could be added.

The scenario was very concrete: he had two computers—one high-performance machine A for heavy compute, and another everyday office machine B. He wanted to use BaoCut on machine B while offloading the compute-hungry transcription tasks to machine A.

I immediately felt this was a good request: the scenario is reasonable, it creates value for users, and it fits the product’s positioning.

But I didn’t immediately open the editor and start coding.

This is the step most likely to be skipped in the whole flow—and the one that should never be skipped.

Decide whether to do it before doing it. That sounds like common sense, but I’ve paid the price many times.

Just a few days ago, for example, I built a feature that used a local text model to assist in splitting and aligning subtitles. During feasibility analysis, I thought there was no technical problem. Only after finishing it and using it did I realize the result was poor, so I ended up cutting it—wasting several days and a pile of tokens. See, even with feasibility analysis, judgment can sometimes be off. But that doesn’t mean feasibility analysis is useless. Without it, you’d fall into even more traps.

It’s a bet on expected value: most of the time it helps you avoid detours, and occasionally it misses.

Feasibility analysis usually looks at two dimensions:

Product angle: Does this feature have value? Does it fit the app’s positioning?

Technical angle: Can it be done technically? Is the cost controllable?

This time, I had already judged the product angle—it was worth doing. So I only needed to focus on technical feasibility.

I sent the user’s original request to Claude Code and asked it to do a feasibility analysis in the context of the current project. After analysis, it concluded: feasible, and listed several technical options.

I quickly scanned the options and formed my own judgment:

Options 0 and C required no code changes, but they were not user-friendly at all—users would have to set up their own ASR server, which ordinary users can’t handle.

Option A was the best: install the app and you can start your own transcription service, making it the simplest for users.

Option B was not friendly enough for Windows.

So I decided to go with option A, and at the same time added the extra feature from option 0: providing an HTTP transcription API.

Notice the pattern here: the agent does the analysis and lays out options; the human makes the final judgment and decision. This is what “human confirmation on the critical path” means—you don’t need to research every technical detail yourself, but you need to make the final call based on your product judgment and technical instincts.

Once feasibility and the technical direction were settled, I still didn’t jump to code. The next step was to have an agent write a design document.

Why a document? This touches a key insight of AI-native development:

Documents have taken on an entirely new role in the AI era: they are the bridge between humans and agents, and between agents and agents.

In traditional development, documentation is often a burden—it goes stale after being written, and people don’t like reading it. But in AI-native development, documents have become the most important intermediary medium for two reasons:

First, a document is the vehicle for humans to review and revise. The agent writes the proposal into a document, and you can read it through, check whether the direction is right and whether the details have problems, and edit directly in the document.

Second, a document is the medium for passing context between agent sessions. Every agent session has a finite context window. When you move from “design” to “development,” you often start a new session. The previous session’s reasoning, decision rationale, and technical plan all need to be passed to the next session via the document. Without it, the next session starts from zero.

In other words, a document is the “memory medium” of AI-native development.

The design document I asked for was a hybrid of product design and technical design: it described what the requirement was, how to architect it, and how to define the interfaces. The goal was to solidify this information so that the agent implementing it later would have clear references, and the human would have an anchor point to check the direction.

Ideally, at the end of each stage, you should produce an archivable deliverable—requirements doc, design proposal, prototype, code, and tests. And you should tie these deliverables to a version control tool like git to track all changes. Then the deliverables themselves can act as an audit trail: who raised the requirement, what the agent produced, and who approved it.

I admit I cut a corner this time: after the design document was written, I went straight to prototyping, mainly because the options from the feasibility phase had no issues and I trusted Fable 5 quite a bit. But for a more complex project, you should carefully review the design document—it costs far less than overturning code after it’s written.

There’s also a critical operational detail: the confirmed document is the entire starting point for the next agent session. When you move from “design” to “development,” it’s often a new session. You don’t need to re-explain the whole story to the agent; you just say, “Implement according to docs/remote-transcription.md.” All decisions and details are already in the document, so the new session can start executing after reading it.

This is one of the areas where I think AI-native development changes the most.

In the traditional flow, requirements documents, prototype design, and UI design were three separate steps done by different people: product managers wrote requirements, interaction designers made prototypes, and UI designers created visual mockups. Every handoff lost information, and every change required coordination among many parties.

With AI, all three can be merged into a single step—high-fidelity prototype design. What does that mean? The prototype you produce is not a wireframe; it’s a high-fidelity design close to the final product, directly including interaction logic and visual design.

This was previously infeasible and extremely costly—you couldn’t expect one person to have product thinking, interaction design, and UI design skills all at once. Even if someone did, a high-fidelity prototype would take days. But now, one AI agent plus a good Design Skill (first choice: Claude Design; you can also use my baoyu-design, which auto-triggers when you mention “prototype design” in the conversation) can quickly produce a high-fidelity prototype.

My app has a companion prototype design page; every time I add or change a feature, I update the prototype first. With the design document as the foundation, prototype design went relatively smoothly, and the first version already looked good. It added a new tab in the settings page to enable the transcription service and discover other nodes on the network.

But a finished prototype doesn’t mean the work is done. At the prototype stage, the cost of changes is relatively low, while making changes after the real product is built is very expensive. So this stage is worth spending time on, iterating again and again.

I adjusted the prototype many times. First, I changed the layout from a list to tabs, separating “start service” and “access other nodes.” In my view, these are two different usage scenarios; mixing them together would confuse users. Then I added icons to show service status, so users could tell at a glance whether the service was on or off.

Later, I found that putting this feature in the settings page was inconvenient—users need to check the service status frequently, and burying it in settings made it too deep. So I moved it to the main screen. After several rounds back and forth, I finally felt it was good enough.

Notice the pattern here: for every adjustment, I only describe in natural language the change I want, and the agent updates the prototype. My attention is entirely on product-level judgments—Is this interaction friendly? Is this interface beautiful? Does it feel natural for users?—rather than obsessing over pixels and layout implementation details.

Why shouldn’t you skip prototype confirmation? Because once the UI and interactions have been developed, the cost of changes increases exponentially. You’d have to change code logic, styles, state management, and test cases. But at the prototype stage, changing a layout can be as simple as saying one sentence.

If you’ve reached this step, you already have the design document and a confirmed high-fidelity prototype. Asking an agent to write the code is now a very simple thing for today’s models.

Together with the /goal command, I sent the design document and prototype to Claude Code (Fable 5) and asked it to implement the milestones one by one as planned in the document. It plans the implementation order itself, writes the code, runs tests, and even takes screenshots to verify the results.

There’s an easily overlooked technique I often emphasize: letting the agent verify its own work reduces how often you need to intervene. After writing a piece of code, it automatically runs tests; if something fails, it debugs and fixes it. After changing an interface, it takes a screenshot to confirm the effect. This gives the agent its own feedback loop, so it checks itself before you see the result. When you, as the human, do final confirmation, you’re already looking at results the agent has verified, not a rough first draft.

This is also why merging some confirmation steps (for example, skipping Code Review and going straight to black-box testing) is relatively safe. The agent is capable enough, and with self-verification during development, the output quality is high.

At this stage, there is very little for the human to do—mainly wait and glance at the progress occasionally.

If you think about it carefully, you’ll see that code is no longer the bottleneck. Traditional processes such as PRDs, estimation, and security reviews were all meant to align things before the development phase, because development could take weeks or months. But when an agent can finish coding in a few hours, those old confirmation processes need to be rethought in the AI era.

The bottleneck has shifted to the two sides of the code: on the left, design and confirmation; on the right, testing, verification, and deployment. These steps still run at human speed, and they are what now need optimization.

That’s exactly why I spent so many words earlier on feasibility analysis, design documents, and prototype design—in AI-native development, these “before the code” tasks are actually the most important.

Even though the agent writes tests, runs tests, and verifies results for you, that doesn’t mean you can trust it completely. You still need to try it yourself next.

Key mindset shift: treat yourself as an ordinary user, not a developer.

Developer testing and user testing have completely different perspectives. Developers subconsciously avoid edge cases and operate along the path they expect. Ordinary users don’t. They click around randomly, enter things you didn’t expect, and use the feature in ways you never imagined.

So what you should do: open the app, pretend you’re seeing the feature for the first time, and use it intuitively. Are the prompts clear enough? Is the interaction natural enough? Are there reasonable guides when something goes wrong?

When you find a problem, just throw it back to the agent and let it fix it. After a few rounds, the feature is basically usable.

Looking at the final result: the remote transcription feature is fully usable.

Did I review the code? No. I treated myself as QA and did black-box testing only. I trusted Fable 5’s coding ability. This is also a concrete example of the “merged confirmation steps” I mentioned earlier: the agent already ran tests and took screenshots during development, and I did another round of black-box testing from the user perspective. The two layers of verification together are enough.

Of course, this trade-off depends on how important the project is. If it’s the core logic of a financial system, you may still need Code Review. But for most feature development, black-box testing is enough.

Let’s look back at the whole flow:

Feasibility analysis → design document → prototype design → coding → test verification

Isn’t this exactly the traditional software development flow? Yes, it is.

AI-native development didn’t invent a new process; it runs the old process in a new way.

Specifically, there are three fundamental changes:

Change one: the executor shifts from human to agent.

At every step, the agent is the one doing the real work. You don’t need to write feasibility analysis reports, draw prototypes, write code, or create test cases yourself. You only need to confirm and decide at key nodes.

You focus your energy on judgment and decisions; the agent handles execution and details.

Change two: confirmation steps can be merged, but not skipped.

In the traditional flow, requirements confirmation, prototype confirmation, and UI confirmation were three separate review meetings. Now you can merge them: requirements documents, prototype design, and UI design are combined into a high-fidelity prototype, confirmed at once. Design documents and prototype design can also be reviewed together.

But the confirmation step itself must never be omitted. Each one exists for a reason:

Feasibility confirmation: decide whether to do it first, so you don’t end up doing a lot of work for nothing.

Technical solution confirmation: is the direction optimal? Is there a better path?

Prototype/UI confirmation: is the interaction friendly? Is the interface beautiful? After development, changes are extremely expensive; at the prototype stage, changes are extremely easy.

Test confirmation: verify whether it’s good from the user’s perspective, not merely whether it runs from the developer’s perspective.

You can speed up confirmations (merge steps, streamline the process), but you cannot skip them. Human judgment is the irreplaceable part of the whole flow.

Change three: documentation becomes more important.

In traditional development, documentation is an accessory—you write it after the code, or even not at all. But in AI-native development, documentation has become core infrastructure.

It serves two key functions:

It is the vehicle for humans to confirm and revise. You can review design documents, annotate prototypes, and modify technical proposals; all these actions happen at the document layer.

It passes context between agent sessions. Your design document is handed to the development session, your prototype is handed to the implementation session, and each session is no longer isolated.

If you’ve used Claude Code, you’ll feel this deeply. Every time you start a new session, you have to re-explain the previous context. A document is the best context-passing medium—it is more precise than verbal descriptions and more structured than chat history.

Of course, documents also introduce a new problem: if versions are not updated in time, they can produce wrong context.

Finally, a topic many people care about: what Skills did you use? Do you need to install many development Skills to boost the agent’s coding ability?

My answer may be surprising: most development Skills are unnecessary.

Today’s large models are already extremely well trained at coding. Look at my entire interaction with the agent in this flow—the prompts were all very simple natural language: “Help me analyze feasibility,” “Write a design document based on option A,” “Build a prototype based on this design,” “Implement according to the document.” No complex prompt engineering, no special coding skills.

Recall what I said earlier: the bottleneck has shifted to the two sides of the code. The code itself no longer needs enhancement; what needs enhancement are the two sides—design confirmation on the left, and testing, verification, and deployment on the right.

I generally use only two types of Skills, which correspond exactly to those two bottlenecks:

The first type supports design confirmation—solving the left-side bottleneck. For example, Claude Design / baoyu-design, tools that merge prototype design and UI design. They help me quickly produce high-fidelity prototypes, so I can confirm the interface and interaction before coding.

The second type automates labor-intensive work—solving the right-side bottleneck. For example, auto-deployment and auto-publishing. After coding, there are packaging, deployment, and release steps that don’t require judgment but do take time. Commands like /goal also let the agent advance by milestones automatically, reducing the work of manually splitting tasks.

The middle layer—coding itself—the model is already good enough; a simple instruction yields high-quality code. Spending effort on process design pays off far more than spending it on prompt optimization.

Looking back at this feature, from GitHub issue to fully usable, I spent almost no time writing code. The time went to feasibility judgment, repeated prototype polishing, and testing by playing the dumb user. These are exactly the parts agents cannot replace: whether to do it, whether the direction is right, and whether it works well—every one requires a human to decide.

The essence of AI-native development is exactly this: the development process is still the same, but the human role has changed. You go from being the person who writes code to the person who manages agents; the output is no longer code, but a series of judgments and decisions.

I know it’s not easy to let go of the attachment to code. Especially those who have written code for many years, merging without looking at every line can feel unsettling. I also arrived at this “black-box testing only” state step by step. But the trend is clear: models will only become better at coding, and human value will be increasingly concentrated on the two sides of the code. The sooner you complete this role transformation, the more leverage you get from AI.