DEV Community: Todd Henderson

AiLang Core Architecture Milestone: Decoupling Targets from the Compiler

Todd Henderson — Tue, 30 Jun 2026 18:03:07 +0000

Decoupling Targets from the Compiler

As AiLang progresses through the 0.0.1 Release Candidate series, the focus is shifting.

Most of the major language features are in place. The virtual machine is stabilizing. The standard library continues to grow.

Now the work is increasingly about refining the architecture before the first stable release.

One of the most significant architectural milestones we've recently completed is the separation of Targets from the compiler.

It may not be as flashy as a new language feature, but it fundamentally changes how the entire ecosystem will evolve.

The Problem

Originally, platform support lived alongside the compiler.

That approach works well early in a project's life, but it doesn't scale.

Every new platform adds more complexity.

Every platform-specific bug potentially requires releasing the compiler.

Every experimental platform increases the maintenance burden for everyone—even developers who will never use it.

As we started planning support for additional targets, the architecture no longer felt right.

Questions started coming up like:

How do we support Raspberry Pi?
What about BeagleBone?
Embedded ARM boards?
Headless cloud services?
Mobile platforms?
An operating system?

The compiler shouldn't need to know about any of those.

Its job is to understand AiLang.

Nothing more.

A New Separation of Responsibilities

The solution is surprisingly simple.

Instead of shipping every platform inside the compiler, Targets become installable packages.

The compiler understands the language.

Targets understand platforms.

            AiLang Compiler
                    │
         ┌──────────┴──────────┐
         │                     │
      AiVM Runtime         Package Manager
                                 │
      ┌──────────────────────────┼──────────────────────────┐
      │                          │                          │
 target-linux              target-macos              target-windows
      │                          │                          │
 target-wasm               target-aios                 target-rpi
      │                          │                          │
                    ...and any future targets...

This gives every target its own lifecycle.

Need to update Raspberry Pi support?

Release a new Raspberry Pi target.

Need support for a new Apple SDK?

Update the macOS target.

Want to experiment with an entirely new platform?

Build a new target package.

The compiler doesn't change.

Why This Matters

This architecture has several advantages.

Independent Releases

Platform support no longer dictates compiler releases.

Each target can evolve independently.

Smaller Core

The compiler remains focused solely on understanding the language.

That keeps it easier to maintain, easier to test, and easier to reason about.

Cleaner CI/CD

Each target can have its own build pipeline, tests, dependencies, and release cadence.

Desktop changes don't impact embedded builds.

Embedded work doesn't slow down desktop developers.

Community Contributions

Eventually, anyone should be able to build their own target without modifying the compiler itself.

Introducing AiOS

One of the biggest beneficiaries of this architecture is something I've hinted at for a while:

AiOS.

AiOS is an experimental operating system target built around the AiVM runtime.

Instead of publishing an executable that runs on another operating system, the goal is to publish a complete bootable image that contains only what's necessary to run an AiLang application.

Think of it like this:

Instead of asking:

"How do I deploy my application onto an operating system?"

AiOS asks:

"What if the application is the operating system?"

Early development is focused on QEMU while the platform matures, with additional hardware targets planned later.

Running Natively...

One of the exciting parts of this milestone is that the exact same AiLang application already runs natively.

Native macOS

No code changes.

Same language.

Same application.

Different target.

...and Running Under AiOS

Now that Targets have been separated, that same application can also run inside AiOS.

It's still early.

There's a tremendous amount of work ahead.

But seeing AiLang applications boot inside an operating system built specifically around the AiVM is an exciting milestone.

Looking Forward

Separating Targets from the compiler opens the door for far more than AiOS.

Future targets could include:

Linux
Windows
macOS
WebAssembly
Raspberry Pi
BeagleBone
Embedded ARM devices
Cloud microservices
Kiosk systems
Virtual appliances
Experimental hardware
Community-developed platforms

Each one can evolve independently while sharing the same compiler and deterministic virtual machine.

Building an Ecosystem

One thing I've learned while building AiLang is that good architecture is usually about removing responsibilities, not adding them.

Today the ecosystem is becoming much clearer.

