Все потоки

Небольшой пост по кэшированию в современных LLM и почему это важно понимать ⭐
Часть 2

Первая часть тут

--------------

Time to live для кэша

У кэша есть время жизни

В Anthropic есть два основных режима: 5 минут и 1 час

5m TTL — это не 5 минут от записи кэша

Это 5 минут с последнего cache hit. Пока вы активно работаете, таймер продлевается. Но если отошли на 6 минут, следующий запрос может снова записывать весь кэш

1h TTL дороже на запись, зато переживает длинные паузы

Множители такие 🔽🔽

• cache write 5m — 1.25× от обычного input
• cache write 1h — 2×
• cache read — 0.1×, то есть примерно 90% скидка

Поэтому кэш окупается почти сразу. По дефолту в Claude Code кэш пишется на час, но можно записывать и на 5 минут в настройках config

Подписка не делает кэш бесплатным

Если вы не API-пользователь, а сидите на Claude Pro / Max, механика всё равно та же

Просто вместо долларов вы тратите квоту 5h / 7d лимитов

И поэтому старая сессия на 300K токенов утром после истёкшего TTL может сжечь ощутимый кусок лимита одним «привет»

Как ощутить кэш

1. Откройте длинную сессию Claude Code, которая больше часа была неактивна
2. Напишите короткое сообщение, например «привет», и засеките Time to First Token — время до первого символа ответа
3. Потом сделайте /rewind и напишите это же сообщение ещё раз

Во второй раз ответ должен появиться примерно в 5 раз быстрее

А если хочется посмотреть цифры — можно пройтись по JSONL-логам Claude Code и посмотреть долю cache_read_input_tokens

Если в длинных агентных сессиях cache reads сильно ниже 80%, вы, скорее всего, что-то делаете не так

Главный вывод

Prompt caching — это причина, почему современные агентные LLM вообще можно использовать в длинных сессиях: с инструментами, историей, файлами, планами, правками и сотнями тысяч токенов контекста

Без кэша каждый новый шаг агента был бы полным перечитыванием прошлого

Вот такие вот дела

-------------

Это часть очень большой статьи про Context Engineering
https://habr.com/ru/articles/1028260/

-------------

Небольшой пост по кэшированию в современных LLM и почему это важно понимать ⭐

Это один из тех механизмов, который на прямую влияет на ваши пятичасовые и недельные окна. Ну и, конечно, на прямые расходы, если вы платите через API

-------------------

Вся архитектура Claude Code и других агентных LLM построена вокруг prompt caching

Без него работа современных агентных систем была бы на порядок дороже

И при этом про кэширование почти никто не знает. Давайте разбираться ⤵️

Сначала: что такое вообще это ваше кэширование

Кэш — это когда система не пересчитывает одно и то же заново, а сохраняет уже готовый результат и переиспользует его

С его помощью становится возможным эффективное переиспользование ранее просчитанных данных

Например, браузеры не скачивают логотип сайта при каждом открытии страницы. А берут его из локального кэша. Поэтому страница открывается быстрее, а серверу не надо отдавать один и тот же файл тысячу раз 🥰

С LLM логика похожая, только вместо картинок и файлов кэшируется часть вычислений внутри модели

Почему это критично для LLM

Модель STATELESS

КАЖДЫЙ РАЗ, когда вы отправляете сообщение в модель — не важно, Codex, Claude Code или Gemini CLI — в модель отправляется ВСЁ КОНТЕКСТНОЕ ОКНО, а не только ваше последнее сообщение

system prompt + tools + история диалога + новое сообщение

Она ничего не помнит и не знает о вас между запросами

А спустя час Claude Code пишет вам:

new task? /clear to save 161.5k tokens

Это значит, что сохранённый кэш длинного контекста уже не стоит считать надёжно доступным, и следующий запрос может потребовать полного пересчёта

Без кэша это дорого и медленно

Как работает prompt caching

У моделей бОльшая часть контекста не меняется от запроса к запросу

