Cursor एजेंट मोड ट्यूटोरियल: GPT-5.6 Sol के साथ REST API बनाना

Cursor क्या है?

Cursor की शुरुआत VS Code के रूप में हुई जिसमें एआई फीचर्स जोड़े गए थे, और ऊपर-ऊपर आज भी वैसा ही दिखता है। एडिटर, फ़ाइल ट्री, टर्मिनल, एक्सटेंशन—सब परिचित। 

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

यदि आप Cursor की नवीनतम क्षमताओं को और खंगालना चाहते हैं, तो हमारे Cursor Automations और Cursor SDK ट्यूटोरियल पढ़ने की सलाह दूँगा।

GPT-5.6 क्या है?

GPT-5.6 OpenAI की नवीनतम मॉडल पीढ़ी है, और यह एक मॉडल नहीं बल्कि तीन हैं: Sol, Terra, और Luna। ये नाम तीन अलग-अलग क्षमता टियर्स हैं, जो पुराने "Instant" लेबल की जगह लेते हैं।

संक्षेप में परिवार इस प्रकार है:

• Sol फ़्लैगशिप है और तीनों में सबसे मज़बूत। केवल इसी टियर में नया max reasoning effort और ultra मोड अनलॉक होते हैं, और कोडिंग, बायोलॉजी, तथा साइबरसिक्योरिटी में यहीं सबसे बड़े लाभ दिखते हैं।

• Terra रोज़मर्रा का डिफ़ॉल्ट है। OpenAI इसे GPT-5.5 के मुकाबले लगभग आधी कीमत पर प्रतिस्पर्धी बताता है।

• Luna तेज़, सस्ता टियर है जो हाई-वॉल्यूम या कम लैटेंसी वाले काम के लिए है, और अपनी कीमत से ज़्यादा सक्षम महसूस होता है।

कोडिंग वॉकथ्रू के लिए Sol ही मायने रखता है, इसलिए हम यहीं उसी का उपयोग कर रहे हैं। Sol में दो नई सेटिंग्स हैं, और जानना ज़रूरी है कि आप वास्तव में किसे छुएँगे। max xhigh से ऊपर का reasoning-effort स्तर है जो एक एजेंट को किसी कठिन समस्या पर अधिक समय देता है, और Cursor में आप इसी सीढ़ी की सबसे ऊँची पायदान सेट करते हैं। ultra, जो काम को समानांतर सबएजेंट्स में बाँटता है, OpenAI के सर्वश्रेष्ठ बेंचमार्क नंबर (Terminal-Bench 2.1 पर 91.9%) दिखाता है, लेकिन यह केवल Codex और API में चलता है, इसलिए Cursor पिकर में नहीं मिलेगा।

पूरा बेंचमार्क टेबल और तीन-टियर प्राइसिंग के लिए हमारा GPT-5.6 Sol, Terra, और Luna गाइड देखें।

Cursor में GPT-5.6 Sol तक कैसे पहुँचें और कॉन्फ़िगर करें

GPT-5.6 Sol Cursor के मॉडल पिकर में उपलब्ध है, और एक बात पहले से जान लें: Cursor के अन्य हालिया फ्रंटियर मॉडल्स की तरह, Sol केवल Cursor के Max Mode में चलता है। यानी यह फुल कॉन्टेक्स्ट विंडो और सभी टूल्स का उपयोग करता है, और प्रति रिक्वेस्ट के बजाय उपयोग के आधार पर बिलिंग होती है, इसलिए लंबे रन के दौरान टोकन खर्च पर नज़र रखें।

मॉडल चुनने के लिए:

1. एजेंट पैनल खोलें Cmd+L (Mac) या Ctrl+L (Windows/Linux) से।
2. इनपुट क्षेत्र के नीचे Model बटन पर क्लिक करें (वह छोटे आइकन के पास वर्तमान मॉडल का नाम दिखाता है)।
3. यदि Auto ऑन है तो उसे ऑफ कर दें।
4. सूची में GPT-5.6 Sol ढूँढें और उसके पास Edit पर क्लिक करें।
5. दाईं ओर एक पैनल खुलेगा, जहाँ आप कॉन्टेक्स्ट विंडो, reasoning स्तर, और फास्ट टॉगल स्वतंत्र रूप से सेट कर सकते हैं।

सही reasoning effort चुनना

Sol चुनना मॉडल चुनना है; reasoning effort तय करता है कि किसी कार्य पर यह कितनी मेहनत से सोचेगा। आप इनमें से चुन सकते हैं:

• None
• Low
• Medium
• High
• Extra High
• Max

None और Low सबसे तेज़ और सस्ते हैं—ऑटोकंप्लीट या ऐसे मैकेनिकल रिफ़ैक्टर के लिए ठीक जहाँ आपको पहले से पता है क्या चाहिए। 

High और Extra High में अधिक समय लगता है क्योंकि ये पहले समस्या पर सोचते हैं; और यह फ़र्क सबसे ज़्यादा तब दिखता है जब आप एजेंट से ऐसी योजना बनाने को कह रहे हों जो कई फ़ाइलों में फैली हो या ऐसी डिबगिंग जहाँ स्रोत तुरंत स्पष्ट न हो। 

Max Extra High से ऊपर बैठता है और एक एजेंट को कठिन समस्या पर काम करने के लिए सबसे अधिक समय देता है। Sol का ultra मल्टी-एजेंट मोड केवल Codex और API में है, इसलिए Cursor के पिकर में नहीं दिखेगा।

यदि आप GPT-5.5 से आ रहे हैं, तो एक चेतावनी: स्तर सीधे मैप नहीं होते। OpenAI की अपनी सलाह है कि किसी परिचित कार्य पर अपने पुराने स्तर से एक कदम नीचे से शुरू करें और केवल तभी ऊपर करें जब परिणाम को उसकी ज़रूरत लगे। मैंने नीचे वैसा ही किया है, इसलिए कुछ स्टेप्स 5.5 ट्यूटोरियल के समकक्ष से कम effort पर चलते हैं।

नीचे दिए गए हैंड्स-ऑन स्टेप्स में, मैं हर कार्य के लिए उपयुक्त reasoning स्तर सुझाऊँगा, लेकिन आप स्वयं भी अलग सेटिंग्स आज़माएँ और देखें आउटपुट कैसे बदलता है।

कॉन्टेक्स्ट विंडो आकार और स्पीड मोड चुनना

आप 272K और 1M कॉन्टेक्स्ट विंडो में से चुन सकते हैं, और Fast मोड ऑन कर सकते हैं जिससे लगभग 1.5x स्पीड पर टोकन जेनरेट होते हैं, लगभग 2.5x क्रेडिट लागत पर। इंटरैक्टिव आगे-पीछे में जहाँ आप रिस्पॉन्स का इंतज़ार करते हैं, Fast अक्सर फ़ायदेमंद है। लंबे बैकग्राउंड टास्क में जहाँ आपने कुछ सौंप दिया है और यह चलते समय आप और काम कर रहे हैं, इसे ऑफ रखना ठीक है।

Cursor सेटअप करना

आइए Cursor में प्रोजेक्ट सेटअप करें।

पूर्वापेक्षाएँ और शुरुआती कॉन्फ़िगरेशन

GPT-5.6 Sol के लिए पेड Cursor प्लान (Pro या उससे ऊपर) चाहिए, और क्योंकि Sol Max Mode में चलता है, आपके अकाउंट पर usage-based प्राइसिंग सक्षम होना आवश्यक है। Python 3.11+ इस प्रोजेक्ट के लिए एकमात्र अन्य लोकल डिपेंडेंसी है। यदि Cursor अभी तक इंस्टॉल नहीं है, तो cursor.com से ले लें, साइन-इन करें, और फिर टर्मिनल से:

mkdir budget-api && cd budget-api
git init
cursor .

एजेंट पैनल दाईं ओर है, और बाईं ओर फ़ाइल एक्सप्लोरर अभी कोई फ़ाइल नहीं दिखाता—यही सही शुरुआती स्थिति है, ताकि एजेंट संरचना बना सके।

Cursor की एआई सरफ़ेस पर नेविगेट करना

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

इनलाइन कंप्लीशन बैकग्राउंड ऑटोकंप्लीट लेयर है। जैसे ही आप टाइप करते हैं, ग्रे सुझाव आस-पास के संदर्भ के आधार पर दिखते हैं, और आप Tab से उन्हें स्वीकार करते हैं। इसे आप कॉल नहीं करते; यह बस दिखता है। जब आप हाथ से कोड लिख रहे हों और मॉडल से बिना प्रवाह तोड़े कीस्ट्रोक्स कम करवाना चाहते हों, तब यही सही मोड है।

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

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

AGENTS.md के साथ प्रोजेक्ट-विशिष्ट गाइडेंस देना

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

AGENTS.md का काम ही यही है: एजेंट के लिए README जहाँ आप वह सब लिखते हैं जो आपको तो स्पष्ट है, पर मॉडल के लिए अदृश्य। AGENTS.md 2025 में OpenAI पहल के रूप में शुरू हुआ और अब एजेंट इंस्ट्रक्शन फ़ाइलों के लिए क्रॉस-टूल मानक है (Linux Foundation के Agentic AI Foundation का हिस्सा, Anthropic के MCP के साथ), इसलिए इसे एक बार ठीक से सीख लेना हर जगह काम आता है।

प्रोजेक्ट रूट पर AGENTS.md नाम की फ़ाइल बनाएँ और निम्नलिखित लिखें ताकि आपका टूल स्टैक, कोडिंग कन्वेंशन, और सीमाएँ तय हो जाएँ:

# AGENTS.md

## Stack
Python 3.11, FastAPI, SQLModel, SQLite (via aiosqlite), pytest, httpx

## Conventions
- All endpoints under /api/v1/
- Pydantic models in app/models.py
- Database logic in app/database.py
- Route handlers in app/routers/
- Type hints required on all function signatures
- Explicit imports only, no wildcards

## Boundaries
- Do not delete or modify any file in tests/ without asking first
- Do not change the DATABASE_URL; it reads from .env
- Never touch pyproject.toml dependencies without showing the diff first

## Verification
Before considering any task complete:
  pytest tests/ -v
  ruff check .
Both must pass.

सीमाओं वाला सेक्शन लोग सबसे ज़्यादा छोड़ देते हैं, और वही सबसे महत्वपूर्ण भी है। इसके बिना, एजेंट कभी-कभी "मदद" के लिए ऐसी चीज़ें फिर से व्यवस्थित या साफ़ करने लगते हैं जिन्हें आपने छूने को कहा ही नहीं। मॉडल को बताना कि क्या ऑफ-लिमिट्स है, उतना ही उपयोगी है जितना बताना कि क्या करना है।

AGENTS.md क्रॉस-टूल मानक है, लेकिन यदि आप Cursor-नेटिव समकक्ष चाहते हैं जो स्कोप्ड .mdc फ़ाइलों के जरिए यही काम करता है, तो हमारा Cursor Rules ट्यूटोरियल एक Python वेब प्रोजेक्ट के लिए उनका सेट बनाना समझाता है।

GPT-5.5 के साथ बजट ट्रैकर API बनाना

प्रोजेक्ट एक REST API है जो पर्सनल बजट एंट्रीज़ को ट्रैक करता है। आप एंट्री बना सकते हैं, वैकल्पिक कैटेगरी फ़िल्टरिंग के साथ उन्हें लिस्ट कर सकते हैं, डिलीट कर सकते हैं, और मासिक खर्च का सारांश निकाल सकते हैं। 

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