AiLang defines the language.
AiVM executes deterministic bytecode.
AiVectra provides a deterministic vector-based UI framework.
Targets understand how to build and publish for specific platforms.
AiOS is one possible target built on that foundation.

Each project has a well-defined responsibility.

Each can evolve independently.

That's a much healthier architecture than trying to build everything into one monolithic toolchain.

The Road to 0.0.1

This work is part of the ongoing effort to stabilize the project as we move through the 0.0.1 Release Candidate series.

It's one of those milestones users may never directly notice—but it's the kind of architectural improvement that makes the project easier to maintain, easier to extend, and easier for others to contribute to.

The language remains focused.

The virtual machine remains deterministic.

Platforms become modular.

That's exactly where I want AiLang to be as we move toward the first stable release.

If you've been following the project, thank you for coming along on the journey.

And if you're just discovering AiLang, now is a great time to take a look. The architecture is beginning to settle, and some exciting things are coming next.

Learn More

If you'd like to follow the project or get involved, here are the best places to start:

Website: AiLang.Codes
GitHub Organization: Github
GitHub Sponsors: Sonsorship

Feedback, bug reports, feature ideas, and contributions are always welcome. As the project moves through the 0.0.1 Release Candidate series, community feedback is helping shape the path toward the first stable release.

What Nearly Two Years of AI Development Taught Me About Teaching

Todd Henderson — Sun, 21 Jun 2026 18:14:34 +0000

Almost two years ago, one of my clients asked me to evaluate AI development tools.

At the time, I had already worked on projects that integrated AI. I had built systems that called AI services, processed AI outputs, and incorporated AI features into applications. But I had never really developed alongside an AI agent.

So I spent time experimenting.

I tried AI-enabled IDEs. I used multiple coding agents. I built demo projects. I intentionally explored different workflows to understand where these tools helped and where they struggled.

What started as a client evaluation turned into nearly two years of daily experience working with AI as part of the software development process.

What surprised me most wasn't the technology.

It was how familiar it felt.

Over the years I've spent a lot of time teaching youth through Scouting America, serving as a merit badge counselor, and helping young people learn technical and practical skills. Again and again, I found myself noticing parallels between mentoring youth and working with AI agents.

The comparison isn't perfect, but it is surprisingly useful.

AI Is Often Like an Eager Beginner

One of the biggest misconceptions about AI is that it behaves like an experienced professional.

In reality, most AI agents behave much more like a highly motivated beginner.

They have read an enormous amount of information.

They can explain concepts fluently.

They often sound extremely confident.

But confidence and understanding are not the same thing.

Anyone who has taught youth has seen this before.

A Scout may be able to repeat information from a handbook perfectly while still lacking practical experience. They know the words, but not yet the judgment that comes from doing the work.

AI often behaves the same way.

It can produce impressive-looking code. It can explain architectural patterns. It can discuss best practices.

But it still benefits enormously from guidance, review, correction, and context.

Instructions Matter More Than Intelligence

When teaching young people, vague instructions usually produce vague results.

"Go clean the campsite" and "Pick up all trash, stack the firewood, and sweep the pavilion" produce very different outcomes.

The same thing happens with AI.

The quality of the result is often directly related to the quality of the instruction.

Developers sometimes describe this as prompt engineering, but to me it feels much closer to mentoring.

Clear expectations matter.

Concrete examples matter.

Defined success criteria matter.

The better the guidance, the better the outcome.

Feedback Loops Are Everything

One of the most effective teaching techniques is immediate feedback.

A student attempts a task.

The mentor reviews it.

Corrections are made.

The student tries again.

AI development works remarkably similarly.

The most productive sessions are rarely a single prompt followed by perfect output.

Instead, they are conversations.

Review.

Correction.

Refinement.

Iteration.

The agent improves because the feedback improves.

Trust Must Be Earned

When teaching youth, you don't immediately hand someone a chainsaw and walk away.

You start with smaller tasks.

You verify understanding.

You gradually increase responsibility.

I've found that AI works best the same way.

I don't blindly accept generated code.

I don't assume correctness because something compiles.

Instead, I establish trust through verification.

Some tasks can be delegated almost completely.

Others require careful review.

The key is understanding where the agent has demonstrated competence and where it still needs supervision.

Context Is More Important Than Capability

