The Frontend-to-AI-Full-Stack Roadmap That Skips the Hype

Recently, "frontend is dead, full-stack is eternal" has started circulating in tech circles again.

Alipay's Experience Technology Department has been disbanded and split, with existing staff reassigned to various business lines. After this news spread, many people took it a step further, turning it into "the frontend as an independent role will definitely disappear."

A more accurate fact is that Alipay's Experience Technology Department AFX, as a typical frontend middle-platform, has been broken up and embedded into business lines. In public information, job titles have been uniformly adjusted from Frontend Engineer to Agent Development Full-Stack Engineer. This isn't Alipay not needing frontend anymore, but rather the middle-platform model hitting its boundaries during the AI implementation phase.

Over the past seven or eight years, middle-platforms concentrated general technologies and capabilities to reduce redundant wheel-building and unify standards, and indeed nurtured large teams during peak periods. AFX successively incubated products like Ant Design, AntV, Egg.js, and Yuque, which are still widely used today, proving that the middle-platform was once effective. Controversy also persisted: when too far from the business, response was slow and decision chains were long. Once business entered rapid iteration, the middle-platform easily became a bottleneck.

Large language models have pushed this contradiction to the surface. AI Agents are rewriting how users interact with products, stretching traditional frontend boundaries. Engineers also need to supplement large model invocation, logic orchestration, and server-side integration. Centralized supply struggles to keep up with this change; embedding people into business lines makes it easier to adapt closely to scenarios. Over the past two years, several leading companies have already downsized or dismantled middle-platforms. Alipay's change this time is not an isolated case; it's more like a microcosm of an industry shift.

Organizational boundaries can be adjusted, but engineering problems won't disappear along with them. AFX's public homepage is still updating a mini-program Markdown renderer for AI streaming output, a multimodal model for mobile UX defect diagnosis, Agent memory, Rust toolchains, and infrastructure around AI engineering. Frontend work still exists, but it no longer revolves solely around pages, components, and API integration.

Similar changes are appearing in Next.js. The Next.js team released Building Next.js for an agentic future in 2026, explicitly proposing to treat Coding Agents as first-class users of the framework. The framework is starting to proactively provide Agents with version-matched documentation, runtime errors, browser logs, routing information, and debugging capabilities, rather than just waiting for models to guess project behavior based on training data.

Alipay's AI Pay has also provided documentation and Skill installation methods for Coding Agents. Developers can install the Alipay payment Skill via npx, then let tools like Cursor or Claude Code read the rules and assist with integration. This indicates that AI Coding is moving from a personal productivity tool into the formal delivery chain of frameworks, SDKs, payments, and enterprise services.

What frontend needs to supplement next is not changing a framework name, nor adding "can call large models" to a resume. A more realistic sequence is roughly as follows:

• First, integrate AI Coding Agents into daily development
• Then, write project specifications, Skills, and verification processes clearly and hand them over to the Agent
• Simultaneously, supplement server-side, database, and deployment knowledge
• Then enter the AI core: first understand large model architecture, then learn decoding parameters, structured output, and caching
• Next, work on Prompt, Context, Memory, then learn Embedding, BM25, RAG, and Function Calling
• For tool exposure, distinguish between in-process tools, CLI, and MCP, then connect Skills to the Agent, using LangChain and LangGraph for orchestration
• Only when truly necessary, add intent recognition, Supervisor, and Multi-Agent
• Before going live, supplement evaluation and AI monitoring, distinguishing which segments Promptfoo, Langfuse, LangSmith, Helicone, and Phoenix each manage

Memorizing all the terms is useless. It's best to verify in your own projects where you'll get stuck if a piece is missing, and what accidents can happen if used incorrectly.

Frontend Frameworks Are Simultaneously Serving Human Developers and Coding Agents

In the past, evaluating a frontend framework mainly depended on whether it allowed developers to write pages, organize routes, request data, and complete builds faster.

Going forward, another judgment criterion must be added:

Can the Coding Agent accurately understand this project and modify and verify code in a real runtime environment?

An Agent can read files but doesn't necessarily know what's happening in the browser. When a developer sees a Hydration Error, they can observe the page, console, and error overlay; by default, an Agent can only see the source code and terminal output. When a user just tells it "fix the page error," it likely hasn't even obtained the specific error and can only guess from the code structure.

Next.js has therefore started exposing runtime status to Agents. The DevTools MCP allows MCP-enabled Coding Agents to access errors, routes, rendering information, and runtime status in the development server. According to the Next.js AI Coding Agents guide, the framework will also place documentation matching the currently installed version into the next package and guide the Agent to read local documentation first via AGENTS.md in the project root, avoiding reliance on outdated training knowledge.

Once the framework supplements these capabilities, the daily routine of a frontend engineer will also change. Reading docs, writing code, and fixing bugs remain, but an additional layer of work is added:

• Preparing accurate project context for the Agent
• Clearly writing which directories can be modified and which cannot
• Writing framework versions and project specifications into machine-readable files
• Allowing the Agent to see browser errors and runtime logs
• Distilling common tasks into project Skills
• Using type checking, testing, and browser verification as safety nets
• Reviewing whether the Agent has expanded the scope of modifications
• Taking responsibility for the final result merged into the main branch

If any of these links are missing, generated code is prone to rework. Insufficient context, wrong framework version, inability to see runtime errors, tests not catching issues, and reviews not catching problems will all send the result back for rework.

Making it easier for Agents to write code doesn't mean engineers can understand the framework less. Problems like incorrect caching strategies, server-side data leaking to the client, broken authentication, and bloated bundles still require a human to recognize first.

In the future, what frontend will do more often is define clear boundaries, letting humans and Agents deliver results together, rather than personally typing out every line.

Phase 1: First Turn AI Coding into a Project Capability

Don't rush to learn LangChain at this step, nor memorize Transformers, Embeddings, and vector databases first. First, integrate AI Coding tools into real projects. Common ones abroad include Claude Code, Codex, Cursor, and Gemini CLI; domestically, you also need to become proficient with tools like Trae, Tongyi Lingma, Wenxin Kuaicode, and CodeBuddy. Tool interfaces differ, but project-level usage follows the same set of principles.

Many people are already using them but are still stuck at "help me write a page" or "help me fix a bug." This is suitable for trials but not for long-term maintenance. The Agent doesn't know why the project was designed this way, which files cannot be touched, or what constitutes completion, making it easy to mistakenly alter business boundaries.

What needs to be practiced at this stage is project-level usage, advancing through the following steps.

First, Understand the Agent's Permissions and Working Methods

Before starting, clarify what it can currently do:

• Which directories can it read
• Can it directly modify files
• Can it run Shell commands, and which commands require manual approval
• Can it access the network, environment variables, and secrets
• Is it running in a sandbox or isolated Worktree
• How to resume after a session interruption
• Where to view the Diff after changes
• What evidence proves the task is done

Different tools may have different names for approval switches, sandboxes, and Worktrees, but these questions must be answered clearly before letting it touch a real project.

When entering an unfamiliar project, don't start with large features. Practice in this order:

• Read-only reconnaissance: Explain the entry point, modules, state management, data flow, dependencies, test commands, and high-risk directories. Speculation must be marked as such.
• Small-scope changes: Only modify specified features, forbidden from touching common components and unrelated files. Before changing, state the scope of impact and verification plan. After changing, run checks and list unresolved risks.
• Fixed rhythm: Evidence first, then plan, then modification, finally verification. The Agent saying "done" doesn't count as finished.

Once these three steps are running smoothly, then talk about project rules and Skills. Opening up large features without understanding permissions makes it very hard to clean up later.

Write Project Rules into the Repository

Don't re-explain the tech stack, directories, and test commands verbally at the start of every new session. Write long-term stable knowledge into the repository, such as AGENTS.md, CLAUDE.md, architecture descriptions, development specifications, testing instructions, security boundaries, and data constraints. If domestic tools have other project description files, also put them in the repository; don't just leave them in chat logs.

The content written should be short, only keeping things that must be followed for every task:

• Tech stack and directory responsibilities
• How state and data flow
• Common development, check, and test commands
• Which modules cannot be arbitrarily modified
• Which operations must be manually confirmed
• What verifications must be run before completion
• Which secrets and configurations cannot enter the repository

Manual-style long documents waste tokens and dilute the truly important constraints. Long-term rules go into project context; practices for a specific type of task are then distilled into Skills.

Distill Repetitive Tasks into Skills

Project rules govern boundaries that must be respected every time; Skills govern how a class of repeatable tasks should be done; the current Prompt only describes the goal this one time. According to Anthropic's Agent Skills documentation, Skills can be loaded on demand. A project can have many, but only the relevant ones are pulled each time. If domestic tools provide project-level skills, rule packages, or workflow templates, distill them following the same boundaries.

Open-source Skills are mostly general capabilities or adapted for a specific scenario. They can be used as reference, but you can't expect installing a set to cover your own project. What truly needs to be written are Skills customized to project requirements: your business boundaries, directories forbidden from modification, acceptance criteria, and how to stop on failure—only you know these best.

What needs to be done at this step:

• First, pick recurring tasks from your own project, such as unit adaptation, bug location, review, release checks
• For each Skill, clearly write trigger conditions, what to read, work sequence, what can be touched, what cannot, what constitutes completion, and when to stop when uncertain
• Use open-source Skills only as templates or comparisons, modifying them to fit this repository's rules before use
• Test triggering with several types of tasks: the right ones should hit, the wrong ones shouldn't misfire, and it should stop and ask when hitting forbidden zones
• Deterministic checks that can be blocked by scripts should be handed to scripts, not left entirely to model judgment

In Claude Code, project-level Skills are generally placed in .claude/skills/; personal, universal ones can be placed in ~/.claude/skills/. For other tools, place them in their respective conventional directories. For how to write the specific files, follow the official documentation. At this stage, just establish the boundaries and processes.

