У серпні 2026 року на arXiv з'явився огляд, який фіксує помітний зсув у тому, як великі мовні моделі застосовують у проєктуванні мікросхем: роль LLM зміщується від генератора HDL-коду до диспетчера, що керує цілим інженерним пайплайном — від технічної специфікації до верифікації готового дизайну.

EDA (Electronic Design Automation) — один з найвибагливіших доменів для будь-якого AI-інструменту. Помилка в софті лагодиться патчем за годину, помилка в кремнії виявляється лише після виробництва партії чипів і коштує місяців затримки та мільйонів доларів. Якщо LLM дозріли настільки, щоб брати на себе більше, ніж просто написання рядків Verilog, це показовий кейс для будь-кого, хто будує AI-агентів у складних технічних доменах.

За даними arXiv, автори огляду розглядають цей перехід як наступний етап зрілості LLM у вузькоспеціалізованих інженерних доменах — не окрему аномалію EDA, а закономірний крок розвитку.

Що саме змінилося в ролі LLM для проєктування чипів?

Спершу LLM у EDA використовували як генератор коду: модель отримувала природномовний опис модуля й видавала готовий блок Verilog або VHDL — за аналогією з тим, як Copilot автодоповнює функцію. Це працювало для ізольованих фрагментів, але не покривало решту циклу — синтез, тестування, фізичне розміщення елементів на кристалі.

Тепер, за оглядом, LLM дедалі частіше стають шаром координації над усім цим ланцюжком: модель інтерпретує специфікацію, викликає інструменти синтезу та верифікації, читає їхній вивід (звіти про таймінги, помилки правил проєктування) і вирішує, що робити далі — переписати модуль, змінити обмеження чи запустити наступний крок пайплайна.

Чим оркестрація принципово відрізняється від генерації коду?

Генерація — це одноразовий акт: запит на вході, код на виході. Оркестрація — це цикл із зворотним зв'язком, у якому модель постійно звіряється зі станом проєкту через існуючі EDA-інструменти. У типовому оркестрованому пайплайні LLM бере участь на кількох етапах одразу:

• інтерпретація специфікації та розбиття її на підзадачі для окремих модулів;
• генерація або правка RTL-коду за результатами попереднього кроку;
• запуск синтезу й читання звітів про таймінги та площу кристала;
• реакція на помилки верифікації — повернення до кроку генерації з уточненим контекстом.

Це той самий патерн, який уже знайомий розробникам софту з агентних кодових асистентів на кшталт Claude Code чи Cursor — тільки ціна помилки на порядки вища, бо повторний випуск кристала (re-spin) неможливо «пропатчити» так, як софт.

Чи стосується цей патерн лише EDA?

Ні — і саме тут висновок огляду виходить за межі вузької індустрії чипів. Автори прямо називають перехід «генерація → оркестрація» ознакою зрілості LLM у будь-якому вузькоспеціалізованому інженерному домені, а не унікальною рисою EDA. Схожу траєкторію вже видно в агентних креативних пайплайнах — наприклад, у тому, як AWS показала референсну архітектуру агентних креативних конвеєрів, де модель теж координує ланцюжок спеціалізованих інструментів замість того, щоб генерувати кінцевий результат одним запитом.

Що це означає для тих, хто будує AI-агентів поза EDA

Наша теза: домен, у якому LLM переходить від «генерувати контент» до «оркеструвати наявний інструментарій», сигналізує про завершення першої, найпростішої фази застосування AI в ньому. EDA з її високою ціною помилки — жорсткий тест: якщо оркестрація там приживається, це аргумент на користь того, що архітектура «модель як диспетчер над перевіреними інструментами», а не «модель як генератор кінцевого результату», масштабується і на інші high-stakes домени — юридичний due diligence, фінансовий аудит, промислове проєктування. Для AI-білдерів практичний висновок простий: якщо ваш домен має чіткий існуючий тулчейн з перевірюваним виводом (лог, звіт, тест), варто проєктувати агента одразу як оркестратора цього тулчейна, а не як генератор, який ви потім обмотуєте перевірками.

Що таке EDA і чому там взагалі використовують LLM?

EDA (Electronic Design Automation) — клас софту для проєктування мікросхем: від опису логіки мовами Verilog чи VHDL до синтезу, розміщення елементів і верифікації перед виробництвом. LLM тут застосовують, щоб пришвидшити рутинні, добре формалізовані кроки цього циклу, які раніше вимагали годин ручної роботи інженера.

Чи означає це, що LLM більше не генерують HDL-код напряму?

Ні, генерація нікуди не зникає — вона просто перестає бути єдиною роллю моделі. У оркестрованому пайплайні генерація HDL-коду лишається одним із кроків, який викликає координаційний шар, коли це потрібно за логікою всього процесу.