ഒരിക്കൽ ഞാൻ ഒരു AI-യോട് ഒരു ബ്രാൻഡ് വെബ്സൈറ്റ് നിർമ്മിക്കാൻ ആവശ്യപ്പെട്ടു. ആദ്യ കാഴ്ചയിൽ അത് വിശ്വസനീയമായി തോന്നിയിരുന്നെങ്കിലും, യഥാർത്ഥത്തിൽ ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങളിൽ അത് പരാജയപ്പെട്ടു. ഹെഡറിൽ കൃത്യം രണ്ട് ലിങ്കുകൾ മാത്രമേ ഉണ്ടായിരുന്നുള്ളൂ. എവിടെയും ഒരു "About" പേജ് ഉണ്ടായിരുന്നില്ല. ബാക്കെൻഡിൽ ഒരു അഡ്മിൻ പാനൽ ഉണ്ടായിരുന്നുവെങ്കിലും, ഫ്രണ്ട്‌എൻഡിലെ ഒരു ബട്ടണിലൂടെയോ റൂട്ടിലൂടെയോ അതിൽ എത്തിച്ചേരാൻ സാധിക്കുമായിരുന്നില്ല. സെർവർ സൈഡ് പ്രവർത്തിച്ചു, എന്നാൽ യൂസർ സൈഡ് പ്രവർത്തിച്ചില്ല.

ഇത്തരത്തിൽ സംഭവിക്കുമ്പോൾ മിക്കവരും കരുതുന്നത് AI മടിയനായതുകൊണ്ടോ അല്ലെങ്കിൽ ടോക്കൺ ലിമിറ്റ് (token limit) വന്നതുകൊണ്ടോ ആണെന്നാണ്. എന്നാൽ സംഭവിക്കുന്നത് അതല്ല. പ്രശ്നം ഘടനാപരമാണ് (structural). AI കോഡിംഗ് ടൂളുകൾ നിർമ്മിച്ചിരിക്കുന്നത് ആന്തരികമായ പൊരുത്തം (internal consistency) പരിശോധിക്കാനാണ്. അവ ചോദിക്കുന്നത്: "ഞാൻ പ്രഖ്യാപിച്ചതെല്ലാം പരസ്പരം യോജിക്കുന്നുണ്ടോ?" എന്നാണ്. എന്നാൽ അവ ചോദിക്കാത്തത്: "ഈ ഡെലിവറബിളിൽ (deliverable) ഉണ്ടായിരിക്കേണ്ട എല്ലാ കാര്യങ്ങളും ഉണ്ടോ?" എന്നാണ്. നിങ്ങളുടെ ബ്രാൻഡ് സൈറ്റിനായി രണ്ട് പേജുകൾ എന്ന് നിങ്ങൾ പറഞ്ഞാൽ, ആ രണ്ട് പേജുകളും പരസ്പരം ലിങ്ക് ചെയ്തിട്ടുണ്ടോ എന്ന് മാത്രം ആ മോഡൽ പരിശോധിക്കും. ലിങ്കുകൾ ശരിയാണെന്ന് കണ്ടാൽ ജോലി പൂർത്തിയായി എന്ന് അത് കരുതും. ഒരു ബ്രാൻഡ് സൈറ്റിന് ഒരു 'About' പേജോ, വിശ്വാസ്യത നൽകുന്ന വിവരങ്ങളോ (trust signals), അല്ലെങ്കിൽ ഒരു കോൺടാക്റ്റ് പേജോ ആവശ്യമാണെന്നതിനെക്കുറിച്ച് അതിന് അടിസ്ഥാനപരമായ ധാരണയില്ല. അതിന്റെ ഉള്ളിൽ ഒരു മാനദണ്ഡവുമില്ല.

ഇതിനുള്ള പരിഹാരത്തെ ഞാൻ Completeness Baseline എന്ന് വിളിക്കുന്നു.

