23 पॉइंट द्वारा GN⁺ 2026-01-07 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • Claude Opus 4.5 मौजूदा AI coding agents से अलग, developer के हस्तक्षेप के बिना भी उच्च-गुणवत्ता वाले applications बनाने लायक स्वायत्त development क्षमता दिखाता है
  • साधारण Windows image conversion utility से लेकर वीडियो रिकॉर्डिंग और एडिटिंग टूल, AI-आधारित posting automation app, और order tracking तथा route calculation app तक, इसने कम समय में वास्तव में काम करने वाले projects पूरे किए
  • Opus 4.5 Firebase backend setup, error log analysis और auto-fix, तथा GitHub Actions deployment configuration जैसे जटिल development tasks खुद संभालता है
  • लेखक मानते हैं कि वे code structure को पूरी तरह नहीं समझते, फिर भी Opus 4.5 को bugs खुद ठीक करते और refactoring suggestions देते देखा
  • इस अनुभव के आधार पर वे ज़ोर देते हैं कि AI के developers को पूरी तरह replace करने की संभावना अब वास्तविक लगने लगी है, और यह AI-केंद्रित development युग का turning point है

Opus 4.5 का आगमन और मौजूदा AI agents से उसका अंतर

  • पहले के AI agents अक्सर अक्षम code generation और बार-बार error fixing की वजह से कम productive होते थे
    • कई बार copy-paste और error fixes के बाद codebase खराब हो जाता था
  • Opus 4.5 इन समस्याओं को पार कर, शुरुआत से ही अधिकतर code सही लिखता है, और error आने पर CLI के जरिए खुद build और fix करने की प्रक्रिया दोहराता है
  • लेखक इसे “AI coding के वादे को सच में पूरा करने वाला model” मानते हैं

Project 1 – Windows image conversion utility

  • Opus 4.5 ने Windows Explorer के right-click menu से image format conversion करने वाली utility एक ही request में पूरी कर दी
    • dotnet CLI का इस्तेमाल करके build और error fixing process को automate किया
    • केवल XAML errors को Visual Studio में देखकर copy करके दिया गया
  • इसने deployment website, PowerShell install script, और GitHub Actions auto-deployment pipeline भी तैयार की
  • logo बनाने के लिए Figma AI का उपयोग किया गया, और Opus ने SVG conversion तथा icon format scripts लिखीं

Project 2 – screen recording और editing tool

  • LICEcap जैसे GIF recording utility से शुरू करके, इसे वीडियो और image editing features तक बढ़ाया गया
    • shapes जोड़ना, crop करना, blur apply करना जैसे editing features कुछ ही घंटों में लागू किए गए
  • source code GitHub पर public है, और लेखक के अनुसार “कुछ घंटों में काफी उन्नत स्तर तक development” हो गया
  • इससे पुष्टि हुई कि Opus 4.5 सिर्फ UI ही नहीं, backend integration work भी कर सकता है

Project 3 – AI posting automation app

  • Facebook page पर अपने-आप posts डालने वाला AI-आधारित mobile app Opus 4.5 से बनाया गया
    • photo upload के बाद AI caption generation और scheduled posting करता है
    • Firebase backend, authentication, storage, और cloud functions को Opus ने CLI के जरिए सीधे configure किया
  • लेखक बताते हैं कि जब तक वे blinds install कर रहे थे, Opus ने app पूरा कर दिया
  • Opus ने error logs का अपने-आप analysis करके fixes लागू किए, और admin dashboard भी बनाया
  • जो काम पहले महीनों लेता था, वह कुछ घंटों में पूरा हो गया

Project 4 – order tracking और route calculation app

  • Gmail order emails को parse करके schedule, route, driving time, और tax के लिए mileage logs अपने-आप calculate किए जाते हैं
  • Opus 4.5 ने Google authentication integration और Firebase connection एक साथ संभाल लिया
  • लेखक के अनुसार, “जो काम हाथ से करना बेहद तकलीफ़देह होता, उसे Opus ने पूरी तरह कर दिया”

code understanding और quality issues

  • लेखक कहते हैं कि Swift न जानने के बावजूद app पूरी तरह काम करता है
  • Opus 4.5 खुद bugs ढूंढकर ठीक करता है, इसलिए लेखक को code की अंदरूनी संरचना न जानने पर भी development जारी रखने में दिक्कत नहीं हुई
  • code quality पर सवाल के जवाब में उनका कहना है कि “अगर code AI ही पढ़े और maintain करे, तो human readability उतनी महत्वपूर्ण नहीं है”
  • VS Code में AI-विशेष code writing prompts का उपयोग कर, LLM के लिए आसानी से समझ आने वाली structure-केंद्रित code बनाई गई

