AI Coding Is a Framework, Not a Library

The more I use AI coding tools, the more strongly I feel that AI coding is a kind of "framework."

Frameworks are an old friend to every programmer. They are usually designed for a specific domain and can dramatically boost coding efficiency. Take REST API services: a mature framework such as Django REST Framework lets you define a data model and a view class, and you get a fully functional CRUD API service out of it.

AI coding tools, like traditional frameworks, are a kind of "lever": they let people move enormous functionality with a tiny input. The only difference is the type of input. A framework needs code (or configuration); AI needs nothing more than a plain-language prompt — "build me a bookstore website."

As a new kind of framework, AI coding is so convenient that it wipes the floor with every framework humans have ever invented. But the problems frameworks are born with have not gone away.

1. Leaky abstractions

All frameworks share one trait: they offer very high-level abstractions to cut down the work needed for a specific feature. Django's ORM, for instance, gives you the "data model" abstraction, sparing you from writing SQL by hand or designing data validation.

Unfortunately, all abstractions leak.

A Django beginner ships a site and the customer complaints explode: the list page loads painfully slowly. Open the database monitoring dashboard and you'll find that this seemingly simple page fires 400 database queries on every visit. To fix it, he has to get his hands dirty, tear open the ORM abstraction, understand how attributes get loaded, and grasp the truth about the "N+1 problem."

With AI coding tools, the leak shows up at the moment we have to abandon the easy natural-language prompt — "implement feature XXX" — and instead say, "your understanding of the state transitions of the items variable is wrong."

Needless to say, today's AI still has an intelligence ceiling. When natural language can't drive the AI to do the job accurately, breaking the abstraction, opening that dusty IDE, and writing prompts precise down to variable names to help the AI find the root cause is our only option.

2. Losing control

All patterns for reusing code fall into roughly two kinds: framework and library.

Whether something is a framework or a library comes down to one question: who controls the overall structure of the program?

With a framework, control sits firmly in the framework's hands. The program you write is a piece fitted into the grand framework program. It's a bit like finishing a cartoon drawing: every element is already outlined in light gray, and you just fill different areas with different colors.

With a library, control stays with you. You choose and coordinate different libraries to build the whole program. It's like playing with bricks: you have thousands of bricks and modules at hand, and you assemble them into whatever shape you want.

What harm does losing control do? Mostly, it hurts modifiability.

With a framework, when the program needs a custom feature, the lack of control means the work depends on whether the framework supports that customization. If it does, the whole thing goes like a hot knife through butter. If it doesn't, then unfortunately you may burn tons of time on a simple requirement.

To be fair, on the "control" axis, AI coding isn't inherently a framework or a library. But there's no denying that the most popular trend right now is to use it as a framework. In vibe coding, for example, the human only supplies vague natural-language prompts and doesn't care at all about the program's entry points, exit points, or overall structure — the AI agent, acting as the framework, controls everything.

Cognitive cost: what DRF teaches us

Why do people tend to treat AI as a framework? That's an interesting question.

I think the key is one phrase: cognitive cost. The traits frameworks are born with hint at something: you can build the most complex features at the lowest cognitive cost. And humans are born to take the easy path — doing more with less thinking is a goal we chase by nature.

Take DRF (Django REST Framework). In DRF, implementing a set of CRUD APIs for one kind of data model takes just these four lines:

class AccountViewSet(viewsets.ModelViewSet):
    queryset = Account.objects.all()
    serializer_class = AccountSerializer
    permission_classes = [IsAccountAdminOrReadOnly]

One class, three attributes, minimal cognitive cost, a full set of RESTful APIs — by any measure, that's a very good deal.

But as noted earlier, a framework's convenience is a double-edged sword, and the "leaky abstraction" and "loss of control" that come with frameworks are unavoidable.

Suppose we now need to change the API so that create returns a different response body and list gets extra filter conditions. How would you do that on top of the code above? The answer: rewrite several methods, including get_queryset, then patch the entire ModelViewSet into an unrecognizable mess with a pile of if/else.

Is there a better way? Certainly. We can drop the high-level ModelViewSet entirely and use a plain ViewSet with no magic at all, composing modules to achieve exactly the same thing.

class AccountViewSet(viewsets.ViewSet):
    permission_classes = [IsAccountAdminOrReadOnly]

    def list(self, request):
        # custom filtering logic for list
        qs = Accounts.objects.filter(...)
        serializer = AccountSerializer(qs, many=True)
        return Response(serializer.data)

    def create(self, request):
        # custom response structure for create
        serializer = AccountForCreationSerializer(obj)
        return Response(AccountForCreationSerializer(obj).data)

By comparison, the most obvious change is that there is more code, and wordier code at that. But the bigger change happens at the level of "cognitive cost."

In the ModelViewSet version, cognitive cost looks low on the surface, but much of it is hidden — it exists as hidden cognitive debt. Later, when requirements change, that debt makes implementing features enormously painful. After restructuring the code, the hidden debt surfaces, and the code's visibility and maintainability improve markedly.

If we look at the example above through the "framework vs library" lens, the new code is organized more like a library — a person owns the program and organizes the whole feature — rather than a framework, where a person is merely a servant filling in the blanks of ModelViewSet.

So we can see that framework and library aren't a strict binary classification of things; they're more like two different ways of thinking. Even inside a huge framework like DRF, there are all sorts of code organization patterns — some lean framework, others clearly lean library.

Maybe it's time to treat AI coding as a library

Back to AI coding. Treating AI coding as a framework pushes us into framework thinking: always chasing shorter prompts, caring less about the code, spending less cognitive cost to reach the goal.

But as the earlier example shows, under that mindset cognitive debt keeps piling up, and the framework's built-in problems — leaky abstraction and loss of control — will hurt us badly down the road.

So why not shift your thinking and treat AI coding as a "library"? Just as with any other library, we own the program and call on it to get work done.

That shift in mindset might mean:

• Stop chasing "write less, do more": fewer prompts (code) for more features looks lovely, but it also means a pile of cognitive debt accumulating;
• Find the "sweet spot" for writing prompts, paying relatively little — not the absolute minimum — cognitive cost;

• Focus on program structure: more than in the pre-AI era, you now need to care about the program's overall structure, acting as chief architect to design the whole thing and internalizing the right structure and constraints into AGENTS.md;

• More precise prompts: based on an understanding of the existing program, write more precise prompts to steer the AI, instead of letting it loose and letting AI run everything;

• Review the code: even with the same framework, when a thorny problem hits, someone who has read the docs thoroughly is more effective than a greenhorn. If AI-written code counts as a framework, then you should review that code, so that when the inevitable "leaky abstraction" strikes, the damage stays as small as possible.

There's no doubt that AI coding is a revolutionary advance. It lets us write programs from a vantage point that previously existed only in the imagination. But AI coding is not magic: like any framework in history, behind its extreme convenience lurk multiple risks — leaky abstractions, loss of control, cognitive debt.

So AI coding is still no silver bullet; it can't truly free us from cognitive cost. But until the real silver bullet arrives, recognizing the limits of AI coding as a new kind of "framework" — and steering it with the mental model of a "library" — may be our best option.