🏎 Гиперкар без единого экрана Hennessey показала Blackbird — машину за 2,5 миллиона долларов, построенную назло всему, что сейчас происходит в автопроме. Ни гибридной установки, ни робота вместо коробки, ни тачскрина. Зато механика с тремя педалями и ключ зажигания. Сердце — 6,2-литровый V8 на 850 л.с., который техасцы разработали вместе с британской Ilmor Engineering, известной по «Формуле-1». Красная зона у него на 9000 об/мин: это самый высокооборотистый атмосферный V8 среди серийных дорожных машин. С места до 96 км/ч — 2,5 секунды, максималка ограничена 354 км/ч. Но добиваться этих цифр придётся руками: никакого лаунч-контроля, никакого полного привода, открытая кулиса шестиступенчатой механики и задний привод. Совсем уж средневековья нет — адаптивная подвеска и ABS на месте. В салоне самое интересное. Ни цифровой панели, ни центрального тачскрина, ни кнопок на руле. Большой аналоговый тахометр, тумблеры и авиационный компас. Единственная уступка современности — камера вместо зеркала заднего вида, этого требует закон. Тираж 71 экземпляр, поставки с 2029 года, и больше двух третей уже распродано. Красота! @droidergram

От лаборатории к умным часам: как измерить кортизол Я всё больше убеждаюсь, что одна из самых интересных областей технологий сегодня находится на стыке инженерии, медицины и ИИ. Пока мы обсуждаем новые модели нейросетей, инженеры пытаются решить другую задачу: научить маленький носимый датчик непрерывно измерять гормон стресса прямо на теле человека. Сегодня уровень кортизола определяют по крови, слюне или моче. Для этого нужно сдать анализ, дождаться результата и получить всего одну цифру - показатель в конкретный момент времени. Но кортизол постоянно меняется. На него влияют сон, тренировки, питание, болезни, время суток, эмоциональная нагрузка и даже конкретная рабочая встреча. Поэтому один лабораторный анализ не показывает всей картины. И инженеры создают аналог непрерывного монитора глюкозы, только для кортизола. Самое интересное здесь не только результат, но и то, как именно они пытаются его получить. Кортизол хотят измерять не через обычный забор крови, а через пот или межклеточную жидкость. Для этого разрабатывают: — микроиглы, которые почти не ощущаются кожей; — электрохимические сенсоры; — аптамеры - молекулы, способные распознавать конкретные вещества; — новые полимерные материалы; — миниатюрные системы, которые могут работать на теле несколько дней подряд. То есть инженерам нужно одновременно решить десятки задач. Как получить достаточное количество жидкости? Как отличить кортизол от других молекул? Как сделать сенсор точным, стабильным и безопасным? Как защитить его от пота, движения, температуры и внешней среды? Как передать данные на смартфон? Как откалибровать устройство так, чтобы его показаниям можно было доверять? И это уже не просто красивые концепты из лабораторий. Появляются первые испытания на людях. Например, стартап Adaptyx показал многосуточное измерение свободного кортизола с фиксацией его естественного суточного ритма и сопоставимостью с анализами венозной крови. Но дальше начинается ещё более сложная инженерная задача. Одного сенсора недостаточно. Нужно научиться правильно интерпретировать полученные данные. Высокий кортизол после тренировки - это нормально. Высокий кортизол утром тоже может быть нормой. А вот изменившийся суточный ритм, отсутствие восстановления или необычная реакция на нагрузку уже могут говорить о проблеме. Поэтому вокруг одного маленького датчика постепенно формируется целая система: сенсор → передача данных → алгоритмы обработки → персональная модель организма → рекомендации для человека или врача. И здесь появляется ИИ. Сегодня умные часы пытаются угадать стресс по косвенным признакам: пульсу, дыханию, температуре кожи и движениям. А прямое измерение кортизола может дать инженерам данные, на которых будут обучаться гораздо более точные модели. Тогда устройство сможет не просто сообщать: «У вас высокий уровень стресса». Оно сможет понимать, как именно ваш организм реагирует на недосып, кофе, перелёты, спорт, рабочие встречи или хроническую нагрузку. Когда-то инженеры сделали возможным непрерывное измерение глюкозы и изменили подход к лечению диабета. Теперь они пытаются сделать то же самое с кортизолом. И мне кажется, что главный технологический прорыв здесь не в том, что часы научатся показывать ещё одну цифру. А в том, что инженеры постепенно создают новый интерфейс между человеком и его собственным организмом. Ссылки на источники: spectrum Stanford https://t.me/kruasanova_as Всё ещё пишет сама и ищет новые способы взаимодействия

