The end of frameworks part 2: after coding, what remains?

AI frameworks, the end of coding, binary assets, Software 2.0, and the AI coding recipe all point to a post-human-framework transition.

If part 1 was about the history of human-centered frameworks, part 2 is about how AI may redefine what a framework is.

<AI coding recipe structure 1.1>

1. An unfamiliar framework raises the learning curve for AI

For a human developer, a framework is something to learn. It may be difficult at first, but with manuals, examples, and team habits, it becomes comfortable. For AI, a framework is different. A model does not understand a framework in the same way a person does. It reconstructs patterns from repeated code, documentation, open source projects, issues, and answers.

That difference matters. Technologies used around the world have higher probability mass. Python, JavaScript, SQL, REST, HTML, Docker, PostgreSQL, and React have abundant public examples. A private company framework, internal DSL, or undocumented component system is a much stranger language for the model.

Strong harnesses, tests, type systems, code review, and permission limits can block many mistakes. But that protection has a cost. The prompt must keep explaining internal rules. Context must carry exceptions. Every unfamiliar abstraction consumes tokens and creates another verification loop. A framework that improved human productivity can become a learning curve for AI.

Technology choice	Effect on human developers	Effect on AI
Widely known standard stack	Easier hiring and collaboration	More training examples, easier prediction
Internal framework	Fits internal work	More errors if context is missing
Excessive abstraction	Reduces repeated human work	Makes execution paths harder to infer
Strong test harness	Prevents human mistakes	Guards AI output
Private DSL	Expresses business concepts	Raises token cost when examples are scarce

Good design in the AI coding era may therefore look less like a beautiful new framework and more like a recipe the model can predict reliably. Boring, widely known combinations may outperform elegant abstractions. That is also an important lens for practical vibe coding and the broader Software 3.0 transition.

2. The most common technology combinations become AI recipes

GitHub Octoverse 2024 shows Python rising to the top of GitHub usage while Jupyter Notebooks and generative AI projects expanded. That is more than a popularity ranking. Public code is a map for AI. The more code, documentation, examples, and failure discussions exist, the easier the path is for a model.

Stack Overflow Developer Survey 2024 points in the same direction. Developers depend heavily on API and SDK documentation, and tools such as Docker, npm, and PostgreSQL remain widely used. If AI is going to code efficiently, it will likely prefer combinations that the world has already made common, documented, and testable.

The most mature languages and platforms humanity created may be reorganized into AI manuals. A web service recipe might look like TypeScript, React, Node, PostgreSQL, Docker, Playwright, OAuth, and REST or GraphQL. A data product recipe might look like Python, FastAPI, PostgreSQL, Pandas, PyTorch, Docker, OpenAPI, and CI tests. The core value is not novelty. It is probability.

An AI coding recipe is not about chasing the newest tool. It is about choosing combinations that models have seen often, that have many public examples, and that can be tested at clear boundaries.

In that light, the claim that new frameworks for humans may stop appearing becomes plausible. For human developers, a new framework can be a new productivity tool. For AI, a new framework is an under-learned probability space.

3. AI may learn executable assets, not its own human-style framework

If AI optimizes for efficiency, does it need to create its own React or Django? Humans need abstraction. We name things, create layers, write manuals, and memorize examples. AI can work differently. What it needs is not a structure that is pleasant for humans to read. It needs a representation that reliably produces desired behavior.

Andrej Karpathy’s Software 2.0 makes this point sharply. Karpathy describes classical software as Software 1.0, written directly by people in languages such as Python or C++. Software 2.0 is written in a much less human-friendly language, such as neural network weights. Dataset and architecture define a search space, and training acts like a compiler that produces the final network. This is the stage before what many now call Software 3.0.

<Software 2.0 and executable assets 1.2>

Push that frame further and future AI does not need a human-readable framework of its own. It may work directly with functioning binary assets, model weights, executable function bundles, validated service blocks, and evaluation harnesses. For humans, source code is an explanation. For AI, the working behavior itself can become the training target.

This does not mean coding disappears tomorrow. Today’s AI still writes code, compiles it, tests it, and runs it. But that pipeline may exist because of humans and the current computing stack. Learning coding, writing code, compiling, installing, and running may be a long chain built around human comprehension.

4. Code itself may be a human interface

Code feels natural to us because we grew up inside programming culture. But code is not a law of nature. It is a notation humans created to control machines. C, Java, Python, JavaScript, and SQL all exist so people can read, write, discuss, and modify instructions. The computer ultimately wants executable state change, not a pretty source file.

