A Full AI-Driven Software Workflow, from PRD to Review, Without Writing a Line of Code

Foreword

Since ChatGPT emerged, I've been thinking about one thing. To what extent can AI really help programmers? Is it just completing a few lines of code? Or can it truly participate in the entire software development process? Recently, some changes happened at my company. This made me rethink my career direction. Rather than continuing to discuss whether AI will replace programmers, it's better to verify it myself. So, I decided to start from an open API, rely entirely on AI, not write a single line of code myself, and try to complete a truly runnable KMP application.

Before starting, we need to think: what roles can we let AI play in this project?

1. AI as a Product Manager

As everyone knows, the start of a product often can't do without a product manager. So how can an AI product manager play this role well?

This is the WanAndroid API development interface documentation. Since AI is playing the product manager, can we let it fetch this API development interface itself, and then automatically analyze the API interfaces through this series of interfaces?

1.1 API Documentation Analysis

As shown in the image

Before using AI, you first need to tell it who you are (your role in the project, tech stack), so that in the subsequent process, the AI will adjust according to your actual situation.
- For example, I mentioned here that I am not familiar with Swift, so the AI noted in the collaboration memory file: "When designing and coding, try to minimize reliance on Swift/Objective-C."

There's a saying that's quite accurate: To get the most out of AI, the first step is to let the AI know how 'useless' you are.

Joking aside, the task was sent to the AI. Let's look at the AI's result.

As shown in the image

CodeX has already analyzed and organized the WanAndroid API documentation according to our requirements, delivering a perfect answer!

At this point, many might think the API analysis is complete, and the next step is to start coding directly?

My answer is No!

If we start coding directly, this project would be no different from an ordinary AI Demo.

I hope Codex can collaborate continuously like a real R&D team, rather than needing to re-introduce the project background every time a new conversation starts.

So, I decided to build a "project memory bank" for Codex.

1.2 PRD, Roadmap, and Project Memory Bank

As shown in the image

In real software development, a project is not just code; it also has:

If these things only exist in chat records, then once a new conversation starts, the AI needs to re-understand the entire project.

This not only wastes tokens but also easily leads to inconsistent decisions!

This paragraph is about: The significance of a memory bank

And this memory bank is roughly divided into three categories:

1.2.1 Project Memory

PRD

RoadMap

Architecture

Summarized in one sentence: Tell the AI what this project is (requirements, development roadmap, architecture description).

1.2.2 Development Memory

Task Memory

Bug Memory

Summarized in one sentence: Tell the AI where the project currently stands and what problems have occurred.

1.2.3 Historical Memory

ChangeLog

Summarized in one sentence: Tell the AI what has happened in this project.

Previously, I always thought that AI's "memory" came from chat history.

After practical experience, I found that true long-term memory should actually come from the project itself.

Chat records will end.

Tokens will be consumed.

But documents within the project will not.

Once PRD, RoadMap, Bug, and Task are stored in the repository, any newly opened conversation can quickly restore to the current project state.

At this point, the AI product manager's work is basically complete.

Next, we are ready to let the AI play the role of a UX designer, automatically generating product prototypes based on the PRD.

2. AI as a UX Designer

2.1 Figma MCP Auto-Invocation

However, when I first tried to let the AI play the UX designer, there was a small hiccup.

As shown in the image

When I prepared to use Figma for UX design, it did generate the WanAndroid KMP UX file on the Figma website. However, when writing data, because I am a free user, it prompted Starter plan MCP tool call limit. Removing the restriction required upgrading the plan, and I wanted to freeload, so I had to switch to another solution!

2.2 AI Simulates a Real Person Operating Figma

Codex, this agent, supports Computer Use, doesn't it? Why not try this feature, bypass MCP, and let it use Computer Use to simulate a real person manually playing the role of a UX designer on the Figma website?

It ran for 13 minutes, the task was completed, and it also used up my 5-hour quota, but the effect was very bad (it can only be described as an eyesore)!

Why was it so bad?

Let's analyze what Figma needs the AI to do.

For example, drawing a homepage:

AI needs to:

A single homepage might involve:

40~80 clicks
20~30 drags
Dozens of alignments
Many fine adjustments