System prompt тот же. Описание инструментов то же. Большая часть истории та же. Меняется только новое сообщение в конце 🙏

Поэтому модель не пересчитывает весь этот повторяющийся префикс заново, а читает уже подготовленный кэш

Что именно кэшируется внутри

Под капотом трансформера для каждого токена считаются специальные Q/K/V-представления: Query, Key и Value

Для нового токена Query считается заново. А вот Key и Value для прошлых токенов уже были посчитаны раньше и не меняются, если префикс тот же

Модель уже прочитала старый контекст и держит его в готовом виде. И если префикс совпал, можно не пересчитывать его заново

Почему кэш легко сломать

Prompt caching работает только при точном совпадении префикса

Один лишний пробел, другой system prompt, изменившийся список tools — и совпадение ломается

В Claude Code порядок примерно такой:

System Prompt → Tool Definitions → Chat History → Current Input

И инвалидация каскадная: если поменялось что-то сверху, слетает всё ниже 💀

Например, если подключить или отключить MCP-сервер в середине большой сессии, то весь кэш слетит

Изменились tool definitions → сломался кэш tools, system и messages → следующий запрос перечитывает всё заново

Что ломает кэш

• Подключили или отключили MCP-сервер — слетает почти всё
• Включили web search — слетает system + messages
• Поменяли tool_choice — слетают messages
• Сделали compact — изменилась история, старый кэш уже не совпадает
• Поменяли reasoning / effort level — история перечитывается заново
• Сменили модель — кэш физически остаётся, но у другой модели свой namespace, поэтому он не работает

-------------

Это часть очень большой статьи про Context Engineering
https://habr.com/ru/articles/1028260/

-------------

Продолжение тут, в постах ограничение на 4000 символов

Эхо из прошлого: ошибки архитектуры могут "выстрелить" спустя годы (благодаря WebArchive)

Представьте: 8 лет назад была небезопасная архитектура с IDOR. Т.е. можно было получить доступ к документу просто зная его ссылку. А ссылки чудным образом попали в WebArchive (он же - Wayback Machine). Спустя время архитектуру поменяли и проблема ушла. Но, WebArchive всё помнит: ссылки уже успели сохраниться. И кто-то, спустя многие годы, публикует статью с указанием ссылок на WebArchive, где указаны персональные данные и платёжки клиентов. Внимание, вопрос: успокоит ли общественность реакция в стиле: "да это давно было, сервиса уж нет"?

Вот один из сохранённых по ссылке документа: он сохранился в Wayback Machine в 2018 и до сих пор доступен.

Самое печальное - некоторые компании не считают это угрозой. Для них это "фича, а не бага". Поподробнее о том почему компании не желают признавать проблему - в моей статье Wayback Machine как архив IDOR: как временные ссылки перестали быть временными.

Книга «Интегральная духовность» Кен Уилбер

С этой книгой у меня вышла совершенно удивительная история.

Лет 10 назад собственник проводил обучение руководителей, в т.ч. меня. Рассказывал о методах, книгах, практиках. В том числе – упомянул Кена Уилбера.

Теперь внимание. Из всего Кена Уилбера было упомянуто: имя, фамилия, название книги и одна фраза: чтобы перейти на новый уровень, надо на нём побывать.

Фразу я запомнил. И потихоньку стал применять. Года через три, очутившись в среде, где мне надо было массово выращивать программистов, тимлидов, руководителей, я без этой неточной цитаты Уилбера сдался бы через месяц.

Потому что я работал с зумерами 😊. Они отличные ребята, но есть у них забавная особенность – другое отношение к ответственности, если сравнивать с миллениалами. Для нас ответственность – это возможность, для них – непонятный, ненужный геморрой. Мне же очень надо было делегировать этим ребятам часть ответственности.

Традиционный подход в управлении – создавать Должности, вроде Руководителей, и позволять/предлагать людям эти Должности Занимать. Уже страшно звучит 😊. Занятие должности, опять же традиционно – это игра ва-банк. Был спецом, стал Начальником, и если не справился – даунгрейд почти невозможен, ибо позорище.

