ਸਦੀਵੀ ਵਾਅਦਾ: ਪ੍ਰੋਗਰਾਮਰਾਂ ਨੂੰ ਖਤਮ ਕਰਨ ਦੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਦਾ ਇਤਿਹਾਸ

ਸੁਪਨਾ ਜੋ ਕਦੇ ਨਹੀਂ ਮਰਦਾ

ਹਰ ਦਹਾਕੇ, ਇੱਕ ਨਵੀਂ ਤਕਨੀਕ ਉਸੇ ਦਲੇਰ ਘੋਸ਼ਣਾ ਦੇ ਨਾਲ ਆਉਂਦੀ ਹੈ: ਪ੍ਰੋਗਰਾਮਰ ਅਪ੍ਰਚਲਿਤ ਹੋਣ ਵਾਲੇ ਹਨ। 1950 ਦੇ ਦਹਾਕੇ ਵਿੱਚ COBOL ਦੀ ਕਾਢ ਤੋਂ ਲੈ ਕੇ 2010 ਦੇ ਨੋ-ਕੋਡ ਕ੍ਰਾਂਤੀ ਅਤੇ 2020 ਦੇ ਜਨਰੇਟਿਵ AI ਵਿਸਫੋਟ ਤੱਕ, ਬਿਰਤਾਂਤ ਕਮਾਲ ਦੀ ਇਕਸਾਰ ਰਿਹਾ ਹੈ। ਵਪਾਰਕ ਨੇਤਾਵਾਂ, ਉੱਦਮ ਪੂੰਜੀਪਤੀਆਂ, ਅਤੇ ਤਕਨਾਲੋਜੀ ਪ੍ਰਚਾਰਕਾਂ ਨੇ ਵਾਰ-ਵਾਰ ਘੋਸ਼ਣਾ ਕੀਤੀ ਹੈ ਕਿ ਪੇਸ਼ੇਵਰ ਸੌਫਟਵੇਅਰ ਵਿਕਾਸ ਦਾ ਅੰਤ ਬਿਲਕੁਲ ਨੇੜੇ ਹੈ। ਫਿਰ ਵੀ ਇੱਥੇ ਅਸੀਂ 2026 ਵਿੱਚ ਹਾਂ, ਅਤੇ ਬਿਊਰੋ ਆਫ਼ ਲੇਬਰ ਸਟੈਟਿਸਟਿਕਸ ਪ੍ਰੋਜੈਕਟ ਸੌਫਟਵੇਅਰ ਡਿਵੈਲਪਰ ਰੁਜ਼ਗਾਰ 2032 ਤੱਕ 25% ਵਧਣ ਲਈ - ਔਸਤ ਕਿੱਤੇ ਨਾਲੋਂ ਕਿਤੇ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ। ਪ੍ਰੋਗਰਾਮਰਾਂ ਨੂੰ ਖਤਮ ਕਰਨ ਦੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਕਹਾਣੀ ਅਸਲ ਵਿੱਚ ਤਕਨਾਲੋਜੀ ਦੇ ਅਸਫਲ ਹੋਣ ਬਾਰੇ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਬੁਨਿਆਦੀ ਗਲਤਫਹਿਮੀ ਬਾਰੇ ਹੈ ਕਿ ਪ੍ਰੋਗਰਾਮਰ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦੇ ਹਨ।

ਕੋਬੋਲ ਕ੍ਰਾਂਤੀ: ਮੇਕਿੰਗ ਮਸ਼ੀਨਾਂ ਅੰਗਰੇਜ਼ੀ ਬੋਲਦੀਆਂ ਹਨ

ਜਦੋਂ ਗ੍ਰੇਸ ਹੌਪਰ ਅਤੇ ਉਸਦੀ ਟੀਮ ਨੇ 1959 ਵਿੱਚ COBOL ਦਾ ਵਿਕਾਸ ਕੀਤਾ, ਤਾਂ ਸਪਸ਼ਟ ਟੀਚਾ ਇੱਕ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਭਾਸ਼ਾ ਨੂੰ ਸਾਦੀ ਅੰਗਰੇਜ਼ੀ ਦੇ ਇੰਨੇ ਨੇੜੇ ਬਣਾਉਣਾ ਸੀ ਕਿ ਕਾਰੋਬਾਰੀ ਪ੍ਰਬੰਧਕ ਆਪਣਾ ਸਾਫਟਵੇਅਰ ਲਿਖ ਸਕਣ। ਨਾਮ ਆਪਣੇ ਆਪ - ਆਮ ਵਪਾਰ-ਮੁਖੀ ਭਾਸ਼ਾ - ਨੇ ਅਭਿਲਾਸ਼ਾ ਨੂੰ ਸੰਕੇਤ ਕੀਤਾ. ਜੇਕਰ ਕੋਡ ਇੱਕ ਵਾਕ ਵਾਂਗ ਪੜ੍ਹਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਵਿਸ਼ੇਸ਼ ਕੋਡਰਾਂ ਦੀ ਲੋੜ ਕਿਉਂ ਪਵੇਗੀ? ਐਗਜ਼ੀਕਿਊਟਿਵ ਕੰਪਿਊਟਰ ਨੂੰ ਸਿਰਫ਼ ਉਹ ਭਾਸ਼ਾ ਦੱਸ ਸਕਦੇ ਹਨ ਜੋ ਉਹ ਪਹਿਲਾਂ ਹੀ ਸਮਝਦੇ ਹਨ।

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

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

4GL Era ਅਤੇ CASE ਟੂਲ: ਆਟੋਮੇਟਰਾਂ ਨੂੰ ਸਵੈਚਾਲਤ ਕਰਨਾ