For Computer Use: This is a nightmare.

Because every step requires:

It's not calling an API, but operating like a real person.

This kind of fine adjustment work is not suitable for Computer Use, so we had to switch to another solution.

I thought about using tools like Axure or MockingBot, but MCP-related features probably have restrictions for free users just like Figma, not to mention I used cracked versions before.

In that case, we don't need to perfectly pursue 100% interactive prototypes. Since I don't want to pay, let's go with a substitute version.

2.3 Codex Directly Generates UX Design Assets

As shown in the image

I directly used the PRD requirements and a series of documents generated in the previous round to generate the corresponding UX document docs/08_WIREFRAME_LAYOUT.md, and additionally generated Image2 text-to-image prompts docs/09_WIREFRAME_IMAGE_PROMPTS.md.

Let's see how the effect looks.

Partial content of the 08_WIREFRAME_LAYOUT.md document
Content of the 09_WIREFRAME_IMAGE_PROMPTS.md text-to-image prompts
Effect generated from the 09_WIREFRAME_IMAGE_PROMPTS.md prompts

Actually, with 08_WIREFRAME_LAYOUT.md, we can proceed to the next step of UI design. If you want to see images, you can generate them using Image2 with the prompts.

But!! I don't want a substitute for this step, nor do I want to pay for it. What if I also want an interactive prototype effect?

2.4 AI Can Not Only Use Tools, But Also Create Tools

At this point, I suddenly realized a problem.

Whether it's:

Figma
MockingBot
Axure

None of them are what I truly need.

What I truly need is:

A low-fidelity prototype that AI can understand, humans can view, and can be handed back to AI for Coding.

In that case.

Why must we rely on existing tools?

If AI can already write code.

Then why can't we:

Directly let AI create a tool for itself?

So. I didn't continue struggling with Figma.

Nor did I continue looking for alternatives to Axure.

Instead, I started a brand new project.

I had Codex write for me:

A JSON-driven low-fidelity prototype viewer (AIWireframeViewer).

As shown in the image

This prototype viewer has two modes: Edit Mode and Run Mode.
The current mode is Edit Mode. The left side is the page list, and the console in the middle displays the navigation relationships between pages.
The switch between Edit Mode and Run Mode is in the upper right corner.

Let's switch to Run Mode to see the effect:

As shown in the image

This way, it looks like it has a prototype interaction effect. But its existence is not to replace Figma.

It is merely to give AI a stable "intermediate language."

As for how it is implemented? That's beyond the scope of UX. I will write a separate article about it later when I have time.

OK, the AI successfully played the role of a UX designer. Next, it's time for the visual designer!

3. AI as a Visual Designer

3.1 AI Establishes a Design System (Visual Specification)

When we used to program, we always developed based on the UI designer's specifications.

So what about AI Coding? How should it be done?

As shown in the image

We established a Design System (visual specification) based on the content of the 08_WIREFRAME_LAYOUT.md document generated above.
The content roughly includes: Color specification, Font specification, Corner radius specification, Spacing specification, and a series of other constraint specifications.

Now that the specification is established, let's proceed to the next step.

3.2 AI Translates Design Language into Development Language

At this point, I actually encountered a new problem.

Although we have a design specification, for AI Coding, these still belong to design language.

For example:

A UI designer would say:

Use the primary color for the homepage.

Card corner radius 16dp.

Use Material Symbols.

But when AI writes Compose, it doesn't directly understand these descriptions.

What it really needs to know is:

What should the colors, fonts, and corner radii from the design draft correspond to in Compose?
Which Material3 component does a design component correspond to, and what Compose Facade is recommended for encapsulation?
What components should a page consist of?

That is to say:

AI Coding does not directly consume the Design System, but rather consumes a layer of Runtime Mapping.

As shown in the image

Theme Mapping, which is responsible for telling the AI: What should the colors, fonts, and corner radii from the design draft correspond to in Compose?
- For example:
- This way, the AI won't guess colors on its own.
Component Mapping, which is responsible for telling the AI: Which Material3 component does a design component correspond to, and what Compose Facade is recommended for encapsulation?
- For example:
- From now on, all pages will uniformly use this set of components, rather than reassembling them for each page.
Page Mapping, which is responsible for telling the AI: What components should a page consist of?
- For example:
- This way, when AI Coding, it no longer needs to analyze the Wireframe, but can directly read the component tree.