Microsoft ввела внутренние лимиты на расходы инженеров на AI-инструменты, с июля 2026 года у подразделений появились целевые токен-бюджеты, сотрудники могут отслеживать личные траты, а дефолтной моделью для внутренней работы стала GPT-5.6 Sol. Вице-президент Джей Парих в письме сотрудникам заявил, что «токенмаксинг — не то, что мы оптимизируем», и что расходы на токены теперь управляются «с той же дисциплиной, что и любой другой критический ресурс». Отдельные инженеры, по внутренним данным, тратят от сотен до нескольких тысяч долларов в месяц. Как подсказывают инсайдеры, вплоть до перехода на usage credits и переключения на gpt-модели GitHub Copilot, собственный продукт компании, работал с очень большим убытком. Конечно, интересно, что компания, даже обладая собственным инференсом, не очень справляется со сведением токен-экономики. https://www.404media.co/microsoft-tells-engineers-tokenmaxxing-is-not-what-we-are-optimizing-for/

Ты ненастоящий программист! Это происходит снова и снова, и каждый раз одинаково. Я начал свою карьеру, когда уже были языки высокого уровня, но ООП еще только набирал обороты. Несмотря на то что новая парадигма быстор становилась мейнстримом и нужно было учиться новому, не утихали разговоры о том, что ООП никогда не заменит структурный подход, потому что «медленно», «сложно», «бессмысленно» и все «настоящие» программисты используют только структуры + ассемблер для оптимизации сложных участков, а все «ненастоящие» — этот ваш новомодный ООП. Потом похожая ситуация была с использованием фреймворков — «настоящие» программисты — это всегда про «хардкор», когда буквально из ничего можешь собрать работающую систему, при этом все, что облегчает твою работу, сразу переводит тебя в разряд нетрушных программистов. Потом фронтенд стал ненастоящим программированием, все по той же схеме — слишком легко, нет технической глубины и сложности. Правда, вопрос со сложностью со временем решили, современные фронтендеры должны хорошо знать браузерные оптимизации, внутреннюю работу V8 и много других «трушных» вещей. Теперь пришла пора ненастоящими программистами называть вайбкодеров и тех, кто использует ИИ в своей работе. Проблема в том, что софт постоянно становится сложнее, объемы растут, задачи сменяют друг друга все быстрее, и использовать старые методы никак не получится. Да, раньше было лучше, каждая строка кода была осмысленным актом искусства, а сейчас тонны типового кода, обернутые в библиотеки и фреймворки, — совсем не искусство, но обычная работа. Задача инженера — делать качественный софт, который решает запросы бизнеса, и можно долго спорить, насколько ИИ неидеален, насколько он может или не может закрыть все задачи разработки, но факт остается фактом — уметь использовать современные инструменты для создания программных систем — это обязанность каждого эксперта в своей области. Соглашусь с теми, кто говорит, что ИИ отчасти хайп. Маятник должен действительно сильно качнуться в сторону, прежде чем вернуться к состоянию равновесия. Сегодня ИИ пихают везде, где можно и нельзя, конференции забиты пустыми докладами, а бизнесу наперебой предлагают внедрение SDLC от самых опытных и умелых интеграторов ИИ. Часть этого хайпа спадет, пузырь лопнет, но ИИ не исчезнет из нашей жизни. Останутся задачи, которые быстрее решать, используя интеллектуальные инструменты, и это станет де-факто стандартом индустрии. Поэтому ничего не мешает подождать, когда все успокоится и индустрия финализирует стандарты использования ИИ, изучить только то, что надо, а не пытаться ловить весь хайп. Но есть нюанс, отложить на потом — накопить долг, поэтому базовые вещи, которые уже устоялись, лучше разбирать сейчас, чтобы в будущем не оказаться в ситуации, когда учить придется слишком много и "еще вчера".

