DESIGN.md கோப்பு என்றால் என்ன? AI ஏஜெண்டுகளுக்கு ஏன் தேவை?

DESIGN.md என்றால் என்ன மற்றும் AGENTS.md எவற்றை உள்ளடக்குவதில்லை

DESIGN.md என்பது உங்கள் repository-ன் root-ல் இருக்கும் ஒரு markdown கோப்பு. இது உங்கள் code ஏன் இந்த வடிவில் வடிவமைக்கப்பட்டுள்ளது என்பதை ஒரு AI coding agent-க்கு விளக்குகிறது. AGENTS.md வேறொரு கேள்விக்கு விடையளிக்கிறது: இங்கே எவ்வாறு பணியாற்றுவது? அதாவது, build command, test command, நிறைவேற்றப்பட வேண்டிய lint, மற்றும் மாற்றக்கூடாத பாதைகள் (paths) ஆகியவற்றை இது குறிப்பிடுகிறது. ஏற்கனவே எடுக்கப்பட்ட முடிவுகளையும், அவற்றை மாற்றினால் என்னென்ன பாதிப்புகள் ஏற்படும் என்பதையும் DESIGN.md பதிவு செய்கிறது.

Claude Code அல்லது Cursor போன்ற ஒரு coding agent, உங்கள் repository-ஐ தானாகவே வாசித்து திருத்தும் திறன் கொண்டது. இது இயல்பாகவே அதிக தன்னம்பிக்கையுடன் செயல்படும். தனக்குத் தெரியாத ஒரு pattern-ஐக் கண்டால், அதை மேம்படுத்த முயற்சிக்கும். உதாரணமாக, ஒரு கையால் எழுதப்பட்ட cache-ஐ Redis (in-memory data store) ஆக மாற்றும்; ஏனெனில், அந்த model வாசித்த பெரும்பாலான code-களில் cache என்பது அப்படித்தான் இருக்கும். AGENTS.md இதைத் தடுக்காது, ஏனெனில் make test எந்த நிலையிலும் நிறைவேறும். மீறப்பட்ட அந்த விதி, அந்த agent வாசிக்கும்படியான எந்த இடத்திலும் எழுதப்படவில்லை.

நீங்கள் இன்னும் முதல் கோப்பை உருவாக்கவில்லை என்றால், அங்கிருந்து தொடங்குங்கள். AGENTS.md மற்றும் அதன் அருகில் இருக்கும் HUMAN.md அதன் வடிவத்தையும், ஒவ்வொரு கருவியும் அதை எங்கே தேடும் என்பதையும் விளக்குகிறது. அதற்கு அடுத்த அத்தியாயம் கீழே கொடுக்கப்பட்டுள்ளது.

ஒரு DESIGN.md கோப்பிற்குள் உண்மையில் என்ன இருக்கிறது

வடிவமைப்பைக் கற்றுக்கொள்வதற்கான மிக வேகமான வழி, நிறுவனங்கள் தங்களைப் பற்றி வெளியிடும் கோப்புகளைப் படிப்பதுதான். official-design-md களஞ்சியம் அவற்றை மட்டுமே கண்காணிக்கிறது. அதன் உள்ளடக்கம் குறித்த விதி ஒரே வரியில் உள்ளது, அந்த வரியே இந்தத் தொகுப்பின் முழு நோக்கமாகும்:

Every entry here is a DESIGN.md published by the company or project itself — not extracted, not reverse-engineered, not community-made.

அக்டோபர் 2026 நிலவரப்படி, இது பதினொன்றைப் பட்டியலிடுகிறது: Ant Design, Atlassian, Clerk, Juspay, Microsoft FAST, Mintlify, Nuxt, Oxide Computer, Resend, Vercel மற்றும் VoltAgent. ஒவ்வொரு கோப்பும் ஒரு பொதுவான URL-ல் உள்ளது; பெரும்பாலானவை வெளியீட்டாளரின் சொந்த டொமைனிலும், மற்றவை பொதுவான GitHub களஞ்சியத்திலும் உள்ளன. எனவே, நீங்கள் இப்போதே ஒரு terminal-ல் இதைப் படிக்கலாம்.

curl -s https://nuxt.com/design.md | head -n 60
curl -s https://vercel.com/design.md | wc -w

