ЖИ жасаған кодты тексеру: бағдарламашы еместерге арналған 7 тексеру

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

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

Бұл бекер күдік емес. Anthropic Claude Code қолданылған 400 000 сеансты талдады: жеті ай ішінде бұзылған кодты түзетуге кеткен жұмыстың үлесі 33%-дан 19%-ға дейін төмендеген. Төмендеді, бірақ жоғалып кеткен жоқ. Әр бесінші сеанс әлі де «ЖИ бұзған нәрсені жөндеуге» арналған.

Код жазудың өзі енді тар орын емес. Қазір тапсырманы қаншалықты жақсы түсінетініңіз және нәтижені қаншалықты жақсы тексере алатыныңыз маңызды.

Құралдарды баптау туралы қосымша материалдар Ailoot құжаттамасында бар.

Дайын жұмыс істеп тұрса, ЖИ жасаған кодты неге тексеру керек?#

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

Сандар мұны растайды. FrontierCode бенчмаркі 2026 жылғы маусымда ЖИ жасаған кодтың өзгеріссіз нақты жұмысқа қаншалықты дайын екенін тексерді. Ең қиын тапсырмалардағы ең үздік модельдер үшін де бұл үлес шамамен 13% болды. Басқаша айтқанда, күрделі тапсырмаларда ЖИ жазған кодтың көбіне сенуге болатындай болу үшін қолмен жетілдіру қажет.

Жақсы жаңалық — тексеруді кез келген адам жасай алады. Anthropic сол 400 000 сеансты талдап, мынадай қорытындыға келді:

Кез келген шақырылған бағдарламашымен салыстырғанда сіздің артықшылығыңыз — тапсырмаңызды өзіңіз жақсы түсінесіз. Тексеру де түсінуге байланысты; ол үшін код оқудың қажеті жоқ. Төмендегі тексерулерді еш әуре-сарсаңсыз өзіңіз жасай аласыз.

ЖИ жасаған кодта нақты не қате болуы мүмкін?#

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

Келесіде ретімен жеті тексеру берілген. Алғашқылары «жұмыс істемейді» және «дұрыс жұмыс істемейді» деген мәселелерді табады; ортаңғылары қауіпсіздік пен ойдан шығарылған нәрселерді қамтиды; соңғылары жариялар алдындағы сақтық шаралары. Оларды ретімен орындаған дұрыс: әр тексеру алдыңғысының аяқталғанына сүйенеді.

1-тексеру: ЖИ-дан кодын қарапайым тілмен түсіндіруді сұраңыз#

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

Жаңа ғана істегеніңді кодсыз, қарапайым тілмен нақты түсіндір:

бұл код қандай тапсырманы шешеді

пайдаланушы түймені басқанда немесе форманы жібергенде не болады

деректер қайда сақталады және оларға кімнің қолы жетеді

не және қандай жағдайда бұзылуы мүмкін

Бағдарламалауды ешқашан білмеген адамға түсіндіргендей жаз. Дұрыс екеніне сенімді емес тұсың болса, оны ашық айт.

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

Айтпақшы, ЖИ сіз сұрағаннан жиі басқаша әрекет етсе, мәселе көбіне модельдің өзінде емес, тапсырманың қалай берілгенінде болады. Мен Claude неге сұрағаныңызды орындамайды деген талаар бөлек жазғанмын.

ЖИ нәтижесін тексеру — контекст инженериясының бір бөлігі: сіз ЖИ-ге кіріс ретінде не беретініңізді де, шығыс нәтижесін қалай бағалайтыныңызды да бақылайсыз. Құралдар жиынтығына ЖИ көшірмесі, Екінші ми және Контекст инженериясы кіреді. Осыдан кейін Claude «галлюцинациялайтын көмекші» болудан қалып, жобаңызды сеніп тапсыруға болатын құралға айналады.

2-тексеру: Нақты пайдаланушы сияқты түрлі сценарийді орындап көріңіз#

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

1. Негізгі сценарийді басынан аяғына дейін орындаңыз

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

