У нас .net ef + hot chocolate graphql. И много sql вообще под капотом собирается. Например, фильтры для админок склеиваются с фильтрами для контроля доступа, сверху докидываются сортировки, и т.п. Понятно, что в этом случае контроль над sql вообще утерян, но нам вроде и не надо - для всяких табличек в админах особенно.
В твоем подходе какая-то композиция запросов предполагается? Или только средствами БД (вьюшки и т.п.)?
Пока непонятно куда этот вайб-код малый бизнес должен засовывать, и куда он будет данные хранить. Каждый вайб-кодер поднимет себе мешок лямбд на питонах, постгре-баз, вперемешку с вызовами API CRM и 1С, и чуть-чуть эксельками на яндекс-дисках?
Не умеют они нормально выбирать api, и подбирать параметры на входе. А некоторые вещи - типа «в каких городах у меня больше всего заказов» - через типичное api просто не сделать.
Пилю похожего агента, и тоже дал ей писать js в стиле «на тебе массив всего, доставай что нужно» - и это работает прям в разы лучше, чем работало api.
Мне вот интересно, в плане альтернативной истории — можно ли было запихнуть во все эти zx spectrum-ы и распиарить в школах scheme? Да, надо GC делать, но в остальном он выглядит даже проще в реализации - почти не надо парсить, проще редактор, проще интерпретатор.
Каков бы был мир, если детей уже лет 40 учили бы по sicp?
Basic же задурил голову, сделав много чего простого настолько сложным, что мы до сих пор разгребаем.
Схему надо передавать с описанием тула, а не в промпт. Тогда когда llm будет инферить параметры, ее генерацию ограничивают так, чтобы json был валидный и по схеме.
Типичный сценарий для современного IT: - берем общий термин или идею (FSD, или там Immutable State) - делаем как-получится реализацию (feature-sliced.design, или там Redux) - пиарим люто бешенно - у людей создаётся ассоциация FSD=feature-sliced.design, Immutable State = Redux - люди начинают считать изначальную идею - плохой, хотя плохая была - реализация
FSD как идея, в том же реакте живёт прям от входа: компоненты лежат в папочке со своими хуками, CSS, и логикой. И отлично это работает. И по-инерции, народ пишет так не только компоненты. В общем, многие проекты на React (особенно без Redux) - они уже Feature-Sliced.
Но нет - пришли люди с папочками, линтерами, и красивым веб-сайтом. Решили научить жить правильно. И вот - пошла справедливая контр-реакция. Но направленная теперь - против самой идеи.
И вот, на полном серьезе людям предлагают переходить на Layered Architecture. Как на беке, да. Где, если что, вообще за все годы не научились делать большие проекты. Где с этими нашими слоями, всю дорогу не получалось ничего кроме лапши. И где единственный способ как-то себе запретить делать лапшу - прям физически разнести код по репозиториям. Это называется "микросервисы", и "микросервисы" переводится как "мы так и не научились разложить код по папочкам".
Не надо тащить эту ошибку на фронт. Я вот сейчас наоборот пытаюсь эти идеи забирать в бек. Чем плоха монорепа, где у тебя те внутри сервисы, взаимодействующие друг с другом через понятные API? Разве это хуже, чем один гигантский DataLayer на сотни таблиц, и бизнес-логика - ходящая рандомно в любую часть БД?
Всё очень сильно зависит от приложения. Я вот тоже пишу уже лет 18 бизнес-приложения, и какой-то прям отделяемой бизнес-логики на фронте - толком и не видел. Логика самого UI - да, бывает прям очень навороченной, всякие там WYSIWYG-билдеры, редактируемые диаграммы Ганта, и т.п. Но вот чтобы прям какую-то сложную функцию про бизнес, не привязанную к UI выделить - это скорее редкость. Это на беке всё обычно.
Но я представляю бизнес-логики может быть много. У всех по-разному. У кого-то там API ходит в 50 микросервисов, постоянно бек просит переделать, и надо слой абстракции. Джависты любят нафигачить по REST своих GET/POST/PUT, и там даже для странички данные достать - уже на пол-страницы кода. А у кого-то - какой-нибудь один стабильный GraphQL, всё что хочешь достаётся одним запросом, и куда удобнее запросы эти класть рядом с компонентом.
Из-за того, что у всех разное - рассуждения о том, какие именно должны быть папки прям в каждом приложении - скорее вообще губительны. Я видел классные, понятные, проекты, где рядом лежат папки с визуальными компонентами, хелперами про бизнес, и т.п - у любителей FSD волосы на жопе зашевелятся, но всё понятно и круто. И видел проекты где лид любит вот эти все папочки, и там пока что-то поймешь - через 10 слоёв надо пройти, менять что-то страшно, а разобраться что где - нереально.
Работает понимание где код разбивать на модули, приёмы как это делать, здоровый перфекционизм, и трудолюбие чтобы постоянно что-то рефачить.
Разделение на слои - это по-факту декомпозиция "для галочки". Ну типа всё красиво разложено по папочкам, в папочках - файлы с похожим содержимым. Но это не дает каких-то прям сильных плюшек. Каждое изменение затрагивает кучу файлов, которые непонятно кто еще использует. Тестировать - непонятно как, получаются дебильные тесты в стиле "если позвали API и fetch отдал объект X, то API отдал объект X".
"Вертикальное" разделение - когда в каждой папочке-подсистеме какой-то понятный кусок функционала, с выставленным API - делать сложнее, но оно даёт плюшки. Можно какие-то вещи делать не выходя из этой папочки (если её API не меняется). На чанки приложение лучше разбивается. И - если вообще всё идеально - что-то можно выносить в библиотеки и использовать в нескольких приложениях. А может даже даже будет просто распилить приложение на два.
Ошибка FSD - это чрезмерно настаивать каких видов нужно делать папочки-модули, и как они должны быть связаны. Ну типа различать features и widgets. Можно ведь делить как угодно, оставляя саму идею.
По-факту, в реальных приложениях часто микс обоих подходов. Общие компоненты - почти всегда выделены как модули, правда не всегда следят чтобы API был нормальный. Какие-нибудь react hooks - сваливают в общую папку по принципу "это же хуки" - и те что общие, и те что нужны одной страничке.
В общем, мысль в том, что думать надо чуть выше абстракциями. Ну, что каждая папочка - это модуль, от него должна быть какая-то польза (проще взять его, чем написать прям по месту), хороший API. И поменьше придумывать синтетические ограничения себе, в стиле "давайте заранее придумаем какие у нас папочки будут, и что будет в них".
Так я и предлагаю не к интернету прикручивать, а к тому же Консультанту. Дать ей тот же API для поиска, и пусть ищет себе по ключевым, векторным, или историю изменений смотрит.
Мысль тут в том, что вместо того, чтобы делать убер-поиск по векторам, дать те же инструменты что человеку. Оно нормально этим умеет пользоваться. И что удобно человеку - ей тоже норм.
Я, в целом, думаю что всем, кто делает LLM-based продукты, надо присмотреться к Cursor, и как им пользуются. Там же типа «собери инфу про то-то, сложи в файлик», «теперь вот эти файлики посмотри и сделай то-то», «теперь проанализируй что мы делали - и сделай себе инструкцию на будущее». Т.е. там нет попытки сделать магию - чтобы один промпт пишешь и оно само. Там дают инструмент, чтобы вести ее по шагам, и каждый шаг контроллировать.
Мне думается, что с LLM только этот путь более-менее и работает - когда ты командуешь, разбиваешь на подзадачи, и проверяешь каждый шаг. Да, он требует научиться этим пользоваться. Но, видимо, придется всем учиться.
А как юристы это всё до LLM искали и обрабатывали? Я тут смотрю на RAG-подход (пытаться найти сразу всё нужное по тексту), и агентный (дать инструменты поиска и анализа через MCP - и пусть сама ищет). И во многих случаях второе работает лучше, хоть и жрет больше токенов.
Т.е. может лучше давать ей поиск, инструмент чтобы доставать историю с дельтами, ходить по ссылкам, доставать выжимки документов? Ну т.е. API от того же UI юридической какой-то БД, и пусть оно само ковыряется?
В Cursor том же именно так делают, а они вроде фишку секут.
Если не надо было бы инфоповод и хайпануть, могли бы вместо этого хитрого протокола, просто REST API с OpenAPI-спекой подключать.
С этой новой прекрасной идеей, ждём новую версию протокола, где для Tool можно схему ответа указать. А то там сейчас тупо текст, и как модель сможет написать код, который как-то результат обработает - не ясно.
Конкретно эту я давал офлайн решать, ребятам из учебки - там это было уместно.
Для онлайн "при зрителях" - она прям слишком сложная. У меня для собесов задачи прям супер-простые, в т.ч. чтобы не парализовало. Уровня дописать полу-готовый ToDo List на React, или вынуть суммы из трех связанных таблиц на .NET.
Но задачи все - с кучей точек где что-то дописать, спросить, обсудить.
Как-то на каком-то похожем сайте решал задачки давно.
И там была задачка - дано сколько-то «рук» в покере - надо посчитать когда левая бьет правую комбинацию.
И мне она так понравилась, что я её давал как тестовую потом.
Прикол в том, что это не сложная какая-то муть про o(n), это максимально близко к тому, что приходится писать в бизнес-приложениях: куча странных условий друг на друге. И написать это красиво и понятно - надо прям уметь.
Разработчикам то может и нравится. Вот понравится ли бизнесу 5х оценки на добавление одного атрибута к продукту, и потом еще неделя т.к. «ой не в тот сервис положили, надо рефакторинг и миграцию данных.
У нас .net ef + hot chocolate graphql. И много sql вообще под капотом собирается. Например, фильтры для админок склеиваются с фильтрами для контроля доступа, сверху докидываются сортировки, и т.п. Понятно, что в этом случае контроль над sql вообще утерян, но нам вроде и не надо - для всяких табличек в админах особенно.
В твоем подходе какая-то композиция запросов предполагается? Или только средствами БД (вьюшки и т.п.)?
Пока непонятно куда этот вайб-код малый бизнес должен засовывать, и куда он будет данные хранить. Каждый вайб-кодер поднимет себе мешок лямбд на питонах, постгре-баз, вперемешку с вызовами API CRM и 1С, и чуть-чуть эксельками на яндекс-дисках?
Не умеют они нормально выбирать api, и подбирать параметры на входе. А некоторые вещи - типа «в каких городах у меня больше всего заказов» - через типичное api просто не сделать.
Пилю похожего агента, и тоже дал ей писать js в стиле «на тебе массив всего, доставай что нужно» - и это работает прям в разы лучше, чем работало api.
И этот тул - через mcp.
Мне вот интересно, в плане альтернативной истории — можно ли было запихнуть во все эти zx spectrum-ы и распиарить в школах scheme? Да, надо GC делать, но в остальном он выглядит даже проще в реализации - почти не надо парсить, проще редактор, проще интерпретатор.
Каков бы был мир, если детей уже лет 40 учили бы по sicp?
Basic же задурил голову, сделав много чего простого настолько сложным, что мы до сих пор разгребаем.
А чем Lens от Iso отличается?
Осталось к браузерам прикрутить плагин, и будет нам гипертекстовый векторный фидонет.
Схему надо передавать с описанием тула, а не в промпт. Тогда когда llm будет инферить параметры, ее генерацию ограничивают так, чтобы json был валидный и по схеме.
Всегда знал, что питон - всратый, бесполезный язык.
Мы микрофронты грузим тупо через стандартный import(). Зачем нужно Single SPA - я так и не понял.
А реакт и UI kit общие, или каждый свой грузит?
Типичный сценарий для современного IT:
- берем общий термин или идею (FSD, или там Immutable State)
- делаем как-получится реализацию (feature-sliced.design, или там Redux)
- пиарим люто бешенно
- у людей создаётся ассоциация FSD=feature-sliced.design, Immutable State = Redux
- люди начинают считать изначальную идею - плохой, хотя плохая была - реализация
FSD как идея, в том же реакте живёт прям от входа: компоненты лежат в папочке со своими хуками, CSS, и логикой. И отлично это работает. И по-инерции, народ пишет так не только компоненты. В общем, многие проекты на React (особенно без Redux) - они уже Feature-Sliced.
Но нет - пришли люди с папочками, линтерами, и красивым веб-сайтом. Решили научить жить правильно. И вот - пошла справедливая контр-реакция. Но направленная теперь - против самой идеи.
И вот, на полном серьезе людям предлагают переходить на Layered Architecture. Как на беке, да. Где, если что, вообще за все годы не научились делать большие проекты. Где с этими нашими слоями, всю дорогу не получалось ничего кроме лапши. И где единственный способ как-то себе запретить делать лапшу - прям физически разнести код по репозиториям. Это называется "микросервисы", и "микросервисы" переводится как "мы так и не научились разложить код по папочкам".
Не надо тащить эту ошибку на фронт. Я вот сейчас наоборот пытаюсь эти идеи забирать в бек. Чем плоха монорепа, где у тебя те внутри сервисы, взаимодействующие друг с другом через понятные API? Разве это хуже, чем один гигантский DataLayer на сотни таблиц, и бизнес-логика - ходящая рандомно в любую часть БД?
Всё очень сильно зависит от приложения. Я вот тоже пишу уже лет 18 бизнес-приложения, и какой-то прям отделяемой бизнес-логики на фронте - толком и не видел. Логика самого UI - да, бывает прям очень навороченной, всякие там WYSIWYG-билдеры, редактируемые диаграммы Ганта, и т.п. Но вот чтобы прям какую-то сложную функцию про бизнес, не привязанную к UI выделить - это скорее редкость. Это на беке всё обычно.
Но я представляю бизнес-логики может быть много. У всех по-разному. У кого-то там API ходит в 50 микросервисов, постоянно бек просит переделать, и надо слой абстракции. Джависты любят нафигачить по REST своих GET/POST/PUT, и там даже для странички данные достать - уже на пол-страницы кода. А у кого-то - какой-нибудь один стабильный GraphQL, всё что хочешь достаётся одним запросом, и куда удобнее запросы эти класть рядом с компонентом.
Из-за того, что у всех разное - рассуждения о том, какие именно должны быть папки прям в каждом приложении - скорее вообще губительны. Я видел классные, понятные, проекты, где рядом лежат папки с визуальными компонентами, хелперами про бизнес, и т.п - у любителей FSD волосы на жопе зашевелятся, но всё понятно и круто. И видел проекты где лид любит вот эти все папочки, и там пока что-то поймешь - через 10 слоёв надо пройти, менять что-то страшно, а разобраться что где - нереально.
Работает понимание где код разбивать на модули, приёмы как это делать, здоровый перфекционизм, и трудолюбие чтобы постоянно что-то рефачить.
Разделение на слои - это по-факту декомпозиция "для галочки". Ну типа всё красиво разложено по папочкам, в папочках - файлы с похожим содержимым. Но это не дает каких-то прям сильных плюшек. Каждое изменение затрагивает кучу файлов, которые непонятно кто еще использует. Тестировать - непонятно как, получаются дебильные тесты в стиле "если позвали API и fetch отдал объект X, то API отдал объект X".
"Вертикальное" разделение - когда в каждой папочке-подсистеме какой-то понятный кусок функционала, с выставленным API - делать сложнее, но оно даёт плюшки. Можно какие-то вещи делать не выходя из этой папочки (если её API не меняется). На чанки приложение лучше разбивается. И - если вообще всё идеально - что-то можно выносить в библиотеки и использовать в нескольких приложениях. А может даже даже будет просто распилить приложение на два.
Ошибка FSD - это чрезмерно настаивать каких видов нужно делать папочки-модули, и как они должны быть связаны. Ну типа различать features и widgets. Можно ведь делить как угодно, оставляя саму идею.
По-факту, в реальных приложениях часто микс обоих подходов. Общие компоненты - почти всегда выделены как модули, правда не всегда следят чтобы API был нормальный. Какие-нибудь react hooks - сваливают в общую папку по принципу "это же хуки" - и те что общие, и те что нужны одной страничке.
В общем, мысль в том, что думать надо чуть выше абстракциями. Ну, что каждая папочка - это модуль, от него должна быть какая-то польза (проще взять его, чем написать прям по месту), хороший API. И поменьше придумывать синтетические ограничения себе, в стиле "давайте заранее придумаем какие у нас папочки будут, и что будет в них".
Так я и предлагаю не к интернету прикручивать, а к тому же Консультанту. Дать ей тот же API для поиска, и пусть ищет себе по ключевым, векторным, или историю изменений смотрит.
Мысль тут в том, что вместо того, чтобы делать убер-поиск по векторам, дать те же инструменты что человеку. Оно нормально этим умеет пользоваться. И что удобно человеку - ей тоже норм.
Я, в целом, думаю что всем, кто делает LLM-based продукты, надо присмотреться к Cursor, и как им пользуются. Там же типа «собери инфу про то-то, сложи в файлик», «теперь вот эти файлики посмотри и сделай то-то», «теперь проанализируй что мы делали - и сделай себе инструкцию на будущее». Т.е. там нет попытки сделать магию - чтобы один промпт пишешь и оно само. Там дают инструмент, чтобы вести ее по шагам, и каждый шаг контроллировать.
Мне думается, что с LLM только этот путь более-менее и работает - когда ты командуешь, разбиваешь на подзадачи, и проверяешь каждый шаг. Да, он требует научиться этим пользоваться. Но, видимо, придется всем учиться.
А как юристы это всё до LLM искали и обрабатывали? Я тут смотрю на RAG-подход (пытаться найти сразу всё нужное по тексту), и агентный (дать инструменты поиска и анализа через MCP - и пусть сама ищет). И во многих случаях второе работает лучше, хоть и жрет больше токенов.
Т.е. может лучше давать ей поиск, инструмент чтобы доставать историю с дельтами, ходить по ссылкам, доставать выжимки документов? Ну т.е. API от того же UI юридической какой-то БД, и пусть оно само ковыряется?
В Cursor том же именно так делают, а они вроде фишку секут.
Если не надо было бы инфоповод и хайпануть, могли бы вместо этого хитрого протокола, просто REST API с OpenAPI-спекой подключать.
С этой новой прекрасной идеей, ждём новую версию протокола, где для Tool можно схему ответа указать. А то там сейчас тупо текст, и как модель сможет написать код, который как-то результат обработает - не ясно.
Конкретно эту я давал офлайн решать, ребятам из учебки - там это было уместно.
Для онлайн "при зрителях" - она прям слишком сложная. У меня для собесов задачи прям супер-простые, в т.ч. чтобы не парализовало. Уровня дописать полу-готовый ToDo List на React, или вынуть суммы из трех связанных таблиц на .NET.
Но задачи все - с кучей точек где что-то дописать, спросить, обсудить.
Вот она: https://projecteuler.net/problem=54
Как-то на каком-то похожем сайте решал задачки давно.
И там была задачка - дано сколько-то «рук» в покере - надо посчитать когда левая бьет правую комбинацию.
И мне она так понравилась, что я её давал как тестовую потом.
Прикол в том, что это не сложная какая-то муть про o(n), это максимально близко к тому, что приходится писать в бизнес-приложениях: куча странных условий друг на друге. И написать это красиво и понятно - надо прям уметь.
Такие задачки на leetcode попадаются?
Разработчикам то может и нравится. Вот понравится ли бизнесу 5х оценки на добавление одного атрибута к продукту, и потом еще неделя т.к. «ой не в тот сервис положили, надо рефакторинг и миграцию данных.
Да Entity Framework тот же.