Статья - комментарий / возражение к статье Осознанный вайб-кодинг. Осознанный вайб-кодинг наверное лучше не Осознанного, но последний тоже работает.
Введение
Ранее «баловался» с «Осознанным вайб-кодингом» - когда вникаешь / погружаешься в код, сгенерированный ИИ, в основном you.com и deepSeek. При этом часто испытывал разочарование, особенно когда просил его использовать непопулярные js-библиотеки.
Ниже поделился «свежим» примером «НеОсознанный вайб-кодинг», т.е. когда в код не вникаешь и это работает. К тому же, должно быть интересно тем, кому нужен RDF Grapher.
Из Осознанного вайб-кодинга (@davidaganov):
Границы вайб-кодинга
Отдельно хочется сказать про генерацию целых сайтов и приложений без какого-либо контроля со стороны человека. Разные сервисы в духе "сделай мне сайт или приложение по описанию" выглядят эффектно, но на практике я считаю такой подход нежизнеспособным.
На первых этапах всё действительно может выглядеть нормально. Можно даже наделать скриншотов приложения и запостить их в интернет, чтобы уделать неверующих в неизбежный прогресс и скорое сокращение всей айти-индустрии. Но проблемы почти всегда начинаются ровно в тот момент, когда требуется внести правки, разобраться в баге или запилить новую фичу. Без понимания архитектуры и происходящего в коде ты очень быстро теряешь контроль над системой.
По этой же причине я считаю вайб-кодинг без крепкой технической базы тупиковым.
Видимо зависит не только от сложности самого проекта, но и от его описания и «обычности» (распространение, стандартизация, коммодитизация). В части «описания» есть опасения (видимо от версии ИИ зависит), что если большая часть материалов в pdf, то ИИ будет сложнее "вникать", чем если та же информация в web (html). Ниже будет пример, как можно реализовать сценарий: Вот тебе ссылка на «ныне» не «очень доступный в РФ» online сервис, повтори мне такой же на моем github.
ты не можешь оценить его качество,
С этим как раз проще, если сравнивать оба сервиса по пользовательским характеристикам. Какая там архитектура, качество кода и т.п. – какая пользователю разница? Если пользователю новый сервис внешне кажется не хуже, то задача выполнена «на отлично». При этом задача выполнена за пол часа, включая создание репозитария и выгрузку на github Pages, т.е. решение «под ключ».
Ниже сценарий использования, когда с почти первого промта получаем желаемое рабочее приложение / сервис (аналог исходному).
1 Проблема «Сервис визуализации RDF \ RDF Grapher
Была проблема. Когда делал статьи по Semantic BPM, то для визуализации схем в тексте статьи использовал финский on-line сервис: https://www.ldf.fi/service/rdf-grapher.
В него «кидаем» URL-параметром RDF-данные и смотрим сгенерированную по этим данным схему (RDF Viewer).
Также URL-параметром передаются схемы в mermaid (https://mermaid.live/ например, архитектура в графе) или graphviz, пример из https://github.com/bpmbpm/rdf-grapher версии ver4p.
RDF, Resource Description Framework (RDF, «среда описания ресурса») — это разработанная консорциумом Всемирной паутины модель для представления данных (wiki или w3.org). Пример применения: библиографические данные в RDF.
Это все к темам Semantic Web, Linked Data, язык знаний, база знаний и т.п. Приемы RDF – данных в сервисе «по кнопке», см. "Загрузить пример RDF данных:". Также см. RDF for dummies.
RDF-данные визуализируются с помощью графа: RDF Grapher - Программа для построения графов по RDF-данным. Однако после известных событий финский сервис стал работать только с VPN и многие стали по ссылкам из статьи видеть не схемы, а «пустой экран». Хотел найти аналогичный RDF Grapher, но найденные не умели передавать данные параметром к URL.
«Руками» такой сервис я бы собрал не быстро. Не найдя ни одного подобного on-line сервиса, решил делать свой «руками ИИ» и заодно добавлять в него всё, чего «захочется».
Ниже «волшебная таблетка», позволяющая такой сервис реализовать на github в «пару касаний» (парой Issues) посредством: https://github.com/link-assistant/hive-mind
1 Делай Раз (подготовка)
1.1 На github.com создаем репозитарий (не забудьте предварительно зарегистрироваться):
https://github.com/bpmbpm?tab=repositories + new
Repository name: rdf-grapher
Description: RDF grapher is a web service for parsing RDF data and visualizing it as a graph.
1.2 Добавление сервиса GitHub Pages
(просто "включить")
1.3 выбирает ИИ-кодера
2 Делай Два (сам кодинг)
2.1 Создаём стартовый (может хватить и единственного) промт:
Повтори в точности по функционалу сервис https://www.ldf.fi/service/rdf-grapher. Используй те же Redland Raptor and Graphviz.
Код напиши на JS. Сервис должен работать через сервис GitHub Pages.
Проект должен быть размещен в папке: https://github.com/bpmbpm/rdf-grapher/tree/main/ver1
Запуск сервиса через https://github.com/bpmbpm/rdf-grapher/tree/main/ver1/index.html
2.2 Смотрим результат: https://bpmbpm.github.io/rdf-grapher/ver1/index.html
При необходимости утоняем задачу через новый промт (с первого раза может не получиться задуманное). В проекте все Issues и Pull requests видны «как на ладони».
Работа с сервисом проста, в минимальном варианте: открываем страничку, выбираем пример и нажимаем кнопку «Визуализировать».
3 Итого
Исходный rdf-grapher (нужен VPN): https://www.ldf.fi/service/rdf-grapher
Новый rdf-grapher (на примере ver1): https://bpmbpm.github.io/rdf-grapher/ver1/
https://github.com/bpmbpm/rdf-grapher/tree/main/ver1
Пример с URL параметром из ver1.
Теперь есть свой сервис rdf-grapher с параметром и без VPN – как аналог финского. На https://github.com/bpmbpm/rdf-grapher также можно посмотреть ver2 и ver3 c более продвинутыми «фишками».
Конечно приведенная задача может быть и не такая «шибко сложная», но вполне сработала до пром-варианта (или еще нет?). Если есть замечания к ver1-ver2-ver3 на https://github.com/bpmbpm/rdf-grapher – буду им рад. Вообще, сервис "свежий" и еще особо не тестировал, т.к. "пошел дальше" к Ver4 и Ver5 (это в сторону Semantic BPM).
Более сложная задача с промтом: «Повтори мне ARIS Express» - так просто «не взлетела», полагаю, что в первую очередь потому, что не online-сервис и по нему мало документации даже в установленном desktop приложении.
Вопрос: Есть ли ИИ-агенты, которым на вход показываешь онлайн-сервис (или desktop приложение), он его изучает и тестирует (создает кейс-тесты), потом генерит код и этими тест-кейсами сам проверяет?
Со временем полагаю, что подобное станет нормой и ПО даже класса ARIS ToolSet будет создаваться «по кнопке» не хуже оригинала. Самое главное: не нужно придумывать (изобретать велосипед) функциональные требования, ТЗ и т.п., а просто можно сказать: «Повтори Это». А уже потом улучшать, т.е. делать "свой ARIS++".
Спасибо @Konard за сервис ИИ програмера.
kiff2007200
Какая там архитектура, качество кода и т.п. – какая пользователю разница?Без комментариев...
AleGen
А что не так?... Пользователю действительно нет никакой разницы. "Вам шашечки, или ехать?"
Суть статьи - в том, что ИИ может помочь сгенерить MVP малыми силами, не привлекая дорогих разрабов. В результате первоначальная задача решается, а разрабы идут на мороз.
Да, вопросы рефакторинга, безопасности, расширяемости, развития и т.д. остаются, но они будут актуальны лишь для 1% всех "создателей" приложений - лишь для тех, кто пилил не пет, и кто выжил и довел дело до конца; вот тогда и можно будет нанять одного из ста разрабов с мороза, который уже будет готов работать за хлеб. ))
Возможно, написал немного утрированно, прошу не придираться к словам.
abve_san
То есть это всё не про деньги и прод, а про плюс-минус студентов и школьников, которые пишут код для оценки, по сути, на отвали. На данный момент никаких проблем нет. Всё верно. Проблемы возникнут тогда, (судя по всему, очень скоро), когда выяснится, что все фирмы, делающие AI, сидят в диких убытках, и они начнут просить серьёзные деньги за доступ к адекватным моделям. И если у корпов деньги есть и они справятся так или иначе. То ко всем студентам, которые пару лет маялись дурью, придёт зима с морозами.
itGuevara Автор
Чем указанный в статье аналог популярного финского сервиса, не считать продом? Чем развернутый пример на github не решение указанной проблемы?
abve_san
Прод это, про обслуживание, безопасность, масштабирование и многое другое. Программирование в списке тоже есть, но отнимает не так много ресурсов. И опять повторю свою мысль, что будут делать все эти ребята, когда вдруг компании AI начнут требовать большие деньги ( убытки-то покрывать надо) за доступ к сильным моделям, а то, что это случится, мне лично очевидно.
itGuevara Автор
Если ближе к приведенному примеру (статический web, js и подобное на github pages или аналоге), то в чем видите проблему например безопасности и обслуживания? Разве развертывание публичного сервиса на площадках типа github не перекладывает на них (платформы) основную часть проблем?
abve_san
На мой взгляд следует разделять прод который существует с целью зарабатывания денег тем или иным способом и там в подавляющем проценте случаев невозможны сайты с парой статичных HTML. И проектaми условных "студентов" которыми забит git. И если бизнес сидит в условном облаке, то часть проблем безопасности и обслуживания передается на откуп этому облаку, но только часть. Например дурацкую ошибку в логине позволяющую злоумышленнику захватить сайт никакое облако не покроет. Или проблемы масштабирования и быстродействия, далеко не всё решается через: "А давайте купим ещё памяти". Так как очень быстро наступает момент когда расходы на инфраструктуру становятся не подьёмными. С другой стороны для условного "студента "такого рода проблемы не имеют критического значения.
itGuevara Автор
Как вариант, "прод", который "без денег" (без "наживы", условно коммунистический, общественно - значимый, open source типа semantic wikipedia, archi, adoxx и т.п.).
Или про pre-prod (как вариант pre-sale), типа макет, но действующий, когда граница макет / пром достаточно размыта. Кстати, вопрос масштабирования тоже решаемый, но вопрос был про безопасность, обслуживание и т.п.
Возвращаясь к приведенному в статье примеру визуализации RDF по URL - в чем проблема? Желательно подробно. Почему это не прод, который "без денег"?
Также: ошибка в логин не при чем, т.к. приведенный сервис публичный (без авторизации), а проблема инфраструктуры не на создателе сервиса, а на владельце платформы (его тарифах), вкл. авторизацию по аккаунту создателя сервиса. Круче MS (github, copilot и т.п.) мало у кого выйдет подобное.
Хотелось бы применительно к озвученному выше публичному сервису "rdf - визуализатор с url" услышать ограничения / проблемы.
И не важно: студент это или "седой" senior. Важен результат, а не титул и не то, что "под капотом" (круто-крутая архитектура и т.п., хотя и в промте можно задать желаемую архитектуру), т е. важен реально "эксплуатируемый", практичный / практический результат.