AI Capability Expansion Guide
General Tactics for Technical Personnel

Cognitive Framework

In the past, when stepping into an unfamiliar tech stack, what really consumed time wasn't the concepts themselves, but the process of checking documentation and trial-and-error—spending half a day digging through forums for an error, reading official docs three times just to figure out the parameters of a foreign API before daring to use it. AI compresses this time to near real-time: paste the error in and locate the probable cause in seconds, ask one sentence to understand a foreign usage, and extract actionable conclusions within ten minutes from documentation that would originally take a whole day to chew through. But what hasn't been compressed is the other end—whether the answers provided by AI are actually correct, a judgment that still relies solely on human verification. Empirical Consensus A thematic analysis of 1,110 open-ended responses in the Google DORA team's "2025 State of AI-assisted Software Development" report reached a similar conclusion: a significant portion of the time saved during the generation phase has been reallocated to the overhead of the verification phase; the article also quotes data from the "2025 DORA report" noting that three out of ten developers still have very low trust in AI-generated code—this data comes from another DORA report. In other words, the real new bottleneck on the path of expanding capability boundaries is not "unable to learn new syntax"—AI can basically handle the syntax layer; what gets people stuck is "is what AI wrote correct, and can I judge it?"

Core arguments verified from DORA official insight "Balancing AI tensions"—the verification overhead conclusion comes from the thematic analysis of 1,110 open-ended responses in the article (not the overall report sample of about 5000 people); the trust data is quoted from the official page of "2025 DORA report" linked in the article, the original text did not disclose the specific sample size for this data, verified in 2026-07.

But expanding boundaries does not equate to omnipotence, and this line must be drawn honestly: If the new field is isomorphic to a mental model you already master—for example, you already know a language with a type system, switching to a language with different syntax but a similar paradigm; you already understand declarative UI, switching to a framework that implements the same mental model—AI efficiency gains are very obvious, and most of the saved time is on "remembering exactly how to write this language/framework", which is exactly what AI is best at filling. But if the new field is completely foreign to you, with no transferable mental model—for example, making architectural decisions in a business domain for the first time, judging "is this solution good" requires experience accumulated by falling into pits and bearing consequences, this kind of judgment cannot be provided by AI; it can list options and lay out trade-off lists, but making the final call requires you to accumulate to the point where you can make the final call. Without drawing this line clearly, expanding boundaries can easily be misunderstood as "having AI makes you omnipotent".

General Methodology: 5-Step Expansion Engine

The five steps are not five isolated tips, but a chain: ① first diagnose "what is truly unfamiliar," ② do a speed-run on learning only this part, ③ immediately build a runnable minimal product (scaffolding), ④ verify its correctness in a verifiable way, ⑤ look back and turn the pitfalls encountered into something you truly understand and can precipitate. Each step unfolds with four questions "what to learn / how to learn / what to use / how to use", and "how to use" gives prompt templates that can be directly copied, not vague statements like "ask AI more".

① Diagnose Gaps

What to Learn

This step isn't about learning new technology, but clarifying one thing first: which parts of the new field can my existing mental models cover. The diagnostic result directly dictates how the next four steps will proceed—the covered parts don't need to be relearned, and the uncovered parts are the real hard bones to chew (exactly how to feed "existing mental models" to AI for mapping will be elaborated in the next section Cross-Domain Mapping). Three specific questions need to be clarified in the diagnostic phase, rather than stopping at "how much I feel I know":

• How much conceptual model overlap is there between this new field and my familiar fields?
• Which are pure terminology translations, and which are truly foreign new concepts?
• What is the first concrete deliverable I want to achieve right now?

How to Learn

