IT

Ассемблер неправильная абстракция Каждый раз когда заходит речь о повышении уровня абстракции, в разговоре всплывает ассемблер в стиле "когда то мы писали на нем, а теперь не пишем". Особенно часто это повторяют сейчас в эру 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 разработчиков, не бравших на себя ранее ответственность за то, что их задача доедет до прода?

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

Google закрыла уязвимость в Android, позволяющую взломать смартфон без действий владельца Сентябрьский патч безопасности для Android устранил уязвимость, которая позволяет удаленно выполнять код на устройстве без каких-либо разрешений и действий со стороны владельца. Какая именно из уязвимостей использовалась для такой атаки, Google не раскрывает. Всего свежий патч содержит около 200 исправлений, из которых 33 имеют статус критических. При этом сразу 8 критических уязвимостей с риском удаленного исполнения кода найдены в компоненте System. Ситуация осложняется тем, что по данным самой Google, порядка 40% всех эксплуатируемых Android-смартфонов в мире уже не получают обновления безопасности и остаются без защиты.

😎ИИ на страже ржавых труб:

как Белый дом и техногиганты спасают американские водоканалы от дефолтных паролей

⚡️Хакеры начали массово взламывать водоканалы США. В ответ в Техасе стартовал проект Watershed 250 - шестимесячный киберполигон, куда согнали толпу тяжеловесов уровня Microsoft, Palo Alto Networks, Google Cloud и Dragos. Задача гигантов - обкатать свои Red Team, нейросетевой мониторинг и умные сенсоры на реальных водоканалах. Передовые ИИ-инструменты пытаются натянуть на инфраструктуру, застрявшую в каменном веке.

🟦В июле злоумышленники взломали больше сотни водных объектов в 12 штатах.

🟦Промышленные контроллеры Rockwell Automation просто висели голыми портами в открытый интернет со стандартными заводскими учетками - атакующим оставалось лишь зайти в веб-панель и сменить пароли.

Теперь федералы на полном серьезе учат коммунальщиков базовой гигиене: убрать ПЛК из публичного доступа, настроить VPN и хотя бы сменить пароль admin... 🦔 CyberYozh

Искал для подписчика варианты бесплатных нейронок, попросил Astra сделать список, может кому пригодится:

Для текста и кода можно собрать рабочий набор без платных подписок: бесплатные чаты для сложных запросов, несколько API с возобновляемыми квотами и локальную модель для повседневной работы. Проверил условия на 12 сентября 2026 — некоторые популярные советы уже устарели. Самые интересные бесплатные API Их можно подключать к своим скриптам, ботам и совместимым редакторам кода. Вариант Что бесплатно Где пригодится и что ограничивает Groq В бесплатном тарифе есть GPT‑OSS‑120B/20B и Qwen3.8‑27B. Для них указаны 30 запросов/мин, 1 000/сутки и 200 тыс. токенов/сутки Текст, объяснение кода, небольшие правки. Дополнительно действует 8 тыс. токенов/мин, поэтому большой контекст быстро упрётся в лимит Z.AI GLM‑4.7‑Flash и GLM‑4.5‑Flash имеют нулевую цену входных и выходных токенов Один из вариантов для небольшого кодового агента и текстовой автоматизации. Не путать с платными FlashX и новыми GLM‑5.x‑Flash; встроенный веб-поиск тоже платный OpenRouter Модели с пометкой :free, 50 запросов/сутки суммарно без пополнения Удобно пробовать разные модели через один API. Для многошагового агента квота небольшая. После покупки минимум $10 кредитов лимит бесплатных моделей повышается до 1 000/сутки Mistral Studio Free mode без банковской карты; страница тарифа указывает $10 API-кредитов в месяц Текст, суммаризация, код, эксперименты со своими приложениями. Проверять доступные модели и лимиты в кабинете Google AI Studio / Gemini API Бесплатный уровень для выбранных моделей, включая Gemini 3.8 Flash Полезно для текста и кода с большим контекстом. Квоты зависят от модели и аккаунта; бесплатные данные могут использоваться для улучшения продуктов Cloudflare Workers AI 10 000 Neurons ежедневно — это единицы вычислений, не количество запросов Небольшие боты, классификация, обработка текста. Часть крупных моделей теперь требует платного способа оплаты Бесплатные инструменты непосредственно для программирования GitHub Copilot Free: 2 000 автодополнений и 50 запросов чата в месяц. Подходит для подсказок во время написания кода и небольших вопросов. Gemini CLI: при входе через личный Google-аккаунт заявлено до 1 000 вызовов моделей в сутки. Бесплатный вход через API-ключ имеет другую квоту — до 250, только Flash. Доступ зависит от региона и аккаунта. Mistral Vibe: бесплатный план включает ограниченные кодовые сессии. Для постоянной работы предлагается платный тариф. Continue: позволяет подключать разные провайдеры, включая OpenRouter и Ollama. Здесь экономия получается за счёт выбранного бесплатного API или локальной модели; сам интерфейс не делает платные модели бесплатными. Одна задача агента может потребовать десятки API-вызовов. Поэтому «50 запросов бесплатно» хорошо для чата, но для самостоятельного исправления проекта может закончиться очень быстро. Для обычного текста — без установки и API Сервис Как использовать Qwen Chat / Studio Бесплатный веб-чат: тексты, переводы, объяснение и генерация кода. Бесплатность чата отдельно от тарификации Qwen Code DeepSeek Бесплатный чат/приложение для текстов, рассуждений и вопросов по коду. Официальное описание бесплатного приложения Mistral Vibe, бывший Le Chat Бесплатные сообщения и поиск с ограничениями; ещё один вариант для черновиков, редактирования и работы с текстом OpenRouter Free Router Можно пробовать бесплатные модели в Playground. Роутер выбирает доступную модель автоматически; для последовательной работы над кодом лучше фиксировать конкретную Практический приём: одна модель делает черновик, другая проверяет конкретные слабые места. Например, Qwen пишет функцию, DeepSeek ищет ошибочные предположения. При этом окончательная проверка кода — запуск и тесты, а не согласие двух чатботов. Локально Два удобных способа: LM Studio — графическое приложение: скачиваешь модель, общаешься с ней, при необходимости включаешь локальный API. После загрузки модели может работать без интернета. Приложение бесплатно для личной и рабочей деятельности. Ollama — удобно для терминала, скриптов и подключения к редактору. Локальное выполнение не имеет облачной квоты; оплачиваются твои электричество и вычисления. Для первого теста на твоём железе разумны: Qwen3 8B — универсальные текстовые задачи. Qwen2.5‑Coder 7B Q4 — небольшой специализированный вариант для кода; файл весит около 4,7 ГБ. Это стартовые кандидаты, а не обещание скорости: длинный контекст дополнительно занимает память. Большие проекты и сложные многошаговые задачи стоит оценивать отдельно. Что из старых подборок стоит вычеркнуть или перепроверить Qwen Code «1 000 бесплатных запросов через OAuth» — этот бесплатный доступ закрыт 15 апреля. Сам агент можно использовать с другим провайдером. Cerebras «вечный бесплатный API» — теперь только $5 пробных кредитов на 30 дней, с подтверждённым способом оплаты. Hugging Face Inference Providers — бесплатный аккаунт получает всего $0,10 в месяц. Это небольшой пробный бюджет. Ollama Cloud — облачные модели имеют квоты и кредиты; без облачных ограничений работает именно локальный запуск.

👌

А чё, так можно было? Недокументированный C# В C# есть четыре ключевых слова, которых нет в документации, но компилятор их спокойно принимает. Одно из них объявляет метод с переменным числом аргументов без всяких массивов. Собирается такой код без единого предупреждения, отрабатывает на Windows и честно выводит переданные значения. Ту же самую сборку переносят на Ubuntu — и вместо результата прилетает InvalidProgramException с сообщением, что соглашение вызова не поддерживается. Байты те же, машина архитектурно та же, x64, а поведение разное, и падает при этом не сам метод, а код, который его вызывает. Разберёмся, почему одна проверка в джите решает судьбу всей сборки.

Создавать или нет На последнем ИИ-хакатоне шесть команд, собранных из незнакомых друг с другом людей, за 90 минут собрали работающий сервис. Он принимает бриф, пишет сценарий, генерирует видеоролик и отправляет результат клиенту. Пару лет назад на такое потребовались деньги и месяцы работы. Сегодня — полтора часа и кофе :) Раньше создавать продукт было дорого и ты десять раз думал, что именно строить. Искал клиентов, выбирал функции, отбрасывал лишнее. Теперь в субботу встал с идеей, в воскресенье — у тебя приложуха с авторизацией, кабинетом и оплатой. Никому не нужная, зато работающая. Y Combinator говорил 30 лет стартаперам: 1. Быстро запусти хоть что-нибудь 2. Поговори с пользователями 3. Сделай то, что им нужно Справедливо, когда главное препятствие — разработка. Сейчас сложность — понять, что вообще стоит создавать. Поэтому и порядок действий перевернут: 1. Найди пользователей чужих продуктов 2. Узнай, за что платят и что бесит 3. Продай решение до разработки 4. Создай только то, что купили Раньше стартапы умирали из-за неумения построить продукт. Теперь из-за умения.

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

