Обновить
4
0.1

Пользователь

Отправить сообщение

А теперь попросите исправить код)))

Не согласен. LLM читает быстро, но поверхностно. Если Вы про контекстное окно, то оно забивается очень быстро, после чего LLM забывает всё больше фактов и путается. Если же Вы про обучение, то тут механизм другой. LLM предсказывает наиболее вероятные токены. Так как на просторах гитхаба и в статьях очень много довольно старого материала, логично, что старые фичи будут казаться LLM более вероятными в использовании. А информации по новым фичами действительно недостаточно, т.к. для обучения нужно большое количество примеров

Когда человек читает, он ассоциирует текст со своим опытом. У LLM, увы, нет опыта. В этом принципиальная разница. Поэтому человеку так сложно запомнить что-то большое. И поэтому человек может разобраться в чем-то по-настоящему глубоко

У меня внезапно возникла интересная мысль

Почему люди создали SPA? Потому что глупо загружать каждый раз одни и те же элементы: хедер, футер, меню и т.д. Кэширование страдает от того, что всё в едином HTML. Но зачем всё так переусложнять, если можно:

  1. Рендерить базовый Layout с шапкой и футером

  2. Внутрь Layout добавить банальный iframe

  3. Менять src у iframe в зависимости от нажатой кнопки в меню

При этом страницы можно писать на любом фреймворке. Они абсолютно независимы. Основная страница в браузере лишний раз не перезагружается, перезагружается только iframe. В чем проблема такого подхода?))

P.S. я конечно немного утрирую. Но ведь помимо этого существует ещё море более лёгких решений, чем SSR с гидратацией и тому подобное

P.S.S. даже нашел статью на тему iframe: https://habr.com/ru/companies/oleg-bunin/articles/716084/?ysclid=mmb3pe6bbn488742420 оказывается, всё уже придумали 30 лет назад)) тема с postmessage звучит очень многообещающе

Это в случае, если конкретно такая задача ставится. Я имел ввиду "боевую" задачу: когда нужно реализовать что-то по ТЗ максимально эффективно

Как вариант - создать собственный сборщик, который на этапе "компиляции" объединяет все html в 1, безо всякого лишнего JS в результате

Видимо, это были не те собесы. Как раз таки то, что ты понимаешь, где конкретно нужны данные технологии, делает из тебя специалиста. Думаю, если на собесе дадут задачу написать хелло ворлд, а кандидат пойдет собирать проект на Next.js, его не примут))

Самое банальное, что тут можно вспомнить - бесконечная загрузка при ошибке

Если подумать, то это реально потенциальный источник багов, т.к. мы вручную управляем состоянием, переносим ответственность за это во фронтенд. Но, в большинстве случаев, это оправдано: "нафига мне тащить поддержку какого-нибудь SSE, если у меня всего один тяжёлый запрос"

Многие спрашивают, где коды Грея применяются. Приведу простейший пример:

Задача скрейпинга отзывов с Амазона. Так как вывод ограничен всего 10-ю страницами, в ход идёт перебор фильтров. То есть мы просто поочередно перебираем все фильтры, затем уникьюлизируем результаты

Но вот проблема: при изменении одного фильтра страница перезагружается. При переборе фильтров в цикле получилось бы очень много лишних перезагрузок, т.к. за 1 итерацию мы меняем сразу несколько фильтров. Так как у меня в тот момент была гонка с другим программистом в этой задаче, я стал думать, как это оптимизировать. И придумал собственный "цикличный код Грея" (на тот момент я даже не знал о существовании такого). Я добился того, что на каждой итерации я изменяю ровно 1 фильтр, но перебираю все значения

У меня не повернулся бы язык назвать C++ "ванильным"))) он и без фреймворков хардкор :)

Они просто проходят ревью :)

Ахахах подловили. На меня так же ругаются, когда я задачи в Jira расписываю :)

В базовых случаях достаточно тупо ограничить доступ. Например, если агент что-то делает в shell, можно создать юзера без рут специально под его цели. Нужен рут доступ - пишет пользователю

Знаете, есть святое правило: не пользоваться самопальной криптографией. Так вот, после этого все аргументы про отсутствие необходимости внедрения сторонних библиотек можно закрыть...

Ну вы же понимаете, что нейросеть где-то обучилась, как это реализовывать?)

Минимализм на максималках. Скоро на двоичном коде будем писать, и все будут счастливы