One lesson I've learned repeatedly is that AI agents often fail not because they lack capability, but because they lack context.

This is also true when teaching people.

A student who doesn't understand the goal of a project will often make poor decisions despite having the technical skills to complete the task.

AI behaves similarly.

The more context an agent has about the project, architecture, constraints, and goals, the better decisions it tends to make.

This is one reason I've become increasingly interested in AI-friendly software architecture.

Good structure doesn't just help humans.

It helps AI as well.

The Best Results Come From Partnership

The most important lesson from the last two years is that AI works best as a collaborator rather than a replacement.

The strongest outcomes happen when human judgment and AI assistance complement each other.

The human provides direction, priorities, experience, and accountability.

The AI provides speed, recall, exploration, and execution assistance.

Neither is sufficient by itself.

Together they can often accomplish more than either could alone.

Final Thoughts

After nearly two years developing alongside AI agents, I don't see them as magical or mysterious.

I also don't see them as replacements for human expertise.

Instead, I increasingly view them as something familiar: capable assistants that benefit from guidance, mentorship, feedback, and structure.

Perhaps that's why the transition felt so natural.

The same skills that help teach young people—patience, communication, clear expectations, constructive feedback, and good leadership—turn out to be surprisingly valuable when working with AI.

The technology is new.

The human skills are not.

From Specifications to Software: AiLang’s First Cross-Platform Application

Todd Henderson — Tue, 16 Jun 2026 03:01:13 +0000

For the past year, I've been building AiLang, an open-source programming language designed around a simple idea:

Application semantics should live in the language, not the host runtime.

This week, the project reached an important milestone.

A weather application written entirely in AiLang now runs on both native macOS and Browser/WebAssembly targets.

While a weather app may not sound particularly exciting, the significance isn't the application itself. The significance is what the application proves.

Why a Weather App?

When building a new language, it's easy to get stuck in a world of examples and toy programs.

Hello World works.

Arithmetic works.

Unit tests pass.

But none of those prove that real applications can be built.

A weather application exercises a surprising amount of the ecosystem:

Multi-file modules
Imports and exports
HTTP requests
JSON processing
String manipulation
State management
User interface rendering
Cross-platform execution

It becomes a practical test of whether the language, runtime, and libraries are actually working together.

The Architecture

AiLang is part of a larger ecosystem consisting of three major components:

AiLang

The programming language itself.

AiLang focuses on deterministic behavior, explicit structure, and AI-friendly source code.

AiVM

The virtual machine responsible for executing AiLang applications.

A core design goal is keeping execution behavior consistent across platforms.

AiVectra

A vector-based UI framework used to build graphical applications.

AiVectra is designed to provide a consistent UI model across native and web environments.

Together, these components form a complete stack:

Language → VM → UI

What This Milestone Validates

Building and running the weather application validated several major pieces of the system.

Module Composition

The application is split across multiple files and modules rather than being a single monolithic source file.

This exercises the import/export system and package structure that future applications will depend on.

Standard Library Growth

The application relies heavily on common functionality:

String handling
Collections
HTTP communication
Data processing

These are the foundations every future application will build upon.

Cross-Platform Execution

Perhaps the most satisfying result was seeing the same application logic run on:

Native macOS
Browser/WebAssembly

without rewriting the application itself.

The runtime profile changes.

The application code does not.

UI Framework Integration

This also serves as an integration test between AiLang, AiVM, and AiVectra.

The language, runtime, and UI framework are no longer evolving independently—they are beginning to function as a cohesive ecosystem.

What Makes This Different?

Many modern frameworks pursue portability through increasingly complex abstractions.

AiLang takes a different approach.

The goal is not to hide platform differences behind layers of framework code.

The goal is to keep application semantics inside the language itself while allowing hosts to remain thin and replaceable.

In other words:

The language defines meaning.
The VM executes meaning.
The host provides capabilities.

This separation has been one of the guiding principles of the project from the beginning.

Still Early

This is not a production-ready application framework.

AiVectra is still young.

AiLang is still evolving.

AiVM continues to gain capabilities.

There is a substantial amount of work remaining.

But software projects are built one milestone at a time.

A year ago, AiLang was largely specifications, prototypes, and architectural discussions.

