Проєкт BMForge

У цій публікації я представляю свій новий проєкт BMForge.

Зараз я використовую Codex з моделлю Sol 6.1 від OpenAI як свого агента для програмування.

Мені він дуже подобається. Швидкість, якість коду та неймовірні можливості справді вражають. Він докорінно змінив те, як я розробляю програмне забезпечення.

Але є й серйозні проблеми.

Самовільне встановлення компонентів

Codex схильний самостійно ухвалювати технологічні рішення. Зіткнувшись із вимогою, він обирає бібліотеку, встановлює її та починає впроваджувати в кодову базу.

Іноді це цілком доречно. Іноді зовсім ні.

Я хочу брати участь у таких рішеннях. У мене є улюблені технології, готові реалізації та усталені підходи. Я не хочу, щоб новий фреймворк з’являвся в проєкті лише тому, що агент вирішив, ніби так зручніше.

Зрештою, це моє програмне забезпечення.

Мій дім, мої правила

Я вже давно займаюся розробкою програмного забезпечення й маю власні способи організації роботи.

Стандарти написання коду, правила іменування, структура каталогів, інтерфейси баз даних, керування релізами та розмежування середовищ DEV, QA і PROD — усе це частини мого життєвого циклу розробки програмного забезпечення (SDLC).

Немає жодних підстав очікувати, що Codex інтуїтивно знає все це. Але мені потрібно, щоб він дотримувався цих практик.

Наприклад, коли ми розслідуємо проблему у виробничому середовищі, розробник не повинен експериментувати безпосередньо на робочому сервері. Треба зібрати журнали, експортувати базу даних, перенести докази на робочу станцію розробника й відтворити проблему там.

Це базова операційна дисципліна.

Codex — надзвичайно здібний розробник, але він не обов’язково знає, як заведено працювати в моєму середовищі.

Коли ж він починає імпровізувати, усе може швидко перетворитися на хаос.

Нам цього не потрібно.

Постійно повторюватися

Codex підтримує файл AGENTS.md з інструкціями для конкретного проєкту. Це корисно, але я помітив, що знову й знову повторюю ті самі вказівки в різних проєктах.

Наприклад:

• «Подивись на скрипт new-release у bmgeoip. Використай цей підхід».
• «Поглянь на проєкт BMDynIP у /opt/dev/bmdynip. Там є сервер звітів. Візьми його за приклад».
• «У проєкті snake-web-code використовується GitPublisher. Почни з цієї реалізації».

І цього було ДУЖЕ БАГАТО.

Проблема полягала не лише в повторенні. Кожна нова реалізація створювала ще одну можливість для появи дрібних неузгодженостей.

Я міг би й далі розширювати AGENTS.md, але мені хотілося чогось системнішого: багаторазового використання, версіонування та можливості поступово вдосконалювати підхід.

Зустрічайте BMForge

BMForge — моя спроба розв’язати ці проблеми.

В основі BMForge лежать три складники:

Специфікації + Процеси + Програмний стек

Він забезпечує спільну інженерну основу для створення нових застосунків із багаторазово використовуваних компонентів і перевірених практик розробки.

Репозиторій містить:

• Специфікації компонентів: Визначають поведінку, дозволені модулі Python, обмеження реалізації та вимоги до тестування.
• Компоненти для повторного використання: Перевірені реалізації типових функцій, зокрема роботи з базами даних, HTTP-сервісів, обміну повідомленнями через ZeroMQ, конфігурації, локалізації та візуалізації.
• Процеси розробки: Ініціалізація проєктів, правила іменування, структура каталогів, встановлення, оновлення, релізи та інші дії SDLC.
• Навички для ШІ-агентів: Інструкції, які навчають агентів програмування дотримуватися цих стандартів і виконувати мої усталені процеси.

Під час створення нового проєкту BMForge надає основу. Застосунок має власну реалізацію й не залежить від BMForge під час виконання.

Навички для ШІ-агентів

Навички ШІ стали тим відсутнім елементом пазла.

Навички набувають дедалі більшого поширення, і в інтернеті їх уже чимало.

Застереження: встановлення сторонньої навички ШІ у своє середовище потребує такої самої обачності, як встановлення стороннього програмного забезпечення. Навички можуть наказувати агентам запускати команди, отримувати доступ до ресурсів і взаємодіяти з вашим середовищем. Переконайтеся, що довіряєте джерелу.

Замість того щоб покладатися на сторонні навички, я створив власні, спеціально для мого середовища розробки.

Це не просто набори промптів. Це операційні інструкції, подібні до тих, якими користуються системні адміністратори та аналітики експлуатації.

Наприклад, навичка аналізу першопричин (RCA) у BMForge навчає Codex, як шукати причини проблем у виробничих застосунках.

Процедура проста:

1. Під’єднатися до виробничого середовища через SSH.
2. Зібрати потрібні журнали й дампи баз даних, не змінюючи віддалену систему.
3. Перенести зібрані матеріали на робочу станцію розробника.
4. Відтворити, дослідити й виправити проблему локально.

