1. When code stops being mandatory

Traditional programming can be represented as a sequence of transformations:

Human
  ↓
Algorithm
  ↓
Source code
  ↓
Compiler
  ↓
Machine code
  ↓
Execution

The compiler optimizes a program already formulated by a human. Source code here is an intermediate language between human intent and the machine.

In Intent-Based Computing, this premise ceases to be the only one. Instead of a sequence of instructions, the system receives a set of conditions:

Intent
+ Data
+ Constraints
+ Available capabilities
+ Policies
+ Verification criteria
              ↓
   Semantic representation
              ↓
     Computation graph
              ↓
         Execution

A human communicates what result needs to be achieved. The system itself determines which computation will produce that result.

This is a fundamental shift. In classical programming, a human chooses the algorithm, data structures, and order of operations, and the compiler translates them to a lower level. In the new model, a human can define the space of acceptable solutions, and the system searches within it for a concrete implementation.

So the programming language does not disappear. It rises to a higher level of abstraction.

Instead of:

do A
then B
if C — run D

a description appears:

get X
under conditions Y
with constraints Z
and reach quality Q

This does not mean that source code will cease to exist. It will remain critically important for operating system kernels, drivers, cryptography, compilers, infrastructure, and critical algorithms — everywhere audit and strict reproducibility are required. But for a huge class of applied tasks, code gradually stops being the mandatory human interface to computation.

2. From library to capability: what happens to GitHub

GitHub, package managers, and the entire library ecosystem rest on one fundamental assumption:

Someone has to write a software component in advance, save it, and let others use it.

A typical chain looks like this:

Human
 ↓
Repository
 ↓
README
 ↓
Documentation
 ↓
Library
 ↓
Integration
 ↓
Application

An agentic system can shorten it radically:

Human
 ↓
Intent
 ↓
Capability Discovery
 ↓
Generated graph
 ↓
Verification
 ↓
Execution

A human no longer has to search for a library, read a README, choose a package, write glue code, and assemble an application. What they need is a capability — a verified ability to perform a certain class of operations.

For example:

Capability:
    normalize_document

Input:
    structured document

Output:
    normalized document

Constraints:
    preserve semantics
    preserve tables

Permissions:
    document read

Verification:
    structural equivalence

Such an object is much closer to the potential machine language of the future than a traditional library. Moreover, a capability is not necessarily code. It can include a specialized model, an algorithmic primitive, a retrieval loop, a tool, an adapter, a set of rules, a proven workflow, or a combination of several computational components.

In the limit, the description of computation looks like this:

Intent
Knowledge
Data
Models
Capabilities
Constraints
Policies
Verification

And the system itself determines which representation of this set will be most effective for a particular task. This is no longer classical programming. This is semantic assembly of computation.

Does this mean GitHub will disappear?

Not necessarily.

GitHub may remain an archive, a collaborative development environment, a source of reference implementations, benchmarks, documentation, provenance, and verifiable components. But its function will change.

Today a repository is first of all a place where the implementation is stored. In the new architecture, the description becomes more important: what the computation can do, what data it accepts, what rights it requires, how reliable it is, and how it was verified.

So GitHub may gradually turn from a marketplace of source code into a marketplace of verifiable computational capabilities. And then part of that marketplace may not be needed at all. If the system can synthesize a typical capability on its own, there is no point for a human to search for a ready-made repository. They turn to the specification, the verification system, and the generation mechanism.

Source code appears only after that — if it is needed at all.

And then the main question really changes:

Not where the source code is, but what properties the computational capability has and why we should trust it.

The answer becomes provenance:

Capability
   ↓
Provenance
   ↓
Verification
   ↓
Identity
   ↓
Permissions
   ↓
History

Trust ceases to be a property of the interface and becomes part of the computational object itself.

3. A program becomes a process, not a file

A traditional program is a relatively stable artifact:

Source code
 ↓
Binary file
 ↓
Launch

After compilation, a binary file can be used thousands or millions of times.

In the new model, computation can continuously rebuild itself:

Intent
   ↓
Graph
   ↓
Execution
   ↓
Telemetry
   ↓
Re-optimization
   ↓
Recompilation
   ↓
Execution
   ↺

The system may discover that one node of the graph is too slow. Another consumes too much energy. A new model gives a more accurate result. A different NPU turns out to be faster. Part of the task is better done locally. Another part is cheaper to send to the cloud. The input data changed. A new algorithm appeared. Quality requirements changed.

In the classical architecture, such changes require a new version of the program. In the new one, they become part of the normal lifecycle of a computation.

So it is no longer just the code that gets optimized. The computation graph itself gets optimized. The system can choose:

• model;
• algorithm;
• order of operations;
• level of precision;
• tool;
• place of execution;
• memory structure;
• way of decomposing the task;
• number of intermediate computations;
• verification criterion.

An important transition takes place:

The classical compiler optimizes a program, while the new computational compiler can choose the program itself.

This is where the most radical change begins.

4. From the language of instructions to the language of constraints

Modern programming languages ultimately describe a sequence of operations. Even high-level code gradually turns into lower-level representations:

Human intent
     ↓
Source code
     ↓
AST
     ↓
Intermediate representation
     ↓
Machine code

A possible architecture of the future looks different:

Intent
   ↓
Semantic representation
   ↓
Candidate computations
   ↓
Evaluation
   ↓
Optimization
   ↓
Hardware-specific graph
   ↓
Execution

Here the language ceases to be exclusively a language of instructions. It becomes a language of goals, constraints, and quality criteria.

For example, instead of an implementation:

for each document:
    extract tables
    normalize values
    compare rows
    generate report

the system receives a specification:

Goal:
    compare financial documents

Constraints:
    preserve source semantics
    do not modify originals

Quality:
    detect discrepancies above the threshold

Privacy:
    sensitive data stays local

Result:
    verified comparison report

Exactly how this will be implemented can be determined after the specification is received. In this sense, the future language turns out to be closer to a description of the space of acceptable computations than to traditional code.

5. The transformer becomes part of the compiler

This is where the most important technological shift arises.

A modern compiler receives a program and transforms it:

Source code
      ↓
Compiler
      ↓
Optimized binary file

A transformer compiler potentially works differently:

Intent
   ↓
Semantic representation
   ↓
Candidate graphs
   ↓
Evaluation
   ↓
Optimization
   ↓
Hardware-specific execution

Here the model does not just generate text. It can take part in choosing the computation itself. For one task it will choose algorithmic path A, for another path B, and for a third it will discover that a ready-made tool is better than a synthesized implementation.

After execution, the system receives feedback:

Result
 ↓
Verification
 ↓
Telemetry
 ↓
Optimization
 ↓
New graph

A closed loop emerges. This is exactly why the concept of Transformer-Native Computing is more interesting than mere "programming with AI". It is not about a human having stopped writing code by hand. It is about the computing system itself becoming a participant in compilation.

6. The disappearance of glue code

A huge part of modern programming is not creating new algorithms at all. It is connecting existing systems:

API
 ↓
Adapter
 ↓
Parser
 ↓
Database
 ↓
Business logic
 ↓
Another API

Programmers spend enormous time converting formats, writing adapters, handling exceptions, and reconciling interfaces between components. The reason is simple: different systems do not share a common semantic model. A human has to write instructions explaining to one system how to talk to another.

If the computing system itself understands:

"take this data, transform it into this structure, check the condition, and pass the result over there",

a significant part of glue code becomes a temporary intermediate representation. It is not only manual program writing that disappears — the need to keep the program after the task is done disappears.

This is one of the main mechanisms of the transition to Ephemeral Software.

7. Continuous machine optimization

A traditional program has a version:

v1.0
 ↓
v1.1
 ↓
v2.0

Each version appears because a human or a team made changes. In a new-type computing system, optimization can happen continuously.

The system observes:

Latency
Energy consumption
Accuracy
Cost
Memory
Failure rate

