Все потоки

В сентябре 2026-го по миру разлетелись заголовки о том, что ученые смогли оцифровать мозг живого существа — мушки дрозофилы. Карту ее «мозга» выложили в общий доступ, и энтузиасты очень быстро превратили ее в игрушку: научили играть в Doom, Minecraft, собирать кубик Рубика и всячески издеваться и заставлять работать. От экспериментов с мухой не удержались и в MWS, о чем расскажу ниже.

Явление бесчисленных эксплуатаций цифровой мухи именовали флайслопом (FlySlop). Но проблема не в этом — стараниями журналистов многие люди решили, что мы действительно научились полностью переносить сознание в компьютер, и новая серия «Черного зеркала» уже не за горами. На самом деле не все так просто: ученым удалось только скопировать один из уровней работы мозга — карту нервной системы с нейронами и синаптическими соединениями. Но до полной функции сознания им еще очень и очень далеко.

Попробуем разобраться, на что действительно способна цифромуха, чего смогли добиться исследователи и случился ли прорыв в нейробиологии…

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

Чтобы техноересь не попала в прод, мы отлавливаем её в тестовой среде. И сегодня я расскажу вам, как собрать песочницу для проведения ритуалов очищения пилотирования РЕД АДМ Промышленной редакции.

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

Когда мы обсуждаем агентов для программирования, разговор быстро сводится к моделям. Какая модель Claude лучше пишет код, а какая версия GPT увереннее чинит ошибки, как Gemini работает с большим репозиторием. Но между моделью и рабочим деревом Git находится ещё один слой, от которого зависит, что агент вообще сможет сделать.

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

Интересный проект, который изменил традиционное устройство моделей — Pi. Это терминальный агент, который строит свой harness с нуля, а не надстраивается над готовым. Его автор, Mario Zechner, сознательно ограничил набор встроенных механизмов работы. Вместо попытки заранее предусмотреть все сценарии Pi предлагает основной инструментарий, который можно приспособить под себя. Oh My Pi вырос из этой основы, но выбрал другое направление: собрать больше решений в одном готовом агенте.

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

В 1986 году Брюс Стерлинг публикует антологию «Зеркальные очки»[1], которую нарекают классикой киберпанка, «тем что вам надо о жанре». Вот только среди сияющего неона и глазных имплантов в нем можно было найти и рассказ о чудачествах Гуддини (а это почти сто лет назад как бы, а не в будущем) и реально кафкианскую повесть о том как неживая материя вдруг стала живой и составила конкуренцию мясным людям. Казалось бы — при чем тут это всё, но...

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

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

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

Следующим моим шагом стало собрать вокруг модели рабочую среду. В моем случае такой средой стал OpenCode. Хотя этот агент в первую очередь ассоциируется с разработкой, его можно использовать гораздо шире. По сути, это оболочка, в которой LLM получает доступ к файлам, инструкциям, локальным инструментам, API и MCP-серверам, а затем использует все это для решения задач конкретного пользователя.

Привет, Хабр! Я Арина, аналитик в Selectel. В этой статье я покажу не столько «как установить OpenCode», сколько как организовать вокруг него рабочее пространство, чтобы агент выдавал более стабильный результат и действительно снимал часть рутинной работы.

Привет! Меня зовут Александр Каненков, я backend-разработчик в компании Домклик.

После перевода сервиса со второго Spring Boot на третий (а у кого-то уже и на четвёртый) мы с командой заметили следующую картину: HTTP-запрос журналируется с traceId, цепочка собирается в трейсе, но стоит сработать задаче Quartz — в журналах worker-потока гордо красуется [NoTrace, NoSpan]. Задача исполняется «в никуда» — без единого идентификатора, вне какого-либо трейса, и связать её с запросом, который её запланировал, невозможно.

Давайте разберём по шагам, почему это случилось и как починить так, чтобы работало и с RAM (in-memory), и с JDBC job store.

На днях я писал здесь, как держу сотни Telegram‑ботов в одном процессе Node.js. Статью прочитали почти 6 тысяч человек, и это приятно. Но есть одна вещь, про которую я там промолчал: продукт пока никто не покупает.

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

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

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

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

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

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

Раньше я начинал учить английские слова и постоянно бросал это дело.

