Все потоки

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

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

Смешанный подход (русская основа + точечные английские термины) даёт результат куда лучше, чем сплошной английский.

Вот четыре причины:

Нейросеть тратит силы на перевод, а не на суть ответа

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

Точные термины включают нужные знания

Лучшие технические статьи и разборы ошибок в индустрии написаны на английском. Слова вроде edge cases (граничные случаи) или trade-offs (компромиссы) работают как ключи, открывающие доступ к самой качественной базе знаний. Их русские аналоги часто уводят модель в скучные учебники или кривые переводы документации. Английский нужен только там, где нет точного и ёмкого русского аналога.

Запрет на воду и лебезение работает только на родном языке

Если вы хотите отучить модель от фраз вроде «Отличный вопрос!» и «Буду рад помочь», писать запрет нужно по-русски. Английское указание avoid sycophancy (избегай подхалимства) не сработает, потому что русские слова-паразиты просто не попадут в её стоп-лист. Инструкции по стилю и тону общения всегда должны быть на языке итогового ответа.

Кривой синтаксис и канцеляризм

Когда модель генерирует русский текст из английского запроса, она часто тащит за собой чужую грамматику. Появляются неестественные причастные обороты и канцеляризм («осуществляется обработка данных» вместо простого «обрабатываем данные»). Русский запрос сразу задаёт правильную структуру: короткие, чёткие и живые предложения.

Формула успеха проста. Русский язык задаёт правила игры, структуру и тон. Английский внедряется точечно, только для специфических технических терминов. Переводить запрос целиком, значит своими же руками снижать качество ответа.

Свой ML-завод: что дает собственная ML-платформа и как ее запустить

Большинство корпоративных ИИ-пилотов не дают измеримых результатов. Не из-за моделей, из-за инфраструктурного хаоса вокруг них.

Специалисты тратят время на подготовку данных и настройку окружения вместо экспериментов. Стек собирается из разрозненных инструментов, интеграция съедает месяцы, видеокарты простаивают и сжигают бюджет. А поверх всего — ужесточение требований к субъектам КИИ и приближающиеся сроки перехода на отечественное ПО.

На вебинаре разберем, как выстроить нормальный процесс разработки ИИ — от загрузки данных до обучения моделей на кластере видеокарт. Покажем, как платформа Evolution Stack.ML от Cloud.ru превращает этот хаос в работающий ML-завод: готовые сервисы убирают месяцы интеграций, единое управление наводит порядок в инфраструктуре, а развертывание внутри контура закрывает требования регуляторов.

Будет полезно специалистам по данным и ML-инженерам, руководителям команд, ИТ-архитекторам, DevOps-инженерам, специалистам по ИБ, техническим и ИТ-директорам.

Что обсудим:

• почему ИИ-проекты не взлетают: разрозненные инструменты, простой GPU и другие грабли;

• во сколько на самом деле обходится машинное обучение (спойлер: затраты на видеокарты лишь вершина айсберга);

• три пути к ML-платформе и скрытые ловушки каждого из них: облако, самостоятельная сборка на базе решений с открытым кодом, готовый продукт;

• когда локальное развертывание дешевле облака — и почему это работает не всегда;

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

• как устроена Evolution Stack.ML и зачем нужны рабочие пространства.

В практической части покажем:

• как создать рабочее пространство и подключить внешние источники данных;

• как запустить Jupyter-сервер на готовом образе — от выбора образа до открытия среды разработки;

• весь путь от первого запуска до распределенного обучения на нескольких GPU;

• как отслеживать метрики прямо из интерфейса платформы.

📅 2 июня в 11:00 мск
📍 Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикеру в прямом эфире.

На Бирже заказов появились новые задачи для разработчиков и консультантов 1С. В подборке — заказы, размещенные с 20 по 27 мая: доработки обработок, настройка обменов, интеграция с «Честным Знаком», задачи по маркировке, ЗУП, УТ, ERP, КА и даже 1С 7.7.

Заказы недели:

• Доработка «Печать договора поставки из справочника Договоры с контрагентами (ERP 2, КА 2, УТ 11)».

