ChatGPT, GitHub Copilot, Cursor आणि त्यांचे इतर सहकारी आता तुम्ही प्रॉम्प्ट टाईप पूर्ण करण्यापूर्वीच React component तयार करून देऊ शकतात. Next.js route ला Supabase शी जोडायचे आहे? काही सेकंदात काम पूर्ण. तो गुंतागुंतीचा TypeScript utility refactor करायचा आहे? येथे type guards सह तीन पर्याय उपलब्ध आहेत. आधुनिक वेब स्टॅक्समध्ये काम करणाऱ्या कोणालाही, हा अनुभव एखाद्या जादूसारखा वाटू शकतो.
मी ही साधने दररोज वापरतो. माझे स्टॅक Next.js, TypeScript आणि Supabase आहे, आणि AI माझ्या एडिटरमध्येच उपलब्ध असते, जी custom hooks तयार करण्यासाठी, डेटाबेस क्वेरीज जनरेट करण्यासाठी किंवा विस्कळीत conditional logic स्वच्छ करण्यासाठी तयार असते. छोट्या कामांसाठी, ते एका अतिशय वेगवान ज्युनियर डेव्हलपरप्रमाणे काम करते. त्याला सिंटॅक्स तोंडपाठ असतो. मला Google करावे लागणारे API surface areas त्याला आठवतात. बॉयलरप्लेट (boilerplate) लिहिताना ते थकत नाही.
पण सॉफ्टवेअरमध्ये चुका (bugs) होतच राहतात. ॲप्स अधिक संथ वाटतात. कस्टमर डॅशबोर्ड्स लॅग होतात. Edge cases मुळे फॉर्म्स क्रॅश होतात. जर AI मुळे कोडिंग इतके सोपे झाले असेल, तर सॉफ्टवेअर वापरण्याचा अनुभव काही वर्षांपूर्वीपेक्षा आता अधिक वाईट का वाटत आहे?
याचे उत्तर असे आहे की, सिंटॅक्स जनरेट करणे आणि सॉफ्टवेअर तयार करणे या दोन वेगळ्या गोष्टी आहेत.
सिंटॅक्स म्हणजे आर्किटेक्चर नाही
AI टोकन्स हाताळण्यात अत्यंत कुशल आहे. त्याला Supabase real-time channel वर लक्ष ठेवणारा useEffect hook लिहायला सांगा, आणि तुम्हाला कंपाईल होण्यासारखा कोड मिळेल. ते एखादी untyped JavaScript फाईल strict TypeScript मध्ये रूपांतरित करू शकते, किंवा तुम्ही कॉफी पिण्यापूर्वी Zod validation सह फॉर्म component तयार करून देऊ शकते.
जे ते करू शकत नाही, ते म्हणजे तुमच्या विशिष्ट ॲप्लिकेशनची रचना (contours) समजून घेणे. चांगल्या सॉफ्टवेअरसाठी विचारपूर्वक state management, race conditions चे काळजीपूर्वक व्यवस्थापन आणि डेटा कुठे साठवला आहे आणि कुठे फक्त प्रदर्शित केला आहे याचा स्पष्ट नकाशा आवश्यक असतो. AI फक्त समोरची फाईल पाहते, संपूर्ण सिस्टम नाही. ते तुमच्या कोडबेसकडे एखाद्या जिवंत रचनेसारखे न पाहता, केवळ एका सपाट मजकूर कॉरिडॉरसारखे (flat text corridor) पाहते.
एखाद्या अशा आर्किटेक्टचा विचार करा ज्याने कधीही प्रत्यक्षात घरात वास्तव्य केलेले नाही. ते सुंदर फ्लोअर प्लॅन्स काढू शकतात. बेडरूमला किती खिडक्या असाव्यात हे त्यांना माहित असते. पण फेब्रुवारीमध्ये पाईप्स कुठे गळू शकतात किंवा उन्हाळ्यात कोणता हॉल वापरण्यायोग्य राहत नाही, हे त्यांना माहित नसते. हे प्रत्यक्ष अनुभवातून आलेले ज्ञानच इमारतीला टिकवून ठेवते. कोडचे कामही अगदी तसेच असते.
दोन अडथळे (The Two Friction Points)
जेव्हा मी कडक नियमावलीशिवाय (guardrails) AI ला कोडचे मोठे भाग लिहू देतो, तेव्हा मला पुन्हा पुन्हा दोन सारख्याच समस्या जाणवतात.
पहिले म्हणजे, ते तुम्ही आधीच प्रस्थापित केलेले डिझाइन पॅटर्न즈 दुर्लक्षित करते. कदाचित तुमची टीम सर्व डेटा फेचिंग (data fetching) custom hooks च्या एका समर्पित लेयरमध्ये करते. कदाचित Supabase RLS policies कशा प्रकारे frontend helpers शी मॅप होतील याचे तुमचे कडक नियम असतील. AI ला याने काही फरक पडत नाही. जर तात्काळ प्रॉम्प्ट सोडवण्यासाठी ते शक्य असेल, तर ते थेट बटणाच्या onClick मध्ये supabase.from().select() टाकून देईल. कोड रन होतो. तो दिसायलाही स्वच्छ वाटतो. पण तो तुमच्या कोडबेसमध्ये एक 'आउटलायर' (outlier) असतो, आणि प्रत्येक आउटलायर म्हणजे भविष्यातील 'refactoring tax' असतो. सहा महिन्यांनंतर, कोणालातरी ती सुई शोधून काढावी लागेल, ती का तिथे आहे हे समजून घ्यावे लागेल आणि तिला पुन्हा योग्य मार्गावर आणावे लागेल.
दुसरे म्हणजे, जिथे साधेपणा पुरेसा आहे तिथे ते गुंतागुंत निर्माण करते. या टूलला अशा रिपॉझिटरीजवर प्रशिक्षित केले गेले आहे ज्यांना abstract factories, गुंतागुंतीचे reducer patterns आणि multi-layered higher-order components ची गरज असते. जेव्हा तुम्ही त्याला एक साधा कॉन्टॅक्ट फॉर्म बनवायला सांगता, तेव्हा ते तुम्हाला एक state machine, एक context provider आणि तीन फाईल्समध्ये पसरलेले custom hook abstraction देऊन टाकू शकते. हे समाधान तांत्रिकदृष्ट्या चुकीचे नसते, पण ते खूप जड (heavy) असते. प्रत्येक अनावश्यक लेयर 'कॉग्निटिव्ह डेट' (cognitive debt) वाढवते. तुम्ही काम टाळले नाही; तुम्ही ते व्याजासह पुढे ढकलले आहे.
वेगाचा सापळा (The Velocity Trap)
येथे एक धोकादायक फीडबॅक लूप आहे. AI तुम्हाला दुप्पट वेगाने फीचर्स तयार करण्यास मदत करते, परंतु मानवी लक्ष (attention) त्याच प्रमाणात वाढू शकत नाही. जर तुम्ही अर्ध्या वेळेत काम पूर्ण करत असाल, तर तुम्ही कोड रिव्ह्यूसाठी दुप्पट वेळ खर्च करत आहात का? तुम्ही अधिक टेस्ट लिहित आहात की कमी?
व्यवहारात, जनरेट केलेल्या कोडवर विश्वास ठेवणे खूप सोपे असते कारण तो अधिकृत वाटतो. तो आधुनिक सिंटॅक्स वापरतो. अगदी योग्य ठिकाणी कमेंट्स दिलेल्या असतात. व्हेरिएबलची नावे व्यावसायिक वाटतात. पण त्या चकाकीमध्ये सूक्ष्म बग्स (subtle bugs) लपलेले असतात. एखाद्या hook मधील dependency array मध्ये setter विसरणे, तांत्रिकदृष्ट्या बरोबर असलेला पण तुम्ही हाताळायला विसरलेला null state परवानगी देणारा TypeScript type, किंवा तुमच्या विशिष्ट स्कीमामध्ये soft-deleted rows विचारात घ्यायला विसरलेली Supabase query. तुम्ही प्रत्येक ओळ वाचण्याऐवजी फक्त वरवर पाहता, कारण डिलिव्हरीचा वेग तशी मागणी करतो. सोमवारी तो वेग खूप छान वाटतो, पण शुक्रवारी डिबगिंग सेशन मध्यरात्रीपर्यंत चालते.
खरा खर्च (The Real Cost)
याचा खर्च डेव्हलपर्सना नाही, तर शेवटच्या वापरकर्त्यांना (end users) सोसावा लागतो.
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