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.

દરખાસ્ત કરો, આપમેળે આગળ ન વધો. AI ને આગલું પગલું સૂચવવા દો, પરંતુ નિર્ણય લેવા માટે માણસને મજબૂર કરો. અમલીકરણના પ્રવાહને (flow of execution) ઓટોમેટ કરો, ક્યારેય નિર્ણય લેવાની પ્રક્રિયાને નહીં. જ્યારે કોઈ મોડેલ એકસાથે ડેટાબેઝ માઈગ્રેશન, ઓથ સ્કીમ (auth scheme) અને પેમેન્ટ હૂક જનરેટ કરી દે છે, ત્યારે તમે દેખરેખના ભોગે સુવિધા મેળવો છો. સાધનને યોજના રજૂ કરવા દો. ડેવલપરને બટન દબાવવા દો.

કામ માટે યોગ્ય મોડેલની પસંદગી કરવી

મેં વિવિધ મોડેલ્સ પર આનું પરીક્ષણ કર્યું અને મૂલ્યમાં સ્પષ્ટ તફાવત જોયો. સસ્તા મોડેલ્સ યાંત્રિક કામગીરીને આશ્ચર્યજનક રીતે સારી રીતે સંભાળી લે છે. તેઓ તમે ટાઈપ કરી શકો તેના કરતા પણ ઝડપથી બોઈલરપ્લેટ (boilerplate), પુનરાવર્તિત ઘટકો અને સ્ટ્રક્ચરલ સ્ટબ્સ તૈયાર કરી દે છે. મોંઘા મોડેલ્સ ત્યારે જ તેમના ભાવને યોગ્ય ઠેરવે છે જ્યારે તેઓ સંયમ દર્શાવે છે. જ્યારે મોડેલ ખોટા ઉકેલો શોધવાને બદલે વાસ્તવિક ખામીને ઓળખીને તેને દર્શાવે, ત્યારે તમારે પ્રીમિયમ વિકલ્પની જરૂર હોય છે. જે મોડેલ ખૂટતા API એન્ડપોઈન્ટ માટે કાલ્પનિક ઉપાય (hallucinate a workaround) શોધે છે તે જોખમી છે. જે મોડેલ અટકી જાય અને કહે, "આ વર્કફ્લો માટે એવા વેબહૂક ટાર્ગેટની જરૂર છે જે વ્યાખ્યાયિત નથી," તે ખર્ચને યોગ્ય ઠેરવે છે. માત્ર જથ્થા માટે નહીં, પણ વિવેકબુદ્ધિ માટે ચૂકવણી કરો.

સિસ્ટમ બનાવો, જાદુની પાછળ ન દોડો

મોટા મોડેલ્સ અથવા વધુ પ્રોમ્પ્ટિંગ ટ્રિક્સનો ઉપયોગ કરીને AI ની ખામીઓને સુધારવાનો પ્રયાસ કરશો નહીં. તેને બેઝલાઇન (baseline) દ્વારા સુધારો. આ ખામી ક્ષમતાની સમસ્યા નથી, પણ અપેક્ષાઓની સમસ્યા છે.

ખૂટતા બ્લોક્સને રોકવા માટે, ત્રણ વસ્તુઓ કરો.

કોડ લખતા પહેલા સિસ્ટમને પૂર્ણતાની બેઝલાઇન આપો. તેને એક ભૌતિક ચેકલિસ્ટ બનાવો જે કાર્યની સાથે જ રહે.

તમારા નિયમોને (conventions) ફરીથી ઉપયોગ કરી શકાય તેવા ભાગોમાં સામેલ કરો. જો તમે ટેમ્પલેટ્સ, લિન્ટ રૂલ્સ અથવા પ્રી-બિલ્ટ સ્કેફોલ્ડ્સ દ્વારા તમારી બેઝલાઇન લાગુ કરો છો, તો AI તમારા ધોરણોનો અંદાજ લગાવવાની આશા રાખવાને બદલે સચોટતાના સ્થાનેથી શરૂઆત કરશે.

નિર્ણય લેવાની પ્રક્રિયા માણસના નિયંત્રણમાં રાખીને પ્રવાહને ઓટોમેટ કરો. મશીનોને પુનરાવર્તિત કામ કરવા દો. નિર્ણયો એવા લોકો માટે રાખો જે સંદર્ભ (context) ને સમજી શકે છે.

અહીં એક છેલ્લી આદત છે જેણે મારા કામ કરવાની રીત બદલી નાખી. જો તમે સાત વખત એક જ ડિઝાઇન નિર્ણય લો છો, તો તેને માત્ર એક વખતનો વિકલ્પ માનવાનું બંધ કરો. તે પુનરાવર્તન નથી, તે એક નિયમ છે. તેને નામ આપો. તેને નિયમમાં ફેરવો. તેને ડોક્યુમેન્ટ કરો. જ્યારે તમે પેટર્નને કોડિફાય (codify) કરો છો, ત્યારે તમે એ શક્યતા દૂર કરો છો કે આઠમી વખત AI તેનાથી વિચલિત થઈ જાય.

આ ફ્રેમવર્ક અને મૂળ સંશોધનનો સ્ત્રોત અહીં મળી શકે છે.

જો તમે સમાન સમસ્યાઓ પર કામ કરી રહેલા અન્ય લોકો સાથે ચર્ચા કરવા માંગતા હોવ, તો તમે GyaanSetu learning community માં જોડાઈ શકો છો.