• Задача 1-Необходимо создать функционал зависимых СИЗ при расчете потребности выдачи которых, на основании норм выдачи, будет учитываться количество по формуле. Задача 2-По умолчанию в заказ на выдачу должен выводится (раздельный комплект).

• Доработка «Загрузка из Гранд-Смета».

• Интеграция УТ 11.3.218 к Честному Знаку.

• 1с розница 2.3. Продажа остатков новый рмк. Ошибка «Штрихкод не соответствует товару».

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

• Настройка и доработка синхронизации УТ 11.4 и БП 3.0 с нуля через EnterpriseData (сворачивание номенклатуры, фильтры)

• Консультации по 1с ут 11.5.22.134.

• Доработка «Расчет накопленных дней отпуска за работу с ядохимикатами за фактически оплаченные/отработанные часы во вредных условиях труда».

• Доработка «Реестр документов для 1С:ERP 2, КА 2, УТ 11».

Биржа заказов Инфостарта помогает быстро найти исполнителя под задачи по 1С: от разовой консультации до доработки конфигурации, настройки обмена, интеграции с внешними сервисами или сопровождения проекта.

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

Как подружить ИБ и разработку через командные топологии: вебинар с разбором реального кейса

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

Один из способов решить проблему — посмотреть не только на инженерные практики, но и на устройство и взаимодействие самих команд. Метод командных топологий помогает выстроить работу так, чтобы ИБ была частью потока поставки, а не контролирующим контуром. На вебинаре 5 июня техлид «Экспресс 42» разберёт:

• как связаны оргструктура команд, коммуникации между ними и архитектура разрабатываемых систем;

• как использовать командные топологии для анализа вашей текущей модели взаимодействия;

• как выглядит применение подхода на реальном проекте: от исходной ситуации до рекомендаций по изменениям и ожидаемого эффекта.

Регистрируйтесь и подключайтесь 5 июня в 12:00 (МСК), чтобы узнать, как командные топологии помогают снизить конфликтные ситуации и ускорить поставку изменений.

Я устал от общения с ИИ

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

Я работал в компании разработчиком. Задал владельцу бизнеса вопрос по бизнес задаче. Он мне присылает скрин из ChatGPT с ответом. Я отвечаю, что это вообще не относится к теме вопроса и там всё неверно. Через минуту он мне снова присылает скрин из ChatGPT. Он даже не читает ответ от ИИ. Он сразу делает скрин и присылает его мне.

Недавно на Reddit мне написали с обсуждением моего поста. Я ответил. Снова написали, я снова ответил. Спустя несколько сообщений я понял, что общаюсь с ИИ агентом.

Я устал от общения с ИИ.
Я хочу общаться с людьми.
Но даже когда я общаюсь с людьми, они пересылают мои вопросы ИИ и дают мне ответ от ИИ.

Blog • Telegram

Git reset: как управлять историей и не уничтожить свою работу

git reset — одна из тех команд, которые удобно держать под рукой, но страшно запускать без понимания последствий. Она помогает очистить локальную историю, убрать лишние коммиты, отменить git add или полностью откатиться к нужному состоянию. Но в режиме --hard может стереть незакоммиченные изменения так, будто ничего и не было.

В новой статье разобрали, что делает git reset, чем отличаются режимы --soft, --mixed и --hard, когда команду можно использовать безопасно, а когда лучше выбрать git revert или git restore. Отдельно показали типичные сценарии: объединение нескольких коммитов, вывод файлов из индекса, полный откат и восстановление после неудачного reset --hard через reflog.

Все подробности — в блоге Рег.облака.

Doom запускался на 486-м процессоре с 4 МБ RAM ещё в 1993 году.

И самое интересное - весь мир игры рендерился через BSP-дерево, binary space partition tree.

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

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

Как это работало:

• BSP-узел делит пространство на переднюю и заднюю часть  

• если игрок спереди - сначала рендерится переднее поддерево  

• если игрок сзади - сначала рендерится заднее поддерево  

• порядок уже задан самой структурой дерева

Именно поэтому Doom не нуждался в z-buffer.

Корректная видимость появлялась не из трюков с глубиной, а из самого порядка обхода BSP-дерева.

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

⚡️ Деннис Ритчи и Стив Джобс умерли в одном месяце: одного оплакивал весь мир, второго почти не заметили

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