Нелепости агентов Агентная разработка - веселая штука конечно. Вот планируешь и кодишь несколько дней с Астрой, Фейблом и Опусом, а потом на e2e вот такое вот выясняется (см. скрин и пояснения в конце). И это прям системная история - 99% получается хорошо и правдоподобно, а в каком-то неожиданном месте Но справедливости ради - это был сложный и огромный кусок работы на десятки тысяч строк кода, хоть и делался в лучших традициях SDD с хорошим планом. Выводы? 1. Делайте e2e тесты - причем как классические через условный Playwright / XCUIAutomation и тд, так и агентные "JIT" тесты - когда агент сам запускает вашу систему в около продовых условиях и ведет себя как Manual QA. 2. Рефлексируйте - если все-таки что-то вылезло несмотря на все ваши пятьсон уровней гардрейлов, обязательно ищите источник проблемы - то есть, в какой момент вашей даркфактори агентного пайплайна вылеза ошибка и как она вообще дошла до live e2e. * Контекст: я разрабатываю агентный интерфейс к одному из своих проектов (в данном случае - это MCP + skill) и вот там оказалось, что ответ в во всех MCP инструментах просто дублируется (структурированный + обычный текст) - абсолютно комичный дефект, который добрался аж до финальной стадии верификации. Live e2e же там устроен так, что сильный агент тестирует другого агента на предмет того, как тот справляется с задачами из юз кейсов - и то, как быстро он справляется, и сколько токенов у него на задачу уходит. Это, кстати, правильный подход и к evals скиллов тоже. Если тоже сталкивались с подобными нелепостями агентов - расскажите в комментариях что это было и как боролись. @ai_driven

💎Две Astra-новости💎 1. OpenAI признала проблемы с Astra и выкатила исправления. По словам Тибо, старые скиллы слишком часто срабатывали и иногда мешали модели проверять свою работу. Эксперимент с управлением контекстом приводил к преждевременным остановкам и ответам на старые сообщения; он затронул примерно 4–5 тысяч пользователей, его отключили. Также убрали неудачно настроенные серверные конфигурации, на которых измеримо падало качество. Обещают, что Astra будет лучше доводить задачи до конца и учитывать последние сообщения. Заодно анонсировали очередной сброс лимитов в ближайшие часы🐈 Пост Тибо. 2. OpenAI советует почистить старые инструкции для Codex. Компания выкатила руководство по скиллам, AGENTS.md и промптам для Astra: накопленные правила могут перегружать контекст, конфликтовать и заставлять модель останавливаться без необходимости. Рекомендуют точнее прописывать условия запуска скиллов, подгружать документацию по задаче и убрать обязательное «прочитай весь проект перед любой правкой». Особенно важно заранее объяснять, что считать завершением: например, реализовать, запустить, проверить результат и исправить ошибки. В помощь обновили skill-creator. Официальный разбор.

Ладно, мухи - это круто, но я к вам пожаловаться. Нужно было по работе сделать довольно простую тулзу. Копировать дескрипшен задачи из Jira в Bitrix. Просто, да? Но нет! Во-первых, это расширение для браузера, во-вторых, должно работать со всеми браузерами, нужно было шарить это на команды, а работает кто в чем. Третье: нельзя пользоваться API Jira. Пятое: нужно копировать и картинки, и текст со всем форматированием. Есть ещё пермишены самого браузера для расширений. В общем, нюансов масса, как оказалось. И тут я думаю заюзаю Astra, AGI ведь уже с нами. Sol пару раз ломал уже работающий функционал, и пришлось переключиться. По наблюдениям думать он стал дольше, но и результат стал чище, больше гипотез, самопроверок, тестирования. Но у этого есть и обратная сторона, токены жгутся как на Камчатке в -50 в котельной. Доходит до смешного, когда я попросил собрать Zip архив со стабильной версией, он думал минуты 2, запуская проверки стабильной версии, и сжег где-то 25% дневного лимита 😣 Вау, это Альтман классно придумал! В общем, будьте аккуратны, Astra очень прожорлива даже на простых задачах, поэтому используйте соответственно задаче. @CGIT_Vines