ഒരു completeness baseline എന്നത് ഒരു ഡെലിവറബിളിൽ എന്തൊക്കെ ഉണ്ടായിരിക്കണം എന്നതിനായുള്ള ഒരു ചെക്ക്‌ലിസ്റ്റ് മാത്രമാണ്. നിങ്ങൾ ആ ഉൽപ്പന്നം (artifact) നിർമ്മിച്ച ശേഷം, ടൂളിന്റെ "പൂർത്തിയായി" എന്ന ആന്തരിക ധാരണയെ വിശ്വസിക്കുന്നതിന് പകരം, ഈ ബാഹ്യ മാനദണ്ഡവുമായി താരതമ്യം ചെയ്ത് യഥാർത്ഥ ഔട്ട്‌പുട്ട് പരിശോധിക്കുക.

Checking Across Three Layers

എല്ലാ കുറവുകളും ഒരുപോലെ വ്യക്തമായിരിക്കില്ല. ഒരു നല്ല baseline മൂന്ന് വ്യത്യസ്ത തലങ്ങളിൽ പരിശോധന നടത്തുന്നു.

Existence (നിലനിൽപ്പ്). ആ ഭാഗം യഥാർത്ഥത്തിൽ ഉണ്ടോ? ഇത് കേൾക്കുമ്പോൾ ലളിതമായി തോന്നാം, എന്നാൽ ഒരു ഡാഷ്‌ബോർഡ് പേജ് നിർമ്മിക്കാതെ തന്നെ, ആ പേജിലേക്ക് റഫറൻസ് നൽകുന്ന ഒരു നാവിഗേഷൻ റാപ്പർ (navigation wrapper) നിർമ്മിക്കാൻ AI സന്തോഷത്തോടെ തയ്യാറാകും. റഫറൻസ് അവിടെയുണ്ടാകും, പക്ഷേ ലക്ഷ്യസ്ഥാനം (target) ഉണ്ടാവില്ല.

Reachability (എത്തിച്ചേരാനുള്ള സാധ്യത). ഒരു യഥാർത്ഥ ഉപയോക്താവിന് അതിൽ എത്തിച്ചേരാൻ കഴിയുമോ? ഒളിഞ്ഞിരിക്കുന്ന അഡ്മിൻ പാനലുകൾ ഇതിന് ഉദാഹരണമാണ്. കോഡ്ബേസിൽ റൂട്ടും കമ്പോണന്റും ഉണ്ടായേക്കാം, എന്നാൽ ഒരു മെനു ഐറ്റമോ ബട്ടണോ അവയെ ഇന്റർഫേസിലേക്ക് എത്തിക്കുന്നില്ലെങ്കിൽ അവ അവിടെയില്ല എന്ന് തന്നെ കരുതാം. സാധാരണ ഉപയോഗത്തിനിടയിൽ ഒരു ഉപയോക്താവിന് അത് കാണാൻ സാധിക്കുന്നില്ലെങ്കിൽ, അത് യഥാർത്ഥത്തിൽ അവിടെയില്ല.

Substantiation (ഉള്ളടക്കത്തിന്റെ ആധികാരികത). ഉപരിതലത്തിന് പിന്നിൽ യഥാർത്ഥ ഡാറ്റയോ ഘടനയോ ഉണ്ടോ? ഒരു പേജ് ലോഡ് ആകുന്നുണ്ടെങ്കിലും അതിൽ പ്ലേസ്‌ഹോൾഡർ ടെക്സ്റ്റുകൾ (placeholder text) മാത്രമാണുള്ളതെങ്കിൽ, അത് വെറുമൊരു രൂപം മാത്രമാണ്. ഒരു ഇമേജ് അപ്‌ലോഡ് സൗകര്യമോ എഡിറ്റ് ചെയ്യാവുന്ന ടെക്സ്റ്റ് ഫീൽഡോ ഇല്ലാത്ത ഒരു 'About' പേജ്, അതിന്റെ HTML കൃത്യമായി കാണപ്പെടുന്നുണ്ടെങ്കിൽ പോലും പൂർണ്ണമല്ല.

