ਮੈਂ ਇੱਕ ਵਾਰ ਇੱਕ AI ਨੂੰ ਇੱਕ ਬ੍ਰਾਂਡ ਵੈੱਬਸਾਈਟ ਬਣਾਉਣ ਲਈ ਕਿਹਾ ਸੀ। ਜੋ ਨਤੀਜਾ ਆਇਆ ਉਹ ਪਹਿਲੀ ਨਜ਼ਰ ਵਿੱਚ ਭਰੋਸੇਯੋਗ ਲੱਗ ਰਿਹਾ ਸੀ, ਪਰ ਇਹ ਉਹਨਾਂ ਤਰੀਕਿਆਂ ਨਾਲ ਖਰਾਬ ਸੀ ਜੋ ਅਸਲ ਵਿੱਚ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ। ਹੈਡਰ ਵਿੱਚ ਸਿਰਫ਼ ਦੋ ਲਿੰਕ ਦਿਖਾਈ ਦੇ ਰਹੇ ਸਨ। ਕਿਤੇ ਵੀ "About" ਪੇਜ ਨਹੀਂ ਸੀ। ਬੈਕਐਂਡ 'ਤੇ ਇੱਕ ਐਡਮਿਨ ਪੈਨਲ ਮੌਜੂਦ ਸੀ, ਫਿਰ ਵੀ ਫਰੰਟਐਂਡ 'ਤੇ ਕੋਈ ਬਟਨ ਜਾਂ ਰੂਟ ਨਹੀਂ ਸੀ ਜੋ ਅਸਲ ਵਿੱਚ ਉਸ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਸੀ। ਸਰਵਰ ਸਾਈਡ ਕੰਮ ਕਰ ਰਹੀ ਸੀ। ਯੂਜ਼ਰ ਸਾਈਡ ਨਹੀਂ।

ਜ਼ਿਆਦਾਤਰ ਲੋਕ ਜੋ ਇਸ ਦਾ ਸਾਹਮਣਾ ਕਰਦੇ ਹਨ, ਉਹ ਮੰਨ ਲੈਂਦੇ ਹਨ ਕਿ AI ਆਲਸੀ ਹੋ ਗਿਆ ਹੈ ਜਾਂ ਟੋਕਨ ਲਿਮਿਟ (token limit) ਖਤਮ ਹੋ ਗਈ ਹੈ। ਅਜਿਹਾ ਨਹੀਂ ਹੋ ਰਿਹਾ ਹੈ। ਸਮੱਸਿਆ ਬਣਤਰ (structural) ਦੀ ਹੈ। AI ਕੋਡਿੰਗ ਟੂਲਸ ਅੰਦਰੂਨੀ ਇਕਸਾਰਤਾ (internal consistency) ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਬਣਾਏ ਗਏ ਹਨ। ਉਹ ਪੁੱਛਦੇ ਹਨ: "ਕੀ ਜੋ ਕੁਝ ਮੈਂ ਘੋਸ਼ਿਤ ਕੀਤਾ ਹੈ, ਉਹ ਆਪਣੇ ਆਪ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ?" ਉਹ ਇਹ ਨਹੀਂ ਪੁੱਛਦੇ: "ਕੀ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਡਿਲੀਵਰੇਬਲ (deliverable) ਵਿੱਚ ਉਹ ਸਭ ਕੁਝ ਸ਼ਾਮਲ ਹੈ ਜੋ ਇਸ ਨੂੰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ?" ਜੇਕਰ ਤੁਸੀਂ ਆਪਣੇ ਬ੍ਰਾਂਡ ਸਾਈਟ ਲਈ ਦੋ ਪੇਜਾਂ ਦਾ ਜ਼ਿਕਰ ਕਰਦੇ ਹੋ, ਤਾਂ ਮਾਡਲ ਵਫ਼ਾਦਾਰੀ ਨਾਲ ਇਹ ਚੈੱਕ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਉਹ ਦੋਵੇਂ ਪੇਜ ਇੱਕ ਦੂਜੇ ਨਾਲ ਲਿੰਕ ਹਨ। ਇੱਕ ਵਾਰ ਲਿੰਕ ਮਿਲ ਜਾਣ 'ਤੇ, ਉਹ ਕੰਮ ਨੂੰ ਪੂਰਾ ਮੰਨ ਲੈਂਦਾ ਹੈ। ਉਸ ਕੋਲ ਇਹ ਅੰਦਰੂਨੀ ਸਮਝ ਨਹੀਂ ਹੈ ਕਿ ਇੱਕ ਬ੍ਰਾਂਡ ਸਾਈਟ ਨੂੰ 'About' ਪੇਜ, ਭਰੋਸੇ ਦੇ ਸੰਕੇਤ (trust signals), ਜਾਂ ਸੰਪਰਕ ਦਾ ਰਸਤਾ ਚਾਹੀਦਾ ਹੁੰਦਾ ਹੈ। ਉਸ ਦੇ ਦਿਮਾਗ ਵਿੱਚ ਕੋਈ ਮਿਆਰ (standard) ਨਹੀਂ ਹੈ।

