DC7831 Info Channel

Quoll v0.3.0 Выложил первую публичную версию Quoll v0.3.0 — моего нового языка разработки с ИИ-агентами. Он заставляет агентов работать с кристаллизованными контрактами, а не со свободной семантической интерпретацией текстов. Делая интерфейсы формальными, а тела реализаций — приватными, он превращает исходный код в компактный и жёсткий, не подверженный эрозии «экзоскелет», который агенты могут безопасно развивать, а люди — быстро читать. https://github.com/rete-labs/quoll — лицензии Apache 2.0 OR MIT. Quoll написан на самом себе. В этой базовой версии его возможности ограничены абстрактными вещами, т.к. системы сборки в целевой язык пока нет. В следующих выпусках: - quoll v0.4.0: проекты, зависимости и базовая сборка в целевой язык - std: стандартная библиотека языка, первый модуль в ней — fs, API для работы с файловой системой - quoll check: первый инструмент из toolchain языка, механическая проверка проекта на quoll на наличие ошибок - quoll v0.5.0: поддержка тестов - authoring на quoll и её продукт quoll-skills: система создания проектов на quoll и целевых языках (система генерации и сборки с агентами) - вебсайт quoll-lang.org на quoll, с рендерером quoll-проектов Следите за новостями!

Чему учить инженера, когда код генерирует агент Факт того, что код генерирует агент, обесценивает всё, что относится к непосредственному написанию кода: синтаксис, названия API, идиомы на уровне отдельных выражений и т.п. Агент делает это сам и делает хорошо. Остаётся только то, что поддерживает человеческие качества — непрерывность, понимание и ответственность. Мы выделили четыре ключевых навыка. Модель исполнения. Понимание требует модели исполнения — знать, что код делает на самом деле: кому принадлежат данные и сколько они живут, где поток блокируется, что происходит с задачей при отмене, где появляется копия. Зачастую типовые дефекты лучше человека находит агент-ревьюер, но без модели исполнения человек не может ни проверить находку, ни понять, чего не нашли, и ревью превращается в механическое чтение текста. Суждение. Это отдельный навык, из понимания оно не следует. Картина знакомая: разработчик прекрасно понимает собственный код, но о чужом судить не может. Причин две. Для своего кода автор держит в голове замысел, а в чужом его приходится восстанавливать по тексту — это другая работа. А у кода, сгенерированного без решений человека, замысла нет вовсе: агент не субъект, и из такого кода можно извлечь лишь фактические решения. И даже поняв, что код делает, нужно ещё решить, хорошо ли так, а для этого нужны критерии: архитектурные практики, соглашения команды, представление о том, куда система пойдёт дальше. Эти критерии зачастую неявные и даже субъективные, и в контексте агента их обычно нет. Суждение нужно для того, чтобы принимать изменения от кого угодно — агента или человека — и вести систему дальше, отличая то, что пойдёт на пользу её будущему, от того, что ему повредит. Решения до кода. Ответственность за сгенерированный код требует, чтобы решения по нему были приняты до генерации. Создание кода — это решения и их воплощение, и под надзором агенту отдаётся только воплощение. Решение, не принятое явно, всё равно будет принято — агентом. Это нормально, если делегирование осознанное; проблемы начинаются, когда решения уходят к агенту самотёком. Записанные решения поддерживают и непрерывность: следующая сессия агента или другой человек начинают не с чистого листа. Кроме того, отвечающий за код должен знать, какие места он обязан читать сам, не полагаясь на тесты — это места, имеющие обязательства обо всех входах и места, где ошибки приводят к необратимым последствиям. Эволюционное проектирование. Правки агентов копят эрозию — каждое следующее изменение обходится дороже предыдущего, и промптами это не лечится. Мы предлагаем новый способ рефакторинга, где двигатель — генерация: фрагмент, накопивший правки, не правят в очередной раз, а генерируют заново — по решениям и предыдущей версии; до шага ценное закрепляется тестами, после шага результат сверяется. Такой рефакторинг работает на небольших масштабах. Чтобы поднять его на уровень системы, нужны верные границы между её компонентами. Создание и поддержание таких границ — это уже не только инженерия, но целое искусство. — Этим навыкам, в особенности первым трем, я буду обучать на своём курсе по Rust в AI-эпоху. Метод обучения строится вокруг того факта, что обучающиеся имеют доступ к фронтирным агентам, и абсолютно все рабочие артефакты генерируются — и при этом курс не пройти вайбкодингом. Как именно это достигается, расскажу в следующем посте. Введение в тему будет сделано в моем докладе на бесплатной конференции сообществ ITGorky 17 октбяря — регистрируйтесь и приходите! #ai #ai_first #software_engineering #rust