Потому спецы не хотят быть начальниками. Даже не смотрят в эту сторону. Зумеры – тем более.

Следуя цитате Уилбера, я заменил Должности на роли. Роль можно играть день, два, месяц, год – а потом перестать. Роли можно совмещать – быть одновременно программистом и тимлидом. Роль – это безопасная возможность попробовать, не влезая на пьедестал и не падая в лужу.

И в роль можно входить несколько раз, делая любые перерывы между попытками. Всё как у Уилбера – побывать на уровне. Разок, другой, потом перестать бояться и, если роль нравится – остаться в ней надолго.

В итоге всё получилось. Зумеры стали ответственнее миллениалов. Я делегировал всё, что было на мне. Теперь у меня зумеры учат зумеров ответственности 😊.

И вот решил я воздать должное Кену Уилберу – купил и прочитал его книгу. И что бы вы думали?

Я не понял НИ ХРЕНА ВООБЩЕ.

Я не нашёл своей любимой цитаты, не понял ни одной таблицы и схемы, не уловил замысла и цели ни книги, ни автора. Полный ноль.

Я оказался в странной, непривычной ситуации. Обычно есть автор и я. Он написал, я прочитал и применил. Но с Уилбером мне помогли – тот человек, что сформулировал смысл в одной короткой фразе. Он сделал за меня всю работу. В этот раз герой – он.

Была в древности наука алхимия – изыскивали, как создать философский камень, превращающий любой предмет в золото. Написали множество книг – говорят, мудрёных и запутанных.

Но есть легенда, что секрет философского камня очень прост, и умещается на небольшой табличке – изумрудной скрижали. Только вот не написали её.

А мне написали.

Из Книжного стека

Вышла серия Qwen 3.7 Preview

В открытый доступ сегодня вышла серия языковых моделей Qwen 3.7, пока в Preview. Доступны модели Qwen3.7 Max Preview, Qwen3.7 Plus Preview, на момент написания доступна только на официальном сайте chat.qwen.ai
Данные модели по заявлению авторов должны иметь "высочайшую" производительность, но как и 3.5, не поддерживают интерпретатор кода и веб поиск. Работают только в Thinking режиме.

UPD: 3.7 Max теперь не в Prewiew, и у неё доступен поиск и интерпретатор кода

UPD 3.7 Plus теперь тоже не в Prewiew

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

Коллеги, у нас на Хабре идет голосование по Veai.

Если вы уже пробовали агент в JetBrains IDE или просто следите за тем, как меняется разработка с AI, загляните и проголосуйте ссылка на голосование Ваше мнение поможет нам понять, что важно разработчикам, и развивать продукт в правильном направлении.

Хочется проверить, насколько разработчикам близка идея AI-агента, который работает не вслепую по grep и длинным логам, а использует IDE как источник фактов: структуру проекта, зависимости, ошибки компиляции, тесты, конфигурации запусков и поведение приложения.

Будем рады голосам, комментариям и особенно критике. Она помогает точнее объяснять, чем Veai отличается от чат-ассистента, который не видит проект так, как его видит IDE.

Если у вас есть опыт с Cursor, Continue, JetBrains AI Assistant или другими инструментами, тоже приходите в обсуждение. Нам важны честные сравнения, а не стерильный маркетинговый текст.

Вы когда-нибудь задумывались о том, насколько связен наш мир? Насколько сложно пересечь границу между странами? И вообще сколько их, этих граничных переходов? А насколько хорош аэропорт Вашего города - в сколько стран или направлений из него можно улететь? А есть ли паромы и периодические водные маршруты между двумя государствами? А ходят ли поезда из одной страны в другую, или ветка уже давно заброшена?

Это кажется простой задачей, пока мы находимся в Европе или, к примеру, в Северной Америке. Но начинает быть очень интересным исследованием, когда мы переместимся в Африку, Центральную Азию или, положим, в Южную Америку. А в Карибском бассейне вдруг окажется, что этим маленькие острова и не связаны настолько хорошо между собой.

А если включить в это уравнение закрытость границ, визовые и паспортные ограничение, то внезапно окажется, что задачка-то и не из лёгких.

Именно поэтому и возник проект Портулан: portolanmap.com. Чтобы показать доступность территорий для внешнего мира. Ведь хотелось бы, чтобы границы были только у нас в головах, но на деле нам приходится считаться с границами государств и территорий.

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

Под капотом - Python-pipeline для сбора и нормализации данных, Svelte/MapLibre GL на фронтенде, статическая раздача через Cloudflare без бэкенда и баз данных.

Куда движется рынок гибридных облаков

Гибрид нужен бизнесу: он помогает держать критичные данные локально, но при этом пользоваться всеми плюсами публичного облака. 

Но как именно будет расти этот рынок, если крупный бизнес думает про безопасность, средний — про бюджет, стартапы — про скорость?

Рассмотрим четыре возможных тенденции.

1️⃣ Тенденция 1: рост через ИИ/ML и дефицит железа

GPU дорогие, быстро устаревают и тяжело отбиваются. Обучение моделей и тяжелые расчеты — кратковременная, но очень серьезная нагрузка. 

Логика для компаний проста: критичные данные и системы остаются on‑premise или в приватном облаке, а обучение и часть инференса перемещаются в публичное облако. 

❗Но развиваться эта тенденция будет не рывком, а постепенно — по мере того как компании наберут практический опыт, начнут больше доверять отечественным провайдерам и снимут внутренние барьеры: технологические и культурные.

От этого подхода в первую очередь выигрывают средние и крупные компании: финтех, e‑commerce, медиа и продуктовый ИТ. 

2️⃣ Тенденция 2: стагнация из-за регуляторики

Если регуляторы продолжат ужесточать требования, список данных, которые нельзя выносить из своего ЦОД, будет только расти.

В этом сценарии крупные компании и госсектор вкладываются в собственные дата-центры и частные облака. Публичное облако используют по остаточному принципу — 20–30% от нагрузки, в основном для тестов и вспомогательных сервисов.

Для тяжелых отраслей (банки, госсектор, здравоохранение) модель почти не меняется: основной фокус по‑прежнему на своих ЦОД и приватных облаках, а публичные остаются вспомогательными. 

❗А вот менее зарегулированных ужесточение правил подталкивает к гибриду — полностью в публичное облако нельзя, полностью делать on‑premise слишком дорого. В итоге гибрид из опции превращается в базовый вектор, и спрос на него будет только расти.

3️⃣ Тенденция 3: разделение по размерам и отраслям

У этой тенденции есть три вектора развития: они зависят от размера и отрасли и компании.

🏦 Крупные корпорации и госсектор держат максимум мощностей на своем железе и в частных облаках. Гибрид для них — это связка нескольких приватных площадок плюс небольшой процент публичного облака для некритичных задач.

🏢 Средний и крупный бизнес с запросом на развитие строят классический гибрид: критичное и регулируемое — в своем контуре, остальное — в облаке, чтобы ускориться и сэкономить.

🏪 Малый бизнес и стартапы без жесткой регуляторики идут в полностью публичное облако. Владеть железом им невыгодно, поэтому архитектура сразу проектируется облачной.

❗И хоть в случае со средним бизнесом гибрид пока упирается в стоимость и сложность, в перспективе именно этот сегмент может стать главным потребителем гибридного облака как сервиса.

😮 Отдельное исключение: специализированный гибрид под ИИ/ML

Даже сильно регулируемые игроки будут выносить в облако тяжелые вычислительные задачи — обучение и часть инференса. При этом данные и ключевые системы будут хранится on-premise. 

Все описанные тенденции мы не выдумали — это выводы из нашего большого исследования. Мы провели 17 глубинных интервью и узнали, как российские компании проектируют гибридные облака и почему делают их основой ИТ-инфраструктуры.

Получить исследование ←

Тестировщик докапывается — и это не баг, а фича

