Since September, I’ve spent more than three months working on Wegic 2.0. From the initial confusion to building a new cognitive framework, the density and change packed into these short three months feels like going through an entire year. Taking advantage of this period of consolidation, it’s also a good time to systematically look back on the growth and changes during this time.

I. Retrospective on the Technical Architecture

Speaking of architecture, it’s unavoidable to compare 1.0 and 2.0.

1. The failure of 1.0 mainly came from three aspects:

1. The custom data structure didn’t match the AI training corpus, making it hard for the model to fully发挥 its capabilities.
2. Insufficient context passing, which hurt continuity and accuracy of tasks.
3. A workflow that was too rigid, lacking flexibility and struggling to adapt to complex application scenarios.

2. Architectural improvements in 2.0

2.0 addressed the above problems and further embraced an Agent architecture. Of course, the current Agent architecture can’t be called the optimal solution—it’s still a trade-off based on today’s technical reality. While we’re at it, let’s also talk about mainstream Agent approaches:

Mainstream Agent Patterns

1. ReAct (Reason + Act) — widely adopted by Cursor, Claude Code, etc.
2. PTA (Plan → Think → Action) — the Plan mode of many AI tools is based on this
3. LangGraph (state machine + DAG) — a controllable execution architecture for multi-agent systems
4. Multi-Agent — collaborative execution by multiple agents
5. Memory Agents — with long-term memory mechanisms

No single architecture can cover all business scenarios, so continuous practice and adjustment in real business contexts is still necessary, gradually forming a system that fits one’s own needs. This may also be the best path for today’s architectural evolution and agile iteration.

References:

• ChatGPT Share
• Towards a Science of Scaling Agent Systems (arXiv)

Towards a Science of Scaling Agent Systems

1. The more tools / the more complex the environment, the more lethal the coordination tax of multi-agent systems becomes
2. When the single-agent baseline is already high (about >45%), adding agents often yields diminishing returns or even negative gains
3. The multi-agent topology determines whether errors are “suppressed” or “amplified”

Token Efficiency

Introducing GPT-5.2 GPT‑5.2 is priced at $1.75 per million input tokens and$14 per million output tokens, with a 90% discount for cached inputs. In multiple agent evaluations, we found that although GPT‑5.2 has a higher per-token cost, the total cost to reach the same quality level is actually lower because GPT‑5.2 has higher token efficiency.

Introducing Claude Opus 4.5 With the effort level set to medium, Opus 4.5 achieves Sonnet 4.5’s best score on SWE-bench Verified while using 76% fewer output tokens. At the highest effort level, Opus 4.5 improves performance by 4.3 percentage points over Sonnet 4.5 while using 48% fewer tokens.

II. Changes in Team Collaboration

The most obvious change is a shift in collaboration from the traditional “separation of product and engineering” model toward agile iteration.

From passive execution → proactive exploration

This approach brought significant benefits to the progress of Wegic 2.0:

• Ideas can be quickly validated and implemented
• Shorter development cycles
• AI Coding makes it possible to deliver a demo within a week
• An MVP can go live within a month

Each member’s initiative has been greatly unleashed.

If you ask: “Is this the best way to collaborate?” My answer is: At least for now, it’s suitable. People can发挥 freely instead of being constrained by process.

As AI capabilities improve, collaboration models will continue to evolve. Maybe in the future everyone could become a super individual: able to complete everything end-to-end—from product and development to testing and ops.

"Intangible" vs "Tangible"

My ideal collaboration style might be: Show me the demo.

III. The Impact of AI Coding on the Team and Individuals

Since October, I’ve gone all-in on Full-vibe Coding. My most immediate feelings are:

1. A massive boost in efficiency from 0 to 1

In the demo stage, AI can basically “give you exactly what you ask for.”

2. But as codebase scale grows, more human control is needed

As projects become more complex, AI is no longer “fully automatic.” You need:

• Humans to define a plan in advance
• Proactively review AI outputs
• Interrupt and adjust when necessary
• Clearly tell the AI how to implement things

This is a new paradigm of human–AI collaboration.

3. Personal mindset shifts accordingly

From the initial “AI can do anything,” to today’s “I control AI.” The deeper you use it, the clearer it becomes:

The productivity revolution of AI Coding is beyond doubt, but the foundation of code quality still lies in people.

For example: a programmer with a sense for Bad Smell versus one without that awareness will definitely produce different code quality even using the same tools.

IV. In the Era of AI Coding, a Programmer’s Core Competitiveness

I think it includes at least the following:

1. Coding and engineering practice ability Small functions, SOLID, design patterns, TDD, DDD, refactoring principles, etc.
2. Problem decomposition ability (Trouble Shooting) Being able to break big problems into executable small units.
3. End-to-end perspective Not just writing code, but also understanding product, interaction, data, and operations logic.
4. Abstraction ability Extracting commonality from complex systems and building models.
5. Understanding of fundamentals Those who grasp the essence are better able to驾驭 AI.

V. Some Thoughts on Integrating Backend Capabilities

On whether to let AI directly take over, deploy, and host users’ backend capabilities, my current view is:

Now is not the right time for “self-deployed, fully managed backends.” Going with third-party integrations (for example, Supabase) may be a better choice than building a Supabase yourself.

The reasons are as follows:

1. Backends are “invisible” and require strong reasoning to build correctly

Unlike UI, which is visual, backend maintenance and construction rely heavily on abstraction and logical reasoning—an area where current AI still isn’t fully competent in complex systems.

2. Business scale amplifies backend complexity, and AI Coding iteration isn’t mature enough yet

As the business grows, backend pressure increases exponentially. AI is currently better at “0 to 1,” but for the long-term evolution from “1 to 100,” there are still gaps in stability and controllability.

3. Backend business changes frequently, placing higher demands on the code

Backend changes often have system-wide ripple effects:

• Complex lineage relationships
• Deep dependency chains
• Huge code context (current AI context windows still can’t fully carry this)

This poses a major challenge for AI-driven automated changes.

4. The security and risk of business data cannot be ignored

Having AI fully manage users’ core data carries huge risk:

• Data leakage
• Permission issues
• Uncontrollable gray-box behavior

The industry is cautious about this today.

5. AI lacks an “operational environment” to complete real backend tasks

Backends are not just about writing code—they also include:

• Code design
• Database management
• Permission systems
• Network configuration
• Deployment / operations
• Monitoring and tuning

At this stage, the environments AI can operate in are far from sufficient to support a complete closed loop of these capabilities.

Conclusion: It’s not that we won’t do backend integration, but that we need a more realistic path

For simple business needs, third-party services like Supabase are already sufficient for most scenarios, while remaining safe, controllable, and efficient. In the future, as AI capabilities and tooling mature, “AI fully taking over the backend” may become a trend—but at least now is not the best time.

More Thinking, More Value