tgindex

Искусство. Код... ИИ?

описание

Канал о прекрасном и не очень, вокруг кода, искуственного интеллекта, и их безопасности. Навигация по каналу: https://t.me/art_code_ai/105

← к каналу@art_code_ai
627
подписчиков
Охват к подписчикам
124,7%
ERR
Реакции к просмотрам
2,08%
778 на 50 постов
Пересылки к просмотрам
2,14%
800
Постов в день
0,0
всего 82

Где отзываются чаще

доля реакций к просмотрам
  • 2 маябез подписи8,56%
  • 30 апр.без подписи8,06%
  • 18 мар.Вы как, слушаете подкасты? Мне нравится и послушать, и поговорить. Недавно вот, был в гостях у подкаста «В SREду на кухне», который ведут инженеры Avito. Обсуждали, как безопасность влияет на надёжность, где чья зона ответственности и в какой момент разработки уже пора думать о безопасности. Посмотреть и послушать можно на YouTube, VK Video, RuTube или на странице подкаста. #ссылки7,07%
  • 28 июл.без подписи6,33%
  • 26 мар.без подписи5,07%
  • 7 авг.🗂 Поддержка agentic-проектов в SECURITY.md security-policy-generator (скилл для генерации SECURITY.md с моделью угроз и кастомизированными под проект правилами безопасного кодинга для агентов — подробно рассказывал о нём тут) теперь поддерживает agentic security, для релевантных проектов, покрывая все аспекты OWASP ASI, как моделью угроз, так и правилами генерирования безопасного кода. Пример готового SECURITY.md, сгенеренного новой версией скилла, можно подсмотреть в c0wrk. Btw, я пока так и не смог спровоцировать агента (c0wrk|OpenCode × GLM-5.2|DeepSeek-V4 Pro|GPT-5.6 Sol) сгенерировать уязвимый код в проектах, с построенным этим скиллом SECURITY.md, хотя очень и целенаправленно пытался 🙈 🙌 #безопасность_кода #ИИ_инструменты5,06%
  • 10 мая📌 VibeSpec — мой подход к SDD ⚠ TL;DR: лежит здесь ☺ К агентской разработке через спецификации (Spec-Driven Development, SDD), как к работающему способу получить хоть какой-то контроль над gen-AI кодом у себя в проектах, я пришёл чуть раньше, чем на свет появились OpenSpec, Spec-Kit и, тем более, угарный Get-Shit-Done. Таких фреймворков намного больше, перечислил только те, которые прям плотно тестировал, по мере их выхода в свет (из них всех мне больше всего зашел OpenSpec, если что). Но понимаете, «для Атоса это слишком много, а для графа де Ла Фер — слишком мало». Большинство проектов, над которыми я работаю, во-первых, весьма среднего объема (десятки KLoC максимум), а во-вторых, в них почти всегда research преобладает над development. Попробовать реализовать одну и ту же штуку 3-5 разными подходами, а потом из них собрать один — мой нормальный повседневный воркфлоу. И любое навязывание «ни шагу без спецификации» при «нет, ты не можешь обновлять спеку по коду» этот процесс невероятно замедляет. Поэтому, последний год, я пользовался примитивным, но достаточно эффективным подходом: одна спека на весь проект + одна команда, позволяющая найти несоответствия между ней и кодом, и устранить их правкой, либо кода, либо спеки. Когда я знал, чего хотел, то просто описывал это в спеке и вызывал команду, в результате которой, агент писал нужный код. Когда не знал, после многочисленных, но в итоге успешных, издевательств над кодом с кучей ручных правок, я снова вызывал команду, и агент корректировал спеку по изменениям в коде. И это прям здорово работало. До тех пор, пока спека не разрасталась до неприличных объемов, осилить которые, уже не мог, ни агент, ни я сам. Стало понятно, что в таких проектах спеку нужно разбивать на смысловые части, и адаптировать воркфлоу с их учетом. Так и родился VibeSpec — набор скиллов, позволяющих вести разработку по SDD в условиях постоянного ресерча и спонтанных правок кода без учета спецификаций. Спецификации делятся 5 на категорий: 1️⃣ meta + index: спека про спеки, индекс для навигации по существующим документам; 2️⃣ architecture: слои, жизненный цикл, модель безопасности и т.п; 3️⃣ domains: фичи, бизнес-логика, инварианты; 4️⃣ contracts: интерфейсы между слоями архитектуры; 5️⃣ decisions: по сути, все ADR'ы, принятые в ходе работы над проектом. Для работы с ними есть 5 agent-agnostic скиллов: 1️⃣ vibespec-init: первичное построение всех категорий спек по кодовой базе; 2️⃣ vibespec-create: создание новой спеки любой категории; 3️⃣ vibespec-update: обновление уже существующей спеки; 4️⃣ vibespec-check: проверка спек и кода относительно друг-друга и приведение в соответствие; 5️⃣ vibespec-consult: оценка по описанию изменений, какие спеки оно затронет, что сломает и т.п. Таким образом, после первоначального init, весь воркфлоу сводится к: consult → create/update → check или (безудержный [вайб-]кодинг) → check. И главное, никаких навязанных шагов по spec-first, которые нельзя было бы сделать позднее, после финальных изменений в очередной фиче. Вот так это выглядит в пет-проекте, над которым сейчас работаю: specs ├── architecture │ ├── data-flow.md │ ├── layers.md │ └── security-model.md ├── contracts │ ├── backend-core.md │ ├── core-sdk.md │ ├── desktop-frontend.md │ └── event-catalog.md ├── decisions │ ├── _template.md │ ├── 001-single-module.md │ ├── 002-sdk-isolation.md │ └── 003-cgo-free-sqlite.md ├── domains │ ├── frontend │ │ ├── events.md │ │ ├── README.md │ │ ├── rendering.md │ │ └── stores.md │ ├── llm-providers.md │ ├── memory │ │ ├── blackboard.md │ │ ├── compaction.md │ │ └── README.md │ ├── orchestration │ │ ├── executor.md │ │ ├── planner.md │ │ ├── README.md │ │ └── router.md │ ├── session-lifecycle.md │ ├── tool-system │ │ ├── builtins.md │ │ ├── mcp-gateway.md │ │ └── README.md │ └── workspace.md ├── INDEX.md └── META.md Всё 🙌 #ИИ_инструменты4,85%
  • 15 апр.без подписи4,79%
  • 28 июн.Разработчики 🆚 ресерчеры Уже много лет, как стало модно делить людей на «разработчиков» и «ресерчеров» (теперь ещё и на «экспертов», но сегодня не об этом). Должностные инструкции и оргструктура закрепляют это разграничение как данность, а в некоторых компаниях эти функции физически разнесены, не просто между должностями, но и между целыми направлениями. Однако же, если отвлечься от позиций в штатке, то на самом деле, это — два фундаментально различных режима мышления. Майндсета, способных и должных сосуществовать в голове одного инженера. Различие между ними изучено достаточно хорошо. Ещё в 1991 году профессор Стэнфорда Джеймс Марч описал дилемму «exploration–exploitation» Exploration — это поиск нового, эксперимент, риск и открытие. Exploitation — исполнение, оптимизация, доведение до совершенства известного. И это, как мне кажется, прям идеально укладывается на реалии R&D. • Исследовательский майндсет — exploration в чистом виде: способность задавать вопросы без гарантии ответа, комфортно работать в условиях хаоса и неопределённости, видеть картину целиком и замечать неочевидные связи. • Разработческий майндсет — exploitation: умение декомпозировать сложную проблему на выполнимые шаги, доводить гипотезные PoC'и до релиза, принимать архитектурные компромиссы и добиваться воспроизводимого качества. Есть удобная аналогия с правшами и левшами, и здесь она приходится, как нельзя кстати. Почти у каждого есть доминирующая рука, но в течение жизни мы всё же учимся использовать обе. С майндсетами та же история: у каждого есть склонность к одному из них, это нормально. Но почти всегда в фоне присутствует и второй. Распознать их не сложно. Отличительные черты • Исследовательский майндсет: толерантность к неопределённости, способность формулировать проверяемые гипотезы, понимать, чем они отличаются от фичей, и безжалостно их опровергать; навык быстрого входа в незнакомый домен, умение эффективно читать научную литературу и отделять сигнал от шума. Ключевой операционный скилл — мышление вне коробки: задавать вопросы, на которые ещё никто не пытался ответить, решать неразрешимые задачи, смотреть на систему снаружи, а не изнутри. Ключевой софт-скилл — безжалостность к опровержению. Исследователь должен быть готов к тому, что 9 из 10 не то, что гипотез — целых исследований, будут однажды прекращены или отправлены «под стол». Если у исследователя каждый результат его работы залетает в прод, это значит лишь то, что он ставит перед собой недостаточно амбициозные цели. • Разработческий майндсет: системное мышление, умение смотреть на систему изнутри, с учетом всех причинно-следственных связей, допущений и tribal-knowledge; параноидальное внимание к edge-кейсам, дисциплина тестирования и документирования, навык оценки сроков и трудозатрат, способность принимать решения при неполноте данных и нести за них ответственность. Ключевой операционный скилл — декомпозиция задач, позволяющая получать понятные и прогнозируемые результаты в плане. Разработчик, ссылающийся на её отсутствие, сродни художнику, который жалуется, что ему дали чистый холст вместо «картинки по номерам». Ключевой софт-скилл — готовность к критике, как к способу стать лучше (ибо код-ревью и критикующие коллеги тут случаются чаще). Как прокачивать Исследовательский майндсет растёт через чтение и реферирование научных статей вне зоны комфорта (это несложно), участие в исследовательских хакатонах без ожидания немедленного практического результата, документирования гипотез и экспериментов с целью выявления в них причинно-следственных связей. Хорошее упражнение: взять технологию и задать цепочку из десяти «почему?», добираясь до фундаментальных ограничений. Ещё одно (практикуемое автором много лет): прочитав абстракты очередной научной статьи, отложить её в сторону и пофантазировать на тему «как бы я решил эту проблему, если бы умел?». И возвращаться к чтению статьи только после формирования в голове понятного тезисного плана решения поставленной в ней проблемы. Разработческий майндсет формируется через участие в опенсорс-проектах с жёстким код-ревью, привычку доводить пет-проекты до состояния «может использоваться кем-то ещё», регулярное решение алгоритмических задач с ограничением по времени (да-да, олимпиады, Codeforces и LeetCode). Главное упражнение: взять чужой исследовательский прототип и превратить его в готовую к проду систему — с полной реализацией всех фичей, обозреваемостью, тестами, обработкой ошибок и документацией. Ни один майндсет не правильнее и не ценнее другого. Исследователь без разработчика производит красивые, но бесполезные артефакты; разработчик без исследователя эффективно строит не то, что нужно бизнесу и пользователям. Подлинный инженер живёт в постоянном конфликте между exploration и exploitation и использует его как источник энергии, а не выбирает одну сторону и окапывается в ней. Инженер R&D — не должность, не диплом и даже не состояние души. Это человек, в мышлении которого неразрывно сплавлены, как вопрошающая любознательность исследователя, так и конструктивная, доводящая до финального результата, воля разработчика. #мысли_вслух4,28%
  • 9 июн.🖥 Какой может быть безопасная разработка Software 3.0? Продолжаем рубрику «Фантазии вокруг постов коллег». Сегодня у нас на очереди серия публикаций Макса Митрофанова о будущем безопасной разработки и аппсека (рекомендую). Начну с дополнения тезиса Макса о том, что (цитирую) «нельзя просто попросить codex/claude code сделать безопасно». Вообще-то, в целом можно, но только, если делать это с уважением правильно. Не «напиши мне безопасный код», конечно. «Правильно» — сводится к управлению фокусом внимания LLM, вокруг того, чем именно является в каждом конкретном проекте «безопасность». К контекст-менеджменту. После публикации скилла-генератора SECURITY.md я очень много экспериментировал, пытаясь заставить LLM написать уязвимый код в проектах, для которых был построен этот файл. И... не смог. Нет, серьезно, если кто-то сможет — пришлите плс, какой был кейс, промпт, политика, агент и LLM, мне прям реально это нужно для тестов одной штуки. Однако же, в целом согласен с тезисом про нынешнюю важность вендорских обвязок с высоким уровнем экспертности в безопасности. Но по другой причине — Swiss Cheese Model. Идём дальше. С чем обычно ассоциируется термин AppSec в плане инструментов? SCA, SAST, DAST и AF, в первую очередь. И вот с их текущим state-of-the-art есть одна очень большая проблема. Думаю все согласятся с тем, что практика блэклистинга чего-либо, как способа обеспечения безопасности приложений, является анти-паттерном? Тогда скажите на милость, почему буквально все существующие инструментальные средства аппсека работают именно по принципу черных списков? SCA ищет «плохие» зависимости, SAST ищет «плохие» фрагменты кода, DAST — определяет «плохое» поведение приложения, AF — фильтрует «плохие» запросы. Понимаете? ВЕСЬ основной инструментарий аппсека сейчас основан на одном из самых заезженных ЕГО ЖЕ антипаттернов 🤷‍♂️ Безусловно можно (и нужно) усиливать текущие инструменты и подходы к аппсеку через ИИ там, где это имеет смысл. Все LLM-триажеры, агенты анализа кода, автопентестеры и т.п. — всё про это. Но такой аппсек, как был классическим, так и останется им же, лишь усиленным современными технологиями. Но что, если ИИ даёт нам возможность пересмотреть взгляды на весь нынешний инструментарий? Что, если связка формального SAST и ИИ-агента (эдакий neuro-SAST), вместо поиска фрагментов уязвимого кода, будет доказывать их защищенность? А сработками будет то, защищенность чего не удалось доказать. SCA будет полагаться на эту связку, анализируя ей все зависимости. А DAST и AF — на построенный с помощью неё же поведенческий профиль приложения, описывающий то, что для приложения РАЗРЕШЕНО, а не запрещено. В результате, вместо показательного аппсека, мы получим доказательный, гарантирующий, что отсутствие сработок — есть отсутствие уязвимостей. Аппсек без false negatives. Вот такое — уже вполне себе претендует на качественно новый уровень, как мне кажется. Но можно пойти ещё дальше. Нет, буквально: если отойти по этой колее назад на достаточное расстояние (вспоминаем предыдущий пост), то станет понятно, что классический аппсек сформировался таким потому, что тогда, в истоках, просто не было другого выбора. Но сейчас он — похоже, есть. Одним из главных принципов нынешнего аппсека является shift-left — вынос влево по жизненному циклу приложения максимального количества усилий на обеспечение его безопасности. Но что, если мы будем применять описанный выше neuro-SAST, вкупе с грамотно построенными им же под конкретный проект политиками безопасности, не к уже написанному коду, а к... ещё не написанному? Сложно себе представить SAST, воткнутый на правах дискриминатора кода между полушариями мозга разработчика-человека. А вот разработчика-агента, раз уж теперь они пишут код — вообще не вопрос. Как вам такой, доказательный леворадикальный аппсек? Вот, что лично я вижу, как будущее безопасной разработки Software 3.0. #мысли_вслух4,27%
  • 8 июн.«Если тебе дадут линованную бумагу, пиши поперёк» На днях, Денис Кораблев, с которым мне довелось классно проработать несколько лет, порассуждал на тему важности нарушения правил в инженерии (почитайте). И мне, как человеку, на которого эпиграф к «451° по Фаренгейту» оказал куда большее влияние, чем весь остальной роман, очень откликнулось. Настолько, что позволю себе эту тему подхватить. На моё отношение к инженерным исследованиям большое влияние в своё время оказали работы философа-логика Николаса Решера (очень рекомендую почитать хотя бы его «The Limits of Science» в последнем переиздании). Его взгляд на развитие науки — тема не на один пост, но одна его мысль перекликается со множеством работ других ученых, как более ранних, так и поздних: Наука подобна исследованию «параметрического пространства» природы; ограниченность ресурсов (времени, денег, оборудования, талантов) вынуждает на развилках выбирать одно направление и безвозвратно терять другие. У других авторов эта же мысль упоминается, как «зависимость путей», «эффект колеи», «QWERTY-эффект» и т.п. Но суть одна: в ходе любого исследования мы сталкиваемся с необходимостью принимать одну из возможных альтернатив, отбрасывая прочие из-за ограниченности ресурсов. И лишая себя возможности однажды к ним вернуться. Совокупность причин, по которым на всём пути была выбрана та или иная альтернатива, по сути — формируют собой свод правил, определяющих дальнейшее движение, ту самую «колею». Согласитесь, было бы крайне нелогично на одной из развилок выбрать путь, соответствующий ресурсному критерию A, а каком-то из последующих — противоречащий ему? А критерии-то накапливаются... И, с каждой развилкой, это все сильнее удаляет исследователя от возможности рассмотреть принципиально иные пути. Пути, которые возможно, в долгосрочной перспективе, привели бы к куда более эффективному решению, окажись на то у исследователя достаточно ресурсов. К ходьбе по бездорожью, как и к прописи поперек линовки, можно относиться, как к нон-конформизму. В конце-концов, это он и есть. Но также это — единственный, на мой взгляд, способ сделать что-то по-настоящему значимое. Тот самый майндсет хакера, в олдскульном смысле — не удачно воткнуть кавычку в очередной плагин Wordpress'а, а шатать саму систему познания реальности везде, где это возможно (а где невозможно — шатать то, что этому мешает). Уверен, что примерно это имел в виду и Денис. Мы сейчас находимся на одной из наиболее важных развилок, случавшихся за последние десятилетия развития вычислительных технологий. Выбрав правильный путь, можно здорово так продолжить текущую колею, делая её глубже, ровнее и эффективнее. Это очень круто, на самом деле. Но может, посмотреть на это иначе? Ведь сейчас у нас в распоряжении появился ресурс, которого не было на всех предыдущих развилках. Может, стоит отойти немного назад, и хорошенько подумать, а не подходящий ли сейчас момент, чтобы двинуть по бездорожью? #мысли_вслух4,18%
  • 17 маябез подписи4,02%