If today’s strongest AI systems are becoming extraordinary engineers and researchers as claimed, their best demonstrations should tackle problems worth solving and expand what we know how to build.

Fable 5.1 vs. GPT-6 Astra

The models impressed me more than the demonstrations did

Last week (i.e., early September 2026) might feel like a festival to many AI enthusiasts. Anthropic released Fable 5.1 and OpenAI began rolling out GPT-6 Astra. Both releases were framed around difficult work: coding, research, computer use, and long-running professional tasks. The release materials from Anthropic and OpenAI made a large capability claim, and the public response supplied a familiar kind of evidence almost immediately. The releases themselves also point toward more consequential work: Anthropic reports a higher-resolution map of part of Venus and GPU-kernel optimizations for biology models, while OpenAI emphasizes software engineering, science, and cybersecurity evaluations. Those claims deserve artifact-level scrutiny, but they are closer to the kind of demonstration I want to see.

Someone asked Fable to make Minecraft. Someone else asked Astra for a GTA-like city. Timelines filled with first-person views, procedural terrain, buildings, vehicles, inventories, weapons, and the kind of small interface details that make a prototype feel like a game rather than a code sample. I enjoyed watching them. They are good demonstrations of how far autonomous generation has come. I was also left wondering why we were giving some of the strongest models we have built problems whose solutions we already know, and whose importance usually disappears once the video ends.

That reaction is not a complaint about games. A model that can turn a short brief into a coherent interactive application is doing many difficult things at once. It has to decompose a request, select tools, write code across several subsystems, run the result, inspect visual output, diagnose failures, and preserve enough state to continue. The result may include rendering, physics, input handling, procedural content, asset loading, user interface, and deployment. A working game is real evidence of capability.

The question is what the evidence supports. If the claim is that a model can synthesize surprisingly sophisticated software quickly, a playable voxel world is persuasive. If the surrounding claim is that the model is an extraordinary engineer, a researcher, or a system that can change the economics of technical work, the burden is larger. The demo must reveal more than a pleasing output. It should tell us whether the system can make an important project possible, improve on the strongest practical approach, or give experts an idea they would not have reached on their own.

That is the standard I want for frontier demonstrations. A strong frontier-AI demonstration should still look like worthwhile work if you remove the model’s name from the headline. The model’s role should make the result more surprising, not supply its value.

A Minecraft clone tests a familiar kind of competence

A good game-generation demo tests whether a model can coordinate a large collection of established techniques into a working artifact. The answer now appears to be yes with increasing frequency. The model may know how voxel engines divide terrain into chunks, how a first-person controller performs collision checks, how procedural noise produces varied geometry, and how a browser or game engine connects all of this to a render loop. It can fill in the connective code that used to keep a prototype from becoming playable.

That is a substantial change in the cost of prototyping. A developer with a game idea can get to a testable interaction quickly, and a small studio can explore more concepts before committing to a production plan. OpenAI’s write-up on building games with Astra is a useful example of this direction: the author describes a game whose universe, terrain, rendering, tests, and authored assets were developed through an agentic loop. Public Fable videos show a similar ability in a more compressed form, including a Minecraft-style build from a short prompt.

The visual result is also easy to evaluate at a glance. Someone who is not a game developer can tell whether the world resembles Minecraft, whether the character moves, whether a block can be placed, and whether the scene is entertaining enough to share. That accessibility is part of why these demos travel so well.

It is also a limit. The same viewer cannot reliably infer the architecture behind the footage. Two repositories can produce an equally convincing minute of video while differing in memory behavior, rendering strategy, test coverage, extensibility, networking readiness, and the amount of manual repair hidden between prompts. A game can look complete while containing a pile of special cases that make the next feature painful. It can also work in one browser tab and fail under a second player, a large world, a slow device, or an interrupted save.

The solution space is familiar too. Voxel terrain, chunk streaming, inventory models, collision systems, day-night cycles, and browser rendering have been discussed and implemented many times. There are open-source clones, tutorials, engine examples, mods, and technical explanations for nearly every subsystem. This does not imply that a model copied a particular repository, and it does not diminish the engineering involved in making the pieces work together. It does mean that a Minecraft-like request sits inside a problem family with a dense library of known patterns. The model is being asked to select and integrate established moves more often than it is being asked to invent a new one.