From this moment on, what AI Coding truly consumes is no longer images, but a Design Runtime that can directly generate code. And this is the input for the next AI Engineering Lead's work.

4. AI as an Engineering Lead

4.1 Before Writing the Homepage, AI Lays the Project Foundation First

After the product requirements, UX design, and visual assets were all prepared, following normal logic, the next step seemed to be starting the development of the homepage.

But after I handed the current project completely to Codex for inspection, it did not recommend jumping directly into business page development.

The reason is simple:

Although the project now has PRD, Wireframe, Design System, and page component mappings, at the code level, it is still just a most primitive KMP template.

If we start directly from the homepage, the homepage will have to simultaneously handle:

Theme initialization
Page navigation
Loading, empty data, and error states
Network exception handling
Platform differences between Android and iOS
Logging and dependency creation
Subsequent login callbacks and detail page navigation

The result of doing this is likely that the homepage will temporarily implement one set, the search page will copy another set, and the later the project develops, the higher the rework cost.

Therefore, before truly developing business features, I first let Codex, in the role of Engineering Lead, perform an Engineering Bootstrap on the project.

As shown in the image

Codex defined this phase as Phase 0.

This phase does not implement the homepage, does not call real interfaces, and does not create any business Features. Instead, it first completes the engineering infrastructure that all pages will depend on.

It ultimately broke down the project initialization into 16 independently verifiable tasks, mainly including:

Toolchain and dependency version baseline
Project package structure and dependency boundaries
Manual dependency injection and Composition Root
Integration of Design Tokens into Compose Theme
Shared navigation root node
Non-business App Shell
Common states like Loading, Empty, Error
Android/iOS platform capability contract
Logging and network transport base layer
Testing, asset verification, and dual-platform quality gates

The most important change here is not the increase in the number of files, but that the project's responsibilities began to be separated.

As shown in the image

After this step, the project is no longer just a KMP template that can display Hello World, but has formed a shared engineering foundation that subsequent Features can plug into.

For example:

AppContainer is responsible for uniformly creating and managing project dependencies;
Navigation Root is responsible for maintaining the navigation state of primary and secondary pages;
Theme truly integrates the visual Tokens generated in the previous phase into Compose;
App Shell is responsible for hosting the application theme, navigation, startup state, and global errors;
AsyncState and AppError unify the loading, empty data, and exception expressions for subsequent pages;
PlatformServices isolates the platform differences between Android and iOS;
HttpTransport only establishes the basic network transport capability, but does not yet include any real interfaces.

This step still has no homepage, no login, favorites, or real APIs.

But every subsequent page no longer needs to re-handle themes, navigation, errors, and platform differences. Instead, they are directly built on the same set of infrastructure.

After completing Phase 0, the project didn't suddenly have a "flashy" page.

But it has transformed from a most primitive KMP example project into an engineering foundation that can formally host business development.

This is also something I gradually realized during this AI Coding practice:

AI Coding is not just about letting AI generate page code faster; more importantly, it's about letting it know when it shouldn't rush to write pages.

After completing the Engineering Bootstrap, the project code already has the capability to host Features.

But what the engineering foundation solves is only "where should the code be placed, and how should dependencies be organized."

Next, there is another problem:

Even if the project structure is ready, when AI is actually Coding, it may still over-engineer due to the pursuit of completeness.

Therefore, before formally starting Feature Development, I added another layer of code implementation constraints for Codex.

4.2 Installing a "Restraint in Coding" Skill for Codex

Why, even after the engineering foundation is complete, am I still afraid to directly let AI write Features?

Because the common problem with AI is not that it can't write, but that it writes too much:

A simple page
        ↓
Adds a new framework
Adds a new abstraction
Adds a new component
Adds future extension points
Refactors old code along the way

Therefore, before formally entering Feature Coding, I installed the Ponytail skill for Codex.

codex plugin marketplace add DietrichGebert/ponytail
codex plugin add ponytail@ponytail

Or directly type in the Codex input box: Install the Ponytail skill for me.

