पसंद (taste) के साथ 30x AI इंजीनियर कैसे बनें

 (pakodas.substack.com)
22 पॉइंट द्वारा GN⁺ 4 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • AI के बड़े पैमाने पर code generate करने के इस दौर में engineer की value को अलग करने वाली मुख्य क्षमता speed, knowledge या experience नहीं, बल्कि ‘taste’, यानी क्या बनाना है यह तय करने की मूल्यांकन क्षमता है
  • OpenAI Codex टीम के सदस्यों ने स्वतंत्र रूप से इसी निष्कर्ष पर पहुंचकर बताया कि अच्छा software taste रखने वाला कोई भी व्यक्ति 10x engineer बन सकता है
  • taste को recognition, compass, vision इन तीन रूपों में बांटा जा सकता है, और ये सभी internal evaluation function की quality नामक एक ही mechanism पर आकर मिलते हैं
  • value मुख्य रूप से problem selection, system architecture, quality judgment, user empathy, communication इन पांच क्षेत्रों में पैदा होती है
  • अब जब code writing commoditized हो चुकी है, judgment और thinking ही असली मूल क्षमता हैं, और इन्हें जानबूझकर विकसित करना होगा

दुनिया बदल चुकी है, लेकिन ज्यादातर engineers ने इसे महसूस नहीं किया

  • Anthropic के CEO Dario Amodei ने मार्च 2025 में भविष्यवाणी की थी कि AI कुछ महीनों में 90% code लिखेगा; उस समय यह बेतुका लगा था
  • Claude Code के निर्माता Boris Cherny ने बताया कि दिसंबर में उनके commit किए गए code का 100% AI ने लिखा था, और उन्होंने एक बार भी IDE नहीं खोला
  • AI coding tools को “slop” कहने वाले Andrej Karpathy ने दिसंबर में अपना रुख पूरी तरह बदल लिया
    • “एक programmer के रूप में मैंने खुद को कभी इतना पीछे छूटा हुआ महसूस नहीं किया, और यह पेशा नाटकीय रूप से पुनर्गठित हो रहा है”
    • Ruby on Rails के निर्माता DHH ने माना कि उनका विरोध इसलिए था क्योंकि “models पर्याप्त अच्छे नहीं थे”, और अब स्थिति पलट चुकी है
    • Vercel के CTO Malte Ubl ने कहा कि “software production की लागत 0 की ओर converge कर रही है”
  • नवंबर–दिसंबर 2025 के बीच Opus 4.5, GPT-5.2, Gemini 3 ने अदृश्य capability boundaries को पार कर लिया, और व्यापक कार्यों में AI code कुशल engineers के स्तर तक पहुंच गया; लगने वाला समय घंटों से मिनटों में सिमट गया
  • जब code generation commoditized हो जाता है, तब जो बचता है वह है software engineering—problem decomposition, क्या बनाना है इसका निर्णय, testing, reliability, scalability design, और trade-off judgment—यानी taste

