AI Bridge: результаты после 399 задач
Когда работаешь над своим проектом один, быстро понимаешь, что писать код — это далеко не самая большая проблема. Сегодня ты проектируешь архитектуру, через час настраиваешь Docker, потом пишешь тесты, правишь фронтенд и разбираешься с очередной ошибкой в логах. Постоянное переключение между задачами съедает гораздо больше времени, чем сама разработка. В какой-то момент мне надоело быть одновременно разработчиком, DevOps-инженером, тестировщиком и техподдержкой. Поэтому я начал собирать для себя инструмент, который забирает рутину. Так появился AI Bridge. Это не история про «нажал кнопку — получил готовый продукт». Архитектуру, инфраструктуру, логику работы, RAG, PostgreSQL + pgvector, мониторинг и оркестратор я писал сам. ИИ занимается только тем, что обычно отнимает больше всего времени: бойлерплейт, типовые CRUD-операции, тесты и первичную проверку кода. Система работает через оркестратор и набор специализированных агентов в Docker-контейнерах. Каждый занимается своей задачей, а контекст подтягивается через RAG из кода, документации и базы знаний проекта. Благодаря этому агент получает не весь репозиторий целиком, а только то, что действительно относится к текущей задаче. За последние 3 дня система обработала 399 задач. Что получилось по цифрам: • Success Rate — 86.2% • Медианная задержка — 62 мс • Время выполнения задач сократилось с 41 секунды до 2.5 секунды • Средний расход токенов снизился с 915 до 77 на задачу Больше всего времени сэкономилось на том, что раньше хотелось откладывать на потом: генерация шаблонного кода, тесты, настройка проекта и мелкие технические задачи. Не всё прошло гладко. Были случаи, когда агент находил несуществующую проблему, пытался её исправить и создавал новые. Поэтому пришлось добавить строгие JSON-контракты между сервисами и предохранитель, который останавливает задачу после нескольких неудачных попыток. Сейчас AI Bridge не заменяет разработчика. Зато позволяет меньше заниматься рутиной и больше времени тратить на архитектуру, инфраструктуру и бизнес-логику. Проект открыт, код лежит на GitHub. Интересно узнать мнение коллег: кто уже использует локальные LLM или собственных агентов в работе? Что реально прижилось, а что оказалось красивой идеей только на бумаге?
Github: https://github.com/Userbash/Hebrew-web
#AI #LLM #AIAgents #Python #BackendDevelopment #SoftwareArchitecture #DevOps #Docker #PostgreSQL #RAG #Automation #OpenSource #PetProject #SystemDesign #SoftwareEngineering
· 10.06
Проблему с агентом который "находит несуществующую проблему" знаю хорошо. У нас решилась разделением фаз: сначала агент только читает и возвращает анализ в JSON, и только после явного подтверждения оркестратора переходит к изменениям. Без этого разделения агент мог за один вызов прочитать, решить что что-то сломано, и тут же починить то, что не надо было трогать. Ещё помогло добавить в промпт явный запрет на изменения в read-фазе, не надеяться что модель сама догадается.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 17.06
Мой путь в разработке ИИ: оптимизация понимания контекста и архитектурные решения
В работе с искусственным интеллектом я постоянно ищу новые методы и подходы для улучшения понимания пользовательского ввода, чтобы система могла правильно расставлять приоритеты и формировать задачи.
Что уже реализовано и протестировано:
Работа с контекстом и данными: Разработал систему трассировки памяти и маршрутизации. Реализовал послойную обработку, хранение и структурирование данных, а также сохранение ключевых слов в датасетах промтов.
Очереди сообщений: Интегрировал RabbitMQ, детально настроил работу с обменниками (exchanges) и очередями для оптимизации нагрузки.
Работа с агентами: Обучил ИИ-агентов корректно воспринимать и обрабатывать акты (видимо, документы/логи/API-акты).
Масштабируемость: За счет внедрения очередей успешно реализовал многопоточность, что значительно повысило производительность системы.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён