跪拜 Guibai
← Back to the summary

The Programmer's Fork in 2026: From Code Writer to AI Driver

2026: The Transformation Path for Programmers

After ClaudeCode and OpenClaw came out, many lamented that programmers would be eliminated, feeling frustrated. In the AI era, how should we transform?

I. The Way We Code Has Changed

When ChatGPT first launched, people were still questioning "Is AI really capable?" Now, no one questions it. Frontend pages, backend APIs, test scripts, SQL, operations scripts, documentation — AI can generate them quickly and well. Not flawlessly, but in some scenarios, it genuinely outperforms humans.

The changes over these years roughly follow this path:

flowchart LR
    A["Before 2024 Traditional Development<br/>Requirements → Manual Coding → Testing → Launch"]
    --> B["2024 Copilot Phase<br/>AI-Assisted Code Completion"]
    --> C["2025 Agent Phase<br/>AI Executes Multi-Step Tasks"]
    --> D["2026 Agentic Phase<br/>Humans Set Goals, AI Decomposes and Executes"]

    style A fill:#444441,stroke:#2C2C2A,color:#ffffff
    style B fill:#1D9E75,stroke:#0F6E56,color:#ffffff
    style C fill:#534AB7,stroke:#3C3489,color:#ffffff
    style D fill:#D85A30,stroke:#993C1D,color:#ffffff

By 2026, the way software is developed has changed. Previously, a feature required product managers to write documents, designers to create UIs, frontend engineers to build pages, backend engineers to write APIs, and testers to write test cases — five or six people working in sequence. Now, it's more like a few core engineers set goals and constraints, AI handles most of the initial draft, and humans focus on decision-making, correction, and acceptance. One person can wear multiple hats.

Some Online Data

Standardized work (CRUD, boilerplate code, test scripts) is easily replaceable. The value of engineers can shift towards business understanding, system design, and quality validation.

II. Facing AI, Programmers Have Two Paths

One is the traditional way. Programmers take requirements, write code, fix bugs, and deliver, using AI tools sparingly or not at all. This is still mainstream but will likely gradually disappear in a few years.

The other is driving AI development. Programmers clarify business goals and boundaries, define constraints (cost, performance, risk), let AI quickly generate and compare solutions, and focus on decision-making, review, and validation. Most code writing is left to AI. Major internet companies are already doing this.

flowchart TD
    A["Programmer"] --> B["Continue Deepening in Execution Layer"]
    A --> D["Expand to Design and Decision Layer"]

    B --> C["Stable job<br/>but growth space gradually narrows"]
    D --> E["Take on more responsibility<br/>value space opens up"]
    
    style A fill:#444441,stroke:#2C2C2A,color:#ffffff
    style B fill:#D85A30,stroke:#993C1D,color:#ffffff
    style C fill:#BA7517,stroke:#854F0B,color:#ffffff
    style D fill:#185FA5,stroke:#0C447C,color:#ffffff
    style E fill:#993556,stroke:#72243E,color:#ffffff

Both paths involve "doing development," but the responsibilities differ.

AI excels at executing clearly defined tasks; the clearer the definition, the better the execution. So the core question isn't whether AI will replace programmers, but how much of your work is "defining problems" versus "executing solutions." For problem definition (design and decision-making), AI can't replace you yet. For execution (coding), AI is likely better than you.

In a word: Decision-making ability > Execution ability.

III. Programmers Won't Disappear, But Their Value Is Changing

AI is strong at execution but weak at decision-making. It can give you ten solutions but doesn't know which one fits your business rhythm, team skill level, or project budget. It can generate large blocks of code but doesn't know which one suits you best. There are things AI still can't do or do well:

  1. Whether this requirement is worth doing at all.
  2. Which boundaries must be held, and what the constraints are.
  3. Which complexities constitute over-engineering.
  4. Which performance issues might become future problems.
  5. Whether this delivery truly solves the user's pain point.

The value of a programmer is shifting upward from "code writing":