Once these capabilities are running together, project-level AI Coding can be considered formed, rather than just having installed a CLI or piled up a bunch of open-source Skills.

How to judge if this phase is passed is not by how many tools are installed. When a new session starts, if the Agent can read project rules, match relevant Skills, state a plan first, only modify the allowed scope, run the prescribed checks, and hand over Diffs and test evidence that can be manually verified, this phase is complete.

Phase 2: For Backend, First Decide Node vs. Non-Node; No Need to Choose All Languages at Once

When frontend developers supplement backend skills, the easiest time sink is language comparison: Node, Go, Java, Python—which one to learn. The standard is actually very simple: whether Node or another language, the one that lets you get started fastest and run an end-to-end project quickest is the better choice.

Don't decide now what language you'll use for the next ten years. First, choose a path based on real constraints and get through it:

• Without clear restrictions, prioritize Node, reusing existing JavaScript or TypeScript to reduce one variable change
• If the company, position, or existing business is already bound to a non-Node tech stack, just follow that stack. Don't switch languages just for the "full-stack" persona

Both paths can get you started. The key is to start building immediately after choosing, not to spread yourself thin on both simultaneously.

Without Hard Constraints, Node Usually Gets You Started Faster

When already familiar with TypeScript and npm, continuing with Node allows you to focus energy on the backend problems you're truly missing:

• How HTTP and authentication enter the service
• How to model databases, how to handle transaction failures
• When to invalidate caches, how to retry asynchronous tasks
• How to recover after an SSE disconnection
• Where to save Agent state, how to audit tool calls

Many AI Coding tools and Agent toolchains also align closely with Node and npm. Claude Code's Getting Started documentation has long provided npm installation and listed the Node.js runtime environment. This doesn't mean you must choose Node; it just illustrates that during the first transition, learning one less new language usually lets you encounter real engineering problems faster.

When Production Constraints Exist, Following the Existing Stack Is Faster

If the target team's permissions, transactions, data, and infrastructure are already built on Go, Java, Python, or another stack, continuing with it is usually faster than starting a separate Node service. Deployment, collaboration, and go-live paths are already in place, and the entry cost is often lower.

Model invocation, streaming responses, structured output, Prompt, caching, RAG, Tool Calling, Agent state, task orchestration, evaluation, and monitoring are not bound to Node. You can switch languages, but the learning focus remains databases, transactions, concurrency, permissions, messaging, and deployment. Just rewriting CRUD in a different syntax doesn't count as supplementing backend knowledge.

When choosing a path, only look at three things:

• Which path can deliver end-to-end results for the current project faster
• What the target team's real production system uses
• Whether what's blocking you now is the language itself, or insufficient backend fundamentals

Long-term language comparison without producing a runnable project is the most common waste on this path.

Node can be a low-cost path into the server side; non-Node can be a path directly into a real production system. The standard isn't which language is more advanced, but which path gets you hands-on and delivering faster. Later, when positions and business change, the tech stack can be adjusted again.

Phase 3: Supplement General Full-Stack First; Don't Use AI to Mask Backend Fundamentals

AI products are, first and foremost, still software products. If users, organizations, permissions, databases, files, tasks, and logs aren't handled well, plugging in a model will only add a pile of inexplicable failures.

At this stage, first build a task system that doesn't include a model, getting general full-stack capabilities running smoothly. You can use Next.js Route Handlers and Server Actions to build server-side intuition, but don't treat them as shortcuts to bypass the backend. What truly needs to be supplemented is this:

• HTTP request lifecycle, parameter validation, and exception handling
• Authentication, authorization, and multi-tenant data isolation
• Relational databases: table design, unique constraints, transactions, concurrent updates, indexing, and pagination
• Redis: caching, sessions, rate limiting, distributed locks, and how to handle cache invalidation
• Message queues and asynchronous tasks: dispatch, consumption, retry, deduplication, failure dead letters
• File uploads, SSE or long connections, and how to recover task status after disconnection
• Docker deployment, structured logging, and basic monitoring and alerting
• Unit testing and integration testing; secrets and sensitive configurations must not enter the repository

Don't just stop at knowing how to use an ORM for databases. How to split tables, which fields need to be unique, how to express one-to-many and many-to-many relationships, which write operations must be in the same transaction, how to avoid overwrites during concurrent updates, how permission conditions enter queries—all these need to be thought through yourself. In a project, you can first build users, organizations, members, projects, tasks, files, and audit logs, then actively construct duplicate submissions, concurrent modifications, permission boundary violations, and task failures to see how the system behaves.

The same goes for message queues and Redis. The focus isn't on knowing how to call the API, but on clarifying what should be synchronous vs. asynchronous, what to do about duplicate message consumption, and whether unfinished tasks have a clear state after a service restart. Monitoring needs to answer whether, when a request fails, the logs can pinpoint the cause.

How to judge if this phase is passed can be checked against these criteria:

• Data from different organizations cannot be read by each other
• Duplicate requests do not generate two copies of business data
• Asynchronous tasks can retry after failure and won't be silently lost
• After SSE disconnection or service restart, task status is still queryable
• Core interfaces have integration tests; failures can be located via logs
• Secrets and sensitive configurations do not enter the repository

