Վերագրել թե՞ patch անել. ինչ թողնել արագ AI հավաքման կոդից

Ուղիղ պատասխան

Patch արեք, երբ կառուցվածքը առողջ է, և խնդիրները տեղային են։ Վերակառուցեք կրիտիկական ուղին, երբ auth, վճարումներ կամ multi-tenant տվյալները խճճված են գեներացված սպագետտիի հետ։ Մարքեթինգային էջերը թողեք, եթե կայուն են։

Ամբողջական rewrite «որովհետև AI էր գրում» - թանկ սովորություն է։ Patch «վճարման անցքի վրայից» - կեղծ խնայողություն։

Ի՞նչ է սա նշանակում գործնականում

• Սկսեք իրական գործընթացի քարտեզից. մուտք, տվյալներ, փող, մուտքեր, ելքայիններ։
• Նկարագրեք վարքը պարզ լեզվով, հետո ստուգեք յուրաքանչյուր ուղի, որտեղ սխալը արժե փող կամ համբավ։
• Թողեք մարդուն ոչ ստանդարտի վրա. մի շտկեք «ևս մեկ prompt-ով» այն, ինչը ինժեներիա է։

Ե՞րբ patch

• UI և layout-ը լավ են, սխալները մեկ մոդուլում են։
• Գաղտնի բանալիները սերվեր են տեղափոխվում մեկ սահմանով։
• Ավելանում են rate limits, webhook signature, մեկ middleware։
• Թեստերը կարելի է կախել նեղ ուղու վրա՝ առանց ծառը կտրելու։

Ե՞րբ rewrite կրիտիկական ուղու վրա

• Auth, payments, multi-tenant և tool կանչերը խճճված են մեկ ֆայլում/prompt-ում։
• Չկա հստակ order մոդել, tenant id, server price։
• Յուրաքանչյուր ուղղում կոտրում է հարևան հոսքը։
• Չկան մատյաններ, սեփականատեր, գործակալը/checkout-ը կանգնեցնելու ճանապարհ։

Ինչպիսին է լավը

• Հստակ սահման. marketing shell vs hardened core։
• Ստանդարտ / ոչ ստանդարտ երթուղիներ գրառումից առաջ։
• Բանալիներ միայն սերվերի վրա. մատյաններ և կանգառի կոճակ։
• rewrite/patch որոշումը գրավոր է՝ «պատրաստ է» չափանիշներով։

Ինչպիսին է վատը

• «Պրևյուում աշխատում է» = ship։
• Թոքեններ և webhook հանրային են «առայժմ»։
• Բացառությունների դեպքում մարդուն փոխանցում չկա։
• Ամբողջական rewrite պերֆեկցիոնիզմի համար, մինչ funnel-ը վճարում չի ընդունում։

Ինչպես է վարում Dali-ն

Արագ AI նախատիպին լուրջ ենք վերաբերվում, հետո ամրացնում ենք. երբեմն patch, երբեմն isolate + rebuild critical path։ Vibe-code rescue, մարտական գործակալներ, վերահսկման կետեր։