1980 ਦੇ ਦਹਾਕੇ ਨੇ ਚੌਥੀ ਪੀੜ੍ਹੀ ਦੀਆਂ ਭਾਸ਼ਾਵਾਂ (4GLs) ਅਤੇ ਕੰਪਿਊਟਰ-ਏਡਿਡ ਸੌਫਟਵੇਅਰ ਇੰਜਨੀਅਰਿੰਗ (CASE) ਟੂਲ ਲਿਆਏ, ਅਤੇ ਉਹਨਾਂ ਦੇ ਨਾਲ, ਪ੍ਰੋਗਰਾਮਰ-ਖਤਮ ਆਸ਼ਾਵਾਦ ਦੀ ਇੱਕ ਤਾਜ਼ਾ ਲਹਿਰ। Informix-4GL, Progress, ਅਤੇ Oracle Forms ਵਰਗੇ ਉਤਪਾਦਾਂ ਨੇ ਵਾਅਦਾ ਕੀਤਾ ਹੈ ਕਿ ਵਿਜ਼ੂਅਲ ਇੰਟਰਫੇਸ ਅਤੇ ਘੋਸ਼ਣਾਤਮਕ ਸੰਟੈਕਸ ਕਾਰੋਬਾਰੀ ਵਿਸ਼ਲੇਸ਼ਕਾਂ ਨੂੰ ਸਿੱਧੇ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਉਣ ਦੇਣਗੇ। ਜੇਮਸ ਮਾਰਟਿਨ, ਪ੍ਰਭਾਵਸ਼ਾਲੀ IT ਸਲਾਹਕਾਰ, ਨੇ 1982 ਵਿੱਚ ਭਵਿੱਖਬਾਣੀ ਕੀਤੀ ਸੀ ਕਿ ਇੱਕ ਦਹਾਕੇ ਦੇ ਅੰਦਰ ਰਵਾਇਤੀ ਪ੍ਰੋਗਰਾਮਿੰਗ ਨੂੰ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਸਵੈਚਲਿਤ ਟੂਲਸ ਦੁਆਰਾ ਬਦਲ ਦਿੱਤਾ ਜਾਵੇਗਾ।

ਕਾਰਪੋਰੇਸ਼ਨਾਂ ਨੇ ਅਰਬਾਂ ਦਾ ਨਿਵੇਸ਼ ਕੀਤਾ। CASE ਟੂਲ ਮਾਰਕੀਟ 1990 ਦੇ ਦਹਾਕੇ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਸਾਲਾਨਾ $6 ਬਿਲੀਅਨ ਤੋਂ ਵੱਧ ਦੀ ਸਿਖਰ 'ਤੇ ਸੀ। ਐਂਡਰਸਨ ਕੰਸਲਟਿੰਗ (ਹੁਣ ਐਕਸੇਂਚਰ) ਵਰਗੀਆਂ ਕੰਪਨੀਆਂ ਨੇ ਇਸ ਵਿਚਾਰ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਪੂਰੇ ਅਭਿਆਸਾਂ ਦਾ ਨਿਰਮਾਣ ਕੀਤਾ ਕਿ ਢਾਂਚਾਗਤ ਵਿਧੀਆਂ ਅਤੇ ਸਵੈਚਾਲਿਤ ਕੋਡ ਬਣਾਉਣਾ ਹੱਥ-ਲਿਖਤ ਸੌਫਟਵੇਅਰ ਦੀ ਲੋੜ ਨੂੰ ਨਾਟਕੀ ਢੰਗ ਨਾਲ ਘਟਾ ਦੇਵੇਗਾ। IBM ਦੀ AD/cycle ਪਹਿਲਕਦਮੀ ਨੇ ਇੱਕ ਵਿਆਪਕ ਵਿਕਾਸ ਵਾਤਾਵਰਣ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜੋ ਪੂਰੇ ਸਾਫਟਵੇਅਰ ਜੀਵਨ ਚੱਕਰ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰੇਗਾ।

ਨਤੀਜੇ ਨਿਸ਼ਚਿਤ ਤੌਰ 'ਤੇ ਮਿਲਾਏ ਗਏ ਸਨ। CASE ਟੂਲਸ ਨੇ ਸਧਾਰਨ, ਚੰਗੀ ਤਰ੍ਹਾਂ ਪਰਿਭਾਸ਼ਿਤ ਐਪਲੀਕੇਸ਼ਨਾਂ - ਮੂਲ ਡਾਟਾ ਐਂਟਰੀ ਫਾਰਮ, ਸਿੱਧੀਆਂ ਰਿਪੋਰਟਾਂ, ਸਟੈਂਡਰਡ CRUD ਓਪਰੇਸ਼ਨਾਂ ਲਈ ਉਚਿਤ ਤੌਰ 'ਤੇ ਵਧੀਆ ਕੰਮ ਕੀਤਾ। ਪਰ ਪਲ ਦੀਆਂ ਲੋੜਾਂ ਗੁੰਝਲਦਾਰ, ਅਸਪਸ਼ਟ, ਜਾਂ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਣ ਦੀ ਲੋੜ ਵਧ ਗਈ, ਟੂਲ ਬੱਕਲ ਹੋ ਗਏ। ਡਿਵੈਲਪਰਾਂ ਨੇ ਆਪਣੇ ਆਪ ਨੂੰ ਉਹਨਾਂ ਤੋਂ ਲਾਭ ਲੈਣ ਦੀ ਬਜਾਏ ਐਬਸਟਰੈਕਸ਼ਨਾਂ ਨਾਲ ਲੜਦੇ ਹੋਏ ਪਾਇਆ, ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਵਿਸਤ੍ਰਿਤ ਕਾਰਜ-ਸਾਧਨ ਲਿਖਦੇ ਹੋਏ ਜੋ ਹੱਥ ਨਾਲ ਕੋਡ ਦੀਆਂ ਦਸ ਲਾਈਨਾਂ ਲੈ ਲੈਣਗੀਆਂ। 1990 ਦੇ ਦਹਾਕੇ ਦੇ ਮੱਧ ਤੱਕ, CASE ਲਹਿਰ ਆਪਣੇ ਭਾਰ ਹੇਠ ਢਹਿ ਗਈ ਸੀ, ਅਤੇ ਪ੍ਰੋਗਰਾਮਰਾਂ ਦੀ ਇੱਕ ਨਵੀਂ ਪੀੜ੍ਹੀ ਜਾਵਾ ਲਿਖ ਰਹੀ ਸੀ ਅਤੇ ਵੈੱਬ ਲਈ ਨਿਰਮਾਣ ਕਰ ਰਹੀ ਸੀ।