In his Y Combinator talk, Karpathy describes Software 3.0, natural language programming, and the LLM operating system. Natural language remains a human-friendly interface. But under that interface, execution may involve model calls, tools, memory, permissions, datasets, evaluators, and runtime environments, not only text code.

At some future point, coding itself may fade from the center. More precisely, the act of humans directly writing source code may move to the edge. If AI can create and verify reliable executable assets directly, source code becomes a less necessary intermediate form.

Current pipeline	Why humans needed it	Possible AI-era replacement
Translate requirements into code	Humans needed to instruct machines	Natural language, examples, simulations, policies
Coding	Humans specified execution rules	Models create executable assets directly
Compilation	Human code became machine format	Training or synthesis produces executable behavior
Install and runtime	Humans prepared environments	Standard in-memory execution environments
Debugging	Humans found logical errors	Evaluators and repair loops handle more of it

The end of coding is not a romantic prediction. It is a cold technical possibility. If source code is a human-friendly intermediate representation, domains with fewer humans may keep less of that representation.

5. AI frameworks bloom only when bugs approach zero

This does not mean every program disappears soon. We are still at the very beginning of AI frameworks. Current AI development tools remain human-centered. A person writes prompts, reads code, checks tests, approves deployment, and accepts responsibility. Today’s AI frameworks are collaboration harnesses, not full replacements.

A true AI-native framework needs one more condition: the bug rate of AI-generated programming assets must approach zero. If the artifacts used for learning contain many bugs, then the AI’s executable assets can inherit that pollution. A small logical error can be compressed, regenerated, and redeployed quietly.

Brooks’ essential complexity returns here. Less code does not remove the difficulty of payments, healthcare, law, security, accounting, permissions, responsibility, or exceptions. Future AI frameworks may deal with those complexities through evaluations, simulations, safety constraints, policies, datasets, and executable assets instead of human-readable code.

A post-code world cannot arrive safely while generated assets remain noisy. If AI learns from buggy artifacts, it may produce faster, but it may also spread errors faster.

6. What disappears may not be programming, but the program itself

Marc Andreessen’s old phrase “software is eating the world” described how software absorbed industry after industry. The next question is whether AI eats the form of software itself.

Coding, bugs, and analog logical mistakes may be the germs of a digital world built by humans. Humans translate intentions into code, compile code, install it, run it, and then fix the bugs that appear. That detour was powerful for decades, but it is not necessarily eternal.

One distant day, programming may not be the thing that disappears. The program itself may disappear. Users may not install apps. Organizations may not choose frameworks. Developers may not design folder structures. Instead, the needed executable asset may appear in memory, be verified, be used, and vanish.

That future framework will not be a manual humans read. It will define what assets a model may generate, what constraints must hold, what evaluations must pass, and what execution boundaries cannot be crossed. The end of human-centered frameworks is therefore the beginning of AI frameworks.

The conclusion is not that developers vanish tomorrow. It is that the central question changes. Instead of asking whether a framework makes coding easier for humans, we will ask whether it lets AI create executable assets with a lower error rate.

Era	Core question	Representative tools	Durable value
Human development	How can people build faster?	Frameworks, manuals, components	Productivity, collaboration, reuse
AI-assisted development	How can people use AI safely?	Prompts, tests, harnesses, agents	Verification, control, responsibility
AI executable asset era	How can AI create working assets directly?	Models, evaluations, policies, in-memory assets	Error rate, reliability, immediacy

The end of frameworks is not the end of tools. It is the end of an era in which tools primarily helped humans write code more easily. What comes next may not be an easier framework, but software assets people no longer need to read.

The end of frameworks part 1: tools built for humans

For search readers, this essay treats human centered frameworks, development frameworks, software engineering, and the AI coding era as one connected transition.

Development frameworks have always looked like tools for computers. In practice, they were mostly tools for people. The real question is whether that kind of human centered framework still needs to keep appearing in the same way.

<The Mythical Man-Month information card 1.1>

1. Frameworks reduced the memory burden of human developers

When developers talk about frameworks, productivity is usually the first word that appears. React, Django, Rails, Spring, Laravel, and Next.js all look like ways to build faster. But under the surface, the central function of a framework is not speed alone. A framework externalizes memory. It stores repeated decisions so that a person does not have to make the same structural choices again on every project.

Standard folder structures, routing rules, ORM conventions, authentication modules, build presets, deployment patterns, boilerplates, official manuals, and reusable components all reduce cognitive load. A developer does not have to ask where every file should live, how state should flow, how the database should be connected, or how the build should be wired. The framework creates rails so humans make fewer mistakes and teams speak the same language.

