Разработка

Представьте: вы пишете "перезапусти продакшн-сервер" в Telegram, и система не просто понимает запрос — она знает, какой именно у вас сервер, что на нём запущено, кто будет затронут простоем, и предлагает конкретный план действий. Без панелей управления, без SSH, без поиска в документации.

Это не шизофреническая фантазия. Это ICNLI (Infrastructure Contextual Natural Language Interface) — открытый стандарт, который мы разработали и уже внедрили в production на десятки серверов.

Представьте ситуацию: вы выбираете между Intel Core i9 и Apple M2 (как пример двух мощных систем). Один потребляет 300 Ватт и греется как печка, другой — 30 Ватт и работает от батареи 20 часов. Один показывает 200 FPS в играх, другой — 90, но в три раза эффективнее. Один стоит $600, другой — встроен в ноутбук за $2000. Кого вы выберете?

С Новым Годом и добро пожаловать в Gas Town!

Gas Town - это новый взгляд на IDE для 2026 года. Gas Town помогает вам справиться с рутиной запуска множества экземпляров Claude Code. Вещи теряются, трудно отследить, кто чем занимается, и так далее. Gas Town помогает со всей этой рутиной и позволяет вам сосредоточиться на том, над чем работают ваши Claude Code.

В этом посте "Claude Code" означает "Claude Code и все его идентичные конкуренты", то есть Codex, Gemini CLI, Amp, Amazon Q-developer CLI, бла-бла-бла, потому что именно этим они и являются. Клоны. Индустрия - это постыдная детская футбольная команда, гоняющаяся за форм-фактором CLI Claude Code образца 2025 года, вместо того чтобы создавать то, что будет дальше.

Я пошел вперед и создал то, что будет дальше. Сначала я предсказал это еще в марте в статье Месть начинающего разработчика. Я предсказал, что кто-то свяжет верблюдов Claude Code вместе в колесницы, и это именно то, что я сделал с Gas Town. Я приручил их настолько, что вы можете продуктивно использовать 20–30 штук одновременно на постоянной основе.

Gas Town имеет свое мнение - во многом как Kubernetes или Temporal, на которые Gas Town похож, по крайней мере, если прищуриться так сильно, что глаза почти полностью закроются. Я включу сравнения как с k8s, так и с Temporal в конце этого поста. Немного удивительно, насколько они похожи, несмотря на радикально разные основы.

Но сравнение должно служить предупреждением: Gas Town сложен. Не потому, что я этого хотел, а потому, что мне приходилось добавлять компоненты до тех пор, пока он не стал самодостаточной машиной. И те части, которые у него теперь есть, ну, они выглядят так, как будто Kubernetes спарился с Temporal, и у них родился очень уродливый ребенок.

Но это работает! Gas Town решает проблему MAKER (Ханойская башня из 20 дисков) вообще элементарно. Просто генерируешь по формуле "цепочку" на миллион шагов - и готово. Вчера ради интереса прогнал 10 дисков за несколько минут: доказал, что тысяча шагов для нас - это не проблема, хотя в статье MAKER говорится, что нейронки ломаются уже через несколько сотен. На 20 дисков закладываю часов 30. На этом мой импровизированный TED Talk окончен.

Все это обретет полный смысл, если вы дочитаете до конца следующих 23 страниц.

Beads продолжает набирать обороты. Когда мои старые друзья начинают натыкаться на него независимо друг от друга, я понимаю, что проект становится вирусным.

Beads занимает совершенно уникальную нишу. Все сосредоточены на создании инструментов планирования, в то время как Beads - это инструмент исполнения. Это всё равно что поставить вашего ИИ-агента на отлично смазанные лыжи. Возможно, лучшим названием было бы Agents on Rails («Агенты на рельсах»). Но название «Beads» (Бусины) хорошо передает идею того, что инструмент сфокусирован исключительно на отслеживании (трекинге) и ни на чем другом: маленькое имя для маленькой системы.