ਦਿ ਵਿਜ਼ੂਅਲ ਪ੍ਰੋਗਰਾਮਿੰਗ ਮਿਰਾਜ

ਇੰਟਰਨੈੱਟ ਦੇ ਉਭਾਰ ਨੇ ਸਾੱਫਟਵੇਅਰ ਬਣਾਉਣ ਦਾ ਲੋਕਤੰਤਰੀਕਰਨ ਕਰਨ ਦਾ ਵਾਅਦਾ ਕਰਨ ਵਾਲੇ ਸਾਧਨਾਂ ਦੀ ਇੱਕ ਹੋਰ ਲਹਿਰ ਪੈਦਾ ਕੀਤੀ। Dreamweaver, FrontPage, ਅਤੇ Flash ਨੇ ਡਿਜ਼ਾਈਨਰਾਂ ਨੂੰ HTML ਲਿਖੇ ਬਿਨਾਂ ਵੈੱਬਸਾਈਟਾਂ ਬਣਾਉਣ ਦੀ ਸਮਰੱਥਾ ਦਿੱਤੀ। ਵਿਜ਼ੂਅਲ ਬੇਸਿਕ ਦਫਤਰ ਦੇ ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਕੰਪੋਨੈਂਟਸ ਨੂੰ ਖਿੱਚ ਕੇ ਅਤੇ ਛੱਡ ਕੇ ਕਾਰਜਸ਼ੀਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਬਣਾਉਣ ਦਿੰਦਾ ਹੈ। ਮਾਈਕਰੋਸਾਫਟ ਐਕਸੈਸ ਨੇ ਵਾਅਦਾ ਕੀਤਾ ਸੀ ਕਿ ਕੋਈ ਵੀ ਇੱਕ ਹਫਤੇ ਦੇ ਅੰਤ ਵਿੱਚ ਡੇਟਾਬੇਸ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾ ਸਕਦਾ ਹੈ।

ਇਹ ਟੂਲ ਅਸਲ ਵਿੱਚ ਲੱਖਾਂ ਲੋਕਾਂ ਨੂੰ ਡਿਜੀਟਲ ਕਲਾਕ੍ਰਿਤੀਆਂ ਬਣਾਉਣ ਲਈ ਸ਼ਕਤੀ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ ਜੋ ਉਹ ਹੋਰ ਨਹੀਂ ਬਣਾ ਸਕਦੇ ਸਨ। ਛੋਟੇ ਕਾਰੋਬਾਰਾਂ ਨੂੰ ਵੈੱਬਸਾਈਟਾਂ ਮਿਲੀਆਂ। ਵਿਭਾਗਾਂ ਨੂੰ ਕਸਟਮ ਟਰੈਕਿੰਗ ਟੂਲ ਮਿਲੇ ਹਨ। ਗੈਰ-ਲਾਭਕਾਰੀ ਨੂੰ ਦਾਨੀ ਡੇਟਾਬੇਸ ਮਿਲੇ ਹਨ। ਪਰ ਇੱਕ ਉਤਸੁਕ ਚੀਜ਼ ਵਾਪਰੀ: ਜਿੰਨੇ ਜ਼ਿਆਦਾ ਗੈਰ-ਪ੍ਰੋਗਰਾਮਰ ਬਣਾਏ ਗਏ, ਓਨੇ ਹੀ ਉਹਨਾਂ ਨੇ ਸੀਮਾਵਾਂ ਦੀ ਖੋਜ ਕੀਤੀ ਕਿ ਵਿਜ਼ੂਅਲ ਟੂਲ ਕੀ ਕਰ ਸਕਦੇ ਹਨ। ਹਰ Dreamweaver ਸਾਈਟ ਨੂੰ ਆਖਰਕਾਰ ਕਸਟਮ JavaScript ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਹਰ ਐਕਸੈਸ ਡੇਟਾਬੇਸ ਆਖਰਕਾਰ ਪ੍ਰਦਰਸ਼ਨ ਦੀਆਂ ਕੰਧਾਂ ਨੂੰ ਮਾਰਦਾ ਹੈ. ਹਰੇਕ ਵਿਜ਼ੂਅਲ ਬੇਸਿਕ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਅੰਤ ਵਿੱਚ ਉਹਨਾਂ ਸਿਸਟਮਾਂ ਨਾਲ ਏਕੀਕ੍ਰਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜਿਸਦਾ ਸਿਰਜਣਹਾਰ ਕਦੇ ਵੀ ਆਸ ਨਹੀਂ ਕਰਦਾ ਸੀ।

"ਪ੍ਰੋਗਰਾਮਿੰਗ ਦਾ ਇਤਿਹਾਸ ਮਨੁੱਖਾਂ ਨੂੰ ਟੂਲਸ ਦੁਆਰਾ ਤਬਦੀਲ ਕੀਤੇ ਜਾਣ ਦੀ ਕਹਾਣੀ ਨਹੀਂ ਹੈ — ਇਹ ਉਹਨਾਂ ਸਾਧਨਾਂ ਦੀ ਕਹਾਣੀ ਹੈ ਜੋ ਮਨੁੱਖ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹਨ, ਜਿਸ ਲਈ ਹਮੇਸ਼ਾਂ ਹੋਰ ਪ੍ਰੋਗਰਾਮਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਘੱਟ ਨਹੀਂ। ਐਬਸਟਰੈਕਸ਼ਨ ਦੀ ਹਰ ਪਰਤ ਗੁੰਝਲਦਾਰਤਾ ਨੂੰ ਖਤਮ ਨਹੀਂ ਕਰਦੀ; ਇਹ ਸਿਰਫ਼ ਇਸਨੂੰ ਬਦਲਦੀ ਹੈ।"

