Чи може AI в AL? Тестування LLM на реальному завданні open source проєкту Data Editor

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Привіт! Мене звати Володимир і я працюю в beeDynamics на позиції розробника Business Central. Я регулярно пишу технічні статті в своєму блозі. Також підтримую декілька open-source проєктів, детальніше в профілі github.

Microsoft Dynamics 365 Business Central — це комплексне рішення для управління бізнесом, яке допомагає невеликим і середнім компаніям об’єднувати роботу своїх команд у сфері фінансів, продажу, послуг та операцій на платформі єдиної зручної програми.

AL — це мова програмування для Microsoft Dynamics 365 Business Central.

У цій публікації я пропоную розглянути, наскільки LLMs придатні для написання AL-коду в реальних завданнях. Як приклад я використаю реальне завдання для open source проєкту Data Editor. Цю задачу я відкладав досить тривалий час. Для порівняння я обрав найпотужніші та найпопулярніші моделі: Claude 4 Sonnet, GPT-5 High, Grok 4 і Gemini 2.5 Pro.

Зміст

1. Вступ
2. Завдання
3. Промпт та моделі
4. Grok 4
5. Gemini 2.5 Pro
6. GPT-5 High
7. Claude 4 Sonnet
8. Людський варіант
9. Валідація та тести
10. Огляд результатів
11. Висновки

Вступ

Під час розробки проєктів код має схильність накопичувати сумнівні рішення, застарілі патерни та короткочасні виправлення. Це технічний борг, і я переконаний, що він неминучий, коли проєкт активно еволюціонує з часом. Існує багато способів зменшити технічний борг, але сьогодні це не тема допису.

Open-source проєкт Data Editor не є винятком. Попри мої зусилля запобігти цьому, технічний борг усе ж може з’являтися. Проєкт почався тоді, коли моя дівчина, тестувальниця Business Central, зауважила, що в Business Central версії 15 і новіших не можна редагувати дані. Вона запропонувала створити застосунок, щоб вирішити це обмеження. Прийшовши з старіших версій ERP (RTC/Classic), це обмеження здавалося суттєвим, тож виникла ідея, і я спроєктував найпростішу можливу реалізацію, яка нагадувала б попередній досвід користувача. Спочатку це був невеликий застосунок для внутрішніх потреб тестування. Найперша версія була написана швидко, «просто щоб працювало», що неминуче від самого початку створило чималу частку технічного боргу.

Звісно, після того як я побачив великий інтерес від багатьох людей і компаній, я неодноразово рефакторив і вдосконалював Data Editor. Втім, до недавнього часу в коді залишалася частина, яка мені не подобалася, і я відкладав її, просто тому, що проблема не впливала на функціональність.

Завдання

Якщо подивитися на попередню версію Data Editor, можна побачити, що три окремі об’єкти дублювали одні й ті самі права доступу для конкретних таблиць.

• Cod81001.DETDataEditorMgt.al
• Pag81000.DETDataEditorBuffer.al
• Pag81004.DETInsertNewRecord.al

Це створювало очевидну проблему супроводу: потрібно було тримати права доступу узгодженими в трьох місцях із реальним ризиком щось пропустити. Це було незручно та складним в підтримці.

Згодом один із контриб’юторів проєкту запропонував вирішити цей технічний борг за допомогою LLM. Мені це здалося цікавим, тому що LLM зрештою не впорався із завданням. Той досвід спонукав мене розробити власний бенчмарк LLM і надихнув на цей порівняльний пост.

Промпти та моделі

Будь-яка взаємодія з LLM починається з написання prompt. В ідеалі prompt має чітко описувати, що потрібно зробити, а саме завдання має бути коротким та зрозумілим. На практиці це не завжди можливо й може займати багато часу. Тому я обрав стратегію одного prompt в agent-thinking mode, зробивши його конкретним, але не надто деталізованим. Якщо робити prompt ще більш дрібним і продовжувати ітерації, дуже швидко доходиш до точки, що швидше і простіше зробити все самостійно.

Я все ж таки вважаю цей prompt достатньо деталізованим, тому що використав власні знання й контекст, щоб акцентувати, на чому й де зосередитися. Іноді це просто неможливо, адже повне розуміння завдання може сформуватися аж в процесі роботи. Крім того, агент має доступ до AL лінтера та аналізаторів коду, тож будь-які очевидні помилки AL були доступні моделям для аналізу.

I have a tool to edit data in Business Central called Data Editor. This is the codebase for this tool.

I have one concern. I have 3 files with the same permissions: @Pag81000.DETDataEditorBuffer.al, @Cod81001.DETDataEditorMgt.al, @Pag81004.DETInsertNewRecord.al.

I would like to isolate these permissions in one object, as it is hard to manage and keep them in sync every time.

At the same time, these direct permissions are required for any READ/MODIFY/INSERT/DELETE operations,

So changes should take into account cases where Modify/Insert/Delete may be present in OnValidate of any field (RecordRef/FieldRef).

In addition, any Get/Find/Next is essentially a record read, which requires permissions to do so.

Для тесту я обрав найбільш популярні та потужні моделі LLM, доступні на сьогодні, а саме:

• Claude 4 Sonnet
• GPT-5 High
• Grok 4
• Gemini 2.5 Pro
• Людський варіант

У цьому наборі «Людський варіант» представляє моє власне рішення задачі.

Чому саме ці моделі? Тому що вони найпотужніші з наявних сьогодні, і я хочу отримати найкращий можливий результат.

Для тестів я використовував Cursor IDE (fork від VS Code). Вважаю, що VS Code + Copilot дадуть подібний результат.

Grok 4

Це доволі нетипова модель із власними сильними сторонами. Однак написання коду явно не краща її сторона. У моїх тестах вона стабільно вражала актуальністью даних та відносно мінімальною фільтрацією контенту. Як співрозмовник або інструмент для пошуку найновішої інформації це може бути хорошим вибором. Як модель для коду — під питанням, а її думки на будь-яку тему варто сприймати обережно, так як можлива сильна особиста упередженість.

Модель не змогла виконати завдання і, що гірше, залишила проєкт у стані, що не компілюється. Імовірно, вона погано працює з великими файлами попри заявлене 256,000 token context window.

Гірше того проєкт не компілюється через некоректне розміщення змінної, яку модель вставила не в те місце. Модель справді почала з правильної ідеї, запровадивши окремий codeunit, Data Operations, але проігнорувала ключові деталі з prompt, пропустила багато місць, де відбуваються операції з даними, і додала цілком нерелевантну процедуру TextValueAsVariant у Data Operations. З якоїсь причини модель вирішила не виправляти код, що не компілюється, хоча бачила всі помилки.

Тут ви можете переглянути повний список змін. На мою думку, результат — повний провал.

Gemini 2.5 Pro

Gemini — дуже креативна й швидка модель, а її one-million-token context window вражає. Знаю, що це улюблена модель для багатьох розробників, особливо з огляду на низьку вартість і можливість безкоштовного використання в Google AI Studio.

За моїм досвідом, це не найкраща модель для коду, хоча й досить сильна. Часто я бачив, як вона видає загалом «середнє» рішення, але при тому створює один конкретний компонент, який справді вражає. Модель блискуче генерує нові ідеї та креативні підходи.

Хоча ця модель також залишила проєкт у стані, що не компілюється, вона впоралася відчутно краще. Вона застосувала цікаву й теоретично коректну ідею: створити новий Permission Set для агрегування всіх тих прав доступу до таблиць. Однак вона проігнорувала помилку компілятора, яка вказує, що довжина назви Permission Set не повинна перевищувати 20 символів.

Створення такого Permission Set технічно працюватиме, але це не найкраще рішення. З погляду безпеки я не хотів би вводити такий набір прав із прямим доступом до таблиць. Підхід креативний, але небезпечний. Також я не хочу додавати додатковий Permission Set, який може вплинути на зворотну сумісність із попередньою версією, адже ці права також доведеться призначати користувачам, які вже використовують застосунок.