स्टेप 1: प्रोजेक्ट संरचना स्कैफ़ोल्ड करना

एजेंट पैनल खोलें और कुछ भी भेजने से पहले reasoning effort High पर सेट करें। एजेंट जो प्लान कोड लिखने से पहले बनाता है, उसकी उपयोगिता उसकी reasoning पर निर्भर है—यहाँ हल्का जवाब आगे चलकर स्ट्रक्चरल फैसलों में उलझन बनता है। आगे बढ़ें और यह पहला प्रॉम्प्ट भेजें:

Set up a FastAPI project for a budget tracker API using SQLModel with 
async SQLite. Structure it with separate files for models, database, and 
routes under an app/ directory. Set up pyproject.toml with uv, install 
dependencies, and create a main.py that starts the app.

Before writing any code, show me the planned directory structure 
and wait for my approval.

आख़िरी पंक्ति आपके सभी नॉन-ट्रिवियल एजेंट प्रॉम्प्ट्स में रखना फ़ायदेमंद है। एक्ज़ीक्यूशन से पहले प्लान माँगना शायद 15 सेकंड की रीडिंग लेता है, पर इससे आप स्ट्रक्चर के फ़ैसले शुरू में ही पकड़ लेते हैं, इससे पहले कि वे दर्जन भर फ़ाइलों में फैलें। 

GPT-5.6 Sol High reasoning पर ऐसे प्लान देता है जो सच में उपयोगी हों, न कि अस्पष्ट सारांश, और अब स्ट्रक्चर की समीक्षा करना बाद में फिर से व्यवस्थित करने से कहीं तेज़ है।

एजेंट प्रोजेक्ट लेआउट प्रस्तावित करता है और एक भी फ़ाइल लिखने से पहले स्वीकृति का इंतज़ार करता है।

जब आप कुछ ऐसा जवाब देते हैं जैसे "ठीक लग रहा है, आगे बढ़ें", तो एजेंट बिल्ड शुरू कर देता है। आप बाईं ओर फ़ाइल ट्री को रीयल-टाइम में भरते देखेंगे, जबकि नीचे टर्मिनल में uv पैकेज इंस्टॉल दिखाता है।

एजेंट ने स्कैफ़ोल्ड के हिस्से के रूप में pyproject.toml बना दी, और फ़ाइल सामग्री नए ऐडिशन के रूप में दिख रही है।

स्कैफ़ोल्ड पूरा होने के बाद, आगे बढ़ने से पहले app/models.py और app/database.py खोलकर एक मिनट दें। पक्का करें कि BudgetEntry मॉडल में कम से कम ये फ़ील्ड हों: id, amount, description, category, और date, और database.py async SQLite इंजन सामान्य तरीके से सेट करता हो। 

यदि कुछ गलत लगे, तो आगे बढ़ने के बजाय अगले संदेश में बता दें। इस चरण पर सुधार सस्ते हैं; बीस फ़ाइलें बदल जाने के बाद नहीं।

स्टेप 2: मुख्य एंडपॉइंट लागू करना

effort को High पर रखें, या पहले Medium आज़माएँ, क्योंकि Sol Medium पर वह मल्टी-फ़ाइल समन्वय कर लेता है जिसके लिए GPT-5.5 पर High चाहिए था। यह इम्प्लिमेंटेशन प्रॉम्प्ट भेजें:

Implement endpoints for budget entries under /api/v1/entries/. Include:
- POST /api/v1/entries/ to create a new entry, returning 201
- GET /api/v1/entries/ to list all entries, with an optional ?category= filter
- DELETE /api/v1/entries/{id} to delete an entry, returning 404 if not found

Use typed Pydantic response models and dependency injection for the DB session.
After implementing, start the app and confirm the /docs endpoint loads.