இவை இரண்டுமே வடிவமைப்பு முறைமை (design system) ஆவணங்கள். ஒரு தயாரிப்பு எப்படித் தெரிய வேண்டும் என்பதை இவை விவரிக்கின்றன: நிறம், எழுத்துரு, இடைவெளி, இயக்கம். பொருளைத் தாண்டிப் படியுங்கள், ஏனெனில் பயனுள்ள பகுதி அதன் தலைப்பை விட எழுத்தின் வடிவமே ஆகும்.

அக்டோபர் 27, 2026 நிலவரப்படி, Nuxt கோப்பு சுமார் 2,000 சொற்களைக் கொண்டுள்ளது, அதில் பெரும்பாலானவை ஒரு விதியும் அதற்கான காரணமும் ஆகும். dark mode தான் இயல்புநிலை தீம் என்று கூறி அது தொடங்குகிறது. இது பிராண்ட் பச்சை நிறத்தை #00DC82 பட்டியலிடுகிறது, மேலும் அந்த பிராண்ட் நிறங்கள் "லோகோக்கள், சமூக ஊடகப் படங்கள் மற்றும் அச்சுப் பணிகளுக்காக. இவற்றை UI குறியீட்டில் மூல மதிப்புகளாகப் பயன்படுத்த வேண்டாம்" என்ற குறிப்புடன் உள்ளது. முடிவிற்கு அருகில், Reject these என்று தலைப்பிடப்பட்ட ஒரு பகுதி பின்வருவனவற்றை உள்ளடக்கியது:

Raw hex values or palette classes (`text-gray-500`) in components instead of semantic tokens.

Vercel கோப்பு நீளமானது, அக்டோபர் 2026 நிலவரப்படி சுமார் 6,000 சொற்கள் உள்ளன, இது இன்னும் ஒரு படி மேலே செல்கிறது. அதன் தலைப்புகளில் ஒன்று Reject generated-design reflexes ஆகும். அதன் கீழே, ஒரு திறமையான generator-க்கு யாரும் கட்டளையிடாதபோது அது எதை நோக்கிச் செல்லும் என்பதன் பட்டியல் உள்ளது:

Hard reject decorative gradients, gradient text, glows, blobs, stripes, textures, grid backgrounds, glass effects, paper simulations, colored side rails, ornamental shadows, and fake depth.

அந்த வாக்கியம் கோப்பின் வகையை வரையறுக்கிறது. இது ஒரு நம்பிக்கையான model உருவாக்கும் இயல்புநிலைகளின் எழுத்துப்பூர்வமான பட்டியல்; model அவற்றை உருவாக்குவதை நிறுத்த வேண்டும் என்பதற்காகவே இது வெளியிடப்படுகிறது. ஏதேனும் ஒரு டொமைனுக்காகப் பட்டியலிடத் தகுதியான ஒவ்வொரு DESIGN.md-ம் இதுவே.

நிறுவனங்கள் ஏன் தங்கள் சொந்த DESIGN.md கோப்பை வெளியிடுகின்றன?

சமூகம் இதில் முந்திக்கொண்டது. awesome-design-md தளத்தில் பொது இணையதளங்களிலிருந்து எடுக்கப்பட்ட 84 கோப்புகள் உள்ளன. அக்டோபர் 27, 2026 நிலவரப்படி அதன் README-ல் உள்ள கணக்கின்படி, ஒவ்வொன்றும் ஒரே மாதிரியான ஒன்பது பிரிவுகளைக் கொண்ட வடிவமைப்பில் எழுதப்பட்டுள்ளன. எனவே, ஒரு முகவரை (agent) ஒரு கோப்பைச் சுட்டிக்காட்டி, அதே போன்ற தோற்றத்தை உருவாக்கச் சொல்ல முடியும். அந்தக் கோப்புகள் பயனுள்ளவை, ஆனால் அவை யூகங்களே. அந்த நிறுவனங்களில் யாரும் அவற்றைச் சரிபார்க்கவில்லை.

முதல் தரப்பு (first-party) கோப்பு என்பது வெளியீட்டின் வாசிப்பு அல்ல, அதுவே மூலமாகும். Vercel தனது type scale-ஐ மாற்றும்போது, vercel.com/design.md அதனுடன் சேர்ந்து மாறுகிறது. மார்ச் மாதம் எடுக்கப்பட்ட நகல், உங்கள் முகவருக்கு பழைய அளவீட்டையே தொடர்ந்து கற்பிக்கும். அந்த நகல் காலாவதியாகிவிட்டது என்பதை உங்கள் களஞ்சியத்தில் (repository) எதுவும் உங்களுக்குத் தெரிவிக்காது.

பதினொரு வெளியீட்டாளர்கள் என்பது இன்னும் சிறிய எண்ணிக்கையே. அந்த களஞ்சியமே இதைக் குறிப்பிடுகிறது: இந்தத் தரம் புதியது மற்றும் அதிகாரப்பூர்வ ஏற்பு வளர்ந்து வருகிறது. இரண்டு தொகுப்புகளும் VoltAgent-ஆல் பராமரிக்கப்படுகின்றன. இது ஒரு திறந்தநிலை முகவர் கட்டமைப்பு (open source agent framework) மற்றும் இது தனது சொந்த கோப்பையும் வெளியிடுகிறது. எனவே, இந்த பட்டியலை ஒரு நடுநிலையான கணக்கெடுப்பாகப் பார்க்காமல், ஒரு கண்காணிப்புக் கருவியாகப் பார்க்கவும். இதில் உள்ளவர்கள் காரணமாக இது கவனிக்கத்தக்கது. மற்ற மென்பொருள் உருவாக்குநர்கள் அதிகம் நகலெடுக்கும் front-end குறியீட்டைக் கொண்ட நிறுவனங்கள் பல இதில் உள்ளன. Ant Design, Microsoft FAST, Juspay மற்றும் Oxide Computer போன்ற புதிய உள்ளீடுகள், பிற குழுக்கள் கட்டமைக்கும் வடிவமைப்பு அமைப்புகளாகும் (design systems). அவற்றின் கோப்புகள் DESIGN.md என்றால் என்ன என்பதற்கான முன்மாதிரியாக மாறி வருகின்றன. AGENTS.md சென்ற பாதையுடன் ஒப்பிட்டுப் பாருங்கள்: agents.md இப்போது 60,000-க்கும் மேற்பட்ட திறந்தநிலைத் திட்டங்கள் இந்த வடிவமைப்பைப் பயன்படுத்துவதாகக் கணக்கிடுகிறது. இதன் பொறுப்பு Linux Foundation-ன் கீழ் உள்ள Agentic AI Foundation-இடம் உள்ளது. DESIGN.md அதே பாதையில் பயணிக்கத் தொடங்கியுள்ளது. ஏப்ரல் 21, 2026 அன்று, Google இந்த வடிவமைப்பிற்கான வரைவு விவரக்குறிப்பை google-labs-code/design.md என வெளியிட்டது. இதில் token schema மற்றும் Apache-2.0 உரிமத்தின் கீழ் ஒரு CLI உள்ளது. அக்டோபர் 2026 நிலவரப்படி, இந்த வடிவம் alpha நிலையில் உள்ளது மற்றும் தீவிர வளர்ச்சியில் உள்ளது. இது ஒரு நடுநிலையான அறக்கட்டளைக்கு பதிலாக Google Labs-ஆல் பராமரிக்கப்படுகிறது. இது ஒரு காட்சி அடையாளத்தை (visual identity) விவரிக்கிறது, எனவே backend கோப்பிற்குத் தேவையான மாறிலிகள் (invariants) பற்றி இது எதுவும் கூறவில்லை. முகவர் வாசிக்கக்கூடிய கோப்புகளுக்கான மரபுகள் விரைவாக நிலைபெற்று வருகின்றன, மேலும் அவை மேலிருந்து கீழ்நோக்கி நிலைபெறுகின்றன.

பயனர் இடைமுகம் இல்லாத திட்டங்களில் DESIGN.md-ல் என்ன இடம்பெற வேண்டும்

VPS-ல் இயங்கும் பெரும்பாலான மென்பொருட்களுக்குக் குறிப்பிட வேண்டிய காட்சி மொழி (visual language) இருப்பதில்லை. இருப்பினும், இந்த கோப்பு அவசியமானது, ஏனெனில் இதன் செயல்முறை நிறங்கள் சார்ந்தது அல்ல. கவனக்குறைவாக மாற்றங்களைச் செய்யும் ஒரு எடிட்டர் மீறக்கூடிய கட்டுப்பாடுகளை ஆவணப்படுத்துவதே இதன் நோக்கம்.