Тестировщиков иногда упрекают в том, что они всё время сомневаются и докапываются. Но что, если это не особенность характера, а главный профессиональный инструмент?

В новом выпуске «Не воспроизводится» Оля Шнайдер и Сережа Атрощенков разбирают тестирование не как набор действий, а как способ мышления. Почему QA ищет не подтверждение своей правоты, а подтверждение реальности? В чём разница между «душнилой» и внимательным инженером — и как донести эту разницу до коллег? Как поиск сложных багов превращается в настоящий квест, и почему отсутствие результата — это тоже результат? И наконец, как справляться с ощущением, что «что-то не так», даже когда работа сделана хорошо.

Слушайте выпуск на всех подкаст-платформах:

🎧 Яндекс Музыка
🔵 VK Видео 
📺 YouTube
Ⓜ️ Mave

Пару месяцев назад мне довелось поучаствовать в “контрольной закупке” одного из ювелирных магазинов. Обстоятельства были предельно ясные: в комментариях группы магазина в мессенджере Телеграмм стали писать боты и предлагать помощь с выбором украшения. При этом переписку старались перевести в личные сообщения, где уже и началось НЛП. Моя задача была определить, кто этим занимается и есть ли причастность сотрудников компании к данной схеме.

Ну что же, примеряем на себе образ “потенциального потерпевшего” и вступаем в переписку с ботом. Сначала меня игнорируют и недели 2-3 не выходят на связь, а потом долгожданное сообщение в … 4 часа утра! В каком часовом поясе живут лица по ту сторону экрана, я могу только догадываться.
Что было дальше, лучше почитать в прикрепленных скриншотах: как говорится, комментировать - только портить.

С учетом ограничений платформы на загрузку только 1 картинки, всю переписку можно прочитать у меня в группе Телеграм или Макс.

Однако при прочтении прошу обратить внимание на следующие аспе:

1. переписка велась с моего основного аккаунта, а “Виктория” даже не предприняла попытку установить, кто с ней общается и чем занимается;

2. адрес доставки и адрес склада совпадают, но у “Виктории” опять ничего не триггернуло;

3. описание банка, направленное “Викторией”, было сгенерировано ИИ не в ее пользу, так как “она” сама пишет: банк контролируется через иностранные компании и просьба не путать по написанию с другими банками. Но для “Виктории” главное, что офис находится в Москве :)

Естественно, что вся переписка велась при непосредственном контроле со стороны службы СБ заказчика. В качестве дополнительного “прогрева” были даже мысли “нарисовать” платежку с оплатой, но мысли о 327-й УК РФ не давали покоя, поэтому решили не рисковать. Ну и конечно, после окончания взаимодействия были уведомлены СБ Российских банков, где присутствовали счета указанных в переписке дропов.

В общем, как пели кот Базилио и лиса Алиса из кинофильма “Буратино”:

На дурака не нужен нож,
Ему с три короба наврёшь -
И делай с ним, что хошь!

Будьте аккуратны, берегите себя и своих близких.

🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

Дела становятся еще детектнее, а запуск новой версии PT NAD 13.0 — еще ближе ☄️

Уже 4 июня, ровно в 14:00, команда системы поведенческого анализа сетевого трафика от Positive Technologies — PT NAD — прольет свет на каждый темный уголок вашей инфраструктуры в новом сезоне «Очень детектных дел» (отсылка не случайна).

В этот день вы сможете вместе с нами узнать, как поменяют правила игры:

• автоматизированное реагирование;

• облачное детектирование;

• архивное хранение метаданных.

Чтобы точно все это успеть, вот чек-лист ваших действий прямо сейчас:

1) Отменить все свои планы на 4 июня в 14:00

2) Зарегистрироваться на онлайн-запуск по ссылке

3) С нетерпением ждать встречи вместе с нами.

Увидимся уже скоро! Такие дела.

Сегодня n8n и Dify стали популярными инструментами для создания ИИ‑агентов, автоматизации процессов и интеграции с LLM. Однако при внедрении в крупном бизнесе компании сталкиваются с рядом вопросов: ИБ, отсутствие SLA, юридические ограничения, интеграция с корпоративной средой.

