Как да прегледате код, генериран от AI

За да прегледате код, генериран от AI, започнете с това какво е променено – кои файлове и защо – след това тествайте поведението сами, преди да прочетете който и да е ред код. После проверете местата, където AI кодът най-често се обърква: липсващи проверки на права от страна на сървъра, тайни, достъпни за браузъра, непроверени входни данни, пакети или функции, които не съществуват, и промени в неща, които никога не сте поискали да пипа.

AI пише код, който обикновено работи и често изглежда подреден. Това прави лесно да го одобрите, без наистина да го проверите. Това ръководство е рутина за преглед, която работи, независимо дали четете код свободно, или изобщо не го четете.

Съобразете прегледа с риска

Не всяка промяна изисква еднакво внимание.

Стъпка 1: Вижте какво е променено

Преди да оцените кода, вземете списъка с промените:

• Ако проектът е в Git, разгледайте diff-а: файловете и редовете, променени от последния commit. Вижте как да използвате Git с приложение, създадено с AI.
• Или попитайте AI директно:

Изброй всеки файл, който си променил в последната промяна, и за всеки обясни с едно изречение какво е променено и защо.

Червени флагове на този етап: файлове, несвързани със заявката, изтрити файлове, промени в конфигурация или зависимости, които не сте поискали.

Стъпка 2: Първо тествайте поведението

Четенето на кода ви казва какво трябва да прави; тестването ви казва какво прави. Преди да четете:

• Пробвайте промяната като обикновен потребител, на десктоп и на екран с размер на телефон.
• Пробвайте с грешни входни данни: празни полета, много дълъг текст, отрицателни числа, дата в миналото.
• Пробвайте без вход и като друг потребител.
• Изпълнете отново потоците, които са най-важни: регистрация, вход, основното действие, плащане.

Ако тестването се провали, си спестили време за четене – докладвайте ясно и оставете AI да го поправи. Вижте как да напишете добър доклад за грешка.

Стъпка 3: Проверете правата на сървъра

Най-важното нещо за проверка. AI инструментите често скриват бутон в страницата, но оставят сървъра готов да изпълни действието за всеки, който го поиска.

За всеки маршрут или функция, която чете или променя данни, попитайте:

• Проверява ли дали потребителят е влязъл?
• Проверява ли дали този потребител има право да достъпи този запис?
• Тази проверка на сървъра ли е, а не само в страницата?

За всеки API маршрут, който си добавил или променил, кажи каква проверка на права прави на сървъра, като цитираш реда. Маркирай всеки маршрут без такава.

После го тествайте: влезте като потребител A, запишете ID на запис, влезте като потребител B и заявете същия запис. Контролният списък за сигурност за приложения, създадени с AI съдържа пълния тест.

Стъпка 4: Търсете изтекли тайни

• Търсете в променените файлове нещо, което прилича на ключ или парола.
• Проверете дали тайните ключове се четат от променливи на средата и се използват само в сървърния код.
• Внимавайте за публични префикси като VITE_ или NEXT_PUBLIC_ при тайни променливи – те се вграждат в кода на браузъра.

Вижте как да пазите API ключовете в безопасност.

Стъпка 5: Проверете входа и грешките

• Валидация на сървъра. Проверките в браузъра могат да бъдат заобиколени. Задължителните полета, дължините, форматите и допустимите стойности трябва да се проверяват и от сървъра.
• Заявките към базата данни използват параметри, а не текст, изграден чрез свързване на входни данни от потребителя в заявката.
• Грешките не се поглъщат. try/catch, което не прави нищо, скрива проблеми. Грешките трябва да се записват в логове, а потребителите трябва да виждат ясно съобщение.
• Вътрешни детайли не се показват на потребителите – стек трасетата и грешките на базата данни принадлежат в логовете.

Стъпка 6: Проверете, че е истинско

AI моделите понякога създават код, който изглежда правилен, но се позовава на неща, които не съществуват.

• Пакети: всяка нова зависимост трябва да е реален, поддържан пакет с точно това име. Внимавайте с имена, които приличат на грешно изписани популярни такива.
• Функции и опции на API: ако кодът вика функция на библиотека или опция на външен API, която не сте виждали, проверете официалната документация.
• Placeholder код: търсете TODO, mock, fake, зададени примерни данни или функции, които връщат фиксирана стойност.

Добави ли нови пакети? За всеки дай точното име, за какво е и дали можем без него.

Стъпка 7: Проверете дали пасва

Кодът може да работи и въпреки това да направи приложението по-трудно за промяна по-късно:

• Дублиране. Същата логика, копирана на няколко места, ще се разминава.
• Последователност. Трябва да следва модела, който използва останалото приложение.
• Размер. Заявка от 20 реда, която е породила 600 реда, заслужава въпрос.
• Мъртъв код. Стари версии, оставени до новите.

Има ли в проекта код, който вече не се използва заради тази промяна, или логика, която е дублирана другаде? Не променяй нищо; просто ги изброи.

Често срещани грешки

• Одобряване, защото изглежда чисто. Подреденият код може все пак да пропусне проверка на права.
• Четене вместо тестване. Първо тествайте, после четете.
• Тестване само на основния път. Пробвайте лоши входни данни, грешния потребител и без вход.
• Игнориране на несвързани промени във файлове. Питайте защо са променени всички файлове.
• Пълно доверие в самопреглед. Използвайте прегледа на AI като първи етап и потвърждавайте с тестване.
• Преглеждане на цяла седмица промени наведнъж. Преглеждайте малките промени, докато се случват.

Контролен списък

• Знам кои файлове са променени и защо, и нищо несвързано не е променено.
• Промяната работи на десктоп и на телефон, с лоши входни данни, без вход и като друг потребител.
• Всеки маршрут с данни проверява вход и собственост на сървъра.
• Няма тайни в кода или в пакетите за браузъра.
• Входът се валидира на сървъра; заявките използват параметри.
• Грешките се записват в логове, не се поглъщат и не се показват подробно на потребителите.
• Новите пакети са реални и нужни; няма измислени функции или placeholder-и.
• Промените с висок риск са били прочетени внимателно и, където трябва, от втори рецензент.

Преглед на код в Mythex

• Режимът Ask отговаря на въпроси за кода, без да го редактира – идеален за заявки от типа „обясни всяка промяна“ и „кои маршрути нямат проверка на права“. Вижте Chat.
• Изгледът на кода показва дървото с файлове, редактора и терминала във всеки план (само за четене в Free, с възможност за редакция в Pro), така че можете сами да прочетете какво е променено. Вижте Code editor.
• /test кара агента да премине през прегледа като потребител и да докладва счупените потоци.
• Checkpoints ви позволяват да върнете промяна, която не минава прегледа.

Ако разработчик преглежда вместо вас, как да работите с разработчик по приложение, създадено с AI обяснява предаването; ако прегледът открие грешка, вижте как да отстраните грешки в приложение, създадено с AI.

Въпроси