Что остается за инженером, когда весь код генерируется ИИ? Крупные ИТ-компании переходят к парадигме разработки с использованием ИИ-агентов. Например, в Яндексе поставлена цель 75/75/75 — до конца года выйти на уровень генерации 75% кода. ИТ-стартапы переходят к использованию ИИ ещё быстрее, и для них практически достижимым является уровень в 100%. Что же в такой ситуации остается за инженером? Известны два полярных ответа. Первый называется "вайбкодингом", или полной автономией — в такой парадигме агенты получают лишь грубые постановки задач, зачастую от человека, не являющегося инженером, и все остальное делают сами. Второй ответ — продолжать работу как и раньше, считая агента членом команды разработки, этаким миддлом, способным решать поставленные задачи наравне с человеком, и проходить через те же процессы, в которых участвуют разработчики-люди; в частности, ревью кода другими разработчиками и лидерами команд. Оказывается, что оба этих подхода плохо работают на практике. Вайбкодинг ломается потому, что агенты не способны поддерживать кодовую базу: с каждым изменением она эродирует всё сильнее, пока не "сгнивает" полностью. В бенчмарке SlopCodeBench агент раз за разом дорабатывает собственное решение по мере того, как раскрываются требования. Ни один агент не доводит задачу до конца, а у лучшего из них — всего лишь 14.8% решённых этапов. Структурная эрозия кода копится в разы быстрее, чем у человека, а качественные промпты снижают стартовый уровень проблем, но скорость деградации не меняют — то есть промпт-инжинирингом это не лечится. Подход с сохранением человеческих процессов ломается из-за того, что генерация кода агентом практически мгновенна и стоит дешево, но ревью кода становится узким горлышком — это внимание человека. В итоге ускорение значительно меньше ожидаемого, при том что инженеры оказываются перегруженными ревью и правками сгенерированного кода. Между этими полюсами индустрия ищет практические ответы, но общепринятого процесса пока не выработала. Самый известный из них — разработка на основе спецификаций (spec-driven development): агент работает автономно, но по подробной спецификации и под контролем тестов. Это закрывает вопрос корректности, но не эрозии. Тесты смотрят на программу снаружи, а гниёт она изнутри: тест не видит, что одна функция теперь живёт в трёх местах. Другой ответ пока известен гораздо меньше — разработка на основе решений. К ней независимо пришли и исследователи и практики, поэтому она известна под разными названиями (decision-driven development, decision-oriented programming и другие). В этой парадигме главный артефакт между человеком и агентом — не спецификация и не код, а явные проектные решения. Спецификация описывает, что программа должна делать; решения фиксируют, как она устроена — именно то, чего не видят тесты снаружи. Решения принимаются до написания кода и записываются вместе с обоснованием, код генерируется по ним, и каждую его часть можно проследить до решения, которое она реализует. Мы не знаем, какой станет разработка через год: отрасль ещё далека от равновесия. Но мы предполагаем, что три качества надолго останутся эксклюзивными для человека: - Непрерывность: агент начинает каждую сессию с чистого листа. - Понимание: агент не понимает систему, которую меняет. - Ответственность: агент не субъект и отвечать за результат не может. В следующем посте разберем, какие навыки позволяют поддерживать эти качества инженеру — и именно им я буду обучать на своём курсе "Rust для AI-first разработки: код генерирует агент, решения принимает инженер". Эти темы также прозвучат в моем докладе на конференции ITGorky 17 октбяря - приходите!)