एजेंट models.py, database.py, routers/entries.py, और main.py को एक समन्वित पास में छूता है। जैसे ही यह हर फ़ाइल पूरी करता है, Cursor एडिटर में नया कंटेंट हाइलाइट कर दिखाता है ताकि आप स्वीकार करने से पहले समीक्षा कर सकें। आपको हर बदली फ़ाइल के नीचे Undo/Keep कंट्रोल दिखाई देंगे।

स्क्रीनशॉट में एजेंट द्वारा इम्प्लिमेंट किए जाने के बाद entries.py राउटर दिख रहा है, साथ ही एजेंट की पुष्टि कि सर्वर शुरू हुआ और /docs एंडपॉइंट सही से लोड हुआ। 

इम्प्लिमेंटेशन स्वीकार होने और सर्वर चलने के बाद, अपने ब्राउज़र में http://localhost:8000/docs खोलें और पक्का करें कि सब सही से वायर्ड है।

FastAPI के ऑटो-जनरेटेड डॉक्यूमेंट्स /docs पर, जहाँ तीनों एंडपॉइंट सही तरह से रजिस्टर दिख रहे हैं। 

स्टेप 3: कैटेगरी वैलिडेशन जोड़ना

इस तीसरे चरण के लिए, आप मॉडल reasoning को Low या Medium तक घटा सकते हैं। एक enum और दो टेस्ट जोड़ना इतना आत्म-समाहित और पूर्वानुमेय है कि इस पर अतिरिक्त deliberation की ज़रूरत नहीं। 

अभी API किसी भी स्ट्रिंग को कैटेगरी के रूप में स्वीकार कर रहा है, जिससे डेटा जल्दी असंगत हो जाएगा। इसे ठीक करें:

Budget entries should only accept these categories: 
food, transport, housing, entertainment, health, other.

Reject any entry with an invalid category using a 422 status and a clear 
error message. Use a Python Enum for the category type. 
Add tests for both a valid category submission and an invalid one in tests/test_entries.py.

एजेंट models.py में एक कैटेगरी enum जोड़ देगा और Pydantic मॉडल को इसे उपयोग करने के लिए अपडेट करेगा। क्योंकि Pydantic enum के खिलाफ़ ऑटोमैटिक वैलिडेशन करता है, अमान्य कैटेगरी रूट हैंडलर के चलने से पहले ही रिजेक्ट हो जाती हैं।

इसके साथ दो टेस्ट लिखे जाने चाहिए: एक जो वैध कैटेगरी के सही से सेव होने की पुष्टि करे, दूसरा जो अमान्य कैटेगरी पर 422 आने की पुष्टि करे।

@ रेफ़रेंस का उपयोग

इन बदलावों को स्वीकार करने के बाद, Cursor की @ कॉन्टेक्स्ट सुविधा से एक त्वरित वेरिफ़िकेशन सवाल पूछें:

@app/models.py Does the CategoryEnum cover all six categories I listed?

एजेंट पैनल में @ टाइप करने पर फ़ाइल पिकर खुलता है, और जैसे ही आप app/models.py चुनते हैं, उस फ़ाइल की सामग्री सीधे प्रॉम्प्ट में शामिल हो जाती है—एजेंट को इसे खोजने या पाथ पर अनुमान लगाने की ज़रूरत नहीं पड़ती।

स्टेप 4: मासिक सारांश एंडपॉइंट बनाना

यहाँ वापस High पर लौटें। एग्रीगेशन क्वेरी में फ़िल्टरिंग, ग्रुपिंग, और रेस्पॉन्स मॉडल डिज़ाइन पर साथ में सोचना पड़ता है—इनमें से किसी एक में गलती का मतलब तीनों फ़ाइलों को फिर छूना होगा। कोर CRUD के काम करने के बाद, सारांश एंडपॉइंट जोड़ें:

Add a GET /api/v1/entries/summary endpoint that accepts month (1-12) and year as query parameters. 
It should return total spending per category for that month and an overall total. 
Use a typed Pydantic response model. 
If no entries exist for the requested month, return an empty summary with zero totals rather than a 404.

यह अधिक दिलचस्प डेटाबेस कार्य है क्योंकि इसमें साधारण select-all की जगह फ़िल्टर्ड क्वेरी के साथ एग्रीगेशन चाहिए। देखें एजेंट database.py में क्वेरी कैसे स्ट्रक्चर करता है; इसे SQLModel के क्वेरी इंटरफ़ेस का उपयोग करना चाहिए, न कि रॉ SQL का, और परिणाम models.py में परिभाषित रेस्पॉन्स मॉडल पर साफ़-सुथरा मैप होना चाहिए।

बदलाव स्वीकार करने के बाद, इस एंडपॉइंट के लिए आप स्वयं test_entries.py में एक टेस्ट लिखें। किसी एक माह में दो एंट्री बनाएँ, उसी माह के लिए सारांश एंडपॉइंट कॉल करें, और टोटल्स मैच होने का एसर्ट करें। इसे एजेंट से न लिखवाकर खुद लिखना टेस्ट क्लाइंट और फ़िक्स्चर्स की रचना से परिचित होने का अच्छा तरीका है।

test_entries.py फ़ाइल में एजेंट-लिखित कैटेगरी वैलिडेशन टेस्ट के साथ मैन्युअल test_monthly_summary फ़ंक्शन दिख रहा है। 

स्टेप 5: वैलिडेशन लूप चलाना

Low या Medium reasoning यहाँ ठीक है—टेस्ट चलाना और लिंट इश्यू ठीक करना रिएक्टिव काम है; एजेंट एरर आउटपुट पढ़कर लक्षित फिक्स लगाता है, न कि कोई आर्किटेक्चरल फ़ैसला करता है। टेस्टिंग एजेंट को सौंपें:

Run pytest tests/ -v and fix any failing tests. 
Do not modify test assertions to make them pass, fix the implementation instead.
Once all tests pass, run ruff check . and fix any linting issues.

एजेंट पैनल में स्ट्रीम होते pytest आउटपुट पर नज़र रखें। 

यदि कुछ फेल होता है, तो एजेंट ट्रेसबैक पढ़ता है, पहचानता है कि किस फ़ाइल में समस्या आई, और फिक्स लागू करता है—सब एक ही सेशन में। आपको एरर कॉपी-पेस्ट कर नया संदेश भेजने की आवश्यकता नहीं; पूरा डिबगिंग और फिक्सिंग लूप एक सतत थ्रेड में होता है।

स्क्रीनशॉट में एजेंट पूरे वैलिडेशन लूप के बाद रिपोर्ट करता दिख रहा है। इस केस में, ruff चेक में इंटरप्रेटर रेज़ोल्यूशन इश्यू आया जो लोकल मशीन पर pyenv/.python-version मिसमैच से हुआ—यह कोड की समस्या नहीं थी। 

यह ध्यान देने योग्य है: एजेंट को कोड से असंबंधित एक एनवायरनमेंट इश्यू मिला, उसने उसके कारण पर विचार किया, और बिना कहे वर्कअराउंड ढूँढ लिया। टूल फ़ेल्यर्स के बीच ऐसे सन्दर्भ-सचेत समस्या-समाधान में ही GPT-5.6 Sol पहले के मॉडेल्स से आगे निकलता है।

हर वैलिडेशन प्रॉम्प्ट में "टेस्ट assertions को पास करवाने के लिए न बदलें" जैसी हिदायत शामिल करना भी समझदारी है। इसके बिना, एजेंट कभी-कभी आसान रास्ता चुन लेते हैं और वास्तविक व्यवहार ठीक करने के बजाय टेस्ट को कम सख्त बना देते हैं।

स्टेप 6: कोड रिव्यू पास

