ЖИ көмегімен өнім жасадым — жұмыс істеп тұрған нәрсені бұзбай қалай жақсартуға болады

Модельдермен жұмыс істеу туралы Ailoot құжаттамасынан көбірек біліңіз.

Неліктен ең қымбат жұмыс іске қосылғаннан кейін басталады?#

Сіз бір кеште қолданба жасап, сілтемесін жариялап, достарыңызға жібердіңіз. Ол жұмыс істейді. Бірақ бір аптадан соң алғашқы шынайы адам келіп, бір нәрсені басқаша басады да, мүмкіндіктердің жартысы істемей қалады. Claude-тан түзетуді сұрайсыз — ол бір нәрсені жөндеп, басқасын бұзады. Таныс жағдай ма?

Дәл осы тұста негізгі сұрақ туады: өнімді іске қосқаннан кейін, алғашқы жұмыс істейтін прототиптің эйфориясы басылып, оны қалай да сүйемелдеу қажет болғанда не істеу керек? Мұны ересектерге арналған vibe coding деуге болады. Жасау — қызық пен жылдамдық. Ал сүйемелдеу салқынқандылықты талап етеді: нені өзгертіп жатқаныңызды түсініп, оны бақылауда ұстауыңыз керек. Көп адам осы екінші кезеңде сүрінеді, өйткені оған ешкім дайындамайды.

Бір салалық зерттеу 2 444 командадан миллионнан астам код өзгерісін талдап, ЖИ көмегімен әзірлеуге жұмсалған ақшаның қайда кететінін есептеді. Көрініс мынадай:

«Vibe coding-тің жасырын құны» нұсқаулығында бұл сандар толығырақ түсіндіріледі. Онда әңгіме ненің ақысын төлеп жатқаныңыз туралы болды. Ал мұнда сұрақ басқа: әр доллардың 44 центі қателерді түзетуге кетеді — бұл мақала сол үлестің өсуіне жол бермеу туралы. Оны бақылауда ұстау жұмысы сүйемелдеу деп аталады.

Ересектерше vibe coding жасайтын адам мен нейрондық желіні бағып қана отыратын адамның айырмасы іске қосылғаннан кейін көрінеді. Біріншісінің код базасы өседі, ол жақсартулар енгізеді, бірақ ештеңе бұзылмайды. Бір айдан кейін екіншісінің өніміне тиісе алмайтындай қорқатын, әр жерінен су ағатын құрылғыға айналады. Алдыменгі топқа қалай қосылуға болатынын қазір түсіндіремін.

Іске қосылғаннан кейін не бұзылады: 5 апат#

Бұлар — саны мен күні көрсетілген, ЖИ көмегімен жасалған нақты өнімдер туралы жарияланған оқиғалар. Оларды мина алаңының картасы деп елестетіңіз: әр мина біреудің басында жарылып үлгерген, ал одан айналып өтудің жолы белгілі.

Бес оқиғаның да негізгі себебі бірдей. Әдепкіде ЖИ бір айдан кейін жүктеме артқан кезде қауіпсіз жұмыс істеуге емес, дәл қазір жұмыс істеуге басымдық береді. Компьютерде әзірлегенде бұл айырманы байқай алмайсыз. Ниеті жаман алғашқы бейтаныс адам келгенде ғана мәселе анық көрінеді.

Мәселе кодты қолмен жазбауда емес — көп адам осылай жұмыс істейді. Мәселе «Дерекқор қорғалған ба?» деп сұрамауда. Келесіде осы сұрақты сіз үшін қоятын сұрау мәтінін көрсетемін.

Алғашқы қорғаныс қабаты — git және «кешегідей күйге» қайтару#

Claude бір нәрсені бұзғанда, «кешегідей қалпына келтір» батырмасы керек. Техникалық атауы — git, ал оны пайдалану ойлағаннан оңай.

Бағдарламашы емес адам білуі керек үш термин:

1. Репозиторий — бұлтта (әдетте GitHub-та) сақталған жоба қалтасы. Кодтың компьютеріңізде ғана тұрмайтын көшірмесі.
2. Коммит — қайту нүктесі. Сіз кодқа іс жүзінде «осы күйді сақта» дейсіз. Әр коммит — қайта оралуға болатын белгі.
3. Деплой — көшіру. Код компьютеріңізде жергілікті тұрғанда, ол тек сіз үшін жұмыс істейді. Деплой оны сыртқы серверге жібереді, сонда барлығына қолжетімді болады.

Жақында жасалған коммит нүктелері бар болса, кез келген бұзылуды бір сөйлеммен кері қайтара аласыз. Сөзбе-сөз.

Мен бір нәрсені бұзып алдым — кеше бәрі жұмыс істеп еді, бүгін істемейді. Бәрі дұрыс болған ең соңғы коммитті тап, содан бері не өзгергенін көрсетіп, жобаны сол күйге қайтар.

Өнімді басқа адамдарға көрсетпей тұрып, мына екі ережені бірден енгізіңіз:

• Репозиторий жабық болуы керек. Ашық емес. Әйтпесе кез келген адам кодыңызды және оның ішіндегінің бәрін оқи алады.
• Құпия деректер файлын елемеу тізіміне қосыңыз. Кілттер, құпиясөздер және дерекқорға кіру деректері бөлек файлда (әдетте .env) сақталады, ол файл репозиторийге ешқашан қосылмайды. .gitignore файлына .env жолын қосыңыз, сонда құпия деректер өзіңізде қалады.

Claude Code-та өзгерістерді қауіпсіз кері қайтару туралы бөлек нұсқаулық бар: Claude Code-тағы өзгерістерді қалай кері қайтаруға болады. Қайту нүктелері болмаса, сақтандыру торынсыз арқан үстімен жүресіз, ерте ме, кеш пе құлайсыз.

/rewind нені кері қайтарады, ал нені қайтармайды?#

Claude Code өзі жасайтын әр өзгерістің алдында күйдің снапшотын жасайды. /rewind пәрмені (немесе Esc пернесін екі рет басу) файлдар мен әңгімені таңдалған нүктеге қайтарады. Бұл ыңғайлы: мүмкіндікті бес минут бұрын бұзсаңыз, бес минутқа кері орала аласыз.

Бірақ жаңадан бастағандардың дерегін жоғалтуына себеп болатын бір қақпан бар. /rewind бәрін кері қайтармайды:

Anthropic мұны анық айтады: снапшоттар — жергілікті «болдырмау» батырмасы, ал git — тұрақты тарих. Снапшоттар нұсқаларды басқару жүйесін толықтырады, бірақ оны алмастырмайды.

Бағдарламашы емес адамға арналған практикалық түйін: /rewind «Claude жаңа ғана мүмкіндікті бұзды» деген жағдайдан құтқарады. Бірақ ол дерекқор жолын жойып немесе кодты бұлтқа жүктеп үлгерсе, оны тек git пен дерекқор сақтық көшірмесі қайтара алады. Сондықтан екі қабатты да сақтаңыз: жылдам кері қайтаруға арналған снапшоттар және жобаның тұрақты тарихына арналған коммиттер.

Жұмыс істеп тұрған нәрсені бұзбай қалай жақсартуға болады?#

Әр екінші адам осы айналымға түседі. ЖИ-ден шағын қатені түзетуді сұрайсыз. Ол орынды көрінетін өзгеріс ұсынады. Сол өзгеріс басқа нәрсені бұзады. Жаңа мәселені түзетуді сұрайсыз, тағы екі мәселе пайда болады. Осылай жалғаса береді.

Бұл айналым vibe coding анықталмаған сипатта болғандықтан туындайды. Бір сұрау мәтіні екі рет берілсе де, екі түрлі код шығуы мүмкін. Сондықтан әр өңдеу айналадағы логиканы байқатпай өзгертуі ықтимал: жеңілдік шегі 10-нан 12 пайызға өзгереді немесе тексеру ережесінің әрекеті ауысады — сіз тексермейсіз, бір ескерту де шықпайды. Мұны логикалық ауытқу дейді, ол табыс әкелетін дәл сол нәрселерге: бағаларға, қолжетімділікке және төлемдерге білдірмей зиянын тигізеді.

