Ассемблер неправильная абстракция Каждый раз когда заходит речь о повышении уровня абстракции, в разговоре всплывает ассемблер в стиле "когда то мы писали на нем, а теперь не пишем". Особенно часто это повторяют сейчас в эру AI. Честно говоря, мне это никогда не казалось правильным сравнением и кажется я могу объяснить почему. Переход от ассемблера к языкам высокого уровня был переходом от слишком низкого уровня завязанного на технические детали, к конструкциям, которые которые задают базис для построения программ практически любой сложности. И вот этот уровень принципиально не менялся десятки лет. Менялись языки, платформы, библиотеки и способы организации кода, но сам программист продолжал работать примерно с теми же конструкциями. Программа на современном языке устроена концептуально почти так же, как программа пятьдесят лет назад. Но после этого характер повышения абстракции изменился. Мы больше не поднимались от технической реализации к естественной модели вычислений. Мы пытались подняться от программирования к описанию намерения, того, что должна делать система, и автоматически получить реализацию. Cobol был одной из первых попыток подняться от описания вычислений к описанию бизнес-намерений. Предполагалось, что программы на похожем на английский языке смогут читать и, возможно, писать сами специалисты бизнеса. Но понятный синтаксис не устранил сложность программирования. Для точного описания поведения все равно понадобились переменные, условия, циклы, структуры данных и процедуры. В результате cobol стал успешным языком для бизнес-систем, но не стал языком самого бизнеса, так как писали на нем по-прежнему программисты. Успешные примеры появились там, где намерение удалось ограничить конкретной и хорошо формализованной областью. Хорошие примеры это регулярки, sql, html/css или terraform. Это конечно еще не бизнес уровень, но уже что-то. Для разработки произвольных программ такую модель создать не получилось. Как только языку намерений требовалось описывать нестандартное поведение, в нем появлялись все привычные конструкции. Постепенно он снова превращался в обычный язык программирования, только с другим синтаксисом и новым набором абстракций. Это хорошо видно на примере BDD. В изначальной идее сценарии на языке, понятном бизнесу, должны были стать общей спецификацией системы и одновременно основой для автоматической проверки. Но довольно быстро выяснилось, что реальные сценарии либо остаются понятными, но описывают только верхний уровень поведения, либо становятся достаточно точными для исполнения, но обрастают техническими деталями и фактически превращаются в еще один код. А между сценариями и работающей системой все равно остается большая часть логики, которую кто-то должен спроектировать и реализовать. Я не думаю, что AI решает эту проблему. Спецификация произвольной системы либо остается неполной, и тогда множество неописанных решений агент принимает самостоятельно, либо обрастает правилами, исключениями, состояниями и способами обработки ошибок и по сложности начинает приближаться к самой программе. AI может значительно увеличить расстояние от намерения до кода и избавить нас от ручной реализации многих деталей, но он не создает универсального уровня абстракции, на котором можно точно описывать любые системы и при этом не программировать. Я был бы рад ошибиться, но пока не вижу предпосылок. А как вы думаете?

Хорошее время для QA-инженеров. Часто слышу тезисы в духе:

AI-coding убил QA

Это не так. Точнее – не совсем так. Если мы внедряем AI-инструменты в процессы разработки, то написание кода достаточно сильно ускоряется. В зависимости от дисциплины и ответственности конкретного разработчика, это ускорение может в большей или меньшей степени влиять на качество производимого кода. Уже на первых этапах внедрения AI-инструментов в процессы разработки, мы получаем "затор" на стадиях ревью и тестирования. Этот затор кому-то придётся разгребать... Желательно – тоже с использованием AI в качестве инструмента. Здесь и появляется QA-инженер. Учитывая, что качество кода – одна из основных претензий к AI-generated-коду, роль грамотного QA (и грамотного QA внутри каждого разработчика) сильно повышается. QA-инженер отвечает за выстраивание quality-gates на разных этапах SDLC, а также организовывает процессы тестирования. QA-инженер даёт гарантию, что код, попавший в продакшн, соответствует конкретным критериям качества. Проблема в том, что в небольших командах QA-инженеры встречаются достаточно редко. Там чаще:

Ну, сидит у нас тестировщик, за плошку риса интерфейсы тыкает, проверяет, что они тыкаются

Эти тестировщики на процесс AI-SDLC влияют, скорее, негативно. Так как, под большим напором задач от AI-accelerated-разработчиков, выбора у них два – либо накапливать себе объёмы для тестирования, либо снижать качество проверок. В первом случае мы получаем нивелирование ускорения time-to-market, как одного из преимуществ AI-SDLC, а во втором – снижение стабильности прода. На этой неделе был "День тестировщика" (9 сентября). Я чуть опоздал с пожеланиями, но всё же: Пользуйтесь теми возможностями, которые предоставляют изменения на рынке. Изучайте глубже процесс AI-SDLC и то, как вы можете повлиять на качество кода на выходе. Потребность в QA-инженерах, способных работать в цикле AI-SDLC, будет только расти. Вопрос для дискуссии: Готовы ли QA-инженеры заменить в формате Tiny-teams разработчиков, не бравших на себя ранее ответственность за то, что их задача доедет до прода?

#Нейропрожарка Алаверды чудной прожарке, еще раз респектище автору. Автор: Stacy Smith Половина комментов под ней крутились вокруг "а вот надо было закончить так. Или так. Или вообще вот так". Штош, кричать в попу - не наш метод, поэтому, вместо комментария, со всем уважением отправляю нейромодернистский перепев (или как это назвать, когда нейровидео по мотивам нейровидео?). К сожалению, бесплатно не получилось - рублей 500 на кредиты ушло. Видео - свежий Грок, по-прежнему радует дешевизной и русским языком, а теперь еще и разнообразный тайминг. Картинки - стандартный набор ГПТ/Банана. Как обычно, не корысти ради, а развлечения для. @cgevent

Поиграйте в ремейк Fatal Frame II: Crimson Butterfly — произведение специфическое, но жутко атмосферное и страшное Fatal Frame 2 на PS2 — единственный хоррор, который я не смог пройти, потому что было слишком страшно. Вероятно, дело в магии PS2, шуршащей в тишине диском, и соответствующей графике. Призраки вышли настолько пугающими, что я просто не смог. Ремейк магией PS2 не обладает, но это всё ещё весьма страшная игра. Проклятая японская деревушка здесь настолько атмосферная, насколько это вообще возможно в j-хоррорах. А Fatal Frame 2 — это квинтэссенция j-хорроров. Скрип половиц, тонкие испачканные стены, крохотные комнаты, скупое, но убранство помещений, рассказывающее свои жуткие истории… А ещё вечная ночь. Такой страшной ночи, как в деревне Минаками, вы не увидите нигде. Структурно Fatal Frame 2 напоминает Silent Hill или даже Resident Evil. В деревушке множество закоулков и несколько домов, которые нужно посетить. Двери открываются не сразу, а для некоторых нужно получить специальный скилл. Дома не очень большие, но крайне запутанные. И да, в игре очень много бэктрекинга — в уже посещённые помещения приходится несколько раз возвращаться, а порой абсолютно неясно, куда вообще идти. Сейчас так сурвайвл-хорроры уже не делают. Пару раз мне даже приходилось открывать прохождение, потому что плотно застревал, и карта никак не помогала. Подсказки вроде бы есть (мирные призраки, например), но их ещё надо увидеть и разобраться, что они тебе пытаются сообщить. В общем, придётся поблуждать. Но при внешней схожести с другими представителями жанра, у Fatal Frame 2 есть своё лицо — в некоторых аспектах она уникальна. Так, в качестве оружия здесь выступает камера-обскура, которой нужно… фотографировать признаков. Плёнка бывает разных видов, от чего зависит сила и скорость перезарядки. Призраки появляются в фокусе не сразу: надо или подождать, или подкрутить его самому — если прокачал нужное умение. Есть ещё несколько специфических фильтров, которые в основном нужны для изучения локаций, но и в бою помогают. Призраки преимущественно медленные (но у них бывают и быстрые атаки), поэтому тактика такая: подбежал, поднял камеру, сфоткал, увернулся, отбежал. Когда прокачаешься (и если есть хорошая плёнка в достатке), то можно фоткать часто и с большой силой — тогда рядовые призраки растворяются достаточно быстро. Но боёвка всё равно получается очень нервная. Пространства всегда не хватает (клаустрофобам понравится), а у разных призраков разные виды атак. В результате бегаешь из угла в угол, судорожно прицеливаясь камерой и стараясь не попасться под удар. Призраки на месте не стоят, возникают то тут, то там, проникают сквозь стены, а ещё могут напугать скримером. Причём чтобы нанести много урона, нужно подойти к призраку как можно ближе. У каждого призрака свой характер и свои механики. Меня буквально до дрожи довела девушка, упавшая при жизни со второго этажа. Она… ползает и истошно хохочет. Иногда появляется над тобой на потолке и с грохотом падает на пол. У многих призраков есть своя история, и им не терпится её рассказать. В общем-то, несмотря на всю жуть, которую творили жители деревни при жизни, их всё-таки жаль. Теперь, будучи призраками, они вынуждены постоянно проживать тот злополучный день, когда не удался ритуал жертвоприношения — но сюжет лучше узнать самому, он тут очень хороший. Если вы считаете себя фанатом хорроров, то пройти определённо стоит. Fatal Frame 2 — немного странная штука, но культовый статус она приобрела не просто так. Ну а лучший и самый удобный способ прикоснуться к великому сейчас — это поиграть в ремейк. #поиграйте

Отвратительные вопросы для Гофера Автор собрал вопросы по Go, которые в реальной работе почти не встречаются. Вызвать приватную функцию из чужого пакета, объяснить, чему равна длина слайса, почему у пустых структур могут совпадать адреса. Знать это, чтобы писать код, необязательно. Зато по тому, как кандидат отвечает, видно, отвечает он сам или подсовывает вопрос модели. Логика тут двойная. На части вопросов срабатывает то, как именно приходит ответ, и это выдаёт того, кто спрашивал не свою голову. А есть зеркальные вопросы, где всё переворачивается. Живой разработчик отвечает спокойно, а модель уверенно ошибается, потому что до нужной версии Go её знания просто не дотягивают.

Интересные примеры неконвенционального использования ИИ произошли на днях — повстанцы-хуситы на севере Йемена, поддерживаемые Ираном, использовали Claude для вайбкодинга ПО для высокотехнологичного ракетного оружия. Антропики, естественно, уже заблокировали их. Anthropic сообщили, что владельцы аккаунтов, заблокированных после обнаружения, не смогли «развернуть действующее устройство», однако провели неудачные испытания управляемой ракеты. В компании уточнили, что узнали об этом, поскольку пользователи вернулись к чат-боту Claude, чтобы выяснить причины неудачи. Пользователи вайбкодили несколько типов вооружений, включая гиперзвуковую ракету вариативной компоновки и боеголовку, использующую комплектующие мобильных телефонов для маневрирования на траектории. В докладе, опубликованном 10 сентября (GTG-87001: Disrupting a Yemen-based guided weapons engineering cell using Claude to develop guidance software, там ещё много интересного по, например, китайскому использованию американского ИИ для изготовления военного ПО), компания пишет, что

Акторы использовали Claude Code вместо инженеров-программистов для разработки программного обеспечения систем наведения, навигации и управления (GNC), которое отвечает за движение и стабилизацию летательного аппарата. Например, они задействовали Claude для интеграции автопилота с открытым исходным кодом в полётный компьютер класса смартфона, написания ПО для управления и оценки позиционирования, настройки параметров управления, запуска конвейера (пайплайна) сборки прошивки и проведения симуляции полёта. Акторы одновременно управляли несколькими инстансами Claude, распределяя между ними роли точно так же, как тимлид делегирует задачи внутри небольшой инженерной команды: одному инстансу поручали написание кода, другому — проведение исследований, а третьему — ревью (проверку) кода, созданного первым.

Однако с другой стороны, Хазам аль-Асад, член политбюро хуситов, назвал «неразумными и нелогичными» предположения о том, что они полагаются на открытые источники для разработки и производства военных мощностей. Следом же повстанцы добились больших успехов по захвату территорий так как сделали дипфейк голоса командующего «Национальным сопротивлением» Йемена генерал-лейтенанта Тарека Салеха, который якобы отдаёт приказ об отступлении и захватили стратегические территории вдоль побережья Красного моря и в Баб-эль-Мандебском проливе — ключевой альтернативе Ормузскому проливу. Чем дальше, тем больше таких неконвенциональных использований и пере-использований ИИ-агентов мы увидим, если, конечно, всю эту лавочку не прикроют совсем скоро и доступ к фронтирным моделям не сделают эксклюзивным для американских военных корпораций и государственных агентств во имя новой холодной хай-тек войны с Китаем, а пользователям оставят мизерные урезанные версии.