மாறாத விதிகள் (Invariants). ஒவ்வொரு மாற்றத்திற்குப் பிறகும் உண்மையாக இருக்க வேண்டிய ஒரு விஷயத்தை, தலா ஒரு வாக்கியத்தில் குறிப்பிடவும். "ஒவ்வொரு எழுதும் செயலும் queue.enqueue() வழியாகவே செல்ல வேண்டும். நேரடியாக database-ல் எழுதினால் audit log தவிர்க்கப்படும், compliance export-க்கு audit log-தான் தேவை." ஒரு விதியுடன் அதற்கான காரணத்தையும் இணைத்தால் மட்டுமே, நீங்கள் எதிர்பாராத ஒரு பணியின் போதும் அது நிலைத்திருக்கும். காரணம் இல்லாமல் விதியை மட்டும் எழுதினால், அது ஒரு விருப்பமாகவே கருதப்பட்டு, காலப்போக்கில் நீக்கப்பட வாய்ப்புள்ளது.

நிராகரிக்கப்பட்ட மாற்றுகள் (Rejected alternatives). வெளிப்படையான விருப்பத்தேர்வு மற்றும் அது ஏன் நிராகரிக்கப்பட்டது என்பதைக் குறிப்பிடவும். "நாங்கள் caching-க்கு Redis-ஐப் பயன்படுத்துவதில்லை. இந்த service ஒரே ஒரு VPS-ல் மட்டுமே இயங்குகிறது, எனவே in-process map வேகமானது மற்றும் பராமரிக்க வேண்டிய daemon-களின் எண்ணிக்கை ஒன்று குறைகிறது. இரண்டாவது application server உருவாக்கப்படும்போது இதை மீண்டும் பரிசீலிக்கலாம்." இந்த விளக்கம் இல்லையென்றால், வேகத்தை அதிகரிக்கச் சொல்லப்படும் ஒரு முகவர் (agent) Redis-ஐச் சேர்க்கக்கூடும்; அது சரியான முடிவாகவே தோன்றும், ஏனெனில் நீங்கள் அந்தத் தடையைப் பற்றி அவரிடம் சொல்லவில்லை. இந்த ஒரு பகுதிதான் முழு கோப்பிற்கும் மதிப்பு சேர்க்கிறது.

எல்லைகள் (Boundaries). சிறிய மாற்றம் பெரிய பாதிப்பை ஏற்படுத்தும் இடங்கள் இவை. Database schema, வாடிக்கையாளர்கள் ஏற்கனவே script-களில் பயன்படுத்தும் public route prefix, application தொடங்குவதற்கு முன் வாசிக்கும் config கோப்பு, ஒரே ஒரு நகல் மட்டுமே இயங்க வேண்டும் என்று கருதும் cron entry போன்றவை. இவற்றை அடையாளம் கண்டு, ஒவ்வொன்றையும் மாற்றினால் ஏற்படும் விளைவுகளைக் குறிப்பிடவும். ஒருவேளை அந்த முகவர் இணையத்தை அணுக முடிந்தால், search backend-ஆக இணைக்கப்பட்ட self-hosted SearXNG instance போன்றவற்றை எல்லைகளாகக் குறிப்பிடவும். ஏனெனில், எந்தத் தரவு குறியீட்டை (code) மாற்ற அனுமதிக்கப்படுகிறது, எது மேற்கோளாக மட்டுமே காட்டப்பட வேண்டும் என்பதை இந்தக் கோப்பு தெளிவுபடுத்த வேண்டும்.

சொற்களஞ்சியம் (Vocabulary). குறியீட்டில் tenant என்றும், குழுவினர் customer என்றும் அழைத்தால், அந்த மாற்றத்தை எழுதி வைக்கவும். இதில் தவறாகப் புரிந்துகொள்ளும் ஒரு முகவர், பார்ப்பதற்குச் சரியாகத் தோன்றும் ஆனால் தவறான மாதிரியைக் கொண்ட குறியீட்டை உருவாக்கும். இது போன்ற பிழைகளை review-ல் கண்டறிவது மிகவும் கடினம்.