यह भेजने से पहले reasoning वापस High पर सेट करें, या चाहें तो Extra High/Max पर—ताकि Sol ऐसे किनारों पर भी मेहनत कर ले जिन्हें एक High पास ऊपर-ऊपर छोड़ दे। इस स्टेप पर उथली reasoning आपको झूठा भरोसा देती है; आप चाहते हैं कि मॉडल सच में सभी संभावित मुद्दों पर काम करे, न कि केवल सबसे स्पष्ट पैटर्न मिलाए। 

प्रोजेक्ट को पूरा मानने से पहले, एजेंट से रिव्यू कराएँ:

Review the current codebase and report on:
1. Query params or path params that are missing validation
2. Database sessions that might not be closing properly
3. Endpoints returning incorrect HTTP status codes
4. Any places where user input reaches the database without going 
   through the ORM

Do not make any changes yet. List each issue with file and line number.

एजेंट ने पाया कि DELETE /api/v1/entries/{entry_id} सही तरह से 204 और 404 कोड लौटाता है (file:line रेफ़रेंस के साथ), कि GET रूट्स उचित 200 डिफ़ॉल्ट्स पर निर्भर हैं, और यह भी पुष्ट किया कि कोई यूज़र इनपुट ORM के बाहर सीधे डेटाबेस तक नहीं पहुँच रहा।

सूची की समीक्षा करने के बाद, फ़िक्स लागू कराने के लिए फ़ॉलो-अप भेजें:

Apply the fixes for the status code issues and the session handling. 
Skip any rate-limiting suggestions, that's out of scope for this version.
Run the tests again after applying.

स्टेप 7: README और CI वर्कफ़्लो

प्रोजेक्ट को सही तरीके से समेटने के लिए दो अंतिम टच। इन दोनों के लिए आप मॉडल का reasoning Low पर रख सकते हैं। README की रचना पूर्वानुमेय है, और CI YAML लगभग बॉयलरप्लेट, इसलिए यहाँ अधिक reasoning के लिए भुगतान करना बेकार है।

Write a README.md with setup instructions, a table of all endpoints (method, path, description), and example curl commands for each endpoint.

और फिर:

Create a .github/workflows/ci.yml that runs pytest and ruff on Python 3.11 for every push and pull request to main.

सातों स्टेप्स के बाद, प्रोजेक्ट संरचना कुछ यूँ दिखती है:

अंतिम विचार

हमने यहाँ एक छोटा API बनाया, लेकिन यह वर्कफ़्लो किसी भी चीज़ तक स्केल करता है। 

एजेंट के किसी फ़ाइल को छूने से पहले AGENTS.md तैयार रखें। किसी भी नॉन-ट्रिवियल काम पर एक्ज़ीक्यूशन से पहले प्लान माँगें। अपने प्रॉम्प्ट्स को स्टेज करें ताकि आपके पास नैचुरल चेकपॉइंट्स हों, न कि एक साथ एक विशाल डिफ़ रिव्यू करना पड़े।किसी विशेष फ़ाइल पर लक्षित सवाल करना हो तो @filename का उपयोग करें। और काम को पूरा मानने से पहले एक रिव्यू पास चलाएँ, क्योंकि लगभग हमेशा कुछ न कुछ पकड़ा जाता है।

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

reasoning स्तर पर एक अच्छा thumb rule: High का उपयोग आर्किटेक्चर फ़ैसलों, मल्टी-फ़ाइल समन्वय, और कुछ गैर-ज़ाहिर डिबगिंग के लिए करें; Medium या Low का उपयोग डॉक्यूमेंटेशन, बॉयलरप्लेट, और सिंगल-फ़ाइल एडिट्स के लिए करें जहाँ आप मॉडल से मूलतः टाइपिंग करवा रहे हैं। कोड रिव्यू और ऐसे स्थानों के लिए जहाँ गलती की कीमत thorough एजेंट रन से अधिक है, Extra High या Max पर विचार करें।