跪拜 Guibai
← Back to the summary

When the AI Bubble Bursts: Engineering Discipline Is the Only Hedge

The Perils and Opportunities of the AI Era: When the Tide Goes Out, How Should Technologists Position Themselves?

Preface: Amid the Hype, Everyone Should Coolly Think About a Fallback

Over the past two years, the software industry has experienced a rare collective frenzy. Vibe Coding became a buzzword: one sentence generates an application, a weekend launches a product, and the narrative that "you don't need to understand code" is everywhere. Large-model company valuations have climbed steadily, compute orders are booked years out, and the investment community's logic has shifted from "will this project make money?" to "is this story big enough?"

Meanwhile, another group's worries are fermenting: Is the AI bubble replaying the Internet mania of 2000? Who will maintain the systems built on prompts two years from now? When "it runs" becomes the team's default delivery standard, and technical debt accumulates at an unprecedented pace, how will it be settled?

This article does not intend to be a prophet. Whether the bubble will formally burst in 2027 is something nobody can answer with certainty. But treating "if it bursts" as a thought experiment and running through it is very worthwhile—because its value doesn't lie in whether the prediction comes true, but in the fact that: regardless of whether the bubble bursts, or when, the problems exposed by the thought experiment already exist today, and the answers it gives already begin to work today.

Bubbles are cycles, and cycles rotate; engineering capability is an asset, and assets can cross cycles. This article talks about three things: where the danger is, where the opportunity is, and how technologists should respond to change in the midst of change. Finally, I will combine my ongoing work on the GoWind framework and discuss why the route of "deterministic development" is particularly worth betting on in this era.

1. The Danger: If the Bubble Bursts, What Would the Picture Look Like?

Taking "2027 AI bubble burst + Vibe Coding technical debt collective detonation" as a hypothetical scenario, running it through, it most likely would be a dual technical and financial credit crisis, similar to the interweaving of the 2000 Internet bubble and the 2008 subprime mortgage crisis.

1.1 Shutdown Wave: "Black Box Systems" That No One Can Maintain

The first to burst will not be the large-model companies, but the enterprises whose core systems are built by piling up Vibe Coding.

One can imagine such a scenario: a batch of startups and non-tech-led enterprises, between 2025 and 2026, at extremely low cost, let AI "vibe" their core business systems into existence. The founding team may not have a single person who truly understands those hundreds of thousands of lines of code. When a system suffers an online incident due to a deep concurrency flaw or architectural collapse, the remaining employees face a labyrinth of "AI scribbles"—no documentation, no design, no one who can understand it. The cost to fix is so high that rewriting is preferable, but rewriting means a long business shutdown. SaaS services, e-commerce sites, and enterprise intranets going down in batches is not an exaggeration.

The outsourcing and takeover ecosystem is equally dangerous. Many teams between 2025 and 2026 used AI for cost reduction and efficiency gains, frantically taking contracts, delivering several times faster, but no one really checked the engineering quality of the deliverables. If these projects collectively fail during the warranty period, the security and stability clauses in the contracts turn into astronomical compensation claims, enough to force a brutal shakeout of the entire outsourcing ecosystem.

The core problem here is not how bad the AI-written code is—in fact, AI-written single-point code quality is often higher than the human average—but rather: when no one is responsible for the system as a whole, the system is in a state of unmanned driving. The horror of technical debt has never been the size of a single amount, but in compound interest and concentrated repayment.

1.2 Supply Chain Interruption and the "Cloud Black Hole"

The second layer of crisis is on the supply side. A fierce capital race is underway in the large-model industry. When the tide goes out, a wave of small and medium-sized model companies going bankrupt is almost a certain script. Systems deeply tied to a specific AI API will, one morning, be completely paralyzed by "service provider shutdown"—the same story as relying on a single SaaS provider that died suddenly, only transmission is faster.