Today, it is running a complete application across native and web targets.

That's meaningful progress.

What's Next?

The weather application is only the beginning.

The next milestones include:

Additional sample applications
Expanded standard libraries
Improved tooling
More runtime profiles
Continued growth of AiVectra
Further self-hosting within the ecosystem

The long-term goal remains the same:

Build a deterministic, AI-native software platform where the language itself is the source of truth.

Links

Project Website: https://ailang.codes

GitHub Organization: https://github.com/AiLangCore

AiLang, AiVM, and AiVectra are open-source and actively evolving.

Garbage Collection vs Deterministic Memory Regions in AiVM

Todd Henderson — Fri, 22 May 2026 02:51:30 +0000

Modern managed runtimes such as the JVM, CLR, Mono SGen, Go, and JavaScript engines rely heavily on sophisticated garbage collectors. These systems are optimized for large, long-running shared heaps with highly dynamic allocation patterns.

AiVM is taking a different path.

Rather than building a traditional “fully managed” runtime with increasingly complex concurrent garbage collectors, AiVM is moving toward a model based on:

deterministic memory regions
explicit lifetime boundaries
worker-local heaps
immutable message passing
safe-point compaction
bounded resource behavior

This document explains both approaches, their tradeoffs, and why AiVM is intentionally choosing a different direction.

Traditional Garbage Collection

The Goal

Traditional garbage collectors attempt to automatically reclaim memory that is no longer reachable by the application.

The runtime tracks references between objects and periodically identifies memory that can be freed.

Most modern systems use some variation of:

mark-sweep
mark-compact
generational collection
concurrent/incremental collection

Mark-Sweep Collection

The classic tracing collector works in two phases:

Mark all reachable objects
Sweep unreachable objects

Flow Diagram

                ┌────────────────────┐
                │   Heap Objects     │
                └─────────┬──────────┘
                          │
                          ▼
                ┌────────────────────┐
                │ Root Traversal     │
                │ (stack/globals)    │
                └─────────┬──────────┘
                          │
                          ▼
                ┌────────────────────┐
                │ Mark Reachable     │
                │ Objects            │
                └─────────┬──────────┘
                          │
                          ▼
                ┌────────────────────┐
                │ Sweep Unmarked     │
                │ Objects            │
                └─────────┬──────────┘
                          │
                          ▼
                ┌────────────────────┐
                │ Free Memory Holes  │
                └────────────────────┘

Advantages

Conceptually simple
Handles arbitrary object graphs
Automatic reclamation

Problems

Fragmentation

After repeated allocations and frees:

[A][_][C][_][E][_][G]

Memory becomes fragmented into holes.

Large allocations may fail even when total free memory exists.

Stop-The-World Pauses

Applications are often paused during collection.

Poor Locality

Live objects become scattered through memory.

Mark-Sweep-Compact

To solve fragmentation, compacting collectors move live objects together.

Flow Diagram

Before Compaction:

[A][_][C][_][E][_][G]

After Compaction:

[A][C][E][G][_][_][_]

Advantages

Solves fragmentation
Better cache locality
Stable long-running heaps

Problems

Object Movement Complexity

Moving objects requires updating:

pointers
stack roots
object references
interior references
handles

Longer Pauses

Compaction is expensive.

Runtime Complexity

The runtime must coordinate relocation safely.

Generational Garbage Collection

Modern runtimes optimize around one observation:

Most objects die young.

The heap is divided into generations.

Flow Diagram

             ┌────────────────────┐
             │  New Allocation    │
             └─────────┬──────────┘
                       │
                       ▼
             ┌────────────────────┐
             │ Young Generation   │
             │   (Nursery)        │
             └─────────┬──────────┘
                       │
                Minor Collection
                       │
        ┌──────────────┴──────────────┐
        │                             │
        ▼                             ▼
┌────────────────────┐   ┌────────────────────┐
│ Dead Objects Freed │   │ Survivors Promoted │
└────────────────────┘   └─────────┬──────────┘
                                    │
                                    ▼
                         ┌────────────────────┐
                         │ Old Generation     │
                         └─────────┬──────────┘
                                   │
                           Major Collection

Advantages

