Как стать автором

Есть странный парадокс последних лет.

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

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

И теперь все встретились посередине.

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

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

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

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

Я называю набор практик для решения этой проблемы Project Hygiene — гигиена проекта. Это не отдельный промпт и не ещё один способ «правильно общаться с нейросетью». Это способ организовать проектную память, проверки и передачу состояния так, чтобы длинная работа с ИИ-инструментами не расползалась после нескольких сессий.

Практическое сравнение Telegram‑VPN в 2026 году: VolnaLink, WOW VPN, Sigma Network, MORI VPN, HVPN, xtls_vless_vpn_bot, EchelonX, GenVPN, Lako VPN и Fly VPN.

За последний год я перепробовал около 15 VPN‑сервисов и решил собрать обзор не с позиции лабораторных тестов, а с позиции обычного пользователя: можно ли поставить VPN себе, родителям или друзьям, чтобы он просто работал.

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

Привет, Habr!

Рутинные процессы после встреч, онбординг клиентов и сотрудников, подготовка follow‑up писем — это те задачи, которые редко выглядят сложными по отдельности, но в сумме создают постоянную операционную нагрузку и «расфокус» в работе команд.

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

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

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

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

Мы живём во времена высоких технологий, ну, по крайней мере, мы так считаем. Но проблема в том, что эти технологии для большинства это так называемые «черные ящики». Спроси у друга, знает ли он, как устроена микроволновка? Скорее всего нет. И это проблема. Но сейчас не о микроволновках, я хочу сфокусировать ваше внимание на искусственном интеллекте. Я бы назвал это вершиной всех «чёрных ящиков», потому что его влияние в современном мире колоссально. К сожалению, авторы выпустили в мир монстра и до сих пор не поняли, насколько он опасен. Мы разберём механику работы ИИ (а точнее проблемы) и начнём выстраивать новый тип модели искуственного интеллекта с помощью выведенных мной систем: ОСНиУ (онтология согласовательной направленности и удержания) и РОА (рефлексивная онтологическая архитектура, второй порядок).

«Бизнесу это невыгодно!», «Мы не будем вкладывать в это ресурсы», «Зачем, оно и так отлично работает» — какие аргументы можно привести против всех этих высказываний?

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

Можно. Но есть моменты на которые важно обратить внимание и донести бизнесу.

Всех приветствую, меня зовут Владислав, я специализируюсь на мобильной безопасности Android‑приложений. На написание данной статьи меня «вдохновила» ситуация, с которой я столкнулся пару недель назад. В целях развития своих навыков и знаний в области ИБ — я активно изучаю чужие приложения с целью поиска уязвимостей (в рамках скоупа и закона, естественно). В связи с этим, хотел бы поразмыслить над темой оценки уязвимостей.

Уже не первый раз сталкиваюсь в проектах на Qt QML с проблемой управления диалогами и всплывающими окнами.

QML — декларативный язык и это здорово! Мы описываем, что хотим видеть на экране, и, если всё сделали правильно, при запуске программы получаем желаемый результат.

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

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

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

Другой вариант, который тоже часто встречается — это обёртка диалога в Component и его непосредственное создание в нужный момент. С точки зрения потребления памяти это уже лучше, но проблему лишнего кода это не решает. Зачастую из-за подготовки такого диалога кода может оказаться даже больше. К тому же нужно не забывать вызывать destroy() для всех динамически созданных объектов, когда они больше не нужны.

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

Обсудим тему и важность стакана в торговле (или orderbook, если так удобнее). В трейдинге это база — то, что необходимо знать в самом начале пути (это как изучать виды финансовых инструментов — не все пригодятся и не все будете использовать, но их знание необходимо для понимания происходящего). Неужели стакан — грааль?

До недавнего времени я спокойно пользовался Screenpresso. Меня всё устраивало: нажал Print Screen, выделил область, скриншот сохранился в папку. Никаких лишних кликов, редакторов и тормозов. Но в один день сервис просто перестал открываться – блокировка в России. Искать зеркала, настраивать прокси ради утилиты для скриншотов – такое себе. Я начал пробовать аналоги.