ਨੋ-ਕੋਡ ਅਤੇ ਲੋਅ-ਕੋਡ: ਨਵੀਨਤਮ ਅਧਿਆਇ

2010 ਦੇ ਦਹਾਕੇ ਦੀ ਨੋ-ਕੋਡ ਅਤੇ ਘੱਟ-ਕੋਡ ਅੰਦੋਲਨ ਨੇ ਸਮੀਕਰਨ ਤੋਂ ਪ੍ਰੋਗਰਾਮਰਾਂ ਨੂੰ ਹਟਾਉਣ ਲਈ ਸ਼ਾਇਦ ਸਭ ਤੋਂ ਵਧੀਆ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਹੈ। ਬਬਲ, ਵੈੱਬਫਲੋ, ਏਅਰਟੇਬਲ, ਅਤੇ ਜ਼ੈਪੀਅਰ ਵਰਗੇ ਪਲੇਟਫਾਰਮਾਂ ਨੇ ਗੈਰ-ਤਕਨੀਕੀ ਸੰਸਥਾਪਕਾਂ ਲਈ ਕਾਰਜਸ਼ੀਲ ਉਤਪਾਦ ਬਣਾਉਣਾ ਅਸਲ ਵਿੱਚ ਸੰਭਵ ਬਣਾਇਆ ਹੈ - ਕਈ ਵਾਰ ਰਵਾਇਤੀ ਕੋਡ ਤੋਂ ਬਿਨਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਣਾਏ ਗਏ ਐਪਲੀਕੇਸ਼ਨਾਂ 'ਤੇ ਲੱਖਾਂ ਦੀ ਉੱਦਮ ਪੂੰਜੀ ਇਕੱਠੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਗਾਰਟਨਰ ਨੇ ਭਵਿੱਖਬਾਣੀ ਕੀਤੀ ਹੈ ਕਿ 2025 ਤੱਕ, 70% ਨਵੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਘੱਟ-ਕੋਡ ਜਾਂ ਨੋ-ਕੋਡ ਤਕਨਾਲੋਜੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨਗੀਆਂ, ਜੋ ਕਿ 2020 ਵਿੱਚ 25% ਤੋਂ ਵੀ ਘੱਟ ਹਨ।

ਨੋ-ਕੋਡ ਅੰਦੋਲਨ ਸਫਲ ਹੋਇਆ ਜਿੱਥੇ ਪਿਛਲੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਇੱਕ ਨਾਜ਼ੁਕ ਸਮਝ ਨੂੰ ਅਪਣਾਉਣ ਦੁਆਰਾ ਠੋਕਰ ਖਾ ਗਈਆਂ ਸਨ: ਜ਼ਿਆਦਾਤਰ ਕਾਰੋਬਾਰੀ ਐਪਲੀਕੇਸ਼ਨਾਂ ਹੱਲ ਕੀਤੀਆਂ ਸਮੱਸਿਆਵਾਂ 'ਤੇ ਭਿੰਨਤਾਵਾਂ ਹਨ। ਜੇਕਰ ਕੋਈ ਸੰਰਚਨਾਯੋਗ ਮੌਜੂਦ ਹੈ ਤਾਂ ਤੁਹਾਨੂੰ ਕਸਟਮ-ਬਿਲਟ CRM ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਜੇਕਰ ਕੋਈ ਮਾਡਿਊਲਰ ਪਲੇਟਫਾਰਮ ਤੁਹਾਡੇ ਵਰਕਫਲੋ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ ਤਾਂ ਤੁਹਾਨੂੰ ਬੇਸਪੋਕ ਇਨਵੌਇਸਿੰਗ ਸਿਸਟਮ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਹ ਬਿਲਕੁਲ Mewayz ਵਰਗੇ ਪਲੇਟਫਾਰਮਾਂ ਦੇ ਪਿੱਛੇ ਫਲਸਫਾ ਹੈ, ਜੋ ਕਿ 207 ਪੂਰਵ-ਨਿਰਮਿਤ ਵਪਾਰਕ ਮੋਡੀਊਲ ਪੇਸ਼ ਕਰਦਾ ਹੈ — CRM ਅਤੇ ਇਨਵੌਇਸਿੰਗ ਤੋਂ ਲੈ ਕੇ ਪੇਰੋਲ, HR, ਫਲੀਟ ਪ੍ਰਬੰਧਨ, ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਤੱਕ — ਕਾਰੋਬਾਰਾਂ ਨੂੰ ਕੋਡ ਦੀ ਇੱਕ ਲਾਈਨ ਲਿਖੇ ਬਿਨਾਂ ਆਧੁਨਿਕ ਸੰਚਾਲਨ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। 138,000 ਤੋਂ ਵੱਧ ਉਪਭੋਗਤਾਵਾਂ ਦੁਆਰਾ ਇਸਦੇ ਮਾਡਿਊਲਰ ਆਰਕੀਟੈਕਚਰ 'ਤੇ ਅਸਲ ਕਾਰੋਬਾਰ ਚਲਾਉਣ ਦੇ ਨਾਲ, ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਸਾਰੇ ਸੌਫਟਵੇਅਰ ਵਿਕਾਸ ਨੂੰ ਬਦਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਬਜਾਏ ਕਾਰੋਬਾਰੀ ਸੰਚਾਲਨ 'ਤੇ ਲਾਗੂ ਹੋਣ 'ਤੇ ਬਿਨਾਂ ਕੋਡ ਦਾ ਵਾਅਦਾ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ।