2. Төлемді бөлек және шынайы тексеріңіз

   Егер жоба төлем қабылдаса, тест режимінде ең аз сомаға өзіңіз төлем жасап көріңіз. Тапсырыс жасалғанын, мәртебесі өзгергенін және хат сізге де, клиентке де жіберілгенін тексеріңіз. «Өткен», бірақ тапсырыс жасалмаған төлем — көзге бірден түспейтін жиі кездесетін ақау.

3. Әдейі қате жасап көріңіз

   Өрістерді бос қалдырыңыз. Сан күтілетін жерге әріптерді енгізіңіз. «Жіберу» түймесін қатарынан екі рет басыңыз. Қате пішімдегі файл жүктеңіз. Жақсы жоба сыпайы түрде «бұлай жасауға болмайды» дейді; нашар жоба істен шығады немесе деректі үнсіз жоғалтады.

4. Телефоннан ашыңыз

   Адамдардың жартысы телефоннан кіреді. Бет орналасуы бұзылмағанын және сол түймелердің телефонда да істейтінін тексеріңіз.

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

3-тексеру: ЖИ-дан қауіпсіздік туралы сұраңыз — дайын сұрау мәтіні#

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

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

Қандай да бір құпия кілт, құпиясөз немесе токен кодта тікелей жазылған ба, тексер. Жеке құпиялар тек серверде қолданылуы керек, ал .env сияқты жергілікті құпия конфигурация git-тен шығарылуы тиіс. .env мен .gitignore frontend/public айнымалыларының браузер жинағына енуіне кедергі болмайды. Клиентке берілетін нақты JavaScript, source map, HTML және желілік жауаптарды қарап, жеке кілттер жоқ екенін тексеріңіз.

Дерекқор интернетке ашық па және оған кімнің қолы жетеді, тексер.

Енгізілген дерек формаларды бұза ала ма, тексер: дерекқор сұрауларына инъекция жасау немесе мәтін өрістеріне қосымша код енгізу мүмкін бе?

Пайдаланушы зиянды дерек жіберсе, не болады?

Ішкі беттерге немесе әкімші панеліне құпиясөзсіз кіруге болатынын тексер.

Әр тармақта мәселе бар-жоғын айтып, тәуекелдің нақты мысалын келтір және оны қалай түзету керегін түсіндір. Ең қауіпті мәселеден баста.

Жоба сырттан келгеннің бәрін ойланбай орындамайтынын да тексеріңіз. Бұл жанама prompt injection деп аталады: бұйрық хатта, пікірде немесе басқа біреудің файлында жасырылып тұрады, ал сіздің ЖИ агентіңіз оны тапсырма деп қабылдап, орындайды. Егер жоба сыртқы деректі оқып, соған сай әрекет етсе, сол деректе жасырын нұсқау болса не болатынын ЖИ-дан сұраңыз.

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

4-тексеру: ЖИ кітапханаларды немесе деректерді ойдан шығарды ма?#

ЖИ жоқ нәрселерді сенімді түрде жазады. Ол шын мәнінде жоқ, атауы нанымды көрінетін кітапхана қосуы мүмкін. Жобада тест орныбасарларын қалдыруы мүмкін: «Example» атты өнім, example@example.com электрондық пошта мекенжайы немесе нақты мазмұнның орнына толтырғыш мәтін. Демонстрацияда байқалмауы мүмкін, бірақ шынайы пайдаланушы үшін бұл ұят немесе істен шыққан жағдай.

Мұны екі қадаммен анықтауға болады. Алдымен тікелей сұраңыз:

Жобаны қарап шығып, шынайы тексер:

Өзің қосқан барлық сыртқы құралдар мен кітапханалар шынымен бар ма, дұрыс орнатылып, жұмыс істей ме? Бірдеңені ойдан шығардың ба?

Нақты деректердің орнына сынақ деректері, мысалдар немесе толтырғыш мәтін қалып қойған жоқ па?

Жобадағы барлық сілтеме, мекенжай және байланыс деректері нақты ма, әлде толтырғыш па?

Тапқандарыңды тізіп, немен алмастыруды ұсын.