flowchart BT
    A("Code Generation — rapidly being replaced by AI; execution layer AI does better than humans")
    B("Solution Selection — requires engineering judgment, application of algorithms and design patterns")
    C("System Design & Boundary Definition — requires architectural thinking, application of algorithms and design patterns")
    D("Requirement Understanding & Business Judgment — requires industry experience, understanding of current state")

    A --> B --> C --> D

    style A fill:#BA7517,stroke:#854F0B,color:#ffffff
    style B fill:#185FA5,stroke:#0C447C,color:#ffffff
    style C fill:#534AB7,stroke:#3C3489,color:#ffffff
    style D fill:#1D9E75,stroke:#0F6E56,color:#ffffff

The higher up the business layer, the closer to requirements, boundaries, and constraints, the more indispensable humans become.

Previously, it was just about writing code. Now the requirements are:

  1. Can you clearly articulate the business problem?
  2. Can you define boundaries, constraints, and trade-offs?
  3. Can you judge where AI output is reliable and where it has pitfalls?
  4. Can you take responsibility for the final delivery?

The focus has shifted from "getting the code written" to "defining the problem well, designing the system well, and validating the result well."

IV. Changes for Several Programmer Roles

There are many types of programmer roles, and different roles are impacted differently. Let's look at frontend, client-side, backend, big data, and full-stack engineers — what changes each faces and where they can go.

Role Fundamental Change Direction to Invest In
Frontend Engineer From interaction implementation to product interface engineering Design systems, product engineering, AI UI review
Client-Side Engineer From feature development to terminal experience ownership Client-side architecture, stability engineering, cross-platform experience
Backend Engineer From API development to domain modeling and system design Business architecture, platform governance, observability
Big Data Engineer From running tasks to data assets and decision systems Metrics governance, data products, intelligent analysis
Full-Stack Engineer From writing everything to delivering business solo Independent products, micro SaaS, technical co-founder

1. Frontend Engineer

Restoring design mockups, writing interactions, connecting APIs, handling compatibility — AI can already do most of this. Frontend engineers need to move up, closer to requirements and UI interactions.

flowchart TD
    subgraph past ["Traditional Responsibilities"]
        direction TB
        P1["Restore design mockups"]
        P2["Write page interactions"]
        P3["API integration"]
        P4["Browser compatibility adaptation"]
    end

    subgraph future ["Transformation Directions"]
        direction TB
        F1["Design System Engineer<br/>Component library / Design specs / Variant strategies"]
        F2["Product Interface Engineer<br/>User journey / Interaction rules / State modeling"]
        F3["AI UI Review Engineer<br/>Generation review / Quality assurance / Accessibility"]
    end

    past -- "AI takes over execution layer" --> future

    style past fill:none,stroke:#ffffff,color:#ffffff
    style future fill:none,stroke:#ffffff,color:#ffffff
    style P1 fill:#D85A30,stroke:#993C1D,color:#ffffff
    style P2 fill:#D85A30,stroke:#993C1D,color:#ffffff
    style P3 fill:#D85A30,stroke:#993C1D,color:#ffffff
    style P4 fill:#D85A30,stroke:#993C1D,color:#ffffff
    style F1 fill:#185FA5,stroke:#0C447C,color:#ffffff
    style F2 fill:#185FA5,stroke:#0C447C,color:#ffffff
    style F3 fill:#185FA5,stroke:#0C447C,color:#ffffff

Take an e-commerce frontend as an example. Previously, the main work was writing product detail, shopping cart, and checkout pages. Now, the more valuable work is defining the interaction rules, component models, and state transitions for these three flows, and letting AI quickly generate page variants for different channels (PC, mobile, mini-program).

After transformation, you need to: start from the user journey, identify which interactions affect conversion and which state transitions are error-prone, rather than just implementing design mockups; define component libraries, API specifications, and variant strategies so one component system supports multiple business lines; use state machines to define complex interactions instead of piling up flag variables; use tools to verify accessibility and compatibility instead of manually testing every browser.

A metric: Can you use 5 component specifications plus one set of state rules to let AI generate a complete business process page? The goal is to improve efficiency by guiding AI, especially for full business process interaction validation.

2. Client-Side Engineer