आखिर taste होता क्या है

  • बेहतरीन engineering teams जिस taste की बात करती हैं, उसकी तीन परिभाषाएं हैं, और ये एक ही क्षमता को अलग-अलग कोण से देखती हैं

  • recognition के रूप में taste

    • दो implementations को देखकर, वजह समझाने से पहले ही यह महसूस कर लेना कि कौन सा बेहतर है
    • Emma Tang: कोई system सच में साफ-सुथरा, scalable, duplication से मुक्त और समझने में सरल है या नहीं, यह taste का सवाल है
    • जैसे sauce चखने वाला chef यह बात सचेत रूप से पहचानने से पहले ही जान लेता है कि उसमें acidity कम है, वैसे ही pattern matching, conscious reasoning से तेज काम करती है
    • Codex टीम ने CLI के लिए TypeScript की जगह Rust चुना
      • दोनों काम कर सकते थे, लेकिन उन्होंने पहचाना कि Rust की constraints—strong typing, explicit memory management, minimal dependencies—तकनीकी फायदों से आगे जाकर engineering culture पर असर डालती हैं
      • यह “technically superior language” नहीं, बल्कि “वह language जो टीम में वांछित behavior बनाती है” वाला निर्णय था
    • खराब taste: सिर्फ इसलिए Rust चुन लेना कि वह trend में है, या किसी blog ने उसे fast बताया है, जबकि second-order effects की समझ न हो

  • compass के रूप में taste

    • Tibo के शब्दों में engineer के पास “अपना compass” होना चाहिए; यह पहले से मौजूद चीज़ का मूल्यांकन नहीं, बल्कि अगला क्या बनाना है यह जानने की क्षमता है
    • वह engineer जो एक line code लिखने से पहले कह दे, “यह सही feature नहीं है”
    • Boris Cherny ने Claude Code के todo list feature के लिए लगभग 20 prototypes दो दिनों में बनाए
      • inline todo, drawer UI, interactive pill, screen के नीचे display जैसी कई कोशिशों के बाद रूप धीरे-धीरे ऐसे विकल्प पर converge हुआ जो arbitrary नहीं, बल्कि inevitable लगता था
      • बाद में वह समझा सके कि final version बेहतर क्यों था, लेकिन बीच के versions के प्रति शुरुआती असंतोष ही compass की तरह काम करने वाला taste था
    • compass वाला taste, execution से पहले की upstream stage में काम करता है, इसलिए recognition वाले taste से भी दुर्लभ है

  • vision के रूप में taste

    • SQ Mah के “इंसान evolution को define करता है” वाले कथन में व्यक्त यह सबसे कठिन रूप है: अभी क्या अच्छा है नहीं, बल्कि दो साल बाद क्या महत्वपूर्ण होगा यह जानना
    • OpenClaw के निर्माता Peter Steinberger एक साथ 5–10 agents चलाते हैं और अपना अधिकतर समय architecture और system design में लगाते हैं
      • उन्होंने कहा, “ज्यादातर code उबाऊ data transformation है; ऊर्जा system design पर केंद्रित करो”
    • Codex टीम की अगली priority rich context-based planning है, जिसके लिए business goals, market dynamics, team priorities जैसी codebase के बाहर की जानकारी चाहिए
      • यह सिर्फ बेहतर code generator नहीं, बल्कि उस भविष्य की ओर product strategy पर लागू vision taste है जिसमें model यह समझता है कि software आखिर मौजूद क्यों है

  • एकीकृत परिभाषा

    • ये तीनों रूप एक ही mechanism पर converge करते हैं: taste है internal evaluation function की quality
    • recognition में evaluation function तैयार output पर काम करती है, compass में possibilities और direction पर, और vision में future और trajectory पर
    • AI द्वारा code generate करने वाली दुनिया में इंसान का काम है evaluation—क्या बनाना है यह तय करना, output पर्याप्त है या नहीं यह जांचना, और architecture बदलने का सही समय पहचानना; यही evaluation अब job itself है

कुछ engineers दूसरों से कहीं ज्यादा क्यों कमाते हैं

  • AI से पहले compensation gap को company, seniority, और specialization इन तीन चीजों से समझा जाता था, लेकिन AI इन तीनों variables को गड़बड़ा रहा है
  • startup में बेहतरीन engineer और औसत engineer के बीच का अंतर 3x से बढ़कर 10x हो गया है, क्योंकि बेहतर engineer AI के सहारे छोटे team की output निकाल पा रहा है
  • seniority का axis बदल रहा है; code लिखने का experience से ज्यादा अच्छे judgment का experience महत्वपूर्ण हो गया है
    • “React जानता है” का value घट रहा है, जबकि “load की स्थिति में reliable system design कर सकता है” का value बढ़ रहा है
  • जिन engineers का gap बड़ा है, उनमें एक समानता है: वे ऐसे decisions लेते हैं जो compound होकर जमा होते हैं
    • एक अच्छा architecture decision एक साल में कई महीनों का काम बचा सकता है
    • एक अच्छा product decision यह तय कर सकता है कि कोई feature वास्तव में adopt होगा या नहीं
  • आप ज्यादा मेहनत करके भी बेहतर taste वाले व्यक्ति से आधी value ही पैदा कर सकते हैं; गलत problem पर 8 agents चलाने से बेहतर है सही problem पर 2 agents चलाना
  • OpenAI के उदाहरण में सबसे productive engineers वे नहीं थे जिन्होंने ज्यादा code generate किया, बल्कि वे थे जिन्होंने users के साथ बातचीत, product direction, empathy पर ज्यादा समय लगाया और अपना focus बदला
    • कुछ लोग “codebase की feel खो रही है” कहते हुए tab autocomplete पर लौट गए; दोनों प्रतिक्रियाएं वैध हैं

value वास्तव में कहां पैदा होती है

  • ऐसी पाँच ज़ोन मौजूद हैं जहाँ taste असंतुलित value बनाता है; ज़्यादातर engineers सिर्फ एक-दो ज़ोन में ही प्रतिस्पर्धा करते हैं

  • Zone 1: समस्या का चयन

    • क्या करना है, यह चुनना सबसे high-leverage taste decision है, लेकिन ज़्यादातर लोग इस पर लगभग सोचते ही नहीं
    • taste वाले engineers पूछते हैं: “अगर इसे अच्छी तरह सुलझा दूँ, तो क्या बाकी पाँच समस्याएँ गायब हो जाएँगी?”
    • Peter Steinberger लंबे समय तक agent के साथ आगे-पीछे बातचीत करके plan को refine करते हैं, challenge और rebuttal करते हैं, और सिर्फ संतुष्ट होने पर ही agent को चलाते हैं; plan ही काम है और execution delegate किया जाता है
    • Claude Code के permission system में जटिल RBAC और granular policy की जगह सबसे सरल approach चुना गया: permission request के बाद जवाब को याद रखना; इससे product तेज़ी से और सहज रूप में launch हुआ

  • Zone 2: सिस्टम आर्किटेक्चर

    • यह वह तरीका है जिससे हिस्से आपस में जुड़ते हैं; taste का सबसे लंबा half-life इसी ज़ोन में होता है; अच्छे decisions 2 साल बाद भी dividend देते हैं, बुरे decisions rewrite माँगने वाले technical debt के रूप में जमा होते जाते हैं
    • Codex के agent loop को state machine के रूप में बनाना, Claude Code में “जहाँ तक संभव हो business logic कम से कम” लिखने का decision, और OpenClaw की modular extensibility के प्रति ज़िद—ये सब architecture taste decisions हैं
    • Boris Cherny: “हर बार नया model आने पर हम बहुत सारा code delete करते हैं, और model के आसपास जितना संभव हो उतना कम code रखते हैं”
      • ज़्यादातर teams हर release में code जोड़ती हैं, लेकिन Claude Code team उसे हटाती है; model ही product है, और उसके आसपास की layer जितनी हो सके उतनी पतली होनी चाहिए

  • Zone 3: गुणवत्ता का निर्णय

    • यह जानना कि launch के लिए पर्याप्त है या और काम चाहिए; यह वह ज़ोन है जहाँ AI मदद नहीं कर सकता, क्योंकि उसे किसी खास context में “काफी” का अर्थ नहीं पता
    • Codex का layered code review: non-core code के लिए सिर्फ AI review, core agent code के लिए human review अनिवार्य
      • taste इस बात में है कि कौन-सा code महत्वपूर्ण है; permission system को human eyes चाहिए, README update को नहीं
    • Codex team लगभग सारा code prompts से लिखती है, लेकिन company के दूसरे विभाग लगभग 70% के स्तर पर हैं; हाथ से लिखा जाने वाला 30% वही हिस्सा है जहाँ quality judgment सबसे महत्वपूर्ण है (“30/70 rule”)

  • Zone 4: उपयोगकर्ता के प्रति सहानुभूति

    • सामने वाले इंसान को वास्तव में क्या चाहिए, इसे समझना; यह AI का सबसे कमज़ोर क्षेत्र है
    • Boris द्वारा बनाया गया Claude Code का contextual loading message—जो साधारण spinner की जगह model क्या कर रहा है यह दिखाता है—किसी ने माँगा नहीं था, लेकिन बिना जानकारी वाले इंतज़ार और जानकारी वाले इंतज़ार के फर्क के लिए बनाया गया
    • Codex के sandbox defaults भी user empathy का decision हैं; Tibo: “adoption rate को नुकसान हो तब भी हम default रूप से ऐसी चीज़ recommend नहीं करते जो सुरक्षित न हो सकती हो”
      • यह समझते हुए कि कई users “इतने technical नहीं” होते और गलती से irreversible काम कर सकते हैं, उन्होंने convenience से ऊपर safety को चुना

  • Zone 5: कम्युनिकेशन और स्टोरीटेलिंग

    • आपने जो बनाया है उसे कैसे frame करते हैं; engineers इसे लगातार कम आँकते हैं, लेकिन market इसी को reward करता है
    • Peter Steinberger के OpenClaw ने viral week के दौरान Claude Code और Codex को मिलाकर जितनी Google searches मिलीं, उससे भी ज़्यादा दर्ज कीं
      • साफ़ नाम, compelling demo, और “एक व्यक्ति team-स्तर का output बनाता है” वाली narrative ने spread को आगे बढ़ाया
    • Codex की AGENTS.md file—जो इंसानों के लिए नहीं बल्कि AI agents के लिए README है—यह पहचानती है कि documentation का reader बदल चुका है, और उसी हिसाब से format को adapt करती है

