Adi Cohen

Originally published on adico.tech. The evolving reference implementation is on GitHub.

My claim is simple: software can be standardized.

In the age of AI, we should not use faster code generation to multiply every historical inconsistency in software development. We should rewrite software toward one unified standard so that humans and AI generate the same best-practice structure every time.

Mathematics gained enormous computational power when Wolfram built a coherent symbolic language around mathematical objects and operations. Software development now needs the equivalent: one language, one machine model, one composition process, one evidence trail, and one standard from the first seed to the final running system.

The problem with AI-generated code

AI can generate code quickly, but speed alone does not create coherence. Without a governing standard, every model can fall back to ordinary development: different signatures, object hierarchies, handwritten glue, loops, conditions, duplicated interfaces, platform-specific implementations, and tests added after the architecture has already diverged.

That is not the future I want. AI should not merely imitate the accumulated habits of the software industry. It should generate from a smaller, deterministic, and verifiable foundation.

Standard Ten

  1. One Thing: every operation receives one canonical Thing and returns one canonical Thing.
  2. One composition form: programs are assembled as nested parts in the same onion or babushka pattern.
  3. One seed: framework, runtime, applications, interfaces, tests, and documentation derive reproducibly from one canonical seed.
  4. No handwritten application code: developers change the seed or declaration; generated artifacts are not manually corrected.
  5. No OOP: functions, modules, and plain data replace user-defined classes, inheritance, and object architecture.
  6. No application control flow: loops, conditions, matching, and control exceptions are replaced by events, routes, maps, folds, and explicit stops.
  7. One event machine: every execution target uses the Unified Event Machine. Python, C, CLI, API, GUI, and browser hosts are interfaces around the same machine.
  8. Explicit boundaries and failures: external effects pass through named outward boundaries. An unrecovered failure opens a ticket; nothing is silently swallowed.
  9. Evidence and determinism: every transformation records ordered evidence, and identical seed, declaration, and input must produce identical artifacts and canonical results.
  10. Complete generated verification: tests, gauntlets, mutations, traceability, and coverage derive from the same source and must satisfy the standard completely.

Conventional development is not an authorized fallback. If Standard Ten cannot express a requested feature, the system reports standard.gap. The standard must be extended generically before the feature is implemented.

One developer language

The developer should not switch languages when moving between the kernel, application, API, GUI, browser, tests, and deployment. The unified development surface is a constrained Python language: functions, modules, canonical Things, event declarations, route tables, and interface trees.

Physical platforms may require UEM bytecode, WebAssembly, native machine code, HTML, CSS, or C. These are generated physical artifacts, not additional developer languages. Developers write one Python seed; the system generates the required targets.

The Unified Event Machine

There is no native machine language supported directly by every processor. Therefore, the project defines a small chip-neutral virtual machine: UEM-16.

LOAD READ WRITE DELETE
EMIT ENQUEUE DEQUEUE ROUTE
APPLY MAP FOLD VERIFY
TICKET OUTWARD ACK STOP

Enter fullscreen mode Exit fullscreen mode

Applications contain no direct loops or conditions. Selection and iteration are confined to named, contract-tested machine primitives. External effects are requests handled by host boundaries. Expected validation failures remain domain results; unrecovered runtime failures create redacted, deduplicated ticket events.

GUI and browser without hardware dependence

The VM interface is also data. A single interface Thing describes windows, controls, layout, state, evidence, tickets, and a browser surface. Native windows, browser windows, remote control, and headless tests are adapters around the same interface protocol.

physical input
→ normalized interface event
→ UEM route
→ new interface Thing
→ outward render request

Enter fullscreen mode Exit fullscreen mode

No widget contains application decisions. Browser navigation, clicking, typing, reading, and screenshots are explicit outward requests whose results return as canonical events.

What has already been demonstrated

  • A Python kernel based on one-input/one-output Things, nested composition, explicit states, evidence, and boundaries.
  • A generator that creates complete small applications and adds features through declarations.
  • Two independent generated domains: text statistics and invoice totals, with zero manual runtime or generated-test corrections.
  • Generic expression composition without invoice-specific generator vocabulary.
  • Event-driven generated domain logic and composition, with residual imperative control flow explicitly counted rather than hidden.
  • UEM-16 canonical bytecode executed by independent Python and C99 hosts.
  • Cross-host canonical equivalence, frozen UEM-ASCII-1 semantics, mutation fuzzing, sanitizer runs, and native x86-64 golden execution.
  • Testing gauntlets that verify laws, effects, execution, contracts, rollback, idempotency, mutations, performance, event flow, ticket behavior, and cross-host equivalence.

The project does not yet claim support for every chip. ARM64, RISC-V, and microcontroller support should be claimed only after unchanged golden vectors run on physical target hardware. The distinction between demonstrated results and future proof is part of the standard.

The direction

AI should generate software the way a deterministic mathematical system evaluates expressions: from a small canonical vocabulary, under explicit laws, with reproducible results and complete verification.

The target pipeline is:

one Python seed
→ Standard Ten declarations
→ UEM-16 canonical bytecode
→ verified host adapter
→ GUI, browser, API, CLI, or physical processor

Enter fullscreen mode Exit fullscreen mode

We should not ask AI to write millions of incompatible programs faster. We should ask AI to regenerate software into one coherent form—and prevent it from falling back when the standard exposes a missing capability.

This is the claim: in the age of AI, the world's code can and should be rewritten toward a unified Standard Ten.

Open implementation

The evolving reference implementation is published at github.com/adico1/unified-code, with generated proof applications in the repository.