Джобса оплакивали планетой, выпускали книги, сняли фильмы, именем назвали улицы. Он подарил iPhone, iPad, iPod и Macintosh, собрал вокруг Apple одну из самых дорогих компаний в истории. Денниса Ритчи провожали разве что в узком кругу и парой статей в блогах. Это был человек, который подарил нам язык C и вместе с Кеном Томпсоном Unix.

Дальше просто пройдёмся по цепочке. Без C нет Unix. Без Unix нет Linux, нет BSD, нет macOS и iOS. Без C не было бы Windows в его нынешнем виде, не было бы C++, Objective-C, Java, JavaScript в их привычном виде. Нет Chrome и Firefox, нет PostgreSQL и SQLite, нет Nginx, нет Photoshop, нет PlayStation и Xbox. Даже Python и PHP написаны на C.

При таком влиянии Ритчи оставался человеком, которого было сложно представить на сцене с черной водолазкой и в режиссёрском свете. Он работал в Bell Labs, носил бороду, избегал интервью и писал программы. Человек, без которого современный цифровой мир просто не выглядел бы так, как сейчас, провёл жизнь в тени своих собственных результатов.

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

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

Привет, коллеги! 👋 Уже в это воскресенье, 31 мая в 10:00, устроим мощный заряд знаний! ⚡️ За 4 часа своими руками поднимем стек мониторинга, настроим дашборды и оповещения! 📊🔔

Для кого это будет полезно:
- разработчики 💻
- аналитики 📈
- системные инженеры 🔧

Все подробности здесь: https://debugskills.ru/articles/labs/prometheus-grafana/

Апостроф и кавычки

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

Апостроф есть прямой ' и типографский ’. Для статей и постов рекомендуется использовать типографский апостроф. Хотя если посмотреть популярные новостные издания или блоги крупных технологических компаний, можно заметить, что у них даже в одной статье могут быть смешаны типографские и прямые апострофы и кавычки. Некоторые ИИ агенты не умеют использовать типографские символы и заменяют их на прямые.

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

Blog • Telegram

Когда регрессия уже не спасает: что почитать тестировщику про современный QA

QA больше не живёт в мире, где достаточно прогнать чек‑лист, закрыть пару багов и сказать: «ну вроде работает».

Сейчас тестировщику приходится думать шире: какие ошибки реально блокируют релиз, почему зелёные E2E‑тесты могут ничего не проверять, как flaky‑тесты ломают доверие к CI и где ИИ помогает, а где просто уверенно угадывает.

Начать стоит со статьи «Почему классический подход к QA больше не работает (и виновата ли в этом эпоха ИИ)». Это не очередной текст про «ИИ заменит тестировщиков», а разбор того, как меняется сама роль QA: от проверки готового продукта к работе с качеством на уровне архитектуры, данных, инфраструктуры, процессов и поведения системы после релиза.

В статье объясняется, почему старый подход уже трещит: современные продукты зависят от микросервисов, облаков, внешних API, ML‑моделей, пользовательских данных и цепочек интеграций. Поэтому тестировщику всё чаще нужно не просто находить баги, а понимать, где система может сломаться, как это повлияет на пользователя и что делать с качеством до, во время и после релиза.

Читать статью

А чтобы глубже разобраться в отдельных QA‑болях, собрали ещё несколько материалов:

1. «Ты QA и у тебя баги. Какие из них блокируют релиз?»
   _{Практичный разбор для ситуаций, когда до релиза осталось два часа, багов несколько, а чинить всё уже невозможно. В статье — как оценивать дефекты не по страшности описания, а по последствиям: деньги, данные, доступ, личная информация, заявки, отчёты и возможность быстро откатиться.}

2. «5 распространенных ошибок новичка в E2E‑тестах»
   _{Для тех, кто пишет автотесты и не хочет получать зелёный, но бесполезный отчёт. На примерах Playwright разбираются ошибки вроде проверки интерфейса без проверки реального взаимодействия, неправильного ожидания событий, слабых локаторов и опасного использования force.}

3. «Могут ли LLM находить flaky‑тесты по одному только коду теста? Разбор одного исследования»
   _{О том, почему идея звучит красиво, но на практике всё сложнее. Flaky‑тесты часто зависят от контекста: окружения, хелперов, кода под тестом, истории изменений и скрытого состояния. Поэтому одной LLM и одного куска теста часто недостаточно.}