Екіншіден, жобаны іске қосып, ішін қарап шығыңыз. Ойдан шығарылған кітапхана іске қосылғанда қате туғызады деуге болады. Ал толтырғыштарды байқау оңай: бетте «Product 1» деп тұрса, оларды ауыстырмағансыз.

Ойдан шығарылған кітапханалар бөлек қауіп төндіреді, өйткені шабуылдаушылар ЖИ ойдан шығаруға бейім атаулармен әдейі құрал тіркейді. Біреуін орнатсаңыз, басқа біреудің коды жобаңызға кіреді. Сондықтан «мына кітапхана расымен бар ма?» деген сұрақты байыппен қабылдаңыз — ол тікелей жобаңыздың қауіпсіздігіне қатысты.

5-тексеру: Бірінші модельдің жұмысын екінші модельге тексертіңіз#

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

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

1. Жаңа сеанс ашыңыз немесе басқа модель қолданыңыз

   Екінші модельді пайдаланыңыз немесе тапсырмалар тарихы жоқ жаңа терезеде сол модельді ашыңыз.

2. Жоба мен дұрыс түсіндірмені беріңіз

   Ашық айтыңыз: «Бұл кодты басқа ЖИ жазды; сенің міндетің — мақтамай, қателер мен қауіптерді табу». Бұл жағымпаздықты тежейді.

3. Екі пікірді салыстырыңыз

   Екеуі де келіссе, олардың дұрыс болуы ықтимал. Келіспесе, сол тұсты зерттеңіз — қызық басталатын жері сол.

Қазір салада дәл осылай болып жатыр: ЖИ жазады, ЖИ тексереді, ал соңғы шешімді адам қабылдайды. Мұны модельге тапсыруға болмайды — бұл сіздің міндетіңіз.

6-тексеру: Өзгеріс бірдеңені бұзса, қалай қайтаруға болады?#

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

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

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

7-тексеру: Жариялар алдында соңында нені тексеру керек?#

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

1. Төлем: тесттен нақты режимге

   Төлем қабылдасаңыз, төлем жүйесіне тест кілті емес, нақты режимнің кілті қосылғанына көз жеткізіңіз. Ең аз сомаға бір нақты төлем жасап, оны өзіңізге қайтарыңыз.

2. Құпия деректер тиісті жерде

   ЖИ-дан сұраңыз: «Жеке кілттер тек серверде қолданылып, .env git-тен шығарылған ба? Нақты браузер жинағында не клиент жауабында, соның ішінде frontend/public айнымалылары не source map арқылы жеке кілт бар ма?» Тек бастапқы .env файлын емес, құрастырылған файлдар мен браузердің желілік жауаптарын тексеріңіз. Git-тен шығару мәнді frontend жинағынан алып қалмайды.

3. Деректердің сақтық көшірмесін жасаңыз

   Дерекқор автоматты түрде бір жерде сақталып жатқанына көз жеткізіңіз. Егер жобаңыз өз серверіңізде іске қосылса, жариялау туралы Coolify нұсқаулығында түсіндіремін.

4. Жарияланған нұсқа өз құрылғыңыздан тыс жерде де жұмыс істейді

   Жобаны өз компьютеріңізден ғана емес, сыртқы сілтеме арқылы телефоннан ашыңыз. Жергілікті жерде жұмыс істейтін нәрсе жарияланған соң әрдайым істей бермейді.

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

Тексеру тым ұзаққа созылса, ЖИ-ға сене салу керек пе?#

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

Claude Code жасаушысы бұған одан да кеңірек қарайды:

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

Тексеру неге бір реттік тапсырма емес, дағды?#

Осы жеті тексеру «іске қостым да, үміттенемін» мен «іске қостым және жұмыс істейтініне көзім жетті» дегеннің арасын ажырататын ең аз жиынтық. Бір рет орындасаңыз, тосын мәселелердің көбін клиенттеріңіз байқамай тұрып-ақ табасыз.

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

ЖИ көшірмесі, Екінші ми және Контекст инженериясы — құралдармен жұмыс істеу туралы қосымша материалдарды Ailoot құжаттамасынан таба аласыз.