DEV Community: Adi Cohen

The Age of AI Requires Standard Ten: One Unified Code for All Software

Adi Cohen — Sat, 25 Jul 2026 17:18:47 +0000

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

One Thing: every operation receives one canonical Thing and returns one canonical Thing.
One composition form: programs are assembled as nested parts in the same onion or babushka pattern.
One seed: framework, runtime, applications, interfaces, tests, and documentation derive reproducibly from one canonical seed.
No handwritten application code: developers change the seed or declaration; generated artifacts are not manually corrected.
No OOP: functions, modules, and plain data replace user-defined classes, inheritance, and object architecture.
No application control flow: loops, conditions, matching, and control exceptions are replaced by events, routes, maps, folds, and explicit stops.
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.
Explicit boundaries and failures: external effects pass through named outward boundaries. An unrecovered failure opens a ticket; nothing is silently swallowed.
Evidence and determinism: every transformation records ordered evidence, and identical seed, declaration, and input must produce identical artifacts and canonical results.
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

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

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

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.

Effortless Markdown From ChatGPT: Supercharge Your Workflow Now

Adi Cohen — Tue, 05 Nov 2024 13:55:12 +0000

Tip: Effortlessly Moving Content from ChatGPT to Markdown Files

Working with ChatGPT can be powerful, especially when you need output in Markdown format. But turning ChatGPT responses into a format ready for your source code can be a bit of a headache. Here’s a strategy I’ve refined to help simplify this process.

`The Challenges of Formatting Markdown from ChatGPT`

Sometimes, asking ChatGPT to output in Markdown, especially with code blocks, can lead to formatting issues.

A basic prompt like:

output in MD format as plaintext into a code block is usually fine. However, if your response includes nested code blocks, things get trickier. Markdown can’t handle nested blocks cleanly, leading to a cluttered or broken format that requires tedious manual fixing.

`A Simple Prompt Hack to Handle Code Blocks`

To make the output easier to handle, I recommend modifying the prompt slightly:

Provide the text with code blocks as one large block. Escape each inner code block’s backticks with double backslashes (\`\\\`\`) and avoid inline Markdown.

While this prompt works, remembering it every time can be cumbersome.

Consider, maybe, using a Chrome extension or snippet manager to store it for quick access.

`An Alternative Approach Using Google Docs`

Recently, I stumbled upon another approach. Copy-paste the response into Google Docs and download it as a .md file.

Open this Markdown file in your IDE, delete any broken code blocks, and simply paste them back from the original ChatGPT response.

This method reduces errors and makes your Markdown files easier to read and share.

`Check Out More Thought-Provoking Content on Adico.tech`

If you found this tip useful, you’ll likely enjoy my latest article: “Think OOP is the Gold Standard for Code Organization? Think Again!”. It challenges traditional Object-Oriented Programming (OOP) principles and explores fresh alternatives for structuring code.

If this sparks ideas, share it, follow, and spread the word!

Keep coding, stay skeptical, and remember: sometimes, the simplest solutions are right in front of us.

Think OOP is the gold standard for code organization? Think again!

Adi Cohen — Mon, 04 Nov 2024 10:11:09 +0000

TL;DR

The Dark Ages of Software Development: The era of Object-Oriented Programming (OOP) can be aptly termed the dark ages of software development, characterized by unnecessary disputes, and a lack of standardization.
Over-Architected Solutions: OOP represents an over-engineered response to the problems it was intended to solve, introducing more complexity than necessary.
Complex Encapsulation: OOP’s approach to encapsulation results in a tree structure layered over another tree structure [folder structure – the natural encapsulator], leading to O(n²) complexity.
Decoupled with Reusability: OOP couples Encapsulation and Reusability in one package, promoting reusability everywhere, instead of by design.
Promoted Arguments/Delayed Standardization: OOP promoted more complicated layered architectures that tried to untangle from it complexity created more complexity.
Costly Consequences: The inefficiencies stemming from OOP have incurred significant costs, adversely affecting productivity and maintenance across the industry.
Natural Evolution: The shift toward organizing classes into single files and dedicated folders signifies a crucial evolution in software design, promoting clarity and modularity.
Introducing MBE: Modular-Based Engineering (MBE) advocates for a simpler, more intuitive folder structure that enhances code organization and maintainability.
The Path Forward: MBE presents a standardizable, clear, adaptable, and estimable solution for modern software development, guiding us away from the complexities of OOP.

Object-Oriented Programming (OOP) has long been celebrated as a revolutionary achievement in software engineering. It introduced the concepts of encapsulation, inheritance, and polymorphism, promising to organize and simplify software complexity. By encouraging developers to think in terms of real-world “objects,” OOP seemed poised to bring clarity and modularity to coding practices. However, as software systems evolved, the initial promise of OOP began to unravel, revealing inherent complexities and pitfalls that hindered its effectiveness.

OOP’s appeal extends beyond its practical benefits; it became a cornerstone of educational curricula, shaping how generations of developers learned to code. This deep-rooted adoption ensured that OOP would be seen as the “right way” to build software, prompting companies to invest billions into applications built around its principles. Yet, as systems grew more complex, developers found themselves tangled in layers of inheritance and convoluted design patterns intended to address the very complications OOP introduced.

Ultimately, OOP’s grand promise has led the software industry into what can be termed the “dark ages of software development,” creating the very complexities it sought to resolve. The time has come to reevaluate the efficacy of this once-visionary approach.

A Critical Analysis of OOP’s Limitations

Despite its conceptual brilliance, Object-Oriented Programming (OOP) has imposed a rigid framework that complicates software development. The reliance on class hierarchies creates inflexible structures that are difficult to modify or extend. When changes are needed, developers often navigate complex webs of dependencies, risking new bugs and increasing technical debt.

A key issue with OOP is its dependence on hierarchical inheritance. Classes inherit attributes and behaviors from parent classes, which can stifle flexibility and lead to cascading changes throughout the system. Once a class hierarchy is established, any necessary modifications can introduce unintended side effects, creating a fragile codebase. This reliance on tree structures leads to “n^2 complexity,” where the impact of changes can ripple through the entire codebase, complicating even minor modifications.

As we transitioned from OOP, we began to see a significant evolution in software development. The movement toward organizing classes into dedicated files marked a pivotal shift. By enforcing the rule that one class should reside in its own folder, developers embraced a more modular mindset. This evolution not only simplified code organization but also laid the groundwork for robust testing practices. Testing a single class housed within a clearly defined folder structure made it easier to identify dependencies and isolate issues, resulting in cleaner, more maintainable code. This evolution prompts us to ask: Where are we headed? The answer lies in recognizing that a logical folder structure is the natural way to encapsulate functionality. This shift reflects an understanding that OOP built a tree structure on top of an existing tree structure, leading to compounded complexities.

Additionally, while reusability has long been touted as a hallmark of good software design, it is worth reconsidering whether it should always be promoted. The principle of “Don’t Repeat Yourself” (DRY) can sometimes lead to over-complexity and confusion. Reusability should be viewed as a contextual consideration rather than an absolute rule, as enforcing it indiscriminately can obscure code clarity and maintainability.

The cost of OOP’s limitations has been staggering, with estimates suggesting trillions of dollars wasted on maintenance, technical debt, and the inefficiencies created by unnecessary arguments over architectures and non-standardization in the field. These financial implications underscore the need for a shift away from the entrenched paradigms that OOP established. The debates and lack of standardization in software development fueled by OOP’s complexities have stifled innovation, diverting resources away from more productive avenues.

Ultimately, OOP has led us into what can be termed the “dark ages of software development.” It has become clear that OOP is an ill-solution that leads to overcomplications and creates a landscape fraught with inefficiencies. As we look toward the future of software engineering, it is essential to acknowledge these limitations and embrace more effective paradigms, such as Modular-Based Engineering (MBE), that promise clarity, adaptability, and a more sustainable approach to building software.

If OOP Wasn’t the Solution, What Is?

This critique of OOP’s shortcomings points us toward a simpler, more flexible approach that avoids its hierarchical complexities. Modular-Based Engineering (MBE) offers a viable alternative, providing a streamlined, efficient framework for building scalable software.

Embracing Modular-Based Engineering for Software Simplicity

Meta Description: Discover how Modular-Based Engineering offers a simpler, more effective approach.

Introducing Modular-Based Engineering (MBE)

MBE represents a modern shift in software development by focusing on simplifying code structure, minimizing dependencies, and reducing technical debt. By eliminating rigid class hierarchies and relying on function-based modules organized by logical folder structures, MBE directly addresses the complexity that OOP introduces. Here, we explore MBE’s core principles and illustrate how each simplifies development compared to OOP.

Modularity Without Classes
In MBE, software is broken down into independent, functional modules instead of relying on classes. Each module serves a specific purpose and interacts through well-defined interfaces, allowing for greater flexibility and easier maintenance. This independence reduces technical debt, as refactoring or replacing a module can be done without impacting others.
Clear Functional Boundaries
MBE prioritizes clear functional boundaries, using pure functions that operate independently and produce no side effects. This ensures that modules are predictable, easily testable, and scalable. In contrast, OOP often entangles functionality within classes, leading to hidden dependencies that complicate testing and debugging.
Encapsulation Through Folder Structure
Instead of encapsulating data and behavior within objects, MBE uses a logical folder structure to define boundaries. Each module is organized intuitively, eliminating the need for complex access controls found in OOP. This natural organization enhances code navigation and clarity.
Dependency Management Without Inheritance
MBE promotes composition over inheritance, allowing modules to import only the dependencies they need. This approach prevents the “fragile base class problem,” where changes in a parent class can ripple through child classes. By keeping dependencies at the module level, MBE enables loose coupling and reduces the impact of changes.
Natural Organization with a Folder-Based Structure
MBE fosters a clear, navigable codebase by organizing modules in a folder-based structure. This eliminates the scattered, often confusing layout seen in OOP. With a well-defined structure, developers can easily locate code and understand the system’s architecture.

Building a Standardized Approach for Software Engineering
To further address the challenges of code organization in modern software development, I am working on the Standardized Folder Structure Whitepaper, which aims to establish a common framework for organizing software projects. This project leverages the principles of MBE to create a cohesive, community-driven approach to structuring code.

At the heart of this initiative is the belief that software projects should follow a logical organizational model that is easily navigable by any developer. This whitepaper introduces a modular folder structure that prioritizes simplicity and adaptability, eliminating the confusion often present in large codebases.

The work is evolving toward a new framework tentatively named CORE, which aims to standardize software engineering practices. I invite you to explore the GitHub repository for the Standardized Folder Structure Whitepaper at https://github.com/adico1/standardized-folder-structure-whitepaper. This is an open, collaborative project where contributions from the developer community are invaluable.

By sharing ideas and refining the structure together, we can create a lasting standard for software development that enhances clarity and maintainability across projects. Join us in bringing much-needed standardization to software engineering—a shift that has the potential to benefit developers and organizations industry-wide.