The Year of AI Applications: Saying 'Yes' While Ignoring Risks? A Comprehensive Open Source Log of Software Development's Journey

marsbitPublished on 2026-06-16Last updated on 2026-06-16

Abstract

The Year of AI Applications: Blindly Saying "Yes" While Ignoring Risks? A Software Development Log Goes Fully Open Source. AI-generated code harbors risks hidden within seemingly correct programs, potentially leading to data leaks or asset loss. The open-source project "Narwhal AI Code Risks," from Peking University's Narwhal-Lab, compiles real-world cases, early warning signs, and typical risk pathways. Its goal is to help developers identify potential hazards early and avoid repeating past mistakes. In 2026, code is generated faster than ever but deployed with less scrutiny. The danger often lies not in glaring errors, but in code that appears normal—syntactically correct, passing all checks—yet introduces subtle but critical flaws like non-existent dependencies, excessive permissions, or exposed databases. A stark example is the Moonwell cbETH oracle incident. A configuration file error, where a cryptocurrency price was set to ~$1.12 instead of ~$2,200, slipped through 28 checks and a pull request signed by both AI (Claude, Copilot) and human developers. This "semantic deviation" resulted in a loss of $1.78 million. The risk is that AI can produce functionally valid code that is semantically wrong for the business context. As AI moves beyond simple code completion to modifying configurations, installing dependencies, and operating via autonomous agents, it traverses longer, less traceable paths within software engineering, blurring traditional boundaries and oversight ...

The risks of AI-written code lurk within seemingly correct code, potentially leading to data breaches or asset loss. The open-source Narwhal AI Code Risks project compiles real-world cases, early warning signs, and typical risk pathways to help developers identify hidden dangers early and avoid repeating past mistakes.

In 2026, code is being generated at an ever-increasing pace, yet deployed with less and less scrutiny.

More and more often, user requirements are placed in a dialogue box, AI reads the context, completes functions, pulls dependencies, fixes configurations, and even conveniently generates tests.

Before you know it, a piece of code is already sitting in the repository, awaiting merge.

Users have developed a new habit: let the AI write it first and get it running, then see what needs fixing if there's a problem.

But in the software world, the most dangerous things are often pieces of code that appear utterly ordinary: syntactically correct, interfaces valid, tests passing, comments perfect.

Yet it may still introduce non-existent package names, open overly broad permissions, expose databases... or even allow an Agent capable of directly calling system tools to exfiltrate sensitive data from internal systems under prompt injection.

The real danger is not a flashing red error light. It's when all risk indicators show normal.

Risks from AI-generated code used to be scattered: a case buried in a security blog, a clue recorded in an Issue. When the next team encountered a similar problem, they had to piece together the source of risk from scratch and expend immense time and effort conducting large-scale empirical measurements on the code.

Now, Peking University's Narwhal-Lab has just open-sourced Narwhal AI Code Risks, which organizes these information fragments into three categories for researchers to examine: real incidents, early signals, and typical risk paths.

Paper link: https://github.com/Narwhal-Lab/Narwhal-aicode-risks

When All 28 Checks Pass, the System Still Veers Off Course

The first clue was a merged Pull Request, where the signature field prominently featured Claude Opus 4.6, Copilot, and four human developers. All 28 checks passed: No one spotted the issue.

Then, the liquidation bot took a few minutes and seized collateral worth $1,778,044.83.

The configuration file set the price of cbETH to its conversion ratio with ETH, approximately $1.12, instead of the actual price near $2,200.

A semantic price error slipped through development, review, and merge processes, ultimately turning into real loss in the financial system. This is the most glaring aspect of the Moonwell cbETH oracle configuration incident.

The problem lay in code without syntax errors, and human developers not immediately halting the anomalous process. On the contrary, it looked complete, smooth—a normal engineering delivery.

But it is precisely this undercurrent of normalcy that makes it a quintessential example of a security incident.

The risk of AI Coding lies in the fact that it doesn't always manifest as errors.

Often, it cloaks itself in the guise of a correct answer, quietly entering the engineering pipeline. The code runs, checks pass, PRs get merged, but the business semantics have already deviated from reality.

In low-risk projects, such semantic drift might just mean rework. But in sensitive contexts like finance or enterprise data systems, it directly leads to data leaks, exposed permissions, and asset loss.