AI-केंद्रित coding principles

  • prompts इस धारणा पर आधारित हैं कि “code AI लिखेगा और maintain करेगा”
    • सरल structure, स्पष्ट entry points, न्यूनतम abstraction, और low coupling पर ज़ोर दिया गया
    • explicit control flow, simple functions, structured logging, और आसान regeneration को महत्व दिया गया
  • code refactoring के समय Opus ने priority के हिसाब से improvement items (high/mid/low) दस्तावेज़ में व्यवस्थित किए
  • security review के समय API keys, login handling, और sensitive data storage की जाँच करने को कहा गया
    • लेखक मानते हैं कि security की पूर्णता “करीब 80% स्तर” पर है और अभी भी चिंता बनी हुई है

AI development युग का मोड़

  • लेखक लिखते हैं कि “कुछ घंटों में चीज़ें बना पाने की इस वास्तविकता में उत्साह और खालीपन दोनों साथ हैं”
  • पहले वे मानते थे कि “AI developers को replace नहीं कर सकता”, लेकिन अब उस संभावना को नकारना मुश्किल है
  • निष्कर्ष में वे ज़ोर देते हैं कि AI-केंद्रित development environment में हिचकिचाए बिना खुद बनाकर देखें
  • अंत में वे चेतावनी देते हैं कि “कम-से-कम API key management की ज़िम्मेदारी आपको खुद लेनी होगी”

सारांश: Opus 4.5 को सिर्फ code assistant से आगे बढ़कर, पूरे applications को स्वायत्त रूप से design, implement और deploy करने में सक्षम AI developer-स्तर के model के रूप में देखा गया है। लेखक का कहना है कि इस अनुभव ने उन्हें AI द्वारा मानव developers को replace किए जाने की वास्तविक संभावना का प्रत्यक्ष एहसास कराया।

3 टिप्पणियां

 
wegaia 2026-01-08

