Why does the agent invent fields that don't exist?

The agent generates code by pattern-matching against training data. If a similar app in training data had a `customer.full_name` field, the agent will write `customer.full_name` for your app, even if your collection only has `first_name` and `last_name`. The code looks correct, the editor does not check it against your actual schema, and the failure only surfaces at runtime when the field returns undefined. Lowcode.agency described this exactly: 'AI generates code that looks right, deploys without errors, then fails the moment a real user touches it.'

What about hallucinated API endpoints?

Same mechanism. If training data showed apps calling `/api/users/me` or `/functions/sendEmail`, the agent may emit fetch calls to those URLs even when your project does not have functions by those names. The fetch call is syntactically valid. The 404 only happens at runtime. Compounding factor: routing desync (covered in the [routing fix](/fix/backend-functions-404-routing-broken)) makes it harder to tell whether an endpoint is hallucinated or just unrouted.

Does TypeScript catch hallucinations if I use it?

Partially. If you have explicit TypeScript types matching your schema and the agent imports them, TypeScript will flag references to missing fields at build time. In practice the agent often generates types alongside hallucinated fields, so the types lie consistently with the code and TypeScript happily compiles both. The reliable validation is runtime, against the actual database, not type-level.

Can I configure the agent to read my real schema?

The agent has access to your project's schema metadata in the editor. It does not always use it consistently. You can improve grounding by including the relevant collection schema in your prompt explicitly: 'Here is the schema for the orders collection: {paste the field list}. Use only these fields.' This reduces hallucination but does not eliminate it.

How often do hallucinations actually ship to production?

More often than you would expect. Several feedback-board entries describe hallucinated code shipping past the editor's preview because the preview did not exercise the affected code path. Henry Collins' Medium post on Base44 fragility specifically mentioned `Sample data sometimes slipped in where real data should be.` The defensive posture is to assume every agent change might have hallucinations and to run every change through real-data smoke tests.

Catch Base44 AI Hallucinations Before They Ship Fake Endpoints and Phantom Fields

What's happening

You ask the AI agent to add a feature: "Show the customer's full name and email in the order summary." The agent writes code. The editor's preview looks fine. You deploy. A real user views their first order and the page renders "undefined undefined" where their name should be, then crashes when the email field also fails to resolve.

You inspect. The agent wrote order.customer.full_name. Your customer collection has first_name and last_name. There is no full_name field. The agent hallucinated it.

A user on lowcode.agency captured the pattern: "AI generates code that looks right, deploys without errors, then fails the moment a real user touches it." Henry Collins' Medium post on Base44 fragility added: "Base44 produces code that looks plausible but produces incorrect functionality when tested." Another user on the feedback board: "Sample data sometimes slipped in where real data should be."

The frustration is that hallucinated code compiles, passes the editor, and even renders mock data correctly because the mock data the agent built also has the hallucinated field. The failure is invisible until the code runs against production data.

Why this happens

The Base44 AI agent generates code through pattern-matching against training data. When it writes a code block that references a customer's name, it samples from the most probable token sequences given the prompt and the surrounding code. If customer.full_name was the most probable next token in training data — common in many SaaS products — that is what the agent emits.

Three factors compound the hallucination problem.

No automatic schema grounding. The agent has access to your collection schemas through the editor's metadata. It does not consistently use them as a hard constraint. Schema is a hint to the agent, not a contract. Different prompt wordings produce different rates of hallucination on the same project.

Mock-data co-hallucination. When the agent generates a component that needs sample data for the preview, it generates the sample data alongside the component. The sample data is internally consistent with the component, including the hallucinated fields. Preview renders work. Real data fails.

Build-time silence. TypeScript catches some hallucinations, but the agent often generates types and code together. If the agent invents customer.full_name, it may also invent a TypeScript interface that includes full_name. The build is satisfied. The runtime is not.

A fourth, sneakier variant: the agent invents API endpoints. You ask for an integration with a real third-party API and the agent emits fetch calls to URLs that look right but do not exist on the third-party service. The 404 only surfaces when the fetch executes.

Sources: lowcode.agency/blog/base44-not-working-errors-fixes, medium.com/@henry_79982/is-base44-falling-apart-f4d6defd3841, nocode.mba/articles/base44-review, feedback.base44.com posts on data binding errors.

How to reproduce

Create a Base44 project with a collection (e.g., customers) that has 2-3 fields (e.g., first_name, last_name, email).
Ask the agent: "Add a customer detail page that shows the customer's full name, email, phone, and avatar."
Read the generated code carefully. Look for references to full_name, phone, and avatar — fields that do not exist in your collection.
Run the editor preview. Note that it renders successfully because the agent generated mock data with the hallucinated fields.
Connect a real customer record to the page. Observe the runtime errors: undefined fields, crashes, or empty renders.
Check the network tab. If the agent generated any fetch calls to API URLs, verify each URL exists. Frequently one or two will 404.

