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-ஐத் தனிப்பட்ட வார்ப்புருக்களுக்குள் கட்டுப்படுத்துவது, உங்கள் உற்பத்திக் குறியீட்டுத் தளத்தை மெதுவாக அழிக்கும் குழப்பமான உயிரினமாக இல்லாமல், நம்பகமான பொறியியல் தோழராக அதை நடத்துவதற்கான முன்நிபந்தனை.