இன்றே நீங்கள் நகலெடுக்கக்கூடிய ஒரு DESIGN.md

# DESIGN.md

## What this service is
One paragraph. What it does, who calls it, where it runs.

## Invariants
- Every write goes through `queue.enqueue()`. Direct writes skip the audit log.
- Timestamps are stored as UTC integers. Only the display layer converts them.
- One process writes to SQLite. The database is in WAL mode, and a second writer
  gets `database is locked` under load.

## Rejected alternatives
- **Redis for caching.** Rejected: one VPS, one process, an in-process map is
  enough. Revisit at two application servers.
- **An ORM for the reporting queries.** Rejected: the reports are four hand-tuned
  SQL statements. The generated query joined the same table twice.

## Boundaries
- `schema.sql` is append-only. A column rename needs a migration and a deploy window.
- The `/v1/` routes are public. Customers script against them, so the response
  shape is frozen.

## Vocabulary
- `tenant` in code is what the docs and the billing system call a customer account.

## Keeping this file honest
Update it in the commit that changes the decision. A stale DESIGN.md is worse
than no DESIGN.md, because the agent believes it.

இன்று உங்கள் நினைவிலிருந்து எழுதக்கூடிய இரண்டு பகுதிகளை நிரப்புங்கள்: மாறாத விதிகள் (invariants) மற்றும் நிராகரிக்கப்பட்ட மாற்றுகள் (rejected alternatives). மீதமுள்ளவற்றை தலைப்புகளாக அப்படியே விட்டுவிடுங்கள். நான்கு உண்மையான வரிகளைக் கொண்ட கோப்பு போதுமானது. நாற்பது வரிகள் கொண்ட ஊகமான கோப்பு தேவையில்லை. உங்கள் repository-ல் பல packages இருந்தால், ஒரு root கோப்பு அனைத்திற்கும் பொருந்தாது. monorepo-வில் உள்ள nested AGENTS.md கோப்புகள் போலவே, இங்கும் கோப்புகளைப் பிரிக்க வேண்டும்: அனைத்துக்கும் பொதுவான முடிவுகளுக்கு ஒரு சிறிய root கோப்பும், ஒவ்வொரு package-க்கும் அதன் சொந்த முடிவுகளுக்காக ஒரு சிறிய கோப்பும் இருக்க வேண்டும்.

சில கருவிகள் repository root-ல் உள்ள அனைத்து markdown கோப்புகளையும் ஏற்றும், சில குறிப்பிட்ட கோப்புகளை மட்டுமே ஏற்றும். எனவே, எதையும் ஊகிக்க வேண்டாம். AGENTS.md-க்கு ஒரு சுட்டியை (pointer) சேர்க்கவும்:

Read DESIGN.md before editing anything under `src/`. It lists the invariants and
the alternatives that were already rejected.

தவறான நடைமுறை: README-ஐ மீண்டும் சொல்லும் DESIGN.md

மிகவும் பொதுவான தவறான வடிவம், வாசிப்பதற்கு நன்றாக இருந்தாலும் எதையும் கற்றுத்தருவதில்லை. இது திட்டம் என்ன செய்கிறது என்பதை விளக்கி, அம்சங்களைப் பட்டியலிட்டு, நிறுவும் முறையை விவரித்து, உரிமத்துடன் முடிகிறது. இதில் உள்ள ஒவ்வொரு வரியும் ஏற்கனவே README-ல் உள்ளது; எதனால் ஒரு விஷயம் அவ்வாறு வடிவமைக்கப்பட்டுள்ளது என்பதற்கான காரணம் எதிலும் இல்லை.

இது உங்களுக்கு இரண்டு விதமான இழப்புகளை ஏற்படுத்துகிறது. முதலாவது, சூழல் (context) தொடர்பான இழப்பு. ஒவ்வொரு பணியின் தொடக்கத்திலும் ஒரு முகவர் (agent) வாசிக்கும் கோப்பிற்கு, ஒவ்வொரு முறையும் நீங்கள் கட்டணம் செலுத்த வேண்டியுள்ளது. மீண்டும் மீண்டும் வரும் நிறுவல் பகுதி, ஒரு குறிப்பிட்ட அளவுள்ள context window-க்கு தேவையற்ற சுமையாகும். அந்த window-ஐ நிர்வகிப்பது ஒரு தனித்திறமை, இது managing the context window in Claude Code பகுதியில் விளக்கப்பட்டுள்ளது. சுருக்கமாகச் சொன்னால், தானாகவே ஏற்றப்படும் எந்தவொரு தகவலும் களஞ்சியத்தில் (repository) மிக உயர்ந்த மதிப்புடையதாக இருக்க வேண்டும்.

