ChatGPT, GitHub Copilot, Cursor, ਅਤੇ ਉਹਨਾਂ ਦੇ ਹੋਰ ਸਾਥੀ ਹੁਣ ਤੁਹਾਡੇ ਵੱਲੋਂ ਪ੍ਰੋਂਪਟ (prompt) ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਇੱਕ React component ਤਿਆਰ ਕਰ ਸਕਦੇ ਹਨ। Next.js route ਨੂੰ Supabase ਨਾਲ ਜੋੜਨਾ ਹੈ? ਕੁਝ ਹੀ ਸਕਿੰਟਾਂ ਵਿੱਚ ਹੋ ਜਾਵੇਗਾ। ਉਸ ਉਲਝੇ ਹੋਏ TypeScript utility ਨੂੰ refactor ਕਰਨਾ ਹੈ? ਇੱਥੇ type guards ਦੇ ਨਾਲ ਤਿੰਨ ਵਿਕਲਪ ਹਨ। ਮਾਡਰਨ ਵੈੱਬ ਸਟੈਕਸ (web stacks) ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਾਲੇ ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਲਈ, ਇਹ ਅਨੁਭਵ ਜਾਦੂ ਵਰਗਾ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ।

ਮੈਂ ਇਹਨਾਂ ਟੂਲਜ਼ ਦੀ ਰੋਜ਼ਾਨਾ ਵਰਤੋਂ ਕਰਦਾ ਹਾਂ। ਮੇਰਾ ਸਟੈਕ Next.js, TypeScript, ਅਤੇ Supabase ਹੈ, ਅਤੇ AI ਮੇਰੇ ਐਡੀਟਰ (editor) ਵਿੱਚ ਹੀ ਮੌਜੂਦ ਹੈ, ਜੋ custom hooks ਬਣਾਉਣ, database queries ਤਿਆਰ ਕਰਨ, ਜਾਂ ਉਲਝੇ ਹੋਏ conditional logic ਨੂੰ ਸਾਫ਼ ਕਰਨ ਲਈ ਤਿਆਰ ਰਹਿੰਦਾ ਹੈ। ਛੋਟੇ ਪੱਧਰ 'ਤੇ, ਇਹ ਇੱਕ ਬਹੁਤ ਤੇਜ਼ ਜੂਨੀਅਰ ਡਿਵੈਲਪਰ ਵਾਂਗ ਕੰਮ ਕਰਦਾ ਹੈ। ਇਹ syntax ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਣਦਾ ਹੈ। ਇਹ ਉਹਨਾਂ API surface areas ਨੂੰ ਯਾਦ ਰੱਖਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਲਈ ਮੈਨੂੰ Google ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਇਹ boilerplate ਲਿਖਦੇ ਹੋਏ ਥੱਕਦਾ ਨਹੀਂ ਹੈ।

ਪਰ ਸਾਫਟਵੇਅਰ ਲਗਾਤਾਰ ਖਰਾਬ ਹੁੰਦਾ ਰਹਿੰਦਾ ਹੈ। ਐਪਸ ਹੁਣ ਹੌਲੀ ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਹਨ। ਕਸਟਮਰ ਡੈਸ਼ਬੋਰਡ ਲੈਗ (lag) ਕਰਦੇ ਹਨ। Edge cases ਫਾਰਮਾਂ ਨੂੰ ਕ੍ਰੈਸ਼ ਕਰ ਦਿੰਦੇ ਹਨ। ਜੇਕਰ AI ਨੇ ਕੋਡਿੰਗ ਨੂੰ ਇੰਨਾ ਆਸਾਨ ਬਣਾ ਦਿੱਤਾ ਹੈ, ਤਾਂ ਸਾਫਟਵੇਅਰ ਦੀ ਵਰਤੋਂ ਕੁਝ ਸਾਲ ਪਹਿਲਾਂ ਨਾਲੋਂ ਹੁਣ ਕਿਉਂ ਬਦਤਰ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ?

ਇਸਦਾ ਜਵਾਬ ਇਹ ਹੈ ਕਿ syntax ਤਿਆਰ ਕਰਨਾ ਅਤੇ ਸਾਫਟਵੇਅਰ ਬਣਾਉਣਾ ਇੱਕੋ ਜਿਹਾ ਕੰਮ ਨਹੀਂ ਹੈ।

Syntax ਆਰਕੀਟੈਕਚਰ ਨਹੀਂ ਹੈ

AI tokens ਨੂੰ ਬਹੁਤ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲਦਾ ਹੈ। ਇਸਨੂੰ ਇੱਕ useEffect hook ਲਿਖਣ ਲਈ ਕਹੋ ਜੋ Supabase real-time channel ਨੂੰ ਸੁਣਦਾ ਹੋਵੇ, ਅਤੇ ਤੁਹਾਨੂੰ ਕੁਝ ਅਜਿਹਾ ਮਿਲੇਗਾ ਜੋ compile ਹੋ ਜਾਵੇਗਾ। ਇਹ ਇੱਕ untyped JavaScript ਫਾਈਲ ਨੂੰ ਸਖ਼ਤ TypeScript ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ, ਜਾਂ ਤੁਹਾਡੇ ਕੌਫੀ ਪੀਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ Zod validation ਦੇ ਨਾਲ ਇੱਕ form component ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ।