Всем привет! Собираемся на оффлайн-встречу в Нижнем Новгороде 17 октября, на конференции ИТ-сообществ :) Ищу спикеров и активистов, кто хочет поучаствовать в организации. Пишите мне @wsnark Наши темы - ИБ и Раст (мини-секция, будет впервые). https://itgorky.ru/bolshaya-vstrecha

Pre-Seed закрыт: строим ядро Florete и Workspace РетеЛабс закрыла раунд Pre-Seed: мы получили финансирование от частного инвестора. Средства пойдут в ядро платформы Florete и в её первую коммерческую редакцию — Florete Workspace. Одно ядро, три редакции: — Edge Mesh для подвижных узлов (дроны, наземная робототехника, IoT), — Service Mesh для гибридных облаков, — Workspace для корпоративной связности. Control plane и агент на узлах один и тот же: работа над MVP Workspace строит фундамент, на котором стоят остальные редакции. Редакция Workspace идёт первой, потому что её боль — самая острая, а цикл — самый короткий. Именно сейчас доступ к внешней инфраструктуре разработки нестабилен, а корпоративный VPN-шлюз остаётся единой точкой отказа: если он упал, то встаёт работа всей команды. Один день простоя команды из 20 разработчиков стоит сегодня около 200 тыс. ₽. MVP — это облачный control plane и агент на узлах. Control plane вычисляет топологию сети и раздаёт политики, агенты поддерживают самовосстанавливающийся mesh поверх разнородных каналов и перестраивают маршруты в обход отказов. Узлы прокачки трафика клиент поднимает на своей инфраструктуре — пользовательский трафик не проходит через наше облако. На каждом соединении — mTLS с криптографической идентичностью узла (X.509-SVID). Разработка Edge Mesh идёт отдельным треком: мы развиваем его вместе с индустриальными партнёрами в рамках инженерной программы с финансированием, независимым от этого раунда. Ядро Florete остаётся открытым. Разработка идёт открыто на Гитхабе под Apache 2.0 / MIT, на Rust, с использованием QUIC — https://github.com/rete-labs/florete Следующая наша точка — пилотные проекты Workspace с дизайн-партнёрами, уже подписавшими письма о намерениях, и раунд Seed осенью. Если хотите одними из первых попробовать Workspace или обсудить участие в Seed-раунде — пишите мне в ТГ @wsnark или на почту ceo@rete-labs.ru Спасибо всем, кто поверил в нас на этой стадии. Вперёд, только вперёд! Фёдор Ляхов, основатель РетеЛабс #анонс #компания #инвестиции

Всем привет! У нас отличные новости! 26 июля с 15:00 до 21:00 нас ждет очередная встреча DCG#7812, она же K0R48LYK 🌝 Теплоход: Москва-183, «Английская пристань» Английская наб., д. 28 Будет всё как мы любим: доклады и атмосфера дружественного общения в окружении морского бриза. Если вы хотите что-то рассказать, то пишите мне в личку - @rusdacent Стандартный временной слот - 40 мин, но если ваш доклад рассчитан на меньший слот, то тоже скидывайте Формат сообщения: - Тема доклада - Краткое описание, о чём хотелось бы рассказать - Временной слот под доклад, который вы хотели бы взять Свистать всех наверх!

