Software is due for its next abstraction layer: CAD

Every major advance in software has come from changing the level of abstraction at which systems are designed. Progress did not come from faster hardware or better discipline alone, but from new languages and tools that allowed developers to stop managing details that no longer mattered and instead express systems at the right level of intent.

We are reaching that boundary again.

AI has accelerated development, but it has also exposed a deeper limitation. The languages we use today are not well suited to describing the kinds of systems we now expect to build. Simply generating more code, even with better models, does not address that mismatch.

A recurring pattern in software history

Early software development required working directly with hardware. Behavior was physical, and every change required manual intervention. Assembly languages introduced the first meaningful abstraction by allowing symbolic instructions to replace physical wiring, but developers still had to think in registers and memory.

Languages like C raised the abstraction further by introducing data structures and control flow, which made operating systems and networking feasible. Later, managed languages such as Java, Python, and JavaScript abstracted away hardware concerns almost entirely, allowing developers to focus on application logic and APIs instead of memory management.

At each step, developers gave up direct control over certain low-level details. In return, they gained the ability to build systems that were larger, safer, and more maintainable. The abstraction matched the complexity of the problems being solved at the time.

Why current languages are showing their limits

Despite being considered high-level, today’s programming languages still operate too close to the implementation layer for modern backend systems.

Most backend work today is not about designing novel algorithms. Teams are primarily concerned with expressing access rules, enforcing invariants across multiple entities, coordinating asynchronous workflows, integrating AI into long-running processes, and ensuring that guarantees hold over time and failure.

These concerns are systemic rather than algorithmic. However, they are still expressed indirectly through functions, classes, endpoints, queues, schedulers, and configuration. The intended behavior of the system exists only implicitly across many pieces of code.

As systems grow, this fragmentation leads to brittleness. Local changes produce unexpected global effects. Invariants are violated in edge cases. Systems behave correctly most of the time but fail under conditions that were never explicitly modeled.

This is especially visible in AI-assisted and vibe-coded systems. The problem is not that the models are incapable, but that the language they are asked to generate code in does not capture the structure and constraints of the system clearly enough.

Why AI alone does not solve this

Using AI to generate code directly in today’s languages shifts effort, but it does not change the underlying problem. The model still has to track constraints, relationships, and invariants across many separate decisions. As the system grows, the burden of keeping everything consistent increases rapidly.

This is why AI performs well on local transformations, small features, and prototypes, but struggles with global system correctness. The issue is not insufficient intelligence. It is insufficient representation.

Without a higher-level model, both humans and AI are forced to reconstruct the system’s intent repeatedly from low-level artifacts.

CAD as a useful analogy

Computer-aided design tools changed architecture and engineering by introducing a single coherent model from which all views are derived. Designers define structure, constraints, and relationships once, and the system enforces consistency across representations.

Changes propagate automatically, and invalid designs are rejected early. The tool does not merely make drawing faster; it prevents entire classes of errors by construction.

In other words, in CAD you don’t draw the same object from ten perspectives and hope they match. You define a single coherent 3D model and from that model CAD generates all views, ensures dimensions are consistent and enforces structural constraints. If you move a wall, every relevant view and computation updates automatically. You cannot “forget” to fix one perspective.

Software development lacks an equivalent abstraction. We still describe systems by assembling many partial views and rely on discipline and testing to keep them aligned.

What a higher-order programming language would provide

A higher-order programming language would allow developers to describe systems in terms of behavior, constraints, and guarantees rather than implementation steps.

Instead of manually encoding how permissions are checked, how asynchronous work is coordinated, or how consistency is preserved, developers would declare the rules and expectations of the system. The underlying implementation would be derived from that specification.

This would not be an AI prompt or a dynamic interpretation layer. It would be a compiled language with a well-defined model and semantics. From a single source of truth, it would generate APIs, data models, workflows, and integration logic that remain consistent by construction.

What we’re building with Sutro

This perspective is what motivates our work on Sutro.

We are building a new generation programming language, starting with the backend, called SutroLang (SLang). SLang is not designed for writing algorithms or stitching together implementation details. It is designed for defining what a backend must do, not how each step is manually executed.

In SLang, developers describe system behavior, policies, relationships, and guarantees directly. From that single specification, the system compiles a coherent backend that stays consistent across the many perspectives a real product requires, including APIs, data models, workflows, permissions, and integrations.

AI can work within this language, but it no longer has to reconstruct the entire system from scattered code and configuration. The language itself carries the structure and enforces coherence, in much the same way that CAD tools enforce consistency in physical design.

That is the problem we are trying to solve, and it is why we believe backend development is ready for its next abstraction layer.