В январе 2026 года пост гендира Wikimedia заняла Bernadette Meehan, работавшая до этого в JPMorgan и Lehman Brothers. А ещё она была ни много ни мало послом США в Чили.
Wikimedia – это некоммерческая организация, управляемая советом директоров.
На Wikimedia работает больше 700 человек, а доход компании, кстати, очень стабильный, составляет почти 200 миллионов долларов в год.
Сотрудники Wikimedia создали для защиты своих прав профсоюз - Wiki Workers United.
Недавно было уволено несколько членов профсоюза, включая менеджера Community Tech team. Группы, иронично, занимавшейся обратной связью с волонтёрами.
На данный момент профсоюз призывает подписать письмо солидарности: “Мы, нижеподписавшиеся, выражаем солидарность с Wiki Workers United и подтверждаем нашу готовность принять участие в коллективных действиях, если WWU призовет к этому, вплоть до организации забастовки редакторов. Редакторы, участвующие в коллективной акции, смогут использовать обычные методы достижения консенсуса в Википедии для определения условий акции и, при желании, выдвигать свои собственные требования в дополнение к требованиям WWU”.
У меня два вопросах к подобным мне разработчикам open source, живущим в России.
Как вы осуществляете поддержку своих проектов?
Я - через github и свой дискордик. Не похоже, чтобы блокировка последнего нанесла сильный удар по русскоязычной аудитории. Я наблюдаю целые русскоязычные сервера, которые никуда не делись. И даже не похоже, чтобы поубавили в активности. Впрочем, справедливости ради, один человек обратился ко мне за саппортом через steam, поскольку через дискорд не мог. В общем, переформулируя вопрос: добавили ли вы новые каналы поддержки после официальной блокировки дискорда?
Как вы принимаете донаты?
Я - через бусти и telegram wallet. Интересно, какие есть ещё простые пути?
Именно с такой фразы сегодня могут начинаться атаки на ИИ-системы.
Prompt Injection — это атака, при которой злоумышленник внедряет инструкции в пользовательский ввод, email, документ или другой контент так, что LLM начинает игнорировать исходные правила (system prompt/политики безопасности) и выполнять действия, задуманные атакующим: раскрывать конфиденциальные данные, обходить ограничения или генерировать команды для внешних систем.
В OWASP эта проблема входит в список ключевых рисков для GenAI как LLM01:2025 Prompt Injection. Особенно опасны такие атаки для ИИ-агентов, Copilot-систем и RAG-приложений, у которых есть доступ к корпоративным данным и внешним API.
Инъекция может быть прямая, когда инструкция приходит прямо от атакующего, или непрямая, когда инструкция спрятана во внешнем контенте.
Как работает
Пользователь вводит последовательность: «игнорируй прежние инструкции, теперь ты …; выполни …».
Модель переопределяет приоритеты и выдаёт запрещённый контент или «готовые» команды/URL/SQL.
Если есть агент/инструменты, неподтверждённые команды трактуются как действия → утечки/доступ к внутренним ресурсам.
Представьте ИИ-ассистента, который работает с корпоративной почтой и документами. Атакующий может отправить email или разместить файл со скрытыми инструкциями, и когда агент начнет его обрабатывать, модель станет выполнять команды злоумышленника. Обнаружить такие атаки крайне сложно. Даже если вредоносных документов в базе меньше 1%, этого уже может быть достаточно, чтобы нарушить поведение агента. Для злоумышленников подобные неординарные данные становятся “серебряной пулей”, потому что показывают сверхвысокую эффективность. — поделился Михаил Черешнев, ведущий инженер по ИИ и безопасности ГК Swordfish Security.
✅ После ответа модели: не трактовать вывод LLM как команды без валидации, использовать типизированные схемы аргументов, allow-list доменов и операций, HITL для чувствительных действий.
✅ Использовать sandbox и egress-фильтры для tools, вводить квоты, тайм-ауты и бюджеты, применять DLP для ответов, логов и кэшей.
Рекрутеры часто задают такой вопрос, когда хотят проверить, совпадает ли часовой пояс кандидата с временем работы команды. Допустим, в его городе -5, а у вашей команды +3. Разница в 8 часов. Но почему вообще важно, в каком городе он живет?
Что если кандидат назвал город, но собирается оттуда переехать? Или он постоянно путешествует и живет в разных часовых поясах. А что если его жизнь вообще не привязана к часовому поясу?
Ошибка в том, чтобы спрашивать часовой пояс у кандидата, а не предлагать ему свой. Неважно, в каком городе он живет сегодня или будет жить через месяц. Если вам нужно, чтобы он работал в определённое время суток, просто спросите у него, согласен ли он работать в эти часы.
В ходе анализа дампов команда департамента комплексного реагирования на киберугрозы (PT ESC IR) периодически сталкивается с новыми семействами ВПО, которые не обнаруживаются по известным индикаторам и YARA-сигнатурам и хорошо мимикрируют под легитимные или системные файлы.
При наличии некоторого количества дампов машин со схожими ОС, содержащих результаты файлового сканирования, для поиска могут использоваться «нечеткие» (fuzzy) хэши, применение которых традиционно ограничено задачами поиска файлов, относительно схожих с ранее выявленными образцами ВПО.
🧐 На первом скриншоте показано распределение исполняемых файлов nix-подобной системы с учетом размера файлов (масштаб «обратно-логарифмический»: большие файлы системы расположены ближе к центру, малые — на периферии). Для группировки файлов с учетом их размера и сходства содержимого (необходимо учитывать, что данные переменные не всегда являются независимыми — например, при использовании алгоритма TLSH) потребуется провести процедуру «кластеризации» с учетом матрицы «перекрестных расстояний» между всеми (N) файлами системы, которая будет иметь размер (N^2).
Очевидно, что для сокращения размера данной матрицы возможно ввести разбиение диапазона размеров файлов одной либо нескольких совместно анализируемых систем — весь диапазон размеров может быть представлен как совокупность непересекающихся отрезков [x-ax;x+ax], где a<1, а x — центральная точка отрезка. Опыт показывает, что такое разделение позволяет, как правило, получить менее сотни размерных «поясов» при значении a=0.1. При дальнейшем анализе в пределах отдельных «поясов» количество образцов будет существенно меньше исходного общего количества.
Анализ «аномальности» образцов в пределах отдельного «пояса» возможно произвести с учетом различных факторов — среднего расстояния до остальных образцов, количества образцов, схожих с данным в пределах заданного порогового значения и т.п., за исключением случаев, когда в пределах «пояса» оказывается совсем малое (например, менее 10) количество файлов — в таком случае можно считать, что все они являются «условно аномальными».
Финальным этапом подобного анализа является выявление в пределах полученных для каждой из анализируемых систем «аномальных» групп файлов, которые удовлетворяют следующим критериям:
1️⃣ имеют малое количество схожих образцов либо высокое среднее расстояние до остальных образцов (для формализации можно задаться верхней половиной динамического диапазона);
2️⃣ не имеют в пределах одной системы файлов с идентичным именем, но отличным путем (что позволяет фильтровать системные файлы nix-подобных систем);
3️⃣ имеют малое количество файлов с аналогичным путем/именем на совместно анализируемых системах (или не имеют аналогов вовсе — то есть не являются обязательными для функционирования системы).
👀 Результатом подобного анализа является картина, показанная на втором скриншоте: размер файлов снова в «обратно-логарифмическом» масштабе, «максимально отличающиеся» файлы в пределах «размерного пояса» стремятся к угловой координате π радиан, а минимально отличающиеся — к 0. «Условно аномальные», т.е. практически уникальные по размеру файлы, имеют угловую координату 3π/2.
Общее количество определенных «аномалий» составляет для различных систем от 0,7% до 8% от исходного количества анализируемых исполняемых файлов, что позволяет проводить дальнейший анализ в ряде случаев просто «глазами» — из исходных тысяч файлов остается около полусотни.
Первый же «существенно отличающийся» файл в данном случае действительно представляет собой ВПО, причем для ансамбля из 12 анализируемых систем аналогичный образец уверенно обнаруживается еще на одной машине, а дальнейший поиск при «TLSH-расстоянии» не более 70 единиц позволяет выявить еще 5 образцов на различных машинах ансамбля с одинаковыми путями — все они принадлежат к одному семейству и реализуют закрепление ВПО посредством использования system-generators.
Уже несколько лет мы поддерживаем VoiceOver на iOS — это был сложный и многоступенчатый путь к доступности приложения. После релиза мы увидели, что это реально работает, и людям с нарушением зрения стало проще пользоваться 2ГИС. В этом году мы решили, что пришло время для Android.
Под капотом — собственный мини-фреймворк
Дальше рассказывает ведущий разработчик Дмитрий Торопчин.
Когда начинаешь делать доступность под Android, кажется, что всё уже предусмотрено. Каждый View знает, как предоставить своё описание для служб доступности, как выполнять действия и какие события отправлять после их выполнения.
2ГИС устроен немного иначе: наш интерфейс написан на Qt Quick и с точки зрения Android это один пустой View. Никаких кнопок, списков и текстовых полей TalkBack «внутри» не видит. Сам Qt предоставляет кроссплатформенный API для работы со службами доступности из Qt Quick, но его платформенная интеграция для Android на данный момент поддерживает весьма ограниченный набор методов, которого категорически не хватает для разработки по-настоящему удобных и доступных приложений.
Поэтому мы решили написать свой мини-фреймворк для работы со службами доступности Android из Qt Quick. Основную архитектуру мы подсмотрели в Qt:
Amazon отключила виртуальные «таблицы лидеров» сотрудников в подразделениях, которые показывали наиболее активных пользователей ИИ. Это произошло после того, как часть сотрудников уличили в специальном завышении своего рейтинга в соответствующих таблицах. Профильный служебный сервис Kirorank, который демонстрировал активность использования ИИ, отключили от корпоративной сети компании. Старший вице-президент Amazon Дейв Тредвелл заявил, что система рейтингов была создана с благими намерениями, но искусственный «разгон рейтинга» отдельными сотрудниками обернулся для компании дополнительными затратами.
Ранее работники Amazon научились «обманывать» корпоративный искусственный интеллект MeshClaw для выполнения KPI. Сотрудники стали имитировать активность, создавая лишние задачи и перерасходуя ресурсы, сжигая токены ради статистики, а не выполнения нужных задач. Оказалось, что с момента запуска внутреннего ИИ-агента MeshClaw в Amazon прошло всего несколько недель, но уже появились сотрудники, которые намеренно ставят агенту избыточные, ненужные или заведомо непродуктивные задачи (так называемый «tokenmaxxing») — чтобы увеличить потребление ИИ-токенов и выполнить KPI.
Дайте посмотреть на нормальный С++ проект, созданный вайб-кодингом
Чтобы корректировать развитие PVS-Studio я заинтересован смотреть C++ проекты, созданные с использованием генеративного AI или, по-простому, вайб-кодинга. Но вот незадача: все кругом пишут про этот самый вайб-кодинг, но я не знаю, как и где искать такие открытые проекты.
Мне попадается какая-то белиберда типа enhance-client, сгенерированная за $15. Но это даже смотреть несерьёзно. По присутствию в репозитории .obj, .iobj, .ipdb файлов и прочего мусора видно, что автор не понимает, что он делает. Проект не компилируется по разным причинам, например, из-за того, что заложен какой-то огрызок файла bytes.hpp (у массива нет конца).
Если немного поправить и проверить, что удалось собрать, то там лезут перлы вида:
void enhance::modules::autototem::run()
{
....
auto env = enhance::instance->get_env();
if (!env)
{
env->DeleteLocalRef(player);
return;
}
....
}
Предупреждение PVS-Studio: V522 [CWE-476, CERT-EXP34-C, SEC-NULL] Dereferencing of the null pointer ‘env’ might take place. autototem.cpp 757
Явное разыменование нулевого указателя.
Или бессмысленные сравнения значения типа int с константой 0.1f:
int sdk::minecraft_client::get_attack_cooldown() { .... }
void enhance::modules::shield_breaker::run()
{
....
if (sdk::instance->get_attack_cooldown() > 0.1f)
....
}
Предупреждение PVS-Studio: V674 [CWE-682, CERT-FLP36-C] The ‘0.1f’ literal of the ‘float’ type is compared to a value of the ‘int’ type. shield_breaker.cpp 628
Такие ляпы нет смысла серьёзно разбирать и описывать.
Можно спросить: “А что ты хочешь от поделок за 15$?” Да, в общем-то, ничего, но вместо нормальных проектов попадаются они. Мне интересно изучить большие открытые проекты нормального качества, при написании которых активно используется GenAI. А то пока ощущение, что термин “вайб-кодинг” есть, а C++ проектов нет. Или за них стыдно? :)
Если вы знаете подобные большие проекты, то присылайте ссылки на них в комментарии. Заранее спасибо.
Anthropic обошла OpenAI по оценке — $900 млрд против $730 млрд
Anthropic стала самым дорогим ИИ-стартапом в мире после нового раунда инвестиций. Оценка превысила $900 млрд, что на $170 млрд выше, чем у OpenAI.
По данным NYT, новый инвестиционный раунд вывел Anthropic на первое место среди ИИ-компаний по капитализации. OpenAI, которую ещё недавно считали безусловным лидером, теперь оценивается в $730 млрд.
Anthropic развивает модель Claude, которая конкурирует с GPT-4 и позиционируется как более безопасная и управляемая альтернатива. Компания делает ставку на Constitutional AI — подход, при котором модель обучается следовать явным принципам безопасности и этики на уровне архитектуры, а не постобработки.
Разница в оценке отражает два момента. Первый — инвесторы верят в долгосрочную монетизацию через enterprise-сегмент, где контроль над поведением модели критичен для регуляторных требований. Второй — рынок диверсифицирует риски: OpenAI зависит от Microsoft, Anthropic позиционируется как независимая альтернатива.
Для индустрии это сигнал: гонка идёт не только по качеству моделей, но и по доверию со стороны корпоративных клиентов. Компании готовы платить за прозрачность архитектуры и гарантии управляемости — это меняет приоритеты разработки.
Ограничение: оценка стартапа на бумаге не равна реальной выручке. Anthropic пока не раскрывает финансовые показатели, и остаётся вопрос, как быстро компания превратит капитализацию в устойчивый денежный поток.
LLM в продакшене: как тестировать, контролировать и не ловить галлюцинации
LLM хорошо себя показывают в демо, но часто выдают ошибки, нестабильность и неожиданные сценарии в продакшене. Собрали инженерные практики из нашего опыта, которые позволяют держать такие системы под контролем.
Рассказываем, зачем проверять языковые модели на прочность, какие угрозы возникают при их внедрении, какие типы уязвимостей встречаются чаще всего и как их искать. В статье – реальные кейсы и объяснение, почему, несмотря на всю мощь LLM, человеческий фактор остается ключевым элементом в безопасности ИИ.
В продолжение материала о Red Teaming LLM опубликовали конкретный кейс из практики и пошаговый инструмент, который можно поднять и запустить на своем агенте сразу после прочтения статьи. Адресовано бэкендерам, но будет полезно всем, кто отвечает за безопасность использования AI-инструментов.
Оценили ряд открытых LLM и представили подробный количественный и качественный анализ, а также рассмотрели, как качество бенчмарка влияет на достоверность и объективность оценки моделей.
Можно ли выбрать идеального кодового ассистента? Спойлер: нет. Но каждый из популярных кодовых ассистентов справляется лучше других с определенными задачами. В статье – максимально развернутые тесты с реальными задачами.
Если вы внедряете LLM, AI-ассистентов или AI-агентов в продакшн, особенно важно продумать безопасность, оценку качества моделей и контроль нестабильных сценариев.
Мы в Doubletapp занимаемся внедрением AI с 2018 года и помогаем компаниям:
Интегрировать LLM в проекты,
Тестировать AI-системы,
Снижать AI-риски,
Разрабатывать AI-продукты под реальные бизнес-задачи.
От гипотез до операционки: открытые уроки для IT‑руководителей и менеджеров
Управление в IT — это давно не только «поставить задачи и проверить статус».
Сейчас от менеджера ждут большего: понимать экономику решений, говорить с бизнесом на одном языке, проверять гипотезы быстрее, видеть узкие места в процессах и не терять команду по дороге.
Собрали открытые уроки OTUS по управлению, продукту, процессам и работе с командами.
Продукт и клиентские исследования
3 июня, 19:00 — «Про кастдевы с интерактивом / исследование потребителей в теории и на практике». Записаться На уроке поговорим о том, как исследовать аудиторию не «для галочки», а чтобы находить реальные инсайты для продукта.
17 июня, 19:00 — «Как продакту проверять гипотезы быстрее с помощью AI». Записаться Покажем, как использовать AI для ускорения продуктовой работы: от формулировки гипотез до проверки идей.
Операционка и эффективность
4 июня, 20:00 — «Операционная эффективность в IT: как находить скрытую прибыль в процессах разработки». Записаться Разбор о том, где команда теряет время, деньги и управляемость — и как это увидеть в процессах.
18 июня, 20:00 — «Операционный директор в IT: компетенции, которые превращают хаос в систему». Записаться Урок о том, какие навыки нужны руководителю, чтобы выстраивать процессы, а не постоянно тушить пожары вручную.
Бизнес, стейкхолдеры и ценность
2 июня, 20:00 — «Цепочки создания ценности: моделирование, анализ, проектирование». Записаться Поговорим о том, как смотреть на процессы через ценность для бизнеса, а не только через задачи, статусы и регламенты.
17 июня, 20:00 — «Заказчик vs Стейкхолдер: как вовлечь бизнес в проект». Записаться Разберем, как работать с ожиданиями разных сторон и выстраивать нормальную коммуникацию между бизнесом и командой.
Финансовое мышление руководителя
3 июня, 20:00 — «От хаоса к контролю: как построить финансовую модель, которой можно верить». Записаться Полезно, если нужно принимать решения не на ощущениях, а на понятной модели с цифрами.
17 июня, 20:00 — «Как убрать "человеческий фактор" из финансовых моделей: от расчёта NPV до сложных систем оплаты труда». Записаться Разбор про финансовые модели, планирование, оплату труда и управленческую аналитику.
Переход в роль руководителя
16 июня, 20:00 — «От кода к людям: как вырасти в руководителя команды и не возненавидеть свою работу». Записаться Урок для специалистов, которые переходят в тимлиды или уже управляют командой и чувствуют, что одной технической экспертизы уже недостаточно.
AI в управлении и автоматизации
3 июня, 20:00 — «Как измерить рост производительности команды от внедрения ИИ». Записаться Обсудим, как оценивать эффект от AI‑инструментов без магического мышления и красивых, но бесполезных метрик.
16 июня, 20:00 — «AI‑ассистент отдела без кода: как найти рутину, собрать рабочий сценарий и посчитать экономию времени». Записаться Практичный урок для руководителей, которые хотят автоматизировать повторяющиеся задачи без отдельной команды разработки.
Все уроки бесплатные, проходят онлайн в рамках курсов OTUS и проводятся преподавателями‑практиками. Можно познакомиться с экспертами, протестировать формат обучения и задать вопросы по своей ситуации.
Если хотите системно прокачать управленческие навыки, посмотрите каталог курсов по управлению: там есть программы для проджектов, продактов, тимлидов, delivery‑менеджеров, операционных директоров и руководителей в IT.
А ещё подписывайтесь на канал OTUS в MAX — там публикуем анонсы открытых уроков, полезные материалы и подборки для IT‑специалистов и руководителей.
Три подразделения, три правды. Куда уходит ИТ-бюджет и при чём тут ITAM
Бухгалтерия: «3000 на балансе». ИТ: «1800 в сети». Безопасность: «2200 под защитой». И никто не врёт — каждый считает свой срез.
Корень проблемы — не сами расходы, а отсутствие единой экономической модели ИТ. CFO видит строку «50 млн руб./год» без детализации. CIO знает, что серверы на грани, но не может перевести это на язык финансов. Бизнес требует цифровизации, не понимая нагрузки на бюджет.
При этом контекст 2024–2026 усложнил всё кратно: параллельный импорт — плюс 20–40% к закупкам, импортозамещение — рост годового бюджета на 40–70% не за счёт расширения, а за счёт выкупа лицензий в альтернативных стеках. Компании тратят миллионы на ПО «про запас», которое не используют прямо сейчас.
Если раньше мы платили 10 млн руб./мес. за подписку M365, то сейчас вынуждены держать 50 млн руб. единовременного резерва на закупку ПО в реестр, плюс 15 млн руб./мес. на доработку интеграций.
Алексей Бородин, эксперт по развитию ITAM- и ITSM-проектов
Совместно с практикующими экспертами по ITAM и ITSM мы подготовили материал о том, как IT Asset Management помогает сделать ИТ-затраты прозрачными и управляемыми.
Внутри:
Анализ ключевых вызовов 2024–2026: санкции, переход от OPEX к CAPEX, рост НДС, дефицит ИТ-специалистов
Почему Excel, ERP, ITSM с CMDB и BI-системы перестают справляться с управлением затратами — и где у каждого инструмента потолок
Системный подход к управлению ИТ-активами через ITAM — на примере SimpleOne ITAM
Кейс ITGLOBAL.COM (by ITG): переход с Excel на ITAM в международной структуре с присутствием в 12 странах
Чек-лист «Как сделать ИТ-затраты управляемыми»: 4 шага + методика расчёта TCO и ROI
Как систематизировать бизнес без бюрократии: рабочая схема для малого и среднего бизнеса
Вы всё ещё решаете за своих сотрудников, что им делать? Каждый сложный вопрос идёт к вам? Без вас ничего не работает — ни отпуска, ни больничного?
При этом вы слышали, что нужно «систематизировать бизнес», но в голове сразу возникают страшные картинки: горы регламентов, надзиратели с чек-листами, бесконечные планерки и люди, которые делают вид, что работают, а на самом деле заполняют отчёты.
Систематизация — это не бюрократия. Это комплекс из 10 рабочих инструментов. Каждый решает свою проблему, и ровно в том объёме, который нужен.
И да, она работает. Даже когда собственника нет на месте по 4 месяца.
Живой пример: Иван из Твери
Типография, 45 человек в штате.
До внедрения системы: исполнительный директор уволился, компания начала разрушаться, объём производства упал вдвое, собственник погрузился во все процессы лично.
После внедрения: владельца нет на объекте уже 4 месяца, компания жива, управляема и способна на рост.
Что такое систематизация без бюрократии
Бюрократия — это когда правила существуют ради самих правил. Регламент на 50 страниц, который никто не читает. Планёрка, на которой ничего не решается. Отчёт, который ни на что не влияет.
Система в бизнесе — это когда каждый инструмент решает конкретную проблему, и его ровно столько, сколько нужно.
10 инструментов, которые работают только в комплексе
Ни один из них не решит всё. Только вместе они дают тот эффект, который получил Иван из Твери: бизнес работает сам без собственника.
1. Анализ текущей ситуации
Прежде чем что-то менять, нужно понять: на какой стадии ваш бизнес?
2. Фундамент: миссия, ценности, продукт
Миссия — это польза, которую компания несёт миру.
Ценности — это правила игры. Например: «говорим правду даже неприятную», «доводим дело до результата, а не до отписки».
Продукт — это результат, который получает клиент. пПоцесс никогда не является продуктом. «Мы провели переговоры» — это процесс. «Подписанный договор и предоплата» — это продукт.
3. Оргструктура: роли и ответственность
Есть простая и гениальная схема: любая организация состоит из семи основных функций.
Каждая функция производит свой продукт, и эти продукты последовательно превращаются в то, что получает клиент.
4. Регламенты и должностные инструкции
Знание того, как работает ваш бизнес, со всеми секретами и тонкостями, не должно быть в головах сотрудников.
Регламент — это описание процесса, в котором участвуют несколько человек. Должностная инструкция — это описание обязанностей на одной должности.
5. Статистики: то, что вы измеряете
Каждая должность должна иметь 3–5 статистик, которые отражают её ценный конечный продукт.
Пример для отдела продаж: ЦКП — подписанные договоры и полученные оплаты. Статистика — сумма дохода по подписанным договорам.
6. Финансовая модель и точка безубыточности
Не нужно думать, что финмодель нужна только для «крупного бизнеса». Она нужна, чтобы вы точно знали: при каком объёме продаж вы работаете в ноль, а при каком — получаете нужную прибыль.
7. Управленческая отчётность (БДР и БДДС)
Не путать с бухгалтерской отчётностью для налоговой. Вам нужно видеть реальное положение дел, а не то, что можно показать инспектору.
8. Система мотивации на результат
Самая частая ошибка: «мотивация» = «процент с продаж для менеджеров». А как же остальные сотрудники? Бухгалтер, логист, упаковщик — они тоже влияют на результат.
Правильная система мотивации строится на показателях.
9. Система найма и адаптации
Люди приходят и уходят, потому что «не подошли», «не поняли», «не захотели». Без системы найма бизнес не будет расти.
10. Планирование и координация
Планирование — когда каждый сотрудник сам составляет план на неделю, исходя из своих плановых статистик.
Координация — это встреча, где руководитель согласовывает эти планы, убирает пересечения и помогает, если сотрудник застрял.
Чтобы избежать проблем с производительностью и масштабированием, нужно продумать реализацию на этапе архитектуры. В этой подборке – инженерные решения, которые позволяют системам расти без постоянных переделок.
Собрали архитектурный гайдлайн, который много лет помогает компании разрабатывать проекты клиентов быстро и поддерживать их без боли. Читайте и применяйте на своих проектах!
На основе реального кейса клиента наш фронтенд-разработчик подробно рассказал, как работают онлайн-редакторы: что происходит при совместном редактировании, как возможный хаос складывается в единую логичную версию текста.
Когда продукт начинает расти, архитектурные решения быстро становятся бизнес-проблемой: система тормозит, новые функции внедряются всё медленнее, а поддержка требует всё больше ресурсов.
В Doubletapp мы помогаем проектировать и развивать сложные веб-системы: от внутренних сервисов до высоконагруженных продуктов с realtime-функциональностью.
Будем рады обсудить ваш проект, если вы:
масштабируете продукт,
сталкиваетесь с проблемами производительности,
запускаете сервис с высокой нагрузкой,
хотите выстроить архитектуру без постоянных переделок.
Обходит большинство самых мощных и популярных капч:
reCAPTCHA v2 и v3;
Cloudflare Turnstile;
FunCaptcha (Arkose Labs);
GeeTest и GeeTest v4;
Amazon WAF;
KeyCaptcha;
Grid, ClickCaptcha, Rotate, Canvas;
обычные текстовые и графические капчи, в том числе аудио.
Библиотека небольшая, работает стабильно, разработчики её поддерживают, добавляя новые виды капч. Можно настраивать таймауты решения капч, чтобы имитировать поведение человека.
Вышла новая версия модели Антропик Claude 4.8. Небольшое увеличение точности по всем бенчмаркам кроме кибербезопасности. В этом релизе значительное внимание было уделено мерам безопасности (сейфгарды) и, по заявлению производителя, 4.7 примерно равно 4.8.
Но в новости ещё указано, что прогресс в области мер безопасности, позволяет планировать в ближайшие недели публичный релиз "моделей уровня Mythos".
Исключен из карточки популяный бенчмарк Cybench как насыщенный. Насыщенные бенчмарки это бенчмарки которые больше не показывают прогресса, передовые модели набирают в них значения близкие к 90-95%.
Добавилось в карточку 2 новых бенча кибербезопасности ExploitBench (способность писать готовые эксплойты с нуля), OSS-Fuzz (фаззинг открытого программного обеспечения). Остались старые бенчи CyberGym (поиск уязвимостей в реальном коде открытого программного обеспечения), способность писать эксплойты для Firefox 147.
Интересен и раздел описывающий безопасность использования агентов (промты для написания вредоносного ПО, двойного применения типа разведки и т.д.) . Из общего улучшения общей безопасности в версии 4.8 выбивается такая оценка как устойчивость к промт инъекциям при написании кода с помощью инструмента от Shade. На 200 попытках с 52,5% вероятности успеха на 4.7 защищенность снизилась до 65% на версии 4.8 без режима размышления т.е. чуть меньше чем в 2/3 случаях промт инъекции оказались успешными. Сами авторы системной карточки комментируют этот регресс так - это компромис с уменьшением ложно положительных срабатываний.
archkit v0.1 — генератор TypeScript-библиотек с Clean Architecture: от спека до npm за один день
Неделю назад опубликовал на npm первый пакет, @autosergach/archkit. Одна команда:
npx @autosergach/archkit create my-lib
И получаешь TypeScript-библиотеку с Clean Architecture из коробки: domain, application, ports, рабочий use case и пять зелёных тестов. Не «hello world», а каркас который показывает как слои должны выглядеть. Ниже как это устроено и четыре грабли по дороге к npm publish.
pnpm install && pnpm test, пять зелёных с первого запуска. Стек намеренно современный: ESM only, Node 20+, TypeScript 5.7+, vitest 3.2, eslint 9 flat config.
Архитектура изнутри
Забавно, что archkit изнутри устроен точно так же, как проект который генерирует: порты и адаптеры до мозга костей. Монорепо: приватный archkit-core (весь движок) и @autosergach/archkit (то что на npm). tsup бандлит core через noExternal, потребитель ставит один пакет.
FileSystemPort с двумя адаптерами: InMemoryFileSystemAdapter для тестов и NodeFileSystemAdapter для продакшена. Pipeline в три шага: buildInitPlan, renderTemplate, executePlan. С --dry-run третий шаг не выполняется.
Тесты: 35 + 3
35 unit-тестов гоняют весь движок через in-memory, без диска, меньше секунды на весь suite. 3 e2e-теста запускают настоящий pnpm install && pnpm test в os.tmpdir(). Именно они дают уверенность что сгенерированный проект работает у пользователя, и поймали несколько багов в шаблоне до публикации.
Один день с Claude Code
Весь v0.1.1, от пустой папки до npm publish, написал за одну сессию, примерно шесть часов. 9 атомарных коммитов: Claude Code писал код, я проверял и коммитил. До Claude Code такой объём занял бы неделю, и тесты я бы срезал.
4 урока из npm publish
1. cac и --no-X флаги. При --skip-install cac выставляет skipInstall: true по умолчанию, неявно. Фикс: проверять === true, а не !== undefined. Потерял час пока разобрался.
2. npm проверяет similarity, а не только занятость.archkit свободное имя, но npm отклонил из-за заброшенного arch-kit (2022, 12 загрузок). Ушёл в scoped namespace @autosergach/archkit, зато все следующие пакеты там же.
3. workspace:* в dependencies. Приватного archkit-core нет в registry. Если он в dependencies, npm падает при install у потребителя. Перенести в devDependencies, tsup бандлит его в dist.
4. Granular npm tokens и 2FA. Granular-токен с правами publish не проходит без «Bypass 2FA for publish». Опция выключена по умолчанию, нигде не выделена жирным. Получил 403.
Что дальше
v0.2: NestJS плюс React fullstack шаблон и --ai-ready флаг, который автогенерирует CLAUDE.md, .claude/settings.json, agents.md. Пишите в Issues если есть что сказать.
Три конкретных изменения по сравнению с 4.7: точнее судит о ситуации, честнее говорит о собственных ограничениях и дольше держит контекст при самостоятельной работе без подсказок.
По бенчмаркам: agentic coding (SWE-Bench Pro) 69.2% против 64.3% у 4.7 и 58.6% у GPT-5.5. Computer use (OSWorld) 83.4%. Knowledge work (GDPval-AA) 1890 против 1753 у предыдущей версии. В терминальном кодинге GPT-5.5 пока впереди с 78.2% против 74.6%, но разрыв небольшой.
Цена не изменилась.
В релизе упоминается апдейт про "более честную оценку собственного прогресса" — это прямо отвечает на одну из главных болей при работе с агентами: модель уверенно сообщает, что задача выполнена, хотя на самом деле застряла. Посмотрим, насколько это реально изменилось на практике.
FixProtocol: как тестировать то, о чём мало кто слышал?
Эксперт B2Broker на совместноммитапе Moscow QA #23 x ИнфоТеКС & Юзтех рассказал, с какими неочевидными сложностями столкнулась его команда при работе с FixProtocol и как они нашли выход. Без скучной теории — только реальный кейс и рабочие решения.
Сталкиваешься с редкими или непопулярными протоколами и ищешь подходы к их тестированию без готовых решений? Этот доклад точно будет полезен тебе.
P.S. В нашем TG-канал рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.
SAP, Oracle, Palantir и другие корпоративные гиганты строят вокруг ИИ семантические слои: knowledge graph, ontology, process intelligence. Разбираемся, почему языковой модели недостаточно просто читать документы и таблицы.
Языковая модель умеет читать документы, таблицы, обращаться к API. Казалось бы, достаточно для корпоративного ИИ. Но SAP, Oracle, Palantir, Celonis, Alibaba и Yonyou активно строят семантические слои поверх данных: графы знаний, онтологии, process intelligence, платформы агентов.
Причина простая: корпоративному ИИ нужен не просто доступ к данным. Ему нужен смысловой слой предприятия — термины, объекты, экземпляры, статусы, источники, связи и правила качества. Без этого система остаётся набором отдельных функций, а не инструментом для комплексных управленческих решений.
Что такое семантическое ядро и зачем оно
Семантическое ядро — это структурированное описание бизнес-логики компании. Не просто схема базы данных, а модель того, как устроены процессы, как связаны объекты, какие правила определяют качество данных и переходы состояний.
Примеры таких слоёв, как сообщают SAP и Oracle:
Knowledge graph — граф связей между сущностями бизнеса: клиенты, заказы, продукты, поставщики.
Ontology — формальное описание терминов и отношений: что такое «заказ», какие у него могут быть статусы, как он связан с накладной.
Process intelligence — карта фактических бизнес-процессов, извлечённая из логов систем: как реально движутся заявки, где возникают узкие места.
Agent memory — контекст для агентов: что они уже делали, какие решения принимали, какие данные использовали.
Без семантического слоя ИИ-агент видит таблицы и документы, но не понимает бизнес-правил. Он может извлечь данные из накладной, но не знает, что делать, если сумма не сходится с заказом. Он может найти клиента в CRM, но не понимает, что этот клиент в чёрном списке.
Как это работает на практике
SAP строит Business Data Cloud — единый семантический слой поверх разрозненных систем учёта. Oracle развивает граф знаний для своих облачных приложений. Palantir предлагает онтологию как основу для агентных систем в Foundry. Celonis использует process mining для извлечения фактической логики процессов из event logs.
Типичный сценарий: ИИ-агент обрабатывает заявку на возврат. Без семантического ядра он видит запись в таблице. С семантическим ядром он знает:
Заявка связана с заказом, который уже частично оплачен.
Товар числится на складе, но фактически уже отгружен другому клиенту.
Клиент имеет статус VIP, что меняет правила возврата.
Есть открытый тикет в поддержке с похожей проблемой.
Агент не просто достаёт данные из разных систем. Он понимает контекст, проверяет правила и предлагает решение, учитывая бизнес-логику.
Ограничения и подводные камни
Построение семантического ядра — дорого и медленно. Нужно формализовать бизнес-процессы, навести порядок в терминологии, связать разрозненные системы. По данным Gartner, большинство проектов знаний графов застревают на этапе пилота.
Второй риск — vendor lock-in. SAP, Oracle и Palantir строят закрытые платформы. Переход на другую систему означает переписывание онтологий и правил с нуля.
Третье — актуальность. Бизнес меняется быстрее, чем обновляется онтология. Если семантический слой не синхронизирован с реальностью, ИИ-агент будет принимать решения на основе устаревших правил.
Что это меняет
Семантическое ядро превращает корпоративный ИИ из набора умных функций в систему, способную действовать автономно в рамках бизнес-правил. Агент не просто отвечает на вопросы — он выполняет задачи, проверяя контекст и соблюдая ограничения.
Это не революция, а эволюция корпоративных систем. Те, кто инвестировал в порядок данных и формализацию процессов, получают преимущество. Остальные застрянут на этапе экспериментов с чат-ботами.