When AI participates in writing code, modifying configurations, conducting reviews, or even co-signing and entering PRs, can we be sufficiently certain of how each deviation occurs?

The Green Light Doesn't Illuminate Every Corner

Early AI code assistants mostly remained at the level of local completions. If the syntax was wrong, the compiler would error, unit tests would fail, and the CI pipeline would block it.

Today's AI Coding ventures much further, while oversight has lagged behind.

It can read files, modify configurations, install dependencies, generate infrastructure scripts, and plan autonomously across multiple tasks via Agents.

AI is no longer just sitting on the sidelines handing over tools; it's beginning to enter longer chains of the software engineering process.

>The once-clear boundaries in software engineering are being reconnected by AI Agents into longer, harder-to-trace pathways.

Scattered Records Need a Common Logbook

Security incidents rarely start with complete conclusions. Some events have solid evidence and can enter the directory as real cases; some remain at the stage of community screenshots, researcher discussions, or preliminary disclosures, suitable only for continued observation; others are not tied to a single real event but have already formed clear patterns, suitable for proactive scenario planning.

Narwhal AI Code Risks divides the material into three layers: `cases/`, `inferred/`, and `scenarios/`.

`cases/` records real incidents with public sources and evidential chains; `inferred/` stores early signals not yet fully substantiated but worth continuous tracking; `scenarios/` organizes typical scenarios with clear risk paths, not yet bound to a single specific incident.

Without such public records, risks from AI Coding easily become short-term memories on the internet.

Today, everyone remembers a certain package name; tomorrow, they discuss a data exposure incident; after a few months, it's all covered by the next wave of tool hype. When similar problems arise again, teams still blunder like headless flies into waters of unknown risk.

What Narwhal AI Code Risks does is anchor these scattered risk fragments, allowing those who come later to turn to the same page.

Following Seven Index Categories to See Where Risks Come From

The problems brought by AI-generated code are not only in the code itself. They are in dependencies, in permissions, in Agent tool calls, and even more so in the way humans trust AI output.

Currently, Narwhal AI Code Risks categorizes risks into 7 types: Supply Chain, Code-Level Vulnerabilities, Cloud & Infrastructure Configuration, Agent Risks, Vertical Domain Risks, Intellectual Property & Compliance Risks, and Human Factors.

In Supply Chain risks, AI may recommend non-existent dependencies. In Code-Level Vulnerabilities, AI might reintroduce path traversal, missing input validation, or authentication issues into business code. In Cloud & Infrastructure Configuration, AI might grant overly broad permissions, public storage buckets, or exposed ports just to get the code running initially. Agent Risks are even more complex, moving beyond text generation to action execution. AI-generated artifacts are planting hidden dangers in real systems.

The AI Engine Is Firing Up, and the Logbook Is Just Beginning

As AI increasingly steps into the real world, related risk prevention and mitigation should not remain confined to post-mortems or scattered discussions.

The truly important aspect of Narwhal AI Code Risks is transforming risk cases into reusable knowledge.

Developers can use it to identify similar issues; security researchers can treat it as a sample library; tool vendors can extract detection rules and evaluation benchmarks from it; the open-source community can continue to contribute new cases, new evidence, and new risk types.

The AI engine is roaring, and every course deviation should leave its coordinates. Risks never disappear by being ignored, but experience can be recorded and passed on. The real value lies not in discovering a single vulnerability, but in ensuring later voyagers don't have to step into the same trap.

What Narwhal AI Code Risks is doing is providing an open-source logbook for the software world in the Year of AI Applications.

References:

https://github.com/Narwhal-Lab/Narwhal-aicode-risks

This article is from the WeChat public account "New Zhiyuan," author: LRST

Related Questions

QWhat is the main purpose of the Narwhal AI Code Risks open-source project mentioned in the article?

AThe main purpose of the Narwhal AI Code Risks open-source project is to systematically collect and categorize real-world risks, early warning signals, and typical risk patterns associated with AI-generated code. It aims to help developers identify hidden dangers early, avoid repeating past mistakes, and build a shared knowledge base for the community to improve safety in AI-assisted software development.

QAccording to the article, what makes AI-generated code particularly dangerous in software development?