Excellent throughput
Fast allocation
Efficient for large applications

Problems

Massive Complexity

Requires:

promotion logic
write barriers
remembered sets
cross-generation tracking
moving collectors
concurrent synchronization

Reduced Determinism

Collection timing becomes heuristic-driven.

Shared Heap Coordination

Multiple threads must cooperate with the collector.

Concurrent / Low-Latency Collectors

Modern runtimes such as:

G1
ZGC
Shenandoah
CMS

attempt to reduce pauses by performing GC concurrently with application threads.

Flow Diagram

Application Threads
        │
        ├── Continue Running
        │
        ▼
Concurrent GC Threads
        │
        ├── Background Marking
        ├── Incremental Relocation
        ├── Barrier Tracking
        └── Heap Coordination

Advantages

Extremely low pauses
Large heaps
Better UI/server responsiveness

Problems

Extreme Runtime Complexity

Requires:

read barriers
write barriers
synchronization protocols
relocation safety
concurrent root scanning
race handling

Higher CPU Overhead

GC becomes part of normal runtime execution.

Harder Debugging

Behavior becomes timing-sensitive.

Why AiVM Is Taking a Different Direction

AiVM is not trying to become:

a desktop CLR replacement
a JVM clone
a general-purpose OS runtime
a giant adaptive managed heap

Instead, AiVM is optimized for:

deterministic execution
bounded resource behavior
portability
AI-generated code stability
cross-platform reproducibility
explicit architectural ownership
worker isolation
predictable runtime behavior

These goals change the memory strategy entirely.

The AiVM Direction: Deterministic Memory Regions

Rather than relying on runtime heuristics to decide object lifetimes, AiVM uses explicit lifetime regions.

Core Idea

Data survives only when it crosses explicit deterministic boundaries.

Flow Diagram

             ┌────────────────────┐
             │ Parse / Eval Work  │
             └─────────┬──────────┘
                       │
                       ▼
            ┌──────────────────────┐
            │ Scratch / Temp       │
            │ Region               │
            └─────────┬────────────┘
                      │
            Explicit Safe-Point Boundary
                      │
        ┌─────────────┴─────────────┐
        │                           │
        ▼                           ▼
┌────────────────────┐   ┌──────────────────────────┐
│ Temporary Data     │   │ Explicitly Promoted Data │
│ Destroyed/Reset    │   │ Survives Boundary        │
└────────────────────┘   └──────────┬───────────────┘
                                     │
                                     ▼
                         ┌──────────────────────────┐
                         │ Long-Lived Region        │
                         │ Module / Session / Blob  │
                         └──────────┬───────────────┘
                                    │
                         Explicit Release / Dispose
                                    │
                                    ▼
                         ┌──────────────────────────┐
                         │ Region Reset / Cleanup   │
                         └──────────────────────────┘

Deterministic Safe Points

AiVM cleanup and compaction occur only at explicit boundaries:

parse complete
module publish
worker completion
message freeze
task join
app shutdown
explicit runtime reset

No hidden background collector.

No heuristic object aging.

No concurrent relocation.

Worker-Local Heaps

AiVM concurrency is based on isolation.

Flow Diagram

Worker A ── Local Heap ─┐
                        │
Worker B ── Local Heap ─┼──► Deterministic Queue
                        │
Worker C ── Local Heap ─┘
                                  │
                                  ▼
                       UI / Semantic Thread
                           Applies Changes

Workers:

perform background computation
allocate local temporary memory
cannot mutate semantic/UI state directly

All observable state changes occur through deterministic queue dispatch.

Why This Fits AiVectra

AiVectra requires:

one UI/semantic thread
background workers
deterministic event ordering
cross-platform consistency
mobile-friendly execution

Traditional shared mutable heaps complicate:

iOS threading
Android UI safety
deterministic rendering
replay/testing
portable behavior

AiVM’s direction keeps UI semantics simple:

Workers do work.
UI thread applies deterministic results.

Resource-Bounded Execution

AiVM is also introducing deterministic cumulative resource accounting:

network bytes
blob memory
arena usage
worker counts
queue depth
file I/O
execution budgets

This supports:

sandboxing
mobile execution
reproducibility
AI agent safety
predictable hosting