На вебинаре покажем, как использовать возможности n8n и Dify в Enterprise‑контуре с помощью платформы ROBIN — безопасно, легально и с полноценной технической поддержкой.

Обсудим:

• какие риски возникают при самостоятельном внедрении Open Source решений;

• как обеспечить соответствие требованиям ИБ и импортозамещения;

• как связать ИИ‑агентов с корпоративными системами и RPA;

• как использовать готовые коннекторы и автоматизировать процессы даже в системах без API;

• реальные кейсы: выставление счетов в 1С через Telegram‑бота (связка n8n + ROBIN) и интеллектуальный подбор оборудования с оформлением заказа в ERP (связка Dify + ROBIN).

Также расскажем о подходе ROBIN к поддержке и сопровождению внешних ИИ‑агентов в корпоративной среде.

20 мая, 11:00, онлайн, бесплатно, требуется регистрация.

Представлен учебный открытый проект Awesome CUDA Books. Это подборка всех основных книг по программированию на CUDA — от начального до продвинутого уровня, C++/Python, архитектура, оптимизация и последние релизы 2024–2026 годов. Основано на практических, высококачественных ресурсах для параллельных вычислений на графических процессорах Nvidia.

В агрессивном поведении ИИ обвинили пользователей

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

Компания Anthropic подсчитала, что в случае угрозы отключения её большая языковая модель шантажирует пользователя (обычно раскрытием личных данных) в 96% случаев. Разработчик обвинил в агрессивном поведении Claude 4… интернет-пользователей. Anthropic заявила, что её чат-бот научился шантажировать, обучившись на текстах, где ИИ совершает злые поступки относительно людей.

Совершенно непонятно, почему Anthropic дистанцируется от текстов, на которых был обучен ИИ, но, по крайней мере, компания нашла несколько способов правильно обучать свою большую языковую модель. Просто приводить примеры правильного поведения не помогает, но положительный эффект дало обучение вести чат с пользователем об этических дилеммах, а также тренировка на художественных текстах о положительном поведении ИИ и на «конституции Claude» (с основами поведения). И ещё один момент: обучение срабатывает, когда к ИИ напрямую обращаются как к Claude — так в версии 4.5 удалось снизить вероятность шантажа почти до нуля.

Видимо, важно не учить ИИ напрямую хорошим поступкам, а рассказывать о правильном поведении на сторонних примерах — как похоже на людей, не правда ли? А если серьёзнее, то контроль поведения ИИ-моделей даст ещё немало проблем, которые ближе к решению этических вопросов, а не к привычной программной разработке.

Согласно проекту Zero Day ClockLive, с 2018 года значительно сократилось время от выявления уязвимостей в ПО до начала их активной эксплуатации в продуктивных системах (дельта между публичным раскрытием CVE и первым подтверждённым случаем эксплуатации в реальных условиях).

AI как промышленный ускоритель: почему работа с нейросетями — это жесткий контроль, а не «вброс промптов»

В последнее время в ИТ-сообществе не утихают споры о том, заменят ли нейросети программистов. Кто-то пророчит скорую смерть профессии, кто-то брезгливо морщится при упоминании сгенерированного кода. На своем опыте я убедился: правы и не правы обе стороны. Всё зависит от того, кто сидит за пультом управления.

Для меня взаимодействие с AI — это не слепой «вброс» абстрактных запросов в надежде получить готовое приложение. Это плотная, изнурительная аналитическая работа. AI сегодня — это лучшая в мире справочная система, сильный ассистент и неплохой аналитик. Но он остается исполнителем, за которым нужен неусыпный надзор.

Работая над архитектурой своего семантического ядра «Эстафеты Хвоста» (высоконагруженный движок на Lazarus/FPC под Jetson Nano в концепции Green Computing), я наглядно прочувствовал физику этого процесса.

Вот главные выводы, к которым я пришел:

1. Чем выше мощность, тем сложнее контроль

