Когато AI асистентите за кодиране спират да работят: Как да променим подхода си

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

Причината обикновено не е в самия модел. Проблемът е в това, какво точно му искаме.

От лесни задачи към сложни промени

AI инструментите като Claude и GPT-4 са добри в малките, прецизни корекции. Те разбират структурата на проекта, спазват стила на кода и правят промени, които не нарушават съществуващите тестове. Това работи отлично, докато искаме само да подобрим нещо в работещата система.

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

Какво се случва с потреблението на токени

Когато опитваме да преустроим модул с помощта на AI:

• Асистентът се опитва да запази всички съществуващи тестове
• Новата структура не съвпада с тях
• Моделът прави минимални промени, за да избегне конфликти
• Ние настояваме още по-настойчиво
• Разходът на токени расте, а отговорите стават неясни

Моделът не се „разваля“. Просто се опитва да изпълни противоречиви инструкции.

Защо се получава така

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

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