跪拜 Guibai
← Back to the summary

AI Made Code Cheap. Certainty Is Now the Expensive Part.

From Claude Code to job survival, six questions, one answer. All data in this article is queried in real-time as of August 2026. Note: This article contains AI assistance.

Foreword: A Confusion Many People Have

I've been asked a few questions recently, and I think they are more honest than most discussions about "Will AI replace programmers?":

Now that we have coding agents like Claude Code, which cover common functions, what else can I do as a frontend developer to improve team efficiency after getting this tool?

Some people write skills, some turn colleagues into skills — I think these have little value. Unless it's a 100% repetitive process, but a 100% repetitive process is just as well handled by a script. So I really can't think of anything else to do.

This confusion is very real, and I think the first half of it is basically correct.

Enterprises indeed don't need to rebuild a Claude Code; turning a colleague's persona into a skill is indeed a toy; 100% deterministic processes should indeed be scripted.

But this reasoning misses one thing, and that thing is precisely the core of how frontend work is changing in the AI era.

1. Core Judgment: AI Has Raised the Price of "Certainty"

Let's start with the conclusion; all subsequent chapters are its expansion:

AI has drastically reduced the cost of 'producing code,' so 'ensuring the code is correct' has become the new bottleneck and the new source of value.

Previously, the cost structure of a feature was roughly: Think 20%, Write Code 60%, Verify 20%.

Now, that 60% for writing code has been compressed to 10%. The remaining two parts haven't changed, or have even become heavier—because the speed of code output has increased, the pressure to verify has actually grown.

The center of gravity in engineering has shifted from 'production' to 'constraint and verification'.

This sentence sounds abstract, but it can directly derive six very specific conclusions. Let's go through them one by one.

2. After Getting AI Programming Tools, the Most Important Thing Isn't Writing Skills

First, Correct the "100% Repetitive" Dichotomy

The reasoning in the original question was: 100% repetitive → write a script; less than 100% repetitive → AI is unreliable. This dichotomy misses the largest chunk in the middle.

The real distribution has three segments:

Determinism Who Does It Example
100% Mechanical Script / codemod Lifecycle method renaming, syntax replacement
70%–90% AI Agent ← This is its irreplaceable zone Semantic decomposition, per-file adaptation, edge case handling
Relies on Judgment Human Architectural decisions, whether to switch libraries

The characteristic of the middle block is: huge workload, high repetition, but the details of each file are different—so pure scripts can't handle it (requires semantic understanding), and doing it manually is pure torture.

Frontend has a massive amount of this kind of work: Vue2→3 migration, class components to Hooks, component library replacement, i18n text extraction, analytics tracking补齐, adaptation after major dependency upgrades. Codemod can handle 70%, the remaining 30% of edge cases used to be entirely manual—that 30% is precisely AI's home turf.

The Two Things That Truly Determine AI Performance Are Not in the Tool

The same AI tool can produce output quality that differs by a factor of three across different codebases. The difference lies in two places:

1. Context Provision

If AI doesn't know you have <AppButton>, it will write a button itself. If it doesn't know your request wrapper, it will directly use fetch.

This is the most typical failure mode for frontend teams using AI: the code runs, but it pollutes the architecture.

The solution is an ordinary markdown file in the project root directory (called CLAUDE.md in Claude Code, other tools have corresponding mechanisms), written in plain language:

# Project Description
- Tech Stack: Vue3 + TS + Vite
- Buttons uniformly use src/components/AppButton, do not write <button> yourself
- Requests uniformly go through src/utils/request.ts, do not use axios/fetch directly
- State management uses Pinia, do not introduce Vuex
- After changing code, must run npm run lint && npm run test
- Do not touch any files under the src/payment/ directory

Why is the ROI of this file higher than all skills combined?

Because AI reads it first every time it starts working. Every constraint you write applies to every subsequent task—this is multiplication. A skill only triggers once in a specific scenario—this is addition.

There's a key insight here: AI has no memory. You correct it today, and it will make the same mistake tomorrow in a new session. It's an intern that never learns. The only solution is to write the rules down externally.