Тут ви можете переглянути повний список змін, на мою думку, результат невдалий, але кращий за попередній.

GPT-5 High

Моделі OpenAI загалом вважають одними з найкращих, якщо не найкращими. Вони дуже розумні та потужні, але не найшвидші і дорогі. Я часто використовую їх для широкого спектра завдань, від створення підсумків до дослідження питань із фізики.

GPT-5 High чудово пише код, але я не вважаю його найкращим в agent mode. Схоже, у цьому режимі модель має труднощі. Крім того, вона дуже дорога й повільна. Згідно з останньою інформацією, GPT-5 model offers a 400,000-token context window. Головне не плутати її з GPT-5 Chat або GPT-5 Mini, адже це різні моделі. На жаль, найменування від OpenAI досі заплутує.

Варто відзначити, що після змін моделі проєкт успішно компілюється, це очевидна перевага над попередніми моделями. Модель відстежує помилки навіть якщо це не зазначено явно, і я вважаю це правильним підходом. Якщо модель змінює код, який раніше компілювався, вона повинна переконатися, що після завершення роботи код і далі компілюється.

Модель також пішла правильним шляхом, винісши потрібні процедури в окремий codeunit і вирішивши повторно використати для цього наявний Cod81001.DETDataEditorMgt.al. Це працючий варіант, але з архітектурного погляду не ідеальний. Крім того, замість ізоляції лише конкретних точок взаємодії з даними, модель перенесла цілі процедури, що теж є дискусійним рішенням.

На жаль, модель не помітила всі місця, де відбуваються операції з даними, хоча я явно виділив зони уваги в prompt. Внаслідок цього рішення вийшло неповним і лише частково функціональним. Для продукту, який активно використовують багато людей, це явно неприйнятно.

Тут ви можете переглянути повний список змін, на мою думку, результат частково успішний.

Claude 4 Sonnet

Я вважаю моделі Anthropic найсильнішими для коду, особливо в agent mode. Сказав би, що в інших типах завдань вони вражають менше, але для коду ймовірно найкращі. Тому я покладав на цю модель високі очікування щодо виконання завдання. Вона досить дорога, хоча й не найдорожча серед конкурентів. На мою думку, якість виправдовує вартість. Її 1-million-token context window величезний.

На щастя, модель не підвела. Серед усіх моделей у цій статті вона найбільше наблизилася до оптимального рішення. Її підхід полягав у винесенні операцій з даними в окремий об’єкт, Cod81010.DETPermissionsProvider.al, який ізолює всі права доступу. Важливо, що вона перенесла лише необхідні операції, а не цілі процедури, які просто їх містили.

Також зазначу, що модель знайшла майже всі місця в коді, де це потрібно було зробити, і навіть розпізнала, що CalcFields можуть бути потенційним ризиком, хоча я цього прямо не вказував. Але це все ж не ідеально, кілька сценаріїв були пропущені. Тому, попри найсильніший результат, я не можу назвати його повним рішенням, хоча він дуже близький.

Мене також запитали, чому не тестувалась модель Claude Opus 4? Особливо з огляду на те, що її вважають найрозумнішою моделлю від Anthropic. Причина в тому, що після виходу версії 4.1 модель здалася мені надто непослідовною, навіть гіршою за Sonnet 4. Після отримання цього запитання я спробував її ще раз, і результати все одно виявилися незадовільними. Ви можете переглянути результат тут. Мені здається, що він трохи нижчий за GPT-5 High, наче модель зробила забагато зайвої роботи, так і не виконавши всього необхідного.

Тут ви можете переглянути повний список змін, на мою думку, результат частково успішний.

Людський варіант

На жаль, жодне зі створених LLM-рішень не було повним або production ready. Тому я вирішив реалізувати власне рішення, яке повністю задовольняє мої вимоги до надійності й не створює додаткових проблем для користувачів. По суті, мій підхід дуже схожий на Claude 4 Sonnet: винести окремий об’єкт для операцій із даними й призначити всі потрібні права доступу саме там, нічого надто складного.