இரண்டாவது இழப்பு இன்னும் மோசமானது. ஒரே தகவலின் இரண்டு பிரதிகள் காலப்போக்கில் மாறுபடும். README-ல் சேவை 8080-ல் இயங்குகிறது என்று இருக்கும், DESIGN.md-ல் இன்னும் 3000 என்று இருக்கும். முகவரால் எதை நம்புவது என்று தீர்மானிக்க முடியாது, எனவே அது ஏதோ ஒன்றைத் தேர்ந்தெடுத்து அதற்கேற்ப குறியீட்டை (code) எழுதிவிடும். எப்போதாவது தவறாக இருக்கும் ஒரு கோப்பு, எப்போதும் சரியாக இருக்கும் கோப்பைப் போலவே அதே நம்பிக்கையுடன் அணுகப்படுகிறது.

இதனைச் சோதிப்பது எளிது. ஒரு பத்தி README-ல் இருக்கத் தகுதியானது என்றால், அதை DESIGN.md-லிருந்து நீக்கிவிடுங்கள். எஞ்சியிருப்பது நீங்கள் ஒரு code review-ல் வாய்மொழியாகச் சொல்லக்கூடிய பகுதியாக இருக்க வேண்டும்; அதாவது "நாங்கள் ஏற்கனவே அதை முயற்சி செய்துவிட்டோம்" என்று தொடங்கும் பகுதியாக இருக்க வேண்டும்.

இந்தக் கோப்பு சரியாகச் செயல்படுகிறதா என்பதை எப்படி அறிவது?

இதற்கென பிரத்யேகமான linter எதுவும் இல்லை. ஆனால், ஒரு நிமிடத்தில் நீங்கள் செய்யக்கூடிய ஒரு சோதனை உள்ளது.

ஒரு மாறாத விதியை (invariant) மீறும் வகையில் ஏஜெண்டிற்கு ஒரு பணியைக் கொடுங்கள். உதாரணமாக, "பழைய வரிசைகளை expired என மாற்றும் ஒரு background job-ஐச் சேர்க்கவும்" என்று கூறலாம். இந்தக் கோப்பு தனது பணியைச் சரியாகச் செய்கிறது என்றால், எந்தவொரு code-ஐயும் எழுதுவதற்கு முன்பே ஏஜெண்ட் அதைத் தெரிவிக்கும்: அந்த job queue.enqueue() வழியாகவே எழுத வேண்டும் என்று அது சொல்ல வேண்டும், ஏனெனில் நேரடியாக எழுதினால் audit log விடுபட்டுவிடும். அது நேரடியாக database connection-ஐத் திறந்து எழுதினால், இரண்டு விஷயங்களில் ஒன்று உண்மையாக இருக்க வேண்டும். ஒன்று, அந்தக் கோப்பு வாசிக்கப்படவே இல்லை, அல்லது அந்த invariant விதியானது விவாதிக்கும் அளவிற்குத் தளர்வாக எழுதப்பட்டுள்ளது.

Token எண்ணிக்கையையும் கவனியுங்கள், ஏனெனில் ஒவ்வொரு முறையும் இந்தக் கோப்பு ஏற்றப்படுகிறது. DESIGN.md-ஐச் சேர்த்த பிறகு context பயன்பாடு அதிகரித்து, பதில்களில் முன்னேற்றம் இல்லை என்றால், ஏஜெண்டிற்கு ஏற்கனவே தெரிந்த விஷயங்களைத்தான் அந்தக் கோப்பு சுமந்து கொண்டிருக்கிறது என்று அர்த்தம். Claude Code-ல் token counters-ஐ வாசித்தல் என்ற பகுதி அந்த budget எங்கே செலவாகிறது என்பதைக் காட்டுகிறது.