Further upstream is compute. NVIDIA's orders facing devastating cancellations, a glut of second-hand H100/B200 chips being auctioned on the market, cloud vendors forced to cut prices to clear idle AI compute infrastructure—these scenes have precise counterparts in the "fiber optic dark fiber" history after 2000. Back then, telecom companies laid fiber far beyond demand, and after the bubble burst, fiber changed hands at scrap prices, but that fiber later carried the entire mobile Internet era. Compute will likely follow the same path: asset prices collapse, infrastructure remains.

1.3 Credit Bankruptcy and the "Anti-AI Movement"

The deepest crisis is at the level of credit. Enterprise executives' attitude toward AI could swing overnight from "embrace or be eliminated" to the other extreme—from blind enthusiasm to extreme reactivity and conservatism, producing compliance requirements like "whoever uses AI nakedly is responsible." VCs become completely immune to AI stories, and capital flows back to businesses with real cash flow. Just as after 2000, ".com" went from glory to shame, but Amazon and Google completed their fundamental-building exactly during that cold winter.

It is worth emphasizing: what a bubble burst kills is never the technology, but the speculation around the technology. The Internet did not die in 2001, and subprime did not eliminate housing demand. Similarly, AI will not disappear because of a bubble burst; what disappears is the illusion that "you can deliver production-grade systems without engineering capability."

2. The Opportunity: The "Renaissance" of Software Engineering After the Crisis

After every shakeout, the industry enters a cycle that values fundamentals more. If the above scenario materializes, software engineering will not disappear; instead, it will usher in a "Renaissance"—a return to valuing engineering discipline.

2.1 The "Artisan" Rises in Value

The most sought-after people in the market will no longer be Vibe Programmers who can quickly crank out prototypes with prompts, but senior engineers with deep foundational skills, who can read complex logs, perform performance analysis, and do architectural refactoring. These people will be like "nuclear power plant accident cleanup teams," hired to handle the technical mess of various enterprises, responsible for assessing, taking over, and restructuring AI legacy systems that no one understands.

This is not fantasy but market law: when the supply side is flattened by "everyone can generate code," what becomes scarce are those who "can take responsibility for results." Generating a piece of code takes a minute; judging whether that code can go to production takes ten years of skill.

2.2 "Compliance-first AI" Replaces "Generative AI"

The industry will learn from the pain and cage AI, moving from "free-form conversational programming" into a cage: strongly typed languages (Go/Rust), standard CI/CD pipelines, automated static code analysis (SAST), and mandatory architectural layering validation. AI's role converges from "a free-wheeling engineer" to "a local filler compliant with specific interfaces," and the acceptance criteria for code output change from "it runs" to "compliance first."

Interestingly, this direction is precisely the optimal intersection of AI capability and engineering governance: the stronger the constraints, the more stable AI's output; the clearer the rules, the smaller the hallucination space. Freedom is AI's amplifier, and also its source of chaos.

2.3 Popularization of "Small but Beautiful" Local Models

The market no longer blindly pursues trillion-parameter general-purpose large models. Enterprises will turn to locally deployed open-source industry-fine-tuned models of 8B~32B: no network connection, no per-token billing, no dependency on any provider that might go bankrupt, focusing only on completing business code generation and assisting development within a specific framework. Safe, controllable, extremely low cost—"model autonomy" will become a standard enterprise feature, just like "data sovereignty" did back then.

2.4 The "Auditization" of Software Engineering

Just as financial statements need audit by accounting firms, in the future, business systems may need to pass a third-party "code robustness and AI contamination audit" before going live or raising funds: whether architecture has clear layering, whether dependencies are orderly, whether critical paths are understandable by someone, the proportion of AI-generated code and test coverage. Software delivery will shift from "delivery means end" to "continuous accountability after delivery."

3. How Technologists Should Position Themselves: Four Actionable Answers

With the scenario laid out, the landing point returns to each individual technologist. Change is not scary; the scary thing is using an old map to navigate a new continent. The following four principles are, in my view, valid no matter which way the bubble goes.

