Ford ने AI क्वालिटी इंस्पेक्शन में दिक्कत के बाद ‘gray beard’ इंस्पेक्टरों को फिर से नियुक्त किया

• Ford Motor Co. ने लंबे समय से चली आ रही quality problems को कम करने के लिए “gray beard” कहे जाने वाले veteran engineers को फिर से बुलाया है, ताकि वे युवा कर्मचारियों को ट्रेनिंग दें और AI tools की कमियों को पूरा करें
• पिछले 3 सालों में 350 veteran engineers को नियुक्त किया गया है; इनमें कई पूर्व Ford कर्मचारी हैं और कुछ suppliers से आए हैं
• उम्मीद के मुताबिक प्रदर्शन न कर पाने वाले AI tools के भरोसे ही quality issues से निपटना मुश्किल रहा, और इन समस्याओं ने कंपनी पर अरबों डॉलर की लागत डाली
• फिर से नियुक्त किए गए लोग on-site judgment सिखाने के साथ-साथ quality response में इस्तेमाल होने वाले AI tools को दोबारा tune करने की भूमिका निभा रहे हैं
• Ford ने गुरुवार को जारी नवीनतम JD Power Initial Quality Survey में mass-market brands के बीच पहला स्थान हासिल किया

---

veteran कर्मियों से मजबूत की गई quality response

• Ford Motor Co. ने लंबे समय से बने हुए quality problems को सिर्फ automation से हल करने के बजाय, अनुभवी लोगों को फिर से तैनात करके इसका जवाब दिया
• कंपनी जिन engineers को “gray beard” कहती है, वे युवा कर्मचारियों के निर्णय लेने में मदद करते हैं और उम्मीद के मुताबिक नतीजे न देने वाले AI tools को फिर से प्रोग्राम करते हैं

3 साल में 350 लोगों की पुनर्नियुक्ति

• Ford ने पिछले 3 सालों में 350 veteran engineers को नियुक्त किया
• भर्ती किए गए लोगों में कई पूर्व Ford कर्मचारी शामिल हैं, और कुछ supplier कंपनियों से आए engineers भी हैं
• इन्हें उन quality problems से निपटने के लिए लगाया गया जिन्हें सुलझाना मुश्किल दिख रहा था

AI tools की सीमाएँ और लागत का दबाव

• quality problems को हल करने में इस्तेमाल किए गए Ford के AI tools उम्मीद के मुताबिक अपनी भूमिका पूरी तरह नहीं निभा सके
• quality problems ने Ford पर अरबों डॉलर की लागत डाली
• कंपनी veteran engineers के अनुभव का उपयोग करके AI tools और युवा कर्मचारियों, दोनों की क्षमता को साथ-साथ मजबूत करना चाहती है

JD Power सर्वे के नतीजे

• Ford ने गुरुवार को जारी नवीनतम JD Power Initial Quality Survey में mass-market brands के बीच पहला स्थान हासिल किया
• इस नतीजे को veteran engineers की पुनर्नियुक्ति और quality problems के खिलाफ उठाए गए कदमों के बाद मिली उपलब्धि के रूप में भी पेश किया गया है

[GN⁺]

Hacker News की राय

