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

В Go 1.27 завезли SIMD Двенадцать лет Go не умел в векторные инструкции без плясок с ассемблером. В 1.27 приехал портируемый пакет simd, и один исходник без единой правки разворачивается в Neon на Apple Silicon и AVX2 на Intel. Автор проверил обещание на двух машинах, полез в дизассемблер и наткнулся на странное. На Mac четыре полосы дали 4,2x, почти потолок. У i9 полос вдвое больше, восемь, а вышло ровно 5x. Куда делись ещё три икса? Разгадка неуютная для всех, кто верит в ширину регистра. Ту же половину выигрыша снимает обычный скаляр, без единой векторной инструкции, стоит завести четыре аккумулятора вручную. Ширина регистра тут вообще на втором плане.

Все там будем, или Почему игровые движки всегда заканчивают одинаково В движке «Блицкрига» нейтральные свиньи по недосмотру отнаследовались от боевого юнита. Завидев врага, они патриотично лезли за оружием, которого у них не было, зато патроны находились сами собой из неинициализированной переменной. Стрелять нечем, а боезапас есть, и свиньи дружно валили игру нулпоинтером. Починили изящно, выдав свиньям парабеллум, но обнулив патроны. Вся прелесть в том, что это не курьёз одной студии, а закономерная стадия, через которую проходит любой движок. Сначала весь код держится на наследовании от одного всемогущего класса, и баги в нём лечатся тем же наследованием, пока команда не упрётся в стену. Дальше по замкнутому кругу через компоненты, конфиги и собственный язык, и снова к началу. Посмотрим, какие четыре стадии проходит каждый движок и почему круг так тянет замкнуться: https://u.habr.com/elBSf

Закончилась эпоха Недавно Дядюшка Боб (автор книг "Чистый код", "Чистая архитектура" и т.д.) заявил, что вообще не читает код, который пишет LLM, вместо этого он использует ограничения в виде автоматизированных тестов и других проверок. Подобных заявлений с каждым днем становится все больше и количество будет только расти. Можно возразить, мол "а как же качество?". На самом деле за последние два года качество генерации сильно возросло, если грамотно гранулировать задачу, можно обойти многие ограничения ИИ (например, дублирование функций и классов, если их нет в контексте, и тому подобные вещи). Фокус ушел на AiSDLC и описание архитектуры проекта. Мне кажется, в моменте мы переживаем этап взросления разработки, когда от написания кода мы уходим к архитектуре и идеям. В этом смысле Роберт Мартин не изменяет своим принципам – он всегда топил за более высокоуровневый взгляд на программирование, и теперь ему стало делать это чуть проще. Но что будет с кодом? Мне кажется, что примерно то же, что произошло с ассемблером: как рабочий инструмент его мало кто использует, но интерес к пониманию того, как все работает, остался, многие смотрят видео по низкому уровню просто из любопытства, из-за того вайба, который дает погружение в инженерию. Поэтому код не исчезнет, просто заниматься им будут по желанию, из любопытства, а не потому что надо.

Все советы Anthropic по разработке за "лето" Студентам советую раз в неделю читать что выходило свежего у OpenAI/Anthropic по разработке с помощью ИИ. На мой взгляд это сейчас самый передний край и проверенное. Лучше всяких ютюб-блогеров. Внутри у них ~80% смерженного кода уже пишет ИИ, инженеры шипят в 8 раз больше, чем в 2021–2025. И они довольно подробно рассказывают, как это устроено. Вот что, имхо, самое полезное было (в PDF подробно, можете почитать и отдать ИИ) 1. Узкое место теперь не написание кода, а проверка. Агенты генерят быстрее, чем люди ревьюят, поэтому все инвестиции – в верификацию. Практически: выписываете всё, что повторно исправляете за моделью, и кодируете в скиллы-проверки (.claude/skills) – агент сам гоняет тесты и чинит до сдачи. Сама команда Claude Code гоняет цепочку /code-review → /simplify → /verify, а потом те же проверки гейтом на каждый PR. 2. CLAUDE.md – короче 200 строк и без очевидного. Только точные команды тестов по подкаталогам (иначе модель запускает полный сьют на 40 минут) и то, что противоречит дефолтам модели. И пересматривать раз в 3–6 месяцев – правила под старые модели душат новые. 3. Разделение простое: пожелание – в CLAUDE.md, процедура – в скилл, закон – в хук. Линтер после каждой правки и блокировка rm -rf – только хуками, скилл модель может и забыть вызвать. 4. Ревью переразделили: ИИ – стиль, линтинг, отлов багов, тесты (несколько узких агентов, с каждой находки требуют доказательств – доля содержательных комментариев выросла с 16% до 54%). Люди – security, границы доверия, продукт. Автономному агенту – минимум прав: их инцидент-бот умеет писать доки и читать логи, деплоить – нет. 5. Самый огненный кейс – миграции. Bun перевели с Zig на Rust: миллион строк за 2 недели и ~$165k в токенах (раньше такое стоило $3–4 млн и 4 года). Рецепт: сначала тесты против обеих кодовых баз, потом rulebook правил перевода, дальше дешёвые модели переводят, дорогие ревьюят. Главный принцип – повторяющийся фейл это баг правила, а не файла: правишь rulebook и перегенерируешь, руками не патчишь. Я так переписывал gtfs.guru, скоро выложу мажорный релиз https://claude.com/blog

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