Client-side work also seems heavily generable by AI, but there's a natural barrier: real device environments are too complex. Weak networks, low-end devices, system version fragmentation, vendor customizations — AI can't handle these on its own.

flowchart TD
    subgraph past ["Traditional Responsibilities"]
        direction TB
        P1["Feature page development"]
        P2["API integration"]
        P3["UI restoration"]
        P4["Manual testing and adaptation"]
    end

    subgraph future ["Transformation Directions"]
        direction TB
        F1["Client-Side Architect<br/>First-screen strategy / Offline architecture / Cache layering"]
        F2["Stability Engineer<br/>Disaster recovery / Crash management / ANR optimization"]
        F3["Terminal Experience Engineer<br/>Performance monitoring / Device adaptation / Weak network optimization"]
    end

    past -- "AI takes over execution layer" --> future

    style past fill:none,stroke:#ffffff,color:#ffffff
    style future fill:none,stroke:#ffffff,color:#ffffff
    style P1 fill:#D85A30,stroke:#993C1D,color:#ffffff
    style P2 fill:#D85A30,stroke:#993C1D,color:#ffffff
    style P3 fill:#D85A30,stroke:#993C1D,color:#ffffff
    style P4 fill:#D85A30,stroke:#993C1D,color:#ffffff
    style F1 fill:#185FA5,stroke:#0C447C,color:#ffffff
    style F2 fill:#185FA5,stroke:#0C447C,color:#ffffff
    style F3 fill:#185FA5,stroke:#0C447C,color:#ffffff

Take an e-commerce app client as an example. Core work will shift to designing first-screen loading strategies, offline caching schemes, and UI degradation and retry mechanisms for network anomalies. Let AI write the code; humans make the architectural decisions.

After transformation, you need to: define the overall strategy for first-screen, offline, caching, and network layering; handle compensation for network anomalies, degradation for version incompatibility, and recovery from memory overflow; use tools like Lighthouse and RUM to define quantifiable goals and track them continuously; understand Android/iOS version differences and vendor pitfalls, avoiding them proactively rather than discovering them through testing.

A metric: Can you independently design a complete weak-network loading solution, including caching, retry, degradation, and notification?

3. Backend Engineer

Backend is as impacted as frontend. API development, ORM mapping, CRUD services, boilerplate code — these are rule-based and repetitive, exactly what AI excels at. Continuing to compete on "API writing speed" offers diminishing returns.

flowchart TD
    subgraph past ["Traditional Responsibilities"]
        direction TB
        P1["CRUD API development"]
        P2["Database table design"]
        P3["Business logic coding"]
        P4["Bug fixing"]
    end

    subgraph future ["Transformation Directions"]
        direction TB
        F1["Domain Architect<br/>Business modeling / Event design / Consistency boundaries"]
        F2["System Design Engineer<br/>Service decomposition / API contracts / Circuit breaker strategies"]
        F3["Platform Governance Engineer<br/>Observability / Cost optimization / Capacity planning"]
    end

    past -- "AI takes over execution layer" --> future

    style past fill:none,stroke:#ffffff,color:#ffffff
    style future fill:none,stroke:#ffffff,color:#ffffff
    style P1 fill:#D85A30,stroke:#993C1D,color:#ffffff
    style P2 fill:#D85A30,stroke:#993C1D,color:#ffffff
    style P3 fill:#D85A30,stroke:#993C1D,color:#ffffff
    style P4 fill:#D85A30,stroke:#993C1D,color:#ffffff
    style F1 fill:#185FA5,stroke:#0C447C,color:#ffffff
    style F2 fill:#185FA5,stroke:#0C447C,color:#ffffff
    style F3 fill:#185FA5,stroke:#0C447C,color:#ffffff

Take a transaction system as an example. Core work will shift to designing event models and state machines for orders, payments, and inventory; defining consistency strategies for inventory deduction; and designing compensation and retry mechanisms. These decisions have high costs if wrong. Code can be left to AI, but design decisions must be made by humans.

