Раньше куча статей и комментариев на хабре была на тему все должны программировать на хаскеле, теперь про хаскель тихо, зато вместо программистов будет программировать ИИ
Походу свидетели хаскеля массово переконвертировались в свидетелей LLM
// handleData handles the POST request to insert data into the vector database.
func handleData(c *gin.Context) {...}
Это мы в БД добавляем какой-то контекст (не путать с gin.Context )) )
// handleSearch handles the GET request to search for relevant documents based on the query.
func handleSearch(c *gin.Context) { ... }
А это мы ищем ответ на наш вопрос, при этом обращение к БД где-то под капотом (видимо)
Тогда получается что мы не search for relevant documents based on the query, а ищем ответ на вопрос, комбинируя сам вопрос с контекстом, который мы получаем из БД. Ну то есть search for relevant documents это один из промежуточных шагов поиска ответа на вопрос, а не результат поиска
Инструмент имеет ограничения, касающиеся переписывания больших участков кода. Так, он технически может переписать код со старого языка, например Perl, на новый, например Python, но не обязательно будет знать, как создать эффективный код, который использует все возможности более современного языка.
Перевод: ребята решили хайпануть, но внезапно оказалось, что генерируемый новый код не рабочий. Чтобы тем не менее хайпануть оставили перевод в спецификации на natural language. Без примеров обсуждать полезность такого подхода (а не человеко-чтения старого кода перед разработкой нового) сложно.
Генерировать код на основе спецификаций OpenAPI научились задолго до появления LLM. Вот, к примеру, для Go. Ну то есть можно и LLM, наверное, для этого использовать, но в данном случае это не принципиально. Зато бОльшая часть инструментов/библиотек для не-ИИ-кодогенерации абсолютно бесплатная. Чего не скажешь об ИИ.
Не говоря уже о том, что если кодогенератор нагенерил что-то непотребное, можно залезть к нему внутрь и понять почему, и как (и можно ли) это исправить. А почему тот или иной результат выдал черный ящик с несколькими миллиардами хз как полученных параметров - разбираться ну такое. Да, я знаю что вайб-кодеры расскажут про окно контекста, что его надо увеличить, что надо в него загнать весь код проекта, и code style guide, и от себя еще что-то в плане личных пожеланий, а потом еще все это подстраивать чтобы получить требуемый результат. Оно точно быстрее и проще чем работающий код ручками написать?
Если появляется отдельная должность DevOps-инженер между разработчиками и администраторами - значит люди не поняли что такое DevOps и зачем он нужен. Справедливости ради следует заметить, что таких (не понявших) процентов 90. А то и 99.
А то что
девопсу никто не учит
это безусловная и печальная правда. Как и то, что во многих случаях и разработке учат так, что лучше бы не учили.
Любая (общеизвестная) LLM (от Сэма, Амодея, гугла, французов, китайцев, зеленых банков и прочих) при решении задач по электричеству путает системы СИ и СГС. Проверено лично на множестве примеров. Особенно любит складывать диэлектрическую проницаемость вакуума в системе СИ (Ф/м) и просто диэлекрическую проницаемость диэлектрика (безразмерная величина). Ну то есть как килограммы со штуками складывать.
Меня гуглопоиск заваливает своими AI Overview, под которыми сам же расписывется AI responses may include mistakes. С рекламой проще было, ее скипаешь просто и смотришь реальные ответы.
Да, были времена ))
Кстати, Rational Rose, к примеру, как то тихо сошла на нет, а вот ARIS разродился ARIS AI Companion, в ногу со временем идут, молодцы
Раньше куча статей и комментариев на хабре была на тему все должны программировать на хаскеле, теперь про хаскель тихо, зато вместо программистов будет программировать ИИ
Походу свидетели хаскеля массово переконвертировались в свидетелей LLM
Бедная стюардесса, опять ее кто-то выкапывать собрался
Это мы в БД добавляем какой-то контекст (не путать с
gin.Context
)) )А это мы ищем ответ на наш вопрос, при этом обращение к БД где-то под капотом (видимо)
Тогда получается что мы не
search for relevant documents based on the query
, а ищем ответ на вопрос, комбинируя сам вопрос с контекстом, который мы получаем из БД. Ну то естьsearch for relevant documents
это один из промежуточных шагов поиска ответа на вопрос, а не результат поискаБардак в головах надо не автоматизировать а обходить стороной
Перевод: ребята решили хайпануть, но внезапно оказалось, что генерируемый новый код не рабочий. Чтобы тем не менее хайпануть оставили перевод в спецификации на natural language. Без примеров обсуждать полезность такого подхода (а не человеко-чтения старого кода перед разработкой нового) сложно.
А ссылка-то где?
Зачем здесь соединять каждое событие со всеми возможными интервалами аренды?
Существуют (и давно причем) инструменты, позволяющие конвертировать многоколоночный текст PDF в одну колонку(k2pdfopt, к примеру).
Вам точно для этого LLM нужна?
Генерировать код на основе спецификаций OpenAPI научились задолго до появления LLM. Вот, к примеру, для Go. Ну то есть можно и LLM, наверное, для этого использовать, но в данном случае это не принципиально. Зато бОльшая часть инструментов/библиотек для не-ИИ-кодогенерации абсолютно бесплатная. Чего не скажешь об ИИ.
Не говоря уже о том, что если кодогенератор нагенерил что-то непотребное, можно залезть к нему внутрь и понять почему, и как (и можно ли) это исправить. А почему тот или иной результат выдал черный ящик с несколькими миллиардами хз как полученных параметров - разбираться ну такое.
Да, я знаю что вайб-кодеры расскажут про окно контекста, что его надо увеличить, что надо в него загнать весь код проекта, и code style guide, и от себя еще что-то в плане личных пожеланий, а потом еще все это подстраивать чтобы получить требуемый результат. Оно точно быстрее и проще чем работающий код ручками написать?
9:68 на картинке #2 (которая Работа начинается в 10:00) - это опечатка? Или какой-то емкий смысл? Или нейросеть глюкнула? ))
отсюда, к примеру
Если появляется отдельная должность DevOps-инженер между разработчиками и администраторами - значит люди не поняли что такое DevOps и зачем он нужен. Справедливости ради следует заметить, что таких (не понявших) процентов 90. А то и 99.
А то что
это безусловная и печальная правда. Как и то, что во многих случаях и разработке учат так, что лучше бы не учили.
Автор оригинальной статьи - журналист с опытом 30 лет, написавший более 10.000 статей. И не более того. Просто классический пример про слышу звон ...
Любая (общеизвестная) LLM (от Сэма, Амодея, гугла, французов, китайцев, зеленых банков и прочих) при решении задач по электричеству путает системы СИ и СГС. Проверено лично на множестве примеров. Особенно любит складывать диэлектрическую проницаемость вакуума в системе СИ (Ф/м) и просто диэлекрическую проницаемость диэлектрика (безразмерная величина). Ну то есть как килограммы со штуками складывать.
Меня гуглопоиск заваливает своими AI Overview, под которыми сам же расписывется AI responses may include mistakes. С рекламой проще было, ее скипаешь просто и смотришь реальные ответы.
Было бы интересно узнать - весь код, или какие-то специальные задачи (тогда какие именно)?
Применительно к финтеху, естественно.
Не совсем по теме, но:
Я ведь правильно понимаю что во втором случае тоже контекст запроса должен в сервисный слой передаваться?
Ключевые слова выделены. Этим можно хоть про 125% процентов напеть.