3.1 Use AI as an Amplifier, Not a Crutch

An amplifier amplifies your existing abilities: someone who understands concurrency uses AI to generate concurrent code and can spot deadlock risks at a glance; someone who understands databases uses AI to write queries and can predict slow queries and index invalidation. A crutch is the opposite: you outsource your judgment, your ability atrophies over time, and atrophy is irreversible.

The specific test is simple: for every piece of code AI generates, can you give a reason "why it's right" or "why it's wrong" in a Code Review? If you can, AI is your leverage; if you can't, you are AI's risk carrier.

The core competitiveness is shifting: from "knowing how to write code" to "knowing how to define problems, review code, and dare to be responsible for results." The cost of writing code approaches zero, which precisely means the cost of judging code will rise sharply—this is the new value anchor for technologists.

3.2 Return to the Fundamentals and Accumulate "Assets That Survive Cycles"

Frameworks become obsolete, languages iterate, products die, but some things haven't changed for decades: operating systems, network protocols, data structures and algorithms, concurrency models, distributed consistency, database principles. These are worth investing in not because "interviews test them," but because all upper-level changes eventually land on these unchanging layers to be resolved. Online incidents never happen in prompts; they happen in memory, in networks, in locks.

At the same time, deliberately preserve "hand-crafted" abilities: regularly write a complete module without AI, read an open-source project's source code, debug a full incident from logs to stack traces. These exercises maintain not nostalgia, but your independent verification ability in the AI era—without verification ability, you can't even judge whether AI output is right or wrong.

3.3 Tame AI with Engineering Discipline, Don't Be Led by AI

Don't choose between "embrace AI fully" and "reject AI entirely". The right posture is to use AI within a strongly constrained framework:

This workflow's essence is to confine "AI's freedom" within "engineering determinism." You'll see that this is exactly the direction GoWind has been practicing.

3.4 Build Verifiable Credibility

After the bubble bursts, the market will scrutinize everyone's true quality with the harshest eyes. At that point, what proves you is not the keywords on your resume, but: you can present architectural designs and explain every trade-off, your maintained open-source project has real commit history and Issue responses, your debugged online incidents have complete postmortems, and your code stands up to others' audits. Credibility = verifiable capability. Start accumulating from today, and every cycle is in your favor.

4. GoWind's Practice: Hedging Uncertainty with "Deterministic Development"

The above sections are principles; this section talks about facts. The GoWind framework I participated in developing is precisely turning the workflow in section 3.3 into a runnable engineering system. It wasn't designed for this hypothetical 2027, but every design decision answers the question "how to do deterministic software development in the AI era."

4.1 Fact One: Contract-Driven, One Proto Generates Six Kinds of Output

The engineering foundation of the GoWind ecosystem is "taking .proto as the sole source of truth": interface definitions, data models, error codes, and validation rules are all converged into Protobuf contracts. One buf generate simultaneously produces backend gRPC stubs, HTTP stubs, error code helpers, request validators, PII desensitizers, OpenAPI documentation, and TypeScript clients for the frontend.

What does this mean? It means the industry's chronic problem of "documentation and implementation inconsistent" is eliminated mechanically—documentation is not written; it is compiled from the source of truth. When an interface changes, all six outputs update synchronously, and frontend TS types align automatically. For AI collaborative development, this strong contract is the most reliable guardrail: AI doesn't need to "guess" what an interface looks like; it faces a type world guaranteed by the compiler, and the hallucination space is compressed to a minimum.

4.2 Fact Two: Framework as Constraint, AI Can Only Do Fill-in-the-Blank

GoWind Admin's backend is built on go-kratos, and from top to bottom, a standardized paradigm is fixed: fixed directory structure (api/service/data), Wire static dependency injection, globally unified error codes, standardized parameter validation, and unified adaptation for both RPC/HTTP protocols. With built-in Lint rules and CI checks, architectural layering, naming conventions, and interface contracts are forcibly intercepted, and non-compliant code cannot enter the main branch.