Ауытқудан қорғайтын бір ереже бар, оны қабырғаға іліп қоюға болады: басқа адамға сөзбе-сөз түсіндіре алмайтын кодты коммит жасамаңыз.

Іс жүзінде бұл жұмыс істеп тұрған кодқа кез келген өзгеріс енгізер алдында қолданатын дайын нұсқауға айналады. Ол ЖИ-ді шағын қадамдар жасауға және нақты не өзгергенін көрсетуге мәжбүр етеді.

Кодты өзгертпес бұрын мынаны орында:

Қазіргі жұмыс істейтін күйді бөлек қайту нүктесі ретінде сақта (коммит жаса).

Нақты нені және қай файлдарда өзгертуді жоспарлап отырғаныңды сөзбен сипатта.

Ең аз өзгеріс жаса — тек тапсырмамды шешетінін ғана, артық ештеңе қоспа.

Не өзгергенін көрсетіп, әр өзгерісті басқа адамға түсіндіре алатындай етіп түсіндір.
Өзім сұрамасам, баға белгілеу, қолжетімділік немесе төлем логикасына тиме.

Апталарды үнемдейтін тағы бір қағида — тапсырманың шекарасын сақтау. Бір мәселе, бір өзгеріс, жылдам іске асыру. ЖИ-ден бір сұрау мәтінімен жобаның жартысын қайта жазуды сұрамаңыз. Кәсіби әзірлеушілер кейде бір батырма керек болғанда тұтас Uber жасап бастап, оны айларға созады. Сізге ондайдың қажеті жоқ.

Мен сипаттағанның бәрі бір нәрсеге сүйенеді: контексті басқару. ЖИ көрші логиканы бұзбауы үшін жоба ережелерін есте сақтауы керек.

Жарияламас бұрын өзгерісті қалай тексеруге болады?#

«Компьютерімде жұмыс істейді» мен «бәріне жұмыс істейді» дегеннің арасында жаңадан бастаушылар өткізіп жіберетін аралық қадам бар: сынақ көшірмесі. Бұл — нақты өзгерісті адамдар көрмей тұрып тексеретін, өндірістік ортаңыздың бөлек снапшоты. Жұмыс циклі мынадай:

1. Өзгерісті өзіңіз жасап, тексеріңіз (әзірлеу).
2. Оны staging ортасына — нақты пайдаланушылары жоқ өндірістік ортаның көшірмесіне — деплой жасаңыз.
3. Негізгі сценарийлерді орындап, ештеңе өзгермегеніне көз жеткізіңіз.
4. Содан кейін ғана өндірістік ортаға деплой жасаңыз.

Бұл іске қосылғаннан кейін неге маңызды? Әр шығарылымда қауіп бар. Кодтағы шағын өзгеріс есептік жазбаға кіруді бұзуы мүмкін. Бір жетіспейтін параметр бүкіл өнімді тоқтатуы ықтимал. Staging мұндай мәселелерді салдарсыз табады, ал өндірістік ортада клиенттерден айырыласыз.

Әр жолы бәрін қолмен тексермеу үшін ЖИ-ге жаңа нұсқаның әрекетін ескі нұсқамен негізгі тұстар бойынша салыстыруды тапсырыңыз.

Мен өзгерісті деплой жасамақпын. Өнімнің негізгі сценарийлерін ретімен тексеріп, әрқайсысы бұрынғыдай жұмыс істеп тұрғанына көз жеткіз:

Жаңа пайдаланушыны тіркеу және жүйеге кіру.

Төлем жасау және төлемнен кейін қолжетімділікті беру.

Қолжетімділік құқықтары: қарапайым пайдаланушы басқа біреудің деректерін немесе әкімші бөлімін көре алмайды.

Негізгі бизнес логикасының сандары (бағалар, жеңілдіктер, шектеулер) өзгермеген.
Егер бірдеңе алдыңғы нұсқадан басқаша жұмыс істесе, тоқтап, нақты не өзгергенін көрсет.

