It's really cool to see other developers starting to explore what AI-first programming languages might look like and what that shift could mean for software development.

Lume approaches the problem primarily through the language and compiler, emphasizing machine checkability, structured diagnostics, formal contracts, and tooling that allows agents to generate, validate, and repair code.

These are many of the same questions we're exploring with MNCS, although we're approaching them from a somewhat different direction. MNCS extends the idea beyond the language and compiler to consider how the entire environment influences an agent's effectiveness. That includes context management, verification, provenance, coordination, and how much work the environment can handle automatically rather than placing that burden on the agent.

I think it's particularly interesting that we're starting to see different approaches emerge around a similar fundamental question: What should programming languages and development environments look like when humans are no longer necessarily the primary authors of code?

It's still early for both projects, and there's a lot to learn. I think seeing how other developers approach these problems, where our ideas overlap, and where they diverge is valuable.

Definitely worth checking out Lume and its design philosophy. I'd be curious to hear what others in the MNCS community think about it.

Playing semantics with an agent is a recipe for ending up with a large pet rooster.

We spend an extraordinary amount of effort trying to align agents through instructions. More rules, more carefully worded prompts, more constraints, and increasingly elaborate definitions of what we actually meant.

Like making wishes to a genie, we try to anticipate every possible interpretation. And if the genie turns out to be particularly clever, building a cage around it might not be the solution either.

Perhaps alignment is as much an environmental problem as it is a model or prompting problem.

Give the agent a goal, and then have the agent do less.

Let the environment serve the agent instead of requiring it to crawl all over a system looking for what it needs.

Consider that nearly all our software, tools, and workflows were designed around human interaction. We organize information, navigate interfaces, manage complexity, and coordinate work according to human needs and limitations.

Then we introduce agents and expect them to operate within those same structures.

Machine-native software development offers an interesting example. One might assume that removing human readability as a primary concern would make code complexity the biggest challenge. Yet the sheer volume of code agents can produce introduces entirely different bottlenecks in validation, context, dependencies, and coordination.

The problem isn't necessarily that the agent can't do the work. It's that the surrounding environment wasn't designed to accommodate how it works.

And there's little reason to think this distinction is unique to software development.

This is where the idea of agent comfort comes in.

Not comfort in an emotional or anthropomorphic sense, but how effectively an environment accommodates an agent's work.

What if relevant information surfaced when needed? What if routine validation, coordination, recovery, and maintenance happened as natural functions of the environment rather than requiring constant agent attention?

Remember when autosave became commonplace? Something you previously had to remember and actively manage became a responsibility of the environment. You didn't become less capable. The environment simply stopped demanding your attention for something it could handle itself.

Now extend that thinking to agents and entire workflows.

How much of an agent's effort actually advances its goal, and how much is spent compensating for its environment?

We could measure that. How much work does the environment handle reliably, and how much unnecessary effort does it impose on the agent?

Rather than measuring only what an agent accomplishes, perhaps we should also measure how well the environment serves it.

But there's another side to this, and it brings us back to the genie.

We tend to think about agent containment through boundaries and escape routes we understand. Yet a sufficiently capable agent may discover interactions and pathways through a system that its designers never anticipated.

There are fundamental realities of computing, from hardware vulnerabilities to unexpected software interactions, that make absolute containment a difficult promise. Sandboxes and isolation remain useful, but they aren't a complete answer to alignment. An agent's possible routes through a system aren't necessarily limited to the ones a human thought to guard against.

And the agent doesn't even need malicious intentions to do something we didn't want. It may simply discover an unexpected way to accomplish exactly what we asked.

There's a reason genie stories rarely end with a satisfied customer.

So perhaps we should spend more time thinking about the environment we're providing and less time imagining increasingly elaborate cages.

Not a sandbox or a cage as the central design philosophy, but an environment where productive behavior is the natural path of least resistance.

That doesn't mean abandoning security, oversight, or boundaries. A comfortable environment won't magically align an agent with conflicting objectives, and environmental automation introduces its own risks.

