Software Factory क्यों विफल होती है: सिर्फ Harness Engineering काफी नहीं

 (github.com/humanlayer)
1 पॉइंट द्वारा GN⁺ 2 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • ऐसी lights-off software factory जहां इंसान code पढ़ते या लिखते नहीं, generation की गति बढ़ाती है, लेकिन दीर्घकालिक maintainability का आकलन करने वाले इंसान को भी हटा देती है, इसलिए जटिल production codebase में काम करना मुश्किल हो जाता है
  • Coding models का reinforcement learning, tests pass करने जैसे तेज और स्पष्ट rewards को optimize करता है, और महीनों बाद सामने आने वाली खराब design cost पर penalty नहीं लगा पाता
  • SWE-bench series bug fixes और existing tests के संरक्षण का मूल्यांकन करती है, लेकिन अंधाधुंध try/catch, type casts, shotgun surgery जैसे code quality को धीरे-धीरे बिगाड़ने वाले changes को नहीं रोक पाती
  • फिलहाल इंसानों को code review संभालना होगा और implementation से पहले product requirements, system architecture, program design, vertical slices की समीक्षा करनी होगी, ताकि rework और बड़े पैमाने पर AI-generated code review कम हो सके
  • Model की सीमाओं को स्वीकार करने पर, अवास्तविक 10–100x automation के बजाय इंसानी स्तर के करीब quality बनाए रखते हुए 2–3x तेजी से develop किया जा सकता है; key judgment और code reading अभी outsource नहीं किए जा सकते

Loop-केंद्रित software factory का वादा और वास्तविकता

  • Production में AI coding अपनाने की होड़ में यह धारणा फैल रही है कि harness और agent loops बढ़ाना ही काफी है
    • StrongDM की lights-off software factory ऐसा तरीका पेश करती है जिसमें इंसान code पढ़ते या लिखते नहीं
    • OpenAI का Symphony भी harness engineering पर आधारित software factory का उदाहरण है
  • यह approach इस premise पर आधारित है कि इंसान bottleneck हैं, models पर्याप्त अच्छे हैं, और code generation की cost लगभग कम है, इसलिए ज्यादा release करना चाहिए
  • लक्ष्य 10–100x speed, high quality, और human code review हटाना—तीनों को एक साथ हासिल करना है
    • माना जाता है कि और linters configure करके और PR review bots को adversarial review करने को कहकर software को अपने-आप safe बनाया जा सकता है
  • वास्तविक field में coding agents की गलतियों से outages होने और codebase के तेजी से टूटने के उदाहरण दिख रहे हैं
  • Faros AI report ने AI coding tools अपनाने के बाद ये बदलाव देखे
    • Review comments की संख्या और लंबाई बढ़ी, लेकिन review के बिना merge होने वाले PR भी बढ़े
    • Incidents और प्रति developer bugs बढ़े
    • हालांकि यह verified causation नहीं, बल्कि correlation signal के करीब है
  • StrongDM के results दिखाने वाला definitive data मिलना मुश्किल है, और February से June के बीच public updates भी कम रहे

जटिल codebase, vibe coding से अलग समस्या है

  • कुछ लोगों द्वारा इस्तेमाल किए जाने वाले side project और 10 साल पुराने enterprise system को maintain करने वाली team की constraints लगभग साझा नहीं होतीं
  • चर्चा का विषय vibe coding खुद नहीं, बल्कि complex codebase की कठिन समस्याएं और production maintenance है
  • पहले brownfield से पुराने Java systems वगैरह समझे जाते थे, लेकिन agents द्वारा बनाए गए codebase भी तेज development speed के कारण करीब 3–6 महीने बाद बदलना मुश्किल हो सकते हैं
  • खराब results पर अक्सर सलाह दी जाती है कि tokens या technology कम हैं, लेकिन core issue harness से ज्यादा model training method में है