Сетевая экспертиза для ваших продуктов Если у какого-то вашего продукта есть боли в области сетей, мы можем быстро провести ревью и помочь с решением. Варианты: - Ревью сетевой архитектуры продукта: анализ того, как продукт работает по сети (протоколы, соединения, безопасность, масштабирование) - Ревью сетевой безопасности продукта: поиск уязвимостей на уровне архитектуры и кода - Оценка применимости Rust: стоит ли переписывать критический компонент на Rust? Мы оценим и, если да, поможем спроектировать первый модуль Сроки: от 2 недель + 1 месяц поддержки Результат: PDF-отчет, презентация для CTO, передача экспертизы вашей команде Эксперты РетеЛабс — не просто консультанты, а практикующие инженеры. Мы сами разрабатываем распределённые системы: наш открытый проект сетевой технологии Florete говорит сам за себя. Работаем с командами, которые ценят глубину, а не поверхностные советы. Подробнее об условиях и форматах: 👉 https://rete-labs.ru/cooperation/consulting #Consulting #DistributedSystems #NetworkSecurity #ReteLabs

Для финансирования разработки открытого проекта Florete ищу клиентов на консалтинг по сетевым технологиям: https://t.me/rete_labs/11 Буду рад репостам и контактам техдиректоров ИТ-компаний, занимающихся созданием продуктов с сетевыми функциями. Личка: @wsnark

Всем привет! RULKC приглашает всех на очередную конференцию Russian Linux Kernel Community по разработке ядра и системного ПО OSDevConf 2025! 🫡 В этом году мы собрали много хардкорных докладов по ядру, системщине, а также сделали отдельную секцию про стык AI и HW/FW/OS. Коллаборация с митапом альянса RISC-V окунет Вас в мир удивительной архитектуры, позволит познакомиться с собществом, которое решает вопросы повышения её применимости. Вы сможете стать свидетелем того, как Wildberries и МЦСТ на одной сцене рассказывают про самые-самые тренды в отладке и профилировании ядра Linux. Как говорится "Это еще цветочки, а ягодки впереди". Приходите и сами все увидите. Всех ждём! 😎 Программа и регистрация (можно оффлайн и онлайн): https://osdevconf.ontico.ru/ Коллеги, будет хардкор по ядру Linux и системной разработке. А главное -- много общения с сутевыми людьми. Обязательно приходите или подключайтесь онлайн. Подробнее про сообщество Russian Linux Kernel Community можно узнать здесь: https://rulkc.org/

Spring QA Meetup 2024 Суббота, 18 мая 2024 12:00, г Нижний Новгород, ул Алексеевская, д 6/16 Corner Place, MTS Startup HUB Привет, друзья! Мы сформировали программу полностью. 18 мая нас ждет 6 докладов на следующие темы 1. Не тереби мое API, Сафонов Лука, лидер российского OWASP, автор нескольких продуктов ИБ 2. Управление процессом тестирования на основе модели TMMi, Телицына Ольга, ведущий консультант компании NEOFLEX 3. Нагрузка без стресса: всё работает, а мы отдыхаем, Гонускус Валентина QA-lead Effective Technologies 4. Вектора атак на AI решения, Александр Смирнов. AppSec в Циан 5. Искусственный интеллект, как упрощение жизни тестировщика, Мария Воронова, Главный инженер по разработке, Сбер 6. Пишем кастомный фреймворк для тестирования ваших приложений, Артем Хюппенен, автоматизатор тестирования систем хранения данных, YADRO 🍺Так же нас ожидают пицца, напитки , прочие вкусняшки и различные конкурсы от партнеров и организаторов Зарегистрироваться можно по ссылочке https://it52.info/events/2024-05-18-spring-qa-meetup-2024