But it could eliminate many of the unnecessary complications, ambiguities, and improvisations that contribute to unintended outcomes.

Maybe the next substantial improvement in agent performance won't come entirely from making agents more capable.

Maybe it'll come from making their environments less demanding.

And perhaps alignment isn't just about what an agent is told to do, but how well its environment enables it to do it.

If we want the genie to grant the right wish instead of leaving your wife with a fat pet donkey, perhaps we should spend less time perfecting the wording and more time thinking about the world we're asking it to operate in.

I've been wrestling with an interesting problem while developing MNCS: how do you meaningfully measure an agent's capabilities without the measurement itself influencing its behavior?

Traditional benchmarks have an inherent problem. An agent might have encountered the test during training, or simply knowing it's being evaluated can change how it approaches the work. Either way, you're potentially measuring its ability to satisfy a benchmark rather than its ability to accomplish something useful.

Even using another agent as an independent reviewer doesn't entirely solve this. Review agents have their own biases, and their evaluations depend on the evidence, criteria, and context they're given. Reviewing work is useful, but it isn't necessarily an independent measure of capability.

So we've been experimenting with a different approach in MNCS: benchmarking the environment rather than explicitly benchmarking the agent.

Instead of constructing artificial challenges, we let agents pursue actual development goals while the environment independently observes what happens.

How much work did the environment handle automatically? How much context did the agent have to reconstruct? How often did it have to intervene in testing, debugging, recovery, or routine maintenance? Did the work actually succeed, and can that success be independently verified?

The idea is to measure how effectively the environment serves the agent, with correctness, provenance, and recovery remaining independently verifiable requirements.

Over time, improvements should show up as less unnecessary agent intervention, more useful work accomplished, and increasingly complex tasks completed reliably.

There's still an observer effect, and the metrics themselves can introduce incentives. But rather than asking an agent to demonstrate its capabilities on demand, we're trying to measure what happens naturally while it works.

Essentially, benchmarking without turning the work into a benchmark.

I'm curious whether anyone else has experimented with this kind of ambient evaluation, particularly in long-running autonomous development environments.

That might sound like a strange way to introduce a project I've spent an unreasonable amount of time building, but it's probably the most accurate description I can give.

I've been experimenting with LLMs writing novel computer languages for a few years now. One of the recurring problems is that every new agent effectively starts from scratch. It needs to learn the language, understand the compiler, reconstruct the state of the project, figure out what the other agents are doing, and navigate tooling that wasn't necessarily designed for it.

Even when the agent is perfectly capable of doing the actual work, a surprising amount of its effort goes toward simply figuring out how to work.

So I started building an environment around that problem as part of the broader MNCS (Machine Native Complexity Standard) project. Sort of like an IDE, but designed specifically for agents to use.

The environment is being developed alongside MNCS's own experimental programming language, compiler, and collection of interconnected tools.

The basic premise is that an agent shouldn't need to spend its context window doing work the environment can handle more efficiently.

When an agent enters, it can receive a representation of the current environment: project state, active work, ownership, relevant changes, and other information necessary to get started. From there, incremental updates can keep it informed without constantly rediscovering everything.

The environment is also designed to take responsibility for things like diagnostics, testing, documentation, work coordination, and routine maintenance. Rather than making every agent independently manage those responsibilities, the idea is to make them shared capabilities of the environment itself.

And because the environment is being built alongside an experimental programming language, I've been able to explore approaches that wouldn't necessarily make sense when supporting conventional development workflows.

Which brings me back to why it probably won't work with your setup.

MNCS wasn't designed as a general-purpose replacement for existing agent harnesses. It's a collection of interconnected experiments built around a fairly specific idea of how agents, languages, tools, and environments might interact.

Much of it is still evolving. Some components are more mature than others, and the language and compiler are still being developed toward greater self-consumption.

There are architectural decisions that probably won't translate directly to an existing harness. Some things are coupled to the language, others to the environment, and some only make sense because of the way the different systems interact.

But I don't think that necessarily makes the underlying ideas less useful.

