AI can generate code. Trust has to be compiled.

The Combobula Manifesto

AI can generate code faster than teams can understand it.

That is the breakthrough—and the problem.

For decades, writing software was the bottleneck. Turning an idea into working code required time, specialized knowledge, and thousands of deliberate decisions. Today, a model can produce a query, an API endpoint, a data transformation, and a user interface in minutes.

The cost of producing syntax is collapsing.

The cost of knowing whether that syntax is safe, correct, and faithful to its purpose is not.

The bottleneck has moved from generation to verification.

AI increases the amount of code we produce. We want to increase the amount of code we can trust.

That is why we are building Combobula.

More code is not the same as more confidence

AI-generated code often looks convincing.

It follows familiar patterns. It uses the right vocabulary. It compiles often enough to encourage us to keep going. It can turn a vague request into a substantial implementation before we have fully articulated what the implementation must preserve.

But plausibility is not a guarantee.

A query can be syntactically valid while combining incompatible units. An aggregate can return the expected shape while losing the meaning of the underlying data. A generated interface can render a number without knowing whether it represents money, temperature, probability, duration, or an identifier.

The code may work in the narrow sense that it runs.

That does not mean it is safe to ship.

As code generation accelerates, teams face a growing verification gap:

AI can create implementations faster than humans can confidently review them.

The answer is not to reject AI. The productivity gains are too valuable, and the direction of change is clear.

The answer is to change what trust depends on.

Trust should not depend on how persuasive the generated code looks. It should not depend on another model assigning it a confidence score. It should not depend on a reviewer reading every generated line and reconstructing every hidden assumption.

Trust should come from explicit contracts and deterministic checks.

AI can generate code.

Trust has to be compiled.

Code is not intent

Source code is only one representation of what a system is supposed to do.

The real intent lives elsewhere:

• a monetary amount must retain its currency;
• an identifier for one entity must not be substituted for another;
• private information must not appear in a public result;
• a percentage must not be treated as an arbitrary number;
• a query must not consume unbounded memory;
• an aggregate must preserve the meaning of the measure it summarizes;
• a user interface must render values according to what they mean, not merely how they are stored.

These are not formatting preferences. They are part of the system.

Yet in most applications, this knowledge is scattered across database declarations, application types, validation rules, query builders, UI components, documentation, and the memories of experienced developers.

Every boundary creates another opportunity for meaning to disappear.

AI magnifies that weakness. A model can reproduce conventions it can see, but it cannot reliably preserve assumptions that were never made explicit.

The more implementation we delegate, the more precisely we must define what the implementation is not allowed to violate.

SQL is where types often stop

Modern application code may have a sophisticated type system. The database may have a carefully designed schema. The user interface may have strongly typed components.

Between them sits SQL.

SQL is powerful because it transforms data freely. It joins, projects, filters, aliases, groups, aggregates, derives, and reshapes.

But those transformations often flatten meaning.

A database column may represent Money<PLN>. After a query crosses an application boundary, it may become a generic decimal.

A timestamp truncated to a month may become a generic date.

A customer identifier may become a string.

A revenue aggregate may arrive at the UI as a number with no indication that it is a measure, that it carries a currency, or that it was produced by summation.

The structural type survives.

The semantic type does not.

Developers then rebuild the missing meaning by hand. They repeat schema knowledge in application code, validators, formatters, table definitions, chart configuration, and form controls.

AI can generate this glue code more quickly.

It can also generate more inconsistencies more quickly.

Types that survive SQL

Combobula begins with a simple proposition:

Types should survive SQL.

Not only primitive types such as strings, numbers, and dates.

Semantic types.

A value should be able to retain information about what it represents, where it came from, which transformations produced it, which operations remain valid, how it may be exposed, and how it should be presented.

Consider a schema containing:

invoice.amount  : Money<PLN>
invoice.paid_at : Instant

And a query:

SELECT
  date_trunc('month', paid_at) AS month,
  sum(amount) AS revenue
FROM invoice
GROUP BY 1
ORDER BY 1;

A conventional type-safe SQL tool may infer:

month   : Date
revenue : Decimal

A semantic type system should be able to preserve more:

month   : TimeBucket<Month>
revenue : Money<PLN> & Aggregate<Sum>

That additional information changes what the rest of the application can know.

The compiler can reject invalid currency operations. The UI can format revenue as Polish złoty. A chart can recognize a time dimension and a numerical measure. A filter can offer a monthly range. An authorization layer can determine whether the result exposes individual records or only aggregates.

The same meaning can move from the database schema, through the query, into application code and all the way to the interface.

Define meaning once.

Preserve it through transformation.

Use it everywhere.

The model is an author, not an authority

We want AI to generate queries, transformations, components, and entire features.

But the model should not be the system that decides whether its own work is safe.

The model is a probabilistic author. The compiler is the authority.

The intended workflow is straightforward:

1. Humans define the domain meaning and the conditions that must remain true.
2. A developer or AI agent proposes an implementation.
3. The compiler derives types, effects, lineage, policies, and execution requirements.
4. The implementation is checked against the declared contract.
5. Only verified plans are allowed to proceed toward production.

AI proposes.

The compiler checks.

Humans remain in control.

This division of responsibility does not diminish the role of the developer. It strengthens it.

The developer no longer has to express every decision as repetitive implementation code. Instead, the developer defines the invariants that every implementation—human-written or generated—must respect.

The job shifts from producing every line of syntax to authoring guarantees.

Compiler confidence, not artificial confidence

“Compiler confidence” does not mean that a tool tells us code is probably correct.

It means the system can state exactly which properties it verified.

A successful check might establish that:

✓ The database schema is compatible
✓ Query inputs and outputs are correctly typed
✓ Semantic types survived every transformation
✓ Nullability is handled explicitly
✓ Units and currencies are compatible
✓ Access policies are satisfied
✓ UI components accept the resulting types
✓ The execution plan remains within declared limits

There is no mysterious score.

There is no claim that the compiler understands an intention nobody expressed.

There is a contract and evidence that the implementation satisfies it.

We will not promise that “if it compiles, it must be the right product.”

We want to make a narrower and more useful promise:

If it compiles, it respects the declared contract.

The stronger and more expressive the contract becomes, the more code can be generated without turning every release into an act of faith.

Every query needs a contract

Correctness does not end with types.

A valid query can still be operationally dangerous. It can request an unbounded result, consume excessive memory, run too long, overload a service, or expose more data than the caller needs.

A trustworthy data application must reason about both meaning and execution.

Every query should have a contract.

Every execution should have a budget.

That budget may include:

• maximum execution time;
• maximum memory usage;
• maximum output size;
• concurrency limits;
• cancellation behavior;
• backpressure;
• access requirements;
• permitted data exposure.

Some properties can be proven before execution. Others can only be estimated and enforced at runtime.

The distinction matters.

We should never pretend that a static analysis can predict every runtime cost perfectly. But we can ensure that uncertainty has boundaries. When a limit is reached, the system should fail predictably rather than consume resources without restraint.

This is how compiler confidence extends into production confidence.

Ordinary SQL should remain ordinary SQL

A safety layer is only useful if teams can adopt it.

Combobula should not require developers to abandon SQL, replace their database, or rewrite an entire application around a proprietary language.

The path to stronger guarantees must be gradual.

Use ordinary SQL.

Adopt semantic types one domain at a time.

Compile one query, one endpoint, or one screen before migrating the rest.

Infer wherever possible. Annotate only where human meaning cannot be discovered automatically.

Keep escape hatches for database-specific functions and unusual domains.

Work with existing tools instead of demanding control over the entire stack.

The best safety systems do not begin by asking teams to stop shipping. They make the next release safer than the previous one.

Models will change. Meaning must survive.

The current generation of AI tools will not be the last.

Models will improve. Vendors will change. Interfaces will be replaced. Today’s preferred coding agent may be irrelevant in a few years.

A company’s domain meaning should not belong to any of them.

Its definitions, constraints, policies, and invariants should remain portable, inspectable, and enforceable independently of the model that generated a particular implementation.

Models are interchangeable.

The meaning of your business is not.

Combobula is not intended to become another place where domain knowledge disappears into prompts. It should turn that knowledge into durable, executable contracts.

Your expertise, compiled.

We are not defending the past

We do not believe the answer to AI-generated code is to preserve every old workflow.

Software development is changing. Some tasks will disappear. Many will be transformed. New abstractions will replace work that once required painstaking manual implementation.

That can be a positive future.

But only if increased automation is matched by increased control.

The future we want is not one where humans compete with machines to produce more syntax.

It is one where:

• humans decide what must remain true;
• machines explore and generate possible implementations;
• compilers verify those implementations against explicit contracts;
• runtimes enforce operational boundaries;
• teams can move faster without shipping blind.

AI should make software creation more accessible.

It should not make software behavior less accountable.

What we believe

Meaning should be defined once and preserved across the stack.

SQL should remain SQL.

AI-generated code should be treated as untrusted until verified.

Compiler errors are more valuable than confidence scores.

Guarantees must be specific about what they do—and do not—prove.

Runtime uncertainty should have explicit limits.

Domain knowledge should belong to its authors, not to a model provider.

Developers should be able to adopt stronger guarantees incrementally.

Humans should remain the authors of intent.

Build at AI speed. Ship with compiler confidence.

We want the speed.

We want the leverage.

We want AI to remove repetitive work and expand what small teams can build.

But we also want releases to become boring again.

We want developers to understand which properties have been verified before they press Deploy. We want generated queries to preserve the meaning of the schema they operate on. We want interfaces to understand the data they present. We want runtime behavior to remain within known limits.

We want more code to be created.

And we want more of it to be safe to ship.

That is the purpose of Combobula.

Types that survive SQL.

So human intent survives AI-generated code.