Incidentally, this also explains the true meaning of "engineering constraint sedimentation"—those "must do this, can't do that" rules mostly exist in the minds of senior employees, only popping up during code review as "we don't write it that way." Sedimentation is moving them from brains into files.

And the method matters: don't sit in a meeting room designing rules out of thin air. If you said "this should reuse an existing component" three times during this week's review, then that rule is worth writing down. Use actual mistakes to decide what to write.

2. Verification Loop (Frontend's Biggest Weakness)

The upper limit of AI output quality is determined by 'whether it can verify itself'.

With a loop, it can self-correct and iterate; without a loop, you are acting as a human validator.

Backend has types and unit tests naturally forming a loop. The frontend's problem is that the "does the rendering look correct" link is usually broken. So the highest-leverage investment for a frontend team is:

Fill in these gaps, and without writing a single line of skill, AI's effective output will jump a level.

3. Large-Scale Refactoring: The Difficulty Was Never Changing Syntax

With the foundation above, let's look at the scenario that best demonstrates value. Take Vue2→3 migration as an example—the typical skepticism for such tasks is:

The business and product teams can't even articulate the requirements themselves, a pile of duplicate code with no idea whether to merge, and testing won't help you verify. After migration, do you dare to go live?

This skepticism is very real. Let me break it down point by point.

First Discipline: Migration Is Not Refactoring

"Duplicate code, not sure whether to merge"—then don't merge, don't even touch it.

The only goal of migration is: swap out the underlying framework, business behavior must not change a single character. Those two ugly duplicate code blocks should remain exactly as they are after migration.

Why must it be this strict? Because if you casually change business logic along the way, when something goes wrong online, you cannot locate the cause—was it the framework change, or was it your meddling with those two code blocks? You won't even know which half to roll back.

Change only one variable at a time; this is the iron law of all large-scale refactoring.

Everything you want to optimize goes into a list called "Deal with after migration." Once migration is stable, create a separate project—by then, it's a normal requirement that can be scheduled normally.

Second: The Old Code Itself Is the Requirements Document

"The product team can't articulate the requirements"—this question doesn't even need to be answered during migration.

You don't need to know what this page "should" look like; you only need to ensure: what it was yesterday, it still is today.

Is there a bug in the logic? Copy it exactly. Is the interaction counter-intuitive? Copy it exactly. Does no one understand it? Copy it exactly.

This immediately bypasses the deadlock—migration does not require product team involvement.

Third: The Confidence to Go Live Doesn't Come from "Guaranteeing No Problems"

No one can guarantee no problems; traditional development can't either.

The engineering approach has never been "ensure zero defects," but rather reduce probability + make the cost bearable. Four layers of insurance:

① First, supplement tests for old code—this is AI's greatest value point

The key is that the test writing approach must be counter-intuitive:

This type of test is called a characterization test, its role is to describe the current state, not define correctness. After migration, run them; if a single one changes, it immediately alerts.

Why did no one do this before? Supplementing tests for three hundred old components is pure manual labor, a huge workload with zero sense of accomplishment, and no team could ever schedule it.

And this is precisely what AI can do now, and do well—you don't need it to be creative, you need it to be patient.

② Visual Regression

Before migration, take screenshots of every page and save them as a baseline. After migration, take another round and let the machine compare pixel differences. This catches the vast majority of "style collapses"—which are precisely the most common accidents in migration. Playwright has built-in screenshot comparison, no need to buy extra services.

③ Roll out in batches, don't big bang

Don't hold your breath for three months and then "switch" one night. That's gambling.

Migrate the 5 most peripheral pages this week (About Us, internal admin pages), go live and observe for a week; if no issues, migrate 15 next week. The problems from the first batch will teach you what to watch out for in the next 200.

④ Ability to roll back in one minute

Launch with a feature flag, route 1% of traffic to the new version first, monitor error tracking. If no increase, scale to 10%, 50%, 100%; if it spikes, turn it off with one click.

Conclusion: I wouldn't dare to launch a full migration without a test baseline all at once—no one should. But I would dare to launch 5 pages with characterization tests + visual regression + 1% canary + one-click rollback.

Testing not cooperating doesn't mean you must shoulder all the risk; it means you must slice the risk into pieces.

How to Specifically Break It Down into Hundreds of Verifiable Small Tasks

Step 0: Subtract First (Highest ROI, Most People Skip)

Before migrating, delete dead code.

After a frontend project runs for a few years, typically 20%–40% of the code is completely unused—offline campaign pages, deprecated old flows, commented-out but undeleted components.

Deleted code: no need to migrate, no need to test, no need to discuss, no need to worry about bugs. A task completed without writing a single line is the most cost-effective.

"Is this page still in use?"—the product team can't answer, but analytics data can. Pull the last 90 days of page views; pages with 0 PVs enter the candidate list.

This step is where product involvement is needed—not asking him "what's the logic of this feature," but showing him the data and asking "can we cut this page that no one has visited in 90 days." This question he can answer.

Step 1: Scan with Machines, Don't Rely on Human Estimates

Run scripts to scan for concrete numbers:

"Migrate Vue2 to Vue3" is a task that cannot be started. "Change these 87 filter instances" is a task that can be started.

Step 2: Sort into Three Buckets

Based on the table above, categorize into A (Script) / B (AI) / C (Human decision).

The handling principle for the C bucket is most important: Don't get bogged down debating during the migration process. When you encounter one, register it, skip it, and move on. Gather a batch before making a centralized decision—otherwise, you'll get stuck on the 3rd file for two days, and the whole project dies there.

Step 3: Work from Leaves to Root

Utility functions / Constants        ← Depend on nothing, do first
    ↓
Base components (Button, Input)
    ↓
Business components
    ↓
Pages

If lower layers are changed incorrectly, everything above breaks; if upper layers are changed incorrectly, only they are affected. Also, prioritize the least important pages for the first batch as practice.

Step 4: Every Task Must Have an Executable Completion Standard

This is what "verifiable" means. Not "feels fine," but a command that can be run:

Task: Migrate src/components/UserCard.vue Completion Standard:

  • npm run type-check passes
  • npm run test -- UserCard passes (running the pre-written characterization tests)
  • Screenshot pixel difference from baseline < 0.1%
  • No new any introduced

Without this line, 'hundreds of small tasks' become hundreds of burdens requiring your personal review—in which case, better not to break them down at all.

Realistic Timeline

Phase What to Do
Week 1 Pull analytics data, cut pages no one uses
Weeks 2–3 Scan inventory, sort into buckets, set up verification loop
Weeks 4–6 AI batch supplements characterization tests for existing code
Week 7 Migrate first batch: 5 most peripheral pages, canary release
Afterward Gradually increase batch size weekly; centralized decision-making for C bucket issues

Note: Not a single line of migration code was written in the first six weeks. All spent on preparation to "make migration verifiable."

This is why most migrations fail—everyone jumps straight into changing code, halfway through realizes they can't verify, don't dare to go live, the branch rots for half a year, and finally gets abandoned.

4. A Counter-Intuitive Data Point: three.js Release Cadence Halved

Many people assume AI will accelerate open-source project iteration. I checked three.js's actual release history:

Version Release Date Interval
r180 2025-09-03 —
r181 2025-11-19 2.5 months
r182 2025-12-10 3 weeks
r183 2026-02-20 2.3 months
r184 2026-04-16 2 months
r185 2026-07-01 2.5 months

Only 6 versions were released in the past 10 months. Historically, three.js was on a monthly release cycle for a long time (r160 was Dec 2023, r180 was Sep 2025—20 versions in 21 months).

The year AI became massively popular is precisely the year three.js's release frequency halved.

Why?

Because the premise that "the bottleneck for open-source projects is code writing speed" is wrong. The real bottlenecks are three things AI cannot solve:

  1. Maintainer review bandwidth. AI makes submitting PRs extremely easy, resulting in a surge in PR quantity but a drop in quality—a flood of code that looks plausible but actually misunderstands the context. AI accelerates the submission side, not the review side; the queue only gets longer.
  2. Design decisions cannot be outsourced. "Should the WebGPU and WebGL APIs be unified, and how do old users migrate" is a judgment call, not a coding task. AI can list the pros and cons of three approaches, but who bears the consequences of choosing wrong?
  3. The responsibility of backward compatibility. Millions of developers rely on it; every API change forces a batch of projects to follow suit.

Another Layer Worth Noting: AI Makes "Changing APIs" More Expensive

AI's "muscle memory" comes from training data, and the vast majority of that training data is old version syntax. When you change an API:

The value of API stability has risen in the AI era, and the hidden cost of breaking changes has increased. The rational choice for frameworks is actually to be more conservative, slower, and more cautious.

This is still the same theme: Certainty has become more expensive.

While We're At It: "Do We Still Need Frameworks with AI?"

Yes. Because the value of a framework was never "helping you write less code"—if that were all, AI could indeed replace it.

What a framework truly provides are three things:

① Verified Correctness. A Matrix4 that has run for over a decade, battle-tested by millions of developers on all sorts of weird GPUs and browsers, versus one generated on the spot by AI—functionally they might be the same, but reliability differs by orders of magnitude. AI can generate code that "looks right," but it cannot generate the attribute of "having been verified by ten years of time."

② Code Ultimately Has to Run on Something. If you don't use three.js, AI has to build you a mini three.js on the spot—WebGPU initialization, shader compilation, geometry buffers, camera transforms, not a single line can be omitted. AI doesn't eliminate complexity; it just changes who writes that complexity. And once written, that complexity is yours to maintain.

③ Socialization of Maintenance Costs. Six months later, Chrome updates, WebGPU behavior changes, iOS Safari has a bug—who is going to fix your 3000 lines of AI-generated rendering code? With a framework, the answer is npm update.

This is the framework's hardest value: turning maintenance cost from 'you carry it alone' to 'shared globally.' This value AI cannot touch at all.

5. The State of Frontend Libraries in 2026 (Real-time npm Data)

Since technology choices still matter, here are the real download numbers for each domain (npm last 7 days, queried 2026-08-11).

Three reading traps first:

  1. Downloads ≠ Users. CI counts every build; it measures ecosystem penetration. Relative multiples are meaningful, absolute numbers are not.
  2. The top-ranked ones are often not actively chosen. ajv (366M), nanoid, qs, postcss are all pulled in indirectly by other packages.
  3. Domestic Chinese library numbers are systematically low. antd, element-plus, echarts heavily use cnpm/private mirrors, not counted in npm stats; real usage should be significantly revised upwards.

Frameworks / Meta-Frameworks

Library Weekly Downloads Judgment
react 163M De facto standard, thickest ecosystem, hiring pool, and AI training data
vue 14.55M Global second place, share in China far higher than this
@angular/core 5.98M Large enterprise internal systems, full-suite out-of-the-box
svelte 5.27M Lowest mental overhead, ecosystem and hiring are weak points
next 52.35M Default answer for React meta-framework
astro 4.44M Optimal solution for content sites / doc sites / marketing pages
nuxt 2M Vue's counterpart to Next
gatsby 0.3M Already dead, do not touch for new projects

Build Chain — Dynasty Change Complete

Library Weekly Downloads Comparison
vite 164M 3x webpack
webpack 55.01M Legacy only
pnpm 153M 16x yarn
yarn 9.66M Eliminated
@rspack/core 8.48M Rust-based webpack-compatible alternative, for speeding up legacy projects

This column's signal is clearest: vite + pnpm, there is no second answer.

Types & Validation

Library Weekly Downloads
typescript 260M
zod 254M (almost caught up to TS)
yup / joi / valibot 12.36 / 23.75 / 16.86M

zod deserves a separate mention: it's no longer just a "form validation library," but a bridge between runtime and the type system—one schema simultaneously produces TS types + runtime validation, used for API responses, forms, environment variables, and AI structured output.

State Management & Data Fetching

Library Weekly Downloads Judgment
@tanstack/react-query 63.7M Standard answer for server-state
zustand 50.58M First choice for client-state
redux / @reduxjs/toolkit 41.03 / 26.97M Legacy projects
pinia 4.63M Only answer for Vue

Cognitive update: What most people think of as 'state management problems' are actually server data caching problems. Once solved with React Query, the actual client state is pitifully small, zustand handles it in a few dozen lines. Stop installing the whole Redux toolkit.

Styling & UI

Library Weekly Downloads Judgment
tailwindcss 121M Has become the default, works extremely well with AI generation
@radix-ui/react-dialog 69.68M Headless component base
lucide-react 97.45M Icon first choice
@mui/material 10.15M Full-suite solution, painful to customize styles
styled-components 10.93M In decline, runtime overhead criticized
antd 3.62M* De facto standard for admin panels (real domestic volume much higher)

Biggest trend: Shift from 'full-suite component libraries' to 'headless components + own style control'.

shadcn/ui itself isn't an npm package (it copies source code into your project), so numbers can't be queried, but the entire chain it popularized has astonishing data.

Why this model won: The pain point of traditional component libraries is "fighting it just to change a style." The headless approach separates behavior (accessibility, keyboard, focus management) from appearance—the hard part uses the library, the simple part you write yourself. Plus, the code is in your repo, AI can directly read and modify it.

But admin panels are an exception: For tables, forms, permissions, antd / element-plus remain the most efficient solution; don't reinvent them just to chase trends.

3D / Graphics / Animation

Library Weekly Downloads Use Case
three 14.22M 3D de facto standard
@react-three/fiber + drei 5.03 + 3.84M Standard way to use three in React
pixi.js 0.91M 2D high performance (games, particles)—don't use three for 2D
konva / fabric 2.56 / 0.9M Canvas graphics editors (whiteboards, poster designers)
framer-motion + motion 42.86 + 17.58M Same library (renamed to motion), combined ~60M
gsap 4.45M Complex timelines, creative sites
lottie-web 7.16M Play After Effects exported animations

Charts & Maps

Library Weekly Downloads Judgment
recharts 56.95M #1 in React ecosystem
echarts 4.68M* De facto standard for domestic admin panels, strongest for complex charts
chart.js 12.64M Lightweight, framework-agnostic
d3 17.73M Not a chart library, it's visualization low-level building blocks
leaflet 6.67M Lightweight map first choice
maplibre-gl 4.02M Vector maps (Mapbox open-source fork, no licensing risk)

Rich Text Editors (Easiest Pitfall Direction)

Library Weekly Downloads
@tiptap/core 17.03M (Headless solution based on ProseMirror, currently the optimal solution)
quill 10.85M (Out-of-the-box, hard to customize)
lexical 4.64M (By Meta, ecosystem still young)
monaco-editor / codemirror 8.36 / 10.07M (Code editors)

Advice: Rich text is one of the deepest pits in frontend, never write your own.

Testing & Code Quality — This Column Has Also Changed Generations

Library Weekly Downloads Comparison
vitest 89.74M 2x jest
jest 46.33M Legacy
@playwright/test 52.79M 7x cypress
cypress 7.36M Defeated
@testing-library/react 52.63M Component testing standard
@biomejs/biome 12.54M Rust-based eslint+prettier in one, dozens of times faster

Utilities

Library Weekly Downloads Judgment
date-fns / dayjs 98.31 / 66.47M moment (35.78M) is unmaintained, do not use for new projects
axios 120M Still the dominator
es-toolkit 41.67M Modern lodash alternative, growing fast, 2–3x smaller bundle size
@dnd-kit/core 22.8M Drag-and-drop first choice (react-beautiful-dnd is unmaintained)
@tanstack/react-virtual 21.14M Virtual list (react-window successor)

6 Signals from the Data

  1. Build chain has completed its generational shift: vite defeated webpack (3:1), pnpm defeated yarn (16:1). Teams still on webpack + yarn are on outdated configurations.
  2. Testing chain has also shifted: vitest surpassed jest (2:1), Playwright crushed Cypress (7:1). These two replacements have low cost and direct benefits.
  3. zod has become new infrastructure, volume rivaling TypeScript itself.
  4. 'Headless components + Tailwind' defeated 'full-suite component libraries' (for B2C scenarios), admin panels remain antd/element territory.
  5. The Redux era is over: React Query + zustand is the new standard combo.
  6. Old libraries are dying in batches: moment, gatsby, formik, react-beautiful-dnd, cypress, styled-components are all in clear decline.

Practical advice: Run this list against your package.json; anything hitting the decline column is the first batch of tech debt candidates. And these replacements (moment→dayjs, jest→vitest, yarn→pnpm) are behaviorally equivalent with clear verification standards—precisely the kind of work best suited for AI to do in batches.

Add a New Dimension When Choosing Tech: Is AI Familiar with It?

This is already a real cost item. With mainstream libraries, AI-generated code is mostly usable; with obscure libraries, AI starts hallucinating APIs.

But beware the version trap—AI training data skews towards older versions; it will give you Redux instead of zustand, react-router-dom instead of v7's react-router, moment instead of dayjs, three's WebGLRenderer instead of WebGPURenderer.

The solution is still that one sentence: Lock your tech choices and banned list in CLAUDE.md.

6. Will Frontend Engineers Be Eliminated?

Many companies are starting to hire full-stack, letting backend devs casually write simple pages, and laying off frontend. My view might differ from the mainstream.

First, Get the Attribution Right

Frontend role contraction started in 2022, a full two years before AI programming tools became widespread. Blaming it on AI doesn't match the timeline.

The real reasons are threefold:

  1. Previous over-hiring was extreme. Frontend expanded the fastest among all roles—shortest training cycle, lowest barrier to entry. A large part of the current situation is just regression to the normal waterline.
  2. Demand-side contraction, not supply-side replacement. Previously, every business line needed an App, official website, mini-program, campaign page; now these projects simply aren't being initiated. It's not 'the same work is being done by AI,' it's 'this work is no longer wanted.'
  3. The toolchain maturing itself lowered the barrier. This lowering happened before AI.

AI is an accelerator, not the cause.

The Essence of "Full-Stackification" Is an Economics Problem

The premise for the existence of specialization is benefits of specialization > costs of collaboration.

Back when frontend and backend separated, it was because frontend became too complex for backend devs to learn; learning cost > communication cost, so they split.

Now AI has driven down the cross-stack learning cost. When the cost of "backend dev casually learning some frontend" is lower than the cost of "frontend and backend aligning on interfaces, integrating, and arguing," merging naturally occurs.

Key corollary: This scale is bidirectional.

The boundary is moving, but there's no rule it must tilt towards the backend. Frontend expanding into backend is actually easier—you already know TypeScript; Node services, BFF, basic data modeling are faster to learn than a backend dev learning CSS layout and browser rendering.

The real question isn't 'will frontend be eaten by backend,' but 'who moves first, you or him.' The person sitting still waiting for the boundary to crush them will be eaten, regardless of which side they started on.

What's Being Eliminated Isn't "Frontend," It's "People Who Only Turn Design Mockups into Code"

Two things must be distinguished:

What's truly being eaten is a very specific segment: "looking at a design mockup and coding it out." This is the most standardized, least uncertain part of all frontend work. And the brutal reality is—many frontend devs spend 80% of their time doing exactly this.

So the accurate statement is: The middle layer is collapsing. Junior frontend devs are most at risk; demand for people who can handle complex problems is actually rising. This isn't an industry disappearing; it's the industry's median bar being raised.

What Cannot Be Eaten

  1. Complex state and interaction on the client. Collaborative editing, real-time whiteboards, visual orchestration, drag-and-drop builders, offline sync. These aren't 'pages'; they are distributed systems running in the browser. AI can write each local part, but cannot sustain the overall state consistency design.
  2. Performance and experience engineering. First paint, bundle size, memory leaks, long lists, animation jank. The key point—people who casually write pages don't even know these problems exist, and AI won't proactively warn you.
  3. The quagmire of cross-platform and compatibility. iOS Safari quirks, WeChat webview, old Android. This experience isn't in any documentation, and therefore isn't in AI's training data.
  4. Translating vague intent into concrete interaction. What exactly does the product manager mean by "make this smoother"? That's judgment, not coding.
  5. Architecture and standards. This one is even more important in the AI era—code production speed is up, so corruption speed is also up. A project that used to rot in a year can now rot in three months.

A Counter-Intuitive Judgment: AI Might Make Frontend More Valuable

When the cost of 'implementation' approaches zero, all differentiation shifts to 'experience'.

If every company can use AI to build a functionally identical product in two weeks, why would users choose yours? Only faster, smoother, better-looking, with more thoughtful details.

Software's value is shifting from 'does it have this feature' to 'is it pleasant to use.' And the latter is precisely frontend's home turf.

The printing press made 'being able to write' completely worthless, but made 'writing well' more valuable than ever. Tool revolutions destroy the floor of capability, but raise the ceiling of reward.

A Side Reminder: Letting Backend Casually Write Pages, the Cost Comes Due in Two or Three Years

For truly simple pages, this is a reasonable decision. But there's a hidden cost: this code has no owner.

A backend dev's goal writing frontend is "it runs," not caring about component reuse, state management, bundle size, or style pollution. After three years of accumulation, you'll have a frontend codebase with no architecture that no one dares to touch—and by then, the original frontend team has already been laid off.

This isn't doom-saying; it's a time-lag problem: the benefits of merging are immediately visible, the costs only appear two or three years later.

As a tech lead, what you can do isn't argue "should we keep frontend," but draw a line: which parts are "simple pages anyone can write," and which are "core product experience, must have someone responsible for architecture."

7. The New Battlefield: AI Productization

It's Not Adding a Chatbox in the Bottom Right Corner

The real definition:

Packaging the model's 'probabilistic, error-prone, slow, uncertain' capabilities into a product form that users dare to use, can verify, can correct, and can bear the consequences of.

There's a fundamental contradiction here:

Bridging the gap between these two is the entire engineering content of AI productization. And this work overwhelmingly falls on the frontend.

Problem Why Traditional Solutions Fail What Frontend Must Solve
Waiting AI takes seconds to minutes; users leave if they see a spinner Show 'what it's doing'—thinking process, tool calls, stage progress
Streaming Content arrives character by character How to render half a code block, layout must not jitter, should it keep following if the user scrolls up, interruptible at any time
Error-prone Traditional UI assumes results are correct Confidence levels, source citations, letting users see at a glance where it might be wrong
Consequential operations Click and it executes Preview → Confirm → Execute → Undoable → Auditable
Correction If wrong, must start over Let users correct at low cost, rather than re-describing everything

Note: None of these five things have anything to do with 'calling the model API.' Calling the API is ten lines of code; the remaining 90% of the engineering effort is entirely in this table.

This is why AI productization is a frontend opportunity—the hard part happens to be on the client side.

Admin Panels Are Especially Suitable

Many people think AI productization is for B2C. Quite the opposite—admin panels might be the best scenario for AI implementation: clear operational boundaries, users are internal employees with higher fault tolerance, massive real pain points of repetitive tedious work, data all within their own systems.

A few examples that could start next week:

① Natural Language Filtering

An order list has 20 filter options; a user wants "Shanghai, last month, amount over 10k, unshipped"—requires 8 clicks.

The key design for AI-ification is not to directly give results, but to give 'filled-in filter conditions':

User input: Shanghai last month amount>10k unshipped
    ↓
[Region: Shanghai ×] [Time: 2026-07-01 ~ 07-31 ×] [Amount: >10000 ×] [Status: Unshipped ×]
    ↓ User sees it, can directly modify
Click 'Search' (hits your original API)

The user can see what the AI understood, can modify it, and isn't panicked by errors.

Contrast with bad design: directly dumping results. The user doesn't know what it filtered, can't discover errors—this kind of feature sees zero usage after three weeks online.

② Document / Image → Auto-fill Form (Highest ROI)

The biggest time sink in admin panels is manually copying unstructured information into the system.

The key design is field-level traceability: each auto-filled value is marked with its source in the original text; hovering highlights the corresponding position in the right-side PDF; uncertain fields are highlighted yellow and require mandatory confirmation.

The human's role shifts from 'data entry' to 'verification.' This shift is psychologically acceptable—no one wants a machine to sign for them, but everyone wants a machine to draft for them.

③ Intent Execution for Batch Operations

"Raise the price of these 200 products by 5%, but don't touch those with stock below 10":

1. User describes intent in plain language
2. AI parses → generates [Preview List]: which 187 will change, to what, which 13 are skipped, why
3. User scans, can manually remove a few entries
4. Confirm execution
5. Top shows 'Modified 187 entries [Undo]', retained for 24 hours
6. Operation log: who, when, what command, what changed

Steps 2, 4, 5, and 6 are 80% of the total engineering effort, and all are frontend work. Step 1, calling the model, is only 5%.

④ Approval Assistance

Don't let AI approve on behalf of humans. The correct approach is to organize the information needed for decision-making and present it to the approver in advance: history, which rules were triggered (with original text), how similar cases were handled, a one-line suggestion + reason. The human just clicks approve or reject.

Pattern: AI does 90% of the information gathering, humans make 10% of the decisions.

This is the safest AI form for admin panels—because the responsibility boundary hasn't changed; the human still signs.

⑤ Natural Language Report Generation

What AI outputs isn't text, but a chart configuration object (like an echarts option), which the frontend directly renders.

Safety red line: AI only produces 'query parameters + chart configuration'; data queries go through existing, permission-checked APIs. Absolutely do not let the model directly generate SQL hitting the production database.

The Most Important Principle: Don't Build a Chatbox

The form of AI-ification for admin panels should be 'AI-enhanced existing interfaces,' not 'adding a Copilot sidebar.'

Because admin panel users are skilled workers. They use the same interface dozens of times daily, knowing button positions with their eyes closed. For them, typing a paragraph describing their need is slower and more tiring than clicking three times.

The failure path for most companies is identical: spend two months building a beautiful Copilot sidebar, launch it, people try it out of novelty for the first two weeks, open rate drops to zero after a month.

The correct landing points are those specific 'currently really annoying' steps—adding natural language input next to the filter bar, adding 'Import from Document' at the top of a form, adding 'Batch Intent Operation' on a list page.

The judgment standard is one sentence: Does it reduce the user's number of clicks and waiting time? If it reduces them, it's a good feature; if it just 'looks AI,' it's self-indulgence.

Specific Skills Worth Building

  1. Structured Output—Getting the model to stably return according to your schema (zod + structured output), rather than parsing natural language. This is the foundation for all AI features.
  2. Streaming Rendering—SSE, incremental markdown parsing, interruption and retry.
  3. Human-in-the-loop Interaction Patterns—Preview, confirm, undo, audit. Design ability more than coding ability.
  4. Cost Awareness—Frontend needs to control context size. This is a new performance optimization dimension.
  5. Failure Fallback—Model timeout, returned format wrong, content blocked. Traditional frontend has no concept of 'the API returned, but the content is wrong'; AI frontend encounters this daily.

Summary: Six Questions, One Answer

Looking back, the six things discussed in this article actually have the same answer:

Question Answer
What to do after getting AI programming tools? Not writing skills, but building context provision and verification loops
How to do large-scale migration? The difficulty isn't changing syntax, it's building the ability to know 'how do I know I didn't break anything'
Why did three.js slow down? Because in the AI era, the cost of breaking changes has risen
Do we still need mature frameworks? Yes, because they provide correctness verified by time
Will frontend be eliminated? What's eliminated is 'implementation'; what remains is judgment and constraint
What's hard about AI productization? 90% of the engineering is in making uncertain output trustworthy and controllable

Six answers point to the same thing:

AI has made producing code cheaper, so certainty has become more expensive.

This is the migration of value distribution happening across the entire industry. Your value no longer depends on how much code you can write, but on how much uncertainty you can take responsibility for.

Specific to action, three things in order of priority:

  1. Fill in the 'verification' gap. Strict types, tests, screenshot comparison, CI. This isn't just for AI—it's simultaneously the chassis of your team's engineering capability.
  2. Make 'decisions' explicit. Tech choices, architectural constraints, banned lists, all written into documentation. Previously this was optional; now, if you don't write it, AI will overwrite your architecture with the old world from its training data.
  3. Actively expand outward. Expand towards backend, towards product, towards the new battlefield of AI productization. Roles responsible for code can be merged; people responsible for outcomes cannot.

Finally, a frank word: In every round of tool revolution, the loudest cries of 'XX is going to be eliminated' almost always come from people outside the industry.

What actually happens is never 'disappearance,' but the definition of the profession being rewritten, with some people keeping up and some not.

You, reading this article right now, thinking about what to do, are already among those keeping up.

The npm download data in this article was queried in real-time via the npm registry API on 2026-08-11, representing the last 7 days of downloads. three.js version information comes from GitHub Releases.