ਪਰ ਸਭ ਤੋਂ ਸਫਲ ਨੋ-ਕੋਡ ਪਲੇਟਫਾਰਮ ਵੀ ਉਸੇ ਅੰਤਰੀਵ ਸੱਚ ਨੂੰ ਪ੍ਰਗਟ ਕਰਦੇ ਹਨ। ਜਦੋਂ ਇੱਕ ਬਬਲ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ 50,000 ਸਮਕਾਲੀ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਕੋਈ ਕੋਡ ਲਿਖਦਾ ਹੈ। ਜਦੋਂ ਇੱਕ ਜ਼ੈਪੀਅਰ ਵਰਕਫਲੋ ਨੂੰ ਬਾਰਾਂ ਏਕੀਕ੍ਰਿਤ ਸੇਵਾਵਾਂ ਵਿੱਚ ਕਸਟਮ ਐਰਰ ਹੈਂਡਲਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਕੋਈ ਕੋਡ ਲਿਖਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਕਾਰੋਬਾਰ ਆਪਣੇ ਮਾਡਿਊਲਰ ਪਲੇਟਫਾਰਮ ਦੀਆਂ ਧਾਰਨਾਵਾਂ ਨੂੰ ਵਧਾ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਕੋਈ ਕੋਡ ਲਿਖਦਾ ਹੈ। ਨੋ-ਕੋਡ ਨੇ ਪ੍ਰੋਗਰਾਮਰ ਨੂੰ ਖਤਮ ਨਹੀਂ ਕੀਤਾ — ਇਹ ਕਿੱਥੇ ਅਤੇ ਕਦੋਂ ਉਹਨਾਂ ਦੀ ਮੁਹਾਰਤ ਜ਼ਰੂਰੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਇਸਦਾ ਪੁਨਰਗਠਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

The AI Gambit: ਕੀ ਇਹ ਸਮਾਂ ਵੱਖਰਾ ਹੋਵੇਗਾ?

GitHub Copilot, Claude, ਅਤੇ GPT-ਅਧਾਰਿਤ ਕੋਡਿੰਗ ਸਹਾਇਕ ਵਰਗੇ ਜਨਰੇਟਿਵ AI ਟੂਲਸ ਨੇ ਬੇਮਿਸਾਲ ਤੀਬਰਤਾ ਨਾਲ ਕੰਪਿਊਟਿੰਗ ਵਿੱਚ ਸਭ ਤੋਂ ਪੁਰਾਣੀ ਬਹਿਸ ਨੂੰ ਮੁੜ ਸੁਰਜੀਤ ਕੀਤਾ ਹੈ। ਸਮਰੱਥਾਵਾਂ ਅਸਲ ਵਿੱਚ ਕਮਾਲ ਦੀਆਂ ਹਨ। AI ਹੁਣ ਕੁਦਰਤੀ ਭਾਸ਼ਾ ਦੇ ਵਰਣਨ, ਡੀਬੱਗ ਗੁੰਝਲਦਾਰ ਗਲਤੀਆਂ, ਰੀਫੈਕਟਰ ਲੀਗੇਸੀ ਸਿਸਟਮ, ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਆਰਕੀਟੈਕਟ ਮਲਟੀ-ਸਰਵਿਸ ਐਪਲੀਕੇਸ਼ਨਾਂ ਤੋਂ ਕਾਰਜਸ਼ੀਲ ਕੋਡ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ। ਸਟੈਨਫੋਰਡ ਦੇ 2025 ਦੇ ਅਧਿਐਨ ਨੇ ਪਾਇਆ ਕਿ AI ਸਹਾਇਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਡਿਵੈਲਪਰਾਂ ਨੇ ਔਸਤਨ 55% ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਪੂਰੇ ਕੀਤੇ। ਕੁਝ ਉੱਦਮ ਪੂੰਜੀਪਤੀਆਂ ਨੇ ਐਲਾਨ ਕੀਤਾ ਹੈ ਕਿ "ਆਖਰੀ ਪ੍ਰੋਗਰਾਮਰ" ਪਹਿਲਾਂ ਹੀ ਪੈਦਾ ਹੋ ਚੁੱਕਾ ਹੈ।

ਹਾਲਾਂਕਿ ਹੁਣ ਤੱਕ ਦੇ ਸਬੂਤ ਇੱਕ ਜਾਣੇ-ਪਛਾਣੇ ਪੈਟਰਨ ਦਾ ਸੁਝਾਅ ਦਿੰਦੇ ਹਨ। ਏਆਈ ਕੋਡਿੰਗ ਟੂਲਸ ਨੇ ਵਿਅਕਤੀਗਤ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਨਾਟਕੀ ਤੌਰ 'ਤੇ ਵਧੇਰੇ ਲਾਭਕਾਰੀ ਬਣਾਇਆ ਹੈ, ਪਰ ਉਨ੍ਹਾਂ ਨੇ ਡਿਵੈਲਪਰਾਂ ਦੀ ਮੰਗ ਨੂੰ ਘੱਟ ਨਹੀਂ ਕੀਤਾ ਹੈ। ਇਸ ਦੀ ਬਜਾਏ, ਕੰਪਨੀਆਂ ਵਧੇਰੇ ਉਤਸ਼ਾਹੀ ਸੌਫਟਵੇਅਰ ਬਣਾਉਣ ਲਈ ਉਤਪਾਦਕਤਾ ਲਾਭਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੀਆਂ ਹਨ, ਤੇਜ਼ੀ ਨਾਲ. ਸਟਾਰਟਅੱਪ ਜਿਨ੍ਹਾਂ ਨੂੰ ਪਹਿਲਾਂ 18 ਮਹੀਨਿਆਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਸੀ ਅਤੇ ਇੱਕ ਉਤਪਾਦ ਭੇਜਣ ਲਈ ਅੱਠ ਦੀ ਇੱਕ ਟੀਮ ਹੁਣ ਤਿੰਨ ਡਿਵੈਲਪਰਾਂ ਨਾਲ ਛੇ ਮਹੀਨਿਆਂ ਵਿੱਚ ਅਜਿਹਾ ਕਰ ਸਕਦੀ ਹੈ — ਪਰ ਉਹ ਤਿੰਨ ਡਿਵੈਲਪਰਾਂ ਦੀ ਮੰਗ ਜ਼ਿਆਦਾ ਹੈ ਅਤੇ ਪਹਿਲਾਂ ਨਾਲੋਂ ਬਿਹਤਰ ਮੁਆਵਜ਼ਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

