![Main article image](


alt="Article illustration 1"
loading="lazy">

) Types, a new visual programming language from Kit Langton, doesn’t tiptoe around its thesis: types aren’t metadata—they’re the medium. In an ecosystem where strongly-typed languages, schema registries, OpenAPI specs, protobuf contracts, and GraphQL SDLs orbit our actual codebases like a bureaucratic halo, Types tries something bolder. Instead of scattering type information across tools, files, and formats, it turns types into the primary artifact you manipulate, compose, and reason about. The code becomes the byproduct; the types are the source of truth. For teams wrestling with API drift, event sprawl, or brittle integrations, this is not just aesthetic. It’s structural.

What Is Types Trying to Fix?

Let’s start with the pain.

Modern software architecture is heavily type-driven in practice, but poorly type-aligned in tooling:

  • You model entities in one language.
  • You expose them in another (OpenAPI, GraphQL, gRPC, etc.).
  • You document them in a third (Confluence, Notion, wikis).
  • You mirror them in clients, often manually or via fragile codegen.

Between each step: drift.

Fields are renamed. Enums go out of date. Optionality changes silently. Backends and frontends, or services in a polyglot environment, operate on belief rather than guarantees. Your architecture is effectively implicit, spread across type definitions, JSON blobs, and tribal knowledge.

Types responds with a simple but subversive question: what if you start from a shared, living, visual type system that all these artifacts come from—and never diverge from?

Types as a Visual, First-Class Type System

Types presents a visually-driven environment where you:

  • Define data types, relationships, and constraints as first-class nodes.
  • Compose applications, APIs, schemas, and flows directly from those types.
  • Generate conventional artifacts (code, schemas, integrations) from a single canonical model.

The key idea is not merely the presence of types, but their primacy:

  • Types are the spatial medium: boxes, links, and shapes aren’t decorations; they’re the logic.
  • Types encode behavior and contracts between components.
  • Types exist at architectural level (systems, services, domains) and implementation level (DTOs, events, commands) in one continuous graph.

For a technical audience raised on TypeScript, Rust, F#, Haskell, or robust schema tooling, this is both familiar and alien. Familiar in its respect for types. Alien in putting them at the center of a visual language rather than the periphery of a textual one.

Why a Visual Language Now Actually Makes Sense

Visual programming has a credibility problem. Too many tools have been either:

  • Toy block-based languages (great for education, poor for production), or
  • Canvas-based integration designers generating opaque, unmaintainable spaghetti.

Types feels different for three reasons that matter to real-world engineers:

  1. It is type-first, not node-first.

    • Most visual tools connect generic “steps” with loose contracts.
    • Types inverts that: the type definitions are the stable core; flows and logic are structured around them.

  2. It acknowledges real constraints of modern systems.

    • The site’s framing (and Langton’s prior work) points toward compatibility with typed ecosystems: TypeScript, robust backends, and event-driven architectures.
    • Rather than pretending to replace everything, it aims to emit artifacts your stack can actually use.

  3. It serves as a shared source of truth.

    • For distributed systems, the hardest part is preserving shared meaning.
    • A centralized graph of types, versioned and generated into real code, is a pragmatic antidote to drift.

In other words: this isn’t “let’s drag blocks instead of writing code.” It’s “let’s elevate the one thing we all rely on but continuously fracture: types.”

Potential Use Cases: Where Types Could Matter Most

While the public material is still high-level, several concrete scenarios emerge where Types could be disproportionately impactful:

1. API and Contract Design

  • Design REST, GraphQL, or RPC contracts visually from a shared type graph.
  • Generate consistent server stubs and client SDKs from the same model.
  • Keep documentation, contracts, and implementations naturally synchronized.

For teams juggling OpenAPI files, ad hoc JSON examples, and out-of-date docs, a type-centric visual layer could function as both living design doc and enforcement mechanism.

2. Event-Driven and Message-Based Architectures

  • Model events, commands, and topics as structured types.
  • Express which services publish/subscribe using typed edges, not comments.
  • Reduce the risk of incompatible consumers when events evolve.

As organizations adopt Kafka, NATS, or cloud-native messaging, the hardest part is not throughput; it’s shared contracts. Types can play the role of a human-friendly schema registry plus topology map.

3. Multi-Language, Multi-Team Systems

  • Generate language-specific types (e.g., TypeScript, Go, Rust) from one source.
  • Enforce equivalence of concepts across boundaries—no more subtly divergent User or Order definitions.

In large organizations, this alone can be the difference between clean interoperability and constant semantic debugging.

How This Fits (and Fights) the Current Tooling Stack

If you’re already heavily invested in:

  • TypeScript for frontends and backends,
  • GraphQL schemas or OpenAPI specs,
  • Protobuf/gRPC contracts,
  • Infrastructure-as-code and GitOps flows,

then Types is not an obvious replacement—it’s a potential orchestrator.

This is where its impact will be decided:

  • Can it integrate cleanly with existing build pipelines?
  • Can type changes become pull requests, reviewed and versioned like code?
  • Can it generate diffable artifacts rather than trapping meaning in a binary canvas?

If Types answers these with mature, developer-first ergonomics, it doesn’t need to win hearts as a “no-code” fantasy. It wins as a precision tool:

A schema brain for your system that never lies.

But if it leans too far into visual opacity or closed formats, it risks being yet another pretty surface over untrustworthy guts.

Security, Reliability, and the Hidden Stakes of Better Types

To a casual observer, a visual type language might look like UI candy. For security and reliability engineers, the story is sharper:

  • Stronger guarantees:
    • Canonical types reduce ambiguities that lead to injection bugs, broken auth flows, or mis-validated payloads.
  • Auditable contracts:
    • A unified type graph makes it easier to inspect data flows: who can emit what, where sensitive fields travel, what is required vs optional.
  • Safer evolution:
    • Intentional type versioning helps avoid backwards-incompatible changes that silently break consumers.

As AI-assisted coding accelerates the production of new endpoints and services, a tool that centralizes truth at the type level becomes not just convenient, but defensive: a way to bound the chaos.

Betting on Types as the Language of Architecture

The most interesting part of Types is not the visuals. It’s the assertion that architecture should be expressed directly in types—and that those types should mechanically govern the systems that implement them.

This idea is both old and timely:

  • Old, in the sense that formal methods, IDLs, and schema-first design have chased it for decades.
  • Timely, because our current sprawl of services, runtimes, and AI-generated code has made drift not an edge case, but the norm.

If Types evolves into a robust, interoperable platform—one that:

  • emits readable, ownable artifacts,
  • plays well with Git, CI/CD, and existing languages,
  • and treats developers as partners, not abstracted-away operators—

then it has a real shot at becoming a new kind of language: not just for writing programs, but for drawing truth.

For now, Types is a bold statement in a space that has long deserved something more ambitious. If your team lives and dies by contracts, schemas, and cross-service consistency, this is one experiment worth watching closely.

Source: https://types.kitlangton.com