# My AI Wishlist

> Source: <https://diverging.run/checkpoints/ai-coding-wishlist/>
> Published: 2026-07-30 14:38:53+00:00

# My AI Wishlist

Compared to my post on [AI coding milestones](https://diverging.run/checkpoints/ai-coding-milestones/), this is a bit more general on tooling + interfaces that might exist someday… I just wish they existed today.

## Business Logic Verification

Many people are interested in formal verification, like TLA+, Lean, or Rocq. That’s great for proofs, cryptography, and llm training data, but not useful for most engineers. What I actually need, day-to-day, is verifying business logic. This is much harder because “business logic” is famously squishy. Even if you did translate all your business logic into Lean, few would be able to read it let alone debug it.

In an ideal world, “tests” would look like business requirements that are evaluated regularly across code (and perhaps proactively on metrics). You could imagine executive summaries expanded out to a laundry list of features that are meticulously validated by an agent. The trick here is to tie the requirements back to the source, like a PRD, Slack message, Google Doc, etc.

Verifying business logic in a pseudo-interactive fashion would let builders know if they’ve regressed on a feature or assess if the tradeoff is worth it.

Sadly, most would use this to build over-complicated products, since “maintaining growing complexity” would no longer be an acceptable excuse to pare down features.

My hope is that a cacophony of messy, spaghetti products jolts us back to being designers again, letting simplicity shine.

## Design Thinking

We certainly have AI doing [real design work](https://diverging.run/checkpoints/claude-design-is-real-design/). But LLMs are not quite doing “design thinking”, made famous by IDEO and others.

What’s special about “design thinking” is tying business problems to product development. In practice, this means UX and UI understanding.

For a model to understand “UX”, that’d require predicting human behavior (possibly [tractable](https://www.mantic.com/)). But today’s benchmarks on UI understanding are [fact-based question/answer pairs](https://mmmu-benchmark.github.io/), not more subjective visual understanding on what makes one product well-designed vs. another.

We do, in fact, have a process for making subjective “good design” legible. It happens during a weekly ritual, all around the world, called the “Design Crit”.

Some researchers are trying to encode design thinking into AI workflows, either through [model training](https://contralabs.com/research/design-crit) or an [interface](https://dl.acm.org/doi/10.1145/3800645.3812885). It’s very nascent, but expect to see progress on this soon, given that data farms are [beefing up in this domain](https://work.mercor.com/explore?listingId=list_AAABnJ0LvLdNuRT_1I9Iib8_).

## AI-first Programming Language

If we had to design the perfect output from an AI agent - an “AI-first” programming language + runtime - what would it look like? What would the requirements be?

Here my stab at it:

- Static verification via algebraic types.
- Strict memory safety, optional or incremental.
- Runtime metrics (like JVM, BEAM, etc.).
- Readable, legible. Ruby, Elixir, Crystal are great examples.
- Short iteration loops.
- Sandboxing &
[security](https://docs.deno.com/runtime/fundamentals/security/)built-in

Of course, these requirements are in conflict with each other (are algebraic types legible?), and to some extent this is just a hand-wavy, pipe dream wishlist programming language that anyone would love to use, with or without AI.

**a short detour...**

(This a kernel of an idea - I may need to expand this in a later post)

One thing to consider is designing the right interface for this “AI-native” programming language (perhaps before we design the language itself).

Let’s take a basic, possibly flawed comparison between Ruby & Rust:

``` python
# Ruby

def average(numbers)
  return nil if numbers.empty?

  numbers.sum.fdiv(numbers.length)
end

# Rust

fn average(numbers: &[f64]) -> Option<f64> {
    if numbers.is_empty() {
        return None;
    }

    Some(numbers.iter().sum::<f64>() / numbers.len() as f64)
}
```

It’s obvious that Ruby is more readable at the cost of giving less information. But what if we selectively “collapsed” details in the Rust code to make it readable, and in your “AI interface” you could expand/collapse information as needed.

A “paper prototype” of what I mean:

```
// Rust, but details "collapsed", ideally with some UI
// to show you something is being hidden

fn average(numbers) {
    if numbers.is_empty() {
        return None;
    }

   numbers.iter().sum() / numbers.len()
}

// if the code does not compile, or there's clear intent
// that you want to dig in (mouse, voice, code review),
// show the "expanded", original vrsion:

fn average(numbers: &[f64]) -> Option<f64> {
    if numbers.is_empty() {
        return None;
    }

    Some(numbers.iter().sum::<f64>() / numbers.len() as f64)
}
```

This would be full integration between a programming language, the interface, and the agent. I’m guessing it’ll take a long time to get here. But when we do it’ll be bliss.

## Gamified Prompting

What is the “Mavis Beacon” of AI?

If you use Claude or Codex every day at work, it’s easy to assume that everyone knows these AI tools inside and out. In reality, there’s a huge gap between those who can do infinite token sorcery and those who merely replaced Google and need to finish their homework. Similar to how we did “digital transformations” in the past, we’ll have “AI transformations” to teach people how to prompt, at scale.

If you’ve used AI tools well, you already know that it requires a totally different way of thinking. It turns this this “way of thinking” has a name: it’s [metacognition](https://en.wikipedia.org/wiki/Metacognition). Even for older LLMs, we’ve observed that [interacting with LLMs demands metacognitive thinking](https://dl.acm.org/doi/full/10.1145/3613904.3642902).

How do we teach skills at scale? Well, with games of course! AI is used to build games, but I wish LLM prompting is more often [used as the core game mechanic](https://x.com/dooart/status/1800503624344453207).

Unfortunately, it may be some time before we get this. It seems the game industry has a [negative outlook on AI](https://gdconf.com/article/gdc-2026-state-of-the-game-industry-reveals-impact-of-layoffs-generative-ai-and-more/). I suspect few game designers will be motivated to create the “Mavis Beacon for AI”, despite how important it is.

Maybe one of the bigger labs can make it happen?

## Multiplayer Coding Harness

How might we share context between coding agents? Imagine I had an agent working on a project, and now I want it to collaborate with a colleague’s agent that was working on a similar domain. How would that work?

The current solution involves dumping context to a shared knowledge base like Notion/Slack/Linear, and then each claude/codex instance uses that as a reference.

But with that, how do we solve the following:

- How does an agent notify/message another agent?
- What if I don’t want my agent to share all of its context, but still be able to use its “private” context when relevant?
- How can I prompt my colleague’s agent?

If you squint, these look similar to people problems that we tackle every day! We’ll need some protocol that blends humans + agents in a multiplayer interface.

There is [A2A](https://a2a-protocol.org/latest/), but I don’t know of anyone really using it.

If you’re working on this, please let me know!