Сейчас, спустя почти 6 недель своего пути, Beads стал намного, намного стабильнее. Это была безумная гонка, порой менялось по 50 тысяч строк кода в день. И никто из нас, контрибьюторов, даже не просматривает этот код. Он на 100% написан ИИ («vibe coded»), сейчас в нем 130 тысяч строк на Go, и примерно половина - это тесты. Десятки тысяч людей используют его в своих повседневных рабочих процессах. Люди говорят мне, что им это так нравится, что они используют его даже для личных списков дел (TODO). А другие направо и налево встраивают его в более крупные оркестраторы. Это также потрясающий строительный блок.

Мы сохранили небольшой объем функционала. Прислушиваясь к мнению сообщества, я отвергаю всё, что не должно быть частью ядра Beads. Поэтому у Beads нет пользовательского интерфейса (UI), но есть множество примеров UI, которые люди создали как проекты «для души» (passion projects). У нас их уже как минимум четыре или пять. Мой приятель и соавтор Джин Ким даже создал свой собственный UI для Beads на Java Swing! Он был так взволнован, когда показывал мне его. И это действительно было очень круто.

Итак, никакого UI, и у Beads также нет системы планирования. Он не для этого. Но он отлично интегрируется с любой системой планирования - просто составьте план, а затем попросите агента создать в Beads эпики и задачи (issues) для этой работы. После того как эпики будут готовы, вы можете натравить на них любое количество агентов, чтобы они их «разгребли».

Последняя большая категория, которую люди постоянно пытаются втиснуть в Beads, - это оркестрация. Мы знаем, что оркестрация неизбежна. И есть соблазн сделать Beads более активным; сегодня он довольно пассивен и ожидает, что Агент будет использовать его как инструмент. Но люди хотят большего. И я их понимаю. Однако этому не место в Beads.

Я занимался вайб-кодингом (vibe coding) как одержимый сорок дней и сорок ночей. Это долгая история, поэтому я резюмирую её в этих трех картинках.

Слева, 3 недели назад: я вайб-кожу на пляже за ужином в Кабо-Сан-Лукас, Мексика, с неподражаемым Торстеном Боллом, нашим приятелем Мэттом Манелой и другими коллегами из Sourcegraph на корпоративном выезде. Кто-то сделал это фото, потому что я отказывался убрать компьютер.

В центре, 2 недели назад: фотография, на которой я фотографирую сам себя, пока еду на скорости 100 км/ч (60 миль/ч) по шоссе в Беллингем, чтобы забрать гитары, занимаясь голосовым вайб-кодингом всю дорогу туда и обратно. Глупо и чертовски опасно. Мне было плевать. Застрял в пробке на несколько часов. Всё равно плевать. Я упоминал, что это вызывает привыкание? Вайб-кодинг вызывает привыкание.

На последнем кадре: мы с женой в торговом центре на прошлой неделе, наслаждаемся приятным днем с кофе, наблюдаем за людьми и вайб-кодим вместе с Моцартом (на фото он в своей любимой сумке). Лин прячется за компьютером - так я получил разрешение руководства на публикацию снимка.

Я никуда не хожу и не делаю ничего, даже не сплю, без своего ноутбука. Ну, разве что когда бегаю - там я ещё не совсем раскусил, как вайб-кодить. Но я близок. Это тема для отдельного поста, но у меня наконец-то работают агенты на GCP с Terraform и Tailscale. Так что скоро я смогу вайб-кодить и с телефона.

Агенты никогда не должны отдыхать.

Те, кто хоть раз пробовал что-то сделать на Flutter, обычно начинали с того, что создавали новый Dart-файл и писали stfl, что сразу создавало шаблонный StatefulWidget с указанным именем для виджета и его состояния. В среде Flutter это называется Live Templates, но по сути — это сниппеты.

Помимо стандартных сниппетов stfl и stls, существуют и другие базовые шаблоны, которые уже установлены по умолчанию. А именно:

Анимация смены темы в Android-версии Telegram на протяжении долгого времени вдохновляет разработчиков на попытки реверс-инжениринга этого красивого трюка: в сети немало подробных гайдов, как сделать подобную анимацию при помощи традиционных XML View и даже Flutter. Но реализаций этой элегантной (хоть и совершенно бесполезной) анимации на Jetpack Compose мне найти так и не удалось, что привело к созданию маленькой библиотеки для анимирования смены темы.

