Вайб-кодинг, или AI-assisted development, отлично работает на уровне прототипа: агент получает текстовое ТЗ и быстро собирает первый рабочий вариант. Но в корпоративной разработке этого мало.

Проблема начинается там, где нужно не просто написать код, а собрать полноценное корпоративное приложение. В Джеймикс между «экран открылся» и «система действительно работает как надо» лежит пропасть.

В какой-то момент мы задались вопросом: можно ли научить ИИ-агента проходить этот путь самостоятельно? Можно, если собрать вокруг него харнесс (англ. harness). Именно о нем статья.

В Джеймикс мы строим этот мост как инженерный харнесс: набор скиллов, инструментов и проверок, который помогает довести работающий прототип до реально работающей системы. Для его строительства мы используем агентную платформу KodaCode (далее — Koda) в собственной разработке на Джеймикс и регулярно гоняем ее на бенчмарках. Если оценивать по делу, Jmix-задачи агент решает уверенно. Разброс от сессии к сессии есть, мы видим его в собственных прогонах, и строгие pass/fail-бенчмарки его даже преувеличивают. Поэтому ставка не на идеального агента: обвязка и контроль не дают этому разбросу попасть в ваш продакшен. Это SKILLS.md под Джеймикс, преднастроенные инструменты и проверки на выходе. 

Ниже разберем шесть составляющих такого харнесса. Мы собрали их в KodaCode для Jmix-проектов: пакет навыков, преднастроенные инструменты и проверки на выходе. Это можно собрать самостоятельно, но на практике такой путь занимает месяцы проб и ошибок.

Автор оригинальной статьи: Daniel Terhorst-North 

Вы можете накормить волков и сохранить овец, если сделаете все правильно.

Многие организации живут в постоянном напряжении между двумя путями разработки: быстрым, но «грязным», и надежным, но медленным. Одни торопятся, оправдывая технический долг «прагматизмом», другие осторожничают, опасаясь ошибок и занимаясь оверинженерингом. Я предлагаю третий путь — «лучшую простую систему на сегодня» (Best Simple System for Now, BSSN), которая сочетает преимущества обоих подходов и не заставляет идти на компромиссы.

Недавно состоялся долгожданный релиз OpenIDE — открытой среды для профессиональной разработки (Spring Boot/Java/Kotlin и многое другое) от консорциума «Haulmont – Axiom – Astra», построенной на принципах открытости, свободы и отсутствия какой-либо дискриминации. В отличие от конкурентов, эта IDE не позиционирует себя как очередное решение для «импортозамещения», а является самостоятельным продуктом, нацеленным на решение широкого спектра задач современной разработки.  

К написанию данной статьи дополнительным стимулом стал «повышенный интерес» сообщества Jmix-разработчиков к GigaIDE от Сбера, релиз которой состоялся почти год назад (27 июня 2024 года). За прошедшее время те, кто хотел, уже успели ознакомиться с возможностями GigaIDE. Теперь же разработчики получили возможность попробовать OpenIDE и сравнить её с предыдущей альтернативой. 

Цель сегодняшней статьи — подробно сравнить эти два продукта и ответить на важные вопросы.

Как описать хороший код в трех словах? Исходя из опыта — это код, который [приятно поддерживать и эксплуатировать]. СОЛИД, SOLID, СОЛИД... Редко код ревью обходится без упоминания этих принципов, но для разработчика это не означает ничего хорошего. А что, если я скажу вам, что есть альтернатива? Недавно я наткнулся на одну англоязычную статью в блоге автора по имени Dan North. Он поднимает крайне интересные темы: написание хорошего кода, поддержка кодовой базы, порочные практики следования устаревшим трафаретам. 

Думаю, для каждого программиста не секрет, что не всегда есть время и возможность подгонять свое решение под SOLID. Иногда проще оценивать свой код по шкале «хорошего кода» без трафаретов. Тут, конечно, прибегут некоторые люди, которые будут утверждать, что их проекты не содержат говнокода и легаси... Это все просто побег от реальности, нежелание принимать то, что любые проекты и их кодовые базы — это вечные «макароны». В общем, идеализация разработки, которая ни к чему, кроме душевных страданий, не ведет.