Компания Unitree провела испытания робота на способность подниматься по стремянке 💬По итогам теста робот успешно преодолел подъём, а также выполнил ряд дополнительных задач в конце маршрута. 💬Есть вероятность, что все действия выполнялись в полностью автономном режиме, однако окончательной ясности в этом вопросе пока нет - разработчики не раскрывают деталей. 💬Стоит отметить, что подъём по лестнице является гораздо более сложной инженерной задачей, чем ходьба по ровной поверхности: роботу необходимо одновременно распределять вес тела между конечностями с почти нулевой погрешностью, чтобы сохранить баланс. ————————— ✔️Подписывайтесь на лучший  канал PRO Роботов 🥲Мы в Max

Ребята дали четырём передовым моделям (Fable vs новые GPT) немного поработать: собрать симуляцию полёта NASA HL-20 — шесть степеней свободы, аэродинамика из 170 таблиц продувок — плюс четыре задачи от уравнений состояния до релятивистской динамики. Сверка относитльно независимого эталона. Claude выиграл - доля правильно произведенных расчётов - 89% против 0.73% у худшего GPT-5.6. Промах в конечной точке траектории: 0.4 метра у Fable, 19, 400 и примерно 500 у остальных. Цена победы $9.60 за прогон; GPT-5.6-Sol взял 81,5% за $1.74. Все провалы похожи: модель проверяет сама себя. Sol перепутал две похожие скорости из условия задачи и точно подогнал расчёт под неверную — все его проверки сошлись, потому что сверяли ответ с его же ошибкой, а не с условием. Terra молча сократила время симуляции с 5 до 3 секунд и себя проверяла на том же укороченном отрезке — накопивгшуюся ошибку никто не увидел. Fable нарочно пытался ломать собственные формулы, чтобы убедиться, что его тесты работают. Похоже поэтому и выиграл. Второй эксперимент: та же модель в их харнессе Dyad с принудительной верификацией набрала 0.899, в стоковом coding-агенте — 0.533 и ноль на релятивистской задаче. Формула авторов: модель — переменная, харнесс — множитель. Авторы исселодвания продают харнесс Dyad, так что мотив формулы очевиден. Тут я с ними не согласен Следить за рынком харнессов для меня сейчас — трата времени: универсальные агенты обмениваются фичами с лагом в недели, кто-то новый временами начинает побеждать, остальные догоняют. Кто сегодня лучший? Знаю, многие пытаются сделать свои варианты. Вместо того что бы работать. Когда появятся новые герои — мы этого не пропустим. Так было сначала с Cursor, потом с Claude Code и наконец то в тулсете закрепился и Codex (мы пользуемся обоими - всмысле обоими одновременно). Dyad в этот раз выиграл зашитой проверкой, которую агент физически не может пропустить. Это вправильный кейс. Мы умеем такое с клодом: у Claude Code есть хуки — скрипты, которые блокируют действие агента, если проверка не прошла. Плюс гит-хуки, которые не дают закоммитить сломанный файл. Работает. Модели меняем постоянно. Проверки, которые агент не может обойти, собираем каждый день. Сергей Булаев AI 🤖 - об AI и не только

Почему антенны работают на физике XIX века, но требуют технологий XXI В основе работы антенны лежат уравнения Максвелла, и другими они станут разве что в альтернативной вселенной. Полтора века неизменной физики. А вот сама антенна за поколения связи превратилась во что-то, что инженер из 1G не опознал бы, от простой всенаправленной железки до решётки, которая наводит отдельный луч на каждого абонента и отличает человека на первом этаже от человека на верхнем. Дальше траектория уходит совсем далеко. Метаструктуры позволяют сделать угол преломления луча отрицательным. В перспективных системах тысяча излучающих элементов умещается в панель размером с чемодан, а голографическая поверхность будущего буквально рисует картину поля вокруг приёмника. Физика та же, инженерия другая.

Телеграмма во Владивосток. Часть вторая Когда провод дотянули от Петербурга до Владивостока, магистраль тут же упёрлась в пропускную способность. Один провод — это один канал, и пока по нему идёт депеша на другой конец страны, все промежуточные станции молчат. Задачу решали ровно тремя ходами, которыми связисты пользуются до сих пор, только на механике. Гнать два сигнала навстречу по одному проводу, вычитая собственную передачу из принимаемого, тот самый принцип, на котором позже поедет эхоподавление в модеме. Убрать из канала самого медленного участника, человека, заменив ключ перфолентой на 1500 знаков в минуту. И временное уплотнение, где диск со щёткой по очереди опрашивает пять телеграфистов, работающих в такт, как оркестр. Механический TDMA за век до цифровой связи. Посмотрим, как телеграф собрал полный набор сетевых проблем, от единой точки отказа до перехвата трафика.

