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 ला वैयक्तिक टेम्पलेटमध्ये बांधणे ही त्याला विश्वासार्ह इंजिनिअरिंग सोबती मानण्याची पूर्वअट आहे, तुमचा प्रोडक्शन कोडबेस हळूहळू नष्ट करणारी अनागोंदी माजवणारी शक्ती म्हणून नव्हे.