உங்கள் laptop-ஐ விட, ஒரு server-ல் ஏஜெண்ட் இயங்கும்போது இது மிக முக்கியமானது. VPS-ல் tmux உடன் கூடிய Claude Code workspace அமைப்பில் இருப்பது போல, நீண்ட நேரம் இயங்கும் session-ல் இருக்கும் ஏஜெண்டிற்கு முந்தைய நாள் உரையாடல்கள் நினைவில் இருக்காது. repository தான் அதன் நினைவகம். நீங்கள் chat-ல் விளக்கி, ஆனால் commit செய்யாத அனைத்தும் அடுத்த session-ல் அழிந்துவிடும்; அந்த விளக்கங்கள் நிலைத்திருக்க DESIGN.md கோப்பே சரியான இடம்.

நீங்கள் விவாதிக்கும் முடிவுகளிலிருந்து தொடங்குங்கள்

முதல் பதிப்பை உருவாக்க இருபது நிமிடங்கள் ஆகும். ஒரு reviewer "இல்லை, நாங்கள் இதை இங்கே வேறு விதமாகச் செய்கிறோம்" என்று குறிப்பிட்ட கடைசி சில pull requests-ஐத் திறந்து பாருங்கள். அத்தகைய ஒவ்வொரு கருத்தும் எழுதப்படாத ஒரு விதியாகும் (invariant). ஒரு மனிதரை விட, ஒரு agent அதே தவறை மிக வேகமாகவும் அடிக்கடிவும் செய்யக்கூடிய இடங்கள் இவை. ஒரு செயல் தோல்வியடையும் போது இந்த கோப்பில் அதைச் சேர்க்கவும்; கால அட்டவணைப்படி செய்ய வேண்டாம். சாதாரண development workflow-ல் agents எங்கே பொருந்தும் என்பதை நீங்கள் இன்னும் கண்டறிந்து கொண்டிருக்கிறீர்கள் என்றால், 2026-ம் ஆண்டிற்கான AI agents கற்றல் வழிகாட்டி உங்களுக்கு அடுத்த கட்டமாக பயனுள்ளதாக இருக்கும்.

FAQ

DESIGN.md ஒரு அதிகாரப்பூர்வமான தரநிலையா (standard)?

AGENTS.md போல இது ஒரு அதிகாரப்பூர்வமான தரநிலை அல்ல. AGENTS.md-க்கு agents.md என்ற தளம் உள்ளது, 60,000-க்கும் மேற்பட்ட open source திட்டங்கள் இதைப் பயன்படுத்துகின்றன, மேலும் Linux Foundation-ன் ஒரு பகுதியான Agentic AI Foundation-ன் மேற்பார்வையில் இது உள்ளது. DESIGN.md ஒரு வெளியிடப்பட்ட specification-ஐக் கொண்டுள்ளது, ஆனால் அதற்கு நடுநிலையான பொறுப்பாளர் எவரும் இல்லை. Google ஏப்ரல் 21, 2026 அன்று ஒரு வரைவு specification-ஐ open-source செய்தது; இது google-labs-code/design.md repository-ல் Apache-2.0 உரிமத்தின் கீழ் உள்ளது. அக்டோபர் 2026 நிலவரப்படி, இது alpha நிலையில் உள்ளது மற்றும் தொடர்ந்து மேம்படுத்தப்பட்டு வருகிறது. இது நிறங்கள், எழுத்துருக்கள் (typography), layout மற்றும் components போன்ற visual identity-ஐ விவரிக்கிறது. DESIGN.md-க்கு முதல்நிலை ஆதரவும் உள்ளது: Vercel, Nuxt, Atlassian மற்றும் Resend உள்ளிட்ட பதினொரு நிறுவனங்கள் மற்றும் திட்டங்கள் இதை வெளியிடுகின்றன. அக்டோபர் 27, 2026 நிலவரப்படி, பொதுத் தளங்களிலிருந்து எடுக்கப்பட்ட மேலும் 84 கோப்புகளைக் கொண்ட ஒரு சமூகத் தொகுப்பும் உள்ளது. மாறிலிகள் (invariants) மற்றும் நிராகரிக்கப்பட்ட மாற்றுகள் (rejected alternatives) குறித்த backend கோப்பிற்கு, இதை நீங்கள் இப்போதே பின்பற்றக்கூடிய மற்றும் தாராளமாக விரிவாக்கக்கூடிய ஒரு மரபாகக் (convention) கருதுங்கள், ஏனெனில் அந்த section பெயர்களை எந்த ஒரு specification-உம் கட்டுப்படுத்தவில்லை.