К посту выше. Если вы еще используете промпты в нейрочате и копируете нейрокод в проект, то вы сильно отстали от трендов. Согласно табличке этот этап прошел в 2024. Уже в 2025 прошел этап простого "ИИ-редактора" (Cursor, Windsurf, Trae и подобные), и стал актуален харнесс - это обвязка вокруг ИИ-модели, комплекс инструментов и правил, а не просто нейрочат. А в 2026 уже начался Graph engineering, то есть уже код некогда, надо оркестрировать пайплайны с ИИ на всех этапах. Забавно, но инерция в индустрии очень сильна. Общался с представителями разных команд из крупных проектов, многие говорят, что ИИ внутри инженеры используют "по желанию". То есть многие команды еще долго будут догонять тренды, нет столько ИИ-евангелистов и умельцев, но значит еще есть возможность такими стать. #ai

Все, с выходом Fable и 5.6 sol вы больше не должны понимать, что происходит у вас в коде. Не до всех еще дошло, но вы больше не software engineer, вы loop engineer

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

Ну камон, ребят. Все же понимают, что публичные лица компаний, который продают лопаты всегда будут преувеличивать ценность этих лопат и формировать хайп, который через какое-то время действительно пушанет технологии до уровня, который они продвигали. Типичный fake it till your make it – так все технологии развиваются и всегда развивались. Но мы то с вами не обязаны собой жертвовать ради этого, ну Почему я считаю, что сейчас это все еще не работает и хорошие инженеры должны понимать что происходит под капотом систем, которые они строят (даже если они строят их печатая/наговаривая английский/русский текст)? Постараюсь порассуждать "из первых принципов": Дело в том, что это всегда так и было – хороший инженер всегда понимал систему как минимум на один уровень абстракции ниже того, на котором её писал. Хороший Python разработчик знает про GIL и 3.13, PyMalloc, сборщик мусора, ссылочную природу объектов, и что многие библиотеки написаны на других языках со своими ограничениями и возможностями. И для него код на пайтоне на самом деле раскрывается гораздо глубже чем он выглядит на первый взгляд – тот самый tacit context Хороший C++ разработчик скорее всего знает не только про разные виды памяти, устройство умных указателей и виртуальные таблицы, но и в курсе про уровни хардварного кэша, особенности архитекутры процессора и хаки, которые использует компилятор для компиляции под эти архитекутры. И может даже знать, в какие конкретно ассемблерные инструкции раскроется его код. Понимает как треды устроены на уровне ОС, какие механизмы их переключения на уровне ядра, и как писать lock-free код ↑ Этого всего нет напрямую в синтаксисе языка. Это особенности поведения систем на гораздо более низких уровнях. И проблема в том, что если инженер их не знает, то он даже не знает чего он не знает. А значит, не узнает и о наличии проблем на этих уровнях. В итоге прод ложится под растущей нагрузкой, баги не находятся неделями и затыкаются костылями, из-за которых прод снова ложится, но уже в следующем квартале ——— Короче, мало топить за loop enginering. Нужно понимать что в результате этих циклов получится Так же как когда вы пишете цикл на C++, вы понимаете, как данные будет лежать в кэше (и в каком), будут ли лишние аллокации в куче, и раскроется ли ваша числодробилка в SIMD-инструкции В общем, это фундаментальное свойство любого профессионала – видеть систему глубже чем она описана Подгорело, @ai_grably