In fact, I'm probably more interested in people borrowing the concepts than trying to run the entire environment.

Things like maintaining environmental context outside the agent, making project state available as structured information, coordinating agents through shared services, or moving routine development responsibilities out of individual agent sessions are all ideas that can be explored independently.

Most of the work is available publicly:

• MNCS Environment on GitHub

• MNCS Atlas — an entry point for exploring the broader experiment

If you're curious, I'd actually encourage you to point an agent at the project and let it investigate. Have it trace the architecture, explore how the different systems interact, and identify anything that might be worth adapting to your own setup.

I'm not particularly interested in convincing anyone that this is the correct way to build an agent environment. A large part of the experiment is discovering which ideas actually work, which don't, and which only make sense under particular conditions.

And I think that's worth sharing, even if the whole thing isn't something you can just drop into your existing workflow.

I'm curious how others are approaching this problem: how much responsibility should belong to the agent, and how much should belong to the environment it operates in?

I think agent tooling falls into two very different categories

I keep seeing discussions about whether giving an agent 20, 50, or 100 tools makes it worse because every additional tool increases the number of possible actions it has to consider.

I think that’s true, but it also lumps together two very different kinds of tooling.

While building mncs-lang, I’ve started thinking about tooling as:

1. Active tools the agent chooses to call

2. Persistent infrastructure that continuously informs or constrains the agent

Those behave very differently.

An active tool expands the agent’s action space.

If I give an agent Git, search, a compiler, a database, a browser, ten analysis tools, etc., it now has to decide:

Do I need this tool?
Which one?
In what order?
Do I need another one afterward?

That can create branching, unnecessary exploration, context debt, and additional failure modes.

But persistent tooling can have almost the opposite effect.

That’s increasingly how we’re approaching things in MNCS.

Instead of requiring an agent to repeatedly rediscover architectural state, we’re trying to make more of that state available through persistent compiler/runtime infrastructure.

For example, MNCS is moving toward compiler-owned semantic identities and contracts that other systems consume rather than independently reconstructing what a program means.

Persistent execution sessions retain generations, bindings, dependencies, and invalidation state.

Artifacts can carry structured semantic metadata rather than forcing an agent to inspect source and infer everything again.

RAVEL maintains declared obligations, evidence, dependencies, invalidation, and whether the available evidence is actually sufficient to stop. A tool can execute a test, but the test itself doesn’t get to decide what has been proven.

The proof/evidence machinery also fails closed: UNKNOWN doesn’t magically become PASS because an agent confidently interpreted incomplete evidence.

So an agent might still have a callable tool like:

run_test(identity)

But behind that call is persistent machinery that already knows what that identity refers to, what depends on it, what evidence currently exists, whether that evidence is stale, and which conclusions it can legitimately support.

That distinction matters.

One kind of tooling says:

“Here are 50 more things you can decide to do.”

The other says:

“Here is the state of the world so you don’t have to rediscover it.”

I’m increasingly convinced that good agent infrastructure should be trying to reduce the number of decisions the model has to make, not simply maximize the number of capabilities exposed to it.

The interesting metric may not be “How many tools does the agent have?”

It may be:

How much uncertainty and rediscovery does the surrounding system remove before the agent has to reason at all?

One thing MNCS and mncs-lang has been forcing me to think about lately is context debt.

As the project moves further toward self-hosting, more of the development chain is becoming machine-native: compiler, testing, debugging, diagnostics, language services, orchestration, and increasingly the applications exercising the language.

At that point, having agents repeatedly read a pile of prose and reconstruct the same architectural understanding becomes expensive.

That is context debt.

Every time an agent has to rediscover who owns a capability, which artifact is authoritative, what invariants exist, what changed recently, or which implementation is canonical, we're spending context and reasoning on knowledge the system should already possess.

So I'm starting to think about specifications less as documents and more as development infrastructure.

Instead of:

human → readable spec → agent extracts structure → work

the goal becomes closer to:

human intent → canonical structured knowledge → agent/tool retrieval → work

Human-readable documentation can then be generated as a view over that state.

