Для GraphQL (пока ещё) не делал. А вот SQL-запрос автомагически в одной из систем писал. К сожалению, коммерческая разработка, так что source не покажу. Но работает.
Им, похоже, даже периодически кто-то помимо меня пользуется. Основные идеи: поточная обработка, независимость от моделей и их динамический анализ, расширяемость синтаксиса. Ну и сверху от этого второй компонент, который умеет генерировать репорты в CSV, HTML, PDF и Excel.
Так по этой логике и продукты не нужны - зачем условному ИИ-писателю Word, условному ИИ-проектировщику Autocad, условному ИИ-блогеру клиент Instagram? Продукты, получается, тоже не нужны, и разрабатывать их незачем и не для кого.
"Никто не будет отвечать"... Даже если мы сейчас не говорим о банковских приложениях или хотя бы об онлайн-пиццерии - много ли будет добровольных пользователей у какого-нибудь глючного погодного виджета, который периодически теряет настройки и путается в долготе и широте?
Вот написаны по спецификации тесты, они все зеленые. А у какого-то пользоваля что-то не работает. Что делать? Снова идти в это казино и фигачить ручку? А какая гарантия, что после этого не отвалится что-то у других пользователей? В отличие от человеческой разработки slot-machine-driven-development не приводит к наработке экспертизы, поэтому любая проблема становится новой и непонятной.
Во-первых, кто отвечает за код, написанный ИИ? Если вы, то - плохая новость - вы обязаны понимать то, что там нагенерировалось. А созданные тем же ИИ тесты по тому же ТЗ обычно зелёные вне зависимости от...
Простыня на 10к строк ИИ тоже понимается далеко не идеально - контекст ограничен.
К тому же паттерны - это штука не только для управления контекстом (человечьим или иишным), но и для управления сложностью. На ум приходит аналогия со строительством домов: мол, раньше для управления объёмом строили из маленьких кирпичиков, а теперь можем просто сразу заливать бетон. Только вот окна и двери, проводка, канализация, вентиляция из бетона не делается, поэтому все "абстракции реализации" остались на месте, хотя из маленьких кирпичиков сами мы теперь можем не строить.
Ну и нельзя не упомянуть про "бесплатность" ИИ-слот-машины. Каждый раз, дергая рычаг этого однорукого бандита, приходится расплачиваться фантиками настоящими деньгами. Причем с каждой новой версией модели денежек сгорает всё больше, а результат сильно предсказуемее не становится.
При таком подходе надо дальше смотреть: а зачем вообще писать какой-то софт, если иишечка с этим сможет справиться самостоятельно?
Никаких офисных пакетов - будут сразу приходить красиво свёрстанные документы, которые, впрочем, читать всё равно все будут через "Иишечка, вот мне тут что-то пришло, прочитай и расскажи в 3 предложениях как для пятилетнего ребёнка".
Вместо сложных и непонятных ERP - CEO (он же бухгалтер, он же уборщик) будет командовать "отправь декларацию в налоговую!"
Всякие автокады и прочее тоже не нужны - иишечка будет проектировать красивое, расчитывать нагрузки и планировать пожарную безопасность.
"Невыполнимое" и "не выполняемое" - это две разные штуки.
Чтобы ваша аишечка что-то сделала, её надо, обычно, явно об этом попросить. А если вы не знаете, ввиду отсутствия собственной экспертизы, о чем просить... Ну, удачи, чо.
Кажется, вы не очень внимательно прочитали мой комментарий, суть которого в том, что оценивать некоторые нефункциональные требования (например, сложность алгоритма), глядя на черный ящик - зачастую так себе идея.
Если работать jsonоукладчиком, то, наверное, это не так важно, хотя, например, "N+1 problem" - очень популярная штука в процессе выборки данных.
Именно сложных алгоритмов действительно требует малая часть кода, но вот покрытие здравым смыслом должно стремиться хотя бы к 50%.
Вот зафигачила вам LLM-ка сортировку пузырьком. Вы для детекта этого знаменательного события предпочтёте workload-тест запустить, или всё-таки в код посмотреть?
И, не глядя в код, как вы догадаетесь о наличии обработки ошибок?
Входить в Шенген - это на Кипре национальный спорт. Когда я туда по ошибке на годик приехал "пожить" в 2016, там тоже обещали, что вот-вот войдет, может быть даже в 2017.
По факту же, пока вопрос с северной частью острова не решится, никакого Шенгена не будет.
Что Palm, что WinMobile - обе системы оставили приятные воспоминания. Нетребовательность к железу, объемный набор софта (включая аудио- и видео- плееры, читалки, карты, игрушки...), и, что удивительно, возможность создавать красивый, понятный и удобный интерфейс в 160x160 пикселях на экранах до 3''.
Для GraphQL (пока ещё) не делал. А вот SQL-запрос автомагически в одной из систем писал. К сожалению, коммерческая разработка, так что source не покажу. Но работает.
Ответил мимо.
О, я в свое время тоже шаблонизатор писал: https://habr.com/ru/articles/560722/
Им, похоже, даже периодически кто-то помимо меня пользуется. Основные идеи: поточная обработка, независимость от моделей и их динамический анализ, расширяемость синтаксиса. Ну и сверху от этого второй компонент, который умеет генерировать репорты в CSV, HTML, PDF и Excel.
Так по этой логике и продукты не нужны - зачем условному ИИ-писателю Word, условному ИИ-проектировщику Autocad, условному ИИ-блогеру клиент Instagram? Продукты, получается, тоже не нужны, и разрабатывать их незачем и не для кого.
"Никто не будет отвечать"... Даже если мы сейчас не говорим о банковских приложениях или хотя бы об онлайн-пиццерии - много ли будет добровольных пользователей у какого-нибудь глючного погодного виджета, который периодически теряет настройки и путается в долготе и широте?
Вот написаны по спецификации тесты, они все зеленые. А у какого-то пользоваля что-то не работает. Что делать? Снова идти в это казино и фигачить ручку? А какая гарантия, что после этого не отвалится что-то у других пользователей? В отличие от человеческой разработки slot-machine-driven-development не приводит к наработке экспертизы, поэтому любая проблема становится новой и непонятной.
Во-первых, кто отвечает за код, написанный ИИ?
Если вы, то - плохая новость - вы обязаны понимать то, что там нагенерировалось. А созданные тем же ИИ тесты по тому же ТЗ обычно зелёные вне зависимости от...
Простыня на 10к строк ИИ тоже понимается далеко не идеально - контекст ограничен.
К тому же паттерны - это штука не только для управления контекстом (человечьим или иишным), но и для управления сложностью.
На ум приходит аналогия со строительством домов: мол, раньше для управления объёмом строили из маленьких кирпичиков, а теперь можем просто сразу заливать бетон. Только вот окна и двери, проводка, канализация, вентиляция из бетона не делается, поэтому все "абстракции реализации" остались на месте, хотя из маленьких кирпичиков сами мы теперь можем не строить.
Ну и нельзя не упомянуть про "бесплатность" ИИ-слот-машины. Каждый раз, дергая рычаг этого однорукого бандита, приходится расплачиваться
фантикаминастоящими деньгами. Причем с каждой новой версией модели денежек сгорает всё больше, а результат сильно предсказуемее не становится.Ну так не называйте, кто ж вас заставляет. А вот use-case очень подходящий.
Плюс к тому, бенчмарки показывают, что даже прогретая JSON-сериализация работает ощутимо быстрее в случае кодогенерации.
А если веб-приложение реализовано как лямбда, у которой проблема холодного старта очень явно выражена?
При таком подходе надо дальше смотреть: а зачем вообще писать какой-то софт, если иишечка с этим сможет справиться самостоятельно?
Никаких офисных пакетов - будут сразу приходить красиво свёрстанные документы, которые, впрочем, читать всё равно все будут через "Иишечка, вот мне тут что-то пришло, прочитай и расскажи в 3 предложениях как для пятилетнего ребёнка".
Вместо сложных и непонятных ERP - CEO (он же бухгалтер, он же уборщик) будет командовать "отправь декларацию в налоговую!"
Всякие автокады и прочее тоже не нужны - иишечка будет проектировать красивое, расчитывать нагрузки и планировать пожарную безопасность.
А загадочный "кто надо" - это кто? И почему он всегда на рынке?
"Невыполнимое" и "не выполняемое" - это две разные штуки.
Чтобы ваша аишечка что-то сделала, её надо, обычно, явно об этом попросить. А если вы не знаете, ввиду отсутствия собственной экспертизы, о чем просить... Ну, удачи, чо.
Кажется, вы не очень внимательно прочитали мой комментарий, суть которого в том, что оценивать некоторые нефункциональные требования (например, сложность алгоритма), глядя на черный ящик - зачастую так себе идея.
Если работать jsonоукладчиком, то, наверное, это не так важно, хотя, например, "N+1 problem" - очень популярная штука в процессе выборки данных.
Именно сложных алгоритмов действительно требует малая часть кода, но вот покрытие здравым смыслом должно стремиться хотя бы к 50%.
Вот зафигачила вам LLM-ка сортировку пузырьком. Вы для детекта этого знаменательного события предпочтёте workload-тест запустить, или всё-таки в код посмотреть?
И, не глядя в код, как вы догадаетесь о наличии обработки ошибок?
PS. А как "решают алгоритмы"?
Почему, если вам лень писать (или хотя бы отредактировать) комментарий самостоятельно, то вы считаете, что остальным будет не лень его читать?
Ага. А мозг к работодателю подключен напрямую. Пальцы в этом не участвуют, пятая точка в офисном кресле не сидит, рот на митингах всегда молчит.
Не говоря о том, что мозг - часть тела, а тушку по частям сдать сложно.
Новая (!) двушка (!!) всего за 200к (!!!)... Эхххх...
Входить в Шенген - это на Кипре национальный спорт. Когда я туда по ошибке на годик приехал "пожить" в 2016, там тоже обещали, что вот-вот войдет, может быть даже в 2017.
По факту же, пока вопрос с северной частью острова не решится, никакого Шенгена не будет.
У ней внутре неонка
«OpenAI for Germany»... Хм, запросы можно будет отправлять по факсу?
Что Palm, что WinMobile - обе системы оставили приятные воспоминания. Нетребовательность к железу, объемный набор софта (включая аудио- и видео- плееры, читалки, карты, игрушки...), и, что удивительно, возможность создавать красивый, понятный и удобный интерфейс в 160x160 пикселях на экранах до 3''.