Оптимізація ШІ-кодингу: Як я зібрав “суперкоманду” агентів, щоб уникнути вигорання токенів та підвищити якість коду
Автор: [Ваше ім’я/Ім’я автора, якщо відомо, або “Експерт з бізнес-аналізу та ШІ”]
Дата: [Дата публікації]
В останній тиждень я відчув себе так, ніби намагався вивчити весь матеріал до іспиту за одну ніч. Тільки замість конспектів були тонни коду, а замість чаю – безлімітний запас кави. І, скажу відверто, навіть цей невичерпний запас бадьорості не врятував.
Мій особистий досвід: вичерпані ліміти та фінансова дилема
Минулого тижня я зіткнувся з неочікуваним явищем: ліміти моїх найулюбленіших ШІ-інструментів – Claude та CodeX – вичерпалися значно швидше, ніж будь-коли раніше. І це при тому, що я не займався чимось надзвичайним, а просто працював над кількома поточними проєктами. Йдеться про мої стандартні передплати, які обходяться мені в значну суму – близько $200 за Claude і ще $200 за CodeX. Найприкріше те, що до скидання лімітів залишалося ще три-чотири дні. Це відчуття, ніби чекаєш на зарплату, коли кишені порожні, а до першого числа ще ціла вічність.
Якщо ви теж відчували, що ваші ШІ-помічники виснажуються швидше, ніж зазвичай, знайте: ви не самотні. Ми всі опинилися в цій “лімітній” човні. І, чесно кажучи, ми усвідомлювали, що цей момент наближається. Це глобальна тенденція, яка спостерігається протягом усього року. Ліміти стають жорсткішими, а ефективність використання токенів – критичнішою. Настав час, коли простої оптимізації не достатньо. Вважаю, що очікування трьох-чотирьох днів для відновлення доступу до можливостей моїх топових передплат є неприйнятним.
Заглиблення в тему: експерименти з відкритими моделями
З огляду на це, я вирішив провести глибокий аналіз. Протягом останніх шести місяців я активно експериментував з різними моделями, зокрема з відкритими, в інтеграції зі своїми ШІ-кодинговими робочими процесами. Те, що починалося як експеримент, перетворилося на нагальну необхідність. Це вже не примха, а ключовий компонент моєї професійної діяльності.
Сучасна індустрія розробки програмного забезпечення все глибше занурюється в інженерію, петлеву інженерію та побудову “фабрик програмного забезпечення” – незалежно від того, як ви називаєте свої ШІ-кодингові процеси. Ми прагнемо масштабувати вивід за допомогою наших кодових агентів. Однак, наразі, головним обмежувачем є саме кількість токенів, яку ми можемо використати.
Стратегічний підхід: диференціація потужності LLM
Саме тому нам необхідно застосовувати стратегічний підхід до наших комплексних ШІ-кодингових робочих процесів (йдуться не про одного агента!). Необхідно чітко визначати, де нам дійсно потрібна максимальна потужність великої мовної моделі (LLM), а де можна використати меншу, більш доступну та швидку модель, яка при цьому забезпечуватиме аналогічну якість виводу. І так, це цілком досяжно.
Я провів багато часу, проводячи детальні дослідження цього тижня, розширюючи базу знань, зібрану протягом року. Я визначив, на яких етапах традиційного ШІ-кодингового робочого процесу – планування, реалізація, валідація та рев’ю – потрібна найбільш потужна LLM, а де її роль може бути менш значущою. Це ключове питання, на яке потрібно відповісти, щоб уникнути виснаження лімітів одразу після їх скидання.
Етапи розробки: планування, реалізація, валідація – де криється “золотий ключик”?
Для всіх тестів, які я провів, я використовував власну “ШІ-фабрику програмного забезпечення”. Ця система інтегрує мої найкращі практики ШІ-кодингу з процесами планування та реалізації. Це комплексна система, куди я можу надіслати обсяг робіт, і вона самостійно генерує та валідує код без мого прямого втручання. Це остаточний тест на автономність ШІ-кодингу, при збереженні високої надійності. Що ще важливіше для моєї мети, ця система дозволяє мені легко тестувати різні комбінації LLM з повним циклом розробки.
Я створив низку різних додатків за допомогою “ШІ-фабрики”, включаючи відеогру, яку я продемонструю. Це чудовий візуальний приклад. Результати, отримані з іншими проєктами, були аналогічні.
Я побудував ту саму гру, але з використанням різних підходів:
- Лише з відкритими моделями.
- Використовуючи Claude.
- Використовуючи CodeX.
Я провів безліч інших тестів, але ці три є основними. Для кожного підходу я обрав найкращу модель:
- Відкриті моделі: DeepSeek V4.1 Flash. За даними бенчмарків LLM в реальному часі, наразі це провідна модель серед відкритих.
- Claude: Claude Fable 5.1 max effort. Найбільш потужна версія.
- CodeX: GPT6 Astra max effort. Також найпотужніша версія.
Під час мого основного тестування я застосував наступні комбінації:
- Для роботи з відкритими моделями: Я використовував Deepseek Flash для планування та рев’ю, а потім GLM 5.3 Flash для реалізації.
- Для Claude: Я застосовував Fable для планування та рев’ю.
- Для CodeX: Я використовував Astra.
Ключовий висновок: я завжди використовував більш потужну LLM для планування та рев’ю, а потім меншу модель для генерації коду. Саме це я з’ясував під час експериментів цього тижня та на початку року.
Найважливішим етапом вашого ШІ-кодингового робочого процесу завжди є планування. Якщо план добре структурований, то модель, що реалізує цей план, навіть не повинна бути надзвичайно потужною, щоб досягти оптимальних результатів. Наприклад, використання Fable як для планування, так і для реалізації дає приблизно такі ж результати, як і використання Fable для планування, а Sonnet – для реалізації. Я навмисно підкреслив це в усіх тестах, які вам покажу.
Реалізація – це, як правило, найінтенсивніший етап робочого процесу з точки зору споживання токенів. Тому використання меншої моделі на цьому етапі є ефективним способом запобігти швидкому виснаженню лімітів.
Звичайно, для деяких надзвичайно складних або малодосліджених завдань може знадобитися потужна модель для всіх етапів. У моїй “ШІ-фабриці” я не завжди цього дотримуюся. Але якщо в процесі бере участь людина-оператор, для невеликих та чітко визначених завдань можна використовувати відкриту модель практично для всього. Таким чином, існують різні комбінації, які мають сенс у різних сценаріях, але це мої загальні рекомендації, підкріплені численними тестами.
Мій улюблений робочий процес наразі: використання GPT6 Astra для планування та рев’ю, а потім GLM 5.3 Flash для надзвичайно швидкої та економічної реалізації. Це мій основний робочий процес для всього, що я роблю за допомогою своєї “ШІ-фабрики”, і навіть за її межами.
Спонсор сьогоднішнього відео: Scrimba – ваш персональний відео-лектор за 3 секунди!
Спонсором сьогоднішнього відео виступає Scrimba, які представили неймовірний інструмент під назвою Explain. Ви ставите запитання, а вони надають повністю озвучений відеоурок за 2-3 секунди, створений в реальному часі. Цей інструмент інтегрується безпосередньо в CodeX та Claude Code!
Зайшовши в Cloud Code, я можу виконати команду SLMCP. І ось, Scrimba Explain підключено. Це вимагало лише однієї команди. Тепер я можу попросити Claude Code створити пояснення для будь-якого елементу.
Я вирішив продемонструвати, як Scrimba створює пояснення для складнішого pull request з мого open-source проєкту Archon. Claude читає diff, генерує урок і стрімить його по слайдах до Scrimba. Я одразу отримую посилання та можу спостерігати за процесом створення пояснення. Мушу сказати, отримане пояснення вразило мене. Дозвольте показати.
Це оригінальний pull request, для якого я створював пояснення. А ось і відео. Я на секунду зупинюся і покажу вам декілька фрагментів:
(Кліп з відео, де автор демонструє пояснення від Scrimba Explain, з голосовим супроводом)
- “PR 3416 надає три адаптери, один спільний шлях.”
- “Я перейду до більш високорівневої діаграми. Ось контракт, який реалізують адаптер CLI та веб-адаптер. Це також переходить у код.”
- “Знаходиться в ядрі. Хелпер приймає будь-який об’єкт, що дозволяє платформі без голови передавати структурно ідентичну роботу.”
- “Чудово. Тож я не буду відтворювати весь ролик, очевидно, але так, звучить чудово, і це розбиває речі дуже добре і просто для мене. Мені подобається.”
Explain також працює з ChatGPT та як розширення Chrome для будь-якої статті. Спробуйте Explain безкоштовно за моїм посиланням у описі!
Як зібрати свою “суперкоманду” ШІ-агентів?
Тепер, можливо, у вас виникне запитання: як саме ми створюємо комплексний ШІ-кодинговий робочий процес, де використовуються різні моделі та провайдери? Можливо, ви захочете реалізувати це так само, як і я. Можливо, ви захочете експериментувати. Як би там не було, існує багато різних способів це зробити.
Найбільш ручний, але простий спосіб – це мати кожного кодового агента, який виводить документ передачі у форматі markdown. Потім ви передаєте його наступній моделі або наступному кодовому агенту. Таким чином, ви проходите по черзі, відкриваючи різні сесії кодових агентів.
Існують також “хабрі” (harnesses), як-от Omnient, які полегшують роботу з моделями та різними провайдерами.
Але те, що я роблю для своєї “ШІ-фабрики програмного забезпечення” та своїх кодингових робочих процесів загалом – це просто використовую мій open-source “хабрі-білдер” Archon. Це значно спрощує створення робочих процесів, які я запускав сотні разів минулого тижня, щоб комбінувати різні моделі та провайдерів.
Для кожного тесту, який я провів, кожна комбінація моделей, структура завжди виглядала так, як робочий процес Archon. І я покажу вам, як виглядають ці робочі процеси трохи згодом.
- Вхідні дані: Завжди GitHub issue, який описує, що ми хочемо побудувати.
- Планування: Найпотужніша модель виконує планування, як-от GPT6 Astra, яка є моїм фаворитом.
- Передача плану: Ми автоматично передаємо цей план наступному вузлу в робочому процесі Archon – це GLM 5.3 Flash, який займається реалізацією.
- Рев’ю: Потім Astra переглядає результат.
- Виправлення: Будь-які знахідки Astra надсилає назад до GLM для виправлення. Ми маємо цей цикл із максимальною кількістю спроб.
- Валідація: Наприкінці ми запускаємо наші тести, переконуючись, що збірка успішна, перед тим, як зробити merge.
Це досить традиційний ШІ-кодинговий робочий процес. Нічого надзвичайного. Це саме та структура, яку я використовував для кожного тесту.
Також існує багато різних способів доступу до відкритих моделей для наших ШІ-кодингових робочих процесів. Але мій улюблений останнім часом, особливо тому, що Archon це підтримує, – це використання Pi як “хабрі” для кодових агентів, а для доступу до LLM – Neon’s AI Gateway.
Я завжди цінував Neon. Мені подобається їхнє рішення для баз даних Postgress. Вони додають багато інших функцій, пов’язаних зі ШІ, таких як AI Gateway, а також нові бекенд-функції, як-от об’єктне сховище, автентифікація та функції. Але зараз я використовую AI Gateway, який надає нам надійний та доступний доступ до практично всіх відкритих моделей, які ви можете собі уявити. Наприклад, у нас є Kimmy K3. Що ще у нас є? GLM 5.3 Flash, про який я багато говорив. Це мій простий спосіб доступу до всіх моделей, які мені потрібні в моїх робочих процесах Archon та з Pi.
Але незалежно від того, як я отримую доступ до цих відкритих моделей, найважливіше – це те, що я не просто використовую Astra або Fable для всього, як багато хто з нас схильний робити. І ви можете налаштувати це з чим завгодно. Вам навіть не потрібен Archon. Це мій інструмент. Він безкоштовний і з відкритим кодом, і я використовую його для запуску “ШІ-фабрики програмного забезпечення”. Але я також не наполягаю, щоб ви використовували мій інструмент. Ні, це просто те, що я робив для своїх експериментів, щоб надати вам ці результати та допомогти вам думати про те, які моделі використовувати, які комбінації.
Ось так виглядають мої робочі процеси Archon (це спрощений вигляд), але практично кожен з них виглядає так: планування з більш потужною моделлю, потім передача цього плану (markdown) до кроку реалізації з дешевшою моделлю, як GLM 5.3 Flash через Neon, потім рев’ю знову потужнішою моделлю, а потім виправлення будь-яких проблем, що виникли, з дешевшою моделлю. Це структура, яку я використовую навіть за межами моїх експериментів, загалом для того, як я зараз працюю з кодовими агентами.
Історія однієї гри: як різні моделі створюють різний результат
Я хотів приділити достатньо часу поясненню свого робочого процесу, своїх експериментів та моделей, які я рекомендую. Але тепер я хочу перейти до самої гри як основного прикладу, щоб дати вам візуалізацію результатів, які я отримав у всіх додатках, які я будував. Це, як я вже сказав на початку відео, ті самі результати, які я отримував незалежно від того, що я будував.
Отже, перша версія гри виглядає жахливо. Ви, мабуть, здогадаєтеся, що це те, що я будував лише з відкритими моделями.
До речі, ця гра – ідея від друга. Дуже крута. Тож я вирішив прогнати її через фабрику. Це гра про “полювання за погодою”, як штормове полювання на Нептуні. Вона насправді багатокористувацька. Різні люди можуть приєднуватися та керувати станціями. Я зараз не буду це налаштовувати, але це досить комплексний проєкт, який я передав у “ШІ-фабрику”.
У цій версії гри я використовував відкриті моделі: Deepseek V4.1 Flash для планування та рев’ю. А для створення коду – GLM 5.3 Flash. Візуальні ефекти настільки погані, що ви навіть не можете зрозуміти, що я рухаюся. Є кілька хмар, які ми бачимо за вікнами. Але так, ми можемо бачити зміну напрямку вгорі ліворуч, коли я повертаюся як пілот. Але загалом, це навіть не хороший старт для гри.
А потім, для наступної версії гри, ця була побудована повністю з Claude, тому що я хотів показати вам приклад, де ми не використовуємо відкриті моделі взагалі. Я використовував Claude Fable 5.1 для побудови всієї цієї штуки. І так, заради токенів, я не міг зробити щось надзвичайно комплексне. Тож, на жаль, я не зміг створити щось надзвичайно красиве, але, погодьтеся, це виглядає досить добре. Безумовно, краще, ніж просто відкриті моделі.
Дозвольте мені перейти до пілота і показати вам, що все виглядає набагато краще. Ось, якщо я візьму керування і зміню напрямок, ви побачите, що … трохи смикається, але я рухаюся до хмар. І коли я рухаюся вперед, хмари насправді наближаються. Навігація на планеті працює досить добре. Було б чудово показати всі інші станції, але це зайняло б багато часу. Головне, що Claude Fable 5.1 зробив досить хорошу роботу для першого ж прототипу цієї гри. Я не виділив надто багато токенів, але так, це досить добре.
А тепер, третя версія гри. Ось тут я справді вражений. Не тому, що вона настільки дивовижна, але тому, що я використовував GLM 5.3 Flash для написання кожного рядка коду в цій версії гри. А для планування та рев’ю я використовував GPT6 Astra.
Ця версія гри коштувала приблизно в чотири рази менше токенів або менше загальної вартості, тому що я використовую GLM для реалізації, і вона працює приблизно так само. Насправді, рух до хмар навіть плавніший. Я б сказав, що ця версія гри навіть краща, хоча я використовував відкриту модель для написання кожного рядка коду. Звісно, допомагає мати Astro Review, але я все ще економлю купу коштів/лімітів, використовуючи цю комбінацію моделей.
Отже, так, трохи “сирна” гра, яка є радше доказом концепції. Але головне тут – це результати, які я отримав практично для кожної програми, яку я будував. І пам’ятайте, повертаючись до LiveBench: Claude Fable 5.1 і GPT6 Astro досить близькі за можливостями. І це чудово, що ми змогли створити навіть трохи кращу гру та інші додатки з цією комбінацією, ніж просто використовуючи Claude. Це доказ, який вам потрібен.
Вам не завжди потрібна найкраща велика мовна модель для кожного кроку вашого процесу. Це цілком варте вашого часу, і я сподіваюся, я дійсно це довів: проаналізуйте свій ШІ-кодинговий робочий процес, з’ясуйте, де вам потрібна найкраща модель, а де – ні. Тому що саме це врятує вас від роздування лімітів для ваших передплат, як-от Claude та CodeX.
Моя “ШІ-фабрика програмного забезпечення” – це те, як я проводжу всі свої тести, як я зараз запускаю свої робочі процеси. Але що б ви не робили зараз, цей урок застосовний: ви повинні справді дослідити відкриті моделі на цьому етапі, тому що стає очевидним, що ми не завжди можемо працювати на наших передових моделях.
Сподіваюся, ви знайшли ці тести цікавими, коли я проходжу через усі ці різні комбінації, розробляючи різні додатки. Якщо так, я був би дуже вдячний за лайк та підписку. Слідкуйте за моїми новими відео, де я продовжуватиму розробляти свою “ШІ-фабрику” та тестувати ці комбінації.
І з цим, побачимося в наступному!
