Печалби:
- Способност да обясни как асистентът за кодиране работи като езиков модел и концепциите за токен, контекстен прозорец, халюцинация
- Способност за разграничаване на софтуерни задачи, при които AI е силен и слаб с ментална карта
- Способност за прилагане на основния работен цикъл на предлагане-производство-проверка към техните собствени задачи
Денят на софтуерния разработчик рядко се прекарва в „писане на код от нулата“. реално време; Четене на кода, написан от някой друг, опит за възпроизвеждане на грешка, сканиране на дневника (редове на дневник, създадени от приложението по време на работа), писане на тестове, писане на PR (заявка за изтегляне - заявка за сливане, при която промяна на кода се изпраща за екипен преглед) обяснение и актуализиране на документацията. Изкуственият интелект (AI) е мултипликатор на скоростта, който може да се докосне до почти всички тези невидими работни места. Но първото условие за безопасното му използване е да разберете правилно какво е и какво не е.
В този раздел ние първо обясняваме основната технология на асистент за кодиране на обикновен език; след това създаваме ментална карта на силните и слабите страни на модела; И накрая, установяваме основната работна дисциплина, която ще използваме в целия модул: предлагане, производство, проверка. Тези три стъпки са гръбнакът на следващите единадесет части.
Забележка: Този модул е общо обучение. В критичен за сигурността софтуер (обработка на плащания, здравеопазване, удостоверяване, критична инфраструктура) изходът на AI не е заместител на преглед и одобрение от квалифициран инженер. AI е асистент; Подписващият е инженерът.
Какво всъщност прави асистентът за кодиране?
Повечето асистенти за кодиране са изградени върху голям езиков модел (LLM – AI, обучен върху огромни количества текст и код, който предвижда следващия най-вероятен „къс“). Моделът не "разбира" кода като човек; Той генерира най-вероятното продължение на контекста, който му давате, въз основа на моделите, които научава от огромен набор от примери. Този привидно прост механизъм дава изненадващо добри резултати на практика - защото повечето софтуер се състои от повтарящи се модели: HTTP заявка, цикъл, нулева проверка, тестов модел.
Три термина са критични тук. Token е най-малката единица, която моделът обработва чрез разделяне на текста; Това е приблизително няколко букви или част от дума. Контекстният прозорец е количеството токени, които моделът може да "види" наведнъж; Вашият код, съобщение за грешка и инструкция трябва да се поберат в този прозорец. Подкана представлява всички инструкции и контекст, които давате на модела. Качеството на резултата, който получавате, зависи пряко от тези две: колкото по-добър контекст и по-ясни инструкции давате на модела, толкова по-добър резултат ще получите. Лошият вход води до лош резултат, дори и да е интелигентен модел — класическото правило на софтуера „боклук вътре, боклук вън“ важи и за AI.
Карта на силните и слабите страни
За да насочите AI към правилните работни места, е необходимо да знаете къде блести и къде се спъва. Запомнянето на тази карта ще ви накара да се чудите с всяка следваща мисия: „Да възложа ли тази работа на AI или да я направя сам?“ Позволява ви да отговорите на въпроса за секунди.
Неговите силни страни са: Генериране на шаблонен код, превод от един език на друг, писане на регулярен израз (regex), описание на функция, създаване на тестов скелет, интерпретиране на съобщение за грешка, изготвяне на документация, предлагане на имена на променливи/функции и незначителни преработки (подобряване на структурата на кода, без да се променя поведението му).
Слабости: Познаване на специфичните за вашата компания бизнес правила, запомняне на цялата ви кодова база, действително изпълнение и проверка на кода, познаване на най-новите версии на библиотеката със сигурност, откриване на уязвимости в сигурността със сто процента гаранция. Най-опасното е халюцинацията: моделът измисля несъществуваща функция, библиотека или API (интерфейс, който позволява обмен на данни между приложения) на много убедителен език. Този риск всъщност може да се превърне във ваша полза, тъй като кодът, за разлика от обикновения текст, може да бъде тестван, за да се види дали „работи“ — просто не пропускайте стъпката за проверка.
Тип мисия
Ролята на AI
мъжка роля
Произвеждане на шаблон/скелет
произвежда чернова
Адаптира се, прегледи
Описание на кода
Дава кратко резюме
Проверява критичната част в кода
писмени тестове
Случаят предполага
Потвърждава покритието и точността
Критична за сигурността логика
полезна идея
Решението и отговорността са изцяло на хората.
Използване на API/библиотека
Генерира проба
Проверява съществуването и версията
архитектурно решение
Видове опции
Избира и защитава познавайки контекста
Стъпка по стъпка: Основен работен цикъл
- Изяснете задачата. Ако вие не можете да напишете това, което искате в едно изречение, не може и моделът. Колкото по-рано несигурността се просмуква във входа, толкова по-голяма става тя в изхода.
- Дайте контекст. Добавете съответния код, пълно съобщение за грешка, версия на език/рамка и ограничения към подканата. Не казвайте „поправете това“, кажете „Python 3.11, FastAPI 0.110; тази функция дава грешка 500, тя избухва, когато тялото на заявката е празно“.
- Роля и формат на налагането. Рамка като „Вие сте старши Go разработчик; просто дайте кода и обосновка от две изречения“ фокусира изхода.
- Поискайте малки. Разделете го на стъпки, а не на една гигантска заявка; Проверете всяка стъпка поотделно. Големите промени са рискови, защото са трудни за проверка и склонни към скриване на грешки.
- Проверете. Пуснете го, тествайте го, прочетете го визуално. Непровереният AI код е "скица", а не "решение". Това е най-неподлежащата на обсъждане стъпка от цикъла.
Три мини калъфа
Случай 1 — Спестяванията на време са реални, но скромни. Когато екип скелетонизира нови CRUD (Създаване-Четене-Актуализиране-Изтриване) крайни точки с AI, времето за първа чернова спадна от приблизително 40 минути на 8 минути. Въпреки това, с преглед и тестване, общото време беше 25 минути; така че реалната печалба е от 40 до 25, около 38%. Тази скорост, измерена вместо очакването „ускорихме се 10 пъти“, е устойчива печалба.
Случай 2 — Халюцинацията струва скъпо. Разработчик използва предложеното от AI повикване requests.get_json() без валидиране; Нямаше такъв метод (точно response.json()). Бяха загубени 20 минути, когато кодът не се компилира. Едно просто "съществува ли наистина този метод?" проверката би нулирала загубата.
Случай 3 — Добрият контекст удвоява резултата. За същия бъг единият разработчик просто написа „Получавам грешка“, а другият добави пълното проследяване на стека, версията и входната проба. Последният получи правилното решение от първия опит; Първият прекара три оборота. Разликата не беше в модела, а във входа.
Четири копируеми шаблона
Мощна подкана за стартиране с общо предназначение:
Роля: Вие сте опитен {{language}} разработчик. Задача: {{what_want}}Контекст:- Рамка/версия: {{framework_and_version}}- Ограничения: {{производителност, стил, правила за зависимост}}Правила:- Не използвайте несъществуваща библиотека/функция; Ако не сте сигурни, маркирайте го като „проверете“. - Първо дайте кратък план, след това кода, след това 2 изречения с обосновка. - Създаване на тестван, работещ код.
За да филтрирате несигурността обратно в модела:
Преди да решите задачата по-долу, избройте ПОНЕ 3 точки, които намирате за липсващи или неясни като въпроси. НЕ пишете код, преди да отговоря. Задача: {{task}}
За да направите изхода самопроверен:
Вие сте създали следния код. Сега сменете ролята си и критикувайте този код: - Избройте 3 случая (крайни случаи), които може да не работят. - Има ли някакви API/функции, които бихте могли да измислите? Марк.- Дайте коригирана версия.Код:{{code}}
За да разделите решение на опции:
Предложете 2-3 подхода за решение на {{problem}}. За всеки: кратко описание, плюс/минус, кога да изберете. Дайте в табличен вид. НЕ избирайте вместо мен; просто изясни варианта.
Слаба подкана / Силна подкана
Слаб: „Коригирайте грешката в този код.“ (Коя грешка? Кой език? Какво е очакваното поведение?)
Силно: "Python 3.11 / FastAPI 0.110. Следната крайна точка връща 500 с KeyError, когато тялото на заявката е празно; искам да върне 400 и смислено съобщение в празно тяло. Първо обяснете причината, след това дайте коригираната функция, след това напишете тест за този сценарий. [код]"
Мощна версия; Той дава езика, версията, действителната грешка, очакваното поведение и изходния формат. Моделът вече не трябва да предвижда.
Често срещани грешки
- Доверяване без проверка. Най-честата и най-скъпа грешка. Не казвайте „решено“, докато кодът не бъде компилиран и тестван.
- Задаване на въпроси без контекст. Отговорът без версия, текст за грешка и ограничения е общ и често грешен.
- Една огромна молба. Невъзможността да заявите и прегледате продукция от 300 линии наведнъж прави грешките невидими.
- Погрешно приемане на самочувствието на модела като доказателство. AI може уверено да каже нещо грешно; Тонът не е индикатор за точност.
- Произволно поставяне на фирмената тайна. Частни ключове, клиентски данни или частен изходен код не трябва да се въвеждат в неодобрени инструменти (ще разгледаме тази тема в раздел 10).
Съвет: Отнасяйте се към всеки резултат от AI като „това е чернова“. Този единствен умствен навик елиминира повечето от рисковете, които ще видите в целия модул.
В обобщение
Асистентът за кодиране е езиков модел, който предвижда следващия най-вероятен фрагмент; Не разбира кода, произвежда шаблони. Ето защо той е силен в повтарящи се, шаблонни задачи; Трябва да се използва предпазливо за работа, която изисква проверка, която е специфична за вашия контекст. Най-големият риск е халюцинацията, а единствената противоотрова е проверката. Дисциплината, която ще следваме през целия модул, е ясна: изяснете задачата, дайте контекст, поискайте малко, валидирайте всеки резултат.
Задача за приложение
Запишете три софтуерни задачи, които сте изпълнили през последната седмица (напр. корекция на грешка, тест, актуализация README). Погледнете „картата на силните и слабите страни“ за всеки и опишете с едно изречение каква ще бъде вашата роля и ролята на AI, ако накарате AI да направи това. След това дайте една от тези задачи на AI с шаблона „start prompt“ по-горе и стартирайте и проверете изхода; Отбележете колко минути сте спестили и колко грешки е трябвало да коригирате.
контролен списък
- [ ] Разбрах, че LLM създава модели, а не „разбира“ код.
- [ ] Мога да обясня понятията токен, контекстен прозорец и подкана в едно изречение.
- [ ] Мога да правя разлика между типове задачи, при които AI е силен и слаб.
- [ ] Знам какво е халюцинация и единствената противоотрова е проверката.
- [ ] Адаптирах цикъла „предложи, изработи, провери“ към собствената си задача.
- [ ] Мога да покажа разликата между силна подкана и слаба подкана в конкретен пример.