Я не специалист по ядру, но в одной из моих команд - команде разработки ПО для "железа" (терминалов авиационной беспроводной связи) - мы сейчас создаем по сути драйверы специализированных устройств и другие низкоуровневые компоненты на Си в пространстве пользователя. И, конечно, есть желание сделать что-то типа расширяемой платформы, ориентиром для которой, естественно, служит ядро. И если всё достаточно понятно с тем, как поддержать некий общий интерфейс драйвера (инициализация/деинициализация, suspend/resume и т.п.), то не совсем ясно, как в такой общей платформе одно устройство может использовать другие. Из общих архитектурных соображений (принципа инверсии зависимостей, буква D в SOLID) прямой связи быть не может - все модули должны зависеть только от абстракций. В ядре видимо это так и сделано, насколько я понял из ответа Матвея - для различных подсистем имеются интерфейсы, которые реализуются конкретными драйверами - а другие драйверы могут пользоваться этими интерфейсами, если доступна их реализация. Примеры драйверов, которые мы реализуем: управление электродвигателем, управление радиотрактом. Они, в свою очередь, используют низкоуровневые чипы или ПЛИС для работы. Буду рад, если поделитесь какими-нибудь деталям или конкретным примерам подобных зависимостей между драйверами в ядре в комментариях :)

Сегодня на конференции DEFCON Ульяновск был интересный и полезный мне доклад - введение в модули и драйверы ядра Линукс от Матвея Быстрина. По своему обыкновению я задал вопрос по теме, которая меня волнует на работе.

Интервью с основателем DEFCON Ульяновск Романом @deadroot Ананьевым

Начинается конференция DEFCON Ульяновск :) https://t.me/dc20e6 Очень приятно встретить множество знакомых) Программа: https://dc78422.ru/meetup/0x09/ Онлайн-трансляции нет, но будут записи докладов

DC7499 уже в эту субботу, 13 апреля. Начинаем в 14.00, послушаем доклады, пообщаемся, а после пойдем в бар. 1. Тема: Способы получения учетных данных пользователей без взаимодействия с lsass. Докладчик: Жмайло Михаил (mzhmo) 2. Тема: Exploiting Windows kernel for sandbox escape. Докладчик: anonymous kernel mode guy 3. Тема: DIY server for home lab. Докладчик: Купреев Олег (0x90) Координаты: 55.808838, 37.629518, Москва, м. Алексеевская, ул. Годовикова, 9с17, подъезд 2, конференс-зал на цокольном этаже. Наш канал: @DC7499NEWZ Регистрация

Интервью с Никитой, представителем YADRO на стенде сервера VEGMAN. Это продукт, разработанный и производящийся в России, предназначен для решения общих задач в корпоративном секторе. Есть модификация, оптимизированная под сетевые нагрузки. Основным преимуществом российской разработки является полноценная поддержка на русском языке - Никита как раз работает в ней. По его словам, в Ядре разработали материнскую плату, а также микрокод и Биос к ней.

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

Интервью с Никитой, представителем YADRO на стенде сервера VEGMAN. Это продукт, разработанный и производящийся в России, предназначен для решения общих задач в корпоративном секторе. Есть модификация, оптимизированная под сетевые нагрузки. Основным преимуществом российской разработки является полноценная поддержка на русском языке - Никита как раз работает в ней. По его словам, в Ядре разработали материнскую плату, а также микрокод и Биос к ней.

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

Новости от партнёров, компании Positive Techologies: Любишь сложные задачи и щелкаешь CTF как орешки? Возможно, пора левелапнуться попробовать что-то новое и поучаствовать в кибербитве Standoff 13. Она пройдет в «Лужниках» с 22 по 25 мая одновременно с фестивалем PHDays 2. Команды атакующих поделятся на два лагеря и будут ломать инфраструктуру виртуальных государств F и S. Ты можешь найти единомышленников, объединиться с ними в команду и принять участие в отборочных соревнованиях, которые продлятся до 10 апреля. А если получится их пройти — побороться за рекордный призовой фонд в 7,5 млн рублей. Плюсы: - это весело; - можно получить хороший приз, а даже если ничего не выиграешь, посмотришь, что это такое — крушить и ломать играть на стороне красных; - возможно, ты разбудишь в себе пентестера и узнаешь, что умеешь гораздо больше, чем представлял. Минусы: отсутствуют. Подать заявку и узнать все подробности можно на сайте Standoff 13, а поискать сообщников команду — в чате Standoff 365. Присоединяйся!