Fuzzy Compiler

Same Job, Different Contract

A C compiler rejects ambiguity. It throws a syntax error. You fix it.

An LLM resolves ambiguity. It picks an interpretation and keeps going. It never tells you it guessed.

Every ambiguity in your spec is a branch point. More ambiguity, more branches, more drift from what you wanted.

Example: Authentication Ambiguity

# Vague spec (many valid compilations)

"Add authentication to the API"



# What the fuzzy compiler might produce:

# Option 1: Session cookies

def authenticate(request):

    session_id = request.cookies.get('session')

    return db.get_user_by_session(session_id)



# Option 2: JWT tokens

def authenticate(request):

    token = request.headers.get('Authorization')

    return jwt.decode(token, SECRET_KEY)



# Option 3: API keys

def authenticate(request):

    api_key = request.headers.get('X-API-Key')

    return db.get_user_by_api_key(api_key)

All three are valid interpretations. Traditional compiler: syntax error. Fuzzy compiler: picks one and keeps going.

# Constrained spec (one valid compilation)

"Add JWT-based authentication with RS256 signing.

Include refresh token rotation and 15-minute access token TTL."



# Now the fuzzy compiler has one clear path:

def authenticate(request):

    token = request.headers.get('Authorization')

    payload = jwt.decode(token, PUBLIC_KEY, algorithms=['RS256'])

    if payload['exp'] < time.now():

        raise TokenExpired()

    return payload['sub']

Errors Are Silent

Traditional compilers fail loud: red text, line numbers. Fuzzy compilers fail silent: the code runs, tests pass, ships to production.

Example: The Multi-Currency Bug

Real production incident from a 2026 e-commerce platform:

# Vague spec (the fuzzy compiler filled in the gaps)

"Add checkout with Stripe payments.

Calculate total from cart items.

Show success page after payment."



# What the fuzzy compiler produced:

def calculate_total(cart_items):

    return sum(item.price * item.quantity for item in cart_items)



def process_payment(total):

    stripe.Charge.create(amount=int(total * 100), currency='usd')



# Tests passed. Code shipped. Worked fine.

# For three weeks.

Then a customer in the UK bought something. Cart had GBP prices. Stripe charged 99 GBP as 9900 USD. $12,000 charge for a $120 order.

# What the spec needed to say:

"Calculate total in item's native currency.

Support USD, GBP, EUR.

Pass currency to Stripe with amount.

Reject if cart has mixed currencies."



# Now the fuzzy compiler has constraints:

def calculate_total(cart_items):

    if not cart_items:

        return 0, None

    

    currency = cart_items[0].currency

    if any(item.currency != currency for item in cart_items):

        raise ValueError('Mixed currencies in cart')

    

    total = sum(item.price * item.quantity for item in cart_items)

    return total, currency



def process_payment(total, currency):

    if currency not in ['USD', 'GBP', 'EUR']:

        raise ValueError(f'Unsupported currency: {currency}')

    stripe.Charge.create(

        amount=int(total * 100),

        currency=currency.lower()

    )

The Implication

Your spec is source code. The quality of your spec determines the quality of your output, not as a nice-to-have but as a conservation law.

You wouldn't write half a function and expect gcc to figure out the rest. Don't write half a spec and expect the fuzzy compiler to guess correctly.

As one developer put it in 2026: "The main weakness would be that they understand nothing about programming, they just generate text that they think you want to see."