ഈ മൂന്ന് തലങ്ങൾ വ്യത്യസ്ത തരത്തിലുള്ള പോരായ്മകൾ കണ്ടെത്താൻ സഹായിക്കുന്നു. Existence എന്നത് കാണാതായ ഒരു ഷൂവിനെ കണ്ടെത്തുന്നു. Reachability എന്നത് അലമാരയിൽ പൂട്ടിയിട്ടിരിക്കുന്ന ഷൂവിനെ കണ്ടെത്തുന്നു. Substantiation എന്നത് അടി ഇല്ലാത്ത ഷൂവിനെ കണ്ടെത്തുന്നു.

Baselines by Type

ഒരു baseline കൊണ്ട് എല്ലാ പ്രോജക്റ്റുകളും കവർ ചെയ്യാൻ കഴിയില്ല. നിങ്ങൾ എന്താണ് നിർമ്മിക്കുന്നത് എന്ന് തരംതിരിക്കുകയും ആ വിഭാഗത്തിന് ആവശ്യമായ കാര്യങ്ങൾ നിർണ്ണയിക്കുകയും വേണം.

Brand sites-ന് പ്രത്യേക വിഭാഗങ്ങളും എത്തിച്ചേരാൻ കഴിയുന്ന പേജുകളും ആവശ്യമാണ്. About, Contact, പ്രൈവസി ലിങ്കുകൾ, കൂടാതെ എല്ലാ പ്രധാന കാഴ്ചകളും കാണിക്കുന്ന നാവിഗേഷൻ എന്നിവ ഇതിൽ ഉൾപ്പെടുന്നു.

APIs-ന് ഡോക്യുമെന്റേഷൻ (documentation), സമഗ്രമായ എറർ കോഡുകൾ (error codes), റേറ്റ് ലിമിറ്റുകൾ (rate limits) എന്നിവ ആവശ്യമാണ്. വിജയത്തിന് 200 OK എന്നും മറ്റെല്ലാത്തിനും ജനറിക് ആയ 500 എറർ കോഡും നൽകുന്ന ഒരു വർക്കിംഗ് എൻഡ്‌പോയിന്റ് (endpoint) പൂർത്തിയായ ഒരു API അല്ല. അത് അപകടകരമാണ്.

Automations-ന് ലോഗുകളും (logs) പരാജയ അറിയിപ്പുകളും (failure alerts) ആവശ്യമാണ്. ഒരു വർക്ക്ഫ്ലോ പുലർച്ചെ 2 മണിക്ക് തകരാറിലാകുകയും, ഒരാൾ ഹിസ്റ്ററി പരിശോധിക്കുന്നത് വരെ ആരും അത് അറിയാതിരിക്കുകയും ചെയ്യുന്നുണ്ടെങ്കിൽ, ആ ഓട്ടോമേഷൻ അപൂർണ്ണമാണ്. Observability എന്നത് ഒരു അധിക സവിശേഷതയല്ല, അത് ഡെലിവറബിളിന്റെ ഭാഗമാണ്.

ഒരിക്കൽ നിങ്ങൾ വിഭാഗം നിശ്ചയിച്ചു കഴിഞ്ഞാൽ, baseline തനിയെ തയ്യാറാകും. കോഡ് നിർമ്മിച്ചതിന് ശേഷം അത് നടപ്പിലാക്കുക എന്നതാണ് പ്രയാസകരമായ കാര്യം.

Design Rules That Hold Up

ഞാൻ എന്റെ പ്രവർത്തനരീതി ഈ ആശയത്തിന് ചുറ്റും പുനർനിർമ്മിക്കുകയും പ്രോജക്റ്റുകൾ തകരാതിരിക്കാൻ സഹായിക്കുന്ന മൂന്ന് പ്രായോഗിക നിയമങ്ങൾ കണ്ടെത്തുകയും ചെയ്തു.