Продолжение Один из комментаторов у Никиты написал, мол, как же импликации нет в языках программирования, когда там есть if (a) b? Но что значит? В известных мне языках программирования это даже не является выражением, но если бы являлось, каким было бы его значение? Иными словами, что бы нам дал вывод print (if (a) b)? Конечно же true! Ведь в этом буквально состоит работа языка программирования: обеспечить b, когда истинно a. Если он этого не делает, то зачем такой язык программирования нужен? Но в то же время, если a ложно, то глядя на эту строчку мы никак не сделаем вывод о том, произойдёт ли b. Может, какая-то другая часть кода обеспечит b. Строчка if (a) b никак не способна предотвратить b. Получается какая-то эзотерика, и только потому, что никто никогда не рассматривает if (a) b как логическое выражение и не пытается оценить его истинность. Всех интересует только логическое выражение a по отдельности, потому что от его истинности зависит, может ли быть уверены в том, что произойдёт b. Импликация в языках программирования была бы, если бы можно было написать if (a→b) c, то есть «если из a следует b, обеспечь c». Но нафиг это надо? Как мы уже выяснили, когда значения a и b уже известны, значение истинности их импликации не несёт никакой пользы и почти никакого смысла.

Импликация, следствие и условия Никита Прокопов написал, что импликация — нифига не интуитивная штука, и поэтому её нет в языках программирования. И действительно: там в комментариях начался обмен мнениями, который хорошо иллюстрирует неинтуитивность. И мне сразу захотелось написать этот пост. Импликация — это логическая операция вида «A → B». Она истинна во всех случаях кроме одного: когда A истинно, а B ложно. Можно оценить по таблице истинности: A  B A → B 0 0 1 0 1 1 1 0 0 1 1 1 То же самое можно сформулировать как «из истины следует истина, а из лжи — что угодно». Кажется, что это простая штука, ведь в жизни мы легко понимаем выражения типа «Если A, то B» или «Из A следует B». Но если сказать, что «из 2×2=4 следует что Волга впадает в Каспийское море» (V), большинство воспротивится этому. Почему, ведь с точки зрения логики это верное утверждение? Дело тут в том, что мы не интерпретируем фразу V буквально. Мы видим, что в общем случае из математического равенства не следует географический вывод. То есть мы подсознательно обобщаем V, превращаем в шаблон, и тогда импликация разрушается. Мы понимаем, что имея лишь «2×2=4» и не зная ничего про Волгу, невозможно сделать вывод о том, куда она впадает. Но импликация означает истинность конкретного этого высказывания, а не то, что высказывание сохранит истинность при обобщении. Зачем мы вообще стали обобщать? Почему мы не можем оценить истинность импликации буквально? Потому что это низачем не нужно никогда, и наш мозг не научен так думать. Следует ли из одного высказывания другое нас интересует лишь тогда, когда мы не знаем истинности одного из них. Но если мы уже знаем истинность обоих высказываний, то у нас просто не возникает вопроса о том, как выводить истинность одного из них из истинности другого — это же совершенно бессмысленнно! Высказывания типа «Если A, то B» нас интересуют как способ выводить истинность B из истинности A или наоборот, то есть только тогда, когда мы не знаем одно из них. А для этого нам нужно вскрыть содержательную связь между A и B, а не просто значения их истинности. Тут-то нам и нужны шаблоны, да такие, что мы уже заранее знаем, что импликация там истинна! Предположим, мы знаем, что «у каждого голландца есть велосипед» (K). Заметьте, что это уже утверждение, содержащее импликацию («если человек голландец, то у него есть велосипед»), и мы уже договорились, что оно истинно. Вот теперь если мы узнаем, что Фёдор голландец, мы сделаем вывод о том, что у него есть велосипед. Импликация помогла сделать этот вывод только потому, что мы 1) уже знали, что сама она истинна, и вдобавок 2) она имела форму шаблона, в который можно было подставить Фёдора. От истинности же импликации V из начала заметки нет никакого проку. Поэтому с такими видами совершенно верных высказываний мы никогда не имеем дела. Они нам кажутся настолько пустыми, что мы не готовы даже пытаться оценивать из истинность.

Что-то я чувствую себя как в этом эпизоде. Я опять проверяю границы агентов. @softwarevlogger прислал мне репозиторий и сказал: «Я это сделал тремя промптами». Смотрю — а там идея пересекается с тем, что делаю я. Я просто скормил знания о своём проекте и об этом репозитории и сказал: изучи, сопоставь, а классные идеи, которых у нас нет, — укради. И fabble украл эти идеи, делегировал опусам (я, кстати, до сих пор не смотрел, но вижу, что апа постоянно перегружается и интерфейс меняется). Ещё один из опусов попросил разрешения на изменения в ридонли-системе памяти, на основе которой я всё построил. Как я понял, в своей системе поиска локальных видео я покрыл ещё один use case. Но я еще не смотрел 🤓