ਮੈਂ ਇਸ ਦੇ ਹੱਲ ਨੂੰ Completeness Baseline ਕਹਿੰਦਾ ਹਾਂ।

Completeness baseline ਸਿਰਫ਼ ਇੱਕ ਮਿਆਰੀ ਚੈੱਕਲਿਸਟ ਹੈ ਕਿ ਕਿਸੇ ਦਿੱਤੇ ਗਏ ਡਿਲੀਵਰੇਬਲ ਵਿੱਚ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਤੁਸੀਂ ਆਰਟੀਫੈਕਟ (artifact) ਤਿਆਰ ਕਰਦੇ ਹੋ, ਫਿਰ ਤੁਸੀਂ ਟੂਲ ਦੇ "ਪੂਰਾ ਹੋਣ" ਦੇ ਅੰਦਰੂਨੀ ਅਹਿਸਾਸ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਬਜਾਏ ਇਸ ਬਾਹਰੀ ਮਿਆਰ ਦੇ ਵਿਰੁੱਧ ਅਸਲ ਆਉਟਪੁੱਟ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹੋ।

ਤਿੰਨ ਪਰਤਾਂ (layers) ਵਿੱਚ ਜਾਂਚ ਕਰਨਾ

ਸਾਰੇ ਗੁੰਮ ਹੋਏ ਹਿੱਸੇ ਬਰਾਬਰ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੁੰਦੇ। ਇੱਕ ਲਾਹੇਵੰਦ ਬੇਸਲਾਈਨ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਪਰਤਾਂ ਦੀ ਜਾਂਚ ਕਰਦੀ ਹੈ।

Existence (ਹੋਂਦ)। ਕੀ ਉਹ ਹਿੱਸਾ ਅਸਲ ਵਿੱਚ ਮੌਜੂਦ ਹੈ? ਇਹ ਬਹੁਤ ਹੀ ਮੁੱਢਲਾ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਇੱਕ AI ਖੁਸ਼ੀ-ਖੁਸ਼ੀ ਇੱਕ ਨੈਵੀਗੇਸ਼ਨ ਵੈਪਰ (navigation wrapper) ਬਣਾ ਦੇਵੇਗਾ ਜੋ ਡੈਸ਼ਬੋਰਡ ਪੇਜ ਦਾ ਹਵਾਲਾ ਤਾਂ ਦਿੰਦਾ ਹੈ ਪਰ ਖੁਦ ਡੈਸ਼ਬੋਰਡ ਪੇਜ ਕਦੇ ਬਣਾਉਂਦਾ ਹੀ ਨਹੀਂ। ਹਵਾਲਾ ਮੌਜੂਦ ਹੈ। ਪਰ ਟਾਰਗੇਟ (target) ਨਹੀਂ ਹੈ।

Reachability (ਪਹੁੰਚਯੋਗਤਾ)। ਕੀ ਇੱਕ ਅਸਲ ਯੂਜ਼ਰ ਅਸਲ ਵਿੱਚ ਉਸ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ? ਲੁਕੇ ਹੋਏ ਐਡਮਿਨ ਪੈਨਲ ਇਸ ਦਾ ਕਲਾਸਿਕ ਲੱਛਣ ਹਨ। ਰੂਟ (route) ਅਤੇ ਕੰਪੋਨੈਂਟ (component) ਦੋਵੇਂ ਕੋਡਬੇਸ ਵਿੱਚ ਮੌਜੂਦ ਹੋ ਸਕਦੇ ਹਨ, ਫਿਰ ਵੀ ਕੋਈ ਮੀਨੂ ਆਈਟਮ, ਬਟਨ, ਜਾਂ ਰੀਡਾਇਰੈਕਟ (redirect) ਉਹਨਾਂ ਨੂੰ ਇੰਟਰਫੇਸ 'ਤੇ ਨਹੀਂ ਦਿਖਾਉਂਦਾ। ਜੇਕਰ ਕੋਈ ਯੂਜ਼ਰ ਆਮ ਵਰਤੋਂ ਦੌਰਾਨ ਉਸ ਨੂੰ ਦੇਖ ਨਹੀਂ ਸਕਦਾ, ਤਾਂ ਉਹ ਅਸਲ ਵਿੱਚ ਉੱਥੇ ਹੈ ਹੀ ਨਹੀਂ।