taste के उदाहरण (और उसकी अनुपस्थिति)

  • tech stack का चयन

    • taste नहीं: “TypeScript सबसे popular है और सब जानते हैं,” convention के आधार पर justification
    • taste है: Boris ने Claude model के लिए TypeScript इसलिए चुना क्योंकि वह “on distribution” है, यानी model उसे पहले से अच्छी तरह handle करता है; यह team comfort नहीं बल्कि model strengths के लिए optimization था
      • Codex ने Rust इसलिए चुना क्योंकि वह “हम जिन engineering standards को सेट करते हैं, उनके बारे में सोचने पर मजबूर करता है” और minimum dependencies देता है जिन्हें सीधे inspect किया जा सके; decision एक जैसा दिखता है, लेकिन दोनों ही सामान्य preference नहीं बल्कि ठोस constraints पर आधारित हैं

  • उस code को संभालना जिसे पूरी तरह नहीं समझते

    • taste नहीं: “AI ने generate किया है और tests pass हो रहे हैं, तो launch कर दो,” tests की पर्याप्तता और maintainability पर कोई विचार नहीं
    • taste है: Peter बिना पढ़े गए code को भी ship करते हैं, लेकिन लापरवाही से नहीं; “मुझे component की जगह और structure, और पूरे system का design पता है, और आम तौर पर वही काफी होता है”
      • tests, linting, और local CI verification layers हैं; एक तरफ़ जुआ है, दूसरी तरफ़ ऐसा system है जिसमें correctness संरचनात्मक रूप से सुनिश्चित होती है

  • feature requests का जवाब

    • taste नहीं: ticket के मुताबिक implement करो, launch करो, फिर अगले पर बढ़ो
    • taste है: Boris launch से पहले दो दिनों में 20 prototypes बनाते हैं; यह धीमापन नहीं बल्कि तेज़ experimentation के ज़रिए सही solution तक navigation है; अनिवार्यता taste की उँगलियों के निशान है

  • AI agents के लिए design

    • taste नहीं: setup guide और API endpoints वाला सामान्य README
    • taste है: Codex, AI को codebase navigate करने, test commands चलाने, और standards follow करने का तरीका बताने के लिए AGENTS.md लिखता है; codebase को ऐसे structure किया जाता है कि model का सफल होना लगभग अनिवार्य हो

  • PR की बाढ़ से निपटना

    • taste नहीं: AI-generated PRs की बाढ़ आने पर भी वही review process बनाए रखना; reviewers पर overload, quality में गिरावट
    • taste है: Emma Tang की team PR के साथ prompt attach करना अनिवार्य करती है; नहीं होने पर Slack में पूछती है, “prompt क्या था?”
      • AI की दुनिया में code से ज़्यादा intent का review उपयोगी है; Peter PRs को “prompt requests” कहते हैं और code से ज़्यादा generation prompts में रुचि रखते हैं; generation unit बदल गई है, इसलिए review unit भी बदलती है

taste विकसित करने की योजना (सिर्फ impressions नहीं)

  • “और experience लो” जैसी सलाह “और exercise करो” जितनी ही बेकार है; नीचे तीन प्रकार के लिए 90-दिन की योजना है

  • महीना 1: structured exposure से recognition taste बनाना

    • mechanism है: विविध quality variance के बड़े exposure के बाद deliberate reflection
    • सप्ताह 1~2: जिन developer tools का आप सम्मान करते हैं, उनमें से 10 का अध्ययन
      • Codex CLI, Claude Code, Linear, Supabase, Stripe dashboard, Vercel, Tailwind, Railway, Resend, और 1 non-software product इंस्टॉल करें या देखें, जैसे कोई अच्छी तरह designed museum exhibit या restaurant menu
      • हर एक पर 15 मिनट लिखें: पहले 60 सेकंड में आपने क्या notice किया, किस बात से खुशी हुई, क्या confusing लगा, और कौन-सा decision आप चुराना चाहेंगे
      • अच्छे tools पहले 30 सेकंड में process समझाने से पहले result दिखाते हैं; बुरे tools यह दिखाने से पहले architecture समझाते हैं कि आपको परवाह क्यों करनी चाहिए
    • सप्ताह 3~4: discovery के लिए नहीं, methodology के लिए 10 papers का अध्ययन
      • मूल BLEU score paper, Anthropic का Constitutional AI paper, Google का PageRank paper, Netflix Prize records, Scaling Laws papers
      • लिखें: methodology को elegant क्या बनाता है, उसे काम कराने वाली एक insight क्या है, और मैं इसे अपने domain में कैसे apply करूँगा
      • आप पाएँगे कि clear evaluation criteria, limitations का ईमानदार खुलासा, और complexity के ऊपर simple formulation जैसे structural principles अलग-अलग fields में बार-बार दोहराए जाते हैं

  • महीना 2: active discernment से compass taste बनाना

    • साप्ताहिक अभ्यास “Side-by-Side”: एक ही तरह के दो examples खोजें और 500 शब्द लिखें कि एक दूसरा से बेहतर क्यों है (दो API docs, दो technical blogs, दो architecture diagrams, दो evaluation frameworks)
      • “मुझे यह पसंद है” कहना मना है; हमेशा “यह बेहतर है क्योंकि…” के साथ specific mechanism बताना है
      • उदाहरण: Stripe documentation बेहतर है क्योंकि वह internal architecture नहीं बल्कि developer क्या करना चाहता है—payment भेजना, errors handle करना—इसके आधार पर organized है
    • दैनिक अभ्यास “Practice Noticing”: जब भी tool, paper, या code देखें, creator के एक decision को चुनें और एक वाक्य लिखें: “यह क्यों, और कोई obvious alternative क्यों नहीं?”; 30 दिनों बाद 30 observations के patterns आपका विकसित होता taste दिखाएँगे

  • महीना 3: generative application से vision taste बनाना

    • सप्ताह 9: ऐसी किसी चीज़ को फिर से design करें जो आपकी ownership में है—team onboarding flow, project README, evaluation pipeline developer experience—जो आपने सीखा है उसके आधार पर
    • सप्ताह 10: अब तक लिखी गई सबसे precise writing लिखें; सबसे लंबी या comprehensive नहीं, बल्कि ऐसी जिसमें हर paragraph अपना काम करे और reader की सोच बदल दे
    • सप्ताह 11: एक system को scratch से design करें और हर decision को convention नहीं बल्कि first principles से explain करें (“best practice है इसलिए microservices” नहीं, बल्कि “team 4 लोगों की है, traffic predictable है, और अगले 18 महीनों में जिस scale benefit की ज़रूरत नहीं होगी उससे deployment simplicity ज़्यादा महत्वपूर्ण है, इसलिए monolith”)
    • सप्ताह 12: अपना taste साझा करें; दो approaches का फर्क सिखाएँ और अपने codebase के लिए AGENTS.md लिखें; taste को systems और documentation में encode करने की क्षमता ही व्यक्तिगत skill और organizational capability के बीच अंतर बनाती है