AAccording to the article, AI-generated code is particularly dangerous because it often appears correct—with proper syntax, legal interfaces, passing tests, and perfect comments—yet can still introduce critical risks. These risks include adding non-existent package names, granting overly broad permissions, exposing databases, or enabling data exfiltration through prompt injection. The danger lies not in obvious errors but in code that passes all checks while containing flawed business logic or security vulnerabilities.

QWhat was the financial impact of the Moonwell cbETH oracle configuration incident described in the article?

AThe financial impact of the Moonwell cbETH oracle configuration incident was a loss of $1,778,044.83 in collateral. This occurred because the configuration file incorrectly set the price of cbETH to a conversion ratio with ETH, approximately $1.12, instead of its actual market value of nearly $2,200. The error passed through all development, review, and merging processes without detection.

QHow does the Narwhal AI Code Risks project categorize the information it collects?

AThe Narwhal AI Code Risks project categorizes the information it collects into three main layers: `cases/` for documented real incidents with public sources and evidence chains, `inferred/` for early warning signals that are not yet fully confirmed but worth monitoring, and `scenarios/` for typical risk patterns that are clear and replicable but not tied to a single specific event.

QWhat are the seven broad categories of risk identified by the Narwhal AI Code Risks project?

AThe seven broad categories of risk identified by the Narwhal AI Code Risks project are: 1. Supply Chain risks (e.g., recommending non-existent dependencies), 2. Code-level Vulnerabilities, 3. Cloud & Infrastructure Configuration risks, 4. Agent risks (related to autonomous AI actions), 5. Vertical Domain-specific risks, 6. Intellectual Property & Compliance risks, and 7. Human Factors risks.

Related Reads

After Tokenization of Assets, How to Exit?

Title: How to Exit After Asset Tokenization? Author: Symbiotic Compiled by: Hu Tao, ChainCatcher Summary: Tokenization addresses how assets go on-chain but largely leaves the redemption question unresolved. While tokenized assets can settle instantly, the underlying redemption for assets like treasuries, private credit, or real estate can take from T+1 to 180 days. This gap hinders DeFi adoption of Real World Assets (RWAs). Three emerging models aim to provide instant exit liquidity, differing primarily in their capital structure and efficiency: 1. **Balance Sheet Model (e.g., Grove Basin):** A single entity (like Sky) provides immediate liquidity from its balance sheet, acting as a bridge during the settlement period. It offers simplicity and deep initial liquidity but is constrained by a single entity's capacity and risk appetite. 2. **Asset-Specific Vault Model (e.g., Upshift Clear):** Independent liquidity providers fund dedicated vaults for each supported asset, earning fees. It decentralizes capital sources but isolates liquidity and capital per asset, leading to potential fragmentation. 3. **Shared Liquidity Layer Model (e.g., Symbiotic Liquid Lane):** A shared capital pool supports multiple RWA types simultaneously. Funds remain productive between redemptions (e.g., earning yield in lending markets). Exits are settled via a competitive RFQ market. This model aims for higher capital efficiency, scalability across assets, and serves longer-duration assets like private credit. Key differentiators are: 1) Source of capital and risk bearer, 2) Redemption pricing mechanism, 3) Capital efficiency, 4) Scalability to new asset types, and 5) Composability. The shared liquidity layer model represents a move from piecemeal solutions toward scalable infrastructure, enabling T+0 exits by pooling capital, maintaining yield, and using competitive pricing, thus enhancing RWA utility in DeFi.

marsbit8m ago

After Tokenization of Assets, How to Exit?

marsbit8m ago

After Tokenizing Assets, How to Exit?

After tokenization, a key unresolved issue is providing holders with a reliable exit mechanism, as underlying asset settlement (taking days to months) lags far behind on-chain token settlement. Three primary models for instant liquidity have emerged, differing in their capital structure and efficiency: 1. **Balance Sheet Model (e.g., Grove Basin):** A single, well-capitalized entity (like Sky) provides immediate liquidity from its own reserves. This offers simplicity and deep initial liquidity but is constrained by that single balance sheet's capacity and risk appetite, limiting scalability. 2. **Dedicated Vault Model (e.g., Upshift Clear):** Independent liquidity providers (LPs) fund separate vaults for each supported asset. This decentralizes capital sources but isolates liquidity and capital, which becomes inefficient as the number of tokenized assets grows. 3. **Shared Liquidity Layer Model (Symbiotic Liquid Lane):** Independent capital providers fund shared vaults that can support multiple tokenized assets simultaneously. Capital remains productive between redemptions (e.g., earning yield in DeFi markets). Exits are settled via a competitive RFQ market where market makers bid. The article argues that the shared layer model offers superior capital efficiency and scalability. It transforms exit liquidity from an asset-specific patch into shared market infrastructure, allowing liquidity capacity to grow with overall market participation rather than being fragmented per asset. This is particularly valuable for longer-duration assets like private credit, where reliable T+0 exits can significantly enhance their utility in DeFi.

链捕手21m ago

After Tokenizing Assets, How to Exit?

链捕手21m ago

Anthropic's Triple Moment: Code Leak, Government Confrontation, and Weaponization

This article analyzes Anthropic's recent conflicts and strategic moves following the U.S. government's emergency halt of its new Fable model, citing national security concerns over potential "jailbreaks." The author argues this incident reveals deeper tensions between AI labs, governments, and the software industry. While critics view Anthropic's safety-focused rhetoric as marketing fear, the author suggests it serves as a commercial moat masking the company's core economic imperative: moving closer to end-users and their valuable data to avoid being commoditized. The piece outlines a coming clash between frontier AI labs like Anthropic and established software companies. Labs need real-world usage data for model improvement via reinforcement learning, creating a cycle where better products attract more users and more data. This threatens software firms who, as Microsoft's Satya Nadella warns, risk having their value captured by a few dominant models. Anthropic's controversial policy changes—initially secretly degrading Fable's performance for LLM development and expanding data retention—are framed as assertions of control, justified by its safety narrative. The company's foundational belief that it alone is sufficiently concerned about superintelligent AI dangers legitimizes its actions, from resisting government demands to shaping usage policies. The author concludes that this alignment of mission, talent, and business strategy is powerful but concerning, as it concentrates immense potential power in the hands of those convinced of their own righteous understanding.

marsbit31m ago

Anthropic's Triple Moment: Code Leak, Government Confrontation, and Weaponization

marsbit31m ago

Xpeng and NIO Compete on Computing Power, Li Auto Shifts Architecture

On June 15, 2026, Li Auto unveiled details of its self-developed chip, Mahe M100, for its new L9 Livis model. CTO Xie Yan stated the goal was not just a faster chip, but a fundamentally different one, targeting the chip architecture itself. While competitors like NIO, Xpeng, and Huawei highlight TOPS (computing power) figures for their self-developed chips, Li Auto’s Mahe M100 focuses on redesigning the underlying architecture. It employs a "dynamic data flow architecture" to address memory bandwidth bottlenecks in large model inference, claiming up to 3x the effective computing power of Nvidia's Thor U for its specific workloads and a 40% reduction in latency. The chip's design was peer-reviewed and accepted at ISCA 2026. However, this performance is highly optimized for Li Auto's own VLA2.1 algorithm, meaning it may not generalize as well to other tasks. Li Auto aims to achieve full-stack in-house development with Mahe M100, covering chip, compiler, OS, AI algorithms, and domain controller—a level of vertical integration few competitors match. Beyond the chip, CEO Li Xiang introduced a new strategic narrative: the "embodied intelligent vehicle," defined as an integration of an EV, a professional driver, an AI computer, and a life assistant. This shifts competition from features like large screens to systemic AI capabilities. A key commitment was that Li Auto's Mahe VLA autonomous driving model will match Tesla's FSD V14 by Q4 2026, with specific OTA milestones set for July, September, and December. Financially, Li Auto faces pressure with declining revenue and vehicle gross margins since Q4 2025, while maintaining high R&D investment (approx. ¥12B in 2026, 50% AI-related). Its 2026 sales target is 550,000 vehicles, up from 406,000 in 2025. The new L9 Livis garnered over 10,000 pre-orders in two weeks. The effectiveness of these strategic moves—new products, OTAs, and the novel chip architecture—will begin to show in Q3 2026 financial results, with the year-end FSD V14 benchmark being the ultimate test.

marsbit1h ago

Xpeng and NIO Compete on Computing Power, Li Auto Shifts Architecture

marsbit1h ago

Trading

Spot
Futures

Hot Articles

Discussions

Welcome to the HTX Community. Here, you can stay informed about the latest platform developments and gain access to professional market insights. Users' opinions on the price of S (S) are presented below.

活动图片