Со стороны программирование звучит как медитативное занятие. Сидишь себе за компом целый день, слушаешь музыку, пьешь вкусный кофе. У все меня примерно так и происходит. Сначала я не спеша пытаюсь выстроить в голове то, что требуется сделать. Именно «не спеша». И не потому что я такой опытный и мудрый, а потому что быстро я просто не умею.
У меня не получается сразу продумать все корнер кейсы, которые сильно могут повлиять на архитектуру. Я не могу быстро достать из памяти нужный паттерн, чтобы на лайвкодинге блеснуть своими знаниями. Поэтому сначала я медленно вчитываюсь в описание задачи, общаюсь с ПМом или коллегами, кто больше знает в этой доменной области, чтобы в обсуждении мой мозг начал работать в правильном направлении.
Все это звучит конечно логично, но явно 10x инженером так не стать. Да и будем честны, даже 2x тоже. В IT, где эффективность, это не один из критериев оценки сотрудника, а недостижимая цель, к которой стремятся все. Мой стиль работы — это проблема. Но благодаря появлению AI, эта проблема стала решена.
В этой части мы рассмотрим некоторые вырезанные, не снятые и альтернативные сцены из производственных раскадровок, основанных на варианте сценария от июня 1978 года. Они были нарисованы до того, как часть сцен была переписана. Эта статья должна показать читателю невиданный мир Чужого, идеи и направления, в которых фильм собирался и мог пойти на ранних этапах производства.
Под рациональностью участников рынков понимается, что они принимают решения осознанно и стремятся получить максимальную доходность при приемлемом для них уровне риска.
Рациональный участник рынка:
анализирует доступную информацию;
оценивает возможную доходность и риск;
выбирает наиболее выгодный для себя вариант;
не принимает решения исключительно под влиянием эмоций;
пересматривает решение при появлении новой существенной информации.
Например, если компания публикует отчёт об ухудшении финансового положения, рациональный инвестор заново оценит перспективы её акций и, возможно, продаст их. Он не станет сохранять бумаги лишь из-за привязанности к компании или надежды на рост, не подкреплённой объективными данными.
При этом рациональность не означает, что инвесторы всегда принимают правильные решения или способны точно предсказывать будущее. Они могут ошибаться из-за недостатка информации и неопределённости. Важно, чтобы их решения были логичными, соответствовали имеющимся данным, собственным целям и отношению к риску.
В экономической теории такое поведение обычно описывается с помощью теории ожидаемой полезности фон Неймана - Моргенштерна. Согласно ей, инвестор выбирает между рискованными вариантами, учитывая не только возможную доходность, но и субъективную ценность каждого результата.
Создатели Теории игр Моргенштерн и Нейман
Например, инвестор выбирает между:
гарантированными 100 000 рублей;
вероятностью 50 % получить 250 000 рублей и вероятностью 50 % не получить ничего.
Он сопоставляет не только суммы, но и полезность возможных исходов с учётом собственного отношения к риску.
Такой выбор считается рациональным, если предпочтения инвестора соответствуют определённым аксиомам:
полнота - инвестор способен сравнить любые два варианта;
транзитивность - если вариант A предпочтительнее B, а B предпочтительнее C, то A предпочтительнее C;
непрерывность - между вариантами нет необъяснимых скачков предпочтений;
независимость - добавление одинакового вероятностного компонента к двум вариантам не меняет предпочтение между ними.
Если эти аксиомы выполняются, поведение человека можно представить как максимизацию ожидаемой полезности.
Важно различать два уровня анализа. Рациональность фон Неймана - Моргенштерна описывает отдельного инвестора, принимающего решения в условиях риска. Гипотеза эффективного рынка описывает итоговое поведение рынка и механизм формирования цен. При этом она не требует, чтобы абсолютно все участники соблюдали аксиомы рациональности: достаточно, чтобы иррациональные ошибки взаимно компенсировались или исправлялись рациональными арбитражёрами.
Manticore Search 29.9.0: chunked auto-embeddings и mmap-доступ к columnar-атрибутам
Manticore Search 29.9.0 добавляет chunked и multi-vector auto-embeddings, ограничение входа для embedding-моделей, UTF-8 идентификаторы, mmap-доступ к columnar-атрибутам по умолчанию, а также исправления для hybrid search, KNN, bulk ingestion и группировки.
Создание молекулярно-кинетической теории во второй половине 19-го века было связано с поиском объяснения природы теплоты, поскольку развитие термодинамики привело к отказу от теории теплорода. Это обстоятельство хорошо подчеркивает название статьи Рудольфа Клаузиуса: '0 роде движения, которое мы называем теплотой' (1857 г.).
Тепловой контакт между горячим и холодным телом приводит к передаче теплоты от горячего тела к холодному и достижению теплового равновесия; при этом передача теплоты от холодного тела к горячему запрещена вторым законом термодинамики. Такое поведение должно объясняться на основе молекулярно-кинетической теории, но в ее основе лежат обратимые во времени законы физики; это обстоятельство потребовало нетривиальных решений.
Людвиг Больцман (1844 -1906) был одним из основоположников теории, и поэтому интересно проследить трансформацию его взглядов. В самом начале Больцман был уверен в возможности строгого обоснования существования необратимых процессов на базе молекулярно-кинетической теории. При появлении парадоксов он изменил свою позицию и перешел к статистическому обоснованию второго закона. На заключительном этапе Больцман выдвинул космологическую флуктуационную гипотезу, которая показывает, что при обсуждении статистической механики нельзя исключить переход от существования флуктуаций к миру как флуктуации.
Токены (tokens) API часто расцениваются как незначительные детали реализации.
Пользователь входит в систему, сервер создает токен, браузер сохраняет его и включает в каждый защищенный запрос (protected request). На верхнем уровне процесс выглядит просто.
Последствия для безопасности отнюдь не просты.
В этой статье рассматривается полный жизненный цикл токена API, от выпуска (issuance) до истечения срока действия (expiration) или принудительного отзыва (revocation).
Какой биллинг нужен стартапу для первого платного запуска? Подключить приём платежей — мало, но и полноценная система расчётов на старте не нужна. Разбираю, что должно войти в MVP биллинга, а какие сценарии можно оставить на потом.
У нас несколько фоновых агентов публикуют контент на разных площадках по расписанию — Дзен, VC, TenChat, Хабр. Если основной движок не справился за 20 минут, включается запасной. Чтобы не сидеть в логах руками и не пропускать пустые слоты, поверх этого стоит раннер: он спрашивает у каждой площадки факт публикации, сверяет с базой и, если слот не закрылся, шлёт алерт с просьбой перезапустить вручную.
Результат был хорош, но далеко не идеален - обучение занимало много времени, качество незначительно росло, хотя размеченных данных стало заметно больше. Да и ощущение, что решение должно быть красивее, но я его не вижу в силу отсуствия экспертизы сохранялось
Поэтому спустя полгода после релиза первой версии я дал исходный контекст задачи кодагенту. Без ссылки на код проекта и без подсказок стека и каких бы то ни было подходов к реализации - только цель и ограничения, а именно:
использовать только аудиоданные
использовать только CPU
уверенно меньше 20% ложных не\срабатываний для обеих классификаций - exclude_disliked and include_liked
Над решением успели поработать opus 4.8 (основная архитектура решения), fable 5 (ревью архитектуры; да-да, надо было наоборот, но архитектура была собрана до выхода fable) glm-5.2 (прикладные планы реализации задач) и 5.3 (прикладные планы+доведение пайплайна до рабочего состояния)
По архитектуре железный друг:
предложил тот же подход, что я использовал, но выкинул polars, вместо которого решил использовать duckdb. Когда он понял, что его не получится нормально развернуть на nfs, мы сошлись на хранении фич файлами parquet, а duckdb-базу билдить локально при запуске обучения - уж очень удобно ее использовать
отделил пайплайны извлечения фич от обучения. Изменение довольно капитанское, но так реально гораздо быстрее проводить эксперименты и улучшать модель. Появляются четкие артефакты с сырыми фичами, которые можно анализировать сами по себе
для процессинга агент сам предложил взять ту же essentia, но вместо навеса моделей на нее - предложил взять panns
примитивы обучения взял те же: mean k-NN distance+GMM log-likelihood+IsotonicRegression. Предложил обучать по одной single-class модели на include_liked и exclude_disliked, но делать это за один проход. На метрику какой из моделей смотреть - решаем на уровне подписки
Когда мы собрали решение - ничего не заработало. Качество детекции было едва выше случайного. И вот тут реально LLM оказались суперполезны, т.к. в анализе данных они понимают сильно больше меня и компенсировали пробелы в экспертизе:
модель подкинула критерий, который позволяет выделить фичи наиболее различные в датасетах. Не просто PCA, а выбрать те фичи, за счет которых мы различаем liked/disliked. 4k фич сжались до 64х - это значительно повысило точность ML-моделей за счет размерности
но даже после этого exclude_disliked продолжала сильно страдать false positive'ами - эксклюдила что нужно и что не нужно. И тут агент предложил балансировать вывод этой модели выводом include_liked классификатора. Т.е. если exclude_liked считает, что трек надо выкинуть, то прежде чем вернуть это решение мы смотрим на include_liked скор этого трека. Если он высокий - трек остается. С таким подходом качество модели стало выше, мой исходный подход показывал когда-либо
В итоге получилось решение, которое работает проще и быстрее, при этом качество его выше, чем было у меня в первой итерации. Время извлечения фич на датасете из 2k треков сократилось с нескольких дней до нескольких часов, а модель стала весить на порядки меньше
Единственной сохранившейся проблемой остается довольно высокое потребление памяти при процессинге - каждый воркер, извлекающий фичи из аудио, потребляет 1.5-2ГБ. Но размен памяти на процессинг на CPU - вполне приемлем при локальном использовании
Необычная статья о том, как с научной и эзотерической точек зрения, без противоречий можно объяснить поведение человека.
Эти знания позволяет по‑новому взглянуть на работу человеческого мышления и объяснят поведение человека в любых!! жизненных ситуациях.
Из статьи читатель узнает о научном исследовании, а также найдёт подтверждение модели в реальных случаях авиационных катастроф и в обычной жизни. Представленная концепция позволяет лучше понять собственные поступки и действия окружающих людей.
На основе анализа большого экспертного материала, полученного в ходе расследования авиационных происшествий, разработана принципиально новая концепция психической деятельности человека и сформулированы законы психической деятельности, нашедшие широкое применение в практике расследования авиакатастроф.
Основа работы — анализ поведения лëтных экипажей в особых ситуациях полёта. Тот материал, который был исследован — уникален. Его нельзя получить ни в одном эксперименте. Это реальная жизненная ситуация, в которой человек действует на грани смертельной опасности.
До недавнего времени, до того времени, пока не обратились к новой концепции, не стали её использовать, в практике в большинстве случаев не удавалось объяснить поведение пилотов с позиции классической психологии.
Даже с позиции здравого смысла, они себя ведут крайне противоречиво. Так, например, часто наблюдали, что один и тот же человек — пилот, командир корабля — ведёт себя как два или три совершенно разных человека, управляющие самолётом. Один сразу сменяет другого. Очень странно, как будто совершенно разные люди.
Anthropic раскрыла детали масштабной мошеннической сети (проект получил кодовое имя GTG-15001) из дейтинг‑приложений, построенной на базе нескольких ИИ-систем. Студия из Китая развернула более 20 мобильных приложений для знакомств, где 75% всех «мэтчей» создавались не людьми, а ИИ‑персонажами, работающими на базе Claude.
Через несколько дней после смерти Стива Джобса, о которой говорил весь мир, тихо умер человек, чей код лежит в основе большей части устройств, на которых этот самый мир об этом читал.
Это пятая статья цикла “Код как борьба: Кратчайшая история IT”. И сегодня у нас сдвоенная история - два человека настолько тесно переплетены в одной истории, что разделять их было бы просто нечестно по отношению к тому, что они сделали вместе.
Привет! Я Сергей Житинский, основатель Git in Sky. Мы занимаемся эксплуатацией и технической поддержкой ИТ-инфраструктуры. Agent-Ops — проект открытой отраслевой методологии совместной работы инженеров и ИИ-агентов. Мы начали разрабатывать его весной этого года и сейчас выложили первый кандидат версии 0.4.0 на GitHub и GitVerse. Одновременно, на конференции IT Elements 2026 мы договорились о совместной работе с инженерами из 2х других компаний, они стали у нас maintainers. Поэтому сегодня Agent-Ops - это не инициатива только одной компании, а совместной работа нескольких. Надеюсь, количество единомышленников будет увеличиваться. Приглашаем контрибуторов развивать этот проект вместе с нами.
Я ожидаю масштабных изменений в ИТ-отрасли, поэтому решил лично заняться этой работой внутри Git in Sky, а наши подходы и предложения вынести на обсуждение профессионального сообщества. Меняется сама организация работы: кто исследует проблему, на каком основании предлагает решение, кто разрешает изменение и кто отвечает, если оно привело к аварии.
Ниже расскажу, как мы предлагаем устроить этот процесс и что вошло в редакцию 0.4.0. Её текущий статус — публичный нормативный кандидат: проект правил для обсуждения и дальнейшего развития.
Я ожидаю масштабных изменений в ИТ-отрасли, поэтому решил лично заняться этой работой внутри Git in Sky, а наши подходы и предложения вынести на обсуждение профессионального сообщества. Меняется сама организация работы: кто исследует проблему, на каком основании предлагает решение, кто разрешает изменение и кто отвечает, если оно привело к аварии.
Ниже расскажу, как мы предлагаем устроить этот процесс и что вошло в редакцию 0.4.0. Её текущий статус — публичный нормативный кандидат: проект правил для обсуждения и дальнейшего развития.
Ко Дню программиста наша ИТ-команда 2ГИС в коллаборации с уличным художником Иваном Серым и Музеем криптографии установили в Москве интерактивный арт-объект в виде клавиши Pause/Break. Найти объект можно на территории музея с 11 сентября.
Этот проект мы посвятили вкладу в реальный мир всех причастных к IT. Разработчики пишут код в цифровой среде, но результат вашей работы проявляется физически: в технологиях и сервисах, которые работают каждый день. Поэтому и объект — физический. А сама клавиша Pause/Break — единственная, которая буквально предлагает остановиться: нажать на кнопку — значит на минуту выйти из рабочего контекста и переключиться. Это и есть поздравление с наступающим профессиональным праздником!
Мы объехали офисы партнёров, встретились с коллегами и обсудили самое актуальное: AI в разработке, продуктовые циклы, управление изменениями и не только. На практических сессиях разбирали реальные кейсы, а на дискуссиях искали ответы на сложные вопросы.
Собрали цифры нашего фестиваля, чтобы показать масштаб:
5 площадок
5 компаний организаторов
Более 600 участников
10 докладов от экспертов отрасли
3 активности — мастермайнд, круглый стол и практикум с живыми кейсами
12 экспертов и спикеров
5 кейсов решено на практикуме по инженерной оптимизации.
Отдельное спасибо организаторам — вы сделали эту неделю незабываемой. Увидимся в следующем году!
В эпоху AI код становится дешевле, а качественное инженерное решение — ценнее.
Поэтому важнее не просто уметь быстро писать код, а уметь спроектировать систему так, чтобы человек и агент одинаково понимали: что нужно изменить, зачем, где проходят границы и каким должен быть результат.
Viaduct помогает превратить архитектурное проектирование в структурированный, проверяемый и доступный AI-агентам контекст — от модели системы до Change Set, по которому можно безопасно реализовать изменение.
Медиаплан обычно собирает внутренняя команда или подрядчик, а отвечает за него руководитель маркетинга. И тут есть риск: на согласование приходит красивая таблица с площадками, бюджетами, показами, кликами и конверсиями, а в результате прогноз может не совпасть с результатом.
Например, охват и частота по средним значениям площадки, CTR и конверсии на основе прошлых размещений. Поэтому задача маркетолога — разобраться, откуда взялась каждая цифра, насколько ей можно доверять и что команда будет делать, если план не совпадает с реальностью. Иначе план может сильно разойтись с фактом, и тогда отвечать за потраченный бюджет придётся маркетологу.
В статье вместе с Ксенией Гавриленко, Performance marketing Lead Яндекс Рекламы и приглашённым преподавателем ВШЭ, рассказали, какие показатели в медиаплане стоит поставить под сомнение, что проверить до запуска и какие вопросы задать команде, чтобы результат приятно удивлял.
Почему изображения атомных орбиталей напоминают цветы, бабочек и причудливые узоры — и что на самом деле стоит за этой красотой? Разбираемся, почему привычная планетарная модель атома не описывает современное представление об электроне, как волновая функция и уравнение Шрёдингера привели к понятию атомной орбитали и откуда берутся её характерные формы.
Unity выпустила официальный плагин для сторонних AI‑агентов, с помощью которого Codex. Claude и Grok могут работать с проектами на Unity. Плагин работает с Unity 6 и подключается непосредственно к AI‑агенту.
Когда меня однажды спросили, что такое инференс и как выглядит локальное развёртывание модели, я ответил правильно, но слишком общо. Через несколько дней пришлось пройти этот путь целиком: поднять две LLM на NVIDIA DGX Spark, отдельную ASR-модель на AMD GPU и подключить всё к мультиагентной платформе. В статье — инженерный разбор того, почему файлы модели ещё не сервис, как длинный контекст конкурирует с KV-кэшем и параллелизмом, почему tokens/sec не описывают пользовательскую задержку и зачем иногда откатывать более быструю модель из-за качества.