taste को तेज़ी से विकसित करने वाले पाँच projects

  • 1. AI-generated code के लिए evaluation framework बनाना

    • ऐसा framework जो linter या test runner नहीं, बल्कि इस सवाल का जवाब दे कि “क्या यह AI code production के लिए पर्याप्त है?”, और अपना rubric परिभाषित करे (correctness, maintainability, efficiency, security, style)
    • इसे AI द्वारा बनाए गए 50 वास्तविक PR पर लागू करके score करें, हैरान करने वाले scores के आधार पर rubric को calibrate करें, नतीजे प्रकाशित करें, और Zone 3(quality judgment) के लिए taste विकसित करें

  • 2. open source project onboarding को फिर से डिज़ाइन करना

    • ऐसे tool को fork करें जिसकी तकनीक सम्मानजनक हो लेकिन onboarding निराशाजनक हो, developer experience के पहले 5 मिनट को फिर से डिज़ाइन करें, README और getting started guide लिखें, और इसे इस तरह संरचित करें कि नया contributor पहले ही दिन PR भेज सके
    • एक साथ Zone 4(user empathy) और Zone 5(communication) बनाएं

  • 3. टीम के लिए “taste test” बनाना

    • implementation approach के 10 जोड़ों की documentation लिखें, जहाँ हर जोड़े में एक पक्ष बेहतर taste दिखाता हो, और 5 engineers से पूछें कि कौन-सा बेहतर है और क्यों
    • दिलचस्प output सही जवाब नहीं, बल्कि असहमति है; जहाँ standards मेल नहीं खाते, वहीं bugs, technical debt, और rework की जड़ होती है; यही सबसे अधिक leverage वाला organizational taste बनाता है

  • 4. 48 घंटे की पाबंदी में product लॉन्च करना

    • prototype नहीं, बल्कि ऐसा काम करने वाला product जिसे दूसरे लोग इस्तेमाल कर सकें; समय की पाबंदी लगातार taste-based फैसले करने को मजबूर करती है (क्या शामिल करना है और क्या काट देना है)
    • अगर आप गलत feature पर 6 घंटे खर्च करते हैं, तो आप कुल समय का एक-चौथाई जला देते हैं, इसलिए खराब फैसलों का असर तुरंत दिखता है

  • 5. ऐसा tech blog लिखना जो सोच बदल दे

    • tutorial या how-to नहीं, बल्कि ऐसा लेख जो परिचित concepts को नए ढंग से गढ़े ताकि पाठक बाद में उन्हें अलग नज़र से देखें (यह समझ कि taste ही evaluation है, या यह पहचान कि हर model release पर code हटाना कोई routine नहीं, बल्कि architecture philosophy है)
    • Zone 5(communication·storytelling) बनाना, क्योंकि असली perspective हर taste की नींव है