#рецепт В чём настоящая ценность Agent Skills. Часть 2 В прошлой части я докрутил мысль, что skill - это workflow package, а не промпт в папочке. Теперь о том, почему у одних скиллы работают, а у других превращаются в markdown-папку с надеждой на чудо или вообще не вызываются Главный подвох: настоящий прикол не только в SKILL.md, а в связке Skill + Agent Harness. Harness - это рантайм вокруг модели: поиск skills, выбор нужного, загрузка инструкций, запуск tools/MCP/shell, права, traces, approvals. Хороший инженерный разбор есть у Addy Osmani: https://addyosmani.com/blog/agent-harness-engineering/ 1) Progressive disclosure - причина почему скиллы масштабируются Агент не должен держать в контексте всю корпоративную библиотеку знаний. Сначала он видит только name + description, потом при выборе грузит SKILL.md, а уже после этого читает references/, assets/, examples/ или исполняет scripts/ Именно поэтому skill лучше гигантского AGENTS.md на 3000 строк. AGENTS.md - always-on фон, skill - on-demand способность. У Codex это описано тут: https://developers.openai.com/codex/skills, у Claude Code тут: https://code.claude.com/docs/en/skills (с CC конечно есть нюансы) Практический совет: в SKILL.md оставляй короткую процедуру, а длинные политики, API-доки, JQL-справки, шаблоны отчетов и примеры выноси в references/assets/examples. Если SKILL.md раздулся в трактат, вероятность его работы крайне низка 2) description - главный триггер, а не аннотация для красоты Частая ошибка: красивое тело скилла и бесполезный description. Агент выбирает skill именно по description, поэтому "Helps with code" - мусор. Это как задача в Jira с названием "Сделать нормально" Нормальный description отвечает: какую задачу делает skill, когда применять, какие слова его триггерят, какие входы нужны, какой результат вернуть и когда НЕ использовать. Пиши скиллы на 1 языке, не используй англорусский, шалоказахский и хинглиш Плохой пример: Helps with project management Лучше: Checks Jira sprint health, finds blocked issues, stale tasks, missing owners and release risks. Use before daily status update or weekly project report. Do not use for backlog prioritization Для проектирования смотри skill-creator от Anthropic: https://github.com/anthropics/skills/blob/main/skills/skill-creator/SKILL.md 3) Anti-rationalization надо писать прямо в инструкции Агент любит срезать углы не хуже менеджера перед пятничным демо. Он легко скажет изменение маленькое, визуально норм, тест-ран тут большой не надо запускать и тд. Поэтому в skill надо писать правила против отговорок Примеры: - - - - если есть diff, сначала inspect, потом summary, потом plan - если действие меняет внешнюю систему, сначала dry-run - если есть write/delete/update, нужен explicit approval - если нет данных, верни missing context, а не додумывай - если scanner не запускался, не пиши что проверка пройдена - - - В twinby я бы такие штуки паковал в jira-daily-radar, spec-quality-checker, release-readiness, browser-manual-test и confluence-sync. Не "агент, расскажи статус", а процедура: откуда читать, что считать риском, какой формат отчета, где нужен человек 4) Skill надо тестировать не только на результат, но и на срабатывание Минимальный набор: - explicit activation test: вызвался руками - implicit activation test: вызвался по естественному запросу - negative test: не вызвался там, где не должен - golden samples: вход -> ожидаемый выход - unit tests для scripts/ - trace review: видно какие шаги реально прошли - with/without skill: есть ли прирост качества, времени или стабильности По evals полезны OpenAI материалы: https://developers.openai.com/blog/eval-skills и разбор Phil Schmid: https://www.philschmid.de/testing-skills Хороший skill скучный: он умеет только 1 штуку делать, явно триггерится, явно проверяет, явно падает и явно просит апрув. Всё остальное обычно демка для LinkedIn/X/чата ваших фанатов в телеграм

Не просто коробка с деньгами: будни инженера сопровождения, который поддерживает банкоматы в строю Мы привыкли видеть в банкомате неприступный железный сейф. А под корпусом сидит обычный системный блок, мало чем отличающийся от того, что стоит у вас на столе. Банкоматом управляет самый рядовой компьютер под Windows или Unix, разве что материнская плата своеобразная, с кучей портов и крупной батарейкой. Казалось бы, раз внутри знакомая начинка, то и добраться до денег дело техники. Раньше так и было, неопытные взломщики шли на банкомат с болгаркой, ломом и кувалдой, а некоторые устройства даже взрывали. Ведущий инженер сопровождения из Альфа-Банка честно говорит, что сегодня думать о взломе бессмысленно, и объясняет почему, не раскрывая лишнего.