In this system, AI's role is clearly defined: it has no right to customize project layering or interaction contracts; it can only fill in business logic within the framework's established rules. Even with multiple rounds of iteration and multiple agents collaborating, the project's architectural model and coding style remain uniform—the conditions for forming an "AI code mountain" are eliminated at the source.

4.3 Fact Three: Codegen and AI Divide the Work, Each Doing What It's Good At

GoWind has a built-in low-intrusion code generator: based on table structures, it generates in one click the backend API/Service/Data three-layer code, frontend CRUD pages, route permission configuration, and database migration scripts. This forms a clear human-machine collaboration chain—humans are responsible for table design and business decisions, the generator is responsible for deterministic code, and AI is responsible for filling in the real business logic within the generated skeleton.

The deterministic parts go to deterministic tools (reproducible, auditable, zero hallucination), and the creative parts go to AI. Once this boundary is clear, efficiency and quality are no longer in opposition.

4.4 Fact Four: Business Foundation and Architectural Flexibility, Covering Real Production Needs

GoWind is not just an empty shell. Admin includes a complete, production-verified business foundation: RBAC three-level permissions (interface-level/button-level/data-level), multi-tenant data isolation, full-chain authentication, operation auditing, dynamic menus, task scheduling, and other essential modules for middle-office and backend systems. The ecosystem extends to production-level solutions in multiple verticals: Shop (e-commerce), CMS (content), UBA (user behavior analysis), OA (workflow), and ERP (accounting consistency).

4.5 Fact Five: A "Learning Ladder" from Monolith to Microservices

The product layout of the GoWind ecosystem is itself a progressive architecture learning path:

This "monolith entry → minimal microservices advancement" ladder design echoes this article's theme: the best way to deal with change is never to reach the sky in one step, but to advance gradually. So it is for learning curves, for architecture evolution, and for industry cycles.

4.6 Why This Route Is Worth Betting On

Compare GoWind's practice with the trends in section 2, and they overlap heavily: contract-driven corresponds to "compliance first," framework constraints correspond to "Guardrailed AI," Codegen plus locally deployable Go tech stack corresponds to "small but beautiful, autonomous and controllable," and layered norms with CI interception correspond to "auditization."

In other words, GoWind is betting not on "AI will succeed" or "AI will fail," but on "no matter how AI develops, engineering discipline is a hard requirement." This is a bet that doesn't depend on the direction of any bubble—if the bubble keeps inflating, it turns human-machine collaboration efficiency into quality; if the bubble bursts, it is the scaffold for rebuilding order on the ruins.

5. Conclusion: Bubbles Burst, Engineering Endures

Back to the opening question: If the bubble really bursts in 2027, what would happen?

It would probably be a brutal process of removing the chaff. It would use the iron fist of online incidents and economic losses to push speculators off the table; it would shatter the illusion that "engineering capability is unnecessary"; then it would push the industry back to an ancient and simple value ranking—determinism over showing off, quality over speed, people who can be responsible for results over people who can write prompts.

The Internet bubble did not kill the Internet; it filtered out Amazon and Google. If the AI bubble bursts, it similarly will not kill AI, but will filter out true AI-assisted engineering: humans define architecture and norms, frameworks solidify engineering standards, toolchains handle deterministic output, and AI focuses on the local creativity it is truly good at.

For technologists, the answer is never in prediction, but in preparation: accumulate unchanging foundational skills, hold firm to architecture decision rights, cage AI with strong constraints, and build verifiable credibility. Cycles rotate, tides rise and fall; those who are prepared always ride the waves, not get crushed by them on the beach.

May we all be as free as the wind—but the confidence of freedom comes from the solid engineering foundation underfoot.

Further Reading and Project Entry Points