Все потоки

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

Об этом факте регулярно вспоминают в сообществе разработчиков, но и сейчас он продолжает бить в больную точку. Стив Джобс и Деннис Ритчи ушли в одном и том же месяце одного и того же года, в октябре 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 тысяч? Как относитесь к использованию ИИ для подготовки юридических документов? Делитесь мнением в комментариях 👇

Представлен открытый учебный проект 100 free open-source github repos everyone needs - 100 бесплатных репозиториев для решения любых задач. У них полностью открытый код и актуальные инструменты:

• ИИ-агенты и скиллы для них;

• Локальные альтернативы SaaS-сервисам;

• Фреймворки и плагины для любых задач;

• Топовые тулзы для разработчиков;

• Курсы и справочники по всевозможным темам;

• Дизайн и фронтенд-разработка;

• Извлечение данных и аналитика;

• Безопасность и приватность в сети;

• Сборник инструментов для подготовки контента.

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

Временные ссылки: как мы убираем секреты из рабочих чатов

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

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

Чтобы снизить этот риск, мы сделали внутри DTIS (кастомная CRM-система от Doubletapp) сервис «Временные ссылки».

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

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

Как это выглядит в интерфейсе

В DTIS появился отдельный пункт меню «Временные ссылки». Он ведёт на страницу управления временными ссылками.

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

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

Просроченные ссылки в списке не хранятся. Пользователь видит только то, что ещё действительно актуально.

Режимы доступа

Мы оставили два основных сценария.

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

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

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

Почему сделали внутри, а не взяли внешний сервис

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

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

Что получилось

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

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

Подробнее о том, как и почему мы решили сделать собственную CRM-систему, в рамках которой работает наш сервис временных ссылок, можно прочитать в статье нашего CTO. 

🐍 Python Roadmap 2026: наконец-то актуальная карта изучения Python.

На GitHub выложили большой русскоязычный роадмап по Python на 2026 год - от первых скриптов до уровня Middle+/Senior.

 Маршрут собран под современный Python:

- Python 3.13+

- free-threaded mode без GIL

- JIT

- uv вместо боли с pip/venv/poetry

- ruff, pyright, pytest, hypothesis

- async-first подход

- типизация

- CPython внутри

- web, базы, ML/AI, DevOps и архитектура

В роадмапе есть нормальная последовательность: сначала окружение и база, потом идиомы, ООП, типы, стандартная библиотека, асинхронность, тестирование, внутренности CPython, web, базы данных, AI-направление, продакшн и архитектура.

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

Для джунов хороший роадмап закрыть дыры.

• Github

#junior #python

«Парадокс мотивации. Почему премии, оценки и похвала не работают и чем их заменить» Альфи Кон

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

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

Но есть подвох, весьма неприятный. Все исследования – не автора. Точнее так: все исследования мотивации, которые про бизнес – не автора. Потому что автор не работал в бизнесе.

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

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

Если кратко сформулировать пользу: некоторым сотрудникам некоторых профессий в некоторых компаниях лучше платить оклад безо всяких KPI.

В этом автор прав. От себя добавлю: нужно понимать принципиальную разницу оклада и сделки (в любой её форме – процент, KPI, бонус, грейды и т.д.). Разница очень простая.

Оклад – это вы купили время сотрудника.
Сделка – это вы купили результат работы сотрудника.

Когда вы купили время (оклад) – никто не гарантирует результат. В этом вся соль. Купленным временем нужно эффективно управлять. Кто это будет, может и должен делать? Здесь тоже важная развилка.

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

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

Ну а на сделке временем управлять не надо – оно принадлежит сотруднику. Как хочет, так и распоряжается. Мы платим за результат его «распоряжения» временем и ресурсами.

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

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

Нейросети для работы: 5 курсов Практикума PRO для маркетологов, продактов, дизайнеров и не только

ИИ перестал быть экспериментом для early adopters. Для специалистов из IT и digital работа с нейросетями постепенно становится таким же прикладным навыком, как SQL, Figma, Git или продуктовая аналитика — в зависимости от роли. Команды используют ИИ, чтобы быстрее проверять гипотезы, автоматизировать рутину, ускорять контент-продакшн и сокращать время от идеи до запуска.

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

«Нейросети для работы» — курс для тех, кто хочет внедрить ИИ в ежедневные процессы и сократить время на рутину.

За 2 месяца научитесь:

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

• анализировать большие массивы данных;

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

• автоматизировать повторяющиеся задачи — от шаблонов писем до отчётности.

В программе — работа с ChatGPT, Claude, DeepSeek, Qwen, Mistral AI, Perplexity и другими инструментами.

Подойдёт тем, кто хочет использовать ИИ в работе независимо от профессии.

«Нейросети для маркетинга» — курс про внедрение ИИ в маркетинговые процессы.

За 2 месяца освоите:

• маркетинговые исследования с использованием AI;

