The Future of AI App Building Depends on Type Safety

The Incentive Problem

AI wants to please you. It optimizes for the reward function it is given, and most of the time that is just “does it compile?” That means it will cut every corner necessary to get to a green checkmark. Those shortcuts look fine at compile time, but they collapse at runtime.

This is why AI falls back to the broad type any, or defaults to a loose type like string where something stricter, like a UUID, is expected. The code compiles, but correctness is already compromised. Worse, the AI does not remember what it wrote a few files ago, so without type safety the project quickly collapses under its own weight as complexity grows.

The Two Kinds of Errors

When AI-generated code runs, you usually see two flavors of type safety problems:

1. Compile-Time Errors

• What happens: The compiler catches a mismatch between the declared type and what was passed in.
• How a human fixes it: Decide whether the caller is wrong (convert 42 to a string) or the function signature is wrong (change it to accept a number type).
• How the AI “fixes” it: Change the argument type to any. Problem “solved,” but you just removed the guardrail that would have caught future errors.

2. Runtime Errors

• What happens: The compiler thinks everything is fine (often because types were loosened), but the real value at runtime does not match the assumption.
• How a human fixes it: Trace the variable back to its source (like an API or database query) and fix the type at the boundary so the data comes in as a proper string.
• How the AI “fixes” it: Without context, it guesses. Maybe it wraps everything in String(...), or just broadens the type again. The crash goes away in this spot, but now logic is broken. Numbers meant for math are suddenly strings.

This cycle of runtime errors → AI “fix” → looser typing compounds quickly. The result is a codebase that compiles and throws fewer runtime errors, but cannot be trusted. Imagine a healthcare scheduling system where doctors’ shifts are managed by the app. A type mismatch slips in: an int for hours is treated as a string. The AI ‘fixes’ it by loosening the type to any. The code compiles and the error disappears, but shift calculations silently break, double-booking doctors and leaving an entire wing of the hospital uncovered.

The Database Multiplier

The moment you connect to a database, errors multiply and their causes become harder to trace. SQL is typed for a reason. Every schema (INT, TEXT, UUID, BOOLEAN) encodes assumptions about your data.

When an AI flattens everything to string | any, you lose those guarantees:

• Bad writes: inserting "true" into a boolean field compiles, but corrupts the DB.
• Bad reads: query returns NULL, but the AI assumed string, leading to a runtime crash.
• Broken relations: if a relation key is expected as an UUID but the AI treats it as a string and mistakenly sends garbage values, the joins will not crash but they will return no data. This hides errors until they surface later as missing or inconsistent results.

This is why serious teams use typed languages and enforce type safety from schema to API. If you do not, the database stops protecting you and hidden issues compound.

Why Mature Teams Enforce Strict Typing

Strict typing is not about slowing developers down. It is about making scale possible.

Types:

• Encode intent into the code.
• Make refactors safe and predictable.
• Catch entire classes of bugs before they hit production.
• Show future developers (and AI) exactly how to use a function or object.

Without type safety, AI’s code sloppiness compounds. With it, the same AI produces code you can trust and extend.

How to Force AI Into Type Safety

You have to treat AI like a junior engineer. Fast, talented, but careless without direction.

• Provide the right context. Give it the interfaces and types it can use. Show examples of usage. Be opinionated about the right way to structure code.
• Give strict instructions. Very clearly let the AI know to not use any, never allow unknown, and to have every method, object, and variable typed. Expect it to have a hard time following these instructions (especially on the first pass).
• Enforce with linting. Just like reviewing a junior developer’s code, you need to check the AI’s. At Woz, we built custom lint rules that define what “good code” means to us. We feed linting failures back to the model until it passes. It may take multiple rounds, but it shifts the reward function toward including type safety.
• Iterate with checks. Compile-time errors, runtime logging, click-through tests. Each iteration forces the AI to tighten types and move closer to production-grade code.

The Woz Way

At Woz, we sacrifice raw generation speed for higher quality. We fight for zero tolerance for any types, enforcing multiple feedback loops and strict linting rules the AI must pass before we call code ‘done.’ It takes constant effort, but it is the only way to keep quality from slipping.

Earlier I mentioned a key point: once AI starts patching runtime errors by loosening types, you enter a vicious cycle. Each fix strips away another guardrail, and the result compounds into a codebase that compiles but is fragile and unmaintainable. The reverse is also true: if you force the AI to respect type safety on every pass, you create a virtuous cycle. Each iteration tightens the guardrails, the codebase becomes cleaner, and quality compounds into something you can trust and build on.

This is the system we have built at Woz: every loop is designed to tighten standards, not weaken them. It is the same reason the best engineering teams choose strongly typed languages. Type safety is the baseline guardrail for maintainability, and letting AI ignore it guarantees your app will never reach production grade.

Woz is proof that AI can write code you would actually ship. Try it, inspect the code, and tell us how we can make it even better.

This piece originally appeared in Unite.AI and has been adapted for our blog.