Capabilities to build: derive data models, event sequences, and consistency boundaries from business processes; determine service decomposition, API specifications, circuit breaker and degradation strategies, cross-service consistency, and high-concurrency stability; establish logging, tracing, and metrics systems to locate issues within 15 minutes, not through manual investigation; make trade-offs between caching, indexing, sharding, and database selection, each balancing cost and performance.

Transitioning from a "CRUD engineer" to a "system design engineer" usually requires some time and experience, ideally having been through one or two large-scale refactoring or performance optimization projects. This type of capability has the highest scarcity and the most intense competition. Once you have solid system design skills, AI becomes hard to replace.

4. Big Data Engineer

A data engineer's daily work involves writing SQL, building ETL pipelines, configuring schedulers, creating reports, and fixing data definitions. This is highly patterned and something AI excels at.

flowchart TD
    subgraph past ["Traditional Responsibilities"]
        direction TB
        P1["Writing SQL / ETL"]
        P2["Configuring scheduled tasks"]
        P3["Creating reports"]
        P4["Fixing data definitions"]
    end

    subgraph future ["Transformation Directions"]
        direction TB
        F1["Metrics Governance Engineer<br/>Metrics system / Unified definitions / Causal analysis"]
        F2["Data Product Engineer<br/>Self-service platform / A/B testing / Data as a service"]
        F3["Decision System Architect<br/>Real-time pipeline / Feature engineering / Intelligent analysis"]
    end

    past -- "AI takes over execution layer" --> future

    style past fill:none,stroke:#ffffff,color:#ffffff
    style future fill:none,stroke:#ffffff,color:#ffffff
    style P1 fill:#D85A30,stroke:#993C1D,color:#ffffff
    style P2 fill:#D85A30,stroke:#993C1D,color:#ffffff
    style P3 fill:#D85A30,stroke:#993C1D,color:#ffffff
    style P4 fill:#D85A30,stroke:#993C1D,color:#ffffff
    style F1 fill:#185FA5,stroke:#0C447C,color:#ffffff
    style F2 fill:#185FA5,stroke:#0C447C,color:#ffffff
    style F3 fill:#185FA5,stroke:#0C447C,color:#ffffff

An engineer previously responsible for daily reports and event tracking can transition to "metrics governance" or "growth analytics platform," defining the calculation definitions for key metrics like GMV, funnels, and delivery time, establishing the computation pipeline from raw events to metrics, and enabling business teams to query data themselves. AI generates the code, but humans must verify the correctness of metric definitions and business logic.

Capabilities to build: understand what key metrics are, how to layer them, and the causal relationships between them; unify definitions of concepts like "user" and "order" across different systems; determine which metrics need real-time computation and which can be batch-processed, balancing cost and latency; package data pipelines into self-service tools for business users.

Transitioning from a "data engineer" to a "data architect" requires deep business understanding. A purely technical background can lead to building things that are "technically correct but useless for the business." This is a key point to watch. Once you have business acumen, AI's replaceability becomes very low.

5. Full-Stack Engineer

Full-stack engineers actually have the most opportunity in the AI era. With AI handling frontend, backend, scripting, deployment, and testing, the ability to take a complete product from requirements to launch becomes even more scarce.

flowchart TB
    subgraph past ["Traditional Responsibilities"]
        direction TB
        P1["Frontend page development"]
        P2["Backend API writing"]
        P3["Simple operations and deployment"]
        P4["Various miscellaneous tasks"]
    end

    subgraph future ["Transformation Directions"]
        direction TB
        F1["Independent Product Engineer<br/>Requirement clarification / Product design / Solo delivery"]
        F2["Technical Co-founder<br/>Vertical SaaS / Micro products / Business loop"]
        F3["AI Collaboration Delivery Expert<br/>Full-chain AI collaboration / Rapid iteration"]
    end

    past -- "AI takes over execution layer" --> future

    style past fill:none,stroke:#ffffff,color:#ffffff
    style future fill:none,stroke:#ffffff,color:#ffffff
    style P1 fill:#D85A30,stroke:#993C1D,color:#ffffff
    style P2 fill:#D85A30,stroke:#993C1D,color:#ffffff
    style P3 fill:#D85A30,stroke:#993C1D,color:#ffffff
    style P4 fill:#D85A30,stroke:#993C1D,color:#ffffff
    style F1 fill:#185FA5,stroke:#0C447C,color:#ffffff
    style F2 fill:#185FA5,stroke:#0C447C,color:#ffffff
    style F3 fill:#185FA5,stroke:#0C447C,color:#ffffff

