TypeScript, AI, технічний боргЯ вже робив пост на цю тему й казав, що AI полегшує використання TypeScript (
https://t.me/jabascript/335). Але сьогодні поділюсь ще однією думкою, що є й зворотня залежність - TypeScript полегшує використання AI.
Коли використовуєте якогось кодінг агента, то йому треба верифікувати коректність змін, що є критичної складовою його роботи. Запустити все й вручну потестувати в браузері агент повноцінно не може. Тому треба автоматизований спосіб, й тут два варіанти:
✅ Статичний аналіз
✅ Запустити тести
Тести не завжди є на момент написання нового коду. Також виконання тестів вимагає часу. А от TypeScript дає можливості статичного аналізу відразу; також помилки його зрозумілі агенту й вказують на конкретні рядки. Тому, використання TypeScript стає критичним сьогодні, якщо ви використовуєте агентів.
Але є ще один важливий аспект - технічний борг й AI. З використанням AI якісний код в проекті стає ще більш важливим, ніж до цього. AI пише умовно як джуніор розробник. Тобто, він дивиться на існуючі приклади в проекті й пише по аналогії. Й чим краще у вас архітектура й якісніші абстракції, тим агенту легшу написати по аналогії код. Але гарної структури у вас немає й в проекті каша - то агент буде генерувати таку саму кашу. Якщо у вас є код, який містить застарівші підходи, то агент буде їх теж копіювати по проекту. Але, якщо у вас є добре структурований код, архітектура, можливо, документація, то агент буде показувати просто неймовірні результати.
Де взяти час на якісний код й на якісні абстракції? Насправді, оскільки агент пише за вас весь рутиний код, то у вас залишається весь час для того, щоб створювати йому правильний архітектурний технічний контекст. Бо, як казав Andrej Karpathy, це не prompt engineering, а context engineering. Тобто, наша задача - це менеджмент контексту (бізнесового, продуктового, технічного й тд) й маючи контекст AI може добре й новий код писати й виправляти баги реалізації.
Тобто, у нас є можливість бути продуктивнішими й мати більш якісний код. Так, й до AI більш якісний код був дешевшим з точки зору підтримки, але тоді на архітектуру час закладався, а от дрібниці постійно накопичувалися (бо менш критичні, а їх фікс часу може займати багато). Зараз же у нас ситуація така, що розробник відповідає за абстракції й рев'ю, а агент працює над реалізацією кожного компонета. Доречі, принцип "Assemble first" (розповідав на DOU Day минулого року) тут стає ще більш актуальним й важливим, бо потім просто реалізовувати дрібні компоненти агенту буде значно простіше.
Що думаєте? Які інсайти у вас при роботі з кодінг-агентами?