Software factory का evolution

  • 1968 से AI adoption से पहले तक

    • ‘software factory’ शब्द ‘software engineering’ expression के सामने आने वाली 1968 NATO conference तक जाता है
    • 2022 के आसपास की typical factory में यह cycle होता था
      • इंसान तय करते हैं कि क्या बनाना है और उसे Linear या Jira जैसे tracker में डालते हैं
      • Assignee implementation और testing करता है
      • Automated checks और human code review के बाद अगर issue हो तो implementation stage में लौटते हैं
      • Production deploy के बाद monitoring होती है, और outages व user feedback को फिर tracker में डाला जाता है
    • Implementation और review में अलग-अलग कई घंटे या कई दिन लगते हैं, इसलिए teams पहले planning, architecture proposals, sprint planning रखकर alignment बनाती हैं
    • Implementation से पहले alignment rework घटाता है, और तय दिशा के करीब उच्च-quality PR को सभी lines पढ़ने पर भी जल्दी review किया जा सकता है

  • Agentic factory

    • Ramp, Stripe, WorkOS, Brex आदि बताते हैं कि agent factories code का लगभग 75% ship करती हैं
    • Existing factory में जहां इंसान implementation करते थे, उस stage को agents से बदलकर orchestration, harness, sandbox, models और computer use को जोड़ा जाता है
    • Implementation time कई घंटे/दिन से घटकर मिनट/घंटे हो जाता है, लेकिन human code reading और testing वैसे ही रहते हैं, इसलिए review bottleneck बन जाता है
    • इस bottleneck को घटाने के लिए कई loops जोड़े जाते हैं
      • Style, bugs, security check करने वाला agent code review
      • Browser और computer use से external behavior check करने वाली regression testing
      • Outages को automatically PR से जोड़कर assignee को fix candidates देने वाला flow
      • User feedback को सीधे work queue से जोड़ने वाला flow
    • अंत में operational problem इतनी रह जाती है कि work queue में कितना कुछ डाला जा सकता है, और results को कितनी जल्दी review व test किया जा सकता है

  • Lights-off factory

    • Dan Shapiro द्वारा नामित lights-off factory, हर change को इंसान द्वारा पढ़े जाने वाले stage को हटा देती है
    • Code review के बजाय इन क्षेत्रों में investment होता है
      • Agents की self-testing
      • Sandboxes और orchestration
      • Automated review और monitoring
      • Gradual rollout और user feedback signals collection
    • इंसानी judgment हटाने पर बस यह बचता है कि agents से कितने tasks करवाए जा सकते हैं, लेकिन यह तरीका complex production codebase में काम नहीं करता

सीधे लागू किए गए lights-off तरीके की विफलता

  • July 2025 से specs और tickets ही पढ़कर small/medium tasks background agents को सौंपने वाला fully lights-off approach लागू किया गया
  • कुछ महीनों बाद ऐसे complex issues आए जिन्हें advanced prompts और workflows से भी हल नहीं किया जा सका
    • जरूरी context जुटाकर model को दिया गया
    • Agent ने लगभग 10 तरीकों से problem reproduce करने की कोशिश की
    • अंत में इंसान को 3 महीने से न पढ़े गए codebase में खुद जाकर root cause ढूंढना पड़ा
  • इस बीच site down हुई, users को असुविधा हुई, और इंसानों को जमा हुए low-quality code को पढ़ना पड़ा
  • पहली failure में speed के लिए risk लेने लायक लगा, लेकिन लगभग तीसरी problem आने पर November में शुरू से फिर लिखना आसान था
    • Co-founder ने VS Code में 2 हफ्तों तक patterns को खुद reimplement किया

Models codebase quality क्यों गिराते हैं

  • Current models काफी human direction के बिना लंबे समय तक codebase quality maintain और improve नहीं कर पाते
  • यहां maintainability का मतलब वह क्षमता है जिससे एक हिस्से को बदलने पर दूसरे हिस्से टूटने और वही change कई जगहों पर करना पड़ने वाली shotgun surgery स्थिति से बचा जा सके
  • Models one-off problem solving या नया marketing site generate करने में बहुत बेहतर हुए हैं, लेकिन समय के साथ code quality improve करने की क्षमता में स्पष्ट सुधार दिखना मुश्किल है
  • Maintainability measure करने के लिए अच्छे benchmarks नहीं हैं, इसलिए इस difference को prove या refute करना भी कठिन है
  • भले ही GPT-5.5 xhigh जैसे models शानदार refactoring करें, अगर इंसान को codebase समझकर required work को specifically instruct करना पड़े, तो lights-off factory की समस्या हल नहीं होती

Claude Code और harness के अंदर reinforcement learning

  • Claude Code से पहले भी aider, cline, codebuff जैसे CLI agents reading, writing, editing, search, shell tools और context engineering देते थे
  • Existing agents में कभी-कभी वही edit बार-बार करके fail होने जैसी tool-use reliability की कमी थी
  • SWE-Agent paper ने analyze किया कि ReadFile result में line numbers डालना या Edit को find/replace से line-range edit में बदलना जैसे छोटे tool design differences भी performance पर असर डालते हैं
  • Claude Code के तेजी से बढ़ने की key reason यह बताई जाती है कि Anthropic ने model को उसी harness के अंदर reinforcement learning कराया जिसे वह वास्तव में release करने वाला था
    • Model weights को इस तरह adjust किया गया कि model agent loop के अंदर exact tool set call करे
    • External developers द्वारा tool definitions और evaluation को model preference के हिसाब से tune करने के विपरीत, model owner model को ही tools के अनुरूप बदल सकता है
  • जिन teams के पास harness और model weights दोनों हैं, उन्हें उन teams पर advantage है जो सिर्फ harness बना सकती हैं लेकिन weights adjust नहीं कर सकतीं

Coding agent reinforcement learning की reward limits

  • Coding model reinforcement learning आम तौर पर इस process को लाखों बार repeat करता है
    1. Tests fix करने जैसी problem solve करने के लिए agent execution trace generate करता है
    2. Validator से execution trace evaluate करता है
    3. Good execution traces की probability बढ़ाने और bad execution traces की probability घटाने के लिए model weights update करता है
  • Problem यह है कि evaluation score बहुत ज्यादा one-dimensional हो सकता है

  • SWE-bench Multilingual example

    • SWE-bench Multilingual Redis, jq, Django जैसे open-source repositories से लिए गए लगभग 15-minute tasks का उपयोग करता है
    • Reward 0 या 1 होता है और दो conditions check करता है
      • FAIL_TO_PASS: requested issue fix हुआ या नहीं
      • PASS_TO_PASS: existing behavior टूटा या नहीं
    • fastlane__fastlane-19304 task ऐसा bug है जहां optional include, exclude parameters न होने पर nil पर .empty? call होने से failure होता है
    • Actual human fix nil को empty array default set करने वाला two-line change था
    • Model को fix से ठीक पहले का base commit और bug report ही मिलते हैं; correct patch और grading test patch नहीं दिखते
    • Evaluation इस order में होता है
      1. Model द्वारा बनाया गया patch preserve किया जाता है
      2. Model ने test files में जो changes किए हैं उन्हें remove किया जाता है
      3. Benchmark का private test patch apply किया जाता है
      4. Existing tests और new tests साथ चलाए जाते हैं
    • Test changes को discard करने की वजह यह है कि model कभी failing tests को comment out कर देता है या meaningless mocks डालकर pass करा देता है
    • Benchmark और reinforcement learning validator समान नहीं हैं और अलग रहने चाहिए, लेकिन दोनों coding execution traces की quality judge करने की structural limits दिखाते हैं

  • Design degradation पर penalty नहीं है

    • अगर tests pass हो जाते हैं, तो solution तक पहुंचने की process और structural quality score में reflect नहीं होती
    • हर जगह try/catch wrap करना या type system के benefits को कमजोर करने वाले loose type casts भी correct answer हो सकते हैं
    • Maintainability damage पर penalty नहीं लगती, जब तक existing और new tests pass होते हैं

Tests pass करने से कठिन है quality validation

  • Tests कुछ seconds में clear success/failure देते हैं, इसलिए reinforcement learning को लाखों बार repeat किया जा सकता है
  • Bad architecture की cost हफ्तों, महीनों या सालों बाद दिखती है, जब small change कई जगहों पर apply करना पड़ता है
  • Current benchmarks ऐसी long-term design cost evaluate नहीं कर पाते
  • Reinforcement learning और benchmarks समान नहीं हैं, लेकिन अगर maintainability reinforcement learning में solve हो चुकी होती, तो benchmark design में भी वह capability दिखने की संभावना होती
  • इसलिए existing benchmark score improvement को इस बात का evidence नहीं माना जा सकता कि model अब codebase को गंदा नहीं करता

Maintainability evaluate करने की नई कोशिशें

  • Model quality की frontier improve हो रही है, लेकिन expectations और marketing technical discipline से आगे चल रहे हैं
  • Maintainability के करीब evaluation की कोशिश करने वाले examples हैं
    • SWE-Marathon: Excel की सभी features replicate करने जैसे लगभग 400-hour tasks और single success/failure के बजाय composite reward channels का उपयोग करता है
    • DeepSWE: real world में actual implement न हुए बड़े open-source tasks का उपयोग करके training data contamination घटाता है, लेकिन quality problem खुद solve नहीं करता
    • Frontier Code: कई PRs में फैले tasks evaluate करता है, और patch से पहले वाले code में भी fail न होने वाले tests लिखने पर penalty देता है
      • Mutation testing जैसी approach से tests की validity deterministically check करता है
      • Code quality rules के आधार पर diff inspect करने वाला judge model भी चलाता है
  • अगर judge model quality को reliably distinguish कर सकता है, तो limit यह है कि शुरुआत से ही अच्छा code generate भी किया जा सकता था
  • Reinforcement learning को fast और reliable oracle चाहिए, लेकिन maintainability के लिए ऐसा oracle नहीं है
  • Review agents और extra tokens obvious mistakes पकड़कर minimum quality बढ़ा सकते हैं, लेकिन reinforcement learning से model को सिखाए गए level से आगे maximum quality नहीं बढ़ाते
  • SWE-Marathon, DeepSWE, Frontier Code success/failure judgment से आगे maintainability evaluate करने की early attempts हैं, लेकिन अभी पूरे codebase को सौंपने लायक नहीं हैं

इंसान को फिर loop में डालने के 4 steps

  • फिलहाल reliable quality judge इंसान है, इसलिए code review restore करना होगा
  • AI से पहले इस्तेमाल की जाने वाली upfront planning लागू करके लंबे reviews और rework की संभावना घटाई जाती है
  • AI leverage का उपयोग product requirements, system architecture, program design, vertical slices—इन चार stages में किया जाता है

  • 1. Product review

    • Short sentence या लंबी voice memo को semi-structured document में बदलकर क्या और क्यों बनाना है, इसे fix किया जाता है
    • पहले user की भाषा में हल की जाने वाली problem define करें और launch के बाद success judge करने के criteria तय करें
      • Workflow execution time घटाना
      • Onboarding milestones जल्दी हासिल करना
      • Error rate या latency improve करना
      • Specific support tickets कम करना
    • Technical details से ज्यादा user experience पर focus करें, और अगर technical decision product decision रोकता है, तो current document save करके architecture review या feasibility prototype पर जाएं
    • Screen behavior पर alignment के लिए लंबे explanation से बेहतर rough HTML mockup होता है
    • Copy changes, one-off scripts, और clear reproduction steps वाले bugs पर यह process लागू न करें; उन्हें सीधे agent को दें
    • Product review केवल उन changes के लिए रखें जिनमें agent के intent misunderstanding की cost बड़ी हो
    • PR reviewers से product और technical specs भी पहले review करवाएं; asynchronous document comments या GitHub/Notion आदि इस्तेमाल किए जा सकते हैं

  • 2. System architecture

    • Services, endpoints, schemas, queues, storage के बीच communication method पर alignment करें, लेकिन program internals तक न जाएं
    • इंसान और agent के communication bandwidth को बढ़ाने के लिए ये representations इस्तेमाल करें
      • UI, API, services, storage के बीच sequence diagrams
      • Request/response दिखाने वाले API contracts
      • नई tables और query shapes दिखाने वाले data models
    • Mermaid useful है, लेकिन ज्यादा उपयोग करने से actual alignment हो चुका है, ऐसी false confidence दे सकता है
    • Architecture review model की bad habits को जल्दी रोकने में effective है, लेकिन high-quality code guarantee करने के लिए पर्याप्त नहीं

  • 3. Program design

    • Implementation से पहले architecture से एक level नीचे code का shape तय करें
      • Types
      • Method signatures
      • Program layout
      • Call stack
    • Complex Mermaid से हल्का pseudocode visualization पढ़ने में आसान होता है
    • Orchestration या control-flow changes के लिए call stack tree इस्तेमाल करें, और बदलने वाला हिस्सा important हो तो diff syntax apply करें
    • File tree diff से new files और modified files की location और role confirm करें
    • Core functions के types और method signatures पहले तय करके agent द्वारा wrong internal design चुनने की संभावना घटाएं
    • Model draft बना सकता है और इंसान adjust कर सकता है; यह code review के दौरान implicitly लिए जाने वाले decisions को सस्ते stage पर आगे खिसकाने का काम है

  • 4. Vertical slice

    • Model database migration → service layer → API → frontend order में build करने वाली horizontal plan prefer करता है
    • Horizontal plan में काम के दौरान browser या curl से real solution को छूकर validate करना मुश्किल होता है
    • AI से पहले developers 500 lines या 2,000 lines एक साथ लिखने के बजाय बीच से बाहर की ओर expand करते हुए लगातार check करते थे
      1. API contract और mock data बनाकर curl से check करें
      2. Frontend में mock data consume करके browser में refine करें
      3. API को service layer से connect करें
      4. Database migration और storage connection add करें
      5. Business logic add करें
      6. Error handling add करें
    • Vertical slices या tracer bullets हर stage पर real behavior test और improve करने देते हैं
    • जहां quality खास तौर पर important है, वहां हर stage पर 100–200 lines review करके direction reset करना, बाद में 2,000+ lines fix करने से सस्ता है
    • Latest models भी human direction के बिना ऐसी planning करने में कठिनाई महसूस करते हैं, और codebase व task-specific generalization भी कठिन है, इसलिए इंसान को loop में रहना होगा

Task size के हिसाब से application

  • 30 minutes की upfront planning implementation के बाद कई घंटों के review को घटा सकती है
  • Human-level के करीब quality बनाए रखने के लिए product design, system architecture, program design, vertical slices में इंसान की involvement जरूरी है
  • हर task पर पूरा process लागू नहीं किया जाता
    • लगभग 40% एक बार में generate होकर या 1–2 हल्के feedback rounds में खत्म हो जाते हैं
    • Medium-sized tasks में product और system design को एक planning document में combine किया जाता है और implementation stages split नहीं किए जाते
    • Large tasks में सभी चार stages से गुजरते हैं, लेकिन large refactoring जैसे cases में product review fit न हो तो वह stage skip किया जाता है
  • आम तौर पर model को एक बार में 1–3 slices दिए जाते हैं और in-progress code review किया जाता है
  • शुरुआत में internal structure या functionality सही कर लेना, bulk generation के बाद क्या गलत हुआ यह खोजने से आसान है

Bottleneck PR count नहीं, PR quality है

  • समस्या बहुत सारे PR नहीं, बल्कि बहुत सारे खराब PR हैं
  • तय design और team conventions follow करने वाला clean PR, सभी files पढ़ने पर भी जल्दी review हो सकता है
  • PRs के सिर्फ 20% में rework हो तो भी submitter और reviewer दोनों पर cognitive और emotional burden पड़ता है
  • AI द्वारा एक बार में generated PRs में rework ratio अक्सर 50% के करीब होता है
  • Submitter AI हो तब भी किसी को काम शुरू करना, result refine करना या responsibility लेनी पड़ती है, इसलिए rework cost गायब नहीं होती

Constraints स्वीकार करके development speed

  • Current key constraint यह है कि model क्या अच्छा करता है और क्या नहीं, यह स्पष्ट है, और फिलहाल इंसान को code पढ़ना ही पड़ेगा
  • Code quality important नहीं है ऐसा मानकर 10–100x speed chase करने के बजाय, constraints के भीतर system optimize करने पर सुरक्षित रूप से 2–3x speed मिल सकती है
  • Practical principles चार हैं
    1. Model के साथ काफी काम करके constraints पर intuition बनाएं
    2. उन constraints के भीतर development system optimize करें
    3. High-leverage points खोजें
    4. Actual code पढ़ें
  • Harness और loops obvious errors घटाने के tools हैं, लेकिन maintainability judgment और design thinking की जगह नहीं ले सकते

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