У меня в инфраструктуре мониторинг уже несколько лет стоит на Telegram‑ботах. Работало, работало — и перестало. Почему? Да кто ж его знает. Никогда такого не было, и вот опять. Боты молчат, сообщения приходят с задержкой или не приходят вообще, а ты сидишь и думаешь, что именно сломалось — связь или всё остальное. Мониторинг, который молчит именно тогда, когда что‑то сломалось — это, строго говоря, не мониторинг.

Начал думать, как это фиксить.

Сейчас в тренде - внедрение ИИ вообще в любой проект, в любой чайник или пылесос. Я давно ковыряюсь в проектировании и Revit, и меня стабильно бесило одно и то же: куча рутины, одинаковых действий, которые можно было бы спокойно автоматизировать. Глядя на то, какие чудеса сейчас творят языковые и диффузионные LLM, генерируя целые детализированные миры, очень хочется сделать тоже самое в строительной сфере.

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

Я решил собрать свой вариант и назвал его AiRevit. Это не чатик с LLM поверх Revit. Тут вообще не предполагается использования такой архитектуры, которая бы основывалась на угадывании токена (нам не нужно ничего угадывать, нужно соблюдать строгие строительные правила). Это детерминированный pipeline, где текст сначала превращается в структурированный program_graph, потом в layout_solution, а уже потом в реальные элементы Revit через Dynamo и Python-скрипты. В репозитории это разложено на Node 3, Node 4 и Node 5, чтобы не было каши и чтобы каждый кусок отвечал за свою часть работы. (https://github.com/Rearks/AiRevit)

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

Интуитивно это воспринимается очень просто: есть «ничего», и в этом «ничего» вдруг возникают объекты. Это звучит как нарушение здравого смысла, и именно поэтому такая формулировка так популярна.

Проблема в том, что она объединяет разные физические эффекты в одну картину. Чтобы разобраться, нужно аккуратно разделить, о чём именно идёт речь, и перейти от образа «частиц в пустоте» к более точному описанию через поля.

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

Я часто записываю себе аудиозаметки. Иду в лес рядом с домом, где интернет ловит примерно никак, балдею от природы, деревьев... И вдруг идея! Достаю телефон, диктую, а уже дома разбираю бэклог.

Для расшифровки обычно прогоняю всё через «Буквицу». Отличный, кстати, сервис — писал про неё на VC год назад. Точность на русском отличная, поддерживает кучу языков, недавно прикрутили диаризацию.

Но и «Буквица» не идеальна.

Hello Neighbor — культовая компьютерная игра, в которой главный персонаж пытается проникнуть в подвал к своему соседу, который явно что-то скрывает. В соседском доме нас ждут десятки разнообразных головоломок, без решения которых цели, увы, не достигнуть. А сам Сосед — умный ИИ, который учится на действиях игрока, выстраивая оборону своего дома — капканы, вёдра с водой на дверях и камеры видеонаблюдения.

Взять интервью у человека, работающего над нашей любимой игрой, стало огромным шагом для нас как для поклонников франшизы Hello Neighbor. Ну, не будем тянуть — встречайте, Александр Чураков, Lead Game Designer Hello Neighbor 3.

Каждая невырожденная матрица — это не просто набор чисел. Геометрически это «скелет» n‑мерного тела (симплекса), зафиксированный в пространстве. Обычно мы описываем матрицы через детерминант или спектр собственных чисел, но эти характеристики часто «слепнут», когда нужно описать внутреннюю форму объекта или когда мы сталкиваемся с экстремально плохой обусловленностью. В этой статье я представлю метод построения метрического дескриптора («паспорта») матрицы. Векторы‑строки матрицы интерпретируются как вершины симплекса, далее вписываем симплекс в гиперсферу и извлекаем набор инвариантов, которые не зависят от вращения, перестановки строк или выбора базовой вершины.

Глобальная гонка за лидерство в сфере ИИ продолжается. У её участников разные подходы, тактики и стратегии. Цели и философия -- тоже.

В интернете полно картинок «как устроен Double Elimination» для 8 участников. Никто не пишет, как этот алгоритм работает на 13, 47 или 100. Разобрал byes, фантомы id=−1 и трюк с reverse() на drop-ins, который чинит повторные встречи в Loser Bracket. ~150 строк TypeScript, 4 схемы, тесты от N=2 до 100.

Моржовый оператор — это :=
Его официальное название — assignment expression (выражение присваивания).

👉 Он позволяет присвоить значение переменной прямо внутри выражения.

Простой пример: