AI कोड जीनियस की तरह लिखता है। आर्किटेक्चर गोल्डफ़िश की तरह।

डेमो के शानदार दिखने के दो हफ़्ते बाद बिल्ड ठीक न होने लायक़ हो चुका था। एक जगह टूटा हुआ नहीं, हर जगह टूटा हुआ, ऐसे तरीक़ों से जो एक-दूसरे का खंडन करते थे। ज़ीरो-शॉट स्केलिंग असल में ऐसी ही दिखती है। ग़ैर-डेवलपर और कभार कोड करने वाले छतों पर चढ़कर चिल्ला रहे हैं कि AI पूरी की पूरी एप्लिकेशन सेकंडों में बना सकता है। वे ज़ीरो-शॉट प्रॉम्प्टिंग से जोड़कर बनाए गए एक चमकदार, चलते-फिरते प्रूफ़ ऑफ़ कॉन्सेप्ट को देखते हैं और मान लेते हैं कि वह लगभग पूरा हो चुका है, किसी उत्पाद को उसकी अंतिम अवस्था तक निखारने में लगने वाले असली, घिसाऊ संरचनात्मक समय को पूरी तरह नज़रअंदाज़ करते हुए।

मैंने उसे आख़िरकार बचा लिया था। पैच करके नहीं। मैंने जो सीखा था उसे रखा, ढाँचा फेंक दिया, और एक ऐसी मेमोरी लेयर पर दोबारा बनाया जिसे एजेंट को कुछ भी लिखने की इजाज़त मिलने से पहले पढ़ना पड़ता था। पूरे चक्कर में लगभग तीन हफ़्ते लगे। उसने जो सिखाया, उसके लिहाज़ से सस्ता सौदा।

आर्किटेक्चर

Claude, GPT5, Gemini 3 जैसे AI मॉडल स्टेटलेस भविष्यवाणी इंजन की तरह काम करते हैं। कोई जटिल प्रोजेक्ट तभी टिकेगा जब उसका अंतर्निहित नॉलेज बेस चट्टान जैसा मज़बूत हो। अगर बुनियाद कमज़ोर है, तो समय के साथ बदलाव ज़रूरी होने पर उत्पाद का निर्माण लाज़िमी तौर पर बग और असंगतियाँ लाने लगेगा।

अगर आप एक अकेले प्रॉम्प्ट से एप्लिकेशन ज़ीरो-शॉट बनाने की उम्मीद करते हैं, या हर कच्चे प्रॉम्प्ट के बाद जादुई नतीजों की उम्मीद करते हैं, तो आप अंतहीन लूप में चलते रहेंगे, एक समस्या ठीक करते हुए चुपके से कहीं और नई समस्याएँ पैदा करते हुए। सिस्टम का नक़्शा बनाने के लिए शोध की योजना और संश्लेषण, उसके बाद लक्षित प्रॉम्प्ट की एक बंदिश-भरी श्रृंखला, ऐसा कोडबेस बनाने की बुनियादी रूप से सबसे अच्छी रणनीति है जो टिके। इसीलिए एक कठोर नॉलेज बेस इतना अहम है।

यही सटीक विभाजन रेखा है: एक अच्छा सॉफ़्टवेयर इंजीनियर AI द्वारा लाई गई संरचनात्मक असंगतियों को तुरंत पकड़ लेगा, जबकि कभार कोड करने वाला अपने रवैये में पूरी तरह बेफ़िक्र हो सकता है, इस बात से सुखद रूप से अनजान कि वह आपस में टकराते स्टेट लॉजिक का एक विनाशकारी गड़बड़झाला मर्ज कर रहा है।

# Example: What a strong, constrained knowledge base looks like
/antigravity-base
├── apps
│   ├── web        (Astro 4 + Tailwind v4)
│   └── studio     (Sanity CMS)
├── packages
│   ├── ui         (Strict design tokens - AI CANNOT hallucinate)
│   ├── config     (Shared ESLint/TS - strict boundaries)
│   └── core       (Business logic boundaries)
├── knowledge      (Deep context and architectural decisions)
│   └── routing-rules.md
└── turbo.json     (Build constraints)

निर्माण

जब मैंने gekro.com बनाई, तो मैंने खाली प्रॉम्प्ट और ज़ीरो-शॉट सफलता की भोली उम्मीद से शुरुआत नहीं की। मैंने एक कठोर आर्किटेक्चरल ढाँचे से शुरुआत की। समय के साथ मैंने अपने ख़ुद के “Antigravity” टेम्पलेट बनाए हैं जो बेहद दोबारा इस्तेमाल होने लायक़ हैं और किसी भी जटिल प्रोजेक्ट को बहुत जल्दी शुरू करने के लिए AI को कठोरता से बाँधने में मेरी मदद करते हैं। हर गंभीर प्रोजेक्ट का शुरुआती बिंदु आपकी मौजूदा और दीर्घकालिक दृष्टि पर आधारित गहरी जड़ों वाली बुनियाद होना चाहिए। बंदिशें लागू करने के लिए डेवलपर्स को अपने ख़ुद के नॉलेज बेस को टेम्पलेट बनाना शुरू करना होगा।

# Initializing the environment from the core template
# Replace with your own base template repo
git clone https://github.com/your-org/your-base my-new-project
cd my-new-project
pnpm install

# Enforcing strict boundaries before AI touches anything
pnpm turbo run typecheck lint

अगर मुझे Claude से कोई नया फ़ीचर बनवाना है, तो उसे मेरे मौजूदा टेम्पलेट की सख़्त परिभाषाओं के भीतर काम करना होगा। यह वही कॉन्फ़िगरेशन ब्लॉक है जो मैं एजेंट के सिस्टम प्रॉम्प्ट में डालता हूँ ताकि वह बेक़ाबू होकर चीज़ें तोड़ने वाली असंगतियाँ न लाए।

// Conceptual representation - actual rules live in your workspace system prompt / .cursorrules
// packages/config/base-agent-rules.ts
export const AgentConstraints = {
  allowAny: false,
  styling: "Tailwind v4 utility classes exclusively",
  state: "No local state for global data - use centralized store",
  components: "Astro islands for interactivity only",
  imports: "Use alias @repo/ui, never relative paths",
  knowledge: "Always refer to /knowledge/routing-rules.md before creating new endpoints"
} as const;

इससे पक्का होता है कि AI अंदाज़ा नहीं लगा रहा कि स्टेट कैसे बनी है। वह बंदिशें पढ़ता है, किसी ख़ास विषय पर गहरे संदर्भ के लिए लक्षित नॉलेज बेस से मिलान करता है, और बदलाव को सर्जिकल ढंग से लागू करता है।

अपने नियमों को लगातार एक समर्पित नॉलेज बेस की ओर इंगित करने से दो बहुत अहम चीज़ें होती हैं: एजेंट सिर्फ़ मौजूदा काम पर अति-केंद्रित हो जाता है, और आपके मॉडल की कॉन्टेक्स्ट सीमा बची रहती है क्योंकि एजेंट एक अकेला इम्प्लीमेंटेशन पैटर्न समझने के लिए पूरे कोडबेस को मेमोरी में नहीं घसीटता।

इस अनुशासन को नज़रअंदाज़ करने का नुक़सान सीधे-सीधे महसूस होता है। हैलुसिनेट किए गए कंपोनेंट और बंदिशों वाले कंपोनेंट के बीच का सटीक फ़र्क़ यह है:

// What AI hallucinates without constraints:
import { Button } from '../../components/ui/Button'  
import { Card } from '../../../shared/Card'
import { theme } from './localTheme'  // invented, doesn't exist

// What AI generates with a constrained template:
import { Button, Card } from '@repo/ui'
import { tokens } from '@repo/config/tokens'

वह अकेला डिफ़ बिना एक शब्द की व्याख्या के पूरी दलील कह देता है।

सिर्फ़ संरचनात्मक बॉइलरप्लेट से आगे, रिपॉज़िटरी की जड़ में “चलते-चलते दस्तावेज़ बनाओ” वर्कफ़्लो, डिसीज़न लॉग और इश्यू ट्रैकर लाना बहुत मदद करता है। एक जीवंत, पठनीय संदर्भ बनाकर जिसे एजेंट कार्रवाई से पहले जाँचता है, आप AI को एक ही समस्या को दो बार सुलझाने की कोशिश में चक्कर काटने से सक्रिय रूप से रोकते हैं। आप असल में अपने फ़ाइल सिस्टम में ही अपना स्थानीय MCP (Model Context Protocol) सर्वर बना रहे हैं। एक स्वस्थ रेपो के लिए एक सख़्त फ़ाइल संगठन सेटअप, जिसमें संदर्भ सीधे एजेंट के नियमों में डाला गया हो, और साथ में एक मज़बूत README, अनिवार्य है।

उदाहरण के लिए, एजेंट को लॉजिक कहाँ भेजना है, यह साफ़ तौर पर नक़्शे पर उतारना आर्किटेक्चरल अनुपालन की गारंटी देता है:

# Agent Prompt: Organization Enforcement
"Generate the new 'Analytics' feature. Follow the established file organization:
- Place all UI components strictly in `packages/ui/src/analytics/`
- Place all business state logic in `packages/core/stores/analytics.ts`
- Do NOT generate local component state. Review the `/knowledge/routing-rules.md` file first and automatically enforce these routing rules."

किसी जटिल प्रोजेक्ट के लिए एप्लिकेशन कोड की एक भी लाइन लिखने से पहले, मेरा मानक वर्कफ़्लो विषय पर एक गहन शोध लेख शुरू करना है। मैं उस आर्किटेक्चरल शोध का संश्लेषण करता हूँ और फिर अपनी प्रॉम्प्ट रणनीति की रूपरेखा बनाना शुरू करता हूँ, उन शोध निष्कर्षों को एक अलग आर्टिफ़ैक्ट फ़ोल्डर में Markdown फ़ाइलों के रूप में सहेजते हुए। स्पष्ट आर्टिफ़ैक्ट का हवाला देने वाली, अच्छी तरह योजनाबद्ध, भारी शोध पर टिकी प्रॉम्प्ट रणनीति, ज़ीरो-शॉट विफलताओं पर प्रतिक्रिया देने और उन्हें ठीक करने के चक्कर में गोल-गोल घूमने से असीम रूप से बेहतर है।

