AI Automation Broke Down on a 90-Component Migration Until the Verification Loop Got a 12x Rewrite

Why I Had to Migrate the Component Library from Vue to uni-app x

First, why do I have this task on my hands? I maintain uView Pro, a cross-platform component library with over 90 components. It originally ran on uni-app Vue3, and I am currently migrating the whole thing to uni-app x.

Why migrate? I brought it on myself... but it's also a necessity.

uni-app's component library only recognizes Vue syntax, while uni-app x compiles directly to native code. One codebase can run on App, Mini Program, and H5 across multiple platforms, with better performance than before. The community has been urging this, but it's a necessary upgrade, not just icing on the cake.

But the migration isn't as simple as changing a file extension. A component's TypeScript needs to become UTS, CSS becomes UCSS, and Vue becomes uvue. The syntax, restrictions, and compilation rules have all changed. With over 90 components, each one must pass four checkpoints: refactoring, building an example page, registering routes, and adding an entry point. It's equivalent to rewriting the entire library. The hardest part is aligning the APIs while keeping the frontend functional.

This is a massive, highly repetitive engineering task—exactly the kind of work I wanted to hand off to AI.

But it wasn't as simple as I imagined. The key issue is that AI doesn't understand how to write uts, uvue, or ucss. Who even created these? Couldn't they just use standard ts, js, css, and vue languages?

I think the reason AI performs poorly when writing uni-app x right now is that there are too few examples on the market, insufficient knowledge bases and experience, and a lack of context. The AI can't even find relevant cases to retrieve. But I even tried uni-agent, which supposedly knows uni-app x best, and the results were still unsatisfactory. When I ask you to fix a problem, what do you mean by constantly deleting my code?

Is this right?

I almost wanted to give up...

My solution for writing uni-app x correctly isn't perfect either. Currently, I've created a large number of rule skills to constrain the AI, telling it how to write uts, ucss, and uvue syntax, trying to keep it from going off track and maximizing the chance of getting it right the first time. If it truly doesn't know how to write something, it should ask me; improvisation is strictly forbidden...

This article won't discuss how AI writes uni-app x for now; let's first talk about this matter...

My Original Idea: Publish a Requirement, Leave the Rest to AI

Given the massive workload, my initial approach was to set up an AI workflow where "publishing the requirement" would be the final step.

The process was defined like this: I would post a component's migration requirement. It would first ask me a few questions to nail down the details, then rewrite the code itself. After writing, it would verify itself. If verification failed, it would fix the issue itself, even taking screenshots to show me during the process. Finally, it would save the reason and result of each fix as a record for me to review later.

I only wanted two things: Automation—so I wouldn't have to supervise each component one by one; Traceability—every step would be remembered, so if a change went wrong, I could trace back to why it was made at the time. Sounds ideal, right?

But... the ideal is full-figured, reality is skin and bones...

It Was Indeed Responsible, But Couldn't Be Fast

The novelty didn't last a week. The problem emerged: it wasn't that it refused to work, it was that it worked too slowly.

The problem was entirely buried in its "self-verification" step. Look at what it did for every single change: first, restart the service, open the page to take a screenshot, stare at it itself, change it if it's wrong, and do it all over again. Moreover, each round was stateless; it forgot the previous round after running this one. The service restarted every time, screenshots were saved anew each time, records were rewritten each time—all idle spinning in between.

For example, pick any one of the 90 components, and it could run through a complete rewrite + verification cycle. But just the "verification—correction" back-and-forth alone could consume most of a day. Once, to make a single line of text display consistently across five platforms, it tried back and forth seven times on its own. Each round restarted the service, generated a new screenshot, and appended a section to the record before finally getting it right. A dozen or two screenshots were saved, and a long record was written.

What's worse is that this wasn't an occasional occurrence, but the norm. One slow process, multiplied by 90 components, equals 90 times the delay. At this rate, relying solely on this "automation," I feared it might take a year.

The most terrifying part: Trae Work's credit consumption also doubled. As shown below, it increased dozens of times. If I looked away for a moment, I almost went back to square one:

It was then I realized: What I wanted wasn't "automatic but makes you wait"; it was "automatic, and get it done quickly," and most importantly, save Tokens.