The last limitation is the easiest to overlook. What problem is the project solving for anyone other than the person running the demonstration? In many cases the answer is: it is testing whether the model can build a convincing game clone. That is a legitimate evaluation target. It tells us about synthesis, integration, and speed. The clone itself usually has no user waiting for it, no operational failure it needs to prevent, and no cost that has made the project impractical. The project exists mainly to reveal the model.

A game demo can therefore be impressive and informative while still carrying little independent significance. The distinction matters because a polished artifact invites a larger interpretation than it can support. These weaknesses do not make the demonstrations useless. They make them insufficient evidence for claims about frontier engineering or research.

Stronger models need stronger counterfactuals

For an early coding agent, a natural comparison was an ordinary programmer working alone. If the agent could complete a task in minutes that would take that programmer an afternoon, the result was easy to understand. As models improve, that comparison becomes less useful. A serious team does not choose the weakest available process as its alternative. It uses specialists, existing tools, prior systems, and human-AI workflows that have already been refined.

For a particular task, I think about the practical baseline as:

$$ B = \max\left( \text{best relevant humans}, \text{best previous AI}, \text{best existing human-AI workflow} \right) $$

This is conceptual shorthand, not a universal score. It asks us to compare a new model with the strongest credible way we already know to approach the same problem. A demonstration becomes more informative when the model changes the outcome relative to that baseline, rather than merely outperforming an imagined programmer with no useful tools.

There are three useful levels of demonstration:

flowchart LR
  A["Reproduction<br/>Build something known"] --> B["Expert compression<br/>Make difficult known work practical"] --> C["Frontier extension<br/>Change what is feasible or worth building"]

Reproduction shows that the model can assemble known techniques into a familiar target. Expert compression shows that it can do difficult, known work faster, cheaper, or with fewer people. Frontier extension asks whether the system can produce a result beyond the strongest practical baseline, or discover a useful direction that the baseline did not contain.

The levels are not a ranking of whether a project is fun or technically difficult. A game clone may be harder to build than an ordinary business application and still be a reproduction. A migration that follows a known plan may be less visually dramatic and more consequential because it changes the economics of work that teams have postponed for years.

A demonstration still needs a reason to exist

A good research proposal usually has to establish several things at once. The problem matters. Existing approaches leave a real gap. The proposed contribution is meaningful and plausibly new. The work could change what researchers or practitioners can do. The sentence “nobody has run this exact analysis before” is not enough, because novelty without a reason to care is thin. Importance without a credible contribution is equally incomplete.

Frontier-AI demonstrations deserve a similar structure.

I find it useful to separate demonstration value from problem value. A demonstration-centered project begins with a model, a convenient task, and an artifact that lets us infer something about the model. A problem-centered project begins with an unresolved need, gives that need to the model, and leaves us with evidence about both the problem and the system. The first is a valid capability probe. The second has a chance to matter after the release cycle ends.

1
2
3
4
5
6
7
8
9

model
  -> convenient task
  -> artifact
  -> inference about the model

important unresolved problem
  -> model
  -> useful result
  -> learning about the problem and the model

Start with a problem that matters

The answer can come from scientific value, safety, cost, reliability, maintainability, access, performance, or a bottleneck that prevents useful work. The test is simple: if a competent human team solved the problem without AI, would anyone still want the result? If the answer is no, the project may still be a fine capability probe, but it should be presented as one.

Ask for a contribution that is genuinely new

Newness does not require a wholly unprecedented theory. It might be a new mechanism, a better tradeoff, a newly practical workflow, an architecture that removes a long-standing burden, or an unexpected way to formulate the task. A model that translates a design faithfully can provide expert compression. A model that changes the design because it finds a better constraint is contributing something more.

Compare against the practical frontier

The comparison should include strong people, earlier systems, and existing ways of combining people with models. A result can be valuable without beating every human at every dimension. It should, however, make a credible difference in the part of the problem the demonstration is claiming to illuminate.