1 टिप्पणियां

 
GN⁺ 2 시간 전
Hacker News टिप्पणियाँ

  • इसे intent-implementation-quality समस्या कहा गया
    software factory एक पंक्ति की requirement से app, feature, bug fix, design change, refactoring तक implement कर सकती है, लेकिन क्या वह उस requirement के पीछे की मानवीय मंशा और product की evolution दिशा को भी ठीक-ठीक बना सकती है, यह अलग सवाल है
    implementation के तरीके combinatorially explode करते हैं, और system के साथ consistent, scalable, समझने में आसान, और लाखों users को सुरक्षित रूप से support करने वाला ‘सही’ तरीका इंसान और समस्या के अनुसार subjective होता है। tests और work evidence से कुछ quality बढ़ाई जा सकती है, लेकिन इस तरह की subjective quality को validate और correct करने वाला feedback loop नहीं है

    • ग्राहक कहे कि “उसे X चाहिए”, फिर भी हो सकता है कि उसे वास्तव में X न चाहिए, X की ज़रूरत ही न हो, या वह Y चाहता हो लेकिन कह न पाया हो। दूसरे ग्राहक X न चाहते हों, या बिना किसी खास वजह के developer को इधर-उधर धकेलते हों
    • ऐसे व्यक्तिगत या hobby software, जिनमें users और revenue लगभग न हों और bug को Claude prompt एक बार देकर ठीक किया जा सके, या product-market fit से पहले के startup में software factory अच्छी तरह फिट बैठती है
      code बिल्कुल न देखकर सिर्फ requirement की सफलता को feedback मानने वाला संतुलन भी संभव है, लेकिन उससे बाहर के software में intent और subjective quality की समस्या अभी हल नहीं हुई है
    • यह मान लेना ही गलत है कि requirement को implementation में बदलने का केवल एक ही तरीका होता है

  • लेख में अच्छी बातें हैं, लेकिन July 2025 के unattended operation experiment को मौजूदा agents की सीमा के रूप में generalize करना मुश्किल है
    model की usefulness ने 2025 की शरद ऋतु या 2026 की वसंत के आसपास बड़ी छलांग लगाई, और मैं भी उसी के बाद agents को पूरे features सौंप सका। लेख model improvement का ज़िक्र करके भी उसे लगभग नज़रअंदाज़ कर देता है, जो मेरे अनुभव से मेल नहीं खाता

    • लेख और product site दोनों ही 2025 में अटके हुए लगते हैं। खासकर “long context जवाब नहीं है” वाला लेख ऐसा लगता है जैसे पुराने performance को सीधे latest models पर extrapolate किया गया हो
      Opus 4.6 के बाद के models 7 लाख से 9 लाख token पर भी इतने stable थे कि intelligence degradation महसूस करना मुश्किल था, और cost efficiency बहुत खराब होने के बावजूद वे काम करते हैं
    • पिछले हफ्ते मैंने Dex Horthy वाले podcast को सुना, और उनकी company Humanlayer लगातार agents की limits को push करते हुए उनका आक्रामक इस्तेमाल कर रही है
      उन्हें मौजूदा models की capability अच्छी तरह पता है, इसलिए अगर उन्होंने तय किया कि अभी unattended software factory संभव है, तो वे दोबारा कोशिश कर रहे होंगे
    • Opus 4.5 निश्चित रूप से बड़ी छलांग था। उसके बाद के models को test न करने वाले व्यक्ति का आकलन कम मूल्य रखता है, लेकिन models perfect न होने पर भी बहुत useful हैं
    • ऐसे में यह लिखना ज़्यादा स्पष्ट होता कि “हमने 2025 में full adoption किया था और 2026 में भी मूल रूप से कुछ बेहतर नहीं हुआ”
      मेरा मानना है कि latest frontier models भी context drift या shotgun surgery को खास बेहतर ढंग से handle नहीं करते। इसका जवाब देना हो तो सिर्फ अनदेखा न करें, बल्कि ठोस evidence और अलग user experience पेश करें
    • यह विवादास्पद हो सकता है, लेकिन complex engineering में मुझे Opus 4.1, 4.5 से ज़्यादा smart लगा
      4.5 तेज़ था और simple prompts तथा implicit intent को बेहतर पढ़ता था, इसलिए नए users को जल्दी आकर्षित करने में फ़ायदेमंद था

  • मैंने अपना software factory 8 महीनों तक बनाया और चलाया है, और automatic work collection व PR submission अभी नहीं है, लेकिन requirement तय होने के बाद यह ज़्यादातर खुद deploy तक आगे बढ़ जाता है। system evaluation के बाद मैंने पिछले 4 महीनों से code review बंद कर दिया है
    एक-पंक्ति prompt के बजाय मैं interview process से unresolved questions और ambiguity पहले साफ करता हूँ, और safeguards के तौर पर plan review, browser-based quality assurance, adversarial review, unit tests, linter, type checker, post-commit hooks, formal methods tracing का इस्तेमाल करता हूँ
    जब बार-बार एक जैसी गलतियाँ दिखती हैं, तो code देखे बिना भी गंदा हो चुका हिस्सा पहचाना जा सकता है। जब requirements बढ़ती हैं और state variables एक-दूसरे पर चढ़ने लगती हैं, तो मैं उन्हें एक sum type में refactor करता हूँ, और जटिल होने पर Quint से formal model और trace बनाकर unit tests के रूप में चलाता हूँ
    codebase में एक साल से ज़्यादा पुराना frontend और backend शामिल है। agent मौजूदा patterns को जैसे-का-तैसा copy करता है, इसलिए स्पष्ट principles ज़रूरी हैं; और नए system boundaries बाँटते समय Sonnet-स्तर के models अक्सर गलत निर्णय लेते थे, जबकि Opus बेहतर था

    • यह पूरी factory नहीं है, लेकिन कई mature vibe coding projects में मेरा अनुभव भी ऐसा ही रहा है
      quality degradation अधिकतर पकड़ी जा सकती थी, और code खोलकर समस्या ढूँढने के बाद agent से उसे साफ न करवा पाने की स्थिति अभी तक नहीं आई। ऐसा भी नहीं देखा कि औसत engineer codebase के contamination को irreversible स्थिति तक पहुँचा दे
    • मुझे code factory से ज़्यादा यह जानना है कि आपने बनाया क्या। यह साबित करने के लिए कि AI coding tools के अलावा भी products बनाए जा सकते हैं, किसी परिणाम की ज़रूरत है
    • अगर आप लंबी पोस्ट या repository के रूप में specific setup और workflow सार्वजनिक करें, तो मैं देखना चाहूँगा

  • या तो आपको codebase के काम करने का तरीका समझना ज़रूरी है, या फिर समझने की ज़रूरत नहीं है
    Claude आपके लिए code लिख सकता है, लेकिन वह आपकी जगह उसे समझ नहीं सकता, और वह प्रक्रिया अब भी मानव गति से चलती है। कुछ मामलों में सब कुछ समझना ज़रूरी नहीं होता, लेकिन इसके लिए अधिक सूक्ष्म भेद चाहिए; Claude अगर perfect code भी लिख दे, तब भी यह तथ्य नहीं बदलता

    • Claude इंसानों से कहीं तेज़ spaghetti codebase को navigate कर सकता है। project understanding को Claude को outsource कर देने में समस्या यह है कि इंसान के लिए वह project बेकार हो जाने के बाद भी उस पर काम चलता रह सकता है
    • इसे समझना/न-समझना जैसा binary देखने के बजाय, इसे इस रूप में देखा जा सकता है कि किसी खास codebase में असरदार ढंग से काम करने के लिए कितनी समझ ज़रूरी है
      LLM से पहले भी कोई पूरे बड़े codebase को नहीं जानता था, लेकिन कम-से-कम अपने बनाए PR और अपनी ownership वाले हिस्से को आम तौर पर समझता था
    • मेरा अनुभव उल्टा है। जिन दो बड़े codebases का अधिकांश मैंने खुद लिखा था और जिनके concepts भी मैंने design किए थे, Claude को मैंने मुझसे कहीं गहराई से समझते देखा, और अब वह मुझे बहुत पुरानी भूली हुई बातें समझा रहा है

  • यह मेरे अनुभव से इतना मिलता-जुलता है कि थोड़ा सुकून मिला। हाल में अक्सर चर्चा होने वाली रुचि और निर्णय-क्षमता याद आ गई।
    आर्किटेक्चर की गुणवत्ता शायद फैशन की तरह ऐसी चीज़ है जिसका कोई पूरी तरह वस्तुनिष्ठ सही जवाब नहीं होता; हो सकता है कि तर्क और rationality मशीनों को सौंपने के बाद इंसानों को aesthetics पढ़नी पड़े।
    implementation की प्रक्रिया जो राहत देती थी, उसके बिना अब लगभग बराबर के विकल्पों के बीच लगातार trade-off तय करना पड़ता है, इसलिए थकान होती है; Fable या GPT-5.6 स्तर के मॉडल में भी code review अब भी ज़रूरी है। छोटी खामियों को याद रखता हूँ और जब ऐसे मिलते-जुलते मुद्दे काफी जमा हो जाते हैं, तब एक साथ ठीक करता हूँ।
    agents के मामले में भी यह चुनना होगा कि क्या कुछ बेहतरीन लोगों के साथ क़रीबी सहयोग किया जाए, या बहुत सारे sub-agents चलाकर अपने-आप अच्छे-बुरे को छाँटा जाए। मेरी पसंद कम लोगों की बहुत उच्च-समन्वित टीम है, लेकिन सही जवाब क्या है यह समय बताएगा।

    • Jake Nations ने Netflix में काम करते समय कहा था, “मैं बुरे pattern को इसलिए देखते ही पहचान लेता हूँ क्योंकि मैं उन्हें रात 2 बजे debug कर चुका हूँ।”
      रुचि वही कठिन अनुभव से बनी अंतर्दृष्टि है, जो software बनाते समय खुद झेले गए सभी anti-patterns और landmines से मिलती है।
      https://www.youtube.com/watch?v=eIoohUmYpGI

  • इस व्यक्ति ने पहले भी बिना आधार की बातें गढ़कर फैलाने और नुकसान पहुँचाने की बात मानी है, और इस बार की सोच अच्छी है इसका कोई सबूत भी नहीं है। उस पर फिर से भरोसा करने के लिए कोई वजह चाहिए।

    • आखिरकार यह उसके product Humanlayer की लंबी विज्ञापन-कॉपी भर है।

  • अभी की स्थिति में सबसे ज़्यादा दिखने वाली समस्या PR review user experience है।
    मुझे GitHub का PR screen हमेशा नापसंद रहा, इसलिए branch डाउनलोड करके $EDITOR में diff देखता था, लेकिन अब इसे इतना असुविधाजनक रखने की कोई वजह नहीं है। code review कंपनी भी नहीं होने के बावजूद Linear छोटे model से बदले गए files को विषयवार group करता है, उनके विवरण देता है, और महत्व के क्रम में दिखाता है, जिससे GitHub से बेहतर basic functionality मिलती है।
    reviewer और requester दोनों की ओर से अतिरिक्त काम किए बिना cognitive load काफ़ी घटता है, और visualization जैसी आगे की सुविधाएँ भी पूरी तरह संभव लगती हैं। यह approach गलत है या कोई व्यापक रूप से इस्तेमाल होने वाला विकल्प है, यह जानने की जिज्ञासा है।
    https://linear.app/docs/diffs#guides

    • सबसे बेहतरीन टीमें PR review नहीं करतीं। बदलाव के दौरान design और architecture पर साथ में चर्चा करती हैं, linting और formatting जैसी मामूली जाँचें automate करती हैं, और बहुत सारे tests व checks के साथ build न तोड़ने वाले नियम सख़्ती से मानती हैं।
      अगर मज़बूत rollback प्रक्रिया भी हो, तो PR gate ऐसा अनावश्यक चरण बन जाता है जो कोई उपयोगी समस्या पकड़ नहीं पाता, और team members आपस में सीधे merge कर सकते हैं।
    • code review को integration gate बनाने वाली policy बेमानी है। मेरा agent review request पर मेरी जगह जवाब देता है और review भी करता है, और human review को अनिवार्य बनाने वाली company policy को भी bypass किया जा सकता है।
      असल में काम करने वाले software का review होना चाहिए, और ऐसा system चाहिए जो बदलाव को तुरंत demo कर सके। code और spec का महत्व घटेगा, और भविष्य का software production GitHub से ज़्यादा Replit के करीब होगा।
    • agents आने से पहले भी PR review कठिन था, लेकिन अब review करने के लिए PR की संख्या भी बढ़ गई है, इसलिए स्थिति और बिगड़ गई है।
    • files के बदलावों को विषयवार group करके समझाना क्या मूल रूप से commit का काम नहीं होना चाहिए?
    • मुझे नहीं लगता कि LLM importance तय करने या code summarize करने में बहुत अच्छे हैं।
      Tree-sitter आधारित approach https://github.com/0x007BA7/codebook के साथ प्रयोग किया और वह पसंद आया। अभी production environment में इस्तेमाल लायक स्तर का नहीं है, लेकिन इसी तरह के तरीके को product बनाया जा सकता है।

  • software factory को लेकर मेरे मन में मिला-जुला भाव है।
    core product इतने बड़े पैमाने का होता है कि हर बदलाव में human input चाहिए, लेकिन हल्के refactoring, test लिखना, और UI बदलावों की automation अच्छी तरह काम करती है। दूसरी ओर, छोटे experiments में result code भले खास न हो, लेकिन आगे scale होने की संभावना दिखी; और मुझे लगता है कि शुरू से ही नई strategy और architecture इस मानकर design किए जा सकते हैं कि agent ही उन्हें लिखेंगे।
    जिन public experiments में मैंने दिशा देने के लिए बिल्कुल दखल नहीं दिया, वे https://relentless.works/ पर दस्तावेज़ित हैं। trading agent को भी बिना दखल सिर्फ़ observe कर रहा हूँ; लगभग 3% का नुकसान है, लेकिन पूरी रकम नहीं डूबी, और हाल में उसने नई positions भी खोली हैं।
    software factory संभव लगती है, लेकिन इसके लिए नए concepts, सोच में बदलाव, और AI का इंतज़ार करने का धैर्य चाहिए।

  • software बनाना आखिर है क्या, यह भी एक बुनियादी समस्या है।
    अगर GitHub tickets AI agent को सौंपकर बस आराम किया जाए, तो abstraction और indirect layers लगातार जुड़ते जाने की संभावना बहुत ज़्यादा है। coding के दौरान “यहाँ Redis इस्तेमाल करें?”, “API तो ज़रूरी data पहले से दे रही है?”, “जो ग्राहक पिछले 1 साल से active नहीं हैं, उन्हें report से बाहर रखें” जैसे नज़रिए बनते हैं, और किसी बिंदु पर इंसान को इन पर फैसला करना ही पड़ता है।

    • यह agent coding में आसानी से खो जाने वाले उस नज़रिए से जुड़ता है कि programming is theory building।
      https://gwern.net/doc/cs/algorithm/1985-naur.pdf
    • पूरी तरह सहमत हूँ। व्यापक रूप से इस्तेमाल होने वाले coding agent workflows और techniques का संग्रह इस तरह design किया जाता है कि planning या code लिखते समय human insight और intuition बाहर आए।
      Claude Code का planning mode, mattpocock/skills, obra/superpowers, और research-plan-implementation flow इसके उदाहरण हैं।
    • अगर आप उस तरह सोचने वाले top 1% developers में हैं, तो बात सही होगी; लेकिन दशकों में मिले ज़्यादातर developers की तुलना में मौजूदा models top tier को छोड़कर इंसानों से बेहतर हैं।
    • मशीनें अब वह भी बना देती हैं जो अभी अस्तित्व में नहीं है, बस जैसा माँगा जाए वैसा। पूरी तरह unmanned automation से ज़्यादा ज़रूरी है information theory, decision theory, और creativity theory का उपयोग करके सही तरह से माँग करना।
      model की memory इंसान की तरह सोते समय weights में नहीं बसती; यह ज़्यादा उस व्यक्ति को नोट्स थमाने जैसा है जिसे कल की बात याद नहीं रहती। अगर high-entropy system समय के साथ project में और entropy जोड़ दे, तो इसमें हैरानी नहीं होनी चाहिए।
    • “API पहले से ज़रूरी data लौटाती है” वाली समस्या खास तौर पर बड़ी है। मैंने कई बार देखा है कि top-level model ऐसी चीज़ के लिए, जो client में पहले से मौजूद data के साथ सिर्फ़ एक line बदलने से हो सकती थी, मौजूदा client-server pattern की नकल करते हुए बेहिसाब code और tokens खर्च कर देता है।
      vibe coding projects ऐसे waste से भरे पड़े हैं, लेकिन prompt लिखने वाले व्यक्ति को इसका पता भी न चले। यह अच्छा है कि tools हर दिन समय बचाते हैं, लेकिन overengineering गंभीर समस्या है।

  • स्वायत्त software factory की बात करते हुए productivity को PR या commit की संख्या से मापना हास्यास्पद है। उस दिशा में जाएँ तो code unit को पहले से ही bos(bunch of shit) कहना चाहिए

    • कुल throughput के बजाय utilization को optimize करने वाली पुरानी गलती दोहराई जा रही है। यह समस्या Eli Goldratt 1970 के दशक से उठाते रहे हैं, फिर भी लोग अब तक नहीं सीख पाए हैं
      https://en.wikipedia.org/wiki/The_Goal_(novel)
    • अगर इस अवधारणा को गंभीरता से चलाना है, तो vanity metrics या code के बारे में अज्ञानता की कोई गुंजाइश नहीं है। automation जितना बढ़ता है, मानक उतने घटते नहीं बल्कि और ऊँचे होते हैं, और कहीं ज़्यादा गणित व मेहनत चाहिए होती है
      यह किसी चरम startup की तरह पूंजी बचाने के बजाय ज़िंदगी के कई साल झोंक देने वाले सौदे के अधिक करीब है