AI обладает огромной производительностью, и она отнюдь не иллюзорна. Он может за секунды выплюнуть сотни строк кода или развернуть сложную математическую модель. Но здесь кроется главная ловушка: если усыпить собственную бдительность, система мгновенно наплодит скрытых архитектурных галлюцинаций. Наш тандем выкристаллизовался именно тогда, когда я жестко поправлял ассистента в вопросах топологии графа, фрактальных маркеров и хронологии всплытия веток из ОЗУ. AI предлагает варианты — человек выносит вердикт и ведёт таргетинг алгоритма (в смысле следит за системным подходом к алгоритмизации, если алгоритмы новы или "вращаются" вокруг ядра с новым алгоритмом - кроме человека это делать некому, так как эти алгоритмы для AI неизвестны). Именно так мне удалось извлечь из одного стёка три UX - бонуса, только жёстко контролируя ответы AI, постоянно тергетируя целевой алгоритм ядра, постоянно внося поправки (ну я пользуюсь бесплатным, от поисковой системы браузера - более быстрые ответы в сравнении с локальными на мои 8 G видеокарты, всегда актуальная документация по IDE, ну и меньше углеродный след).

2. Время как решающий фактор

То, что нейросеть приходится постоянно корректировать, направлять и проверять «под микроскопом» — с лихвой окупается скоростью выдачи базовых конструкций. AI берет на себя рутину, синтаксический шум и написание boilerplate-кода. Моя цель — решить этим проектом ряд прикладных задач, чтобы высвободить личный временной ресурс для дальнейшего масштабирования системы. AI дает инженеру главное преимущество — время.

3. Шлифовка результата — это и есть работа

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

Итог

AI не заменит тех, кто умеет думать и проектировать. Если не отдавать бразды правления слепому алгоритму, а использовать его как реактивный бустер под строгим человеческим контролем, результат взаимодействия всегда будет строго положительным.

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

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

Представлен репозиторий с более чем 10 тыс. готовых API для:

• автоматизации — для рутинных задач и повторяющихся процессов, которые постоянно нужны;

• сбора данных с любого сайты, парсим и находим нужное с веб‑сайтов;

• аналитики — собираем данные о рынке, конкурентах и бизнесе;

• электронной коммерции — мониторинг цен, товаров, аналитика рынка;

• соцсетей — сбор постов, анализ вовлечённости аудитории и тенденций;

• интеграции ИИ — подключение к нейросетям, обработка контента и генерация данных;

• рынка труда — мониторинг вакансий, анализ зарплат и новых возможностей роста;

• недвижимости — поиск и анализ объявлений о продаже и покупки недвижимости для себя и инвестиций.

Представлен открытый проект tokenspeed (онлайн-версия), который показывает, насколько быстро на самом деле обрабатываются разные количества токенов в секунду. Все бенчмарки локальных LLM показывают пропускную способность: «47 токенов/с на M3», «180 токенов/с на 4090», «500 токенов/с на Groq». Но если вы не видели потоковую передачу токенов с такой скоростью, эти цифры трудно понять. tokenspeed — это терминальная утилита, которая передаёт фиктивные токены с любой заданной вами скоростью, так что вы можете увидеть, как эти цифры выглядят на самом деле.

Пользователь превратил свои Apple Watch в волшебную палочку. Он создал приложение, которое позволяет управлять умным домом жестами и заклинаниями из «Гарри Поттера». Энтузиаст делает движение запястьем, словно машет палочкой, и произносит заклинание. Часы распознают одновременно жест и голосовую команду, после чего запускается нужное действие через HomeKit. Например, если сказать Lumos и правильно взмахнуть рукой, в доме включится свет. Команда Nox, наоборот, выключит освещение. К заклинанию можно привязать практически разные действия: открытие умного замка, изменение температуры, включение музыки. В основе лежат датчики, которые уже есть в Apple Watch: акселерометр и гироскоп отвечают за распознавание движения, а микрофон за голосовую команду. После этого приложение запускает соответствующий шорткат в HomeKit.