Capability-gated design. ഒരു ടൂളിനോ നിർമ്മിച്ച മോഡ്യൂളിനോ എന്ത് ചെയ്യാൻ കഴിയുമെന്ന് ആദ്യം മനസ്സിലാക്കുക. ഒരു കമ്പോണന്റ് ലൈബ്രറിയിൽ മൊബൈൽ ഡ്രോവർ (mobile drawer) സപ്പോർട്ട് ഇല്ലെങ്കിൽ, അത് ഉണ്ടെന്ന് കരുതി ഒരു നാവിഗേഷൻ സ്കീം നിർമ്മിക്കാൻ AI-യോട് ആവശ്യപ്പെടരുത്. ഒരു കപ്പാസിറ്റി ഇല്ലാത്തപ്പോൾ സിസ്റ്റം തകരാതെ ഇരിക്കണം. പരിധികൾ ആദ്യം അറിയുക. അതിനുള്ളിൽ നിന്ന് ഡിസൈൻ ചെയ്യുക.

Public engine, private values. കഠിനമായ ജോലികൾക്കായി ഒരു പബ്ലിക് എൻജിൻ ഉപയോഗിക്കുക, എന്നാൽ നിങ്ങളുടെ സ്വകാര്യ ഡാറ്റയും കോൺഫിഗറേഷനുകളും റൺടൈമിൽ (runtime) മാത്രം ഉൾപ്പെടുത്തുക. ഇത് നിങ്ങളുടെ വ്യക്തിഗതമായോ കമ്പനിയുടെയോ രീതികളെ സുരക്ഷിതമായും വേറിട്ടുനിർത്താനും സഹായിക്കുന്നു. AI ഫ്രെയിം നിർമ്മിക്കുന്നു, നിങ്ങൾ അതിൽ ഗ്ലാസ് ഘടിപ്പിക്കുന്നു. നിങ്ങളുടെ യഥാർത്ഥ മാനദണ്ഡങ്ങളെ ലംഘിക്കുന്ന രീതിയിൽ കാര്യങ്ങൾ കോഡ് ചെയ്യാതിരിക്കാൻ ഇത് സഹായിക്കുന്നു.

Propose, do not auto-advance. Let the AI suggest the next step, but force a human to make the choice. Automate the flow of execution, never the judgment. When a model auto-generates a database migration, an auth scheme, and a payment hook in one breath, you get convenience at the cost of oversight. Make the tool present the plan. Let the developer press the button.

Picking the Right Model for the Job

I tested this across different models and found a clear split in value. Cheaper models handle mechanical bulk shockingly well. They churn out boilerplate, repetitive components, and structural stubs faster than you can type. The expensive models earn their price only when they demonstrate restraint. You want the premium option when it refuses to invent fake fixes and instead flags a genuine gap. A model that hallucinates a workaround for a missing API endpoint is dangerous. A model that stops and says, "This workflow requires a webhook target that is not defined," is worth the cost. Pay for discernment, not volume.

Build Systems, Don't Chase Magic

Do not try to fix AI gaps by throwing bigger models or more prompting tricks at the problem. Fix them with a baseline. The gap is not a capacity problem. It is an expectations problem.

To stop the missing blocks, do three things.

Give the system a completeness baseline before any code is written. Make it a physical checklist that lives next to the task.

Bake your conventions into reusable parts. If you enforce your baseline through templates, lint rules, or pre-built scaffolds, the AI starts from a position of correctness rather than hoping it guesses your standards.

Automate the flow while keeping a human in control of judgment. Let the machines handle repetition. Reserve the decisions for people who understand the context.

Here is one last habit that changed how I work. If you make the same design decision seven times, stop treating it as a one-off choice. That is not repetition. That is a law. Name it. Turn it into a rule. Document it. When you codify the pattern, you remove the chance that an AI will drift away from it the eighth time.

The source for this framework and the original exploration can be found here.

If you want to trade notes with others working through the same problems, you can join the GyaanSetu learning community.