Находил новый способ, занимался им какое-то время, а потом появлялись дела, работа, не хватало времени, и я снова всё забрасывал.

Но полтора года назад всё изменилось: с того момента я выучил 623 слова почти не тратя на это время. Без силы воли, дисциплины и изменения привычного образа жизни.

В этой статье расскажу, как учить слова, когда вообще нет времени. И больше никогда это не бросать.

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

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

Разберём это на DMA, владении периферией, состояниях GPIO, прерываниях и unsafe — без попытки доказать, что Rust должен заменить Си.

Представим распределённую инфраструктуру в разных регионах. Между площадками есть VPN: он даёт связность и защищает трафик. Каждый час нужно передать бэкап объёмом 50 GB и развернуть его в другом регионе.

Чтобы уложиться в час, нужна стабильная полезная скорость. Но после запуска cronjob оказывается, что передача идёт заметно медленнее: RTT около 30 ms, иногда теряются пакеты, а бэкап не успевает скачаться даже за пару часов. Рассмотрим, что с этим можно сделать из разряда минимум действий, максимум пользы.

Рабочий день закончился. Вы доделываете свои дела, и тут руководитель просит вас подготовить сложный отчёт: «Срочно, никто кроме тебя не сделает. Успеешь за час?».
Вы уже не раз выручали, и это стало нормой.

Разбираем кейс о психологической безопасности и трудных диалогах.

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

Но долго прятать голову в песок не получилось. Вскоре я узнал, что эти символы обозначают удивительную связь между, казалось бы, несовместимыми мирами гравитации и квантовой механики. А ещё более странным образом это «соответствие анти‑де‑ситтеровского пространства и конформной теории поля» предполагает, что гравитация устраняет различие между объёмом и площадью. Более общая идея получила название голографического принципа, и теперь мне кажется, что это самое глубокое предположение в теоретической физике за последние 30 лет.

Физики‑теоретики склонны голосовать ногами, и AdS/CFT вызвало настоящий массовый забег. Три основополагающие статьи по этой теме, опубликованные в конце 1990-х годов, получили десятки тысяч цитирований и с огромным отрывом стали самыми цитируемыми работами по теоретической физике цифровой эпохи. В моих разговорах с физиками, изучающими голографию, они часто казались искренне ошеломлёнными и прибегали к словам вроде «волшебство» и «чудо», чтобы её описать. И, конечно, не помешало и то, что голография привела к практически общепринятому ответу на самую знаменитую загадку физики: вопреки тому, что утверждал Стивен Хокинг, чёрные дыры не являются тюрьмами, из которых ничто не может выбраться.

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

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

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

Эта статья о том, как статистический тест может показать различие там, где его нет, и как такую поломку отловить. Языковые модели тут ни при чём: такая же поломка случается и в A/B-тесте, в проверке после квантизации и в регрессионном тесте, который сравнивает распределение времени ответа до и после релиза.

Привет!

Заверните обычный File в структуру из одного поля и пробросьте чтение внутрь. Пара строк, логика не поменялась. А теперь скопируйте через io::copy файл на 64 мегабайта: голый File справлялся за два системных вызова, обёртка сделает больше шестнадцати тысяч.

Ошибки в коде нет, вы просто выпали из специализации, которой в стабильном Rust официально не существует. Зато в стандартной библиотеке на ней висит больше сотни функций, и такая фича там не одна: даже NonNull хранит адрес в типе, который на stable объявить нельзя.

Чем глубже копаешь, тем веселее. Та же специализация ускоряет collect и умеет заставить код без единого unsafe читать освобождённую память, а итератор, написанный как обычная функция, превращается в идеальный ассемблер и почему-то отказывается векторизоваться. Материала набралось на четыре-пять статей, это первая, и в ней пять фич: gen-блоки, pattern types, специализация, become и #[loop_match].

Это вторая часть материала про ИИ-агентов в корпоративном контуре для блога ЛАНИТ. В первой речь шла о том, как ограничить агента технически, какие полномочия ему давать, как разделять доверенные и недоверенные источники, что логировать и как тестировать систему до запуска. Здесь – о следующем вопросе. Что происходит, если ограничения все-таки не сработали, агент сделал что-то не то, а последствия уже наступили?

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

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