For example, building a lightweight SaaS for small training institutions that handles "lead management + class consumption analysis + parent follow-up." Previously, this required a team of at least 3-5 people. Now, one person plus AI can create the first version and launch it for a fee. The key isn't a comprehensive tech stack, but the ability to independently complete the entire process from business analysis to deployment and maintenance.

The required skills are more product- and delivery-oriented: discuss requirements with business stakeholders, create prototypes, and set priorities; make trade-offs between features, performance, cost, and speed, considering both frontend and backend; handle the entire chain from development to launch, monitoring, and iteration; know how to evaluate whether the product truly solves the problem.

The transformation cycle is 1-2 years, best done in a small team or personal project. The market opportunity is the largest — vertical SaaS, internal tools, and startup projects all need such people. Previously, large and medium enterprises favored specialized division of labor, and full-stack's main battlefield was in small companies, startups, or innovative projects. Now, with AI's rise, large and medium enterprises are also turning to full-stack development.

The above only lists a few engineer roles. Other roles like algorithm, system, operations, and test engineers also face transformation, all needing to transition to AI drivers.

V. Transformation Paths for Programmers

In the AI era, individual companies are becoming more common. It's normal for one or a few people to do the work of a team. But not everyone needs to go into management or start a business. If you still want to stay on the front lines, the following paths are viable. The first two are based on transforming within your current role; the last three are new paths outside your role.

flowchart TD
    A(["Programmer Transformation Paths"])
    A --> B["Path 1<br/>Architecture & System Design"]
    A --> C["Path 2<br/>Business Requirements & Product Engineering"]
    A --> D["Path 3<br/>Personal Products & Independent Development"]
    A --> E["Path 4<br/>Efficient Delivery & Freelancing"]
    A --> F["Path 5<br/>Enterprise AI Adoption Consultant"]

    style A fill:#444441,stroke:#2C2C2A,color:#ffffff
    style B fill:#185FA5,stroke:#0C447C,color:#ffffff
    style C fill:#1D9E75,stroke:#0F6E56,color:#ffffff
    style D fill:#D85A30,stroke:#993C1D,color:#ffffff
    style E fill:#BA7517,stroke:#854F0B,color:#ffffff
    style F fill:#534AB7,stroke:#3C3489,color:#ffffff

Path 1: Architecture Design & System Design

This is an extension of the backend role from Chapter IV, suitable for backend, senior full-stack, and infrastructure engineers. Value is no longer in writing services but in defining boundaries, decomposing modules, capacity planning, setting SLAs, and controlling costs — deciding what to hand over to AI and what must be manually backed up. A typical path is upgrading from a senior backend engineer on a multi-year order system to a business architecture lead, decomposing business domains, defining event models, and creating disaster recovery strategies.

Path 2: Business Requirements & Product Engineering

Suitable for frontend, client-side, and engineers who have done business development for years. What AI fears most isn't hard code but unclear problem statements. People who truly understand business become more valuable in the AI era. For example, a frontend engineer who has long worked on operations platforms and understands business processes, permission models, and form rules can upgrade to a "product engineer" — defining requirements themselves, having AI generate pages and APIs, and doing their own acceptance testing.

Path 3: Build Personal Products, Create Small but Beautiful Applications

This is the biggest new opportunity the AI era offers programmers.

Previously, building a product alone was hard due to insufficient manpower and long cycles. Now, the barrier has dropped significantly. With a technical foundation and AI collaboration, vertical industry SaaS, small admin panels, internal tools, and data analysis tools can all be started by one person.

For example, a full-stack engineer builds a lightweight management tool for a specific vertical industry. Previously, this needed a team of at least 3-5 people. Now, one person plus AI can create an MVP, launch it, charge for it, and iterate. The core competitive advantage isn't technical breadth but industry understanding and rapid delivery capability.

