У спільноті AI‑інженерів ім’я Майкла Арнальді добре відоме завдяки бібліотеці Effect для TypeScript та його практичним експериментам з агентами, що пишуть код. На воркшопі на каналі AI Engineer він демонструє, як будувати застосунки на Effect разом із LLM‑агентами, але між рядками там звучить значно ширша тема: як влаштовані сучасні моделі для програмування, чому вони не «вчаться» від наших сесій і як обирати між закритими та open‑weights моделями.
Це вже не теоретична розмова. Арнальді прямо говорить, що щонайменше пів року взагалі не пише код руками — за нього це роблять моделі, причому як у TypeScript, так і в Rust. На цьому тлі питання, як саме тренуються такі моделі, що вони вміють і чого не вміють, перестає бути академічним і стає питанням щоденної інженерної практики.
Коли бібліотечний розробник перестає писати код руками
Майкл Арнальді програмує з 12 років і більшу частину часу працює на «бібліотечному рівні» — це низькорівневий, складний код із важкою типізацією, де потрібно глибоко розуміти мову, абстракції та те, як користувачі взаємодіятимуть із бібліотекою. Традиційно це саме той тип роботи, де автоматизація виглядала найменш імовірною: мало документації, майже немає готових прикладів, багато прихованих інваріантів.
Попри це, за його словами, останні шість–вісім місяців він фактично не писав код вручну. Увесь новий код — і для TypeScript, і для Rust — генерують LLM‑моделі. Спочатку він очікував, що ШІ буде кориснішим у «аплікейшн‑ленді», де багато шаблонів, CRUD‑логіки та повторюваних патернів. Але виявилося, що навіть для складних бібліотек сучасні моделі вже достатньо сильні, аби взяти на себе левову частку роботи.
Цей досвід важливий з двох причин. По‑перше, він демонструє, що поточний рівень можливостей LLM для кодування вже перетнув поріг «іграшки» і став інструментом для серйозної інженерії. По‑друге, він оголює обмеження: щоб моделі працювали на такому рівні, доводиться дуже чітко розуміти, як вони тренуються і як із ними взаємодіяти.
Як тренують моделі для програмування: від інтернету до компілятора
У масовій уяві LLM часто порівнюють із людським мозком: нібито це система, яка «вчиться» з досвіду, запам’ятовує розмови, накопичує знання. Арнальді наполягає: це хибна метафора. Архітектурно й організаційно сучасні моделі влаштовані зовсім інакше.
Він описує три великі етапи життєвого циклу моделі.
Спочатку — передтренування. Модель «дивиться» на гігантський масив тексту, зазвичай це значна частина публічного інтернету та інші великі корпуси. На цьому етапі вона вчиться базовій статистиці мови, загальним знанням, структурі коду, але без спеціалізації на конкретних задачах.
Далі йде спеціалізація. Модель донавчають на більш таргетованих даних: наприклад, на коді, технічній документації, задачах певного типу. Це робить її кориснішою для конкретних доменів, але все ще без чіткої поведінкової «політики».
Нарешті, пост‑тренування. Саме тут з’являються моделі, орієнтовані на програмування. За словами Арнальді, кодові LLM проходять етапи reinforcement learning на кодових базах. Їм дозволяють «рватися» крізь репозиторії, вносити зміни, а потім оцінюють результат: чи компілюється код після змін, чи проходять тести, чи не зламалися інваріанти. Ці оцінки повертаються в тренувальний цикл і коригують політику моделі.
Ключовий момент: для кодових моделей важливим сигналом стає саме компіляція та поведінка коду, а не красивість тексту чи стилістика. Це формує специфічну «інтуїцію» моделі: вона навчається не лише продовжувати текст, а й робити зміни, які з більшою ймовірністю збережуть працездатність системи.
Саме тому такі моделі добре поводяться в реальних репозиторіях: вони звикли до задач на кшталт «зміни цей файл так, щоб усе ще компілювалося». Але це також пояснює, чому вони не надто добре працюють із документацією чи зовнішніми сервісами: на них їх просто не вчили.
Чому LLM не пам’ятають ваші сесії і що таке контекстне «забування»
Після завершення цих трьох етапів модель, по суті, «заморожується». Вона більше не отримує нових знань від користувачів. Арнальді підкреслює: на відміну від людського мозку, який безперервно перетворює досвід на довгострокову пам’ять, LLM не мають механізму постійного навчання в продакшені.
Якщо сьогодні змусити модель виконати задачу певним специфічним способом, завтра вона цього не «згадає». Вона не будує персоналізовану історію взаємодії з конкретним розробником чи командою. Усе, що вона «пам’ятає» в межах однієї сесії, — це вміст контекстного вікна.
Арнальді пропонує дивитися на взаємодію з моделлю як на роботу з фіксованим масивом повідомлень. Кожен новий запит і відповідь додаються в цей масив, поки не буде досягнуто межі контексту. Далі старіші повідомлення починають викидатися або стискатися. Жодного «нічного сну», під час якого модель інтегрує новий досвід у свої ваги, не існує.
Це має два наслідки.
По‑перше, знання моделі завжди відстають від реальності. Навіть якщо її перенавчають кожні кілька місяців, між зрізами тренувальних даних завжди є лаг. Арнальді оцінює, що в кращому разі модель має знання «шестимісячної давності».
По‑друге, великі контекстні вікна не є панацеєю. Сьогодні на ринку вже є моделі з контекстом у мільйон токенів, але, як зауважує Арнальді, це може більше шкодити, ніж допомагати. Усе, що потрапляє в контекст, подається на вхід нейромережі, яка намагається передбачити наступний токен. Якщо туди звалити забагато різнорідної інформації, модель легко заплутати. Особливо це помітно, коли в одному контексті змішують кілька задач, різні проєкти чи стилі.
Звідси випливає архітектурний висновок: інженерам доводиться будувати навколо LLM інфраструктуру, яка компенсує їхню «дурість» і відсутність пам’яті. Моделі сильні в узагальненні та локальному міркуванні, але слабкі в довгостроковому накопиченні знань і управлінні великими обсягами контексту.
Моделі для коду: чому вони дивляться на ваш репозиторій, а не на документацію
Розуміння того, як тренуються кодові LLM, пояснює й те, як із ними варто працювати. Арнальді наголошує: моделі, які використовуються як агенти для програмування, тренувалися насамперед на споживанні та продукуванні коду, а також на операціях у межах користувацького репозиторію.
Їх не вчили читати людську документацію як основне джерело істини. Їх не вчили працювати з MCP‑серверами чи іншими допоміжними шарами, які з’явилися вже пізніше. Вони оптимізовані під те, щоб дивитися на файли в проєкті, змінювати їх і перевіряти, чи все ще «збирається».
Звідси випливає практичний висновок: якщо хочеться, щоб агент добре використовував певну бібліотеку, найнадійніший спосіб — зробити її код частиною того самого простору, який модель сприймає як «ваш репозиторій». Саме тому Арнальді в своїй роботі просто клонує репозиторій Effect у директорію проєкту й маскує його під частину власного коду. Так модель починає досліджувати бібліотеку так само, як і будь‑який інший модуль застосунку, витягуючи патерни безпосередньо з вихідників.
Це також пояснює, чому покладатися на node_modules як на «джерело правди» для агента неефективно. Під час тренування моделі вчили фокусуватися на «користувацькому» коді, а не на залежностях. Якщо бібліотека лежить у node_modules або навіть у git‑ignored директорії, агент із великою ймовірністю просто не буде її активно сканувати. Деякі інструменти, на кшталт Cursor, додатково не індексують файли, які ігноруються Git, що ще більше зменшує шанси, що модель звернеться до цих джерел.
У результаті найпростіша й найнадійніша стратегія, яку Арнальді формулює майже як мантру, — «просто клонувати репозиторій». Зробити бібліотеку частиною того самого дерева файлів, де працює агент, і дозволити моделі вчитися на коді, а не на документації. Це не суперечить тому, що модель не «вчиться» у довгостроковому сенсі: вона не змінює свої ваги, але в межах поточного контексту може побудувати досить багату картину патернів і структур, якщо їй дати правильний доступ.
GPT 5.4 проти GPT‑4: еволюція кодових моделей і відставання open‑weights
У воркшопі Арнальді використовує GPT 5.4 як основну модель для кодування. Раніше він працював із GPT‑4 (у його термінах — «set 4») і порівнює ці покоління досить образно: GPT‑4 нагадував «дитину з ножем, яка бігає по дому». Модель уже була достатньо сильною, щоб писати код, зокрема й на бібліотечному рівні, але поводилася непередбачувано, часто робила небезпечні чи дивні кроки.
Новіші моделі, такі як GPT 5.4 чи Opus 4.5, на його досвіді значно стабільніші й краще пристосовані до складних кодових задач. Це не означає, що вони безпомилкові, але рівень «хаосу» помітно зменшився, а здатність утримувати складні інваріанти й працювати з нетривіальними абстракціями — зросла.
На цьому тлі особливо цікаво виглядає порівняння з open‑weights моделями. Арнальді оцінює, що відкриті моделі відстають від «фронтирних» пропрієтарних систем приблизно на три–шість місяців за можливостями. Це не прірва в роки, а радше часовий лаг: те, що сьогодні вміє GPT 5.4, через кілька місяців, імовірно, з’явиться в найкращих open‑source моделях.
Цей лаг уже сьогодні має практичні наслідки. Арнальді нагадує, що він успішно використовував GPT‑4 для бібліотечного розроблення ще до появи нинішніх поколінь. Якщо зараз у відкритому доступі є моделі, які за рівнем можливостей наближаються або навіть перевершують GPT‑4, то питання не в тому, «чи зможуть open‑weights моделі колись писати серйозний код», а в тому, коли саме вони стануть достатньо надійними для щоденних задач.
Водночас він звертає увагу на політичні та бізнесові ризики. Деякі вендори, зокрема Anthropic, вводять доволі жорсткі обмеження на використання своїх моделей, що робить їх менш привабливими для глибокої інтеграції в інженерні процеси. OpenAI наразі виглядає прийнятно, але немає гарантій, що через рік‑два політика не зміниться. На цьому тлі симпатія до open‑source виглядає не лише ідеологічною, а й прагматичною: контроль над моделлю означає меншу залежність від зовнішніх рішень.
Архітектура навколо «дурної» машини: як жити з обмеженнями LLM
Усі ці спостереження зводяться до однієї простої, але важливої тези: навіть якщо модель здається «розумною», інженер має поводитися з нею як із дуже потужною, але фундаментально «дурною» машиною. Вона не пам’ятає минулого, не розуміє контексту поза своїм вікном, не має цілей і не оновлює знання між сесіями.
Арнальді описує це як необхідність «архітектувати навколо тупого процесу». Модель має стиснене, застаріле уявлення про світ, обмежений контекст і здатність до узагальнення, але не до накопичення. Навіть якщо збільшити кількість параметрів до трильйона чи десяти трильйонів, цього не вистачить, щоб зберегти всю людську інформацію. Знання завжди будуть компресованими, а поведінка — результатом статистичного узагальнення, а не точного відтворення фактів.
На практиці це означає кілька речей.
По‑перше, потрібно свідомо керувати контекстом. Замість того щоб намагатися запхати в одне вікно «все й одразу», краще розбивати роботу на невеликі, чітко окреслені задачі. Арнальді, наприклад, запускає кодового агента через bash‑скрипт у циклі: дає невелике завдання, дозволяє йому виконати його, потім процес завершується, і наступна задача починається з чистішого контексту. Це допомагає уникати накопичення шуму й плутанини.
По‑друге, потрібно підсовувати моделі правильні джерела знань. Якщо кодові LLM тренувалися на репозиторіях, то найкращий спосіб «навчити» їх новій бібліотеці — зробити її частиною того самого дерева файлів, де вони працюють. Звідси стратегія «клонувати репозиторій» як базова інженерна практика.
По‑третє, варто приймати як даність, що модель не запам’ятає ваші інструкції назавжди. Якщо потрібна стабільна поведінка, її доведеться кодувати в інструменти, скрипти, конфігурації, а не сподіватися, що «модель звикне». Усе, що не потрапляє в контекст поточної сесії, для неї не існує.
Це не применшує досягнень LLM. Навпаки, на тлі цих обмежень той факт, що Арнальді вже пів року не пише код руками, виглядає ще вражаюче. Машина, яку він називає «тупою», уже достатньо сильна, щоб брати на себе складні бібліотечні задачі в TypeScript і Rust. Але саме тому так важливо розуміти її реальну природу, а не приписувати їй людські якості.
Висновок: тверезий погляд на «розумні» моделі
Історія Майкла Арнальді — це не стільки про те, як LLM «замінили» йому ручне програмування, скільки про те, як змінюється роль інженера в епоху кодових моделей. З одного боку, моделі вже сьогодні здатні писати складний, типобезпечний код на рівні бібліотек. З іншого — вони залишаються інструментами з чіткими архітектурними обмеженнями: без пам’яті, без безперервного навчання, із крихким контекстом.
Розуміння того, як вони тренуються — від масового передтренування до reinforcement learning на кодових базах, — дозволяє будувати навколо них правильні практики. Замість того щоб сподіватися, що модель «прочитає документацію», варто дати їй вихідний код. Замість того щоб покладатися на «величезний контекст», краще розбивати роботу на малі кроки. Замість того щоб чекати, що вона «запам’ятає» ваш стиль, потрібно кодувати правила в інструменти й репозиторії.
На тлі швидкої еволюції — від GPT‑4 до GPT 5.4 і далі, з open‑weights моделями, що наздоганяють фронтир із лагом у кілька місяців, — такий тверезий, інженерний погляд стає ключовим. Моделі стають потужнішими, але не стають «людськішими». І саме це розуміння дозволяє перетворити їх із модної іграшки на справжній робочий інструмент.
Джерело
Відео «Vibe Engineering Effect Apps — Michael Arnaldi, Effectful» на YouTube