А если хочется не только читать, но и разбирать QA‑подходы на практике — присмотритесь к бесплатным открытым урокам OTUS. Разделили ближайшие темы по направлениям: от ИИ в автотестах до мониторинга и инцидент‑менеджмента.

ИИ в тестировании и автотестах

• 2 июня, 20:00. «Нейросети и глубокое обучение в тестировании ПО: как приручить ИИ». Записаться

• 16 июня, 20:00. «ИИ в автотестах: помощник или угроза?». Записаться

• 18 июня, 20:00. «Тесты, которые чинят себя сами: практика ИИ в UI‑тестировании». Записаться

API, автотесты и инструменты

• 4 июня, 20:00. «API под контролем: тестирование сервисов с помощью Postman». Записаться

• 4 июня, 20:00. «Быстрая настройка конвейера автотестирования для 1С с хранилищем и Git». Записаться

Надежность, мониторинг и инциденты

• 10 июня, 20:00. «Мониторинг распределенных систем». Записаться

• 16 июня, 20:00. «Инцидент‑менеджмент в SRE. Как быстро находить, устранять и предотвращать сбои в системе». Записаться

Выбирайте тему под свой текущий фокус: ИИ в автотестах, API, мониторинг или инциденты. А если хочется посмотреть всё расписание — полный календарь открытых уроков OTUS.

И подписывайтесь на канал OTUS в MAX — там делимся новыми статьями, анонсами открытых уроков и полезными материалами для IT‑специалистов.

Вебинар уже завтра: как 1С-специалисту получать больше заказов через Инфостарт

Завтра, 28 мая в 11:00 мск, проведем вебинар для 1С-специалистов, которые хотят получать больше заказов через Биржу заказов Инфостарт и выстроить стабильный поток клиентов.

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

Поговорим о том:

— как искать перспективные заказы;
— как оформлять профиль и повышать конверсию откликов;
— как оценивать стоимость работ;
— как получать обращения напрямую через профиль;
— как использовать публикации и форум для привлечения клиентов.

Также обсудим безопасную сделку, бесплатные отклики, стартмани, подписку PRO и экономику работы на площадке.

Спикеры:

Алена Солохина — руководитель отдела маркетинга Инфостарт,
Антон Репин — руководитель группы аналитиков 1С Инфостарт.

В конце — Q&A-сессия с ответами на вопросы участников. Вопросы можно оставить заранее при регистрации.

📅 28 мая, 11:00 мск
⏱ Длительность: 1 час

26 мая 2026 года платформе для сообщества профессионалов в сфере IT исполнилось 20 лет. Хабр приглашает всех пользователей присоединиться к продолжающемуся празднованию этого события.

Добро пожаловать в «Дом Хабра». За 20 лет здесь написали 352 855 статей и переводов, их суммарное время на прочтение перевалило за два миллиона минут, а само сообщество выросло до 71 849 авторов. У самой охватной статьи — почти 5,7 миллиона просмотров. У самой заплюсованной  — 1 447 плюсов, у самой комментируемой — 2 939 комментариев. А самую сохраняемую добавили в закладки 9 292 раза.

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

Хабр — это дом, который вы строили сами, и к юбилею сообщества мы оттолкнулись от этой мысли и сделали из неё игру «Дом Хабра».

Что такое «Дом Хабра»

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

«Дом Хабра» — это игра, где есть дом из пяти тематических комнат. В каждой — мини-квест в механике поиска предметов: нужно найти спрятанные объекты, решить небольшую задачу и помочь герою комнаты. Главная задача: пройти все комнаты дома и собрать жильцов на празднование дня рождения Хабра в гостиной.

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

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

• Карьера (кабинет Хабр Карьеры),

• Инновации (лаборатория X5 Tech),

• Авторы (чердак Лаборатории Касперского),

• Разработка (игровая VK),

• Образование (библиотека Финама).

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

Индустрия AI смещается со сверхразумного AGI на рекурсивный RSI