Құпия деректеріңіз қайда? Жаңадан бастаушының ең үлкен олқылығы#

Ең үлкен қауіп туралы егжей-тегжейлі айтайын, өйткені ол басқа кез келген қатерден көп өнімді істен шығарады. ЖИ код жазғанда ең оңайы — бірден жұмыс істейтін жерге, яғни браузерде ашылатын беттің кодына кілтті салу. Әзірлеу кезінде айырмашылықты байқамайсыз. Бірақ браузерге жеткеннің бәрін кез келген адам әзірлеуші құралдарын ашып көре алады.

Клиенттерінен $87,500 алынған негізін қалаушы кейін мұның алдын бір ғана сұрау мәтінімен алуға болатынын айтқан. Ақша кейін қайтарылған, бірақ қайтарылмайтын алымдар мен жоғалған тыныштық қайтпады. Міне, сол сұрау мәтіні.

Бүкіл жобаны тексеріп, ешбір құпия кілт браузерге түспейтініне көз жеткіз:

Дерекқор, төлем жүйесі және сыртқы қызметтерге арналған барлық кілтті тап.

Әрқайсысы тек серверде, орта айнымалыларында сақталғанына және бет кодында жоқ екеніне көз жеткіз.

Жоба тарихын тексер — бұрын қандай да бір кілт оған кездейсоқ қосылып кеткен жоқ па?
Құпия деректерді тапқан әр орынды және әрқайсысына қатысты не істеу керегін тізіп көрсет.

Жақын жерде тұрған тағы бір қауіп — қолжетімділік құқықтарын тек браузер жағында тексеру. Егер өніміңіз «әкімші бөлімін көрсету» керек пе екенін бет кодында шешсе, кез келген адам бұл шешімді айналып өте алады. Қолжетімділік құқықтары әрдайым серверде тексерілуі керек. Дерекқор деректерді тек соған құқығы бар адамдарға қайтаруы тиіс — бұл үшін жол деңгейіндегі қауіпсіздік (RLS) қолданылады және оны әр кестеде қосу керек.

Қолжетімділікті сатпас немесе басқа адамдарды кіргізбес бұрын өнімнің жалпы қауіпсіздік аудитін өткізіңіз.

Жобаға шабуыл жасаушының көзімен қарап, қауіпсіздік олқылықтарын тап:

Браузерге жіберілетін кодта немесе жоба тарихында қандай да бір құпия кілт сақталған ба?

Әр дерекқор кестесінде жол деңгейіндегі қауіпсіздік (RLS) қосылған ба, қолжетімділік құқықтары тек браузерде емес, серверде тексеріле ме?

Дерекқордың автоматты сақтық көшірмесі бапталған ба, одан қалпына келтіруге болатынын тексеріп көрдім бе?

Өндірістік дерекқор ЖИ агенті жұмыс істейтін ортадан оқшауланған ба?
Әр тармақ бойынша бәрі дұрыс па, әлде нақты нені түзету керегін айт.

Vibe coding қауіпсіздігі туралы бөлек толық нұсқаулық бар: Vibe coding арқылы жасалған қолданбаны қалай қорғауға болады. Ереже қарапайым: басқаша екенін тексермейінше, ЖИ әдепкіде жасағанның бәрін қорғалмаған деп есептеңіз.

Өнімді қайда орналастыру керек: хостинг баспалдағы#

Бірден өз серверіңізді жалға алып, қолмен баптаудың қажеті жоқ — бастапқыда бұл күрделі жұмыс, уақытыңызды алады. Өнім өскен сайын көтерілуге болатын баспалдақ бар:

1. Тегін хостинг (мысалы, Vercel) — өзіңізге, сынақтарға және шағын жобаларға. Платформа аудиторияңыз үшін қолжетімді болып, адамдардың жеке деректерін сақтамасаңыз, жарайды.
2. Бір пәрменмен деплой жасайтын платформа (Railway) — бэкенд пен дерекқор болғанда. Бір пәрменмен деплой жасайсыз, серверді баптаудың қажеті жоқ. Бастау кедергісі аз.
3. Жеке бөлінген сервер — жүктеме жоғары болғанда және толық бақылау қажет болғанда. Платформаның шегіне жеткен соң осыған көшіңіз.

