Відкритий лист страховому ринку України — Ознайомитись

    Зворотній зв'язок

    Що кожен розробник має знати про LLM

    Що кожен розробник має знати про LLM (перш ніж звинувачувати інструмент)

    Коли хтось каже “ШІ написав поганий код,” ми завжди питаємо: а ти розумієш, з чим саме розмовляєш?

    Більшість розробників працюють з ШІ через агенти — Copilot, Cursor, Claude Code. Але агент — це лише водій. Двигун під капотом — це LLM. І якщо ти не розумієш двигун, то будеш постійно розчаровуватись, не розуміючи чому.

    Агент — це не LLM.

    LLM — це stateless-функція. Вона приймає текст, передбачає наступний токен і повторює. Без пам’яті. Без наміру. Без “розуміння” вашого проєкту. Кожен виклик починається з чистого аркуша — єдина “пам’ять” — це те, що вміщується в контекстне вікно.

    Агент — це шар зверху: він керує контекстом, викликає інструменти, читає файли, повторює при помилках. Коли Claude Code виправляє баг у 5 файлах, LLM не “бачить” усі 5 одночасно — агент подає їх стратегічно.

    Три речі, які реально змінюють підхід до роботи:

    1. Розбивайте великі задачі на маленькі. Модель має обмежену увагу — чим більше шуму в запиті, тим гірше вона фокусується. “Зроби рефакторинг модуля автентифікації” перевантажує її рішеннями. “Винеси валідацію токена в окрему функцію” дає чітку ціль. Менша задача = менше шуму = кращий результат.
    2. Показуйте, що хочете, а не чого не хочете. LLM побудовані для продовження патернів. Фраза “не використовуй класи” змушує модель думати про класи в першу чергу. Натомість опишіть, що ви хочете, і дайте короткий приклад стилю. “Використовуй функціональний стиль з ланцюжками filter/map” працює значно краще, ніж список заборон. Хороші приклади перемагають довгі пояснення.
    3. Ітеруйте, а не починайте заново. Багато розробників ставляться до кожного промпту як до іспиту з однієї спроби. На практиці поступова розбудова — “тепер додай обробку помилок,” “зроби це async,” “перейменуй для зрозумілості” — стабільно дає кращі результати, ніж спроба отримати ідеал з першого запиту. Кожне уточнення тримає модель сфокусованою на одній речі. Розмова — це інтерфейс, а не одна команда.

    Наш висновок після місяців щоденного використання: команди, які засвоїли ці основи, отримували помітно кращі результати з тими самими інструментами. Не завдяки вигадливішим промптам — тому що перестали воювати з архітектурою і почали працювати з нею.

    Яка концепція LLM найбільше змінила вашу роботу з ШІ-інструментами? Пишіть у коментарях.

    #AI #SoftwareEngineering #AIinPractice #EngineeringCulture #LLM #AgenticAI #DevTools