Раньше все обсуждали AGI – искусственный общий интеллект, который думает «как человек», и даже лучше. Теперь внимание переключается на рекурсивные системы (RSI), которые умеют переписывать и улучшать собственный код. Если AGI пугали, что «машины станут умнее нас», то с RSI призывают, «как заставить модель саму себя апгрейдить без участия инженеров».

Почему именно сейчас? Сходятся несколько факторов. Завершается цикл крупных AI-проектов на биржу, и капитал ищет новые темы для роста. Метрика успеха становится понятнее. Конкретный бенчмарк будет в том, сколько итераций самооптимизации проходит система за час. Коммерческая логика тоже работает: кто первый запустит рекурсивный цикл, тот получит экспоненту в скорости разработки.

К середине 2026 года признаков скорого прорыва к RSI пока нет. Даже Anthropic, которая заявляет, что использует Claude для большей части своего кода, не демонстрирует систем, способных к автономному циклическому улучшению. Но появляются стартапы, которые делают ставку на это направление. Например, Recursive Superintelligence фокусируется на дизайне чипов, то есть задаче, где даже небольшие оптимизации дают кратный экономический эффект.

Риски те же, что и всегда. Нет доказательств, что текущие архитектуры трансформеров способны к устойчивому самоусовершенствованию без деградации. Растет разрыв между затратами на внедрение AI и реальной отдачей. Недавно операционный директор Uber Эндрю Макдональд признался, что компания исчерпала годовой бюджет на AI-токены за несколько месяцев, но не увидела пропорционального роста продуктивности. Даже если это технически получится, непонятно, как это монетизировать и кто будет платить AI, который сам себя переписывает.

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

ИИ не заменил менеджеров. Он сделал их узким местом

Картинка из моей работы. Облачная конференция, сессии наших спикеров на других ивентах, лендинги, статьи в СМИ и блог, Хабр. При производстве практически каждой единицы контента используется ИИ — целая фабрика агентов. Но между ИИ и готовым результатом есть человек, в данном случая я. Человек смотрит, проверяет, принимает решение. И этот ресурс ничем не масштабируется.

И это не то, чтобы только у меня подгорает. На прошлой неделе в HBR вышел материал Managers Are Struggling to Keep Up with the AI Productivity Boom. Открывается цитатой менеджера: "каждые тридцать минут кто-то создаёт что-то, что я должен посмотреть". CIO в свежей колонке формулирует ещё жёстче: исполнение перестаёт быть ограничением, дефицитным ресурсом становится суждение. Производство чего либо-ускорилось в разы. Но при этом никто не перестраивает поток работы под ИИ, практически всегда остаются те же цепочки согласований, что были до.

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

Короче, производство ускорили на порядок, а пропускную способность решений — процентов на двадцать. Разница оседает у тебя на столе. И, надо признать, в этом нет ничьего злого умысла. Просто индустрия выкатила инструмент, который сжимает один этап цепи, и почему-то решила, что от этого ускорилась вся цепь. Не ускорилась. Узкое место мигрировало. Сейчас оно сидит на менеджерском стуле и проверяет то, что выдала модель.

💡Что могу посоветовать. «Делегируйте больше», «фокусируйтесь на главном», «приоритизируйте» — это всё сработает только, если у вас есть большая команда.

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

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

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

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

Подписывайтесь на канал, там больше и раньше.

Дорогой Хабр, с днём рождения!

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

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

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

С днём рождения, уникальная площадка с уникальным комьюнити!

К вопросу о возрасте последнего общего предка всего живого (LUCA) и степени самосогласованности данных в современной молекулярной биологии.

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

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

Но все же более интересным, и, не побоюсь этого слова, шокирующим для меня был другой вывод статьи, а именно, что, в соответствии с расчетами ее авторов, основанными на методе молекулярных часов, LUCA жил на Земле уже примерно 4.50 миллиардов лет назад, то есть, всего через 20 миллионов лет после столкновения Земли с Тейей! На минуточку, по оценке ученых, после указанного столкновения только остывание поверхности Земли до приемлемых для жизни температур заняло, как минимум, те самые 20 млн. лет. А ведь LUCA был уже, по сути, прокариотической клеткой с более, чем 2000 кодируемыми ДНК генами.