ਅਜਿਹੇ ਡੋਮੇਨ ਵੀ ਹਨ ਜਿੱਥੇ AI ਦੁਆਰਾ ਤਿਆਰ ਕੋਡ ਪੁਰਾਣੀਆਂ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਬਜਾਏ ਨਵੀਆਂ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਇਹਨਾਂ ਲਗਾਤਾਰ ਚੁਣੌਤੀਆਂ 'ਤੇ ਵਿਚਾਰ ਕਰੋ:

• ਸੁਰੱਖਿਆ ਕਮਜ਼ੋਰੀਆਂ: NYU ਦੇ ਟੰਡਨ ਸਕੂਲ ਤੋਂ ਖੋਜ ਵਿੱਚ ਪਾਇਆ ਗਿਆ ਕਿ AI-ਉਤਪੰਨ ਕੋਡ ਵਿੱਚ ਲਗਭਗ 40% ਵਾਰ ਸੁਰੱਖਿਆ ਖਾਮੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਜਿਸ ਲਈ ਤਜਰਬੇਕਾਰ ਡਿਵੈਲਪਰਾਂ ਦੀ ਸਮੀਖਿਆ ਅਤੇ ਸੁਧਾਰ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ
• ਆਰਕੀਟੈਕਚਰਲ ਤਾਲਮੇਲ: AI ਵਿਅਕਤੀਗਤ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਬਣਾਉਣ ਵਿੱਚ ਉੱਤਮ ਹੈ ਪਰ ਸੈਂਕੜੇ ਇੰਟਰੈਕਟਿੰਗ ਕੰਪੋਨੈਂਟਸ ਦੇ ਨਾਲ ਵੱਡੇ ਕੋਡਬੇਸਾਂ ਵਿੱਚ ਇੱਕਸਾਰ ਆਰਕੀਟੈਕਚਰਲ ਪੈਟਰਨ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਲਈ ਸੰਘਰਸ਼ ਕਰਦਾ ਹੈ
• ਡੋਮੇਨ-ਵਿਸ਼ੇਸ਼ ਤਰਕ: ਵਿੱਤੀ ਨਿਯਮ, ਹੈਲਥਕੇਅਰ ਪਾਲਣਾ (HIPAA), ਅਤੇ ਹਵਾਬਾਜ਼ੀ ਸੁਰੱਖਿਆ ਮਾਪਦੰਡਾਂ ਨੂੰ ਸੂਖਮ ਸਮਝ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਕਿ ਮੌਜੂਦਾ AI ਮਾਡਲ ਅਕਸਰ ਸੂਖਮ, ਖਤਰਨਾਕ ਤਰੀਕਿਆਂ ਨਾਲ ਗਲਤ ਹੁੰਦੇ ਹਨ
• ਡੀਬੱਗਿੰਗ AI ਆਉਟਪੁੱਟ: ਜਦੋਂ AI ਦੁਆਰਾ ਤਿਆਰ ਕੋਡ ਉਤਪਾਦਨ ਵਿੱਚ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸਮੱਸਿਆ ਦਾ ਨਿਦਾਨ ਕਰਨ ਲਈ ਅਕਸਰ ਕੋਡ ਨੂੰ ਹੱਥੀਂ ਲਿਖਣ ਨਾਲੋਂ ਡੂੰਘੀ ਮੁਹਾਰਤ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਵਿਸ਼ੇਸ਼ ਕੰਮ ਦੀ ਇੱਕ ਨਵੀਂ ਸ਼੍ਰੇਣੀ ਬਣਾਉਣਾ
• ਏਕੀਕਰਨ ਦੀ ਗੁੰਝਲਤਾ: ਸੰਗਠਨਾਤਮਕ ਸੀਮਾਵਾਂ ਦੇ ਪਾਰ ਸਿਸਟਮਾਂ ਨੂੰ ਜੋੜਨਾ — ਆਧੁਨਿਕ APIs ਲਈ ਵਿਰਾਸਤੀ ਮੇਨਫ੍ਰੇਮ, ਕਲਾਉਡ ਸੇਵਾਵਾਂ ਲਈ ਆਨ-ਪ੍ਰੀਮਿਸ ਡੇਟਾਬੇਸ — ਵਿੱਚ ਤਕਨੀਕੀ ਕਰਜ਼ੇ, ਰਾਜਨੀਤਿਕ ਰੁਕਾਵਟਾਂ, ਅਤੇ ਗੈਰ-ਦਸਤਾਵੇਜ਼ੀ ਵਿਵਹਾਰ ਸ਼ਾਮਲ ਹਨ ਜੋ ਆਟੋਮੇਸ਼ਨ ਦਾ ਵਿਰੋਧ ਕਰਦੇ ਹਨ

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

ਭਵਿੱਖਬਾਣੀ ਹਮੇਸ਼ਾ ਅਸਫਲ ਕਿਉਂ ਹੁੰਦੀ ਹੈ

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

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