Питерские инженеры создали робота-снегоуборщика «Объект 314» для Арктики Губернатор Александр Беглов сообщил об успешных испытаниях полностью автономной машины. Согласно заявлению, робот уверенно работает при морозе до -40°C, оператор управляет ей удалённо из тепла. Гусеничный робот от Санкт‑Петербургского политехнического университета Петра Великого работает до 8 часов без подзарядки, может передвигаться со скоростью до 5 км/ч, оснащён лидарами и камерами для навигации. Предусмотрено сменное оборудование: отвал, щётка, шнекоротор (типа огромная конусная дрель для снега). Для навигации используются круговой LiDAR, инерциальные датчики, спутниковое позиционирование и IP-камеры. Устройство досерийное, находится на этапе опытной эксплуатации.

Наглядное сравнение прогресса по тепловому щиту Starship, но важен контекст. Характерный белый паттерн в носовой части от горения изоляции между плитками. По сути это сажа, которая и должна оставаться. Ещё на V2 они добавили дополнительный слой защиты, который загибается по краям под плиткой (до этого экспериментировали на V1). Его хорошо видно вблизи по белому цвету между плитками (он не везде). Означает ли это, что щит не работает? Нет. Потребуется ли для этого замена? Нет, только повреждённых. Также важно, что на этих 4 пусках отрабатывались разные сценарии входа в атмосферу. Flight 10 и 11 под доп нагрузкой и со снятыми плитками, отсюда продукты оксидации на защите и прогар местами, ещё и проверяли пределы по нагрузкам. Flight 12 также отличался по профилю, тк дополнительно тестировали нижние плавники под нагрузкой, но это не сильно повлияло на профиль хода. Flight 13 как раз ближе всего именно к тому, что будет при штатном возвращении на башню. Это наиболее мягкий сценарий, плюс корабль чуть дольше входил в атмосферу, и у них было больше времени, чтобы скинуть всю ту набранную энергию. Работы всё ещё очень много, но на данном этапе этого достаточно, чтобы попытаться вернуть корабль на башню. К слову, заменить все плитки они могут за несколько дней. 📸: Nic Cruz Patane

У Сбера есть интересный whitepaper где он описывает технологию разработки продукта с помощью агентных циклов. Можно сколько угодно не любить корпоратов, но игнорировать тренд, который формируется у нас на глазах - это просто глупо. Хотим мы этого или нет, но основой работы для инженеров становится архитектура агентных циклов, умение выстраивать процессы, делать оценку качества, вносить и контролировать метрики качества. Это работает потому что бизнесу интересно выпускать фичи в 2-3 раза быстрее, даже за счет дополнительных издержек на производство этих фич. Некоторое время еще можно подождать, чтобы убедиться, что тренд устойчив, но, ИМХО, цикл ранних последователей уже скоро закончится.

Превращаем виртуальный индикатор кислорода Subnautica в реальное устройство Синтетический голос произносит «oxygen», и это значит, что времени на решение уже не осталось. Кто нырял в Subnautica, знает эту связку счётчика с двумя числами и подступающей паники. Автор решил вытащить этот прибор из игры в реальный мир и повесить перед собой круглый дисплей, показывающий, сколько кислорода осталось прямо сейчас. Дальше начинается инженерная часть. Студия сама выросла из моддеров и разрешила ковырять игру, так что данные достаёт плагин на C#, читающий значения четыре раза в секунду и отправляющий их наружу по UDP. По пути выясняется, почему кислород в логах утекает дробными долями, а не тикает целыми, и как это спасает плавность будущей анимации.

Рука без автора: анатомия шестиосного промышленного манипулятора Промышленный манипулятор точно повторяет одно движение по три смены в день, пять лет подряд без капремонта, и конструкция его настолько удачна, что не меняется десятилетиями. Вот только придумать её целиком не удалось никому. Передачу в запястье изобрёл в 1955-м инженер обувной компании, редуктор в основании запатентовал немец ещё до войны, а математику для контроллера вывел стэнфордский аспирант в диссертации 1968-го и не заработал на ней ни цента. Эти люди не были знакомы, их разделяли страны и десятилетия, а изобретения сошлись вместе так, будто их проектировали друг под друга. Те же редукторы из запястья, к слову, NASA когда-то поставило на луноход, и оригиналы до сих пор лежат на Луне. Узнаем, как рука без единого автора собралась из чужих идей в машину, которую боятся переделывать.