and looks for a more efficient implementation. The same Intent may today be executed by one graph and tomorrow by another.

For example:

Intent A

Day 1:
Model A → GPU → Cloud

Day 30:
Model B → NPU → Locally

Day 100:
Model C → Hybrid graph

Meanwhile the user keeps formulating the same intent. What changes is the way it is computed.

This is similar to how a modern processor hides a huge amount of microarchitectural optimization from the programmer. Only now the object of optimization is not a single instruction but the entire computational process. As a result, the program ceases to be a final artifact. It becomes a hypothesis about the best way to perform the task right now.

8. What happens to the programmer profession

Here it is especially easy to draw the wrong conclusion: "Programmers will disappear". What is more likely is the opposite — the division of labor will change.

Today most of applied development sits between the human requirement and machine execution:

Requirement
      ↓
Programmer
      ↓
Source code
      ↓
Computer

If the intermediate layer is synthesized automatically:

Requirement
      ↓
Intent / Specification
      ↓
AI compiler
      ↓
Computation

then the need for a human as a manual translator of requirements into instructions disappears. But tasks of another level remain:

Architecture
Security
Verification
Domain expertise
Policies
Capability Design
System constraints

A human is less and less responsible for each instruction and more and more for the space in which those instructions can be generated. So the future profession may be closer not to a "programmer" in today's sense but to a computing systems and constraints engineer.

He does not design every function. He designs:

• what states exist;
• what capabilities are available;
• what rules apply;
• what results are considered correct;
• how verification is performed;
• what errors are unacceptable;
• what computations can be trusted to the machine autonomously.

This resembles the historical transition from manual machine-tool operation to designing automated production.

9. Code stays where the cost of error is high

Abandoning source code entirely would be a mistake. The higher the requirements for reproducibility and formal verification, the more valuable an explicit implementation is.

Code will survive especially long in areas where it is necessary to prove:

• that the system does exactly what is claimed;
• that the behavior is reproducible;
• that certain classes of errors are absent;
• that critical infrastructure does not depend on the probabilistic behavior of a model;
• that the algorithm can be formally verified.

So the future does not look like "CODE → ZERO". Rather:

CODE
 ↓
one of several representations

For some tasks, code will remain the main artifact. For others, it will become an internal intermediate representation that a human does not need to see at all.

10. The new control point: not code, but capability

If source code ceases to be the main object, a question arises: where does power now concentrate?

In the old model, control is distributed roughly like this:

OS
 ↓
Application
 ↓
Library
 ↓
Code
 ↓
User

In the new architecture, it can shift:

Identity
   ↓
Policy
   ↓
Capability
   ↓
State
   ↓
Computation

What becomes key is not the question "What code do you have installed?" but:

"What computational capabilities are available to you?"

It is capability that becomes the new unit of control. A platform that manages a set of capabilities can control far more than a platform that manages an app store. If one company determines which models are available, which tools are allowed, which data can be used, which agents have identity, and which actions the policy engine permits, it effectively controls the space of possible computations.

So the end of heavy software does not at all mean the end of platform power. It may lead to its concentration at an even deeper level.

11. From the app monopoly to the monopoly of computational space

This is an important correction to the thesis about the decline of Microsoft, Google, and other large platforms. The disappearance of the traditional application does not destroy the monopoly automatically — it may simply move.

Today the user is tied to:

Application
Format
Operating system
App store

Tomorrow they may be tied to:

Model
Identity
Capability Registry
State format
Policy system
Inference infrastructure

The new technological cycle simultaneously creates both the opportunity to destroy old monopolies and the opportunity to build new, even deeper ones. The winner will not necessarily be whoever has more applications. The one who controls the following may win:

models + capabilities + identity + state + verification + computational infrastructure.

This is exactly why the transition to Intent-Based Computing is not only a technological but also an economic shift.

12. What remains of GitHub

In the end, GitHub does not necessarily have to disappear. What may disappear is its current necessity. Today a repository answers the question: "Where is the program?" In the new architecture, other questions matter more:

"What can this capability do?"

"What data does it need?"

"What rights does it require?"

"Who verified it?"

"On what data and models was it created?"

"What are the limits of its use?"

"How to prove the reproducibility of the result?"

So the future system of distributing computation may no longer look like:

Repository
    ↓
Cloning
    ↓
Build
    ↓
Installation

but like:

Capability Registry
       ↓
Trust / Provenance
       ↓
Policy check
       ↓
Composition
       ↓
Runtime optimization

Source code does not disappear anywhere in the process. It simply ceases to be the mandatory unit for distributing a computational capability.

13. After source code

If we put both parts together, a rather unusual picture emerges.

The first part showed the disappearance of the mandatory application:

Application
      ↓
Ephemeral software

The second — the disappearance of mandatory source code:

Source code
      ↓
Semantic representation

Next, the idea of a fixed program disappears too:

Program
      ↓
Adaptive computation

And with it, the role of the compiler changes:

Compiler
      ↓
Continuous computation optimizer

The result is a new sequence:

Human intent
      ↓
Semantic specification
      ↓
Capability Selection
      ↓
Computation synthesis
      ↓
Verification
      ↓
Execution
      ↓
Telemetry
      ↓
Optimization
      ↺

In this architecture, a human is no longer obliged to describe in advance the entire path from intent to result. They set the goal, constraints, and acceptance criteria. The machine chooses the path.

14. What can really disappear

The most likely transformation looks not like the sudden death of programming but like the gradual disappearance of several familiar objects.

First, the application ceases to be mandatory. Then manual integration ceases to be mandatory. Then the need for source code as a user-facing artifact diminishes. Then part of the libraries turn into capabilities. Then compilation turns into a continuous process of synthesis and optimization.

And finally, the very unit of programming changes.

Today we think: "How do I write a program?" In the new architecture, the question gradually becomes different:

"How do you define a space of acceptable computations in which the system itself finds the best way to get the desired result?"

This is no longer just a new way to write software. It is a different model of computation.

15. 2031: what should be visible if this forecast is right

A forecast makes sense only if it can be attempted to be refuted. By 2031, the thesis about the transition to Intent-Based Computing will look convincing only if several observable signs are present.

First: a local Guard or a similar capability and policy control loop will become a common element of mass-market computing devices, not an experimental architecture.

Second: agent identity and permission management will become a standard part of enterprise infrastructure, comparable in importance to human and service-account identity.

Third: generative interfaces (generative UI) will become a working tool in real products, not just a demo feature.

Fourth: a significant part of applied software will be created dynamically by agents, rather than distributed exclusively as pre-built applications.

Fifth: capabilities and semantic specifications will begin to be used as standalone objects of development and audit.

If none of this happens, and generative systems remain mostly assistants writing code for the traditional software stack, then the architectural paradigm shift described here did not take place. And that is a quite possible outcome.

Conclusion: after the program

Over the past half century, the computer industry has several times changed the place where complexity concentrates.

First, humans operated the machine directly. Then programming languages appeared. Then operating systems hid the hardware. Graphical interfaces hid the operating systems. Cloud platforms hid the infrastructure.

Now models are beginning to hide the very process of creating a program.

Each time, complexity did not disappear — it rose one level of abstraction. That is why the next stage may turn out not to be "the era when AI writes all the code". That is too small a forecast.

A deeper transition looks different:

The computer stops waiting for a pre-written program and begins to synthesize computation around intent.

The application becomes temporary. The interface — generative. State — independent of the application. Code — one of the possible intermediate forms. Compilation turns into continuous optimization. And programming gradually shifts from writing instructions to designing intents, constraints, capabilities, and verification criteria.

Perhaps it is here that the era of "heavy software" ends. Not because there will be fewer programs. But because the program will cease to be the main object of the computing system.

The main object will become the machine's ability to transform the state of the world under the influence of human intent. And then the computer will no longer look like a set of installed programs. It will look like a computing environment that reassembles itself around the task every time.