इसके अलावा, इस तरह बनाने से लागत पर ज़बरदस्त नियंत्रण मिलता है। यह रणनीति तब सबसे अच्छी चलती है जब आपके पास पहले से मल्टी-प्रोवाइडर सेटअप हो, जिसे एब्स्ट्रैक्शन लेयर मामूली बना देती है। आपका ब्लूप्रिंट और संरचनात्मक संश्लेषण उपलब्ध सबसे सक्षम फ़्रंटियर मॉडल से बनना चाहिए, जैसे Gemini Pro या Claude Opus। एक बार कठोर आर्किटेक्चरल सीमाओं की रूपरेखा बन जाए, तो Flash जैसे तेज़, सस्ते मॉडल को दस्तावेज़ीकृत ब्लूप्रिंट पर अमल करने दें। जब स्थानीय कोड जनरेशन पूरा हो जाए, तो बेस टेम्पलेट के विरुद्ध सख़्त संगति सुनिश्चित करने के लिए ऊँचे दर्जे के मॉडल से पुल रिक्वेस्ट की समीक्षा करवाएँ। इससे लंबे समय में भारी रक़म बचती है।

आख़िर में, एजेंट से हर नए फ़ीचर के लिए एक टेस्ट सुइट बनवाना हमेशा अनिवार्य रखें। सुनिश्चित करें कि इसके निर्देश वर्कस्पेस नियमों या README में साफ़ तौर पर मौजूद हों, ताकि हर बड़े प्रॉम्प्ट चक्र में परीक्षण अनिवार्य हो, बाद की बात नहीं।

# Agent Prompt: Test Suite Mandate
"Whenever you create or modify a component, you MUST simultaneously generate/update the exact corresponding `vitest` suite in the `packages/core/tests/` directory to cover the failure cases. Do not ask for permission, just include the test in the PR."

समझौते

तनाव पूरी तरह टेम्पलेट बनाने की शुरुआती लागत और कच्ची प्रॉम्प्टिंग की भ्रामक रफ़्तार के बीच है। दोबारा इस्तेमाल होने वाले टेम्पलेट सँभालने में वीकेंड के वे घंटे लगते हैं जो मैं फ़ीचर बनाने में बिताना पसंद करता। इसके अलावा, जब किसी अंतर्निहित फ़्रेमवर्क का नया बड़ा संस्करण आता है, तो टेम्पलेट बुनियादी तौर पर टूट जाता है। उस पर आधारित हर आगामी AI जनरेशन को बुनियाद पैच होने तक भारी हाथ से दिशा देनी पड़ती है।

एक दूसरा समझौता भी है जो मैंने नहीं सुलझाया, और मुझे पक्का नहीं कि किसी ने सुलझाया है। मेमोरी अब भी कमज़ोर कड़ी है। अच्छी मेमोरी लेयर, समझदार स्किल्स सेटअप और कई एजेंट के तालमेल के बावजूद, एक बड़ा प्रोजेक्ट अब भी चुपचाप ऐसी चीज़ें छोड़ देता है जो उसे जानने वाला कोई इंसान कभी न छोड़ता। इसलिए आप ख़ुद को दोहराते हैं। इस वर्कफ़्लो का यही हिस्सा मुझे सचमुच खीझ दिलाता है, और टेम्पलेटिंग की कोई मात्रा इसे ठीक नहीं करती।

आगे की राह

यह कहना ज़रूरी है कि मैंने क्या ग़लत समझा था। मैं सोचा करता था कि AI कोड जनरेशन बस बग-प्रवण है: कि वह समझे बिना पूरे आत्मविश्वास से लिखता है, और कोई भी संदर्भ उसे बचा नहीं सकता। जिन मॉडलों पर मैंने वह राय बनाई थी, उनके लिए यह एक उचित आकलन था। मौजूदा मॉडलों के लिए यह उचित आकलन नहीं है। वे बहुत आगे आ गए हैं, और उन पर उससे काफ़ी ज़्यादा भरोसा किया जा सकता है जितना मैंने कभी माना था, लेकिन सख़्ती से उतना ही जितना संदर्भ आप उन्हें थमाते हैं, और यही इस लेख की पूरी दलील है।

हम कोड के लिए मॉडलों को प्रॉम्प्ट करने से हटकर आर्किटेक्चरल अनुपालन के लिए मॉडलों को प्रॉम्प्ट करने की ओर बढ़ रहे हैं। AI को निजी टेम्पलेट के भीतर बाँधना उसे एक भरोसेमंद इंजीनियरिंग साथी मानने की पूर्व शर्त है, न कि एक अराजक सत्ता जो धीरे-धीरे आपके प्रोडक्शन कोडबेस को तबाह कर दे।