The Tee System: a practical proposal to enable performance, simplicity, and readiness for AI-assisted development

The Tee System is a proposal, not a framework and not a rulebook. It is a working example of how software systems can be built when three concerns are treated as equally important from the start: performance, simplicity, and readiness for AI-assisted development.

Many systems optimize for only one or two of these. They are easy to start but hard to operate. Or fast at scale but complex from day one. Or friendly to AI code generation but difficult to audit or reason about later.

The Tee System explores what happens when these three goals are addressed together, with clear trade-offs and explicit constraints. It does this through a concrete, runnable example, not through theory alone.

Intentions behind the Tee system

Most software systems do not start complex. They become complex.

At the beginning there is usually a clear problem: a business process, some rules, data that needs to be stored, and people who need to work with it. Over time, layers are added. A separate frontend appears. Middleware follows. Caches, queues, background workers, and frameworks accumulate. Each addition is often reasonable on its own. Together, they spread meaning across many places.

The result is not always a more powerful system. More often, it is a system that is harder to understand, harder to change, and harder to trust.

The Tee System starts from a different position. It asks a simple question: what if we deliberately stop adding layers unless there is a clear, present reason to do so?

This is not simplicity for simplicity’s sake. It is about keeping meaning close to where decisions are made.

In the Tee System there are two effective runtime layers: one application service and one database. The application contains workflows, rules, and decisions. The database contains data and enforces integrity. Nothing else is required by default.

This choice is intentional, and it comes with trade-offs. Some common patterns are avoided. There is no mandatory message broker. There is no separate read model service. There is no assumption that the user interface must be a large client-side application. These choices are not rejected because they are wrong, but because they should be conscious decisions, not automatic defaults.

A system built this way is easier to reason about. When something happens, you can usually follow it from the HTTP request, through a command or a query, down to a SQL statement. There are fewer hidden paths. Fewer places where logic can silently diverge.

This clarity matters even more as AI becomes part of how software is built.

AI can generate code quickly. It can refactor. It can fill in large amounts of boilerplate. But AI also amplifies the structure it is given. If meaning is spread across layers, conventions, and implicit behavior, AI will struggle to keep the system coherent. If the structure is explicit and constrained, AI becomes far more reliable.

The Tee System is designed with this in mind. Commands and queries are explicit. SQL is written openly, not hidden behind abstractions. State lives in one place. Rules are enforced, not implied. This makes the system readable, not only for humans, but also for machines that assist in building and evolving it.

Readability is not a cosmetic concern. It is a form of auditability. When a system is readable, you can explain why a decision was made, why data looks the way it does, and what will happen if something changes. This matters to engineers, but also to architects, auditors, and business stakeholders who need confidence in how the system behaves.

PostgreSQL plays a central role in this approach. It is treated as a first-class system, not a passive storage engine and not a dumping ground for workflows. The database enforces constraints, relationships, and consistency. The application enforces processes and decisions. Each part does what it is good at, and the boundary between them is clear.

The user interface follows the same reasoning. The Tee System starts with server-rendered HTML. This provides a stable and predictable baseline. It keeps state on the server, where it is easier to reason about. When richer interactions are needed, they can be added carefully through progressive enhancement. The system does not assume that every application must start as a complex single-page application.

Operationally, the Tee System favors reality over theory. It optimizes for predictable performance, low idle cost, and clear failure modes. Scaling is possible, but incremental. Indexes come before caches. Read replicas come before service fan-out. New infrastructure is added only when there is a concrete need.

Language choice is part of this same thinking, which is why the Tee System uses Rust.

Choosing Rust is not a statement that Java or Python are bad technologies. They are widely used for good reasons. The choice of Rust is about what should be safe and efficient by default, especially in a world where AI generates more and more of the code.

Traditionally, teams chose languages that optimized for speed of development, and addressed performance and resource usage later. AI changes that balance. When code generation becomes cheap, the cost shifts away from writing code toward operating it correctly over time.

Rust provides strong guarantees at compile time. Memory safety without a garbage collector. No data races by default. Explicit ownership and lifetimes. Predictable resource usage. These guarantees are enforced by the language, not by convention.

This matters because AI does not intuit danger. If a language allows unsafe behavior by default, AI will generate it unless carefully constrained. Rust removes entire classes of errors, regardless of whether the code was written by a human or generated by a model.

Java and Python take different approaches. Java relies on a managed runtime and garbage collection, which provides safety but makes memory behavior less predictable and often increases baseline resource usage. Python prioritizes expressiveness and ease of use, but its performance and concurrency model are harder to reason about in long-running production systems.

Rust is not a panacea. It has a steeper learning curve. Compile times can be longer. Some patterns require more thought. These are real trade-offs.

The reason Rust fits the Tee System is that AI assistance reduces the cost of working with Rust’s strictness, while the guarantees remain. AI can help generate correct Rust code, but it cannot bypass the compiler. That raises the baseline for correctness, performance, and safety without relying on constant human vigilance.

This aligns with the broader goals of the Tee System: fewer runtime surprises, clearer boundaries, systems that remain understandable under change, and code that can be audited and trusted over time.

Conclusion

The Tee System is not a universal solution. It is not designed for every problem, and it does not promise that complexity will never appear. It is a set of deliberate constraints.

Those constraints aim to keep systems coherent, readable, and predictable as they grow, and as AI becomes a more active participant in software development. They make trade-offs explicit instead of hiding them behind defaults.

If you need highly decoupled event-driven architectures, real-time collaboration at massive scale, or complex client-side state machines, the Tee System may feel limiting. In those cases, additional layers may be justified.

If, however, you are building business applications where correctness, auditability, performance, and long-term maintainability matter, the Tee System offers a clear starting point. Not by being clever, but by being explicit about what is included, what is excluded, and why those choices were made.