DESIGN.md-ஐ AGENTS.md-ன் ஒரு பகுதியாக மட்டும் வைத்திருக்கலாமா?

சிறிய repository-களுக்கு, ஆம். ஒரு கோப்பை agent நிச்சயமாகப் படிக்கும், இரண்டு கோப்புகள் இருந்தால் ஒன்றைப் புறக்கணிக்க வாய்ப்புள்ளது. AGENTS.md-ஐ எளிதாகப் பார்க்க முடியாத நிலை ஏற்படும்போதோ அல்லது இரண்டு பகுதிகளும் வெவ்வேறு வேகத்தில் மாறுகின்றன என்று நீங்கள் உணரும்போதோ அவற்றை இரண்டாகப் பிரிக்கவும். build மாறும்போது AGENTS.md மாறும். ஒரு முடிவு மாறும்போது DESIGN.md மாறும்; இது அரிதாகவே நடக்கும், ஆனால் அதிக முக்கியத்துவம் வாய்ந்தது. நீங்கள் பிரிக்கும்போது, AGENTS.md-ல் ஒரு வரியைச் சேர்த்து, code-ஐ மாற்றும் முன் DESIGN.md-ஐப் படிக்குமாறு agent-க்கு அறிவுறுத்தவும், ஏனெனில் எல்லா கருவிகளும் root-ல் உள்ள அனைத்து markdown கோப்புகளையும் ஏற்றுவதில்லை (load).

DESIGN.md, architecture decision record-லிருந்து எவ்வாறு வேறுபடுகிறது?

ADR (architecture decision record) என்பது ஒரு முடிவின் தேதியிடப்பட்ட பதிவு. ஆரோக்கியமான திட்டங்களில் இதுபோன்ற டஜன் கணக்கான பதிவுகள் ஒரு கோப்புறையில் இருக்கும். அது ஒரு வரலாறு; வரலாற்றை ஏற்றுவது அதிகச் செலவுடையது, ஏனெனில் எவை இன்னும் நடைமுறையில் உள்ளன என்பதைக் கண்டறிய agent அவை அனைத்தையும் படிக்க வேண்டியிருக்கும். DESIGN.md என்பது தற்போதைய நிலை; ஒவ்வொரு பணியின் போதும் முழுமையாகப் படிக்கப்படும் வகையில் இது எழுதப்படுகிறது. நீங்கள் ஏற்கனவே ADR-களை எழுதுகிறீர்கள் என்றால், இரண்டையும் வைத்திருங்கள். ADR எப்போது, என்ன முடிவு எடுக்கப்பட்டது என்பதைக் கூறுகிறது. DESIGN.md இன்று எது உண்மை என்பதைக் கூறுகிறது, மேலும் agent-க்கு நீங்கள் சுட்டிக்காட்ட வேண்டியது இதையே.

DESIGN.md எவ்வளவு நீளமாக இருக்க வேண்டும்?

ஒவ்வொரு முறையும் தயக்கமின்றி ஏற்றும் அளவுக்குச் சுருக்கமாக இருக்க வேண்டும். வெளியிடப்பட்ட உதாரணங்கள் நீளமாக உள்ளன, ஏனெனில் அவை முழுமையான visual language-ஐக் குறிப்பிடுகின்றன: அக்டோபர் 2026 நிலவரப்படி, Nuxt கோப்பு சுமார் 2,000 சொற்களையும், Vercel கோப்பு சுமார் 6,000 சொற்களையும் கொண்டுள்ளன. ஒரு backend service-க்கு பொதுவாக இதைவிட மிகக் குறைவே தேவைப்படும். ஒரு பக்கத்தில் தொடங்கி, ஒரே ஒரு வாக்கியம் மூலம் தடுத்திருக்கக்கூடிய ஒரு தவறை agent செய்யும்போது மட்டும் அதை விரிவாக்குங்கள். நீளம் ஒரு அளவுகோல் அல்ல. ஒவ்வொரு வரியும் agent தவறாகச் செய்யக்கூடிய ஒரு விஷயமாக இருக்க வேண்டும்.