These dimensions should remain separate. An important problem can produce a modest contribution. A novel artifact can turn out to be useless. A frontier result can be difficult to evaluate because nobody knows the best architecture in advance. Keeping the criteria distinct makes the claim more honest and the experiment more useful.

There are also two ways for a model to contribute. The first is a known unmet need: something people have wanted to solve but could not solve satisfactorily. A large migration, a safer systems interface, or a compiler optimization that is too expensive to implement by hand fits this category. The second is a previously unrecognized need. Experts see an artifact or mechanism and realize that it solves a problem they had not formulated, or that it creates a useful possibility they had not considered. That contribution reaches back into problem selection. The best model may sometimes give us a better question before it gives us a better answer.

Bun surprised me because I expected the process to break

The example that moved my own expectations most was Jarred Sumner’s rewrite of Bun from Zig to Rust. The project matters before the model enters the story. Bun is a widely used JavaScript runtime, bundler, package manager, and test runner. Its Zig implementation had accumulated difficult memory-management problems at the boundary between manually managed memory and JavaScriptCore’s garbage-collected runtime. The Bun write-up lists use-after-free crashes, leaks, double frees, out-of-bounds access, and races among the bugs being fixed in the existing codebase.

The team had already invested in sanitizers, fuzzing, safety-checked builds, and end-to-end leak tests. A manual rewrite still looked unreasonable. The source describes 535,496 lines of Zig, excluding comments, and estimates that three engineers with full context would need about a year. A year spent on a rewrite would also defer feature work, compatibility fixes, and security work. The realistic alternative was to keep repairing the same class of stability problems.

Rust offered a different enforcement mechanism. Its ownership and cleanup rules can turn many use-after-free, double-free, and forgotten-cleanup cases into compiler errors. That does not solve every problem in Bun, especially where the new code crosses into C and C++ or carries assumptions inherited from the old architecture. It changes the cost of finding a meaningful class of defects. The migration therefore had a clear significance and a clear gap: the desired result was valuable, while the conventional path to it was economically difficult.

The experiment was not a magic prompt. Sumner spent time creating a PORTING.md guide that mapped Zig patterns to Rust patterns, and a workflow analyzed lifetimes and recorded them in LIFETIMES.tsv. A trial conversion of three files went through separate implementation and adversarial-review passes. The larger run used roughly 50 dynamic workflows in Claude Code, with as many as 64 Claude instances divided across four worktrees. The model used was a pre-release Fable 5, not the later Fable 5.1 release.

The process also failed in ordinary ways before it worked. Agents stepped on one another with git stash, git reset, and slow commands. The workflow had to be edited to establish stricter repository rules and then reshaped into four shards. The model translated files, worked through approximately 16,000 compiler errors, repaired crate dependencies, ran subcommands, and drove the test suite toward passing. Each unit of work could have an implementer, two separate adversarial reviewers, and a fixer. Sumner monitored the workflows, read their outputs, and changed the loops when the process produced bad behavior.

The feedback signal was unusually strong. Bun’s tests were written in TypeScript, so they could act as a language-independent behavioral oracle. On Debian 13 x64, the published table reports 1,386,826 expect() calls across 60,624 tests in 4,174 files. The suite could say that the Rust implementation behaved differently from the Zig implementation at a very large number of observable points. Compilation errors supplied another structured queue of failures. The loop looked roughly like this:

1
2
3
4
5
6

translate
  -> compile
  -> test
  -> adversarial review
  -> repair
  -> repeat

Bun reports that the entire test suite passed across its supported platforms in 11 days, at an approximate API cost of $165,000. The comparison is not “one prompt versus a year of humans.” It is one engineer designing and supervising a large verification-and-generation process against a counterfactual of several engineers spending a year on a migration that the team probably would not have undertaken. That is still an extraordinary change in practical economics.

This is where the case changed my prior. If I had designed the workflow from scratch, I would have wanted more explicit ownership rules, dependency tracking, context handoffs, and global-state management before allowing dozens of agents to edit a large repository. Those are sensible concerns. The surprising result was that a comparatively direct architecture, written specifications, worktree isolation, compiler feedback, tests, and adversarial review converged much further than I expected.