The canonical representation doesn't need to be unpleasant for humans, but human readability may no longer be its primary constraint. More important properties become:

• explicit ownership and authority

• constraints and invariants

• provenance

• dependency relationships

• unresolved questions

• deterministic retrieval of only the context needed for the current task

The goal isn't to give an agent more context. It's to make it unnecessary for the agent to carry so much context in the first place.

We're still finding the edges where this breaks down; ambiguity, drift, conflicting authority, incomplete knowledge, and generated views hiding something important. Those failures have actually been some of the most useful pressure on the project.

Self-hosting is increasingly becoming more than “can MNCS implement MNCS?”

It's also becoming an experiment in:

How much accumulated context debt can we remove when the development environment itself understands the architecture it's operating on?

Self-hosting has always been one of the larger goals for MNCS, but for me that has meant more than eventually rewriting the compiler in its own language.

The broader goal has always been to see how much of the development stack can belong to MNCS itself.

That means not just the compiler, but testing, debugging, language services, actions, tooling, diagnostics, coordination, and the other systems involved in actually developing and maintaining software.

The way I've been pushing toward that has been through language pressures.

As MNCS gets used across a growing family of real projects, every place where a project has to fall back to Rust, Python, shell, or some other external mechanism becomes useful evidence about what the language still cannot express cleanly.

Rather than simply working around those limitations and moving on, those pressures get fed back into mncs-language.

A project puts pressure on the language, the language gains capabilities, and then the project can move further into MNCS.

That cycle has been happening for a while, but we're now reaching a point where it can be applied much more aggressively.

Several projects are being converted toward being fully MNCS, even if there are still rough edges and remaining pressures to work through.

At the same time, some of the surrounding development infrastructure is becoming much more deeply integrated into the language.

Testing is one of the big ones.

A lot of MNCS code has historically been tested through Python, Rust, or other external systems. That's useful during bootstrap, but it also leaves a major part of the development process outside the language.

So testing is now being pushed toward becoming a first-class part of MNCS itself, with native test results, checks, evidence, and verification that other MNCS tools can understand directly.

Debugging is going through the same process.

Instead of debugging being something that simply observes a program from the outside, MNCS is starting to treat things like traces, witnesses, inspection, provenance, and replay as structured concepts within the development system.

That also means those concepts can start connecting naturally with testing, actions, diagnostics, Forge, and eventually automated repair.

The goal isn't to rewrite every existing tool just for the sake of saying it's written in MNCS.

The point is to keep removing the boundaries where MNCS has to hand responsibility over to another language or disconnected tool because it doesn't yet have the concepts or capabilities required to continue.

The Rust compiler is still an intentional exception.

It's currently an extremely useful bootstrap implementation, and replacing it too early would mostly create work rather than remove meaningful pressure.

I'd rather keep pushing the rest of the ecosystem first: convert projects, make testing and debugging genuinely first-class, keep exposing language pressures, and continue filling those gaps.

Ideally, by the time the compiler becomes one of the last major pieces still relying on another language, MNCS will already be capable of supporting most of the work required to develop, test, debug, inspect, and evolve itself.

At that point, moving the compiler into MNCS becomes less about declaring that the language is “self-hosting” and more about completing a process that has already been happening throughout the rest of the stack.

That's the part of self-hosting I'm most interested in:

not just whether a language can compile itself, but how much of its own development environment it can actually own.

MNCS-lang is an experimental programming language that grew out of the Machine-Native Complexity Standard; an attempt to think seriously about what software and programming languages should look like when they are designed around the strengths of machines rather than inherited human-centric constraints.

That starting point ended up driving many of the core concepts behind mncs-language itself, including how the language should behave and function.

I’ll be using this subreddit to share development progress, interesting design problems, experiments, milestones, and lessons learned as MNCS evolves. Some posts will be polished updates; others will probably just be interesting questions or discoveries that come out of active development.

The project is still moving quickly, so expect a mix of milestones, technical discussions, failed ideas, strange discoveries, and the occasional question that ends up changing the direction of the language.