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 ని వ్యక్తిగత టెంప్లేట్ల లోపల పరిమితం చేయడం, దాన్ని మీ ప్రొడక్షన్ కోడ్‌బేస్‌ను నెమ్మదిగా నాశనం చేసే అస్తవ్యస్త అస్తిత్వంగా కాకుండా నమ్మకమైన ఇంజినీరింగ్ సహచరుడిగా పరిగణించడానికి ముందస్తు షరతు.