taste-केंद्रित तरीके से करियर को optimize करना

  • speed race बंद करें

    • जब AI machine speed से code लिखता है, तब coding speed की race हारने वाला खेल है; प्रति घंटे 500 lines generate करने वाले व्यक्ति से ज़्यादा मूल्यवान वह है जो 30 मिनट सोचकर तय करे कि वास्तव में कौन-सी 50 lines चाहिए
    • implementation speed commoditized हो चुकी है, और जो commoditized नहीं हुआ है वह है क्या बनाना है और उसे कैसे implement करना है, इस पर judgment

  • taste के लिए ज़रूरी ‘adjacent skills’ में निवेश करें

    • सर्वश्रेष्ठ engineers की समानता यह है कि वे सिर्फ coders नहीं हैं; Boris एक startup founder हैं, Emma ने Stripe में 4 साल तक data infrastructure lead किया, और Peter ने PSPDFKit को एक global business में बदला
    • taste को raw material चाहिए; product thinking, design sense, business understanding, और communication ability वही सामग्री हैं जो taste को संभव बनाती हैं

  • ऐसी roles चुनें जहाँ taste को reward मिलता हो

    • अच्छी तरह परिभाषित specs को implement करने वाली भूमिकाएँ speed को reward करती हैं, जबकि ऐसी roles जहाँ यह तय करना होता है कि क्या बनाना है, कैसे बनाना है, और क्या पर्याप्त है, taste को सीधे reward करती हैं
    • जिन roles में taste को विशेष रूप से reward मिलता है: early startup founding engineer, product company tech lead, platform·infrastructure engineer जो ऐसे systems डिज़ाइन करते हैं जिन पर दूसरे engineers निर्माण करते हैं, developer experience engineer, और staff+ engineer जो cross-team architecture decisions संभालते हैं

  • taste दिखाने वाले public work samples बनाएं

    • AI युग में resume से ज़्यादा portfolio महत्वपूर्ण है; सबूत output में होता है (अच्छी तरह डिज़ाइन किया गया open source, स्पष्ट और सुसंगत perspective वाला tech blog, और ऐसे products जिन्हें लोग वास्तव में इस्तेमाल करते हैं)
    • Peter का OpenClaw किसी भी resume से अधिक प्रभावी है, और Boris का Claude Code prototype किसी भी behavioral interview answer से बेहतर taste साबित करता है

असुविधाजनक सच

  • taste असमान रूप से वितरित है, और आगे भी रहेगा; कुछ लोगों ने 15 साल में हज़ारों फैसलों के ज़रिए इसे विकसित किया है, इसलिए उनकी शुरुआती बढ़त को 90 दिन की योजना से पकड़ा नहीं जा सकता
    • Codex team ऐसे model बनाने वाली कंपनी में काम करती है जहाँ unlimited token access है, और Peter का शुरुआती बिंदु भी असामान्य है—20 साल का अनुभव और एक company exit
  • फिर भी “taste नहीं” और “थोड़ा-सा taste” के बीच का अंतर करियर प्रभाव के लिहाज़ से बहुत बड़ा है, और इसे भरा जा सकता है; सिर्फ ticket लेकर implement करने वाला व्यक्ति जब user research के आधार पर यह प्रस्ताव देने लगे कि क्या बनाया जाए, और test व architecture तक को AI के साथ implement करे, वही छलांग taste है
  • Gergely Orosz की ईमानदार स्वीकारोक्ति: “ऐसा लगता है जैसे अचानक कुछ मूल्यवान मुझसे छीन लिया गया हो; coding में अच्छा होने तक पहुँचने में बहुत मेहनत लगी, और flow में डूबकर ideas टाइप करना मेरी सबसे अच्छी यादों में है”
    • हाथ से code लिखने की skill का कम केंद्रीय हो जाना सचमुच एक loss है, लेकिन कौन-सा code होना चाहिए, उसे कैसे संरचित किया जाना चाहिए, और क्या पर्याप्त है—यह जानने की क्षमता हमेशा से असली क्षमता रही है
  • आगे वही engineers सफल होंगे जो इसे समझते हैं; taste हमेशा से काम का हिस्सा था, बस code के भीतर छिपा हुआ था, और AI ने typing अपने हाथ में लेकर उसे सामने ला दिया है

संबंधित पढ़ाई

2 टिप्पणियां

 
clastneo 3 시간 전

अरे, अब तो 10x भी नहीं, 30x के बारे में सोचना पड़ेगा haha
 
channprj 2 시간 전

मैं भी x배 엔지니어 जैसी कुछ बढ़ा-चढ़ाकर कही गई अभिव्यक्तियाँ देखना बंद करना चाहता/चाहती हूँ.. T_T
ये देखने में भले ही quantitative लगती हों, लेकिन असल में qualitative अभिव्यक्तियाँ ही हैं।