MZ MAKSYM ZAKHAROVPRODUCT / PROJECT / LIVEOPS
03 / ПРОЄКТІНЖЕНЕРНИЙ КЕЙС · 2026

AI-агент для
перевірених
змін коду

AI Integration · Agent Tooling · Local LLM Systems

Спроєктував локальне середовище, у якому AI-агент працює з PHP- та Python-проєктами: знаходить потрібний код, виконує команди в ізольованому середовищі, вносить обмежені зміни й перевіряє результат перед завершенням завдання.

Моя зона відповідальності: архітектура, інтеграція інструментів, правила редагування, перевірки, налаштування моделі та маршрутизація локальних моделей.

2ПЕРЕВІРЕНІ СЦЕНАРІЇ ДЛЯ PHP І PYTHON
7ЗАДОКУМЕНТОВАНИХ ВНУТРІШНІХ СЦЕНАРІЇВ PASS
4,91×ЗРОСТАННЯ ПЕРЕВІРЕНОГО КОНТЕКСТУ

Результати внутрішніх випробувань 13–14 вересня 2026 року.

Переглянути робочий процес ↓Технічний кейс (PDF, RU · 220 КБ)

01 / ЗАВДАННЯ І РЕЗУЛЬТАТ

Від запиту до перевіреної зміни

Мені було потрібне локальне середовище, де модель працює зі справжнім репозиторієм, а її дії обмежені робочою папкою та інструментами перевірки. Я поєднав локальний inference, доступ до коду, виконання команд у Docker sandbox і перевірку результату в один процес для PHP і Python. Це внутрішній інженерний проєкт.

02 / МІЙ ВНЕСОК

Що я спроєктував та інтегрував

Архітектура й доступ

Поєднав Proxmox VE, LXC, Docker і постійну робочу папку. Агент виконує команди в sandbox без прямого shell-доступу до хоста.

Правила роботи з кодом

Налаштував цільове читання та зміни за актуальним станом файлу; заборонив повний перезапис наявних файлів і необмежені повторні спроби.

Перевірка результату

Додав PHP/Python lint, статичний аналіз і тести до завершення завдання. Після повторно відхиленої зміни агент зупиняє редагування.

Налаштування й маршрутизація

Профілював Qwen3.6-35B-A3B на CPU/GPU та інтегрував llama-router: GPU завантажує потрібну модель на вимогу, фонові завдання виконує CPU-модель.

03 / РОБОЧИЙ СЦЕНАРІЙ

Як агент завершує завдання

Задокументований PHP-сценарій охоплює читання потрібної ділянки репозиторію, зміну, перевірки й завершення. Окремий Python-сценарій перевіряє відновлення пошкодженого файлу.

  1. 1

    Знаходить потрібну ділянку коду та читає актуальний стан файлу.

  2. 2

    Змінює пов’язаний фрагмент без повного перезапису наявного файлу.

  3. 3

    Запускає перевірки: lint, статичний аналіз і тести для PHP; compile/Ruff для Python.

  4. 4

    Завершує після PASS. Повторно відхилена зміна зупиняє подальше редагування.

Задокументовані внутрішні сценарії зі статусом PASS

  • Native tool calls і JSON-аргументи
  • DFlash і серіалізація викликів інструментів
  • Read-only аналіз репозиторію
  • PHP: зміна → lint/static/tests → finalize
  • Python: recovery → compile/Ruff → finalize
  • Зупинка після вичерпання бюджету змін
  • Regression suite Workspace Tool 1.4.16

04 / ВИМІРЮВАННЯ

Що показали тести

Дві внутрішні конфігурації від 13–14 вересня 2026 року. Benchmark і спостереження в coding-запитах позначено окремо.

Показник До Результат Умови вимірювання
Контекст28 672 токени140 800 токенів (4,91×)Перевірений запит; на 143 872 токенах стався CUDA OOM.
Cold prefill111,05 tok/s · uBatch 128~274,6–276,2 tok/s · uBatch 512~275,6 tok/s для cold request із 8 117 токенів; 2,48× у цьому sweep.
Decode26,11 tok/s · без DFlash32,20 tok/s · DFlash n=2Приріст ~23% у benchmark, не гарантія для кожного запиту.
Coding turns—~30–33 tok/sСпостерігалося після налаштування в репрезентативних запитах.
Prefix cache—~97–98% reuseЛише representative final passes; залежить від сесії та перемикання моделі.

05 / АРХІТЕКТУРА

Як пов’язані компоненти

Архітектура: Open WebUI, llama-router, GPU-модель, Workspace Tool, Docker sandbox, постійна робоча папка й окрема CPU-модель
  1. Open WebUI
  2. llama-router
  3. Qwen / Impish
  4. Workspace Tool
  5. Docker sandbox · PHP / Python
  6. Persistent workspace
Open WebUI спрямовує запит через llama-router до потрібної GPU-моделі. Workspace Tool обмежує операції з репозиторієм; команди виконуються в Docker sandbox. На GPU одночасно працює одна модель, окрема CPU-модель обслуговує фонові завдання.

06 / ІНЖЕНЕРНІ РІШЕННЯ

Як я обирав робочу конфігурацію

Контекст і пам’ять

Зберіг q8_0 K/V і перевірену межу 140 800 токенів. Запит на 143 872 токени виявив обмеження пам’яті.

Batch і MoE placement

uBatch 512 пришвидшив prefill; 544/576 не дали значущого виграшу. n-cpu-moe=36 використовує менше VRAM без втрати швидкості порівняно з 34.

Speculative decoding

DFlash n=2 поліпшив decode у серії тестів; n=4 і n=8 показали гірші результати.

07 / МАТЕРІАЛИ

Як перевірити цей кейс

PDF російською містить схему, конфігурацію, вимірювання та результати внутрішніх сценаріїв від 13–14 вересня 2026 року. Знеособлений перебіг завдання та результати перевірок можу показати на співбесіді.

Технічний кейс (PDF, RU · 220 КБ) ↗

Окремий приклад AI-функції в комерційному продукті — RAG FAQ для підтримки X-BOT. Переглянути X-BOT →

08 / ЗАСТОСУВАННЯ ДОСВІДУ

Де корисний мій досвід

AI/LLM integration · Agent tooling · Workflow automation · PHP/Python verification · Local inference · Model routing

Зв’язатися щодо ролі →