Forwarded from НЕЙРО РЫЛС. Клуб Николая Колягина
Media is too big
VIEW IN TELEGRAM
Выкладываю клип сюда по просьбам в инсте ❤️
🍾3❤1
Forwarded from Пирамида 👁🗨
This media is not supported in your browser
VIEW IN TELEGRAM
Вышла Unreal Engine 5.8 — и впервые в составе движка появился MCP-сервер
Релиз состоялся сегодня.
Главная новость для тех, кто работает с ИИ-агентами, — встроенный плагин Model Context Protocol.
Это плагин, который позволяет LLM-системам подключаться к движку и понимать как сам редактор, так и ваш проект.
По сути, AI-агенту больше не нужен сторонний мост: он видит контекст проекта напрямую и может помогать собирать ассеты и системы, расширять функциональность движка, проводить тестирование и оптимизацию.
Плагин поставляется с готовым доступом к ядру редактора из коробки.
На практике это означает, что агенты вроде Claude Code или Cursor смогут подключаться прямо к редактору Unreal, обращаться к контексту проекта и собирать ассеты и системы изнутри движка.
Стоит отметить, что MCP-плагин имеет статус Experimental, то есть официально не считаются готовыми к продакшену.
В более широком смысле это первый случай, когда крупнейший игровой движок встраивает поддержку ИИ-агентов как штатную часть пайплайна, а не как сторонний эксперимент сообщества — на фоне десятков community-серверов, которые до сих пор подключались к Unreal через обходные пути.
Релиз состоялся сегодня.
Главная новость для тех, кто работает с ИИ-агентами, — встроенный плагин Model Context Protocol.
Это плагин, который позволяет LLM-системам подключаться к движку и понимать как сам редактор, так и ваш проект.
По сути, AI-агенту больше не нужен сторонний мост: он видит контекст проекта напрямую и может помогать собирать ассеты и системы, расширять функциональность движка, проводить тестирование и оптимизацию.
Плагин поставляется с готовым доступом к ядру редактора из коробки.
На практике это означает, что агенты вроде Claude Code или Cursor смогут подключаться прямо к редактору Unreal, обращаться к контексту проекта и собирать ассеты и системы изнутри движка.
Стоит отметить, что MCP-плагин имеет статус Experimental, то есть официально не считаются готовыми к продакшену.
В более широком смысле это первый случай, когда крупнейший игровой движок встраивает поддержку ИИ-агентов как штатную часть пайплайна, а не как сторонний эксперимент сообщества — на фоне десятков community-серверов, которые до сих пор подключались к Unreal через обходные пути.
👍2
Недавно наткнулся на совет по работе с Claude Code.
Автор писал, что после долгого обсуждения задачи Claude Code может начать терять контекст. И предложил довольно интересный способ это отслеживать — поставить в системный промпт простой «маркер»:
Идея простая: пока Claude помнит эту инструкцию — всё хорошо. Если однажды ответ начинается без твоего имени, значит контекст, возможно, начал деградировать. И это сигнал напомнить модели о задаче или заставить её перечитать контекст.
Мне идея понравилась, и я решил попробовать.
Правда, не в Claude Code, а в Cursor. Добавил такую инструкцию в системный промпт и стал ждать, когда маркер сработает.
Прошёл месяц.
И знаете что? Ни разу.
Grok ни разу не забыл обратиться ко мне по имени.
Получается довольно забавная ситуация: сама идея маркеров мне по-прежнему кажется хорошей — это действительно простой способ проверять, сохраняется ли какой-то элемент контекста. Но конкретно этот маркер за месяц практического применения себя никак не проявил.
Возможно, дело в том, что Cursor работает с контекстом иначе, чем Claude Code. А возможно, такие простые инструкции просто слишком хорошо переживают длинный контекст.В любом случае, было интересно самому проверить эту гипотезу на практике
Автор писал, что после долгого обсуждения задачи Claude Code может начать терять контекст. И предложил довольно интересный способ это отслеживать — поставить в системный промпт простой «маркер»:
Начинай каждый свой ответ с обращения ко мне по имени
Идея простая: пока Claude помнит эту инструкцию — всё хорошо. Если однажды ответ начинается без твоего имени, значит контекст, возможно, начал деградировать. И это сигнал напомнить модели о задаче или заставить её перечитать контекст.
Мне идея понравилась, и я решил попробовать.
Правда, не в Claude Code, а в Cursor. Добавил такую инструкцию в системный промпт и стал ждать, когда маркер сработает.
Прошёл месяц.
И знаете что? Ни разу.
Grok ни разу не забыл обратиться ко мне по имени.
Получается довольно забавная ситуация: сама идея маркеров мне по-прежнему кажется хорошей — это действительно простой способ проверять, сохраняется ли какой-то элемент контекста. Но конкретно этот маркер за месяц практического применения себя никак не проявил.
Возможно, дело в том, что Cursor работает с контекстом иначе, чем Claude Code. А возможно, такие простые инструкции просто слишком хорошо переживают длинный контекст.В любом случае, было интересно самому проверить эту гипотезу на практике
👍3
https://x.com/firesidealpha/status/2093860831595499892
Ну да, они не знают...
Так откуда же мне знать что мой Cursor написал?
Ну да, они не знают...
Так откуда же мне знать что мой Cursor написал?
X (formerly Twitter)
Fireside Alpha (@firesidealpha) on X
SemiAnalysis' Jordan Nanos reveals the OpenAI engineers scrolling their own kernel code had no idea what it did line by line, and it didn't matter because the AI does
"It's not slop, because it p…
"It's not slop, because it p…
Все хотят, чтобы AI писал красивый и читаемый код. Кто-то берёт модель подороже, кто-то пишет километровые промпты, кто-то заводит отдельные skills.
А я последние несколько месяцев использую гораздо более простой подход.
После того как AI закончил основную задачу, просто прошу его пройтись по коду и применить KISS, DRY и YAGNI.
И, знаете, работает. Код заметно упрощается, из него исчезает лишнее, а структура становится чище.
Конечно, это не заменяет code review и не делает любой AI-код автоматически хорошим. Но на практике это оказалось удивительно простым и эффективным способом немного привести код в порядок.
А я последние несколько месяцев использую гораздо более простой подход.
После того как AI закончил основную задачу, просто прошу его пройтись по коду и применить KISS, DRY и YAGNI.
И, знаете, работает. Код заметно упрощается, из него исчезает лишнее, а структура становится чище.
Конечно, это не заменяет code review и не делает любой AI-код автоматически хорошим. Но на практике это оказалось удивительно простым и эффективным способом немного привести код в порядок.
👍2
Мне кажется, IT сейчас методично рубит сук, на котором сидит.
Джунов больше не хотят растить: зачем платить новичку и тратить месяцы на онбординг, если типовые задачи можно отдать AI?
Но рынок пошёл дальше. Техлидов вполне можно посадить на обычные сеньорские позиции. Команды и процессы строить уже не нужно — нужен человек, который способен контролировать работу нескольких AI-агентов.
Только вот настоящий senior ценен не тем, что умеет писать код. Он знает, как проектировать системы: какие паттерны применять, где проводить границы компонентов, какие решения являются архитектурно здоровыми, а какие превращают проект в макаронного монстра.
И если сегодня перестать проводить людей через путь от джуна до сеньора, завтра появятся разработчики, которые прекрасно умеют ставить задачи AI, но не знают, какие задачи ему вообще нужно поставить. Они не знают паттернов, не видят архитектурных проблем и не понимают, что именно нужно проверить в результате.
Вот тогда станет по-настоящему интересно: AI будет генерировать всё более сложные системы, а людей, способных понять, что в этих системах неправильно, рынок сам себе уже не вырастит.
Джунов больше не хотят растить: зачем платить новичку и тратить месяцы на онбординг, если типовые задачи можно отдать AI?
Но рынок пошёл дальше. Техлидов вполне можно посадить на обычные сеньорские позиции. Команды и процессы строить уже не нужно — нужен человек, который способен контролировать работу нескольких AI-агентов.
Только вот настоящий senior ценен не тем, что умеет писать код. Он знает, как проектировать системы: какие паттерны применять, где проводить границы компонентов, какие решения являются архитектурно здоровыми, а какие превращают проект в макаронного монстра.
И если сегодня перестать проводить людей через путь от джуна до сеньора, завтра появятся разработчики, которые прекрасно умеют ставить задачи AI, но не знают, какие задачи ему вообще нужно поставить. Они не знают паттернов, не видят архитектурных проблем и не понимают, что именно нужно проверить в результате.
Вот тогда станет по-настоящему интересно: AI будет генерировать всё более сложные системы, а людей, способных понять, что в этих системах неправильно, рынок сам себе уже не вырастит.
❤1👍1
А вы вообще знаете, сколько стоит один SELECT?
Возьмём Google BigQuery — распределённую аналитическую систему, где в on-demand модели стоимость запроса зависит от объёма обработанных данных.
Представим банковское приложение. У которого есть таблица
Пользователь пишет в поддержку: «У меня не сходится баланс».
Support открывает его историю транзакций, чтобы разобраться, что произошло.
При этом таблица оптимизирована под другой сценарий. Основной индекс — по
Для поиска конкретной транзакции это отлично. Но support не знает
поэтому запрос делает full scan всей таблицы:
1 запрос → 1 TiB → $6.25.
Теперь немного инженерии.
Разбиваем таблицу на партиции:
PARTITION BY DATE(created_at)
Если 1 TiB распределён примерно равномерно за год, запрос за один день читает уже около 2.8 GiB
1 запрос → 2.8 GiB → ~$0.017
А теперь добавляем clustering:
CLUSTER BY user_id
Партиционирование сначала отбрасывает ненужные даты, а clustering помогает внутри нужной партиции быстрее отсечь данные, которые относятся не к этому пользователю.
И не надо путать с
Возьмём Google BigQuery — распределённую аналитическую систему, где в on-demand модели стоимость запроса зависит от объёма обработанных данных.
Представим банковское приложение. У которого есть таблица
transactions размером 1 TiB с историей транзакций за год.Пользователь пишет в поддержку: «У меня не сходится баланс».
Support открывает его историю транзакций, чтобы разобраться, что произошло.
При этом таблица оптимизирована под другой сценарий. Основной индекс — по
tx_id: уникальному ID транзакции, который приходит из внешней системы, например блокчейна.Для поиска конкретной транзакции это отлично. Но support не знает
tx_id. Он знает пользователя только user_id
SELECT *
FROM transactions
WHERE user_id = '...'
AND created_at >= TIMESTAMP(CURRENT_DATE())
AND created_at < TIMESTAMP(DATE_ADD(CURRENT_DATE(), INTERVAL 1 DAY))
поэтому запрос делает full scan всей таблицы:
1 запрос → 1 TiB → $6.25.
Теперь немного инженерии.
Разбиваем таблицу на партиции:
PARTITION BY DATE(created_at)
Если 1 TiB распределён примерно равномерно за год, запрос за один день читает уже около 2.8 GiB
1 запрос → 2.8 GiB → ~$0.017
А теперь добавляем clustering:
CLUSTER BY user_id
Партиционирование сначала отбрасывает ненужные даты, а clustering помогает внутри нужной партиции быстрее отсечь данные, которые относятся не к этому пользователю.
И не надо путать с
LIMIT 10, это ограничивает результат, но не обязательно объём данных, который движку пришлось обработать.👍2❤1
Ещё только ленивый не обосрал новую раскладушку от Apple. Но громче всех её обосрал Тим Кук, который ушёл из компании ровно перед презентацией, оставив презентовать это говно Грегу — как его там — Федериги.
А давайте посмотрим, во что на самом деле обходится новый складной iPhone.
Не в деньгах за железо, а в требованиях к железу со стороны софта.
В одном приложении, на одном iPhone и при одном и том же скролле измерили прирост RAM:
Swift +9,74 MB
Flutter +25,33 MB
React Native +45,13 MB
На новом iPhone с 12 GB RAM пользователь, скорее всего, этого даже не заметит. Но RAM закончивается и iOS начинает втихую выгружать приложения начиная с самых тяжелых.
Пользователь свернул аппку, через 20 секунд вернулся, а корзина пустая, состояние потеряно, сессия слетела. Он думает это баг в приложении, а в crash reports при этом ничего нет.
И вот здесь начинается экономика: чем тяжелее становится software stack, тем хуже опыт на старых устройствах и тем большую часть существующей пользовательской базы бизнес начинает обслуживать хуже.
Бизнес теряет деньги не потому, что потерял клиента, а потому, что перестал нормально обслуживать того, кто уже был клиентом, и даже не осознает это.
Не в деньгах за железо, а в требованиях к железу со стороны софта.
В одном приложении, на одном iPhone и при одном и том же скролле измерили прирост RAM:
Swift +9,74 MB
Flutter +25,33 MB
React Native +45,13 MB
На новом iPhone с 12 GB RAM пользователь, скорее всего, этого даже не заметит. Но RAM закончивается и iOS начинает втихую выгружать приложения начиная с самых тяжелых.
Пользователь свернул аппку, через 20 секунд вернулся, а корзина пустая, состояние потеряно, сессия слетела. Он думает это баг в приложении, а в crash reports при этом ничего нет.
И вот здесь начинается экономика: чем тяжелее становится software stack, тем хуже опыт на старых устройствах и тем большую часть существующей пользовательской базы бизнес начинает обслуживать хуже.
Бизнес теряет деньги не потому, что потерял клиента, а потому, что перестал нормально обслуживать того, кто уже был клиентом, и даже не осознает это.
Applefy
Swift vs Flutter: RAM and CPU Efficiency Compared
How native Swift and Flutter compare on memory and CPU — peer-reviewed benchmark data, the engine and GC overhead behind the gap, and the iOS limits Flutter cannot clear.
⚡️Инженеры, приехавшие чинить дата-центр Яндекса после атаки, выставили счет на свои услуги в 5 раз дороже из-за «повышенного спроса»
😁4🔥2
Приходишь устраиваться на работу. У них AWS. Ты знаешь AWS, архитектуру, сервисы, очереди, реплики, отказоустойчивость. Проектируешь систему, объясняешь компромиссы, обсуждаешь масштабирование.
— Отлично! Видно, что вы опытный специалист.
Уходишь довольный. Двадцать лет в индустрии всё-таки не зря.
Через неделю идёшь на собеседование в другую компанию. У них Hetzner и bare metal.
— А как вы будете управлять инфраструктурой? А отказами оборудования? А сетью? А вот у нас всё на физических серверах...
— Ну, это решаемые инженерные задачи. Давайте обсудим требования.
— Понятно. Вы знаете только AWS. Нам нужен настоящий архитектор.
И вот ты уже не архитектор, а какой-то беспомощный любитель облачных кнопок. Двадцать лет опыта аннулированы. Можешь забирать куртку.
И ведь у каждой технологии найдётся свой адепт, который объяснит тебе, почему ты нихуя не понимаешь в профессии.
Знаешь AWS — опытный кнопкодав.
Не знаешь AWS — динозавр.
Знаешь Kubernetes — переусложняешь.
Не знаешь Kubernetes — не умеешь в современную инфраструктуру.
Знаешь микросервисы — не понимаешь простоты.
Пишешь монолит — не понимаешь масштабирования.
А если знаешь всё перечисленное, то тебе объяснят, что настоящий архитектор должен был ещё десять лет назад написать собственный оркестратор на Rust и запустить его на калькуляторе.
— Отлично! Видно, что вы опытный специалист.
Уходишь довольный. Двадцать лет в индустрии всё-таки не зря.
Через неделю идёшь на собеседование в другую компанию. У них Hetzner и bare metal.
— А как вы будете управлять инфраструктурой? А отказами оборудования? А сетью? А вот у нас всё на физических серверах...
— Ну, это решаемые инженерные задачи. Давайте обсудим требования.
— Понятно. Вы знаете только AWS. Нам нужен настоящий архитектор.
И вот ты уже не архитектор, а какой-то беспомощный любитель облачных кнопок. Двадцать лет опыта аннулированы. Можешь забирать куртку.
И ведь у каждой технологии найдётся свой адепт, который объяснит тебе, почему ты нихуя не понимаешь в профессии.
Знаешь AWS — опытный кнопкодав.
Не знаешь AWS — динозавр.
Знаешь Kubernetes — переусложняешь.
Не знаешь Kubernetes — не умеешь в современную инфраструктуру.
Знаешь микросервисы — не понимаешь простоты.
Пишешь монолит — не понимаешь масштабирования.
А если знаешь всё перечисленное, то тебе объяснят, что настоящий архитектор должен был ещё десять лет назад написать собственный оркестратор на Rust и запустить его на калькуляторе.
👍1👏1😁1