Introduction

Programming languages make different tradeoffs, but nearly all share a deeper problem: they expose a single resolution of complexity, shaped by the machine or compiler rather than by what the programmer is trying to accomplish.

The goal shouldn’t simply be to make a language easy or powerful. It should be to minimize the time required to understand a system while preserving strong guarantees around performance, security, and correctness.

Complexity is sometimes necessary. But it shouldn’t all be visible at once.

The harder parts of programming should be available on demand. Details should fold into comprehensible abstractions that you can open and inspect when the work requires it. The programming surface should present the right resolution for the task at hand.

Typical was conceived before AI code generation became useful. Since then, software development has changed dramatically, especially over the past year. That change hasn’t made the idea obsolete. It has extended it.

Once AI becomes a serious author of software, abstraction no longer needs to stop at the language boundary. Implementation details can fold into engineering intent. Engineering intent can fold into product behavior. Product behavior can fold into business objectives.

The ladder of abstraction can continue all the way from machine details to the reasons the software exists.

Today, AI coding appears to be converging on two primary resolutions:

1. Prompt the system at a high level, largely detached from the engineering process.
2. Drop into the generated code and review it at full implementation detail.

That is too large a jump.

At one end, you express what you want but have little visibility into how well it was built. At the other, you are suddenly reviewing thousands of lines in a language that may expose enormous incidental complexity. In Rust specifically, reading the code can feel as though you’ve passed beneath the implementation logic itself and stepped inside the compiler.

Both views are useful. The problem is the missing middle.

Software work happens at many resolutions. Sometimes you care about a business rule. Sometimes an architectural boundary. Sometimes a data model, concurrency policy, performance constraint, public API, or individual operation. Each task has a natural level of detail.

A better environment would let people and agents work at whichever resolution matches the decision being made. You could move from business intent into system structure and then into implementation, exposing detail only where it matters.

This only works if those abstractions are trustworthy. A higher-level view can’t just be an AI-generated summary of the code. It has to be a faithful view of the same underlying program. That requires a sound language and a compiler that preserves and verifies the relationships between levels.

Then complexity can be hidden without hiding uncertainty. You can work with a business rule, architecture, data model, or performance constraint while knowing that the implementation beneath it remains consistent—and open it when it doesn’t.

This matters more when AI writes the code. Reviewing every generated line doesn’t scale, but neither does trusting plausible output. The useful middle is being able to inspect the decisions that matter while the language and compiler enforce the details you’ve folded away.

Most of the industry is attacking this with better models, harnesses, and agent workflows. Those will help, but they operate above the programming model.

Typical puts the structure needed for this into the language, compiler, and environment themselves. The goal is not to hide engineering. It is to let people and agents work at the level the task requires, from business intent down to machine detail, without losing trust as they move between them.