Я нашел репозитории в GitHub, которые распространяют вредоносный код. Обсудил с ИИ что с этим делать, но полезных советов он не дал. Я открыл обсуждение на GitHub. Мне ответили. Там был точно такой же текст от ИИ. Я указал на это и ответ удалили. Потом ответил другой человек. Там снова был такой же ответ от ИИ.
Я работал в компании разработчиком. Задал владельцу бизнеса вопрос по бизнес задаче. Он мне присылает скрин из ChatGPT с ответом. Я отвечаю, что это вообще не относится к теме вопроса и там всё неверно. Через минуту он мне снова присылает скрин из ChatGPT. Он даже не читает ответ от ИИ. Он сразу делает скрин и присылает его мне.
Недавно на Reddit мне написали с обсуждением моего поста. Я ответил. Снова написали, я снова ответил. Спустя несколько сообщений я понял, что общаюсь с ИИ агентом.
Я устал от общения с ИИ. Я хочу общаться с людьми. Но даже когда я общаюсь с людьми, они пересылают мои вопросы ИИ и дают мне ответ от ИИ.
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 часа своими руками поднимем стек мониторинга, настроим дашборды и оповещения! 📊🔔
Для кого это будет полезно: - разработчики 💻 - аналитики 📈 - системные инженеры 🔧
В американском стиле используются двойные типографские кавычки “ ”, в британском одинарные ‘ ’, а в технической документации прямые " ". В американском стиле знаки препинания ставятся внутри кавычек, в британском исходя из смысла. Но часто даже в американских блогах и технических книгах знаки ставят по смыслу, а не внутри.
Апостроф есть прямой ' и типографский ’. Для статей и постов рекомендуется использовать типографский апостроф. Хотя если посмотреть популярные новостные издания или блоги крупных технологических компаний, можно заметить, что у них даже в одной статье могут быть смешаны типографские и прямые апострофы и кавычки. Некоторые ИИ агенты не умеют использовать типографские символы и заменяют их на прямые.
Всегда удобнее ставить прямые кавычки, чем зажимать 3 клавиши для типографских. Тем более в прямых одинаковый символ для открытия и закрытия кавычек, а в типографских разные. На ноутбуке можно настроить умную автозамену на типографский вариант, но большинство программ игнорируют эту настройку. Если вы пишете на разных языках или под разный стиль, то умная замена не поможет. Можно настроить скрипт для автозамены перед публикацией статей, но если в статье содержатся примеры кода, то в них нельзя делать замену. Можно перед публикацией вручную заменять на типографские, но при ответе на комментарии снова будут прямые. Есть шрифты, которые красиво отображают прямой апостроф, но шрифт контролируешь только на своем сайте. Некоторые сайты при наборе текста автоматически заменяют на типографские знаки, но если делать вставку текста, то в нем оставляют прямые.
Когда регрессия уже не спасает: что почитать тестировщику про современный QA
QA больше не живёт в мире, где достаточно прогнать чек‑лист, закрыть пару багов и сказать: «ну вроде работает».
Сейчас тестировщику приходится думать шире: какие ошибки реально блокируют релиз, почему зелёные E2E‑тесты могут ничего не проверять, как flaky‑тесты ломают доверие к CI и где ИИ помогает, а где просто уверенно угадывает.
Начать стоит со статьи «Почему классический подход к QA больше не работает (и виновата ли в этом эпоха ИИ)». Это не очередной текст про «ИИ заменит тестировщиков», а разбор того, как меняется сама роль QA: от проверки готового продукта к работе с качеством на уровне архитектуры, данных, инфраструктуры, процессов и поведения системы после релиза.
В статье объясняется, почему старый подход уже трещит: современные продукты зависят от микросервисов, облаков, внешних API, ML‑моделей, пользовательских данных и цепочек интеграций. Поэтому тестировщику всё чаще нужно не просто находить баги, а понимать, где система может сломаться, как это повлияет на пользователя и что делать с качеством до, во время и после релиза.
А чтобы глубже разобраться в отдельных QA‑болях, собрали ещё несколько материалов:
«Ты QA и у тебя баги. Какие из них блокируют релиз?» Практичный разбор для ситуаций, когда до релиза осталось два часа, багов несколько, а чинить всё уже невозможно. В статье — как оценивать дефекты не по страшности описания, а по последствиям: деньги, данные, доступ, личная информация, заявки, отчёты и возможность быстро откатиться.
«5 распространенных ошибок новичка в E2E‑тестах» Для тех, кто пишет автотесты и не хочет получать зелёный, но бесполезный отчёт. На примерах Playwright разбираются ошибки вроде проверки интерфейса без проверки реального взаимодействия, неправильного ожидания событий, слабых локаторов и опасного использования force.
А если хочется не только читать, но и разбирать QA‑подходы на практике — присмотритесь к бесплатным открытым урокам OTUS. Разделили ближайшие темы по направлениям: от ИИ в автотестах до мониторинга и инцидент‑менеджмента.
ИИ в тестировании и автотестах
2 июня, 20:00. «Нейросети и глубокое обучение в тестировании ПО: как приручить ИИ». Записаться
16 июня, 20:00. «ИИ в автотестах: помощник или угроза?». Записаться
18 июня, 20:00. «Тесты, которые чинят себя сами: практика ИИ в UI‑тестировании». Записаться
API, автотесты и инструменты
4 июня, 20:00. «API под контролем: тестирование сервисов с помощью Postman». Записаться
4 июня, 20:00. «Быстрая настройка конвейера автотестирования для 1С с хранилищем и Git». Записаться
16 июня, 20:00. «Инцидент‑менеджмент в SRE. Как быстро находить, устранять и предотвращать сбои в системе». Записаться
Выбирайте тему под свой текущий фокус: ИИ в автотестах, API, мониторинг или инциденты. А если хочется посмотреть всё расписание — полный календарь открытых уроков OTUS.
И подписывайтесь на канал OTUS в MAX — там делимся новыми статьями, анонсами открытых уроков и полезными материалами для IT‑специалистов.
Вебинар уже завтра: как 1С-специалисту получать больше заказов через Инфостарт
Завтра, 28 мая в 11:00 мск, проведем вебинар для 1С-специалистов, которые хотят получать больше заказов через Биржу заказов Инфостарт и выстроить стабильный поток клиентов.
Разберем, как сегодня заказчики выбирают специалистов, что влияет на доверие к профилю, как откликаться на проекты без демпинга и какие возможности площадки помогают получать больше обращений.
Поговорим о том:
— как искать перспективные заказы; — как оформлять профиль и повышать конверсию откликов; — как оценивать стоимость работ; — как получать обращения напрямую через профиль; — как использовать публикации и форум для привлечения клиентов.
Также обсудим безопасную сделку, бесплатные отклики, стартмани, подписку PRO и экономику работы на площадке.
Спикеры:
Алена Солохина — руководитель отдела маркетинга Инфостарт, Антон Репин — руководитель группы аналитиков 1С Инфостарт.
26 мая 2026 года платформе для сообщества профессионалов в сфере IT исполнилось 20 лет. Хабр приглашает всех пользователей присоединиться к продолжающемуся празднованию этого события.
Добро пожаловать в «Дом Хабра». За 20 лет здесь написали 352 855 статей и переводов, их суммарное время на прочтение перевалило за два миллиона минут, а само сообщество выросло до 71 849 авторов. У самой охватной статьи — почти 5,7 миллиона просмотров. У самой заплюсованной — 1 447 плюсов, у самой комментируемой — 2 939 комментариев. А самую сохраняемую добавили в закладки 9 292 раза.
За этими большими числами — люди, которые открывали редактор и садились писать поздно вечером, когда желание поделиться было важнее сна. Это дискуссии в комментариях, которые иногда заканчивались дружбой или офером. Это сообщество, которое строило себя само — статья за статьёй и хаб за хабом.
Хабр — это дом, который вы строили сами, и к юбилею сообщества мы оттолкнулись от этой мысли и сделали из неё игру «Дом Хабра».
Что такое «Дом Хабра»
Метафора простая: Хабр — это большой дом, который строят его жители. А это вы: разработчики, инженеры, авторы, эксперты, читатели. Каждый, кто написал сюда статью, ответил на вопрос или просто листал ленту в три часа ночи — вы часть этого дома.
«Дом Хабра» — это игра, где есть дом из пяти тематических комнат. В каждой — мини-квест в механике поиска предметов: нужно найти спрятанные объекты, решить небольшую задачу и помочь герою комнаты. Главная задача: пройти все комнаты дома и собрать жильцов на празднование дня рождения Хабра в гостиной.
Постарались сделать рисовку в духе «Времени приключений», чтобы вы могли поностальгировать. И повторимся, что саму игру проходить лучше с десктопа — так удобнее и приятнее.
Комнаты в доме тематические. И задумка была в том, чтобы каждая из них отражала грани экосистемы Хабра, без которой нельзя представить сообщество:
Карьера (кабинет Хабр Карьеры),
Инновации (лаборатория X5 Tech),
Авторы (чердак Лаборатории Касперского),
Разработка (игровая VK),
Образование (библиотека Финама).
Каждый партнёр разыграет призы среди тех, кто пройдет задания во всех комнатах Дома Хабра: пакеты фирменного мерча, промокоды, индивидуальные обучения. Победителей будет много.
Индустрия AI смещается со сверхразумного AGI на рекурсивный RSI
RSI: обучение → анализ себя → улучшение → новая версия → еще более быстрое улучшение → …
Раньше все обсуждали AGI – искусственный общий интеллект, который думает «как человек», и даже лучше. Теперь внимание переключается на рекурсивные системы (RSI), которые умеют переписывать и улучшать собственный код. Если AGI пугали, что «машины станут умнее нас», то с RSI призывают, «как заставить модель саму себя апгрейдить без участия инженеров».
Почему именно сейчас? Сходятся несколько факторов. Завершается цикл крупных AI-проектов на биржу, и капитал ищет новые темы для роста. Метрика успеха становится понятнее. Конкретный бенчмарк будет в том, сколько итераций самооптимизации проходит система за час. Коммерческая логика тоже работает: кто первый запустит рекурсивный цикл, тот получит экспоненту в скорости разработки.
К середине 2026 года признаков скорого прорыва к RSI пока нет. Даже Anthropic, которая заявляет, что использует Claude для большей части своего кода, не демонстрирует систем, способных к автономному циклическому улучшению. Но появляются стартапы, которые делают ставку на это направление. Например, Recursive Superintelligence фокусируется на дизайне чипов, то есть задаче, где даже небольшие оптимизации дают кратный экономический эффект.
Риски те же, что и всегда. Нет доказательств, что текущие архитектуры трансформеров способны к устойчивому самоусовершенствованию без деградации. Растет разрыв между затратами на внедрение AI и реальной отдачей. Недавно операционный директор Uber Эндрю Макдональд признался, что компания исчерпала годовой бюджет на AI-токены за несколько месяцев, но не увидела пропорционального роста продуктивности. Даже если это технически получится, непонятно, как это монетизировать и кто будет платить AI, который сам себя переписывает.
Что будет с рынком? Не ждите сингулярности в ближайшие годы. Но готовьтесь к тому, что инвестиции, кадры и исследовательские приоритеты уже смещаются в сторону автономных систем. Ценность переходит от данных и готовых моделей к архитектурам, способным к эволюции без постоянного вмешательства человека.
ИИ не заменил менеджеров. Он сделал их узким местом
Картинка из моей работы. Облачная конференция, сессии наших спикеров на других ивентах, лендинги, статьи в СМИ и блог, Хабр. При производстве практически каждой единицы контента используется ИИ — целая фабрика агентов. Но между ИИ и готовым результатом есть человек, в данном случая я. Человек смотрит, проверяет, принимает решение. И этот ресурс ничем не масштабируется.
Опять вернусь к своему опыту. Когда ревьюишь черновик от человека, то ловишь опечатки и логику. Когда ревьюишь то, что выдала модель — проверяешь каждый факт, каждую формулировку, каждую цифру. Ошибки модели уверенные, гладкие, правдоподобные, их не отловить, читая по-диагонали. ИИ снимает нагрузку с генерации и нагружает верификацию. Инженеры в опросах напрямую отвечают: проверять 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 и помогает бизнесу избавиться от ручных операций.
Доверился ChatGPT в суде? А штраф платить тебе, а не боту
Очень интересное решение кассации, касающееся применения искусственного интеллекта. Рассказываю по фактам.
Что произошло
Компания подала кассационную жалобу и указала в ней ряд судебных актов (в том числе ВС РФ и ВАС РФ), а также привела оттуда цитаты, которые прямо подтверждали её аргументы.
Однако окружной суд выявил, что одних документов не существует, а в других нет заявленных суждений.
Компания получила штраф 50 000 рублей за неуважение к суду.
Как суд мотивировал решение
Окружной суд указал следующее:
⦁ Компания представила заведомо ложные сведения, подделала источники, стремилась повлиять на суд авторитетом высшей инстанции. Это прямой обман и грубейшее неуважение к правосудию.
⦁ У подобного поведения нет оправданий, включая довод о подготовке кассационной жалобы с помощью ИИ. В таком случае за достоверность сгенерированного текста отвечает участник дела, который использовал технологию.
⦁ Просьба нового представителя не учитывать сфабрикованную практику не освобождает компанию от ответственности. Она рассчитывала на пользу от обмана, пока кассация не обнаружила подделку. Проявление неуважения уже состоялось как оконченное нарушение и требует реакции.
⦁ Внутренние отношения компании с представителем не важны для применения к ней санкции.
А исковые требования (основной долг за неоплату бухгалтерских услуг и неустойка) составляли всего 55 246 рублей.
Всегда поражают споры на такие суммы. Стороны не смогли договориться из-за столь незначительной суммы, зато были готовы пройти три инстанции. В итоге ещё и штраф 50 000 рублей сверху. Вопрос: овчинка выделки стоила?
Что это значит для всех
Напомню, по общему правилу АПК РФ максимальный размер судебного штрафа для организаций — 100 000 рублей. Здесь назначили 50 000 — половину от максимума.
Вывод: Кассация сформировала важную правовую позицию, и теперь многие нижестоящие суды будут её учитывать.
Этот пример доказывает: ИИ не заменит юриста, потому что ответственность за достоверность сведений и норм в судебных документах лежит исключительно на вас. Нейросеть может ошибиться не только в судебной практике, но и в нормативном обосновании, а также «нагаллюцинировать» несуществующие факты - штрафовать будут вас. Поэтому не стоит готовить судебные документы самостоятельно через ИИ и подавать их в суд без проверки живым юристом
Документ: Постановление АС Западно-Сибирского округа от 14.05.2026 по делу N А27-7831/2025
А что вы думаете? Стоило ли идти в кассацию из-за 55 тысяч? Как относитесь к использованию ИИ для подготовки юридических документов? Делитесь мнением в комментариях 👇
Представлен открытый учебный проект 100 free open-source github repos everyone needs - 100 бесплатных репозиториев для решения любых задач. У них полностью открытый код и актуальные инструменты:
ИИ-агенты и скиллы для них;
Локальные альтернативы SaaS-сервисам;
Фреймворки и плагины для любых задач;
Топовые тулзы для разработчиков;
Курсы и справочники по всевозможным темам;
Дизайн и фронтенд-разработка;
Извлечение данных и аналитика;
Безопасность и приватность в сети;
Сборник инструментов для подготовки контента.
При этом у каждого проекта своя лицензия, а авторы подробно разбирают их назначение и способы применения.
Временные ссылки: как мы убираем секреты из рабочих чатов
В рабочих чатах постоянно всплывает чувствительная информация: API-ключи, временные пароли, доступы к тестовым аккаунтам, документы, архивы, конфиги. Обычно это выглядит безобидно: «скинь токен», «вот пароль от стенда», «держи файл». Но у такого подхода есть проблема — всё это остаётся в истории переписки.
Если аккаунт сотрудника скомпрометирован, злоумышленник получает не только новые сообщения, но и весь архив: старые пароли, ключи, ссылки, файлы и переписки по проектам. Даже если часть данных уже неактуальна, быстро проверить это сложно. В итоге приходится срочно чистить чаты, отзывать токены, менять пароли и проверять инфраструктуру.
Идея простая: вместо того чтобы отправлять секрет прямо в чат, сотрудник создаёт короткоживущую ссылку. В ссылке могут быть текстовые данные — например токен, пароль или инструкция — а также файл. Получатель открывает ссылку и забирает данные, а после истечения срока жизни они становятся недоступны и удаляются.
Это не замена полноценным vault-системам и менеджерам секретов. Но сервис хорошо закрывает частый рабочий сценарий: быстро передать чувствительную информацию коллеге, подрядчику или клиенту, не оставляя её навсегда в мессенджере.
Как это выглядит в интерфейсе
В DTIS появился отдельный пункт меню «Временные ссылки». Он ведёт на страницу управления временными ссылками.
На этой странице пользователь может сразу создать новую ссылку: указать название, выбрать режим доступа, добавить секретные данные, задать срок жизни и при необходимости прикрепить файл. После создания появляется ссылка, которую можно скопировать и отправить получателю.
Ниже отображается список ранее созданных актуальных ссылок. Для удобства есть поиск по названию. У каждой ссылки можно посмотреть срок действия, скопировать её или вручную отозвать, если она была отправлена не туда или больше не нужна.
Просроченные ссылки в списке не хранятся. Пользователь видит только то, что ещё действительно актуально.
Режимы доступа
Мы оставили два основных сценария.
Первый — только пользователи DTIS. Это режим по умолчанию. Он подходит для внутренней передачи данных между сотрудниками, когда ссылку может открыть только авторизованный пользователь.
Второй — доступ для всех, у кого есть ссылка. Он нужен для ситуаций, когда данные нужно передать внешнему пользователю: клиенту, подрядчику или партнёру.
Если у пользователя нет доступа, он видит ошибку. Если ссылка уже просрочена или была отозвана, данные по ней недоступны.
Почему сделали внутри, а не взяли внешний сервис
Для таких данных важно контролировать весь контур: где они хранятся, кто имеет доступ, как удаляются и какие правила применяются. Внешние сервисы могут быть удобными, но для передачи рабочих секретов это лишний риск: зависимость от сторонней инфраструктуры, возможные утечки, изменения условий и отсутствие нужной интеграции с нашей моделью доступа.
Готовыми внешними сервисами для такой задачи мы пользоваться не хотели. При этом подходящего self-hosted решения, которое можно было бы быстро и аккуратно встроить в DTIS, авторизацию и внутренние процессы, мы для себя не нашли. Поэтому решили сделать небольшой собственный инструмент под наши сценарии.
Что получилось
Теперь вместо сообщения «вот пароль от стенда» в рабочем чате появляется временная ссылка. Она живёт ограниченное время, может быть доступна только авторизованным сотрудникам и при необходимости отзывается вручную.
Сервис небольшой, но он меняет привычку: секреты больше не должны жить в мессенджерах. Чат остаётся местом для общения, а чувствительные данные передаются через контролируемый механизм с понятным сроком жизни.
Подробнее о том, как и почему мы решили сделать собственную CRM-систему, в рамках которой работает наш сервис временных ссылок, можно прочитать в статье нашего CTO.
В роадмапе есть нормальная последовательность: сначала окружение и база, потом идиомы, ООП, типы, стандартная библиотека, асинхронность, тестирование, внутренности CPython, web, базы данных, AI-направление, продакшн и архитектура.
На каждом этапе есть задачи, чеклисты, примеры кода и бесплатные ресурсы. То есть это не мотивационная простыня, а маршрут, по которому реально можно идти несколько месяцев и видеть прогресс.
«Парадокс мотивации. Почему премии, оценки и похвала не работают и чем их заменить» Альфи Кон
Мне повезло – я читал эту книгу, уже покрытый шрамами от разработки и внедрения систем мотивации. Иначе мог автору поверить и натворить делов. Если вы – новичок в мотивации людей, применяйте знания из книги с большой осторожностью.
Если кратко, то книга топит за оклады. И против бонусов, премий, сделки, KPI и прочих оценок, которые только демотивируют. Автор приводит результаты огромного множества исследований – никогда столько ссылок не видел в относительно современной нон-фикшн книге.
Но есть подвох, весьма неприятный. Все исследования – не автора. Точнее так: все исследования мотивации, которые про бизнес – не автора. Потому что автор не работал в бизнесе.
Автор работал в школьном образовании, и там парадокс мотивации – никакой не парадокс, а уже давно и широко шагающая практика. Есть огромная область знаний и исследований – формирующее оценивание. Я в эту тему когда-то очень сильно погрузился, волею судеб. Некоторые аспекты формирующего оценивания проникли даже в наши родные образовательные стандарты – это к слову о широте распространения подхода.
Как, зачем и почему автор перешёл на мотивацию в бизнесе – не знаю, но книжку-таки написал, и она очень хорошо разошлась. Пользы в ней много, если понимать ограничения, которые я описал.
Если кратко сформулировать пользу: некоторым сотрудникам некоторых профессий в некоторых компаниях лучше платить оклад безо всяких KPI.
В этом автор прав. От себя добавлю: нужно понимать принципиальную разницу оклада и сделки (в любой её форме – процент, KPI, бонус, грейды и т.д.). Разница очень простая.
Оклад – это вы купили время сотрудника. Сделка – это вы купили результат работы сотрудника.
Когда вы купили время (оклад) – никто не гарантирует результат. В этом вся соль. Купленным временем нужно эффективно управлять. Кто это будет, может и должен делать? Здесь тоже важная развилка.
Если сотрудник – как говорится, «самоходящий», сам знает что делать, сидит работает, старается, творческий, с энтузиазмом – временем он будет управлять сам. От начальника – приоритеты и ограничения. Собственно, автор книги всех людей видит именно такими сотрудниками.
Если сотрудник – ну, скажем так, не такой – его временем придётся управлять начальнику. Ставить задачи, контролировать исполнение, ограничивать интернет и соц.сети, следить за временем в курилке и у кофемашины, разрабатывать процессы, инструкции, автоматизировать работу и т.д. Таких людей, по мнению автора, почти нет.
Ну а на сделке временем управлять не надо – оно принадлежит сотруднику. Как хочет, так и распоряжается. Мы платим за результат его «распоряжения» временем и ресурсами.
Резюмируя, скажу: автор прав насчёт окладов, если решён вопрос управления временем. Или сотрудник сам будет управлять, или начальник с секундомером.
