I once asked an AI to build a brand website. What came back looked convincing at first glance, but it was broken in the

I once asked an AI to build a brand website. What came back looked convincing at first glance, but it was broken in the ways that actually matter. The header showed exactly two links. There was no "About" page anywhere. An admin panel existed on the backend, yet no button or route on the frontend could actually reach it. The server side functioned. The user side did not.

Most people who run into this assume the AI got lazy or hit a token limit. That is not what is happening. The issue is structural. AI coding tools are built to police internal consistency. They ask: "Does everything I declared line up with itself?" They do not ask: "Does this kind of deliverable contain everything it is supposed to contain?" If you mention two pages for your brand site, the model dutifully checks whether those two pages link back to each other. Once the links resolve, it considers the task complete. It has no inherent notion that a brand site needs an About page, trust signals, or a contact path. There is no standard in its head.

I call the fix a Completeness Baseline.

A completeness baseline is simply a standard checklist of what a given deliverable must contain. You generate the artifact, then you check the real output against this external standard instead of trusting the tool's internal sense of "done."

Checking Across Three Layers

Not all missing pieces are equally obvious. A useful baseline checks three distinct layers.

Existence. Does the part actually exist? This sounds basic, but an AI will happily build a navigation wrapper that references a dashboard page without ever generating the dashboard page itself. The reference exists. The target does not.

Reachability. Can a real user actually get to it? Hidden admin panels are the classic symptom. The route and the component might both exist in the codebase, yet no menu item, button, or redirect exposes them to the interface. If a user cannot trip over it during normal use, it is not really there.

Substantiation. Is there real data or structure behind the surface? A page that loads but contains only placeholder text and no image upload slot is a skeleton wearing a costume. An About page without an image slot or editable text field is not complete, even if the HTML renders cleanly.

These three layers catch different classes of gaps. Existence finds the missing shoe. Reachability finds the shoe locked in a closet. Substantiation finds the shoe with no sole.

Baselines by Type

One baseline will not cover every project. You need to classify what you are building and define the non-negotiables for that category.

Brand sites need specific sections and reachable pages. Think About, Contact, privacy links, and navigation that actually exposes every major view.

APIs need documentation, exhaustive error codes, and rate limits. A working endpoint that returns 200 OK for success and a generic 500 for everything else is not a finished API. It is a hazard.

Automations need logs and failure alerts. If a workflow breaks at 2 AM and nobody knows until a human checks the run history, the automation is incomplete. Observability is not a bonus feature. It is part of the deliverable.

Once you name the category, the baseline writes itself. The hard part is enforcing it after the code is generated.

Design Rules That Hold Up

I rebuilt my own workflow around this idea and landed on three practical rules that keep projects from slowly unraveling.

Capability-gated design. Before you commit to a tool or a generated module, detect what it can actually do. If a component library lacks native mobile drawer support, do not let the AI generate a full navigation scheme that assumes it exists. The system should degrade gracefully instead of breaking when a capability is missing. Know the boundaries first. Design inside them.

Public engine, private values. Use a public engine for the heavy lifting, but inject your private data, configs, and conventions at runtime. This keeps your personal or company methods safe and separate from the generated scaffold. The AI builds the frame. You snap in the glass. This prevents the model from hard-coding assumptions that violate your actual standards or leak sensitive patterns into public training contexts.

Propón, no avances automáticamente. Deja que la IA sugiera el siguiente paso, pero obliga a un humano a tomar la decisión. Automatiza el flujo de ejecución, nunca el juicio. Cuando un modelo autogenera una migración de base de datos, un esquema de autenticación y un hook de pago de un solo tirón, obtienes conveniencia a costa de la supervisión. Haz que la herramienta presente el plan. Deja que el desarrollador presione el botón.

Elegir el modelo adecuado para el trabajo

Probé esto en diferentes modelos y encontré una clara división en el valor. Los modelos más económicos manejan el trabajo mecánico pesado sorprendentemente bien. Generan código repetitivo (boilerplate), componentes redundantes y esqueletos estructurales más rápido de lo que puedes escribir. Los modelos costosos justifican su precio solo cuando demuestran moderación. Quieres la opción premium cuando se niega a inventar soluciones falsas y, en su lugar, señala una brecha real. Un modelo que alucina una solución temporal para un endpoint de API inexistente es peligroso. Un modelo que se detiene y dice: «Este flujo de trabajo requiere un objetivo de webhook que no está definido», vale lo que cuesta. Paga por el discernimiento, no por el volumen.

Construye sistemas, no persigas la magia

No intentes solucionar las carencias de la IA lanzando modelos más grandes o más trucos de prompting al problema. Soluciónalas con una base de referencia (baseline). La brecha no es un problema de capacidad. Es un problema de expectativas.

Para evitar los bloques faltantes, haz tres cosas.

Dale al sistema una base de referencia de integridad antes de escribir cualquier código. Conviértela en una lista de verificación física que acompañe a la tarea.

Integra tus convenciones en piezas reutilizables. Si aplicas tu base de referencia mediante plantillas, reglas de lint o estructuras predefinidas (scaffolds), la IA comenzará desde una posición de corrección en lugar de esperar adivinar tus estándares.

Automatiza el flujo manteniendo a un humano al mando del juicio. Deja que las máquinas se encarguen de la repetición. Reserva las decisiones para las personas que comprenden el contexto.

Aquí hay un último hábito que cambió mi forma de trabajar. Si tomas la misma decisión de diseño siete veces, deja de tratarla como una elección aislada. Eso no es repetición. Eso es una ley. Ponle nombre. Conviértela en una regla. Documéntala. Cuando codificas el patrón, eliminas la posibilidad de que una IA se desvíe de él la octava vez.

La fuente de este marco de trabajo y la exploración original pueden encontrarse aquí.

Si quieres intercambiar ideas con otros que enfrentan los mismos problemas, puedes unirte a la comunidad de aprendizaje de GyaanSetu.