ਜੋ ਇਹ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਉਹ ਹੈ ਤੁਹਾਡੀ ਖਾਸ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਢਾਂਚੇ (contours) ਨੂੰ ਸਮਝਣਾ। ਚੰਗੇ ਸਾਫਟਵੇਅਰ ਲਈ ਸੋਚ-ਸਮਝ ਕੇ state management, race conditions ਦੀ ਸਾਵਧਾਨੀ ਨਾਲ ਸੰਭਾਲ, ਅਤੇ ਇਸਦਾ ਸਪੱਸ਼ਟ ਨਕਸ਼ਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਡਾਟਾ ਕਿੱਥੇ ਸਟੋਰ ਹੈ ਅਤੇ ਕਿੱਥੇ ਸਿਰਫ਼ ਦਿਖਾਇਆ ਜਾ ਰਿਹਾ ਹੈ। AI ਸਿਰਫ਼ ਮੌਜੂਦਾ ਫਾਈਲ ਨੂੰ ਦੇਖਦਾ ਹੈ, ਪੂਰੇ ਸਿਸਟਮ ਨੂੰ ਨਹੀਂ। ਇਹ ਤੁਹਾਡੇ codebase ਨੂੰ ਇੱਕ ਜਿਉਂਦੇ-ਜਾਗਦੇ ਢਾਂਚੇ ਦੀ ਬਜਾਏ ਇੱਕ ਸਧਾਰਨ ਟੈਕਸਟ ਕੋਰੀਡੋਰ ਵਾਂਗ ਮੰਨਦਾ ਹੈ।

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

ਦੋ ਰਗੜ ਦੇ ਬਿੰਦੂ (Friction Points)

ਜਦੋਂ ਮੈਂ AI ਨੂੰ ਸਖ਼ਤ ਨਿਯਮਾਂ (guardrails) ਤੋਂ ਬਿਨਾਂ ਕੋਡ ਦੇ ਵੱਡੇ ਹਿੱਸੇ ਲਿਖਣ ਦਿੰਦਾ ਹਾਂ, ਤਾਂ ਮੈਂ ਵਾਰ-ਵਾਰ ਇੱਕੋ ਜਿਹੀਆਂ ਦੋ ਸਮੱਸਿਆਵਾਂ ਦੇ ਸਾਹਮਣੇ ਆਉਂਦਾ ਹਾਂ।

ਪਹਿਲਾ, ਇਹ ਉਹਨਾਂ design patterns ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦਿੰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਸਥਾਪਿਤ ਕਰ ਚੁੱਕੇ ਹੋ। ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਤੁਹਾਡੀ ਟੀਮ ਸਾਰਾ data fetching custom hooks ਦੇ ਇੱਕ ਵੱਖਰੇ ਲੇਅਰ ਵਿੱਚ ਰੱਖਦੀ ਹੋਵੇ। ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕੋਲ Supabase RLS policies ਨੂੰ frontend helpers ਨਾਲ ਜੋੜਨ ਲਈ ਇੱਕ ਸਖ਼ਤ ਵਿਧੀ ਹੋਵੇ। AI ਨੂੰ ਇਸ ਨਾਲ ਕੋਈ ਫਰਕ ਨਹੀਂ ਪੈਂਦਾ। ਜੇਕਰ ਇਸ ਨਾਲ ਮੌਜੂਦਾ ਪ੍ਰੋਂਪਟ ਦਾ ਹੱਲ ਨਿਕਲਦਾ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ ਬਟਨ ਦੇ onClick ਵਿੱਚ ਸਿੱਧਾ supabase.from().select() ਪਾ ਦੇਵੇਗਾ। ਕੋਡ ਚੱਲਦਾ ਹੈ। ਇਹ ਸਾਫ਼ ਵੀ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਪਰ ਇਹ ਤੁਹਾਡੇ codebase ਵਿੱਚ ਇੱਕ outlier ਹੈ, ਅਤੇ ਹਰ outlier ਭਵਿੱਖ ਵਿੱਚ refactoring ਦਾ ਵਾਧੂ ਬੋਝ ਬਣਦਾ ਹੈ। ਛੇ ਮਹੀਨਿਆਂ ਬਾਅਦ, ਕਿਸੇ ਨੂੰ ਉਹ ਸੂਈ ਲੱਭਣੀ ਪਵੇਗੀ, ਇਹ ਸਮਝਣਾ ਪਵੇਗਾ ਕਿ ਇਹ ਕਿਉਂ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਵਾਪਸ ਸਹੀ ਰੇਖਾ ਵਿੱਚ ਲਿਆਉਣਾ ਪਵੇਗਾ।

