What is Emergent Coding?
Last week, at a Bitcoin Cash conference, I was introduced to a groundbreaking new paradigm in software development, called Emergent Coding.
Not just a new programming methodology — this is quite possibly the most radical software breakthrough to appear in decades. Emergent coding is as different from traditional coding as Bitcoin is from traditional money.
Source Code and Compiled Code
In order to understand emergent coding, we have to know a few things about code.
There’s two broad varieties of computer code. The first is source code, also known as “high level language” code. This is human-readable. It’s what programmers work with all day long.
The second is compiled code, and is not human-readable. It’s understood by machines, and at the lowest level is simply 1s and 0s. It may be called “byte code”, “machine code”, or similar names. Compiled code is generated from source code by a special program called a compiler.
Proprietary Software vs Open Source Software
Emergent coding is an alternative to the existing methods used to develop software: proprietary and open-source. Let’s quickly review these:
Proprietary: A company will pay developers, but the end user only has access to the compiled code. The intellectual property of the company (and the revenue potential of the software) is protected because it’s hard to reverse-engineer the compiled code to get the source.
Open-source: Developers make their source code available to the entire world. Anyone can compile it, use it, re-use it, copy it, and pretty much do whatever they want. Although there are ways to monetize open source projects, most open source code development is uncompensated.
Getting the Best of Both Worlds
The great advantage of open-source is the efficiency that comes from code re-usage, and also the capacity for many unaffiliated developers to collaborate. However, if anyone is allowed to freely copy and use the code, it also means there’s limited potential for developers to be paid.
On the other hand, proprietary software provides a business model that pays developers, yet has limited potential for code reuse or collaboration outside of the company.
What if there could be system that offers both developer compensation and code reuse? This is what makes emergent coding so powerful.
The “ELI5” on How It Works
In a nutshell: In emergent coding, developers don’t publish source code. They only provide compiled code. This protects their intellectual property. Despite the absence of source code, the functionality (i.e. “software feature”) can be integrated into any project that wants to use it at compile time.
Of course, the entire system is engineered in such a way as to make this possible. (In the traditional software world, you cannot take two separately developed pieces of machine code and mash them together.)
Developers create applications called “Agents” which are designed to provide a specific feature. Compilation is done in a decentralized manner. Agents collaborate and interface with other Agents, and also make compile-time requests to subcontractor Agents.¹
The result of utilizing an Agent in your project is that its code cannot be easily reverse-engineered. The compiled code is highly contextual, making it virtually impossible to copy a compiled feature into another project.
But there is another aspect to all this, and that’s the economic model.
It’s All About the Economic Incentives
There’s several parallels between Bitcoin and emergent coding. Bitcoin was revolutionary not just because it used proof-of-work mining, but also because it came with a baked-in economic incentive model that helped secure the system.
“A greedy attacker…ought to find it more profitable to play by the rules” — Satoshi Nakamoto
Likewise, emergent coding doesn’t merely enable decentralized code compilation. It also incentivizes and monetizes it. Like Bitcoin, it turns human greed into something useful, productive, and beneficial.
You see, it’s not just that a code agent is integrated into a project at compile time… it’s also simultaneously paid for the privilege.
Perhaps this is part of the reason why it took 50 years for such a system to appear — before Bitcoin, there wasn’t a good payment rail to even make this kind of system feasible.
This is not to imply that once Bitcoin came along, it was easy to create emergent coding. Under the hood, there is an intricate set of moving parts that represents a true feat of engineering.
The Future
Only time will tell how big emergent coding will be. It seems to have huge potential, because it seeks to make the software development industry more “granular” and thus more market-efficient.
A whole class of developers who aren’t receiving funding from proprietary software projects can earn a living or increase their income.
The most reliable, least buggy, and best performing code will naturally rise to the top for the benefit of everyone — a real answer to the decades-old problem of software projects being consistently past-deadline and over-budget. Plus, the code reuse that is afforded becomes even stronger and less buggy due to its repeated testing.
The most common objection I hear among developers is “everything will have to be rewritten”. Although this is generally true, there’s an economic incentive to make this happen. And if Bitcoin is any indication, there may be a huge early adopter opportunity here.
Footnotes
1. A slightly more detailed explanation of how it works:
Emergent Coding uses a mesh of software “Agents” to perform the role of a compiler — a “distributed” compiler. Each Agent in this mesh provides a for-fee service that creates a “feature” in a client’s project. To create software, a developer merely selects the features they want, and contracts the Agents that provide those features. Those Agents contracted will collaborate to determine some high level design requirements before subcontracting pre-vetted Agents for smaller features that cleverly map onto their own feature. That is, by building their smaller features into the project, these subcontractors will automatically meet the obligations of delivering the parent feature.
But these subcontractors also collaborate and subcontract for yet smaller features and-so-on. Importantly, each subcontracting link forms a temporary project scaffold vital to the operation of the final stages of the distributed compiler. Eventually after many layers of subcontracting, Agents are contracted for the tiniest features which, thanks to the scaffold, now understand precisely where in the project binary their feature is to be delivered. They too collaborate with peers at their level to determine some requirements (such as how to represent an integer or flag etc.), gathering the remaining knowledge needed to design a binary fragment typically consisting of little more than a machine instruction. These custom designed fragments are returned to their clients which use the scaffold to guide the pieces together. These clients do likewise, combining fragments guided by the scaffold to create ever larger fragments until what emerges is one big fragment — the project’s machine code!