मैंने Opus 4.5 से कहा कि वह एक लाइन का code ठीक करे, लेकिन उसने उसके ऊपर मौजूद लगभग 10 लाइन की config code अपनी मर्ज़ी से डिलीट कर दी। जब मैंने पूछा कि उसने उसे क्यों हटाया, तो उसने कहा कि उसे लगा वह बस बेकार code था, इसलिए हटा दिया..

 
GN⁺ 2026-01-07
Hacker News की राय
  • मिड-लेवल इंजीनियर का काम सिर्फ नया ऐप बनाना नहीं, बल्कि scalability और understandability को ध्यान में रखकर architecture डिज़ाइन करना होता है
    Opus 4.5 “एक ऐप बना दो” जैसे स्तर की requests तो अच्छी तरह संभाल लेता है, लेकिन जब असली काम की तरह मौजूदा code में feature जोड़ने को कहो, तो यह अजीब abstractions इस्तेमाल करता है या मनचाही quality पाने के लिए कई बार सुधार करना पड़ता है
    non-technical लोग सोच सकते हैं, “चल रहा है तो ठीक है”, लेकिन इंजीनियर जानते हैं कि इतना काफी नहीं है

    • ‘सही तरीका’ दो तरह का होता है — context के हिसाब से सही तरीका और वह तरीका जिसे इंजीनियर generalized रूप में सही मानते हैं
      याद है, पहले टीम में “सही जवाब” को लेकर लड़ाई होती थी। आखिर में किसी outsider को आकर याद दिलाना पड़ता था कि business के नजरिए से क्या महत्वपूर्ण है
      कई बार गंदा-सा सही, पर जल्दी बनाकर दिशा सही है या नहीं, यह validate करना ही असली ‘सही’ तरीका होता है
      समस्या तब होती है जब शुरुआत से ही over-engineering हो, या उल्टा manager refactoring रोक दे। आखिरकार संतुलन ही सबसे ज़रूरी है
    • ऐसे projects देखकर लगता है कि GitHub पर मौजूद image converter या Minesweeper clone को सीधे fork कर लेना चाहिए, इसलिए LLM का इस्तेमाल बस copyright हटाने के लिए किया जा रहा है
    • कुछ लोग दावा करते हैं कि “code quality अब महत्वपूर्ण नहीं रही”। मतलब आज tests pass हो जाएँ तो काफी है, और कल अगर पूरी refactoring चाहिए तो थोड़ा extra credit खर्च करके कुछ घंटों में फिर से बना लेंगे
    • मुझे यह देखकर हैरानी हुई कि Opus 4.5 मौजूदा codebase के idiomatic patterns को काफ़ी अच्छी तरह follow करता है
      अगर उसे साफ़ तौर पर कहो कि पास के code को पढ़े, तो यह कहीं बेहतर काम करता है। सिर्फ एक-दो वाक्य और जोड़ना भी काफी होता है
    • मौजूदा code में feature जोड़ते समय अगर चाही गई abstraction को सीधे निर्देश में बता दो, तो यह धीरे-धीरे अच्छा काम करता है
      फिर भी मैं व्यक्तिगत रूप से GPT‑5.2 को ज़्यादा पसंद करता हूँ
  • बहुत से इंजीनियर Claude Code जैसे LLM agents की मौजूदा क्षमता को कम आँक रहे हैं
    हमारी टीम ने Claude Code से code review, ESLint automation, PR checklist, docs sync, और test coverage checks तक automate कर दिए हैं
    ticket triage भी अपने-आप हो जाता है, इसलिए जब इंजीनियर काम शुरू करता है तब तक आधा काम पहले से हो चुका होता है
    example repo claude-code-showcase पर है
    मुझे पूरा यक़ीन है कि 2026 तक यह industry का standard workflow बन जाएगा

    • frontend (React, HTML, mobile) और low-level (OpenGL, io_uring, libev आदि) क्षेत्रों में LLM उपयोग का अनुभव बहुत अलग है
      Opus 4.5 JS apps तो अच्छी तरह बना लेता है, लेकिन अगर C++ में 2003 के किसी paper का shadow algorithm लागू करने को कहो, तो पूरी तरह बिखर जाता है
      Fabien Sanglard की Doom3 BFG threading review तक खिलाने पर भी सिर्फ बेकार code निकलता है
      यानी “हम LLM को कम नहीं आँक रहे, बल्कि यह अभी practical नहीं है इसलिए इंतज़ार कर रहे हैं”
    • बहुत से लोगों ने शुरुआत में AI coding आज़माई और errors व frustration के कारण छोड़ दिया
      लेकिन Opus 4.5 एक स्तर ऊपर है। errors बहुत कम हैं और ज़्यादातर छोटी-मोटी गलतियों तक सीमित हैं
    • यूनिवर्सिटी में छात्रों को पढ़ाते हुए मैंने Cursor, Claude Code, और Codex को test किया,
      और AI की मदद से 2 हफ्ते लगने वाला project सिर्फ 5 घंटे में पूरा कर लिया
      AI न होता तो शायद इसे शुरू भी नहीं करता
    • AI द्वारा बनाए गए README में directory structure लिखना हास्यास्पद लगता है। tree command से सब दिख जाता है
    • आगे चलकर “programmer” नाम की नौकरी ही कम हो सकती है, और tools का इस्तेमाल करके सृजन करने की क्षमता अधिक महत्वपूर्ण हो जाएगी
  • मैंने Opus 4.5 का काफी इस्तेमाल किया है, और complex code analysis में यह शानदार है, लेकिन अभी भी इंसान-स्तर की problem-solving नहीं है
    उदाहरण के लिए, यह graph layout algorithm को सही पहचान लेता है, लेकिन उसकी bug खुद ठीक नहीं कर पाता
    code analysis और knowledge augmentation के लिए यह बेहतरीन है, लेकिन compound problem solving अभी इसके बस की बात नहीं

    • Copilot की token बचाने के लिए context काट देने वाली संरचना इसकी सीमा है
      अगर असली performance चाहिए तो API सीधे इस्तेमाल करनी होगी, और एक PR पर तीन अंकों का खर्च भी आ सकता है
      संदर्भ: models.dev
    • यह चौंकाने वाला था कि Copilot, Opus 4.5 इस्तेमाल करते समय tokens को 3x गिनता है, और मैंने महीने का आधा quota सिर्फ एक हफ्ते में खर्च कर दिया
    • AI को सिर्फ code analysis tool की तरह इस्तेमाल करना भी काफ़ी मूल्यवान है
      docs generation में यह इंसानों से बेहतर है, और इसकी error rate भी अक्सर इंसानों से कम होती है
    • third-party tool के ज़रिए इस्तेमाल करने पर व्यवहार अलग होता है
      Claude Code subscription लेकर इसे सीधे VS Code या Cursor में आज़माने की सलाह दूँगा
  • छुट्टियों के दौरान मैंने GPT‑5.x से कई projects किए —
    Swift automation tools, ARM JIT engine integration, synthesizer prototype वगैरह
    GPT‑5.2 और Codex family, Opus जितने ही शक्तिशाली हैं, यहाँ तक कि पूरा CI workflow एक साथ सेट up कर सकते हैं
    मेरे जैसे लोगों के लिए, जो planning करते हैं और code review करते हैं, यह productivity multiplier है

    • GPT‑5.2 अक्सर CLI utility के अस्तित्व या उसके feature को hallucinate कर देता था
      गलती पकड़ने के लिए असली source code खंगालना पड़ता था
    • Gemini 3 Pro (High) और Antigravity, Amp, Junie जैसे tools भी प्रभावशाली लगे
      मैंने Ruby के लिए Ratatui binding library सिर्फ 2 हफ्तों में पूरी कर ली
      Antigravity कई agents को parallel चलाकर context compression और automatic management करता है
      ऐसे advanced tools, free version से बिल्कुल अलग अनुभव देते हैं
      Unix tools और git CLI को साथ इस्तेमाल करने से context छोटा रहता है और efficiency अधिकतम हो जाती है
    • LLM backend·CLI code में मज़बूत हैं, लेकिन HTML/CSS या JS frontend जैसे visual feedback वाले क्षेत्रों में अब भी कमज़ोर हैं
      structured input-output में ये अच्छे हैं, लेकिन जहाँ “sensory polish” चाहिए वहाँ असफल हो जाते हैं
  • हाल में HN पर LLM से जुड़े negative comments बहुत कम हुए हैं, ऐसा महसूस हुआ
    लेकिन ज़्यादातर shared projects अभी भी tech demo स्तर पर ही रुक जाते हैं
    context बनाना, यानी user requirements को समझना, अभी भी इंसानों का काम है
    weekend में कई apps बनाए जा सकते हैं, लेकिन उन्हें maintain करने वाला शायद ही कोई होता है

    • negative comments कम होने का कारण यह भी हो सकता है कि लोग बार-बार होने वाली “नया model 1000x बेहतर” बहस से थक चुके हैं
    • यह भी हो सकता है कि monetizable products बनाने वाले लोग चुपचाप build कर रहे हों, इसलिए share नहीं करते
    • production deployment और maintenance में बहुत भारी मेहनत लगती है
      Karpathy ने भी कुछ ऐसा ही अनुभव साझा किया था — prototype आसान है, deployment मुश्किल
      अगर tool सिर्फ personal use के लिए है, तो completeness से ज़्यादा problem solving पर ध्यान देना भी काफी है
    • AI इस्तेमाल करने वाले लोग भी आख़िरी 20% वाले हिस्से में अटक जाते हैं, जहाँ integrated thinking चाहिए
      अगर सोचने का काम AI पर छोड़ दो, तो खुद सोचने की क्षमता कमज़ोर पड़ जाती है
    • game development में भी 80/20 rule वैसा ही लागू होता है
      idea test करना तेज़ हो गया है, लेकिन polished product तक पहुँचने के लिए अब भी इंसानी धैर्य चाहिए
  • Opus 4.5 में सिर्फ knowledge ही नहीं, autonomous problem-solving ability भी काफ़ी बेहतर हुई है
    अगर समस्या स्पष्ट रूप से परिभाषित हो, तो यह लगभग सब कुछ हल कर देता है, यहाँ तक कि reverse engineering भी कर चुका है
    हाल में मैं खुद coding कम करता हूँ, specs लिखता हूँ और Opus को execute व improve करने के लिए निर्देश देता हूँ

    • सार्वजनिक examples में coding-agent-benchmark और
      C64 game reverse engineering project शामिल हैं
    • “over-engineering” रोकने का तरीका क्या है, यह जानने की जिज्ञासा है
    • मैं Claude web app को rubber duck debugging के लिए इस्तेमाल करना अधिक efficient पाता हूँ
      Claude Code शक्तिशाली है क्योंकि यह पूरा codebase देख सकता है, लेकिन quota बहुत तेज़ी से खत्म हो जाता है
      इसलिए मैं फिर web version पर लौट आया
    • मैं भी हाल में side projects लगभग इसी तरह कर रहा हूँ
  • Opus 4.5 से मैंने Python-based JavaScript interpreter, WebAssembly runtime, और Rust string search routine का C port तक बनवाने की कोशिश की
    ज़्यादातर प्रयोग smartphone पर किए, और नतीजे हैरान करने वाले थे

    • अगर “Python में लिखा JS interpreter” Bellard के MQJS पर आधारित है, तो उसका स्रोत ज़रूर बताना चाहिए
      संदर्भ: micro-javascript
    • visual reasoning की ज़रूरत वाले सवालों में (जैसे slime mold path algorithm) यह अब भी कमज़ोर है
    • “Rust routine को C में port करके तेज़ बना दिया” — यह नतीजा दिलचस्प है
    • जब मैंने कहा “JavaScript में Python 3 interpreter लिखो”, तो इसने tests तक pass कर दिए, यह देखकर हैरानी हुई
    • लेकिन हाल में मुझे बहुत बड़ा फर्क महसूस नहीं हुआ। models स्थिर लग रहे हैं, जबकि agent frameworks ज़्यादा आगे बढ़े हैं
      example video: Mastodon लिंक
  • developers को सचमुच hire किए जाने का कारण responsibility है
    StackOverflow या GitHub से code copy करने के दौर में भी tools थे,
    लेकिन जब समस्या आती है तो जिम्मेदारी आख़िरकार इंसान की ही होती है

    • आजकल जिम्मेदारी लेने वाला व्यक्ति सबसे महत्वपूर्ण है
      अगर कोई भरोसेमंद teammate AI code पर अपना नाम लगाने को तैयार है, तो वह ठीक है
    • लेकिन industry, responsibility से ज़्यादा नई चीज़ें बनाने वालों को reward करती है
      maintenance को अक्सर नज़रअंदाज़ किया जाता है
    • अब real-time code review ही default mode बनता जा रहा है
      मैंने weekend में एक SaaS का 80% AI से बनवाया और सिर्फ core हिस्से खुद लिखे
      22 साल पहले लिखी language spec paste की, और Opus ने 3 मिनट में parser और tests पूरा कर दिया
      हम अब शायद mining industry की तरह बदलाव के साथ ढलने वाले मोड़ पर हैं
    • इसलिए मैं AI को writer से ज़्यादा editor·reviewer की तरह इस्तेमाल करना पसंद करता हूँ
      code मैं लिखता हूँ, और AI से problems खोजने व test suggestions लेने का काम कराता हूँ
  • Opus 4.5 मेरी मदद से एक नई programming language बना रहा है
    low-level implementation तक पर चर्चा करते हुए, यह लगभग pair programming जैसा सहयोग देता है
    लेकिन बड़े codebase में अभी भी इंसान की system-level control ज़रूरी है
    नहीं तो Opus spec बदल देता है या तात्कालिक workaround से ढँक देता है
    यह कोई万能 tool नहीं है, लेकिन लगता है कि यह मेरी ज़िंदगी का सबसे productive year बना सकता है
    साथ ही, अगर ऐसी technology आम हो गई, तो छोटे web communities के पुनर्जागरण की उम्मीद भी है

    • हो सकता है कभी AI खुद code maintain करे,
      लेकिन तब तक मुझे लगता है कि ऐसी languages ज़्यादा महत्वपूर्ण हैं जिन्हें इंसान आसानी से समझ सके
    • कुछ लोग अब भी संदेह से पूछते हैं, “क्या ऐसी चीज़ बनाना वाकई मायने रखता है?”
    • किसी ने मज़ाक में यह भी कहा, “ऐसा उपन्यास कौन खरीदेगा?”
  • जब मैंने Opus 4.5 से कहा, “पूरे project को improve करो”, तो इसने अजीब architecture और ढेर सारे bugs पैदा कर दिए
    tests या bug detection में यह शानदार है, लेकिन पूरी structure design इसे सौंप दो तो पछताना पड़ेगा

    • इसकी जगह “improvement ideas suggest करो” कहना और उनमें से अच्छे ideas चुनकर Claude से समझवाने के बाद implement करवाना ज़्यादा efficient है
    • जब आपको साफ़ पता हो कि “क्या improve करना है”, तब यह सबसे अच्छा काम करता है
      “कुछ भी improve करके दिखाओ” सबसे खराब prompt है
    • ऐसे cases model की कमज़ोरियाँ दिखाने वाले अच्छे examples हैं
      पहले किसी ने किसी agent से रातभर improve करवाया और बदले में 100,000 lines का कचरा code पाया था
      इसलिए plan-based development महत्वपूर्ण है
      संदर्भ: The Highest Quality Codebase
    • Opus सहित ज़्यादातर models मौजूदा code को improve करने में कमज़ोर हैं, लेकिन नया code लिखने में अच्छे हैं
    • AI की code review suggestions में 90% बेकार होती हैं, लेकिन बाकी 10% सचमुच असली problems पकड़ लेती हैं
      ऐसा लगता है कि यह infinite loop की तरह लगातार fixes सुझाता रह सकता है
 
[यह टिप्पणी छिपाई गई है.]