Scaffolding was the method. The model could use a written porting guide, a lifetime table, compiler diagnostics, tests, and review disagreement productively at a scale where I expected coordination overhead to dominate. A weaker system could still have generated a million-line-looking diff and failed to converge. The capability was visible in the use of feedback, not just in the volume of generated code.

The evidence also has boundaries. A passing behavioral suite does not prove that every unsafe boundary is sound. A translation can preserve old design problems while adding a language with better local guarantees. The migration needed human monitoring, CI, fuzzing, and continued repair. The fact that the workflow produced regressions or coordination failures would not invalidate the result; it would tell us where the process still needed engineering.

Bun is a stronger demonstration because the AI attribution is not what gives the project its value. A human team completing the same migration would have produced a meaningful result. The model changed the counterfactual by making work that had been postponed for economic reasons practical enough to attempt. That is expert compression with consequences outside the demonstration itself, and it points toward frontier extension: once large migrations become affordable, teams can consider architectural changes they previously treated as impossible.

I would rather give Astra a language problem I cannot solve

A useful next demonstration would start with a problem whose best design is unknown rather than with a target artifact whose shape is familiar. I would give Astra, or a comparable system, the task of designing and implementing a Python variant that preserves Python’s ergonomics while offering strong static typing, Hindley-Milner-style inference where appropriate, natural integration with Pydantic and basedpyright, compile-time diagnostics, JIT compilation, AOT compilation, and practical compatibility with the Python ecosystem.

The requirements are intentionally in tension. Python is successful partly because it permits mutation, duck typing, reflection, decorators, dynamic dispatch, runtime modification, and metaprogramming. Hindley-Milner inference is most comfortable with a more constrained semantic world. A JIT or AOT compiler benefits from stable types and representations. Pydantic performs valuable runtime validation, while basedpyright reasons about a gradual static type system. The task is to decide what the language means at the boundary rather than to bolt a type checker onto existing syntax.

The smallest example already exposes the issue:

1
2

def identity(x):
    return x

A useful inference result would be:

$$ \forall \alpha.\ \alpha \to \alpha $$

The compiler has inferred that identity accepts a value of any type and returns a value of that same type. The programmer did not have to write a generic parameter. That is pleasant in a language with Python’s feel.

Now consider a statically visible error:

1
2
3
4
5

class User(BaseModel):
    name: str
    age: int

User(name="Alice", age="wrong")

If the call and the model definition are available to the compiler, rejecting the string passed to age is sensible. The ecosystem also contains code like this:

1
2

payload = json.loads(request.body)
User(**payload)

The type of payload is not known precisely from the source. Runtime validation remains necessary, and the compiler should communicate that boundary rather than pretending that inference has proved more than it has.

This is not a request for a prescribed implementation. I would not tell the model to use LLVM, Cranelift, MLIR, Rust, an ownership system, or a particular intermediate representation. Existing projects such as Numba, Cython, and mypyc solve important pieces. Leaving the architecture open is part of the experiment: otherwise I would mostly be testing whether the model can follow my design. The experiment should reveal what architecture it chooses when it has to reconcile the whole set of constraints.

A useful result could be a pleasant language that catches meaningful errors, exposes good interfaces to Python tooling, compiles selected code effectively, and interoperates with real packages. It could also be a partial compiler with one excellent static/dynamic boundary, a useful inference strategy, or a representation that makes later compilation practical. The evaluation would include Python developers, type-system researchers, compiler engineers, and maintainers of the relevant tools. The contribution would be stronger if those reviewers found a mechanism they had not considered and could explain why it was useful.

The requirements may not all fit together. That is part of the point. A clear characterization of the incompatibility, accompanied by a smaller design that gets the best available tradeoff, would be a better outcome than a superficially complete language whose guarantees collapse as soon as it meets real Python code.

Make C++ safer without pretending history does not exist

A second challenge would ask for a credible successor to C++ that improves safety, diagnostics, compile times, and maintainability while retaining systems-level performance, low-level control, and a realistic migration path for existing software.

The underlying problem is large enough to matter without any AI narrative. C++ remains embedded in operating systems, browsers, databases, game engines, scientific tools, financial infrastructure, and countless internal systems. Memory-safety failures, concurrency errors, long builds, complicated diagnostics, and difficult maintenance create costs that teams have been paying for years. Rust, Carbon, and the C++ Core Guidelines each address parts of this problem. A new language with a clean slate still does not answer the migration question.

The successor would need to coexist with C and C++ libraries, object layouts, ABIs, templates, custom allocators, build systems, generated bindings, platform SDKs, and decades of engineering practice. It would need an incremental path in which a team can improve one component without freezing the rest of the product for a year. A nominally safer language with an ordinary foreign-function interface is an interesting systems language, but it is not yet a successor to the installed base.

There is a second constraint that is easy to lose. Safety mechanisms can add concepts. Ownership, regions, capabilities, effects, lifetime annotations, and metaprogramming rules may each solve a real problem while making the language harder to learn and maintain. The challenge should ask for semantic compression: can a smaller set of orthogonal principles replace several overlapping conventions about raw pointers, smart pointers, moves, copies, lifetimes, aliasing, and thread safety?

A design that is simply Rust with C++ punctuation would miss the target. So would a new language that claims interoperability while requiring a new wrapper around every serious dependency. The installed base is part of the specification, not an inconvenient detail to postpone.

The model should also be allowed to reject the premise. Perhaps the desired combination of safety, ABI compatibility, compile-time performance, source compatibility, and low-level control contains an unavoidable contradiction. A rigorous explanation of which properties cannot coexist, together with the least damaging compromise, would be valuable. Engineering advances often begin as a better statement of the constraint.

Evaluation would require people who can inspect the result at the level of actual systems work: C++ practitioners, compiler engineers, programming-language researchers, and maintainers of large native codebases. Their judgment should include a practical question: would I rather maintain production code this way? A stronger response would be: I would not have designed it that way, and after studying it I think its way may be better.

Let the demonstration teach us something

Open-ended projects make evaluation harder because the evaluator does not know the best answer in advance. That is also why they can provide stronger evidence. A Minecraft clone usually has a known target state. The evaluator can compare the artifact with a familiar reference, even if the internal quality is hidden. A language or systems design challenge may return a new mechanism, a partial system, a negative result, or a reframing that changes the question.

The evaluation should follow the artifact after the video ends. Correctness matters, along with robustness, maintainability, performance, novelty, utility, reproducibility, expert judgment, and the resources required. No single score can represent all of these. A result that is novel but unusable should be described differently from a result that is less novel but deployable and valuable.

The counterfactual should be documented rather than implied. How much elapsed time did the model use? What compute and tools were available? How many hours of specialist labor were required? Where did humans intervene? What did the best previous system or human-AI workflow achieve under a comparable budget? Perfect experimental matching will rarely be possible, but a credible comparison is much better than a cinematic claim about replacing an unnamed team.

The trajectory matters as much as the final artifact. Publish the initial plan, the major decisions, failed approaches, human interventions, revisions, test results, remaining defects, cost, and final state. A viewer should be able to distinguish a system that found a useful design from one that was repeatedly steered toward a result and edited out of the footage. For a language project, publish the compiler and test suite. For a systems migration, publish the compatibility tests, benchmarks, review record, and known unsafe boundaries.

Public visual appeal still has a place. It is a good invitation to look at the work. When the claim concerns expert engineering, independent expert review has to carry the rest of the argument. The more unfamiliar the result, the more important it becomes to show how the reviewers tried to break it and what they learned.

The best demo leaves something behind

The strongest frontier systems may indeed be extraordinary. That is why their demonstrations should become more demanding as the models improve. We can keep making familiar games, websites, and applications; they are useful probes of synthesis and integration. They should not be asked to carry claims about capabilities that the artifacts do not test.

A better standard starts with a problem that matters independently of the model. It asks for a contribution that adds something new. It compares the result with the strongest practical alternative, including existing human-AI workflows. Then it gives experts enough evidence to decide whether the result changes what can be built, studied, or maintained.

The two forms of ambition are straightforward:

Solve something we have wanted to solve but could not.

or:

Show us something we had not thought to want, then demonstrate why we should.

A frontier model should leave us with more than evidence about the model. It should leave us with a solution, design, artifact, technique, or question that was not available before. If the model disappeared from the story afterward, the result should still matter.