That is why the end of frameworks does not simply mean that tools disappear. It means the reason for creating new human centered frameworks may weaken. If fewer humans read, memorize, edit, and coordinate code directly, then rules designed primarily for human comfort become less central.

Framework element	What it did for humans	Why it mattered
Standard folders	Reduced placement decisions	Teammates could find code quickly
Presets and boilerplates	Reused repeated setup	Fewer early configuration mistakes
Components and libraries	Avoided repeated implementation	Humans did not rebuild everything
Official manuals	Provided a learning path	People needed a shared reference
Community patterns	Stored repeated experience	Teams avoided the same failures

A good framework was therefore a social contract as much as an execution tool. The computer did not care whether a project used Rails, Django, or Next.js. People cared, because people needed conventions they could remember, teach, review, and discuss.

2. Brooks explains why frameworks became necessary

Fred Brooks’ The Mythical Man-Month remains important because it explains why large software projects are not solved by simply adding people. In No Silver Bullet, Brooks separates software difficulty into essential complexity and accidental complexity.

Essential complexity comes from the problem itself. A payment system has money, permissions, refunds, settlement, fraud, security, and exceptions. A hospital system has patients, prescriptions, records, responsibility, and regulation. Better tools do not remove that core difficulty. Accidental complexity comes from awkward languages, painful builds, slow compilation, repetitive setup, poor documentation, and communication overhead.

Frameworks grew because they attacked accidental complexity. They helped developers spend less energy on routing, database plumbing, rendering rules, or integration boilerplate, and more energy on the actual business problem.

From Brooks’ perspective, a framework is not a silver bullet. It is more like a cleaning tool for accidental complexity. It does not remove the essence of software, but it lets humans stay closer to the essence for longer.

This makes frameworks extremely valuable in the human era. Standardization reduced memory. Manuals reduced learning friction. Components reduced repetition. Presets reduced avoidable mistakes. Frameworks mattered because humans were limited by memory, attention, and coordination.

3. Design Patterns was a shared human vocabulary

The same idea appears in Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. The book described 23 classic object-oriented design patterns, but its deepest value was not just code examples. It gave developers names for recurring structures.

<Design Patterns information card 1.2>

Names like Singleton, Factory, Observer, and Adapter became powerful because they compressed long design discussions into short phrases. “Use an Observer here” or “extract an Adapter” saved many sentences. That compression was for humans. It helped people review, explain, and coordinate software.

Framework conventions work the same way. Next.js App Router, Rails convention over configuration, Spring dependency injection, and Django batteries included are not just technical features. They are a human vocabulary for understanding a system quickly.

Human collaboration problem	What patterns and frameworks offered	What may change with AI
Design intent is hard to explain	A named pattern compresses intent	AI may use statistical similarity more than names
New teammates must learn quickly	Manuals and conventions guide them	If fewer people read code, manuals lose weight
Repeated design is tiring	Components and abstractions reduce repetition	AI can regenerate routine code cheaply
Code review needs standards	Framework norms create review criteria	Tests and harnesses may become stronger criteria

Human centered frameworks were therefore technologies for saving memory and agreement. They existed because people needed them. Machines ultimately execute state transitions, not manuals.

4. Popular technologies become easier terrain for AI

This does not mean every framework immediately becomes meaningless in the AI coding era. Today’s models still work on the code, documentation, open source projects, questions, answers, examples, and manuals humans have left behind. Widely used languages and frameworks are therefore easier terrain for AI.

GitHub Octoverse 2024 reports that Python became the most used language on GitHub and that generative AI and data science activity surged. Stack Overflow Developer Survey 2024 shows how strongly developers rely on API and SDK documentation, and how broadly tools such as Docker, npm, and PostgreSQL are used. The pattern is clear: the human development ecosystem becomes the map that AI has learned most deeply.

Here is the paradox. Human centered frameworks may stop being the main place of innovation, but the frameworks humans used most will become the safest recipes for AI. React, Python, PostgreSQL, Docker, REST, OAuth, HTML, and SQL are predictable because examples are everywhere. By contrast, internal DSLs, private company frameworks, and undocumented abstractions are unfamiliar territory for a model. This connects directly to the broader discussion around Software 3.0 and the AI coding era.

The key risk in the AI coding era is not simply whether a framework is used. The risk is whether the model has learned the terrain well enough. A tool familiar to humans is not always a tool familiar to the model.

Part 1 ends here. Development frameworks were built for people: standardization, presets, easy components, manuals, and design patterns all served human productivity and collaboration. As the human share of development shrinks, the need for new frameworks designed mainly for human comfort may shrink too.

Continued in part 2. The next part looks at AI recipes, executable assets after code, and the possibility of AI-native frameworks.