ਦੂਜਾ, ਜਦੋਂ ਸਾਦਗੀ ਕਾਫ਼ੀ ਹੁੰਦੀ ਹੈ, ਇਹ ਗੁੰਝਲਦਾਰਤਾ ਵੱਲ ਵਧ ਜਾਂਦਾ ਹੈ। ਇਸ ਟੂਲ ਨੂੰ ਅਜਿਹੇ ਵੱਡੇ repositories 'ਤੇ ਸਿਖਲਾਈ ਦਿੱਤੀ ਗਈ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ abstract factories, ਗੁੰਝਲਦਾਰ reducer patterns, ਅਤੇ multi-layered higher-order components ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਸਧਾਰਨ contact form ਬਣਾਉਣ ਲਈ ਕਹਿੰਦੇ ਹੋ, ਤਾਂ ਇਹ ਤੁਹਾਨੂੰ ਇੱਕ state machine, ਇੱਕ context provider, ਅਤੇ ਇੱਕ custom hook abstraction ਦੇ ਸਕਦਾ ਹੈ ਜੋ ਤਿੰਨ ਫਾਈਲਾਂ ਵਿੱਚ ਫੈਲਿਆ ਹੋਵੇ। ਇਹ ਹੱਲ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਗਲਤ ਨਹੀਂ ਹੈ। ਇਹ ਸਿਰਫ਼ ਭਾਰੀ ਹੈ। ਹਰ ਬੇਲੋੜੀ ਲੇਅਰ cognitive debt ਵਧਾਉਂਦੀ ਹੈ। ਤੁਸੀਂ ਕੰਮ ਤੋਂ ਬਚੇ ਨਹੀਂ; ਤੁਸੀਂ ਇਸਨੂੰ ਵਿਆਜ ਸਮੇਤ ਟਾਲ ਦਿੱਤਾ ਹੈ।

ਵੇਲੋਸਿਟੀ ਦਾ ਜਾਲ (The Velocity Trap)

ਇੱਥੇ ਇੱਕ ਖ਼ਤਰਨਾਕ ਫੀਡਬੈਕ ਲੂਪ ਹੈ। AI ਤੁਹਾਨੂੰ ਦੁੱਗਣੀ ਤੇਜ਼ੀ ਨਾਲ ਫੀਚਰ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਪਰ ਮਨੁੱਖੀ ਧਿਆਨ ਉਸੇ ਤਰ੍ਹਾਂ ਨਹੀਂ ਵਧਦਾ। ਜੇਕਰ ਤੁਸੀਂ ਅੱਧੇ ਸਮੇਂ ਵਿੱਚ ਕੰਮ ਪੂਰਾ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਕੀ ਤੁਸੀਂ code review 'ਤੇ ਦੁੱਗਣਾ ਸਮਾਂ ਬਿਤਾ ਰਹੇ ਹੋ? ਕੀ ਤੁਸੀਂ ਜ਼ਿਆਦਾ ਟੈਸਟ ਲਿਖ ਰਹੇ ਹੋ, ਜਾਂ ਘੱਟ?

ਅਸਲ ਵਿੱਚ, ਤਿਆਰ ਕੀਤੇ ਗਏ ਕੋਡ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਬਹੁਤ ਆਸਾਨ ਹੈ ਕਿਉਂਕਿ ਇਹ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਲੱਗਦਾ ਹੈ। ਇਹ ਮਾਡਰਨ syntax ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਕਮੈਂਟਸ ਬਿਲਕੁਲ ਸਹੀ ਥਾਵਾਂ 'ਤੇ ਹੁੰਦੇ ਹਨ। ਵੇਰੀਏਬਲ ਦੇ ਨਾਮ ਪੇਸ਼ੇਵਰ ਲੱਗਦੇ ਹਨ। ਉਸ ਚਮਕ-ਧਮਕ ਵਿੱਚ ਬਾਰੀਕ bugs ਲੁਕੇ ਹੁੰਦੇ ਹਨ। ਇੱਕ hook ਵਿੱਚ dependency array ਜੋ setter ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ। ਇੱਕ TypeScript type ਜੋ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਸਹੀ ਹੈ ਪਰ ਇੱਕ null state ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਸੰਭਾਲਣਾ ਭੁੱਲ ਗਏ ਹੋ

Software feels clunkier because complexity is growing faster than teams can steward it. We are building bigger applications with smaller crews, armed with tools that make us feel invincible. When one developer can scaffold an entire dashboard in an afternoon, the organization expects three dashboards by Wednesday. Scale without care produces fragile systems. State balloons. Bundle sizes creep up. Race conditions multiply. The interface might look modern, but it resets itself when a user hits the back button, or it takes four seconds to hydrate because nobody had time to profile the waterfall of AI-generated data fetches.

Work With the Machine, Not For It

None of this means you should throw AI out of your editor. It means you need boundaries.

Use it for what it is good at. Let it write the dull stuff: repetitive TypeScript interfaces, boilerplate Supabase queries, Jest setup