The conversation about artificial intelligence has narrowed to two competing bets about how human-level capability is built. The first, held by the major frontier labs, is that scaling neural networks produces general intelligence as an emergent property. The second, held by a smaller community in the cognitive-science lineage, is that intelligence requires explicit cognitive architecture. Both bets are unresolved, and both engage centrally with whether sufficiently capable AI systems can be produced. This paper argues that a third bet sits beneath both, addresses a question neither engages with directly, and is independently worth making: software construction is fundamentally the transformation of semantic representations into one another, and the substrate that supports those transformations determines what AI assistance can do. The current substrate for AI-assisted construction — source code in text files, semantic structures in developers' heads, prose documentation that no toolchain can verify — places a ceiling on what AI assistance can achieve no matter how capable the underlying language models become. We describe a substrate that addresses this gap: a self-defining specification language, a compiler-compiler that produces parsers and serializers in four target languages, a canonical binary form with round-trip closure as structural-correctness oracle, and first-class isomorphic mappings between representations. The implementation backing for this architectural model is established in [2]; the present paper articulates the position-level implications, summarizes empirical results on construction of approximately twenty-six sibling repositories over twelve weeks of focused work, describes the *Adaptive Programming* methodology that emerges when AI assistance operates at the specification layer, and considers two application domains — cross-language source translation and ontology-based knowledge extraction — where the substrate reframes problems current tooling addresses poorly. The third bet's position is intentionally narrow: not a path to general intelligence, not a theory of cognition, but a class of substrate that makes AI-assisted specification-layer construction tractable in ways code-layer assistance alone cannot reach.
Aleksandr F. Urakhchin· Zenodo (CERN European Organi...· 0 citations
Translating an existing application from one general-purpose programming language into another is a long-standing engineering problem with no general solution. Arbitrary source-to-source translation is intractable because the two languages live in different runtime-semantic worlds with significant non-isomorphism in their type systems, exception models, standard libraries, and reflection capabilities. We report a worked example in which a specific class of application — a data-model-shaped web backend, specifically the canonical RealWorld / Conduit Medium-clone specification implemented in Python with FastAPI — is mechanically translated into TypeScript via a multi-stage pipeline of deterministic transformations operating over a small, well-bounded family of domain-specific languages. The pipeline decomposes the Python source into ten family-specific DSLs (DataModelEntity, DataModelRelationship, RouteContract, RouteHandler, RepositoryQuery, AuthPolicy, ValidationRule, ErrorHandling, Configuration, ApplicationBootstrap), emits TypeScript fragments through ten independent per-family emitters, assembles the fragments into target modules, fills handler bodies through a registry of hand-authored translations, and wires the result through a thin TypeScript runtime adapter into an Express HTTP service. The resulting service passes 293 of 293 assertions of the canonical RealWorld Postman conformance collection — exceeding the upstream Python baseline of 280 assertions. The methodological discipline that drove the work — Adaptive Programming: explicit `LOCK` invariants declared at every slice opening, hand-authored golden artefacts validated by byte-equal diff before any implementation iteration — closed forty-six slices over the arc, of which forty-two landed without implementation iteration. We are explicit about scope: the authentication flow is end-to-end pipelined (register, login, JWT issuance, validation cross-call), exercising the full decompose → emit → assemble → bodies → runtime path; the non-authentication endpoints (articles, comments, profiles, tags, follow) execute against hand-wired runtime handlers that share state with the pipelined infrastructure. The full Postman collection passes against the resulting service.
Aleksandr F. Urakhchin· Zenodo (CERN European Organi...· 0 citations
The conversation about artificial intelligence has narrowed to two competing bets about how human-level capability is built. The first, held by the major frontier labs, is that scaling neural networks produces general intelligence as an emergent property. The second, held by a smaller community in the cognitive-science lineage, is that intelligence requires explicit cognitive architecture. Both bets are unresolved, and both engage centrally with whether sufficiently capable AI systems can be produced. This paper argues that a third bet sits beneath both, addresses a question neither engages with directly, and is independently worth making: software construction is fundamentally the transformation of semantic representations into one another, and the substrate that supports those transformations determines what AI assistance can do. The current substrate for AI-assisted construction — source code in text files, semantic structures in developers' heads, prose documentation that no toolchain can verify — places a ceiling on what AI assistance can achieve no matter how capable the underlying language models become. We describe a substrate that addresses this gap: a self-defining specification language, a compiler-compiler that produces parsers and serializers in four target languages, a canonical binary form with round-trip closure as structural-correctness oracle, and first-class isomorphic mappings between representations. The implementation backing for this architectural model is established in [2]; the present paper articulates the position-level implications, summarizes empirical results on construction of approximately twenty-six sibling repositories over twelve weeks of focused work, describes the *Adaptive Programming* methodology that emerges when AI assistance operates at the specification layer, and considers two application domains — cross-language source translation and ontology-based knowledge extraction — where the substrate reframes problems current tooling addresses poorly. The third bet's position is intentionally narrow: not a path to general intelligence, not a theory of cognition, but a class of substrate that makes AI-assisted specification-layer construction tractable in ways code-layer assistance alone cannot reach.
Aleksandr F. Urakhchin· Zenodo (CERN European Organi...· 0 citations
Translating an existing application from one general-purpose programming language into another is a long-standing engineering problem with no general solution. Arbitrary source-to-source translation is intractable because the two languages live in different runtime-semantic worlds with significant non-isomorphism in their type systems, exception models, standard libraries, and reflection capabilities. We report a worked example in which a specific class of application — a data-model-shaped web backend, specifically the canonical RealWorld / Conduit Medium-clone specification implemented in Python with FastAPI — is mechanically translated into TypeScript via a multi-stage pipeline of deterministic transformations operating over a small, well-bounded family of domain-specific languages. The pipeline decomposes the Python source into ten family-specific DSLs (DataModelEntity, DataModelRelationship, RouteContract, RouteHandler, RepositoryQuery, AuthPolicy, ValidationRule, ErrorHandling, Configuration, ApplicationBootstrap), emits TypeScript fragments through ten independent per-family emitters, assembles the fragments into target modules, fills handler bodies through a registry of hand-authored translations, and wires the result through a thin TypeScript runtime adapter into an Express HTTP service. The resulting service passes 293 of 293 assertions of the canonical RealWorld Postman conformance collection — exceeding the upstream Python baseline of 280 assertions. The methodological discipline that drove the work — Adaptive Programming: explicit `LOCK` invariants declared at every slice opening, hand-authored golden artefacts validated by byte-equal diff before any implementation iteration — closed forty-six slices over the arc, of which forty-two landed without implementation iteration. We are explicit about scope: the authentication flow is end-to-end pipelined (register, login, JWT issuance, validation cross-call), exercising the full decompose → emit → assemble → bodies → runtime path; the non-authentication endpoints (articles, comments, profiles, tags, follow) execute against hand-wired runtime handlers that share state with the pipelined infrastructure. The full Postman collection passes against the resulting service.
Aleksandr F. Urakhchin· Zenodo (CERN European Organi...· 0 citations
We use cookies to run the site and, with your consent, for analytics and to show ads.
See our Cookie Policy.