• 2000 के दशक के मध्य की offshoring लहर देख चुके लोगों के नज़रिए से, यह मौजूदा रुझान भी लगभग उसी रास्ते पर चल रहा है
  बड़ी कंपनियों के CEO/CFO अपने golf दोस्तों से यह शेख़ी बघारते हैं कि “विदेशी workforce से कितना बचाया”, और पहले चरण में बड़ी संख्या में लोगों को निकालकर काम विदेश भेज दिया जाता है, जिससे 5~6 तिमाहियों तक financial metrics सुधर जाते हैं
  दूसरे चरण में कर्मचारियों और संगठन का ढाँचा टूटने लगता है, और यह साफ़ होने लगता है कि cultural और communication barriers को अब भी असरदार ढंग से पार करना मुश्किल है। बहुत कम लोग इसे सही तरह कर पाते हैं, ज़्यादातर के लिए यह फिट नहीं बैठता
  तीसरे चरण तक आते-आते जो लोग दूसरी नौकरी ढूँढ सकते थे वे जा चुके होते हैं, और कंपनी जली हुई खोल जैसी बचती है, जो पाँचवें चरण में स्वाभाविक रूप से खत्म हो जाती है
  • असली बात अल्पकालिक मुनाफ़े की है। Accenture और Infosys जैसी कंपनियों के partners पुराने industrial कंपनियों के executives को घेरते हैं, और कंपनी का प्रदर्शन बिगड़ भी जाए तो accounting tricks से उसे कुछ समय छिपाया जा सकता है
    फिर जब एक तिमाही बुरी तरह बिगड़ती है, तो पूरा financial year हिल जाता है, blame game शुरू होता है, और “belt-tightening”, “fixed cost को variable cost में बदलना” जैसी बातें आने लगती हैं
    उसी समय Big Consulting का वह प्रस्ताव, जिसे इसी financial year में तुरंत cost saving के रूप में दिखाया जा सके, बहुत आकर्षक लगने लगता है
    दरारें जल्दी दिखने लगती हैं: program/project management कमज़ोर होता है, service quality गिरती हुई लगती है लेकिन उसके metrics नहीं होते, पहली टीम के जाने पर outsourcing staff को फिर से train करना पड़ता है, और नए projects का sizing भी नहीं हो पाता
    business unit के भीतर shadow IT department बन जाते हैं, और outsourcing vendor को vendor consolidation या दूसरे vendors पर दबाव डालने में कोई दिलचस्पी नहीं होती
    अगर मकसद लगातार खराब प्रदर्शन करने वाले IT department को रणनीतिक रूप से सुधारना हो, तो इसमें कुछ value हो सकती है, लेकिन core business की गिरावट छिपाने के लिए जल्दबाज़ी में किया जाए तो लगभग कभी काम नहीं करता
  • मज़ेदार बात यह है कि सब मानते हैं कि ऐसी leadership खराब है, लेकिन जब खुद वैसी ही authority और decision-making position पर पहुँचते हैं, तो ज़्यादातर वही काम करते हैं
  • यह अब भी लगातार हो रहा है, बस कुछ internal technical staff को बचाकर रखने की कोशिश की जाती है। दिक्कत यह है कि internal staff को सिद्धांततः खुद बदलाव नहीं करना चाहिए, सिर्फ “मदद” करनी चाहिए, इसलिए उनके पास टिके रहने की प्रेरणा कम होती है
  • इसका हल तो साफ़ है: cultural barriers को AI से पार करो। translation भी हो जाएगी, तो overseas staff को company language जानने की भी ज़रूरत नहीं रहेगी और cost और घट जाएगी /s
• कर्मचारियों को निकालकर AI से replace करने का विचार अपने आप में कितना short-sighted है, यह अलग बात है, लेकिन Ford ने गलत कर्मचारियों को निकाला
  LLM उन skilled senior engineers के हाथ में सबसे अच्छा काम करता है जो इन building blocks को पहले से समझते हैं और ऊँचे abstraction level पर काम कर सकते हैं
  एक मायने में LLM agent का इस्तेमाल करना ऐसा है जैसे किसी बहुत तेज़ और smart, लेकिन blind spots वाले और organizational knowledge की कमी वाले junior को निर्देश देना
  इसे सही ढंग से चलाना senior की क्षमता है, इसलिए अगर seniors को हटा दिया गया, तो LLM का सबसे अच्छा इस्तेमाल करने वाले लोगों को ही बाहर कर दिया गया
  • यह तो बिल्कुल बुनियादी बात है। जटिल architecture task prompts बनाने के लिए कम से कम abstraction level पर समाधान का पता होना चाहिए
    अगर आपके दिमाग में सही system design ही नहीं है, तो कोई भी LLM उसे हवा से पैदा नहीं कर सकता
  • Ford ने कर्मचारियों को निकाला, यह किसने कहा? लेख में ऐसा कुछ नहीं है
