- Task/Plan Harness qo'llanishi -
1. Kirish
So'nggi rivojlantirish ishlarida LLM asosidagi kodlash vositalaridan foydalanish miqdori tobora ortib bormoqda. Men ham loyiha ishlash unumdorligini oshirish uchun Codex-dan foydalanishni boshladim. Dastlab, uni oddiy usulda ishlatdim. Kerakli ishni so'rov orqali ta'riflab, LLM tomonidan yozilgan natijalarni ko'rib chiqdim va yetishmayotgan jihatlarni qayta so'radim. Oddiy o'zgartirishlar yoki takroriy ishlar uchun bu usul bilan yetarlicha samarali bo'ldi.
Lekin ishning hajmi oshgan sari oddiy so'rov usulida cheklovlar bor edi. So'rovni uzun yozsangiz ham, LLM ishni umuman ishonchli boshqara olmadi va ish vaqti uzayganda, ilgari kelishilgan yoki oldingi o'zgartirish niyatlarini yo'qotish holatlari yuzaga keldi. Dastlab, men so'rovni batafsilroq yozsam muammoni hal qilgan deb o'yladim. Biroq aslida, muammo so'rovda emas, balki ishni boshqarish uchun tuzilma yetishmasligi bilan bog'liq edi.
Ushbu maqolada men LLM asosida rivojlantirish ishlarida boshdan kechirgan muammolarimni va buni hal qilish uchun Task/Plan harnesini qo'llash jarayonini tartibga solaman. Oddiygina harnes tushunchasini tushuntirishdan ko'ra, nima uchun zarur deb hisoblardim, qanday qoidalar yaratganim, haqiqiy ish jarayoni qanday o'zgarganiga e'tibor qaratildi.
2. Faqat so'rovlar yordamida ish yuritishda duch kelgan muammolar
Birinchi marta Codex-dan foydalanganda, bitta sessiyada iloji boricha ko'p ishni bajarmoqchi edim. Masalan, bir funksiya implementatsiya qilish kerak bo'lsa, talablarni uzun qilib izohlaydigan, tegishli fayllarni topishini ta'minlaydigan va implementatsiya va testga birlashtirilgan holda so'ragan edim. Qisqa ishlar uchun yaxshi edi, lekin ish uzoqlashganda sessiya ichida yig'ilgan kontekst juda ko'p bo'lib ketdi.
Eng avvalo his qilgan muammo kontekst oynasi edi. Ish hajmi ko'p va vaqt uzoqlashgani sari LLM oldingi ma'lumotlarni unutib yuboradi yoki oldindan belgilangan yo'nalishdan boshqa usulda kod yozishi mumkin. Faqatgina esga olib qolish darajasida emas, kod sifatida ham tebranishlar bo'lib turdi. Dastlab nisbatan aniq anglangan tuzilmani oxirgi qismlarga borgan sari taxminan taxmin qiladigan yoki allaqachon qaror qilingan ma'lumotlarni qayta o'zgartirish kabi muammolar paydo bo'ldi.
Ushbu holatda kontekst oynasini tozalash uchun sessiyani boshlash yana boshqa xarajatlarni olib keldi. Yangi sessiyada hozirgacha nima qilganimni, qaysi fayllarni o'zgartirganimni va qaysi qarorlarni qabul qilganimni yana tushuntirishim kerak bo'ldi. Izohni qisqartirsam, LLM noto'g'ri tushunardi va izohni uzaytirsam, yana kontekst tezda to'lib ketardi. Yakunida, ishlarni tezlashtirish uchun vositalardan foydalanayotgan bo'lsam-da, qaysidir paytdan boshlab ish jarayonini tiklash uchun vaqt sarflaydigan holatlarda bo'ldim.
Ikkinchi muammo LLM o'z-o'zidan noaniq ma'lumotlarga qaror qilishi edi. Rivojlantirish ishlarida foydalanuvchi qaroriga ehtiyojli nuqtalar ko'p. API shartnomasini qanday qo'yish, mavjud tuzilmani saqlab qolish, yangi abstraktsiyani yaratish, tasdiqni qayerga qadar amalga oshirish kabi muammolar mavjud. Agar so'rovda aniq ko'rsatilmagan qism bo'lsa, LLM savol bermay, o'zining mantiqiy tamoyillari asosida qaror qilib, implementatsiyaga o'tishi mumkin edi.
Muammo shundaki, bu qaror har doim mening niyatimga mos kelmas edi. Tashqi ko'rinishida gap bo'lib chiqarilgan kod yaxshi ko'rinishi mumkin, lekin haqiqiy loyiha yo'nalishidan yoki men o'ylagan doiradan chetga chiqishi mumkin edi. Bu vaqtda allaqachon o'zgartirilgan kodni tiklash, yana tushuntirish, yana ish qilishim kerak edi. Ba'zan, ishning o'zidan ko'ra, noto'g'ri ishni qaytarish xarajatlari ko'proq his qilingan paytlar bo'lgan.
3. Harnesni qo'llash sabablari
Ushbu muammoni hal qilish uchun harnes nomli tushunchani qo'llashni boshladim. Bunda harnes, LLMga har safar erkin ish berish o'rniga, ishni bajarganidan oldin va keyin bajarilishi kerak bo'lgan belgilangan jarayonlar va hujjatlarni belgilash usuli hisoblanadi. Ya'ni, so'rov bir marta so'rov bo'lsa, harnes ishni umumiy boshqarish uchun tuzilma kabi.
Men qo'llagan usul Task/Plan harnesi. Nomi bilan bir qatorda TASK.md va PLAN.md nomli ikki hujjat atrofida ishni boshqaradi. TASK.md hozirgi ishning birligi va holatini qayd etadi, PLAN.md esa batafsil implementatsiya rejalari, qarorlar va tasdiq mezonlarini qayd etadi. LLM foydalanuvchining so'rovini olganda, darhol implementatsiya qilmaydi, avval ishni kichik bir birliklarga ajratadi va reja tayyorlaydi.
Ushbu usulning asosiy jihati katta muammolarni bir marta hal qilmaslikdir. Ishni T-01, T-02 kabi kichik birliklarga ajratib, bir ish tugagach holatini qayd etib, compilejava sessiyasini boshlaydigan qilib qo'yildi. Sessiyani boshlaganida ham TASK.md va PLAN.md ga oldingi ish mazmuni va umumiy reja qoldi, shuning uchun keyingi sessiyada bu hujjatni o'qish orqali ishlashni davom ettirish mumkin.
4. Vazifa/Reja Hainesning asosiy tuzilishi
Hainesning fayl tuzilishi funksiya bo'yicha ish papkalariga asoslangan. Rootda vaqtinchalik TASK.md va PLAN.md joylashtirish ko'plab ishlarning aralashishiga olib keladi, shuning uchun funksiya bo'yicha faol ishlar va tugallangan ishlarni ajratish tuzilmasidan foydalandik.
.codex/tasks/active/<feature-slug>/TASK.md
.codex/tasks/active/<feature-slug>/PLAN.md
.codex/tasks/completed/<feature-slug>/TASK.md
.codex/tasks/completed/<feature-slug>/PLAN.mdTASK.md ish holatlari paneliga yaqin. Hozir qanday ishlayotganingiz, qaysi ish tugallandi, keyin nima qilish kerakligini qisqacha ko'rishingiz kerak. Aksincha, PLAN.md batafsil reja hujjatiga yaqin. Ish doirasi, chiqarilgan doira, qarorlar, amalga oshirish usuli, tasdiqlash usuli, holat logini o'z ichiga oladi.
# <Feature Name> Tasks
## Status
- Last updated: <YYYY-MM-DD>
- Current task: T-01
## Tasks
- [x] T-00. Create task baseline documents
- Plan reference: PLAN.md 0, 1, 3
- Status: Completed
- Clear after completion: Not required
- [ ] T-01. Implement first scoped change
- Plan reference: PLAN.md 2
- Status: Pending
- Clear after completion: RequiredDastlab, ishni hujjatga bo'lish jarayoni noqulay ko'rinishi mumkin. Biroq haqiqatan ham yozib ko'rsangiz, bu hujjatlar sessiyalar orasidagi bog'lovchi sifatida xizmat qiladi. LLM joriy sessiyadagi eslashga qodir bo'lmagan ma'lumotlar ham hujjatda yozilgan bo'lsa, qayta o'qib davom ettirishingiz mumkin. Odamlar ham hozirgi joyni tezda anglay olishadi.
5. Kontekst oynasi muammosini hal qilish
Meni birinchi marta hal qilmoqchi bo'lgan muammo kontekst oynasi edi. Oldingi usulda bitta sessiyada tahlil, amalga oshirish, tuzatish, tasdiqlashni davom ettirmoqchiman. Bu usul dastlab tez, lekin orqaga borgan sari kontekst kengayib, LLMning javob sifati pasaygan muammosi bo'ldi.
Task/Plan Hainesda bu muammoni ish birligi ajratish orqali hal qildik. LLM so'rovni olganda, avval barcha ishlarni kichik Tasklarga ajratadi. Har bir Task bitta sessiyada tushunish va ishlash mumkin bo'lgan kattalikda bo'lishi kerak. Masalan, backend shartlarini o'zgartirish, frontend chaqiruvlarini tuzatish, test va qurilish tasdiqi har biri alohida Task bo'lishi mumkin.
Bitta Task tugagach, albatta TASK.md va PLAN.mdni yangilab turadi. Keyingi ishga o'tishdan oldin sessiyani boshlang'ichga qaytarishni ta'minlaydi. Bu yerda muhim jihat shundaki, oddiygina sessiyani uzmasdan, uzilishdan oldin hozirgi holatni hujjatda qoldirishdir. Shunday qilib, yangi sessiya boshlanganda oldingi ishlarni qayta tushuntirmasligingiz mumkin.
T-01 완료 후 기록 예시
TASK.md
- [x] T-01. Update backend command contract
- Status: Completed
- Clear after completion: Required
- Result: Command 필드 구조를 변경하고 관련 Flow 호출부를 수정했습니다.
PLAN.md State Log
| Task | Status | Last result | Next start |
| T-01 | Completed | 백엔드 계약 변경 완료, compileJava 통과 | T-02 프론트엔드 호출부 수정 |Shunday qilib, qayd etib qo'ysangiz, yangi sessiyada avval TASK.mdga qarab, zarurat bo'lsa PLAN.mddagi tegishli bo'limni tekshirishingiz mumkin. Avval men uzoq tavsiflarni yana yozishim kerak bo'lgan, lekin endi hujjat bu rolni o'z zimmasiga oldi. Natijada, sessiyalarni tez-tez boshlang'ichga qaytarsangiz ham, ish oqimi to'xtamaydi.
Shuningdek, katta muammoni bir marta hal qilish o'rniga kichik muammolarni birma-bir hal qilmoqda LLMning javob sifati ko'proq barqaror bo'ldi. LLM keng doirani bir marta ko'rishdan ko'ra, aniq doira va tugallangan mezonlar bilan kichik ishlar bo'yicha yaxshiroq natijalarga erishdi. Bu jihatni haqiqiy qo'llashda eng katta o'zgarish sifatida his qildik.
6. Qaror qilinmagan narsalarni amalga oshirmaslik qoidasi
Kontekst muammolarini bir muncha hal qilganimdan so'ng yana bir muammo paydo bo'ldi. LLMning noaniq mazmunni o'z-o'zidan hal qilish muammosi. Ayniqsa ishlab chiquvchi, albatta qaror qilishi kerak bo'lgan joyda LLM o'z-o'zidan harakat qilishiga ba'zi hollarda guvoh bo'ldim. Bu muammo oddiy kod xatoliklaridan ko'ra xavfliroq edi. Agar yo'nalish noto'g'ri bo'lsa, ko'p faylni o'zgartirgandan keyin muammoni aniqlaymiz.
Buni hal qilish uchun PLAN.mdda Qarorlar talab etiladigan bo'limni qo'shdim. Amalga oshirishdan oldin qaror qilinishi kerak bo'lgan narsalarni birinchi bo'lib aniqlab, bittasi ham ochiq holatda qolganda ishni boshlamaslik qoidasi yaratdim. Bu qoida tatbiq etilgandan so'ng, LLM noaniq qismlarni o'z-o'zidan hal qilmay, tanlovlar va foyda-zararlarni tartibga tushirishdan so'ng men saylagan qarorni kutadi.
## 1. Decisions Required
| ID | Decision Needed | Options / Notes | Status | Decision |
| --- | --- | --- | --- | --- |
| D-01 | API 응답을 기존 DTO에 추가할지, 별도 DTO를 만들지 결정 필요 | 기존 DTO 확장: 변경 범위 작음 / 별도 DTO: 역할 분리 명확 | Open | |
규칙:
- Status가 Open인 결정이 하나라도 있으면 구현을 시작하지 않습니다.
- 사용자가 선택하면 Status를 Decided로 변경하고 Decision에 근거를 기록합니다.Bu usul kutganimdan ko'ra samara berdi. Avval men talab qilib bilmagan joylarni LLM taxmin qilib o'tdi. Endi o'z-o'zidan LLM mening o'tkazib yuborgan qarorlarni birinchi bo'lib aytadi. Masalan, eski maydonni qayta ishlatishni, yangi maydon qo'shishni, tasdiqlash joyini backendda yoki frontendda ekanligini avval taklif qiladi.
Bu jarayon faqat LLMni nazorat qilishdan iborat emasdi. Mening ko'rsatmalarimni ko'rib chiqishda ham yordam berdi. Men ishni talab qilganda barcha qarorlarni o'ylab ko'rganimni his qilaman, lekin aslida, ko'p vaqtlar o'zgarishlar bo'ladi. PLAN.mdning qarorlar ro'yxati shunday bo'shliqlarni aniqlovchi vosita bo'ldi. Amalga oshirishdan oldin savollar berilganda, vaqtincha to'xtash va yo'nalishni qayta tekshirish imkonini beradi, shuningdek noto'g'ri amalga oshirgandan so'ng orqaga qaytarish narxini kamaytirishi mumkin.
7. Ish faoliyati va chiqarib qo‘yish doirasini aniqlash
LLM ishlatganingizda tez-tez duch kelinadigan muammolardan biri so‘ralmagan takliflarni ham qo‘shishga bo‘lgan intilishdir. Atrofdagi kodning uslubini to‘g‘rilash yoki aloqador ko‘rinadigan tuzilmani qo‘shimcha o‘zgartirish yoki kelajakdagi kengaytirishni hisobga olib abstraktsiyalar yaratish kabi.
Shuning uchun PLAN.md dan Ishlatish Qoidalariga doira va chiqarib qo‘yishni albatta yozishga majbur qildim. Bu loyihada o‘zgartirish mumkin bo‘lgan sohalar va o‘zgartirish mumkin bo‘lmagan sohalarni ajratishdir. Masalan, aniq API shartnomasi o‘zgartirilishi kerak bo‘lsa, belgilangan Command, Flow, Resource va chaqiruv joylarini doira deb belgilab, aloqasiz qayta ishlash yoki yaratilgan kodni to‘g‘ridan-to‘g‘ri o‘zgartirishni chiqarib qo‘yish sifatida yozamiz.
## 0. Working Rules
- Scope is limited to **************Command, *************Cdo, Flow/Resource wiring, and directly affected frontend call sites.
- Out-of-scope files/modules: unrelated track pattern behavior, generated target project files, unrelated UI restyling.
- Verification rule: run focused backend compile and affected frontend build when possible.
- Do not start implementation while any item in Decisions Required is Open.Bu qoidani qo‘llaganimizda, LLM ish jarayonida yaxshi takliflar topsa ham, darhol qo‘llamaydi. Kerak bo‘lsa alohida vazifaga ajratish yoki foydalanuvchidan tasdiqlash oladi. Shuning uchun bitta ishning keraksiz darajada kattalashishini oldini oldik. Ayniqsa, hamkorlikdagi kodlarda kichik o‘zgartirish bloku muhim bo'lgani sababli, bu qoidalar ko‘rib chiqish mumkin bo‘lgan o‘zgartirishlarni saqlashda yordam berdi.
8. Tekshirish mezonlarini avval belgilashning samarasi
LLM kod yaratishda tezkor yordam beradi, lekin yaratilgan kodning haqiqatan ham xavfsizligi alohida muammo. Shuning uchun PLAN.md ga Tekshirish qoidasi kiritildi. Ishni boshlashdan oldin qanday usul bilan tugallanganligini belgilab olishdir.
Masalan, backend o‘zgartirilsa, aloqador modullarning compileJava yoki testlarini ishga tushiramiz, frontend o‘zgartirilsa esa tegishli paketning build yoki turini tekshiramiz. Atrof-muhit muammolari tufayli tekshirishni amalga oshira olmasak, amalga oshirilmagan sabablari va o‘rniga tushuntirilgan ma’lumotlarni yozamiz. Muhimi, tugallanishini LLM ning his-tuyg‘usiga qoldirmaslik.
Verification or completion:
- Run .\gradlew.bat :drama-feature:compileJava :drama-facade:compileJava
- Search for stale **********Cdo.get**********Id() references
- If verification is blocked, record the blocker and the smallest successful checkBu mezon mavjud bo‘lganda ish natijalarini ko‘rib chiqishda ham qulay. Faqat “o‘zgartirdim” emas, balki qanday tekshirishni o‘tkazganimiz ham yoziladi. Haqiqiy ishda buildning muvaffaqiyatli o‘tganini, belgilangan havolalarning endi qolmaganini, yaratilgan natijaning maqsad qilingan nom bilan kelishini tekshirish muhim edi. Tekshirish mezonlarining avval belgilanishi LLMga ishni qachon tugallashini aniqroq belgilashda yordam berdi.
9. Haqiqiy ish jarayonidagi o'zgarishlar
Hanesni qo'llashdan oldin ish jarayoni nisbatan oddiy edi. Men promptda funktsiyani tushuntirsam, LLM uni amalga oshirardi va men natijani ko‘rib chiqardim. Agar muammo bo‘lsa, yana so‘rardim. Bu usul tez boshlashga imkon beradi, lekin ish murakkablashganda takroriy tuzatishlar ko‘payar edi.
Hanesni qo‘llaganidan so‘ng jarayon o‘zgardi. Avval ish maqsadi va doirasini aniqlaymiz. Keyin LLM TASK.md va PLAN.md ni yozadi. PLAN.md da qaror qabul qilish zarur bo‘lgan holatlar mavjud bo‘lsa, amalga oshirishni to‘xtatib, men tanlayman. Barcha qarorlar belgilanganidan so‘ng bitta vazifani bajaradigan bo‘lamiz. Vazifa tugagach, natijalar va tekshirish ma’lumotlarini yozamiz va kerak bo‘lsa sessiyani qayta tiklab, keyingi vazifaga o‘tamiz.
작업 흐름
1. 사용자 요청 입력
2. LLM이 작업 목표, 범위, 제외 범위, 검증 기준 정리
3. TASK.md / PLAN.md 생성
4. Decisions Required 확인
5. Open 결정이 있으면 구현 중단 후 사용자 결정 대기
6. 하나의 Task만 구현
7. 검증 실행 및 결과 기록
8. 세션 초기화 후 다음 Task 진행Bu jarayon dastlab sekin dek ko‘rinsa ham, umumiy ish vaqtida aksincha kamayishi ko‘p hollarda kuzatilgan. Noto‘g‘ri yo‘nalishda amalga oshirish va orqaga qaytish bilan bog‘liq muammolar kamaydi, sessiya uzoq davom etganda sifat pasayishi muammolari ham kamaydi. Eng muhimi, ish holati hujjatda saqlanib qolganligi sababli, o‘rtada to‘xtab qolish yoki boshqa ish bilan shug‘ullanishga qachon qaytsangiz ham davom ettirish oson edi.
10. Qo‘llab-quvvatlash paytida sezilgan afzalliklar
Birinchi afzallik kontekstni boshqarish osonlashganidir. Sessiyani uzoq vaqt davom ettirish shart emas, shuning uchun LLMning sifatining pasayishini kamaytirish mumkin bo‘ldi. Avval sessiyani qayta tiklash og‘ir edi, lekin endi TASK.md va PLAN.md borligi sababli, qayta tiklash ish jarayonining bir qismi bo‘lib qoldi.
Ikkinchi afzallik esa qaror olish xarajatlarining kamayganidir. LLM ixtiyoriy ravishda qaror qabul qilmaydi, zarur qarorlar ro‘yxatini avval berib qo‘yadi, shuning uchun amalga oshirishdan oldin yo‘nalishni belgilash mumkin bo‘ldi. Bu jarayonda men ko‘rsatib o‘tamagan tanlovlar hamlarni ko‘rish imkoniyatim bo‘ldi.
Uchinchi afzallik – sharh berish imkoniyatining oshganidir. Ish doirasi, qaror sabablari, tasdiqlash natijalari hujjatda qoldirilishi tufayli, keyinchalik kodga qaraganda nega bunday o'zgartirganingizni aniqlash osonlashdi. Ayniqsa, bir nechta fayl bir vaqtda o'zgartiriladigan ishda bu yozuv kichik loyiha hujjati vazifasini bajaradi.
Turtinchi afzallik – LLMning roli aniq tuzilganidir. Xarnesni qo'llashdan oldin LLM ba'zida bajaruvchi va loyihalovchi kabi harakat qilishi mumkin edi. Xarnesni qo'llaganimizdan so'ng, LLM reja doirasida amalga oshirishga yordam beradi va ish chekkalari va qarorlarni dasturchi nazorat qiladi.
11. Qo'llashda e'tibor berish kerak bo'lgan jihatlar
Task/Plan xarnesi har bir ish uchun zarur emas. Oddiy izoh so'rab, kodni o'qish yoki qisqa o'zgartirishlar uchun ortiqcha bo'lishi mumkin. Xarnes kod o'zgartirish, sozlash o'zgartirish, sinov o'zgartirish, mahsulot o'zgartirish kabi haqiqiy omborga ta'sir ko'rsatadigan ishlarda samarali bo'ldi.
Bundan tashqari, hujjatlarni juda batafsil yozish boshqaruv xarajatlarini oshiradi. TASK.md faqat ish holatini qisqacha qayd etishi kerak, batafsil ma'lumotlarni esa PLAN.mdda saqlash ma'qul. TASK.md juda uzun bo'lsa, joriy ishni tezda tushunish qiyinlashadi. Aksincha, agar PLAN.md juda qisqa bo'lsa, keyingi sessiyada asoslarni tiklash qiyin bo'ladi.
Oxirida, xarnes borligi sababli tekshirish zarur emas degani emas. LLM hali ham noto'g'ri kod yarata oladi va tasdiqlash buyruqlari o'tsa ham talablarni to'liq qondira olmasligi mumkin. Xarnes, LLMga ishonish vositasi sifatida emas, dasturchi uchun LLMni xavfsizroq ishlatish uchun nazorat vositasi sifatida qaralishi to'g'ri.
12. Xulosa
Bu tajriba orqali LLMni yaxshi qo'llash uchun faqat buyruqni yaxshi yozish etarli emasligini his qildim. Buyruq – ulkan zamon talablarini etkazish vositasi. Bunga qarama-qarshi, Task/Plan xarnesi butun ishni boshqarish tuzilmasidir. Amaliyotda bir martalik talablar o'rniga barqaror ish tuzilmasi muhimroq edi.
Task/Plan xarnesini qo'llaganimizdan so'ng kontekst oynasi muammosi tufayli sifatning pasayishi kamaydi va sessiya boshlanishidan so'ng ishni oson davom ettirish imkoniyati bo'ldi. Shuningdek, hal qilinmagan masalalarni oldindan aniqlash va amalga oshirishni to'xtatish qoidasi tufayli LLM tasodifan yo'nalishni belgilash muammosi ham kamaydi.
Natijada, LLM tezda kod yozuvchi vositadan tashqari, aniq ish tuzilmasi ichida ishlab chiqaruvchanlikni oshiruvchi vositaga aylandi. Biroq, bu samara LLMga barcha narsani topshirganingizda emas, balki dasturchi ish chekkasi, qaror mezonlari, tasdiqlash mezonlarini aniq belgilaganida yanada kuchayadi. Kelajakda ham LLMni amaliyotga qo'llaganda, ishni qanday bo'lish va yozish va tasdiqlashga ko'proq e'tibor berishim kerakligiga ishonaman.
DEVKC