ਤੀਜਾ, ਉਹ ਕਿਸੇ ਪੇਸ਼ੇ ਨੂੰ ਖਤਮ ਕਰਨ ਲਈ ਟਿਡੀਅਮ ਨੂੰ ਖਤਮ ਕਰਨ ਨੂੰ ਗਲਤ ਸਮਝਦੇ ਹਨ। ਅਕਾਊਂਟੈਂਟਸ ਨੂੰ ਸਪ੍ਰੈਡਸ਼ੀਟਾਂ ਦੁਆਰਾ ਖਤਮ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ - ਉਹਨਾਂ ਨੂੰ ਵਧੇਰੇ ਕੀਮਤੀ ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ ਕੰਮ ਕਰਨ ਲਈ ਆਜ਼ਾਦ ਕੀਤਾ ਗਿਆ ਸੀ। ਗ੍ਰਾਫਿਕ ਡਿਜ਼ਾਈਨਰਾਂ ਨੂੰ ਫੋਟੋਸ਼ਾਪ ਦੁਆਰਾ ਖਤਮ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ - ਉਹਨਾਂ ਨੂੰ ਉਹ ਚੀਜ਼ਾਂ ਬਣਾਉਣ ਲਈ ਸ਼ਕਤੀ ਦਿੱਤੀ ਗਈ ਸੀ ਜੋ ਪਹਿਲਾਂ ਅਸੰਭਵ ਸਨ। ਇਸੇ ਤਰ੍ਹਾਂ, ਪ੍ਰੋਗਰਾਮਿੰਗ ਆਟੋਮੇਸ਼ਨ ਦੀ ਹਰੇਕ ਲਹਿਰ ਨੇ ਵਿਕਾਸਕਰਤਾਵਾਂ ਨੂੰ ਐਬਸਟਰੈਕਸ਼ਨ ਦੇ ਉੱਚ ਪੱਧਰ 'ਤੇ ਸਮੱਸਿਆਵਾਂ ਨਾਲ ਨਜਿੱਠਣ ਲਈ ਆਜ਼ਾਦ ਕੀਤਾ ਹੈ, ਪਰ ਗੁੰਝਲਦਾਰ ਪ੍ਰਣਾਲੀਆਂ ਬਾਰੇ ਤਰਕ ਕਰ ਸਕਣ ਵਾਲੇ ਮਨੁੱਖਾਂ ਦੀ ਬੁਨਿਆਦੀ ਲੋੜ ਸਿਰਫ ਵਧੀ ਹੈ।

ਕਾਰੋਬਾਰਾਂ ਲਈ ਅਸਲ ਸਬਕ

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

ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਮਾਡਿਊਲਰ ਪਲੇਟਫਾਰਮ ਪਹੁੰਚ ਇਸਦੀ ਕੀਮਤ ਨੂੰ ਸਾਬਤ ਕਰਦੀ ਹੈ। ਜਦੋਂ ਕਾਰੋਬਾਰ ਆਪਣੀ ਕਾਰਜਸ਼ੀਲ ਰੀੜ੍ਹ ਦੀ ਹੱਡੀ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਮੇਵੇਜ਼ ਵਰਗੇ ਪਲੇਟਫਾਰਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ - CRM, ਇਨਵੌਇਸਿੰਗ, ਐਚਆਰ ਪ੍ਰਬੰਧਨ, ਬੁਕਿੰਗ ਪ੍ਰਣਾਲੀਆਂ, ਵਿਸ਼ਲੇਸ਼ਣ ਡੈਸ਼ਬੋਰਡ - ਉਹ ਤਕਨੀਕੀ ਸੋਚ ਦੀ ਜ਼ਰੂਰਤ ਨੂੰ ਖਤਮ ਨਹੀਂ ਕਰ ਰਹੇ ਹਨ। ਉਹ ਇਸ 'ਤੇ ਫੋਕਸ ਕਰ ਰਹੇ ਹਨ। ਫਲੀਟ ਪ੍ਰਬੰਧਨ ਤੋਂ ਲੈ ਕੇ ਲਿੰਕ-ਇਨ-ਬਾਇਓ ਟੂਲਸ ਤੱਕ ਹਰ ਚੀਜ਼ ਨੂੰ ਕਵਰ ਕਰਨ ਵਾਲੇ 207 ਮਾਡਿਊਲ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਵਿਕਾਸ ਸਰੋਤਾਂ ਨੂੰ ਸੌਵੀਂ ਵਾਰ ਹੱਲ ਕੀਤੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਮੁੜ ਖੋਜਣ ਦੀ ਬਜਾਏ ਅਸਲ ਨਵੀਨਤਾ ਵੱਲ ਸੇਧਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

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

ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ

ਪ੍ਰੋਗਰਾਮਰਾਂ ਨੂੰ ਖਤਮ ਕਰਨ ਦੀਆਂ ਪਿਛਲੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਹਮੇਸ਼ਾ ਅਸਫਲ ਕਿਉਂ ਹੁੰਦੀਆਂ ਹਨ?

"ਪ੍ਰੋਗਰਾਮਰ-ਰਿਪਲੇਸਿੰਗ" ਤਕਨਾਲੋਜੀ ਦੀ ਹਰ ਪੀੜ੍ਹੀ — COBOL ਤੋਂ ਲੈ ਕੇ ਵਿਜ਼ੂਅਲ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਤੋਂ ਬਿਨਾਂ-ਕੋਡ ਪਲੇਟਫਾਰਮਾਂ ਤੱਕ — ਆਖਰਕਾਰ ਇਸਨੂੰ ਹਟਾਉਣ ਨਾਲੋਂ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰਤਾ ਪੈਦਾ ਕਰਦੀ ਹੈ। ਇਹਨਾਂ ਸਾਧਨਾਂ ਨੇ ਸਧਾਰਣ ਕੰਮਾਂ ਲਈ ਦਾਖਲੇ ਦੀ ਰੁਕਾਵਟ ਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਘਟਾ ਦਿੱਤਾ, ਪਰ ਜਿਵੇਂ ਕਿ ਵਪਾਰਕ ਲੋੜਾਂ ਵਧੀਆਂ, ਸੰਗਠਨਾਂ ਨੂੰ ਅਜੇ ਵੀ ਏਕੀਕਰਣ, ਕਸਟਮ ਤਰਕ, ਸੁਰੱਖਿਆ ਅਤੇ ਪੈਮਾਨੇ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਹੁਨਰਮੰਦ ਡਿਵੈਲਪਰਾਂ ਦੀ ਲੋੜ ਸੀ। ਨਵੀਨਤਾ ਦੀ ਹਰ ਨਵੀਂ ਲਹਿਰ ਨਾਲ ਪ੍ਰੋਗਰਾਮਰਾਂ ਦੀ ਮੰਗ ਵਧੀ ਹੈ।