The action in this step isn't "learning", it's "asking"—and letting AI ask you instead, rather than making a self-assessment checklist yourself. The practice of a self-assessment checklist is unreliable inherently: you easily overestimate the parts of the field you are familiar with (thinking "I definitely know this" only to find it full of holes when asked in detail), and easily underestimate the unfamiliar fields (thinking "I know nothing about this" when it's actually something you use every day, just under a different name). Letting AI proactively ask follow-up questions, judging your knowledge boundaries revealed in your answers along the way, is much more accurate than scoring yourself.

What to Use

This step requires no project context; pure chat mode is enough—Claude Code / Codex conversation mode, just start a new session, no need to mount any codebases.

How to Use

I am a [Your background, e.g.: Backend developer with 5 years of Java experience, familiar with Spring / MySQL / Message Queues].
I now want to expand my capability boundary to: [Target new field, e.g.: Distributed system architecture design].
The first concrete deliverable I want to achieve right now is: [As specific as possible, e.g.: Design a workable multi-active disaster recovery solution for our existing system].

Before I say more, ask me 3-5 diagnostic questions first, aimed at figuring out my actual knowledge boundaries in this new field—
Don't assume I know nothing, and don't assume I know everything. The questions must be specific enough that I can judge at a glance "I know this" or "I really haven't heard of this".

After I finish answering, categorize this new field into three types based on my answers, listed in a table:
① Overlap Zone: Conceptually basically the same as my existing fields, just under different terminology
② Translation Zone: Concepts are not strictly equivalent, but can be understood by analogy using my existing concepts—you must specifically point out how to draw the analogy
③ Brand-new Zone: I have absolutely no corresponding mental models, concepts that need to be built from scratch

② AI Knowledge Speed-run

What to Learn

Only learn the minimal set of concepts in the "brand-new zone" diagnosed in the previous step that prevents you from verifying the correctness of the output—nothing else. We must explicitly exclude an intuitive approach here: systematically reading the official documentation or textbook end-to-end. That's the old way of learning a new tech stack, which is very inefficient in capability boundary expansion scenarios, because the "brand-new zone" often accounts for only a small fraction of the new field. Reading the whole documentation equals relearning the "overlap zone" and "translation zone" from scratch, which is a waste of time.

How to Learn

Use AI to do "concept translation", rather than "listening to a lecture from scratch". Specific technique: for every new concept learned, immediately draw an analogy with the corresponding old concept in the "overlap zone" confirmed in step ①, and ask AI to test you in reverse to verify that you really understand it—it explaining doesn't count, you answering the questions correctly does. The easiest mistake to make in this step is "assuming you've learned it because you understood what it said", reverse testing is the only means to pop this illusion.

What to Use

AI conversation + official documentation, you need both. Official documentation is not an optional supplement, it is a necessary step to verify AI's claims—AI's analogy explanations may be vivid but inaccurate, especially regarding version details or edge conditions. Relying purely on AI's explanation can easily lead to memorizing an incorrect analogy as fact.

How to Use

I have completely no mental model of [Specific concept in the brand-new zone, e.g.: Saga pattern in distributed transactions].
In my existing mental models, what might relate to it is: [Corresponding old concept in the overlap zone, e.g.: ACID of database transactions, business compensation/reversal mechanisms].

Please:
1. Use my existing [corresponding old concept] as an analogy to explain exactly what [new concept] is, what problem it solves, and what the fundamental differences are from what I'm familiar with
2. After explaining, don't stop, immediately give me 3 true/false or scenario questions to test me—the questions must test whether "I just memorized your words" or "I truly understand it", don't give gimmes
3. After I answer, first judge right or wrong, then point out exactly which step in my understanding I got wrong

Finally, tell me: if my understanding is wrong, which section in the official documentation/authoritative materials can I verify directly? Give specific sections or keywords, don't just say "check the official documentation".

③ Scaffolding Start

What to Learn

This step does not aim to "understand all principles", the goal is to build a runnable minimal product and establish a feel for it. Deliberately allow "knowing what it does without knowing why"—this is the fundamental difference between this step and step ②: step ② learns the minimal concept set needed to "verify if the output is correct", while step ③ is to get things running first, leaving the gaps in principles to be filled in step ⑤.

How to Learn

Build as you ask, dig deep only when stuck; do not try to thoroughly learn all concepts before getting hands-on. This is the anti-pattern most likely to slow progress: always feeling "I'll be ready to start after learning just a bit more," resulting in being stuck in the learning phase without output. The minimal runnable product itself is the best feedback—if it doesn't run or throws an error, go back and ask about the corresponding concept; the pertinence is much higher than learning everything in advance.

What to Use

This step requires two assets that can be directly copied into the project: a configuration template placed in the project root to constrain how AI collaborates, and a prompt library covering high-frequency scenarios. Both are universal versions, not tied to any specific tech stack; fill in the placeholders according to your actual project.

How to Use

Asset 1: AI Collaboration Configuration Template (Save as CLAUDE.md in the project root directory, or the rule file read by the corresponding tool, so AI obeys it automatically in every interaction):

# Project Conventions —— [Your project name / one-sentence description]

## Tech Stack
[Your tech stack: Language / Framework / Data Layer / Deployment Method —— list clearly according to actual project status, so AI doesn't guess the environment]

## Hard Rules
- Provide a plan before making changes; if a solution involves modifying 3 or more files, a checklist must be provided for confirmation before starting
- Ask directly about uncertainties, don't guess the implementation—guessing wrong and reworking is much more expensive than asking a question
- Before introducing new dependencies / new concepts, explain why they are needed and if there's a simpler alternative
- Run after modifications are complete: [Your lint / typecheck / test command, e.g., npm run lint && npm test, or pytest, or go vet && go test ./...]

## Communication Conventions
- I am familiar with [Your existing tech stack/field], use it as an analogy to explain new concepts, don't assume I'm starting from scratch
- When giving me code, explain in passing how the correctness of this code can be verified (echoing ④ Verification Loop below)

Asset 2: Prompt Library (six high-frequency scenarios, copy directly, replace placeholders according to current task):

④ Verification Loop

What to Learn

The correctness of AI's output cannot be judged merely by "looking right"—this is exactly the uncompressed part mentioned at the beginning of this page: a significant portion of the time saved in the generation phase needs to be spent in the verification phase. What needs to be learned is not how to use a specific tool, but the judgment to choose the appropriate verification method for the new field: unit tests, type checking, running in a real environment, or checking against official documentation line by line; which one can confirm the output in your hands is correct depends on the type of output, not applying a one-size-fits-all verification method.

How to Learn

The specific technique is to require AI to state how its output can be verified, rather than thinking of verification methods yourself. AI usually knows what tests should accompany the code it writes and where errors are most likely to occur, but defaults to not providing this proactively—it stops after giving you the code, and unless you explicitly request it, the "how to verify this code" step is skipped by both sides.

What to Use

Remember these types of tools by category, no need to tie them to a specific tech stack: Unit testing frameworks (which have counterparts in most tech stacks, like Jest/Vitest in JS ecosystem, pytest in Python, built-in testing package in Go), Type checkers (like tsc in TypeScript, mypy in Python), linter/static analysis tools (like ESLint in JS ecosystem, Ruff/Pylint in Python, golangci-lint in Go, specifically catching code style issues and common pitfalls that type checkers ignore), and the official documentation for that field as the ultimate source of truth.

How to Use

After implementing [feature/change], please attach the following along with the code—don't wait for me to ask:

1. How can the correctness of this code be verified? List in order of priority:
   ① Can unit tests be written? Provide a test case skeleton (using the testing framework already in my project; if none, specify the recommended one)
   ② Are there type checks/static checks that can directly catch the most common errors for this type of change?
   ③ Under what real environment/real data must this code be run to count? Provide specific verification steps
   ④ For parts involving external APIs/official behavior, from which version of official docs did you get your claims? List the sources so I can verify line by line; I cannot rely solely on your paraphrasing

2. If some of the above four categories are not applicable (e.g., this change cannot be unit tested), explicitly state why it is not applicable, do not skip over it without mentioning.

3. Finally tell me in one sentence: If this code was given to you by someone else to review, would you merge it directly yourself?

⑤ Deepening and Precipitation

What to Learn

From "it runs" to "understanding why". The specific method is to look back at the pitfalls encountered in steps ③ and ④, and ask AI "why is this way of writing correct, and are there other ways to write it"—the "knowing what it does without knowing why" allowed in the scaffolding stage must be filled in at this stage.

How to Learn

The AI version of the Feynman Technique: Try explaining what you just learned to the AI yourself, and have AI point out your mistakes, rather than passively receiving its explanations. Being able to explain it clearly is the most honest test of whether you "truly understand" or just "think you understand"—the feeling of "I get it" when passively listening to explanations is easily an illusion; explaining it yourself will immediately reveal where you actually can't express it clearly.

What to Use

AI conversation + your own note files. The key to the word "precipitation" is "settling"—it must land in a document or template you continuously maintain; just leaving it in the chat history means no precipitation, and two weeks later you still won't remember what pitfalls you encountered or why you changed the way you wrote it back then.

How to Use

Feynman Verification—do this step first after finishing a module:

Let me explain the [concept/module] I learned this week to you. Don't interrupt me until I finish.
After I finish, point out my mistakes in these three areas:
① Where was my explanation wrong or inaccurate
② What key points did I miss (even if what I explained was correct, but the overall understanding is incomplete)
③ Ask me 1-2 questions like "why is doing it this way correct, and would another way work", forcing me to provide reasons instead of reciting answers

Periodic Review—precipitate the issues exposed in the Feynman session along with the output from this period:

Here is my code diff, pitfall log for this period, and the errors pointed out in the Feynman session just now. Please summarize:
① What are my recurring mistake patterns
② What should I deliberately practice in the next period, giving specific advice down to "what scenarios to practice with", don't just say "practice more"
③ Which knowledge points did I think I understood, but the Feynman session revealed I actually didn't
④ Format ①②③ into markdown that can be directly pasted into my notes file ([Your note file name/path]); don't just leave it in this chat round and consider it done

Cross-Domain Mapping Technique

Cross-domain mapping is the specific operational method for the three classifications of "overlap zone / translation zone / brand-new zone" in step ① "Diagnose Gaps" of the 5-step expansion engine: feed your complete A-domain mental model to AI, and let AI help you sort new concepts into two actionable buckets—"This is a translation of A" (corresponding to ① overlap zone + ② translation zone: concepts basically match, just changing terms or requiring a little analogy to understand, learning cost is low) and "This is a new concept A doesn't have" (corresponding to ③ brand-new zone: the parts that actually require time to understand). The three classifications in the diagnosis phase are responsible for "seeing where the gaps are clearly," and these two buckets are responsible for "deciding how to handle each gap specifically"—once sorted, what can be translated is directly mapped over, and only what is truly new deserves your learning time. This technique is not a one-time action strictly for "learning a new field for the first time," but a reusable capability: from now on, every time you switch to a new domain—mobile to web today, frontend to backend tomorrow, monolith to distributed the day after—you can reuse the exact same questioning structure to maximize your existing experience and only spend effort on the truly unfamiliar parts.

Three Cross-Domain Examples

The three groups below are specific output examples of this mapping technique, not meant for you to memorize—focus on "how to convert existing concepts into analogies for new concepts," this conversion method is the reusable part.

Android ↔ iOS: Declarative UI Paradigm Translation

Mobile → Web Frontend: Compose/Kotlin → React/TS Essence Summary

Web Frontend → Backend/Server: Three Intuitions Frontend Devs Easily Get Wrong

Cross-Domain Analogy Prompting Technique (Universal Version)

The table below adapts the "Android Analogy Prompting Technique" into a universal version not bound to a specific tech stack—fill in the placeholders with the two domains you are crossing between; the same questioning structure can be reused in any cross-domain learning.

End-to-End Deep Cases

The two cases below both go through the 5-step methodology above completely; choose the one closer to your direction to read deeply, or read both—their internal structure is identical, reading one is enough to master the method, and the other can serve as a reference.

• Case A: Starting from mobile, expanding to full-stack cross-platform →
• Case B: Starting from frontend/client, expanding to backend and server-side →

Case A: Mobile → Full-Stack Cross-Platform

You are a mobile engineer with an Android or iOS background. You already have a solid mental model of declarative UI, ViewModel/StateFlow state management, and Room local persistence. Now you want to go one layer higher—not just "writing an app that runs on a phone," but being able to independently build a full-stack application covering frontend rendering, backend write operations, and database read/writes all by yourself, without waiting for backend colleagues to schedule it. Below, we'll walk through this transition using the 5-Step Expansion Engine, using the Next.js full-stack framework as the technology choice example; the principles apply equally to Nuxt, SvelteKit, and other full-stack frameworks.

① Diagnose Gaps (Case Study)

Combining the two mapping tables from Cross-Domain Mapping (Android↔iOS remember/@State translation, Mobile→Web Frontend remember→useState, LaunchedEffect→useEffect), clarify one thing: the two layers full-stack adds compared to "mobile→frontend" are backend services and databases—you currently have absolutely no mental model for these two layers, which makes them the ③ brand-new zone that this diagnosis needs to draw out. The frontend layer likely falls into the ① overlap zone / ② translation zone because you already have declarative UI intuition, so you don't need to spend time relearning it.

Don't estimate "how much I think I know" yourself. Based on the frontend mapping provided in #mapping, apply the same "overlap zone / translation zone / brand-new zone" three-way classification to the backend and database layers, and let AI actively ask follow-up questions instead of listing a checklist yourself.

AI conversational diagnosis, pure chat mode is sufficient, no need to mount codebases.

I am an [Android/iOS] mobile engineer with [N] years of experience in [Kotlin+Compose / Swift+SwiftUI],
familiar with declarative UI, ViewModel/StateFlow state management, Room local persistence, and Retrofit network layer.

I now want to expand my capability boundary to: independently building a full-stack application where I handle frontend + backend + database all by myself
(Using Next.js as an example, principles apply to other full-stack frameworks).
The first concrete deliverable I want to achieve right now is: [e.g., a personal project management tool with login and private data persistence].

Before I say more, ask me 3-5 diagnostic questions, covering:
① Frontend rendering layer—what overlaps with my declarative UI intuition
② Backend service layer—I've never written an API, focus on this layer
③ Database layer—I've only used local embedded DBs like Room, never touched real server-side databases or permission models

After I answer, categorize the results into three layers in a table: ① Overlap Zone ② Translation Zone ③ Brand-new Zone,
and specifically highlight: in the "backend service layer" and "database layer," which concepts have absolutely no counterpart in mobile development and must be built from scratch.

② AI Knowledge Speed-run (Case Study)

Pick a real blocker from the diagnosed ③ brand-new zone: "where exactly does which piece of code run"—the boundary between server components and client components, and when page HTML is generated (SSR/SSG/ISR). This is a part where the mobile mental model has absolutely no counterpart: in an app, all code runs on the device, while a full-stack app introduces for the first time the fact that "the same codebase has one part running on the server and one part running in the browser."

Use your existing intuition of "which layer handles what capabilities" as an analogy primer, but demand that AI tests you immediately after explaining, rather than thinking you understand it after hearing the analogy—this is the application of the #engine step ② "reverse testing" technique in this specific brand-new zone.

AI conversation is enough; no need to mount real project code during the concept clarification phase.

I am a mobile engineer, very familiar with the mental model that "code only runs on the device." Please explain the boundary between "server components" and "client components" in Next.js (or similar full-stack frameworks):

1. By default, where do the components I write run? What declaration makes them switch to run on the other side?
2. Give a specific counter-example: if I put database query logic inside a component that is supposed to run in the browser, what are the consequences—
   does it throw a compile-time error, blow up at runtime, or worse (like secrets being sent to the browser)?
3. Then explain the three patterns of "when page HTML is generated" (SSR/SSG/ISR), and map them to which types of pages in the app I want to build (personalized dashboard after login / pure display landing page / infrequently updated detail page)?
4. After explaining, give me 3 true/false questions to test if I really differentiate between "default capabilities of server components" and "capabilities client components only have after explicit declaration."

A reliable answer usually looks like this (structure is more important than exact wording; judging "did AI really explain it clearly" depends on these three pieces): first, a decision table—can you use useState/onClick, can you query the DB or read secrets directly, which is the default—this table should be memorizable in 30 seconds. Second, specific counter-examples—putting database queries in a component declared with "use client" will fail directly at build time because the browser can't get database connections, whereas conversely, "wanting to use onClick in a server component but forgetting to declare "use client"" is the most common pitfall missed in AI-generated code. Finally, a one-sentence conclusion for SSR/SSG/ISR—use SSG for static content, ISR with revalidate for infrequently updated content pages, SSR for personalized dashboards after login, which exactly corresponds to the "whether to cache, how long to cache" judgment you're already familiar with in Room/local caching, just applied at the page granularity this time.

③ Scaffolding Start (Case Study)

Don't aim to learn the whole tech stack; first build a minimal full-stack product "with login, and one piece of private data you can read and write"—this bar is a notch higher than a "runnable Hello World" because it simultaneously verifies whether the frontend rendering, backend writing, and database permissions layers are truly connected, rather than just getting a simple static page to run.

Build as you ask, query whichever layer you get stuck on, combined with the universal startup commands and CLAUDE.md template provided in #engine Step ③—you don't need to read the framework or database documentation thoroughly in the startup phase.

We use Next.js as an example here for specific commands; the principles apply to other full-stack frameworks. Database uses Supabase/Postgres as an example; principles apply to other database services.

npx create-next-app@latest my-app --yes
cd my-app
npm run dev   # http://localhost:3000

After building the project, confirm that "strict": true is still in tsconfig.json (this is the foundation for the next step ④ Verification Loop to work), then do just one thing to prop up the scaffolding: integrate Auth (Supabase Auth or OAuth/Email login from a similar service) + create a table that only the owner can read and write. Log in, write a piece of your own data, and read it back seeing only yours—getting these three steps to run is the first passing mark for crossing over from mobile to full-stack, and the principle applies to other full-stack frameworks and DB services. You can also add a proxy.ts (Next.js 16 renamed middleware.ts, behavior is unchanged, official codemod provided) to redirect unauthenticated users to the login page, which corresponds to the Interceptor auth interception you are familiar with.

④ Verification Loop (Case Study)

Following #engine Step ④ "AI output correctness cannot be judged merely by looking right," the most representative part in the full-stack case is data permissions: AI can easily write code that "looks like it runs" but has permission loopholes—forgetting the owner filter in a query, or using an omnipotent secret key that ignores permissions on the browser side. What you need to learn in this step is to pair this kind of "must be verified, cannot just read code" output with an executable verification method.

Take Row Level Security (RLS) in Supabase/Postgres as an example; the principle applies to other DB permission models (like middleware auth + ORM layer filtering in a self-built backend, or row-level permissions in other cloud DBs): first let AI provide the policy, then let AI play the attacker to list several bypass attempts, and use two real test accounts querying each other to verify it holds up—this is the concrete implementation of #engine Step ④ "require AI to state how its output can be verified".

The database's policy configuration interface or SQL Editor + two test accounts (you cannot self-test with one account; two identities must attack each other to count as verification).

-- Taking Supabase/Postgres as an example, enable RLS on a table and write a minimal policy (principles apply to other DB permission models)
alter table projects enable row level security;
-- After enabling, all access is denied by default—this is its value; a missing policy = request denied, not data running naked

create policy "Can only read own projects"
  on projects for select
  using ( owner_id = (select auth.uid()) );

This table has RLS enabled and the above policy written. Please play the attacker and provide 3 attempts that might bypass this policy and read someone else's data (e.g., forgetting to write a policy for a certain operation, writing the policy condition backwards, bypassing with the wrong secret key).

Then I will use two real test accounts (log in as Account A and try to query Account B's data) to reproduce and verify each one—
you tell me exactly how to execute each attempt first, and I will report the results back to you after verifying.

⑤ Deepening and Precipitation (Case Study)

From "runnable" to "long-term stable operation"—the engineering habits mobile engineers are familiar with like "crash rate dashboards" and "canary releases" need to be re-implemented as another set of concrete actions in full-stack; the deepening phase is about filling these in one by one.

Following the Feynman technique in #engine Step ⑤, go through each item in the table below and explain to yourself "why I need this, what old habit of mine it corresponds to"; anything you can't explain clearly means it hasn't truly precipitated, so go back and study it specifically.

The tools below are listed by category, not locking into specific brands—use GitHub Actions or equivalents for CI, Sentry or equivalents for monitoring.

Use this table to migrate "existing mobile engineering habits" to full-stack item by item:

The fact about proxy.ts renaming was verified against the Next.js official documentation proxy.js file reference (Migration to Proxy section, effective from v16.0.0), verified in 2026-07.

Case B: Frontend/Client → Backend and Server-Side Engineering

You are an engineer with a frontend (React/Vue, etc.) or client-side background. You are already proficient in the mental models of componentization, state management, and "sending a request, getting data, and rendering it." Now you want to dive one layer deeper—not just consuming APIs written by others, but designing the API contract yourself, choosing a backend language to get the service actually running, and taking responsibility for its stability in a production environment. Below, we'll go through the 5-Step Expansion Engine again, using Fastify (Node.js) as the primary tech choice; the principles apply equally to other backend frameworks. The starting point is exactly the "Web Frontend → Backend/Server" mapping table in #mapping—that table has already pointed out the three intuitions frontend developers most easily get wrong (stateless requests, connection pools, idempotency); we will continue the diagnosis from there.

① Diagnose Gaps (Case Study)

The three mappings provided in #mapping basically fall into the ① overlap zone / ② translation zone—you already have the intuition for "controlled side effects", you're just moving the granularity from "component re-rendering" to "a single HTTP request". What really needs to be categorized into the ③ brand-new zone in this step are two areas not covered by that table: Routing and Contract Design (you've always been the "consumer" of APIs, now you must become the "designer" of this contract—how to layer paths, which status codes to use, how to unify error structures, all must be decided by you, no longer just reading docs and taking what's there) and the Server-Side Perspective of Authentication (the frontend only needs to "read" the login state—getting the token to decide whether to show a button or redirect to the login page; the backend needs to "write" and be responsible for its security boundaries—how the token is issued, how it's validated, how expiration is handled, and how to revoke it if leaked, things the frontend never has to worry about).

Don't estimate yourself first. Directly paste the mapping table from #mapping to the AI as the "confirmed overlap zone", and let the AI only ask follow-up questions on the remaining parts—this saves the effort of re-diagnosing what's already been diagnosed, focusing the questioning power on the truly unfamiliar areas of contract design and authentication.

AI conversational diagnosis, pure chat mode is sufficient, no need to mount codebases.

I am a frontend/client engineer with [N] years of experience in [React/Vue/Mobile],
familiar with component-driven development, state management, consuming REST or GraphQL APIs using fetch/axios, handling loading/error states, and using received tokens to determine login status and redirect.

I now want to expand my capability boundary to: independently designing APIs, choosing a backend language to get the service running, and understanding the basics of deployment and ops (don't need to be an ops expert, but need to be able to deploy the service myself and know if it's running normally).
The first concrete deliverable I want to achieve right now is: [e.g., a minimal backend service with login and CRUD operations for one table].

The confirmed overlap/translation zones are as follows, no need to ask me about these again:
- HTTP requests are stateless by default; state must be explicitly saved to a DB/cache
- Database connection pool ≈ reusing connections instead of creating new ones every time
- API idempotency: resending the same request multiple times only changes the server's final state once

Beyond these, please ask me 3-5 diagnostic questions, focusing on:
① Routing and API contract design—I've always been the consumer, now I need to be the designer
② Server-side perspective of authentication and session management—issuing, validating, expiring, and revoking tokens
③ Parts I have absolutely no concept of: database design basics (normal forms, indexes)

After I answer, break it down into a table of ① Overlap Zone ② Translation Zone ③ Brand-new Zone, highlighting which ones must be built from scratch.

② AI Knowledge Speed-run (Case Study)

Pick three real blockers from the diagnosed ③ brand-new zone: server-side implementation of stateless request processing (not just knowing "stateless" conceptually, but knowing exactly where state is stored and how it's read/written when handling concurrent requests), database design basics (at least being able to understand and design: what first/second/third normal forms actually mean when creating tables, what problems indexes solve and their costs), and the server-side perspective of authentication and session management (the differences from the frontend "consuming login state" perspective—the server has to decide whether to use sessions or tokens, how to store tokens, and how to prevent tampering).

Use your frontend intuitions like "props flowing one way, lifting state up to a common parent component" as analogy primers, but strictly demand that the AI tests you immediately after explaining—this is the application of the #engine step ② "reverse testing" technique in these three brand-new zones. Understanding an analogy doesn't mean you can actually use it correctly when designing a table or choosing an authentication method.

AI conversation is enough; no need to mount real project code during the concept clarification phase.

I am a frontend engineer, very familiar with the mental model of "lifting state up to a common parent component to avoid duplicated sources of truth."
Please explain clearly in three parts:

1. Stateless request processing: If I want to "remember" a user's state across multiple requests on the server (like a shopping cart or login state), where is it actually stored? List at least two options (session storage / token with embedded state) and their respective trade-offs, and use my familiar "lifting state up" intuition to explain why I can't rely on the server process memory being reliable long-term.

2. Database design basics: Use a concrete example (like three tables: "Article + Author + Tags") to explain clearly what duplication/anomaly problems the first/second/third normal forms solve, which fields to index to speed up queries, and what the costs of indexing are (slower writes, takes up space).

3. Server-side perspective of authentication: Compared to my familiar "frontend reads token to decide whether to show the login page," what extra responsibilities does the server have—how are tokens issued and validated, how are they handled after expiration, and how are they revoked if leaked.

After each part, immediately give me 2 scenario questions to test me; the questions must test whether I can actually use it correctly in the design phase, don't give me gimme "true or false" questions.

③ Scaffolding Start (Case Study)

Don't aim to learn the entire backend tech stack; first build "a minimal runnable API service + one readable/writable table"—this bar is also a notch higher than "Hello World" because it simultaneously verifies whether the routing, request processing, and data persistence layers are truly connected.

Build as you ask, combined with the universal startup commands and CLAUDE.md template provided in #engine Step ③—you don't need to read the framework documentation thoroughly in the startup phase.

There are many mainstream choices for backend languages/frameworks today. Here we name an example whose active ecosystem has been verified by WebFetch as the main thread: if your frontend background is JS/TS, Fastify in the Node.js ecosystem is a natural extension, reusing the same language. The principles apply equally to Go (like net/http+chi), Java (Spring Boot), Python (FastAPI, whose adoption rate has shown a rare surge in recent years), and other languages and frameworks. Start with a minimal table for the database; you don't need to spin up a standalone database service first—Node.js 24 LTS onwards can use the built-in node:sqlite module without extra flags. Its official stability is marked as 1.2 (Release Candidate, close to stable, API can be directly used for startup verification). But note that DatabaseSync is synchronous blocking I/O—in an event-loop-based asynchronous framework like Fastify, one synchronous query will block the entire process and stall other concurrent requests. This is exactly why the advice "only suitable for minimal verification in the teaching/startup phase; before really going to production, you should evaluate more mature async database solutions (like PostgreSQL with an async driver, or a dedicated ORM)" truly holds water.

# Using Node.js + Fastify as an example, principles apply to FastAPI/Spring Boot and other frameworks
mkdir my-api && cd my-api
npm init -y
npm i fastify
# Add "type": "module" in package.json to use the import syntax below

// server.js —— Minimal runnable API + one table, using built-in node:sqlite, zero external dependencies
import Fastify from 'fastify'
import { DatabaseSync } from 'node:sqlite'

// export function build() only assembles the instance, doesn't listen on a port—test.js relies on it to get an injectable app
export function build() {
  const db = new DatabaseSync('app.db')
  db.exec(`
    CREATE TABLE IF NOT EXISTS todos (
      id INTEGER PRIMARY KEY AUTOINCREMENT,
      title TEXT NOT NULL,
      done INTEGER DEFAULT 0
    )
  `)

  const app = Fastify({ logger: true })

  app.get('/todos', (req, reply) => {
    const rows = db.prepare('SELECT * FROM todos').all()
    reply.send(rows)
  })

  app.post('/todos', (req, reply) => {
    const { title } = req.body
    const stmt = db.prepare('INSERT INTO todos (title) VALUES (?)')
    const info = stmt.run(title)
    reply.code(201).send({ id: info.lastInsertRowid, title, done: 0 })
  })

  app.get('/me', (req, reply) => {
    if (!req.headers.authorization) {
      reply.code(401).send({ error: 'unauthorized' })
      return
    }
    reply.send({ id: 1 })
  })

  return app
}

// Only running this file directly (node server.js) actually listens on a port; it won't execute here when imported as a module by test.js
if (import.meta.url === `file://${process.argv[1]}`) {
  build().listen({ port: 3000 })
}

After running it, test once with curl -X POST localhost:3000/todos -d '{"title":"First Item"}' -H 'content-type: application/json' and once with curl localhost:3000/todos—if both a write and a read go through, that is the minimal passing mark for this crossover.

④ Verification Loop (Case Study)

Following #engine Step ④ "AI output correctness cannot be judged merely by looking right," the three places in backend services most easily fudged by AI-generated code are: API Contract (is the response structure and status code really consistent with the documentation/frontend agreement?), Authentication Boundaries (are requests without login/permissions truly rejected, rather than "the check is written in code but missed on a certain path?"), and Data Consistency under Concurrency (if two requests modify the same row of data at the same time, is the final result correct?—this is a problem frontend devs almost never encounter; there is no true concurrency like "two users clicking submit at the same time" in a single browser).

Just like Case A, first ask AI to provide a verification plan, then turn it around and have it play the "nitpicker" to list edge cases that might be missed—this is the concrete implementation of #engine Step ④ "require AI to state how its output can be verified," only this time the verification target has changed from "database row-level permissions" to "API contract + authentication + concurrency."

The testing method officially recommended by Fastify is fastify.inject() combined with Node.js's built-in node:test test runner—no need to actually start a port to listen, inject requests directly to test, which is enough to cover contract testing and auth boundary testing; for concurrency consistency, you need to spin up a real port and hit it with multiple concurrent requests.

// test.js —— using fastify.inject() + node:test, zero extra test dependencies (Fastify officially recommended approach)
import { test } from 'node:test'
import assert from 'node:assert'
import { build } from './server.js'   // encapsulate server into a reusable build() function, no need to actually listen on a port before inject

test('POST /todos returns 201 and the created record', async () => {
  const app = build()
  const res = await app.inject({
    method: 'POST',
    url: '/todos',
    payload: { title: 'Test Todo' }
  })
  assert.strictEqual(res.statusCode, 201)
  assert.strictEqual(JSON.parse(res.body).title, 'Test Todo')
})

test('Accessing protected route without auth header should return 401', async () => {
  const app = build()
  const res = await app.inject({ method: 'GET', url: '/me' })
  assert.strictEqual(res.statusCode, 401)
})

Here is the route list for my API service: [paste route list, marking which ones require login].
Please:
1. For each route, provide contract testing key points: expected status code/response structure for normal input, and expected behavior for at least 2 types of abnormal input (missing fields, wrong types, unauthorized access to someone else's data).
2. For routes marked "requires login", list 3 scenarios that should be rejected but are easiest to miss in code (e.g., expired token, correct token format but wrong signature, valid token but accessing someone else's resource).
3. For [specific write operation, e.g., "inventory deduction" / "balance transfer"], provide a concurrency scenario description—will two requests arriving at the same time cause data inconsistency, and what means should be used to prevent it (like database transactions, version field for optimistic locking, unique constraints). Explain the principle in one sentence, don't just say the word "lock".

⑤ Deepening and Precipitation (Case Study)

From "runnable" to "can be deployed live and knowing if it's running normally"—a frontend engineer's experience with "deployment" usually stops at "pushing a static site." Backend services require taking on two more responsibilities: Deployment Basics (containerization concepts, how to manage environment variables hierarchically) and Observability Basics (minimal awareness of logging and monitoring). The deepening phase is about filling in these two gaps.

Following the Feynman technique in #engine Step ⑤, go through the checklist below and explain to yourself "what specific problem does each item prevent"; whatever you can't explain clearly means it hasn't truly precipitated.

List concepts by category, not locking into specific brands—for containerization, just understand Docker multi-stage builds and using slim base images; for monitoring, use Sentry or similar services provided by cloud vendors.

"From Runnable to Production-Ready" Checklist:

Fastify installation commands, minimal service code, and fastify.inject() official recommended testing approach were verified against the Fastify Official Getting Started and Fastify Official Testing Guide; node:sqlite API usage (DatabaseSync/exec/prepare/run/all) and stability marker (1.2 Release Candidate) verified against Node.js Official SQLite Docs; Node.js 24 (Krypton) being the current Active LTS verified against Node.js Official Releases Page; FastAPI adoption rate rising significantly in two years verified against JetBrains/PSF "State of Python 2025" Official Blog, verified in 2026-07.

Technical Solo Company / Indie Hacker

① Topic Selection: 5-Question Filter (Must Answer Before Starting)

② User Acquisition: SEO is your whole reason for choosing Web Full-Stack, fully utilize it

• Product is Content: Every feature page/tutorial page/comparison page is a search entrance, SSG is inherently indexable—technically, you need to implement site-level SEO infrastructure like generateMetadata/sitemap.ts/robots.ts/JSON-LD. Look up the specific syntax in official framework docs, don't just memorize the slogan without checking the code;
• Programmatic SEO: Use data to batch generate long-tail pages ("X vs Y" matrices, template libraries)—this relies on routing powered by generateStaticParams. The combination of AI + Next.js allows one person to build a thousand-page site;
• Cold Start 3 Channels: Build in public (indie hacker communities / Jike), Q&A acquisition (solving real problems where others ask and dropping a link), and pivoting retrospectives themselves are content (your iteration process is serialized material).

Specific operation paths for Search Console are subject to Google's official help documentation. Platform UI changes frequently, so only the action sequence is given here, without screenshot steps that will expire.

③ Payments Collection: Realities for Domestic Entities (Often Avoided in Tutorials)

④ From 0 to $1000 MRR: Milestone Action Plan

Pricing mental model: Don't set the starting subscription price too low (hard to raise, easy to lower), offer annual discounts, create a 3-tier pricing model to establish a psychological anchor.

⑤ What AI Can Do for You in Commercialization

Many tasks in the commercialization phase are not technical work, but "thinking clearly + writing clearly". This type of task is most suitable for AI acceleration: use AI to help spot loopholes when validating topic hypotheses with the ① 5-Question Filter, quickly convert topic conclusions into a testable landing page copy skeleton, and build a basic Customer Support/FAQ page to catch the most common repetitive questions early on. These aren't questions of "can it be done," but rather "is it worth writing from scratch yourself." Letting AI draft them can save more than half your time.

You don't need to "learn," here it's "use"—just adapt the prompt templates below with your own product information and run them; no need to learn prompt engineering first.

General AI conversational tools (ChatGPT/Claude equivalents) are sufficient; no need to mount additional codebases or install plugins.

【Validating Topic Hypotheses】
Here are my answers to the 5 questions from the "5-Question Filter":
1. [Am I a user myself—Answer]
2. [Target users' payment habit—Answer]
3. [Can it be found via search, with a few candidate search terms]
4. [MVP core action that can be stripped down to in a short cycle]
5. [List of 3-5 surviving competitors]

Please play a critical angel investor, point out one or two of the weakest assumptions in these five answers,
and provide concrete methods to validate these assumptions at the lowest cost (without writing code).

【Writing Testable Landing Page Copy Skeleton】
Based on the validated product hypotheses above, please write a landing page copy skeleton for me.
Requirement: Do not use generic marketing fluff. Follow the "Hero Headline (value proposition) → Sub-headline (how it works) → 3 Core Pain Points & Solutions → Social Proof (even if it's just my own usage data) → CTA (Join Waitlist)" structure.
Give me direct usable copy, do not describe the structure.

【Building Basic Customer Support/FAQ】
Here is a description of my product's core features: [...]. Please list 8-10 questions users are most likely to ask repeatedly in the first month after launch (refer to 1-2 competitors [...]), give a concise, no-human-intervention-needed answer for each, and mark which 2-3 questions MUST be transferred to a human rather than being answered automatically by AI/FAQ.

AI-Assisted Learning System

3-Layer Learning Method (Master Plan)

Letting AI Generate Your Dynamic Self-Test Checklist

Don't memorize a fixed question bank tied to a specific tech stack. Whether you are currently in the literacy, project execution, or internalization phase, and what you've actually learned recently, determines what you most need to be quizzed on right now. In each learning cycle, feed your phase, learned content, deliverables produced, and still-fuzzy areas to the AI, and let it specifically attack those blind spots where you "thought you knew it after reading." If you can't answer a question, go back to the project or materials for remedial learning, and regenerate it based on new progress in the next cycle.

Copy-and-pasteable Self-Test Prompt:

My current learning phase is: [Rapid Literacy / Learn by Doing / Deliberate Internalization].
Here is the content list I learned in my current learning cycle:
- [Content 1]
- [Content 2]
- [Content 3]

The deliverables I actually produced are: [Projects, Code, Articles, or Demos].
The areas I'm still fuzzy on are: [List them; you can write "unsure" if you don't know].

Based on the above information, give me 10 self-test questions where "being able to speak the answer fluently to thin air counts as a pass."
Requirements:
1. Cover concept boundaries, underlying mechanisms, solution trade-offs, fault diagnosis, and verification methods;
2. Prioritize testing areas I might think I understand but actually don't; do not test rote memorization of nouns;
3. Match the difficulty to my current phase, and include at least 3 scenario questions tied to actual deliverables;
4. Provide only the questions first, no answers. After I dictate my answers one by one, point out errors, omissions, and vague expressions,
   give the minimal remedial action, and finally organize a checklist of gaps to heavily re-check in the next round of self-testing.

Pitfalls and Mental Models

Resource Library

Rating Explanation: S = Mainline Must-Use · A = Highly Recommended · B = Use in Specific Phases

Learning Resources and Material Selection

Tools, Templates, and Tech Stack Supplements

Community and Repo Interconnectivity