Під час RCA ніколи не змінювати виробниче середовище.

Ось і все. Жодних складних процедур, жодної бюрократії. Просто перевірена операційна практика, якої Codex тепер може послідовно дотримуватися.

Інші навички визначають, як використовувати константи, будувати інтерфейси баз даних, реалізовувати HTTP-сервіси або готувати реліз.

Головне, що мені більше не доводиться щоразу пояснювати все з нуля.

Обмеження — це перевага

BMForge свідомо обмежує технології, які Codex може впроваджувати.

Специфікації компонентів визначають дозволений програмний стек. Якщо вимогу неможливо задовольнити наявними компонентами й модулями, Codex має зупинитися та обговорити зі мною альтернативи.

Можливо, нам потрібна нова бібліотека. Можливо, слід розширити наявний компонент. А можливо, варто переглянути саму вимогу.

Але це буде свідоме рішення.

ШІ бере участь в інженерному процесі, а не одноосібно перевизначає його.

Створення бібліотеки компонентів

BMForge також спроєктований так, щоб розвиватися.

Деякі компоненти взято з наявних розгорнутих застосунків. Вони вже були розроблені та використані на практиці, тому є добрим відправним пунктом.

Інші створюються на основі специфікацій, щоб задовольняти потреби майбутніх застосунків.

Розробляючи нове програмне забезпечення, я знаходжу спільні шаблони й переношу їх до BMForge для повторного використання.

Кожен новий проєкт потенційно може зробити внесок у наступний.

Простежуваність і безперервне вдосконалення

Ця частина мене особливо захоплює.

Компоненти BMForge містять метадані, які ідентифікують специфікацію та її версію, за якими їх було реалізовано.

Це встановлює простежуваний зв’язок між розгорнутим застосунком та інженерною специфікацією, на якій ґрунтуються його компоненти.

Уявімо, що я знаходжу дефект.

Я можу простежити шлях від проблемного компонента до його специфікації, визначити, де саме причина — у реалізації чи в самій специфікації, — і вдосконалити відповідну частину.

Цей принцип так само працює для підвищення якості й продуктивності.

З часом ці покращення можуть повертатися до BMForge і ставати доступними для майбутніх застосунків.

Знайти проблему. Поліпшити реалізацію. Поліпшити специфікацію. Передати знання далі.

Саме в цьому мета: не просто повторно використовувати код, а накопичувати інженерні знання.

Це поступовий, крок за кроком, процес, у якому кожне покращення може підвищити якість наступних проєктів.

Механізм простежуваності вже працює. Детальніша звітність і аналітика, які він уможливлює, — ще попереду.

ШІ як учасник SDLC

За BMForge стоїть ширша ідея.

Я не намагаюся винайти цілком нову методологію розробки лише тому, що тепер до процесу долучився ШІ.

У мене вже є SDLC, який мене влаштовує.

Я просто інтегрую ШІ в цей процес як ще одного учасника.

Codex забезпечує неймовірну швидкість і здатність реалізовувати рішення. Я визначаю вимоги, архітектуру, стандарти, надаю операційний досвід та інженерні судження.

BMForge забезпечує спільну основу для злагодженої співпраці.

Агент працює ефективніше, оскільки розуміє своє середовище. Моя продуктивність зростає, бо мені більше не потрібно знову й знову пояснювати ті самі правила та створювати ту саму інфраструктуру.

А отримане програмне забезпечення залишається зрозумілим, зручним для підтримки й моїм власним.

Перші результати

Це лише початок, але я вже використав BMForge, щоб створити DevLog — застосунок, який відстежує, скільки часу я витрачаю на різні проєкти GitHub.

DevLog збирає дані про активність розробки й показує їх на простій вебпанелі.

Застосунок невеликий, але став корисною практичною перевіркою цього підходу.

BMForge стандартизував і пришвидшив початкове налаштування проєкту, надав готові компоненти та усталені правила розробки й допоміг Codex створити цілісну реалізацію без постійного повторного винайдення базової інфраструктури.

І в DevLog, і в самому BMForge ще є багато можливостей для покращення.

Але ж у цьому й полягає задум.

Висновок

BMForge почався як спосіб перестати повторювати одне й те саме агенту програмування.

Тепер він перетворюється на щось цікавіше: колекцію специфікацій, процесів, багаторазово використовуваних компонентів та операційних знань, яка постійно зростає й підтримує мій спосіб розробки програмного забезпечення.

Тепер я можу створювати застосунки значно швидше, не втрачаючи контролю над архітектурою, вибором технологій чи операційними практиками.

А коли щось не працює, у мене є механізм, що дозволяє повернути цей досвід до фреймворку.

BMForge дозволяє мені розробляти програмне забезпечення зі швидкістю ШІ, зберігаючи власну інженерну дисципліну.

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

Є певне кумедне відчуття замкненого кола в тому, щоб використовувати ШІ для створення фреймворку, який навчає ШІ розробляти програмне забезпечення за перевіреними людськими підходами. Приємно все ще залишатися частиною процесу!