The Underestimated Claude Code: A Critical Piece of the AI-Native Software Development Puzzle

🚥

Editor's note: Yesterday Anthropic released Claude 3.7, sparking heated discussion across the internet. I tried Claude 3.7 in Cursor right away and got that "electricity is flowing" feeling.

If 3.5 was still just patching code on top of existing foundations (like a mid-level engineer), then 3.7 can already handle a certain degree of system architecture design — evolving into an architect. That's a qualitative leap.

In today's piece, Yan Wang shares his take on Claude Code, which Anthropic launched alongside Claude 3.7.

🚥

Author Yan Wang: Olympic torchbearer, private pilot, coffee roaster, Ivy League PhD. Personal website: Computing Life[1]

Anthropic released Claude 3.7 yesterday, drawing widespread media attention. But most people seem to have overlooked another tool launched simultaneously — Claude Code. This command-line tool looks unremarkable, its interface isn't particularly user-friendly, and it doesn't make bold claims about self-evolution or replacing human programmers like Cursor or Devin.

But as I dug deeper, I realized that Claude Code — this seemingly ordinary tool — may be precisely the key to driving the AI Native software development revolution, and could even profoundly influence future business models and ecosystems.

From Traditional Models to AI-Friendly Development

In our efforts to introduce and promote Agentic AI, we often receive feedback about AI coding tools like Cursor: these tools work well for quickly prototyping, writing auxiliary scripts, or handling ad-hoc data analysis tasks.

But as soon as large projects or mature existing codebases enter the picture, AI frequently gets stuck — it often can't find the most relevant files and function interfaces, doesn't understand relevant development standards and best practices, let alone comprehend the high-level decision-making behind each design or the historical baggage that comes with it.

This is actually a critical problem. Many enterprises have hundreds of thousands or even millions of lines of internal core code. Just listing dependencies, structure, and documentation is headache-inducing enough, never mind expecting AI to learn it all in one go. So AI shines in small projects but can't touch the most mission-critical systems.

If we can't solve the problem of interfacing with existing codebases, AI development will remain stuck at auxiliary development or prototype building, unable to truly serve large-scale, serious, and most commercially valuable projects.

And if we can solve the problem of enabling AI to correctly and efficiently use existing codebases, the entire field below could advance by leaps and bounds.

We could see AI-led software development rapidly land across domains.

So to some extent, AI development is facing a chasm: on one side, the beautiful vision of AI autonomously developing software; on the other, the reality that AI still can't leverage most private codebases.

But to be fair, this isn't really AI's own fault. As we've discussed multiple times[2], for AI to effectively complete any task (not just programming), the prerequisite is that it has sufficient background knowledge.

It's like hiring a new intern. Throwing them into a codebase of hundreds of files and expecting them to immediately write correct, efficient code is asking too much. A better approach is to give them onboarding training so they understand the library's functions, structure, design, and even history. After such training, the intern's success rate at writing high-quality code improves dramatically.

For AI, the concrete form of this onboarding training is often giving it a ready-made prompt file.

For example, the Model Context Protocol (MCP) project provides such a prompt file at this URL[3]. If you throw this prompt file at an AI (like ChatGPT or Cursor), it will have enough background knowledge to write correct code. Currently, building this prompt file is still often a semi-automated or even manual process.

For instance, we can take all the docstrings from a library and feed them to ChatGPT, asking it to filter out the most important functions and write a Markdown document to serve as the AI's prompt. With this kind of documentation support, AI can easily write correct programs for small-to-medium scale projects.

So up to this point, we've already seen two different software development models:

1. One traditional model where the deliverable of software development is the code itself, plus at most documentation for humans.
2. But another new approach is AI-friendly software development. It emphasizes that software development deliverables are not just for humans, but also for AI. So beyond the code itself and human-facing documentation, there is often also an AI-facing prompt file. The benefit is that AI can quickly get up to speed and use this library to directly write correct programs.

As tools like Cursor gradually gain popularity, the importance of whether software development is AI-friendly is also growing.

For example, you're a tech lead at a company choosing between two libraries. One library you can pick up and start writing programs with Cursor immediately; the other requires all kinds of learning and processing before you can write code bit by bit with AI assistance.

The competitive advantage of the former in the market is self-evident.

21st.dev, Library as a Service, and AI Native Development

The AI-friendly software development model, while making considerable progress compared to traditional software development, still has quite a distance to go before triggering a revolution across the entire software development field.

To understand this, let's first look at 21st.dev[4].

The 21st.dev website — or software library — is quite interesting. It's essentially a UI library providing many frontend components. But unlike traditional software library usage, it doesn't deliver all components to users for them to learn and write code with. Instead, it works the other way around: users tell it what they want to build, and it chooses which UI components to call to build a frontend for the user.

In other words, its deliverable isn't a class library, but the code the user needs itself — code that includes relevant classes, which users can modify themselves after receiving it.

This is actually a new way of using libraries: Library as a Service (LaaS).

The deliverable of a software library isn't code, isn't documentation, but directly becomes a service, an API. For user/developer experience, this is a major change. Because even in AI-friendly mode, in actual development, this prompt file still requires developers to write and maintain themselves, placing many demands on teams in terms of documentation management, version control, and prompt writing.

Therefore, even the AI-friendly development model often only makes incremental improvements within the existing write-code — package — deploy pipeline, without disruptively changing the delivery model. LaaS is different. Starting from the logic of "what I deliver is an API + the AI execution power behind it," it bundles commercial and technical delivery together, fundamentally changing how to charge, how to demo externally, and how to iterate and upgrade. If traditional software libraries delivered building materials, LaaS delivers a turnkey construction crew — reconstructing the software development value chain.

Beyond the user experience upgrade, LaaS also offers significant benefits to enterprises providing libraries.

On one hand, this gives enterprises greater control and autonomy — externally encouraging users to apply best practices when using the library, internally enabling more comprehensive and efficient optimization.

On the other hand, from a revenue perspective, this value-added service can generate excess profit, transforming what was traditionally a one-time-delivered software library into a goose that keeps laying golden eggs.

For the entire software development field, the LaaS approach brings enormous room for imagination. If in the future our software libraries are all delivered via LaaS, the process of AI using these libraries to further build software becomes particularly simple and smooth. AI would more play the role of a planner — coordinating and planning, simply deciding which library's domain expertise fits which problem.

Then, the actual writing of code using these libraries can be completely handled through each library's services, completed via API calls. In a sense, this could also be called Library as an Agent. This transforms a complex software development process using multiple software libraries into a multi-agent collaboration and iteration problem.

This solves the problem we raised at the beginning of the previous chapter. With LaaS, by completely delegating library learning and usage to agents built by library authors, Agentic AI is no longer just a toy for solving ad-hoc problems, but can flexibly and efficiently adapt to existing enterprise-grade software libraries.

Compared to traditional methods, and even AI-friendly methods, this development approach is more AI native. Although Agentic AI is still very new, and we currently can hardly predict what form software development will ultimately converge to.

But we can be fairly certain that what everyone eventually adopts will be an AI-native approach — a technical framework where all technical means are designed around AI, serving as AI enablers to maximize AI's work efficiency.

Claude Code and the Future AI Development Ecosystem

The LaaS vision is beautiful, but its implementation threshold remains high.

For example, how to introduce Agentic Workflow into the code generation process to achieve self-iteration and self-correction, thereby ensuring generated code quality. This requires considerable practical experience and deep understanding of LLMs. We only need to look at the performance gap between open-source Cline and Cursor to easily understand this.

But Claude Code's emergence fills this gap perfectly, greatly lowering the implementation difficulty of LaaS.

Specifically, Claude Code's functionality is like a command-line version of Cursor. You describe the programming task to implement in natural language within command-line parameters, and it calls several accompanying tools — including running commands, modifying files, etc. — to use Agentic Workflow for self-iteration and self-correction.

Therefore, many application scenarios that were previously difficult to solve because Cursor doesn't provide an API can now be easily realized through Claude Code.

So although it has no GUI and doesn't seem particularly attractive to end users, Claude Code as a foundational building block provides us with solid ground for constructing many similar applications.

Meanwhile, under the guidance of the LaaS vision, its value isn't in letting us quickly clone a Cursor, but in having the potential to push the entire software development field toward LaaS or similar AI-native development paradigms. This fills in an important missing piece for fundamentally transforming the entire AI development model.

Beyond this, Claude Code has another function: it can use Agentic methods to call various tools to read code under a folder, step by step building out a prompt file.

Its Agentic characteristics allow it to actively explore codebases, and through dynamic analysis of execution processes, continuously refine and correct its understanding of projects.

It's like a human intern who, after receiving initial instructions, will go read and analyze relevant modules on their own, using a combination of natural language description and tool calls to confirm which parts of code are suitable for reuse and which need rewriting.

Once we complete such a migration process in existing systems, it's equivalent to truly breaking through the barrier between AI and traditional codebases for AI.

When subsequently developing new features or refactoring old logic, AI doesn't need to go through the same lengthy learning process again, but can directly take over this automated workflow and iteratively update results.

Therefore, in summary, Claude Code's goal is to transform traditional software library usage toward AI-friendly and AI-native directions, by providing appropriate tools to make both transitions smoother and painless.

The vision and ambition behind it are actually far greater than the surface value of this simple command-line tool.

The embryonic form of a world where one AI coordinates all services, automatically codes, and automatically schedules — perhaps it has already quietly appeared in Claude Code.

This vision still has quite a road to travel before truly landing, including standardization of API specifications, security policy controls, and discussions about boundaries and responsibility allocation for Agentic AI in different scenarios. But from the step Claude Code has taken, Anthropic is already very pragmatically solving an industry-wide pain point: how to enable AI to more intelligently interface with legacy systems, and how to gradually transform legacy systems into new LaaS forms, thereby heading toward an AI-native future.

This may be precisely Anthropic's most forward-looking move, yet it was overlooked by many because it wasn't as dazzling as Claude 3.7.

But I believe that when people look back in the future, they will find that Claude Code played an irreplaceable starting-point role in this AI-native software revolution.

---

This article was first published on the author's personal website Computing Life[5]

References

[1] Computing Life: https://yage.ai/

[2] Discussed multiple times: https://yage.ai/prompt-engineering-guide.html

[3] This URL: https://modelcontextprotocol.io/llms-full.txt

[4] 21st.dev: https://21st.dev/

[5] This article was first published on the author's personal website Computing Life: https://yage.ai/