Вера в будущее KMP также подтолкнула меня к тому, чтобы сделать ее из коробки готовой к установке в Compose-Multiplatform проекты, с поддержкой всех основных платформ (Android, iOS, Desktop JVM, Web WASM+JS).

Хотя сама библиотека вышла крайне компактной, ее реализация оказалась довольно нетривиальной на мой субъективный взгляд и может быть интересна каждому, кто изучает Compose или ищет подобные решения для своего проекта.

На старте написания библиотеки сами собой возникли ряд требований, которым она должна была отвечать:

Астрология и сопутствующие эзотерические практики не имеют научного обоснования. С позиции доказательного подхода это форма шарлатанства, основанная на вере в корреляцию между положением небесных тел и человеческой судьбой. Несмотря на это, рынок подобных услуг существует и оценивается в миллиарды долларов ежегодно. По статистике, каждый третий взрослый человек на планете обращался к астрологии в той или иной форме.

До появления мощных языковых моделей цифровые инструменты в этой области были примитивны — генераторы общих гороскопов, простые расклады карт. Они не могли конкурировать с живыми консультантами по глубине анализа и персонализации. Профессиональные астрологи используют сложные расчеты эфемерид, систем домов, аспектов. Их услуги стоят дорого, так как требуют времени и определенной экспертизы, даже если сама экспертиза построена на непроверяемых предпосылках.

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

В общем, мы по-своему воюем с шарлатанами, обесцениваем их труд. Если сложный расчет натальной карты можно получить бесплатно за несколько кликов, мотивация платить крупные суммы живому астрологу снижается. Это сокращает финансовые потоки в индустрии, оставляя в ней только тех, кто готов платить за ритуал общения с человеком, а не за сам результат вычислений.

Можно получить идеальные 60 FPS и зелёные метрики — и всё равно услышать от пользователей «невозможно работать». Потому что мозг прощает “мыло”, но не прощает задержку: курсор начинает жить своей жизнью, клики “не туда”, печать с запозданием.

В этой части разбираю Input Channel, Cursor Channel и round-trip latency: почему SPICE таскает курсор отдельным каналом, откуда берётся эффект «курсор на резинке», чем отличается server mouse mode от client mouse mode, и почему без usb-tablet / vdagent всё быстро превращается в квест.

Третья статья серии — про то, что реально определяет UX в VDI: не картинка, а отклик.

2025 год стал для ИИ временем отрезвления. Эпоха масштабирования подходит к концу. Эксперты сходятся во мнении, что простым увеличением данных и вычислительной мощности следующий качественный скачок не совершить. На первый план выходят новые архитектуры, компактные модели и принципиально иные подходы к обучению.

В 2026 году индустрия, похоже, даст ответ на вопрос, что ИИ может дать нам здесь и сейчас. Мы вступаем в эпоху прагматичного ИИ.

Попробуем разобраться, какие именно тенденции определят лицо ИИ в наступающем 2026-м году.

Всем привет!

Идея LensDB родилась с простого поста моего друга. он делился своим опытом создания Shared Memory кэша для своего пет-проекта на C#. В этом посте он написал:

Q65 — цифровой протокол, разработанный Джо Тейлором (K1JT) и его командой в 2021 году для проведения минимальных связей в условиях сложных трасс прохождения радиосигнала.

В предыдущей части части были рассмотрены общая структура протокола и алгоритмы формирования сигнала. В этой части статьи рассматриваются принципы цифровой обработки сигналов и синхронизации в протоколе Q65.

Статья может быть интересна радиолюбителям и людям, интересующимся темой цифровой обработки сигналов.

Так уж случилось, что из разработки железа и встроенного ПО я постепенно ушел в безопасность. А в дальнейшем и в пентест. Мой первый заказ по чтению залоченной прошивки.

«Нет никакой защиты, есть только количество времени и знаний, необходимых для достижения цели.»