Я також зауважив, що немає сенсу використовувати direct permissions на об’єкті, оскільки за ефектом вони не відрізняються від indirect permissions. Це стосується лише object-level permissions. Тому я перейшов із direct на indirect permissions, див. Cod81003.DETDataOperations.al. Жодна з моделей цього не помітила.

Тут ви можете переглянути повний список змін, на мою думку, результат повністю успішний.

Валідація та тести

Також жодна з моделей не створила функціональних тестів для Permissions, бо моделям бракувало знань і контексту, необхідних для їх написання. Саме тому використання MCP, ймовірно, нічого б не змінило. Тести, які генерували моделі, фактично нічого не перевіряли, але показували «success».

Щоб оцінити результат кожної моделі та «людський варіант», необхідно виконати валідацію, і для цього є багато методів. По-перше, найпростіший підхід — застосувати сіру речовину у власній голові. Простіше кажучи, знання та досвід розробника. Досвідчений розробник може оцінити якість відповідей на підставі свого досвіду та знань.

Ручне тестування — ще один можливий шлях. Як і перший метод, він не дає абсолютних гарантій, але разом ці підходи забезпечують практичний спосіб порівняти результати й розмістити варіанти відносно один одного.

Я використав власні знання та досвід для оцінки рішень і вручну протестував кожен варіант. Додатково я запровадив третій метод валідації: нові автоматизовані тести, призначені для перевірки того, як застосунок поводиться з мінімальними наборами прав. Важливо зазначити, що ці тести поки що не покривають усі сценарії, у майбутньому я планую розширити кількість автоматизованих тестів для Data Editor.

Підсумовуючи, я оцінював якість рішень трьома методами:

• Особистий досвід і знання.
• Ручне тестування.
• Автотести.

Огляд результатів

Виходячи з моїх методів валідації, результат такий:

Висновки

Варто пам’ятати, що це були завдання з однією спробою. Я міг продовжувати просити LLM виправляти проблемні місця. Однак, як я вже зазначав, якщо відносно просте завдання потребує більше часу на взаємодію з LLM, ніж на його ручне розв’язання, користь різко падає. До того ж прохання щось виправити означає, що потрібно явно вказати проблему, що своєю чергою вимагає вже мати повне розуміння завдання й уміти виконати його самостійно.

Тому я не вірю у «vibe coding». Це не працюючий концепт сьогодні й, можливо, ніколи не стане працюючим.

Водночас я впевнений у корисності LLM, просто не для кожного завдання. Ефективна робота з LLM це не лише написання prompt та інструкцій, а й розуміння того, які проблеми їм підходять найкраще. Чим менше можливих шляхів розв’язання і що більше ви надаєте контексту, тим кращими будуть результати.

Також не слід очікувати, що LLM спроєктує надійну архітектуру проєкту. Краще створити архітектуру самостійно, а потім інструктувати модель працювати в межах архітектури.

Ось чому мені подобається позиціонування Microsoft Copilot, як асистента, а не заміни людині. З огляду на мій досвід і численні тести, це влучне позиціонування. Без фахового нагляду й особистої експертизи ви не зможете валідувати результати галюцинацій LLM.

Отже, мої висновки з попередньої роботи з моделями та цього експерименту. Вони актуальні для мене станом на сьогодні й можуть змінитися:

• Vibe coding не працює.
• LLMs генерують не production-ready код, потрібна валідація.
• Найкращі моделі для коду від Anthropic, наприклад Claude 4 Sonnet.
• Найкращі моделі для більшості інших завдань від OpenAI, наприклад GPT-5 High.
• LLMs все ще галюцинують і припускаються помилок.
• LLMs залишаються дуже корисними в багатьох завданнях, включно з написанням коду.
• Технологія чудова, але хайпу значно більше, ніж потрібно.
• Ефективна робота з LLMs потребує експертизи, не лише доменної, а й навичок у використанні самих моделей.
• AI може в AL 🙂

See English version in blog.