Why Not Full Concurrent GC?

AiVM may eventually evolve toward more advanced memory management.

But before beta, the project is prioritizing:

simplicity
correctness
deterministic behavior
bounded execution
explicit ownership
predictable debugging

The current roadmap intentionally delays:

fully generational GC
concurrent tracing collectors
moving shared heaps
runtime heuristic aging

until after the core runtime architecture stabilizes.

The Key Philosophical Difference

Traditional runtimes optimize for:

huge shared dynamic heaps

AiVM optimizes for:

deterministic lifetime regions
isolated workers
explicit boundaries
message passing
bounded resources

That dramatically reduces how much garbage collection complexity is actually required.

Conclusion

Traditional garbage collectors are extraordinary engineering achievements. They power modern browsers, enterprise servers, mobile runtimes, and massive applications.

But they solve a different problem.

AiVM is intentionally optimizing for:

deterministic execution
AI-generated code reliability
bounded runtime behavior
portable semantics
explicit architectural ownership
reproducible cross-platform execution

For those goals, deterministic memory regions and safe-point cleanup are currently a better fit than large concurrent tracing collectors.

The result is a runtime architecture that is:

simpler
more predictable
easier to reason about
easier to sandbox
easier to port
easier to make deterministic

while still supporting real multithreaded production workloads through isolated workers and deterministic message passing.

Learn More

To learn more about the AiLangCore ecosystem and follow development:

AiLangCore is actively evolving in the open, with ongoing work focused on deterministic execution, AI-oriented tooling, bounded resource behavior, portable runtime architecture, and vector-first cross-platform UI development.

AiLang: Exploring Deterministic AI-First Programming with Gemma 4

Todd Henderson — Fri, 22 May 2026 02:24:14 +0000

AiLang: Exploring Deterministic AI-First Programming with Gemma 4

What I Built

AiLang — A Deterministic AI-First Programming Language Ecosystem

https://ailang.codes

https://github.com/AiLangCore

AiLang is an experimental AI-first programming language ecosystem focused on deterministic execution, canonical structure, and spec-governed semantics.

The ecosystem currently includes:

AiLang — the language and SDK
AiVM — a deterministic virtual machine/runtime
AiVectra — a cross-platform UI framework

The project explores an important question:

What would a programming language look like if it were designed specifically for AI-assisted development and autonomous agents?

Most existing languages evolved around human-centric workflows and increasingly complex runtime behavior. AiLang instead prioritizes:

deterministic execution
canonical formatting
structured syntax
reproducible builds
thin replaceable runtimes
AI-oriented tooling workflows

The host runtime intentionally remains mechanical and replaceable, while semantic authority lives entirely inside the language specification itself.

The project originally started while evaluating AI-assisted software development tools for a client project. That experimentation eventually evolved into a much larger exploration of deterministic systems and AI-native software architecture.

Demo

Website

https://ailang.codes

GitHub Repositories

Example AiLang Program

Program#p1 {
  Export#e1(name=start)

  Let#l1(name=start) {
    Fn#f1(params=args) {
      Block#b1 {
        Call#c1(target=sys.stdout.writeLine) {
          Lit#s1(value="Hello from AiLang")
        }

        Return#r1 {
          Lit#i1(value=0)
        }
      }
    }
  }
}

Current Areas of Development

Deterministic execution
Canonical formatting
AI-assisted tooling workflows
Runtime portability
NativeAOT experimentation
Standard library expansion
Multi-agent orchestration concepts

Code

GitHub

https://github.com/AiLangCore

Primary repositories:

How I Used Gemma 4

Gemma 4 was used throughout development as part of the broader AI-assisted workflow surrounding the AiLang ecosystem.

The project itself explores deterministic architectures for AI-assisted software engineering, so using modern language models during development became a natural part of the experimentation process.

I primarily focused on AI-assisted:

architecture exploration
implementation iteration
parser experimentation
runtime design discussions
documentation generation
specification refinement
testing strategies
developer workflow analysis

One of the core ideas behind AiLang is that existing programming languages were largely designed around human-first workflows rather than autonomous or collaborative AI systems.

Working alongside modern AI models while developing AiLang helped reinforce several architectural priorities:

deterministic behavior
canonical formatting
structured syntax
explicit semantics
reproducibility
reduced ambiguity for tooling

For this project, the larger-context capabilities of modern models were especially valuable when reasoning about:

multi-repository architecture
runtime boundaries
language semantics
deterministic VM behavior
long-term ecosystem structure

Rather than replacing engineering decisions, AI tooling acted as an accelerator for experimentation and iteration while the core architectural constraints and deterministic guarantees remained specification-driven.

AiLang: An AI-First Language Focused on Deterministic Execution

Todd Henderson — Fri, 22 May 2026 02:20:31 +0000

AiLang — GitHub Finish-Up-A-Thon Challenge Submission

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

AiLang — A Deterministic AI-First Programming Language

AiLang Website: https://ailang.codes

AiLangCore GitHub Organization: https://github.com/AiLangCore

AiLang is an experimental AI-first programming language ecosystem focused on deterministic execution, canonical structure, and spec-governed semantics.

The project currently consists of three major components:

AiLang — the language, compiler, and SDK
AiVM — a deterministic virtual machine/runtime
AiVectra — a cross-platform UI framework

Unlike many modern platforms where behavior is partially defined by the runtime or host platform, AiLang keeps semantic authority inside the language specification itself. The host runtime is intentionally thin, mechanical, and replaceable.

The goal is to explore what programming languages and tooling could look like when designed specifically for:

autonomous AI agents
reproducible builds
deterministic execution
canonical formatting
multi-agent development workflows

This project started as a collection of experiments around deterministic execution and AI-assisted development, but evolved into a much larger ecosystem focused on AI-native software engineering.

Demo

Website

https://ailang.codes

GitHub Repositories

Example AiLang Program

Program#p1 {
  Export#e1(name=start)

  Let#l1(name=start) {
    Fn#f1(params=args) {
      Block#b1 {
        Call#c1(target=sys.stdout.writeLine) {
          Lit#s1(value="Hello from AiLang")
        }

        Return#r1 {
          Lit#i1(value=0)
        }
      }
    }
  }
}

Current Focus Areas

Deterministic VM execution
Canonical formatting
Spec-governed semantics
AI-oriented tooling
Multi-file module support
Standard library expansion
NativeAOT runtime work
Future C-based VM portability

The Comeback Story

This project originally began while I was working for a client evaluating AI tools for software development workflows. During that process, I became increasingly interested in the limitations current programming languages present for AI-assisted development, deterministic execution, and autonomous tooling. What started as a small experimental language project gradually evolved into the broader AiLang ecosystem.

Over time, the scope grew into a complete ecosystem:

language
VM/runtime
tooling
UI framework
package system concepts
AI-agent workflows

Like many long-running side projects, parts of the architecture evolved organically and needed substantial cleanup and stabilization before they could realistically move toward public adoption.

For this challenge, I focused heavily on:

improving architectural consistency
refining deterministic execution guarantees
cleaning up repository structure
improving documentation
strengthening the specification-first workflow
hardening VM resource limit handling
improving the overall developer onboarding experience

One major focus was reinforcing a core design principle:

The language defines behavior — not the runtime.

That required revisiting assumptions across the compiler, VM, syscall boundaries, and tooling to ensure the ecosystem remained deterministic and spec-governed.

This challenge helped push the project from “experimental internal architecture work” toward something that is becoming increasingly usable and explainable to outside developers.

My Experience with GitHub Copilot

GitHub Copilot became an extremely valuable accelerator during development, especially while working across multiple repositories and architectural layers simultaneously.

Where it helped the most:

scaffolding repetitive infrastructure
generating test boilerplate
helping iterate on parser/runtime ideas
exploring alternative implementations
accelerating documentation work
reducing friction while refactoring

The biggest benefit was not replacing architectural thinking, but reducing the mechanical overhead around experimentation.

Because AiLang emphasizes deterministic behavior and specification-driven development, I still had to carefully validate generated code against the project’s architectural constraints and invariants.

In many ways, the project itself explores a question closely related to tools like Copilot:

What would a programming language look like if it were designed from the beginning for AI-assisted development?

That exploration became one of the driving motivations behind the entire AiLang ecosystem.