ਕੀ ਅੰਤ ਵਿੱਚ AI ਸਾਫਟਵੇਅਰ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਬਦਲ ਲਵੇਗਾ?

AI ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਉਤਪਾਦਕਤਾ ਗੁਣਕ ਹੈ, ਨਾ ਕਿ ਬਦਲੀ। ਜਿਵੇਂ ਕਿ ਸਪ੍ਰੈਡਸ਼ੀਟਾਂ ਨੇ ਲੇਖਾਕਾਰਾਂ ਨੂੰ ਖਤਮ ਨਹੀਂ ਕੀਤਾ, ਉਤਪੰਨ AI ਮਨੁੱਖੀ ਨਿਰਣੇ, ਆਰਕੀਟੈਕਚਰਲ ਸੋਚ, ਅਤੇ ਸਮੱਸਿਆ-ਹੱਲ ਕਰਨ ਦੀ ਲੋੜ ਨੂੰ ਹਟਾਏ ਬਿਨਾਂ ਵਿਕਾਸ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ। Mewayz ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਆਦਰਸ਼ ਪਹੁੰਚ ਦਾ ਪ੍ਰਦਰਸ਼ਨ ਕਰਦੇ ਹਨ — ਪਰਦੇ ਦੇ ਪਿੱਛੇ ਇੰਜੀਨੀਅਰਿੰਗ ਮਹਾਰਤ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹੋਏ ਕਾਰੋਬਾਰਾਂ ਨੂੰ ਸਸ਼ਕਤ ਕਰਨ ਲਈ 207 ਮਾਡਿਊਲਾਂ ਵਿੱਚ AI ਆਟੋਮੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ।

ਪ੍ਰੋਗਰਾਮਰਾਂ ਲਈ ਮੌਜੂਦਾ ਨੌਕਰੀ ਦਾ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਕੀ ਹੈ?

ਉਨ੍ਹਾਂ ਦੇ ਅਪ੍ਰਚਲਿਤ ਹੋਣ ਬਾਰੇ ਦਹਾਕਿਆਂ ਦੀਆਂ ਭਵਿੱਖਬਾਣੀਆਂ ਦੇ ਬਾਵਜੂਦ, ਪ੍ਰੋਗਰਾਮਰ ਦੀ ਮੰਗ ਅਸਧਾਰਨ ਤੌਰ 'ਤੇ ਮਜ਼ਬੂਤ ਬਣੀ ਹੋਈ ਹੈ। ਬਿਊਰੋ ਆਫ ਲੇਬਰ ਸਟੈਟਿਸਟਿਕਸ ਸਾਫਟਵੇਅਰ ਡਿਵੈਲਪਰ ਰੁਜ਼ਗਾਰ ਵਿੱਚ 25% ਵਾਧੇ ਦਾ ਪ੍ਰੋਜੈਕਟ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਜ਼ਿਆਦਾਤਰ ਪੇਸ਼ਿਆਂ ਨੂੰ ਪਛਾੜਦਾ ਹੈ। ਪੈਟਰਨ ਸਪੱਸ਼ਟ ਹੈ: ਹਰੇਕ ਨਵੀਂ ਤਕਨਾਲੋਜੀ ਜੋ ਪ੍ਰੋਗਰਾਮਰਾਂ ਨੂੰ ਬਦਲਣ ਦੀ ਬਜਾਏ ਇਸ ਦੇ ਦਾਇਰੇ ਦਾ ਵਿਸਤਾਰ ਕਰਦੀ ਹੈ ਕਿ ਸੌਫਟਵੇਅਰ ਕੀ ਪੂਰਾ ਕਰ ਸਕਦਾ ਹੈ, ਹਰ ਉਦਯੋਗ ਵਿੱਚ ਹੁਨਰਮੰਦ ਡਿਵੈਲਪਰਾਂ ਲਈ ਹੋਰ ਮੰਗ ਪੈਦਾ ਕਰਦਾ ਹੈ।

ਕਾਰੋਬਾਰ ਆਪਣੀਆਂ ਟੀਮਾਂ ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ ਆਟੋਮੇਸ਼ਨ ਤੋਂ ਕਿਵੇਂ ਲਾਭ ਉਠਾ ਸਕਦੇ ਹਨ?

ਸਭ ਤੋਂ ਚੁਸਤ ਪਹੁੰਚ ਵਾਧਾ ਹੈ, ਬਦਲਣਾ ਨਹੀਂ। Mewayz ਵਰਗੇ ਟੂਲ $19/mo ਤੋਂ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੇ ਇੱਕ 207-ਮੋਡਿਊਲ ਕਾਰੋਬਾਰੀ OS ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦੇ ਹਨ ਜੋ ਦੁਹਰਾਉਣ ਵਾਲੇ ਵਰਕਫਲੋ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰਦਾ ਹੈ — ਮਾਰਕੀਟਿੰਗ, CRM, ਸਮਾਂ-ਸਾਰਣੀ, ਇਨਵੌਇਸਿੰਗ — ਤਾਂ ਜੋ ਟੀਮਾਂ ਰਣਨੀਤਕ ਕੰਮ 'ਤੇ ਧਿਆਨ ਦੇ ਸਕਣ। ਇਹ ਇਤਿਹਾਸਕ ਸਬਕ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ: ਆਟੋਮੇਸ਼ਨ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਰੁਟੀਨ ਕੰਮਾਂ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ ਅਤੇ ਮਨੁੱਖਾਂ ਨੂੰ ਉੱਚ-ਮੁੱਲ ਦੀਆਂ ਚੁਣੌਤੀਆਂ ਨਾਲ ਨਜਿੱਠਣ ਲਈ ਮੁਕਤ ਕਰਦਾ ਹੈ।