Но и это ещё не все. Тоже в прошлом году во втором по мировой известности журнале Science вышла другая статья, в которой вычислялись временные рамки адаптации бактерий к кислороду и, попутно, оценивался возраст последнего общего предка всех ныне живущих бактерий. Он у авторов получился равным примерно 4.15 млрд. лет. И все бы хорошо, но практически по всем современным работам в этой области между появлением последнего общего предка всех живых существ на Земле и появлением последнего общего предка бактерий прошел минимум миллиард лет.

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

Надеюсь, в конце-концов у ученых все же хватит смелости признать, что жизнь зародилась не на Земле!)

Агентный ИИ: как внедрять автономные цифровые системы безопасно

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

В новом руководстве разбираем:

🎱как меняются цифровые системы с приходом агентного ИИ,

🎱какие уязвимости возникают в цепочках действий и логике принятия решений,

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

🎱как компании сейчас проходят путь внедрения агентного ИИ.

Скачивайте руководство на нашем сайте.

1С как центр бизнес-экосистемы: зачем разработчику разбираться в обмене данными

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

На курсе «Обмен данными в системе 1С:Предприятие» мы разбираем, как проектировать и реализовывать такие интеграции на практике: от обменов между конфигурациями до API, JSON, XML, HTTP- и WEB-сервисов.

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

Обмен данными — не просто техническая настройка. Это способ связать отдельные участки бизнеса в единый процесс.

Один из частых сценариев — обмен между конфигурациями 1С: «Управлением торговлей», ЗУП, «Бухгалтерией» и другими решениями. Если конфигурации типовые, часть обменов можно настроить стандартными средствами. Но в реальных проектах базы часто дорабатываются: появляются новые реквизиты, меняются документы, добавляются справочники и нестандартная логика учета.

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

Другой сценарий — интеграция 1С с внешними системами: сайтом, маркетплейсом, CRM, BI-сервисом или сторонней базой данных. На схеме все выглядит просто: 1С выгружает товары, цены и остатки, а обратно получает заказы и статусы оплат. На практике сразу появляются нюансы: API недоступен, данные пришли в неожиданном формате, заказ изменился после загрузки, внешний идентификатор не нашелся в базе.

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

Для обменов в 1С используются файлы, XML, JSON, XDTO, HTTP- и WEB-сервисы, внешние источники данных, COM- и OLE-технологии, планы обмена. Но выбор технологии — только часть задачи. Гораздо важнее понять логику процесса: откуда берутся данные, куда они должны попасть, кто отвечает за их актуальность и как система ведет себя при сбое.

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

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

Для пользователя важен не сам факт передачи JSON или XML, а результат: заказ попал в учет, остатки обновились, документы сформировались, отчетность не разъехалась. Поэтому разработчик 1С все чаще работает не только внутри конфигурации. Он связывает 1С с внешними сервисами, настраивает двусторонний обмен, проектирует API и помогает бизнесу избавиться от ручных операций.

Старт курса «Обмен данными в системе 1С:Предприятие» — 5 июня 2026 года.

Доверился ChatGPT в суде? А штраф платить тебе, а не боту

Очень интересное решение кассации, касающееся применения искусственного интеллекта. Рассказываю по фактам.

Что произошло

Компания подала кассационную жалобу и указала в ней ряд судебных актов (в том числе ВС РФ и ВАС РФ), а также привела оттуда цитаты, которые прямо подтверждали её аргументы.

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

Компания получила штраф 50 000 рублей за неуважение к суду.

Как суд мотивировал решение

Окружной суд указал следующее:

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

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

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

⦁ Внутренние отношения компании с представителем не важны для применения к ней санкции.

А исковые требования (основной долг за неоплату бухгалтерских услуг и неустойка) составляли всего 55 246 рублей.

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

Что это значит для всех

Напомню, по общему правилу АПК РФ максимальный размер судебного штрафа для организаций — 100 000 рублей. Здесь назначили 50 000 — половину от максимума.

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

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

Документ: Постановление АС Западно-Сибирского округа от 14.05.2026 по делу N А27-7831/2025

А что вы думаете? Стоило ли идти в кассацию из-за 55 тысяч? Как относитесь к использованию ИИ для подготовки юридических документов? Делитесь мнением в комментариях 👇