AI Writes His npm Code in Seconds. He Rebuilt His Packages for AI Users.
First in the series. Written for everyone who has published open-source packages: when AI can write in a dozen seconds the code you built over five years, what's the point?
I'm Long Jiushan, a front-end developer. I've written a few npm packages and built several admin-dashboard frameworks in the RuoYi ecosystem.
The conclusion first
I've been making npm plugins for five years, and once thought I had built up some technical moat.
Early this year I found that moat was fake.
AI can write in a dozen seconds the component I spent two days writing, and it gave me an accessibility improvement I never thought of.
I almost gave up maintaining these packages.
Then I realized one thing and restarted: AI is not the enemy of plugins; AI is the new user of plugins.
Previously I designed plugins for "people"; now I design for "AI". The difference between the two is much larger than I imagined.
This article is about that process. I won't oversell how great the results are — data hasn't proved anything yet. I'll only talk about how I noticed the problem.
If you also maintain open-source packages, especially for admin dashboards, this might be useful. I'll list the four things I did at the end.
1. My reasons for making packages were actually pragmatic
From when I first published to npm until now, I have 10 packages: one admin-dashboard utility library, a few components, and a scaffolding tool.
For real reasons:
First, speed.
I've worked on many RuoYi-style admin projects. Null checks, date formatting, dictionary display, masking, thousand separators, SM (Chinese national cryptography) encryption/decryption... this code gets rewritten in every project, and while writing you have to decide "does 0 count as empty" and "use yyyy or YYYY".
After making packages, new projects just npm i and done.
Second, to have something to show.
In front-end, writing "familiar with Vue3" on a resume is not convincing. Writing "I published npm packages" at least gives you more to talk about.
Third, technical barrier — this one now looks like a joke.
I really thought: these are things I accumulated over years of pitfalls; anyone who wants to use them has to install my package. That's a barrier.
These 10 packages cover the most repetitive work in admin dashboards. If you work on RuoYi-style projects, installing ljs-tools basically covers the utility-function side — 15 utility modules plus 9 components.
In 2023, this idea held.
By the end of 2025, it collapsed.
2. AI writes better than me, and faster
I usually write code by hand. Every time I finish a task I get a sense of accomplishment, it feels great. But later it became bittersweet.
One day I needed a "number scrolling" effect — the animation where numbers on a big screen climb from 0 to a target. My package moving-numbers-vue3 did exactly that.
But that day I didn't install it; I casually asked AI:
Write in Vue3 a big-screen number scrolling effect, numbers from 0 to target, with thousand separators
It gave code that ran. It added thousand separators, easing curves, and even added a prefers-reduced-motion accessibility fallback.
I stared at the screen for a while.
This requirement originally took me about two days — handling decimal points, layout jumps when digit length changes, sign position, and how to avoid restarting from zero on data updates.
AI took a dozen seconds. And its accessibility handling — I never even thought of that.
My package is indeed more complete in details. For example, the pitfall of "not re-rolling from 0 when data updates" is handled; the AI version just restarts. But honestly, most users won't notice that difference.
That night I checked my packages' download statistics.
s-timeline weekly downloads: 384.
ball-swiper: 372.
trends-table: 371.
These numbers are also inflated. On October 23, the day I released a version, moving-numbers-vue3 got 531 downloads that day — all from CI npm install, unrelated to real users.
At that moment I was numbed! I'm a traditionalist, called an old antique by friends. I remembered they were already writing code with AI, while I insisted on writing it myself, learning what I didn't know by thinking, then writing it myself, and only using AI when forced (and even then, I'd carefully read and learn from the AI output).
When I actually used AI, I realized the times had changed. AI can already handle 95% of business development; the remaining 5% is because I couldn't explain clearly.
The barrier I once believed in vanished instantly. The protective suit I had finally put on disappeared. Running naked doesn't feel good.
I realized one thing:
The "technical barrier" I was proud of is essentially an "information gap."
Previously, others didn't know how to write it or were too lazy, so they installed my package. Now AI knows how to write it and doesn't mind the trouble — the barrier is gone.
3. The hardest part isn't "nobody uses it"
It's thinking "is this still meaningful?"
Nobody uses it anyway; AI can write it all. Why should I spend time fixing it?
During that period I genuinely considered: forget it, I'll stop maintaining.
After so many years of hard work, the impact of AI broke the dam in an instant.
Night after night I felt sad. I even wanted to delete the repos.
4. The turning point was a sentence
I forgot where I saw it, but the gist was:
AI is the new user of plugins, not the enemy of plugins.
I froze for a long time.
5. Change the question: who is actually using my package?
My previous thought was: people use my packages.
Developers install packages, read docs, write code, and file issues on bugs.
So I optimized for human experience: clear README, full parameter tables, plenty of examples.
But what if AI is also a user?
Its first hurdle: it doesn't know my package exists.​
A package with three hundred weekly downloads probably isn't in training data. — It's because I didn't make it discoverable.
Second hurdle: even if it knows, it doesn't know what it can do.​
README is written for humans, full of parameter tables. — It's because I didn't give it a readable capability description.
Third hurdle: even if it knows what it can do, it doesn't know what parameters to pass.​
Without type declarations, it has to guess. — It's because I didn't give type definitions.
Fourth hurdle: even if it guesses right, it doesn't know how to integrate.​
Global registration or local import? Do styles need to be imported manually? — It's because I didn't give integration conventions.
All four of these are my responsibility, not AI's.
I later organized these four into a "four-layer acceptance": can be discovered, can be understood, can be correctly invoked, can be directly integrated. This has been my most valuable thinking in the last two years; the second article will cover how to implement it.
At that moment I realized: I had been complaining that AI took my job, but I never thought — my stuff didn't give AI any interface.
6. So what to do
In the following months, I mainly did one thing:
Turn packages "for humans" into packages "that AI can also use."
There are four concrete things.
1. Make it discoverable
There's a community convention called llms.txt that lets AI quickly understand a project when crawling. I wrote one following that format and placed it at the root of the documentation site, listing all 10 packages, each with one sentence on what problem it solves.
I also rewrote npm keywords. Originally broad words like vue3 and component; now I added scenario words: ruoyi, admin-dashboard, sm2, watermark.
2. Make it understandable
Each package got an AI.md — a manual written specifically for AI, not a parameter table, but "when to use, how to use, what pitfalls exist."
I also filled in index.d.ts type declarations. This one is critical: AI reads type definitions much more accurately than docs.
3. Make it directly integratable
This was the most troublesome part. I wrote a scaffolding tool create-ljs that generates a complete project with one command.
I also wrote AGENTS.md — a "project manual" for AI collaborators, explaining the project's conventions, red lines, and common traps, placed in the template.
AGENTS.md is now used in many projects. The reference I used at the time was "a document for onboarding a new colleague" — if AI is a new colleague on this project, what should I tell it? That analogy later became the backbone of the whole approach.
4. Open-source everything
I hesitated the longest on this one.
Previously I was unwilling, thinking the code was hard-won; if open-sourced, someone might copy it.
This code was built with effort, every line and word doesn't shine, but it carries my sweat and tears.
If I open-source it, won't it all be copied? But if I don't, I'm always building behind closed doors!
I kept going back and forth, until AI's heavy blow knocked me out; only then did I wake up.
I finally reasoned:
Code itself is not a barrier; my ability to judge which code to use in what scenario is.
A pretty function is not a barrier; the process of logical thinking and the ability to analyze business are.
Also, not open-sourcing has a more practical problem — my most substantial work is hidden in private repos, and others (interviewers, potential clients, AI) can't see it at all. What isn't seen equals non-existence.
7. Current state
All 10 repos are now open-sourced.
9 npm packages were republished, metadata filled in, links pointing to their source repos.
READMEs were rewritten — originally starting with "# Introduction / this is a dynamic table", now starting with "when to use it, when not to use it".
Though I've only taken the first step and data hasn't changed, my mood is better. My mindset has shifted. I'm friends with AI now!!!
But one change is immediately visible: I can talk about this stuff.
Before, when I said "I've published 10 npm packages," the other person opened GitHub and got 404. Now they can see the code, see the commit history, see the design I made to be AI-friendly.
In closing
I can't say this path is right. Data will prove it, or it may prove nothing.
But one thing I'm sure of:
I can't change that AI writes code. What I can change is how AI-friendly the code I write is.
This is a new problem, no standard answer yet. I'll try it my own way and write what I learn here.
Next article will cover the concrete methods — how to implement the "four-layer acceptance" and what pitfalls I hit at each step.
Series articles
- Second: Let AI Use It: Four-Layer Acceptance (to be published)
- Third: Cleanup Before Open-Sourcing (to be published)
If you also maintain open-source packages, how are you dealing with AI? Discuss in the comments.