Вы не туда господа смотрите, по-моему все очевидно, как и для чего будет использоваться закон. +1 рычаг давления на банки, скорее всего этим ходом вынудят банки использовать Цифровой Рубль, как и пользователей.
Т.к скажут Цифровой рубль находится под полным контролем ЦБ.
Я кстати занимался его интеграцией в один крупный банк. Конкретно у них все по феншую было.
Я написал огромный фрагментированный текст, который было невозможно читать даже мне, поэтому я обленился и попросил deepseek r1 перестроить мой текст, чтобы не тратить ваше время на пустые рассуждения и перескакивание с темы на тему:
Использование больших языковых моделей (LLM) в разработке — это новый сложный навык. Вот ключевые инсайты, основанные на практическом опыте.
Ключевое наблюдение: Код часто эффективнее естественного языка
Превосходство кода: На основе работы с моделью DeepSeek R1 был сделан вывод, что LLM лучше понимает код, чем естественноязыковые описания. Промты, где преобладал код с минимальными текстовыми пояснениями, в большинстве случаев давали более качественный результат.
Ограничение скорости: Несмотря на это, решение задачи через LLM часто занимало больше времени из-за необходимости многочисленных корректировок, а в некоторых случаях модель вообще не справлялась.
Пример со сложной задачей: При работе с пространственными задачами (например, распознавание жестов) текстовый промт не работал совсем. Решение было найдено только тогда, когда модель получала готовую кодобазу на 70-90%, после чего она успешно находила и исправляла ошибку, не заметную разработчику.
Проблемы и вызовы
Новый обязательный навык: Современный программист должен разбираться не только в классических областях (алгоритмы, БД, DevOps), но и в нейросетях, понимая их внутренние проблемы.
Неуниверсальность промтов: Нет единой формулы для написания промтов. Логика и принципы сильно разнятся от модели к модели, особенно при различиях в архитектуре и датасетах.
Сложность выбора формата: Бывает сложно предугадать, что эффективнее: русский язык, английский или код. Этот выбор часто кажется случайным и может отнять больше времени, чем ручное решение задачи.
"Триггерные" фразы: Существуют определенные слова и сочетания, которые могут моментально ухудшить качество ответа модели.
Проблема большого контекста: С увеличением объема контекста производительность LLM падает. Модель начинает:
Допускать ошибки и противоречия (коллизии).
Игнорировать части промта.
Впадать в циклы, повторяя одни и те же фразы.
Ограниченная логика: Некоторые логические задачи LLM решить не в состоянии в принципе.
Накопление ошибок: Модель плохо справляется с задачами, которые на 90% состоят из её же предыдущих ответов (сгенерированного кода или "мыслей"). Это связано с тем, что LLM предсказывает следующий токен на основе уже имеющегося текста, и ошибки накапливаются.
Практические рекомендации
Используйте локальные модели: Для экспериментов и лучшего контроля используйте такие инструменты, как Ollama.
Говорите на языке кода: В промтах для технических задач оперируйте терминами языка программирования и структурами данных.
Предоставляйте базу для сложных задач: Для нетривиальных задач давайте модели готовый каркас или значительную часть кода, который ей нужно будет только достроить.
Управляйте контекстом: При фиксе багов, рефакторинге или решении новых проблем начинайте новый чат. Это очищает контекст и помогает модели "сфокусироваться".
Будьте конкретны и нейтральны:
Излагайте суть четко и без лишней информации.
Избегайте эмоциональных оценок и оскорблений. Критика заставляет модель тратить ресурсы контекста на "оправдания" и смену стиля общения, а не на решение задачи.
Знайте пределы: Признайте, что некоторые задачи LLM не решат. Не тратьте время на попытки "заставить её понять" — делайте это сами.
Разделяйте задачи: Если модель не может починить свой же код в текущем диалоге, скопируйте проблемный участок в новое окно чата.
Итог
Навык эффективного взаимодействия с LLM — это новые "алгоритмы и структуры данных". Это фундаментальный скилл, который уже сейчас требуют многие компании.
Для обучения рекомендуется начинать с книг вроде "Грокаем машинное обучение".
Для карьеры: Без понимания принципов работы нейросетей вас уже могут не взять на работу.
Яндекс уже обогнал эпл и встроил рекламу в свое приложение в т.ч в платные типа Яндекс Еды, Яндекс Go, где ты нехилую маржу платишь за пользование сервисами. А тебе еще и рекламу суют.
В Яндекс Картах рекламу еще можно понять.
В Яндекс Go, Яндекс Еда нет, как и в Apple Maps, которые вообще в РФ нормально не работают.
Ну одно дело ты разрешаешь браузеру устанавливать приложение, а парой и загрузчику или какому-нибудь MTKDeviceSpectator, другое дело ты разрешаешь официальному приложению Xbox ставить приложения.
И раз гугл упомянул безопасность, то Epic и другие хотят ставить приложения без этой плашки.
Ну и нужно ли говорить, что теперь GPlay будет магазином магазинов.
Так же скажу, что это верно и для сериализаторов/десериализаторов.
Кто-то поменял username на user_name и отвалилась половина зависимых сервисов.
А тесты замоканы. Там всегда один и тот же json.
Тоже самое можно и про ORM сказать, если иметь достаточно компетенции можно заранее писать высокопроизводительные запросы в БД и поддерживать все в идеальном состоянии. Таким образом, исключая ряд проблем.
Но как мы знаем этого не происходит потому что это отнимает слишком много времени, один человек не справится с поддержкой 15+ сервисов. А у двух человек разные взгляды на разработку одного и того же продукта и далеко не факт, что вы договоритесь.
У команды из 15 человек все еще сложнее. Найти компромисс иногда сжирает времени больше, чем реализация.
И лучше иметь одинаковые проблемы и соответственно пути их решения на 15+ сервисах, чем за год сделать ничего продумывая, как же все это идеально реализовать. Постоянно переписывая код до идеального состояния.
По сути Mapstruct и другие "мапперы" это способ ускорить разработку здесь и сейчас в обмен на возможные проблемы в будущем. "Здесь и сейчас" по сути это то, что крайне важно для бизнеса потому, как, если не успеешь за конкурентами, они тебя обгонят и съедят.
Да и в случае личных проектов мне и наверное большинству не хочется всю жизнь провести за компьютером, пока твои друзья 3 раз за год летают забугор.
Тебе всегда, когда ты начинаешь новый пет проект хочется увидеть результат здесь и сейчас и чаще всего из-за подобных ожиданий он и не развивается потому что ожидания не были оправданы.
Вывод: важно реалистично подходить к разработке проекта, и там где необходимо использовать ручной подход, а там где это не критично использовать mapstruct или другие инструменты.
По документалкам про автомобили некого Крашеного я помню, что подобные новости это способ надавить на компанию, чтобы заставить платить отчисления организации, которая давит. (Посмотрите кто автора поста.)
Ни на что не намекаю, но Детройт стал таким, как раз из-за подобных организаций. (потому что у компаний кончились деньги и им пришлось закрыться. Можете документалку про Детройт глянуть, там около 2 часов контента.)
Обобщу:
> Нормально делай, нормально будет.
Правда неправда, правильно неправильно.
Вы не туда господа смотрите, по-моему все очевидно, как и для чего будет использоваться закон. +1 рычаг давления на банки, скорее всего этим ходом вынудят банки использовать Цифровой Рубль, как и пользователей.
Т.к скажут Цифровой рубль находится под полным контролем ЦБ.
Я кстати занимался его интеграцией в один крупный банк. Конкретно у них все по феншую было.
Согласен, хочется читать людей
Плюс одна причина почему я пользуюсь Firefox
Как вы видите разработчики обленятся даже текст писать. И выигрыш по времени, пока, что будет небольшим или нулевым.
Это моя точка зрения т.к я верю в исследование из статьи, поэтому вам необходимо самим решить в зависимости от вашей точки зрения верить мне или нет.
Я написал огромный фрагментированный текст, который было невозможно читать даже мне, поэтому я обленился и попросил deepseek r1 перестроить мой текст, чтобы не тратить ваше время на пустые рассуждения и перескакивание с темы на тему:
Использование больших языковых моделей (LLM) в разработке — это новый сложный навык. Вот ключевые инсайты, основанные на практическом опыте.
Ключевое наблюдение: Код часто эффективнее естественного языка
Превосходство кода: На основе работы с моделью DeepSeek R1 был сделан вывод, что LLM лучше понимает код, чем естественноязыковые описания. Промты, где преобладал код с минимальными текстовыми пояснениями, в большинстве случаев давали более качественный результат.
Ограничение скорости: Несмотря на это, решение задачи через LLM часто занимало больше времени из-за необходимости многочисленных корректировок, а в некоторых случаях модель вообще не справлялась.
Пример со сложной задачей: При работе с пространственными задачами (например, распознавание жестов) текстовый промт не работал совсем. Решение было найдено только тогда, когда модель получала готовую кодобазу на 70-90%, после чего она успешно находила и исправляла ошибку, не заметную разработчику.
Проблемы и вызовы
Новый обязательный навык: Современный программист должен разбираться не только в классических областях (алгоритмы, БД, DevOps), но и в нейросетях, понимая их внутренние проблемы.
Неуниверсальность промтов: Нет единой формулы для написания промтов. Логика и принципы сильно разнятся от модели к модели, особенно при различиях в архитектуре и датасетах.
Сложность выбора формата: Бывает сложно предугадать, что эффективнее: русский язык, английский или код. Этот выбор часто кажется случайным и может отнять больше времени, чем ручное решение задачи.
"Триггерные" фразы: Существуют определенные слова и сочетания, которые могут моментально ухудшить качество ответа модели.
Проблема большого контекста: С увеличением объема контекста производительность LLM падает. Модель начинает:
Допускать ошибки и противоречия (коллизии).
Игнорировать части промта.
Впадать в циклы, повторяя одни и те же фразы.
Ограниченная логика: Некоторые логические задачи LLM решить не в состоянии в принципе.
Накопление ошибок: Модель плохо справляется с задачами, которые на 90% состоят из её же предыдущих ответов (сгенерированного кода или "мыслей"). Это связано с тем, что LLM предсказывает следующий токен на основе уже имеющегося текста, и ошибки накапливаются.
Практические рекомендации
Используйте локальные модели: Для экспериментов и лучшего контроля используйте такие инструменты, как Ollama.
Говорите на языке кода: В промтах для технических задач оперируйте терминами языка программирования и структурами данных.
Предоставляйте базу для сложных задач: Для нетривиальных задач давайте модели готовый каркас или значительную часть кода, который ей нужно будет только достроить.
Управляйте контекстом: При фиксе багов, рефакторинге или решении новых проблем начинайте новый чат. Это очищает контекст и помогает модели "сфокусироваться".
Будьте конкретны и нейтральны:
Излагайте суть четко и без лишней информации.
Избегайте эмоциональных оценок и оскорблений. Критика заставляет модель тратить ресурсы контекста на "оправдания" и смену стиля общения, а не на решение задачи.
Знайте пределы: Признайте, что некоторые задачи LLM не решат. Не тратьте время на попытки "заставить её понять" — делайте это сами.
Разделяйте задачи: Если модель не может починить свой же код в текущем диалоге, скопируйте проблемный участок в новое окно чата.
Итог
Навык эффективного взаимодействия с LLM — это новые "алгоритмы и структуры данных". Это фундаментальный скилл, который уже сейчас требуют многие компании.
Для обучения рекомендуется начинать с книг вроде "Грокаем машинное обучение".
Для карьеры: Без понимания принципов работы нейросетей вас уже могут не взять на работу.
сделай хоткей
AltStore можно поставить так-то уже сейчас и как я понял, даже из россии, чекните гайды на ютабе
Хочу этот прекрасный пост в формате видео))
Яндекс уже обогнал эпл и встроил рекламу в свое приложение в т.ч в платные типа Яндекс Еды, Яндекс Go, где ты нехилую маржу платишь за пользование сервисами. А тебе еще и рекламу суют.
В Яндекс Картах рекламу еще можно понять.
В Яндекс Go, Яндекс Еда нет, как и в Apple Maps, которые вообще в РФ нормально не работают.
А как ты думаешь читая новость о том, что Эпл проиграла иск о бракованных батареях?
Когда проектируешь архитектуру своего приложения, а не просто по приколу кодишь, то без диаграмм никуда.
А лучше UML я пока ничего не видел.
Ну одно дело ты разрешаешь браузеру устанавливать приложение, а парой и загрузчику или какому-нибудь MTKDeviceSpectator, другое дело ты разрешаешь официальному приложению Xbox ставить приложения.
И раз гугл упомянул безопасность, то Epic и другие хотят ставить приложения без этой плашки.
Ну и нужно ли говорить, что теперь GPlay будет магазином магазинов.
Иронично
Ой, удалите плиз, я перепутал email
Мне, а есть сайт где такие разработки люди выкладывают? Я бы посмотрел, я на хабр только из-за этого захожу.
Чтобы смотреть, как люди пишут код, и объясняют свою логику того почему так.
Чтобы пополнять свои знания
Результаты опроса теперь полностью не релевантные из-за ошибки в цене, в рф он стоит около 24-25к, что очень демократично для такого девайса.
Так этой фиче уже месяца 4 и даже в бете не ios
Согласен по всем пунктам и даже без но.
Так же скажу, что это верно и для сериализаторов/десериализаторов.
Кто-то поменял username на user_name и отвалилась половина зависимых сервисов.
А тесты замоканы. Там всегда один и тот же json.
Тоже самое можно и про ORM сказать, если иметь достаточно компетенции можно заранее писать высокопроизводительные запросы в БД и поддерживать все в идеальном состоянии. Таким образом, исключая ряд проблем.
Но как мы знаем этого не происходит потому что это отнимает слишком много времени, один человек не справится с поддержкой 15+ сервисов. А у двух человек разные взгляды на разработку одного и того же продукта и далеко не факт, что вы договоритесь.
У команды из 15 человек все еще сложнее. Найти компромисс иногда сжирает времени больше, чем реализация.
И лучше иметь одинаковые проблемы и соответственно пути их решения на 15+ сервисах, чем за год сделать ничего продумывая, как же все это идеально реализовать. Постоянно переписывая код до идеального состояния.
По сути Mapstruct и другие "мапперы" это способ ускорить разработку здесь и сейчас в обмен на возможные проблемы в будущем. "Здесь и сейчас" по сути это то, что крайне важно для бизнеса потому, как, если не успеешь за конкурентами, они тебя обгонят и съедят.
Да и в случае личных проектов мне и наверное большинству не хочется всю жизнь провести за компьютером, пока твои друзья 3 раз за год летают забугор.
Тебе всегда, когда ты начинаешь новый пет проект хочется увидеть результат здесь и сейчас и чаще всего из-за подобных ожиданий он и не развивается потому что ожидания не были оправданы.
Вывод: важно реалистично подходить к разработке проекта, и там где необходимо использовать ручной подход, а там где это не критично использовать mapstruct или другие инструменты.
По документалкам про автомобили некого Крашеного я помню, что подобные новости это способ надавить на компанию, чтобы заставить платить отчисления организации, которая давит. (Посмотрите кто автора поста.)
Ни на что не намекаю, но Детройт стал таким, как раз из-за подобных организаций. (потому что у компаний кончились деньги и им пришлось закрыться. Можете документалку про Детройт глянуть, там около 2 часов контента.)