• models hype पर खरे नहीं उतरे, इसलिए यह रुझान कुल मिलाकर एक मानक क्रम की तरह ही सामने आएगा
  LLM और agents मुश्किल समस्याएँ हल करने में बहुत मददगार हैं, लेकिन हम अभी उस स्तर पर नहीं पहुँचे जहाँ हम सिर्फ design और architecture करें और बाकी सब काम उन्हें सौंप दें
  हम उसके काफ़ी करीब पहुँचे हैं, और कुछ specific use cases में यह शायद पहले से संभव भी हो, लेकिन low-level काम या बड़े enterprises के large-scale migration work के लिए यह अभी भी पर्याप्त नहीं है
  agents हैं, agents के agents भी हैं, लेकिन फिर भी कई बार project के बड़े हिस्से निकालकर फेंकने पड़ते हैं क्योंकि code बेकार होता है और कुत्तों के आगे डालने लायक होता है। यह GLM-5.2 के आधार पर कहा गया है
  • यहाँ document-driven development मदद करता है। मेरे workflow का 75% हिस्सा अलग-अलग abstraction levels पर documents बनाते हुए धीरे-धीरे नीचे जाना है, जब तक कि वह आखिर में code न बन जाए
    tests पास होने के बाद आम तौर पर code optimal, साफ़-सुथरा, bug-free और बहुत अच्छी तरह documented होता है
    लेकिन इंसान को लगातार बार-बार बीच में दखल देना पड़ता है
• https://archive.is/DI4Cq
  The Verge ने भी इसे कवर किया है:
  https://www.theverge.com/transportation/956316/ford-quality-...
  • सभी मीडिया outlets को इसे और ज़्यादा कवर करना चाहिए
• industrial field में AI के fail होने की वजह यह है कि SKILL.md या दूसरे knowledge injection तरीक़े compliance की गारंटी नहीं देते। AI को लगता है कि उसे “ज़्यादा बेहतर पता है”
  • मेरा एक दोस्त भी इसे रोकने के लिए hook जैसे ढेर सारे तंत्र तैयार कर चुका है, लेकिन LLM अब भी कभी-कभी उन्हें तोड़ देता है
    मुझे नहीं लगता कि इसका कोई पूर्णतया अचूक समाधान मौजूद है
  • पता नहीं यह irony है या नहीं। मेरी नज़र में failure की मुख्य वजह यह है कि बहुत-सा knowledge और experience intuitive होता है और documented नहीं होता
  • अगर compliance ही मुख्य समस्या होती, तो हमें यह रोकने का तरीका ईजाद करने की ज़रूरत ही नहीं पड़ती कि कंप्यूटर सिर्फ वही न करें जो उन्हें बताया गया है
• अमेरिकी software engineers को union चाहिए
  अगर उन्होंने कहीं और नौकरी नहीं पकड़ ली है, तो 20% salary hike और लोहे जैसा मजबूत contract मिले बिना उन्हें वापस नहीं जाना चाहिए
  • इस industry में boom और bust का चक्र चलता रहता है। projects आते हैं और गायब हो जाते हैं, और software company में काम करने पर भी बस यह उतार-चढ़ाव थोड़ा कम होता है
    अगर आप सीमित upside स्वीकार करके stability चाहते हैं, तो IT/server management बेहतर हो सकता है, क्योंकि वहाँ लगातार ज़रूरत बनी रहती है
• Ford ने पिछले 3 वर्षों में 350 engineers भर्ती किए, और यह AI inspection tools के कमज़ोर इस्तेमाल के समानांतर हुआ
  इसका LLM से संबंध नहीं है, और यह लगभग निश्चित रूप से custom IBM hardware पर पुराने convolutional neural network (CNN) के साथ visual inspection करने वाले MAIVIS और AiTriz pilot के बारे में है
  • सही कहा। लगता है बहुत से लोग timing वाले अहम बिंदु को मिस कर रहे हैं। गलती 3 साल पहले पहचानी गई थी, और automotive design व manufacturing process का lead time लंबा होता है
    ऊपर से इस कहानी का ट्रिगर यह है कि “Ford JD Power quality survey ranking में फिर से ऊपर लौटा”, इसलिए सिर्फ reporting delay ही 6~18 महीने और जोड़ देता है
    इस तरह देखें तो मूल layoff गलती 5~8 साल पहले हुई थी

यह नहीं पता कि बताए गए “MAIVIS और AiTriz पायलट” कब लागू किए गए थे, लेकिन एक और संभावना यह है कि Ford की PR टीम ने यह देखा हो कि अभी AI backlash वाली कथा चलन में है, और कई वजहों से हुए किसी सकारात्मक news event को समझाने में उसे अवसरवादी तरीके से उभार दिया हो
व्यक्तिगत रूप से, मुझे लगता है कि ऐसी “AI backlash” थीम वाली खबरों को उतनी ही सीमित दृष्टि से देखना चाहिए जितना पहले उन “AI के कारण layoffs” वाली थीम को देखा जाना चाहिए था, जिन्हें कंपनियाँ वैसे भी करने वाली छंटनी को सही ठहराने के लिए पकड़ लेती थीं