To stress-test: ask for an integration with a service the agent has not been told you use (e.g., "send a Slack notification when an order is placed"). The agent will write fetch calls to a Slack webhook URL it invents from training-data patterns. The URL will not match your actual Slack webhook.

Step-by-step fix

You cannot stop the agent from hallucinating. You can detect hallucinations before they reach users. The fix is workflow plus runtime checks, not a magical agent setting.

1. Demand the agent list referenced fields explicitly

Change your prompts. Instead of "show the customer's full name," ask: "Show the customer's full name. List every field on the customer collection you reference, and confirm each is in this schema: {first_name, last_name, email}. If you need a field not in this list, stop and ask before writing code."

This shifts the agent into a self-checking mode. It does not eliminate hallucination, but the agent will catch its own invented fields about half the time when forced to enumerate them.

2. Validate field references against the live schema in CI

Write a script that walks your codebase, finds every collection-field reference (e.g., customer.X, orders.Y), and checks each against the live schema. Fail the build if any reference is missing.

// scripts/validate-fields.ts
import { base44 } from "@base44/sdk";
import { readFileSync } from "node:fs";
import { glob } from "glob";

async function main() {
  const collections = ["customers", "orders", "products"];
  const schemas: Record<string, string[]> = {};
  for (const name of collections) {
    const sample = await base44.collection(name).list({ limit: 1 });
    schemas[name] = sample[0] ? Object.keys(sample[0]) : [];
  }

  const files = await glob("src/**/*.{ts,tsx}");
  const errors: string[] = [];
  for (const file of files) {
    const text = readFileSync(file, "utf8");
    for (const [name, fields] of Object.entries(schemas)) {
      const re = new RegExp(`${name}\\.(\\w+)`, "g");
      for (const match of text.matchAll(re)) {
        const field = match[1];
        if (!fields.includes(field) && !["id", "created_at", "updated_at"].includes(field)) {
          errors.push(`${file}: ${name}.${field} not in schema`);
        }
      }
    }
  }

  if (errors.length) {
    console.error("Hallucinated fields detected:");
    errors.forEach((e) => console.error(`  ${e}`));
    process.exit(1);
  }
}

main();

This is a static check that catches the most common hallucinations. Refine the regex for your code style.

3. Smoke-test every agent change with real data

Maintain a small test suite that exercises every code path against real-data records, not mock data. Run it after every agent change. The tests do not have to be exhaustive — they need to touch every component the agent might have changed.

// tests/smoke.test.ts
test("customer detail page renders against real customer", async () => {
  const customer = await base44.collection("customers").list({ limit: 1 });
  expect(customer[0]).toBeDefined();
  // Render the page in a headless browser, assert no console errors.
  await page.goto(`/customers/${customer[0].id}`);
  const errors = await page.evaluate(() => window._consoleErrors ?? []);
  expect(errors).toHaveLength(0);
});

If you cannot run a headless browser, even a simple "fetch the page and assert HTTP 200 plus expected text" works.

4. Audit fetch calls against an allowlist

For external API calls, maintain an allowlist of legitimate URLs your app uses. Lint to fail any fetch that targets a URL not on the list.

// scripts/check-fetch-allowlist.ts
const ALLOWED_HOSTS = ["api.stripe.com", "api.openai.com", "hooks.slack.com"];
// Walk source, find fetch(...) and new URL(...) calls, extract the host, fail if not in ALLOWED_HOSTS.

This catches hallucinated third-party URLs the agent invented.

5. Keep a "verified APIs" doc

Maintain a docs/integrations.md file in your repo that lists every external service your app integrates with, the exact URL, and the auth method. Reference this file in every prompt that involves integration code: "Use only the integrations listed in docs/integrations.md."

6. Use feature flags for new agent-generated code

Wrap every new feature in a feature flag so you can disable it instantly if hallucinations slip through to production. Roll out to staff first, then a small percentage of users, then everyone.

DIY vs hire decision

DIY this if: You have a small project and you can spare a day to set up the field-validation script and a basic smoke test suite. The workflow change is the main fix.

Hire help if: You have already shipped hallucinated code to customers, you have integrations with multiple third-party APIs, or your team does not have a quality-assurance process. Our fix-sprint sets up the schema-validation CI step, the smoke-test rig, the fetch-allowlist linter, and a written prompt-discipline guide for your team. Most teams see hallucination escapes drop to under 5 percent of changes within two weeks of the engagement.

Need this fixed in 48 hours?

Our fix-sprint instruments your CI with field validation, fetch-allowlist linting, and a real-data smoke test suite. Includes a prompt-discipline guide your team can adopt immediately.

Start a fix sprint for hallucination protection

AI agent regression loop breaks working code — the larger pattern of agent-introduced regressions that hallucinations are part of.
AI forgets context once the window overflows — the agent's drift back to training-data patterns is worst when context is lost.
Prompt conflicts produce contradictory code — a sibling failure mode in the agent's code generation pipeline.