Ponytail does not replace the project architecture, nor does it decide what the product should do.

It is only responsible for adding a judgment before the AI writes code:

Is the current capability truly needed as a new addition;
Does an implementation already exist in the project that can be reused;
Can Kotlin, Compose, or platform native capabilities already solve it;
Do current dependencies already provide the corresponding capability;
Only when the previous answers are all negative, add the minimal implementation.

What it pursues is not simply reducing code, but reducing unnecessary implementation without sacrificing validation, error handling, security, accessibility, and testing.

For AiWanAndroid, this constraint is particularly important.

Phase 0 has already established Theme, Navigation, AsyncState, AppError, Platform Contract, and HttpTransport.

Therefore, when developing the homepage later, the AI should prioritize reusing these capabilities, rather than creating a new set of state, navigation, or network infrastructure for the homepage.

Ponytail solves the problem of "how much code should AI write."

But it still doesn't know:

Which phase the current project has entered;
Which documents have been frozen;
What must be read before starting each Feature;
Which files cannot be modified by ordinary Coding tasks;
What conditions must be met for a Feature to be considered complete.

These rules cannot rely on me re-explaining them in every new conversation.

Therefore, before entering Chapter 5, one last project knowledge organization is needed.

4.3 Refactoring AGENTS.md to Make Every New Conversation Follow the Same Set of Rules

At this point in the project, the AGENTS.md in the root directory has accumulated a lot of content.

It records the product, UX, visual design, document entry points, and collaboration preferences, helping the AI understand how the project was built step by step.

But after entering Feature Development, this document also presented a new problem:

It records too much about "how the project got here," but doesn't clearly enough tell the AI "how to develop next."

For example, wireframe image Prompts, Visual Review, and Compose Readiness were important for the previous design phase, but not every Feature Coding conversation needs to read them by default.

If all historical documents continue to serve as pre-context, it not only increases Token consumption but may also prevent the AI from distinguishing the currently truly effective constraints.

Therefore, I did not continue appending content to AGENTS.md, but let Codex reorganize it globally.

The principles for this reorganization were:

Retain long-term effective project rules;
Delete default contexts that have completed their historical mission;
Mark product, UX, and visual assets as Frozen Assets;
Distinguish between default must-read documents and documents read per Feature;
Clarify the current AI role;
Add Ponytail to the Coding Workflow;
Define the scope that ordinary Features are not allowed to modify;
Define a unified Definition of Done.

As shown in the image

The refactored AGENTS.md is no longer responsible for preserving complete history, but is more like a Feature Development Guide.

Source Of Truth tells the AI which sources of truth a new Feature should read;
Frozen Assets tells it which product, UX, and visual assets cannot be modified by ordinary Coding tasks;
Ponytail Policy specifies when to enable the minimal implementation constraint and its priority when conflicting with project specifications;
Definition Of Done unifies the completion criteria for each Feature.

After completing this refactored AGENTS.md, every subsequent new Codex conversation no longer requires me to repeatedly explain the entire project.

The AI only needs to read AGENTS.md to know:

Currently in Feature Development;
Currently should play the role of Android/KMP Feature Engineer;
Which documents to read before starting a task;
Which assets have been frozen;
When to enable Ponytail;
What Plan needs to be output before Coding;
Which changes are out of bounds;
What conditions must be met to declare a Feature complete.

At this point, the code foundation, AI Coding constraints, and project context are all ready.

Starting from the next chapter, no more setting up environments, no more organizing specifications, directly entering the first business Feature.

5. AI as an Android/KMP Engineer

5.1 How AI Completes the First Feature

After the previous four chapters, we finally begin the real AI Coding.

And a mature AI Coding project is not one where Prompts become increasingly complex, but one where Prompts become increasingly simple.

As shown in the image

This time, my Prompt was just one sentence: Current task: Develop the homepage.

Let's directly look at the effect of this task:

5.2 Why AI Coding Can Complete a Feature with a Single Prompt

Why, with just one sentence, does the AI know what to do?

Because in the previous chapters, we have already completed the knowledge precipitation of the entire project.

After the AI receives this sentence, it does not immediately start writing code.

Instead, it automatically completes the following steps according to the Workflow defined in AGENTS.md:

As shown in the image

After the plan was confirmed, Codex did not directly start implementing the homepage, but first analyzed the impact scope of the entire Feature.

For example:

Does it need to add a new page;
Does it need to modify navigation;
Can it reuse the existing Theme;
Will it affect other Features;
Does it violate Frozen Assets;
Does it require platform difference handling;
Does it comply with Ponytail's minimal implementation principle.

Only after confirming that none of these were issues did it truly start Coding.

However, after the homepage development was completed, there was one last problem. Code that can run does not mean this Feature is truly deliverable.

Real software development requires one final process: Review.

6. AI as a Reviewer (Quality Acceptance)

I originally thought that Chapter 6 should continue by giving the AI a new Prompt.

For example:

"Please start the acceptance review for the homepage."

Later, when organizing the entire Workflow, I found it was completely unnecessary.

Because Codex, in Plan Mode, had already:

Integrated into a complete lifecycle.

Review is not a new task.

It is a natural part of this Feature.

Initially, I was going to write this chapter as: 《AI as a Test Engineer》

But later I found: In real AI Coding software R&D, Review is never something that starts only after Coding is finished. It happens continuously throughout the entire development process.

As shown in the image

Before announcing Task Complete, the AI will proactively complete:

Build verification;
Compilation error fixes;
Code Review;
Memory update;
Task status update.

Only when the entire Feature meets the completion conditions will it truly end this task.

Therefore, I later revised the table of contents for this article.

Changing the original:

AI as a Test Engineer

To:

AI as a Reviewer (Quality Acceptance)

Because for this current AI Coding Workflow:

Review is not something that happens after development, but a part of the development process itself.

Up to this point, the goal this article truly wanted to verify has actually been achieved.

We are not proving:

Whether AI can write a homepage.

But verifying:

Whether a complete AI Coding Workflow can truly be run through.

Facts have proven, it can.

From product analysis, to UX, visual design, engineering initialization, and then to Feature Coding and final Review.

The entire software R&D process can already be deeply participated in by AI.

As for:

How to use AI to generate test cases;
How to let AI write interface tests;
How to implement click-click-click automated testing;
How to let AI take over the QA work of traditional projects;

These already belong to another, more complete AI QA workflow.

I plan to separately organize an article later to systematically discuss this topic.

When I looked back and reorganized the entire project, I suddenly realized:

What truly changed was not that the homepage development was completed.

But that I had started to get used to treating AI as a project member, not a chatbot.

This is also the biggest takeaway from writing this article.

Therefore, before concluding, I want to talk more about some thoughts this practice brought me.

7. Summary: What Has AI Coding Truly Changed?

If I had to summarize this practice in one sentence, I think it's not:

Will AI replace programmers?

But another question:

What kind of person will AI ultimately turn programmers into?

Before, like many people, I treated AI as a chat tool.

Ask a question when encountering something I didn't know.

Write a function, complete a few lines of code.

It wasn't until this time, truly starting from scratch and letting AI participate in a project throughout, that I realized it has long played a role beyond just "code completion."

It can be a product manager, analyzing APIs and organizing PRDs; it can be a UX designer, outputting page information architecture and Wireframes; it can be a visual designer, establishing a Design System; it can be an architect, building the engineering foundation; it can also be an Android/KMP engineer, completing Feature development according to project rules.

And what I truly need to do has changed instead.

Before, I needed to tell the AI:

How to write this line of code?

Now, I am more often thinking about:

How should this project collaborate?

7.1 AI Won't Think for You, But It Will Infinitely Amplify Your Thinking

There's a saying online:

AI won't eliminate programmers, but programmers who use AI will eliminate those who don't.

I agree with this statement, but I think it can go one step further.

I'd rather change it to:

AI won't eliminate programmers, it will eliminate those programmers who stop thinking.

Why?

Because AI itself has no goals.

It won't suddenly decide to develop a product.

It won't suddenly think of breaking a project into PRD, UX, Visual, Engineering.

It certainly won't proactively establish Workflow, Memory, Source Of Truth.

These ideas still come from humans.

AI's capability is more like a magnifying glass.

The clearer your ideas, the more obvious its amplification effect.