If these problems still can't be overcome, later when connecting an Agent, ordinary engineering errors will easily be packaged as "model instability."

Phase 4: Formally Enter AI Learning, Advancing in This Order

After supplementing general full-stack skills, then enter the AI core. Don't pile on frameworks and multi-agent setups right away. A more stable order is to first understand how models work, then learn to control output, feed context and memory, then do retrieval, Function Calling, and the several ways to expose capabilities to Agents, then connect Skills and orchestration, and finally reach intent recognition, Supervisor, and Multi-Agent.

It is recommended to advance along this line:

• Large model architecture and basic concepts
• Decoding parameters, streaming calls, structured output, and Prompt Cache
• Prompt Engineering
• Context Engineering
• Working memory, short-term memory, and long-term memory
• Embedding, BM25, and RAG
• Function Calling, Tool Calling
• Tool exposure methods: in-process tools, CLI, MCP
• Connecting Skills to Agents
• LangChain and LangGraph
• Intent recognition, Supervisor, and Multi-Agent

If the earlier parts aren't understood, it's easy to misdiagnose engineering problems as model capability problems later.

First, Understand What Large Models Are Doing

First, build engineering-oriented intuition. No need to derive formulas from scratch, but at least clarify:

• Tokens, context windows, how input and output are billed
• Transformer intuition: how the model predicts the next token based on existing tokens
• What problems pre-training, fine-tuning, and alignment each solve
• Why hallucinations occur, why mid-constraint forgetting happens, why longer context isn't necessarily better
• What scenarios chat models, reasoning models, and embedding models are respectively suitable for

The goal isn't to become an algorithm researcher, but to know the system boundaries when later tuning parameters, writing Prompts, doing memory, and RAG.

Then Learn Decoding Parameters, Streaming Calls, Structured Output, and Prompt Cache

Knowing how to call an API doesn't equal knowing how to control output. At this step, practice common control items until proficient:

• The impact of temperature, top_p, max_tokens, stop on result stability and diversity
• Streaming output, timeouts, rate limiting, retries, and request cancellation
• Structured output and Schema validation; on missing fields or type errors, retry, fix, or return failure
• How to view input/output tokens, time-to-first-token, and per-call cost

Here, also separate "caching" first. Prompt Cache only addresses the computational cost of repeated prefixes; it's not business memory. Taking Claude as an example, it generally follows the hierarchy of tool definitions, system rules, and message prefixes. Stable content placed at the front and changing content at the back makes cache hits more likely. The Prompt Caching documentation also requires using the cache write and read tokens in the response to judge whether a hit actually occurred. Just turning on the switch without looking at hit rate, latency, and cost is equivalent to not doing it.

Then Design Prompts as Interfaces

Many people understand Prompt Engineering as finding a universal prompt phrase, such as specifying a role, asking for step-by-step thinking, and adding a "please answer seriously." This works for single chats but cannot support an application.

In a system, a Prompt is closer to an interface contract, and at minimum must clearly state:

• Task goal and success criteria
• Where input comes from, what are trusted facts, and what are just user requests
• What the model can and cannot do
• When to initiate Function Calling, when to ask follow-up questions, how to return when unable to complete
• Output structure and failure handling

Anthropic's Prompt Engineering overview lists clear success criteria, executable evaluation methods, and an initial Prompt as prerequisites before starting optimization. Without test samples, so-called optimization is usually just rewording based on one particular answer.

When implementing, start with tasks with clear boundaries like classification, information extraction, and content summarization, then touch open-ended Agents. Output must pass through a Schema; model results must not be directly concatenated into SQL, Shell, file paths, payment amounts, permission parameters, or device controls. Prompts should be versioned by purpose, and after changes, run fixed tests, not just manually ask two or three questions.

Next, Do Context Engineering

Prompt is only one part of the context. A real request will also carry project rules, conversation history, retrieval results, tool definitions, tool returns, task status, and security constraints. These cannot all be unconditionally stuffed into the window.

What Context Engineering needs to answer is what information is truly needed for the current step, what is trustworthy, what is expired, and how to organize it. A common mistake is throwing chat history, all documents, and all tools at the model at once; longer context does not mean better results.

Before assembling context each time, first judge:

• What is the goal of the current step
• Which facts will affect the next step
• Does the information come from the user, database, or model speculation
• Is the data still valid, does it have permissions
• Should the original text be kept or just a summary
• After the step ends, which information needs to be written back to state or the memory layer

If you can't answer clearly, you shouldn't stuff the entire block of data in as-is. Stable prefixes are suitable for Prompt Cache; dynamic retrieval and current questions are built per step.

Learn Memory Separately and Clearly; Don't Confuse It with Cache and RAG

Many projects treat "stuffing all chat history back in" as memory, which is insufficient. In engineering, at least three layers must be distinguished:

• Working memory: Temporary state within the current round of the Agent loop, such as the step being executed, intermediate tool results, items pending confirmation
• Short-term memory: Conversation summaries and key conclusions still valid within the current session, limited by the context window, usually requiring compression, truncation, or summarization; cannot infinitely append original text
• Long-term memory: Facts that need to be retained across sessions, such as user preferences, project conventions, historical decision summaries, stored in a database or dedicated memory store, retrieved when needed

At the same time, draw clear boundaries with three other things:

• Prompt Cache: Saves computational cost of repeated prefixes, not responsible for remembering who the user is
• RAG: Retrieves external knowledge documents, not equivalent to personal or task memory
• Checkpoint: Saves task execution progress for interruption recovery, also not equivalent to long-term memory

What needs to be practiced at this step is writing, reading, updating, forgetting, and permissions. What content deserves to enter long-term memory, what can only stay in short-term summaries, which tool results are discarded after use, when to summarize and when to keep the original text—all need rules. Otherwise, the Agent will either suffer amnesia or remember expired, unauthorized, and noisy information together.

Then Learn Embedding and BM25, and Build RAG as a Data System

After having context and memory, then do external knowledge access. Retrieval requires at least two paths:

• Embedding vector retrieval: Suitable for semantically similar questions with different phrasing but similar meaning
• BM25 and other keyword retrieval: Suitable for queries requiring exact matches, like error codes, API names, product numbers, proper nouns

The problems solved by the two paths are different: using only Embedding, exact terms are easily missed; using only BM25, rephrased queries may not be found. Real projects usually do hybrid retrieval, running vector recall and BM25 recall in parallel, then applying Metadata Filters, result fusion, and Rerank as appropriate.

RAG is far more than "document chunking, writing to a vector database, similarity retrieval"; it's a continuously maintained data pipeline:

• Document parsing and cleaning, preserving titles, sources, versions, and page numbers
• Chunking by document type, not just by character count
• Embedding recall plus BM25 recall, with Metadata Filter, fusion, and Rerank when necessary
• Permissions enforced before retrieval; cannot recall first and then let the model decide if viewing is allowed
• When documents are updated or deleted, vectors, full-text indexes, and caches are synchronously cleaned
• Establish a fixed question set to check recall, citations, refusal to answer, and permission isolation

Initially, using PostgreSQL with pgvector, combined with full-text search or BM25 for hybrid search, is sufficient. No need to pile on multiple vector databases from the start. Being able to answer questions is just a Demo; being able to update, delete, isolate, cite, and evaluate makes it a RAG system.

Clearly Learn Function Calling, Tool Calling

In the OpenAI ecosystem, it's often called Function Calling; in Anthropic and other documentation, it's often called Tool Use or Tool Calling. They refer to the same thing: the model doesn't actually query databases, send emails, or modify orders. It only returns a structured function or tool call request. The application reads the request, validates parameters, executes the function, and then returns the result as the next message to the model.

Boundaries must be established first: the model is responsible for proposing which function to call and what parameters to pass; the business system is responsible for deciding whether execution is allowed. First, hand-write a minimal loop yourself, clearly writing these contracts:

• Function or tool name, purpose, input/output Schema
• Controls like tool_choice: forced call, auto-select, or forbidden call
• Whether parallel calls to multiple functions are supported
• Timeouts, permissions, whether there are side effects, whether manual approval is required
• Failure results, retry, and idempotency methods
• Maximum loop count, token budget, termination conditions, and audit records

Amount calculations, permission judgments, inventory deductions, and state changes are handed to deterministic programs. Models are suitable for intent recognition, text understanding, candidate solutions, and unstructured organization. Without these constraints, an Agent can easily call the same function repeatedly in a failure branch, or treat "no error reported" as task completion.

How to Expose Tools to Agents: In-Process Tools, CLI, and MCP

Function Calling solves how the model proposes actions, not what form the tools are connected in. At this layer, at least three exposure methods must be distinguished. They are not an upgrade relationship, and certainly not "MCP is more advanced than Function Calling":

• In-process tools: Functions registered within the application process; when the model calls, they execute locally. Low latency, easy to debug, suitable for core business actions
• CLI, Shell: Give the Agent terminal capabilities to directly run git, gh, rg, kubectl, tests, and custom scripts. Very common in Coding Agents; models are well-trained on CLI, piping combinations are strong, token overhead is usually lower
• MCP: Use a unified protocol to discover and call external capabilities, suitable for cross-client reuse, structured Schemas, and external systems requiring unified authentication and auditing. See MCP Server Concepts

Selection can be judged by scenario:

• High-frequency, local, with mature existing commands: prioritize CLI, no need to forcibly wrap a layer of MCP
• When needing to share the same set of external capabilities across Cursor, Claude Code, and self-built Agents, or when strong type discovery is needed: then use MCP
• Core business database writes, payments, permission checks: prioritize in-process tools plus a gateway, don't just rely on the model piecing together commands