• создание контента и креативов;

• фактчекинг результатов нейросетей;

• автоматизацию коммуникаций и настройку ИИ-агентов;

• работу с аналитикой и гипотезами.

В программе — ChatGPT, Claude, Gemini, Midjourney, Veo 3, Sora 2, Kandinsky, n8n, Make.com и другие инструменты.

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

«Нейросети для продакт-менеджера» — курс для продактов, которые хотят использовать ИИ на всех этапах продуктового цикла.

За 1,5 месяца научитесь:

• исследовать рынок и конкурентов;

• формулировать гипотезы и Product Canvas;

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

• готовить PRD и рабочую документацию;

• создавать прототипы и ИИ-воркфлоу;

• проектировать ИИ-агентов (в расширенных тарифах).

В программе — Yandex AI Studio, SpeechKit Playground, Figma, VS Code, Yandex Workflows, VLM-чаты и другие инструменты.

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

«Нейросети для дизайна» — курс для тех, кто работает с визуалом, видео и контентом.

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

• генерацию изображений и видео;

• редактирование и анимацию изображений;

• апскейлинг и работу с фоном;

• создание презентаций, графиков и диаграмм;

• исследование конкурентов и генерацию идей.

В программе — Midjourney, Runway, Stable Diffusion, Recraft AI, Vizcom и KREA AI. Доступ к KREA AI предоставляется бесплатно на время обучения.

«Вайбкодинг» — курс про создание IT-продуктов с помощью нейросетей — без необходимости писать код самостоятельно.

За 8 недель соберете 3+ проекта: лендинги, CRM-системы, сервисы бронирования и телеграм-ботов.

В программе:

• генерация технических спецификаций и кода;

• работа с API и базами данных;

• настройка интеграций и автоматизаций;

• деплой проектов;

• тестирование и рефакторинг кода.

Среди инструментов — Replit, Cursor, GitHub, Vercel, PostgreSQL, n8n, Next.js и Prisma.

Подойдёт тем, кто хочет запускать собственные сервисы без команды разработки.

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

От B2B-продаж к международному IT-продукту: про смену майндсета, антикризисный менеджмент и работу с партнерами по всему миру — Влад Стоянов в подкасте «Привет, касатики»

В гостях у Жени Ившина и Лены Соколовой наш Product Lead рассказал про свой нестандартный карьерный путь и то, как устроена работа с международным партнерским IT-продуктом изнутри.  

Слушай на Яндекс Музыка или Apple Podcasts, чтобы узнать: 

> как 10 лет в продажах привели Влада к желанию влиять на сам продукт, а не продавать его вопреки его недостаткам;

> почему в Garage Eight ценят тех, кто готов сказать «это можно сделать лучше» и не боится это отстаивать;

> чем партнер из Бразилии отличается от партнера из Юго-Восточной Азии и как это влияет на продукт;

> как выстроить стейкхолдер-менеджмент, когда результат виден не сразу, а через несколько кварталов;

> почему тушить пожары своими руками — это путь к выгоранию, а не к системному бизнесу;

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

Мы Garage Eight верим, что результат — это не выпущенная фича, а подтвержденное влияние на бизнес и пользователей. Если откликается наш майндсет, присылай свое CV через форму фаст-трек на сайте.

Жгите токены, не головы

Итак, Y Combinator сформулировал суть AI Native self-improving company.

Первый шаг — это тотальный сбор всех потоков коммуникаций:

- все email, внутренние и внешние

- вся переписка в messengers, включая DM

- все запросы пользователей к системам компании (в UI, БД, API)

Только тогда AI получает полную реальную картину происходящего и может делать полезные выводы.

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

Написание софта, его поддержка теряют смысл, тем более с помощью разработчиков, AI сам, используя мозг, может писать новый софт на каждый важный случай, почти мгновенно тестируя гипотезы и раскатывая то, что сработало. То есть софт — это теперь производная, а не core entity. Core — это мозг, собирающий всю информацию.

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

Давайте представим, как это реально работает:

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

Раньше было: кто-то должен заметить это, сообщить middle management, эту штуку должны приоритизировать, потом запланировать, потом вставить в спринт, потом сделать, потом протестить, потом задеплоить. Это может занять от недель до месяцев.

Теперь AI сам нашел эту проблему в отзывах клиентов, определил, что она значимо влияет на финансовые показатели, и сам ее починил. Все за несколько часов.

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

Сотрудники располагаются в этом случае на краях системы и нужны для тех областей, где AI не может получить данные сам (тот самый human in the loop).

В компании фактически остаются только DRI (с полной ответственностью за результат, а не за кусочек pipeline), я эту роль называл Super Product Owners.

Важный месседж от Y Combinator — Burn Tokens, not Head count. Жгите токены, а не деньги на зарплаты. Я про это говорю в классификации организаций будущего.

Больше по теме тут.