Жаңа ғана іске қосқан бағдарламашы емес адам үшін серверді қолмен баптауды қажет етпейтін, бір пәрменмен деплой жасайтын платформа — ең оңай нұсқа. Жеке серверге кейін көшіңіз. Нақты мысалмен осы жолмен жүргіңіз келсе, Coolify көмегімен vibe coding жобасын жеке серверге орналастыру нұсқаулығын қараңыз.

Қолданбаны, дерекқорды және сақтық көшірмелерді қашан бөлу керек?#

Үш нәрсені бір себетте сақтамаған жөн: қолданбаны, дерекқорды және сақтық көшірмелерді. Пайдаланушы аз кезде бәрі бірге тұрады, бұл қалыпты. Бірақ оларды қашан бөлу керегін көрсететін нақты белгі бар.

• Қолданба мен дерекқорды бөлек машиналарға орналастырыңыз. Белгісі: ең жоғары жүктемеде процессор мен жадты пайдалану 70–80 пайыздан жоғары болып, сұраулар баяулайды, ал қолданба мен дерекқор бір ресурстарға таласады. Бөлген соң қолданбаға тимей дерекқорды күшейтуге болады, және керісінше.
• Сақтық көшірменің 3-2-1 ережесін қолданыңыз. Деректің үш көшірмесі, екі түрлі тасымалдағышта, біреуі басқа жерде. Бұл жабдық істен шығуынан және бопсалаушы бағдарламалардан қорғайды. Ең бастысы — сақтық көшірмелер автоматты жасалуы керек.

Сақтық көшірме жиілігі бірнеше сағаттық деректен айырылу қаншалықты қымбатқа түсетініне байланысты. Төлем жазбаларының бір сағатын жоғалтуға болмайтын онлайн жазылым қызметінде сақтық көшірме аралығы бір сағаттан қысқа болуы керек немесе тексерілген транзакция журналдары мен уақыт нүктесіне дейін қалпына келтіру (PITR) қажет. Аралықты төзуге болатын ең көп дерек жоғалтуынан таңдаңыз және қызметті қалпына келтіруге кететін уақытты бөлек сынаңыз. Блогқа күніне бір рет жеткілікті. Логикасы қарапайым: қанша деректен айырылуға болатынын шешіп, сақтық көшірмелерді соған сай баптаңыз.

Өнімімді маңыздырақ инфрақұрылымға көшіру уақыты келген-келмегенін шешуге көмектес. Әр тармақты тексеріп, меннен сұра:

Ең жоғары жүктеме кезінде процессор мен жад қаншалықты жүктеледі — пайдалану 70–80 пайыздан жоғары болып тұра ма?

Дерекқор мен қолданба бір машинада ма, әлде бөлек пе?

Дерекқордың автоматты сақтық көшірмесі бапталған ба, одан қалпына келтіруді тексердім бе?

Деплой жасамас бұрын тексеруге арналған ортаның бөлек көшірмесі (staging) бар ма?
Нәтижеге сүйеніп нақты ұсыныс бер: нені сол күйі қалдыру, алдымен нені бөлу және неге.

Басқарылатын дерекқорды ма, әлде өзіңіздікін бе деген бөлек сұрақ бар. Шағын команда үшін басқарылатыны әрдайым дерлік тиімді: өзіңіздікі жабдық жағынан арзан, бірақ техникалық күтімге сағаттап уақыт кетеді. Егер жалғыз жұмыс істесеңіз және өніміңіз инфрақұрылымға қатысты болмаса, ол сағаттардың құны сервер бағасындағы айырмадан жоғары.

Сүйемелдеуді автоматты режимге қалай қоюға болады?#

Қолмен сүйемелдеу қажытады. Мұны екі жолмен азайтуға болады: мониторинг және тексеруші агент.

Мониторингте әртүрлі екі міндетке арналған екі бөлек құрал бар:

1. «Сайт жұмыс істеп тұр ма?» — қолжетімділікті бақылайтын монитор (мысалы, UptimeRobot). Ол өнімге бірнеше минут сайын сұрау жіберіп, істен шықса ескерту жібереді. Тегін жоспары бар.
2. «Нақты не бұзылды?» — қате бақылау құралы (мысалы, Sentry). Ол қолданба ішіндегі қателерді жинап, ненің қай жерде және не себепті істен шыққанын көрсетеді.

Біріншісі өнімнің істен шыққанын байқайды. Екіншісі қай мүмкіндік неге істемей қалғанын көрсетеді. Екеуі бірге «Клиент қолдау қызметіне жазбай тұрып, ақауды біле аламын ба?» деген сұраққа жауап береді.

Автоматты режимнің екінші деңгейі — тексеруші агент. Жылжымайтын мүлік агенттігін елестетіңіз: таңғы жетіде ЖИ агенті сайттағы өтінімдерді оқып, брондау формасы бұзылғанын көреді, кодтан себебін тауып, түсіндірмесі бар дайын түзетуді ұсынады. Сіз тексеріп, «иә» дейсіз — ол деплой жасайды. Реті маңызды: алдымен пайдаланушының мәселесін шешіңіз (қолжетімділікті қайтарыңыз, кешірім сұраңыз), содан кейін себебі мен ақша мәселесін тексеріңіз.

ЖИ-дің өндірістік дерекқорға қолжетімділігіне қатысты тағы бір ереже: оған тек оқуға арналған пайдаланушы беріңіз, ал жеке деректерді аралық қабаттың артына жасырып, агентке адамның шын атының орнына «аты» сияқты белгі көрсетіңіз. Сонда ол қателессе де, өндірістік деректерді физикалық тұрғыда жоя немесе бүлдіре алмайды. Агент өндірістік дерекқорды өшірген, жоғарыдағы кестедегі оқиға дәл осындай шектеудің болмағаны туралы. Апат болып қойса не істеу керегін ЖИ дерекқорыңызды жойса не істеу керек нұсқаулығы түсіндіреді.

Өнімді қашан жабатын кез келді?#

Сүйемелдеудің ең аз бағаланатын бөлігі — оны қашан тоқтату керегін білу. Көп өнім жасайтындардың бәрінде жобалар зираты бар: бірін жасап, біраз шұқылап, кейін тастап кеткен. Бұл қалыпты, сәтсіздік емес. Сәтсіздік — жұмсаған уақытыңызға өкінгендіктен, ешкім пайдаланбайтын жобаны айлап сүйреп жүру.

Шешім қабылдауға болатын межелер:

1. Екі апта — идеяның жұмыс істейтін-істемейтінін байқауға жеткілікті. Алғашқы нақты пайдаланушылар қайта келсе, жалғастырыңыз. Үнсіздік те — жауап.
2. Үш ай — қатаң шек. Үш айда іске аспаса, жабыңыз. Vibe coding жылдамдығын ескерсек, бір идеяны сынауға алты ай жұмсау — тым ұзақ.

Жобаны жабу психологиялық тұрғыдан қиын, сондықтан оны сезім емес, шешім ретінде қарастырыңыз. Еңбек сіңірген жобадан бас тарту жұмысын атқара алмайтын қызметкерді жұмыстан шығаруға ұқсайды: жағымсыз, бірақ оны ұстап отыру жібергеннен қымбатқа түседі.

Сүйемелдеу — өнімді тірі әрі адамдарға пайдалы ұстау үшін істелетін жұмыс. Қалғанының бәрі — git, сақтық көшірме, мониторинг — өнім сізге күн сайын пайда әкеле бастайтын межеге жетуге көмектесетін құрал ғана.

ЖИ көмегімен өнімді бір кеште жасау — жұмыстың жартысы ғана. Өнімді өсіре отырып, тірі әрі қауіпсіз ұстау — ересектерге арналған vibe coding деген осы.

Келесі қадамыңыз үшін — Ailoot.