MCP's Tools specification also emphasizes that sensitive tools must be able to refuse, servers must validate and rate-limit, and clients must confirm, timeout, and audit. Whether using CLI or MCP, permissions, idempotency, and auditing cannot be omitted. In production, a more stable structure remains: the Agent proposes a call, the gateway parses identity, the business service then validates permissions and state, high-risk actions go through manual confirmation, execution is audited, and structured results are returned.

Connect Skills to the Agent

Function Calling solves single actions; Skills solve how a class of repeatable tasks should be done. The project Skills written for the Coding Agent in Phase 1 and the Skills connected to the business Agent here follow the same logic: clearly write trigger conditions, required reading, steps, boundaries, and acceptance criteria, allowing the Agent to load on demand, rather than relying on verbal Prompts to explain from scratch each time.

When connecting, focus on practicing these things:

• How Skill metadata is registered: name, description, applicable scenarios, ensuring the Agent can hit based on the description, rather than stuffing all Skills into the context at once
• How to load after a hit: first read the summary, confirm relevance, then load the full SKILL.md, reference materials, and scripts
• How Skills and tools cooperate: Skills define the process and boundaries; actually modifying data, querying databases, sending messages still go through Function Calling. Specific execution can be in-process tools, CLI, or MCP
• Open-source Skills are only templates; ultimately, they must be modified into versions that fit this project's rules
• Use three types of tasks—should trigger, should not trigger, should stop and ask—to verify if the connection is correct

Connecting Skills unstably before adding Multi-Agent will only replicate the chaotic process multiple times.

Then Use LangChain for Assembly, LangGraph for Long-Running Tasks

After single Agents, Function Calling, tool exposure methods, and Skills are running smoothly, then introduce frameworks. LangChain is suitable for quickly assembling models, Prompts, structured output, tools, and short-task Agents. LangGraph is more suitable for long-running, stateful, recoverable tasks, with a focus on State, conditional branching, Checkpoints, Interrupts, human approval, and failure recovery.

The learning order is also fixed: first, map it to the function calls and Skill loading you've hand-written, seeing what the framework handles for you; when you need to save running facts across requests, wait for approval, or recover mid-way, then use LangGraph. Deterministic processes continue using regular programs; only when the next step truly depends on semantic and current state dynamic judgment is it handed to the Agent for decision.

Then Learn Intent Recognition, Supervisor, and Multi-Agent

Most projects should first make a reliable single Agent stable. Only when task boundaries are clear and the single Agent is already frequently conflicting among multiple responsibilities should you split into Multi-Agent.

At this step, practice in this order:

• Intent recognition: First determine if the user wants to query knowledge, modify data, go through after-sales, or chat, then decide which link or Agent to route to
• Supervisor: A supervising Agent responsible for task decomposition, dispatch, aggregation, and termination; sub-Agents only do their own narrow responsibilities
• Multi-Agent collaboration: Clearly define each one's tools, Skills, context, and permissions; agree on handoff formats, shared state, and result merging rules
• Failure and conflict: When a sub-Agent fails, who retries, who escalates, who is responsible to the user—all must be written out in advance

Without intent recognition and a Supervisor, Multi-Agent easily devolves into talking over each other, repeatedly calling tools, and being unable to merge results. It's only worth introducing when tasks can be clearly decomposed and merging rules are clear.

Once these capabilities are strung together, the AI core line can be considered established. A summary diagram can be used to nail down the learning sequence.

How to judge if this phase is passed is not by how many frameworks are installed, but by being able to explain, in the above order, what problem each step solves, and clearly stating which layer Function Calling, CLI, and MCP each manage. In your own project, you must produce controllable model calls, testable Prompts, explainable context, layered memory, RAG with permissions, Function Calling with contracts, tool exposure methods chosen by scenario, Skills loadable on demand, and intent recognition, Supervisor, and Multi-Agent only introduced when truly necessary.

Phase 5: Evaluation, AI Monitoring, and Security Determine Whether an Agent Can Go Live

A regular API returning 200 usually means the request executed successfully. An AI system returning 200 only means the model responded successfully; it neither proves the answer is correct nor proves the tool call is safe. Therefore, evaluation and monitoring cannot be postponed to a last-minute patch before the project goes live.

At this step, three things must be watched simultaneously: whether components and tasks have fixed evaluations, whether there is traceable AI monitoring and tracing online, and whether high-risk actions have permission gates graded by side effects.

Component-level evaluation at least covers classification accuracy, Schema parsing success rate, RAG recall, citation correctness, tool selection, tool parameters, and refusal results. Task-level evaluation looks at whether the Agent completed the goal, whether the path was reasonable, whether there were redundant tool calls, whether there were permission violations, whether it stopped correctly, whether it could recover after failure, and whether the final result met business requirements.

Don't install all tools at once. First, distinguish between offline evaluation and online monitoring:

• Promptfoo: Leans towards offline evaluation and CI gating before release, using fixed test cases, assertions, multi-model comparison, and even red-teaming to block obvious regressions before deploying
• Langfuse: Leans towards production monitoring, open-source and self-hostable, responsible for Traces, Prompt management, scoring, tokens, and cost latency
• LangSmith: Also covers Traces, datasets, and online evaluation, with deeper integration with LangChain and LangGraph
• Helicone: Leans towards gateway-proxy-style monitoring; changing baseURL logs requests, latency, and cost, suitable for first getting a clear view of expenses
• Arize Phoenix: Leans towards the OpenTelemetry route, suitable for teams already on an OTel system wanting framework-neutral Trace and evaluation workflows

A common closed loop is: Promptfoo manages pre-release regression; Langfuse, LangSmith, or Phoenix manages real online traces; a gateway like Helicone first breaks down cost and latency. Failed samples are then fed back into the offline test set, rather than just relying on manually clicking through a Demo a few times.

AI monitoring is also not entirely the same as regular service monitoring. Besides error rates and availability, continuously watch these signals:

• Request-level: Model, Prompt version, input/output, tokens, time-to-first-token, total latency, cache hits, failure reasons
• Trace-level: Retrieval recall, tool selection and parameters, tool results, state transitions, approvals, and human takeovers
• Quality and cost: User feedback, refusal rate, hallucination-related complaints, per-task cost, daily budget alerts, model degradation count

Traces record execution facts, not post-hoc summaries. A complete Trace must at minimum string together user input, Prompt version, model, context sources, retrieval results, tool names and parameters, tool results, state changes, approval records, tokens, Prompt Cache hits, latency, final output, and user feedback. Without this information, when an error occurs online, often only the final answer is visible, making it hard to judge whether the problem came from the model, retrieval, Prompt, tools, or state management.

Permissions must be graded by side effects. Read-only searches and general knowledge retrieval have lower risk; modifying data, sending messages, executing code, controlling devices, publishing content, and initiating payments have real side effects and require stricter control. At minimum, there must be a tool whitelist, least privilege, parameter validation, timeouts, call count limits, token and cost budgets, sandboxing, human approval, audit logs, and rollback or compensation. The production closed loop can be summarized into a risk gating diagram:

How to judge if this phase is passed: Promptfoo can block obvious regressions before release; monitoring tools like Langfuse, LangSmith, Helicone, or Phoenix can locate an online failure and explain cost and latency; high-risk operations can be intercepted; recovery is possible after interruption; new versions can pass fixed tests proving no obvious regression.

Phase 6: Use One Main Project to String Together the Entire Route

The learning route cannot be split into a dozen unrelated Demos.

Node writes a Todo, Prompt makes a translator, RAG makes a PDF Q&A, Agent calls a weather API once—each project can run, but no connections form between the capabilities.

A more effective method is to choose one main project and continuously add capabilities to it. For example, the Coding Agent desktop workbench we recently built was, in its early stages, just a pnpm Monorepo and an Electron shell that could run. Only later did we gradually supplement the Agent loop, permission sandbox, Skills, context compression, completion verification, and interrupt-resume. In an interview, you talk about how this project grew, not boast about five small Demos separately.

Directories in shared packages must also grow with responsibilities. agent, context, permission, prompt, skills, provider each manage their own segment. Opening it, you know where to go to change permissions, where to change prompts, rather than letting AI pile files into one big folder based on needs, leaving you unable to find your way after two weeks.

The ability of a main project to continuously add capabilities relies on these boundaries still being in place, not on the feature list growing longer while the directory structure gets blurrier.

The same goes for intent recognition. Initially, single-intent classification was enough, but users really do say things like "What content does this project have, how many updates, who all submitted?" One sentence asks for project content, commit count, and contributors. Forcing one label would definitely miss things. Later, it was changed to first decompose into multiple intents, querying in parallel where possible.

After decomposition, one path reads the README, one counts commits, one lists authors—much more reliable than pretending there's only one "check project" intent.

The Coding Agent's Prompt also had mishaps. Initially, the idea was that the more complete the system prompt, the better, stuffing the full text of Skills, project descriptions, and security rules in all at once. After just two rounds of user questions, the context blew up, and sometimes it even regurgitated internal instructions. Later, it was changed so the prompt only contained a Skills index and bottom-line rules; the main body used UseSkill for on-demand loading, and AGENTS.md went through a separate instruction assembly path, not mixed with memory.

Also, don't start building as a full product right away. First, stabilize the repository and process boundaries; the model can modify files and run commands. Permissions and sandboxing are often supplemented after a mishap. Context blowing up, stopping halfway, it saying it's done but tests failing—when you step on these pitfalls, then add compression, memory, verification, and resume. This is more practical than daydreaming a grand architecture diagram.

If open-sourcing, others opening the repository should be able to understand what you did; if closed-source, at least provide a usable entry point: an installer, online demo, or an application-based trial.

How the architecture is split, how AGENTS.md constrains, how Skills are used, how permissions block, how completion is verified, how to resume after interruption—plus leave one or two real mishap records. Write clearly what can be public; for what cannot be public, clarify the boundaries in demos and explanations.

In a resume, don't just write:

Wrote a very long system prompt for a Coding Agent.

A more effective expression is:

The Coding Agent initially stuffed full Skill text and project rules into the system prompt, causing rapid context inflation. Later changed to injecting only a Skills index, loading main bodies on-demand via UseSkill, routing AGENTS.md through the instruction layer and isolating it from memory. Then used fixed code-modification tasks to check for missed loads or leakage of internal instructions to the user.

All numbers within must come from real tests; don't fabricate for resume effect.

A Few Places Where Learning Most Easily Goes Astray

The longer the route, the easier it is to pile on tools, frameworks, and abstractions first, yet迟迟 not touch a real task that can be repeatedly delivered. A more stable starting point is often what you are already doing. For example, when doing Douyin content, topic selection, angle, title, script, and publishing materials appear repeatedly. Once the steps are stable, they can first be consolidated into a Skill, clearly writing trigger conditions, material sources, output format, and acceptance criteria, then talk about automation. First, get the "topic selection to generation" link running smoothly; this is more useful than writing dozens of generic Skills empty-handed.

Don't Replace Real Scenarios with Abstract Checklists

First, choose a task that will recur repeatedly, then choose a Coding Agent, and get the context files, permissions, Diffs, tests, and this one Skill running smoothly. Switching tools is easy; establishing project-level usage habits is harder. When a task only appears once and the steps aren't stable yet, first write it into notes or a temporary Prompt; don't rush to encapsulate.

Don't Tweak Unversioned Prompts by Feel

Once a Skill can run, the next common pitfall is tweaking the Prompt. Write a couple more lines, switch models, adjust the temperature—it looks better on the spot, but you can't say exactly how it's better than the previous version, nor can you revert to the previous version. Prompts must be versioned by purpose, e.g., douyin-topicSelection-v3. For each change, keep a change log and corresponding test set. After changing, first use Promptfoo to run offline regression, checking if topic relevance, title usability, script structure, sensitive words, and refusal to answer have regressed. Only replace the online version after passing. Without version numbers and fixed test cases, so-called optimization is just gambling on the feel of the next manual query.

An incorrect answer also doesn't equal a bad Prompt. Data not entering the context, RAG not recalling, unclear tool descriptions, permission blocks, state loss, insufficient model capability, or the evaluation standard itself being wrong can all manifest as "the answer is wrong." First, locate the link, then decide whether to change the Prompt, retrieval, tools, or acceptance criteria, rather than piling on more instructions with every failure.

Don't Learn Multi-Agent from the Start, and Don't Treat Frameworks as Mandatory Abstractions

Most projects first need a reliable single Agent, plus a few tools with clear boundaries. Multi-Agent increases context synchronization, state conflicts, token costs, result merging, and debugging difficulty. It's only worth introducing when tasks can be clearly decomposed and handoff and merging rules are clear. The same goes for orchestration frameworks. First, hand-write a structured output and tool loop using the model's official SDK. After understanding the raw call chain, then judge whether LangChain or LangGraph can truly reduce repetition. Otherwise, when framework behavior doesn't match expectations, it's hard to tell if it's a model problem or an encapsulation problem.

Don't Prematurely Split into Microservices for the Sake of Technical Sophistication

One modular main service, one asynchronous Worker, a database, and Redis are already sufficient to complete most learning projects. Only split services when independent scaling, fault isolation, runtime environment differences, or clear team boundaries emerge.

Don't Trust the Agent's Self-Declared Completion

Task completion must be proven by external evidence: type checks pass, tests pass, browser behavior is correct, Diffs haven't overstepped boundaries, permissions haven't been relaxed, data hasn't been corrupted, and real acceptance conditions hold. For content-type Skills, also be able to explain whether the topic fits the account positioning, whether the script is filmable, and whether there are any boundary-violating expressions. The Agent's summary can only be used as a reference, not a substitute for verification.

Summary

Frontend hasn't disappeared because of AI; what has narrowed is the old responsibility boundary that only focused on pages and interfaces.

Next.js supplementing AGENTS.md and runtime visibility for Coding Agents, and Alipay putting Skills into the integration chain, indicate that Agents have entered formal delivery, not just being personal productivity tools.

When transitioning to AI full-stack, don't pile on frameworks at the start. First, integrate Coding Agents into real projects, clearly write rules and Skills, then supplement backend. Whether the language is Node or something else isn't important; engineering problems like HTTP, authentication, databases, caching, tasks, and deployment are unavoidable. Once the full-stack foundation is there, then learn in order: models, Prompts, context, memory, RAG, Function Calling. On tools, distinguish between in-process, CLI, and MCP. Only talk about Multi-Agent after a single Agent is stable. Finally, evaluation, monitoring, permissions, and failure recovery. The entire route is best compressed into one main project that grows, rather than split into a bunch of unrelated Demos.

Code can be written faster by Agents, but project boundaries, verification standards, and final delivery responsibility are still the engineer's job.

If you want to learn more in-depth content, you can also add my WeChat yunmz777 to find out more. I have very rich AGENT learning materials here:

There is also a corresponding Harness Engineer project:

If you are interested in collaborative documents, there is also a document Agent project:

Interested parties can contact me ~