• सबमिशन का शीर्षक था “Ford rehires 350 engineers after AI fails to preserve expertise or train juniors”, लेकिन लेख की सामग्री ऐसी नहीं कहती
  सबमिटर से: “Please submit the original source. If a post reports on something found on another site, submit the latter.” - https://news.ycombinator.com/newsguidelines.html
  अभी इसे लेख के मूल शीर्षक पर वापस कर दिया गया है
  और जोड़ूँ तो, मीडिया कभी-कभी लेख का शीर्षक बदल देता है, इसलिए आम तौर पर सबमिटर ने guidelines का पालन ही किया होता है, बस हमें उसे पकड़ने में कभी-कभी समय लग जाता है
• सही है, इसका AI से कोई संबंध नहीं लगता। अच्छा होगा अगर यह टिप्पणी सबसे ऊपर पहुँच जाए
• पहली कोशिश नाकाम रही, इसलिए अभी पीछे हटे हैं, लेकिन कुछ समय बाद फिर कोशिश करेंगे और उन लोगों को फिर से निकाल देंगे
  • स्थायी श्रम मशीन का सपना ऐसा है जिसके पीछे पूंजीपति इस हद तक आसक्त हैं कि इस काल्पनिक सपने का पीछा करते हुए पृथ्वी तक को नष्ट कर दें। उत्पीड़क रुकने चाहिए
• ज्ञान दो तरह का होता है। एक explicit knowledge है, जिसे markdown files या wiki में आसानी से codify किया जा सकता है, और दूसरा tacit knowledge है, जो मुख्यतः संगठन के लोगों के अनुभव में समाया होता है
  explicit knowledge, संगठनात्मक ज्ञान के विशाल हिमखंड की बस चोटी जैसा होता है
  • उस tacit knowledge का कोई ऐसा मूल्य नहीं होता जिसे आसानी से quantify किया जा सके, और वह P&L में भी नहीं दिखता, इसलिए अधिकांश executives उसे ध्यान में नहीं रखते
    मैंने अपने करियर में यह बार-बार होते देखा है। जब कोई चला जाता है या layoffs होते हैं, और इसे ध्यान में नहीं रखा जाता, तो कंपनी बाद में हड़बड़ाकर यह समझने लगती है कि कोई प्रक्रिया जिसे कोई व्यक्ति वर्षों से चुपचाप चला या maintain कर रहा था, और जिसके बारे में किसी और ने सोचा भी नहीं था, असल में कैसे काम करती थी
  • distillation process का इस्तेमाल किया जा सकता है। जैसे AI को senior engineer से बार-बार सवाल पूछने दिए जाएँ, हालाँकि ऐसा नहीं करना चाहिए। जैसे जैतून से तेल निचोड़ा जाता है
• इसे सरल तरीके से सोचें। अगर 100 कर्मचारियों वाली कोई कंपनी एक समय में 12 घर बनाती है, तो वह 6 लोगों की framing team को 2 लोगों + 1 robot वाली team में बदलने का प्रयोग कर सकती है
  बेहतर विकल्प है या नहीं, यह देखने के लिए कई प्रयोग किए जा सकते हैं, और उसकी कीमत 4 कर्मचारियों को चुकानी पड़ेगी
  अगर 1000 कर्मचारियों वाली कंपनी एक समय में 100 घर बनाती है, तो लगभग 12 लोगों को घटाकर 3 robot teams बनाई जा सकती हैं
  अगर 10,000 कर्मचारियों वाली कंपनी एक समय में 1000 घर बनाती हो, तब भी प्रयोग के लिए सिर्फ कुछ teams ही काफी होंगी, और प्रभावित कर्मचारियों की संख्या शायद 20-30 तक ही सीमित रहेगी
  हैरानी की बात यह है कि कोई कंपनी अपने ही कारोबार से इतनी दूर हो सकती है कि इस स्तर के mass harm के बिना वह बदलाव के असर को समझ ही न सके