Встановлення Laravel-пакета займає тридцять секунд, тоді як на якісну реалізацію потрібен час. Проте з появою AI-асистентів часовий фактор відходить на другий план, адже написання коду відбувається у фоновому режимі.
Коли ми просимо агента створити завантажувач файлів, у розробника спрацьовує рефлекс: як це реалізувати? Переглядаючи Laravel-пакети, ми бачимо медіабібліотеку від Spatie — це популярний і надійний вибір. Встановив, налаштував і пішов далі. У AI-агентів такого рефлексу немає. Вони просто будують із нуля.
Але не всі задачі чи пакети однакові. Як вирішити: покластися на зовнішню бібліотеку чи змусити роботів написати саме те, що нам потрібно?
Категорія 1: Спільні задачі
Багато проблем є типовими й уже давно вирішеними.
Наприклад, структура меню сайту, що має відображатися у футері та генерувати breadcrumbs. Це актуально для багатьох застосунків. Для цього ми створили spatie/laravel-navigation.
Навігація сайту — це автономна та стабільна задача. Пакет може мати зручний API або враховувати окремі кейси, але це не є чимось надскладним. Дозвольте роботам побудувати саме те, що вам потрібно.
Категорія 2: Складні задачі
Деякі проблеми здаються простими лише на перший погляд, але приховують реальну складність всередині.
Припустимо, ви хочете додати на сайт графік роботи. Здавалося б: з понеділка по п'ятницю, з дев'ятої до п'ятої, готово. Але потім з’являються винятки для свят, відпустки, особливі вихідні або робочі неділі. Вам потрібна модель, що описує «стандартні години, окрім випадків, коли вони змінюються». Потім це має проіндексувати Google, тож потрібна серіалізація в JSON-LD. Згодом ви розумієте, що користувачі дивляться графік із різних часових поясів, що значно все ускладнює.
AI-агент здатний це реалізувати, але вам доведеться заздалегідь описати всі нюанси або додавати їх у процесі. Робот не передбачить типових проблем за вас, а якісний пакет — так. Наш opening-hours package містить рішення для кейсів, які збиралися роками реальної практики. Ви отримуєте цей досвід «з коробки».
Обирайте пакети для складних проблем, за які ви не хочете нести персональну відповідальність. Нехай роботи краще зосередяться на вашій основній бізнес-логіці.
Категорія 3: Зовнішні задачі
Деякі проблеми пов'язані з факторами поза вашим контролем — наприклад, з API стороннього сервісу. Зовнішні сервіси та протоколи еволюціонують, і ваш код має встигати за ними.
Хочете додати інтеграцію з Linear? Агент напише клієнт, що працює сьогодні. Але коли Linear оновить свій API, саме ви будете змушені це помітити, дослідити та виправити код. Підтримуваний пакет бере ці зміни на себе. Все, що вам потрібно — це composer update.
Те саме стосується пакетів із підтримкою драйверів. Сьогодні ви використовуєте Pusher для передачі даних у реальному часі, а завтра захочете перейти на Laravel Reverb. Пакет із підтримкою драйверів зведе рефакторинг до зміни конфігурації. Якщо ж агент написав кастомну інтеграцію під Pusher, згодом її доведеться повністю переписувати під Reverb.
Для зовнішніх задач тягар підтримки є постійним. Пакети мінімізують обсяг коду, який вам доведеться оновлювати. Нехай роботи витрачають свої токени на щось інше.
Категорія 4: Витончені рішення
Не кожне рішення щодо пакета є суто технічним. Іноді ви обираєте пакет через його філософію та підхід.
Inertia спрямовує вас і вашого агента до певного патерну. Навіть якщо ви можете зібрати власну версію Inertia під свої потреби, ви обираєте оригінал, бо вірите у вектор розвитку цього фреймворку.
Аналогічно, ми використовуємо Livewire не лише через технічні переваги. Ми обираємо його, бо Caleb Porzio має чудовий смак у дизайні API. Великі оновлення бібліотек часто приносять нові можливості, що викристалізувалися з досвіду тисяч розробників.
Коли йдеться про код у центрі архітектури, що визначає спосіб побудови застосунку, покладайтеся на авторів, яким довіряєте. У роботів смаку поки що немає.
Що це означає для пакетів?
Як розробники пакетів, ми зацікавлені в цьому питанні. Але ми створюємо їх, щоб заповнити прогалини там, де це потрібно. Якщо AI-агенти візьмуть на себе рутинні задачі, ми з радістю відмовимося від підтримки таких пакетів і зосередимося на більш цікавих викликах.
Перед кожним composer require тепер стоїть не питання «чи є для цього пакет?» (майже напевно є). Головне питання тепер: «чи хочу я бути власником цієї проблеми?»
