AI Coding Is a "Framework"

The more I use AI coding tools, the more convinced I become: AI coding is a kind of "framework."

Frameworks are an old friend to every programmer. They are usually built for a specific domain and can dramatically improve coding efficiency. Take REST API services as an example: some mature frameworks, such as Django REST Framework, can generate a full CRUD API service as soon as you define the data models and view classes.

AI coding tools are like traditional frameworks in that they are both forms of leverage: with very little input, they let people produce substantial functionality. The difference is only in the input type. A framework needs code or configuration, while AI may need only a simple natural-language prompt: "Build a bookstore website."

The Problem with Frameworks

As a new kind of framework, AI coding is so convenient that it can run circles around almost any framework humans have invented before. But the built-in problems of frameworks have not disappeared.

1. Leaky Abstractions

All frameworks share one trait: they provide high-level abstractions that reduce the work needed to implement a feature. For example, Django's ORM provides the abstraction of a "data model," which saves you from writing raw SQL and building validation logic by hand.

But unfortunately, all abstractions leak.

Imagine a Django beginner launches a website and immediately gets flooded with complaints because the list page is painfully slow. Once they open the database monitoring panel, they discover that every request to this seemingly simple page triggers 400 database queries. To fix the problem, they have to get their hands dirty, tear through the ORM abstraction, understand how attributes are loaded, and uncover the truth behind the N+1 problem.

With AI coding tools, "abstraction leakage" shows up the moment we have to give up the easy natural-language prompt, "Implement feature XXX," and instead say something like, "Your understanding of the state transition for the items variable is wrong."

There is no point pretending otherwise: today's AI still has real intelligence limits. When natural language alone cannot reliably drive the AI to finish the job, we have to break the abstraction, reopen the dust-covered IDE, and use prompts precise enough to name specific variables so the AI can find the root cause.

2. Loss of Control

Nearly every pattern for code reuse can be roughly divided into two categories: frameworks and libraries.

To tell whether something is a framework or a library, the key question is: Who controls the overall structure of the program? When you use a framework, control sits firmly with the framework. The program you write is only one part embedded inside the larger program defined by the framework. It is a bit like filling in a coloring book: every shape is already outlined in light gray, and your job is only to color different areas.

When you use a library, control stays with you. You decide how to combine different libraries to build the whole program. That is more like playing with building blocks: you have countless pieces and modules at hand, and you assemble them into the shape you want.

What harm does losing control cause? The main issue is changeability.

When you use a framework and need to customize a feature, the work depends on whether the framework supports that kind of customization. If it does, the experience is smooth as butter. If it does not, then unfortunately, you may spend a huge amount of time on a very simple requirement.

To be fair, on the dimension of "control," AI coding is not inherently either a framework or a library. But one thing is clear: the most popular current trend is to use it like a framework. In vibe coding, for example, humans provide only vague natural-language prompts and pay little attention to program boundaries or overall structure. Everything is then controlled by the AI agent as the framework.

Cognitive Cost: What DRF Teaches Us

Why are people inclined to treat AI as a framework? It is an interesting question.

I think the answer turns on one phrase: cognitive cost. A framework naturally suggests this promise: you can achieve the most complex functionality with the lowest possible cognitive cost. Humans are wired to conserve effort. Doing more while thinking less has always been one of our instinctive goals.

Take DRF (Django REST Framework) as an example. In DRF, implementing a full CRUD API for a model takes only these four lines of code:

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

One class. Three attributes. Extremely low cognitive cost. A complete RESTful API. By any measure, that looks like a very good deal.

But as mentioned earlier, the convenience of frameworks is a double-edged sword. The problems that come with them, such as leaky abstractions and loss of control, are unavoidable.

Now suppose we need to change the API so that create returns a different response body, and list applies extra filtering conditions. How do we do that with the code above? The answer is: first override multiple methods, including get_queryset, and then patch the whole ModelViewSet with a pile of if/else statements until it barely resembles what it was before.

Is there a better way? Yes. We can drop the high-level ModelViewSet, use the plain ViewSet without any magic, and build the same functionality through explicit composition.

class AccountViewSet(viewsets.ViewSet):
    permission_classes = [IsAccountAdminOrReadOnly]
    def list(self, request):
        # Special filtering logic for list
        qs = Accounts.objects.filter(...)
        serializer = AccountSerializer(qs, many=True)
        return Response(serializer.data)
    def create(self, request):
        # Special response structure for create
        serializer = AccountForCreationSerializer(obj)
        return Response(AccountForCreationSerializer(obj).data)

Compared with the original, the most obvious change is that the new version has more code and looks more verbose. But the larger change is actually in cognitive cost.

In the ModelViewSet version, the cognitive cost appears low on the surface, but much of the cost is merely hidden. It survives as concealed cognitive debt. Later, when requirements change, that debt makes implementation painful. Once we adjust the structure, the hidden debt rises to the surface, and the code becomes more visible and easier to maintain.

If we look at this example through the lens of "framework versus library," the new structure is closer to a library. The human, as the owner of the program, organizes the functionality. It is no longer a framework model in which the human acts merely as a servant filling gaps in ModelViewSet.

At this point, we can see that frameworks and libraries are not a strict binary classification of things. They are more like two different ways of thinking. Even inside a large framework like DRF, different styles of code organization exist: some lean toward the framework mindset, while others clearly lean toward the library mindset.

Maybe We Should Treat AI Coding as a Library

Back to AI coding. Treating AI coding as a framework pushes us toward a framework-style mindset: we keep trying to write shorter prompts, pay less attention to the code, and reduce cognitive cost as much as possible.

But as the earlier examples show, that mindset keeps piling up cognitive debt. And the built-in problems of frameworks, leaky abstractions and loss of control, will eventually hurt us in serious ways.

If that is true, why not change the mindset and treat AI coding as a library instead? Just like any other library, we should use it as the owners of the program, calling on it to help us get work done.

That shift in mindset may mean:

• Stop chasing "less input, more output." Using fewer prompts or less code to produce more functionality sounds attractive, but it also means a large amount of cognitive debt accumulates along the way. Find the "sweet spot" for prompting, aiming for relatively low cognitive cost rather than the absolute minimum.
• Pay attention to program structure. Compared with the pre-AI era, you may now need to care even more about the overall structure of the program, act as the chief architect, and encode the right structure and constraints in AGENTS.md.
• Use more precise prompts. Based on an understanding of the existing program, write more precise prompts to guide the AI, instead of letting it improvise and dominate the process.
• Review the code. Even when using the same framework, the person who knows the documentation well will handle tough problems more efficiently than the person who charges in blindly. If you treat AI-generated code as framework output, then you should review it carefully so that when abstraction leakage inevitably appears, the damage stays under control.

There is no question that AI coding is a revolutionary step forward. It lets us write software from a level of abstraction that once existed only in imagination. But AI coding is not magic. Like every framework before it, its extreme convenience hides multiple risks: leaky abstractions, loss of control, and cognitive debt.

So AI coding is still not a silver bullet. It cannot truly free us from cognitive cost. But until a real silver bullet arrives, the best choice may be to understand the limits of AI coding as a new kind of framework, and to use the mental model of a library to keep it under control.