Path 4: Efficient Delivery & Freelancing

Previously, the biggest problem with freelancing was lack of time and slow delivery. Now, it's different.

By integrating AI into the delivery process, many small to medium projects become feasible, such as corporate websites, CRM/ERP customization, mini-programs, data reporting platforms, and automation scripts.

For example, an engineer familiar with React and Java previously took 6 weeks to deliver a backend system. Now, by breaking down requirements clearly, having AI generate the main frontend and backend code, and focusing on business rules and deployment themselves, they can deliver the first version in 2-3 weeks. The unit price may not be higher, but the output per unit of time increases significantly.

Path 5: Enterprise AI Adoption Consultant

The barrier is not low, but it's suitable for senior engineers.

Many companies don't lack "people who can use AI"; they lack people who can truly integrate AI into the development process. This includes building team prompt specifications, setting up internal knowledge bases, getting AI involved in coding, testing, and review, defining automation boundaries, and integrating model capabilities into business systems.

For example, an engineer with experience in platform engineering or data platforms can do "AI R&D efficiency transformation" for medium-sized enterprises. This isn't about selling concepts but concretely implementing requirement templates, code standards, knowledge bases, testing strategies, and automated review processes.

VI. What Using AI Well Actually Brings

The benefits of learning AI are roughly in four directions: improved delivery efficiency, ability to take on more complex projects, a clear advantage in promotions (architect, tech lead positions will prioritize those who understand system design and can use AI to improve efficiency), and higher career freedom (lower barriers for freelancing, independent development, and small teams).

Currently, knowing how to use AI is an advantage, much like knowing how to use a computer was back then. But when "using AI" becomes a basic skill, this advantage will also level out. What truly appreciates in the long run is the combination of system design ability, business understanding, and AI collaboration skills — not just "I know how to use AI, I've mastered the Agent workflow."

flowchart LR
    A["Master AI Collaboration"] --> B["Faster, more stable delivery"]
    B --> C["Enter the design and decision layer"]
    C --> D["Take on higher-value work"]
    D --> E["More career choices"]

    style A fill:#185FA5,stroke:#0C447C,color:#ffffff
    style B fill:#534AB7,stroke:#3C3489,color:#ffffff
    style C fill:#D85A30,stroke:#3C3489,color:#ffffff
    style D fill:#1D9E75,stroke:#0F6E56,color:#ffffff
    style E fill:#ff6600,stroke:#0F6E56,color:#ffffff

Using AI well is actually not easy; it's a new discipline. Having a handy tool and knowing how to harness it to truly unleash its efficient value requires continuous exploration and practice.

VII. Four Abilities Worth Strengthening

Based on AI programming practice over the past two years, especially since the second half of 2025, the following four abilities are very valuable and can stand the test of time.

1. Defining the Problem Clearly

Many people feel AI output quality is low or doesn't meet requirements, but the root cause may be that the problem wasn't clearly stated. Break down requirements along these five dimensions:

Answering these five questions clearly before letting AI start will significantly improve output quality.

2. Making System Design Trade-offs

AI can quickly generate several solutions, but choosing which one and why still requires human judgment.

Every time you push a solution forward, seriously consider these trade-offs:

There are no standard answers; they depend on experience, the company's stage, budget, and risk tolerance. AI can't help you make these decisions.

3. Structuring the Problem, Guiding AI's Direction

AI is powerful, but it solves problems based on existing general rules. Every company and project is different, requiring many personalized considerations.

For example, when encountering a search problem, you need to decide whether to use an index, inverted index, or B-tree. For a scheduling problem, you need to decide if a greedy algorithm is sufficient or if dynamic programming is needed. For real-time computation, you need to decide how to divide time windows and handle late-arriving data.

Quickly judging the problem type and giving direction — AI handles the implementation details. If the direction is right, efficiency can multiply several times. If the direction is wrong, even the fastest code generation is useless.

4. Validating AI Output

AI's most common mistake is producing something that "looks right but is actually problematic." During review, at least scan for these categories:

You don't need to check every detail every time, but most problems fall into these categories.

VIII. A Practical Transformation Roadmap for Programmers

We need to be prepared to fully switch to driving AI programming, writing little to no code ourselves, and relying entirely on AI to write it.

flowchart LR
    A["Months 1-2<br/>Integrate AI into daily development"]
    --> B["Months 3-4<br/>Supplement requirements, architecture, and validation skills"]
    --> C["Months 5-6<br/>Complete a full practical project"]

    A1["Code generation / Test generation / Documentation generation"]
    B1["Requirement decomposition / System design / Code review"]
    C1["From requirements to launch<br/>Build a knowledge base and templates"]

    A --> A1
    B --> B1
    C --> C1

    style A fill:#D85A30,stroke:#993C1D,color:#ffffff
    style B fill:#185FA5,stroke:#0C447C,color:#ffffff
    style C fill:#1D9E75,stroke:#0F6E56,color:#ffffff
    style A1 fill:#D85A30,stroke:#993C1D,color:#ffffff
    style B1 fill:#185FA5,stroke:#0C447C,color:#ffffff
    style C1 fill:#1D9E75,stroke:#0F6E56,color:#ffffff

Month 1: Make AI a Daily Tool

Choose a suitable tool (Claude, Codex, Gemini, Cursor, Windsurf, GitHub Copilot, etc.), use it daily, keep it fresh, try several. Start with small tasks: write tests, scripts, design documents, requirement descriptions. Record which AI outputs are directly usable and which need significant modification, and find your rhythm.

There are two common pitfalls. One is frequently tweaking prompts — 80% of the benefit comes from good requirement definition, not prompt fine-tuning. The other is handing everything to AI, leading to chaotic code style and technical debt. Define an "AI delivery standard" for yourself and build your own Skills system.

Within about 2 weeks, you should form the habit of instinctively thinking "let AI do a first pass" when encountering a task, with a direct usability rate of over 90% for simple tasks.

Month 2: Supplement Upper-Level Skills

Focus on strengthening one weakest area; don't try to do too many:

This month, it's easy to "learn a lot but not apply it in real work." It's best to practice on real projects. By this stage, you should be able to write a system design document you thoroughly understand, and your Code Review feedback should rise from "formatting and naming" to "logic, performance, and maintainability."

Month 3: Complete a Full Project

Choose a project that is small but complete — an admin panel, internal tool, mini-program, or automation system. The focus isn't on scale but on going through the entire process from requirements to launch.

Require yourself to: write requirements clearly using a requirement description framework; decide before starting which parts AI will generate, which you'll write manually, and which open-source components you'll use; have at least 90% of the code produced by AI, with you only responsible for review and acceptance; try not to write code yourself; if you must, only write core strategic logic and key scheduling; the project must actually run.

After finishing, look back and see if you can explain why you designed it that way and why you chose that solution. If you can, you've gone through a complete AI-era development process, and you can apply this framework to any future project.

IX. Finally

AI makes many programmers anxious, and that's normal. Not because of AI itself, but because the core skill of the past decade (writing code) is being gradually replaced.

But if we think it through, it's not that scary.

First, AI replacing humans will be a process, likely taking a year or two to adjust.

Second, transitioning to an AI driver isn't difficult for programmers. You don't need to delve into the principles of AI large models (understanding them is enough), nor do you need to chase the latest frameworks and APIs. You are still a software engineer, just programming in a different way.

Also, not everyone has to "transform." Some people just love writing code, line by line. That's perfectly fine; this kind of work won't disappear, and the most critical parts still rely on humans.

The pace varies greatly across companies and domains. Big tech companies are leading. Infrastructure teams may not be immediately affected. The pressure on startups and large companies is different.

If you have the energy, spend a few months going through the complete process of "using AI from requirements to launch" once. Then think about: what work AI can do well, what work still needs you, what your role is in the new process, and whether you're willing to move in this direction.

Finally, in the AI era, we are no longer code writers, but AI drivers and decision-makers. AI is strong at execution; humans are stronger at decision-making.

Related Links