Without ideas, it can only continuously repeat existing knowledge.

So, throughout the entire project, what I truly invested the most time in was not writing Prompts, but thinking:

How can I make it easier for AI to understand this project?

7.2 The Endpoint of Prompt is Not Prompt Engineering

Many people, when first learning AI, will study Prompts.

Including myself.

Initially, I would also write hundreds or thousands of words of prompts, hoping the AI would understand all the background at once.

But later on, I found that Prompts became shorter and shorter.

Finally, when developing the homepage, what I truly input was just one sentence:

Current task: Develop the homepage.

Why did the Prompt become shorter and shorter?

Not because the AI became smarter.

But because the project already possessed its own long-term memory.

PRD, Design System, Theme, Architecture, AGENTS, Task Memory...

These have all been precipitated into the project itself.

The Prompt is no longer responsible for describing the entire world.

It is only responsible for telling the AI:

Which Feature is up now.

This is also one of my biggest takeaways:

The endpoint of Prompt Engineering is actually Project Engineering.

What truly matters is not the Prompt, but the project.

7.3 I Think Skills Will Become the Next Generation of "Development Templates"

At this point, I had another new idea.

If this entire Workflow can be continuously reused.

Then why must it stay within a blog post?

For example:

The product manager chapter can be precipitated into a Product Skill.
The UX phase can be precipitated into a UX Skill.
The Visual phase can be precipitated into a Design Skill.
Engineering Bootstrap can be precipitated into an Engineering Skill.
Even AGENTS.md, Ponytail, Workflow, Definition Of Done can gradually be precipitated into team-level development specifications.

In the future, when a new project starts.

Perhaps what truly needs to be done is no longer copying an Android Template.

But:

Installing a set of software R&D Skills belonging to this team.

7.4 I'm Increasingly Looking Forward to Multi-Agent

Thinking one step further.

What if Product, UX, Visual, Architecture, Android Engineer are no longer completed by the same AI.

But become multiple Agents?

For example:

As shown in the image

Each Agent has its own long-term memory.
Each has its own responsibility boundaries.
Each has its own Definition Of Done.
They collaborate with each other through documents, rules, and Workflows.

Such a process is already very close to a real software team. I believe this is also one of the future development directions for AI software R&D.

7.5 Programmers Might Redefine Themselves

When many people discuss AI, they always like to label themselves.

Frontend.

Backend.

Android.

iOS.

Algorithms.

...

But this practice increasingly makes me feel:

In the future, what truly matters may not be these labels.

But:

Whether you possess the ability to turn an idea into a product.

AI is continuously lowering the barrier to technical implementation.

Before, one person might only be able to complete the part of work they were familiar with.

Now, one person can leverage AI to quickly cross the boundaries between product, design, development, and testing.

Of course, this doesn't mean everyone will become a full-stack engineer.

Rather, it means:

Everyone has the opportunity to become someone who can organize AI collaboration.

Programmers are no longer just code writers.

More like a director.

You are responsible for proposing goals.

Setting rules.

Arranging roles.

And AI is responsible for completing their respective tasks.

This article is not trying to prove:

AI can already replace programmers.

Quite the opposite.

It makes me even more convinced:

What will truly be scarce in the future is not people who can write code.

But:

People who can ask questions.
People who can design Workflows.
People who can organize multiple AIs to collaborate.
People who can continuously precipitate project knowledge.

This time, I only completed a small KMP project.

But I believe this will not be the endpoint.

Next, what I want to try more is:

Refining the entire Workflow into reusable Skills;
Trying a Multi-Agent collaborative software R&D process;
Letting AI not just complete a Feature, but truly participate in a long-term project.

Perhaps a few years later, when we look back at the Prompts, AGENTS, and Workflows discussed today, they will all become a phase in the history of AI software R&D.

But I believe one thing will not change:

What truly determines the upper limit of AI has never been just the model, but also the people who use it, and the workflows they build. The model determines speed, the workflow determines scale, and human ideas determine how far AI can ultimately go.

The project for this article has been uploaded to GitHub AiWanAndroid

The AI-created tool mentioned in section 2.4 of this article has also been simultaneously uploaded to GitHub AIWireframeViewer Tool