So, let's have Trae Work analyze it:

Why I Decided to Modify It

Put another way—the conclusion I drew from this slowness is: How fast a process can be depends not on how smart your model is, but on how smooth your self-verification loop is.

It was slow not because it was stupid, but because three design aspects were heavy:

1. The service restarted from scratch every time; it had no awareness of "using the last one."
2. Judgment relied on "screenshot + human eyes"; every change required stopping to look.
3. Records and screenshots were redone every time, sacrificing speed for traceability.

All three of these could be changed. Why did I decide to change them? Because if I didn't, let alone not being able to finish migrating 90 components, even if I forced the migration through, this "automation" wouldn't deliver its intended value—a process that makes people wait saves hands but drains the mind, and is itself a false automation.

How I Changed It: Putting the Grinding Step on the Fast Track

I targeted the most grinding step—verification.

(1) Reuse state; don't let it start from zero every time. Keep the service running persistently, tell it to connect directly to the existing one after making changes, and don't restart every time. The heaviest startup step was gone instantly.

(2) Replace "human eye" with "script judgment." Whether an ellipsis is displayed, whether component interfaces are complete, whether icons and text are on the same line—these aren't metaphysics; they are style properties and coordinate standards that can be written down. I equipped it with a small script. After making changes, run it once, and it directly outputs "success or failure, which item is wrong," no screenshots or guessing needed.

(3) Bind "judgment" and "traceability" together, rather than letting them drag each other down. The script runs and outputs results line by line. This output itself is the record, saved as it runs, cleaner than the lengthy manual records it wrote before, and faster to look up. Automation, traceability, and speed—I wanted all three.

After the modification, its self-verification was compressed from "start service + screenshot + human eye" to "run one command to the end." One round dropped from about four minutes to a dozen or so seconds.

The Effect After Modification

The most direct number: one round of verification dropped from about 240 seconds to about 19 seconds, a more than tenfold improvement. I ran it twice consecutively, once 18.7 seconds, once 18.6 seconds, very stable.

Looking back at the migration project—90 components, each needing to pass the "verification—correction" gate. Previously, one component could grind through this gate for an entire afternoon; now, one takes less than a few minutes. Originally, I estimated the whole library migration would take at least a month or so; now, I dare to cut that number by more than half.

A more interesting change is in mindset. Before, I only assigned it "safe, small tasks," fearing it would get stuck. Now that its verification is fast, I dare to throw more complex, bolder tasks at it, and it dares to think of several solutions before starting. Speed is contagious.

I tested the new script twice more: 18.7s → 18.6s, stable. The old link, based on previous analysis, took a median of about 240s, a speed increase of about 9–16 times.

For the amplification effect on today's type of task (repeated troubleshooting of circle-progress canvas):

• Before optimization: 7 rounds × ~240s ≈ 28 minutes of pure verification + repeated trial and error
• After optimization: the same 7 rounds × ~19s ≈ 2.2 minutes, and the assertion can quickly locate "which item is wrong," reducing the number of trial-and-error rounds themselves.

A Few Things You Can Copy Directly

This set of things works for any scenario where "AI does the work for you, but can't be fast":

1. For reusable state, don't let it start from zero every time. The fact that "the service is still running"—tell it to connect directly, cutting out the most expensive restart.

2. Quantify what can be quantified; don't rely on human eyes. Whether it's enough, correct, or aligned—write it as a judgeable standard for a script to decide, don't rely on screenshots and mutual guessing.

3. Bind judgment and traceability into one command. Don't sacrifice speed for traceability. The result of the script run is itself the record, both accurate and easy to look up.

4. When it's slow, first find "which step is slow." Its slowness is often not because it's stupid, but because one step is too heavy. Pinpointing that step is ten times more effective than urging it to run faster.

Conclusion

I originally aimed for "automation + traceability." Only when it actually ran did I understand that the prerequisite for saving effort is being fast enough.

This time, I only had Trae Work modify its most grinding step, and the results were already immediate—the migration project for 90 components finally has an end in sight, and the release date is just around the corner. Now that the verification step is fast, I plan to align other steps with this path one by one.

When everything is connected one day, this workflow will truly deserve the words "fully automatic," and that is exactly what I originally wanted it to help me accomplish with this project.