Как вы знаете в STM32 много 16 битных таймеров. При этом их разрядности порой не достаточно для получения тайм штампов.

Проблема в том, что в STM32 таймеры обладают очень низкой разрядностью. Большинство таймеров 16 битные. Есть только два 32 битных таймера и они обычно чем-то заняты.

При этом большинство прошивок требуют возможности получать микросекундные тайм штампы. Это нужно для выдерживания пауз, для планировщика, для подписывания логов и прочего. То есть нужен таймер, который увеличивается на 1 каждую 1 микросекунду и не переполняется в обозримой перспективе.

В случае 16 битного таймера такой таймер будет переполняться каждые 65 ms. Это плохо.

Попробуем разобраться, что делать в этой ситуации.

Стандарт ISO 7816 состоит из 15 частей и главным образом нацелен на приведение к общему виду тех отраслей, что используют смарт-карты. Четвертая часть документа описывает логическую структуру файловой системы, получившую широкое распространение: ее можно встретить в идентификационных документах, средствах криптографической защиты информации, в банковском секторе и телекоме.

Проснулись, потянулись, зашли в новости, а там за ночь вышло пять новых нейросетей, две из которых уже успели устареть, пока вы чистили зубы. Добро пожаловать в реальность, где вчерашний прорыв сегодня годится только для мемов. Бедный Уил Смит и спагетти. Мы тут только-только привыкли к 2025-му, а индустрия уже вовсю пакует чемоданы в 2026-й.

Кажется, если моргнуть чуть дольше обычного, можно пропустить момент, когда ваш холодильник начнет писать код на Python.

Чтобы не потеряться в этом бесконечном параде релизов и не пытались гуглить ответы в Яндексе, мы собрали «Арсенал 2026». Это те инструменты, которые помогут не просто разобраться в мире ИИ, но и заставить его работать на вас, пока остальные всё еще пытаются правильно составить промпт для генерации котиков.

Разминайте пальцы и готовьтесь - сейчас будем смотреть на то, с чем мы влетаем в этот год.

Приятного прочтения!

Автор: Денис Аветисян

Обзор посвящен стремительно развивающейся области применения больших языковых моделей для оптимизации, трансляции и конструирования компиляторов.

В детстве, которое пришлось на 90-е, мне очень хотелось иметь Интернет. Родители не собирались его подключать, поэтому я позвонил провайдеру и сказал, что хочу создать аккаунт. У меня спросили фамилию, я назвал вымышленную. Потом у меня спросили номер кредитной карты, я сказал, что мне нужно найти бумажник, после чего я перезвоню.

Из книги Big Secrets и нескольких выпусков журнала 2600 я знал пару фактов о кредитных картах. Номера карт American Express всегда состояли из 15 цифр и начинались с тройки, а номера карт Visa состояли из 16 цифр и начинались с четвёрки. Первая пара цифр обозначала банк-эмитент, затем шёл номер счёта; последняя цифра вычислялась при помощи алгоритма Луна и использовалась как контрольная сумма всех предыдущих цифр.

Самый частый вопрос к тезису о том, что языковые модели не думают - чисто практический.

В предыдущей публикации я выдвинул тезис, который многих заставил почувствовать себя неуютно: большие языковые модели не мыслят. Они не рассуждают так, как это делает человек. Они лишь предсказывают следующий токен.

Самым частым возражением было не философское, а практическое:

«Если это правда, то как ИИ удается заниматься арифметикой?»

Сложение, вычитание, умножение - эти процессы кажутся точными, механическими и основанными на строгих правилах. Они выглядят полной противоположностью «размытому» предсказанию языка. Поэтому естественно предположить, что где-то внутри модели спрятан калькулятор или нечто очень на него похожее.

Но его там нет. Однако происходит кое-что весьма любопытное.

Большинство гайдов по C# в Интернете или давно утратили актуальность, или содержат лишь небольшие вкрапления новых возможностей, но лишены последовательности. Есть и другая крайность - ИИ простыни сгенерированного текста под видом статей, которые очень тяжело читать. Я хочу сделать свою попытку изменить ситуацию.