Substantiation (ਪੁਸ਼ਟੀ)। ਕੀ ਸਤ੍ਹਾ ਦੇ ਪਿੱਛੇ ਅਸਲ ਡੇਟਾ ਜਾਂ ਢਾਂਚਾ ਹੈ? ਇੱਕ ਪੇਜ ਜੋ ਲੋਡ ਹੁੰਦਾ ਹੈ ਪਰ ਜਿਸ ਵਿੱਚ ਸਿਰਫ਼ ਪਲੇਸਹੋਲਡਰ ਟੈਕਸਟ (placeholder text) ਹੈ ਅਤੇ ਕੋਈ ਇਮੇਜ ਅਪਲੋਡ ਸਲਾਟ ਨਹੀਂ ਹੈ, ਉਹ ਇੱਕ ਕੱਪੜੇ ਪਹਿਨਿਆ ਹੋਇਆ ਕੰਕਾਲ ਹੈ। ਇੱਕ 'About' ਪੇਜ ਜਿਸ ਵਿੱਚ ਇਮੇਜ ਸਲਾਟ ਜਾਂ ਐਡਿਟ ਕਰਨ ਯੋਗ ਟੈਕਸਟ ਫੀਲਡ ਨਹੀਂ ਹੈ, ਉਹ ਪੂਰਾ ਨਹੀਂ ਹੈ, ਭਾਵੇਂ HTML ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਰੈਂਡਰ (render) ਕਿਉਂ ਨਾ ਹੋ ਰਿਹਾ ਹੋਵੇ।

ਇਹ ਤਿੰਨ ਪਰਤਾਂ ਗੈਪਸ (gaps) ਦੀਆਂ ਵੱਖ-ਵੱਖ ਸ਼੍ਰੇਣੀਆਂ ਨੂੰ ਫੜਦੀਆਂ ਹਨ। Existence ਗੁੰਮ ਹੋਏ ਜੁੱਤੇ ਨੂੰ ਲੱਭ ਲੈਂਦੀ ਹੈ। Reachability ਅਲਮਾਰੀ ਵਿੱਚ ਬੰਦ ਜੁੱਤੇ ਨੂੰ ਲੱਭ ਲੈਂਦੀ ਹੈ। Substantiation ਬਿਨਾਂ ਤਲੇ ਵਾਲੇ ਜੁੱਤੇ ਨੂੰ ਲੱਭ ਲੈਂਦੀ ਹੈ।

ਕਿਸਮ ਅਨੁਸਾਰ ਬੇਸਲਾਈਨਾਂ

ਇੱਕ ਬੇਸਲਾਈਨ ਹਰ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਕਵਰ ਨਹੀਂ ਕਰੇਗੀ। ਤੁਹਾਨੂੰ ਇਹ ਵਰਗੀਕਰਨ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਕਿ ਤੁਸੀਂ ਕੀ ਬਣਾ ਰਹੇ ਹੋ ਅਤੇ ਉਸ ਸ਼੍ਰੇਣੀ ਲਈ ਗੈਰ-ਮੰਨਣਯੋਗ (non-negotiables) ਚੀਜ਼ਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

Brand sites ਨੂੰ ਖਾਸ ਸੈਕਸ਼ਨਾਂ ਅਤੇ ਪਹੁੰਚਯੋਗ ਪੇਜਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। About, Contact, privacy ਲਿੰਕਾਂ, ਅਤੇ ਅਜਿਹੀ ਨੈਵੀਗੇਸ਼ਨ ਬਾਰੇ ਸੋਚੋ ਜੋ ਅਸਲ ਵਿੱਚ ਹਰ ਮੇਜਰ ਵਿਊ (major view) ਨੂੰ ਦਿਖਾਉਂਦੀ ਹੋਵੇ।

APIs ਨੂੰ ਡਾਕੂਮੈਂਟੇਸ਼ਨ (documentation), ਵਿਸਤ੍ਰਿਤ ਐਰਰ ਕੋਡ (error codes), ਅਤੇ ਰੇਟ ਲਿਮਿਟਸ (rate limits) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਕੰਮ ਕਰ ਰਿਹਾ ਐਂਡਪੁਆਇੰਟ (endpoint) ਜੋ ਸਫਲਤਾ ਲਈ 200 OK ਅਤੇ ਬਾਕੀ ਸਭ ਕੁਝ ਲਈ ਇੱਕ ਆਮ 500 ਰਿਟਰਨ ਕਰਦਾ ਹੈ, ਉਹ ਇੱਕ ਮੁਕੰਮਲ API ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਖਤਰਾ ਹੈ।

Automations ਨੂੰ ਲੌਗਸ (logs) ਅਤੇ ਫੇਲ੍ਹਰ ਅਲਰਟਸ (failure alerts) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜੇਕਰ ਕੋਈ ਵਰਕਫਲੋ ਰਾਤ 2 ਵਜੇ ਟੁੱਟ ਜਾਂਦਾ ਹੈ ਅਤੇ ਜਦੋਂ ਤੱਕ ਕੋਈ ਇਨਸਾਨ ਰਨ ਹਿਸਟਰੀ ਚੈੱਕ ਨਹੀਂ ਕਰਦਾ ਉਦੋਂ ਤੱਕ ਕਿਸੇ ਨੂੰ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ, ਤਾਂ ਉਹ ਆਟੋਮੇਸ਼ਨ ਅਧੂਰੀ ਹੈ। ਅਬਜ਼ਰਵੇਬਿਲਟੀ (Observability) ਕੋਈ ਬੋਨਸ ਫੀਚਰ ਨਹੀਂ ਹੈ। ਇਹ ਡਿਲੀਵਰੇਬਲ ਦਾ ਹਿੱਸਾ ਹੈ।

ਇੱਕ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਸ਼੍ਰੇਣੀ ਦਾ ਨਾਮ ਰੱਖ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਬੇਸਲਾਈਨ ਆਪਣੇ ਆਪ ਲਿਖੀ ਜਾਂਦੀ ਹੈ। ਔਖਾ ਹਿੱਸਾ ਕੋਡ ਜਨਰੇਟ ਹੋਣ ਤੋਂ ਬਾਅਦ ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਹੈ।

ਡਿਜ਼ਾਈਨ ਨਿਯਮ ਜੋ ਟਿਕਦੇ ਹਨ

ਮੈਂ ਇਸ ਵਿਚਾਰ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਆਪਣੇ ਵਰਕਫਲੋ ਨੂੰ ਮੁੜ ਬਣਾਇਆ ਅਤੇ ਤਿੰਨ ਵਿਵਹਾਰਕ ਨਿਯਮਾਂ 'ਤੇ ਪਹੁੰਚਿਆ ਜੋ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਹੌਲੀ-ਹੌਲੀ ਖਰਾਬ ਹੋਣ ਤੋਂ ਰੋਕਦੇ ਹਨ।

Capability-gated design। ਕਿਸੇ ਟੂਲ ਜਾਂ ਜਨਰੇਟ ਕੀਤੇ ਗਏ ਮੋਡੀਊਲ (module) ਲਈ ਵਚਨਬੱਧ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਪਤਾ ਲਗਾਓ ਕਿ ਉਹ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਕਿਸੇ ਕੰਪੋਨੈਂਟ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਨੇਟਿਵ ਮੋਬਾਈਲ ਡਰਾਅਰ (mobile drawer) ਸਪੋਰਟ ਦੀ ਕਮੀ ਹੈ, ਤਾਂ AI ਨੂੰ ਅਜਿਹਾ ਪੂਰਾ ਨੈਵੀਗੇਸ਼ਨ ਸਕੀਮ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਨਾ ਦਿਓ ਜੋ ਇਹ ਮੰਨ ਕੇ ਚੱਲਦੀ ਹੋਵੇ ਕਿ ਇਹ ਮੌਜੂਦ ਹੈ। ਸਿਸਟਮ ਨੂੰ ਕਿਸੇ ਸਮਰੱਥਾ ਦੀ ਕਮੀ ਹੋਣ 'ਤੇ ਟੁੱਟਣ ਦੀ ਬਜਾਏ ਸੁਚਾਰੂ ਰੂਪ ਵਿੱਚ ਡਿਗ੍ਰੇਡ (degrade gracefully) ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਪਹਿਲਾਂ ਸੀਮਾਵਾਂ ਨੂੰ ਜਾਣੋ। ਉਹਨਾਂ ਦੇ ਅੰਦਰ ਡਿਜ਼ਾਈਨ ਕਰੋ।

Public engine, private values। ਭਾਰੀ ਕੰਮਾਂ ਲਈ ਪਬਲਿਕ ਇੰਜਣ ਦੀ ਵਰਤੋਂ ਕਰੋ, ਪਰ ਆਪਣੇ ਨਿੱਜੀ ਡੇਟਾ, ਕੌਂਫਿਗਸ (configs), ਅਤੇ ਰਵਾਇਤਾਂ (conventions) ਨੂੰ ਰਨ-ਟਾਈਮ (runtime) 'ਤੇ ਇੰਜੈਕਟ ਕਰੋ। ਇਹ ਤੁਹਾਡੇ ਨਿੱਜੀ ਜਾਂ ਕੰਪਨੀ ਦੇ ਤਰੀਕਿਆਂ ਨੂੰ ਜਨਰੇਟ ਕੀਤੇ ਗਏ ਸਕੈਫੋਲਡ (scaffold) ਤੋਂ ਸੁਰੱਖਿਅਤ ਅਤੇ ਵੱਖਰਾ ਰੱਖਦਾ ਹੈ। 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.