Спор заключается в том, нужно ли понимать, что нейронка пишет, или доверить ей всё и не париться. Нейронка способна писать автономно только базовые проекты, которые пишутся в одиночку. В большой компании она может писать отдельные алгоритмы, которые всё равно проходят ревью. Так что вывод очевиден. Просто большинство людей, кричащих, что ИИ всемогущий, либо никогда не работали в команде в большой строгой конторе, либо просто поддерживают хайп. Я сам пользуюсь ИИ. Но я понимаю каждую строчку, что он пишет, и проверяю всё досканально

И по-прежнему ни одного примера поддержки старого легаси-кода какого-нибудь древнего проекта без документации... Вот когда ИИ сделает это, тогда я поверю, что он что-то может

В статье описываются максимально базовые вещи, которые и раньше с лихвой делались нейронкой. "Революция" только в автономности. Нейронка всё равно не понимает, не осознаёт то, что она пишет, и это - главная проблема.

Вот у меня прекрасный пример галлюцинаций нейронки есть. Можете особо не вникать, но я постараюсь максимально кратко объяснить. Мы разрабатываем сервис, связанный с логистикой перевозок. Мой коллега по проекту попросил ИИ написать код для просчета сложных маршрутов (маршруты из 2-х сегментов, с промежуточной точкой). Конкретно - нужно было написать запросы к БД через Sqlalchemy (т.е. нужен SELF JOIN). Нейронка вместо того, чтобы честно этот SELF JOIN написать, взяла и просто поменяла тип маршрута в базовом запросе. Всё работало! Без единой ошибки. Но данные были некорректны. Всё потому, что нейронка не поняла, что надо сделать

В примере проблема, безусловно, не в нейронке, а в способе её использования. Человек просто не проверил результат. Но этот пример отлично доказывает, что нейронка может легко не понять, и без единой ошибки в консоли сдать "готовый" проект, который не будет правильно работать. Если бы у нас были тесты, нейронка так же неправильно могла бы их написать из-за отсутствия осознания задачи. Именно понимание цели делает человеческий код надёжнее. И пока нейронка не сможет осознавать то, что она делает, она никогда не заменит человека. Не всё можно покрыть автотестами. Иногда нужно реальное понимание задачи

Спор строится на правильном предположении, что люди понимают, что пишут, а ИИ - нет. Поэтому все замечания справедливы: код нейронки должен проверяться человеком, обладающим опытом и осознающий цель написания программы

Человек может ошибиться потому, что был невнимателен, и такое легко правится ИИ. Но ИИ может выдать полную хрень, потому что не поняла задание, и это будет работать, и вот такое уже человеку сложно отловить. Я лично был свидетелем такого безобразия в своём собственном проекте) могу рассказать, если не верите, что такое бывает

Ну если статья состоит из воды без конкретики и каких-либо примеров - это шлак. Куча таких статей, которые абсолютно неинформативны. Но это не проблема ИИ. Люди и раньше писали такие статьи. Просто в настоящее время подобное генерируется исключительно нейронкой. Человек часто не вникает в тему, просто говорит нейронке "сгенерируй текст такой-то". И выкладывает. Это неприятно читать. Такие статьи справедливо называют шлаком, но не всегда справедливо добавляют приставку "ИИ-"))

Другое дело - статьи, в которых всё написано по делу, есть реальные кейсы, но текст "причёсан" нейронкой. Это не всегда удачно получается, но такие статьи действительно приятно и полезно читать. И их как раз не назовешь шлаком. Они ценны

Почему люди часто говорят про "ИИ-шлак"? Потому, что многие люди генерируют текст без разбора, не вникая в тему, а ИИ склонен галлюцинировать и писать много воды. Авторы подобное далеко не всегда замечают или игнорируют. Таких статей ОЧЕНЬ много, поэтому многие, видя стиль ИИ, автоматически воспринимают текст как шлак, хотя иногда это может быть не так. Формируется ошибочное убеждение, что все статьи с применением ИИ - шлак. И это относится к любому продукту: статьи, игры, истории из клуба романтики

Я уверен, что в своём заявлении гендиректор попросил не относиться предвзято к подобным творениям. Если это так, то это ПРАВИЛЬНО. Но я бы добавил к этому ещё то, что за своё творение нужно нести ответственность, что подразумевает проверку перед публикацией

Информация

В рейтинге
4 418-й
Зарегистрирован
Активность

Специализация

Специалист
PHP
Git
Laravel
Yii framework
Kohana framework
Vue.js
JavaScript
Java
Linux
C++